Subject: QUIC Address Extension for NAT detection

From: Tommy Pauly <[email-masked]>
Date: Wed, 13 Mar 2019 09:19:38 -0700

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

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Wed, 13 Mar 2019 09:54:10 -0700

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.

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.

Kind Regards,
Mikkel Fahnøe Jørgensen

On 13 March 2019 at 17.20.02, Tommy Pauly (tpauly=[email-masked])
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/

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

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 13 Mar 2019 10:31:34 -0700

> On Mar 13, 2019, at 9:54 AM, Mikkel Fahnøe Jørgensen <[email-masked]> wrote:
> 
> How does that work when you are behind multiple layers of translations, which isn’t that unusual in a cloud environment:

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=[email-masked] <mailto:tpauly=[email-masked]>) wrote:
>

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Wed, 13 Mar 2019 10:39:51 -0700

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.

I’m not sure how useful the information is, but if the cloud runs on a
10.10.1x.xx network, for example via Docker bridges, the clients address
will likely be translated to something also on the 10.10.1x.xx network. An
attacker that by other means has gained packet injection capabilities could
use this information to guess other client addresses and do something evil.
Or, it may just reveal some details about the infrastructure such as likely
vendor equipment etc.

---

From: Erik Kline <[email-masked]>
Date: Wed, 13 Mar 2019 10:57:27 -0700

Instead of "client sends {}, server responds with {client addr info}", why
not just make it bidirectional and the presence in either direction is
taken as a request to the receiving peer to respond in kind?

This would be more like "client sends {server addr info}, server responds
with {client addr info}".  It might be useful for observing things like
networks playing games with DNS?  IDK...

---

From: Christian Huitema <[email-masked]>
Date: Wed, 13 Mar 2019 12:36:00 -0700

On 3/13/2019 9:19 AM, Tommy Pauly 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
> 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.
>

I think the extension would be useful in many scenarios. My comment is
mostly editorial: please don't use the name "public address". There is a
long history behind that, starting with the early work on STUN. If you
look at the recent versions of STUN, ICE or TURN, they use the term
"reflected address" to indicate the address provided by the STUN server.

This points to the layer of NATs discussion, and also the network model.
When there are layers of NATs, it is conceivable that some servers will
be reached through just one layer, and other through several. In
general, there reflected address may vary as a function of the path
between client and server. Trying to model that with just "one global
address" does not work.

-- Christian Huitema

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 13 Mar 2019 16:34:55 -0400

On Thu, Mar 14, 2019, at 04:57, Erik Kline wrote:
> Instead of "client sends {}, server responds with {client addr info}", 
> why not just make it bidirectional and the presence in either direction 
> is taken as a request to the receiving peer to respond in kind?

Looping might be a reason not to have the signal be symmetric.

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 13 Mar 2019 13:42:52 -0700

On Wed, Mar 13, 2019 at 12:36 PM Christian Huitema <[email-masked]>
wrote:

> I think the extension would be useful in many scenarios.

Agreed! We've run a number of experiments in Google QUIC over the years
which could have used this mechanism if it had existed. (Instead we
communicated this info in a fairly ad-hoc manner)

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 14 Mar 2019 07:04:12 +0900

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.

-- 
Kazuho Oku

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 13 Mar 2019 15:20:06 -0700

> On Mar 13, 2019, at 3:04 PM, Kazuho Oku <[email-masked]> wrote:
> 

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.

> 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

---

From: Mike Bishop <[email-masked]>
Date: Wed, 13 Mar 2019 22:27:14 +0000

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 <[email-masked]> On Behalf Of Tommy Pauly
Sent: Wednesday, March 13, 2019 3:20 PM
To: Kazuho Oku <[email-masked]>
Cc: QUIC WG <[email-masked]>; Eric Kinnear <[email-masked]>; Chris Wood <[email-masked]>
Subject: Re: QUIC Address Extension for NAT detection

Thans,
Tommy

---

From: Christian Huitema <[email-masked]>
Date: Wed, 13 Mar 2019 15:36:19 -0700

> On Mar 13, 2019, at 3:27 PM, Mike Bishop <[email-masked]> wrote:
> 

The address validation procedures already almost have an implicit requirement that servers know the client address, since the NEW TOKEN is supposedly per address. But yes, I assume it is not strictly required. In which case the server should either not negotiate the extension, or answer "I don't know", maybe with an all null address.

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 14 Mar 2019 07:46:23 +0900

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

-- 
Kazuho Oku

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 14 Mar 2019 07:53:59 +0900

> I correct?), then the server can see if the client has returned by

Please discard my comment. The client sends the server's address. I
think I'm still asleep.

-- 
Kazuho Oku

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 13 Mar 2019 20:32:59 -0400

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

A server in this situation could refuse to support the extension.
 
> The address validation procedures already almost have an implicit 
> requirement that servers know the client address, since the NEW TOKEN 
> is supposedly per address. But yes, I assume it is not strictly 
> required. In which case the server should either not negotiate the 
> extension, or answer "I don't know", maybe with an all null address.

Address validation can still work in a context like this.  Maybe the load balancer terminates IPv4 and maps the connection onto an IPv6 address that the ultimate server sees as the client address.  I would still rather hold to the assumption anyway.  I suspect that not negotiating would be easier than the additional complexity of an "I don't know" message.

---

From: Roberto Peon <[email-masked]>
Date: Thu, 14 Mar 2019 17:10:45 +0000

More succinctly:
This can expose IPs behind NATs.

Honestly, I'd balk at that.
-=R

On 3/13/19, 5:59 PM, "QUIC on behalf of Mike Bishop" <[email-masked] on behalf of [email-masked]> wrote:

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

    

    
    
    Thans,
    Tommy
    
    >> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dpauly-2Dquic-2Daddress-2Dextension_&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=kbdeKTH7BVfD-Cw5yTzStNazxTXRMfPRe3QRdBXBHyE&s=iR4iXVZ3Ek-ORAm3u1Cyw4rCkpe5Ak4mTw8GzMt9I70&e=
    >> 
    >> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dkinnear-2Dtls-2Dclient-2Dnet-2Daddress&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=kbdeKTH7BVfD-Cw5yTzStNazxTXRMfPRe3QRdBXBHyE&s=2cqPmG4Zyvf_1DXkcSf9plq8bSxUq-cncVnwLuVAzNI&e=
    >> /
    >>

---

From: Christopher Wood <[email-masked]>
Date: Thu, 14 Mar 2019 10:19:40 -0700

> Honestly, I'd balk at that.

Can you say more?

Thanks,
Chris

---

From: Roberto Peon <[email-masked]>
Date: Thu, 14 Mar 2019 17:35:41 +0000

There are two questions that can be asked:
  1) PeerA asks PeerB: What is PeerA's address?
  2) PeerA asks PeerB: What is PeerB's address?

#1 It can potentially expose that PeerB is internally NAT'd (PeerA's IP as stated by B is different than what PeerA knows Peer A's IP should be)
#2 It can potentially expose that PeerB is internally NAT'd (PeerB's IP as stated by B is different than what PeerA knows Peer B's IP should be)

There should be some overriding benefit that overrides the increased risk of such exposures  (understanding parts of the internal structure of other networks) unless we believe that such exposures are going to happen anyway. 

We have L7 mechanisms for doing things like this today (have an endpoint to which the server can reply with the perceived IP) which is potentially preferable as this gives the applications say (servers don't have to expose such endpoints) in whether such leaks are a good or poor tradeoff.
-=R

On 3/14/19, 10:19 AM, "Christopher Wood" <[email-masked]> wrote:

    Can you say more?
    
    Thanks,
    Chris

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 14 Mar 2019 10:44:42 -0700

> On Mar 14, 2019, at 10:35 AM, Roberto Peon <[email-masked]> wrote:
> 

Please note that PeerA cannot ask PeerB for PeerB's address. That is not allowed in our proposal. Only publicly perceived addresses are ever sent, no private addresses behind NATs.

Thanks,
Tommy

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 14 Mar 2019 10:47:14 -0700

> On Mar 13, 2019, at 5:32 PM, Martin Thomson <[email-masked]> wrote:
> 

Yes, I agree that the simplest solution to the concern about a server that's deployed in a scenario in which it is not seeing public client addresses, but translated ones that may not be appropriate to report, is to simply have these servers not negotiate support for this option. From their perspective, they're just saying "sorry, I can't help you". An additional message for "I don't know" would be redundant with that.

If the deployment is such that the server in this situation could know, via a channel with the load balancer for example, what the original public client address and port are, then it could just send those.

Best,
Tommy

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Thu, 14 Mar 2019 12:48:52 -0500

Please note that PeerA cannot ask PeerB for PeerB's address. That is not
allowed in our proposal. Only publicly perceived addresses are ever sent,
no private addresses behind NATs.

Thats not true if there is NAT mapping close to peerB for inbound traffic.
In that case you reveal details about the deployment.

Also the deployment cannot control this information leakage because it
might be a random application library with a local QUIC implementation that
is just configured default to respond.

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 14 Mar 2019 10:54:20 -0700

> On Mar 14, 2019, at 10:48 AM, Mikkel Fahnøe Jørgensen <[email-masked]> wrote:
> 
>> 
> Thats not true if there is NAT mapping close to peerB for inbound traffic. In that case you reveal details about the deployment.
> 
> Also the deployment cannot control this information leakage because it might be a random application library with a local QUIC implementation that is just configured default to respond.
> 
> 

If the deployment is aware of this setup, it can and should disable the extension if it does not want to potentially reveal interior addresses that it is translating; or, coordinate with the load balancer to send the real client public address.

I find the argument a bit weak that this is an issue for deployments that cannot control what application libraries do: nothing prevents those same servers from leaking this information today to clients over any number of application-protocol mechanisms. If the deployment wants to translate public client IP addresses into its own internal addresses that are considered sensitive and private, and thus not to be shared outside the network, it should have some way to validate or trust the application code running within the deployment. Rogue applications could leak quite a lot in this scenario.

Thanks,
Tommy

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Thu, 14 Mar 2019 10:58:21 -0700

If the deployment is aware of this setup, it can and should disable the
extension if it does not want to potentially reveal interior addresses that
it is translating; or, coordinate with the load balancer to send the real
client public address.

I find the argument a bit weak that this is an issue for deployments that
cannot control what application libraries do: nothing prevents those same
servers from leaking this information today to clients over any number of
application-protocol mechanisms.

That is correct, but no random NodeJS, PHP, Go, Ruby, Python TCP library
would normally do that unless the application explicitly wants that to
happen.

If this extension is default in such libraries for QUIC, it would leak by
default.

It is not so much about rogue application - it you have those, good luck
anyway.

---

From: Patrick McManus <[email-masked]>
Date: Wed, 20 Mar 2019 10:25:59 -0400

Coincidentally I have been noodling with an almost identical idea (though I
was only going to allow the client side to request its own IP as seen by
the peer) for prototyping in h2 with an eye towards quic if it proved
useful.

Would it be easiest to start it there (and would you be interested in
implementing it there?) as that framework already has wide deployment and a
sorta-exercised extension mechanism that seems like it should work with
minimal disruption to test out if the information is indeed useful.

I agree that ideally this is a transport function but I wouldn't let that
stand in the way of getting some experience.

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 20 Mar 2019 08:34:34 -0700

Hi Patrick,

Interesting! Glad we're thinking along similar lines.

The extension for TLS, similar to what you mention, only allows the client side to request its own public IP address from the server's perspective. Since this is the model that would be used for HTTP/2 and similar protocols, it ends up being pretty similar. We're definitely interested in seeing this mechanism be used for TLS connections beyond HTTP/2, for example in something like DNS-over-TLS connections. Is there any reason you see to have the mechanism in HTTP/2 as opposed to one layer down in TLS?

Thanks,
Tommy

> On Mar 20, 2019, at 7:25 AM, Patrick McManus <[email-masked]> wrote:
> 
> Coincidentally I have been noodling with an almost identical idea (though I was only going to allow the client side to request its own IP as seen by the peer) for prototyping in h2 with an eye towards quic if it proved useful.
> 
> Would it be easiest to start it there (and would you be interested in implementing it there?) as that framework already has wide deployment and a sorta-exercised extension mechanism that seems like it should work with minimal disruption to test out if the information is indeed useful.
> 
> I agree that ideally this is a transport function but I wouldn't let that stand in the way of getting some experience.
> 
> 
> 
> On Wed, Mar 13, 2019 at 12:19 PM Tommy Pauly <tpauly=[email-masked] <mailto:40apple.com@dmarc..ietf.org>> wrote:

---

From: Patrick McManus <[email-masked]>
Date: Thu, 21 Mar 2019 11:22:20 -0400

My thinking was that this is information that the HTTP layer is going to
act on.. by adjusting its timeout, parallel connection, and/or ping
strategy accordingly.. so as a practical matter if it gets implemented in a
differently layer you need both an interface for passing that data around
and you need to manage two more dependencies (1] your own software deps add
a TLS dependency for something that isn't really about transport security,
and 2] you now require 1.3 on both peers which might be a change
disproportionate to the value here).. we've seen tls-lib dependencies
really slow down adoption cycles in the past.

but it could totally work.

My thinking is this is really a transport property of quic, but we could
get some more immediate experience with it (as well as parity) as a trivial
h2 extension.

On Wed, Mar 20, 2019 at 11:34 AM Tommy Pauly <[email-masked]> wrote:

> The extension for TLS, similar to what you mention, only allows the client
> side to request its own public IP address from the server's perspective.
> Since this is the model that would be used for HTTP/2 and similar
> protocols, it ends up being pretty similar. We're definitely interested in
> seeing this mechanism be used for TLS connections beyond HTTP/2, for
> example in something like DNS-over-TLS connections. Is there any reason you
> see to have the mechanism in HTTP/2 as opposed to one layer down in TLS?
>
> Thanks,
> Tommy
>
> Coincidentally I have been noodling with an almost identical idea (though
> I was only going to allow the client side to request its own IP as seen by
> [email-masked] <40apple.com@dmarc..ietf.org>> wrote:
>
>> helps determine whether or not NAT rebindings are expected to create “fake”