Re: QUIC Address Extension for NAT detection

[Ryan Hamilton <[e-mail]>]

On Wed, Mar 13, 2019 at 12:36 PM Christian Huitema <[e-mail]>
wrote:

>
> On 3/13/2019 9:19 AM, Tommy Pauly wrote:
> > We recently posted a draft that defines a proposed extension to QUIC
> > that allows peers to request their perceived IP address and port from
> > their peer, effectively allowing NAT detection along a path:
> >
> > QUIC Address Extension
> > https://datatracker.ietf.org/doc/draft-pauly-quic-address-extension/
> >
> > We have posted a corresponding document in TLS that provides the same
> > mechanism for TLS/TCP connections:
> >
> > TLS Client Network Address Extension
> > https://datatracker.ietf.org/doc/draft-kinnear-tls-client-net-address/
> >
> > One of the benefits specific to QUIC from detecting a NAT is that it
> > helps determine whether or not NAT rebindings are expected to create
> > “fake” migration events. It also helps a client know whether or not
> > rotating CIDs and local ports will be of use to obfuscate a client’s
> > connections.
> >
> > If you have any thoughts on use cases for this information, or the
> > mechanism, we’d love to hear them!
>
>
> I think the extension would be useful in many scenarios.


Agreed! We've run a number of experiments in Google QUIC over the years
which could have used this mechanism if it had existed. (Instead we
communicated this info in a fairly ad-hoc manner)