public inbox for nncp-devel@lists.cypherpunks.ru
Atom feed
* [EN] NNCP 8.1.0 release announcement
@ 2022-01-16 13:14 Sergey Matveev
2022-01-17 1:19 ` John Goerzen
0 siblings, 1 reply; 9+ messages in thread
From: Sergey Matveev @ 2022-01-16 13:14 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1.1: Type: text/plain, Size: 2146 bytes --]
I am pleased to announce NNCP 8.1.0 release availability!
NNCP (Node to Node copy) is a collection of utilities simplifying
secure store-and-forward files and mail exchanging.
This utilities are intended to help build up small size (dozens of
nodes) ad-hoc friend-to-friend (F2F) statically routed darknet
delay-tolerant networks for fire-and-forget secure reliable files, file
requests, Internet mail and commands transmission. All packets are
integrity checked, end-to-end encrypted (E2EE), explicitly authenticated
by known participants public keys. Onion encryption is applied to
relayed packets. Each node acts both as a client and server, can use
push and poll behaviour model. Also there is multicasting areas support.
Out-of-box offline sneakernet/floppynet, dead drops, sequential and
append-only CD-ROM/tape storages, air-gapped computers support. But
online TCP daemon with full-duplex resumable data transmission exists.
------------------------ >8 ------------------------
The main improvements for that release are:
* "nncp-cfgdir" does not require "self" section existence in
configuration file.
* Ability to act as Yggdrasil network client, using online protocol
on top of it. http://www.nncpgo.org/Yggdrasil.html
------------------------ >8 ------------------------
NNCP's home page is: http://www.nncpgo.org/
Source code and its signature for that version can be found here:
http://www.nncpgo.org/download/nncp-8.1.0.tar.xz (1339 KiB)
http://www.nncpgo.org/download/nncp-8.1.0.tar.xz.sig
SHA256 hash: 777536DF 775E76D6 6B05645D 6F440494 D39DFCBD 7E52DE02 5AF919A3 94CF53EC
GPG key ID: 0x2B25868E75A1A953 NNCP releases <releases@nncpgo•org>
Fingerprint: 92C2 F0AE FE73 208E 46BF F3DE 2B25 868E 75A1 A953
There are mirrors where you can also get the source code tarballs:
http://www.nncpgo.org/Mirrors.html
Please send questions regarding the use of NNCP, bug reports and patches
to mailing list: http://lists.cypherpunks.ru/nncp_002ddevel.html
--
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
[-- Attachment #1.2: nncp-8.1.0.tar.xz.meta4 --]
[-- Type: application/metalink4+xml, Size: 1270 bytes --]
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [EN] NNCP 8.1.0 release announcement
2022-01-16 13:14 [EN] NNCP 8.1.0 release announcement Sergey Matveev
@ 2022-01-17 1:19 ` John Goerzen
2022-01-17 7:01 ` Sergey Matveev
0 siblings, 1 reply; 9+ messages in thread
From: John Goerzen @ 2022-01-17 1:19 UTC (permalink / raw)
To: Sergey Matveev; +Cc: nncp-devel
Hi Sergey,
I just read http://www.nncpgo.org/Yggdrasil.html and WOW, this is
fantastic!
I've read up on the doc page and I'm a little unclear on a few things:
- Does it support the Yggdrasil LAN multicast, and if so, can the
interfaces it listens on for that be listed?
- If one does not want to have an open port for incoming peer
connections, can a person just omit the bindPublic and bindLocalhost?
- Does the "optional list of allowed incoming connections" refer to
systems that are allowed to establish peering connections to the
embedded Yggdrasil node, or does it mean a list of systems that are
allowed to connect to NNCP over Yggdrasil?
- Either way, I'm unclear how to give that list of allowed incoming
connections.
Thanks!
- John
On Sun, Jan 16 2022, Sergey Matveev wrote:
> I am pleased to announce NNCP 8.1.0 release availability!
>
> NNCP (Node to Node copy) is a collection of utilities simplifying
> secure store-and-forward files and mail exchanging.
>
> This utilities are intended to help build up small size (dozens of
> nodes) ad-hoc friend-to-friend (F2F) statically routed darknet
> delay-tolerant networks for fire-and-forget secure reliable files, file
> requests, Internet mail and commands transmission. All packets are
> integrity checked, end-to-end encrypted (E2EE), explicitly authenticated
> by known participants public keys. Onion encryption is applied to
> relayed packets. Each node acts both as a client and server, can use
> push and poll behaviour model. Also there is multicasting areas support.
>
> Out-of-box offline sneakernet/floppynet, dead drops, sequential and
> append-only CD-ROM/tape storages, air-gapped computers support. But
> online TCP daemon with full-duplex resumable data transmission exists.
>
> ------------------------ >8 ------------------------
>
> The main improvements for that release are:
>
> * "nncp-cfgdir" does not require "self" section existence in
> configuration file.
>
> * Ability to act as Yggdrasil network client, using online protocol
> on top of it. http://www.nncpgo.org/Yggdrasil.html
>
> ------------------------ >8 ------------------------
>
> NNCP's home page is: http://www.nncpgo.org/
>
> Source code and its signature for that version can be found here:
>
> http://www.nncpgo.org/download/nncp-8.1.0.tar.xz (1339 KiB)
> http://www.nncpgo.org/download/nncp-8.1.0.tar.xz.sig
>
> SHA256 hash: 777536DF 775E76D6 6B05645D 6F440494 D39DFCBD 7E52DE02 5AF919A3 94CF53EC
> GPG key ID: 0x2B25868E75A1A953 NNCP releases <releases@nncpgo•org>
> Fingerprint: 92C2 F0AE FE73 208E 46BF F3DE 2B25 868E 75A1 A953
>
> There are mirrors where you can also get the source code tarballs:
> http://www.nncpgo.org/Mirrors.html
>
> Please send questions regarding the use of NNCP, bug reports and patches
> to mailing list: http://lists.cypherpunks.ru/nncp_002ddevel.html
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [EN] NNCP 8.1.0 release announcement
2022-01-17 1:19 ` John Goerzen
@ 2022-01-17 7:01 ` Sergey Matveev
2022-01-17 14:55 ` John Goerzen
0 siblings, 1 reply; 9+ messages in thread
From: Sergey Matveev @ 2022-01-17 7:01 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1: Type: text/plain, Size: 1766 bytes --]
Greetings!
*** John Goerzen [2022-01-16 19:19]:
>I've read up on the doc page and I'm a little unclear on a few things:
You right with all questions: indeed it is not so obvious and clear in
documentation. Will definitely update it. Also I am looking to replace
μTP transport protocol with pure TCP (implemented on pure Go) or
something even simpler. It looks like unnecessary overhead. But I should
investigate it deeper.
>- Does it support the Yggdrasil LAN multicast, and if so, can the
>interfaces it listens on for that be listed?
By default no, but can be added quite easily, that I will do. I just
ignored that feature for later times.
>- If one does not want to have an open port for incoming peer
>connections, can a person just omit the bindPublic and bindLocalhost?
Currently no (without any reason :-)), but you are right that it is
completely ordinary use-case. Will do it.
>- Does the "optional list of allowed incoming connections" refer to
>systems that are allowed to establish peering connections to the
>embedded Yggdrasil node, or does it mean a list of systems that are
>allowed to connect to NNCP over Yggdrasil?
It is related only to Yggdrasil network, to its "AllowedPublicKeys"
configuration option. Will make it more clear in documentation too.
>- Either way, I'm unclear how to give that list of allowed incoming
>connections.
You can control (or allow any) only peer connections to the listener,
with the option above. No ability to limit who can be answered to as
NNCP service itself, except for removing noise* keys from configuration
to forbid online protocol usage at all.
--
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [EN] NNCP 8.1.0 release announcement
2022-01-17 7:01 ` Sergey Matveev
@ 2022-01-17 14:55 ` John Goerzen
2022-01-17 15:08 ` Sergey Matveev
0 siblings, 1 reply; 9+ messages in thread
From: John Goerzen @ 2022-01-17 14:55 UTC (permalink / raw)
To: Sergey Matveev; +Cc: nncp-devel
On Mon, Jan 17 2022, Sergey Matveev wrote:
> Greetings!
>
> *** John Goerzen [2022-01-16 19:19]:
>>I've read up on the doc page and I'm a little unclear on a few things:
>
> You right with all questions: indeed it is not so obvious and clear in
> documentation. Will definitely update it. Also I am looking to replace
> μTP transport protocol with pure TCP (implemented on pure Go) or
> something even simpler. It looks like unnecessary overhead. But I should
> investigate it deeper.
TCP would be really convenient! It would also enable cooperation
between NNCP nodes that use the new integrated Yggdrasil code, and NNCP
nodes that have a standalone Yggdrasil node and simply listen on a port
that's available over Yggdrasil (as I already have been doing here).
I have been working to get the quux public relay available on Yggdrasil,
and being able to not have to say "this way for TCP with standlone, that
way for uTP with integrated" would be really nice.
If a change to TCP is imminent, perhaps I will hold off packaging and
uploading 8.1.0 to Debian so as to not introduce something that will
shortly be replaced over there.
>>- Does it support the Yggdrasil LAN multicast, and if so, can theq
>>interfaces it listens on for that be listed?
>
> By default no, but can be added quite easily, that I will do. I just
> ignored that feature for later times.
>
>>- If one does not want to have an open port for incoming peer
>>connections, can a person just omit the bindPublic and bindLocalhost?
>
> Currently no (without any reason :-)), but you are right that it is
> completely ordinary use-case. Will do it.
>
>>- Does the "optional list of allowed incoming connections" refer to
>>systems that are allowed to establish peering connections to the
>>embedded Yggdrasil node, or does it mean a list of systems that are
>>allowed to connect to NNCP over Yggdrasil?
>
> It is related only to Yggdrasil network, to its "AllowedPublicKeys"
> configuration option. Will make it more clear in documentation too.
>
>>- Either way, I'm unclear how to give that list of allowed incoming
>>connections.
>
> You can control (or allow any) only peer connections to the listener,
> with the option above. No ability to limit who can be answered to as
> NNCP service itself, except for removing noise* keys from configuration
> to forbid online protocol usage at all.
Got it, thanks!
- John
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [EN] NNCP 8.1.0 release announcement
2022-01-17 14:55 ` John Goerzen
@ 2022-01-17 15:08 ` Sergey Matveev
2022-01-17 20:23 ` John Goerzen
0 siblings, 1 reply; 9+ messages in thread
From: Sergey Matveev @ 2022-01-17 15:08 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1: Type: text/plain, Size: 1007 bytes --]
*** John Goerzen [2022-01-17 08:55]:
>TCP would be really convenient! It would also enable cooperation
>between NNCP nodes that use the new integrated Yggdrasil code, and NNCP
>nodes that have a standalone Yggdrasil node and simply listen on a port
>that's available over Yggdrasil (as I already have been doing here).
No, TCP transport over Yggdrasil packet interface is not related or
interfere with ordinary TCP in anyway :-). But I see completely no
problems for nncp-daemon to listen on both "interfaces" (on Yggdrasil
and ordinary TCP), so will add that possibility too.
>If a change to TCP is imminent
I will definitely add ability to listen simultaneously on TCP as
previously and optionally on Yggdrasil. But I do not know if will
succeed in replacing μTP with TCP -- but anyway it is completely
hidden from the user.
Thanks for all your notes and suggestions!
--
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [EN] NNCP 8.1.0 release announcement
2022-01-17 15:08 ` Sergey Matveev
@ 2022-01-17 20:23 ` John Goerzen
2022-01-17 21:07 ` Emery Hemingway
2022-01-18 22:01 ` Yggdrasil Sergey Matveev
0 siblings, 2 replies; 9+ messages in thread
From: John Goerzen @ 2022-01-17 20:23 UTC (permalink / raw)
To: Sergey Matveev; +Cc: nncp-devel
On Mon, Jan 17 2022, Sergey Matveev wrote:
> *** John Goerzen [2022-01-17 08:55]:
>>TCP would be really convenient! It would also enable cooperation
>>between NNCP nodes that use the new integrated Yggdrasil code, and NNCP
>>nodes that have a standalone Yggdrasil node and simply listen on a port
>>that's available over Yggdrasil (as I already have been doing here).
>
> No, TCP transport over Yggdrasil packet interface is not related or
> interfere with ordinary TCP in anyway :-). But I see completely no
> problems for nncp-daemon to listen on both "interfaces" (on Yggdrasil
> and ordinary TCP), so will add that possibility too.
I understand. I think I explained poorly. One can run NNCP on
Yggdrasil in two ways:
1) By running the Yggdrasil software outside NNCP, and just using
Yggdrasil IPv6 addrs, which will have a TCP connection.
2) By running the embedded Yggdrasil node, which will use uTP.
It would be great if these two modes of operation were compatible. That
is, if you run a node with the embedded code, you could connect to it
with the traditional (TCP to an IPv6 address) code.
This way, how the other end connects to Yggdrasil is transparent. All
four types of connection would be possible:
Client with embedded Ygg -> server with embedded Ygg
Client with embedded Ygg -> server with standalone Ygg
Client with standlone Ygg -> server with embedded Ygg
Client with standlone Ygg -> server with standalone Ygg
>>If a change to TCP is imminent
>
> I will definitely add ability to listen simultaneously on TCP as
> previously and optionally on Yggdrasil. But I do not know if will
> succeed in replacing μTP with TCP -- but anyway it is completely
> hidden from the user.
Except, of course, that you can't mix and match the two approaches. So
if you have someone that is saying "connect to me over NNCP at
yggdrasil:....", you can't just put an IPv6 address in addrs and have it
working using your system's existing Yggdrasil interface. There may be
reasons a person would want to run Yggdrasil standalone. For instance:
- Tighter control over connections by using a firewall
- Support for multicast peer detection
- Tighter control over what version of Yggdrasil is used
- Ability to run multiple services under a single key
And of course reasons a person may want to run the embedded Yggdrasil
instance:
- No chance of accidental exposure of ports over the public Yggdrasil IP
- A quick and effective way to bypass the firewall/NAT problem - no need
to install a separate piece of software on the system
- No need to have a process running as root
Ideally, one should be able to move a keypair from yggdrasil.conf to
nncp.hjson (or the reverse) and keep operating as before with zero
changes to clients.
Thanks for all this!
John
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [EN] NNCP 8.1.0 release announcement
2022-01-17 20:23 ` John Goerzen
@ 2022-01-17 21:07 ` Emery Hemingway
2022-01-18 22:13 ` Yggdrasil support Sergey Matveev
2022-01-18 22:01 ` Yggdrasil Sergey Matveev
1 sibling, 1 reply; 9+ messages in thread
From: Emery Hemingway @ 2022-01-17 21:07 UTC (permalink / raw)
To: nncp-devel
Hello,
The Yggdrasil feature came at an ideal time for me, last week I was
trying to setup a relay in a container without TUN permissions (so no
local Yggdrasil node) and no access to a 300:/8 gateway.
I only started with the Yggdrasil feature today, but sticking with µTP
sounds fine to me. Yggdrasil almost always tunneled through TCP anyway.
Configuration of the embedded node and neighbors could use some
improvements, but I think compatibility between nodes using embedded
Yggdrasil and naïve TCP/IP nodes can wait until we get more experience.
There are other protocols that could be tunnelled through Yggdrasil, so
what to do is an open question that isn't limited to NNCP.
Something worth mentioning is that Yggdrasil network can be crawled and
the NNCP nodes discovered. The fix to keep NNCP private is to bind the
daemon to an 300:…/64 address that is routed though Yggdrasil gateway.
A Yggdrasil node can be passively discovered but to find the 300:…/64
addresses being it takes active enumeration.
Also, thanks for the missing "self" fix. With that I hope to upstream
the NNCP NixOS module soon.
Cheers,
Emery
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Yggdrasil support
2022-01-17 21:07 ` Emery Hemingway
@ 2022-01-18 22:13 ` Sergey Matveev
0 siblings, 0 replies; 9+ messages in thread
From: Sergey Matveev @ 2022-01-18 22:13 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1: Type: text/plain, Size: 1452 bytes --]
Greetings!
*** Emery Hemingway [2022-01-17 21:07]:
>The Yggdrasil feature came at an ideal time for me, [...]
Cool! Glad to hear that! Soon there will be an updated version with many
fixes in documentation, slightly more flexible options and ability to
act as real TCP-answering node inside that Yggdrasil network.
>I only started with the Yggdrasil feature today, but sticking with µTP
>sounds fine to me.
I believe that yggmail's author, being also the author of µTP library,
just used it for code simplicity. I do not think it is too overheadful
and harmful for performance, so indeed acceptable. But anyway, my commit
with its replacement is already ready :-). Actually TCP also has
undesirable overhead at least with its CRCs, that are just useless with
Yggdrasil's authenticated encryption, but it is negligible.
>Something worth mentioning is that Yggdrasil network can be crawled and
>the NNCP nodes discovered. The fix to keep NNCP private is to bind the
>daemon to an 300:…/64 address that is routed though Yggdrasil gateway
I think it is applicable only when you run NNCP daemon in "TCP mode" on
that 300/64 network. Yggdrasil-mode does not use /64 subnets feature at
all: just single public key maps to single IPv6 200/7 address. You just
have no option to change address or routing at all.
--
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Yggdrasil
2022-01-17 20:23 ` John Goerzen
2022-01-17 21:07 ` Emery Hemingway
@ 2022-01-18 22:01 ` Sergey Matveev
1 sibling, 0 replies; 9+ messages in thread
From: Sergey Matveev @ 2022-01-18 22:01 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1: Type: text/plain, Size: 2677 bytes --]
*** John Goerzen [2022-01-17 14:23]:
>It would be great if these two modes of operation were compatible. That
>is, if you run a node with the embedded code, you could connect to it
>with the traditional (TCP to an IPv6 address) code.
Ah, I see! I misunderstood you previously indeed.
Well, today I replaced μTP transport with full IP+TCP networking stack
implemented by gvisor.dev/gvisor. It works slightly faster than μTP, but
anyway much slower than direct ordinary TCP.
I think that is because of the Yggdrasil's code itself: it is very
simple and compact (that is good), but I noticed much memory allocations
and copying, that probably is the source of the problem. Anyway it means
that I just can not saturate gigabit link now.
That gave ability to use ordinary IPv6+TCP over Yggdrasil's PacketConn
interface. But it does not give ability to connect to the derived IPv6
address. Diving in the Yggdrasil's source code (that is really pretty
simple and small!) showed me that I also had to process special
out-of-band packets asking for my Yggdrasil node's full 256-bit public
key, that is related to given 200/7 IPv6-address. Without that, I was
only able to listen on ordinary TCP socket on 200/7 address and connect
to it with nncp-call "yggdrasil:" with explicitly provided full public
key. Yggdrasil's PacketConn interface really works only with full
ed25519 public keys as addresses. IPv6↔ed25519 resolution is completely
separate work pipeline.
Except for increased code size (well, now we are dealing with the full
IP+TCP network stack in Go!), the only danger is that Yggdrasil's
out-of-band packet types are not exported constants in its module
(typeKeyDummy, typeKeyLookup, typeKeyResponse in
yggdrasil-go/src/ipv6rwc/ipv6rwc.go), so I had to copy them, that won't
give guarantees that if next Yggdrasil's version won't change them.
>Client with embedded Ygg -> server with embedded Ygg
>Client with embedded Ygg -> server with standalone Ygg
>Client with standlone Ygg -> server with embedded Ygg
>Client with standlone Ygg -> server with standalone Ygg
Yes, all that cases should work now with my currently uncommited code.
>There may be
>reasons a person would want to run Yggdrasil standalone. For instance:
>[...]
All of that valid points! Seems they are good to be included in
documentation.
>Ideally, one should be able to move a keypair from yggdrasil.conf to
>nncp.hjson (or the reverse) and keep operating as before with zero
>changes to clients.
That should work fine.
--
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2022-01-18 22:14 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-16 13:14 [EN] NNCP 8.1.0 release announcement Sergey Matveev
2022-01-17 1:19 ` John Goerzen
2022-01-17 7:01 ` Sergey Matveev
2022-01-17 14:55 ` John Goerzen
2022-01-17 15:08 ` Sergey Matveev
2022-01-17 20:23 ` John Goerzen
2022-01-17 21:07 ` Emery Hemingway
2022-01-18 22:13 ` Yggdrasil support Sergey Matveev
2022-01-18 22:01 ` Yggdrasil Sergey Matveev