Re: QUIC Address Extension for NAT detection

[Kazuho Oku <[e-mail]>]

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).

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.

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