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
