Just one QUIC bit
blog.apnic.net
Just one QUIC bit
1–10 of 105 posts
Re: Just one QUIC bit
#2Just to make sure I understand this:
- Google has been spearheading a protocol called 'QUIC'
- It bypasses tradition TCP by using UDP to create it's own version of TCP but encrypts the data it sends
- However it could be (is?) sending a bit and header that can make tracking the message path easier.
I would guess if that is true then and would not effect the performance the bit and header should be removed. I don't see what the fuss is about. Can't two different implementations exist along side each other and the public will choose the better one?
Correction: I misread the article and thought though spin bit was for an encryption key. Let this be a lesson to everyone: if you are going to comment at 2 am in the morning reread your article.
Re: Just one QUIC bit
#3Just to make sure I understand this: - Google has been spearheading a protocol called 'QUIC' - It bypasses tradition TCP by using UDP to create it's own version of TCP but encrypts the data it sends - However it could be (is?) sending a bit and header that can make tracking the message path easier. I would guess if that is true then and would not effect the performance the bit and header should be removed. I don't se…
[deleted]
Re: Just one QUIC bit
#4Just to make sure I understand this: - Google has been spearheading a protocol called 'QUIC' - It bypasses tradition TCP by using UDP to create it's own version of TCP but encrypts the data it sends - However it could be (is?) sending a bit and header that can make tracking the message path easier. I would guess if that is true then and would not effect the performance the bit and header should be removed. I don't se…
It doesn't make decrypting the message easier. It just exposes a bit of unencrypted information, that makes it possible to infer information like how the connection's round-trip time. And the argument is over whether exposing that information has value, and whether routers and other boxes in the middle will abuse that information.
Re: Just one QUIC bit
#5IMO the article completely fails to describe the actual issue.
- "Then there is the NAT function, where the 5-tuple of protocol, source and destination addresses and the source and destination port numbers is used as a lookup vector into a translation table, and both the IP and the inner transport packet headers are altered by the NAT before passing the packet onward."
Nice try, but if the outer layer is UDP, then NAT alters the UDP packet headers. The QUIC payload is never touched.
- "Many network operators use the IP and transport packet headers to perform traffic engineering functions, packet interception and forced proxy caching. Various forms of middleware may reach into the TCP control fields and manipulate these values to modify session flow rates. All of these activities are commonplace, and some network operators see this as an essential part of their service."
I don't see why the people tasked with standardizing Internet protocols now have to make provisions for the jerks who literally break the Internet.
- "This bit, the “spin bit” is intended to be used by passive observers on the network path to expose the round trip time of the connection. The management of the bit’s value is simple: the server simply echoes the last seen value of the bit in all packets sent in this connection. The client echoes the complement of the last seen bit when sending packets to the server. The result is that when there is a continuous sequence of packets in each direction this spin bit is flipped between 0 and 1 in time intervals of one Round Trip Time (RTT). Not only is this RTT time signature visible at each end, but it is visible to any on-path observer as well."
I have literally no idea why a protocol should actively leak unnecessary information to a passive observer, and I have no idea what passive observers would do with the information they can deduce from this "spin bit". The payload is still encrypted, so you still can't do all the "traffic engineering, packet interception and forced proxy caching". As a passive observer you sit somewhere in the middle of the whole stream, and if you can even fish out the necessary packets (they might take different routes in each direction), you still don't know how far you are from the other end. Not even talking about the random processing delays at the server end. You're measuring garbage. How is this bit even useful for anything?
Re: Just one QUIC bit
#6If you give an engineer a bit:
https://mailarchive.ietf.org/arch/msg/quic/yQfBIAOnUEKIWjZhF...
You can kind of see how this might get out of hand and cause the discuss to digress and go in circles.
Re: Just one QUIC bit
#7What’s even the point of this spin-bit thing? Of what use is an estimate of my roundtrip-time to intermediaries?
Re: Just one QUIC bit
#8Middleboxes have been tampering with packets and headers for way too long. It's most definitely time to move back control to the two ends of the connection, to avoid fossilisation and the same mistakes made in the past. IPv6 and QUIC are a cardinal step in this direction, and we cannot afford to let myopic decisions screw up the opportunity to fix what has been broken for so long.
Re: Just one QUIC bit
#9IMO the article completely fails to describe the actual issue. - "Then there is the NAT function, where the 5-tuple of protocol, source and destination addresses and the source and destination port numbers is used as a lookup vector into a translation table, and both the IP and the inner transport packet headers are altered by the NAT before passing the packet onward." Nice try, but if the outer layer is UDP, then NA…
The point is that QUIC is supposed to be fully encrypted below the UDP layer. The question is why add bits in the clear on top of this to water it down and open an avenue for potential abuse.
Re: Just one QUIC bit
#10What’s even the point of this spin-bit thing? Of what use is an estimate of my roundtrip-time to intermediaries?
Network engineers can use it to monitor network performance.