Subject: [quicwg/base-drafts] IP restrictions on Tokens makes them of limited use for non-anycast DNS load balancing (#4076)

From: ianswett <[email-masked]>
Date: Mon, 07 Sep 2020 14:03:37 -0700

PR #3996 adds a new normative restriction on when tokens received in NEW_TOKEN can be used:

"Therefore, clients SHOULD NOT send a token received in a NEW_TOKEN frame from
one server address in an Initial packet that is sent to a different server
address.  As strict equality might reduce the utility of this mechanism, clients
MAY employ heuristics that result in different server addresses being treated
as equivalent, such as treating addresses with a shared prefix of sufficient
length as being functionally equivalent (for instance, /24 in IPv4 or /56 in
IPv6). In addition, clients SHOULD treat a preferred address that is
successfully validated as equivalent to the address on which the connection was
made; see {{preferred-address}}."

I believe this will greatly reduce the practical value of 0-RTT, since most responses cannot fit into 2 packets(assuming 1 to complete the handshake) and unless Anycast is used for load balancing, it's extremely common for the IPs not to match and quite common for them not to share a /24 or /56.

>From local testing, when I resolved www.google.com twice in a row a second apart, I got 172.217.6.196 and 172.217.12.164.
I can follow up with some numbers on how frequently this occurs today in existing deployments if that's useful?

Also, from an editorial perspective, I also don't think this normative statement should only be in security considerations, since I believe it's more likely to be missed there.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4076

---

From: ianswett <[email-masked]>
Date: Mon, 07 Sep 2020 17:43:47 -0700

On the email thread, I suggested changing the restriction to something like "MUST NOT use tokens from one RFC address space in a different one.", but @martinthomson said that people setup vulnerable servers on public internet addresses.

The key to SSRF is that one peer has a privilege that the other peer does not, but if it's a public address, couldn't either peer send traffic to the address without any clever use of another QUIC peer?  Address spoofing isn't trivial, but it's certainly possible in some cases, so anyone only relying on peer IP address would already be vulnerable, so I'm not grasping how QUIC is making this worse for public IPs.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4076#issuecomment-688556968

---

From: Martin Thomson <[email-masked]>
Date: Mon, 07 Sep 2020 20:26:41 -0700

No guaranteed.  I used to work at an office that had a firewall and a VPN.  There were a bunch of unprotected server behind that firewall.  Most, if not all, of those servers used addresses from public address space.  This is likely not common practice any more (addresses are expensive), but it is also not completely unexpected.

To give an example, one thing you might consider is that you have a subnet (x::/56 say) where servers all operate public addresses and operate services that are accessible on the public Internet.  However, that network also has a bypass for authentication checks if the source address of a request is in the x::/56 subnet to enable cross-traffic between services without overheads.  This might be consider acceptable if you also assume that ingress filtering is in use for the network.

I need to stress again how much I think that this sort of thing is monumentally inadvisable.  On the other hand, if we're looking for hypotheticals (in the absence of actual cases), then these are at least plausible cases to consider.

That said, I definitely agree that this restriction is not great and it probably is too much.  I don't know how to generate a heuristic that can capture a change of the magnitude you identify.  Google is lucky to have addresses that are contiguous at ~/20; I imagine that other servers have to work with a larger spread.  (BTW, I get 142.250.66.228)

After considering this, if we are not going to implement more rigorous protections for other aspects of this (migration spoofing), then it seems reasonable to allow this reuse and accept the risk.  That means relying on the generic protections more for this case also, which already talk about moving from public space to link-local/site-local/private spaces.  We might even just rely solely on those protections.

(The editorial note is well-taken; we can fix that.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4076#issuecomment-688596190

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 10 Sep 2020 22:46:32 -0700

Closed #4076 via #4089.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4076#event-3754435817

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Sep 2020 15:30:52 -0700

Reopened #4076.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4076#event-3770565930

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Sep 2020 15:31:05 -0700

Reopening so that we can get this into our processes.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4076#issuecomment-693013750

---

From: Lars Eggert <[email-masked]>
Date: Thu, 24 Sep 2020 05:44:58 -0700

Closing this now that WGLC has finished. #4089 was already merged.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4076#issuecomment-698320437

---

From: Lars Eggert <[email-masked]>
Date: Thu, 24 Sep 2020 05:44:58 -0700

Closed #4076.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4076#event-3803026908