The Road to QUIC

https://blog.cloudflare.com/the-road-to-quic/?hn

by zackbloom • 8 years ago

141 48 8 years ago

blog.cloudflare.com

hinkley• 8 years ago

So who are the bad actors they’re freezing out with this spec? They mention problems with middle boxes which I’ve heard before, but no finger pointing.

tialaramex4• 8 years ago

I can't find any mention of "bad actors" or "freezing out" anybody or anything so I'm going to guess you meant just generally which middle boxes are "bad" and the answer is all of them, almost by definition.

The specifications we're dealing with here don't (and in modern protocols, this is quite deliberate) allow for any middleboxes. The only, minimal way to implement such a thing correctly in the face of that situation is to act as a full proxy, which is going to _suck_ for performance and your customers aren't going to pay for a product that throttles their connectivity badly nor for the hardware that would let you run a line speed proxy.

So, they don't, they try to make an end run around the protocol compliance, typically the idea goes something like this:

During connection setup we'll inspect everything and implement whatever rules are key to our product, but mostly we'll pass things between the real client and server transparently, only intervening as necessary for our role

Then, we can "whitelist" most connections, and let them continue at line speed without actually being inspected further.

Unlike a full proxy this design breaks, messily, when optional protocol features are understood by the client and server but not the middlebox. This is because either the middlebox pretends to understand when it doens't (so client and server seem to get their mutually agreed new feature, but if it has any impact on how the protocol is used it breaks mysteriously since the middlebox didn't know) or the middlebox squashes everything it doesn't understand then steps out of the way and expects that to work out OK even though the client and server now misunderstand each other's situation.

vitus2• 8 years ago

generally which middle boxes are "bad" and the answer is all of them, almost by definition.

NATs and firewalls are the first two classes of middleboxes that come to mind, and I wouldn't consider either of them inherently "bad".

As pointed out in the article, NATs suffer from the shortcoming that without visibility into stream semantics (e.g. SYNs / RSTs / FINs), they often fall back to using arbitrarily set timeouts that can sever long-lived connections (e.g. an idle SSH session, where messages might be infrequent).

In my view, "bad" middleboxes are those that lead to protocol ossification -- TLS 1.3 (also from the article) is a good example of that. With encrypted control state, middleboxes (without cooperation by one of the endhosts) are forced to treat QUIC packets as opaque UDP blobs.

Part of the problem is that some middleboxes don't actually follow the robustness principle, and will in fact strip unrecognized protocol options or drop the packets entirely.

cm21873• 8 years ago

I am so glad to see these old standards (tcp, http) finally being offered a better, more secure alternative. But the most problematic of all in my opinion is smtp. Anyone aware of an equivalent of the quic/http2 initiative for smtp?

dns would be second most problematic one, but like for ipv6, dnssec exists, it is just not used enough to get a chance to take over.

dtech3• 8 years ago

It's been a few years since I did server e-mail management, but SMTP/email in 2018 is quite different from SMTP/email in 1985.

For starters all large e-mail exchanges (Gmail/Live) require you to use TLS, so most mx<>mx connections are already secured. Additional protocols like SPF, DKIM and DMARC are securing origins, messages and reducing spam and spoofing.

cm21873• 8 years ago

Yeah but TLS is using STATTLS which is trivially downgradable, most smtp servers on the internet use invalid (selfsigned or expired) certs, and no one validates anything. As for spf, dkim, they are nice hints for spam level but are not used to block spoofed traffic.

So all these features are a thin layer in of lipstick on the pig and don’t really make the problem a solved problem.

boramalper• 8 years ago

JMAP?

JMAP is a modern standard for email clients to connect to mail stores. It therefore primarily replaces IMAP + SMTP submission. It does not replace MTA-to-MTA SMTP transmission. JMAP was built by the community, and continues to improve via the IETF standardization process. Upcoming work includes adding contacts and calendars (replacing CardDAV/CalDAV).

https://jmap.io

cm21873• 8 years ago

Thanks. That's interesting but my mail pain point is smtp to smtp protocol. Client to smtp server is less problematic, your client will shout if the certificate is invalid. Smtp to smtp is where the phishing, spamming, etc happens.

popshart• 8 years ago

Too much complexity.

I find it interesting how everything has to be encrypted and 'secure' now. The excuse is always the NSA, but let's be honest: A new transport protocol isn't going to protect you from them. I think there's a lot more to the cellular baseband and Intel ME backdoors than anyone can imagine.

Google is going to do the same thing with this they did with HTTPS. Soon enough, you'll be penalized through search and/or Chrome for not supporting it.

dtech3• 8 years ago

The incentive for Google is that all browsers support QUIC, it saves them a lot of hardware costs and increases performance. They couldn't care less if your website uses QUIC.

You're receiving downvotes because you're propagating the "pushing encryption is motivated by Google's evil agenda" that's currently in vogue with a subsection of HN commenters, for reasons unknown to me because quite frankly the arguments are ridiculous.

myhf• 8 years ago

all browsers support QUIC

Try blocking your network's access to www.google-analytics.com (with a fast-loading block notice page) and you will see that most webpages become unusable with a 30-second delay before page load completes.

If QUIC only works when the network has no partitions, then QUIC doesn't work.

viraptor• 8 years ago

The excuse is always the NSA

This generalisation is pretty bad. The excuse was Firesheep (https://en.m.wikipedia.org/wiki/Firesheep) in 2010. Another one was ISPs injecting ads and malware into pages (https://thehackernews.com/2016/02/china-hacker-malware.html). Another one is BGP hijack of public DNS (https://news.ycombinator.com/item?id=17178905)

Even with NSA, encryption pretty much kills passive data collection, as long as the other end is not compromised.

Sure, it won't help you if you're targeted. But that's not a good reason to drop encrypt-everything efforts.

IshKebab• 8 years ago

I think they forgot to change the source port in the NAT diagram.

omginternets2• 8 years ago

Does anybody have data (or some sort of formal analysis) comparing protocol overhead between TCP and QUIC?

AndrewDucker• 8 years ago

Not specifically overhead, but there are general benchmarks covering a variety of situations: https://blog.apnic.net/2018/01/29/measuring-quic-vs-tcp-mobi...

topspin• 8 years ago

Thank you for that. Very informative.

omginternets2• 8 years ago

Thanks for this. It's very informative, even though it's not the packet-level analysis I was initially looking for.

However, we observed that QUIC performs significantly worse than TCP when the network reorders packets (Figure 2).
Upon investigating the QUIC code, we found that in the presence of packet reordering, QUIC falsely infers that packets have been lost, while TCP detects packet reordering and increases its NACK threshold.

Under what conditions does packet ordering usually occur?

From the looks of the figures, it seems like packet-reordering is a function of the x-axis value (rate-limit of some sort?).

What's going on here? Does anybody know?

innocenat3• 8 years ago

I don't know about differences between gQUIC and new QUIC, but I always hate gQUIC to the level that I always disabled it on my machine. Main reason being that my ISP always prioritize TCP over UDP, so during congested period (6-10pm), gQUIC is useless.

andrius4669• 8 years ago

Should't that hate be directed to your ISP?

pixl972• 8 years ago

Yes, but being that most people have very little choice in their choice of ISP, so much hate has already been directed at them with little change in outcome, directing hate at any other group is more effective.

innocenat3• 8 years ago

Only if I don't have work to do during that time. Otherwise, anything to get the work done is first priority.

NelsonMinar• 8 years ago

I had a funny problem with my router QoS a couple of years ago. It was classifying unknown UDP traffic as junk, and QUIC counted as unknown. This problem was entirely self-inflicted, I was using crappy firmware and I misconfigured it. But I can easily imagine other network infrastructure treating UDP traffic poorly.

Which is a mistake. A lot of UDP traffic should be priority for low latency; games, for instance. The problem is that there's also a lot of bulk transfer happening over UDP, like Bittorrent. Long story short, traffic shaping is hard.

BTeam• 8 years ago

The BitTorrent protocol uses UDP only when using a congestion control mechanism on top of it (uTP). In fact uTP is aware when the send buffer is filled and when latency is introduced so that it automatically back-off and let interactive traffic some time to be exchanged in priority.

The standard BitTorrent protocol uses TCP by default and is arguably worse: since it uses more TCP connexion by nature compared to a client-server file delivery, it have more chances to be prioritized.

So BT over UDP with uTP transport protocol is in fact a clever way to balance heavy traffic and interactive one.

innocenat3• 8 years ago

If I were an ISP and the the network is congested, I would too drop UDP before TCP as UDP likely won't get resent.

Customer service can play dump and say the internet (== WWW) is working fine. And since we customer usually don't have choice anyway.

peterwwillis• 8 years ago

If I were developing a new protocol, and I thought more than just web browsers might want to use it, I would develop it as a new standard internet transport protocol. None of this trying to avoid getting industry adoption. Talk to Cisco, Juniper, IBM, Google, Microsoft, Apple, Intel, Broadcom, TP-Link, Huawei, Foundry, Avaya, Marvell, Foxconn, etc. Get it adopted in silicon and software, and get the industry actually excited about an upgraded protocol. They get to use it to push sales of new devices, so it's great for them. You get to use it to work around stupid intermediary networking issues.

kim0• 8 years ago

Sounds very interesting indeed. I wish more of those secure protocols would focus more on some sort of obfuscation. This is to stop repressive regimes from simply blocking all this impressive privacy tech, yielding zero actual benefit to end users.

The Road to QUIC

Related Stories