idnits 2.17.1 draft-ferguson-ingress-filtering-01.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-27) 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 7) 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 are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 6 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: ---------------------------------------------------------------------------- -- 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' Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Paul Ferguson 2 November 1996 cisco Systems, Inc. 3 Expires in six months Daniel Senie 4 Proteon, Inc. 6 Network Ingress Filtering 7 Defending Against IP Source Address Spoofing 8 draft-ferguson-ingress-filtering-01.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 attacks which 32 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 methods for using ingress traffic filtering 36 to deny attacks which use forged IP addresses. 38 Table of Contents 40 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 41 2. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 42 3. Restricting forged traffic . . . . . . . . . . . . . . . . 4 43 4. Further capabilities for networking equipment. . . . . . . 5 44 5. Liabilities. . . . . . . . . . . . . . . . . . . . . . . . 5 45 6. Summary. . . . . . . . . . . . . . . . . . . . . . . . . . 6 46 7. Security Considerations. . . . . . . . . . . . . . . . . . 6 47 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 7 48 9. References . . . . . . . . . . . . . . . . . . . . . . . . 7 49 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 7 51 1. Introduction 53 A resurgence of Denial of Service Attacks [1] aimed at various 54 targets in the Internet have produced new challenges within the 55 Internet Service Provider (ISP) and network security communities to 56 find methods to mitigate these types of attacks. The difficulties 57 in reaching this goal are numerous; simple tools already exist to 58 limit the effectiveness and scope of these attacks, but they have 59 not been widely implemented. 61 This method of attack has been known for some time. Defending 62 against it has been a concern. Bill Cheswick is quoted in [2] 63 as saying that he pulled a chapter from his book, "Firewalls and 64 Internet Security" [3], at the last minute because there was no way 65 for an administrator of the system under attack to effectively defend 66 that system. By mentioning the method, he was concerned about 67 encouraging its use. 69 While the filtering method discussed in this document does 70 absolutely nothing to protect against flooding attacks which 71 originate from valid prefixes, it will prohibit an attacker within 72 the originating network from launching an attack of this nature using 73 forged source addresses that do not conform to ingress filtering 74 rules. All providers of Internet connectivity are urged to 75 implement filtering described in this document to disallow attackers 76 from using forged source addresses which do not reside within 77 legitimately advertised prefixes. 79 An additional benefit of implementing this type of filtering is that 80 it enables the originator to be easily traced, since the attacker 81 would have to use a valid, and reachable, source address. 83 2. Background 85 A simplified diagram of the problem is depicted below: 87 9.0.0.0/8 88 host <----- router <--- Internet <----- router <-- attacker 90 TCP/SYN 91 <--------------------------------------------- 92 Source: 192.168.0.4/32 93 SYN/ACK 94 no route 95 TCP/SYN 96 <--------------------------------------------- 97 Source: 10.0.0.13/32 98 SYN/ACK 99 no route 100 TCP/SYN 101 <--------------------------------------------- 102 Source: 172.16.0.2/32 103 SYN/ACK 104 no route 106 [etc.] 108 Assume: 110 o The host is the targeted machine. 112 o The attacker resides within the "valid" prefix 9.0.0.0/8 114 o The attacker launches the attack using randomly changing source 115 addresses; in this example, the source addresses are depicted 116 as from within [4], which are not present in the global Internet 117 routing tables, and therefore, unreachable. Any unreachable prefix 118 could be used to perpetrate this attack method. 120 Also worthy of mention is a case wherein the source address is 121 forged to appear to have originated from within another legitimate 122 network. For example, an attacker using a valid network address 123 could wreak havoc by making the attack appear to come from an 124 organization which did not, in fact, originate the attack and 125 was completely innocent. In such cases, the administrator of a 126 system under attack may be inclined to filter all traffic coming 127 from the apparent attack source. Adding such a filter would then 128 result in a denial of service to legitimate, non-hostile end-systems. 129 In this case, the administrator of the system under attack 130 unwittingly becomes an accomplice of the attacker. 132 When an attack is launched using unreachable source address, the 133 target host attempts to reserve resources waiting for a response. 134 The attacker repeatedly changes the bogus source address on each 135 new packet sent, thus exhausting additional host resources. 137 Alternatively, if the attacker uses someone else's valid host address 138 as the source address, the system under attack will send a large 139 number of SYN/ACK packets to what it believes is the originator of 140 the connection establishment sequence. In this fashion, the attacker 141 does damage to two systems: the destination target system, as well as 142 the system which is actually using the spoofed address in the global 143 routing system. 145 The result of both attack methods is extremely degraded performance, 146 or worse, a system crash. 148 Responding to this threat, the operating system vendors have 149 modified their software to allow the targeted servers to sustain 150 attacks with very high connection attempt rates. This is a welcome 151 and necessary part of the solution to the problem. Ingress filtering 152 will take time to be implemented everywhere and be fully effective, 153 but the extensions to the operating systems can be implemented 154 quickly. This combination should prove effective against source 155 address spoofing. See [1] for vendor and platform software upgrade 156 information. 158 3. Restricting forged traffic 160 The problems encountered with this type of attack are numerous, 161 and involve shortcomings in host software implementations, routing 162 methodologies, and the TCP/IP protocols themselves. However, by 163 restricting transit traffic which originates from a downstream 164 network to known prefix(es), the problem of source address 165 spoofing can be virtually eliminated in the attack scenario. 167 11.0.0.0/8 168 / 169 router 1 170 / 171 / 172 / 9.0.0.0/8 173 ISP <----- ISP <---- ISP <--- ISP <-- router <-- attacker 174 A B C D 2 175 / 176 / 177 / 178 router 3 179 / 180 12.0.0.0/8 182 In the example above, the attacker resides within 9.0.0.0/8, 183 which is provided Internet connectivity by ISP D. An input 184 traffic filter on the ingress (input) link of "router 2", which 185 provides connectivity to the attacker's network, restricts traffic 186 to allow only traffic originating from source addresses within the 187 9.0.0.0/8 prefix, and prohibits an attacker from using "invalid" 188 source addresses which reside outside of this prefix range. 190 In other words, the ingress filter on "router 2" above would check: 192 IF packet's source address from within 9.0.0.0/8 193 THEN forward as appropriate 195 IF packet's source address is anything else 196 THEN deny packet 198 Network administrators should log information on packets which are 199 dropped. This then provides a basis for monitoring any suspicious 200 activity. 202 4. Further capabilities for networking equipment 204 Several additional functions could be considered for future 205 platform implementations. These include: 207 o Implementation of automatic filtering on remote access servers. 208 In most cases, a user dialing into an access server is an 209 individual user on a single PC. The ONLY valid source IP 210 address for packets originating from that PC is the one 211 assigned by the ISP (whether statically or dynamically 212 assigned). The remote access server could check every packet 213 on ingress to ensure the user is not spoofing addresses. 214 Obviously, provisions also need to be made for cases where the 215 customer legitimately is attaching a net or subnet via a remote 216 router, but this could certainly be implemented as an optional 217 parameter. 219 o Examination of forwarded packets for valid return path. Routers 220 could perform a look up on the source address of packets being 221 forwarded in their routing tables. If the routing table indicates 222 a different interface as the next hop than the interface on which 223 the packet arrived, then the packet would be discarded. This 224 could lead to problems when network administrators set up 225 multiple paths in such a way that traffic doesn't always flow 226 on the same path in both directions (asymmetric routing). Note 227 that this check may degrade router performance. 229 5. Liabilities 231 Filtering of this nature has the potential to break some types of 232 special services, such as some IP Mobility implementations. It is 233 in the best interest of the ISP offering these types of special 234 services, however, to consider alternate methods of implementation, 235 such as point-to-point tunneling, or any other method which is not 236 affected by ingress traffic filtering. 238 While ingress filtering drastically reduces the success of source 239 address spoofing, it does not preclude an attacker using a forged 240 source address of another host within the permitted prefix filter 241 range. It does, however, ensure that when an attack of this nature 242 does indeed occur, a network administrator can be sure that the 243 attack is actually originating from where it advertises. This 244 simplifies tracking down of the culprit, and at worst, the 245 administrator can block a range of source addresses until the 246 problem is resolved. 248 If ingress filtering used in an environment where DHCP or BOOTP 249 is used, the network administrator would be well advised to ensure 250 that packets with a source address of 0.0.0.0 and a destination 251 of 255.255.255.255 are allowed to be forwarded to the appropriate 252 destination. Since the router is most likely performing as the BOOTP 253 or DHCP relay agent, the router will then be able to forward the 254 requests. 256 6. Summary 258 Ingress traffic filtering at the periphery of Internet connected 259 networks will reduce the effectiveness of source address spoofing 260 denial of service attacks. Network service providers and 261 administrators have already begun implementing this type of 262 filtering on periphery routers, and it is recommended that all 263 service providers do so as soon as possible. In addition to aiding 264 the Internet community as a whole to defeat this attack method, it 265 can also assist service providers in locating the source of the 266 attack if service providers can categorically demonstrate that their 267 network already has ingress filtering in place on customer links. 269 Corporate network administrators should implement filtering to 270 ensure their corporate networks are not the source of such 271 problems. Indeed, filtering could be used within an organization to 272 ensure users do not cause problems by improperly attaching systems 273 to the wrong networks. The filtering would also block a disgruntled 274 employee from anonymous attacks. 276 It is the responsibility of all network administrators to ensure 277 they do not become the unwitting source of an attack. 279 7. Security considerations 281 The primary consideration is to inherently increase security for the 282 Internet community as a whole; as more Internet Providers and 283 corporate network administrators implement ingress filtering, the 284 opportunity for an attacker to use forged source addresses as an 285 attack methodology will lessen. Tracking the source of an attack is 286 simplified when the source is more likely to be "valid." By reducing 287 the number and frequency of attacks in the Internet as a whole, 288 there will be more resources for tracking the attacks which 289 ultimately do occur. 291 8. Acknowledgments 293 The North American Network Operators Group (NANOG) [5] group as a 294 whole deserves special credit for openly discussing these issues and 295 actively seeking possible solutions. Also, thanks to Justin Newton 296 [Erol's Internet, Inc.] and Steve Bielagus [Proteon, Inc.] for their 297 comments and contributions. 299 9. References 301 [1] CERT Advisory CA.96-12; TCP SYN Flooding and IP Spoofing 302 Attacks; September 24, 1996 304 [2] B. Ziegler, "Hacker Tangles Panix Web Site", Wall Street Journal, 305 12 September 1996 307 [3] "Firewalls and Internet Security: Repelling the Wily Hacker"; 308 William R. Cheswick and Steven M. Bellovin, Addison-Wesley 309 Publishing Company, 1994; ISBN 0-201-63357-4 311 [4] RFC-1918, "Address Allocation for Private Internets"; Y. Rekhter, 312 R. Moskowitz, D. Karrenberg, G. de Groot, E. Lear; February 1996 314 [5] The North American Network Operators Group; 315 http://www.nanog.org 317 10. Authors' addresses 319 Paul Ferguson Daniel Senie 320 cisco Systems, Inc. Proteon, Inc. 321 400 Herndon Parkway 9 Technology Drive 322 Herndon, VA USA 20170 Westboro, MA USA 01581 323 Email: pferguso@cisco.com Email: dts@proteon.com