public inbox for nncp-devel@lists.stargrave.org
Atom feed
From: John Goerzen <jgoerzen@complete•org>
To: Sergey Matveev <stargrave@stargrave•org>
Cc: nncp-devel@lists.cypherpunks.ru
Subject: Re: Assorted NNCP questions
Date: Mon, 28 Dec 2020 12:32:17 -0600	[thread overview]
Message-ID: <87zh1xok7i.fsf@complete.org> (raw)
In-Reply-To: <X+mLYSHucMJcQ/Pp@stargrave.org>


On Mon, Dec 28 2020, Sergey Matveev wrote:

> *** John Goerzen [2020-12-27 22:34]:
>>Ahhhh..  I hadn't realized that it had to be in sync on both 
>>ends. When I
>>corrected that, it began behaving as expected.  That does have 
>>some logic to
>>it; presumably whatever side has the smallest value becomes the 
>>operative one
>>for the connection?  This may be a useful thing to document 
>>wherever those
>>settings are referenced.
>
> Agreed and will document it explicitly. Each side has its own 
> deadline
> timers and if one is decided that session is over, then of 
> course it
> will disconnect.

So one question I'm having here is how does it work.  Does the 
timeout apply to:

1) No incoming or outgoing NNCP packets to the site;

or

2) No response to PING commands in that amount of time?

I'm guessing from the documentation the answer is #1.  That raises 
the question: can the code be configured to use SO_KEEPALIVE or a 
protocol-level ping to hold the TCP connection open?  This would 
help, eg, for NAT devices with short timeouts or a remote that's 
crashed and rebooted (to detect that it is no longer 
communicating).


> Personally I make my backups with gpg too, but just to be sure 
> that
> their encrypted form is placed on long-term storage:
>     zfs send -R | zstd | gpg -z 0 -r ... -e | nncp-file - ...
> Anyway I should think about all of that subject with multiple
> recipients. If A sends data to C, -via B, then B-node anyway 
> will see

As I think about it, personally I think it would be best not to do 
this in the NNCP code.  The reason is that right now it is very 
clear that no node can see data except for the data destined for 
it.  Weakening this promise can lead to complexity, both for the 
implementation and for the users.  Complexity is a source of 
security bugs.  And I think the use case isn't very common, and 
could be resolved with a brief script combined with gpg.

My particular use case involves a low-bandwidth internet 
connection from A->B, and then B->C and B->D are both 
high-bandwidth (airgap or LAN).  So B can be an "exploder" to 
receive the data from A and then queue it up for both C and D.

But this is simple as the route to C and D both is "via B".  In 
other more complex situations, the "exploder" would be a different 
points in the route, or perhaps even several different exploders 
in the topology.  Representing that in NNCP itself would be 
complex.

So I think it is easy enough for me to gpg-encrypt on A, and have 
a tiny tiny script on B that uses tee to pipe it to two nncp-exec 
commands, one for C and one for D.  Only C and D would possess the 
decryption keys.

Representing this one case in NNCP might be easy enough (A 
generates a typical packet to B, with the inner data encrypted to 
both C and D's keys) but making it generic would be complex and 
probably not worth it.

- John

  reply	other threads:[~2020-12-28 18:33 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-27  4:48 Assorted NNCP questions John Goerzen
2020-12-27  9:53 ` Sergey Matveev
2020-12-28  4:34   ` John Goerzen
2020-12-28  7:37     ` Sergey Matveev
2020-12-28 18:32       ` John Goerzen [this message]
2020-12-28 19:43         ` Sergey Matveev
2020-12-30 12:01   ` Sergey Matveev