idnits 2.17.1 draft-ietf-savi-threat-scope-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (September 8, 2010) is 4979 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 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 VeriSign, Inc. 4 Intended status: Informational F. Baker 5 Expires: March 12, 2011 Cisco Systems 6 J. Halpern 7 Ericsson 8 September 8, 2010 10 SAVI Threat Scope 11 draft-ietf-savi-threat-scope-03 13 Abstract 15 This memo discusses threats enabled by IP source address spoofing and 16 discusses a number of techniques aimed at mitigating those threats. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on March 12, 2011. 35 Copyright Notice 37 Copyright (c) 2010 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 5 54 3. Spoofed-based Attack Vectors . . . . . . . . . . . . . . . . . 6 55 3.1. Blind Attacks . . . . . . . . . . . . . . . . . . . . . . 6 56 3.1.1. Single Packet Attacks . . . . . . . . . . . . . . . . 6 57 3.1.2. Flood-Based DoS . . . . . . . . . . . . . . . . . . . 6 58 3.1.3. Poisoning Attacks . . . . . . . . . . . . . . . . . . 7 59 3.1.4. Spoof-based Worm/Malware Propagation . . . . . . . . . 7 60 3.1.5. Reflective Attacks . . . . . . . . . . . . . . . . . . 8 61 3.1.6. Accounting Subversion . . . . . . . . . . . . . . . . 8 62 3.1.7. Other Blind Spoofing Attacks . . . . . . . . . . . . . 8 63 3.2. Non-Blind Attacks . . . . . . . . . . . . . . . . . . . . 9 64 3.2.1. Man in the Middle (MITM) . . . . . . . . . . . . . . . 9 65 3.2.2. Third Party Recon . . . . . . . . . . . . . . . . . . 9 66 4. Current Anti-Spoofing Solutions . . . . . . . . . . . . . . . 9 67 4.1. Host to link layer neighbor via switch . . . . . . . . . . 11 68 4.2. Upstream routers . . . . . . . . . . . . . . . . . . . . . 11 69 4.3. ISP Edge PE Router . . . . . . . . . . . . . . . . . . . . 12 70 4.4. ISP NNI Router to ISP NNI Router . . . . . . . . . . . . . 12 71 4.5. Spoofing In Local Area Network Segments . . . . . . . . . 12 72 4.6. Cable Modem Subscriber Access . . . . . . . . . . . . . . 13 73 4.7. DSL Subscriber Access . . . . . . . . . . . . . . . . . . 13 74 4.8. BCP 38 . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 4.9. Unicast RPF . . . . . . . . . . . . . . . . . . . . . . . 13 76 4.10. Port-based Address Binding . . . . . . . . . . . . . . . . 13 77 4.10.1. Manual Binding . . . . . . . . . . . . . . . . . . . . 14 78 4.10.2. Automated Binding . . . . . . . . . . . . . . . . . . 14 79 4.10.3. IEEE 802.1X . . . . . . . . . . . . . . . . . . . . . 14 80 4.11. Cryptographic Techniques . . . . . . . . . . . . . . . . . 14 81 4.12. Residual Attacks . . . . . . . . . . . . . . . . . . . . . 15 82 5. Topological Considerations . . . . . . . . . . . . . . . . . . 15 83 5.1. Address Provisioning Mechanisms . . . . . . . . . . . . . 15 84 5.2. LAN devices with Multiple Addresses . . . . . . . . . . . 15 85 5.2.1. Routers . . . . . . . . . . . . . . . . . . . . . . . 15 86 5.2.2. NATs . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 5.2.3. Multi-Instance Hosts . . . . . . . . . . . . . . . . . 16 88 5.2.4. Multi-LAN Hosts . . . . . . . . . . . . . . . . . . . 16 89 5.2.5. Firewalls . . . . . . . . . . . . . . . . . . . . . . 16 90 5.2.6. Mobile IP . . . . . . . . . . . . . . . . . . . . . . 17 91 5.2.7. Other Topologies . . . . . . . . . . . . . . . . . . . 17 92 5.3. IPv6 Considerations . . . . . . . . . . . . . . . . . . . 17 93 6. Applicability of Anti-Spoofing Solutions . . . . . . . . . . . 18 94 6.1. Analysis of Host Granularity Anti-Spoofing . . . . . . . . 18 95 7. Existing Techniques for IP Source Address Validation . . . . . 19 96 8. Deployment Considerations . . . . . . . . . . . . . . . . . . 20 97 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 98 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 99 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 100 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 101 12.1. Normative References . . . . . . . . . . . . . . . . . . . 22 102 12.2. Informative References . . . . . . . . . . . . . . . . . . 22 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 105 1. Overview 107 The Internet Protocol, specifically IPv4 [RFC0791] and IPv6 108 [RFC2460], employ a connectionless hop-by-hop packet forwarding 109 paradigm. A host connected to an IP network that wishes to 110 communicate with another host on the network generates an IP packet 111 with source and destination IP addressing information, among other 112 options. 114 At the IP Network Layer, or Internet Layer, there is typically no 115 required transactional state when communicating with other hosts on 116 the network. Hosts generating packets for transmission have the 117 opportunity to spoof (forge) the source address of packets which they 118 transmit. 120 Source address verification is necessary in order to detect and 121 reject spoofed packets and contribute to the overall security of IP 122 networks. In particular, source address verification techniques 123 enable detection and rejection of spoofed packets, and also 124 implicitly provide some assurances that the source address in an IP 125 packet is legitimately assigned to the system that generated the 126 packet. 128 Solutions such as BCP 38 [RFC2827] provide guidelines for one such 129 technique for network ingress filtering. However, if these 130 techniques are not implemented at the ingress point of the IP 131 network, then the validity of the source address cannot be positively 132 ascertained. Furthermore, BCP 38 only implies source address 133 verification at the Internet Layer, and is most often implemented on 134 IP subnetwork address boundaries. One of the difficulties in 135 encouraging the deployment of BCP 38 is that there is relatively 136 little benefit until it is very widely deployed, which is not yet the 137 case. The local application of the principle of BCP 38 fortunately 138 has local benefit, even before BCP 38 is fully deployed. It also 139 helps get the Internet towards a state where BCP 38 is more widely 140 followed. 142 It should be noted that while BCP 38 directs providers to provide 143 protection from spoofed prefixes, it is clearly desirable for 144 enterprise operators to provide that protection more locally, and 145 with better traceability. This allows the enterprise to be a better 146 Internet participant, and to quickly detect and remedy problems when 147 they occur. 149 Also, there is a possibility that in a LAN environment where multiple 150 hosts share a single LAN or IP port on a switch or router, one of 151 those hosts may spoof the source addresses of other hosts within the 152 local subnet. Understanding these threats and the relevant 153 topologies in which they're introduced is critical when assessing the 154 threats that exist with source address spoofing. 156 The aim of this document is to provide some additional details 157 regarding spoofed-based threat vectors, and discuss implications of 158 various network topologies. 160 2. Glossary of Terms 162 The following acronyms and terms are used throughout this memo. 164 BGP: The Border Gateway Protocol, used to manage routing policy 165 between large networks. 167 CPE Router: Customer Premises Equipment Router. The router on the 168 customer premises, whether owned by the customer or the provider. 169 Also called the Customer Edge, or CE, Router. 171 IP Address: An Internet Protocol Address, whether IPv4 or IPv6. 173 ISP: Internet Service Provider. Any person or company that delivers 174 Internet service to another. 176 MAC Address: An Ethernet Address or comparable IEEE 802 series 177 address. 179 NNI Router: Network to Network Interface Router. This router 180 interface faces a similar system operated by another ISP or other 181 large network. 183 PE Router: Provider Edge Router. This router faces a customer of an 184 ISP. 186 Spoofing: The act of forging datagram header contents at the Link or 187 Network Layer 189 TCP: The Transmission Control Protocol, used on end systems to 190 manage data exchange. 192 uRPF: Unicast Reverse Path Forwarding. A procedure in which the 193 route table, which is usually used to look up destination 194 addresses and route towards them, is used to look up the source 195 address and ensure that one is routing away from it. When this 196 test fails, the event may be logged, and the traffic is commonly 197 dropped. 199 3. Spoofed-based Attack Vectors 201 Spoofing is employed on the Internet for a number of reasons, most of 202 which are in some manner associated with malicious or otherwise 203 nefarious activities. In general, two classes of spoofed-based 204 attack vectors exist: blind attacks and non-blind attacks. The 205 following sections provide some information of blind and non-blind 206 attacks. 208 3.1. Blind Attacks 210 Blind attacks typically occur when an attacker isn't on the same 211 local area network as a source or target, or when an attacker has no 212 access to the datapath between the attack source(s) and the target 213 systems. The result is that they have no access to legitimate source 214 and target systems. 216 3.1.1. Single Packet Attacks 218 One type of blind attacks, which we'll refer to here as "single 219 packet DoS attacks", involves an attacking system injecting spoofed 220 information into the network which results in either a complete crash 221 of the target system, or in some manner poisons some network 222 configuration or other information on a target system so as to impact 223 network or other services. 225 An example of an attack that can cause a receiving system to crash is 226 a LAND attack. A LAND attack packet would consist of an attacking 227 system forwarding a packet (e.g., TCP SYN) to a target system that 228 contains both a source and destination address of that target system. 229 The target system would "lock up" when creating connection state 230 associated with the packet, or would get stuck in a state where it 231 continuously replies to itself. 233 Another class of a single packet attacks involves an attacker 234 poisoning network or DNS cache information, perhaps to simply break a 235 given host's connection, enable MITM or other attacks. Network level 236 attacks that could involve single packet DoS include ARP cache 237 poisoning and ICMP redirects. The most obvious example which depends 238 upon falsifying an IP source address is an on-link attacker poisoning 239 a router's ARP or ND cache. The ability to forge a source address 240 can also be helpful in causing a DNS cache to accept and use 241 incorrect information. 243 3.1.2. Flood-Based DoS 245 Flooding-based DoS attack vectors are particularly effective attacks 246 on the Internet today. They usually entail flooding a large number 247 of packets towards a target system, with the hopes of either 248 exhausting connection state on the target system, consuming all 249 packet processing capabilities of the target or intermediate systems, 250 or consuming a great deal of bandwidth available to the target system 251 such that they are essentially inaccessible. 253 Because these attacks require no reply from the target system and 254 require no legitimate transaction state, attackers often attempt to 255 obfuscate the identity of the systems that are generating the attack 256 traffic by spoofing the source IP address of the attacking traffic 257 flows. Because ingress filtering isn't applied ubiquitously on the 258 Internet today, spoof-based flooding attack vectors are typically 259 very difficult to traceback. In particular, there may be one or more 260 attacking sources beyond your network border, and the attacking 261 sources may or may not be legitimate sources, it's difficult to 262 discriminate if the sources are not directly connected to the local 263 routing system. 265 Common flood-based DoS attack vectors today include SYN floods, ICMP 266 floods, and IP fragmentation attacks. Attackers may use a single 267 legitimate or spoofed fixed attacking source address, although 268 frequently they cycle through large swaths of address space. As a 269 result, mitigating these attacks on the receiving end with source- 270 based policies is extremely difficult. 272 Furthermore, the motivator for spoof-based DoS attacks may actually 273 be to encourage the target to filter explicitly on a given set of 274 source addresses, or order to disrupt the legitimate owner(s) access 275 to the target system. 277 3.1.3. Poisoning Attacks 279 While poison attacks can often be done with single packets, it is 280 also true that a stream of packets can be used to find a window where 281 the target will accept the incorrect information. In general, this 282 can be used to perform broadly the same kinds of poinsonings as 283 above, with more versatility. 285 3.1.4. Spoof-based Worm/Malware Propagation 287 Self-propagating malware has been observed that spoofs its source 288 address when attempting to propagate to other systems. Presumably, 289 this was done to obfuscate the actual source address of the infected 290 system. 292 3.1.5. Reflective Attacks 294 DNS reflective amplification attacks are a particularly potent DoS 295 attack vector on the Internet today. Like other amplification 296 attacks, an attack source generates a packet with a source-spoofed 297 address mapping to that of the target system. The packet, upon 298 receipt by the victim or some intermediate node, typically elicits a 299 large reply message, which is directed to the target of the attack. 300 The amplification factor observed for attacks targeting DNS root and 301 other top level domain name infrastructure in early 2006 was on the 302 order of 76:1. The result is that just 15 attacking sources with 303 512Kbps of upstream attack bandwidth could generate one Gbps of 304 response attack traffic towards a target system. 306 Smurf attacks employ a similar reflective amplification attack 307 vector, exploiting traditional default IP subnet directed broadcast 308 address behaviors that would result in all the active hosts on a 309 given subnet responding to (spoofed) ICMP echo request from an 310 attacker, and generating a large amount of ICMP echo response traffic 311 directed towards a target system. They were particularly effective 312 in large campus LAN environments where 50k or more hosts might reside 313 on a single subnet. 315 3.1.6. Accounting Subversion 317 If an attacker wishes to distribute content or other material in a 318 manner that employs protocols that require only uni-directional 319 flooding and generate no end-end transactional state, they may desire 320 to spoof the source IP address of that content in order to avoid 321 detection or accounting functions enabled at the IP layer. While 322 this particular attack has not been observed, it is included here to 323 reflect the range of power that spoofed addresses may have even 324 without the ability to receive responses. 326 3.1.7. Other Blind Spoofing Attacks 328 Other Blind spoofing attacks might include spoofing in order to 329 exploit source routing or other policy based routing implemented in a 330 network. It may also be possible in some environments to use 331 spoofing techniques to perform blind or non-blind attacks on the 332 routers in a site or in the Internet. There are many techniques to 333 mitigate these attacks, but it is well known that there are 334 vulnerabilities in this area. Among other attacks, if there are 335 multiple routers on-link with hosts, a host may be able to cause 336 problems for the routing system by replaying modified or unmodified 337 routing packets as if they came from another router. 339 3.2. Non-Blind Attacks 341 Non-blind attacks often involve mechanisms such as eavesdropping on 342 connection, resetting state so that new connections may be hijacked, 343 and an array of other attack vectors. Perhaps the most common of 344 these attack vectors is known as man in the middle attacks. 346 3.2.1. Man in the Middle (MITM) 348 Connection Hijacking is one of the more common man in the middle 349 attack vectors. In order to hijack a connection an attacker usually 350 needs to be in the forwarding path and often times employs TCP RST or 351 other attacks in order to reset a transaction. The attacker may have 352 already compromised a system that's in the forwarding path, or they 353 may wish to insert themselves in the forwarding path. 355 For example, an attacker with access to a host on LAN segment may 356 wish to redirect all the traffic on the local segment destined for a 357 default gateway address (or all addresses) to itself in order to 358 perform man-in-the-middle attacks. In order to accomplish this the 359 attacker might transmit gratuitous ARP [RFC0826] messages or ARP 360 replies to the Ethernet broadcast address ff:ff:ff:ff:ff:ff, 361 notifying all the hosts on the segment that the IP address(es) of the 362 target(s) now map to it's own MAC address. If the port to which the 363 attacker is connected were to implement policy that binds a single 364 Link Layer and IP address tuple to that port upon initial 365 provisioning, spoofed packets, at the Link Layer and/or Network 366 Layer, would be discarded on ingress. 368 3.2.2. Third Party Recon 370 Another example of sighted attack is third party reconnaissance. The 371 use of spoofed addresses, while not necessary for this, can often 372 provide additional information, and helps mask the traceability of 373 the activity. The attack involves sending packets towards a given 374 target system and observing either target or intermediate system 375 responses. For example, if an attacker were to source spoof TCP SYN 376 packets towards a target system from a large set of source addresses, 377 and observe responses from that target system or some intermediate 378 firewall or other middle box, they would be able to identify what IP 379 layer filtering policies may be in place to protect that system. 381 4. Current Anti-Spoofing Solutions 383 The first requirement is to eliminate datagrams with spoofed 384 addresses from the Internet. Identifying and dropping datagrams 385 whose source address is incompatible with the Internet topology at 386 sites where the relationship between the source address and topology 387 can be checked can eliminate such datagrams. For example, Internet 388 devices can confirm that: 390 o The IP source address is appropriate for the lower layer address 391 (they both identify the same system) 393 o The IP source address is appropriate for the device at the layer 2 394 switch port (the address was assigned to a, and perhaps the, 395 system that uses that port) 397 o The prefix to which the IP source address belongs is appropriate 398 for the part of the network topology from which the IP datagram 399 was received (while the individual system may be unknown, it is 400 reasonable to believe that the system is located in that part of 401 the network). 403 Filtering points farther away from the source of the datagram can 404 make decreasingly authoritative assertions about the validity of the 405 source address in the datagram. Nonetheless, there is value in 406 dropping traffic that is clearly inappropriate, and in maintaining 407 knowledge of the level of trust one can place in an address. 409 Edge Network 1 CPE-ISP _.------------. 410 _.----------------. Ingress/ ISP A `--. 411 ,--'' `---. ,' `. 412 ,' +----+ +------+ +------+ `. / +------+ +------+ \\ 413 ( |Host+--+Switch+--+ CPE +---)-(---+ PE +- - - -+ NNI | ) 414 `. +----+ +------+ |Router| ,' \\ |Router| |Router| / 415 `---. Host-neighbor +------+' `.+------+ +--+---+,' 416 `----------------'' '--. |_.-' 417 `------------'| 418 | 419 Edge Network 2 ISP-ISP Ingress | 420 _.----------------. _.----------.| 421 ,--'' `---. ,-'' |--. 422 ,' +----+ +------+ +------+ `. ,+------+ +--+---+. 423 ( |Host+--+Switch+--+ CPE +---)---+-+ PE +- - - -+ NNI | \\ 424 `. +----+ +------+ |Router| ,' ( |Router| |Router| ) 425 `---. +------+' \\ +------+ +------+ / 426 `----------------'' `. ,' 427 '--. ISP B _.-' 428 `----------'' 430 Figure 1: Points where an address can be validated 432 Figure 1 illustrates five related paths where a source address can be 433 validated: 435 o host to switch, including host to host via the switch 437 o Host to enterprise CPE Router 439 o Enterprise CPE Router to ISP edge PE Router, and the reverse 441 o ISP NNI Router to ISP NNI Router 443 In general, datagrams with spoofed addresses can be detected and 444 discarded by devices that have an authoritative mapping between IP 445 addresses and the network topology. For example, a device that has 446 an authoritative table between Link Layer and IP addresses on a link 447 can discard any datagrams in which the IP address is not associated 448 with the Link Layer address in the datagram. The degree of 449 confidence in the source address depends on where the spoofing 450 detection is performed and the prefix aggregation in place between 451 the spoofing detection and the source of the datagram. 453 4.1. Host to link layer neighbor via switch 455 The first point at which a datagram with a spoofed address can be 456 detected is on the link to which the source of the datagram is 457 connected. At this point in the network, the source Link Layer and 458 IP addresses are both available, and can be verified against each 459 other. A datagram in which the IP source address does not match the 460 corresponding Link Layer address can be discarded. Of course, the 461 trust in the filtering depends on the trust in the method through 462 which the mappings are developed. This mechanism can be applied by a 463 first hop router, or switch on the link. The first hop switch has 464 the most precise information for this. 466 On a truly shared medium link, such as classic Ethernet, the best 467 that can be done is to verify the Link Layer and IP addresses against 468 the mappings. When the link is not shared, such as when the hosts 469 are connected through a switch, the source host can be identified 470 precisely based on the port through which the datagram is received or 471 the MAC address if it is known to the switch. Port identification 472 prevents transmission of malicious datagrams whose Link Layer and IP 473 addresses are both spoofed to mimic another host. 475 4.2. Upstream routers 477 Beyond the first hop router, subsequent routers may additionally 478 filter traffic from downstream networks. Because these routers do 479 not have access to the Link Layer address of the device from which 480 the datagram was sent, they are limited to confirming that the source 481 IP address is within a prefix that is appropriate for downstream 482 router from which the datagram was received. 484 Options include the use of simple access lists or the use of unicast 485 reverse path filtering (uRPF). Access lists are generally 486 appropriate only for the simplest cases, as management can be 487 difficult. Strict Unicast RPF accepts the source address on a 488 datagram if and only if it comes from a direction that would be 489 rational to send a datagram directed to the address, which means that 490 the filter is derived from routing information. These filtering 491 procedures are discussed in more detail in [RFC3704]. 493 4.3. ISP Edge PE Router 495 An obvious special case of the discussion is with an ISP PE router, 496 where it provides its customer with access. BCP 38 specifically 497 encourages ISPs to use ingress filtering to limit the incidence of 498 spoofed addresses in the network. 500 The question that the ISP must answer for itself is the degree to 501 which it trusts its downstream network. A contract might be written 502 between an ISP and its customer requiring that the customer apply the 503 procedures of network ingress filtering to the customer's own 504 network, although there's no way upstream networks would be able to 505 verify this. 507 4.4. ISP NNI Router to ISP NNI Router 509 The considerations explicitly related to customer networks can also 510 be applied to neighboring ISPs. An interconnection agreement might 511 be written between two companies requiring network ingress filtering 512 policy be implemented on all customers connections. ISPs might, for 513 example, mark datagrams from neighboring ISPs that do not sign such a 514 contract or demonstrably do not behave in accordance with it as 515 'untrusted'. Alternatively, the ISP might place untrusted prefixes 516 into a separate BGP community and use that to advertise the level of 517 trust to its BGP peers. 519 In this case, uRPF is less effective as a verification tool, due to 520 asymmetric routing. However, when it can be shown that spoofed 521 addresses are present, the procedure can be applied. 523 4.5. Spoofing In Local Area Network Segments 525 On Link Layer segments where multiple hosts reside, or a single MAC 526 address can be associated with a port or interface, if a binding 527 between a hardware address (e.g., MAC address) and corresponding IP 528 address(es) are not provisioned via some means (either manual or 529 dynamic mechanisms), then an attacker may exploit attack vectors that 530 enable MITM or other spoof-based attacks. 532 4.6. Cable Modem Subscriber Access 534 Cable Modem Termination Systems (CMTS) employ DOCSIS Media Access 535 Control (MAC) domains, which are similar to Ethernet LAN 536 environments. 538 4.7. DSL Subscriber Access 540 While DSL subscriber access can be bridged or routed, as seen by the 541 service provider's device, it is generally the case that the 542 protocols carry enough information to verify which subscriber is 543 sending packets. Thus, for ensuring that one DSL subscriber does not 544 spoof another, enforcement can generally be done at the aggregation 545 router. This is true even when there is a bridged infrastructure 546 among the subscribers, as DSL access generally requires all 547 subscriber traffic to go through the access aggregation router. 549 If it is desirable to provide spoofing protection among the devices 550 within a residence, that would need to be provided by the CPE device, 551 as the ISPs router does not have enough visibility to do that. It is 552 not clear at this time that this problem is seen as a relevant 553 threat. 555 4.8. BCP 38 557 If BCP 38 [RFC2827] is implemented in LAN segments, it is typically 558 done so on subnetwork boundaries and traditionally relates only to 559 Network Layer ingress filtering policies. The result is that hosts 560 within the segment cannot spoof packets from address space outside of 561 the local segment itself, however, they may still spoof packets using 562 sources addresses that exist within the local network segment. 564 4.9. Unicast RPF 566 Unicast RPF is a crude mechanism to automate definition of BCP 38 567 style filters based on routing table information. Its applicability 568 parallels that of BCP 38, although deployment caveats exist, as 569 outlined in [RFC3704]. 571 4.10. Port-based Address Binding 573 Much of the work SAVI appears to be initially targeting is aimed at 574 minimizing source address spoofing in the LAN. In particular, if 575 mechanisms can be defined to accommodate configuration of port 576 binding information for IP and MAC layer addresses in LAN 577 environments, a large portion of the spoofing threat space in the LAN 578 can be marginalized. 580 However, establishing this binding is not trivial, and varying across 581 both topologies type and address allocation mechanisms. 583 4.10.1. Manual Binding 585 Binding of a single Link Layer and Network Layer address to a port 586 may initially seem trivial. However, two primary areas exist that 587 can complicate such techniques. In particular, these areas involve 588 topologies where more than a single IP layer address may be 589 associated with a MAC address on a given port, or where multiple 590 hosts are connected to a single IP port. Furthermore, if one or more 591 dynamic address allocation mechanisms such as DHCP are employed, then 592 some mechanism must exist to associate those IP layer addresses with 593 the appropriate Link layer ports, as addresses are allocated or 594 reclaimed. 596 4.10.2. Automated Binding 598 For IPv4 the primary and very widely used automated binding technique 599 is DHCP based address assignment. Controlling where authoritative 600 information can be sourced, coupled with sniffing and enforcing the 601 assignments is an effective technique. 603 For IPv6, there are two common automated address binding techniques. 604 While there are many variations and details, for purposes of 605 understanding the threats and basic responses, these are Stateless 606 Address AutoConfiguration (SLAAC) and DHCPv6 based address 607 assignment. In both cases, binding establishment needs to be tied to 608 the state machines for these protocols, and appropriate message 609 sniffing and enforcement. For DHCPv6 based techniques, it is also 610 necessary to use classification techniques to ensure that responses 611 come from authoritative sources. 613 4.10.3. IEEE 802.1X 615 IEEE 802.1x is an authentication protocol that permits a network to 616 determine the identity of a system seeking to join it and apply 617 authorization rules to permit or deny the action. 619 4.11. Cryptographic Techniques 621 Needless to say, MITM and replay attacks can typically be mitigated 622 with cryptographic techniques. However, many of the applications 623 today either don't or can't employ cryptographic authentication and 624 protection mechanisms. ARP for IPv4 does not use such protection. 625 While SEND provides such protection for IPv6 ND, SEND is not widely 626 used to date. While DNSsec will significantly help protect DNS from 627 spoof based poisoning attacks, it will probably be sufficiently long 628 for truly widespread use that other protections can be usefully 629 deployed as well. 631 4.12. Residual Attacks 633 It should be understood that not all combinations of network, service 634 and enforcement choices will result in a protectable network. For 635 example, if one uses conventional SLAAC, in a switched network, but 636 tries to only provide address enforcement on the routers on the 637 network, then the ability to provide protection is severely limited. 639 5. Topological Considerations 641 As noted previously, topological components and address allocation 642 mechanisms have significant implications on what is feasible with 643 regard to Link layer address and IP address port bindings. The 644 following sections discuss some of the various topologies and address 645 allocation mechanisms that proposed SAVI solutions should attempt to 646 address. 648 5.1. Address Provisioning Mechanisms 650 In a strictly static environment, configuration management for access 651 filters that map Link Layer and Network Layer addresses on a specific 652 switch port might be a viable option. However, most networks, 653 certainly those that accommodate actual human users, are much more 654 dynamic in nature. As such, mechanisms that provide port-MAC-IP 655 bindings need to accommodate dynamic address allocation schemes 656 enabled by protocols such as DHCP, DHCPv6 for address allocation, and 657 IPv6 Stateless Address Autoconfiguration. 659 5.2. LAN devices with Multiple Addresses 661 From a topology considerations perspective, when attempting 662 port-MAC-IP bindings, host connected to switch ports that may have 663 one or more IP addresses, or certainly, devices that forward packets 664 from other network segments, are problematic. 666 5.2.1. Routers 668 The most obvious example of devices that are problematic when 669 attempting to implement port-MAC-IP bindings is that of routers. 670 Routers not only originate packets themselves and often have multiple 671 interfaces, but also forward packets from other network segments. As 672 a result, it's difficult for port-MAC-IP binding rules to be 673 established a priori, because it's likely that many addresses and IP 674 subnets should be associated with the port-MAC in question. 676 5.2.2. NATs 678 Validating traffic from Prefix-based and multi-address NATs also 679 becomes problematic, for the same reasons as routers. Because they 680 may forward traffic from an array of address, a priori knowledge must 681 exist providing what IPs should be associated with a given port-MAC 682 pair. 684 5.2.3. Multi-Instance Hosts 686 Another example that introduces complexities is that of multi- 687 instance hosts attached to a switch port. These are single physical 688 devices, which internally run multiple physical or logical hosts. 689 When the device is a blade server, with internal blades each hosting 690 a machine, there is essentially a physical switch inside the blade 691 server. While tractable, this creates some complexity for 692 determining where enforcement logic can or should live. 694 Logically distinct hosts such as are provided by many varieties of 695 virtualization logic result in a single physical host, connect to a 696 single port on the Ethernet switch in the topology, actually having 697 multiple internal IP and MAC addresses, and essentially an internal 698 switch. While it may be possible for this internal switch to help 699 control threats among the virtual hosts, or between virtual hosts and 700 other parts of the network, such enforcement cannot be counted on at 701 this time. 703 5.2.4. Multi-LAN Hosts 705 Multi-interface hosts, in particular those that are multi-homed and 706 may forward packets from any of a number of source addresses, can be 707 problematic as well. In particular, if a port-MAC-IP binding is made 708 on each of the interfaces, and then either a loopback IP or the 709 address of third interface is used as the source address of a packet 710 forwarded through an interface for which the port-MAC-IP binding 711 doesn't map, the traffic may be discarded. Static configuration of 712 port-MAC-IP bindings may accommodate this scenario, although some a 713 priori knowledge on address assignment and topology is required. 715 While the use of loopback addressing or sending packets out one 716 interface with the source address from another are rare, they do 717 legitimately occur. Some servers, particularly ones that have 718 underlying virtualization, use loopback techniques for management. 720 5.2.5. Firewalls 722 Firewalls that forward packets from other network segments, or serve 723 as a source for locally originated packets, suffer from the same 724 issues as routers. 726 5.2.6. Mobile IP 728 Mobile IP hosts in both IPv4 and IPv6 are proper members of the site 729 where they are currently located. Their care-of-address is a 730 properly assigned address that is on the link they are using. And 731 their packets are sent and received using that address. Thus, they 732 do not introduce any additional complications. (There was at one 733 time consideration of allowing mobile hosts to use their home address 734 when away from home. This was not done, precisely to ensure that 735 mobile hosts comply with source address validity requirements.) 736 Mobile Hosts with multiple physical interfaces fall into the cases 737 above. 739 Mobile IP home agents are somewhat more interesting. Although they 740 are (typically) fixed devices, they are required to send and receive 741 packets addressed from or to any currently properly registered mobile 742 node. From an analysis point of view, even though the packets that a 743 Home Agent handles are actually addressed to or from the link the HA 744 is on, it is probably best to think of them as routers, with a 745 virtual interface to the actual hosts they are serving. 747 5.2.7. Other Topologies 749 Any topology that results in the possibility that a device connected 750 to a switch port may forward packets with more than a single source 751 address for packet which it originated may be problematic. 752 Additionally, address allocation schemas introduce additional 753 considerations when examining a given SAVI solutions space. 755 5.3. IPv6 Considerations 757 IPv6 introduces additional capabilities which indirectly complicate 758 the spoofing analysis. IPv6 introduces and recommends the use of 759 stateless address autoconfiguration (often referred to as SLAAC). 760 This allows hosts to determine their IP prefix, select an ID, and 761 then start communicating. While there are many advantages to this, 762 the absence of control interactions complicates the process of 763 behavioral enforcement. 765 An additional complication is the very large ID space. Again, this 766 64 bit ID space provided by IPv6 has many advantages. It provides 767 the opportunity for many useful behaviors. However, it also means 768 that in the absence of controls, hosts can mint anonymous addresses 769 as often as they like, modulo the idiosyncrasies of the duplicate 770 address procedure. Like many behaviors, this is a feature for some 771 purposes, and a problem for others. But it does have implications 772 for switch cost; the switch needs to store more addresses and so 773 needs more memory. 775 6. Applicability of Anti-Spoofing Solutions 777 The above sections covered a number of security threats. Not all 778 these threats can be prevented by anti-spoofing techniques. However, 779 all of these threats can be ameliorated to some degree. We can look 780 at three categories of effect we can achieve: 782 Prevention: Some of the threats described above explicitly require 783 that a host send packets using some other active hosts IP address 784 as a source. Anti-Spoofing measures can prevent these attacks. 786 Impediment: Many of the attacks above, such as some kinds of DoS 787 attacks, can be conducted more easily if the attacking host can 788 use multiple different IP addresses. Depending upon the kind of 789 anti-spoofing available, the scope of such false addresses, or 790 even their use, may be prevented, hindering the attacker even if 791 the attack is not completely prevented. 793 Traceability: Even when attacks cannot be prevented, the ability to 794 reliably trace an attack allows appropriate responses, and thereby 795 also creates an environment which discourages attacks instead of 796 encouraging them. Thus, ensuring that even attacks which are not 797 dependent upon spoofing cannot use source address spoofing to hide 798 their origin is extremely important. 800 For example, sites which deploy BCP 38 cannot be the source of 801 attacks which rely on spoofing the source site from which an attack 802 was launched. Wide deployment of BCP 38 would also simplify the task 803 of tracking attacks back to their actual origin. 805 6.1. Analysis of Host Granularity Anti-Spoofing 807 Applying anti-spoofing techniques at the host level enables a site to 808 achieve several valuable objectives. While it is likely the case 809 that for many site topologies and policies, full source spoofing 810 protection is not possible, it is also true that for many sites there 811 are steps that can be taken that provide benefit. 813 One important class of benefit is masquerade prevention. Security 814 threats involving one machine masquerading as another, for example in 815 order to hijack an apparently secure session, can occur within a site 816 with significant impact. Having mechanisms such that host facing 817 devices prevent this is a significant intra-site security 818 improvement. Given that security experts report that most security 819 breaches are internal, this can be valuable. One example of this is 820 that such techniques should mitigate internal attacks on the site 821 routing system. 823 A second class of benefit is related to the traceability described 824 above. When a security incident is detected, either within a site, 825 or externally (and traced to the site( it can be critical to 826 determine what the actual source of the incident was. If address 827 usage can be tied to the kinds of anchors described earlier, then it 828 is possible to respond to security incidents. 830 In addition to these local observable benefits, there can be more 831 global benefits. For example, if address usage is tied to anchors, 832 it may be possible to prevent or control the use of large numbers of 833 anonymous IPv6 addresses for attacks, or at least to track even those 834 attacks back to their source. 836 7. Existing Techniques for IP Source Address Validation 838 Existing techniques for IP source address validation are 839 insufficient. While each technique has its own shortcomings, the 840 following list of general categories of reasons include some of the 841 deficiencies of all existing technique: 843 False negatives: Techniques may yield false negatives, thus enabling 844 an attacker to select an IP source address that is spoofed, but 845 still passes IP source address validation. 847 False positives: Techniques may yield false positives, thereby 848 causing interruption or denial of service to hosts that use 849 legitimate IP source addresses. 851 Non-trivial configuration: Requirements for non-trivial 852 configuration imply expenditures and pose a risk for 853 misconfiguration, which may again lead to false positives or false 854 negatives. Both may discourage operators from employing a given 855 technique. 857 Proprietary: Procurement policies of organizations oftentimes 858 require that devices purchased use techniques that are 859 standardized rather than proprietary. Such policies, for good or 860 ill, hinder or prevent the deployment of proprietary techniques. 862 The only standardized technique for IP source address validation is 863 ingress filtering [RFC2827]. This calls for routers to check whether 864 the prefix of a to-be-forwarded packet's IP source address is amongst 865 a list of prefixes considered legitimate for the interface through 866 which the packet arrives. Packets that fail this check are 867 discarded. 869 Ingress filtering may yield false negatives in a deterministic 870 manner. Packets with a legitimate IP source address prefix, but a 871 spoofed interface identifier, pass ingress filtering checks. Also, 872 packets with an illegitimate IP source address prefix pass the checks 873 as long as the prefix is from the list of prefixes considered 874 legitimate, if more than one prefix is considered as legitimate on 875 the ingress interface.. 877 Ingress filtering implementations that require manual establishment 878 of the list of legitimate prefixes cause considerable configuration 879 overhead. Unicast Reverse Path Forwarding (uRPF) mitigates this 880 issue by automatically deriving the list of legitimate prefixes from 881 a router's forwarding table: A to-be-forwarded packet's IP source 882 address prefix is considered legitimate if the packet is coming 883 through an interface via which return traffic would be routed. On 884 the other hand, Unicast Reverse Path Forwarding may yield false 885 positives, in particular for hosts and networks with multiple, 886 topologically separate Internet attachments [RFC3704]. 888 Consequently, there is a need for an IP source address validation 889 technique that avoids false negatives and false positives, that can 890 be set up with no or only trivial configuration, and that has been 891 standardized. The development of such a technique is the goal of the 892 proposed Source Address Validation Improvements (SAVI) working group 893 in the Internet Engineering Task Force. 895 8. Deployment Considerations 897 From a global Internet perspective, deployment of anti- spoofing 898 techniques tends to suffer from a "tragedy of the commons" situation. 899 That is, there is a general consensus that everyone should implement 900 anti-spoofing measures, yet individual organizations don't want to 901 bear the cost of deployment themselves, often because demonstrating 902 direct tangible return on investment is not possible. Upon analysis, 903 it often seems apparent that local implementation of anti-spoofing 904 measures is of more benefit to the "greater Internet" than the local 905 network domain itself. A similar situation occurs with de- 906 aggregation of Internet routing information for multi-homing and 907 traffic engineering purposes, as well as the lack of explicit inter- 908 domain routing prefix filters on the Internet. 910 Until network operators begin to accept that their local design 911 choices have global implications, and act upon this responsibility, 912 the problem is not going to go away. 914 Ideally, with additional work in the areas of SAVI to ease deployment 915 and management burdens, the deployment cost to operators will 916 decrease and more wide-scale deployment will continue. Furthermore, 917 application of SAVI-like techniques provides more obvious benefits to 918 network administrators that are concerned with MITM and similar 919 attacks. 921 As mentioned earlier, there are local security benefits to the 922 deployment of SAVI security mechanisms. This may help motivate the 923 deployment of tools with widespread benefit. 925 9. IANA Considerations 927 This memo asks the IANA for no new parameters. 929 Note to RFC Editor: This section will have served its purpose if it 930 correctly tells IANA that no new assignments or registries are 931 required, or if those assignments or registries are created during 932 the RFC publication process. From the authors' perspective, it may 933 therefore be removed upon publication as an RFC at the RFC Editor's 934 discretion. 936 10. Security Considerations 938 This document provides limited discussion of some security threats 939 source address validation improvements will help to mitigate. It is 940 not meant to be all-inclusive, either from a threat analysis 941 perspective, or from the source address verification application 942 side. 944 It is seductive to think of SAVI solutions as providing the ability 945 to use this technology to trace a datagram to the person, or at least 946 end system, that originated it. For several reasons, the technology 947 can be used to derive circumstantial evidence, but does not actually 948 solve that problem. 950 In the Internet Layer, the source address of a datagram should be the 951 address of the system that originated it and to which any reply is 952 expected to come. But systems fall into several broad categories. 953 Many are single user systems, such as laptops and PDAs. Multi-user 954 systems are commonly used in industry, and a wide variety of 955 middleware systems and application servers have no user at all, but 956 by design relay messages or perform services on behalf of users of 957 other systems (e.g., SMTP and peer-to-peer file sharing). 959 Until every Internet-connected network implements source address 960 validation at the ultimate network ingress, and assurances exist that 961 intermediate devices are to never modify datagram source addresses, 962 source addresses must not be used as an authentication mechanism. 963 The only technique to unquestionably verify source addresses of a 964 received datagram are cryptographic authentication mechanisms such as 965 IPsec. 967 11. Acknowledgements 969 A portion of the primer text in this document came directly from 970 [I-D.baker-sava-operational], authored by Fred Baker and Ralph Droms. 971 Many thanks to Christian Vogt and Suresh Bhogavilli for contributing 972 text and a careful review of this document. 974 12. References 976 12.1. Normative References 978 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 979 September 1981. 981 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 982 (IPv6) Specification", RFC 2460, December 1998. 984 12.2. Informative References 986 [I-D.baker-sava-operational] 987 Baker, F. and R. Droms, "IPv4/IPv6 Source Address 988 Verification", draft-baker-sava-operational-00 (work in 989 progress), June 2007. 991 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 992 converting network protocol addresses to 48.bit Ethernet 993 address for transmission on Ethernet hardware", STD 37, 994 RFC 826, November 1982. 996 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 997 Defeating Denial of Service Attacks which employ IP Source 998 Address Spoofing", BCP 38, RFC 2827, May 2000. 1000 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1001 Networks", BCP 84, RFC 3704, March 2004. 1003 Authors' Addresses 1005 Danny McPherson 1006 VeriSign, Inc. 1008 Email: dmcpherson@verisign.com 1010 Fred Baker 1011 Cisco Systems 1013 Email: fred@cisco.com 1015 Joel M. Halpern 1016 Ericsson 1018 Email: joel.halpern@ericsson.com