Re: QUIC Address Extension for NAT detection

[Christian Huitema <[e-mail]>]

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. My comment is
mostly editorial: please don't use the name "public address". There is a
long history behind that, starting with the early work on STUN. If you
look at the recent versions of STUN, ICE or TURN, they use the term
"reflected address" to indicate the address provided by the STUN server.

This points to the layer of NATs discussion, and also the network model.
When there are layers of NATs, it is conceivable that some servers will
be reached through just one layer, and other through several. In
general, there reflected address may vary as a function of the path
between client and server. Trying to model that with just "one global
address" does not work.

-- Christian Huitema