idnits 2.17.1 draft-ferguson-ingress-filtering-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 3 instances of lines with control characters in the document. == There are 8 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 231 has weird spacing: '...special servi...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 2002 (ref. '6') (Obsoleted by RFC 3220) == Outdated reference: A later version (-05) exists of draft-ietf-mobileip-tunnel-reverse-02 Summary: 11 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Paul Ferguson 2 July 1997 cisco Systems, Inc. 3 Expires in six months Daniel Senie 4 OpenROUTE Networks, Inc. 6 Network Ingress Filtering: 7 Defeating IP Source Address Spoofing Denial of Service Attacks 8 draft-ferguson-ingress-filtering-02.txt 10 Status of this Memo 12 This document is an Internet Draft. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, 14 and its Working Groups. Note that other groups may also distribute 15 working documents as Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six 18 months. Internet Drafts may be updated, replaced, or obsoleted by 19 other documents at any time. It is not appropriate to use Internet 20 Drafts as reference material or to cite them other than as a 21 "working draft" or "work in progress." 23 To learn the current status of any Internet-Draft, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts 25 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Abstract 31 Recent occurrences of various Denial of Service (DoS) attacks 32 which have employed forged source addresses have proven to be a 33 troublesome issue for Internet Service Providers and the Internet 34 community overall. This paper discusses a simple, effective, 35 and straightforward method for using ingress traffic filtering 36 to deny DoS attacks which use forged IP addresses to be 37 propagated from "behind" an Internet Service Provider's (ISP) 38 aggregation point. 40 Table of Contents 42 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 43 2. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 44 3. Restricting forged traffic . . . . . . . . . . . . . . . . 4 45 4. Further capabilities for networking equipment. . . . . . . 5 46 5. Liabilities. . . . . . . . . . . . . . . . . . . . . . . . 5 47 6. Summary. . . . . . . . . . . . . . . . . . . . . . . . . . 6 48 7. Security Considerations. . . . . . . . . . . . . . . . . . 7 49 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 7 50 9. References . . . . . . . . . . . . . . . . . . . . . . . . 7 51 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 7 53 1. Introduction 55 A resurgence of Denial of Service Attacks [1] aimed at various 56 targets in the Internet have produced new challenges within the 57 Internet Service Provider (ISP) and network security communities to 58 new and innovative methods to mitigate these types of attacks. 59 The difficulties in reaching this goal are numerous; simple 60 tools already exist to limit the effectiveness and scope of 61 these attacks, but they have not been widely implemented. 63 This method of attack has been known for some time. Defending 64 against it has been a concern. Bill Cheswick is quoted in [2] 65 as saying that he pulled a chapter from his book, "Firewalls and 66 Internet Security" [3], at the last minute because there was no way 67 for an administrator of the system under attack to effectively defend 68 that system. By mentioning the method, he was concerned about 69 encouraging its use. 71 While the filtering method discussed in this document does 72 absolutely nothing to protect against flooding attacks which 73 originate from valid prefixes, it will prohibit an attacker within 74 the originating network from launching an attack of this nature using 75 forged source addresses that do not conform to ingress filtering 76 rules. All providers of Internet connectivity are urged to 77 implement filtering described in this document to prohibit 78 attackers from using forged source addresses which do not 79 reside within legitimately advertised prefixes. In other words, 80 if an ISP is aggregating routing announcements for multiple 81 downstream networks, strict traffic filtering should be used 82 to prohibit traffic which claims to have originated from outside 83 of these announcements. 85 An additional benefit of implementing this type of filtering is that 86 it enables the originator to be easily traced, since the attacker 87 would have to use a valid, and reachable, source address. 89 2. Background 91 A simplified diagram of the problem is depicted below: 93 9.0.0.0/8 94 host <----- router <--- Internet <----- router <-- attacker 96 TCP/SYN 97 <--------------------------------------------- 98 Source: 192.168.0.4/32 99 SYN/ACK 100 no route 101 TCP/SYN 102 <--------------------------------------------- 103 Source: 10.0.0.13/32 104 SYN/ACK 105 no route 106 TCP/SYN 107 <--------------------------------------------- 108 Source: 172.16.0.2/32 109 SYN/ACK 110 no route 112 [etc.] 114 Assume: 116 o The host is the targeted machine. 118 o The attacker resides within the "valid" prefix 9.0.0.0/8 120 o The attacker launches the attack using randomly changing source 121 addresses; in this example, the source addresses are depicted 122 as from within [4], which are not present in the global Internet 123 routing tables, and therefore, unreachable. Any unreachable prefix 124 could be used to perpetrate this attack method. 126 Also worthy of mention is a case wherein the source address is 127 forged to appear to have originated from within another legitimate 128 network, ie. one which does not appear in the global routing 129 system. For example, an attacker using a valid network address 130 could wreak havoc by making the attack appear to come from an 131 organization which did not, in fact, originate the attack and 132 was completely innocent. In such cases, the administrator of a 133 system under attack may be inclined to filter all traffic coming 134 from the apparent attack source. Adding such a filter would then 135 result in a denial of service to legitimate, non-hostile end-systems. 136 In this case, the administrator of the system under attack 137 unwittingly becomes an accomplice of the attacker. 139 When an attack is launched using unreachable source address, the 140 target host attempts to reserve resources waiting for a response. 141 The attacker repeatedly changes the bogus source address on each 142 new packet sent, thus exhausting additional host resources. 144 Alternatively, if the attacker uses someone else's valid host address 145 as the source address, the system under attack will send a large 146 number of SYN/ACK packets to what it believes is the originator of 147 the connection establishment sequence. In this fashion, the attacker 148 does damage to two systems: the destination target system, as well as 149 the system which is actually using the spoofed address in the global 150 routing system. 152 The result of both attack methods is extremely degraded performance, 153 or worse, a system crash. 155 Responding to this threat, most operating system vendors have 156 modified their software to allow the targeted servers to sustain 157 attacks with very high connection attempt rates. This is a welcome 158 and necessary part of the solution to the problem. Ingress filtering 159 will take time to be implemented pervasively and be fully effective, 160 but the extensions to the operating systems can be implemented 161 quickly. This combination should prove effective against source 162 address spoofing. See [1] for vendor and platform software upgrade 163 information. 165 3. Restricting forged traffic 167 The problems encountered with this type of attack are numerous, 168 and involve shortcomings in host software implementations, routing 169 methodologies, and the TCP/IP protocols themselves. However, by 170 restricting transit traffic which originates from a downstream 171 network to known, and intentionally advertised, prefix(es), the 172 problem of source address spoofing can be virtually eliminated 173 in this attack scenario. 175 11.0.0.0/8 176 / 177 router 1 178 / 179 / 180 / 9.0.0.0/8 181 ISP <----- ISP <---- ISP <--- ISP <-- router <-- attacker 182 A B C D 2 183 / 184 / 185 / 186 router 3 187 / 188 12.0.0.0/8 190 In the example above, the attacker resides within 9.0.0.0/8, 191 which is provided Internet connectivity by ISP D. An input 192 traffic filter on the ingress (input) link of "router 2", which 193 provides connectivity to the attacker's network, restricts traffic 194 to allow only traffic originating from source addresses within the 195 9.0.0.0/8 prefix, and prohibits an attacker from using "invalid" 196 source addresses which reside outside of this prefix range. 198 In other words, the ingress filter on "router 2" above would check: 200 IF packet's source address from within 9.0.0.0/8 201 THEN forward as appropriate 203 IF packet's source address is anything else 204 THEN deny packet 206 Network administrators should log information on packets which are 207 dropped. This then provides a basis for monitoring any suspicious 208 activity. 210 4. Further capabilities for networking equipment 212 Additional functions could be considered for future 213 platform implementations. The following one is worth noting: 215 o Implementation of automatic filtering on remote access servers. 216 In most cases, a user dialing into an access server is an 217 individual user on a single PC. The ONLY valid source IP 218 address for packets originating from that PC is the one 219 assigned by the ISP (whether statically or dynamically 220 assigned). The remote access server could check every packet 221 on ingress to ensure the user is not spoofing addresses. 222 Obviously, provisions also need to be made for cases where the 223 customer legitimately is attaching a net or subnet via a remote 224 router, but this could certainly be implemented as an optional 225 parameter. 227 5. Liabilities 229 Filtering of this nature has the potential to break some types of 230 special services. It is in the best interest of the ISP offering 231 these types of special services, however, to consider alternate 232 methods of implementing these services to avoid being affected 233 by ingress traffic filtering. 235 Mobile IP as defined in [6] is affected by ingress filtering. As 236 specified, traffic to the mobile node is tunneled, but traffic from 237 the mobile node are not tunneled. This results in packets from the 238 mobile node(s) which have source addresses that do not match with 239 the network where the station is attached. The Mobile IP Working 240 Group is addressing this problem by specifying "reverse tunnels" 241 in [7]. This draft provides a method for the data transmitted from 242 the mobile node to be tunneled to the home agent before transmission 243 to the Internet. There are additional benefits to the reverse 244 tunneling scheme, including better handling of multicast traffic. 245 Those implementing mobile IP systems are encouraged to implement 246 this tunneling. 248 While ingress filtering drastically reduces the success of source 249 address spoofing, it does not preclude an attacker using a forged 250 source address of another host within the permitted prefix filter 251 range. It does, however, ensure that when an attack of this nature 252 does indeed occur, a network administrator can be sure that the 253 attack is actually originating from within the known prefixes that 254 are being advertised. This simplifies tracking down of the culprit, 255 and at worst, the administrator can block a range of source 256 addresses until the problem is resolved. 258 If ingress filtering is used in an environment where DHCP or BOOTP 259 is used, the network administrator would be well advised to ensure 260 that packets with a source address of 0.0.0.0 and a destination 261 of 255.255.255.255 are allowed to reach the relay agent in routers 262 when appropriate. 264 6. Summary 266 Ingress traffic filtering at the periphery of Internet connected 267 networks will reduce the effectiveness of source address spoofing 268 denial of service attacks. Network service providers and 269 administrators have already begun implementing this type of 270 filtering on periphery routers, and it is recommended that all 271 service providers do so as soon as possible. In addition to aiding 272 the Internet community as a whole to defeat this attack method, it 273 can also assist service providers in locating the source of the 274 attack if service providers can categorically demonstrate that their 275 network already has ingress filtering in place on customer links. 277 Corporate network administrators should implement filtering to 278 ensure their corporate networks are not the source of such 279 problems. Indeed, filtering could be used within an organization to 280 ensure users do not cause problems by improperly attaching systems 281 to the wrong networks. The filtering would also block a disgruntled 282 employee from anonymous attacks. 284 It is the responsibility of all network administrators to ensure 285 they do not become the unwitting source of an attack. 287 7. Security considerations 289 The primary consideration is to inherently increase security for the 290 Internet community as a whole; as more Internet Providers and 291 corporate network administrators implement ingress filtering, the 292 opportunity for an attacker to use forged source addresses as an 293 attack methodology will lessen. Tracking the source of an attack is 294 simplified when the source is more likely to be "valid." By reducing 295 the number and frequency of attacks in the Internet as a whole, 296 there will be more resources for tracking the attacks which 297 ultimately do occur. 299 8. Acknowledgments 301 The North American Network Operators Group (NANOG) [5] group as a 302 whole deserves special credit for openly discussing these issues and 303 actively seeking possible solutions. Also, thanks to Justin Newton 304 [Priori Networks] and Steve Bielagus [OpenROUTE Networks, Inc.] 305 for their comments and contributions. 307 9. References 309 [1] CERT Advisory CA.96-12; TCP SYN Flooding and IP Spoofing 310 Attacks; September 24, 1996 312 [2] B. Ziegler, "Hacker Tangles Panix Web Site", Wall Street Journal, 313 12 September 1996 315 [3] "Firewalls and Internet Security: Repelling the Wily Hacker"; 316 William R. Cheswick and Steven M. Bellovin, Addison-Wesley 317 Publishing Company, 1994; ISBN 0-201-63357-4 319 [4] RFC-1918, "Address Allocation for Private Internets"; Y. Rekhter, 320 R. Moskowitz, D. Karrenberg, G. de Groot, E. Lear; February 1996 322 [5] The North American Network Operators Group; 323 http://www.nanog.org 325 [6] RFC-2002, "IP Mobility Support"; C. Perkins; October 1996 327 [7] draft-ietf-mobileip-tunnel-reverse-02.txt, "Reverse Tunneling for 328 Mobile IP"; G. Montenegro; March 1997 330 10. Authors' addresses 332 Paul Ferguson Daniel Senie 333 cisco Systems, Inc. OpenROUTE Networks, Inc. 334 400 Herndon Parkway 9 Technology Drive 335 Herndon, VA USA 20170 Westboro, MA USA 01581 336 Email: pferguso@cisco.com Email: dts@openroute.com