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

[ianswett <[e-mail]>]

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