idnits 2.17.1 draft-ietf-savi-threat-scope-07.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 03, 2013) is 4034 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.J. Baker 5 Expires: October 05, 2013 Cisco Systems 6 J.M. Halpern 7 Ericsson 8 April 03, 2013 10 SAVI Threat Scope 11 draft-ietf-savi-threat-scope-07 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 05, 2013. 40 Copyright Notice 42 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Spoofed-based Attack Vectors . . . . . . . . . . . . . . . . 5 60 3.1. Blind Attacks . . . . . . . . . . . . . . . . . . . . . . 6 61 3.1.1. Single Packet Attacks . . . . . . . . . . . . . . . . 6 62 3.1.2. Flood-Based DoS . . . . . . . . . . . . . . . . . . . 6 63 3.1.3. Poisoning Attacks . . . . . . . . . . . . . . . . . . 7 64 3.1.4. Spoof-based Worm/Malware Propagation . . . . . . . . 8 65 3.1.5. Reflective Attacks . . . . . . . . . . . . . . . . . 8 66 3.1.6. Accounting Subversion . . . . . . . . . . . . . . . . 8 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) . . . . . . . . . . . . . . 9 70 3.2.2. Third Party Recon . . . . . . . . . . . . . . . . . . 10 71 3.2.3. Other Non-Blind Spoofing Attacks . . . . . . . . . . 10 72 4. Current Anti-Spoofing Solutions . . . . . . . . . . . . . . . 10 73 4.1. Topological Locations for Enforcement . . . . . . . . . . 12 74 4.1.1. Host to link layer neighbor via switch . . . . . . . 12 75 4.1.2. Upstream Switches . . . . . . . . . . . . . . . . . . 12 76 4.1.3. Upstream Routers . . . . . . . . . . . . . . . . . . 13 77 4.1.4. ISP Edge PE Router . . . . . . . . . . . . . . . . . 13 78 4.1.5. ISP NNI Router to ISP NNI Router . . . . . . . . . . 13 79 4.1.6. Cable Modem Subscriber Access . . . . . . . . . . . . 14 80 4.1.7. DSL Subscriber Access . . . . . . . . . . . . . . . . 14 81 4.2. Currently Available Tools . . . . . . . . . . . . . . . . 15 82 4.2.1. BCP 38 . . . . . . . . . . . . . . . . . . . . . . . 15 83 4.2.2. Unicast RPF . . . . . . . . . . . . . . . . . . . . . 15 84 4.2.3. Port-based Address Binding . . . . . . . . . . . . . 15 85 4.2.4. Cryptographic Techniques . . . . . . . . . . . . . . 16 86 4.2.5. Residual Attacks . . . . . . . . . . . . . . . . . . 17 87 5. Topological Challenges Facing SAVI . . . . . . . . . . . . . 17 88 5.1. Address Provisioning Mechanisms . . . . . . . . . . . . . 17 89 5.2. LAN devices with Multiple Addresses . . . . . . . . . . . 17 90 5.2.1. Routers . . . . . . . . . . . . . . . . . . . . . . . 17 91 5.2.2. NATs . . . . . . . . . . . . . . . . . . . . . . . . 17 92 5.2.3. Multi-Instance Hosts . . . . . . . . . . . . . . . . 18 93 5.2.4. Multi-LAN Hosts . . . . . . . . . . . . . . . . . . . 18 94 5.2.5. Firewalls . . . . . . . . . . . . . . . . . . . . . . 19 95 5.2.6. Mobile IP . . . . . . . . . . . . . . . . . . . . . . 19 96 5.2.7. Other Topologies . . . . . . . . . . . . . . . . . . 19 98 5.3. IPv6 Considerations . . . . . . . . . . . . . . . . . . . 19 99 6. Analysis of Host Granularity Anti-Spoofing . . . . . . . . . 20 100 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 101 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 102 8.1. Privacy Considerations . . . . . . . . . . . . . . . . . 22 103 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 104 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 105 10.1. Normative References . . . . . . . . . . . . . . . . . . 23 106 10.2. Informative References . . . . . . . . . . . . . . . . . 23 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 109 1. Overview 111 The Internet Protocol, specifically IPv4 [RFC0791] and IPv6 112 [RFC2460], employ a connectionless hop-by-hop packet forwarding 113 paradigm. A host connected to an IP network that wishes to 114 communicate with another host on the network generates an IP packet 115 with source and destination IP addressing information, among other 116 options. 118 At the IP Network Layer, or Internet Layer, there is typically no 119 required transactional state when communicating with other hosts on 120 the network. In particular, the network does not track any state 121 about the hosts using the network. This is normally a benefit. 122 However, as a consequence of this, hosts generating packets for 123 transmission have the opportunity to spoof (forge) the source address 124 of packets which they transmit, as the network does not have any way 125 to tell that some of the information is false. 127 Source address validation is necessary in order to detect and reject 128 spoofed packets at the IP layer in the network, and contributes to 129 the overall security of IP networks. This draft deals with the 130 subset of such validation done by the network based on observed 131 traffic and policy. Such source address validation techniques enable 132 detection and rejection of many spoofed packets, and also implicitly 133 provide some assurances that the source address in an IP packet is 134 legitimately assigned to the system that generated the packet. 136 Solutions such as BCP 38 [RFC2827] provide guidelines for one such 137 technique for network ingress filtering. However, if these 138 techniques are not implemented at the ingress point of the IP 139 network, then the validity of the source address cannot be positively 140 ascertained. Furthermore, BCP 38 only implies source address 141 validation at the Internet Layer, and is most often implemented on IP 142 subnetwork address boundaries. One of the difficulties in 143 encouraging the deployment of BCP 38 is that there is relatively 144 little benefit until it is very widely deployed, which is not yet the 145 case. 147 Hence, in order to try to get better behavior, it is helpful to look 148 for an application like BCP 38, but one which can be applied locally, 149 and give locally beneficial results. The local benefit would provide 150 a reason for the site to deploy, while moving the Internet as a whole 151 towards an environment where BCP 38 is widely effected. SAVI is 152 aimed at providing locally more specific protection, with the benefit 153 of better local behavior and local traceability, while also providing 154 better compliance with the cases dealt with by BCP 38. 156 It should be noted that while BCP 38 directs providers to provide 157 protection from spoofed prefixes, it is clearly desirable for 158 enterprise operators to provide that protection more locally, and 159 with better traceability. This allows the enterprise to be a better 160 Internet participant, and to quickly detect and remedy problems when 161 they occur. For example, when an enterprise receives a report of an 162 attack originating within that enterprise, the operational staff 163 desires to be able to track from the IP address sourcing the attack 164 to the particular machine within the enterprise that is the source. 165 This is typically simpler and more reliable than other techniques, 166 such as trying to find the attack in ongoing outbound traffic To do 167 this, the enterprise needs both that the address assignment and usage 168 information be usable (logging), and that the information be 169 accurate, i.e. that no other machine could have been using that 170 address. 172 Also, there is a possibility that in a LAN environment where multiple 173 hosts share a single LAN or IP port on a switch or router, one of 174 those hosts may spoof the source addresses of other hosts within the 175 local subnet. Understanding these threats and the relevant 176 topologies in which they're introduced is critical when assessing the 177 threats that exist with source address spoofing. 179 This document provides additional details regarding spoofed-based 180 threat vectors, and discuss implications of various network 181 topologies. 183 2. Glossary of Terms 185 The following acronyms and terms are used throughout this memo. 187 binding anchor: The relationship used by a device performing source 188 address enforcement to perform the validation and enforcement. 189 Examples in different situations include Layer 2 addresses or 190 physical ports. 192 BGP: The Border Gateway Protocol, used to manage routing policy 193 between large networks. 195 CPE Router: Customer Premises Equipment Router. The router on the 196 customer premises, whether owned by the customer or the provider. 197 Also called the Customer Edge, or CE, Router. 199 IP Address: An Internet Protocol Address, whether IPv4 or IPv6. 201 ISP: Internet Service Provider. Any person or company that delivers 202 Internet service to another. 204 MAC Address: An Ethernet Address or comparable IEEE 802 series 205 address. 207 NNI Router: Network to Network Interface Router. This router 208 interface faces a similar system operated by another ISP or other 209 large network. 211 PE Router: Provider Edge Router. This router faces a customer of an 212 ISP. 214 Spoofing: The act of sending a datagram header whose contents at the 215 Link or Network Layer do not match the network policies and 216 activities on address assignment or claiming. Generally, this 217 corresponds o sending messages with source network or link layer 218 information that is assigned to or properly claimed by some other 219 devices in the network 221 TCP: The Transmission Control Protocol, used on end systems to 222 manage data exchange. 224 uRPF: Unicast Reverse Path Forwarding. A procedure in which the 225 route table, which is usually used to look up destination 226 addresses and route towards them, is used to look up the source 227 address and ensure that one is routing away from it. When this 228 test fails, the event may be logged, and the traffic is commonly 229 dropped. 231 3. Spoofed-based Attack Vectors 233 Spoofing is employed on the Internet for a number of reasons, most of 234 which are in some manner associated with malicious or otherwise 235 nefarious activities. In general, two classes of spoofed-based 236 attack vectors exist: blind attacks and non-blind attacks. The 237 following sections provide some information of blind and non-blind 238 attacks. The section includes information on attacks where the 239 spoofing is primarily intended to interfere with tracing the attacks, 240 as well as attacks where spoofing the source address is a necessary 241 component to the damage or interference. 243 3.1. Blind Attacks 245 Blind attacks typically occur when an attacker isn't on the same 246 local area network as a source or target, or when an attacker has no 247 access to the data path between the attack source(s) and the target 248 systems. In this situation, the attacker has no access to the source 249 and target systems. 251 3.1.1. Single Packet Attacks 253 One type of blind attacks, which we'll refer to here as "single 254 packet DoS (Denial of Service) attacks", involves an attacking system 255 injecting spoofed information into the network which results in 256 either a complete crash of the target system, or in some manner 257 poisons some network configuration or other information on a target 258 system so as to impact network or other services. 260 An example of an attack that can cause a receiving system to crash is 261 what is called a LAND attack. A LAND attack packet would consist of 262 an attacking system sending a packet (e.g., TCP SYN) to a target 263 system that contains both a source and destination address of that 264 target system. It would also contain a single value for port number, 265 used as both the source and destination port number. Certain target 266 systems will then "lock up" when creating connection state associated 267 with the packet, or would get stuck in a state where it continuously 268 replies to itself. As this is an attack that relies on bugs in the 269 target, it is possible, but by no means certain, that this threat is 270 no longer viable. 272 Another form of blind attack is a RST probe [RFC0793]. The attacker 273 sends a series of packets to a destination which is engaged in a 274 long-lived TCP session. The packets are RST packets, and the 275 attacker uses the known source and destination addresses and port 276 numbers, along with guesses at the sequence number. If he can send a 277 packet close enough to the right value, in theory he can terminate 278 the TCP connection. While there are various steps that have been 279 developed to ameliorate this attack, preventing the spoofing of 280 source addresses completely prevents the attack from occuring. 282 3.1.2. Flood-Based DoS 284 Flooding-based DoS attack vectors are particularly effective attacks 285 on the Internet today. They usually entail flooding a large number 286 of packets towards a target system, with the hopes of either 287 exhausting connection state on the target system, consuming all 288 packet processing capabilities of the target or intermediate systems, 289 or consuming a great deal of bandwidth available to the target system 290 such that they are essentially inaccessible. 292 Because these attacks require no reply from the target system and 293 require no legitimate transaction state, attackers often attempt to 294 obfuscate the identity of the systems that are generating the attack 295 traffic by spoofing the source IP address of the attacking traffic 296 flows. Because ingress filtering isn't applied ubiquitously on the 297 Internet today, spoof-based flooding attack vectors are typically 298 very difficult to traceback. In particular, there may be one or more 299 attacking sources beyond your network border, and the attacking 300 sources may or may not be legitimate sources, it's difficult to 301 determine if the sources are not directly connected to the local 302 routing system. These attacks might be seen as primarily to be 303 addressed by BCP 38 deployment, which would not be in scope for this 304 document. However, as noted earlier, deployment of SAVI can help 305 remediate lack of BCP 38, and even when BCP 38 is deployed can help 306 provide useful information for responding to such attacks. 308 Common flood-based DoS attack vectors today include SYN floods, ICMP 309 floods, and IP fragmentation attacks. Attackers may use a single 310 legitimate or spoofed fixed attacking source address, although 311 frequently they cycle through large swaths of address space. As a 312 result, mitigating these attacks on the receiving end with source- 313 based policies is extremely difficult. 315 If an attacker can inject messages for a protocol which requires 316 control plane activity, it may be possible to deny network control 317 services at a much lower attack level. While there are various forms 318 of protection deployed against this, they are by no means complete. 319 Attacks which are harder to trace (such as with spoofed addresses) 320 are of course of more concern. 322 Furthermore, the motivator for spoof-based DoS attacks may actually 323 be to encourage the target to filter explicitly on a given set of 324 source addresses, or order to disrupt the legitimate owner(s) access 325 to the target system. 327 3.1.3. Poisoning Attacks 329 While poison attacks can often be done with single packets, it is 330 also true that a stream of packets can be used to find a window where 331 the target will accept the incorrect information. In general, this 332 can be used to perform broadly the same kinds of poisonings as above, 333 with more versatility. 335 One important class of poisoning attacks are attacks aimed at 336 poisoning network or DNS cache information, perhaps to simply break a 337 given host's connection, enable MITM (Man in the Middle) or other 338 attacks. Network level attacks that could involve single packet DoS 339 include ARP cache poisoning and ICMP redirects. The most obvious 340 example which depends upon falsifying an IP source address is an on- 341 link attacker poisoning a router's ARP or ND cache. The ability to 342 forge a source address can also be helpful in causing a DNS cache to 343 accept and use incorrect information. 345 3.1.4. Spoof-based Worm/Malware Propagation 347 Self-propagating malware has been observed that spoofs its source 348 address when attempting to propagate to other systems. Presumably, 349 this was done to obfuscate the actual source address of the infected 350 system. This attack is important both in terms of an attack vector 351 that SAVI may help prevent, and also as a problem which SAVI can help 352 track back to find infected systems. 354 3.1.5. Reflective Attacks 356 Reflective amplifications attacks, wherein a sender sends a single 357 packet to an intermediary, resulting in the intermediary sending a 358 large number of packets, or much larger packets, to the target, are a 359 particularly potent DoS attack vector on the Internet today. Many of 360 these attacks rely on using a false source address, so that the 361 amplifier attacks the target by responding to the messages. 363 DNS is one of the common targets of such attacks. The amplification 364 factor observed for attacks targeting DNS root and other top level 365 domain name infrastructure in early 2006 was on the order of 76:1. 366 The result is that just 15 attacking sources with 512Kbps of upstream 367 attack bandwidth could generate one Gbps of response attack traffic 368 towards a target system. 370 Smurf attacks employ a similar reflective amplification attack 371 vector, exploiting traditional default IP subnet directed broadcast 372 address behaviors that would result in all the active hosts on a 373 given subnet responding to (spoofed) ICMP echo request from an 374 attacker, and generating a large amount of ICMP echo response traffic 375 directed towards a target system. They were particularly effective 376 in large campus LAN environments where 50k or more hosts might reside 377 on a single subnet. 379 3.1.6. Accounting Subversion 380 If an attacker wishes to distribute content or other material in a 381 manner that employs protocols that require only uni-directional 382 flooding and generate no end-end transactional state, they may desire 383 to spoof the source IP address of that content in order to avoid 384 detection or accounting functions enabled at the IP layer. While 385 this particular attack has not been observed, it is included here to 386 reflect the range of power that spoofed addresses may have even 387 without the ability to receive responses. 389 3.1.7. Other Blind Spoofing Attacks 391 Other Blind spoofing attacks might include spoofing in order to 392 exploit source routing or other policy based routing implemented in a 393 network. It may also be possible in some environments to use 394 spoofing techniques to perform blind or non-blind attacks on the 395 routers in a site or in the Internet. There are many techniques to 396 mitigate these attacks, but it is well known that there are 397 vulnerabilities in this area. 399 3.2. Non-Blind Attacks 401 Non-blind attacks often involve mechanisms such as eavesdropping on 402 connection, resetting state so that new connections may be hijacked, 403 and an array of other attack vectors. Perhaps the most common of 404 these attack vectors is known as man in the middle attacks. In this 405 case, we are concerned not with an attacker who can modify a stream, 406 but rather one who has access to information from the stream, and 407 uses that to launch his own attacks. 409 3.2.1. Man in the Middle (MITM) 411 Connection Hijacking is one of the more common man in the middle 412 attack vectors. In order to hijack a connection an attacker usually 413 needs to be in the forwarding path and often times employs TCP RST or 414 other attacks in order to reset a transaction. The attacker may have 415 already compromised a system that's in the forwarding path, or they 416 may wish to insert themselves in the forwarding path. 418 For example, an attacker with access to a host on LAN segment may 419 wish to redirect all the traffic on the local segment destined for a 420 default gateway address (or all addresses) to itself in order to 421 perform man-in-the-middle attacks. In order to accomplish this, in 422 IPv4 the attacker might transmit gratuitous ARP [RFC0826] messages or 423 ARP replies to the Ethernet broadcast address ff:ff:ff:ff:ff:ff, 424 notifying all the hosts on the segment that the IP address(es) of the 425 target(s) now map to it's own Layer 2 address. The source IP address 426 in this case is spoofed. Similar vulnerabilities exist in IPv6 NDP 427 [RFC4861]. 429 3.2.2. Third Party Recon 431 Another example of sighted attack is third party reconnaissance. The 432 use of spoofed addresses, while not necessary for this, can often 433 provide additional information, and helps mask the traceability of 434 the activity. The attack involves sending packets towards a given 435 target system and observing either target or intermediate system 436 responses. For example, if an attacker were to source spoof TCP SYN 437 packets towards a target system from a large set of source addresses, 438 and observe responses from that target system or some intermediate 439 firewall or other middle box, they would be able to identify what IP 440 layer filtering policies may be in place to protect that system. 442 3.2.3. Other Non-Blind Spoofing Attacks 444 There are presumably many other attacks that can be performed based 445 on the ability t spoof source address while seeing the target. Among 446 other attacks, if there are multiple routers on-link with hosts, a 447 host may be able to cause problems for the routing system by 448 replaying modified or unmodified routing packets as if they came from 449 another router. 451 4. Current Anti-Spoofing Solutions 453 The goal of this work is to reduce datagrams with spoofed IP 454 addresses from the Internet. This can be aided by Identifying and 455 dropping datagrams whose source address binding is incompatible with 456 the Internet topology and learned information. This can be done at 457 sites where the relationship between the source address and topology 458 and binding information can be checked. For example, With these 459 bindings, in many networks Internet devices can confirm that: 461 o The IP source address is appropriate for the lower layer address 462 (they both identify the same system) 464 o The IP source address is explicitly identified as appropriate for 465 the physical topology; for example, the source address is 466 appropriate for the layer 2 switch port through which the datagram 467 was received. 469 o The prefix to which the IP source address belongs is appropriate 470 for the part of the network topology from which the IP datagram 471 was received (while the individual system may be unknown, it is 472 reasonable to believe that the system is located in that part of 473 the network). 475 Filtering points farther away from the source of the datagram can 476 make decreasingly authoritative assertions about the validity of the 477 source address in the datagram. Nonetheless, there is value in 478 dropping traffic that is clearly inappropriate, and in maintaining 479 knowledge of the level of trust one can place in an address. 481 Edge Network 1 CPE-ISP _.------------. 482 _.----------------. Ingress/ ISP A `--. 483 ,--'' `---. ,' `. 484 ,' +----+ +------+ +------+ `. / +------+ +------+ \\ 485 ( |Host+--+Switch+--+ CPE +---)-(---+ PE +- - - -+ NNI | ) 486 `. +----+ +------+ |Router| ,' \\ |Router| |Router| / 487 `---. Host-neighbor +------+' `.+------+ +--+---+,' 488 `----------------'' '--. |_.-' 489 `------------'| 490 | 491 Edge Network 2 ISP-ISP Ingress | 492 _.----------------. _.----------.| 493 ,--'' `---. ,-'' |--. 494 ,' +----+ +------+ +------+ `. ,+------+ +--+---+. 495 ( |Host+--+Switch+--+ CPE +---)---+-+ PE +- - - -+ NNI | \\ 496 `. +----+ +------+ |Router| ,' ( |Router| |Router| ) 497 `---. +------+' \\ +------+ +------+ / 498 `----------------'' `. ,' 499 '--. ISP B _.-' 500 `----------'' 502 Figure 1: Points where an address can be validated 504 Figure 1 illustrates five related paths where a source address can be 505 validated: 507 o host to switch, including host to host via the switch 509 o Host to enterprise CPE Router 511 o Enterprise CPE Router to ISP edge PE Router, and the reverse 513 o ISP NNI Router to ISP NNI Router 515 In general, datagrams with spoofed IP addresses can be detected and 516 discarded by devices that have an authoritative mapping between IP 517 addresses and the network topology. For example, a device that has 518 an authoritative table between Link Layer and IP addresses on a link 519 can discard any datagrams in which the IP address is not associated 520 with the Link Layer address in the datagram. The degree of 521 confidence in the source address depends on where the spoofing 522 detection is performed and the prefix aggregation in place between 523 the spoofing detection and the source of the datagram. 525 4.1. Topological Locations for Enforcement 527 There are a number of kinds of places, which one might call 528 topological locations, where solutions may or should be deployed. As 529 can be seen in the details below, as the point of enforcement moves 530 away from a single cable attached directly to the host being 531 validated, additional complications arise. It is likely that fully 532 addressing many of these cases may require additional coordination 533 mechanisms across the device which cover the disparate paths. 535 4.1.1. Host to link layer neighbor via switch 537 The first point at which a datagram with a spoofed address can be 538 detected is on the link to which the source of the datagram is 539 connected. At this point in the network, the source Link Layer and 540 IP addresses are both available, and can be validated against each 541 other, and potentially against the physical port being used. A 542 datagram in which the IP source address does not match the 543 corresponding Link Layer address can be discarded. Of course, the 544 trust in the filtering depends on the trust in the method through 545 which the mappings are developed. This mechanism can be applied by a 546 first hop router, or switch on the link. The first hop switch has 547 the most precise information for this. 549 On a truly shared medium link, such as classic Ethernet, the best 550 that can be done is to validate the Link Layer and IP addresses 551 against the mappings. When the link is not shared, such as when the 552 hosts are connected through a switch, the source host can be 553 identified precisely based on the port through which the datagram is 554 received or the Layer 2 address if it is known to the switch. Port 555 identification prevents transmission of malicious datagrams whose 556 Link Layer and IP addresses are both spoofed to mimic another host. 558 Other kinds of links may fall at different places in this spectrum, 559 with some wireless links having easier ways of identifying individual 560 devices than others, for example. 562 4.1.2. Upstream Switches 564 In many topologies, there can be additional switches between the host 565 attached switch and the first router in the network. In these cases, 566 additional issues can arise which affect SAVI operations. If the 567 bridging topologies which connects the switches changes, or if LACP 568 [IEEE802.3ad], VRRP, or link management operations, change which 569 links are used to deliver traffic, the switch may need to move the 570 SAVI state to a different port, or the state may need to be moved or 571 reestablished on a different switch. 573 4.1.3. Upstream Routers 575 Beyond the first hop router, subsequent routers may additionally 576 filter traffic from downstream networks. Because these routers do 577 not have access to the Link Layer address of the device from which 578 the datagram was sent, they are limited to confirming that the source 579 IP address is within a prefix that is appropriate for downstream 580 router from which the datagram was received. 582 Options include the use of simple access lists or the use of unicast 583 reverse path filtering (uRPF). Access lists are generally 584 appropriate only for the simplest cases, as management can be 585 difficult. Strict Unicast RPF accepts the source address on a 586 datagram if and only if it comes from a direction that would be 587 rational to send a datagram directed to the address, which means that 588 the filter is derived from routing information. These filtering 589 procedures are discussed in more detail in [RFC3704]. 591 In many cases, this router has access to information about what IP 592 prefixes are to be used on a given subnet. This might be because it 593 delegated that prefix through DHCP or monitored such a delegation. 594 It may have advertised that prefix in IPv6 Neighbor Discovery Router 595 Advertisement messages, or monitored such an advertisement. These 596 can be seen as generalizations of the access lists above. When the 597 topology permits, the router can enforce that these prefixes are used 598 by the hosts. 600 4.1.4. ISP Edge PE Router 602 An obvious special case of the discussion is with an ISP PE router, 603 where it provides its customer with access. BCP 38 specifically 604 encourages ISPs to use ingress filtering to limit the incidence of 605 spoofed addresses in the network. 607 The question that the ISP must answer for itself is the degree to 608 which it trusts its downstream network. A contract might be written 609 between an ISP and its customer requiring that the customer apply the 610 procedures of network ingress filtering to the customer's own 611 network, although there's no way upstream networks would be able to 612 validate this. 614 Conversely, if the provider has assigned a single IP address to the 615 customer (for example, with IPv4 NAT in the CPE) PE enforcement of 616 BCP 38 can be on the full address, simplifying many issues. 618 4.1.5. ISP NNI Router to ISP NNI Router 619 The considerations explicitly related to customer networks can also 620 be applied to neighboring ISPs. An interconnection agreement might 621 be written between two companies requiring network ingress filtering 622 policy be implemented on all customers connections. ISPs might, for 623 example, mark datagrams from neighboring ISPs that do not sign such a 624 contract or demonstrably do not behave in accordance with it as 625 'untrusted'. Alternatively, the ISP might place untrusted prefixes 626 into a separate BGP community [RFC4271] and use that to advertise the 627 level of trust to its BGP peers. 629 In this case, uRPF is less effective as a validation tool, due to 630 asymmetric routing. However, when it can be shown that spoofed 631 addresses are present, the procedure can be applied. 633 Part of the complication here is that in the abstract it is very 634 difficult to know what addresses should appear in packets sent from 635 one ISP to another. Hence packet level filtering and enforcement is 636 very difficult at this point in the network. Whether one views this 637 as specific to the NNI, or a general property of the Internet, it is 638 still a major factor that needs to be taken into account. 640 4.1.6. Cable Modem Subscriber Access 642 Cable Modem Termination Systems (CMTS) employ DOCSIS Media Access 643 Control (MAC) domains. These share some properties with general 644 switched networks, as described above in Section 4.1.1, some 645 properties with DSL access networks, as described below in 646 Section 4.1.7. They also often have their own provisioning and 647 monitoring tools which may address some of the issues described here. 649 4.1.7. DSL Subscriber Access 651 While DSL subscriber access can be bridged or routed, as seen by the 652 service provider's device, it is generally the case that the 653 protocols carry enough information to validate which subscriber is 654 sending packets. Thus, for ensuring that one DSL subscriber does not 655 spoof another, enforcement can generally be done at the aggregation 656 router. This is true even when there is a bridged infrastructure 657 among the subscribers, as DSL access generally requires all 658 subscriber traffic to go through the access aggregation router. 660 If it is desirable to provide spoofing protection among the devices 661 within a residence, that would need to be provided by the CPE device, 662 as the ISPs router does not have enough visibility to do that. It is 663 not clear at this time that this problem is seen as a relevant 664 threat. 666 4.2. Currently Available Tools 668 There are a number of tools which have been developed, and have seen 669 some deployment, for addressing these attacks. 671 4.2.1. BCP 38 673 If BCP 38 [RFC2827] is implemented in LAN segments, it is typically 674 done so on subnetwork boundaries and traditionally relates only to 675 Network Layer ingress filtering policies. The result is that hosts 676 within the segment cannot spoof packets from address space outside of 677 the local segment itself, however, they may still spoof packets using 678 sources addresses that exist within the local network segment. 680 4.2.2. Unicast RPF 682 Unicast RPF is a crude mechanism to automate definition of BCP 38 683 style filters based on routing table information. Its applicability 684 parallels that of BCP 38, although deployment caveats exist, as 685 outlined in [RFC3704]. 687 4.2.3. Port-based Address Binding 689 Much of the work of SAVI is initially targeting minimizing source 690 address spoofing in the LAN. In particular, if mechanisms can be 691 defined to accommodate configuration of port binding information for 692 IP, either to a port, to an an unchangeable or authenticated MAC 693 address, or to other credentials in the packet such that an impostor 694 can not create the needed values, a large portion of the spoofing 695 threat space in the LAN can be marginalized. 697 However, establishing this binding is not trivial, and varying across 698 both topologies type and address allocation mechanisms. 700 4.2.3.1. Manual Binding 702 Binding of a single Link Layer and Network Layer address to a port 703 may initially seem trivial. However, two primary areas exist that 704 can complicate such techniques. In particular, these areas involve 705 topologies where more than a single IP layer address may be 706 associated with a MAC address on a given port, or where multiple 707 hosts are connected via a single physical port. Furthermore, if one 708 or more dynamic address allocation mechanisms such as DHCP are 709 employed, then some mechanism must exist to associate those IP layer 710 addresses with the appropriate Link layer ports, as addresses are 711 allocated or reclaimed. 713 4.2.3.2. Automated Binding 715 For IPv4 the primary and very widely used automated address 716 assignment technique is DHCP based address assignment. This can be 717 coupled with filtering policies which control which hosts can 718 originate DHCP replies. Under such circumstances, SAVI switches can 719 treat DHCP replies as authoritative sources of IP Address binding 720 information. By eavesdropping on the DHCP exchanges, the SAVI switch 721 can create the bindings needed for address usage enforcement. 723 For IPv6, there are two common automated address assignment 724 techniques. While there are many variations and details, for 725 purposes of understanding the threats and basic responses, these are 726 Stateless Address Autoconfiguration (SLAAC) and DHCPv6 based address 727 assignment. For DHCP based IPv6 address assignment, the techniques 728 above are applicable and suitable. 730 When SLAAC is used for IPv address assignment, the switches can 731 observe the SLAAC messages and use those to create the enforcement 732 bindings. This enables the switches to ensure that only properly 733 claimed IP addresses are used for data traffic. It does not enforce 734 that these addresses are assigned to the hosts, since SLAAC does not 735 have a notion of address assignment. 737 4.2.3.3. IEEE 802.1x 739 IEEE 802.1x is an authentication protocol that permits a network to 740 determine the identity of a user seeking to join it and apply 741 authorization rules to permit or deny the action. In and of 742 themselves, such tools confirm only that the user is authorized to 743 use the network, but do not enforce what IP address the user is 744 allowed to use. It is worth noting that elements of 802.1x may well 745 be useful as binding anchors for SAVI solutions. 747 4.2.4. Cryptographic Techniques 749 Needless to say, MITM and replay attacks can typically be mitigated 750 with cryptographic techniques. However, many of the applications 751 today either don't or can't employ cryptographic authentication and 752 protection mechanisms. ARP for IPv4 does not use such protection. 753 While SEND provides such protection for IPv6 NDP, SEND is not widely 754 used to date. Usage of such techniques is outside the scope of this 755 document. 757 While DNSSEC will significantly help protect DNS from the effects of 758 spoof based poisoning attacks, such protection does not help protect 759 the rest of the network from spoofed attacks. 761 4.2.5. Residual Attacks 763 It should be understood that not all combinations of network, service 764 and enforcement choices will result in a protectable network. For 765 example, if one uses conventional SLAAC, in a switched network, but 766 tries to only provide address enforcement on the routers on the 767 network, then the ability to provide protection is severely limited. 769 5. Topological Challenges Facing SAVI 771 As noted previously, topological components and address allocation 772 mechanisms have significant implications on what is feasible with 773 regard to Link layer address and IP address port bindings. The 774 following sections discuss some of the various topologies and address 775 allocation mechanisms that proposed SAVI solutions should attempt to 776 address. 778 5.1. Address Provisioning Mechanisms 780 In a strictly static environment, configuration management for access 781 filters that map Link Layer and Network Layer addresses on a specific 782 switch port might be a viable option. However, most networks, 783 certainly those that accommodate actual human users, are much more 784 dynamic in nature. As such, mechanisms that provide port-MAC-IP 785 bindings need to accommodate dynamic address allocation schemes 786 enabled by protocols such as DHCP, DHCPv6 for address allocation, and 787 IPv6 Stateless Address Autoconfiguration. 789 5.2. LAN devices with Multiple Addresses 791 From a topology considerations perspective, when attempting port-MAC- 792 IP bindings, hosts connected to switch ports that may have one or 793 more IP addresses, or certainly, devices that forward packets from 794 other network segments, present traffic that is much harder to make 795 subject to such bindings and enforcement. 797 5.2.1. Routers 799 The most obvious example of devices that are problematic when 800 attempting to implement port-MAC-IP bindings is that of routers. 801 Routers not only originate packets themselves and often have multiple 802 interfaces, but also forward packets from other network segments. As 803 a result, it's difficult for port-MAC-IP binding rules to be 804 established a priori, because it's likely that many addresses and IP 805 subnets should be associated with the port-MAC in question. 807 5.2.2. NATs 808 Validating traffic from Prefix-based and multi-address NATs also 809 becomes problematic, for the same reasons as routers. Because they 810 may forward traffic from an array of address, a priori knowledge must 811 exist providing what IPs should be associated with a given port-MAC 812 pair. 814 5.2.3. Multi-Instance Hosts 816 Another example that introduces complexities is that of multi- 817 instance hosts attached to a switch port. These are single physical 818 devices, which internally run multiple physical or logical hosts. 819 When the device is a blade server, e.g. with internal blades each 820 hosting a physical machine, there is essentially a physical switch 821 inside the blade server. While tractable, this creates some 822 complexity for determining where enforcement logic can or should 823 live. 825 Logically distinct hosts such as are provided by many varieties of 826 virtualization logic result in a single physical host, connect to a 827 single port on the Ethernet switch in the topology, actually having 828 multiple internal virtual machines, each with IP and MAC addresses, 829 and what is essentially (or sometimes literally) an internal LAN 830 switch. While it may be possible for this internal switch to help 831 control threats among the virtual hosts, or between virtual hosts and 832 other parts of the network, such enforcement cannot be counted on at 833 this time. 835 A further complication with multi-instance hosts is that in many 836 environments these hosts may move while retaining their IP addresses. 837 This can be an actual relocation of the running software, or a backup 838 instance taking over the functions of the software. In both cases, 839 the IP address will appear at a new topological location. Depending 840 upon the protocols used, it may have the same MAC address or 841 different one, and the system may or may not issue a gratuitous ARP 842 request after relocation. When such a move is done without changing 843 the MAC address, the SAVI switches will need to update their state. 844 While the ARP may be helpful, traffic detection, switch based 845 neighbor solicitation, interaction with orchestration system, or 846 other means may be used. 848 5.2.4. Multi-LAN Hosts 850 Multi-interface hosts, in particular those that are multi-homed and 851 may forward packets from any of a number of source addresses, can be 852 problematic as well. In particular, if a port-MAC-IP binding is made 853 on each of the interfaces, and then either a loopback IP or the 854 address of third interface is used as the source address of a packet 855 forwarded through an interface for which the port-MAC-IP binding 856 doesn't map, the traffic may be discarded. Static configuration of 857 port-MAC-IP bindings may accommodate this scenario, although some a 858 priori knowledge on address assignment and topology is required. 860 While the use of loopback addressing or sending packets out one 861 interface with the source address from another are rare, they do 862 legitimately occur. Some servers, particularly ones that have 863 underlying virtualization, use loopback techniques for management. 865 5.2.5. Firewalls 867 Firewalls that forward packets from other network segments, or serve 868 as a source for locally originated packets, suffer from the same 869 issues as routers. 871 5.2.6. Mobile IP 873 Mobile IP hosts in both IPv4 and IPv6 are proper members of the site 874 where they are currently located. Their care-of-address is a 875 properly assigned address that is on the link they are using. And 876 their packets are sent and received using that address. Thus, they 877 do not introduce any additional complications. (There was at one 878 time consideration of allowing mobile hosts to use their home address 879 when away from home. This was not done, precisely to ensure that 880 mobile hosts comply with source address validity requirements.) 881 Mobile Hosts with multiple physical interfaces fall into the cases 882 above. 884 Mobile IP home agents are somewhat more interesting. Although they 885 are (typically) fixed devices, they are required to send and receive 886 packets addressed from or to any currently properly registered mobile 887 node. From an analysis point of view, even though the packets that a 888 Home Agent handles are actually addressed to or from the link the HA 889 is on, it is probably best to think of them as routers, with a 890 virtual interface to the actual hosts they are serving. 892 5.2.7. Other Topologies 894 Any topology that results in the possibility that a device connected 895 to a switch port may forward packets with more than a single source 896 address for packet which it originated may be problematic. 897 Additionally, address allocation schemas introduce additional 898 considerations when examining a given SAVI solutions space. 900 5.3. IPv6 Considerations 902 IPv6 introduces additional capabilities which indirectly complicate 903 the spoofing analysis. IPv6 introduces and recommends the use of 904 SLAAC [RFC4862]. This allows hosts to determine their IP prefix, 905 select an IID, and then start communicating. While there are many 906 advantages to this, the absence of control interactions complicates 907 the process of behavioral enforcement. 909 An additional complication is the very large IID space. Again, this 910 64 bit ID space provided by IPv6 has many advantages. It provides 911 the opportunity for many useful behaviors. However, it also means 912 that in the absence of controls, hosts can mint anonymous addresses 913 as often as they like, modulo the idiosyncrasies of the duplicate 914 address procedure. Like many behaviors, this is a feature for some 915 purposes, and a problem for others. For example, without claiming 916 the entire ID space, an on-link attacker may be able to generate 917 enough IP addresses to fill the Neighbor Discovery table space of the 918 other L3 devices on the link, including switches which are monitoring 919 L3 behavior. This could seriously interfere with the ability for 920 other devices on the link to function. 922 6. Analysis of Host Granularity Anti-Spoofing 924 Applying anti-spoofing techniques at the host level enables a site to 925 achieve several valuable objectives. While it is likely the case 926 that for many site topologies and policies, full source spoofing 927 protection is not possible, it is also true that for many sites there 928 are steps that can be taken that provide benefit. 930 One important class of benefit is masquerade prevention. Security 931 threats involving one machine masquerading as another, for example in 932 order to hijack an apparently secure session, can occur within a site 933 with significant impact. Having mechanisms such that host facing 934 devices prevent this is a significant intra-site security 935 improvement. Given that security experts report that most security 936 breaches are internal, this can be valuable. One example of this is 937 that such techniques should mitigate internal attacks on the site 938 routing system. 940 A second class of benefit is related to the traceability described 941 above. When a security incident is detected, either within a site, 942 or externally (and traced to the site) it can be critical to 943 determine what the actual source of the incident was. If address 944 usage can be tied to the kinds of anchors described earlier, then it 945 is possible to respond to security incidents. 947 In addition to these local observable benefits, there can be more 948 global benefits. For example, if address usage is tied to anchors, 949 it may be possible to prevent or control the use of large numbers of 950 anonymous IPv6 addresses for attacks, or at least to track even those 951 attacks back to their source. 953 As described below in the security considerations, these operational 954 behaviors need to be evaluated in the context of the reduction in 955 user privacy implied if one logs traffic bindings. In particular, in 956 addition to the architectural trade offs, the network administrator 957 must plan for the proper handling of this privacy relevant 958 information about his users. 960 7. IANA Considerations 962 This memo asks the IANA for no new parameters. 964 Note to RFC Editor: This section will have served its purpose if it 965 correctly tells IANA that no new assignments or registries are 966 required, or if those assignments or registries are created during 967 the RFC publication process. From the authors' perspective, it may 968 therefore be removed upon publication as an RFC at the RFC Editor's 969 discretion. 971 8. Security Considerations 973 This document provides limited discussion of some security threats 974 source address validation improvements will help to mitigate. It is 975 not meant to be all-inclusive, either from a threat analysis 976 perspective, or from the source address validation application side. 978 It is seductive to think of SAVI solutions as providing the ability 979 to use this technology to trace a datagram to the person, or at least 980 end system, that originated it. For several reasons, the technology 981 can be used to derive circumstantial evidence, but does not actually 982 solve that problem. 984 In the Internet Layer, the source address of a datagram should be the 985 address of the system that originated it and to which any reply is 986 expected to come. But systems fall into several broad categories. 987 Many are single user systems, such as laptops and PDAs. Multi-user 988 systems are commonly used in industry, and a wide variety of 989 middleware systems and application servers have no user at all, but 990 by design relay messages or perform services on behalf of users of 991 other systems (e.g., SMTP and peer-to-peer file sharing). 993 Until every Internet-connected network implements source address 994 validation at the ultimate network ingress, and assurances exist that 995 intermediate devices are to never modify datagram source addresses, 996 source addresses must not be used as an authentication mechanism. 997 The only technique to unquestionably validate source addresses of a 998 received datagram are cryptographic authentication mechanisms such as 999 IPsec. 1001 It must be presume that there will be some failure modes in any SAVI 1002 deployment, given the history of technical security mechanisms. A 1003 possible attack to be considered by network administrators is an 1004 inside attack probing the network for modes of spoofing that can be 1005 accomplished. If the probes are conducted at a level below alarm 1006 thresholds, this might allow an internal attacker to safely determine 1007 what spoof modes he can use. Thus, the use of these techniques must 1008 be managed in such a way as to avoid giving a false sense of security 1009 to the network administrator. 1011 8.1. Privacy Considerations 1013 It should be understood that enforcing and recording IP address 1014 bindings has privacy implications. In general, collecting private 1015 information about users brings ethical and legal responsibilities to 1016 the network administrator. 1018 With operations of the type described here, the network administrator 1019 is collecting information about where on his network the user is 1020 active. In addition, the recorded bindings supplement address usage 1021 information about users that is available from DHCP logs. For 1022 example, if IPv6 SLAAC is being used, ad IP to Layer 2 address 1023 bindings are being logged, the administrator will have access to 1024 information associating users with their IP addresses even if IPv6 1025 privacy addresses are used. 1027 In addition to this, care must be taken in attributing actions to 1028 users on the basis of this sort of information. Whatever the 1029 theoretical strength of the tools, administrators should always allow 1030 for such information being wrong, and should be careful about any 1031 actions taken on the basis of apparent attribution. These techniques 1032 do nothing about address spoofing from other sites, so any evaluation 1033 of attribution also needs to allow for such cases. 1035 9. Acknowledgments 1037 A portion of the primer text in this document came directly from 1038 [I-D.baker-sava-operational], authored by Fred Baker and Ralph Droms. 1039 Many thanks to Christian Vogt, Suresh Bhogavilli, and Pekka Savola 1040 for contributing text and a careful review of this document. 1042 10. References 1043 10.1. Normative References 1045 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1046 1981. 1048 [RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version 1049 6 (IPv6) Specification", RFC 2460, December 1998. 1051 10.2. Informative References 1053 [I-D.baker-sava-operational] 1054 Baker, F. and R. Droms, "IPv4/IPv6 Source Address 1055 Verification", draft-baker-sava-operational-00 (work in 1056 progress), June 2007. 1058 [IEEE802.3ad] 1059 Standards Association, IEEE., "IEEE 801.1AX-2008, IEEE 1060 Standard for Local and Metropolitan Area Networks - Link 1061 Aggregation", 2008. 1063 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 1064 793, September 1981. 1066 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 1067 converting network protocol addresses to 48.bit Ethernet 1068 address for transmission on Ethernet hardware", STD 37, 1069 RFC 826, November 1982. 1071 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1072 Defeating Denial of Service Attacks which employ IP Source 1073 Address Spoofing", BCP 38, RFC 2827, May 2000. 1075 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1076 Networks", BCP 84, RFC 3704, March 2004. 1078 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1079 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1081 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1082 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1083 September 2007. 1085 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1086 Address Autoconfiguration", RFC 4862, September 2007. 1088 Authors' Addresses 1089 Danny McPherson 1090 VeriSign, Inc. 1092 Email: dmcpherson@verisign.com 1094 Fred Baker 1095 Cisco Systems 1097 Email: fred@cisco.com 1099 Joel M. Halpern 1100 Ericsson 1102 Email: joel.halpern@ericsson.com