QUIC: Google's New Secure UDP-Based Protocol 97
New submitter jshurst1 writes "Google has announced QUIC, a stream multiplexing protocol running over a new variation of TLS, as well as UDP. The new protocol offers connectivity with a reduced number of round trips, strong security, and pluggable congestion control. QUIC is in experiment now for Chrome dev and canary users connecting to Google websites."
Re:Don't trust 'em (Score:5, Insightful)
The always-present question for UDP (Score:2, Insightful)
How do you stop a denial of service attack if both sides aren't required to maintain the overhead of the connection? TCP uses the overhead caused by ACK packets as a rate limiter on clients.
There are obviously high-bandwidth frameworks where you're already putting a strain on systems just by using them, where low-latency is also critical, and UDP is appropriate; video chat comes to mind, but outside of that very limited purview, what use could encrypting UDP actually do?
Not necessarily the right place (Score:3, Insightful)
I have no objection to protocol experiments that are 100% Open Source implementations. I wouldn't trust one that was not, and an Open Standard is just instructions for people who make implementations.
But it seems that a lot of this might belong in a system facility rather than the browser and server. I don't know if it makes sense to put all of TLS in the kernel, but at least it could go in its own process. Using UDP is fine for an experiment, but having 200 different ad-hoc network stacks each tied into their own application and all of them using UDP is not.
Re:The always-present question for UDP (Score:3, Insightful)
How do you stop a denial of service attack if both sides aren't required to maintain the overhead of the connection
How do you stop it if someone does not bother to respect the rate limiter? You are assuming that someone doing something bad is going to play by the rules.
QUIC is more like TCP in these ways, exception to (Score:5, Insightful)
They could have, but QUIC is "better" for their use cases. In many ways, it's like an improved version of TCP. It runs on top of UDP simply
because routers, firewalls, etc. often only speak TCP and UDP. From the FAQ:
> it is unlikely to see significant adoption of client-side TCP changes in less than 5-15 years. QUIC allows us to test and experiment with new ideas,
> and to get results sooner. We are hopeful that QUIC features will migrate into TCP and TLS if they prove effective.
> You can outright lose data. Your packets can arrive out of order. It's okay with video data where a hiccup only makes a few missing pixels,
> but with text, that's a terrible idea.
Unless of course the protocol you're running over UDP handles that stuff, just like TCP handles that stuff.
Normally, it's a bad idea to use UDP to run a protocol that has in-order packets, guaranteed delivery, etc. because TCP already gives you that.
Why re-invent TCP? Unless you're going to spend a few million dollars on R&D to make your UDP-based protocol actually be better than TCP,
you should just use TCP.
That "unless you're going to spend a few million dollars on R&D" is the key here. Google DID make the investment, so the protocol actually does
work better for the particular use than TCP does.
Comment removed (Score:3, Insightful)
Re:Don't trust 'em (Score:4, Insightful)
It's "like" TLS, as in "its none dairy but it tastes just like milk".
Google's reason for doing this is to lower their costs associated with better security. This creates a 3 way instead of a 5 way exchange for the security protocol setup. Fewer connections less load on their stuff and less stuff they have to buy.
The security landscape is littered with security implementations which tried improve existing protocols. Just type in the terms WAP and security for a story on how to take a secure starting point SSL and bugger it.
Another is Microsoft's introduction of PKINIT for keberos, kerberos is a proveably security protocol which is limitied by the entropy in a users password, MS "fixed" this with PKINIT however they initroduced replay attach vectors precisely because they wanted fewer exchanges. BTW google seems to have done a better job in this regard +1 for google, -1 for MS.