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

[Martin Thomson <[e-mail]>]

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