Re: QUIC Address Extension for NAT detection

[Tommy Pauly <[e-mail]>]

Hi Patrick,

Interesting! Glad we're thinking along similar lines.

The extension for TLS, similar to what you mention, only allows the client side to request its own public IP address from the server's perspective. Since this is the model that would be used for HTTP/2 and similar protocols, it ends up being pretty similar. We're definitely interested in seeing this mechanism be used for TLS connections beyond HTTP/2, for example in something like DNS-over-TLS connections. Is there any reason you see to have the mechanism in HTTP/2 as opposed to one layer down in TLS?

Thanks,
Tommy

> On Mar 20, 2019, at 7:25 AM, Patrick McManus <[e-mail]> wrote:
> 
> 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] <mailto:40apple.com@dmarc..ietf.org>> 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/ <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/ <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