4 ms·

The spin bit reminds me of the evil bit[1]. Endpoints/clients/servers don't have much reason to set it, except when explicitly running a trace. It may work un

by mey 7y ago

The spin bit reminds me of the evil bit[1]. Endpoints/clients/servers don't have much reason to set it, except when explicitly running a trace. It may work under initial implementations, but I expect it will eventually become a dead field. Why maintain the code complexity to expose this information to a network operator? Even worse, "malicious" clients could spin the bit randomly. [1] https://en.m.wikipedia.org/wiki/Evil_bit https://en.m.wikipedia.org/wiki/Evil_bit

cesarb 7y ago
> but I expect it will eventually become a dead field. I hope that's all that happens. My worry is that middleboxes will start to depend on it, and any implementation which doesn't spin it "correctly" (where "correctly" is defined by the middlebox vendor, not the standard) will be blocked.
- unilynx 7y ago
  There isn't much they can do about it? All they can do is corrupt or block the packet, which looks to the end user like high packet loss on random connections... earning that router type a reputation for being very slow and pushing it out of he market.
  - silotis 7y ago
    The average user doesn't have the level of visibility into the system to know that the middlebox is the one causing the problem. Instead whatever changed last gets the blame, regardless of what's actually at fault. So if a user's existing applications set the spin bit "correctly" and a new application does not, the new application will be judged as buggy, not the middlebox which has been working fine until now.
- tialaramex 7y ago
  Depend on it to do /what/ though? Middleboxes can equally well insist upon tampering with other data they can't interpret in QUIC, and that too just causes the packets to be discarded. To what end? Middleboxes aren't actively malevolent they're just built by idiots. Our experience has been that middlebox vendors _ossify_ things. They see a field that's defined "Zero: Reserved for future use" and they say "Aha, that's supposed to be zero" and so now that "future use" can never happen. For example the Certificate in TLS 1.2 and earlier isn't intended to be useful to anyone except the TLS Client. But middleboxes interpret it anyway, they insist it should be an X.509 certificate, possibly from a known CA - and so it's impossible to add a "Gzip'd Certificate" feature to TLS 1.2 even though if you look at the protocol description it's easy to see how, if you actually tried you would find middleboxes throw a fit since this isn't X.509 and now your software can't be deployed. But in TLS 1.3 compressed certificates are a thing, because TLS 1.3 encrypts almost everything and that includes Certificate. A client can say "I grok Compressed Certificates" and the server goes "Here's a Compressed Certificate" and nobody else is any the wiser. A middlebox doesn't know about it and so it can't meddle.
  - mey 7y ago
    In a lot of corp env, a corp CA is injected, which allows middleware to MITM sessions. TLS 1.3 still allows this nonsense. Most current gen firewalls rely on this to be useful.
    - tialaramex 7y ago
      In TLS 1.3 you can only do this by proxying all connections. Whereupon all these hypothetical non-compliant QUIC streams are yours and nobody on the rest of the Internet cares. This is a significant (and for the "IT security" industry expensive) change compared to previous versions but it was done with this in mind. The methods often employed to avoid doing proxying don't actually deliver security though they did ossify the protocol but they are cheaper. Too bad. Let's take my compression example again. Your "firewall" won't tell you it understands compressed certs since it has no idea what they are, and it won't request them from the server, no ossification. New features don't work for you inside your "firewall" making the Internet worse for you, but for everybody else improvements continue. The same for the spin bit. Corp A enforces a completely broken spin bit for "security", it suffers mysterious and hard to diagnose network faults but the rest of the Internet isn't affected and life continues as normal.
  - cesarb 7y ago
    > Depend on it to do /what/ though? My specific worry is that some "firewalls" will try to use the little that's still visible (the spin bit, packet sizes, packet timing, etc) to try to guess whether the connection comes from a "legitimate" source like a common web browser, and discard the packets otherwise. "You flipped the bit when you should have flopped it, so you're a malware and I'm going to blackhole your whole IP address for the rest of the day", things like that.
bsysop 7y ago
What developer out there reads "The spin bit is an OPTIONAL feature of QUIC", then sees "Implementations MUST allow administrators of clients and servers to disable the spin bit either globally or on a per-connection basis" and thinks "Yes, this is definitely something I will implement and test out all the edge cases." Especially stuff like "The random selection process SHOULD be designed such that on average the spin bit is disabled for at least one eighth of network paths." This whole thing is going to be a congestion control arms race. With TCP out the window this is going to be an epic battle of network operators trying to heuristically classify important vs. bulk traffic any way they can, content servers trying every trick in the book to get their traffic prioritized ahead of competitors, and savvy users running tweaked router firmware to jump the Fair Share queue.
- Ericson2314 7y ago
  I dunno, there is far less information than before.
Wicher 7y ago
As I read the RFC[1], every endpoint is supposed to disable the spinning on about 1 in 8 connections. I presume to force middleboxes to accept connections with and without it set. > Even when the spin bit is not disabled by the administrator, implementations MUST disable the spin bit for a given connection with a certain likelihood. The random selection process SHOULD be designed such that on average the spin bit is disabled for at least one eighth of network paths. [1] https://tools.ietf.org/html/draft-ietf-quic-transport-23#section-17.3.1 https://tools.ietf.org/html/draft-ietf-quic-transport-23#sec...
- Wicher 7y ago
  (and as long as there is at least one actor interested in RTT, and this actor happens to controlling both endpoints for a significant amount of traffic crossing the internet (Chrome/Google), there will be good mix of connections with and without spinbit)
anoncake 7y ago
Correct link: https://en.wikipedia.org/wiki/Evil_bit https://en.wikipedia.org/wiki/Evil_bit
irq-1 7y ago
> Even worse, "malicious" clients could spin the bit randomly. That's how its supposed to work. https://tools.ietf.org/html/draft-ietf-quic-transport-23#section-17.3 https://tools.ietf.org/html/draft-ietf-quic-transport-23#sec... > When the spin bit is disabled, endpoints MAY set the spin bit to any value, and MUST ignore any incoming value. It is RECOMMENDED that endpoints set the spin bit to a random value either chosen independently for each packet or chosen independently for each connection ID.

by mey 7y ago

cesarb 7y ago

> but I expect it will eventually become a dead field. I hope that's all that happens. My worry is that middleboxes will start to depend on it, and any implementation which doesn't spin it "correctly" (where "correctly" is defined by the middlebox vendor, not the standard) will be blocked.

unilynx 7y ago
There isn't much they can do about it? All they can do is corrupt or block the packet, which looks to the end user like high packet loss on random connections... earning that router type a reputation for being very slow and pushing it out of he market.
- silotis 7y ago
  The average user doesn't have the level of visibility into the system to know that the middlebox is the one causing the problem. Instead whatever changed last gets the blame, regardless of what's actually at fault. So if a user's existing applications set the spin bit "correctly" and a new application does not, the new application will be judged as buggy, not the middlebox which has been working fine until now.
tialaramex 7y ago
Depend on it to do /what/ though? Middleboxes can equally well insist upon tampering with other data they can't interpret in QUIC, and that too just causes the packets to be discarded. To what end? Middleboxes aren't actively malevolent they're just built by idiots. Our experience has been that middlebox vendors _ossify_ things. They see a field that's defined "Zero: Reserved for future use" and they say "Aha, that's supposed to be zero" and so now that "future use" can never happen. For example the Certificate in TLS 1.2 and earlier isn't intended to be useful to anyone except the TLS Client. But middleboxes interpret it anyway, they insist it should be an X.509 certificate, possibly from a known CA - and so it's impossible to add a "Gzip'd Certificate" feature to TLS 1.2 even though if you look at the protocol description it's easy to see how, if you actually tried you would find middleboxes throw a fit since this isn't X.509 and now your software can't be deployed. But in TLS 1.3 compressed certificates are a thing, because TLS 1.3 encrypts almost everything and that includes Certificate. A client can say "I grok Compressed Certificates" and the server goes "Here's a Compressed Certificate" and nobody else is any the wiser. A middlebox doesn't know about it and so it can't meddle.
- mey 7y ago
  In a lot of corp env, a corp CA is injected, which allows middleware to MITM sessions. TLS 1.3 still allows this nonsense. Most current gen firewalls rely on this to be useful.
  - tialaramex 7y ago
    In TLS 1.3 you can only do this by proxying all connections. Whereupon all these hypothetical non-compliant QUIC streams are yours and nobody on the rest of the Internet cares. This is a significant (and for the "IT security" industry expensive) change compared to previous versions but it was done with this in mind. The methods often employed to avoid doing proxying don't actually deliver security though they did ossify the protocol but they are cheaper. Too bad. Let's take my compression example again. Your "firewall" won't tell you it understands compressed certs since it has no idea what they are, and it won't request them from the server, no ossification. New features don't work for you inside your "firewall" making the Internet worse for you, but for everybody else improvements continue. The same for the spin bit. Corp A enforces a completely broken spin bit for "security", it suffers mysterious and hard to diagnose network faults but the rest of the Internet isn't affected and life continues as normal.
- cesarb 7y ago
  > Depend on it to do /what/ though? My specific worry is that some "firewalls" will try to use the little that's still visible (the spin bit, packet sizes, packet timing, etc) to try to guess whether the connection comes from a "legitimate" source like a common web browser, and discard the packets otherwise. "You flipped the bit when you should have flopped it, so you're a malware and I'm going to blackhole your whole IP address for the rest of the day", things like that.

bsysop 7y ago

What developer out there reads "The spin bit is an OPTIONAL feature of QUIC", then sees "Implementations MUST allow administrators of clients and servers to disable the spin bit either globally or on a per-connection basis" and thinks "Yes, this is definitely something I will implement and test out all the edge cases." Especially stuff like "The random selection process SHOULD be designed such that on average the spin bit is disabled for at least one eighth of network paths." This whole thing is going to be a congestion control arms race. With TCP out the window this is going to be an epic battle of network operators trying to heuristically classify important vs. bulk traffic any way they can, content servers trying every trick in the book to get their traffic prioritized ahead of competitors, and savvy users running tweaked router firmware to jump the Fair Share queue.

Ericson2314 7y ago
I dunno, there is far less information than before.

Wicher 7y ago

As I read the RFC[1], every endpoint is supposed to disable the spinning on about 1 in 8 connections. I presume to force middleboxes to accept connections with and without it set. > Even when the spin bit is not disabled by the administrator, implementations MUST disable the spin bit for a given connection with a certain likelihood. The random selection process SHOULD be designed such that on average the spin bit is disabled for at least one eighth of network paths. [1] https://tools.ietf.org/html/draft-ietf-quic-transport-23#section-17.3.1 https://tools.ietf.org/html/draft-ietf-quic-transport-23#sec...

Wicher 7y ago
(and as long as there is at least one actor interested in RTT, and this actor happens to controlling both endpoints for a significant amount of traffic crossing the internet (Chrome/Google), there will be good mix of connections with and without spinbit)

anoncake 7y ago

Correct link: https://en.wikipedia.org/wiki/Evil_bit https://en.wikipedia.org/wiki/Evil_bit

irq-1 7y ago

> Even worse, "malicious" clients could spin the bit randomly. That's how its supposed to work. https://tools.ietf.org/html/draft-ietf-quic-transport-23#section-17.3 https://tools.ietf.org/html/draft-ietf-quic-transport-23#sec... > When the spin bit is disabled, endpoints MAY set the spin bit to any value, and MUST ignore any incoming value. It is RECOMMENDED that endpoints set the spin bit to a random value either chosen independently for each packet or chosen independently for each connection ID.