4 ms·

A P2P Vision for QUIC (2024)

100 points by mooreds 1y ago

api 1y ago
Any UDP protocol can be made P2P if it can be bidirectionally authenticated. For TCP based protocols it's very hard since there is no reliable way to hole punch NATs and stateful firewalls with TCP.
- klabb3 1y ago
  Maybe success rates are higher with UDP – I don’t know. But it certainly works to hole punch with TCP as well. If you’re lucky you can even run into a rare condition called ”TCP simultaneous open”, where both sides believe they are the dialer.
  - embedding-shape 1y ago
    > where both sides believe they are the dialer. First time I've heard about this, and went looking for more. Came across https://news.ycombinator.com/item?id=5969030 https://news.ycombinator.com/item?id=5969030 (95 points - July 1, 2013 - 49 comments) that had bunch of background info + useful discussions.
  - api 1y ago
    It can be done, but it's less reliable and also requires the ability to forge packets that is not allowed on all platforms. So it's hard to use in any production application if you want it to run in user space, on Windows, or on mobile.
    - klabb3 1y ago
      No I don’t think it does. But I am using it in user space[1] successfully with no packet forging. I believe the outbound attempt (SYN) creates a mapping, and even if that conn is blocked on the other end, the inbound conn (SYN but in the other direction) is allowed. Again, maybe packet forging is needed for some routers/middleboxes/firewalls, since careful inspection would show that the conns are technically independent. If you have any details about this, please let me know! (Networking is difficult to test.) 1: https://payload.app/ https://payload.app/
superkuh 1y ago
Wait? How does that work? QUIC REQUIRES CA TLS for all endpoints. So you can do the discovery/router workarounds but then the person trying to connect to you with QUIC won't be able to unless you have a signed corporate CA TLS cert. I guess you could integrate some Lets Encrypt ACME2 periodic updater scheme into your P2P program but that's getting pretty complex and fragile. And it also provides a centralized way for anyone who doesn't like your P2P tool to legally/socially pressure it to shut it down.
- embedding-shape 1y ago
  I guess most if not all QUIC endpoints you come across the internet will have encryption, as the specification requires as such. But if you control both ends, say you're building a P2P application that happens to use QUIC, I don't think there is anything stopping you from using an implementation of QUIC that doesn't require that, or use something else than TLS, even if the specification would require you to have it.
  - superkuh 1y ago
    Just as long as you statically build and ship your application. Because I guarantee the QUIC libs in $distro are not going to be compiled with the experimental flags to make this possible. You're going to be fighting QUIC all the way to get this to work. It's the wrong choice for the job. Google did not design QUIC for human use cases and the protocol design reflects this.
    - embedding-shape 1y ago
      Judging (guessing) by the author's GitHub profile (https://github.com/marten-seemann https://github.com/marten-seemann), seems they've built their own "pure Go" QUIC implementation, maybe precisely for those purposes :)
- jayd16 1y ago
  Ok so you need to trust each other's certs. What's the big deal? Presumably you already have some other channel to share addresses so you can also share temporary self signed certs for this purpose.
throw0101d 1y ago
> Unfortunately, no matter how hard you try, there is a certain percentage of nodes for whom hole punching will never work. This is because their NAT behaves in an unpredictable way. Or they are centrally/corporate-controlled and do not allow hole punching.
- max-privatevoid 1y ago
  You can't disallow hole punching.
  - mikepurvis 1y ago
    From TFA: "Unfortunately, no matter how hard you try, there is a certain percentage of nodes for whom hole punching will never work. This is because their NAT behaves in an unpredictable way. While most NATs are well-behaved, some aren’t. This is one of the sad facts of life that network engineers have to deal with." In this scenario, the article goes on to describe a convention relay-based approach. I would guess that most consumer routers are very cooperative as far as hole punching because it's pretty critical functionality for bittorrent and many online games. Corporate firewalls wouldn't be as motivated to care about those use-cases or may want to actively block them.
    - embedding-shape 1y ago
      > Corporate firewalls wouldn't be as motivated I think parents point is a bit like "you can't disallow lock picking"; the term "hole punching" being used to describe techniques that are intentionally trying to bypass whatever thing others (particularly corporations) try to put in the way, sometimes for good reasons and sometimes for kind of shit reasons.
  - throw0101d 1y ago
    > You can't disallow hole punching. Try doing it over a network that only allows connections through a SOCKS/Squid proxy, or on a network that uses CG-NAT (i.e., double-NAT). See also: > UDP hole punching will not work with symmetric NAT devices (also known as bi-directional NAT) which tend to be found in large corporate networks. In symmetric NAT, the NAT's mapping associated with the connection to the known STUN server is restricted to receiving data from the known server, and therefore the NAT mapping the known server sees is not useful information to the endpoint. * https://en.wikipedia.org/wiki/UDP_hole_punching#Overview https://en.wikipedia.org/wiki/UDP_hole_punching#Overview
jauntywundrkind 1y ago
I hope some day the browser's webtransport also gets p2p support. It seemed like there was such a good exciting start, but the spec has been dormant for years. https://github.com/w3c/p2p-webtransport https://github.com/w3c/p2p-webtransport
- embedding-shape 1y ago
  Someone correct me if I'm wrong, but I think p2p-webtransport was superseded by "webtransport" (https://github.com/w3c/webtransport https://github.com/w3c/webtransport). Supposedly, the webtransport design should be flexible enough to support p2p even though focus is the traditional server<>client.
  - jauntywundrkind 1y ago
    Superceded? No. Webtransport already was well on its way to approval when p2p-webtransport was created. Webtransport as a protocol certainly could be used for p2p, but the browser APIs aren't there: hence p2p-webtransport was created, to allow its use beyond traditional server<->client.
  - vasilvv 1y ago
    The story here is a bit complicated. WebTransport is, in some sense, an evolution of RTCQuicTransport API, which was originally meant to solve the issues people had with SCTP/DTLS stack used by RTCDataChannel. At some point, the focus switched to client-server use cases, with an agreement that we can come back to the P2P scenario after we solve the client-server one.
- devttyeu 1y ago
  It is halfway there arguably, and libp2p does make use of it - https://docs.libp2p.io/concepts/transports/webtransport/ https://docs.libp2p.io/concepts/transports/webtransport/ Unlike websockets you can supply "cert hash" which makes it possible for the browser to establish a TLS connection with a client that doesn't have a certificate signed by a traditional PKI provider or even have a domain name. This property is immensely useful because it makes it possible for browsers to establish connections to any known non-browser node on the internet, including from secure contexts (i.e. from an https page where e.g. you can't establish a ws:// connection, only wss:// is allowed but you need a 'real' tls cert for that)
0-674-00671-2 1y ago
If I recollect, sha256 public or private signatures that are used on a thin-client for P2P server architecture. Carrier peering using the UDP hashes for encrypting network traffic from a WAN to serve a Tier 1 network.
1vuio0pswjnm7 1y ago
"Unfortunately, no matter how hard you try, there is a certain percentage of nodes for whom hole punching will never work." It might be helpful to cite the percentage It's relatively small A default policy that relays traffic through a third party is asinine For the small percentage, the third parties will always be there if they need them. The internet has an enormous supply of middlemen, like Google For everyone else, the third parties, i.e. the middlemen, can be avoided

100 points by mooreds 1y ago

api 1y ago

Any UDP protocol can be made P2P if it can be bidirectionally authenticated. For TCP based protocols it's very hard since there is no reliable way to hole punch NATs and stateful firewalls with TCP.

klabb3 1y ago
Maybe success rates are higher with UDP – I don’t know. But it certainly works to hole punch with TCP as well. If you’re lucky you can even run into a rare condition called ”TCP simultaneous open”, where both sides believe they are the dialer.
- embedding-shape 1y ago
  > where both sides believe they are the dialer. First time I've heard about this, and went looking for more. Came across https://news.ycombinator.com/item?id=5969030 https://news.ycombinator.com/item?id=5969030 (95 points - July 1, 2013 - 49 comments) that had bunch of background info + useful discussions.
- api 1y ago
  It can be done, but it's less reliable and also requires the ability to forge packets that is not allowed on all platforms. So it's hard to use in any production application if you want it to run in user space, on Windows, or on mobile.
  - klabb3 1y ago
    No I don’t think it does. But I am using it in user space[1] successfully with no packet forging. I believe the outbound attempt (SYN) creates a mapping, and even if that conn is blocked on the other end, the inbound conn (SYN but in the other direction) is allowed. Again, maybe packet forging is needed for some routers/middleboxes/firewalls, since careful inspection would show that the conns are technically independent. If you have any details about this, please let me know! (Networking is difficult to test.) 1: https://payload.app/ https://payload.app/

superkuh 1y ago

Wait? How does that work? QUIC REQUIRES CA TLS for all endpoints. So you can do the discovery/router workarounds but then the person trying to connect to you with QUIC won't be able to unless you have a signed corporate CA TLS cert. I guess you could integrate some Lets Encrypt ACME2 periodic updater scheme into your P2P program but that's getting pretty complex and fragile. And it also provides a centralized way for anyone who doesn't like your P2P tool to legally/socially pressure it to shut it down.

embedding-shape 1y ago
I guess most if not all QUIC endpoints you come across the internet will have encryption, as the specification requires as such. But if you control both ends, say you're building a P2P application that happens to use QUIC, I don't think there is anything stopping you from using an implementation of QUIC that doesn't require that, or use something else than TLS, even if the specification would require you to have it.
- superkuh 1y ago
  Just as long as you statically build and ship your application. Because I guarantee the QUIC libs in $distro are not going to be compiled with the experimental flags to make this possible. You're going to be fighting QUIC all the way to get this to work. It's the wrong choice for the job. Google did not design QUIC for human use cases and the protocol design reflects this.
  - embedding-shape 1y ago
    Judging (guessing) by the author's GitHub profile (https://github.com/marten-seemann https://github.com/marten-seemann), seems they've built their own "pure Go" QUIC implementation, maybe precisely for those purposes :)
jayd16 1y ago
Ok so you need to trust each other's certs. What's the big deal? Presumably you already have some other channel to share addresses so you can also share temporary self signed certs for this purpose.

throw0101d 1y ago

> Unfortunately, no matter how hard you try, there is a certain percentage of nodes for whom hole punching will never work. This is because their NAT behaves in an unpredictable way. Or they are centrally/corporate-controlled and do not allow hole punching.

max-privatevoid 1y ago
You can't disallow hole punching.
- mikepurvis 1y ago
  From TFA: "Unfortunately, no matter how hard you try, there is a certain percentage of nodes for whom hole punching will never work. This is because their NAT behaves in an unpredictable way. While most NATs are well-behaved, some aren’t. This is one of the sad facts of life that network engineers have to deal with." In this scenario, the article goes on to describe a convention relay-based approach. I would guess that most consumer routers are very cooperative as far as hole punching because it's pretty critical functionality for bittorrent and many online games. Corporate firewalls wouldn't be as motivated to care about those use-cases or may want to actively block them.
  - embedding-shape 1y ago
    > Corporate firewalls wouldn't be as motivated I think parents point is a bit like "you can't disallow lock picking"; the term "hole punching" being used to describe techniques that are intentionally trying to bypass whatever thing others (particularly corporations) try to put in the way, sometimes for good reasons and sometimes for kind of shit reasons.
- throw0101d 1y ago
  > You can't disallow hole punching. Try doing it over a network that only allows connections through a SOCKS/Squid proxy, or on a network that uses CG-NAT (i.e., double-NAT). See also: > UDP hole punching will not work with symmetric NAT devices (also known as bi-directional NAT) which tend to be found in large corporate networks. In symmetric NAT, the NAT's mapping associated with the connection to the known STUN server is restricted to receiving data from the known server, and therefore the NAT mapping the known server sees is not useful information to the endpoint. * https://en.wikipedia.org/wiki/UDP_hole_punching#Overview https://en.wikipedia.org/wiki/UDP_hole_punching#Overview

jauntywundrkind 1y ago

I hope some day the browser's webtransport also gets p2p support. It seemed like there was such a good exciting start, but the spec has been dormant for years. https://github.com/w3c/p2p-webtransport https://github.com/w3c/p2p-webtransport

embedding-shape 1y ago
Someone correct me if I'm wrong, but I think p2p-webtransport was superseded by "webtransport" (https://github.com/w3c/webtransport https://github.com/w3c/webtransport). Supposedly, the webtransport design should be flexible enough to support p2p even though focus is the traditional server<>client.
- jauntywundrkind 1y ago
  Superceded? No. Webtransport already was well on its way to approval when p2p-webtransport was created. Webtransport as a protocol certainly could be used for p2p, but the browser APIs aren't there: hence p2p-webtransport was created, to allow its use beyond traditional server<->client.
- vasilvv 1y ago
  The story here is a bit complicated. WebTransport is, in some sense, an evolution of RTCQuicTransport API, which was originally meant to solve the issues people had with SCTP/DTLS stack used by RTCDataChannel. At some point, the focus switched to client-server use cases, with an agreement that we can come back to the P2P scenario after we solve the client-server one.
devttyeu 1y ago
It is halfway there arguably, and libp2p does make use of it - https://docs.libp2p.io/concepts/transports/webtransport/ https://docs.libp2p.io/concepts/transports/webtransport/ Unlike websockets you can supply "cert hash" which makes it possible for the browser to establish a TLS connection with a client that doesn't have a certificate signed by a traditional PKI provider or even have a domain name. This property is immensely useful because it makes it possible for browsers to establish connections to any known non-browser node on the internet, including from secure contexts (i.e. from an https page where e.g. you can't establish a ws:// connection, only wss:// is allowed but you need a 'real' tls cert for that)

0-674-00671-2 1y ago

If I recollect, sha256 public or private signatures that are used on a thin-client for P2P server architecture. Carrier peering using the UDP hashes for encrypting network traffic from a WAN to serve a Tier 1 network.

1vuio0pswjnm7 1y ago

"Unfortunately, no matter how hard you try, there is a certain percentage of nodes for whom hole punching will never work." It might be helpful to cite the percentage It's relatively small A default policy that relays traffic through a third party is asinine For the small percentage, the third parties will always be there if they need them. The internet has an enormous supply of middlemen, like Google For everyone else, the third parties, i.e. the middlemen, can be avoided