doc/usecases.texi

   1 @node Use cases
   2 @unnumbered Use cases
   3
   4 @menu
   5 * Occasional connection to mail server: UsecaseMail.
   6 * Unreliable/expensive communication link: UsecaseUnreliable.
   7 * Slow/expensive link for high-volume data, bad QoS: UsecaseQoS.
   8 * Extreme terrestrial environments, no link: UsecaseNoLink.
   9 * Private, isolated MitM-resistant networks: UsecaseF2F.
  10 * Highly secure isolated air-gap computers: UsecaseAirgap.
  11 * Network censorship bypassing: UsecaseCensor.
  12 * Reconnaissance, spying, intelligence, covert agents: UsecaseSpy.
  13 @end menu
  14
  15 @node UsecaseMail
  16 @section Occasional connection to mail server
  17
  18 Assume that you have got your own @url{http://www.postfix.org/, Postfix}
  19 SMTP server connected to the Internet. But you read and write emails on
  20 your notebook, that is connected to it just from time to time. How can
  21 you flush buffered mail queues when your notebook is connected?
  22
  23 One possibility is to log in and run something like @command{postqueue
  24 -f}, but by default you have got only several days so and sender will
  25 receive notification emails that his messages still are not delivered
  26 yet. Also you must have secure link (SSH, VPN, etc).
  27
  28 Another possibility is to use POP3/IMAP4 servers, but this is too
  29 overcomplicated and bloated for the simple task. Not an option. KISS!
  30
  31 Just tell both of your Postfixes (on the server and notebook) to drop
  32 email as a mail via NNCP to specified node. This is done similarly as
  33 with UUCP and as written in
  34 @url{http://www.postfix.org/UUCP_README.html, Postfix documentation}.
  35
  36 Look @ref{Postfix, here} for further information. All mail will be
  37 stored in NNCP @ref{Spool, spool}, that after exchanging and tossing
  38 will call local @command{sendmail} command to deliver them just that was
  39 happened on the same machine.
  40
  41 @node UsecaseUnreliable
  42 @section Unreliable/expensive communication link
  43
  44 Assume that you have got slow modem/radio/cellular link that frequently
  45 disconnects and causes TCP timeouts. Not all HTTP servers support file
  46 download continuation. SMTP does not support resuming at all and heavy
  47 messages is a problem to retrieve. Moreover, each disconnect leads to
  48 the same data retransmission again, that can be expensive to afford.
  49
  50 Just send your mail and files through NNCP. You can use either offline
  51 delivery methods -- read about them in the next section, or you can use
  52 included NNCP TCP daemon.
  53
  54 The command below:
  55
  56 @verbatim
  57 % nncp-file file_i_want_to_send bob:
  58 % nncp-file another_file bob:movie.avi
  59 @end verbatim
  60
  61 will queue two files for sending to @code{emph} node. Fire and forget!
  62 Now this is daemon's job (or offline transfer) to send this file part by
  63 part to remote system when it is available.
  64
  65 @node UsecaseQoS
  66 @section Slow/expensive link for high-volume data, bad QoS
  67
  68 Assume that you can give your relatively cheap 2 TiB removable hard
  69 drive to someone each day at the morning (and take it back at the
  70 evening). This equals to 185 Mbps good quality (without any speed
  71 degradation) link in single direction. What about more and bigger hard
  72 drives? This type of data exchange is called
  73 @url{https://en.wikipedia.org/wiki/Sneakernet, sneakernet}/floppynet.
  74
  75 NNCP allows traffic @ref{Niceness, prioritizing}: each packet has
  76 niceness level, that will guarantee that it will be processed earlier or
  77 later than the other ones. Nearly all commands has corresponding option:
  78
  79 @verbatim
  80 % nncp-file -nice 32 myfile node:dst
  81 % nncp-xfer -nice 192 /mnt/shared
  82 % nncp-call -nice 224 bob
  83 [...]
  84 @end verbatim
  85
  86 @node UsecaseNoLink
  87 @section Extreme terrestrial environments, no link
  88
  89 This is some kind of too slow link. Offline delivery methods is the only
  90 choice. Just send files as shown in previous section, but use removable
  91 media for transferring packets to other nodes.
  92
  93 Assume that you send two files to @emph{bob} node. Insert USB storage
  94 device, mount it and run:
  95
  96 @verbatim
  97 % nncp-xfer -node bob /media/usbstick
  98 @end verbatim
  99
 100 to copy all outbound packets related to @emph{bob}'s node. Use
 101 @option{-force} option to forcefully create related directory on USB
 102 storage if they are missing (for example when running for the first
 103 time).
 104
 105 If you use single storage device to transfer data both to @emph{bob} and
 106 @emph{alice}, then just omit @option{-node} option to copy all existing
 107 outgoing packets to that storage device.
 108
 109 @verbatim
 110 % nncp-xfer /media/usbstick
 111 @end verbatim
 112
 113 Unmount it and transfer somehow to Bob and Alice. When they will insert
 114 it in their computers, they will use exactly the same command:
 115
 116 @verbatim
 117 % nncp-xfer /media/usbstick
 118 @end verbatim
 119
 120 to find all packets related to their node and copy them locally for
 121 further processing. @ref{nncp-xfer} is the only command used with
 122 removable devices.
 123
 124 @node UsecaseF2F
 125 @section Private, isolated MitM-resistant networks
 126
 127 All Internet connections can be eavesdropped and forged. You
 128 @strong{have to} to use encryption and authentication for securing them.
 129 But it is very hard to secure metadata, that leaks during each online
 130 session. When you start your shiny new software server be sure that
 131 there could be huge quantity of bogus peers trying to perform
 132 @url{https://en.wikipedia.org/wiki/Sybil_attack, Sybil attack}. Opennet
 133 peer-to-peer networking is dangerous thing to do.
 134
 135 The most popular cryptographic protocol in Internet is
 136 @url{https://en.wikipedia.org/wiki/Transport_Layer_Security, TLS} that
 137 is very hard to implement right and hard to configure for mutual
 138 participants authentication. Not all TLS configurations and related
 139 protocols provide @url{https://en.wikipedia.org/wiki/Forward_secrecy,
 140 forward secrecy} property -- all previously intercepted packets could be
 141 read if private keys are compromised.
 142
 143 Friend-to-friend networks, darknets can mitigate risks related to fake
 144 and forged nodes. However they are harder to support and require more
 145 time to be done right.
 146
 147 NNCP's TCP daemon uses @url{http://noiseprotocol.org/, Noise-IK}
 148 protocol to mutually authenticate peers and provide effective (both
 149 participants send payload in the very first packet) secure transport
 150 with forward secrecy property.
 151
 152 @verbatim
 153 % nncp-daemon -bind [::]:5400
 154 @end verbatim
 155 will start TCP daemon listening on all interfaces for incoming
 156 connections.
 157
 158 @verbatim
 159 % nncp-call bob
 160 @end verbatim
 161 will try to connect to @emph{bob}'s node known TCP addresses (taken from
 162 configuration file) and send all related outbound packets and retrieve
 163 those the Bob has. All interrupted transfers will be automatically
 164 resumed.
 165
 166 @node UsecaseAirgap
 167 @section Highly secure isolated air-gap computers
 168
 169 If you worry much about security, then air-gapped computer could be the
 170 only choice you can afford. Computer without any modems, wired and
 171 wireless networks. Obviously the only possibility to exchange mail and
 172 files is to use physically removable storage devices like CD-ROM, hard
 173 drive, tape and USB flash drives (worst choice, due to those devices
 174 complexity).
 175
 176 Presumably you have got another own hop before that computer: another
 177 intermediate node which performs basic verification of retrieved storage
 178 devices, possibly by rewriting the data from USB/hard drives to CD-RWs.
 179
 180 NNCP supports packets relying (transitioning) out-of-box.
 181
 182 @verbatim
 183 neigh:
 184   bob:
 185     [...]
 186     addrs:
 187       lan: [fe80::5400%igb0]:5400
 188   bob-airgap:
 189     [...]
 190     via: [bob]
 191 @end verbatim
 192
 193 That configuration file tells that we have got two known neighbours:
 194 @emph{bob} and @emph{bob-airgap}. @emph{bob} can be reached via online
 195 connection using @emph{lan} address. @emph{bob-airgap} can be reached by
 196 sending intermediate relay packet through the @emph{bob}.
 197
 198 Any command like @command{nncp-file myfile bob-airgap:} will
 199 automatically create an encapsulated packet: one for the destination
 200 endpoint, and other carrying it for intermediate relaying node.
 201
 202 Pay attention that relaying node knows nothing about the packet inside,
 203 but just its size and priority. Transition packets are encrypted too.
 204 @emph{bob} can not read @emph{bob-airgap}'s packets.
 205
 206 @node UsecaseCensor
 207 @section Network censorship bypassing
 208
 209 This is some kind of bad link too. Some governments tend to forbid
 210 @strong{any} kind of private communication between people, allowing only
 211 entertainment content delivering and popular social networks access
 212 (that are already bloated with advertisements, locally executed
 213 proprietary JavaScript code (for spying on user activities, collect data
 214 on them), shamelessly exploiting of very basic interhuman need of
 215 communication).
 216
 217 This is their natural wish. But nobody forces you to obey huge
 218 corporations like Apple, Google or Microsoft. It is your choice to
 219 create isolated friend-to-friend network with piles of harmless content
 220 and private messaging. Only predators silently watch for their victims
 221 in mammals world -- it harms your health being watched and feeling that
 222 you are the victim that has already done something wrong.
 223
 224 @node UsecaseSpy
 225 @section Reconnaissance, spying, intelligence, covert agents
 226
 227 Those guys know how Internet is a dangerous place incompatible with
 228 privacy. They require quick, fast dropping and picking of data. No
 229 possibility of many round-trips -- just drop the data, fire-and-forget.
 230 It could be either removable media again, or
 231 @url{https://en.wikipedia.org/wiki/USB_dead_drop, USB dead drops}, or
 232 @url{https://en.wikipedia.org/wiki/PirateBox, PirateBox}es, or
 233 @url{https://en.wikipedia.org/wiki/Short-range_agent_communications, SRAC}.
 234 Short lived short range networks like Bluetooth and WiFi can also
 235 be pretty fast, allowing to quickly fire chunks of queued packets.
 236
 237 Very important property is that compromising of those dead drops and
 238 storages must not be fatal and even dangerous. Packets sent through the
 239 network and exchanged via those devices are end-to-end @ref{Encrypted,
 240 encrypted} (but unfortunately lacking forward secrecy). No filenames,
 241 mail recipients are seen.
 242
 243 All communications are done with so-called @ref{Spool, spool} area:
 244 directory containing only those unprocessed encrypted packets. After
 245 packet transfer you still can not read any of them: you have to run
 246 another stage: tossing, that involves your private cryptographic keys.
 247 So even if your loose your computer, storage devices and so on -- it is
 248 not so bad, because you are not carrying private keys with it, you do
 249 not "toss" those packets immediately on the same device. Tossing
 250 (reading those encrypted packets and extracting transferred files and
 251 mail messages) could and should be done on a separate computer.