QUIC experiments [pdf] | Hacker News Reader

QUIC experiments [pdf]

ietf.org

62 pointsjsnell19 comments

One interesting thing is that we'll need new tools to diagnose QUIC connection problems.

When you're looking at a range of ports used to open a connection between layer 7 and, due to the pre-negotiated encryption basically layer 3, netcat, nmap, and tcpdump aren't as informative as they were before.

I'd love to know how Google has been handling that sort of troubleshooting internally.

There's QUIC support in Wireshark. Use the beta version. :)

Udp is too broken to use in quic http://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00

Seems counterproductive. I don't see how UDP is intrinsically more prone to allowing reflection attacks than TCP if it's used as the foundation for a well-designed connection-oriented protocol. And indeed, the principles of packet amplification and session authentication are much better understood than in days of TCP/IP.

ISPs limiting DoS UDP flows isn't reason to not use UDP for legitimate purposes. After all, nothing stops DoS botnets from sending junk TCP packets.

The problem is that today, UDP is a rate limited sewer of attack traffic from Brazilian home routers and so on. Your legit traffic is guilty by association. Devs need to know udp is collateral damage in the ddos war

> Devs need to know udp is collateral damage in the ddos war

Is it? Where's the citation to support the claim that UDP is widely rate-limited? Even if some network operators are daft enough to be indiscriminately rate-limiting all of UDP and not just the ports that are abused (DNS, SNMP, NTP, etc.), how is it productive to encourage more network operators to do that, as this draft does? (Section 4, "Recommendations for Network Operators" point 3.)

I would actually put money on most of those UDP rate limits being in place because of uTP Bittorrent traffic. It's dumb and it needs to stop. Nothing between two networks on the Internet should be inspecting the transport layer.

And since when has 'guilty by association' been a good reason to condemn anything?

It's not a matter of guilt. It is a practical reality of the ddos abuse on the net. It is massive and breaks network. It is all we can do to keep the net up at times. Serious.

Is the net up if we can't fully use it? UDP is an important part of the net. If we can't use it, then the net is not fully operational.

There are other ways to combat abuse than to filter out half the popular application protocols on the net. Eg start depeering ISPs who aren't swift in limiting/taking down their DoS spewing compromised customers.

How are you rate limiting UDP traffic? If it's after the traffic is on your network isn't that too late to be rate limiting?

You're absolutely right. This draft tries to pull the wool over the reader's eyes by saying "UDP allows a single packet response from an application. TCP and SCTP operate differently. TCP has a three-way handshake..." In reality, TCP is no different from UDP and will respond to a SYN packet with a spoofed source address. The reason why that's not a problem is because the response provides no amplification. So you just design your UDP-based protocol to never respond to an unauthenticated packet with a larger response and it's fine. Indeed, that's how modern UDP-based protocols are designed, since we understand this now. The only problems are with old protocols which were designed before anyone knew better.

And even old protocols like DNS over UDP are slowly improving.

https://tools.ietf.org/html/draft-ietf-dnsop-cookies-04

Yep, 100% accurate. We've actually found that our site and hardware is being used to reflectively attack third parties. Attackers send us a SYN flood with a source IP of their intended target, and we bombard the target with a flood of SYN-ACK cookie responses. Our hardware can handle line-rate SYN cookies, so we dish out whatever we take in. Sorry, but that's the nature of unsigned TCP. Maybe we should just drop TCP off the Internet, too. Right? ;)

So what are the "baseline levels" of UDP traffic your RFC refers to?

Are you willing to disclose?

"If UDP must be used encapsulate it in IPSec to avoid matching IP protocol 17 filters."

And then you are going to have problems with IPSec getting filtered?

As a UDP user, that is one sad RFC. Maybe I should just write my application to use CurveCP?

I thought that QUIC used a signed request wrapped in UDP? If it's forged, it should be pretty easy to drop at the application layer, right?

Other than that, you're still open to a volumetric attack, but that's not any different from using 1480 byte TCP SYNs. Small pipes are going to be clogged regardless.

Good to see t-mobile trying to sabotage online gaming. /s

Is that draft serious?

"Application and protocol developers should avoid using UDP. [...] has made UDP subject to aggressive filtering at the transport protocol level."

"In the case of QUIC [I-D.draft-tsvwg-quic-protocol] and other transport innovations, a new IANA assigned protocol number should be used [...]"

The whole point of using UDP for QUIC and other transport innovations, is because other protocol numbers are aggressively filtered by NAT routers and other middleboxes!

When you are in a controlled network, sure, you can use a new protocol number (as was done by SCTP). When you are designing a protocol to be used by end-users on networks you don't control, you have to use either TCP or UDP, or it won't work in many cases.

Super cool. Roundtrips are especially expensive on mobile – it'd be interesting to see their latency improvement numbers broken out by mobile vs desktop. But the deck is fairly light on how much this helps with latency in general.

Reply on news.ycombinator.com