Onion routing considerations for libp2p

[Mikerah]

It's been great seeing all the progress in standardizing various aspects of libp2p in the past few months. Great work.

I just want to bring up implementing onion routing over libp2p. Past work has focused mainly on adding Tor onion routing as a libp2p transport (see here). However, Tor is just one way to do onion routing. Recent work by @gpestana has focused on other onion routing protocols like HORNET. Even though every onion routing protocol has its quirks, it would be great to start standardizing onion routing over libp2p.

[raulk]

@mikerah ack! Do you have bandwidth to help us assess state of the art and possible design directions? PL could consider funding a small grant for this.

[Mikerah]

I do! Hit me up on telegram.

[gpestana]

@Mikerah nice, I'd love to help with this!

[cheako]

I've been reviewing Arti, tor implemented in Rust. I'm planing on using tor bridges as relays for #312

[wheresaddie]

bumping this issue as we currently are discussing implementation and are planning to align during Lisbon on next steps

[mxinden]

Cross referencing https://github.com/libp2p/rust-libp2p/pull/2899 by @umgefahren here.

[umgefahren]

Cross referencing libp2p/rust-libp2p#2899 by @umgefahren here.

This effort however is just an implementation of Tor as a transport for rust-libp2p.

Just for clarification: Is this about standardizing Onion Routers / Mixnets as libp2p transports (relying on non libp2p p2p networks, i.e. I2P, Tor and ones that use libp2p like hoprnet) or defining a general way of using libp2p for Onion Routing? Considering the latter I'm thinking of a mixture between protocol, transport and multiplexer or in other words providing ways to route traffic through other libp2p nodes like Tor nodes do (I know we do something similar for NAT).

Both things are interesting. Although the latter would be really challenging from my point of view. Regardless I would be happy to participate here, since I already developed the Tor transport for rust-libp2p and I will be in Lisbon too.

Finally I want to point out that there is more to Tor than just the onion routing. The ability to do DNS while keeping a Tor client anonymous and hidden services are at least as important as the onion routing. Last but not least the anti-censorship and hole punching capabilities are very important too. There are really good reasons to make these parts also available to libp2p, although there are not directly onion routing.

[TheRook]

@umgefahren I agree that privacy and censorship are really separate. Censorship is really about blending in an ibp2p-tls is maybe a little closer to HTTPS than Tor. Have you seen the https://snowflake.torproject.org/ project?

Finally I want to point out that there is more to Tor than just the onion routing. The ability to do DNS while keeping a Tor client anonymous and hidden services are at least as important as the onion routing. Last but not least the anti-censorship and hole punching capabilities are very important too. There are really good reasons to make these parts also available to libp2p, although there are not directly onion routing.

[cheako]

@TheRook I opened a ticket with snowflake to migrate it to libp2p... but after some research I discovered that the libp2p on wire protocol is insufficient for what I was thinking and stopped as the result would have been another bespoke protocol. Specifically, libp2p applications can't share a signaler where the signal server can mandate clients advertise something like the snowflake protocol.

[TheRook]

@cheako I think the existing TLS and webrtc are really the best transports we could be using to avoid deep-packet inspection. Because we have TLS, I was suggesting we just adopt snowflake's bootstrapping system which is a lot easier to do that impalement some kind of onion routing or an exotic protocol, which i don't see helping with the problem of censorship - at least not right away.

If I am not mistaken, I think we can piggyback on snowflake's bootstrapping infrastructure and use it to from connections to the libp2p DHT without using Tor at all.

Certificate pinning to build trusted connections will likely have a much more meaningful important impact on the network, and it doesn't incur additional network overhead as with onion routing. We have observed content filters MITM'ing TLS, and without a certificate authority our options are limited, but cert pinning is a still viable solution to the problem of MITM. We can also use snowflake to make our TLS appear more similar to HTTPS, and I think this is a good feature to support.

[TheRook]

@cheako On the privacy front - it looks like we have a libp2p onion router in golang here: https://github.com/hashmatter/libp2p-onion-routing

There are other privacy preserving features implanted by hashmatter which work together that can be found below: https://github.com/hashmatter/p3lib

[cheako]

@TheRook My interests are regarding nat traversal. I'm interested in small networks ~5nodes where all of them are behind nat. My goal is for the solution to be accessible to my 7year old self, servers and domains should be provided by volunteers.

For example, what if a dozen networks share a signaling server, you'd want advanced routing taking place on the signaling server. I also want things like the signaling server to be able to mandate and enforce well-behaved clients. That is, if the admin wants to only allow clients that support kad-dht that should be possible in a secure way.

For me, this is a big dream.

[TheRook]

I am also quite interested in NAT traversal, in fact I found two rather nasty NAT traversal bugs in the mainline. I fond that nat teaveral fail if two clients try and use the same incoming port - pretty simple mistake and an easy fix - but the bug is unassigned.

Have you looked at IPFS delegate routers? Because libp2p is slow at solving these problems IPFS was forced to developed delegate routers to handle NAT traversal - so it sounds like the feature we both want.

Delegate routers can also aid in privacy and freedom of information - in that it is a lot more difficult to filter every delegate - when the network is constantly changing.

On Wed, Feb 22, 2023, 12:17 AM Michael Mestnik @.***> wrote:

@TheRook https://github.com/TheRook My interests are regarding nat traversal. I'm interested in small networks ~5nodes where all of them are behind nat. My goal is for the solution to be accessible to my 7year old self, servers and domains should be provided by volunteers.

For example, what if a dozen networks share a signaling server, you'd want advanced routing taking place on the signaling server. I also want things like the signaling server to be able to mandate and enforce well-behaved clients. That is, if the admin wants to only allow clients that support kad-dht that should be possible in a secure way.

For me, this is a big dream.

— Reply to this email directly, view it on GitHub https://github.com/libp2p/specs/issues/200#issuecomment-1439599216, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAD7MN5ZF2ILGTWIZKGELFTWYXDTLANCNFSM4IIRAHTA . You are receiving this because you were mentioned.Message ID: @.***>

[randomodbuild]

Now that browser to browser WebRTC has been implemented in js-libp2p, are there any updates to implementing onion routing? Could help protect privacy as well as evading censorship for those in restrictive networks who need to bootstrap.

[TheRook]

Now that browser to browser WebRTC has been implemented in js-libp2p, are there any updates to implementing onion routing? Could help protect privacy as well as evading censorship for those in restrictive networks who need to bootstrap.

Onion routing has already been implemented, but hasn't been merged. IPFS is a VC scam to get people to pay for data services.

[randomodbuild]

What? Care to elaborate.

[TheRook]

Onion routing on libp2p has been implemented more than once - why are you looking to write another?

https://github.com/hashmatter/libp2p-onion-routing

On Mon, May 1, 2023 at 2:17 PM randomodbuild @.***> wrote:

Now that browser to browser WebRTC has been implemented in js-libp2p, are there any updates to implementing onion routing? Could help protect privacy as well as evading censorship for those in restrictive networks who need to bootstrap.

— Reply to this email directly, view it on GitHub https://github.com/libp2p/specs/issues/200#issuecomment-1530297447, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAD7MNYZG2CTUNG7AVSNXADXEAR7FANCNFSM4IIRAHTA . You are receiving this because you were mentioned.Message ID: @.***>

[AustinFoss]

I

Now that browser to browser WebRTC has been implemented in js-libp2p, are there any updates to implementing onion routing? Could help protect privacy as well as evading censorship for those in restrictive networks who need to bootstrap.

I just came looking for this sort of open issue after finding that previously mentioned library that "has already been implemented" and the youtube presentation.

IMO i don't think that libp2p will have thing like onion routing ever added as a core part of it's protocol. Could be wrong on that but it's just my intuition. There are ways of tunneling IPFS over Tor from a server node but for a browser context projects like this may be more well suited: https://github.com/Ayms/node-Tor/tree/master

Though both solutions mentioned so far do not seem quite complete. Being able to anonymize libp2p will happen but it is still relatively early days.