idnits 2.17.1 draft-ietf-savi-threat-scope-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 25, 2009) is 5388 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SAVI D. McPherson 3 Internet-Draft Arbor Networks 4 Intended status: Informational F. Baker 5 Expires: January 26, 2010 Cisco Systems 6 J. Halpern 7 Ericsson 8 July 25, 2009 10 SAVI Threat Scope 11 draft-ietf-savi-threat-scope-01 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 26, 2010. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 This memo discusses threats enabled by IP source address spoofing and 50 discusses a number of techniques aimed at mitigating those threats. 52 Table of Contents 54 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 5 56 3. Spoofed-based Attack Vectors . . . . . . . . . . . . . . . . . 5 57 3.1. Blind Attacks . . . . . . . . . . . . . . . . . . . . . . 6 58 3.1.1. Single Packet Attacks . . . . . . . . . . . . . . . . 6 59 3.1.2. Flood-Based DoS . . . . . . . . . . . . . . . . . . . 6 60 3.1.3. Poisoning Attacks . . . . . . . . . . . . . . . . . . 7 61 3.1.4. Third Party Recon . . . . . . . . . . . . . . . . . . 7 62 3.1.5. Spoof-based Worm/Malware Propagation . . . . . . . . . 7 63 3.1.6. Reflective Attacks . . . . . . . . . . . . . . . . . . 7 64 3.1.7. Accounting Subversion . . . . . . . . . . . . . . . . 8 65 3.1.8. Other Blind Spoofing Attacks . . . . . . . . . . . . . 8 66 3.2. Non-Blind Attacks . . . . . . . . . . . . . . . . . . . . 8 67 3.2.1. Man in the Middle (MITM) . . . . . . . . . . . . . . . 8 68 3.2.2. Third Party Recon . . . . . . . . . . . . . . . . . . 9 69 4. Current Anti-Spoofing Solutions . . . . . . . . . . . . . . . 9 70 4.1. Host to link layer neighbor or switch . . . . . . . . . . 11 71 4.2. Upstream routers . . . . . . . . . . . . . . . . . . . . . 11 72 4.3. ISP Edge PE Router . . . . . . . . . . . . . . . . . . . . 12 73 4.4. ISP NNI Router to ISP NNI Router . . . . . . . . . . . . . 12 74 4.5. Spoofing In Local Area Network Segments . . . . . . . . . 12 75 4.6. Cable Modem Subscriber Access . . . . . . . . . . . . . . 12 76 4.7. DSL Subscriber Access . . . . . . . . . . . . . . . . . . 13 77 4.8. BCP 38 . . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 4.9. Unicast RPF . . . . . . . . . . . . . . . . . . . . . . . 13 79 4.10. Port-based Address Binding . . . . . . . . . . . . . . . . 13 80 4.10.1. Manual Binding . . . . . . . . . . . . . . . . . . . . 13 81 4.10.2. Automated Binding . . . . . . . . . . . . . . . . . . 14 82 4.10.3. IEEE 802.1X . . . . . . . . . . . . . . . . . . . . . 14 83 4.11. Cryptographic Techniques . . . . . . . . . . . . . . . . . 14 84 4.12. Residual Attacks . . . . . . . . . . . . . . . . . . . . . 14 85 5. Topological Considerations . . . . . . . . . . . . . . . . . . 14 86 5.1. Address Provisioning Mechanisms . . . . . . . . . . . . . 14 87 5.2. LAN devices with Multiple Addresses . . . . . . . . . . . 15 88 5.2.1. Routers . . . . . . . . . . . . . . . . . . . . . . . 15 89 5.2.2. NATs . . . . . . . . . . . . . . . . . . . . . . . . . 15 90 5.2.3. Multi-Instance hosts . . . . . . . . . . . . . . . . . 15 91 5.2.4. Multi-LAN Hosts . . . . . . . . . . . . . . . . . . . 15 92 5.2.5. Firewalls . . . . . . . . . . . . . . . . . . . . . . 16 93 5.2.6. Mobile IP . . . . . . . . . . . . . . . . . . . . . . 16 94 5.2.7. Other Topologies . . . . . . . . . . . . . . . . . . . 16 95 5.3. IPv6 Considerations . . . . . . . . . . . . . . . . . . . 16 96 6. Applicability of Anti-Spoofing Solutions . . . . . . . . . . . 17 97 6.1. Analysis of Host Granularity Anti-Spoofing . . . . . . . . 17 98 7. Existing Techniques for IP Source Address Validation . . . . . 18 99 8. Deployment Considerations . . . . . . . . . . . . . . . . . . 19 100 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 101 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 102 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 103 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 104 12.1. Normative References . . . . . . . . . . . . . . . . . . . 21 105 12.2. Informative References . . . . . . . . . . . . . . . . . . 21 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 108 1. Overview 110 The Internet Protocol, specifically IPv4 [RFC0791] and IPv6 111 [RFC2460], employ a connectionless hop-by-hop packet forwarding 112 paradigm. A host connected to an IP network that wishes to 113 communicate with another host on the network generates an IP packet 114 with source and destination IP addressing information, among other 115 options. 117 At the IP Network Layer, or Internet Layer, there is typically no 118 required transactional state when communicating with other hosts on 119 the network. Hosts generating packets for transmission have the 120 opportunity to spoof (forge) the source address of packets which they 121 transmit. 123 Source address verification is necessary in order to detect and 124 reject spoofed packets and contribute to the overall security of IP 125 networks. In particular, source address verification techniques 126 enable detection and rejection of spoofed packets, and also 127 implicitly provide some assurances that the source address in an IP 128 packet is legitimately assigned to the system that generated the 129 packet. 131 Solutions such as BCP 38 [RFC2827] provide guidelines for one such 132 technique for network ingress filtering. However, if these 133 techniques are not implemented at the ingress point of the IP 134 network, then the validity of the source address can not be 135 positively ascertained. Furthermore, BCP 38 only implies source 136 address verification at the Internet Layer, and is most often 137 implemented on IP subnetwork address boundaries. One of the 138 difficulties in encouraging the deployment of BCP 38 is that there is 139 relatively little benefit until it is very widely deployed, which is 140 not yet the case. The local application of the principle of BCP 38 141 fortunately has local benefit, even before BCP 38 is fully deployed. 142 It also helps get the Internet towards a state where BCP 38 is more 143 widely followed. 145 There is a possibility that in a LAN environment where multiple hosts 146 share a single LAN or IP port on a switch or router, one of those 147 hosts may spoof the source addresses of other hosts within the local 148 subnet. Understanding these threats and the relevant topologies in 149 which they're introduced is critical when assessing the threats that 150 exists with source address spoofing. 152 The aim of this document is to provide some additional details 153 regarding spoofed-based threat vectors, and discuss implications of 154 various network topologies. 156 2. Glossary of Terms 158 The following acronyms and terms are used throughout this memo. 160 BGP: The Border Gateway Protocol, used to manage routing policy 161 between large networks. 163 CPE Router: Customer Premises Equipment Router. The router on the 164 customer premises, whether owned by the customer or the provider. 165 Also called the Customer Endpoint, or CE, Router. 167 IP Address: An Internet Protocol Address, whether IPv4 or IPv6. 169 ISP: Internet Service Provider. Any person or company that delivers 170 Internet service to another. 172 MAC Address: An Ethernet Address or comparable IEEE 802 series 173 address. 175 NNI Router: Network to Network Interface Router. This router 176 interface faces a similar system operated by another ISP or other 177 large network. 179 PE Router: Provider Endpoint Router. This router faces a customer 180 of an ISP. 182 Spoofing: The act of forging datagram header contents at the Link or 183 Network Layer 185 TCP: The Transmission Control Protocol, used on end systems to 186 manage data exchange. 188 uRPF: Unicast Reverse Path Forwarding. A procedure in which the 189 route table, which is usually used to look up destination 190 addresses and route towards them, is used to look up the source 191 address and ensure that one is routing away from it. When this 192 test fails, the event may be logged, and the traffic is commonly 193 dropped. 195 3. Spoofed-based Attack Vectors 197 Spoofing is employed on the Internet for a number of reasons, most of 198 which are in some manner associated with malicious or otherwise 199 nefarious activities. In general, two classes of spoofed-based 200 attack vectors exists; blind attacks and non-blind attacks. The 201 follow sections provide some information of blind and non-blind 202 attacks. 204 3.1. Blind Attacks 206 Blind attacks typically occur when an attacker isn't on the same 207 local area network as a source or target, or when an attacker has no 208 access to the datapath between the attack source(s) and the target 209 systems. The result is that they have no access to legitimate source 210 and target systems. 212 3.1.1. Single Packet Attacks 214 One type of blind attacks, which we'll refer to here as "single 215 packet DoS attacks", involves an attacking system injecting spoofed 216 information into the network which results in either a complete crash 217 of the target system, or in some manner poisons some network 218 configuration or other information on a target system such to impact 219 network or other services. 221 An example of an attack that can cause a receiving system to crash is 222 a LAND attack. A LAND attack packet would consist of an attacking 223 system forwarding a packet (e.g., TCP SYN) to a target system that 224 contains both a source and destination address of that target system. 225 The target system would "lock up" when creating connection state 226 associated with the packet, or would get stuck in a state where it 227 continuously replies to itself. 229 Another example of a single packet DoS attack involves that of a 230 system poisoning network or DNS cache information, perhaps in order 231 to simply break a given hosts connection, enable MITM or other 232 attacks. Network level attacks that could involve single packet DoS 233 include ARP cache poisoning and ICMP redirects. 235 3.1.2. Flood-Based DoS 237 Flooding-based DoS attack vectors are particularly effective attacks 238 on the Internet today. They usually entail flooding a large number 239 of packets towards a target system, with the hopes of either 240 exhausting connection state on the target system, consuming all 241 packet processing capabilities of the target or intermediate systems, 242 or consuming a great deal of bandwidth available to the target system 243 such that they are essentially inaccessible. 245 Because these attacks require no reply from the target system and 246 require no legitimate transaction state, attackers often attempt to 247 obfuscate the identity of the systems that are generating the attack 248 traffic by spoofing the source IP address of the attacking traffic 249 flows. Because ingress filtering isn't applied ubiquitously on the 250 Internet today, spoof-based flooding attack vectors are typically 251 very difficult to traceback. In particular, there may be one or more 252 attacking sources beyond your network border, and the attacking 253 sources may or may not be legitimate sources, it's difficult to 254 discriminate if the sources are not directly connected to the local 255 routing system. 257 Common flood-based DoS attack vectors today include SYN floods, ICMP 258 floods, and IP fragmentation attacks. Attackers may use a single 259 legitimate or spoofed fixed attacking source addresses, although 260 frequently they cycle through large swaths of address space. As a 261 result, mitigating these attacks on the receiving end with source- 262 based policies is extremely difficult. 264 Furthermore, the motivator for spoof-based DoS attacks may actually 265 be to encourage the target to filter explicitly on a given set of 266 source addresses, or order to disrupt the legitimate owner(s) access 267 to the target system. 269 3.1.3. Poisoning Attacks 271 As discussed in single-packet DoS above, there are several other 272 attack mechanisms that employ source address spoofing. The more 273 common of these attack vectors include DNS cache poisoning, ARP cache 274 poisoning, and ICMP redirects. While these attacks can be used for 275 disrupting services, they're often used to redirect traffic to 276 network elements where attack intends to carry out additional 277 malicious activities. 279 3.1.4. Third Party Recon 281 Third party reconnaissance attacks may be either blind or non-blind 282 attacks. An example of third party reconnaissance is when an 283 attacker wishes to fingerprint a remote operating system type, 284 perhaps in order to initiate some TCP session hijacking, and in order 285 to do so must be able to identify the TCP sequence and algorithm 286 employed by the target system. Initiating a determined number of 287 connections with the target system may assist with this. 289 3.1.5. Spoof-based Worm/Malware Propagation 291 Self-propagating malware has been observed that spoofs it's source 292 address when attempting to propagate to other systems. Presumably, 293 this was done to obfuscate the actual source address of the infected 294 system. 296 3.1.6. Reflective Attacks 298 DNS reflective amplification attacks are a particularly potent DoS 299 attack vector on the Internet today. Like other amplification 300 attacks, an attack source generates a packet with a source-spoofed 301 address mapping to that of the target system. The packet, upon 302 receipt by the victim or some intermediate node, typically elicits a 303 large reply message, which is directed to the target of the attack. 304 The amplification factor observed for attacks targeting DNS root and 305 other top level domain name infrastructure in early 2006 was on the 306 order of 76:1. The result is that just 15 attacking sources with 307 512k of upstream attack bandwidth could generate one Gbps of response 308 attack traffic towards a target system. 310 Smurf attacks employ a similar reflective amplification attack 311 vector, exploiting traditional default IP subnet directed broadcast 312 address behaviors that would result in all the active hosts on a 313 given subnet responding to (spoofed) ICMP echo request from an 314 attacker, and generating a large amount of ICMP echo response traffic 315 directed towards a target system. They were particularly effective 316 in large campus LAN environments where 50k or more hosts might reside 317 on a single subnet. 319 3.1.7. Accounting Subversion 321 If an attacker wishes to distribute content or other material in a 322 manner that employs protocols that require only uni-directional 323 flooding and generate no end-end transactional state, they may desire 324 to spoof the source IP address of that content in order to avoid 325 detection or accounting functions enabled at the IP layer. 327 3.1.8. Other Blind Spoofing Attacks 329 Other Blind spoofing attacks might include spoofing in order to 330 exploit source routing or other policy based routing implemented in a 331 network. It may also be possible in some environments to use 332 spoofing techniques to perform blind or non-blind attacks on the 333 routers in a site or in the Internet. There are many techniques to 334 mitigate these attacks, but it is well known that there are 335 vulnerabilities in this area. 337 3.2. Non-Blind Attacks 339 Non-blind attacks often involve mechanisms such as eavesdropping on 340 connection, resetting state so that new connections may be hijacking, 341 and an array of other attack vectors. Perhaps the most common of 342 these attack vectors is known as man in the middle attacks. 344 3.2.1. Man in the Middle (MITM) 346 Connection Hijacking is one of the more common man in the middle 347 attack vectors. In order to hijack a connection an attacker usually 348 needs to be in the forwarding path and often times employs TCP RST or 349 other attacks in order to reset a transaction. The attacker may have 350 already compromised a system that's in the forwarding path, or they 351 may which to insert themselves in the forwarding path. 353 For example, an attacker with access to a host on LAN segment may 354 wish to redirect all the traffic on the local segment destined for a 355 default gateway address (or all addresses) to itself in order to 356 perform man-in-the-middle attacks. In order to accomplish this the 357 attacker might transmit gratuitous ARP [RFC0826] messages or ARP 358 replies to the Ethernet broadcast address ff:ff:ff:ff:ff:ff, 359 notifying all the hosts on the segment that the IP address(es) of the 360 target(s) now map to it's own MAC address. If the port to which the 361 attacker is connected were to implement policy that binds a single 362 Link Layer and IP address tuple to that port upon initial 363 provisioning, spoofed packets, at the Link Layer and/or Network 364 Layer, would be discarded on ingress. 366 3.2.2. Third Party Recon 368 Another example of third party reconnaissance that falls into both 369 the blind and non-blind attack class involves spoofing packets 370 towards a given target system and observing either target or 371 intermediate system responses. For example, if an attacker were to 372 source spoof TCP SYN packets towards a target system from a large set 373 of source addresses, and observe responses from that target system or 374 some intermediate firewall or other middle box, they would be able to 375 identify what IP layer filtering policies may be in place to protect 376 that system. 378 4. Current Anti-Spoofing Solutions 380 The first requirement is to eliminate datagrams with spoofed 381 addresses from the Internet. Identifying and dropping datagrams 382 whose source address is incompatible with the Internet topology at 383 sites where the relationship between the source address and topology 384 can be checked can eliminate such datagrams. For example, Internet 385 devices can confirm that: 387 o The IP source address is appropriate for the lower layer address 388 (they both identify the same system) 390 o The IP source address is appropriate for the device at the layer 2 391 switch port (the address was assigned to a, and perhaps the, 392 system that uses that port) 394 o The prefix to which the IP source address belongs is appropriate 395 for the part of the network topology from which the IP datagram 396 was received (while the individual system may be unknown, it is 397 reasonable to believe that the system is located in that part of 398 the network). 400 Filtering points farther away from the source of the datagram can 401 make decreasingly authoritative assertions about the validity of the 402 source address in the datagram. Nonetheless, there is value in 403 dropping traffic that is clearly inappropriate, and in maintaining 404 knowledge of the level of trust one can place in an address. 406 Edge Network 1 CPE-ISP _.------------. 407 _.----------------. Ingress/ ISP A `--. 408 ,--'' `---. ,' `. 409 ,' +----+ +------+ +------+ `. / +------+ +------+ \\ 410 ( |Host+--+Switch+--+ CPE +---)-(---+ PE +- - - -+ NNI | ) 411 `. +----+ +------+ |Router| ,' \\ |Router| |Router| / 412 `---. Host-neighbor +------+' `.+------+ +--+---+,' 413 `----------------'' '--. |_.-' 414 `------------'| 415 | 416 Edge Network 2 ISP-ISP Ingress | 417 _.----------------. _.----------.| 418 ,--'' `---. ,-'' |--. 419 ,' +----+ +------+ +------+ `. ,+------+ +--+---+. 420 ( |Host+--+Switch+--+ CPE +---)---+-+ PE +- - - -+ NNI | \\ 421 `. +----+ +------+ |Router| ,' ( |Router| |Router| ) 422 `---. +------+' \\ +------+ +------+ / 423 `----------------'' `. ,' 424 '--. ISP B _.-' 425 `----------'' 427 Figure 1: Points where an address can be validated 429 Figure 1 illustrates five places where a source address can be 430 validated: 432 o Host to host or host to switch, 434 o Host to enterprise CPE Router, 436 o Enterprise CPE Router to ISP edge PE Router, 438 o ISP NNI Router to ISP NNI Router, and the 440 o ISP edge PE Router facing the destination CPE Router. 442 In general, datagrams with spoofed addresses can be detected and 443 discarded by devices that have an authoritative mapping between IP 444 addresses and the network topology. For example, a device that has 445 an authoritative table between Link Layer and IP addresses on a link 446 can discard any datagrams in which the IP address is not associated 447 with the Link Layer address in the datagram. The degree of 448 confidence in the source address depends on where the spoofing 449 detection is performed and the prefix aggregation in place between 450 the spoofing detection and the source of the datagram. 452 4.1. Host to link layer neighbor or switch 454 The first point at which a datagram with a spoofed address can be 455 detected is on the link to which the source of the datagram is 456 connected. At this point in the network, the source Link Layer and 457 IP addresses are both available, and can be verified against each 458 other. A datagram in which the IP source address does not match the 459 corresponding Link Layer address can be discarded. Of course, the 460 trust in the filtering depends on the trust in the method through 461 which the mappings are developed. This mechanism can be applied by 462 neighboring hosts, or by the first hop router. 464 On a shared medium link, such as Ethernet, the best that can be done 465 is to verify the Link Layer and IP addresses against the mappings. 466 When the link is not shared, such as when the hosts are connected 467 through a switch, the source host can be identified precisely based 468 on the port through which the datagram is received or the MAC address 469 if it is known to the switch. Port identification prevents 470 transmission of malicious datagrams whose Link Layer and IP addresses 471 are both spoofed to mimic another host. 473 4.2. Upstream routers 475 Beyond the first hop router, subsequent routers may additionally 476 filter traffic from downstream networks. Because these routers do 477 not have access to the Link Layer address of the device from which 478 the datagram was sent, they are limited to confirming that the source 479 IP address is within a prefix that is appropriate for downstream 480 router from which the datagram was received. 482 Options include the use of simple access lists or the use of unicast 483 reverse path filtering (uRPF). Access lists are generally 484 appropriate only for the simplest cases, as management can be 485 difficult. Strict Unicast RPF accepts the source address on a 486 datagram if and only if it comes from a direction that would be 487 rational to send a datagram directed to the address, which means that 488 the filter is derived from routing information. These filtering 489 procedures are discussed in more detail in [RFC3704]. 491 4.3. ISP Edge PE Router 493 An obvious special case of the discussion is with an ISP PE router, 494 where it provides its customer with access. BCP 38 specifically 495 encourages ISPs to use ingress filtering to limit the incidence of 496 spoofed addresses in the network. 498 The question that the ISP must answer for itself is the degree to 499 which it trusts its downstream network. A contract might be written 500 between an ISP and its customer requiring that the customer apply the 501 procedures of network ingress filtering to the customer's own 502 network, although there's no way upstream networks would be able to 503 verify this. 505 4.4. ISP NNI Router to ISP NNI Router 507 The considerations explicitly related to customer networks can also 508 be applied to neighboring ISPs. An interconnection agreement might 509 be written between two companies requiring network ingress filtering 510 policy be implemented on all customers connections. ISPs might, for 511 example, mark datagrams from neighboring ISPs that do not sign such a 512 contract or demonstrably do not behave in accordance with it as 513 'untrusted'. Alternatively, the ISP might place untrusted prefixes 514 into a separate BGP community and use that to advertise the level of 515 trust to its BGP peers. 517 In this case, uRPF is less effective as a verification tool, due to 518 asymmetric routing. However, when it can be shown that spoofed 519 addresses are present, the procedure can be applied. 521 4.5. Spoofing In Local Area Network Segments 523 On Link Layer segments where multiple hosts reside, or a single MAC 524 address can be associated with a port or interface, if a binding 525 between a hardware address (e.g., MAC address) and corresponding IP 526 address(es) are not provisioned via some means (either manual or 527 dynamic mechanisms), then an attacker may exploit attack vectors that 528 enable MITM or other spoof-based attacks. 530 4.6. Cable Modem Subscriber Access 532 Cable Modem Termination Systems (CMTS) employ DOCSIS Media Access 533 Control (MAC) domains, which are similar to Ethernet LAN 534 environments. 536 4.7. DSL Subscriber Access 538 Something about DSLAMs here.. 540 4.8. BCP 38 542 If BCP 38 [RFC2827] is implemented in LAN segments, it is typically 543 done so on subnetwork boundaries and traditionally relates only to 544 Network Layer ingress filtering policies. The result is that hosts 545 within the segment cannot spoof packets from address space outside of 546 the local segment itself, however, they may still spoof packets using 547 sources addresses that exist within the local network segment. 549 4.9. Unicast RPF 551 Unicast RPF is a crude mechanism to automate definition of BCP 38 552 style filters based on routing table information. It's applicability 553 parallels that of BCP 38, although deployment caveats exists, as 554 outlined in [RFC3704]. 556 4.10. Port-based Address Binding 558 Much of the work SAVI appears to be initially targeting is aimed at 559 minimizing source address spoofing in the LAN. In particular, if 560 mechanisms can be defined to accommodate configuration of port 561 binding information for IP and MAC layer addresses in LAN 562 environments, a large portion of the spoofing threat space in the LAN 563 can be marginalized. 565 However, establishing these binding is not trivial, and varying 566 across both topologies type and address allocation mechanisms. 568 4.10.1. Manual Binding 570 Binding of a single Link Layer and Network Layer address to a port 571 may initially seem trivial. However, two primary areas exist that 572 can complicate such techniques. In particular, these area involves 573 topologies where more than a single IP layer address may be 574 associated with a MAC address on a given port, or where multiple 575 hosts are connected to a single IP port. Furthermore, if one or more 576 dynamic address allocation mechanisms such as DHCP are employed, then 577 some mechanism must exist to associate those IP layer addresses with 578 the appropriate Link layer ports, as addresses are allocated or 579 reclaimed. 581 4.10.2. Automated Binding 583 DHCP, RADIUS, Other solutions, Cisco IP Source Guard, etc.. 585 4.10.3. IEEE 802.1X 587 IEEE 802.1x is an authentication protocol that permits a network to 588 determine the identity of a system seeking to join it and apply 589 authorization rules to permit or deny the action. 591 4.11. Cryptographic Techniques 593 Needless to say, MITM and replay attacks can typically be mitigated 594 with cryptographic techniques. However, many of the applications 595 today either don't or can't employ cryptographic authentication and 596 protection mechanisms. ARP and DNS are two examples. DNSSEC does 597 propose to assist, but until it's deployed ubiquitously, from 598 clients, to resolvers, to authoritative roots, clients and resolvers 599 are still vulnerable to replay, cache poisoning and MITM attacks. 601 4.12. Residual Attacks 603 Stuff which these solutions don't address 605 Stuff which no one will use the existing solutions for 607 5. Topological Considerations 609 As noted previously, topological components and address allocation 610 mechanisms have significant implications on what is feasible with 611 regard to Link layer address and IP address port bindings. The 612 following sections discuss some of the various topologies and address 613 allocation mechanisms that proposed SAVI solutions should attempt to 614 address. 616 5.1. Address Provisioning Mechanisms 618 In a strictly static environment configuration management for access 619 filters that map Link Layer and Network Layer addresses on a specific 620 switch port might be a viable option. However, most networks, 621 certainly, those that accommodate actual human users, are much more 622 dynamic in nature. As such, mechanisms that provide port-MAC-IP 623 bindings need to accommodate dynamic address allocation schemes 624 enabled by protocols such as DHCP. 626 5.2. LAN devices with Multiple Addresses 628 From a topology considerations perspective, when attempting 629 port-MAC-IP bindings, host connected to switch ports that may have 630 one or more IP addresses, or certainly, devices that forward packets 631 from other network segments, are problematic. 633 5.2.1. Routers 635 The most obvious example of devices that are problematic when 636 attempting to implement port-MAC-IP bindings is that of routers. 637 Routers not only originate packets themselves and often have multiple 638 interfaces, but also forward packets from other network segments. As 639 a result, it's difficult for port-MAC-IP binding rules to be 640 established a priori, because it's likely that many addresses and IP 641 subnets should be associated with the port-MAC in question. 643 5.2.2. NATs 645 Prefix-based and multi-address NATs also become problematic, for the 646 same reasons as routers. Because they may forward traffic from an 647 array of address, a priori knowledge must exist providing what IPs 648 should be associated with a given port-MAC pair. 650 5.2.3. Multi-Instance hosts 652 Another example that introduces complexities is that of multi- 653 instance hosts attached to a switch port. Multi clients, with the 654 same or different MACs, may be attached to the port and may either 655 have static IP addresses assigned, or may receive one or more 656 dynamically via DHCP or similar means. Accommodating multi-instance 657 hosts, or even blade-server type devices dynamic is feasible, buy may 658 introduces complexities if the solution in question does not 659 accommodate unique considerations introduced in these environments. 661 5.2.4. Multi-LAN Hosts 663 Multi-interface hosts, in particular those that are multi-homed and 664 may forward packets from any of a number of source addresses, can be 665 problematic as well. In particular, if a port-MAC-IP binding is made 666 on each of the interfaces, and then either a loopback IP or the 667 address of third interface is used as the source address of a packet 668 and forward through in interface for which the port-MAC-IP binding 669 doesn't map, the traffic may be discarded. Static configuration of 670 port-MAC-IP bindings may accommodate this scenario, although some a 671 priori knowledge on address assignment and topology is required. 673 5.2.5. Firewalls 675 Firewalls that forward packets from other network segments, or serve 676 as a source for locally originated packets, suffer from the same 677 issues as routers. 679 5.2.6. Mobile IP 681 Mobile IP hosts in both IPv4 and IPv6 as proper members of the site 682 where they are currently located. Their care-of-address is a 683 properly assigned address that is on the link they are using. And 684 their packets are sent and received using that address. (There was 685 at one time consideration of allowing mobile hosts to use their home 686 address when away from home. This was not done, precisely to ensure 687 that mobile hosts comply with source address validity requirements.) 688 Mobile Hosts with multiple physical interfaces fall into the cases 689 above. 691 Mobile IP home agents are somewhat more interesting. Although they 692 are (typically) fixed devices, they are required to send and receive 693 packets addressed from or to any currently properly registered mobile 694 node. From an analysis point of view, even though the packets that a 695 Home Agent handles are actually addressed to or from the link the HA 696 is on, it is probably best to think of them as routers, with a 697 virtual interface to the actual hosts they are serving. 699 5.2.7. Other Topologies 701 Any topology that results in the possibility that a device connected 702 to a switch port may forward packets with more than a single source 703 address for packet which it originated may be problematic. 704 Additionally, address allocation schemas introduce additional 705 considerations when examining a given SAVI solutions space. 707 5.3. IPv6 Considerations 709 IPv6 introduces additional capabilities which indirectly complicate 710 the spoofing analysis. IPv6 introduces and recommends the use of 711 stateless address autoconfiguration (often referred to as SLAAC). 712 This allows hosts to determine their IP prefix, select an ID, and 713 then start communicating. While there are many advantages to this, 714 the absence of control interactions complicates the process of 715 behavioral enforcement. 717 An additional complication is the very large ID space. Again, this 718 64 bit ID space provided by IPv6 has many advantages. It provides 719 the opportunity for many useful behaviors. However, it also means 720 that in the absence of controls, hosts can mint anonymous addresses 721 as often as they like, modulo the idosyncrasies of the duplicate 722 address procedure. Like many behaviors, this is a feature for some 723 purposes, and a problem for others. But it does have implications 724 for switch cost; the switch needs to store more addresses and so 725 needs more memory. 727 6. Applicability of Anti-Spoofing Solutions 729 The above sections covered a number of security threats. Not all 730 these threats can be prevented by anti-spoofing techniques. However, 731 all of these threats can be ameliorated to some degree. We can look 732 at three categories of effect we can achieve: 734 Prevention: Some of the threats described above explicitly require 735 that a host send packets using some other active hosts IP address 736 as a source. Anti-Spoofing measures can prevent these attacks. 738 Impediment: Many of the attacks above, such as some kinds of DoS 739 attacks, can be conducted more easily if the attacking host can 740 use multiple different IP addresses. Depending upon the kind of 741 anti-spoofing available, the scope of such false addresses, or 742 even their use, may be prevented, hindering the attacker even if 743 the attack is not completely prevented. 745 Traceability: Even when attacks can not be prevented, the ability to 746 reliably trace an attack allows appropriate responses, and thereby 747 also creates an environment which discourages attacks instead of 748 encouraging them. Thus, ensuring that even attacks which are not 749 dependent upon spoofing can not use source address spoofing to 750 hide their origin is extremely important. 752 For example, sites which deploy BCP 38 can not be the source of 753 attacks which rely on spoofing the source site from which an attack 754 was launched. Wide deployment of BCP 38 would also simplify the task 755 of tracking attacks back to their actual origin. 757 6.1. Analysis of Host Granularity Anti-Spoofing 759 Applying anti-spoofing techniques at the host level enables a site to 760 achieve several valuable objectives. While it is likely the case 761 that for many site topologies and policies, full source spoofing 762 protection is not possible, it is also true that for many sites there 763 are steps that can be taken that provide benefit. 765 One important class of benefit is masquerade prevention. Security 766 threats involving one machine masquerading as another, for example in 767 order to hijack an apparently secure session, can occur within a site 768 with significant impact. Having mechanisms such that host facing 769 devices prevent this is a significant intra-site security 770 improvement. Given that security experts report that most security 771 breaches are internal, this can be valuable. One example of this is 772 that such techniques should mitigate internal attacks on the site 773 routing system. 775 A second class of benefit is related to the traceability described 776 above. When a security incident is detect, either within a site, or 777 externally (and traced to the site, it can be critical to determine 778 what the actual source of the incident was. If address usage can be 779 tied to the kinds of anchors described earlier, then it is possible 780 to respond to security incidents. 782 In addition to these local observable benefits, there can be more 783 global benefits. For example, if address usage is tied to anchors, 784 it may be possible to prevent or control the use of large numbers of 785 anonymous IPv6 addresses for attacks, or at least to track even those 786 attacks back to their source. 788 7. Existing Techniques for IP Source Address Validation 790 Existing techniques for IP source address validation are 791 insufficient. While each technique has its own shortcomings, the 792 following list of general categories of reasons include some of the 793 deficiencies of all existing technique: 795 False negatives: Techniques may yield false negatives, thus enabling 796 an attacker to select an IP source address that is spoofed, but 797 still passes IP source address validation. 799 False positives: Techniques may yield false positives, thereby 800 causing interruption or denial of service to hosts that use 801 legitimate IP source addresses. 803 Non-trivial configuration: Requirements for non-trivial 804 configuration imply expenditures and pose a risk for 805 misconfiguration, which may again lead to false positives or false 806 negatives. Both may discourage operators from employing a given 807 technique. 809 Proprietary: Procurement policies oftentimes require techniques that 810 are standardized, hence hindering or preventing the deployment of 811 proprietary techniques. 813 The only standardized technique for IP source address validation is 814 ingress filtering [RFC2827]. This calls for routers to check whether 815 the prefix of a to-be-forwarded packet's IP source address is amongst 816 a list of prefixes considered legitimate for the interface through 817 which the packet arrives. Packets that fail this check are 818 discarded. 820 Ingress filtering may yield false negatives in a deterministic 821 manner. Packets with a legitimate IP source address prefix, but a 822 spoofed interface identifier, pass ingress filtering checks. Also, 823 packets with an illegitimate IP source address prefix pass the checks 824 as long as the prefix is from the list of prefixes considered 825 legitimate, if more than one prefix is considered as legitimate on 826 the ingress interface.. 828 Ingress filtering implementations that require manual establishment 829 of the list of legitimate prefixes cause considerable configuration 830 overhead. Unicast Reverse Path Forwarding (uRPF) mitigates this 831 issue by automatically deriving the list of legitimate prefixes from 832 a router's forwarding table: A to-be-forwarded packet's IP source 833 address prefix is considered legitimate if the packet is coming 834 through an interface via which return traffic would be routed. On 835 the other hand, Unicast Reverse Path Forwarding may yield false 836 positives, in particular for hosts and networks with multiple, 837 topologically separate Internet attachments [RFC3704]. 839 Consequently, there is a need for an IP source address validation 840 technique that avoids false negatives and false positives, that can 841 be set up with no or only trivial configuration, and that has been 842 standardized. The development of such a technique is the goal of the 843 proposed Source Address Validation Improvements (SAVI) working group 844 in the Internet Engineering Task Force. 846 8. Deployment Considerations 848 From a global Internet perspective, deployment of anti- spoofing 849 techniques tends to suffer from a "tragedy of the commons" situation. 850 That is, there is a general consensus that everyone should implement 851 anti-spoofing measures, yet individual organizations don't want to 852 bear the cost of deployment themselves, often because demonstrating 853 direct tangible return on investment is not possible. Upon analysis, 854 it often seems apparent that local implementation of anti-spoofing 855 measures is of more benefit to the "greater Internet" than the local 856 network domain itself. A similar situation occurs with de- 857 aggregation of Internet routing information for multi-homing and 858 traffic engineering purposes, as well as the lack of explicit inter- 859 domain routing prefix filters on the Internet. 861 Until network operators begin to accept that their local design 862 choices have global implications, and act upon this responsibility, 863 the problem is not going to go away. 865 Ideally, with additional work in the areas of SAVI to ease deployment 866 and management burdens, the deployment cost to operators will 867 decrease and more wide-scale deployment will continue. Furthermore, 868 application of SAVI-like techniques provides more obvious benefits to 869 network administrators that are concerned with MITM and similar 870 attacks. 872 As mentioned earlier, there are local security benefits to the 873 deployment of SAVI security mechanisms. This may help motivate the 874 deployment of tools with widespread benefit. 876 9. IANA Considerations 878 This memo asks the IANA for no new parameters. 880 Note to RFC Editor: This section will have served its purpose if it 881 correctly tells IANA that no new assignments or registries are 882 required, or if those assignments or registries are created during 883 the RFC publication process. From the author"s perspective, it may 884 therefore be removed upon publication as an RFC at the RFC Editor"s 885 discretion. 887 10. Security Considerations 889 This document provides limited discussion of some security threats 890 source address validation improvements will help to mitigate. It is 891 not meant to be all-inclusive, either from a threat analysis 892 perspective, or from the source address verification application 893 side. 895 It is seductive to think of SAVI solutions as providing the ability 896 to use this technology to trace a datagram to the person, or at least 897 end system, that originated it. For several reasons, the technology 898 can be used to derive circumstantial evidence, but does not actually 899 solve that problem. 901 In the Internet Layer, the source address of a datagram should be the 902 address of the system that originated it and to which any reply is 903 expected to come. But systems fall into several broad categories. 904 Many are single user systems, such as laptops and PDAs. Multi-user 905 systems are commonly used in industry, and a wide variety of 906 middleware systems and application servers have no user at all, but 907 by design relay messages or perform services on behalf of users of 908 other systems (e.g., SMTP and peer-to-peer file sharing). 910 Until every Internet-connected network implements source address 911 validation at the ultimate network ingress, and assurances exist that 912 intermediate devices are to never modify datagram source addresses, 913 source addresses must not be used as an authentication mechanism. 914 The only technique to unquestionably verify source addresses of a 915 received datagram are cryptographic authentication mechanisms such as 916 IPSEC. 918 11. Acknowledgements 920 A portion of the primer text in this document came directly from 921 [I-D.baker-sava-operational], authored by Fred Baker and Ralph Droms. 922 Many thanks to Christian Vogt for contributing text and a careful 923 review of this document. 925 12. References 927 12.1. Normative References 929 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 930 September 1981. 932 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 933 (IPv6) Specification", RFC 2460, December 1998. 935 12.2. Informative References 937 [I-D.baker-sava-operational] 938 Baker, F. and R. Droms, "IPv4/IPv6 Source Address 939 Verification", draft-baker-sava-operational-00 (work in 940 progress), June 2007. 942 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 943 converting network protocol addresses to 48.bit Ethernet 944 address for transmission on Ethernet hardware", STD 37, 945 RFC 826, November 1982. 947 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 948 Defeating Denial of Service Attacks which employ IP Source 949 Address Spoofing", BCP 38, RFC 2827, May 2000. 951 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 952 Networks", BCP 84, RFC 3704, March 2004. 954 Authors' Addresses 956 Danny McPherson 957 Arbor Networks 959 Email: danny@arbor.net 961 Fred Baker 962 Cisco Systems 964 Email: fred@cisco.com 966 Joel M. Halpern 967 Ericsson 969 Email: jhalpern@redback.com