On 1/3/21 10:51 PM, John Goerzen wrote:
> Hey, the posts are outnumbering the spam (at least on Google Groups
> [yeah, I know, don't shoot me]) so I took that as a positive sign
> for Usenet :-)

;-)

> Thank you!

You're welcome.

> So a quick disclaimer that applies to all of my answers here: I'm
> not the author of NNCP, so I can speak to my understanding of it,
> but not necessarily with authority.

ACK

> There is a mailing list at
> https://lists.cypherpunks.ru/pipermail/nncp-devel/ and the author is
> active there.

I'll have to check that out. Thank you for the link.

> With that out of the way, yes, that is indeed my understanding.
>
>
> The NNCP usage of the word "daemon" is a little loose.

Okay.... I'm using "daemon" to mean a process that is running all the
time, independent of what it does.

> So in UUCP, there is uucico, which is both the outbound caller and
> the inbound listener/daemon.

I've not (yet) messed with UUCP which allows incoming TCP connections on
ports 540 / 4031.

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.

> In NNCP, these roles are split into three separate programs:
>
> nncp-daemon - the listener (roughly uucico -l)

I presume this is the daemon (which runs all the time) that listens for
incoming TCP connections.

> nncp-call - an on-demand caller (uucico -S)
>
> nncp-caller - the caller with scheduling rules (uucico -s if memory
> serves?)
>
> The "daemon" can be run as a daemon (I run it under systemd [again,
> don't shoot me!] quite easily). But it also has an -inetd option
> that, of course, can run under inetd... but is really just a "speak
> the protocol on stdin/stdout" so it could just as easily be run under
> ssh as with uucico.

ACK

The daemon / (x)inetd aspect is just used to convert incoming TCP
connections to STDIN / STDOUT to / from the NNCP processes on the local
system.

> I think that would be an accurate characterization, yes. I mean,
> both programs fundamentally store packets in regular files, so as
> long as you are careful not to trip over race conditions in either
> direction, it should be reasonably simple.

ACK

> (I wonder if sequence numbers make it at all more complicated on the
> UUCP side?

I don't know. I somewhat doubt it. I think the sequence numbers are
more for the call. -- Seeing as how we're talking about moving files
between queues, which is independent of and after the call, I doubt that
they would be much of an issue. But it wouldn't be the first time that
I'm wrong.

> This is one article about doing something similar with UUCP:
> https://www.dumain.com/posts/Forward_to_the_1970s_with_UUCP.../
> and it wasn't super simple. TBH I've never tried it.

$ReadingList++

> The NNCP tools for this also have built-in support for grades/nice,
> preventing duplicate packets (I can't remember if UUCP does this
> anymore; I seem to recall not?).

My understanding is that the duplication ~> error detection and
recovery, was done as part of the line protocol. As such, I think it's
somewhat outside of UUCP's queued store-and-forward mechanism.

> Generally yes, but I play with long-distance low-power radios (think
> 20 miles with 500mW or less) so it isn't ALWAYS that way even now!

I'm not completely surprised by that.

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

> True, though TBH I don't think anybody has tried NNCP over raw serial
> lines yet. Must put that on my list...

:-)

> So I made an inartful simplification there.
>
> One could, in both UUCP and NNCP worlds, handle multi-hop mail routing
> by either:
>
> 1) Having the MTA do it (presumably via a smarthost for leaf nodes)
> - in a manner similar to how things happen over the Internet now
>
> 2) Doing this at the UUCP/NNCP protocol level
>
> So basically if you are going to have the MTA on node1 execute
> something like "nncp-exec -via node2,node3,node4 node5 rmail janedoe"
> (aka uux node2!node3!node4!node5!rmail janedoe) then the sending node
> needs to have the keys for all four of those nodes since it needs to
> prepare all of the onion encryption layers.
>
> If, on the other hand, node1 knows that "meh, I just send all my mail
> to node2 and it figures it out", then it would be doing "nncp-exec
> node2 rmail janedoe@node5" or something similar; node2 presumably
> would know to route that via node3 and so forth.

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

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.

Method A [email] [email] [email] [email] [email]
[node1]---[node2]---[node3]---[node4]---[node5]

vs

Method B [email] [email]
[node1]---[node2]---[node3]---[node4]---[node5]

I'm eliding the smart host aspect because that would likely be the same
conceptual configuration of originating systems and first hop in either
system.

> I have never set up an MTA with full bang-path routing (my UUCP
> uses were all late enough to be essentially Internet leaf sites with
> RFC822-style addressing routed over UUCP) so TBH I don't quite know
> how the MTAs handled that, but my understanding is that is was pretty
> much on the user to know the full bang path from the local system to
> the recipient and it just handed this over to uux.

My experience is quite similar.

The experience I have with multi-node (bang) paths has more to do with
file copy (uucp / uuto) and command execution (uux).

From a purely efficiency point of view, it seems like it would be
better to have fewer MTA interactions with longer bang paths between them.

But none of that speaks to what a downstream MTA does with a message
that it won't accept.

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

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.

> Doing it at the NNCP level would have a security benefit as well,
> since it would be neither necessary nor possible to decrypt it at
> MTAs along the way.

Agreed.

> Exim has an example config where you could send things to, eg,
> janedoe@node5.UUCP and it could have a routing lookup table --
> or just pass this to the lower level.

I feel like that the MTA should have access to the necessary information
to get to the next MTA in line.

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

> If the MTA were to call nncp-exec to a node that nncp-exec doesn't
> know about, it would get an immediate command failure from the pipe
> to nncp-exec and that would presumably turn into an immediate DSN.

One would hope.

> The difference is that with uux, the local system would only need
> to know about node2 and if, say, node3 doesn't know about node4,
> then that's an issue that surfaces later. (Technically this could
> still happen in NNCP; you could know about all those nodes but then
> node3 might not know about node4, but I'd think it would be more rare)

I think that this is highly dependent on if you're using Method A or
Method B above. The failures of each is different.

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.

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

On Monday, January 4, 2021 at 8:05:56 PM UTC-6, Grant Taylor wrote:

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

Yes, NNCP would fail to look up the node in its configuration, and therefore would drop it. (I haven't explicitly tested this but this seems to be an explicit design goal)

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

Correct.

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

The story is only marginally better with NNCP. You can setuid/setgid some stuff as is often done with UUCP, or mess with sticky bits on spool directories and such. Outbound packets will be safe from inspection, since they are encrypted using a different node's public key. Inbound packets could be decoded by any user that can read the NNCP config file (though you could probably restrict that, resulting in some protection). There is no default support for a multiuser setup, and I haven't messed with it either.

My own setup has been to run NNCP as the nncp user, and create sudo rules to allow passwordless sudo from my user account to the nncp-* commands as nncp. That segments off my private files from any kind of NNCP bug for the most part. I add myself to the nncp group so I can pull things out of the incoming directory.

Another approach would be to create a separate installation for each user. This would also be possible in UUCP, but is simpler in NNCP. For instance, I could have a master NNCP on my system, that all inboud and outbound traffic is routed via. Then I would set up another NNCP installation as jgoerzen, with all the files in my own home directory. Then they could talk to each other; for instance, the master would "call" the jgoerzen one like this:

"|sudo -H -u jgoerzen nncp-daemon -inetd"

and vica-versa for calls in the other direction.

This could be extended arbitrarily to any number of users.

With NNCP only needing a single config file, it is somewhat faster to set up than UUCP, but conceptually I don't think there is anything ruling this out from a UUCP perspective either.

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

Don't discount the possibility that I am incorrect also :-)

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

From a configuration and authorization perspective, yes. Both data at rest and data in flight are secured.

But I think this is a key point and puts a finer point on what was a bit hand-wavy on my part in my initial post. There is no username/password authentication in NNCP because there is no point; a node will prove who it is by its keypairs on the wire protocol (and by what it can decrypt on the offline formats) and the path a packet takes to its destination doesn't matter to the destination.
> 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).

Right. NNCP does maintain an outbound queue in subdirectories per node (named after the node's public key). But there is no way for the receiver to see what the via-path was for a packet to reach it; it is expected that for an answer to be returned, the via-path should be defined in the config file on the receiver. Basically the routing is supposed to be transparent to the user, though it can be explicitly given at any time with a -via parameter.

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

Control over forwarding is a bit of a missing link in NNCP right now, and probably wouldn't hurt to have. Though I can see why Sergey left it out, if he envisioned an NNCP network to be one of curated peers and the forwarded packets are opaque to the nodes anyway, and the path is irrelevant to permissions.

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

True. A compromised node3 could send packets that claim to be from node3, as of course they would be, and could execute whatever attacks node3 would be granted permissions to do. I didn't mean to imply that compromise of node3 would be a "meh, I don't care" event, but rather that it couldn't be used to spoof another node.

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

Possibly, and that's why there is a minsize configuration option and parameter: http://www.nncpgo.org/Commands.html#OptMinSize

- John

On 1/4/21 8:33 PM, John Goerzen wrote:
> Yes, NNCP would fail to look up the node in its configuration, and
> therefore would drop it. (I haven't explicitly tested this but this
> seems to be an explicit design goal)

ACK

> The story is only marginally better with NNCP. You can setuid/setgid
> some stuff as is often done with UUCP, or mess with sticky bits
> on spool directories and such. Outbound packets will be safe
> from inspection, since they are encrypted using a different node's
> public key. Inbound packets could be decoded by any user that can
> read the NNCP config file (though you could probably restrict that,
> resulting in some protection). There is no default support for a
> multiuser setup, and I haven't messed with it either.

I wonder if it would be possible to borrow / lean on history of MTAs and
how they get messages into files that the user and root can access.
Granted, that relies on an MTA and / or LDA to do that final delivery
that crosses the UID / GID barrier.

> My own setup has been to run NNCP as the nncp user, and create sudo
> rules to allow passwordless sudo from my user account to the nncp-*
> commands as nncp.

(thumbs up) on the use of sudo to non-root user.

Though I prefer to use authentication (other than password) to sudo via
SSH keys.

> That segments off my private files from any kind of NNCP bug for the
> most part. I add myself to the nncp group so I can pull things out
> of the incoming directory.

I largely agree. Though the thing that fails this type of configuration
in my experience is that the nncp user probably can't access files from
your home directory to send. So you need to arrange access be it
permissions or file location.

> Another approach would be to create a separate installation for each
> user. This would also be possible in UUCP, but is simpler in NNCP.

Ya.... That's the direction that I've ended up thinking about before.
Though I prefer the idea of leaning on ownership like MTAs / LDAs do.

> For instance, I could have a master NNCP on my system, that all inboud
> and outbound traffic is routed via. Then I would set up another NNCP
> installation as jgoerzen, with all the files in my own home directory.
> Then they could talk to each other; for instance, the master would
> "call" the jgoerzen one like this:
>
> "|sudo -H -u jgoerzen nncp-daemon -inetd"
>
> and vica-versa for calls in the other direction.
>
> This could be extended arbitrarily to any number of users.

*nod*

> With NNCP only needing a single config file, it is somewhat faster
> to set up than UUCP, but conceptually I don't think there is anything
> ruling this out from a UUCP perspective either.
>
> Don't discount the possibility that I am incorrect also :-)

Sure.

> From a configuration and authorization perspective, yes. Both data
> at rest and data in flight are secured.
>
> But I think this is a key point and puts a finer point on what
> was a bit hand-wavy on my part in my initial post. There is no
> username/password authentication in NNCP because there is no point;
> a node will prove who it is by its keypairs on the wire protocol
> (and by what it can decrypt on the offline formats) and the path a
> packet takes to its destination doesn't matter to the destination.
>
> Right. NNCP does maintain an outbound queue in subdirectories per
> node (named after the node's public key). But there is no way for
> the receiver to see what the via-path was for a packet to reach it;
> it is expected that for an answer to be returned, the via-path should
> be defined in the config file on the receiver.

Please elaborate. How would node3 use a via-path and be able to send an
error to node1?

Something like how ICMP errors are dealt with in regard to various
tunneling techniques come to mind. In short, push the error to the end
(presuming it can get there) and have the end generate the error back
tot he sender. -- There is the obvious problem of what to do if the
problem can't be pushed to the end because the end is unreachable. I
still wonder if there might not be some prior art here.

> Basically the routing is supposed to be transparent to the user,
> though it can be explicitly given at any time with a -via parameter.

ACK

> Control over forwarding is a bit of a missing link in NNCP right now,
> and probably wouldn't hurt to have. Though I can see why Sergey left
> it out, if he envisioned an NNCP network to be one of curated peers
> and the forwarded packets are opaque to the nodes anyway, and the
> path is irrelevant to permissions.

I get the impression that the intended use case for NNCP is private and
/ or between a small group of trusted friends. Likely in a mostly full
mesh between each other, thus no real need for forwarding, save for
gatewaying like below.

Though I have had a ""public UUCP network between my public VPSs and my
home router, which acted as a gateway to a ""private UUCP network for my
internal systems. So, friends wouldn't be able to UUCP to my private
workstation, but my VPSs could.

> True. A compromised node3 could send packets that claim to be from
> node3, as of course they would be, and could execute whatever attacks
> node3 would be granted permissions to do. I didn't mean to imply
> that compromise of node3 would be a "meh, I don't care" event, but
> rather that it couldn't be used to spoof another node.

ACK

> Possibly, and that's why there is a minsize configuration option and
> parameter: http://www.nncpgo.org/Commands.html#OptMinSize

I'm thinking something like size minus minimum and then dividing by X
bytes per wrapper to guestimate how many wrappers there are.

I wonder if you could mess with things by doing something like this:
node1!node2!node3!node2!node3!node4!node5 }:-)

--
Grant. . . .
unix || die

On Monday, January 4, 2021 at 10:36:07 PM UTC-6, Grant Taylor wrote:

> I largely agree. Though the thing that fails this type of configuration
> in my experience is that the nncp user probably can't access files from
> your home directory to send. So you need to arrange access be it
> permissions or file location.

Ahh, but nncp-file can read from stdin (without buffering in RAM!) So you can do:

sudo -Hu nncp nncp-file - node2:blah.tar.gz < bigfile.tar.gz

Now if you want to use NNCP's support for sending a directory (in which it internally makes a tar file anyway), then you'd have to move it to a location NNCP could acces, yes. Or else make the tar file yourself and pipe it to nncp-file.

> > Right. NNCP does maintain an outbound queue in subdirectories per
> > node (named after the node's public key). But there is no way for
> > the receiver to see what the via-path was for a packet to reach it;
> > it is expected that for an answer to be returned, the via-path should
> > be defined in the config file on the receiver.
> Please elaborate. How would node3 use a via-path and be able to send an
> error to node1?

It would have to use the default via-path defined in its config file. In the absence of that, it would queue it for node1 directly.

I think the basic idea with NNCP is that you generally know the routes to take in advance, so specify them as defaults to take that burden away from every command invocation. You still CAN do that, but usually don't need to.

> I wonder if you could mess with things by doing something like this:
> node1!node2!node3!node2!node3!node4!node5 }:-)

Sooner or later you're going to have to install this thing to test your evil machinations yourself :-)

- John

On 1/4/21 9:48 PM, John Goerzen wrote:
> Ahh, but nncp-file can read from stdin (without buffering in RAM!)

*nod*nod*

> It would have to use the default via-path defined in its config file.
> In the absence of that, it would queue it for node1 directly.

ACK

> I think the basic idea with NNCP is that you generally know the
> routes to take in advance, so specify them as defaults to take that
> burden away from every command invocation. You still CAN do that,
> but usually don't need to.

ACK

> Sooner or later you're going to have to install this thing to test
> your evil machinations yourself :-)

Ya. I don't /currently/ have a use for it. So for now it's just
investigation. I will likely spin up a couple of VMs and play with
things as time permits in the future.

--
Grant. . . .
unix || die