TCP packets travel at the same speed as udp.
I will go into more detail. TCP is designed to be a reliable protocol. When a packet is lost, TCP reduces the transfer rate and retransmits the packet. If enough packets are lost, the connection is reset entirely. This is not desirable with a video game, where game state is being constantly refreshed already; retransmissions are redundant, and the developer wants to control when the connection is considered unsalvageable. There are also other factors. A game developer could go into more detail with you on this (I am not involved with such decisions), but the simple fact is that UDP is used almost exclusively with fast-action video games. That definitely won't change for already-released games and it's unlikely to change in the near future for new games.
Your level of tcp window pacing is relevant to your congestion algo. There is also sctp ....
Yes, but the game developers want to control the way that congestion is handled, without trying to turn global knobs in the OS that may not even be exposed.
I noticed you did not include today's reported udp1720.
UDP port 1720 was the destination port here, not the source port. As I understand it, the attack did not involve reflection and this is not a common target. His problem was mostly that a botnet was sending him attack traffic, not that it was using a specific protocol or port (those are just variables that the attacker could adjust -- and botnet users certainly will adjust to TCP if UDP starts seeing more rate-limiting). Blocking a destination service port like this would be akin to blocking TCP port 80 in response to an attack that involves spoofed TCP SYN traffic to port 80. That might be appropriate in some circumstances, such as if the victim is not a webserver, but it's not generally a good idea to limit it globally, and it's even less of a good idea to limit TCP overall.
Somebody took it on the chin because they did not rate limit that port. Tomorrow it will be a different port.
It is not the case that high-amplification-factor UDP services are discovered on a daily basis -- or anything close to that.
What is the attack bandwidth volume ratio you see between tcp and udp? Mine is nearly 100% udp, but i have an eyeball network
Attackers usually turn to UDP first, and if they use a spoofing traffic source, the preferred vector will usually be amplification using one of the big three -- NTP, DNS, or SSDP. When this fails, they will often turn to TCP attacks, or application-specific attacks. Those with botnets often use TCP SYN or small UDP packets to start. My networks have a large component of game server traffic, so at least 75% of legitimate traffic that we see is also UDP. I would expect to see most attacks here also use UDP, just because attackers frequently choose the protocol vector to match the service.
But it is udp, so it is not orthogonal and would hit the bitbucket on protocol level policer without anyone opening a ticket or getting pages.
A policer would degrade any UDP application and he'd probably have even more trouble tickets from customers than he would from just immediately null-routing the target IP addresses. Such tickets would could be a bit more complicated to troubleshoot, as staff and customers may not expect a UDP rate-limit to be the cause. My main point is that an overall UDP rate-limit is not a good idea for most networks -- and certainly not eyeball networks -- and we don't want to encourage it. Rate-limits (or other rules) on specific ports that are used in amplification attacks, however, might make a lot of sense, depending on the network. Potentially, an overall UDP rate-limit on individual users might also make sense (if those users are known to not need to use UDP).
This draft is not trying to deperecate udp. It is simply illuminating a situation and a trend and providing advice. As a network operator, my concern is that protocols doing cool things like quic and webrtc will grow very quickly on udp and the signal will mix with ddos noise in such a way that i cannot tease them apart.
My concerns with this document, and the sentiment behind it, are primarily twofold. 1. Network operators may see it and think that an overall network-wide rate-limit UDP is a good idea, when there are much smarter mitigation options available. 2. Developers may read the document, consider UDP deprecated, and start to redevelop their libraries to use other protocols that may not be the right fit or might have a higher cost to develop. This unnecessarily burdens them. Right now, I haven't heard a lot of organizations tell me that they're rate-limiting UDP overall, thankfully. I really don't want it to start, and I hate to think that this sort of exposure might encourage that decision to be made more widely. Network operators reading this, please don't blanket rate-limit UDP across your network!
Today, i rate limit udp with a sledge hammer just to keep the network up. If you say i have to rate limit with a scalpel, that probably wont work.
If you have an eyeball network that might have any gamers on it, you should consider switching to just a regular hammer, by limiting the major amplification vectors instead of UDP overall. At the very least, limit commonly-used reflection ports in an earlier rule, to pull out just the reflection traffic before resorting to the sledge. -John