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