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

QUIC experiments [pdf]

ietf.org

Post reply on HN
Print view View original

11–20 of 20 posts

Re: QUIC experiments [pdf]

#11

Post by nly »

agwa wrote: post #9
nly wrote: post #4

Earlier quoted context omitted.

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, nothi…

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 jus…

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

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

Re: QUIC experiments [pdf]

#12

Post by gwu78 »

cambyrne wrote: post #3

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

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?

Re: QUIC experiments [pdf]

#13

Post by srj »

cambyrne wrote: post #5
nly wrote: post #4

Earlier quoted context omitted.

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, nothi…

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

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?

Re: QUIC experiments [pdf]

#14

Post by valleyhut »

cambyrne wrote: post #10
nly wrote: post #7

Earlier quoted context omitted.

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.

Re: QUIC experiments [pdf]

#15

Post by scurvy »

cambyrne wrote: post #3

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

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.

Re: QUIC experiments [pdf]

#16

Post by bla2 »

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.

Re: QUIC experiments [pdf]

#17

Post by scurvy »

nly wrote: post #4
cambyrne wrote: post #3

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, nothi…

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? ;)

Re: QUIC experiments [pdf]

#19

Post by zurn »

cambyrne wrote: post #10
nly wrote: post #7

Earlier quoted context omitted.

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.

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.

Re: QUIC experiments [pdf]

#20

Post by cesarb »

cambyrne wrote: post #3

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

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.

Post reply on HN