Re: Using QUIC to traverse NATs

[Marten Seemann <[e-mail]>]

Thanks for all the feedback! I'll address multiple points made in the
thread so far.

Multipath:
I'd like this extension to work well with QUIC Multipath, and I don't see
anything that would prevent that. However, I don't think it needs anything
multipath-specific, and can run on top of a RFC 9000 stack just as well.
In specific:

   1. RFC 9000 already allows a client to simultaneously probe an
   arbitrary number of paths, and to keep them alive (by sending probing
   packets). The only thing that multipath adds here is the capability to send
   / receive on multiple paths at the same time, but a NAT won't even be able
   to distinguish between these scenarios.
   2. Multipath doesn't allow the server to initiate a new path: as in RFC
   9000, path initiation is solely the client's responsibility. A NAT
   traversal solution will need to define a way for the server to send a hole
   punching packet either way.

Who's initiating the migration:
When we designed QUIC, we concluded that server-initiated migration creates
a lot of corner cases, especially around the simultaneous initiation of new
paths. It might also open up new attack scenarios. The draft therefore
doesn't change that logic: All probing of new paths is driven by the
client. That’s why we need to sure that the the QUIC client's ACE agent
ends up being the controlling agent (it is my understanding that the
controlling agent is responsible for the probing of new paths).
That being said, the draft should probably go into more detail regarding
NAT rebindings that might happen on the server's NAT.

QUIC Address Extension:
This seems useful for nodes that don’t need to rely on ICE for their
address discovery, e.g. p2p applications that are running continuously.
They cut then piggy-back address discovery on top of connections they’re
establishing anyways. In fact, I have deployed something very similar, with
the address requests happening at the application layer.

Who’s responsible for path selection?
Martin is making a good point here (and wrote a really interesting ICE /
DTLS draft 10 years ago, thank you for sharing!). In mode 1, I’d imagine
that ICE runs to completion before the QUIC handshake starts, so it would
be ICE’s responsibility to select the path. In mode 3, it makes sense to
have the QUIC layer decide which of the paths to use, as it probably knows
more about the application’s needs than ICE.


On Tue, 18 Jul 2023 at 18:55, Martin Thomson <[e-mail]> wrote:

> Hi Marten,
>
> I did a little thinking about this problem a fair while back, see
> https://datatracker.ietf.org/doc/html/draft-thomson-rtcweb-ice-dtls-00
>
> That's closer in truth to your mode 3.  That is, it collapses the
> protocols.  And of course there are properties of DTLS that ensure that
> this is less than ideal, whereas QUIC might be better suited to the sorts
> of tweaks that connectivity checking demands.
>
> In particular, it is worth thinking about carefully here is how much
> QUIC's path validation logic is duplicative of parts of ICE and whether
> that is overhead that can be saved.
>
> As for the non-collapsed versions, you might need to be clearer about
> which part of the stack is responsible for path selection.  In mode 1, this
> is not particularly clear.  If you think of classic ICE, you essentially
> have ICE being responsible for path selection (especially with the
> continuous ICE versions) and the flow that you initiate on top of it is
> ignorant of path changes.  That will interact somewhat poorly with a
> protocol like QUIC that expects to be more involved in that process.  It's
> worse in mode 2, which might be quite confusing with the two layers
> interacting as they do.  That could stand to be made much clearer.
>
> Cheers,
> theonewithan"i"
>
> On Mon, Jul 10, 2023, at 22:20, Marten Seemann wrote:
> > I just submitted a new draft that describes how to do NAT traversal
> using QUIC:
> > https://datatracker.ietf.org/doc/draft-seemann-quic-nat-traversal/
> >
> > The document defines 3 distinct modes. The first mode is the simplest
> > one, first running ICE to completion to find a suitable path between
> > two nodes, and then establishing a QUIC connection on that path.
> > The other two modes use a proxied QUIC connection to do the ICE
> > signaling (potentially using one of the protocols defined by the MASQUE
> > WG), and then make use of QUIC connection migration to migrate to a
> > better / direct path.
> >
> > This is an early draft version, and I wouldn’t be surprised if it
> > wasn’t actually implementable, most likely due to my limited
> > familiarity with ICE. I’d appreciate feedback if the general direction
> > makes sense.
> >
> > Cheers,
> > Marten
>
>