3

I am building a service that I can implement equally well with either TCP or UDP. If I use TCP, I expose vulnerability to SYN flood and other attacks on TCP protocol. If I use UDP, it will be harder to block UDP flood upstream without also blocking my legitimate traffic. Is there a clear choice here? I am inclined toward UDP because bandwidth exhaustion attacks impact others on the network so I expect will become increasingly difficult, e.g., with less tolerance for address spoofing and fewer services available to amplify traffic.

5

When choosing TCP and UDP, you need to look beyond simply security. Without knowing the details of what you're trying to design it's impossible to make a recommendation of which protocol to use.

Consider these basic facts.

  • TCP requires a 3 way handshake to setup the connection, preventing many spoofing attacks based on IP address.

  • TCP can use an SSL connection if you ever needed to add encryption.

  • UDP requires less resources on the server end to keep track of
    sockets.

  • In my view, any protocol for the public Internet needs a 3-way handshake to deal with address spoofing. But, with UDP you can do this with a cryptographic token instead of creating state on the server and being vulnerable to SYN flood style attack. Also, with UDP I can require that the token request packet be e.g., 1000 bytes, so attacker must consume more bandwidth to request token than server sends out in return. – user1055568 Oct 5 '15 at 18:31
  • @user1055568 Yup. You can build it into UDP if you like, but it's free and well tested in TCP. It's just all about tradeoffs. – Steve Sether Oct 5 '15 at 19:22
  • Yes, well tested and proven to be vulnerable to SYN flood attacks more than 20 years ago. – user1055568 Oct 5 '15 at 20:41
  • I guess you are aware of SYN cookies? They are implemented in commonplace OS and aren't new either, they have been proposed at least 19 years ago. – Ángel Oct 5 '15 at 21:23
  • 2
    You can use tls over udp, too. It's called DTLS or Datagram tls. – atk Oct 6 '15 at 0:14
1

The choice of UDP vs TCP depends on your use case and of the kind of DDos. For simple bandwidth-eating DDos it does not matter much because if all bandwidth is used by the attack there will be no more traffic for your application, no matter if UDP or TCP based. UDP might have a slight advantage in this case because UDP by itself does not need multiple packets for a connection establishment (but your application protocol might need it).

If you care more about attacks eating resources on the system (like SYN flooding or simply keeping lots of connections open) UDP might look better at first since it does not use as much resources in the system as TCP does. But if your application needs some idea of connection, of reliability and ordered data transfer you end up implementing all the nice things TCP already has within your application. And there they will probably take up more resources than the optimized implementations within the OS kernel, which means that you end up being more affected by DDos than if you would simply use TCP.

Also, by using established technologies instead of doing you own application level network handling you can use existing Anti-DDos solutions. With your own special protocol instead you would need to invent your own special Anti-DDos solution too.

I am building a service that I can implement equally well with either TCP or UDP.

If you can implement the same service with the same reliability in UDP and TCP and your UDP implementation would use less system resources than the TCP implementation (i.e. kernel and user space resources combined) then you might go for UDP because using less resources is a good think when confronted with DDos.

  • Any idea about relative prevalence of simple bandwidth eating attacks versus higher level? – user1055568 Oct 5 '15 at 18:39
  • @user1055568: I don't have any statistics but I also don't think that they would help much. If somebody wants to attack you he chooses the attack which hurts you and not the one most widely used. – Steffen Ullrich Oct 5 '15 at 19:13
  • @user1055568 Statistics would be kind of pointless since attackers will always adapt to the holes in the system. Stats can only tell you about what people WERE doing, not what they can do, or are doing now. Several years ago nobody went after Java plugin bugs. Now it's a trend. The same bugs were in Java at that time to exploit, but it wasn't trendy to do so. – Steve Sether Oct 5 '15 at 19:27
  • UDP reflection attacks would not be possible if ISP's were blocking spoofed IP addresses or if there were no public services to blindly reply with amplified data. The statistics are interesting because they indicate to what extent these attack vectors are being closed off. Since there is essentially no defense against a bandwidth attack, I would expect it to be the method of choice unless it is becoming too hard to do. – user1055568 Oct 5 '15 at 20:50
  • @user1055568: there are several defenses against bandwidth attacks. Having a high bandwidth itself and a quick way to filter packets upstream helps a lot and there are providers offering such services. And UDP reflection is not the only bandwidth attack, botnets are another one but especially botnets can also be used for application level attacks to exhaust server resources. – Steffen Ullrich Oct 5 '15 at 21:17
0

I think you are overthinking. You are screwed when it comes to DDOS, either you pick UDP or TCP. If you have no anti-DDOS appliance or service stopping the flood before it reaches your service, there is nothing you can do aside from dropping packets locally. You did not specify the requirements of your application which leads me to provide a generic answer:

  • If your application requires no long communications and you are willing to lose packets use UDP. Client sends request, you respond, and you are done(e.g. chargen). Less overhead added by unnecessary handshakes.
  • If you need to exchange session information and need reliability, go for TCP (e.g. HTTP).

There is no one size fits all. Even the solutions i gave you are not generic enough: you could use UDP to communicate using HTTP (why not?).

What i would suggest is pick your poison: TCP or UDP and then use a firewall to limit the amount of syn requests using limit: http://www.cyberciti.biz/tips/howto-limit-linux-syn-attacks.html.

There is a technique called SYN cookies to prevent this kind of issues that you can enable in Linux:http://www.cyberciti.biz/faq/enable-tcp-syn-cookie-protection/

Still, as i said, if your you have no external appliance sinking the DDOS traffic (blackhole) or your ISP/service provider preventing the flood, don't even bother about protecting the application/machine on your own. You will probably protect your application from crashing if you drop packets but you won't be able to serve any requests, which is the essence of the DDOS (Distributed Denial of Service).

Stay safe ;)

  • AES will run at Gbits/sec on modern processors, so I think it is plausible for well designed protocols to detect and drop bogus packets and continue offering the service, unless the inbound link is saturated. But, in that case, the inbound link to the firewall is probably saturated too, so it is no help. – user1055568 Oct 5 '15 at 20:59
  • @user1055568 that looks like numbers for a continuous encryption. If you are handling different users, you would need a different key for each, and in AES the key initialization is (relatively) expensive. – Ángel Oct 5 '15 at 21:27
  • @user1055568 don't forget that CPUs have dedicated modules and lightweight implementations of AES (in hardware is fast). What happens in DDOS is that your link/immediate router/immediate switch will be clogged with traffic. You can still drop the packets but it wouldn't help much. It is like having a queue for people complaining and for people buying. You can just drop the complainers but they are still filling the queue :P – BrunoMCBraga Oct 6 '15 at 10:05
  • @Ángel, yes, those rates are for continuous encryption. However, a 3-way UDP handshake token requires only a single key. E.g. client requests token, server returns time-stamp + observed ip address + fast mac over those values; all subsequent client requests must include this token. If all inbound packets less than some fixed size, e.g., 1KB, are automatically dropped, then you need just a few AES block encryptions per KB inbound to filter down to handshake completions. – user1055568 Oct 6 '15 at 16:46
  • @BrunoMCBraga, I was wondering in that scenario where you need to ask for upstream filtering, whether it is a serious liability to be using UDP, which I otherwise prefer for the reasons mentioned here. – user1055568 Oct 6 '15 at 16:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.