Re: Using QUIC to traverse NATs

[David Schinazi <[e-mail]>]

Overall this sounds like it could be useful for P2P QUIC, though the
presence of multiple modes sounds like the use-cases haven't been fleshed
out enough. What's the goal here?

Also, for this to work P2P, we'd need QUIC server migration since preferred
address doesn't let you try a list of ICE candidates. That or pull out the
multipath hammer.

FWIW, Tommy Chris and Eric had written up the address signaling part up one
pandemic ago:
https://datatracker.ietf.org/doc/draft-pauly-quic-address-extension/

David

On Tue, Jul 18, 2023 at 9:34 AM Christian Huitema <[e-mail]>
wrote:

> I think that adding a Stun function to QUIC is very straightforward: add a
> frame "i see you from this address", have peers send it in connection
> responses or with path responses. That goes very well with the multipath
> extensions.
>
> Adding an address announce frame to Quic is also straightforward. It is
> also very useful in multipath operations: "you can contact me at this
> alternate address".
>
> After that, the missing part for ICE is the bidirectional probe. We can
> debate which is more complex, adding the function to Quic or coordinating
> ICE and Quic.
>
> -- Christian Huitema
>
> > On Jul 18, 2023, at 8:37 AM, Joerg Ott <[e-mail]> wrote:
> >
> > Hi Marten,
> >
> > good writeup, thanks much; I am with Dan that the geenral direction
> > makes sense.  (We've been looking at the interaction with ICE for RTP-
> > over-QUIC).
> >
> > One bit I always struggle with ICE when using it together with a
> > powerful transport is not the initial setup but the subsequent
> > operation.
> >
> > When two ICE agents negotiate some addresses (and possibly do their path
> > probing), they will then hand over the transport addresses to be used
> > for the QUIC connection.  At this point, the state within ICE and the
> > state within QUIC agree.
> >
> > There are reasons for QUIC to update address information (take a NAT
> > rebinding or a preferred server address), but those won't necessarily
> > be propagated back to the ICE state machine, so the states start to
> > diverge.
> >
> > If you use ICE with plain old UDP, it'd be up to ICE to discover
> > changes and reconfigure address pairs, including probing.
> >
> > This doesn't have to be a issue but it may be useful to document how
> > ICE and QUIC are supposed to interact for error conditions and address
> > changes.
> >
> > Cheers,
> > Jörg
> >
> >> On 11.07.23 07: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/ <
> 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
> >
>
>