5 ms·

Most of the deadliest DDoS attacks happen over UDP. Spoofing, reflection and amplification just to name a few. Many businesses just deny UDP to protect themself

Most of the deadliest DDoS attacks happen over UDP. Spoofing, reflection and amplification just to name a few. Many businesses just deny UDP to protect themself against the on going DDoS threats. I feel this move won't make internet a better and safer place, but let's see.

tyingq 8y ago
That's because other UDP based protocols don't have tcp like sequence numbers or other anti-spoofing measures. Quic has a source address token that makes it hard to spoof.
- PeterisP 8y ago
  As far as I understand, the parent's point is that QUIC makes your network vulnerable to attacks from spoofed non-QUIC services because you have to allow UDP packets to reach your network - their usual practice is to protect yourself by just dropping all UDP, but as soon as you want a single system to serve QUIC, then you can't do that anymore and need to inspect all these UDP packages even if it's an extreme amount of some amplified DDoS garbage.
  - tyingq 8y ago
    Confused. You don't have to allow all UDP traffic. Just port 443 for some specific set of IP addresses.
derefr 8y ago
See https://blog.cloudflare.com/the-road-to-quic/#deflectingreflection https://blog.cloudflare.com/the-road-to-quic/#deflectingrefl...
baby 8y ago
Or let's actually read about QUIC before quickly commenting on it. QUIC uses two mechanism to make sure you cannot do such attacks: * it requires a proof of IP ownership (exactly like TCP sequence numbers) to setup a connection ID (pretty much, you're able to receive the server's response to finalize the connection) [1] * it requires the client's first message (client hello) to be padded to at least the size of the server's response. Which implies that an attacker would require as much bandwidth as is spent by the server performing the attack, making the attack as practical as the attack without QUIC. [2] [1]: https://tools.ietf.org/html/draft-ietf-quic-transport-16#section-8 https://tools.ietf.org/html/draft-ietf-quic-transport-16#sec... [2]: https://tools.ietf.org/html/draft-ietf-quic-tls-16#section-9.1 https://tools.ietf.org/html/draft-ietf-quic-tls-16#section-9...
- john37386 8y ago
  Quic is secure and doesn't allow spoofing. But, since it runs on UDP, a hacker could attack few DNS servers and amplify a UDP attack toward a Quic server. This is true for all reflection and amplification attacks. Hence, Quic is vulnerable to receive huge amplification attacks +100Gb and soon 1Tbps. It will not make internet a safer and better place. Even video game companies used to use UDP and they move away because UDP is too dangerous. They now use TCP with a kind of websocket techno to not allow UDP. Many big enterprises don't allow UDP toward their critical infrastructure.
  - Brybry 8y ago
    I'm curious, what games have moved exclusively to TCP? Most (all?) multiplayer games I play still seem to use UDP, though there is definitely more mixed TCP use than there used to be.
    - penagwin 8y ago
      Slither.io and Agar.io use exclusively TCP but that's only because browsers don't allow you to send/receive UDP packets. If you've ever played those games on any network or device with shaky internet then you'll know those games have lag issues, and the only way to optimize it more would be to switch to UDP (Which they can't)
      - gsich 8y ago
        I am not sure if that is what your parent meant by "games". If you want to talk about browsergames, you usually add the term "browser".
    - drawkbox 8y ago
      Indeed, nearly all FPS/MMO/RTS games are realtime and need UDP, only some messages need to be reliable/ACK'd or ordered and TCP is overkill except for turn based games. Real-time games have to be UDP or more typically a variation of Reliable UDP (RUDP) [1]. Many networking kits are based on reliable UDP and common early implementations as the core/base of their network layers such as enet [2] or RakNet [3] (Unity, Unreal, Sony, Oculus and more). RUDP or variants are UDP with channels, ordering, priority as well as ACKs where needed for reliable/must deliver messages through the use of a return UDP ACK datagram for verification. Reliable UDP is a set of service enhancement such as congestion control, retransmission, thinning server algorithms that allow a Real-time Transport Protocol (RTP) for media broadcasts even in the presence of packet loss and network congestion. Reliable UDP ACKS are used commonly in areas like global events such as game start, game end, player entered, player died, player hit etc, all other positioning/action is UDP broadcast with dropped packets lerped [5] and slerped [6] out with interpolation [7] and extrapolation to deal with lag compensation [8] and client prediction [9][10][11]. Sometimes this also involves channels and grid/graph areas where only messages to players around you or in that area are required to ACK when needed i.e. player hit/death. Most large real-time games are just UDP broadcast for 99% of action. TCP is almost never used in real-time action games like FPS, MMO, RTS etc. Rarely are TCP and UDP combined, rather RUDP or later something like SCTP, allows streaming/real-time capable broadcasts with enough verification/reliable messages where needed. Combining TCP and UDP can end up with queuing issues that affect both TCP and UDP traffic [4] so most games just go with reliable variant of UDP. Gaffer on Games has a good section on why UDP is used in games [12] > The web is built on top of TCP, which is a reliable-ordered protocol. > To deliver data reliably and in order under packet loss, it is necessary for TCP to hold more recent data in a queue while waiting for dropped packets to be resent. Otherwise, data would be delivered out of order. > This is called head of line blocking and it creates a frustrating and almost comedically tragic problem for game developers. The most recent data they want is delayed while waiting for old data to be resent, but by the time the resent data arrives, it’s too old to be used. > Unfortunately, there is no way to fix this behavior under TCP. All data must be received reliably and in order. Therefore, the standard solution in the game industry for the past 20 years has been to send game data over UDP instead. > How this works in practice is that each game develops their own custom protocol on top of UDP, implementing basic reliability as required, while sending the majority of data as unreliable-unordered. This ensures that time series data arrives as quickly as possible without waiting for dropped packets to be resent. > So, what does this have to do with web games? The main problem for web games today is that game developers have no way to follow this industry best practice in the browser. Instead, web games send their game data over TCP, causing hitches and non-responsiveness due to head of line blocking. > This is completely unnecessary and could be fixed overnight if web games had some way to send and receive UDP packets. [1] https://www.ietf.org/proceedings/44/I-D/draft-ietf-sigtran-reliable-udp-00.txt https://www.ietf.org/proceedings/44/I-D/draft-ietf-sigtran-r... [2] http://enet.bespin.org/ http://enet.bespin.org/ [3] https://en.wikipedia.org/wiki/RakNet https://en.wikipedia.org/wiki/RakNet [4] https://web.archive.org/web/20180704154418/https://www.isoc.org/inet97/proceedings/F3/F3_1.HTM https://web.archive.org/web/20180704154418/https://www.isoc.... [5] https://en.wikipedia.org/wiki/Linear_interpolation https://en.wikipedia.org/wiki/Linear_interpolation [6] https://en.wikipedia.org/wiki/Slerp https://en.wikipedia.org/wiki/Slerp [7] https://developer.valvesoftware.com/wiki/Interpolation https://developer.valvesoftware.com/wiki/Interpolation [8] https://developer.valvesoftware.com/wiki/Lag_compensation https://developer.valvesoftware.com/wiki/Lag_compensation [9] https://developer.valvesoftware.com/wiki/Prediction https://developer.valvesoftware.com/wiki/Prediction [10] https://gafferongames.com/post/snapshot_compression/ https://gafferongames.com/post/snapshot_compression/ [11] https://gafferongames.com/post/snapshot_interpolation/ https://gafferongames.com/post/snapshot_interpolation/ [12] https://gafferongames.com/post/why_cant_i_send_udp_packets_from_a_browser/ https://gafferongames.com/post/why_cant_i_send_udp_packets_f...

tyingq 8y ago

That's because other UDP based protocols don't have tcp like sequence numbers or other anti-spoofing measures. Quic has a source address token that makes it hard to spoof.

PeterisP 8y ago
As far as I understand, the parent's point is that QUIC makes your network vulnerable to attacks from spoofed non-QUIC services because you have to allow UDP packets to reach your network - their usual practice is to protect yourself by just dropping all UDP, but as soon as you want a single system to serve QUIC, then you can't do that anymore and need to inspect all these UDP packages even if it's an extreme amount of some amplified DDoS garbage.
- tyingq 8y ago
  Confused. You don't have to allow all UDP traffic. Just port 443 for some specific set of IP addresses.

derefr 8y ago

See https://blog.cloudflare.com/the-road-to-quic/#deflectingreflection https://blog.cloudflare.com/the-road-to-quic/#deflectingrefl...

baby 8y ago

Or let's actually read about QUIC before quickly commenting on it. QUIC uses two mechanism to make sure you cannot do such attacks: * it requires a proof of IP ownership (exactly like TCP sequence numbers) to setup a connection ID (pretty much, you're able to receive the server's response to finalize the connection) [1] * it requires the client's first message (client hello) to be padded to at least the size of the server's response. Which implies that an attacker would require as much bandwidth as is spent by the server performing the attack, making the attack as practical as the attack without QUIC. [2] [1]: https://tools.ietf.org/html/draft-ietf-quic-transport-16#section-8 https://tools.ietf.org/html/draft-ietf-quic-transport-16#sec... [2]: https://tools.ietf.org/html/draft-ietf-quic-tls-16#section-9.1 https://tools.ietf.org/html/draft-ietf-quic-tls-16#section-9...

john37386 8y ago
Quic is secure and doesn't allow spoofing. But, since it runs on UDP, a hacker could attack few DNS servers and amplify a UDP attack toward a Quic server. This is true for all reflection and amplification attacks. Hence, Quic is vulnerable to receive huge amplification attacks +100Gb and soon 1Tbps. It will not make internet a safer and better place. Even video game companies used to use UDP and they move away because UDP is too dangerous. They now use TCP with a kind of websocket techno to not allow UDP. Many big enterprises don't allow UDP toward their critical infrastructure.
- Brybry 8y ago
  I'm curious, what games have moved exclusively to TCP? Most (all?) multiplayer games I play still seem to use UDP, though there is definitely more mixed TCP use than there used to be.
  - penagwin 8y ago
    Slither.io and Agar.io use exclusively TCP but that's only because browsers don't allow you to send/receive UDP packets. If you've ever played those games on any network or device with shaky internet then you'll know those games have lag issues, and the only way to optimize it more would be to switch to UDP (Which they can't)
    - gsich 8y ago
      I am not sure if that is what your parent meant by "games". If you want to talk about browsergames, you usually add the term "browser".
  - drawkbox 8y ago
    Indeed, nearly all FPS/MMO/RTS games are realtime and need UDP, only some messages need to be reliable/ACK'd or ordered and TCP is overkill except for turn based games. Real-time games have to be UDP or more typically a variation of Reliable UDP (RUDP) [1]. Many networking kits are based on reliable UDP and common early implementations as the core/base of their network layers such as enet [2] or RakNet [3] (Unity, Unreal, Sony, Oculus and more). RUDP or variants are UDP with channels, ordering, priority as well as ACKs where needed for reliable/must deliver messages through the use of a return UDP ACK datagram for verification. Reliable UDP is a set of service enhancement such as congestion control, retransmission, thinning server algorithms that allow a Real-time Transport Protocol (RTP) for media broadcasts even in the presence of packet loss and network congestion. Reliable UDP ACKS are used commonly in areas like global events such as game start, game end, player entered, player died, player hit etc, all other positioning/action is UDP broadcast with dropped packets lerped [5] and slerped [6] out with interpolation [7] and extrapolation to deal with lag compensation [8] and client prediction [9][10][11]. Sometimes this also involves channels and grid/graph areas where only messages to players around you or in that area are required to ACK when needed i.e. player hit/death. Most large real-time games are just UDP broadcast for 99% of action. TCP is almost never used in real-time action games like FPS, MMO, RTS etc. Rarely are TCP and UDP combined, rather RUDP or later something like SCTP, allows streaming/real-time capable broadcasts with enough verification/reliable messages where needed. Combining TCP and UDP can end up with queuing issues that affect both TCP and UDP traffic [4] so most games just go with reliable variant of UDP. Gaffer on Games has a good section on why UDP is used in games [12] > The web is built on top of TCP, which is a reliable-ordered protocol. > To deliver data reliably and in order under packet loss, it is necessary for TCP to hold more recent data in a queue while waiting for dropped packets to be resent. Otherwise, data would be delivered out of order. > This is called head of line blocking and it creates a frustrating and almost comedically tragic problem for game developers. The most recent data they want is delayed while waiting for old data to be resent, but by the time the resent data arrives, it’s too old to be used. > Unfortunately, there is no way to fix this behavior under TCP. All data must be received reliably and in order. Therefore, the standard solution in the game industry for the past 20 years has been to send game data over UDP instead. > How this works in practice is that each game develops their own custom protocol on top of UDP, implementing basic reliability as required, while sending the majority of data as unreliable-unordered. This ensures that time series data arrives as quickly as possible without waiting for dropped packets to be resent. > So, what does this have to do with web games? The main problem for web games today is that game developers have no way to follow this industry best practice in the browser. Instead, web games send their game data over TCP, causing hitches and non-responsiveness due to head of line blocking. > This is completely unnecessary and could be fixed overnight if web games had some way to send and receive UDP packets. [1] https://www.ietf.org/proceedings/44/I-D/draft-ietf-sigtran-reliable-udp-00.txt https://www.ietf.org/proceedings/44/I-D/draft-ietf-sigtran-r... [2] http://enet.bespin.org/ http://enet.bespin.org/ [3] https://en.wikipedia.org/wiki/RakNet https://en.wikipedia.org/wiki/RakNet [4] https://web.archive.org/web/20180704154418/https://www.isoc.org/inet97/proceedings/F3/F3_1.HTM https://web.archive.org/web/20180704154418/https://www.isoc.... [5] https://en.wikipedia.org/wiki/Linear_interpolation https://en.wikipedia.org/wiki/Linear_interpolation [6] https://en.wikipedia.org/wiki/Slerp https://en.wikipedia.org/wiki/Slerp [7] https://developer.valvesoftware.com/wiki/Interpolation https://developer.valvesoftware.com/wiki/Interpolation [8] https://developer.valvesoftware.com/wiki/Lag_compensation https://developer.valvesoftware.com/wiki/Lag_compensation [9] https://developer.valvesoftware.com/wiki/Prediction https://developer.valvesoftware.com/wiki/Prediction [10] https://gafferongames.com/post/snapshot_compression/ https://gafferongames.com/post/snapshot_compression/ [11] https://gafferongames.com/post/snapshot_interpolation/ https://gafferongames.com/post/snapshot_interpolation/ [12] https://gafferongames.com/post/why_cant_i_send_udp_packets_from_a_browser/ https://gafferongames.com/post/why_cant_i_send_udp_packets_f...