RE: QUIC Address Extension for NAT detection

[Mike Bishop <[e-mail]>]

If I'm understanding correctly, the concern is about the server running inside a private infrastructure such that it never sees the client's public IP, but instead an IP belonging to the inner edge of its load balancer.  To echo back the "client IP" in this deployment scenario would expose the server's deployment details to clients.

I'm unsure how common such deployments are.

-----Original Message-----
From: QUIC <[e-mail]> On Behalf Of Tommy Pauly
Sent: Wednesday, March 13, 2019 3:20 PM
To: Kazuho Oku <[e-mail]>
Cc: QUIC WG <[e-mail]>; Eric Kinnear <[e-mail]>; Chris Wood <[e-mail]>
Subject: Re: QUIC Address Extension for NAT detection



> On Mar 13, 2019, at 3:04 PM, Kazuho Oku <[e-mail]> wrote:
> 
> I like the idea of communicating the address, I agree that it would be 
> useful for QUIC in general to detect NATs.
> 
> OTOH I am bit concerned of the privacy implications of a server asking 
> the client it's IP address. Because it could be considered as a 
> private information, when the client is running behind a NAT (or a 
> VPN, or something like Tor).

To clarify, you are concerned about the server asking the client to send what the server's address is? The protocol only lets the an endpoint request its own public address. The security concerns section points this out:

Moreover, since endpoints can only request their public
   address, peers cannot accidentally transmit their (possibly private)
   address to a peer.

> 
> Considering that, it might be a good idea to make the protocol 
> asymmetric; i.e. design the frames so that the server sends the 
> perceived address of the client and then the client responds with a 
> boolean indicating if the perceived address is the actual address.

Yes, as something further than the existing mechanism, we could have replies indicate if a client thinks it is behind a NAT based on the result of the exchange.

Thans,
Tommy

> 
> 2019年3月14日(木) 1:20 Tommy Pauly <tpauly=[e-mail]>:
>> 
>> 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
> 
> 
> 
> --
> Kazuho Oku