Live data from Hacker News

QUIC experiments [pdf]

ietf.org

1–10 of 20 posts

Re: QUIC experiments [pdf]

#2
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.

Re: QUIC experiments [pdf]

#4
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, nothing stops DoS botnets from sending junk TCP packets.

Re: QUIC experiments [pdf]

#5
post #4
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…

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

Re: QUIC experiments [pdf]

#6
post #5
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

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

Re: QUIC experiments [pdf]

#7
post #5
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

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?

Re: QUIC experiments [pdf]

#8

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. :)

Re: QUIC experiments [pdf]

#9
post #4
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…

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.

Re: QUIC experiments [pdf]

#10
post #7
post #5

Earlier quoted context omitted.

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

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