Re: QUIC Address Extension for NAT detection

[Patrick McManus <[e-mail]>]

Coincidentally I have been noodling with an almost identical idea (though I
was only going to allow the client side to request its own IP as seen by
the peer) for prototyping in h2 with an eye towards quic if it proved
useful.

Would it be easiest to start it there (and would you be interested in
implementing it there?) as that framework already has wide deployment and a
sorta-exercised extension mechanism that seems like it should work with
minimal disruption to test out if the information is indeed useful.

I agree that ideally this is a transport function but I wouldn't let that
stand in the way of getting some experience.



On Wed, Mar 13, 2019 at 12:19 PM 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
>