4 ms·

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

nly 11y ago
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.
- cambyrne 11y ago
  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
  - agwa 11y ago
    > 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.)
  - nly 11y ago
    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?
    - cambyrne 11y ago
      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.
      - valleyhut 11y ago
        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.
      - zurn 11y ago
        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.
  - srj 11y ago
    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?
- agwa 11y ago
  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.
  - nly 11y ago
    And even old protocols like DNS over UDP are slowly improving. https://tools.ietf.org/html/draft-ietf-dnsop-cookies-04 https://tools.ietf.org/html/draft-ietf-dnsop-cookies-04
- scurvy 11y ago
  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? ;)
gwu78 11y ago
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?
scurvy 11y ago
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.
tacticus 11y ago
Good to see t-mobile trying to sabotage online gaming. /s
cesarb 11y ago
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.

nly 11y ago

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.

cambyrne 11y ago
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
- agwa 11y ago
  > 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.)
- nly 11y ago
  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?
  - cambyrne 11y ago
    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.
    - valleyhut 11y ago
      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.
    - zurn 11y ago
      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.
- srj 11y ago
  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?
agwa 11y ago
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.
- nly 11y ago
  And even old protocols like DNS over UDP are slowly improving. https://tools.ietf.org/html/draft-ietf-dnsop-cookies-04 https://tools.ietf.org/html/draft-ietf-dnsop-cookies-04
scurvy 11y ago
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? ;)

gwu78 11y ago

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?

scurvy 11y ago

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.

tacticus 11y ago

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

cesarb 11y ago

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.