Re: QUIC Address Extension for NAT detection

[Erik Kline <[e-mail]>]

Instead of "client sends {}, server responds with {client addr info}", why
not just make it bidirectional and the presence in either direction is
taken as a request to the receiving peer to respond in kind?

This would be more like "client sends {server addr info}, server responds
with {client addr info}".  It might be useful for observing things like
networks playing games with DNS?  IDK...

On Wed, 13 Mar 2019 at 09:19, Tommy Pauly <tpauly=[e-mail]>
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!
>
> Best,
> Tommy
>