Recent denial-of-service attacks taking down League of Legends and other popular gaming services are doing more than just wielding a rarely-seen technique to vastly amplify the amount of junk traffic directed at targets. In at least some cases, their devastating effects can deprive celebrity game players of huge amounts of money.

As Ars reported last week, the attacks are abusing the Internet's Network Time Protocol (NTP), which is used to synchronize computers to within a few milliseconds of Coordinated Universal Time. A command of just 234 bytes is enough to cause some NTP servers to return a list of up to 600 machines that have previously used its time-syncing service. The dynamic creates an ideal condition for DoS attacks. Attackers send a modest-sized request to NTP servers and manipulate the commands to make them appear as if they came from one of the targeted gaming services. The NTP servers, which may be located in dozens or even hundreds of locations all over the world, in turn send the targets responses that could be tens or hundreds of times bigger than the spoofed request. The technique floods gaming servers with as much as 100Gbps, all but guaranteeing that they'll be taken down unless operators take specific precautions ahead of time.

Among the recent targets of this type of attack are game servers used by celebrity players who broadcast live video streams of their gaming prowess that are viewed as many as 50,000 times. In some cases, the massive audiences translate into tens of thousands of dollars per month, as ads are displayed beside video feeds of the players blowing away opponents in Dota 2 and other games.

"These people generate revenue using game servers, so when they're attacked it creates dramatic financial loss for them," said Matt Mahvi, CEO and founder of Staminus, a service that blocks more than 100,000 DoS attacks each month. "I can see that our customers were streaming [and] their game servers were being attacked. I'm seeing these massive, massive attacks that come in against our customers."

Mahvi said that over the past month or so the vast majority of DoS campaigns reaching 40Gbps and above have relied on NTP abuse. In the past, such "volumetric" attacks—meaning those that rely on massive volumes of data to overwhelm their targets—were mostly made possible through so-called DNS amplification techniques. This much older and better-known method allows attackers to magnify attacks by a factor of about eight. It works by sending IP lookup requests with spoofed source addresses to open domain name system servers, which in turn bombard targets with lengthy replies. Late last year, the NTP technique came into vogue, possibly as many DoS victims learned how to better defend against the DNS attacks.

Enlarge/ A graph showing a 90-Gbps attack on one Staminus customer. Staminus CEO Matt Mahvi said some attacks approach or exceed 100 Gbps.

Staminus

"What we have is a situation where the very large volumetric attacks have a high tendency of being NTP-based floods right now," Mahvi said. "The second aspect to this is that whoever is doing this or has access to these floods seems to also have access to very, very large TCP based attacks as well. So what we're seeing is a flip between volumetric and high-packet per second attacks."

The combination of NTP attacks and TCP packets have been directed at a variety of Staminus customers in recent weeks, including including several popular top Minecraft servers and Minecraft celebrity streamers, whom Mahvi declined to identify by name. The player frequently streams his online playing in channels that attract huge numbers of viewers. Attacks that disrupt the player appear similar to those that recently targeted PhantomL0rd, a popular League of Legends player who regularly broadcasts his gameplay over Twitch TV.

The amount of amplification available through NTP-based attacks depends on several variables, including the specific server that's being abused and the command an attacker chooses. John Graham-Cumming, a researcher at DoS protection service Cloudflare, said typical attacks amplify a 234-byte request sent by an attacker into a response split across 10 packets that totals 4,460 bytes.

"That's an amplification factor of 19x, and because the response is sent in many packets, an attack using this would consume a large amount of bandwidth and have a high packet rate," Graham-Cumming wrote late last week. NTP Servers that are particularly popular could potentially do much more damage. Using the MON_GETLIST command to cause it to send the addresses of the past 600 computers that have interacted with the server, the amplification factor could reach about 206.

Promoted Comments

I work for a large HS district in NJ & were getting killed with this type of attack for about 20-30 min everyday around noon. When it hits were seeing 10gb+ per second......

We have spent the better part of 2 weeks trying to figure out who would, could, and why its happening. Hard to believe a disgruntled HS student could pull this off. For what its worth this is not an easy thing to defend against. Especially if you actually need to use NTP servers......

edit:Yes we've gone to the ISP for assistance, but all they offer us is add on services($$$) to defend against it. They won't even just block NTP to our circuit.

If all ISPs would enable Urpf ( Unicast Reverse Path Forwarding ), these kind of attacks using spoofed source IPs would simply not be possible. The packets would be dropped at the source.

Out of curiosity, is there any reason to allow spoofed source IPs in packets?

It has to do with two different protocols. Most of what you do on the web uses TCP, which requires what is known as a TCP handshake to establish identity and create the connection. Some things, however, use a different protocol called UDP. This is a connectionless protocol. Meaning there is no way for the server to know where the packet came from once it has been routed. The server simply sends the reply to the IP address in the packet. Other protocols that you use every day like NTP, DNS, HTTP, HTTPS all either run over UDP or TCP. NTP and DNS are good for flooding attacks because they both run on UDP. Spoof the address and unless measures are taken the reply will head wherever you take it. And like this article says, you can create queries that cause comparatively massive replies. So in reality, no one is allowing it. It is just a nature of the underlying protocol. And if you are wondering why you would use UDP instead, it has to do with overhead. Setting up and maintaining TCP connections is a drain on both processor and network resources.

*Removed word for clarity

23 posts | registered Jul 2, 2012

Latest Ars Video >

War Stories | Thief: The Dark Project

1998's Thief: The Dark Project was a pioneer for the stealth genre, utilizing light and shadow as essential gameplay mechanics. The very thing that Thief became so well-known for was also the game's biggest development hurdle. Looking Glass Studios founder Paul Neurath recounts the difficulties creating Thief: The Dark Project, and how its AI systems had to be completely rewritten years into development.

War Stories | Thief: The Dark Project

War Stories | Thief: The Dark Project

1998's Thief: The Dark Project was a pioneer for the stealth genre, utilizing light and shadow as essential gameplay mechanics. The very thing that Thief became so well-known for was also the game's biggest development hurdle. Looking Glass Studios founder Paul Neurath recounts the difficulties creating Thief: The Dark Project, and how its AI systems had to be completely rewritten years into development.

Does the purpose of the attacks appear to be extorting the pro gamers?

No, it's just trolls. Most popular streamers have had to stream from behind DOS protection proxies for almost two years now (it got really bad around the launch of D3), but the tactic of taking down entire games is relatively new.

If all ISPs would enable Urpf ( Unicast Reverse Path Forwarding ), these kind of attacks using spoofed source IPs would simply not be possible. The packets would be dropped at the source.

What sort of performance (latency, CPU, memory) overhead would URPF introduce into the ISP's routers/firewalls? Would it be significant enough that it might cause issues for ISPs? Or does CISCO & co only include URPF in certain devices?

I'm just curious whether there might be a slightly justifiable reason that ISPs aren't enabling it, or if the reason is merely that they're too damn lazy to care.

I can't help but associate that with "Huge douchenozzle"...I blame PewDiePie for that...

He's the biggest YouTube personality, but that's mainly because his demographic (preteens/teens) lines up directly with the people who are most comfortable with internet video. He's not representative of the whole of internet broadcasters, or even most of the successful ones (although he's actually a good guy, his show persona is just intolerably annoying).

They typically have a niche, either in a specific game or a style of play (min-maxing, speedrunning, roguelikes, hell platformers, etc), and cater to that extensively. I strongly suggest checking out the top streams on Twitch if you want a good cross section of what streamers are like. Some are there just for the game (Kripparian, Trump, most LoL pros), and some of them are there mainly as entertainers (ManVsGame, Towelliee, Lethalfrag), but there's generally something for everyone. It's harder to find exactly what you want on YouTube because of the vast quantity of content, but chance are there's someone doing videos on your type of games in a style you will like.

If all ISPs would enable Urpf ( Unicast Reverse Path Forwarding ), these kind of attacks using spoofed source IPs would simply not be possible. The packets would be dropped at the source.

What sort of performance (latency, CPU, memory) overhead would URPF introduce into the ISP's routers/firewalls? Would it be significant enough that it might cause issues for ISPs? Or does CISCO & co only include URPF in certain devices?

I'm just curious whether there might be a slightly justifiable reason that ISPs aren't enabling it, or if the reason is merely that they're too damn lazy to care.

Only the higher-end routers can do uRPF in hardware. And there is certainly a performance impact.For routers with subscriber connected to it (BRAS, BNG) it is recommended to enable uRPF on them to protect yourself and the internet as a whole. On upstream routers, the use of uRPF can be tricky due to false positives, causing legitimate traffic to be dropped.

Everytime I hear about something going on in the LoL community, that stereotype is reinforced. It seems like pro gaming elevates the most arrogant and thoughtless people to the top.

I thought money and fame always does this?

I don't think that's true. And anyway it's not just the pros, gaming in general (and the internet, I guess) seems to have some big socialization problems. The comments you see when women stream... ugh.

If all ISPs would enable Urpf ( Unicast Reverse Path Forwarding ), these kind of attacks using spoofed source IPs would simply not be possible. The packets would be dropped at the source.

Could you please explain further? I am always astounded by these kinds of attacks. Being someone who is almost tech-illiterate I am impressed and confused at the same time! Also, if such a solution is possible, why has it not been implemented?

I work for a large HS district in NJ & were getting killed with this type of attack for about 20-30 min everyday around noon. When it hits were seeing 10gb+ per second......

We have spent the better part of 2 weeks trying to figure out who would, could, and why its happening. Hard to believe a disgruntled HS student could pull this off. For what its worth this is not an easy thing to defend against. Especially if you actually need to use NTP servers......

edit:Yes we've gone to the ISP for assistance, but all they offer us is add on services($$$) to defend against it. They won't even just block NTP to our circuit.

Why haven't web server evolved to handle DOS attacks?(not the NTP IP spoofing attack) eg. If a web server see's 10 syn packets, reply back to all of them with syn-acks, and then if it doesn't see a response from any of the 10 within say a few seconds, close the 10 connections, add this host to a deny list for 24 hours, and do the same for every host that tries this half open attack? now when one of these hosts tries more dos attacks, the packets are dropped straight away, but I'm guessing it not that easy, and if it was it'd be implemented already.

If all ISPs would enable Urpf ( Unicast Reverse Path Forwarding ), these kind of attacks using spoofed source IPs would simply not be possible. The packets would be dropped at the source.

Out of curiosity, is there any reason to allow spoofed source IPs in packets?

The word "Spoof" in this context means to fake an IP address. So the NTP server only thinks it's getting a request from the game servers. The nature of spoofing means that it's extremely difficult or impossible to detect a spoofed IP vs. a legitimate one.

If all ISPs would enable Urpf ( Unicast Reverse Path Forwarding ), these kind of attacks using spoofed source IPs would simply not be possible. The packets would be dropped at the source.

Out of curiosity, is there any reason to allow spoofed source IPs in packets?

It has to do with two different protocols. Most of what you do on the web uses TCP, which requires what is known as a TCP handshake to establish identity and create the connection. Some things, however, use a different protocol called UDP. This is a connectionless protocol. Meaning there is no way for the server to know where the packet came from once it has been routed. The server simply sends the reply to the IP address in the packet. Other protocols that you use every day like NTP, DNS, HTTP, HTTPS all either run over UDP or TCP. NTP and DNS are good for flooding attacks because they both run on UDP. Spoof the address and unless measures are taken the reply will head wherever you take it. And like this article says, you can create queries that cause comparatively massive replies. So in reality, no one is allowing it. It is just a nature of the underlying protocol. And if you are wondering why you would use UDP instead, it has to do with overhead. Setting up and maintaining TCP connections is a drain on both processor and network resources.

Why haven't web server evolved to handle DOS attacks?(not the NTP IP spoofing attack) eg. If a web server see's 10 syn packets, reply back to all of them with syn-acks, and then if it doesn't see a response from any of the 10 within say a few seconds, close the 10 connections, add this host to a deny list for 24 hours, and do the same for every host that tries this half open attack? now when one of these hosts tries more dos attacks, the packets are dropped straight away, but I'm guessing it not that easy, and if it was it'd be implemented already.

Well, at the webserver end, he'd be adding all the NTP severs to a 24 hr deny list, which might be a problem depending on how critical time sync is for your webserver.

Honestly, we should thank the kiddies who do this: their providing excellent impetus to close some longstanding vulnerabilities in basic IP services. Already, we're seeing them having to resort to NTP, which looks to be far less effective the DNS attacks from a few years ago, so they've already created a better, more robust internet.

Does the purpose of the attacks appear to be extorting the pro gamers?

No, it's just trolls. Most popular streamers have had to stream from behind DOS protection proxies for almost two years now (it got really bad around the launch of D3), but the tactic of taking down entire games is relatively new.

Interesting. You wonder that they can't think of a more appropriate target, though.

If all ISPs would enable Urpf ( Unicast Reverse Path Forwarding ), these kind of attacks using spoofed source IPs would simply not be possible. The packets would be dropped at the source.

Out of curiosity, is there any reason to allow spoofed source IPs in packets?

It has to do with two different protocols. Most of what you do on the web uses TCP, which requires what is known as a TCP handshake to establish identity and create the connection. Some things, however, use a different protocol called UDP. This is a connectionless protocol. Meaning there is no way for the server to know where the packet came from once it has been routed. The server simply sends the reply to the IP address in the packet. Other protocols that you use every day like NTP, DNS, HTTP, HTTPS all either run over UDP or TCP. NTP and DNS are good for flooding attacks because they both run on UDP. Spoof the address and unless measures are taken the reply will head wherever you take it. And like this article says, you can create queries that cause comparatively massive replies. So in reality, no one is allowing it. It is just a nature of the underlying protocol. And if you are wondering why you would use UDP instead, it has to do with overhead. Setting up and maintaining TCP connections is a drain on both processor and network resources.

*Removed word for clarity

Don't neglect latency when explaining UDP: it's one of the key reasons it's used in most modern implementations.

Why haven't web server evolved to handle DOS attacks?(not the NTP IP spoofing attack) eg. If a web server see's 10 syn packets, reply back to all of them with syn-acks, and then if it doesn't see a response from any of the 10 within say a few seconds, close the 10 connections, add this host to a deny list for 24 hours, and do the same for every host that tries this half open attack? now when one of these hosts tries more dos attacks, the packets are dropped straight away, but I'm guessing it not that easy, and if it was it'd be implemented already.

The problem with that is attackers spoof the IP addresses for SYN floods as well. Since they don't care about the response, they can send each SYN as a different IP address. And for volumetric attacks, it becomes a 10 pounds in a 5 pound bag issue. Even if you are dropping it at the front door, there is still a jam to get to the door. ISP scrubbing and services like Cloudflare and Prolexic are designed to help with that, but it is a very complicated problem. Especially when attackers devise solutions that turn the internet's own infrastructure against itself.

I can't help but associate that with "Huge douchenozzle"...I blame PewDiePie for that...

He's the biggest YouTube personality, but that's mainly because his demographic (preteens/teens) lines up directly with the people who are most comfortable with internet video. He's not representative of the whole of internet broadcasters, or even most of the successful ones (although he's actually a good guy, his show persona is just intolerably annoying).

I'm not sure how much of a nice guy he is considering his comment about "Your extra view gets me extra cash lolololol", even if he apologized for it.

Quote:

They typically have a niche, either in a specific game or a style of play (min-maxing, speedrunning, roguelikes, hell platformers, etc), and cater to that extensively. I strongly suggest checking out the top streams on Twitch if you want a good cross section of what streamers are like. Some are there just for the game (Kripparian, Trump, most LoL pros), and some of them are there mainly as entertainers (ManVsGame, Towelliee, Lethalfrag), but there's generally something for everyone. It's harder to find exactly what you want on YouTube because of the vast quantity of content, but chance are there's someone doing videos on your type of games in a style you will like.

I'm not into live streams that much, except for those who do horror games.

There was one youtuber I liked, Birgirpall, but the current changes in youtube revenue schemes kind of shafted them so they haven't released new videos as often.

I work for a large HS district in NJ & were getting killed with this type of attack for about 20-30 min everyday around noon. When it hits were seeing 10gb+ per second......

We have spent the better part of 2 weeks trying to figure out who would, could, and why its happening. Hard to believe a disgruntled HS student could pull this off. For what its worth this is not an easy thing to defend against. Especially if you actually need to use NTP servers......

edit:Yes we've gone to the ISP for assistance, but all they offer us is add on services($$$) to defend against it. They won't even just block NTP to our circuit.

Really? You don't read the news often if you think a HS kid is not capable of this.

Why haven't web server evolved to handle DOS attacks?(not the NTP IP spoofing attack) eg. If a web server see's 10 syn packets, reply back to all of them with syn-acks, and then if it doesn't see a response from any of the 10 within say a few seconds, close the 10 connections, add this host to a deny list for 24 hours, and do the same for every host that tries this half open attack? now when one of these hosts tries more dos attacks, the packets are dropped straight away, but I'm guessing it not that easy, and if it was it'd be implemented already.

Well, at the webserver end, he'd be adding all the NTP severs to a 24 hr deny list, which might be a problem depending on how critical time sync is for your webserver.

Honestly, we should thank the kiddies who do this: their providing excellent impetus to close some longstanding vulnerabilities in basic IP services. Already, we're seeing them having to resort to NTP, which looks to be far less effective the DNS attacks from a few years ago, so they've already created a better, more robust internet.

Then you get your firewall DOS'd by tracking too many rules. Routing data is much easier than inspecting it. If you create a large deny list, you need to check that entire deny list, or at least until a hit, against the incoming data.

This seems like awfully high amplitude for "just trolling lol". NTP amplification only goes so high - like the article said, usually a max of 8x or so - which means in order to generate an 80Gbps DDoS stream, you still need 10 Gbps of upload bandwidth to start with.

The highest consumer-level bandwidth available in my area has a 5mbps upload pipe - so you'd need 2,048 people with that highest-level connection, operating at full saturation, to generate the input stream before the NTP amplification. That's not "small fry" right there - that's levels that pretty strongly imply a botnet.

You could in theory issue a tool like the old LOIC to a bunch of eager disgruntled followers and tell them "target [this site] lol", but surely if this were the case, somebody would have reported on it by now...? I haven't heard any rumors of grass-roots attacks from the usual places (4chan, etc) personally.

I really wonder if there isn't money to be followed here.

edit: FWIW, I recently had to close NTP holes on some older FreeBSD servers in a datacenter environment that were being used in this type of attack. They were completely saturating the datacenter's upload bandwidth until the problem was found and resolved. Yuck. Also FWIW: modern linux distros aren't generally useful for this crap even if the NTP port is allowed to be accessed from the internet; they implement controls that do not allow the list command to be used by untrusted addresses, with the default trust only being given to localhost. Not sure if FreeBSD ever patched their NTP version up similarly or not.

If all ISPs would enable Urpf ( Unicast Reverse Path Forwarding ), these kind of attacks using spoofed source IPs would simply not be possible. The packets would be dropped at the source.

Out of curiosity, is there any reason to allow spoofed source IPs in packets?

It has to do with two different protocols. Most of what you do on the web uses TCP, which requires what is known as a TCP handshake to establish identity and create the connection. Some things, however, use a different protocol called UDP. This is a connectionless protocol. Meaning there is no way for the server to know where the packet came from once it has been routed. The server simply sends the reply to the IP address in the packet. Other protocols that you use every day like NTP, DNS, HTTP, HTTPS all either run over UDP or TCP. NTP and DNS are good for flooding attacks because they both run on UDP. Spoof the address and unless measures are taken the reply will head wherever you take it. And like this article says, you can create queries that cause comparatively massive replies. So in reality, no one is allowing it. It is just a nature of the underlying protocol. And if you are wondering why you would use UDP instead, it has to do with overhead. Setting up and maintaining TCP connections is a drain on both processor and network resources.

*Removed word for clarity

Don't neglect latency when explaining UDP: it's one of the key reasons it's used in most modern implementations.

No it isn't. Latency is exactly the same, regardless of whether you're using UDP or TCP. It takes some number of milliseconds for your message to hit the end point. It takes some number of milliseconds for the other end point's response to return. Assuming the path is the same, the time will be the same. The point to UDP is that you can completely ignore any responses if you don't actually need delivery guarantee, and if you do, you can more intelligently design the mechanism to suit your application better than TCP's standard congestion control.

Latency is exactly the same, regardless of whether you're using UDP or TCP. It takes some number of milliseconds for your message to hit the end point. It takes some number of milliseconds for the other end point's response to return. Assuming the path is the same, the time will be the same.

This isn't true - google TCP window size to find out why.

(TL;DR is that the source will only send so many packets before receiving ACKs for them, so on a higher latency connection, you end up sending packets in discrete pulses rather than a steady stream. UDP doesn't require receipt guarantees, so there's no scaling, so the source will keep sending packets as fast as it can manage to with no extra wait times injected.)

If all ISPs would enable Urpf ( Unicast Reverse Path Forwarding ), these kind of attacks using spoofed source IPs would simply not be possible. The packets would be dropped at the source.

Out of curiosity, is there any reason to allow spoofed source IPs in packets?

It has to do with two different protocols. Most of what you do on the web uses TCP, which requires what is known as a TCP handshake to establish identity and create the connection. Some things, however, use a different protocol called UDP. This is a connectionless protocol. Meaning there is no way for the server to know where the packet came from once it has been routed. The server simply sends the reply to the IP address in the packet. Other protocols that you use every day like NTP, DNS, HTTP, HTTPS all either run over UDP or TCP. NTP and DNS are good for flooding attacks because they both run on UDP. Spoof the address and unless measures are taken the reply will head wherever you take it. And like this article says, you can create queries that cause comparatively massive replies. So in reality, no one is allowing it. It is just a nature of the underlying protocol. And if you are wondering why you would use UDP instead, it has to do with overhead. Setting up and maintaining TCP connections is a drain on both processor and network resources.

*Removed word for clarity

Don't neglect latency when explaining UDP: it's one of the key reasons it's used in most modern implementations.

No it isn't. Latency is exactly the same, regardless of whether you're using UDP or TCP. It takes some number of milliseconds for your message to hit the end point. It takes some number of milliseconds for the other end point's response to return. Assuming the path is the same, the time will be the same. The point to UDP is that you can completely ignore any responses if you don't actually need delivery guarantee, and if you do, you can more intelligently design the mechanism to suit your application better than TCP's standard congestion control.

Which affects latency, when viewed in context of the entire network stack, instead of only thinking about latency during signaling.

It is that affect on userland latency that makes it the protocol of choice for things like streaming and multiplayer game communication.

Spoofed IP addresses have been causing problems for over a decade now, and measures to prevent it have been around almost as long. If all ISP's would just lock down their routers to dump packets unless their source address can be reached from the port they arrive at.

Picture it this way: if you're flying over the Pacific Ocean towards LA it's extremely implausible that your plane took off from NY.

If all ISPs would enable Urpf ( Unicast Reverse Path Forwarding ), these kind of attacks using spoofed source IPs would simply not be possible. The packets would be dropped at the source.

Out of curiosity, is there any reason to allow spoofed source IPs in packets?

It has to do with two different protocols. Most of what you do on the web uses TCP, which requires what is known as a TCP handshake to establish identity and create the connection. Some things, however, use a different protocol called UDP. This is a connectionless protocol. Meaning there is no way for the server to know where the packet came from once it has been routed. The server simply sends the reply to the IP address in the packet. Other protocols that you use every day like NTP, DNS, HTTP, HTTPS all either run over UDP or TCP. NTP and DNS are good for flooding attacks because they both run on UDP. Spoof the address and unless measures are taken the reply will head wherever you take it. And like this article says, you can create queries that cause comparatively massive replies. So in reality, no one is allowing it. It is just a nature of the underlying protocol. And if you are wondering why you would use UDP instead, it has to do with overhead. Setting up and maintaining TCP connections is a drain on both processor and network resources.

*Removed word for clarity

Don't neglect latency when explaining UDP: it's one of the key reasons it's used in most modern implementations.

No it isn't. Latency is exactly the same, regardless of whether you're using UDP or TCP. It takes some number of milliseconds for your message to hit the end point. It takes some number of milliseconds for the other end point's response to return. Assuming the path is the same, the time will be the same. The point to UDP is that you can completely ignore any responses if you don't actually need delivery guarantee, and if you do, you can more intelligently design the mechanism to suit your application better than TCP's standard congestion control.

Standard latency in regards to time for a packet to travel the wire, yes. Things like time to first byte, no. There are plenty of different latency measures. TCP requires a handshake which adds latency in terms of the total transaction.

Why haven't web server evolved to handle DOS attacks?(not the NTP IP spoofing attack) eg. If a web server see's 10 syn packets, reply back to all of them with syn-acks, and then if it doesn't see a response from any of the 10 within say a few seconds, close the 10 connections, add this host to a deny list for 24 hours, and do the same for every host that tries this half open attack? now when one of these hosts tries more dos attacks, the packets are dropped straight away, but I'm guessing it not that easy, and if it was it'd be implemented already.

It is indeed not the issue (anymore), and a better solution was implemented the better part of two decades ago (SYN Cookies).

The issue today simply getting so much data, that your pipe can't handle it. It doesn't matter if the server ignores the data, it's all about drowning it in noise, so it never even receives legitimate traffic (and legitimate connections that are already started get lost).

Hard to believe a disgruntled HS student could pull this off. For what its worth this is not an easy thing to defend against.

When you consider that the only level of sophistication required to direct an attack like this is possession of a bitcoin or two and the IP address of the target you want taken down, it's rather easy to believe.

That whole thing with PhantomL0rd was designed specifically to get the attention of the kinds of teenagers who would do this kind of thing.

No it isn't. Latency is exactly the same, regardless of whether you're using UDP or TCP. It takes some number of milliseconds for your message to hit the end point. It takes some number of milliseconds for the other end point's response to return. Assuming the path is the same, the time will be the same. The point to UDP is that you can completely ignore any responses if you don't actually need delivery guarantee, and if you do, you can more intelligently design the mechanism to suit your application better than TCP's standard congestion control.

Most TCP stacks implement Nagle's algorithm, which causes TCP to wait up to 100ms to attempt to coalesce smaller packets into one larger packet. TCP also has to re-transmit if something doesn't get through, which can cause jitter if you don't need that feature.

But yes, you are mostly correct. If you disable Nagle, sending one sub-MTU sized message over TCP should take about the same amount of time as UDP.

In practice, TCP has been assumed to be relatively latency insensitive, so some TCP stacks have given up tighter latency for higher throughput. An example would be to reduce hardware interrupts for TCP streams to let more packets buffer. This reduces overhead which increases throughput but increases latency.