Re: [quicwg/base-drafts] Spin bit should be applied per each 5-tuple rather than per connection (#1828)

[Brian Trammell <[e-mail]>]

I tend to agree with @ianswett here -- while different CIDs may often represent connections between the same processes (and therefore with similar e2e delays at a given instant in time), this is not guaranteed to be the case. Is per-CID spin a useful passive measurement signal in the general case, though?

Stepping back, there seem to be two broad usage patterns with partially conflicting requirements here:

- possibly-mobile client with load-balanced server. Here the server proposes non-zero-length CIDs, and the client proposes a zero-length CID. The client will generally not use one server CID at a time. Since the CID reserve a client has exists to attempt to reduce address linkability on a rebinding event, the spin state should not be shared across CIDs -- this language has been in spin-exp since London (*)

- client-server connection using CID multiplexing. In this case, both client and server CIDs must be in use, though the CID size does not necessarily need to be the same in each direction. Migration linkability mitigation is harder in this case, and it's not clear to me that it's even a requirement. Here, per-5-tuple-spin would be possible. (note that in this case the server also has to keep CID-2-tuples around, so @ianswett's point that per-CID is hard on the server does not apply here)

Per-5-tuple spin is clearly more useful to the path -- otherwise, on-path devices has to use heuristics to guess the CID (node, this is not very hard if it has a few packets, but it needs to keep a header buffer up to max CID length until it locks on, and it can use heuristics about well-known servers/CDNs/configurations to make an initial guess that will be correct almost all of the time -- in any case, any on-path measurement device offering RTT information will also probably offer flow information). But it seems impossible to do for those cases where we care about reducing spin state contribution to rebinding linkability.

* as I've pointed out at many times in the past, rebinding linkability reduction still seems to rely on incredibly wishful thinking to me, and I'd really like to see some data on the anonymity set sizes for rebindings in the temporal domain. Even in the case that linkability reduction has a practical benefit, spin state adds a tiny fraction of a bit of information, so blanking spin state on CID change is of vanishingly small benefit. However, it is consistent with the rest of the protocol's design, and I'm still willing to pretend it's a useful exercise, because there seems to be broad consensus that we believe in it.


-- 
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/1828#issuecomment-436938812