10 ms·
Just one QUIC bit
- randomerr 9y agoJust 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.
- deleted 9y ago[deleted]
- JoshTriplett 9y agoIt 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.
- giovannicarruba 9y agoIMO 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?
- nicky0 9y agoThe 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.
- IshKebab 9y agoYes but it doesn't really say why anyone wants this spin bit. What are they going to do with it? Measure RTTs? Why? What for?
- corndoge 9y agoIt seems you were the one who completely failed to understand the article. Your first point implies you think the author was talking about QUIC in that section, when instead the author was merely using NAT as an example of packet inspection to provide context to the topic. Your second point is in fact exactly the point of the entire article, which itself is a commentary on the decision making process and factors in that process that IETF is presently using to decide exactly how much to "break" the protocols, and moreover on the observation that many people in the IETF do not consider this to be "breaking" at all. Your third point is a commentary on the utility of the bit itself, which is not really the focus of the article anyway. You claim: "IMO the article completely fails to describe the actual issue." How so?
- Lazare 9y ago> Nice try, but if the outer layer is UDP, then NAT alters the UDP packet headers. The QUIC payload is never touched. You didn't understand the article. It's talking about existing TCP traffic here, not QUIC. > 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. 1) A lot of them are the same people and 2) internet protocols are worthless without adoption, which is why we're still groping towards IPv6. Or for a shorter answer: Politics. > How is this bit even useful for anything? Here's an internet draft proposing adding a spin bit which discussed, among other things, some uses for it: https://tools.ietf.org/html/draft-trammell-quic-spin-01 https://tools.ietf.org/html/draft-trammell-quic-spin-01
- anameaname 9y agoIf you give an engineer a bit: https://mailarchive.ietf.org/arch/msg/quic/yQfBIAOnUEKIWjZhFW8CYPOcEKc 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.
- tzahola 9y agoWhat’s even the point of this spin-bit thing? Of what use is an estimate of my roundtrip-time to intermediaries?
- nicky0 9y agoNetwork engineers can use it to monitor network performance.
- IshKebab 9y agoHow though, because surely it includes the time outside the observers network? And if they only want to monitor performance inside their network nothing so them from using an out of band system, or even adding their own timing footers to packets.
- nicky0 9y agoRead this comment: https://news.ycombinator.com/item?id=16696159 https://news.ycombinator.com/item?id=16696159
- erpellan 9y agoWhich they could presumably also do by injecting their own packets, not snooping on everyone else's?
- nicky0 9y agoI don't know, how would you inject packets into an encrypted end to end connection? Passive observation of traffic is a useful network performance monitoring technique.
- mhandley 9y agoKnowing the RTT seen by actual user traffic is useful because, for example, it lets you observe if that traffic is encountering excessive queuing. It's hard to know this by other means; for example you may think you can just ping the end systems, but these days ICMP is often filtered, and even it it wasn't, the test probes may be queued differently due to weighted fair queuing, or even take a different path due to equal-cost-multipath routing. In the end, the only true measure is what the traffic itself experiences. Now, whether it is necessary for operators to know if user traffic is seeing excessive queuing is open to debate. But the fact is they do currently use this as one network health measure.
- qalmakka 9y agoMiddleboxes 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.
- kiriakasis 9y agoI believe that lack of compatibility between IPv4 and IPv6 was more relevant than middleboxes meddling with packets.
- whatupmd 9y ago"Who needs Firewalls and NAT," he loudly declares while kicking down the walls of the house to expose himself to the natural elements.
- pdkl95 9y ago> The client echoes the complement of the last seen bit when sending packets to the server. Since neither the client or server care about this big, there doesn't appear to be anything that forces the client to actually implement this behavior. The client could always set it to 0 or even set it (pseudo-)randomly on each packet. The bit shouldn't exist, but if the IETF did add it to the standard, would hostile middleware boxen actually start drooping packets if they don't see the "spin bit" change?
- silotis 9y agoThis was my first thought as well. I would love to see the reaction from the pro-spin-bit camp if Google announced that Chrome will never set the spin bit.
- mhandley 9y agoI was in the IETF meeting. It was actually a very civil discussion, and I think almost everyone in the room could see both sides on the issue. On the one hand, we've seen increasing problems with middleboxes making assumptions about end-to-end protocols, and this making it very hard to then deploy new end-to-end functionality. The problem is real; we measured this effect in this paper: http://www0.cs.ucl.ac.uk/staff/M.Handley/papers/extend-tcp.pdf http://www0.cs.ucl.ac.uk/staff/M.Handley/papers/extend-tcp.p... Indeed, one of the changes the IETF group has made since taking on QUIC is to also encrypt the QUIC sequence numbers, so middleboxes can't play silly games by observing them (they were already integrity protected). However, the flip side is that network operators do use observations of network round trip time gained from passive observation of traffic so as to discover if traffic is seeing excessive queuing somewhere. An inability to do this with QUIC may either lead to worse network behaviour, or to them using other methods to gain insight. If you're in a location where you can observe both directions of a flow, you can easily do this by, for example, delaying a bunch of packets by 200ms, then letting them go. When you see a burst of (encrypted) ack packets return, you can deduce the RTT from your observation point to the destination. I'd really like to avoid operators thinking they need to do such hacks just to measure RTT, and the spin bit lets a passive observer see the RTT. In the end, I was not convinced entirely by either argument, and neither was the consensus in the room. It's not a clear-cut decision; there are reasonable arguments either way. Such is engineering.
- anameaname 9y agoRealistically, are network operators going to add artificial delay to packets going through their network? If they don't get their bit, and they start slowing down communication, it would seem like market correction would solve it.
- mhandley 9y agoI've no idea what techniques will actually be applied by operators - I never expected middleboxes to go to the extremes they currently do either. But the technique I mentioned, of briefly delaying a short burst of packets, if done only occasionally, isn't really going to be noticed during a large transfer. I'm not claiming its a good idea though!
- wpietri 9y agoNice. I especially like this bit: "Sometimes difficult choices admit to no sensible compromise between them and the process simply has to make a contentious decision one way or the other. While individuals make such decisions all the time, the collective process that enlists a large group of diverse perspectives, interests and motivations finds such decision making extraordinarily challenging."
- Asdfbla 9y agoAs someone only superficially familiar with networking, I think it would be interesting to know what impact the current packet inspection practices by the middleboxes have on network performance. After all, the article mentions that those middleboxes want to control the message flow and use that as justification. The assumption behind QUIC seems to be that there's no "global" benefit in that specific kind of network management and that it's mostly selfish interests of local network operators that motivate messing with the packets? Basically, what are the incentives of the middleboxes to inspect packages and what do they really stand to lose?
- signa11 9y ago> interesting to know what impact the current packet inspection practices by the middleboxes have on network performance. well, all (almost ?) current boxes can do that at line rate for minimal sized packets. > incentives of the middleboxes to inspect packages(sic) incentive is for charging / billing / steering packet flows etc.
- Asdfbla 9y agoI probably expressed that wrong, I was more wondering if the packet sniffing had any beneficial impact on the performance in the sense of QoS or congestion control or something like that. After all, they have to do it for a reason. But your second points mentions it's for billing and such, so I guess that's my answer.
- woah 9y agoI don’t think it’s for billing most of the time. The middleboxes usually provide some kind of immediate benefit to the network, while breaking core networking assumptions and thus contributing to a weird form of technical debt.
- xtrapolate 9y agoThis proposal is a compromise. Wouldn't a specific metadata/heartbeat "packet", routinely dispatched by the involved parties, serve a better solution? My personal stand is to prohibit exposing any metadata on the connection whatsoever, but given the counterarguments, I don't think the proposed solution is ideal.
- no_identd 9y ago>My personal stand is to prohibit exposing any metadata on the connection whatsoever https://grothoff.org/christian/habil.pdf https://grothoff.org/christian/habil.pdf Christian Grothoff - The GNUnet System [October 2017, 181 pages, PDF]
- lumisota 9y agoMy takeaway from the meeting was that it isn't clear that the spin bit is actually useful. Leaving aside the arguments that RTT shouldn't be exposed (it is anyway, with the handshake): does the spin bit actually provide useful information? It seems to be a fairweather metric: OK resolution when the network is operating normally, but providing no useful information when something has gone wrong (which is when you'd want it most).
- bullen 9y agoAgain the solution is not to reimplement TCP on top of UDP but to make TCP like UDP: https://www.ietf.org/id/draft-add-ackfreq-to-tcp-00.txt https://www.ietf.org/id/draft-add-ackfreq-to-tcp-00.txt
- tialaramex 9y agoA nice thing about the I-D system is that we don't have to waste RFC numbers on this sort of crank nonsense. Once upon a time the IETF would end up publishing this sort of thing as an RFC and then everybody would just ignore it, but that used up the numbers and short memorable numbers are nice, which was a shame. Now we can publish them as "drafts" which just quietly expire once their interest moves on to investigating which metal foils can be made into hats that best resist government mind control rays or whatever.
- no_identd 9y ago>to investigating which metal foils can be made into hats that best resist government mind control rays or whatever. You joke, but Allan H. Frey already solved that in the 1960s, just add a 2"x2" wire mesh near the temples, over the temporal lobes. Blocks all RF interaction with the brain, no tin foil hat required. ...of course, this doesn't block 'mind control rays', the only thing it actually blocks consists of the Microwave auditory effect, and the only target audience for that consists of Radar techs walking around in front of hugeass antennas. ;)
- rphlx 9y ago> the only target audience for that consists of Radar techs walking around in front of hugeass antennas And perhaps US diplomats in Cuba.
- datalist 9y agoI am not sure I understood the article to be honest. Does QUIC encrypt the actual UDP packet (meaning from IP down, including the UDP header)? If that is the case it is not UDP anymore and there will be "problems" in getting to anywhere in the first place. If it only encrypts the UDP payload, where does NAT come in? How would that be different from what TLS does over TCP? Did I miss anything? Thanks.
- detaro 9y agopure NATs aren't a problem for QUIC, but other middleboxes are.
- datalist 9y agoThe article specifically refers to NAT. What other boxes would you have in mind? And is the UDP header encrypted or not? Thanks!
- detaro 9y agoThe article only mentions NAT as the most prominent example of middle boxes. And no, the UDP header obviously is not encrypted, if it were it wouldn't work with existing devices and OSes. UDP doesn't give you much information to mess with, which is part of why it's used for QUIC: it works through existing networks, and they can protect the deeper protocol layers against development of new middle-boxes attempting to look into them by encrypting all of it.
- datalist 9y agoI am not sure it is that obvious given the article's focus on NAT. But what is the problem exactly then?
- detaro 9y agoThe problem is that if a protocol has visible parts, middleboxes will try to do stuff with those and not handle them correctly in corner cases, or when the protocol changes (e.g. TLS had issues with middleboxes attempting to verify details of the handshake and breaking or downgrading a connection when it saw options it didn't know, e.g. because a newer TLS version was used. MPTCP extended TCP and had lots of problems with things that expected specific behavior of TCP flags and parameters, where MPTCP would have liked to use them differently. With HTTP there have been issues with proxies not understanding new headers, or things like websockets. ...) QUIC tries to prevent this by making as little as possible visible outside the encryption: it should look to a middlebox as much as possible like an opaque data stream, and not reveal any details about what's going on inside. Now there is a proposal to add something that is explicitly visible to the network, and people are worried that will come back to bite them in some way if they make an exception now.
- bogomipz 9y agoThe author states: >"Many network operators use the IP and transport packet headers to perform traffic engineering functions, packet interception and forced proxy caching." I'm guessing this referring to transparent hardware caches looking at Layer 7/HTTP headers? And then: "Various forms of middleware may reach into the TCP control fields and manipulate these values to modify session flow rates" Does the author mean TCP flow control here? So there exists middleware which changes the ACK and RWND values in TCP headers? Does anyone know what middleware vendors do this? I'm guessing this might be done as as part of network "accelerator" hardware devices like Riverbed. Is this correct?
- breatheoften 9y agoThere are still environments where active policies described by network operators to manage traffic flows is _required_ for users to make any productive use of the network ... I used to work on research ships — 50 people at sea for months at a time with satellite internet having only 256kbps (800ms latency). It was abysmal to watch as over time everyone became completely dependent on internet connectivity for their computing needs as all services moved to the cloud. Trying to provide a useable internet experience in that context involved blocking as much as we could that users machines were doing (usually without their awareness) in the background that simply couldn’t happen from that network — making the trade offs to try and select for things that _could_ work was a huge challenge. It seems like QUIC offers better fundamental performance primitives but no way to solve for protecting users from themselves in this kind of environment ...
- tangent128 9y agoThe"correct" answer there is probably to make the network limits explicit, by explicitly requiring a proxy server or organization CA installed in the client. QUIC should still work with middleware that actually terminates the connection instead of meddling from outside.
- marshray 9y agoSounds like Android at least can be told via DHCP it's on a metered connection: https://www.reddit.com/r/networking/comments/4wk4rw/dhcp_option_to_signal_metered_connection/ https://www.reddit.com/r/networking/comments/4wk4rw/dhcp_opt...
- pcunite 9y agoI disable QUIC in my network because I'm doing QoS at my router and utilize TCP flow control to slow things do to where I want them to be. QUIC makes the incorrect assumption that the network never wants to slowdown or to even allow for a configurable speed. Don't be too clever.
- zlynx 9y agoJust ruthlessly drop QUIC packets that are over the flow control limits. It will adapt. Playing games with TCP settings is fun I guess, but simple RED with ECN and drop work well with fewer bad side-effects. Every Internet protocol expects packet drops on overload. What was that about being too clever?
- floatboth 9y agoWhy use flow control? Why not just a traffic shaper like altq/dummynet/whatever? Do you really only care about TCP traffic and not torrents, games, VoIP etc.?
- gene91 9y agoThis idea of forbidding middlebox from messing up things sounds great. I have an honest question here though. What stops a middle box from terminating all QUIC connections (and therefore get access to decrypted content)?
- floatboth 9y agoQUIC uses TLS, so it's pretty much the same situation as any other TLS connection. Of course in a corporate environment you can trust the middlebox's CA on all the work machines. That's actually fine. What everyone seems to hate here is middleboxes that don't terminate connections and try to mess with them in other ways.
- deleted 9y ago[deleted]