Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Just one QUIC bit

blog.apnic.net

Post reply on HN
Print view View original

51–60 of 105 posts

Re: Just one QUIC bit

#51

Post by datalist »

detaro wrote: post #50
datalist wrote: post #48

Earlier quoted context omitted.

The article specifically refers to NAT. What other boxes would you have in mind? And is the UDP header encrypted or not? Thanks!

The 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 l…

I am not sure it is that obvious given the article's focus on NAT.

But what is the problem exactly then?

Re: Just one QUIC bit

#52

Post by datalist »

iknowstuff wrote: post #49
datalist wrote: post #46

I 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.

The article only mentions NAT as a showcase of what IP packet parsing is used for. QUIC does not encrypt the UDP header. TLS 1.3 actually run into a lot of issues due to network ossification. QUIC has been developed to bypass TCP's ossification problem and enable quicker iteration and deployment to improve latency, congestion mitigation etc. You could argue that if QUIC's principles were in place for TCP/IP 20 years…

Thank you, though giving an example that does not even apply to the case is not the best approach when one wants to make a case :)

If it does not tamper with UDP I fail to recognise the issue though to be honest.

Re: Just one QUIC bit

#53

Post by bogomipz »

The 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?

Re: Just one QUIC bit

#54

Post by pilif »

datalist wrote: post #52
iknowstuff wrote: post #49

Earlier quoted context omitted.

The article only mentions NAT as a showcase of what IP packet parsing is used for. QUIC does not encrypt the UDP header. TLS 1.3 actually run into a lot of issues due to network ossification. QUIC has been developed to bypass TCP's ossification problem and enable quicker iteration and deployment to improve latency, congestion mitigation etc. You could argue that if QUIC's principles were in place for TCP/IP 20 years…

Thank you, though giving an example that does not even apply to the case is not the best approach when one wants to make a case :) If it does not tamper with UDP I fail to recognise the issue though to be honest.

> If it does not tamper with UDP I fail to recognise the issue though to be honest.

the problem is that if you expose any kind of information in addition to just the IP and UDP headers, then future middleboxes will start to use this information and will start dropping packets they can't parse.

If a QUIC packet is just random noise (aside of the UDP and IP headers), then a middlebox can't make assumptions about the inner workings of QUIC. It's a very common (but unfortunate) practice by "security" appliances to drop everything they don't understand because they treat that as potentially malicious.

Let me make a (hypothetical) example: Let's say QUIC packets had some publicly available "version" field. The implementation as it's used now is setting that to 1.

Now middleboxes start "gaining" support for QUIC and as "everybody" knows, the only widely deployed version is 1, so these middleboxes start to treat every other value of that field as a possible attack and drop such packets.

Now, years later, we want a new version of QUIC, but unfortunately, the most widely deployed (and never updated) middleboxes out there assume any version but 1 to be malicious.

Which leaves us with a "version" field that practically has to be set to 1, so now we need another way to flag the new packets. Maybe a "real_version" field? Who knows? We'll have to try various things until the majority of the middle-boxes currently deployed are fooled.

Also, it will likely be impossible to fool them all, so even when we get around the majority of the boxes, we'll still exclude some people from being able to reach QUIC 2 servers. Sure - it will be a very small amount, but it won't be zero.

This isn't just theoretical. We had this problem just now with TLS 1.3. Since the beginning SSL and then TLS had version fields in order for clients and servers to negotiate the SSL version to use.

Unfortunately, because of precisely this problem, that field stopped being useable years ago where even the 1.2 negotiation had to happen using a workaround which then promptly also stopped working for 1.3.

By not exposing anything but random noise as part of a QUIC packet, the protocol designers aim to prevent this from happening. If all a "transparent" proxy sees is random noise, they can decide to not support QUIC at all or to support all of it. They can't decide on a "safe" subset and burn that into the internet for all eternity.

Re: Just one QUIC bit

#55

Post by breatheoften »

There 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 ...

Re: Just one QUIC bit

#56

Post by datalist »

pilif wrote: post #54
datalist wrote: post #52

Earlier quoted context omitted.

Thank you, though giving an example that does not even apply to the case is not the best approach when one wants to make a case :) If it does not tamper with UDP I fail to recognise the issue though to be honest.

> If it does not tamper with UDP I fail to recognise the issue though to be honest. the problem is that if you expose any kind of information in addition to just the IP and UDP headers, then future middleboxes will start to use this information and will start dropping packets they can't parse. If a QUIC packet is just random noise (aside of the UDP and IP headers), then a middlebox can't make assumptions about the in…

Thanks for the detailed response, but I am "with" you :).

The bit (no pun intended) I do not understand is why there is such a discussion in the first place? Why do they insist on a plaintext status bit?

Thats why I wondered if there was any encryption outside of the UDP payload.

Re: Just one QUIC bit

#57

Post by isostatic »

ksec wrote: post #35
tialaramex wrote: post #32

Earlier quoted context omitted.

No. Bandwidth limits and delay aren't the same thing. CPE (the WiFi router or similar in your home) often adds delay because a few megabytes of RAM is cheap and the people who built it don't understand what they're doing. This is called "buffer bloat". But inside the network core this rarely comes up.

Does anyone know how much buffer bloat or delay is added in the router, or CPE or Modem? I assume they are less then 1ms? I have been trying to figure this out for a while but information aren't really available.

Depends on the router, and the load. If you have a 100mbit uplink and 4x1 gig on the downlink side, you could easily have 10mbit of packets arrive in 3ms (70 packets per millisecond), but would take 30ms to send those packets. You can either

1) Drop -- despite total trafic being only 10mbit a second

2) Queue -- introducing a delay of 30ms.

In reality you'd put latency critical applications (voip etc) at the top of the queue so the pcakets get transmitted without the delay, and your facebook packets get delayed by 31ms rather than 30ms.

Re: Just one QUIC bit

#58

Post by IshKebab »

mhandley wrote: post #16

I 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/…

The thing I don't understand is why these network operators care about RTT outside their network? Shouldn't they only care about getting packets through their network as quickly as possible, which you don't need this spin bit for.

Re: Just one QUIC bit

#59

Post by pilif »

datalist wrote: post #56
pilif wrote: post #54

Earlier quoted context omitted.

> If it does not tamper with UDP I fail to recognise the issue though to be honest. the problem is that if you expose any kind of information in addition to just the IP and UDP headers, then future middleboxes will start to use this information and will start dropping packets they can't parse. If a QUIC packet is just random noise (aside of the UDP and IP headers), then a middlebox can't make assumptions about the in…

Thanks for the detailed response, but I am "with" you :). The bit (no pun intended) I do not understand is why there is such a discussion in the first place? Why do they insist on a plaintext status bit? Thats why I wondered if there was any encryption outside of the UDP payload.

The discussion about exposing the bit was to allow network administrators to detect retransmissions. The bit is supposed to flip constantly, if it doesn't, then retransmissions happen and thus something might be wrong with the network.

Because it's just one bit and it can have two values and both are valid and both values are seen with about the same frequency, a middlebox won't be able to just drop a packet if the value is either 0 or 1.

This is why there is even a discussion happening. It's felt to be reasonably safe to include to provide some actual value to tools.

The debate is though whether it's really safe and/or whether it provides enough value to go through the trouble.

If you ask me personally, in my professional life, I have been bitten by protocol ossification way more than by not being able to make sense out of a packet stream, so I personally would absolutely not expose anything.

But then again, I'm an application level developer and not a network administrator.

Re: Just one QUIC bit

#60

Post by tangent128 »

breatheoften wrote: post #55

There 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 c…

The"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.
Post reply on HN