RFC 2827

Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing

📅 published May 2000, from ietf

RFC 2827: Network Ingress Filtering 🎀

Okay bestie, let's get into this one. It's RFC 2827, and the full title is "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing" ✨. P. Ferguson from Cisco Systems, Inc. and D. Senie from Amaranth Networks Inc. wrote it together 👯‍♀️. It's dated May 2000 🌸 and it's a Best Current Practice, which is why it's labelled BCP 38 💅. It also obsoletes RFC 2267 🫶, so if you still have 2267 bookmarked, it's time to let it go 💀.

Status of this Memo 📌

This doc is a BCP for the Internet Community, and it's asking everyone to talk about it and suggest improvements 💬. Distribution of this memo is unlimited, so share away 🦋.

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract 🎀

Lately there have been a bunch of Denial of Service (DoS) attacks that use forged source addresses, and honestly? It's been a real headache 😭 for Internet Service Providers and the wider Internet community. This paper walks through a simple, effective, and straightforward method. The idea is to use ingress traffic filtering so that DoS attacks using forged IP addresses can't get propagated from "behind" an Internet Service Provider's (ISP) aggregation point 🚫.

Table of Contents 🗂️

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . .  2
 2.  Background . . . . . . . . . . . . . . . . . . . . . . . .  3
 3.  Restricting forged traffic . . . . . . . . . . . . . . . .  5
 4.  Further capabilities for networking equipment. . . . . . .  6
 5.  Liabilities. . . . . . . . . . . . . . . . . . . . . . . .  6
 6.  Summary. . . . . . . . . . . . . . . . . . . . . . . . . .  7
 7.  Security Considerations. . . . . . . . . . . . . . . . . .  8
 8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . .  8
 9.  References . . . . . . . . . . . . . . . . . . . . . . . .  8
10.  Authors' Addresses . . . . . . . . . . . . . . . . . . . .  9
11.  Full Copyright Statement . . . . . . . . . . . . . . . . . 10

1. Introduction ✨

Okay so, DoS attacks are back in a big way 🔥 aimed at all kinds of targets on the Internet. That's created some new challenges for ISP and network security folks, who are trying to find new and innovative ways to mitigate these attacks [1]. Reaching that goal is not easy, and there are a lot of difficulties 😩. Some simple tools already exist to limit how effective and how far-reaching these attacks can be, but they haven't been widely deployed.

This attack method has been around for a while 🕰️. Defending against it, though, has been an ongoing worry. Bill Cheswick is quoted in [2] saying that he pulled a chapter from his book, "Firewalls and Internet Security" [3], at the last minute 🙈. The reason? There was no way for an administrator of a system under attack to really defend it. He was also worried that talking about the method would encourage people to use it.

Here's the important bit 💅. Filtering as described in this document does absolutely nothing to protect against flooding attacks that come from valid prefixes (IP addresses). What it does do is stop an attacker inside the originating network from launching this kind of attack with forged source addresses that don't follow the ingress filtering rules 🛑. All providers of Internet connectivity are urged to implement the filtering in this document, so attackers can't use forged source addresses that aren't inside a range of legitimately advertised prefixes. Put another way, if an ISP is aggregating routing announcements for multiple downstream networks, it should use strict traffic filtering to block traffic that claims to have come from outside those aggregated announcements 🧚.

Another perk of this filtering is that it makes the originator easy to trace back to its true source 🕵️‍♀️. That's because the attacker would have to use a valid, legitimately reachable source address, so there's no hiding behind a fake one.

2. Background 🌸

Let's look at a simplified diagram of the TCP SYN flooding problem 👀:

                                                 204.69.207.0/24
 host <----- router <--- Internet <----- router <-- attacker

          TCP/SYN
      <---------------------------------------------
            Source: 192.168.0.4/32
 SYN/ACK
 no route
          TCP/SYN
      <---------------------------------------------
            Source: 10.0.0.13/32
 SYN/ACK
 no route
          TCP/SYN
      <---------------------------------------------
            Source: 172.16.0.2/32
 SYN/ACK
 no route

 [etc.]

Here's what's going on in that example 🧐:

  • The "host" is the targeted machine 🎯.
  • The attacker lives inside the "valid" prefix, 204.69.207.0/24 😈.
  • The attacker launches the attack using randomly changing source addresses. In this example, the source addresses come from within [4], which are not generally present in the global Internet routing tables, so they're unreachable 🫥. That said, any unreachable prefix could be used to pull off this attack method.

There's another case worth knowing about, and it's kind of messed up 😭. The source address can be forged so it looks like it came from another legitimate network that is in the global routing table(s). For example, an attacker using a valid network address could wreak havoc by making the attack appear to come from an organization that didn't actually originate it and is totally innocent 💔. In that situation, the administrator of the system under attack might be tempted to filter all traffic coming from that apparent attack source. But adding that filter results in a denial of service to legitimate, non-hostile end-systems 🙃. So the administrator of the system under attack has unwittingly become an accomplice of the attacker 💀.

It gets worse 😩. TCP SYN flood attacks cause SYN-ACK packets to be sent to one or many hosts that had no involvement in the attack, and those hosts become secondary victims. That lets the attacker abuse two or more systems at once 🥲.

Similar attacks have been tried using UDP and ICMP flooding 🌊. The first one, UDP flooding, uses forged packets to try to connect the chargen UDP service to the echo UDP service at another site. Systems administrators should NEVER allow UDP packets destined for system diagnostic ports from outside of their administrative domain to reach their systems 🚨. The second one, ICMP flooding, takes advantage of an insidious feature in IP subnet broadcast replication mechanics 🤯. This attack relies on a router serving a large multi-access broadcast network to frame an IP broadcast address (such as one destined for 10.255.255.255) into a Layer 2 broadcast frame (for ethernet, FF:FF:FF:FF:FF:FF). Ethernet NIC hardware (MAC-layer hardware, specifically) will only listen to a select number of addresses in normal operation. The one MAC address that all devices share in normal operation is the media broadcast, or FF:FF:FF:FF:FF:FF. In this case, a device will take the packet and send an interrupt for processing. So a flood of these broadcast frames will consume all available resources on an end-system [9] 😵. It's perhaps prudent for system administrators to consider making sure their border routers do not allow directed broadcast packets to be forwarded through their routers by default 🧱.

When a TCP SYN attack is launched using an unreachable source address, the target host tries to reserve resources while it waits for a response 🤷‍♀️. The attacker keeps changing the bogus source address on each new packet, which keeps exhausting more and more host resources 📉.

Alternatively, if the attacker uses someone else's valid host address as the source address, the system under attack will send a large number of SYN/ACK packets to what it believes is the originator of the connection establishment sequence 📬. This way, the attacker does damage to two systems: the destination target system, and the system that's actually using the spoofed address in the global routing system 💥.

The result of both attack methods is extremely degraded performance or, worse, a system crash 😱.

In response to this threat, most operating system vendors have changed their software so the targeted servers can sustain attacks with very high connection attempt rates 🛡️. This is a welcome and necessary part of the solution! Ingress filtering will take time to be deployed everywhere and be fully effective, but the operating system extensions can be implemented quickly 🏃‍♀️. Put those together and you get something that should prove effective against source address spoofing 💖. See [1] for vendor and platform software upgrade information 📚.

4. Further possible capabilities for networking equipment ✨

okay so there are more cool things future platforms could totally do 💅 one is worth flagging:

  • Automatic filtering on remote access servers 🦋 Usually when someone dials into an access server, it's just one individual on one PC. The ONLY valid source IP address for packets coming from that PC is the one the ISP assigned it, whether that's static or dynamic. So the remote access server could check every packet on ingress to make sure the user isn't faking the source address on the packets they send. Obviously there need to be provisions for when a customer legitimately attaches a net or subnet through a remote router, but that could be an optional parameter 🎀. We've gotten reports that some vendors and some ISPs are already starting to build this 😭

We considered suggesting that routers also validate the source IP address of the sender, as suggested in [8]. But that methodology won't work well in the real networks out there today 🙈 The idea is to look up the source address and check whether the return path to that address would flow out the same interface the packet arrived on. With the number of asymmetric routes on the Internet, that would clearly be problematic 💀

5. Liabilities ⚠️

Filtering like this has the potential to break some types of "special" services 👀 It's in the best interest of the ISP offering these special services, though, to consider alternate ways of implementing them so they aren't affected by ingress traffic filtering 💖

Mobile IP, as defined in [6], is specifically affected by ingress traffic filtering 😩 As specified, traffic to the mobile node is tunneled, but traffic from the mobile node isn't tunneled. That means packets from the mobile node(s) can have source addresses that don't match the network where the station is attached. To accommodate ingress filtering and other concerns, the Mobile IP Working Group developed a method for "reverse tunnels," specified in [7] 🧚 This gives the mobile node a way to have its data tunneled to the home agent before it goes out to the Internet. There are extra perks to the reverse tunneling scheme too, including better handling of multicast traffic. Those implementing mobile IP systems are encouraged to implement this method of reverse tunneling 🫶

As mentioned previously, ingress traffic filtering drastically reduces the success of source address spoofing, but it doesn't stop an attacker from using a forged source address of another host within the permitted prefix filter range 🥲 What it does do is make sure that when an attack like this really happens, a network administrator can be sure it's originating from within the known prefixes being advertised. That makes tracking down the culprit way easier, and at worst the administrator can block a range of source addresses until the problem is resolved 🔥

If ingress filtering is used in an environment where DHCP or BOOTP is used, the network administrator would be well advised to make sure that packets with a source address of 0.0.0.0 and a destination of 255.255.255.255 are allowed to reach the relay agent in routers when appropriate. The scope of directed broadcast replication should be controlled, though, and not arbitrarily forwarded 🌸

6. Summary 🍓

Ingress traffic filtering at the periphery of Internet-connected networks will reduce the effectiveness of source address spoofing denial of service attacks 🛡️ Network service providers and administrators have already begun implementing this type of filtering on periphery routers, and it's recommended that all service providers do so as soon as possible. Besides helping the Internet community as a whole defeat this attack method, it can also help service providers locate the source of an attack, if they can categorically demonstrate that their network already has ingress filtering in place on customer links 👑

Corporate network administrators should implement filtering to make sure their corporate networks aren't the source of these problems 💅 Honestly, filtering could be used inside an organization too, to make sure users don't cause problems by improperly attaching systems to the wrong networks 🤭

The filtering could also, in practice, block a disgruntled employee from anonymous attacks 🙈

It's the responsibility of all network administrators to make sure they don't become the unwitting source of an attack of this nature 🫠

7. Security Considerations 🔐

The primary intent of this document is to inherently increase security practices and awareness across the Internet community as a whole. As more Internet Providers and corporate network administrators implement ingress filtering, the opportunity for an attacker to use forged source addresses as an attack methodology will significantly lessen. Tracking the source of an attack is simplified when the source is more likely to be "valid." By reducing the number and frequency of attacks across the Internet as a whole, there will be more resources available for tracking the attacks that do ultimately occur 🚨

8. Acknowledgments 🫶🌈

The North American Network Operators Group (NANOG) [5] deserves special credit as a whole for openly discussing these issues and actively seeking possible solutions 👏 Also, a big thank you to Justin Newton [Priori Networks] and Steve Bielagus [IronBridge Networks] for their comments and contributions 💜

9. References 📚

  • [1] CERT Advisory CA-96.21; TCP SYN Flooding and IP Spoofing Attacks; September 24, 1996.
  • [2] B. Ziegler, "Hacker Tangles Panix Web Site", Wall Street Journal, 12 September 1996.
  • [3] "Firewalls and Internet Security: Repelling the Wily Hacker"; William R. Cheswick and Steven M. Bellovin, Addison-Wesley Publishing Company, 1994; ISBN 0-201-63357-4.
  • [4] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", RFC 1918, February 1996.
  • [5] The North American Network Operators Group; http://www.nanog.org.
  • [6] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
  • [7] Montenegro, G., "Reverse Tunneling for Mobile IP", RFC 2344, May 1998.
  • [8] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
  • [9] Thanks to: Craig Huegen; See: http://www.quadrunner.com/~chuegen/smurf.txt.

10. Authors' Addresses 🧚

Paul Ferguson
Cisco Systems, Inc.
13625 Dulles Technology Dr.
Herndon, Virginia  20170 USA

EMail: ferguson@cisco.com

Daniel Senie
Amaranth Networks Inc.
324 Still River Road
Bolton, MA 01740 USA

EMail: dts@senie.com

Copyright (C) The Internet Society (2000). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

Acknowledgement 💖

Funding for the RFC Editor function is currently provided by the Internet Society 🎀

📦 where this page comes from