On Mon, Jan 04 2021, Grant Taylor wrote:

> On 1/3/21 10:51 PM, John Goerzen wrote:
> All of the UUCP that I've done has been initiated via a cron job (thus the
> cron
> daemon) and / or login shells and / or specifically executed commands.
> Meaning
> that in an idle state, there was no daemon (running process) specifically for
> UUCP.

ACK. The same is possible with the "nncp-daemon".

> Aside: I'd like to learn more about what you're doing. Please reply with
> where
> I can learn more. Do you have a blog, Twitter, etc? (Perhaps direct email is
> better.)

I seem to have anticipated this :-) The blog is at
https://changelog.complete.org/ and has my radio experiments. I linked you one
post but if you search for LoRA and Xbee there, you'll turn up others. I also
have been meaning to set up a Meshtastic device soon (Meshtastic is a
low-powered long-distance IM mesh that uses LoRA under the hood; ideal for
off-grid communication or communication in censored areas). I'm also
@jgoerzen@floss.social on Mastodon (I am trying to ease out of the centralized
social media companies and into the decentralized ones). Also you're welcome
to email.

> This is effectively the difference of where you put the bulk of the logic.

Yes.

> You can either do more of the work at the email layer, with direct
> node-to-node
> email routing. Or you can do more of the work at the transport layer, with
> node-to-node(-to-node) transport routing.

Exactly.

>> NNCP's config file actually lets you specify a default route to a known node,
>> so there would be no need for explicit routing at the MTA level if you just
>> do
>> it all at the NNCP level.
>
> Hum. I'd have to spend some time thinking about the implications of such a
> default configuration on an MTA. Especially in idea of not being an open
> relay.
> -- I guess that the MTA on the NNCP default could list source nodes that it
> will allow relaying for.

NNCP, as with UUCP, will let you specify what (if any) commands a given remote
is allowed to execute. If you don't want to accept mail from a given node with
either system, the only really safe thing is to not give it access to rmail in
the first place.

> As I think about it, by the time that rmail is invoked, it's too late to
> actually reject a message and force the sending MTA to deal with it. Instead,
> the receiving MTA will likely /need/ to /receive/ and then / reject/ (bounce)
> the message. Lest messages make it to the receiving MTA to only be dropped.
> Such drop behavior is antithetical to proper operation of email.

Yes, though in reality I could see it happening with both UUCP and NNCP (you get
three hops down the line and then your destination has denied permission to run
rmail, for instance). ISTR uuxqt can generate an error report at this point. I
would need to look into NNCP's behavior here; I believe it holds the packet in
the incoming queue thinking that the failure may eventually get resolved.
Probably not ideal in this situation.

>> With NNCP's default "via" settings available in the config, the routing can
>> be
>> invisible to both the MTA and the user (but of course, the keys are needed).
>
> Now I have to stop and ask: Does the user (human or MTA or other) have any
> knowledge of the necessary public keys to make up the onion? Or is that all
> handled by the NNCP transport layer? -- Much like the user does not need to
> know the particulars about IPsec transport between two systems as those
> details
> are handled at a lower layer and hidden from the user.

It's all handled at the transport layer. All the NNCP commands work with the
nodename aliases, both for input from users and for display purposes -- though I
believe you can also hand it raw public keys if you like.

That said, if you have read access to the spool directory, everything there is
by public key so you can certainly access things at that level if you feel the
need. But nncp-stat and friends will show the human-friendly aliases instead.

>> A node doesn't have to be known by the same name on every host, either, since
>> the spool directories and all internal structures are based off the node's
>> public key rather than its name.
>
> IMHO aliases / a.k.a.s / nicknames can complicate things and possibly cause
> routing loops.

I don't *think* so, since it is source-routed just like UUCP, and none of the
lower-level protocol uses the aliases at all.

> Though, they may be able to be used to avoid a situation that I have yet to
> find
> a solution for with UUCP. Node 2 going offline and never returning in a
> node1!node2!node3!user situation. How does node1 manage to re-route traffic
> to
> node3 which is online? This lack of redundancy / re-routability has long
> bothered me.

So I have actually brought a situation like this up on the NNCP list. Actually
NNCP is going to be worse than UUCP at this, because the packets in that
situation will have been encrypted to node2 along their way to node3, and unless
you have node2's private keys, will become useless if node2 goes away.

With UUCP, you could presumably do some ugly munging and get what you want in
the end.

> I guess do to the nature of onion routing, the down stream system doesn't have
> any knowledge of the upstream source, save for the previous hop that sent the
> current packet / message / datagram / nomenclature?

Not exactly; the downstream system actually has conclusive knowledge of the
source but not the hops it took to get there. More on that below.

>> Do I blindly receive? Pretty much yes :-)
>
> See above. I now realize that it's blindly receive and then bounce -or-
> loose mail.

I meant that in the context of ZFS receive actually. But if I'm following the
conversation here, you're not wrong.

>> un-receivable and exit with an error. nncp-toss (uuxqt) handles the error
>> exit
>> code as "try this again on the next run" so it will eventually converge on
>> the
>> appropriate solution even with a large backlog of packets to process.
>
> I was thinking where an intermediate snapshot was lost. You know, the
> snapshot
> that the subsequent snapshot was based on.

If the origin snapshot is just lost to thin air, then it will not be possible to
zfs receive an incremental based on it, ever. However, if the source snapshot
just hasn't been received yet, then the zfs receive based on the source will
fail initially, but when NNCP retries it later after the source has been
received, it will succeed.

>> I guess I could say that the NNCP protocol is designed to be self-securing
>> and
>> reasonably delay-tolerant, even on half-duplex links. It also does integrity
>> checks of the whole of received packets. Of course you can run uucico over
>> SSH, but SSH is rather difficult to get running over some high-latency links;
>> it strongly wants a full-duplex link and has handshake timeouts that don't
>> work well with some of them.
>
> I wonder how well TCP will do over the links that SSH is less than happy with.

Better. I actually have experience with this.

So almost all radios are half-duplex at heart. Many modern digital ones
simulate full duplex operation by very rapid switching, but the lower-speed ones
won't.

So I had to add a whole algorithm to lorapipe to deal with ssh, because part of
ssh's handshake has both the client and the server send data simultaneously. A
sensible performance optimization in general but terrible for an RF link with
virtually nonexistent collision detection. By the time packets would get
retransmitted, ssh would have timed out and aborted. I had to add a very simple
feature to lorapipe: a "more data is coming after this packet" bit that
facilitated turn-taking, allowing ssh handshake to proceed.

That's not to say that TCP with its ACKs was great over LoRA with my initial
algorithm, just that SSH was particularly pathological.

But of course, with either UUCP or NNCP, one doesn't actually have to run TCP
(in NNCP's case, you do need a reliable link, but it need not be a TCP one).

> Is NNCP truly half duplex capable when it uses nncp-{bundle,batch}? Or is
> that
> more a gateway of sorts to an intermediate format?

Yes. So nncp-bundle -tx is basically a program to create a tarball out of files
in the outgoing spool directory. nncp-bundle -rx does the reverse, processing
packets in the tarball destined for the local node (and ignoring everything
else). That's why you can pipe nncp-bundle to uux. The NNCP wire protocol
itself is, I think, designed to be half-duplex but obviously there is going to
be some back-and-forth on any wire protocol.

nncp-xfer moves packets to a directory structure at an arbitrary point (usually
a USB drive or something).

>> I feel like neighbor-level transport security in UUCP is solved reasonably
>> easily (uucico over ssh, etc.) But in the example above, node5 can't really
>> tell that the packet originated on node1 and arrived at node5 unmodified with
>> any degree of certainty.
>
> Maybe it's my lack of understanding of onion routing, but I don't see how this
> is any different with NNCP vs UUCP.
>
> Note: I'm assuming that:
>
> node5 only sees correct packets as being from node4.
> node4 only sees correct packets as being from node3 and to node5.
> node3 only sees correct packets as being from node2 and to node4.
> node2 only sees correct packets as being from node1 and to node3.
> node1 generates the node2(node3(node4(node5))) onion and sends it node2.
>
> IMHO node5 has no idea where the packet / onion originated from, just a path
> back to the unknown source.

So what happens here is that node1 first generates an encrypted packet to node5,
using node5's public key, and that packet is signed by node1. Next, it takes
that whole thing, encryption and signature and all, and uses it as input for an
encrypted packet to node4 -- that packet itself also signed by node1. It
repeats this process until it generates the packet to node2.

Think of it like this:

node1$ gpg --sign -e -r node5 < datafile > node5.gpg
node1$ gpg --sign -e -r node4 < node5.gpg > node4.gpg
node1$ gpg --sign -e -r node3 < node4.gpg > node3.gpg
node1$ gpg --sign -e -r node2 < node3.gpg > outbound-to-node2.gpg
node1$ rm node[345.jpg]

Node2 receives the packet - encrypted only to it, and signed by node1 - and
decrypts the payload. The payload is a command (send this on to node2) and an
encrypted payload for THAT command -
encrypted to node2 and signed by node1. This process also continues until you
get to node5.

So, at node4, node4 receives its packet from node3 -- signed by node1, encrypted
to node4. Node4 decrypts it and finds a payload for node5 -- again, signed by
node1, encrypted to node5. It places this in the queue for node5. (Just like
with node2)

Node5 receives the packet. It verifies the signature from node1, and it is the
only node that can decrypt it. nncp-toss finds the packet in the rx queue from
node4, but it doesn't really pass this information on anywhere; it knows from
the signature that the origin was node1 (doesn't much care how it arrived) and
that single verified signature is what is used for all processing (looking up
whether node1 is authorized to run a command, exposed as an environment variable
to nncp-exec runners, used to determine the incoming directory for nncp-file,
etc).

Node5 could sort of know that the packet arrived from node4, but there is no
cryptographic guarantee of that (the ONLY signatures in this whole chain come
from node1) so that information is basically discarded.

This is different from the UUCP model, in which node5 only really knows about
its neighbor node4 and may have no idea whatever about node1's existence.
Permissions in UUCP are based on what the neighbor can do, not what the source
can do, if I remember correctly.

The other thing that follows from this is that if node3 were compromised, the
worst it can do is fail to relay packets. It cannot modify packets (signature
validation from node1 would fail), it cannot spoof node1 (lacking its private
key), it can't inject fake packets claiming to have followed the
node1!node2!node3 path (again, lacking node1's private key), it can't even see
what the ultimate destination is (it just knows the next hop is node4 but since
it doesn't have node4's private key, it doesn't even know if node4 is the
ultimate hop or not).

I really like this.

>> NNCP exposes the origin node's public key via an environment variable so it's
>> all right there.
>
> Does the original node add additional identifying information to the packet?
>
> Or do I have an incorrect understanding of onion routing?

I think you did, but hopefully it's cleared up above :-)

Yes, all packets in the chain are signed by the origin and only the origin.

- John