20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours

John jw at nuclearfallout.net
Tue Jul 21 03:01:14 UTC 2015


> 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



More information about the NANOG mailing list