Re: QUIC Address Extension for NAT detection

[Patrick McManus <[e-mail]>]

My thinking was that this is information that the HTTP layer is going to
act on.. by adjusting its timeout, parallel connection, and/or ping
strategy accordingly.. so as a practical matter if it gets implemented in a
differently layer you need both an interface for passing that data around
and you need to manage two more dependencies (1] your own software deps add
a TLS dependency for something that isn't really about transport security,
and 2] you now require 1.3 on both peers which might be a change
disproportionate to the value here).. we've seen tls-lib dependencies
really slow down adoption cycles in the past.

but it could totally work.

My thinking is this is really a transport property of quic, but we could
get some more immediate experience with it (as well as parity) as a trivial
h2 extension.


On Wed, Mar 20, 2019 at 11:34 AM Tommy Pauly <[e-mail]> wrote:

> 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] <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/
>>
>> 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
>>
>
>