idnits 2.17.1 draft-ietf-savi-threat-scope-05.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 (April 11, 2011) is 4736 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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: October 13, 2011 Cisco Systems 6 J. Halpern 7 Ericsson 8 April 11, 2011 10 SAVI Threat Scope 11 draft-ietf-savi-threat-scope-05 13 Abstract 15 Source Address Validation Improvement (SAVI) effort aims to 16 complement ingress filtering with finer-grained, standardized IP 17 source address validation. This document describes threats enabled 18 by IP source address spoofing both in the global and finer-grained 19 context, describes currently available solutions and challenges, and 20 provides a starting point analysis for finer-grained (host 21 granularity) anti-spoofing work. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on October 13, 2011. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Spoofed-based Attack Vectors . . . . . . . . . . . . . . . . . 6 60 3.1. Blind Attacks . . . . . . . . . . . . . . . . . . . . . . 6 61 3.1.1. Single Packet Attacks . . . . . . . . . . . . . . . . 6 62 3.1.2. Flood-Based DoS . . . . . . . . . . . . . . . . . . . 7 63 3.1.3. Poisoning Attacks . . . . . . . . . . . . . . . . . . 8 64 3.1.4. Spoof-based Worm/Malware Propagation . . . . . . . . . 8 65 3.1.5. Reflective Attacks . . . . . . . . . . . . . . . . . . 8 66 3.1.6. Accounting Subversion . . . . . . . . . . . . . . . . 9 67 3.1.7. Other Blind Spoofing Attacks . . . . . . . . . . . . . 9 68 3.2. Non-Blind Attacks . . . . . . . . . . . . . . . . . . . . 9 69 3.2.1. Man in the Middle (MITM) . . . . . . . . . . . . . . . 10 70 3.2.2. Third Party Recon . . . . . . . . . . . . . . . . . . 10 71 4. Current Anti-Spoofing Solutions . . . . . . . . . . . . . . . 10 72 4.1. Topological Locations for Enforcement . . . . . . . . . . 12 73 4.1.1. Host to link layer neighbor via switch . . . . . . . . 12 74 4.1.2. Upstream routers . . . . . . . . . . . . . . . . . . . 12 75 4.1.3. ISP Edge PE Router . . . . . . . . . . . . . . . . . . 13 76 4.1.4. ISP NNI Router to ISP NNI Router . . . . . . . . . . . 13 77 4.1.5. Cable Modem Subscriber Access . . . . . . . . . . . . 14 78 4.1.6. DSL Subscriber Access . . . . . . . . . . . . . . . . 14 79 4.2. Currently Available Tools . . . . . . . . . . . . . . . . 14 80 4.2.1. BCP 38 . . . . . . . . . . . . . . . . . . . . . . . . 14 81 4.2.2. Unicast RPF . . . . . . . . . . . . . . . . . . . . . 14 82 4.2.3. Port-based Address Binding . . . . . . . . . . . . . . 15 83 4.2.4. Cryptographic Techniques . . . . . . . . . . . . . . . 16 84 4.2.5. Residual Attacks . . . . . . . . . . . . . . . . . . . 16 85 5. Topological Challenges Facing SAVI . . . . . . . . . . . . . . 16 86 5.1. Address Provisioning Mechanisms . . . . . . . . . . . . . 16 87 5.2. LAN devices with Multiple Addresses . . . . . . . . . . . 17 88 5.2.1. Routers . . . . . . . . . . . . . . . . . . . . . . . 17 89 5.2.2. NATs . . . . . . . . . . . . . . . . . . . . . . . . . 17 90 5.2.3. Multi-Instance Hosts . . . . . . . . . . . . . . . . . 17 91 5.2.4. Multi-LAN Hosts . . . . . . . . . . . . . . . . . . . 18 92 5.2.5. Firewalls . . . . . . . . . . . . . . . . . . . . . . 18 93 5.2.6. Mobile IP . . . . . . . . . . . . . . . . . . . . . . 18 94 5.2.7. Other Topologies . . . . . . . . . . . . . . . . . . . 18 95 5.3. IPv6 Considerations . . . . . . . . . . . . . . . . . . . 19 97 6. Analysis of Host Granularity Anti-Spoofing . . . . . . . . . . 19 98 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 99 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 100 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 101 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 102 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 103 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 106 1. Overview 108 The Internet Protocol, specifically IPv4 [RFC0791] and IPv6 109 [RFC2460], employ a connectionless hop-by-hop packet forwarding 110 paradigm. A host connected to an IP network that wishes to 111 communicate with another host on the network generates an IP packet 112 with source and destination IP addressing information, among other 113 options. 115 At the IP Network Layer, or Internet Layer, there is typically no 116 required transactional state when communicating with other hosts on 117 the network. Hosts generating packets for transmission have the 118 opportunity to spoof (forge) the source address of packets which they 119 transmit. 121 Source address verification is necessary in order to detect and 122 reject spoofed packets and contribute to the overall security of IP 123 networks. In particular, source address verification techniques 124 enable detection and rejection of spoofed packets, and also 125 implicitly provide some assurances that the source address in an IP 126 packet is legitimately assigned to the system that generated the 127 packet. 129 Solutions such as BCP 38 [RFC2827] provide guidelines for one such 130 technique for network ingress filtering. However, if these 131 techniques are not implemented at the ingress point of the IP 132 network, then the validity of the source address cannot be positively 133 ascertained. Furthermore, BCP 38 only implies source address 134 verification at the Internet Layer, and is most often implemented on 135 IP subnetwork address boundaries. One of the difficulties in 136 encouraging the deployment of BCP 38 is that there is relatively 137 little benefit until it is very widely deployed, which is not yet the 138 case. 140 Hence, in order to try to get better behavior, it is helpful to look 141 for an application like BCP 38, but one which can be applied locally, 142 and give locally beneficial results. The local benefit would provide 143 a reason for the site to deploy, while moving the Internet as a whole 144 towards an environment where BCP 38 is widely effected. SAVI is 145 aimed at providing locally more specific protection, with the benefit 146 of better local behavior and local traceability, while also providing 147 better compliance with the cases dealt with by BCP 38. 149 It should be noted that while BCP 38 directs providers to provide 150 protection from spoofed prefixes, it is clearly desirable for 151 enterprise operators to provide that protection more locally, and 152 with better traceability. This allows the enterprise to be a better 153 Internet participant, and to quickly detect and remedy problems when 154 they occur. For example, when an enterprise receives a report of an 155 attack originating within that enterprise, the operational staff 156 needs to be able to track from the IP address sourcing the attack to 157 the particular machine within the enterprise that is the source. 158 This both that the information be useable (logging), and that the 159 information be accurate, i.e. that no other machine could have been 160 using that address. 162 Also, there is a possibility that in a LAN environment where multiple 163 hosts share a single LAN or IP port on a switch or router, one of 164 those hosts may spoof the source addresses of other hosts within the 165 local subnet. Understanding these threats and the relevant 166 topologies in which they're introduced is critical when assessing the 167 threats that exist with source address spoofing. 169 The aim of this document is to provide some additional details 170 regarding spoofed-based threat vectors, and discuss implications of 171 various network topologies. 173 2. Glossary of Terms 175 The following acronyms and terms are used throughout this memo. 177 BGP: The Border Gateway Protocol, used to manage routing policy 178 between large networks. 180 CPE Router: Customer Premises Equipment Router. The router on the 181 customer premises, whether owned by the customer or the provider. 182 Also called the Customer Edge, or CE, Router. 184 IP Address: An Internet Protocol Address, whether IPv4 or IPv6. 186 ISP: Internet Service Provider. Any person or company that delivers 187 Internet service to another. 189 MAC Address: An Ethernet Address or comparable IEEE 802 series 190 address. 192 NNI Router: Network to Network Interface Router. This router 193 interface faces a similar system operated by another ISP or other 194 large network. 196 PE Router: Provider Edge Router. This router faces a customer of an 197 ISP. 199 Spoofing: The act of forging datagram header contents at the Link or 200 Network Layer 202 TCP: The Transmission Control Protocol, used on end systems to 203 manage data exchange. 205 uRPF: Unicast Reverse Path Forwarding. A procedure in which the 206 route table, which is usually used to look up destination 207 addresses and route towards them, is used to look up the source 208 address and ensure that one is routing away from it. When this 209 test fails, the event may be logged, and the traffic is commonly 210 dropped. 212 3. Spoofed-based Attack Vectors 214 Spoofing is employed on the Internet for a number of reasons, most of 215 which are in some manner associated with malicious or otherwise 216 nefarious activities. In general, two classes of spoofed-based 217 attack vectors exist: blind attacks and non-blind attacks. The 218 following sections provide some information of blind and non-blind 219 attacks. 221 3.1. Blind Attacks 223 Blind attacks typically occur when an attacker isn't on the same 224 local area network as a source or target, or when an attacker has no 225 access to the datapath between the attack source(s) and the target 226 systems. The result is that they have no access to legitimate source 227 and target systems. 229 3.1.1. Single Packet Attacks 231 One type of blind attacks, which we'll refer to here as "single 232 packet DoS attacks", involves an attacking system injecting spoofed 233 information into the network which results in either a complete crash 234 of the target system, or in some manner poisons some network 235 configuration or other information on a target system so as to impact 236 network or other services. 238 An example of an attack that can cause a receiving system to crash is 239 a LAND attack. A LAND attack packet would consist of an attacking 240 system sending a packet (e.g., TCP SYN) to a target system that 241 contains both a source and destination address of that target system. 242 It would also contain a single value for port number, used as both 243 the source and destination port number. Certain target systems will 244 then "lock up" when creating connection state associated with the 245 packet, or would get stuck in a state where it continuously replies 246 to itself. As this is an attack that relies on bugs in the target, 247 it is possible, but by no means certain, that this threat is no 248 longer viable. 250 Another form of blind attack is a RST probe [RFC0793]. The attacker 251 sends a series of packets to a destination which is engaged in a 252 long-lived TCP session. The packets are RST packets, and the 253 attacker uses the known source and destination addresses and port 254 numbers, along with guesses at the sequence number. If he can send a 255 packet close enough to the right value, in theory he can terminate 256 the TCP connection. While there are various steps that have been 257 developed to ameliorate this attack, preventing the spoofing of 258 source addresses completely prevents the attack from occuring. 260 3.1.2. Flood-Based DoS 262 Flooding-based DoS attack vectors are particularly effective attacks 263 on the Internet today. They usually entail flooding a large number 264 of packets towards a target system, with the hopes of either 265 exhausting connection state on the target system, consuming all 266 packet processing capabilities of the target or intermediate systems, 267 or consuming a great deal of bandwidth available to the target system 268 such that they are essentially inaccessible. 270 Because these attacks require no reply from the target system and 271 require no legitimate transaction state, attackers often attempt to 272 obfuscate the identity of the systems that are generating the attack 273 traffic by spoofing the source IP address of the attacking traffic 274 flows. Because ingress filtering isn't applied ubiquitously on the 275 Internet today, spoof-based flooding attack vectors are typically 276 very difficult to traceback. In particular, there may be one or more 277 attacking sources beyond your network border, and the attacking 278 sources may or may not be legitimate sources, it's difficult to 279 determine if the sources are not directly connected to the local 280 routing system. These attacks might be seen as primarily to be 281 addressed by BCP 38 deployment, which would not be in scope for this 282 document. However, as noted earlier, deployment of SAVI can help 283 remediate lack of BCP 38, and even when BCP 38 is deployed can help 284 provide useful information for responding to such attacks. 286 Common flood-based DoS attack vectors today include SYN floods, ICMP 287 floods, and IP fragmentation attacks. Attackers may use a single 288 legitimate or spoofed fixed attacking source address, although 289 frequently they cycle through large swaths of address space. As a 290 result, mitigating these attacks on the receiving end with source- 291 based policies is extremely difficult. 293 If an attacker can inject messages for a protocol which requires 294 control plane activity, it may be possible to deny network control 295 services at a much lower attack level. While there are various forms 296 of protection deployed against this, they are by no means complete. 297 Attacks which are harder to trace (such as with spoofed addresses) 298 are of course of more concern. 300 Furthermore, the motivator for spoof-based DoS attacks may actually 301 be to encourage the target to filter explicitly on a given set of 302 source addresses, or order to disrupt the legitimate owner(s) access 303 to the target system. 305 3.1.3. Poisoning Attacks 307 While poison attacks can often be done with single packets, it is 308 also true that a stream of packets can be used to find a window where 309 the target will accept the incorrect information. In general, this 310 can be used to perform broadly the same kinds of poisonings as above, 311 with more versatility. 313 One important class of poisoning attacks are attacks aimed at 314 poisoning network or DNS cache information, perhaps to simply break a 315 given host's connection, enable MITM or other attacks. Network level 316 attacks that could involve single packet DoS include ARP cache 317 poisoning and ICMP redirects. The most obvious example which depends 318 upon falsifying an IP source address is an on-link attacker poisoning 319 a router's ARP or ND cache. The ability to forge a source address 320 can also be helpful in causing a DNS cache to accept and use 321 incorrect information. 323 3.1.4. Spoof-based Worm/Malware Propagation 325 Self-propagating malware has been observed that spoofs its source 326 address when attempting to propagate to other systems. Presumably, 327 this was done to obfuscate the actual source address of the infected 328 system. This attack is important both in terms of an attack vector 329 that SAVI may help prevent, and also as a problem which SAVI can help 330 track back to find infected systems. 332 3.1.5. Reflective Attacks 334 Reflective amplifications attacks, wherein a sender sends a single 335 packet to an intermediary, resulting in the intermediary sending a 336 large number of packets, or much larger packets, to the target, are a 337 particularly potent DoS attack vector on the Internet today. Many of 338 these attacks rely on using a false source address, so that the 339 amplifier attacks the target by responding to the messages. 341 DNS is one of the common targets of such attacks. The amplification 342 factor observed for attacks targeting DNS root and other top level 343 domain name infrastructure in early 2006 was on the order of 76:1. 344 The result is that just 15 attacking sources with 512Kbps of upstream 345 attack bandwidth could generate one Gbps of response attack traffic 346 towards a target system. 348 Smurf attacks employ a similar reflective amplification attack 349 vector, exploiting traditional default IP subnet directed broadcast 350 address behaviors that would result in all the active hosts on a 351 given subnet responding to (spoofed) ICMP echo request from an 352 attacker, and generating a large amount of ICMP echo response traffic 353 directed towards a target system. They were particularly effective 354 in large campus LAN environments where 50k or more hosts might reside 355 on a single subnet. 357 3.1.6. Accounting Subversion 359 If an attacker wishes to distribute content or other material in a 360 manner that employs protocols that require only uni-directional 361 flooding and generate no end-end transactional state, they may desire 362 to spoof the source IP address of that content in order to avoid 363 detection or accounting functions enabled at the IP layer. While 364 this particular attack has not been observed, it is included here to 365 reflect the range of power that spoofed addresses may have even 366 without the ability to receive responses. 368 3.1.7. Other Blind Spoofing Attacks 370 Other Blind spoofing attacks might include spoofing in order to 371 exploit source routing or other policy based routing implemented in a 372 network. It may also be possible in some environments to use 373 spoofing techniques to perform blind or non-blind attacks on the 374 routers in a site or in the Internet. There are many techniques to 375 mitigate these attacks, but it is well known that there are 376 vulnerabilities in this area. Among other attacks, if there are 377 multiple routers on-link with hosts, a host may be able to cause 378 problems for the routing system by replaying modified or unmodified 379 routing packets as if they came from another router. 381 3.2. Non-Blind Attacks 383 Non-blind attacks often involve mechanisms such as eavesdropping on 384 connection, resetting state so that new connections may be hijacked, 385 and an array of other attack vectors. Perhaps the most common of 386 these attack vectors is known as man in the middle attacks. In this 387 case, we are concerned not with an attacker who can modify a stream, 388 but rather one who has access to information from the stream, and 389 uses that to launch his own attacks. 391 3.2.1. Man in the Middle (MITM) 393 Connection Hijacking is one of the more common man in the middle 394 attack vectors. In order to hijack a connection an attacker usually 395 needs to be in the forwarding path and often times employs TCP RST or 396 other attacks in order to reset a transaction. The attacker may have 397 already compromised a system that's in the forwarding path, or they 398 may wish to insert themselves in the forwarding path. 400 For example, an attacker with access to a host on LAN segment may 401 wish to redirect all the traffic on the local segment destined for a 402 default gateway address (or all addresses) to itself in order to 403 perform man-in-the-middle attacks. In order to accomplish this, in 404 IPv4 the attacker might transmit gratuitous ARP [RFC0826] messages or 405 ARP replies to the Ethernet broadcast address ff:ff:ff:ff:ff:ff, 406 notifying all the hosts on the segment that the IP address(es) of the 407 target(s) now map to it's own MAC address. Similar vulnerabilities 408 exist in IPv6 NDP [RFC4861]. 410 3.2.2. Third Party Recon 412 Another example of sighted attack is third party reconnaissance. The 413 use of spoofed addresses, while not necessary for this, can often 414 provide additional information, and helps mask the traceability of 415 the activity. The attack involves sending packets towards a given 416 target system and observing either target or intermediate system 417 responses. For example, if an attacker were to source spoof TCP SYN 418 packets towards a target system from a large set of source addresses, 419 and observe responses from that target system or some intermediate 420 firewall or other middle box, they would be able to identify what IP 421 layer filtering policies may be in place to protect that system. 423 4. Current Anti-Spoofing Solutions 425 The first requirement is to eliminate datagrams with spoofed IP 426 addresses from the Internet. Identifying and dropping datagrams 427 whose source address is incompatible with the Internet topology at 428 sites where the relationship between the source address and topology 429 can be checked can eliminate such datagrams. For example, Internet 430 devices can confirm that: 432 o The IP source address is appropriate for the lower layer address 433 (they both identify the same system) 435 o The IP source address is appropriate for the device at the layer 2 436 switch port (the address was assigned to a, and perhaps the, 437 system that uses that port) 439 o The prefix to which the IP source address belongs is appropriate 440 for the part of the network topology from which the IP datagram 441 was received (while the individual system may be unknown, it is 442 reasonable to believe that the system is located in that part of 443 the network). 445 Filtering points farther away from the source of the datagram can 446 make decreasingly authoritative assertions about the validity of the 447 source address in the datagram. Nonetheless, there is value in 448 dropping traffic that is clearly inappropriate, and in maintaining 449 knowledge of the level of trust one can place in an address. 451 Edge Network 1 CPE-ISP _.------------. 452 _.----------------. Ingress/ ISP A `--. 453 ,--'' `---. ,' `. 454 ,' +----+ +------+ +------+ `. / +------+ +------+ \\ 455 ( |Host+--+Switch+--+ CPE +---)-(---+ PE +- - - -+ NNI | ) 456 `. +----+ +------+ |Router| ,' \\ |Router| |Router| / 457 `---. Host-neighbor +------+' `.+------+ +--+---+,' 458 `----------------'' '--. |_.-' 459 `------------'| 460 | 461 Edge Network 2 ISP-ISP Ingress | 462 _.----------------. _.----------.| 463 ,--'' `---. ,-'' |--. 464 ,' +----+ +------+ +------+ `. ,+------+ +--+---+. 465 ( |Host+--+Switch+--+ CPE +---)---+-+ PE +- - - -+ NNI | \\ 466 `. +----+ +------+ |Router| ,' ( |Router| |Router| ) 467 `---. +------+' \\ +------+ +------+ / 468 `----------------'' `. ,' 469 '--. ISP B _.-' 470 `----------'' 472 Figure 1: Points where an address can be validated 474 Figure 1 illustrates five related paths where a source address can be 475 validated: 477 o host to switch, including host to host via the switch 479 o Host to enterprise CPE Router 481 o Enterprise CPE Router to ISP edge PE Router, and the reverse 483 o ISP NNI Router to ISP NNI Router 485 In general, datagrams with spoofed IP addresses can be detected and 486 discarded by devices that have an authoritative mapping between IP 487 addresses and the network topology. For example, a device that has 488 an authoritative table between Link Layer and IP addresses on a link 489 can discard any datagrams in which the IP address is not associated 490 with the Link Layer address in the datagram. The degree of 491 confidence in the source address depends on where the spoofing 492 detection is performed and the prefix aggregation in place between 493 the spoofing detection and the source of the datagram. 495 4.1. Topological Locations for Enforcement 497 There are a number of kinds of places, which one might call 498 topological locations, where solutions may or should be deployed. 500 4.1.1. Host to link layer neighbor via switch 502 The first point at which a datagram with a spoofed address can be 503 detected is on the link to which the source of the datagram is 504 connected. At this point in the network, the source Link Layer and 505 IP addresses are both available, and can be verified against each 506 other. A datagram in which the IP source address does not match the 507 corresponding Link Layer address can be discarded. Of course, the 508 trust in the filtering depends on the trust in the method through 509 which the mappings are developed. This mechanism can be applied by a 510 first hop router, or switch on the link. The first hop switch has 511 the most precise information for this. 513 On a truly shared medium link, such as classic Ethernet, the best 514 that can be done is to verify the Link Layer and IP addresses against 515 the mappings. When the link is not shared, such as when the hosts 516 are connected through a switch, the source host can be identified 517 precisely based on the port through which the datagram is received or 518 the MAC address if it is known to the switch. Port identification 519 prevents transmission of malicious datagrams whose Link Layer and IP 520 addresses are both spoofed to mimic another host. 522 Other kinds of links may fall at different places in this spectrum, 523 with some wireless links having easier ways of identifying individual 524 devices than others, for example. 526 4.1.2. Upstream routers 528 Beyond the first hop router, subsequent routers may additionally 529 filter traffic from downstream networks. Because these routers do 530 not have access to the Link Layer address of the device from which 531 the datagram was sent, they are limited to confirming that the source 532 IP address is within a prefix that is appropriate for downstream 533 router from which the datagram was received. 535 Options include the use of simple access lists or the use of unicast 536 reverse path filtering (uRPF). Access lists are generally 537 appropriate only for the simplest cases, as management can be 538 difficult. Strict Unicast RPF accepts the source address on a 539 datagram if and only if it comes from a direction that would be 540 rational to send a datagram directed to the address, which means that 541 the filter is derived from routing information. These filtering 542 procedures are discussed in more detail in [RFC3704]. 544 4.1.3. ISP Edge PE Router 546 An obvious special case of the discussion is with an ISP PE router, 547 where it provides its customer with access. BCP 38 specifically 548 encourages ISPs to use ingress filtering to limit the incidence of 549 spoofed addresses in the network. 551 The question that the ISP must answer for itself is the degree to 552 which it trusts its downstream network. A contract might be written 553 between an ISP and its customer requiring that the customer apply the 554 procedures of network ingress filtering to the customer's own 555 network, although there's no way upstream networks would be able to 556 verify this. 558 Conversely, if the provider has assigned a single IP address to the 559 customer (for example, with IPv4 NAT in the CPE) PE enforcement of 560 BCP 38 can be on the full address, simplifying many issues. 562 4.1.4. ISP NNI Router to ISP NNI Router 564 The considerations explicitly related to customer networks can also 565 be applied to neighboring ISPs. An interconnection agreement might 566 be written between two companies requiring network ingress filtering 567 policy be implemented on all customers connections. ISPs might, for 568 example, mark datagrams from neighboring ISPs that do not sign such a 569 contract or demonstrably do not behave in accordance with it as 570 'untrusted'. Alternatively, the ISP might place untrusted prefixes 571 into a separate BGP community [RFC4271] and use that to advertise the 572 level of trust to its BGP peers. 574 In this case, uRPF is less effective as a verification tool, due to 575 asymmetric routing. However, when it can be shown that spoofed 576 addresses are present, the procedure can be applied. 578 Part of the complication here is that in the abstract it is very 579 difficult to know what addresses should appear in packets sent from 580 one ISP to another. Hence packet level filtering and enforcement is 581 very difficult at this point in the network. Whether one views this 582 as specific to the NNI, or a general property of the Internet, it is 583 still a major factor that needs to be taken into account. 585 4.1.5. Cable Modem Subscriber Access 587 Cable Modem Termination Systems (CMTS) employ DOCSIS Media Access 588 Control (MAC) domains. These share some properties with general 589 switched networks, as described above in Section 4.1.1, some 590 properties with DSL access networks, as described below in 591 Section 4.1.6. They also often have their own provisioning and 592 monitoring tools which may address some of the issues described here. 594 4.1.6. DSL Subscriber Access 596 While DSL subscriber access can be bridged or routed, as seen by the 597 service provider's device, it is generally the case that the 598 protocols carry enough information to verify which subscriber is 599 sending packets. Thus, for ensuring that one DSL subscriber does not 600 spoof another, enforcement can generally be done at the aggregation 601 router. This is true even when there is a bridged infrastructure 602 among the subscribers, as DSL access generally requires all 603 subscriber traffic to go through the access aggregation router. 605 If it is desirable to provide spoofing protection among the devices 606 within a residence, that would need to be provided by the CPE device, 607 as the ISPs router does not have enough visibility to do that. It is 608 not clear at this time that this problem is seen as a relevant 609 threat. 611 4.2. Currently Available Tools 613 There are a number of tools which have been developed, and have seen 614 some deployment, for addressing these attacks. 616 4.2.1. BCP 38 618 If BCP 38 [RFC2827] is implemented in LAN segments, it is typically 619 done so on subnetwork boundaries and traditionally relates only to 620 Network Layer ingress filtering policies. The result is that hosts 621 within the segment cannot spoof packets from address space outside of 622 the local segment itself, however, they may still spoof packets using 623 sources addresses that exist within the local network segment. 625 4.2.2. Unicast RPF 627 Unicast RPF is a crude mechanism to automate definition of BCP 38 628 style filters based on routing table information. Its applicability 629 parallels that of BCP 38, although deployment caveats exist, as 630 outlined in [RFC3704]. 632 4.2.3. Port-based Address Binding 634 Much of the work of SAVI is initially targeting minimizing source 635 address spoofing in the LAN. In particular, if mechanisms can be 636 defined to accommodate configuration of port binding information for 637 IP, either to a port, to an unforgeable MAC address, or to other 638 unforgeable credentials in the packet, a large portion of the 639 spoofing threat space in the LAN can be marginalized. 641 However, establishing this binding is not trivial, and varying across 642 both topologies type and address allocation mechanisms. 644 4.2.3.1. Manual Binding 646 Binding of a single Link Layer and Network Layer address to a port 647 may initially seem trivial. However, two primary areas exist that 648 can complicate such techniques. In particular, these areas involve 649 topologies where more than a single IP layer address may be 650 associated with a MAC address on a given port, or where multiple 651 hosts are connected via a single physical port. Furthermore, if one 652 or more dynamic address allocation mechanisms such as DHCP are 653 employed, then some mechanism must exist to associate those IP layer 654 addresses with the appropriate Link layer ports, as addresses are 655 allocated or reclaimed. 657 4.2.3.2. Automated Binding 659 For IPv4 the primary and very widely used automated address 660 assignment technique is DHCP based address assignment. Controlling 661 where authoritative information can be sourced, coupled with sniffing 662 and enforcing the assignments is an effective technique, which can in 663 many networks automatically provide sufficient binding information. 665 For IPv6, there are two common automated address assignment 666 techniques. While there are many variations and details, for 667 purposes of understanding the threats and basic responses, these are 668 Stateless Address Autoconfiguration (SLAAC) and DHCPv6 based address 669 assignment. In both cases, SAVI binding establishment needs to be 670 tied to the state machines for these address assignment protocols, 671 with appropriate message sniffing and enforcement. For DHCPv6 based 672 techniques, it is also necessary to use classification techniques to 673 ensure that responses which are trusted actually come from 674 authoritative sources. 676 4.2.3.3. IEEE 802.1x 678 IEEE 802.1x is an authentication protocol that permits a network to 679 determine the identity of a system seeking to join it and apply 680 authorization rules to permit or deny the action. In and of 681 themselves, such tools confirm only that the user is authorized to 682 use the network, but do not enforce what IP address the user is 683 allowed to use. It is worth noting that elements of 802.1x may well 684 be useful as binding anchors for SAVI solutions. 686 4.2.4. Cryptographic Techniques 688 Needless to say, MITM and replay attacks can typically be mitigated 689 with cryptographic techniques. However, many of the applications 690 today either don't or can't employ cryptographic authentication and 691 protection mechanisms. ARP for IPv4 does not use such protection. 692 While SEND provides such protection for IPv6 NDP, SEND is not widely 693 used to date. 695 While DNSSEC will significantly help protect DNS from the effects of 696 spoof based poisoning attacks, such protection does not help protect 697 the rest of the network from spoofed attacks. 699 4.2.5. Residual Attacks 701 It should be understood that not all combinations of network, service 702 and enforcement choices will result in a protectable network. For 703 example, if one uses conventional SLAAC, in a switched network, but 704 tries to only provide address enforcement on the routers on the 705 network, then the ability to provide protection is severely limited. 707 5. Topological Challenges Facing SAVI 709 As noted previously, topological components and address allocation 710 mechanisms have significant implications on what is feasible with 711 regard to Link layer address and IP address port bindings. The 712 following sections discuss some of the various topologies and address 713 allocation mechanisms that proposed SAVI solutions should attempt to 714 address. 716 5.1. Address Provisioning Mechanisms 718 In a strictly static environment, configuration management for access 719 filters that map Link Layer and Network Layer addresses on a specific 720 switch port might be a viable option. However, most networks, 721 certainly those that accommodate actual human users, are much more 722 dynamic in nature. As such, mechanisms that provide port-MAC-IP 723 bindings need to accommodate dynamic address allocation schemes 724 enabled by protocols such as DHCP, DHCPv6 for address allocation, and 725 IPv6 Stateless Address Autoconfiguration. 727 5.2. LAN devices with Multiple Addresses 729 From a topology considerations perspective, when attempting 730 port-MAC-IP bindings, hosts connected to switch ports that may have 731 one or more IP addresses, or certainly, devices that forward packets 732 from other network segments, present traffic that is much harder to 733 make subject to such bindings and enforcement. 735 5.2.1. Routers 737 The most obvious example of devices that are problematic when 738 attempting to implement port-MAC-IP bindings is that of routers. 739 Routers not only originate packets themselves and often have multiple 740 interfaces, but also forward packets from other network segments. As 741 a result, it's difficult for port-MAC-IP binding rules to be 742 established a priori, because it's likely that many addresses and IP 743 subnets should be associated with the port-MAC in question. 745 5.2.2. NATs 747 Validating traffic from Prefix-based and multi-address NATs also 748 becomes problematic, for the same reasons as routers. Because they 749 may forward traffic from an array of address, a priori knowledge must 750 exist providing what IPs should be associated with a given port-MAC 751 pair. 753 5.2.3. Multi-Instance Hosts 755 Another example that introduces complexities is that of multi- 756 instance hosts attached to a switch port. These are single physical 757 devices, which internally run multiple physical or logical hosts. 758 When the device is a blade server, e.g. with internal blades each 759 hosting a physical machine, there is essentially a physical switch 760 inside the blade server. While tractable, this creates some 761 complexity for determining where enforcement logic can or should 762 live. 764 Logically distinct hosts such as are provided by many varieties of 765 virtualization logic result in a single physical host, connect to a 766 single port on the Ethernet switch in the topology, actually having 767 multiple internal virtual machines, each with IP and MAC addresses, 768 and what is essentially (or sometimes literally) an internal LAN 769 switch. While it may be possible for this internal switch to help 770 control threats among the virtual hosts, or between virtual hosts and 771 other parts of the network, such enforcement cannot be counted on at 772 this time. 774 5.2.4. Multi-LAN Hosts 776 Multi-interface hosts, in particular those that are multi-homed and 777 may forward packets from any of a number of source addresses, can be 778 problematic as well. In particular, if a port-MAC-IP binding is made 779 on each of the interfaces, and then either a loopback IP or the 780 address of third interface is used as the source address of a packet 781 forwarded through an interface for which the port-MAC-IP binding 782 doesn't map, the traffic may be discarded. Static configuration of 783 port-MAC-IP bindings may accommodate this scenario, although some a 784 priori knowledge on address assignment and topology is required. 786 While the use of loopback addressing or sending packets out one 787 interface with the source address from another are rare, they do 788 legitimately occur. Some servers, particularly ones that have 789 underlying virtualization, use loopback techniques for management. 791 5.2.5. Firewalls 793 Firewalls that forward packets from other network segments, or serve 794 as a source for locally originated packets, suffer from the same 795 issues as routers. 797 5.2.6. Mobile IP 799 Mobile IP hosts in both IPv4 and IPv6 are proper members of the site 800 where they are currently located. Their care-of-address is a 801 properly assigned address that is on the link they are using. And 802 their packets are sent and received using that address. Thus, they 803 do not introduce any additional complications. (There was at one 804 time consideration of allowing mobile hosts to use their home address 805 when away from home. This was not done, precisely to ensure that 806 mobile hosts comply with source address validity requirements.) 807 Mobile Hosts with multiple physical interfaces fall into the cases 808 above. 810 Mobile IP home agents are somewhat more interesting. Although they 811 are (typically) fixed devices, they are required to send and receive 812 packets addressed from or to any currently properly registered mobile 813 node. From an analysis point of view, even though the packets that a 814 Home Agent handles are actually addressed to or from the link the HA 815 is on, it is probably best to think of them as routers, with a 816 virtual interface to the actual hosts they are serving. 818 5.2.7. Other Topologies 820 Any topology that results in the possibility that a device connected 821 to a switch port may forward packets with more than a single source 822 address for packet which it originated may be problematic. 823 Additionally, address allocation schemas introduce additional 824 considerations when examining a given SAVI solutions space. 826 5.3. IPv6 Considerations 828 IPv6 introduces additional capabilities which indirectly complicate 829 the spoofing analysis. IPv6 introduces and recommends the use of 830 SLAAC [RFC4862]. This allows hosts to determine their IP prefix, 831 select an IID, and then start communicating. While there are many 832 advantages to this, the absence of control interactions complicates 833 the process of behavioral enforcement. 835 An additional complication is the very large IID space. Again, this 836 64 bit ID space provided by IPv6 has many advantages. It provides 837 the opportunity for many useful behaviors. However, it also means 838 that in the absence of controls, hosts can mint anonymous addresses 839 as often as they like, modulo the idiosyncrasies of the duplicate 840 address procedure. Like many behaviors, this is a feature for some 841 purposes, and a problem for others. For example, without claiming 842 the entire ID space, an on-link attacker may be able to generate 843 enough IP addresses to fill the Neighbor Discovery table space of the 844 other L3 devices on the link, including switches which are monitoring 845 L3 behavior. This could seriously interfere with the ability for 846 other devices on the link to function. 848 6. Analysis of Host Granularity Anti-Spoofing 850 Applying anti-spoofing techniques at the host level enables a site to 851 achieve several valuable objectives. While it is likely the case 852 that for many site topologies and policies, full source spoofing 853 protection is not possible, it is also true that for many sites there 854 are steps that can be taken that provide benefit. 856 One important class of benefit is masquerade prevention. Security 857 threats involving one machine masquerading as another, for example in 858 order to hijack an apparently secure session, can occur within a site 859 with significant impact. Having mechanisms such that host facing 860 devices prevent this is a significant intra-site security 861 improvement. Given that security experts report that most security 862 breaches are internal, this can be valuable. One example of this is 863 that such techniques should mitigate internal attacks on the site 864 routing system. 866 A second class of benefit is related to the traceability described 867 above. When a security incident is detected, either within a site, 868 or externally (and traced to the site) it can be critical to 869 determine what the actual source of the incident was. If address 870 usage can be tied to the kinds of anchors described earlier, then it 871 is possible to respond to security incidents. 873 In addition to these local observable benefits, there can be more 874 global benefits. For example, if address usage is tied to anchors, 875 it may be possible to prevent or control the use of large numbers of 876 anonymous IPv6 addresses for attacks, or at least to track even those 877 attacks back to their source. 879 7. IANA Considerations 881 This memo asks the IANA for no new parameters. 883 Note to RFC Editor: This section will have served its purpose if it 884 correctly tells IANA that no new assignments or registries are 885 required, or if those assignments or registries are created during 886 the RFC publication process. From the authors' perspective, it may 887 therefore be removed upon publication as an RFC at the RFC Editor's 888 discretion. 890 8. Security Considerations 892 This document provides limited discussion of some security threats 893 source address validation improvements will help to mitigate. It is 894 not meant to be all-inclusive, either from a threat analysis 895 perspective, or from the source address verification application 896 side. 898 It is seductive to think of SAVI solutions as providing the ability 899 to use this technology to trace a datagram to the person, or at least 900 end system, that originated it. For several reasons, the technology 901 can be used to derive circumstantial evidence, but does not actually 902 solve that problem. 904 In the Internet Layer, the source address of a datagram should be the 905 address of the system that originated it and to which any reply is 906 expected to come. But systems fall into several broad categories. 907 Many are single user systems, such as laptops and PDAs. Multi-user 908 systems are commonly used in industry, and a wide variety of 909 middleware systems and application servers have no user at all, but 910 by design relay messages or perform services on behalf of users of 911 other systems (e.g., SMTP and peer-to-peer file sharing). 913 Until every Internet-connected network implements source address 914 validation at the ultimate network ingress, and assurances exist that 915 intermediate devices are to never modify datagram source addresses, 916 source addresses must not be used as an authentication mechanism. 917 The only technique to unquestionably verify source addresses of a 918 received datagram are cryptographic authentication mechanisms such as 919 IPsec. 921 9. Acknowledgments 923 A portion of the primer text in this document came directly from 924 [I-D.baker-sava-operational], authored by Fred Baker and Ralph Droms. 925 Many thanks to Christian Vogt, Suresh Bhogavilli, and Pekka Savola 926 for contributing text and a careful review of this document. 928 10. References 930 10.1. Normative References 932 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 933 September 1981. 935 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 936 (IPv6) Specification", RFC 2460, December 1998. 938 10.2. Informative References 940 [I-D.baker-sava-operational] 941 Baker, F. and R. Droms, "IPv4/IPv6 Source Address 942 Verification", draft-baker-sava-operational-00 (work in 943 progress), June 2007. 945 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 946 RFC 793, September 1981. 948 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 949 converting network protocol addresses to 48.bit Ethernet 950 address for transmission on Ethernet hardware", STD 37, 951 RFC 826, November 1982. 953 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 954 Defeating Denial of Service Attacks which employ IP Source 955 Address Spoofing", BCP 38, RFC 2827, May 2000. 957 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 958 Networks", BCP 84, RFC 3704, March 2004. 960 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 961 Protocol 4 (BGP-4)", RFC 4271, January 2006. 963 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 964 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 965 September 2007. 967 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 968 Address Autoconfiguration", RFC 4862, September 2007. 970 Authors' Addresses 972 Danny McPherson 973 VeriSign, Inc. 975 Email: dmcpherson@verisign.com 977 Fred Baker 978 Cisco Systems 980 Email: fred@cisco.com 982 Joel M. Halpern 983 Ericsson 985 Email: joel.halpern@ericsson.com