public inbox for nncp-devel@lists.cypherpunks.ru
Atom feed
* NNCP road warrior
@ 2022-01-06 20:54 John Goerzen
2022-01-08 0:57 ` Jonathan Lane
` (2 more replies)
0 siblings, 3 replies; 10+ messages in thread
From: John Goerzen @ 2022-01-06 20:54 UTC (permalink / raw)
To: nncp-devel
So I have been reflecting on the recent conversations about two
different routes and such, and thought "can we solve this problem at a
different layer?"
I've been looking into two options that would be very interesting here.
One is Yggdrasil network, https://yggdrasil-network.github.io/ . This
is an overlay network atop the public Internet, that is fully end-to-end
encrypted all the time. More particularly, the entire global network is
an auto-healing mesh, so if you take your laptop from home to work, it
will find a new path online (or re-establish a link with the same peer)
and your IP address remains the same. IP addresses are v6 only and are
derived from the node's public key, so each person gets basically a
globally-routable static IP, plus also a /64 subnet if you like. You
can also run Yggdrasil in an entirely closed network by simply never
connecting any of the nodes to a public peer on the main network (though
the moment one node is connected to the main network, they all are
reachable there via mesh routing)
Tinc vpn https://tinc-vpn.org/ is another option. While it came along
long before Yggdrasil, I think of it as sort of a private-only
alternative. Like Yggdrasil, it has mesh routing so you can reach any
of your nodes via any others so long as there is a path somewhere,
somehow. Unlike Yggdrasil, it's aimed more at traditional VPN uses and
lets you specify your own IP ranges, routing between networks, etc.
A sort of third option is Tor. I've tried this for awhile, and operate
a couple of nncp-daemons as a Tor onion service. This achieves the
portability I'm looking for, but is slow. EXTREMELY slow. So slow, in
fact, that NNCP seems to have a 10-second timeout on connect that often
gets triggered.
Here's my idea... for, say, sending things out from my laptop: I can
have the default addr for the destination (say, lan) be hardcoded to an
IP that is only reachable on the lan. Then, when I am traveling, I can
optionally manually trigger a call to a different address -- its tinc or
Yggdrasil one -- if I am at a place with good enough Internet service,
etc. I think that should all work reasonably well. Of course, if I
don't care about sending 10GB backups over tethered 4G, I could just
always use the tinc or Yggdrasil IP instead.
This doesn't resolve EVERY use case -- for instance, if my home box is
down and I still want to get backups out by sending some stuff via
something else -- but it does help, I think.
John
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: NNCP road warrior
2022-01-06 20:54 NNCP road warrior John Goerzen
@ 2022-01-08 0:57 ` Jonathan Lane
2022-01-08 11:26 ` Sergey Matveev
2022-01-12 21:40 ` John Goerzen
2022-01-08 7:17 ` Koushik Roy
2022-01-08 11:12 ` Sergey Matveev
2 siblings, 2 replies; 10+ messages in thread
From: Jonathan Lane @ 2022-01-08 0:57 UTC (permalink / raw)
To: nncp-devel
On Thu, Jan 06, 2022 at 02:54:39PM -0600, John Goerzen wrote:
> So I have been reflecting on the recent conversations about two
> different routes and such, and thought "can we solve this problem at a
> different layer?"
>
> I've been looking into two options that would be very interesting here.
>
> One is Yggdrasil network, https://yggdrasil-network.github.io/ . This
> is an overlay network atop the public Internet, that is fully end-to-end
> encrypted all the time. More particularly, the entire global network is
> an auto-healing mesh, so if you take your laptop from home to work, it
> will find a new path online (or re-establish a link with the same peer)
> and your IP address remains the same. IP addresses are v6 only and are
> derived from the node's public key, so each person gets basically a
> globally-routable static IP, plus also a /64 subnet if you like. You
> can also run Yggdrasil in an entirely closed network by simply never
> connecting any of the nodes to a public peer on the main network (though
> the moment one node is connected to the main network, they all are
> reachable there via mesh routing)
>
> Tinc vpn https://tinc-vpn.org/ is another option. While it came along
> long before Yggdrasil, I think of it as sort of a private-only
> alternative. Like Yggdrasil, it has mesh routing so you can reach any
> of your nodes via any others so long as there is a path somewhere,
> somehow. Unlike Yggdrasil, it's aimed more at traditional VPN uses and
> lets you specify your own IP ranges, routing between networks, etc.
>
> A sort of third option is Tor. I've tried this for awhile, and operate
> a couple of nncp-daemons as a Tor onion service. This achieves the
> portability I'm looking for, but is slow. EXTREMELY slow. So slow, in
> fact, that NNCP seems to have a 10-second timeout on connect that often
> gets triggered.
I think this gets back into the NNCP+Syncthing hybrid. In my recent
experience, the only places I don't have 5G/LTE on par with my home
LAN's uplink are -really- far off the beaten path, like a ship off shore
or on airplane wifi, and those situations tend to align more with just
working offline anyways. Multi-routing only makes sense for metered
connections where you want SOME connectivity, which I no longer have.
For those cases where you need an overlay to contact your home or a
well-located server, I enjoy Wireguard. It's got native support in
GNU/Linux and OpenBSD, and a nice set of mobile apps. Wireguard is also
much faster than Tor or even OpenVPN. Yggdrasil is something I haven't
tried, but based on my experience with CJDNS it probably works fine.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: NNCP road warrior
2022-01-06 20:54 NNCP road warrior John Goerzen
2022-01-08 0:57 ` Jonathan Lane
@ 2022-01-08 7:17 ` Koushik Roy
2022-01-12 22:07 ` John Goerzen
2022-01-08 11:12 ` Sergey Matveev
2 siblings, 1 reply; 10+ messages in thread
From: Koushik Roy @ 2022-01-08 7:17 UTC (permalink / raw)
To: John Goerzen, nncp-devel
John Goerzen <jgoerzen@complete•org> writes:
> One is Yggdrasil network, https://yggdrasil-network.github.io/ . This
> is an overlay network atop the public Internet, that is fully end-to-end
> encrypted all the time. More particularly, the entire global network is
> an auto-healing mesh, so if you take your laptop from home to work, it
> will find a new path online (or re-establish a link with the same peer)
> and your IP address remains the same. IP addresses are v6 only and are
> derived from the node's public key, so each person gets basically a
> globally-routable static IP, plus also a /64 subnet if you like. You
> can also run Yggdrasil in an entirely closed network by simply never
> connecting any of the nodes to a public peer on the main network (though
> the moment one node is connected to the main network, they all are
> reachable there via mesh routing)
I've joined the public mesh for this before and played around. It never
occurred to me to try to use this (or CJDNS) and have the underlying
mesh handle the routing for me. This sounds like a pretty great idea
honestly. It might even be a fun "social" way for folks to peer on
NNCP. Offering a handoff between an NNCP net on Hyperboria or the
Yggdrasil equivalent and a separate NNCP network on the regular net
might be interesting too. Lots of possibilities here!
>
> Tinc vpn https://tinc-vpn.org/ is another option. While it came along
> long before Yggdrasil, I think of it as sort of a private-only
> alternative. Like Yggdrasil, it has mesh routing so you can reach any
> of your nodes via any others so long as there is a path somewhere,
> somehow. Unlike Yggdrasil, it's aimed more at traditional VPN uses and
> lets you specify your own IP ranges, routing between networks, etc.
The reason I didn't want to go with a Tinc/OpenVPN/WireGuard solution is
configuration. Configuring routes is a pain, and I don't want to have to
remember different IPs in different situations. Though when I phrase it
this way, it makes it sound like a silly first-world problem :) It's
just that alternatives like CJDNS and Yggdrasil exist. I've used OpenVPN
in the past when I was traveling in a country that was heavy-handed with
internet censorship and offered access to friends when traveling in
censored countries as well.
> A sort of third option is Tor. I've tried this for awhile, and operate
> a couple of nncp-daemons as a Tor onion service. This achieves the
> portability I'm looking for, but is slow. EXTREMELY slow. So slow, in
> fact, that NNCP seems to have a 10-second timeout on connect that often
> gets triggered.
Tor seems a bit overkill here? NNCP is already doing its own
encryption. The onion routing doesn't seem as useful, but then again, it
depends on your use case. It would be interesting to setup an NNCP
hidden service that hands messages off to Usenet. Or this would only be
interesting to me and I'm weird, which is a perfectly acceptable result.
Thanks for the recommendation I have no idea why I completely forgot
about CJDNS and Yggdrasil. I'm probably going to set those up instead
and mesh my machines together and use NNCP over that. I can't believe I
missed something so obvious. I never ended up doing any measurements to
see what the overhead incurred by the mesh was the last time I was
playing around with CJDNS and Yggdrasil, so this seems like a good
opportunity to.
- Koushik
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: NNCP road warrior
2022-01-06 20:54 NNCP road warrior John Goerzen
2022-01-08 0:57 ` Jonathan Lane
2022-01-08 7:17 ` Koushik Roy
@ 2022-01-08 11:12 ` Sergey Matveev
2022-01-12 22:13 ` John Goerzen
2 siblings, 1 reply; 10+ messages in thread
From: Sergey Matveev @ 2022-01-08 11:12 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1: Type: text/plain, Size: 2425 bytes --]
Greetings!
*** John Goerzen [2022-01-06 14:54]:
>One is Yggdrasil network, https://yggdrasil-network.github.io/
That thing was great, when I looked at it last time! But I never
participated in its global overlay network.
I love the whole idea beneath cjdns: just create overlay network, with
encryption and convenient IPv6 addresses, nothing more, no anonymity
preservation, that would destroy all performance.
However when I joined Hyperboria network, then it segfaulted on my
FreeBSD at random times: possibly after ten seconds, possibly after
several hours. It was stable only outside Hyperboria. Probably it was
stable on GNU/Linux-es.
I like Yggdrasil because it is written on Go and have never seen any
fault with it, like it was happening with cjdns in Hyperboria. I thought
about using it as a VPN replacement, but because it works on top of TCP,
I abandoned that idea (efficiency questions).
>A sort of third option is Tor.
Also another option is I2P, that is much more serious network, but its
performance, at least because of smaller anonymity set (number of
participants in the whole network), is worse.
>This doesn't resolve EVERY use case -- for instance, if my home box is
>down and I still want to get backups out by sending some stuff via
>something else -- but it does help, I think.
Appears that the problem you are trying to solve is just the lack of
availability of some computers over the Internet. And the root of the
problem is still staying alive IPv4 with all that NATs among us. IPv6
gives globally routable addresses, that you would reach anywhere. Also
IPv6 committee thought and designed Mobile IPv6, that is pretty
efficient (it uses special IPsec-authenticated ICMPv6 packets and
extended headers for redirection to mobile address), but currently there
are no usable implementation in OSes out of box.
Because of increasing rates of IPv6 adoption (more that 35% of the whole
traffic in Internet is sent over IPv6, and, if I am not mistaken, more
than a half of traffic in USA is IPv6) all of that is just a question of
time when people will get the "real" Internet where arbitrary computer
can connect with another arbitrary computer.
But currently we have to use some workarounds indeed, like VPNs and
overlay networks.
--
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] 10+ messages in thread
* Re: NNCP road warrior
2022-01-08 0:57 ` Jonathan Lane
@ 2022-01-08 11:26 ` Sergey Matveev
2022-01-08 21:00 ` Jonathan Lane
2022-01-12 21:40 ` John Goerzen
1 sibling, 1 reply; 10+ messages in thread
From: Sergey Matveev @ 2022-01-08 11:26 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1: Type: text/plain, Size: 1585 bytes --]
*** Jonathan Lane [2022-01-08 00:57]:
>For those cases where you need an overlay to contact your home or a
>well-located server, I enjoy Wireguard.
I also appreciate it much! In my opinion it just literally just the best
VPN protocol: it just does its job right, without any optional features.
Many years ago, when I tried to use WiFi, I found that no existing VPN
solutions was satisfactory for me. I can not trust WiFi encryption
implementation in all those access points, so I have to use some
encrypted tunnel over its connections. SSH is slow. OpenVPN is slow and
burdensome to configure. IPsec's intro is virtually larger than the
whole Wireguard's source code :-). Moreover none of them gave ability to
use strong password authentication. And so on, so on. So I wrote my own
simple VPN on Go: http://www.govpn.info/. Later I have added other
features still not found in other solution. Now the project is
abandoned, because I started to love IPsec and use it everywhere now,
except for remote VPN connection over IPv4 networks, that is Wireguard
now. But Wireguard is definitely a thing that should be done a long time ago!
>Wireguard is also much faster than Tor or even OpenVPN.
[boring mode on :-)]
It should not be comparable with Tor: they solve completely different
tasks. It will be faster anyway, because it is direct point to point
tunnel. OpenVPN will be slower at least because of its ancient slow
cryptographic algorithms.
--
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] 10+ messages in thread
* Re: NNCP road warrior
2022-01-08 11:26 ` Sergey Matveev
@ 2022-01-08 21:00 ` Jonathan Lane
0 siblings, 0 replies; 10+ messages in thread
From: Jonathan Lane @ 2022-01-08 21:00 UTC (permalink / raw)
To: nncp-devel
On Sat, Jan 08, 2022 at 02:26:43PM +0300, Sergey Matveev wrote:
> >Wireguard is also much faster than Tor or even OpenVPN.
>
> [boring mode on :-)]
> It should not be comparable with Tor: they solve completely different
> tasks. It will be faster anyway, because it is direct point to point
> tunnel. OpenVPN will be slower at least because of its ancient slow
> cryptographic algorithms.
>
> --
> Sergey Matveev (http://www.stargrave.org/)
It's true that Tor does a completely different thing, but John brought
up the raw performance envelope comparison, which is why I thought
Wireguard was worth a mention. And yes, OpenVPN has many slownesses
baked into the design. IIRC the Wireguard developers wrote a whitepaper
about it explaining why they needed to build Wireguard in the first
place.
--
tidux@sdf•org
SDF Public Access UNIX System - http://sdf.org
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: NNCP road warrior
2022-01-08 0:57 ` Jonathan Lane
2022-01-08 11:26 ` Sergey Matveev
@ 2022-01-12 21:40 ` John Goerzen
1 sibling, 0 replies; 10+ messages in thread
From: John Goerzen @ 2022-01-12 21:40 UTC (permalink / raw)
To: nncp-devel
On Fri, Jan 07 2022, Jonathan Lane wrote:
> I think this gets back into the NNCP+Syncthing hybrid. In my recent
> experience, the only places I don't have 5G/LTE on par with my home
> LAN's uplink are -really- far off the beaten path, like a ship off shore
> or on airplane wifi, and those situations tend to align more with just
> working offline anyways. Multi-routing only makes sense for metered
> connections where you want SOME connectivity, which I no longer have.
Hi Jonathan,
Different places are different of course. Where I live (Kansas) a small
fraction of the state's land area has 5G, a decent chunk has 4G, but
there are still substantial places where you can't get any signal at
all. Go further west and you find places where most of a state has no
cell coverage at all. I also frequently travel to remote areas -- not
even really wilderness areas -- that have little or no connectivity.
John
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: NNCP road warrior
2022-01-08 7:17 ` Koushik Roy
@ 2022-01-12 22:07 ` John Goerzen
0 siblings, 0 replies; 10+ messages in thread
From: John Goerzen @ 2022-01-12 22:07 UTC (permalink / raw)
To: Koushik Roy; +Cc: nncp-devel
On Sat, Jan 08 2022, Koushik Roy wrote:
> John Goerzen <jgoerzen@complete•org> writes:
>
> I've joined the public mesh for this before and played around. It never
> occurred to me to try to use this (or CJDNS) and have the underlying
> mesh handle the routing for me. This sounds like a pretty great idea
> honestly. It might even be a fun "social" way for folks to peer on
> NNCP. Offering a handoff between an NNCP net on Hyperboria or the
> Yggdrasil equivalent and a separate NNCP network on the regular net
> might be interesting too. Lots of possibilities here!
I absolutely agree! I hope to get the Quux public relay available on
Yggdrasil in the near future.
FWIW, cjdns is no longer maintained and Hyperboria is also in decline.
Yggdrasil is both the software (akin to cjdns) and network (akin to
Hyperboria) and is explicitly designed to address some of the
shortcomings in cjdns and BATMAN.
>> Tinc vpn https://tinc-vpn.org/ is another option. While it came along
>> long before Yggdrasil, I think of it as sort of a private-only
>> alternative. Like Yggdrasil, it has mesh routing so you can reach any
>> of your nodes via any others so long as there is a path somewhere,
>> somehow. Unlike Yggdrasil, it's aimed more at traditional VPN uses and
>> lets you specify your own IP ranges, routing between networks, etc.
>
> The reason I didn't want to go with a Tinc/OpenVPN/WireGuard solution is
> configuration. Configuring routes is a pain, and I don't want to have to
> remember different IPs in different situations. Though when I phrase it
This is absolutely a great point. Yggdrasil is sooo easy. Though the
tradeoff is, if you peer with the main net anywhere, you probably want
to have a firewall in place (not a bad idea anyhow, really) since it
effectively gives you an unfiltered public IP.
>> A sort of third option is Tor. I've tried this for awhile, and operate
>> a couple of nncp-daemons as a Tor onion service. This achieves the
>> portability I'm looking for, but is slow. EXTREMELY slow. So slow, in
>> fact, that NNCP seems to have a 10-second timeout on connect that often
>> gets triggered.
>
> Tor seems a bit overkill here? NNCP is already doing its own
> encryption. The onion routing doesn't seem as useful, but then again, it
> depends on your use case. It would be interesting to setup an NNCP
> hidden service that hands messages off to Usenet. Or this would only be
> interesting to me and I'm weird, which is a perfectly acceptable result.
So the reason I was using tor is because hidden services on tor are
(except for things like Yggdrasil) one of the easiest ways to be able to
run nncp-daemon on a connection that can't have a public listening port.
Also in some cases, tor lets people bypass restrictive firewalls and
such. In fact, the quux public relay is available via tor. I have
used this technique to get files to my home machine from remote - but as
I said, it's so slow and I don't really need the anonymity at the tor
level anyhow.
> Thanks for the recommendation I have no idea why I completely forgot
> about CJDNS and Yggdrasil. I'm probably going to set those up instead
> and mesh my machines together and use NNCP over that. I can't believe I
> missed something so obvious. I never ended up doing any measurements to
> see what the overhead incurred by the mesh was the last time I was
> playing around with CJDNS and Yggdrasil, so this seems like a good
> opportunity to.
I tried it out at home.
I have 2.5Gbps LAN cards between my main workstation and a server.
Yggdrasil was running at about 1Gbps on that, which had the CPU on the
slower of the machines pegged, presumably due to encryption and such.
Over the public Internet, when I have my laptop at a remote location
peered directly to a computer at home, the latency of ssh is half what
it was when using a bastion box in between them. Also mosh is finally
usable for me due to the stability of IPs.
nncp over Yggdrasil is quite fast and well-performing, too.
John
>
> - Koushik
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: NNCP road warrior
2022-01-08 11:12 ` Sergey Matveev
@ 2022-01-12 22:13 ` John Goerzen
2022-01-14 8:03 ` Sergey Matveev
0 siblings, 1 reply; 10+ messages in thread
From: John Goerzen @ 2022-01-12 22:13 UTC (permalink / raw)
To: nncp-devel
Hi Sergey!
On Sat, Jan 08 2022, Sergey Matveev wrote:
> Greetings!
>
> *** John Goerzen [2022-01-06 14:54]:
>>One is Yggdrasil network, https://yggdrasil-network.github.io/
>
> I like Yggdrasil because it is written on Go and have never seen any
> fault with it, like it was happening with cjdns in Hyperboria. I thought
> about using it as a VPN replacement, but because it works on top of TCP,
> I abandoned that idea (efficiency questions).
I had concerns around this too. I haven't done a direct comparison to
Wireguard, but so far it is performing really well. I suspect this is
due to two things:
1. Configuring the interface for extra-jumbo packets (nearly 64K in most
cases)
2. Setting the TCP congestion handling algorithm to bbr
I don't have data to prove it, but I strongly suspect that these two
measures together would be in the same range of performance as UDP-based
algorithms except for the lossiest of links. Plus they avoid some of
the problems that the UDP-based algorithms can have around MTU.
> Appears that the problem you are trying to solve is just the lack of
> availability of some computers over the Internet. And the root of the
More it's the "I've got backups on my laptop and I want to get them
somewhere that's not my laptop at all costs, even if the intended
destination is down, so that if the laptop crashes, I don't lose the
backups with it."
- John
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: NNCP road warrior
2022-01-12 22:13 ` John Goerzen
@ 2022-01-14 8:03 ` Sergey Matveev
0 siblings, 0 replies; 10+ messages in thread
From: Sergey Matveev @ 2022-01-14 8:03 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1: Type: text/plain, Size: 1130 bytes --]
*** John Goerzen [2022-01-12 15:13]:
>> about using it as a VPN replacement, but because it works on top of TCP,
>> I abandoned that idea (efficiency questions).
>I don't have data to prove it, but I strongly suspect that these two
>measures together would be in the same range of performance as UDP-based
>algorithms except for the lossiest of links. Plus they avoid some of
>the problems that the UDP-based algorithms can have around MTU.
I understand that it greatly simplifies many things in code and all that
issues with MTU. But it can never be efficient because of
http://sites.inka.de/bigred/devel/tcp-tcp.html
Also it prevents *desired* behaviour of no attempts to deliver dropped
packets (well, UDP nature). It is completely good, simple, tempting and
acceptable solution for the mesh network, but not the replacement for
VPN between two hosts, between machines in the LAN, for multi-gigabit
datacenter solutions and that kind of things. I was only concerned about
that kind of use-cases.
--
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] 10+ messages in thread
end of thread, other threads:[~2022-01-14 8:03 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-06 20:54 NNCP road warrior John Goerzen
2022-01-08 0:57 ` Jonathan Lane
2022-01-08 11:26 ` Sergey Matveev
2022-01-08 21:00 ` Jonathan Lane
2022-01-12 21:40 ` John Goerzen
2022-01-08 7:17 ` Koushik Roy
2022-01-12 22:07 ` John Goerzen
2022-01-08 11:12 ` Sergey Matveev
2022-01-12 22:13 ` John Goerzen
2022-01-14 8:03 ` Sergey Matveev