HTTP/1.1 200 OK Date: Mon, 08 Apr 2002 23:52:51 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Sat, 16 Nov 1996 00:17:00 GMT ETag: "304c7c-3ead-328d07fc" Accept-Ranges: bytes Content-Length: 16045 Connection: close Content-Type: text/plain Internet Draft Paul Ferguson November 1996 cisco Systems, Inc. Expires in six months Daniel Senie Proteon, Inc. Network Ingress Filtering Defending Against IP Source Address Spoofing draft-ferguson-ingress-filtering-01.txt Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract Recent occurrences of various Denial of Service 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 methods for using ingress traffic filtering to deny attacks which use forged IP addresses. draft-ferguson-ingress-filtering-01.txt [Page 1] INTERNET-DRAFT Network Ingress Filtering November 1996 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 2. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Restricting forged traffic . . . . . . . . . . . . . . . . 4 4. Further capabilities for networking equipment. . . . . . . 5 5. Liabilities. . . . . . . . . . . . . . . . . . . . . . . . 5 6. Summary. . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations. . . . . . . . . . . . . . . . . . 6 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . 7 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 7 1. Introduction A resurgence of Denial of Service Attacks [1] aimed at various targets in the Internet have produced new challenges within the Internet Service Provider (ISP) and network security communities to find methods to mitigate these types of attacks. The difficulties in reaching this goal are numerous; 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 has been a concern. Bill Cheswick is quoted in [2] as saying that he pulled a chapter from his book, "Firewalls and Internet Security" [3], at the last minute because there was no way for an administrator of the system under attack to effectively defend that system. By mentioning the method, he was concerned about encouraging its use. While the filtering method discussed in this document does absolutely nothing to protect against flooding attacks which originate from valid prefixes, 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 disallow attackers from using forged source addresses which do not reside within legitimately advertised prefixes. An additional benefit of implementing this type of filtering is that it enables the originator to be easily traced, since the attacker would have to use a valid, and reachable, source address. draft-ferguson-ingress-filtering-01.txt [Page 2] INTERNET-DRAFT Network Ingress Filtering November 1996 2. Background A simplified diagram of the problem is depicted below: 9.0.0.0/8 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.] Assume: o The host is the targeted machine. o The attacker resides within the "valid" prefix 9.0.0.0/8 o The attacker launches the attack using randomly changing source addresses; in this example, the source addresses are depicted as from within [4], which are not present in the global Internet routing tables, and therefore, unreachable. 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. 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. draft-ferguson-ingress-filtering-01.txt [Page 3] INTERNET-DRAFT Network Ingress Filtering November 1996 When an 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. Responding to this threat, the 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 everywhere 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 [1] for vendor and platform software upgrade information. 3. Restricting forged traffic The problems encountered with this type of attack are numerous, and involve shortcomings in host software implementations, routing methodologies, and the TCP/IP protocols themselves. However, by restricting transit traffic which originates from a downstream network to known prefix(es), the problem of source address spoofing can be virtually eliminated in the attack scenario. 11.0.0.0/8 / router 1 / / / 9.0.0.0/8 ISP <----- ISP <---- ISP <--- ISP <-- router <-- attacker A B C D 2 / / / router 3 / 12.0.0.0/8 draft-ferguson-ingress-filtering-01.txt [Page 4] INTERNET-DRAFT Network Ingress Filtering November 1996 In the example above, the attacker resides within 9.0.0.0/8, which is provided Internet connectivity by ISP D. An input traffic filter on the ingress (input) link of "router 2", which provides connectivity to the attacker's network, restricts traffic to allow only traffic originating from source addresses within the 9.0.0.0/8 prefix, and prohibits an attacker from using "invalid" source addresses which reside outside of this prefix range. In other words, the ingress filter on "router 2" above would check: IF packet's source address from within 9.0.0.0/8 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. 4. Further capabilities for networking equipment Several additional functions could be considered for future platform implementations. These include: o Implementation of automatic filtering on remote access servers. In most cases, a user dialing into an access server is an individual user on a single PC. The ONLY valid source IP address for packets originating from that PC is the one assigned by the ISP (whether statically or dynamically assigned). The remote access server could check every packet on ingress to ensure the user is not spoofing addresses. Obviously, provisions also need to be made for cases where the customer legitimately is attaching a net or subnet via a remote router, but this could certainly be implemented as an optional parameter. o Examination of forwarded packets for valid return path. Routers could perform a look up on the source address of packets being forwarded in their routing tables. If the routing table indicates a different interface as the next hop than the interface on which the packet arrived, then the packet would be discarded. This could lead to problems when network administrators set up multiple paths in such a way that traffic doesn't always flow on the same path in both directions (asymmetric routing). Note that this check may degrade router performance. 5. Liabilities Filtering of this nature has the potential to break some types of special services, such as some IP Mobility implementations. It is draft-ferguson-ingress-filtering-01.txt [Page 5] INTERNET-DRAFT Network Ingress Filtering November 1996 in the best interest of the ISP offering these types of special services, however, to consider alternate methods of implementation, such as point-to-point tunneling, or any other method which is not affected by ingress traffic filtering. While ingress 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 where it advertises. This simplifies tracking down of the culprit, and at worst, the administrator can block a range of source addresses until the problem is resolved. If ingress filtering 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 be forwarded to the appropriate destination. Since the router is most likely performing as the BOOTP or DHCP relay agent, the router will then be able to forward the requests. 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 is recommended that all service providers do so as soon as possible. In addition to aiding the Internet community as a whole to defeat this attack method, it can also assist service providers in locating the source of the attack if service providers can categorically demonstrate that their network already has ingress filtering in place on customer links. Corporate network administrators should implement filtering to ensure their corporate networks are not the source of such problems. Indeed, filtering could be used within an organization to ensure users do not cause problems by improperly attaching systems to the wrong networks. The filtering would also 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. 7. Security considerations The primary consideration is to inherently increase security for the Internet community as a whole; as more Internet Providers and corporate network administrators implement ingress filtering, the draft-ferguson-ingress-filtering-01.txt [Page 6] INTERNET-DRAFT Network Ingress Filtering November 1996 opportunity for an attacker to use forged source addresses as an attack methodology will 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 in the Internet as a whole, there will be more resources for tracking the attacks which ultimately do occur. 8. Acknowledgments The North American Network Operators Group (NANOG) [5] group as a whole deserves special credit for openly discussing these issues and actively seeking possible solutions. Also, thanks to Justin Newton [Erol's Internet, Inc.] and Steve Bielagus [Proteon, Inc.] for their comments and contributions. 9. References [1] CERT Advisory CA.96-12; 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] RFC-1918, "Address Allocation for Private Internets"; Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de Groot, E. Lear; February 1996 [5] The North American Network Operators Group; http://www.nanog.org 10. Authors' addresses Paul Ferguson Daniel Senie cisco Systems, Inc. Proteon, Inc. 400 Herndon Parkway 9 Technology Drive Herndon, VA USA 20170 Westboro, MA USA 01581 Email: pferguso@cisco.com Email: dts@proteon.com draft-ferguson-ingress-filtering-01.txt [Page 7]