]> Cypherpunks.ru repositories - nncp.git/blobdiff - doc/usecases.texi
Replace YAML with Hjson
[nncp.git] / doc / usecases.texi
index f6a2be33d6e1f010f0265e2f2f4a95e1a47b949d..113089dfa23383feb0c4a79813bea7c1988d2cc5 100644 (file)
@@ -1,15 +1,21 @@
 @node Use cases
 @unnumbered Use cases
 
+See also this page @ref{Сценарии, on russian}.
+
 @menu
 * Occasional connection to mail server: UsecaseMail.
+* Lightweight fast POP3/IMAP4 replacement: UsecasePOP.
 * Unreliable/expensive communication link: UsecaseUnreliable.
 * Slow/expensive link for high-volume data, bad QoS: UsecaseQoS.
 * Extreme terrestrial environments, no link: UsecaseNoLink.
-* Private, isolated MitM-resistant networks: UsecaseF2F.
+* One-way broadcasting communications: UsecaseBroadcast.
+* Satellite links: UsecaseSatelliteLinks.
+* Private, isolated MitM/Sybil-resistant networks: UsecaseF2F.
 * Highly secure isolated air-gap computers: UsecaseAirgap.
-* Network censorship bypassing: UsecaseCensor.
+* Network censorship bypassing, health: UsecaseCensor.
 * Reconnaissance, spying, intelligence, covert agents: UsecaseSpy.
+* Cheap night transfers: UsecaseCaller.
 @end menu
 
 @node UsecaseMail
@@ -26,32 +32,34 @@ receive notification emails that his messages still are not delivered
 yet. Also you must have secure link (SSH, VPN, etc).
 
 Another possibility is to use POP3/IMAP4 servers, but this is too
-overcomplicated and bloated for the simple task. Not an option. KISS!
-
-@anchor{Postfix}
+overcomplicated and bloated for the simple task. Not an option.
+@url{https://en.wikipedia.org/wiki/KISS_principle, KISS}!
 
 Just tell both of your Postfixes (on the server and notebook) to drop
-email as a mail via NNCP to specified node. This is done similarly as
-with UUCP and as written in Postfix
-@url{http://www.postfix.org/UUCP_README.html, documentation}.
-
-Search for @code{uucp} related strings in @code{master.cf} and replace
-command to NNCP ones:
-
-@verbatim
-nncp unix - n n - - pipe flags=Fqhu user=nncp argv=nncp-mail -quiet $nexthop $recipient
-@end verbatim
-
-then add transport map, telling that mail for example.com domain can be
-reached through NNCP transport to node @code{bob}:
-
-@verbatim
-example.com nncp:bob
-@end verbatim
-
-Now, all mail will be stored in NNCP @ref{Spool, spool}, that after
-exchanging and tossing will call local @code{sendmail} command to
-deliver them just that was happened on the same machine.
+email as a mail via NNCP (@ref{nncp-exec}) to specified node. This is
+done similarly as with UUCP and as written in
+@url{http://www.postfix.org/UUCP_README.html, Postfix documentation}.
+
+Look @ref{Postfix, here} for further information. All mail will be
+stored in NNCP @ref{Spool, spool}, that after exchanging and tossing
+will call local @command{sendmail} command to deliver them just like
+that happened on the same machine.
+
+@node UsecasePOP
+@section Lightweight fast POP3/IMAP4 replacement
+
+@ref{nncp-daemon} can be connected with @ref{nncp-caller} for a long
+time -- it can create TCP connection that lasts for many hours. When
+SMTP server receives mail, it will call @ref{nncp-exec} creating an
+outbound encrypted packet. Daemon checks outbound directory each second
+and immediately sends notification about undelivered packets to remote
+side, that also downloads it at once.
+
+There are only dozens of bytes notifying about incoming packets, dozens
+of bytes telling to download those packets. Mail packets are compressed
+(POP3 and IMAP4 as a rule do not). You have lightweight, compressed,
+low-delay, reliable link for the mail with strong encryption and mutual
+sides authentication!
 
 @node UsecaseUnreliable
 @section Unreliable/expensive communication link
@@ -59,23 +67,24 @@ deliver them just that was happened on the same machine.
 Assume that you have got slow modem/radio/cellular link that frequently
 disconnects and causes TCP timeouts. Not all HTTP servers support file
 download continuation. SMTP does not support resuming at all and heavy
-messages is a problem to retrieve. Moreover, each disconnect leads to
-the same data retransmission again, that can be expensive to afford.
+messages is problematic to retrieve. Moreover, each disconnect leads to
+the same data retransmission again, that can not be afforded sometimes.
 
-Just send your mail and files through NNCP. You can use either offline
-delivery methods -- read about them in the next section, or you can use
-included NNCP TCP daemon.
+Just send your @ref{nncp-exec, mail} and @ref{nncp-file, files} through
+NNCP. You can use either offline delivery methods -- read about them in
+the next section, or you can use included NNCP @ref{nncp-daemon, TCP
+daemon}.
 
-The command below:
+The command:
 
 @verbatim
-% nncp-file file_i_want_to_send bob:
-% nncp-file another_file bob:movie.avi
+$ nncp-file file_i_want_to_send bob:
+$ nncp-file another_file bob:movie.avi
 @end verbatim
 
-will queue two files for sending to @code{bob} node. Fire and forget!
-Now this is daemon's job (or offline transfer) to send this file part by
-part to remote system when it is available.
+will queue two files for sending to @emph{bob} node. Fire and forget!
+Now this is daemon's job (or offline transfer) to send this files part
+by part to remote system when it is available.
 
 @node UsecaseQoS
 @section Slow/expensive link for high-volume data, bad QoS
@@ -92,12 +101,23 @@ niceness level, that will guarantee that it will be processed earlier or
 later than the other ones. Nearly all commands has corresponding option:
 
 @verbatim
-% nncp-file -nice 32 myfile node:dst
-% nncp-xfer -nice 192 /mnt/shared
-% nncp-call -nice 224 bob
+$ nncp-file -nice FLASH myfile node:dst
+$ nncp-xfer -nice PRIORITY /mnt/shared
+$ nncp-call -nice NORMAL bob
 [...]
 @end verbatim
 
+Huge files could be split on smaller @ref{Chunked, chunks}, giving
+possibility to transfer virtually any volumes using small capacity
+storages.
+
+You can also use CD-ROM and tape drives:
+
+@verbatim
+$ nncp-bundle -tx bob | cdrecord -tao -
+$ nncp-bundle -tx bob | dd of=/dev/sa0 bs=10240
+@end verbatim
+
 @node UsecaseNoLink
 @section Extreme terrestrial environments, no link
 
@@ -105,39 +125,83 @@ This is some kind of too slow link. Offline delivery methods is the only
 choice. Just send files as shown in previous section, but use removable
 media for transferring packets to other nodes.
 
-Assume that you send two files to @code{bob} node. Insert USB storage
-device, mount it and run:
+Assume that you send two files to @emph{bob} node. Insert USB storage
+device (SD is preferable!), mount it and run @ref{nncp-xfer}:
 
 @verbatim
-% nncp-xfer -node bob /media/usbstick
+$ nncp-xfer -node bob /media/usbstick
 @end verbatim
 
-to copy all outbound packets related to @code{bob}'s node. Use
-@code{-force} option to forcefully create related directory on USB
-storage if they are missing (for example when running for the first
-time).
+to copy all outbound packets related to @emph{bob}. Use @option{-mkdir}
+option to create related directory on USB/SD storage if they are missing
+(for example when running for the first time).
 
-If you use single storage device to transfer data both to @code{bob} and
-@code{alice}, then just omit @code{-node} option to copy all existing
-outgoing packets to that storage device.
+If you use single storage device to transfer data both to @emph{bob} and
+@emph{alice}, then just omit @option{-node} option to copy all available
+outgoing packets.
 
 @verbatim
-% nncp-xfer /media/usbstick
+$ nncp-xfer /media/usbstick
 @end verbatim
 
-Unmount it and transfer somehow to Bob and Alice. When they will insert
+Unmount it and transfer storage to Bob and Alice. When they will insert
 it in their computers, they will use exactly the same command:
 
 @verbatim
-% nncp-xfer /media/usbstick
+$ nncp-xfer /media/usbstick
 @end verbatim
 
 to find all packets related to their node and copy them locally for
-further processing. @code{nncp-xfer} is the only command used with
+further processing. @command{nncp-xfer} is the only command used with
 removable devices.
 
+@node UsecaseBroadcast
+@section One-way broadcasting communications
+
+Sometimes you have got high-bandwidth but unidirectional link, for
+example, satellite's broadcasting signal. You are not able to use online
+@ref{Sync, synchronization protocol} because it requires mutual interaction.
+
+You can use @ref{Bundles, bundles} and stream them above. They are just
+a sequence of @ref{Encrypted, encrypted packets} you can catch on.
+
+@verbatim
+$ nncp-bundle -tx alice bob eve ... | command to send broadcast
+$ command to receive broadcast | nncp-bundle -rx
+@end verbatim
+
+With built-in packet duplicates detection ability, you can retransmit
+your broadcasts from time to time, to increase chances the recipient
+will catch them by regular stream listening.
+
+@node UsecaseSatelliteLinks
+@section Satellite links
+
+Satellite links have @strong{very} high delays together with high
+bandwidths. You can send several megabits of data per second, but they
+will reach the remote side only after half a second!
+Most file sharing protocols like
+@url{https://en.wikipedia.org/wiki/Files_transferred_over_shell_protocol, FISH},
+@url{https://en.wikipedia.org/wiki/FTP, FTP},
+@url{https://en.wikipedia.org/wiki/Secure_copy, scp},
+@url{https://en.wikipedia.org/wiki/XMODEM, XMODEM}
+will perform very badly because of round-trips quantity. Each file
+transmission explicitly generates request and acknowledgement packets
+that are send over the link. Remote side won't do anything until it
+receives them. Moreover not all protocols allow duplex data
+transmission (when both sides are sending data simultaneously).
+
+NNCP's @ref{Sync, synchronization protocol} (SP) tries to mitigate all
+that issues by reducing number of round-trips, number of packets passing
+through. All file lists, file download requests are grouped together
+(pipelined) in one huge packet. Only transmission halt and successful
+file download acknowledgements are sent explicitly. SP could be asked
+only either to upload or download packets for our node. SP could ignore
+files with low priority. Full files listing is passing even during the
+handshake procedure.
+
 @node UsecaseF2F
-@section Private, isolated MitM-resistant networks
+@section Private, isolated MitM/Sybil-resistant networks
 
 All Internet connections can be eavesdropped and forged. You
 @strong{have to} to use encryption and authentication for securing them.
@@ -149,7 +213,7 @@ peer-to-peer networking is dangerous thing to do.
 
 The most popular cryptographic protocol in Internet is
 @url{https://en.wikipedia.org/wiki/Transport_Layer_Security, TLS} that
-is very hard to implement right and hard to configure for mutual
+is very hard to implement correctly and hard to configure for mutual
 participants authentication. Not all TLS configurations and related
 protocols provide @url{https://en.wikipedia.org/wiki/Forward_secrecy,
 forward secrecy} property -- all previously intercepted packets could be
@@ -159,21 +223,22 @@ Friend-to-friend networks, darknets can mitigate risks related to fake
 and forged nodes. However they are harder to support and require more
 time to be done right.
 
-NNCP's TCP daemon uses @url{http://noiseprotocol.org/, Noise-IK}
-protocol to mutually authenticate peers and provide effective (both
-participants send payload in the very first packet) secure transport
-with forward secrecy property.
+NNCP's @ref{nncp-daemon, TCP daemon} uses
+@url{http://noiseprotocol.org/, Noise-IK} protocol to mutually
+authenticate peers and provide effective (both participants send payload
+in the very first packet) secure transport with forward secrecy
+property.
 
 @verbatim
-% nncp-daemon -bind [::]:5400
+$ nncp-daemon -bind [::]:5400
 @end verbatim
 will start TCP daemon listening on all interfaces for incoming
 connections.
 
 @verbatim
-% nncp-call bob
+$ nncp-call bob
 @end verbatim
-will try to connect to @code{bob}'s node known TCP addresses (taken from
+will try to connect to @emph{bob}'s node known TCP addresses (taken from
 configuration file) and send all related outbound packets and retrieve
 those the Bob has. All interrupted transfers will be automatically
 resumed.
@@ -185,8 +250,8 @@ If you worry much about security, then air-gapped computer could be the
 only choice you can afford. Computer without any modems, wired and
 wireless networks. Obviously the only possibility to exchange mail and
 files is to use physically removable storage devices like CD-ROM, hard
-drive, tape and USB flash drives (worst choice, due to those devices
-complexity).
+drive, SD, tape and USB flash drives (@strong{worst} choice, due to
+those devices complexity).
 
 Presumably you have got another own hop before that computer: another
 intermediate node which performs basic verification of retrieved storage
@@ -195,46 +260,52 @@ devices, possibly by rewriting the data from USB/hard drives to CD-RWs.
 NNCP supports packets relying (transitioning) out-of-box.
 
 @verbatim
-neigh:
-  bob:
+neigh: {
+  bob: {
     [...]
-    addrs:
-      lan: [fe80::5400%igb0]:5400
+    addrs: {
+      lan: "[fe80::5400%igb0]:5400"
+    }
+  }
   bob-airgap:
     [...]
-    via: [bob]
+    via: ["bob"]
+  }
+}
 @end verbatim
 
-That configuration file tells that we have got two known neighbours:
-@code{bob} and @code{bob-airgap}. @code{bob} can be reached via online
-connection using @code{lan} address. @code{bob-airgap} can be reached by
-sending intermediate relay packet through the @code{bob}.
+That @ref{Configuration, configuration file} tells that we have got two
+known neighbours: @emph{bob} and @emph{bob-airgap}. @emph{bob} can be
+reached via online connection using @emph{lan} address.
+@emph{bob-airgap} can be reached by sending intermediate relay packet
+through the @emph{bob}.
 
-Any command like @code{nncp-file myfile bob-airgap:} will automatically
-create an encapsulated packet: one for the destination endpoint, and
-other carrying it for intermediate relaying node.
+Any command like @command{nncp-file myfile bob-airgap:} will
+automatically create an encapsulated packet: one for the destination
+endpoint, and other carrying it for intermediate relaying node.
 
 Pay attention that relaying node knows nothing about the packet inside,
-but just its size and priority. Transition packets are encrypted too.
-@code{bob} can not read @code{bob-airgap}'s packets.
+but just its size and priority. Transition packets are encrypted too:
+using well-known @url{https://en.wikipedia.org/wiki/Onion_routing, onion
+routing} technology. @emph{bob} can not read @emph{bob-airgap}'s packets.
 
 @node UsecaseCensor
-@section Network censorship bypassing
+@section Network censorship bypassing, health
 
 This is some kind of bad link too. Some governments tend to forbid
 @strong{any} kind of private communication between people, allowing only
 entertainment content delivering and popular social networks access
 (that are already bloated with advertisements, locally executed
-proprietary JavaScript code (for spying on user activities, collect data
-on them), shamelessly exploiting of very basic interhuman need of
-communication).
+@url{https://www.gnu.org/philosophy/free-sw.html, proprietary}
+JavaScript code (for spying on user activities, collect data on them),
+shamelessly exploiting the very basic human need of communication).
 
 This is their natural wish. But nobody forces you to obey huge
 corporations like Apple, Google or Microsoft. It is your choice to
-create isolated friend-to-friend network with piles of harmless content
-and private messaging. Only predators silently watch for their victims
-in mammals world -- it harms your health being watched and feeling that
-you are the victim that has already done something wrong.
+create an isolated friend-to-friend network with piles of harmless
+content and private messaging. Only predators silently watch for their
+victims in mammals world -- it harms your health being watched and
+feeling that you are the victim that has already done something wrong.
 
 @node UsecaseSpy
 @section Reconnaissance, spying, intelligence, covert agents
@@ -242,25 +313,78 @@ you are the victim that has already done something wrong.
 Those guys know how Internet is a dangerous place incompatible with
 privacy. They require quick, fast dropping and picking of data. No
 possibility of many round-trips -- just drop the data, fire-and-forget.
-It could be either removable media againor
-@url{https://en.wikipedia.org/wiki/USB_dead_drop, USB dead drops}, or
-@url{https://en.wikipedia.org/wiki/PirateBox, PirateBox}es, or
+It could be either removable media again and/or
+@url{https://en.wikipedia.org/wiki/USB_dead_drop, USB dead drops},
+@url{https://en.wikipedia.org/wiki/PirateBox, PirateBox}es,
 @url{https://en.wikipedia.org/wiki/Short-range_agent_communications, SRAC}.
 Short lived short range networks like Bluetooth and WiFi can also
 be pretty fast, allowing to quickly fire chunks of queued packets.
 
 Very important property is that compromising of those dead drops and
-storages must not be fatal and even dangerous. Packets sent through the
-network and exchanged via those devices are end-to-end @ref{Encrypted,
-encrypted} (but unfortunately lacking forward secrecy). No filenames,
-mail recipients are seen.
+storages must be neither fatal nor even dangerous. Packets sent through
+the network and exchanged via those devices are end-to-end
+@ref{Encrypted, encrypted} (but unfortunately lacking forward secrecy).
+No filenames, mail recipients are seen.
 
-All communications are done with so-called @ref{Spool, spool} area:
+All node communications are done with so-called @ref{Spool, spool} area:
 directory containing only those unprocessed encrypted packets. After
 packet transfer you still can not read any of them: you have to run
-another stage: tossing, that involves your private cryptographic keys.
-So even if your loose your computer, storage devices and so on -- it is
-not so bad, because you are not carrying private keys with it, you do
-not "toss" those packets immediately on the same device. Tossing
-(reading those encrypted packets and extracting transferred files and
-mail messages) could and should be done on a separate computer.
+another stage: @ref{nncp-toss, tossing}, that involves your private
+cryptographic keys. So even if your loose your computer, storage devices
+and so on -- it is not so bad, because you are not carrying private keys
+with it (don't you?), you do not "toss" those packets immediately on the
+same device. Tossing (reading those encrypted packets and extracting
+transferred files and mail messages) could and should be done on a
+separate computer (@ref{nncp-cfgmin} command could help creating
+configuration file without private keys for that purpose).
+
+If you really want to carry your private keys, then @ref{nncp-cfgenc}
+command will be able to encrypt your configuration file. Passphrase you
+enter is strengthened with both CPU and memory hard function.
+
+@node UsecaseCaller
+@section Cheap night transfers
+
+Your Internet/telephone traffic price can vary, depending on daytime.
+Night calls/connections could be twice as cheaper. You wish to send your
+files at that time, but keep high priority email infrequently passing
+through in anytime. Also you wish to pass any kind of traffic when the
+node is available through the LAN.
+
+You can easily set your preferences in @ref{Call, call
+configurations} for @ref{nncp-caller} command used in online
+communications.
+
+@verbatim
+neigh: {
+  [...]
+  some-node: {
+    [...]
+    addrs: {
+      lan: "[fe80::be5f:f4ff:fedd:2752%igb0]:5400"
+      wan: "some-node.com:5400"
+    }
+    calls: [
+      {
+        cron: "*/1 * * * *"
+        addr: lan
+        nice: MAX
+        onlinedeadline: 3600
+      },
+      {
+        cron: "*/10 * * * *"
+        addr: wan
+        nice: PRIORITY
+        xx: rx
+      },
+      {
+        cron: "*/1 0-7 * * *"
+        addr: wan
+        nice: BULK
+        onlinedeadline: 3600
+        maxonlinetime: 3600
+      },
+    ]
+  }
+}
+@end verbatim