Re: QUIC Address Extension for NAT detection

[Tommy Pauly <[e-mail]>]

> On Mar 13, 2019, at 9:54 AM, Mikkel Fahnøe Jørgensen <[e-mail]> wrote:
> 
> How does that work when you are behind multiple layers of translations, which isn’t that unusual in a cloud environment:
> Client has a nat router at home, cloud has public to private IP mappings.

NAT detection, as already works in protocols like IKE, generally just detects that there is either something translating your address/ports or not. So, each direction can detect that there is >=1 translations, but not how many.

> 
> Also, this information could provide information about cloud infrastructure that maybe best stays local - not sure about implications. But a standard web framework terminating QUIC might have no idea about the surrounding infrastructure and volunteer more information that the cloud infrastructure wants to.

Can you explain the concern around cloud infrastructure? If a server is running in a cloud service, this extension has it send the *client's* address back to the client so that the client can detect if it is itself behind a NAT. No peer sends their own local address to the other side at any point.

Best,
Tommy

> 
> 
> Kind Regards,
> Mikkel Fahnøe Jørgensen
> 
> 
> On 13 March 2019 at 17.20.02, Tommy Pauly (tpauly=[e-mail] <mailto: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/ <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