RFC 4732

Internet Denial-of-Service Considerations

📅 published December 2006, from ietf

Okay bestie, this is RFC 4732: Internet Denial-of-Service Considerations 🎀. It was published in November 2006 as an Informational document, so it's sharing good info, not laying down rules 💅. The main authors are M. Handley, Ed. (UCL) and E. Rescorla, Ed. (Network Resonance), and the Internet Architecture Board (IAB) is listed alongside them 🧚. It doesn't obsolete or update any other RFCs, so it's a standalone glow-up 🦋.

Status of This Memo ✨

This memo gives information to the Internet community. It is not an Internet standard of any kind, and anyone can share it freely because distribution is unlimited 💖.

Copyright Notice 🌸

Abstract 🫶

Okay so this doc gives you a tour of the ways someone can pull off a denial-of-service (DoS) attack on Internet systems 😭. The whole point is to nudge protocol designers and network engineers toward designs that are way more robust 💪. It also talks through partial fixes that make attacks less effective, and how some of those fixes can accidentally open up new holes 🙈.

Table of Contents 🍓

   1. Introduction ....................................................3
   2. An Overview of Denial-of-Service Threats ........................4
      2.1. DoS Attacks on End-Systems .................................4
           2.1.1. Exploiting Poor Software Quality ....................4
           2.1.2. Application Resource Exhaustion .....................5
           2.1.3. Operating System Resource Exhaustion ................6
           2.1.4. Triggered Lockouts and Quota Exhaustion .............7
      2.2. DoS Attacks on Routers .....................................8
           2.2.1. Attacks on Routers through Routing Protocols ........8
           2.2.2. IP Multicast-based DoS Attacks ......................9
           2.2.3. Attacks on Router Forwarding Engines ...............10
      2.3. Attacks on Ongoing Communications .........................11
      2.4. Attacks Using the Victim's Own Resources ..................12
      2.5. DoS Attacks on Local Hosts or Infrastructure ..............12
      2.6. DoS Attacks on Sites through DNS ..........................15
      2.7. DoS Attacks on Links ......................................16
      2.8. DoS Attacks on Firewalls ..................................17
      2.9. DoS Attacks on IDS Systems ................................18
      2.10. DoS Attacks on or via NTP ................................18
      2.11. Physical DoS .............................................18
      2.12. Social Engineering DoS ...................................19
      2.13. Legal DoS ................................................19
      2.14. Spam and Black-Hole Lists ................................19
   3. Attack Amplifiers ..............................................20
      3.1. Methods of Attack Amplification ...........................20
      3.2. Strategies to Mitigate Attack Amplification ...............22
   4. DoS Mitigation Strategies ......................................22
      4.1. Protocol Design ...........................................23
           4.1.1. Don't Hold State for Unverified Hosts ..............23
           4.1.2. Make It Hard to Simulate a Legitimate User .........23
           4.1.3. Graceful Routing Degradation .......................24
           4.1.4. Autoconfiguration and Authentication ...............24
      4.2. Network Design and Configuration ..........................25
           4.2.1. Redundancy and Distributed Service .................25
           4.2.2. Authenticate Routing Adjacencies ...................25
           4.2.3. Isolate Router-to-Router Traffic ...................26
      4.3. Router Implementation Issues ..............................26
           4.3.1. Checking Protocol Syntax and Semantics .............26
           4.3.2. Consistency Checks .................................27
           4.3.3. Enhance Router Robustness through
                  Operational Adjustments ............................28
           4.3.4. Proper Handling of Router Resource Exhaustion ......28
      4.4. End-System Implementation Issues ..........................29
           4.4.1. State Lookup Complexity ............................29
           4.4.2. Operational Issues .................................30
   5. Conclusions ....................................................30
   6. Security Considerations ........................................31
   7. Acknowledgements ...............................................31
   8. Normative References ...........................................31
   9. Informative References .........................................32
   Appendix A. IAB Members at the Time of This Writing ...............36

1. Introduction ✨

A Denial-of-Service (DoS) attack is when one or more machines target a victim and try to stop it from doing useful work 😤. The victim could be a network server, client, or router, a network link or a whole network, a single Internet user or a company doing business online, an Internet Service Provider (ISP), a country, or any mix of those 🌍. Some DoS attacks involve gaining unauthorized access to network or computing resources, but for the most part this document focuses on attacks that don't involve compromising the victim's computing facilities 🔐.

Here's the tea: the original ARPANET and NSFNet were closed environments, so nobody thought about denial-of-service attacks when the original Internet Architecture was designed 💀. As a result, almost every Internet service is vulnerable to DoS attacks of enough scale 😭. In most cases, enough scale is reached by compromising a bunch of end-hosts (usually with a virus or worm) or routers, then using those compromised machines to carry out the attack. That's called a Distributed Denial-of-Service (DDoS) attack 🤖. There are also plenty of cases where a single well-connected end-system can pull off a successful DoS attack all on its own 👀.

This document is meant to serve a few purposes:

To highlight possible avenues for attack, and by doing so encourage protocol designers and network engineers toward designs that are more robust 💖.
To discuss partial solutions that reduce the effectiveness of attacks 🛡️.
To highlight how some partial solutions can be taken advantage of by attackers to carry out alternative attacks 🫣.

That last point keeps popping up as a theme in DoS, and it shows how much we're missing proper architectural solutions 🙃. The authors hope this document will kick off informed debate about future architectural solutions that could be feasible and cost-effective to deploy 🎀.

They also hope it will spark discussion leading to architectural solutions that make all Internet systems less susceptible to denial-of-service attacks 🌈.

Now, in principle you can't tell apart a sufficiently subtle DoS attack from a flash crowd (where unexpected heavy but non-malicious traffic has the same effect as a DoS attack) 🥴. That's true, but malicious attacks are usually more expensive to launch than many of the crude attacks we've seen so far 💸. So defending against DoS isn't about stopping every possible attack. It's mostly about raising the bar high enough for malicious traffic 🏋️‍♀️✨.

It's also important to remember that not every DoS problem is malicious 📣. Failed links, flash crowds, misconfigured bots, and plenty of other causes can lead to resource exhaustion problems, so the overall goal should be to stay robust against all forms of overload 🫶.

2. An Overview of Denial-of-Service Threats 💅

In this section we go through a wide range of possible DoS attacks 📚. This list can't be exhaustive, but it aims to give a good overview of the spectrum of possibilities we need to defend against 🎯.

We don't describe any attacks that aren't already publicly well documented 🙅‍♀️.

2.1. DoS Attacks on End-Systems 💻

We start with attacks on end-systems. In this context, an end-system is typically a PC or network server, but it can also be any communication endpoint 🖥️. For example, a router is also an end-system from the point of view of terminating TCP connections for BGP [10] or ssh [46] 🔌.

2.1.1. Exploiting Poor Software Quality 🐛

The simplest DoS attacks on end-systems exploit poor software quality on the end-systems themselves, and just make that software crash 💥. For example, buffer-overflow attacks might be used to compromise the end-system, but even if the buffer overflow can't be used to gain access, it's usually still possible to overwrite memory and crash the software 😩. Vulnerabilities like this can, in principle, affect any software that uses data supplied from the network 🌐. So not only might a web server be vulnerable, but it might also be possible to crash the back-end software (like a database) that a web server gets its data from 🗄️.

Software crashes from poor coding don't just affect application software. They can also hit the operating system kernel itself 🫠. A classic example is the so-called "ping of death", which became widely known in 1996 [21] 📅. This exploit crashed many popular operating systems when they were sent a single fragmented ICMP echo request packet whose fragments added up to more than the 65535 bytes allowed in an IPv4 packet 😱.

Okay, the ping of death is a real problem, but it's not a major architectural problem 🙌. Once an attack like this is discovered, the relevant code can be patched easily, and the problem goes away ✅. Still, as more and more software gets embedded, it's important not to lose the ability to upgrade the software in those systems 🔧💜.

2.1.2. Application Resource Exhaustion ✨

okay so apps don't just float around with infinite resources 💅 they live in a world with a finite supply of stuff, and when they process network traffic they're using that stuff to do their actual job. the sneaky move is an attacker making the app run out of one specific resource so it literally can't do its thing anymore 😭

the obvious things that could get exhausted are:

Available memory.
The CPU cycles available.
The disk space available to the application.
The number of processes or threads or both that the application is permitted to use.
The configured maximum number of simultaneous connections the application is permitted.

this list is clearly not complete 🙈 but it shows a few important things!!

some resources are self-renewing 🔄 CPU cycles are the perfect example. if the attack stops, more CPU cycles just become available again, no drama.

other resources like disk space need an explicit action to free up 🧹 if the app can't clean that up on its own, the damage can stick around long after the attack is over. 💀

this problem has been understood for years, and it's common practice to store logs and incoming email in a separate disk partition (/var on Unix systems) so that exhaustion has less of an impact. iconic move 👑

some resources are limited by configuration 🎀 the maximum number of processes and the maximum number of simultaneous connections are usually not hard limits, they're configured limits. the whole point is to let the machine keep doing other stuff when the app misbehaves. but you have to be really careful picking those numbers! for example, if a machine's only job is to be an FTP server, setting the max simultaneous connections way lower than the machine could actually handle just makes the attacker's life easier 🥺 but setting the limit way too high might let the attacker crash the machine (because of poor OS design when handling resource exhaustion) or allow livelock (see below). both of those are way worse failure modes, bestie 😬

2.1.3. Operating System Resource Exhaustion

conceptually, OS resource exhaustion and application resource exhaustion are super similar 🦋 the difference is that when an app runs out, the operating system may be able to protect other tasks from getting caught in the DoS attack. but if the OS itself runs out of resources, things can get way more catastrophic 💀

the best-known DoS attack on an operating system is the TCP SYN-flood [19], which is basically a memory-exhaustion attack 🧠 the attacker sends a flood of TCP SYN packets at the victim asking for connection setup, but then never actually completes the setup. the victim creates state to handle each incoming connection. if the attacker can create state faster than the victim can time it out, the victim runs out of the memory it uses to hold TCP state, and then it can't service legitimate TCP connection setup attempts. this was made worse in some implementations that used a small dedicated storage space for half-open connections, which made the attack easier than it otherwise would have been 🙃 and on a poorly coded operating system, running out of resources might also crash the whole system.

an alternative TCP DoS attack is the Ack-flood [23], which is basically a CPU exhaustion attack on the victim ⚡ the attacker floods the victim with TCP packets pretending to come from connections that were never established. a busy server with lots of outstanding connections has to check which connection each packet belongs to. some TCP implementations did this search really inefficiently, so the attacker could burn through all the victim's CPU servicing these packets instead of serving real requests. not it 😤

we should note that strong authentication mechanisms don't necessarily protect against CPU exhaustion attacks 🔐 in fact, badly designed authentication mechanisms that use cryptographic methods can make the problem worse. if an authentication mechanism lets an attacker send a packet that needs relatively expensive cryptographic authentication before it can be thrown away, the attacker's CPU exhaustion attack gets easier. main character energy for the attacker, not for us 🙄

CPU exhaustion attacks can also get worse because of poor OS handling of incoming network traffic 🌪️ without any malicious traffic, an ideal OS should behave like this:

As incoming traffic increases, the useful work done by the OS should increase until some resource (such as the CPU) is saturated.
From this point on, as incoming traffic continues to increase, the useful work done should be constant.

but that's often not what happens 😩 lots of systems suffer from livelock [33], where after saturation, increasing the load actually decreases the useful work done. one reason is that the system spends more and more time processing network interrupts for packets that will never get processed, which leaves less and less time for the application those packets were meant for. literally doing a lot of nothing 🫠

2.1.4. Triggered Lockouts and Quota Exhaustion

a lot of user-authentication mechanisms try to protect against password guessing by locking the user out after a small number of failed attempts 🔒 but if an attacker can guess or find out a user's ID, they can trigger that lockout and lock out the legitimate user instead. the protection becomes the weapon 😭

another way to deny service with protection mechanisms is to exhaust a quota 📉 this is probably most common with small web servers that are commercially hosted, where the server's contract with the hosting company allows a fixed amount of traffic per day. an attacker may be able to burn through that quota super fast and get the service suspended. similar attacks may be possible against other kinds of quota too 💸

and if there are no quotas at all, but the victim gets charged for their network traffic, a financial denial-of-service may be possible 💀💸 that one hits the wallet instead of the server.

2.2. DoS Attacks on Routers

a lot of the denial-of-service attacks you can run against end-systems can also be run against the control processor of an IP router 🖥️ for example, by flooding the command and control access ports. with a router, these attacks might make it stall, or make it stop processing routing packets altogether. even if the router keeps servicing routing packets, it might get so slow that routing protocols time out ⏱️ and in any of these cases, the consequence isn't just that the router stops forwarding traffic. it also causes routing protocol churn, which can have further side effects 🌀

one example of such a side effect comes from BGP route flap damping [11], which is meant to reduce global routing churn 🌍 if an attacker can cause BGP routing churn, route flap damping may then suppress the flapping routes [31]. and that suppression likely makes the networks served by those routes unreachable. the mitigation ends up becoming the problem, which is so frustrating 😤

a DoS attack on the router control processor might also stop the router from being managed effectively 🎛️ that could block actions that would help mitigate the DoS attack, and it might also make it harder to figure out what's causing the problem.

2.2.1. Attacks on Routers through Routing Protocols

on top of being end-systems, most routers run dynamic routing protocols 🗺️ and the routing protocols themselves can be used to stage a DoS attack on a router or a network of routers. this requires the ability to send traffic from addresses that could plausibly have generated the relevant routing messages. that's kinda hard with interior routing protocols but pretty easy with External Border Gateway Protocol (eBGP), for example 👀

the simplest attack on a network of routers is to overload the routing table with so many routes that the router runs out of memory, or doesn't have enough CPU power to process them all [26] 🧨 we should note that depending on how various routers around the network are distributed and how capable they are, such an attack might not overwhelm the routers near the attacking router, but could cause problems to pop up somewhere else in the network 🌐

some routing protocol implementations let you configure limits on the maximum number of routes heard from a neighbor [27] 🎚️

but limits often make things worse instead of better 😬 they make it possible for the attacker to push out legitimate routes with spoofed routes, which creates an easy form of DoS attack. not ideal, bestie.

an alternative attack is to overload the routers on the network by creating enough routing table churn that they can't keep up with the changes 🌪️ lots of routing protocols let you configure damping factors to avoid exactly this problem. however, just like with table size, a threshold applied inconsistently may let the spoofed routes merge with legitimate routes before the mechanism kicks in, which causes the legitimate routes to get damped. ugh, so messy 🫠

the simplest routing attack on a specific destination is for an attacker to announce a spoofed desirable route to that destination 🎣 a route might be desirable because it has a low metric, or because it's more specific than the legitimate route. either way, if the route is believed, traffic for the victim gets pulled toward the attacking router, where it will typically be discarded 🗑️

a more subtle denial-of-service attack might target a network instead of a single destination 🕵️‍♀️ under some circumstances, propagating inconsistent routing information can cause traffic to loop. if an attacker can make this happen on a busy path, the looping traffic might cause significant congestion, and it might also fail to reach the legitimate destination. the chaos is real 😵‍💫

in the past, there have been cases where different generations of routers interpreted a routing protocol specification differently 📜 in particular, BGP specifies that in the case of an error, the BGP peering should be dropped. but if some routers in a network treat a particular route as valid while others treat it as invalid, it may be possible to inject a BGP route at one point in the Internet and cause peerings to be dropped at many other places across the Internet 💥 unlike many of the examples above, while this kind of issue might be a serious short-term problem, it's not a fundamental architectural problem. once the problem is understood, deploying patched routing code can permanently solve it ✅ that's a glow-up moment for the whole Internet 🌸

2.2.2. IP Multicast-based DoS Attacks 📡

okay so there are basically two flavors of IP multicast 💅: traditional Any-Source Multicast (ASM), as specified in RFC 1112 [4], where multiple sources can send to the same multicast group, and Source-Specific Multicast (SSM), where the receiver has to specify both the IP source address and the group address 🫶. The two flavors give attackers pretty different DoS options, so let's dive in 🌸

ASM protocols like PIM-SM [6], MSDP [32], and DVMRP [12] typically make some routers create routing state right when a packet gets sent to a multicast group 🧚. They do this so the traffic reaches the group receivers and not the non-receivers 🎀. These protocols are super vulnerable to DoS attacks, bc an attacker who sends to lots of multicast groups can cause two things: a multicast routing table explosion (which means control processor memory exhaustion 😭) and multicast forwarding table exhaustion (which means forwarding card memory exhaustion or thrashing 💀).

ASM also lets an attacker send traffic to the same group as legit traffic 🙈, which can cause network congestion and deny service to the legitimate group. Not it 🙅

SSM does not let senders send to arbitrary groups unless a receiver has requested the traffic 🦋. So sender-based attacks on multicast routing state are not possible with SSM ✨. But, as with ASM, a receiver can still join a large number of multicast groups, causing routers to hold a large amount of multicast routing state, which can lead to memory exhaustion and so denial-of-service to legitimate traffic 🥀.

With IPv6, hosts are required to send ICMP Packet Too Big or Parameter Problem messages under certain circumstances, even if the destination address is a multicast address 📮. If the attacker can place themselves in the appropriate position in the multicast tree, a packet with an unknown but mandatory Destination Option, for instance, could generate a very large number of responses to the claimed sender 💌.

With IPv4, the same problem exists with multicast ICMP Echo Request packets, but these are somewhat easier to filter 🧹.

The examples above should not be taken as exhaustive. These are actually specific cases of a general problem that can happen when a multicast/broadcast request solicits a reply from a large number of nodes 🌈.

2.2.3. Attacks on Router Forwarding Engines 🏰

Router vendors implement lots of different mechanisms for packet forwarding, but broadly they fall into two categories: ones that use a forwarding cache, and ones that do not 🗂️. With a forwarding cache, the forwarding engine does not hold the full routing table. It just holds the currently active subset of the forwarding table ✨.

Many modern routers use a loosely coupled architecture, where one or more control processors handle the routing protocols and communicate over an internal network link to special-purpose forwarding engines, which actually forward the data traffic 🔌. In such architectures, it may be possible for an attacker to overwhelm the communications link between the control processor and the forwarding engine 😵. This is possible because the forwarding engines support very high speed links, and the control processor simply cannot handle a similar rate of traffic 🐢.

There may be many ways in which an attacker can trigger communication between the forwarding engines and the control processor. The simplest way is for the attacker to send to the router's IP address, but this should in principle be relatively easy to prevent using filtering on the forwarding engines 🛡️. Another way might be to cause the router to forward data packets using the "slow path". This involves sending packets that require special attention from the forwarding router. If the forwarding engine is not smart enough to perform such forwarding, it will typically pass the packet to the control processor 🐌. In a router using a forwarding cache, it may be possible to overload the internal communications by thrashing the forwarding cache 🌀. Finally, any form of data-triggered communication between the forwarding engine and the control processor might cause such a problem. Certain multicast routing protocols, including PIM-SM, contain many such data triggered events that could potentially be problematic 🧐.

The effects of overloading such internal communications are hard to predict and are very implementation-dependent 🤷. One possible effect might be that the forwarding table in the forwarding engine gets out of synchronization with the routing table in the control processor that reflects what the routing protocols believe is happening 😳. This might cause traffic to be dropped or to loop 🔁.

Finally, if an attacker can generate traffic that causes a router to auto-install access control list (ACL) entries, perhaps by triggering a response from an intrusion detection system, then it may be possible to exhaust the ACL resources on the router 🚨. This might prevent future attacks from being filtered or, worse, cause ACL processing to be handled by the route processor 💥.

2.3. Attacks on Ongoing Communications 🎯

Instead of attacking the end-system itself, it is also possible for an attacker to disrupt ongoing communications 💬. If an attacker can observe a TCP connection, then it is relatively easy for them to spoof packets to either reset that connection or to de-synchronize it so that no further progress can be made [29]. Such attacks are not prevented by transport or application-level security mechanisms such as TLS [5] or ssh, because the authentication takes place after TCP has finished processing the packets 🔐.

If an attacker cannot observe a TCP connection, but can infer that such a connection exists, it is theoretically possible to reset or de-synchronize that connection by spoofing packets into the connection. However, this might require an excessively large number of spoofed packets to guess both the port of the active end of the TCP connection (in most cases, the port of the passive end is predictable) and the currently valid TCP sequence numbers 🎲. However, as some operating systems have poorly implemented predictable algorithms for selecting either the dynamically selected port or the TCP initial sequence number [41] [20], then such attacks have been found to be feasible [34]. Advice as to how to reduce the vulnerability in the specific case of TCP is available in [37] 📚.

An attacker might be able to significantly reduce the throughput of a connection by sending spoofed ICMP source quench packets, although most modern operating systems should ignore such packets 🙃. However, care should be taken in the design of future transport and signaling protocols to avoid the introduction of similar mechanisms that could be exploited 🛠️.

2.4. Attacks Using the Victim's Own Resources 🪞

Instead of directly overloading the victim, it may be possible to cause the victim or a machine on the same subnet as the victim to overload itself 🤯.

An example of such an attack is documented in [18], where the attacker spoofs the source address on a packet sent to the victim's UDP echo port. The source address is that of another machine that is running a UDP chargen server (a chargen server sends a character pattern back to the originating source) 🎭. The result is that the two machines bounce packets back and forth as fast as they can, overloading either the network between them or one of the end-systems itself 🏓.

2.5. DoS Attacks on Local Hosts or Infrastructure ✨

okay so these are the attacks that only a local attacker can pull off, aka someone already sitting on your subnet 👀

An attacker on a subnet can stop other local hosts from getting online at all by draining the address pool that a Dynamic Host Configuration Protocol (DHCP) server hands out 😭 To do it they need to spoof the MAC address of an ethernet or wireless card, and ngl that's pretty doable with certain hardware and operating systems 💀

There's also a sneaky DHCP move: just answer faster than the legit DHCP server and hand out an address that's totally useless to the victim 🙈

These bootstrapping attacks are a pain to stop, bestie, because trust relationships usually get set up after IP communication is already happening 🫠

ARP spoofing [16] is giving similar energy. The attacker answers ARP requests before the victim does and keeps traffic from ever reaching them 🚫 Some brands of ethernet switch make it even easier. Just send from the victim's MAC address and the switch redirects traffic meant for the victim to the attacker's port. Yikes 😬 This can also block traffic from the victim by setting off screening or flap-dampening algorithms in the switch, depending on how the switch is designed 🦋

Broadcast storms [16] might be possible too. You flood a local LAN with a stream of unicast IP packets sent to the broadcast MAC address, and then some hosts on the LAN may try to forward those packets to the correct MAC address. That greatly amplifies the traffic on the LAN 🌪️

802.11 wireless networks have SO many ways to deny service 📡 In some cases the lack of DoS defenses was a deliberate choice. 802.11 runs on unlicensed spectrum, so the thinking was that interference would be everywhere and intentional radio jamming would be trivial anyway. That's why not much DoS protection was built in at the higher layers.

Still, some weaknesses against fancier attacks are worth knowing about. The big one is that association is unprotected, which lets rogue access points (APs) solicit notifications that would otherwise have gone to legitimate APs 😤

The SSID field gives basically zero defense here. Unless encryption is on, it's trivial to announce a base station (or even an ad-hoc mode host) using the same network name (SSID) as the real one. Adding authentication and encryption à la 802.1X and 802.11i may not help much on this front either. The SSID space is unmanaged, so anyone can put whatever they want in that field, and most host stacks don't handle that gracefully. Plus SSIDs are often left on the manufacturer's default, which makes them super predictable 🙃

Some 802.11 basestations have limited memory for how many associations they can support. If that limit gets exceeded, they may drop all associations 💔 To avoid this, some APs advertise their load so stations can pick less-loaded ones. But crude implementations of those algorithms can cause instability.

Also, because 802.11 authentication happens at a comparatively high layer of the stack, an attacker can just deauthenticate or disassociate the victim from the basestation, even when Wired Equivalent Privacy (WEP) is in use [30] 🥲 Bellardo and Savage [15] describe some simple remedies that reduce how effective these attacks are. IEEE 802.11w will protect Deauthenticate or Disassociate frames, but the attack is still possible by forging Association frames.

So what all of these have in common is that they exploit weaknesses in the link auto-configuration mechanisms. In a wireless network, a station has to detect APs to decide which one to connect to. In 802.11 that's handled by the Beacon and Probe Request/Response mechanisms 📻

Beacons can't easily be encrypted, because a station needs them before authentication to figure out which APs it might want to talk to. Authentication only happens after interpreting the Beacon, so encrypting it is a chicken-egg problem 🌀 You can't get the key to decrypt the Beacon until you've authenticated, and you may not be able to figure out which AP to authenticate with until you've decrypted the Beacon. Note that in principle you could encrypt Beacons with a shared (per-AP) key, but then every station would have to trial-decrypt beacons until one matched whatever shared authentication secret it had. Not particularly convenient, tbh.

So discussions of Beacon frame security have mostly focused on authentication of Beacon frames, not encryption. Even that is hard. A station could validate a Beacon after authentication, either by checking a Message Integrity Check (MIC) computed with the group key provided by the AP or by verifying the Beacon parameters during the 4-way handshake. But validating before authentication may require keys to be synchronized between APs within an SSID 🔑

2.6. DoS Attacks on Sites through DNS 🌐

In today's Internet, DNS is so important that if access to a site's DNS servers is denied, the site is effectively unreachable 😩 even if there's no actual communication problem with the site itself.

Many of the attacks on end-systems described above can be aimed at DNS servers too. But as servers go, DNS servers aren't particularly vulnerable to DoS. As long as a DNS server has sufficient memory, a modern host can usually respond very rapidly to DNS requests for which it's authoritative 🏎️ This was demonstrated in October 2002, when the root nameservers were hit with a very large DoS attack [38]. A number of the root nameservers have since been replicated using anycast [1] to further improve their resistance to DoS. Still, it's important for authoritative servers to have relaying disabled, or an attacker can force the DNS servers to hold state [40] 🧠

Many of the routing attacks can also be used against DNS servers by targeting the routing for the server. If the DNS server is co-located with the site it's authoritative for, the fact that the DNS server is also unavailable is of secondary importance. But if all the DNS servers become unavailable, email to that site may bounce instead of being stored while the mail servers are unreachable. So distribution of DNS server locations is important 📬

Causing network congestion on links to and from a DNS server can have similar effects to end-system attacks or routing attacks. DNS fails to get an answer, and the site being served is effectively denied access 🚧

Here's the plot twist 🤯 If an attacker can deny external access to all the DNS servers for a site, that doesn't just cause email to that site to be dropped. It also causes email from that site to be dropped. This is because recent versions of mail transfer agents such as sendmail will drop email if the mail originates from a domain that does not exist. Sendmail performs this check as an anti-spam measure, and spam itself can be viewed as a form of DoS attack. So defending against one DoS attack opens up the vulnerability that allows another. A classic example of unexpected consequences 💅 If a receiving implementation is using a black-hole list (see Section 2.14) served by DNS, an attacker can also mount a DoS attack by attacking the black-hole server.

Finally, a data corruption attack is possible if a site's nameserver is permitted to relay requests from untrusted third parties [40] 😱 The attacker issues a query for the data they want to corrupt, and the victim's nameserver relays the request to the authoritative nameserver. The request contains a 16-bit ID that's used to match up the response with the request. If the attacker spoofs enough response packets from the authoritative nameserver just before the official response arrives, each containing a forged response and a different DNS ID, then there's a reasonable chance one of the forged responses will have the correct DNS ID. The incorrect data then gets believed and cached by the victim's nameserver, so it gives the incorrect response to future queries. The odds go up if the attacker issues many different requests for the same data with different DNS IDs, because many nameserver implementations issue relayed requests with different DNS IDs. That means the response only has to match any one of these request IDs [17] [36].

The use of anycast for DNS services makes it even more vulnerable to spoofing attacks. An attacker who can convince the ISP to accept an anycast route to their fake DNS server can arrange to receive requests and generate fake responses 🎭 Anycast DNS also makes DoS attacks on DNS easier. The idea is to disable one of the DNS servers while maintaining the BGP route to that server. That creates failures for any client that gets routed to the now-defunct server 💀

2.7. DoS Attacks on Links 🔗

The simplest DoS attack is to send enough non-congestion-controlled traffic that a link becomes excessively congested, and legitimate traffic suffers unacceptably high packet loss 📉

Under some circumstances, the effect of a link DoS can be way more extensive. We already talked about the effects of denying access to a DNS server. Congesting a link might also cause a routing protocol to drop an adjacency if sufficient routing packets are lost, which could greatly amplify the effects of the attack 😬 Good router implementations prioritize the transmission of routing packets, but this is not a total panacea. If routers are peered across a shared medium such as ethernet, it may still be possible to congest the medium sufficiently that routing packets are lost.

Even if a link DoS doesn't cause routing packets to be lost, it may prevent remote access to a router using ssh or Simple Network Management Protocol (SNMP) [48]. That might make the router unmanageable, or prevent the attack from being correctly diagnosed 🙈

The prioritization of routing packets can itself cause a DoS problem. If the attacker can cause a large amount of routing flux, it may be possible for a router to send routing packets at a high enough rate that normal traffic is effectively excluded. However, this is unlikely except on low-bandwidth links 🐢

Finally, it may be possible for an attacker to deny access to a link by causing the router to generate sufficient monitoring or report traffic that the link is filled 📟 SNMP traps are one possible vector for such an attack, as they are not normally congestion controlled.

Attackers with physical access to multiple access links can easily bring down the link. This is particularly easy to mount and difficult to counter with wireless networks 🧨

2.8. DoS Attacks on Firewalls ✨

okay so firewalls are supposed to be the bodyguards 💅 for the systems behind them. since they limit what traffic can reach those systems, they can help defend against denial-of-service attacks 🛡️. BUT, and this is a big but 😭, under some circumstances the firewall itself can get turned into a weapon in a DoS attack.

there are lots of kinds of firewall, but broadly they split into stateful and stateless classes 🦋. "state" here just means whether the firewall keeps track of the active flows going through it. stateless firewalls can usually only be attacked by trying to exhaust the firewall's processing resources. stateful firewalls can be attacked by sending traffic that makes the firewall hold excessive state, or state with a pathological structure 💀.

with excessive state, the firewall just runs out of memory 🫠. then it can't create the state it needs to pass legitimate flows, and most firewalls will fail disconnected, which means the systems behind them lose service. not it 😩.

with pathological structure, the attacker sends traffic that makes the firewall's data structures hit their worst-case behaviour 🙈. an example is when the firewall uses hash tables to look up forwarding state and the attacker can predict the hash function. then the attacker may be able to make a huge pile of flow state land in the same bucket, and the firewall's lookup performance goes from O(1) to O(n), where n is the number of flows the attacker can instantiate [28]. so the attacker can make forwarding slow down to the point where legitimate traffic going through the firewall is effectively denied service 💔.

2.9. DoS Attacks on IDS Systems 🔍

intrusion detection systems (IDSs) have similar problems to firewalls, honestly it's giving déjà vu 🌀. an attacker might be able to make an IDS run out of processing power, run out of memory, or instantiate state with pathological structure. but unlike a firewall, an IDS normally fails open, and that does NOT deny service to the systems it protects 🙌. the catch is that subsequent attacks the IDS would have caught may get missed 👀.

some IDSs are reactive, meaning once they detect a hostile event they react by blocking later traffic from the hostile system, or by ending an ongoing connection from that system 🚫. an attacker might be able to spoof packets from a legitimate system, which would make the IDS think that legitimate system is hostile. the IDS would then block traffic from the legit system, and boom, that system is denied service 😭. it can get especially messy if the legit system is a router, a DNS server, or another system that a whole bunch of other systems depend on to work 🥲.

2.10. DoS Attacks on or via NTP ⏰

network time servers generally aren't considered security-critical services, but under some circumstances NTP servers could be used to pull off a DoS attack 🕰️.

the most obvious one is just DoSing the NTP servers themselves 💥. lots of end-systems have pretty poor clock accuracy, so without access to network time their clocks will naturally drift 😵‍💫. that can cause problems for distributed systems that rely on good clocks. for example, one commonly used revision control system can fail if it thinks the modification timestamp is in the future 🙃.

and if an attacker can subvert the NTP servers a host relies on, whether by compromising them or impersonating them, the attacker may be able to control that host's system clock 🫣. that can have all kinds of unexpected consequences, including dated resources like encryption or authentication keys expiring early 🔑. and then that can block access to other, more critical services 😱.

2.11. Physical DoS 🔌

so far we've mostly talked about denial-of-service attacks carried out over the network 🌐. BUT computer systems are only as resilient as their weakest link 🔗. it can be way easier to deny service by causing a power failure, cutting network cables, or just switching a system off, so physical security matters at least as much as network security 🔒. physical attacks can also be entry points for non-physical DoS, for example by reducing the resources available to deal with overcapacity 📉.

the weakest link might also be a human 🫶. when defending against DoS, you shouldn't neglect the possibility of denial-of-service through social engineering, like convincing an employee to make a configuration change that stops normal operation 🎭. bestie, never underestimate a convincing email 💀.

2.13. Legal DoS ⚖️

computer systems can't be considered in isolation from the social and legal systems they operate in 🏛️. this document focuses mainly on the technical issues, but we note that "cease and desist" letters, government censorship, and other legal mechanisms also touch on denial-of-service issues 📜.

2.14. Spam and Black-Hole Lists 📧

unsolicited commercial email, also known as "spam", can effectively cause denial-of-service to email systems 📭. the intent isn't DoS, but all that unwanted mail can waste the recipient's time, or make legitimate email fail to get noticed in all the background noise 🙄. if spam filtering software is used, some level of false positives is to be expected, so those messages are effectively denied service too 😤.

one way to cut down on spam is black-hole lists 🕳️. the IP addresses of dial-up ISPs or mail servers used to originate or relay spam get added to black-hole lists. recipients of mail can choose to consult these lists and reject spam if it originates or is relayed by systems on the list 📨. the big problem is that an attacker might be able to get a victim black-hole-listed even if the victim wasn't responsible for relaying any spam 😩. so the black-hole list itself can become a way to pull off a DoS attack 💅. note that every black-hole list has its own policy on additions, and some are less susceptible to this DoS attack than others 🌈. consumers of black-hole list technology are advised to look into these policies before they subscribe 🧐. similar considerations apply to feeds of bad BGP bad route advertisements 🛣️.

3. Attack Amplifiers 📣

a lot of the attacks described above rely on sending enough traffic to overwhelm the victim 🌊. those attacks get way easier thanks to "attack amplifiers", where an attacker sends traffic using the victim's spoofed source address and makes larger responses come back to the victim 🪞. a detailed discussion of these reflection attacks can be found in [35] 💜.

3.1. Methods of Attack Amplification

okay so the OG move here is the "smurf" attack [22] 🎀. The attacker sends an ICMP echo request with the victim's spoofed source address to the subnet-broadcast address of a network that's going to be the amplifier. Then every system on that subnet replies with an ICMP echo response, and all of those replies go straight to the victim 💀. Smurf attacks aren't as big a deal anymore, though, because routers usually drop those packets now and end-systems don't respond to them ✨.

Next up is the DNS reflection attack 🦋. The attacker sends a DNS request to a DNS server asking it to resolve a domain name, and again the source address is the victim's spoofed address. The request is carefully picked so the response comes back way bigger than the request, and that's where the amplification comes from 📈. Fun fact (no cap): the biggest DNS responses tend to be the ones with DNSsec authentication info in them 🤓. This one only works if the attacker can spoof the victim's source address. BUT, if the victim's DNS server is set up to relay requests from external clients, it might be possible to make it clog up its own incoming network link 😭.

Then there's amplification through retransmission 🌸. The go-to example is the TCP amplification attack known as "bang.c". The attacker sends a spoofed SYN with the victim's source address to an arbitrary TCP server. That server replies with a SYN|ACK headed to the victim, and if no final ACK shows up to finish the handshake, the server keeps retransmitting the SYN|ACK a bunch of times 🔁. Usually this attack uses a huge list of random servers as reflectors. For it to work, the reflector can't get a RST back from the victim in response to the SYN|ACK. But if the attack traffic is overwhelming enough, either the server or its access link gets so jammed that packet loss keeps many reflectors from ever getting that RST, so they just keep retransmitting 🫠. Firewalls that quietly drop the incoming SYN|ACK without sending a RST can make it even worse 🙈.

Services that relay requests need some care too 🧚. If an attacker can send a request to a proxy, and that proxy then tries to connect to a victim whose address the attacker picked, and the proxy keeps resending the request when nobody answers, that can also act as an attack amplifier 💅.

Another flavour of amplification happens in protocols where the payload includes an IP address or hostname that subsequent messages should get sent to. A good example is the Session Initiation Protocol (SIP) [50], which carries a payload defined by the Session Description Protocol (SDP) [51]. The SDP part of a SIP message tells everyone the IP address and port that media packets go to, and those media packets are typically encoded using the Real Time Transport Protocol (RTP) [52] 🎶.

So the attack works like this: the attacker sends a protocol message and sets the IP address inside the payload to point at the attack target. The recipient then generates subsequent traffic to that IP address 🎯. Depending on the protocol, this can give a LOT of amplification. With SIP specifically, if a caller sets up calls to high-bandwidth media sources (like a video server or streaming audio server), a single SIP INVITE packet, which is usually a few hundred bytes, can kick off a nearly continuous stream of media packets. Those streams can run anywhere from a few kbits per second all the way up to megabits per second 😱. This specific attack is called the "voice hammer" 🔨.

Unlike the techniques above, this one doesn't need the attacker to modify packets or even spoof their source IP address. That makes it way easier to pull off 🥺.

The fix for this one comes down to careful protocol design 💖. Protocols should, whenever possible, avoid putting IP addresses or hostnames in the payload as the places where subsequent messages get sent. Instead, when it's possible, messages should go back to the source IP the protocol packet came from. If that design isn't possible, the protocol should include a handshake that positively confirms the protocol entity at that IP address or hostname actually wants to receive those follow-up messages. That handshake itself needs to be lightweight (so it doesn't become its own DoS attack) and secured against spoofed handshake responses 🛡️.

One last, somewhat similar attack can happen with protocols where one message leads to another message that isn't sent as a reply to the first message's source address. This can be a problem with protocols that enable mobility, for example, and it might let an attacker dodge ingress filtering 👀. These protocols are notoriously hard to get right 😵‍💫.

3.2. Strategies to Mitigate Attack Amplification

in general, the big architectural lessons are pretty simple 🌈:

As far as possible, perform ingress filtering [7] [39] to prevent source address spoofing.
Avoid designing protocols or mechanisms that can return significantly larger responses than the size of the request, unless a handshake is performed to validate the client's source address. Such a handshake needs to incorporate an unpredictable nonce that is secure enough to mitigate the amplification effects of the protocol.
All retransmission during initial connection setup should be performed by the client.
Proxies should not arbitrarily relay requests to destinations chosen by a client.
Avoid signaling third-party connections. Any unavoidable third-party connections set up by a signaling protocol should incorporate lightweight validation before sending significant data.

4. DoS Mitigation Strategies

4.1. Protocol Design

4.1.1. Don't Hold State for Unverified Hosts

okay so the big goal from an end-system server's point of view is simple: don't create state until you've finished a handshake with the client to validate their address 🫶. And as much as possible, push the work and the state-holding over to the client ✨. There are a bunch of techniques for this, including SYN cookies [2] [14] 🍪. All client-server protocols should probably be designed so these techniques can be used, but turning the mechanism on should normally be at the server's discretion, so you're not doing unnecessary work under normal circumstances 💅.

4.1.2. Make It Hard to Simulate a Legitimate User

Honestly, other than having massive overcapacity, the only real defense against resource consumption attacks is to discriminate against attackers on purpose 😤. The general idea is to find something legitimate users can do that attackers can't. The most commonly proposed approaches are:

Puzzles: force the attacker to do some computation that wouldn't be onerous for a single user but is too expensive to do en masse [14].
Reverse Turing tests: specialized puzzles that are hard for machines to do but easy for humans, making automated attacks hard [13].
Reachability testing: force the proposed client to demonstrate that it can receive traffic at a given IP address. This makes it easier to trace attackers 🔍.

All of these have substantial limitations, sadly 💀. Puzzles tend to discriminate against legitimate users with slow computers. On top of that, the wide availability of remotely controlled compromised machines ("bots") means attackers have ample computing power at their disposal 🤖. There has been substantial work on attacking reverse Turing tests automatically, which makes them of limited applicability. And finally, reachability testing is substantially weakened by bots, because the attacker doesn't need to hide their source address 🙃.

4.1.3. Graceful Routing Degradation

A goal with routing protocols is graceful degradation under overload, plus automatic recovery once the source of the overload has been fixed 🌱. Some routing protocols nail this more than others. RIP [53] doesn't scale well, BUT if a router runs out of memory when receiving a RIP route, it can just drop the route and send an infinite metric to its peers. The route gets refreshed later, and if the original source of the problem is resolved, the router can process it correctly 🙌.

BGP is a different story, though 😬. It's stateful in the sense that a peer assumes you've processed (or chosen to filter) any route it sent you. The base BGP spec has no mechanism to refresh state, and even the later route refresh option [3] is hard to use when you're overloaded. A BGP router that can't store a route it received has two choices: completely restart BGP, or shut down one or more peerings [26]. So the effects of a BGP overload are way more severe than they need to be, which amplifies the effect of any attack 📉.

In general, few routing protocol designs actively think about how routers will behave under overload conditions. That should be an explicit part of future routing protocol designs 🧠. Precise details should clearly be left to implementors, but the protocol design needs to give them the capability to do their job properly 👑.

4.1.4. Autoconfiguration and Authentication

Autoconfiguration mechanisms make deployment so much easier, and they're getting more necessary as the number of networked devices grows past what anyone can manage by hand 🧚‍♀️. HOWEVER, it should be recognised that unauthenticated autoconfiguration opens up lots of avenues for attack 🚨. There's a clear tension between ease of configuration and security of configuration, especially because some environments want units to operate with effectively no authentication (e.g., airport hotspots) ✈️. Future autoconfiguration protocols should consider the need to let different end-systems operate at different points on this spectrum within the same autoconfiguration framework 🌈. Also, this implies that network elements should avoid acting for unauthenticated hosts, and instead just let them access the network more or less directly 🎀.

4.2. Network Design and Configuration ✨

Okay bestie, the big idea here is that networks should have their own private, out-of-band way in to the console or control ports 🔐. That way the control stuff still works even if someone is hammering the control plane or the data plane of the in-band network 💥. Usually this means a totally separate infrastructure built just for that purpose 🛠️. Out-of-band access is a crucial capability for DoS mitigation because a lot of the usual redundancy and capacity tricks (like prioritizing routing or network management traffic) totally flop during attacks 😭. Redundancy protocols like VRRP [47] can also fall apart during these attacks, since they may not be able to keep their adjacencies alive 💀.

Defaults are sneaky 🙈. Some vendors have IP redirect, directed broadcast, and proxy ARP turned on out of the box, and attackers can exploit that to run several of the attacks in this document. Publicly readable SNMP [48] communities, like "public", can spill confidential info to a prospective attacker 👀. Then there's TFTP [49], an unauthenticated configuration management protocol that you should avoid if possible. At the very least, protect access to TFTP configuration archives and filter TFTP at administrative boundaries 🚧. Finally (yes, the original says this twice, we're keeping both 😂), many router password encryption techniques are reversible, so keeping passwords in a configuration archive, even in the encrypted form the router writes, can lead to unauthorized access if that archive gets compromised 🔓.

4.2.1. Redundancy and Distributed Service

Basic principle: design systems to handle failure by having redundant servers that can take over when one goes down. This is just as true for DoS attacks, which often focus on a given server and/or link 🎯. If service delivery points are distributed across the network, attacking the entire service gets way harder 🧱. Attacks on a single network link become more difficult too 🙌.

4.2.2. Authenticate Routing Adjacencies

Generally, cryptographic authentication mechanisms are too costly to form the main part of DoS prevention 💸. But routing adjacencies are too important to risk an attacker injecting bad routing info, which can affect way more than the router in question 🌊. So additional non-cryptographic mechanisms should be used to stop arbitrary end-systems from making the router burn CPU cycles validating authentication data 🔥.

For BGP, at the very least, this means TCP MD5 [9] or IPsec authentication, combined with GTSM [8] to prevent eBGP association with non-immediate neighbors. In the future, this will likely mean better authentication of the routing information itself 🔮.

4.2.3. Isolate Router-to-Router Traffic

As far as is feasible, router-to-router traffic should be isolated from data traffic 🚧. How you do this depends on the precise technologies available, both in the router and at the link layer. The goal: link failure for data traffic should also cause failure for routing traffic, but an attacker cannot directly send packets to the control processor of the routers 🙅.

Heads up, there's a downside: some diagnostic techniques (like pinging consecutive routers to find the source of a delay) may no longer be possible 🔍. Ideally, alternative mechanisms that don't open up new DoS avenues should be designed to replace those lost techniques.

4.3. Router Implementation Issues 🖥️

Because a router can be considered an end-system, it can potentially benefit from all the prevention mechanisms prescribed for end-system implementation 💁. But a router is different from a host: it implements routing protocols and forwards data, which leads to additional router-specific implementation considerations. The issues below are illustrative, not exhaustive 📚.

4.3.1. Checking Protocol Syntax and Semantics

Protocol syntax defines how protocol messages are formed and the rules of exchanges. The questions that syntax checking addresses include, but aren't limited to, these:

Who sent the message?
Does the content conform to the protocol format?
Was the message sent with correct timing?

Step one in protocol syntax verification is making sure an incoming message was sent by a legitimate party 🕵️‍♀️. There are multiple ways to do that. You can verify the source IP address and even the MAC address of the message. Since eBGP peers are normally directly connected, you can also check the TTL value in a packet and discard any BGP updates packet whose TTL is less than some maximum value (typically, max TTL - 1) [8]. Cryptographic authentication should also be used whenever it's available to verify that an incoming message is really from an expected sender 🔐. For BGP, at the very least, this means TCP MD5 [9] or IPsec authentication.

Beyond sender verification, it's also important to check the syntax of a received routing message, instead of assuming everything came in a correct format 🙃. Routers have crashed in the past upon receiving ill-formed routing messages, and rigorous syntax checking prevents those faults 🛡️.

4.3.2. Consistency Checks

Protocol semantics define the meaning of the message content, the interpretation of the values, and the actions to be taken based on that content 🧠. Here's a simple example: when a link failure causes a router in Autonomous System (AS) A to send a peer router B a withdrawal message for prefix P, B should make sure any alternative path it finds to reach P does not go through A. This simple check is shown to significantly improve BGP convergence time in many cases [42] ⚡.

Another example of semantic checking against false routing injection is described in [44] 🎯. The basic idea is to attach a list of the valid origin ASes to the route announcement for prefix P. Thanks to the rich connectivity of today's Internet topology, a remote AS will receive routing updates from multiple different paths, and it can check whether each update carries the identical origin AS list. A false origin may announce reachability to P or alter the origin AS list, but it would be difficult, if not impossible, to block the correct updates from propagating out. So remote ASes can detect false updates by observing the inconsistency in the received origin AS lists for P 🕵️. Research studies show that the "allowed origin list" test can effectively detect the majority of falsely originated updates 📈.

Verifying the validity of BGP routes can be seriously challenging, because BGP is policy driven and the policies of individual ISPs are unknown in most cases 🤷‍♀️. But assuming policies don't change on a short timescale, in principle you could verify new updates against observed routes from the recent past, which reflect the routing policies in place. Research work is needed to explore this direction 🔬.

Note that while the steps above are all fairly simple and don't really "bulletproof" the protocol, each one adds some degree of protection 🧱. So combining these techniques can effectively reduce the probability of undetected faults 💖.

4.3.3. Enhance Router Robustness through Operational Adjustments

There are a bunch of configuration tunings that can enhance the robustness of BGP operations 🛠️. One example is letting BGP peers coordinate a limit on the number of prefixes one BGP speaker will send to its peer [43]. Sure, this check doesn't validate the prefix owned by each peer, but it can prevent false announcements of large numbers of invalid routes 🙌. Had all BGP routers been configured with this simple check earlier, several large-scale routing outages in the past could have been prevented 😤.

⚠️ Careful with hard limits of this type! They can be used to mount a DoS, because implementations often discard excess routes indiscriminately, which can cause black-holing of correct routes.

Another useful tuning is adjusting BGP's KeepAlive and Hold Timer values to minimize BGP peering session resets ⏱️. Previous measurements show that heavy traffic load, such as the kind caused by worms, can cause BGP KeepAlive messages to be delayed or dropped, which then causes BGP peering session breakdown 🪱. These load-induced session breaks and re-establishments can lead to an excessive number of BGP updates right when stable routing is needed most 💔.

4.3.4. Proper Handling of Router Resource Exhaustion

On top of the resource exhaustion problems that apply to all end-systems, as described in Section 2, router implementations must also take special care when handling resource exhaustion so the router keeps operating despite the problem 🧯.

Here's an example: under normal operations, a router doesn't need a large cache to hold outstanding ARP requests, because the replies usually come back within a few milliseconds ⚡. But certain conditions can lead to ARP cache exhaustion, like during a virus attack where many packets are sent to non-existing IP addresses, so there are no ARP replies to those requests 🦠. This has happened before and led to routers failing to forward packets 😭.

Queue management is another example 📬. Many high-end routers are designed so most packets can be handled purely in specialized processors (Application-Specific Integrated Circuits (ASICs), Field Programmable Gate-Arrays (FPGAs), etc.). Exceptional packets, though, have to be routed to a supporting general purpose CPU for handling. On some of these systems, it may be possible to mount a low-effort DoS attack by saturating the queues between the specialized hardware and the supporting processor 😬.

So the attack vector on routers and network devices is a low packets-per-second (PPS) queue saturation attack on the ASIC's raw queue structure 🎯. The countermeasure is to have multiple such queues designed so it's difficult for an attacker to arrange to fill multiple queues [45] 🛡️.

4.4. End-System Implementation Issues 💻

4.4.1. State Lookup Complexity

Any system that instantiates per-connection state should take great care to implement state-lookup mechanisms so that performance can't be controlled by the attacker 🕸️. One way to do this is to use hash tables where the hash mechanism is keyed in such a way that the attacker can't instantiate a large number of flows in the same hash bucket 🧚.

4.4.1.1. Avoid Livelock 🌀

Most operating systems use network interrupts to receive data from the network, and honestly that's a great move 💅 as long as the host only spends a small amount of its time handling network traffic. But this leaves the host open to livelock [33] 😭, where under heavy load the OS spends all its time handling interrupts and zero time doing the actual work needed to handle the traffic at the application level. Major "all talk, no action" energy 💀. Server operating systems should consider using network polling at times of heavy load, rather than being interrupt-driven 🔄. They should also be carefully architected so that, as far as reasonably possible, traffic received by the OS is processed to completion or very cheaply discarded ✨.

4.4.1.2. Use Unpredictable Values for Session IDs 🎲

Most recent TCP implementations use fairly good random mechanisms for allocating the TCP initial sequence numbers, which is so iconic of them 🦋. In general, any dynamically allocated value that's used purely to identify a communication session should be allocated using an unpredictable mechanism 🔐. Why? Because this increases the search space for an attacker who wants to disrupt ongoing communications, and bestie, a bigger search space is a much harder hunt for them 🙈. So the dynamically allocated port of the active end of a TCP connection might also be randomly allocated 🌸.

With DNS, the ID that is used to match responses with requests should also be randomly generated 🎀. Ngl though, the protection is rather limited here, because the ID field is only 16 bits 💔.

4.4.2. Operational Issues 🛠️

4.4.2.1. Eliminate Bad Traffic Early 🚫

Many DoS attacks are generic bandwidth consumption attacks, and they work by clogging the link that connects the victim server to the Internet 🚧. Filtering these attacks at the server does no good, because the traffic has already traversed the link, and that link was the scarce resource all along 😩. So such flows need to be filtered at some point closer to the attacker 🎯. Where possible, operators should filter out obviously bad traffic 🗑️. In particular, they should perform ingress filtering [7] 👑.

4.4.2.2. Establish a Monitoring Framework 👀

Network operators are strongly encouraged to establish a monitoring framework to detect and log abnormal network activity 📊. One cannot defend against an attack that one doesn't detect or understand, periodt 💅. Such monitoring tools can be used to set a baseline of "normal" traffic, and they can be used to detect aberrant flows and determine the type and source of those aberrant flows 🔍. This is extremely helpful when responding to distributed DoS attacks or a flash crowd, and it should be in place prior to the event ⏰.

5. Conclusions 🌈

In this document, we have highlighted possible avenues for DoS attacks on networks and networked systems 🗺️. The whole point is encouraging protocol designers and network engineers towards designs that are more robust 💪. We have discussed partial solutions that reduce the effectiveness of attacks, and we've also highlighted how some partial solutions can be taken advantage of by attackers to perpetrate alternative attacks 😈.

Our focus has primarily been on protocol and network architecture issues, but there are many things that network and service operators can do to lessen the threat 🫶. Further advice and information for network operators can be found in [24] [39] [25] 📚.

It is our hope that this document will spur discussion leading to architectural solutions that reduce the succeptibility of all Internet systems to denial-of-service attacks ✨. We really want everything on the Internet to be less vulnerable to DoS, and that's the dream 🦋.

6. Security Considerations 🔐

This entire document is about security. Literally the whole thing. 🚨

7. Acknowledgements 🎀

We are very grateful to Vern Paxson, Paul Vixie, Rob Thomas, Dug Song, George Jones, Jari Arkko, Geoff Huston, and Barry Greene for their constructive comments on earlier versions of this document 🫶💖.

8. Normative References 📖

[1] J. Abley, "Hierarchical Anycast for Global Service Distribution", http://www.isc.org/index.pl?/pubs/tn/index.pl?tn=isc-tn-2003-1.txt.

[2] D.J. Bernstein, "SYN Cookies", http://cr.yp.to/syncookies.html.

[3] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, September 2000.

[4] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.

[5] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.

[6] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.

[7] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.

[8] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL Security Mechanism (GTSM)", RFC 3682, February 2004.

[9] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.

[10] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.

[11] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route Flap Damping", RFC 2439, November 1998.

[12] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988.

[13] L. von Ahn, M. Blum, N. Hopper, and J. Langford. CAPTCHA: Using hard AI problems for security. In Proceedings of Eurocrypt, 2003.

9. Informative References 📚

[14] T. Aura, P. Nikander, J. Leiwo, "DOS-resistant authentication with client puzzles", In B. Christianson, B. Crispo, and M. Roe, editors, Proceedings of the 8th International Workshop on Security Protocols, Lecture Notes in Computer Science, Cambridge, UK, April 2000.

[15] J. Bellardo, S. Savage, "802.11 Denial-of-Service Attacks: Real Vulnerabilities and Practical Solutions", Proceedings of the USENIX Security Symposium, Washington D.C., August 2003.

[16] S.M. Bellovin, "Security Problems in the TCP/IP Protocol Suite", Computer Communication Review, Vol. 19, No. 2, pp. 32-48, April 1989.

[17] CCAIS/RNP Alertas do Cais ALR-19112002a, "Vulnerability in the sending requests control of Bind versions 4 and 8 allows DNS spoofing", http://www.rnp.br/cais/alertas/2002/cais-ALR-19112002a.html.

[18] CERT Advisory CA-1996-01, "UDP Port Denial-of-Service Attack", Feb 1996.

[19] CERT Advisory CA-1996-21, "TCP SYN Flooding and IP Spoofing Attacks", Sept 1996.

[20] CERT Advisory CA-2001-09, "Statistical Weaknesses in TCP/IP Initial Sequence Numbers", May 2001.

[21] CERT Advisory CA-1996-26, "Denial-of-Service Attack via ping", Dec 1996.

[22] CERT Advisory CA-1998-01, "Smurf IP Denial-of-Service Attacks", http://www.cert.org/advisories/CA-1998-01.html, Jan 1998.

[23] CERT Incident Note IN-2000-05, "'mstream' Distributed Denial of Service Tool", May 2000.

[24] CERT/CC - "Managing the Threat of Denial of Service Attacks", http://www.cert.org/archive/pdf/Managing_DoS.pdf.

[25] CERT/CC - "Trends in Denial of Service Attack Technology", http://www.cert.org/archive/pdf/DoS_trends.pdf.

[26] D.F. Chang, R. Govindan, J. Heidemann, "An Empirical Study of Router Response to Large Routing Table Load", Proceedings of the 2nd Internet Measurement Workshop (IMW 2002), 2002.

[27] Cisco Systems, "Configuring the BGP Maximum-Prefix Feature", Cisco Document ID: 25160, http://www.cisco.com/warp/public/459/bgp-maximum-prefix.html.

[28] Scott A Crosby and Dan S Wallach, "Denial of Service via Algorithmic Complexity Attacks", Proceedings of the USENIX Security Symposium, Washington D.C., August 2003.

[29] Laurent Joncheray, "Simple Active Attack Against TCP", 5th USENIX Security Symposium, 1995.

[30] M. Lough, "A Taxonomy of Computer Attacks with Applications to Wireless", PhD thesis, Virginia Polytechnic Institute, April 2001.

[31] Z. Mao, R. Govindan, G. Varghese, R. Katz, "Route Flap Dampening Exacerbates Internet Routing Convergence", Proceedings of ACM SIGCOMM, 2002.

[32] Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.

[33] J. Mogul, KK. Ramakrishnan, "Eliminating Receive Livelock in an Interrupt-driven Kernel", ACM Transactions on Computer Systems, Vol 15, Number 3, pp. 217-252, 1997.

[34] Watson, P., "Slipping in the Window: TCP Reset attacks", Presentation at 2004 CanSecWest, http://www.cansecwest.com/archives.html.

[35] V. Paxson, "An Analysis of Using Reflectors for Distributed Denial-of-Service Attacks", Computer Communication Review 31(3), July 2001.

[36] Joe Stewart, "DNS Cache Poisoning - The Next Generation", Jan 27 2003, http://www.lurhq.com/dnscache.pdf.

[37] Stewart, R., Ed., and M. Dalal, Ed., "Improving TCP's Robustness to Blind In-Window Attacks", Work in Progress, June 2006.

[38] P. Vixie, G. Sneeringer, M. Schleifer, "Events of 21-Oct-2002", http://f.root-servers.org/october21.txt.

[39] P. Vixie, "Securing the Edge", http://www.icann.org/committees/security/sac004.txt.

[40] D. Wessels, "Running An Authoritative-Only BIND Nameserver", http://www.isc.org/index.pl?/pubs/tn/index.pl?tn=isc-tn-2002-2.txt.

[41] M. Zalewski, "Strange Attractors and TCP/IP Sequence Number Analysis", http://www.bindview.com/Services/Razor/Papers/2001/tcpseq.cfm.

[42] D. Pei, X. Zhao, L. Wang, D. Massey, A. Mankin, F. S. Wu, and L. Zhang. Improving BGP Conver-gence Through Assertions Approach. In Proc. of IEEE INFOCOM, June 2002.

[43] Chavali, S., Radoaca, V., Miri, M., Fang, L., and S. Hares, "Peer Prefix Limits Exchange in BGP", Work in Progress, April 2004.

[44] X. Zhao, D. Massey, A. Mankin, S.F. Wu, D. Pei, L. Wang, L. Zhang, "BGP Multiple Origin AS (MOAS) Conflicts", http://nanog.org/mtg-0110/lixia.html, 2001.

[45] Cisco Systems, "Building Security Into the Hardware", ftp://ftp-eng.cisco.com/cons/isp/security/CPN-Summit-2004/Paris-Sept-04/SE14-BUILDING-SECURITY-INTO-THE-HARDWARE-c1_8_30_04.pdf, 2004.

[46] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.

[47] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", RFC 3768, April 2004.

[48] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.

[49] Malkin, G. and A. Harkin, "TFTP Timeout Interval and Transfer Size Options", RFC 2349, May 1998.

[50] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.

[51] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.

[52] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.

[53] Hedrick, C., "Routing Information Protocol", RFC 1058, June 1988.

Appendix A. IAB Members at the Time of This Writing 🎓

Bernard Aboba
Loa Andersson
Brian Carpenter
Leslie Daigle
Elwyn Davies
Kevin Fall
Olaf Kolkman
Kurtis Lindvist
David Meyer
David Oran
Eric Rescorla
Dave Thaler
Lixia Zhang

Authors' Addresses ✨

okay bestie, here are the people who wrote this one 🫶 Mark J. Handley, Ed. and Eric Rescorla, Ed. are listed as editors, and the IAB is credited too. Here's exactly how to reach them:

Mark J. Handley, Ed.
UCL
Gower Street
London  WC1E 6BT
UK

EMail: M.Handley@cs.ucl.ac.uk


Eric Rescorla, Ed.
Network Resonance
2483 E. Bayshore #212
Palo Alto  94303
USA

EMail: ekr@networkresonance.com


Internet Architecture Board
IAB

EMail: iab@ietf.org

Full Copyright Statement 🎀

okay so the legal bit, but make it cute 💅 The copyright belongs to The IETF Trust (2006). This document is subject to the rights, licenses and restrictions in BCP 78, and apart from what that says, the authors keep all their rights 📜

The disclaimer is super serious, so here it is word for word:

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,
AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.

Intellectual Property 🦋

the IETF doesn't say whether any patents or other rights apply to the tech in this doc, or whether you can get a license for it. It also hasn't checked for any such rights itself 🙈 For the rules about rights in RFCs, look at BCP 78 and BCP 79.

Any IPR disclosures sent to the IETF Secretariat, plus any promised licenses, or the results of trying to get a general license or permission for implementers or users, can be found in the IETF online IPR repository at http://www.ietf.org/ipr.

If you know about any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard, the IETF wants to hear about it. Send it to ietf-ipr@ietf.org 📬

Acknowledgement 🌸

big thank-you moment 🥹 Funding for the RFC Editor function is currently provided by the Internet Society.

📦 where this page comes from

ietf: rfc4732 2006-12
💖 girlified by claude-haiku-5-5 on 2026-10-16: a language model's rewrite of the original, under its terms