Yes, the "path challenge" packets are usually padded to perform address
validation and MTU validation in a single transaction. As you say,
sending a lot of fully padded packets may create some overhead. It may
also create a "request forgery" concern, as stated in the security section.
Basically, we have a tradeoff. RFC 9000 does not actually mandate
padding of path challenge packets. In particular, servers are always
required to apply anti-amplification protection. If anti protection
limits the size of the server packets, they can defer PMTU validation
until more data has been received from the client, or until the client's
address has been validated. Sending unpadded path challenge packets is
not a protocol violation, it is just a less efficient, because it
inserts a 1RTT delay.
The downside is using the "masque" path for an extra 1-RTT. The upside
is lower overhead from failed trials, and also lower "amplification"
concerns -- basically, having the same impact as ICE currently does.
Opinions may differ, and it would be nice to hear them.
-- Christian Huitema
On 10/29/2024 5:47 AM, Ben Schwartz wrote:
In previous discussions, the main challenge I've heard for this architecture is
related to QUIC's approach to MTU qualification. STUN packets are tiny, so
it's tolerable to send a lot of them (O(N*M) to check all candidate pairs).
QUIC Initials and such are usually padded to prove that the path MTU is large
enough, which makes them terribly inefficient for NAT hole punching.
How do you imagine PMTUD would work for P2P QUIC?
--Ben
________________________________
From: Marten Seemann <[email protected]>
Sent: Monday, October 28, 2024 10:42 PM
To: QUIC WG <[email protected]>; [email protected] <[email protected]>
Subject: [Masque] p2p QUIC
Hi QUIC and MASQUE enthusiasts, Christian and I have published a blog post
describing our vision for a p2p extension of QUIC: https: //seemann.
io/posts/2024-10-26---p2p-quic/. The idea is to do everything inside of QUIC:
Imagine two p2p nodes
Hi QUIC and MASQUE enthusiasts,
Christian and I have published a blog post describing our vision for a p2p extension
of QUIC:
https://seemann.io/posts/2024-10-26---p2p-quic/<https://urldefense.com/v3/__https://seemann.io/posts/2024-10-26---p2p-quic/__;!!Bt8RZUm9aw!6W2t_dQMHs1tiFalSAENp4XfqajorAqrDd40gvq8KpYR6jDpIwBSIck716540SjXE5WUkPu96n3iZZXMysk$>.
The idea is to do everything inside of QUIC: Imagine two p2p nodes first
establishing a proxied connection via a relay (immediately starting to exchange
application data), and the QUIC stack migrating this connection towards a direct path
between the two nodes in the background.
It turns out that there are just a few missing pieces:
1. We can use the listener extension to CONNECT-UDP
(https://datatracker.ietf.org/doc/draft-schinazi-connect-udp-listen/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-schinazi-connect-udp-listen/__;!!Bt8RZUm9aw!6W2t_dQMHs1tiFalSAENp4XfqajorAqrDd40gvq8KpYR6jDpIwBSIck716540SjXE5WUkPu96n3iYAYMoIo$>)
to enable relaying between peers that don't have a direct connection (yet), and for
peers where NAT traversal fails (thereby replacing what traditionally a TURN server
would've been deployed for).
2. It is trivial to perform address discovery inside of QUIC (replacing STUN):
https://datatracker.ietf.org/doc/draft-seemann-quic-address-discovery/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-seemann-quic-address-discovery/__;!!Bt8RZUm9aw!6W2t_dQMHs1tiFalSAENp4XfqajorAqrDd40gvq8KpYR6jDpIwBSIck716540SjXE5WUkPu96n3ivL1LLoU$>
3. Finally, we can use QUIC's path migration logic to establish the NAT bindings
("hole punching") required for a direct connection between two nodes. We just need to
allow the server to initiate paths, and coordinate hole punching attempts:
https://datatracker.ietf.org/doc/draft-seemann-quic-nat-traversal/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-seemann-quic-nat-traversal/__;!!Bt8RZUm9aw!6W2t_dQMHs1tiFalSAENp4XfqajorAqrDd40gvq8KpYR6jDpIwBSIck716540SjXE5WUkPu96n3i-DsCx80$>
In terms of maturity, the address discovery draft has gone through a couple of
revisions since we last discussed it in the QUIC WG in Prague, and is now
implemented by multiple QUIC stacks. The NAT traversal draft needs a bit more
work.
While these drafts were all presented individually, we haven’t talked a lot
about how they fit into the bigger picture before presenting the vision in our
blog post. We would love to get feedback from the working groups, and help to
drive the drafts to publication.
-- Marten
