summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2827.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2827.txt')
-rw-r--r--doc/rfc/rfc2827.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc2827.txt b/doc/rfc/rfc2827.txt
new file mode 100644
index 0000000..f3cc8b0
--- /dev/null
+++ b/doc/rfc/rfc2827.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+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.
+
+Abstract
+
+ Recent 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.
+
+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
+
+
+
+
+
+
+
+Ferguson & Senie Best Current Practice [Page 1]
+
+RFC 2827 Network Ingress Filtering May 2000
+
+
+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 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
+ [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
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ferguson & Senie Best Current Practice [Page 2]
+
+RFC 2827 Network Ingress Filtering May 2000
+
+
+2. Background
+
+ A simplified diagram of the TCP SYN flooding problem is depicted
+ below:
+
+ 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.]
+
+ Assume:
+
+ o The "host" is the targeted machine.
+
+ o The attacker resides within the "valid" prefix, 204.69.207.0/24.
+
+ 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 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
+
+
+
+Ferguson & Senie Best Current Practice [Page 3]
+
+RFC 2827 Network Ingress Filtering May 2000
+
+
+ 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 [9]. 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.
+
+
+
+
+
+
+Ferguson & Senie Best Current Practice [Page 4]
+
+RFC 2827 Network Ingress Filtering May 2000
+
+
+ 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 [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, and intentionally advertised, prefix(es), the
+ problem of source address spoofing can be virtually eliminated in
+ this attack scenario.
+
+ 11.0.0.0/8
+ /
+ router 1
+ /
+ /
+ / 204.69.207.0/24
+ ISP <----- ISP <---- ISP <--- ISP <-- router <-- attacker
+ A B C D 2
+ /
+ /
+ /
+ router 3
+ /
+ 12.0.0.0/8
+
+
+ In the example above, the attacker resides within 204.69.207.0/24,
+ 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
+ 204.69.207.0/24 prefix, and prohibits an attacker from using
+ "invalid" source addresses which reside outside of this prefix range.
+
+
+
+
+
+
+
+
+Ferguson & Senie Best Current Practice [Page 5]
+
+RFC 2827 Network Ingress Filtering May 2000
+
+
+ In other words, the ingress filter on "router 2" above would check:
+
+ IF packet's source address from within 204.69.207.0/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.
+
+4. Further possible capabilities for networking equipment
+
+ Additional functions should be considered for future platform
+ implementations. The following one is worth noting:
+
+ 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 the source address on the packets which he
+ is originating. 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. We have received reports
+ that some vendors and some ISPs are already starting to
+ implement this capability.
+
+ We considered suggesting routers also validate the source IP address
+ of the sender as suggested in [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.
+
+5. Liabilities
+
+ Filtering of this nature has the potential to break some types of
+ "special" services. It is in the best interest of the ISP offering
+ these types of special services, however, to consider alternate
+ methods of implementing these services to avoid being affected by
+ ingress traffic filtering.
+
+
+
+
+
+Ferguson & Senie Best Current Practice [Page 6]
+
+RFC 2827 Network Ingress Filtering May 2000
+
+
+ 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 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 [7]. 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.
+
+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.
+
+
+
+Ferguson & Senie Best Current Practice [Page 7]
+
+RFC 2827 Network Ingress Filtering May 2000
+
+
+ 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.
+
+7. Security Considerations
+
+ The primary intent of this document is to inherently increase
+ security practices and awareness for 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 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
+ [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.
+
+
+
+
+Ferguson & Senie Best Current Practice [Page 8]
+
+RFC 2827 Network Ingress Filtering May 2000
+
+
+ [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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ferguson & Senie Best Current Practice [Page 9]
+
+RFC 2827 Network Ingress Filtering May 2000
+
+
+11. Full Copyright Statement
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ferguson & Senie Best Current Practice [Page 10]
+