On 1/4/21 4:00 PM, John Goerzen wrote:
> ACK. The same is possible with the "nncp-daemon".
>
> 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.

Thank you for the link. I will be consuming more of your articles.

> 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'll keep an eye out for a write up.

> 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.

Ya ... Mastodon ... I should sing into the account that I have.

> 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.

Agreed.

I would also hope that there is a way to cause NNCP (UUCP) to simply
drop anything that wasn't from an explicitly allowed host, independent
of how it got into the system.

Preferably using anything not explicitly allowed as an Indicator of
Compromise.

> 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).

Agreed.

Though, hopefully such a path would be tested before put into
production. Thus meaning that this type of failure is less likely to
occur. I guess it depends if the path is user provided or admin provided.

> 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.

I presume that you're referring to NNCP on the receiving end system
where rmail was prohibited.

> 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.

ACK

> 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.

*nod*

This brings to mind another short coming I've seen with UUCP.
Inter-user access on the same system.

Does NNCP even extend the encryption to the user level on the system?
E.g. destination!user1 vs destination!user2. As in if files were sent
something like uuto /path/to/local-file destination!user3.

The UUCP installations that I've been exposed to were largely if you can
access the UUCP spool, you could access just about anything in it.
Perhaps this was a misconfiguration on those systems.

> 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.

That makes sense.

> So I have actually brought a situation like this up on the NNCP list.

/me thinks that he should subscribe.

> 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.

True....

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

Yep.

> 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.

Hum.

I feel like I should go back and re-read about ToR.

I wonder if I'm incorrect about it too or of NNCP's behavior diverges at
this point.

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

*nod*

> 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 was thinking more along the lines of each snapshot being based against
the previous snapshot and loosing one snapshot along the line. I'd
think that all subsequent snapshots would be unusable.

> Better. I actually have experience with this.

Good.

> 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.

Interesting.

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

That's not the first time that I've heard SSH referred to as pathological.

It also brings to mind some of the optimization methods that have been
tried over satellite networks. E.g. ""terminate the TCP at a proxy that
spoofs remote IPs, send the data as a non-TCP stream, and then originate
a new TCP connection from the remote proxy spoofing local IPs to the
remote end point.

> 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).

ACK

> 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.

Thank you for clarifying.

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

*nod*

> 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).

Thank you for explaining how NNCP operates. I now need to go back and
refresh myself on how ToR operates.

> 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.

So NNCP really is about the data at rest as opposed to the data in
flight. Thus the flight path really doesn't make any difference to NNCP.

A non-trivial portion of UUCP is about the flight path, accounts that
are used, and other associated metadata. In addition to the data at
rest (what queue does it go into).

> 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.

I largely agree.

Though I think there is some security around what remote node(s) the
local node will forward from and / or to. I can't tell you at the
moment if that's the remote source node or the direct neighbor node.

> 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),

Eh ... I suspect that an upstream node could perform a DoS and send
bogus packets that ultimately consume resources.

> 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 wonder if it would be possible to perform some metadata (packet size)
analysis and speculate about anything.

> I really like this.

*nod*

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

More so.

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

*nod*nod*

--
Grant. . . .
unix || die