Re: QUIC Address Extension for NAT detection

[Kazuho Oku <[e-mail]>]

2019年3月14日(木) 7:46 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.

Please discard my comment. The client sends the server's address. I
think I'm still asleep.
>
> > 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



-- 
Kazuho Oku