Re: QUIC Address Extension for NAT detection

[Kazuho Oku <[e-mail]>]

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

I was concerned about the server asking the address of the client
which might be running behind an VPN or something.

Assume a client having an IPv6 address, occasionally connects to
example.com through a VPN.

Without the extension, the server cannot tell if the client is the one
that has visited previously or not, because the client tuple that the
server observes changes between connections.

However, if the server could obtain the client's true IP address
(that's what the _QUIC version_ of the I-D allows, am
I correct?), then the server can see if the client has returned by
checking the value.

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


-- 
Kazuho Oku