Network Working Group P. Ferguson Request for Comments: 2827 Cisco Systems, Inc. Obsoletes: 2267 D. Senie BCP: 38 Amaranth Networks Inc. Category: Best Current Practice May 2000 Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing Status of this Memo This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved.
AbstractRecent occurrences of various Denial of Service (DoS) attacks which have employed forged source addresses have proven to be a troublesome issue for Internet Service Providers and the Internet community overall. This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. 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] aimed at various targets in the Internet have produced new challenges within the Internet Service Provider (ISP) and network security communities to find new and innovative methods to mitigate these types of attacks. The difficulties in reaching this goal are numerous; some simple tools already exist to limit the effectiveness and scope of these attacks, but they have not been widely implemented. This method of attack has been known for some time. Defending against it, however, has been an ongoing concern. Bill Cheswick is quoted in  as saying that he pulled a chapter from his book, "Firewalls and Internet Security" , at the last minute because there was no way for an administrator of the system under attack to effectively defend the system. By mentioning the method, he was concerned about encouraging it's use. While the filtering method discussed in this document does absolutely nothing to protect against flooding attacks which originate from valid prefixes (IP addresses), it will prohibit an attacker within the originating network from launching an attack of this nature using forged source addresses that do not conform to ingress filtering rules. All providers of Internet connectivity are urged to implement filtering described in this document to prohibit attackers from using forged source addresses which do not reside within a range of legitimately advertised prefixes. In other words, if an ISP is aggregating routing announcements for multiple downstream networks, strict traffic filtering should be used to prohibit traffic which claims to have originated from outside of these aggregated announcements. An additional benefit of implementing this type of filtering is that it enables the originator to be easily traced to it's true source, since the attacker would have to use a valid, and legitimately reachable, source address.
4], which are not generally present in the global Internet routing tables, and therefore, unreachable. However, any unreachable prefix could be used to perpetrate this attack method. Also worthy of mention is a case wherein the source address is forged to appear to have originated from within another legitimate network which appears 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 which did not, in fact, originate the attack and was completely innocent. In such cases, the administrator of a system under attack may be inclined to filter all traffic coming from the apparent attack source. Adding such a filter would then result in a denial of service to
legitimate, non-hostile end-systems. In this case, the administrator of the system under attack unwittingly becomes an accomplice of the attacker. Further complicating matters, TCP SYN flood attacks will result in SYN-ACK packets being sent to one or many hosts which have no involvement in the attack, but which become secondary victims. This allows the attacker to abuse two or more systems at once. Similar attacks have been attempted using UDP and ICMP flooding. The former attack (UDP flooding) uses forged packets to try and 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 latter attack (ICMP flooding), uses 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 common 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. Thus, a flood of these broadcast frames will consume all available resources on an end-system . It is perhaps prudent that system administrators should consider ensuring that their border routers do not allow directed broadcast packets to be forwarded through their routers as a default. When an TCP SYN attack is launched using unreachable source address, the target host attempts to reserve resources waiting for a response. The attacker repeatedly changes the bogus source address on each new packet sent, thus exhausting additional 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. In this fashion, the attacker does damage to two systems: the destination target system, as well as the system which is 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 modified their software to allow the targeted servers to sustain attacks with very high connection attempt rates. This is a welcome and necessary part of the solution to the problem. Ingress filtering will take time to be implemented pervasively and be fully effective, but the extensions to the operating systems can be implemented quickly. This combination should prove effective against source address spoofing. See  for vendor and platform software upgrade information.
In other words, the ingress filter on "router 2" above would check: IF packet's source address from within 220.127.116.11/24 THEN forward as appropriate IF packet's source address is anything else THEN deny packet Network administrators should log information on packets which are dropped. This then provides a basis for monitoring any suspicious activity. 8], but that methodology will not operate well in the real networks out there today. The method suggested is to look up source addresses to see that the return path to that address would flow out the same interface as the packet arrived upon. With the number of asymmetric routes in the Internet, this would clearly be problematic.
Mobile IP, as defined in , is specifically affected by ingress traffic filtering. As specified, traffic to the mobile node is tunneled, but traffic from the mobile node is not tunneled. This results in packets from the mobile node(s) which have source addresses that do not match with the network where the station is attached. To accommodate Ingress Filtering and other concerns, the Mobile IP Working Group developed a methodology for "reverse tunnels", specified in . This provides a method for the data transmitted by the mobile node to be tunneled to the home agent before transmission to the Internet. There are additional benefits to the reverse tunneling scheme, including better handling of multicast traffic. Those implementing mobile IP systems are encouraged to implement this method of reverse tunneling. As mentioned previously, while ingress traffic filtering drastically reduces the success of source address spoofing, it does not preclude an attacker using a forged source address of another host within the permitted prefix filter range. It does, however, ensure that when an attack of this nature does indeed occur, a network administrator can be sure that the attack is actually originating from within the known prefixes that are being advertised. This simplifies tracking down the culprit, 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 ensure 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, however, and not arbitrarily forwarded.
The filtering could also, in practice, block a disgruntled employee from anonymous attacks. It is the responsibility of all network administrators to ensure they do not become the unwitting source of an attack of this nature. 5] group as a whole deserves special credit for openly discussing these issues and actively seeking possible solutions. Also, thanks to Justin Newton [Priori Networks] and Steve Bielagus [IronBridge Networks]. for their comments and contributions.  CERT Advisory CA-96.21; TCP SYN Flooding and IP Spoofing Attacks; September 24, 1996.  B. Ziegler, "Hacker Tangles Panix Web Site", Wall Street Journal, 12 September 1996.  "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.  Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", RFC 1918, February 1996.  The North American Network Operators Group; http://www.nanog.org.  Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.