idnits 2.17.1 draft-ietf-savi-threat-scope-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 : ---------------------------------------------------------------------------- ** There are 10 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 250 has weird spacing: '...attacks on th...' -- The document date (January 21, 2009) is 5574 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Danny McPherson 2 Arbor Networks 3 Fred Baker 4 Cisco Systems 5 Expires: July 2009 January 21, 2009 6 Intended Status: Informational 8 SAVI Threat Scope 9 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Copyright Notice 34 Copyright (c) 2009 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. 44 Abstract 46 This memo discusses threats enabled by IP source address spoofing and 47 discusses a number of techniques aimed at mitigating those threats. 49 Table of Contents 51 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 52 2. Glossary of Terms. . . . . . . . . . . . . . . . . . . . . . . 6 53 3. Spoofed-based Attack Vectors . . . . . . . . . . . . . . . . . 6 54 3.1. Blind Attacks . . . . . . . . . . . . . . . . . . . . . . . 7 55 3.1.1. Single Packet DoS. . . . . . . . . . . . . . . . . . . . 7 56 3.1.2. Flood-Based DoS. . . . . . . . . . . . . . . . . . . . . 7 57 3.1.3. Poisoning Attacks. . . . . . . . . . . . . . . . . . . . 8 58 3.1.4. Third Party Recon. . . . . . . . . . . . . . . . . . . . 9 59 3.1.5. Spoof-based Worm/Malware Propagation . . . . . . . . . . 9 60 3.1.6. Reflective Attacks . . . . . . . . . . . . . . . . . . . 9 61 3.1.7. Accounting Subversion. . . . . . . . . . . . . . . . . . 10 62 3.1.8. Other Blind Spoofing Attacks . . . . . . . . . . . . . . 10 63 3.2. Non-Blind Attacks . . . . . . . . . . . . . . . . . . . . . 10 64 3.2.1. Man in the Middle (MITM) . . . . . . . . . . . . . . . . 10 65 3.2.2. Third Party Recon. . . . . . . . . . . . . . . . . . . . 11 66 4. Current Anti-Spoofing Solutions. . . . . . . . . . . . . . . . 11 67 4.1. Host to link layer neighbor or switch . . . . . . . . . . . 13 68 4.2. Upstream routers. . . . . . . . . . . . . . . . . . . . . . 13 69 4.3. ISP Edge PE Router. . . . . . . . . . . . . . . . . . . . . 14 70 4.4. ISP NNI Router to ISP NNI Router. . . . . . . . . . . . . . 14 71 4.5. Spoofing In Local Area Network Segments . . . . . . . . . . 14 72 4.6. Cable Modem Subscriber Access . . . . . . . . . . . . . . . 15 73 4.7. DSL Subscriber Access . . . . . . . . . . . . . . . . . . . 15 74 4.8. BCP 38. . . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 4.9. Unicast RPF . . . . . . . . . . . . . . . . . . . . . . . . 15 76 4.10. Port-based Address Binding . . . . . . . . . . . . . . . . 15 77 4.10.1. Manual Binding. . . . . . . . . . . . . . . . . . . . . 16 78 4.10.2. Automated Binding . . . . . . . . . . . . . . . . . . . 16 79 4.10.3. IEEE 802.1X . . . . . . . . . . . . . . . . . . . . . . 16 80 4.11. Cryptographic Techniques . . . . . . . . . . . . . . . . . 16 81 4.12. Residual Attacks . . . . . . . . . . . . . . . . . . . . . 17 82 5. Topological Considerations . . . . . . . . . . . . . . . . . . 17 83 5.1. Address Provisioning Mechanisms . . . . . . . . . . . . . . 17 84 5.2. LAN devices with Multiple Addresses . . . . . . . . . . . . 17 85 5.2.1. Routers. . . . . . . . . . . . . . . . . . . . . . . . . 18 86 5.2.2. NATs . . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 5.2.3. Multi-Instance Hosts . . . . . . . . . . . . . . . . . . 18 88 5.2.4. Multi-LAN Hosts. . . . . . . . . . . . . . . . . . . . . 18 89 5.2.5. Firewalls. . . . . . . . . . . . . . . . . . . . . . . . 19 90 5.2.6. Mobile IP. . . . . . . . . . . . . . . . . . . . . . . . 19 91 5.2.7. Other Topologies . . . . . . . . . . . . . . . . . . . . 19 92 6. Applicability of Anti-Spoofing Solutions . . . . . . . . . . . 19 93 6.1. Analysis of Host Granularity Anti-Spoofing. . . . . . . . . 19 94 7. Existing Techniques for IP Source Address Valida- 95 tion" 20 771. . . . . . . . . . . . . . . . . . . . . . . . . . . 96 8. Deployment Considerations. . . . . . . . . . . . . . . . . . . 21 97 9. Security Considerations. . . . . . . . . . . . . . . . . . . . 22 98 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 99 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 100 12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 24 101 12.1. Normative References . . . . . . . . . . . . . . . . . . . 24 102 12.2. Informative References . . . . . . . . . . . . . . . . . . 24 103 13. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 25 105 1. Overview 107 The Internet Protocol, specifically IPv4 [RFC791] and IPv6 [RFC2460], 108 employ a connectionless hop-by-hop packet forwarding paradigm. A 109 host connected to an IP network that wishes to communicate with 110 another host on the network generates an IP packet with source and 111 destination IP addressing information, among other options. 113 At the IP Network Layer, or Internet Layer, there is typically no 114 required transactional state when communicating with other hosts on 115 the network. Hosts generating packets for transmission have the 116 opportunity to spoof (forge) the source address of packets which they 117 transmit. 119 Source address verification is necessary in order to detect and 120 reject spoofed packets and contribute to the overall security of IP 121 networks. In particular, source address verification techniques 122 enable detection and rejection of spoofed packets, and also 123 implicitly provide some assurances that the source address in an IP 124 packet is legitimately assigned to the system that generated the 125 packet. 127 Solutions such as BCP 38 [RFC2827] provide guidelines for one such 128 technique for network ingress filtering. However, if these 129 techniques are not implemented on 32-bit prefix boundaries at the 130 ultimate ingress point of the IP network then the validity of the 131 source address can not be positively ascertained. Furthermore, BCP 132 38 only implies source address verification at the Internet Layer, 133 and is most often implemented on IP subnetwork address boundaries. 135 There is a possibility that in an LAN environment where multiple 136 hosts share a single IP port on a switch or router, one of those 137 hosts may source address spoof the source addresses of other hosts 138 within the local subnet. Understanding these threats and the 139 relevant topologies in which they're introduced is critical when 140 assessing the threats that exists with source address spoofing. 142 The aim of this document is to provide some additional details 143 regarding spoofed-based threat vectors, and discuss implications of 144 various network topologies. 146 2. Glossary of Terms 148 The following acronyms and terms are used throughout this memo. 150 BGP: The Border Gateway Protocol, used to manage routing policy 151 between large networks. 153 CPE Router: Customer Premises Equipment Router. The router on the 154 customer premises, whether owned by the customer or the provider. 155 Also called the Customer Endpoint, or CE, Router. 157 IP Address: An Internet Protocol Address, whether IPv4 or IPv6. 159 ISP: Internet Service Provider. Any person or company that delivers 160 Internet service to another. 162 MAC Address: An Ethernet Address. 164 NNI Router: Network to Network Interface Router. This router 165 interface faces a similar system operated by another ISP or other 166 large network. 168 PE Router: Provider Endpoint Router. This router faces a customer 169 of an ISP. 171 Spoofing: The act of forging datagram header contents at the Link 172 or Network Layer 174 TCP: The Transmission Control Protocol, used on end systems to 175 manage data exchange. 177 uRPF: Unicast Reverse Path Forwarding. A procedure in which the 178 route table, which is usually used to look up destination 179 addresses and route towards them, is used to look up the source 180 address and ensure that one is routing away from it. When this 181 test fails, the event may be logged, and the traffic is commonly 182 dropped. 184 3. Spoofed-based Attack Vectors 186 Spoofing is employed on the Internet for a number of reasons, most of 187 which are in some manner associated with malicious or otherwise 188 nefarious activities. In general, two classes of spoofed-based 189 attack vectors exists; blind attacks and non-blind attacks. The 190 follow sections provide some information of blind and non-blind 191 attacks. 193 3.1. Blind Attacks 195 Blind attacks typically occur when an attacker isn't on the same 196 local area network as a source or target, or when an attacker has no 197 access to the datapath between the attack source(s) and the target 198 systems. The result is that they have no access to legitimate source 199 and target systems. 201 3.1.1. Single Packet DoS 203 One type of blind attacks, which we'll refer to here as "single 204 packet DoS attacks", involves an attacking system injecting spoofed 205 information into the network which results in either a complete crash 206 of the target system, or in some manner poisons some network 207 configuration or other information on a target system such to impact 208 network or other services. 210 An example of an attack that can cause a receiving system to crash is 211 a LAND attack. A LAND attack packet would consist of an attacking 212 system forwarding a packet (e.g., TCP SYN) to a target system that 213 contains both a source and destination address of that target system. 214 The target system would "lock up" when creating connection state 215 associated with the packet, or would get stuck in a state where it 216 continuously replies to itself. 218 Another example of a single packet DoS attack involves that of a 219 system poisoning network or DNS cache information, perhaps in order 220 to simply break a given hosts connection, enable MITM or other 221 attacks. Network level attacks that could involve single packet DoS 222 include ARP cache poisoning and ICMP redirects. 224 3.1.2. Flood-Based DoS 226 Flooding-based DoS attack vectors are particularly effective attacks 227 on the Internet today. They usually entail flooding a large number 228 of packets towards a target system, with the hopes of either 229 exhausting connection state on the target system, consuming all 230 packet processing capabilities of the target or intermediate systems, 231 or consuming a great deal of bandwidth available to the target system 232 such that they are essentially inaccessible. 234 Because these attacks require no reply from the target system and 235 require no legitimate transaction state, attackers often attempt to 236 obfuscate the identity of the systems that are generating the attack 237 traffic by spoofing the source IP address of the attacking traffic 238 flows. Because ingress filtering isn't applied ubiquitously on the 239 Internet today, spoof-based flooding attack vectors are typically 240 very difficult to traceback. In particular, there may be one or more 241 attacking sources beyond your network border, and the attacking 242 sources may or may not be legitimate sources, it's difficult to 243 discriminate if the sources are not directly connected to the local 244 routing system. 246 Common flood-based DoS attack vectors today include SYN floods, ICMP 247 floods, and IP fragmentation attacks. Attackers may use a single 248 legitimate or spoofed fixed attacking source addresses, although 249 frequently they cycle through large swaths of address space. As a 250 result, mitigating these attacks on the receiving end with source- 251 based policies is extremely difficult. 253 Furthermore, the motivator for spoof-based DoS attacks may actually 254 be to encourage the target to filter explicitly on a given set of 255 source addresses, or order to disrupt the legitimate owner(s) access 256 to the target system. 258 3.1.3. Poisoning Attacks 260 As discussed in single-packet DoS above, there are several other 261 attack mechanisms that employ source address spoofing. The more 262 common of these attack vectors include DNS cache poisoning, ARP cache 263 poisoning, and ICMP redirects. While these attacks can be used for 264 disrupting services, they're often used to redirect traffic to 265 network elements where attack intends to carry out additional 266 malicious activities. 268 3.1.4. Third Party Recon 270 Third party reconnaissance attacks may be either blind or non-blind 271 attacks. An example of third party reconnaissance is when an 272 attacker wishes to fingerprint a remote operating system type, 273 perhaps in order to initiate some TCP session hijacking, and in order 274 to do so must be able to identify the TCP sequence and algorithm 275 employed by the target system. Initiating a determined number of 276 connections with the target system may assist with this. 278 3.1.5. Spoof-based Worm/Malware Propagation 280 Self-propagating malware has been observed that spoofs it's source 281 address when attempting to propagate to other systems. Presumably, 282 this was done to obfuscate the actual source address of the infected 283 system. 285 3.1.6. Reflective Attacks 287 DNS reflective amplification attacks are a particularly potent DoS 288 attack vector on the Internet today. Like other amplification 289 attacks, an attack source generates a packet with a source-spoofed 290 address mapping to that of the target system. The packet, upon 291 receipt by the victim or some intermediate node, typically illicts a 292 large reply message, which is directed to the target of the attack. 293 The amplification factor observed for attacks targeting DNS root and 294 other top level domain name infrastructure in early 2006 was on the 295 order of 76:1. The result is that just 15 attacking sources with 296 512k of upstream attack bandwidth could generate one Gbps of response 297 attack traffic towards a target system. 299 Smurf attacks employ a similar reflective amplification attack 300 vector, exploiting traditional default IP subnet directed broadcast 301 address behaviors that would result in all the active hosts on a 302 given subnet responding to (spoofed) ICMP echo request from an 303 attacker, and generating a large amount of ICMP echo response traffic 304 directed towards a target system. They were particularly effective 305 in large campus LAN environments where 50k or more hosts might reside 306 on a single subnet. 308 3.1.7. Accounting Subversion 310 If an attacker wishes to distribute content or other material in a 311 manner that employs protocols that require only uni-directional 312 flooding and generate no end-end transactional state, they may desire 313 to spoof the source IP address of that content in order to avoid 314 detection or accounting functions enabled at the IP layer. 316 3.1.8. Other Blind Spoofing Attacks 318 Other Blind spoofing attacks might include spoofing in order to 319 exploit source routing or other policy based routing implemented in a 320 network. 322 3.2. Non-Blind Attacks 324 Non-blind attacks often involve mechansisms such as eavesdropping on 325 connection, resetting state so that new connections may be hijacking, 326 and an array of other attack vectors. Perhaps the most common of 327 these attack vectors is known as man in the middle attacks. 329 3.2.1. Man in the Middle (MITM) 331 Connection Hijacking is one of the more common man in the middle 332 attack vectors. In order to hijack a connection an attacker usually 333 needs to be in the forwarding path and often times employs TCP RST or 334 other attacks in order to reset a transaction. The attacker may have 335 already compromised a system that's in the forwarding path, or they 336 may which to insert themselves in the forwarding path. 338 For example, an attacker with access to a host on LAN segment may 339 wish to redirect all the traffic on the local segment destined for a 340 default gateway address (or all addresses) to itself in order to 341 perform man-in-the-middle attacks. In order to accomplish this the 342 attacker might transmit gratuitous ARP [RFC826] messages or ARP 343 replies to the Ethernet broadcast address ff:ff:ff:ff:ff:ff, 344 notifying all the hosts on the segment that the IP address(es) of the 345 target(s) now map to it's own MAC address. If the port to which the 346 attacker is connected were to implement policy that binds a single 347 Link Layer and IP address tuple to that port upon initial 348 provisioning, spoofed packets, at the Link Layer and/or Network 349 Layer, would be discarded on ingress. 351 3.2.2. Third Party Recon 353 Another example of third party reconnaissance that falls into both 354 the blind and non-blind attack class involves spoofing packets 355 towards a given target system and observing either target or 356 intermediate system responses. For example, if an attacker were to 357 source spoof TCP SYN packets towards a target system from a large set 358 of source addresses, and observe responses from that target system or 359 some intermediate firewall or other middle box, they would be able to 360 identify what IP layer filtering policies may be in place to protect 361 that system. 363 4. Current Anti-Spoofing Solutions 365 The first requirement is to eliminate datagrams with spoofed 366 addresses from the Internet. Identifying and dropping datagrams 367 whose source address is incompatible with the Internet topology at 368 sites where the relationship between the source address and topology 369 can be checked can eliminate such datagrams. For example, Internet 370 devices can confirm that: 372 o The IP source address is appropriate for the lower layer address 373 (they both identify the same system) 375 o The IP source address is appropriate for the device at the layer 2 376 switch port (the address was assigned to a, and perhaps the, 377 system that uses that port) 379 o The prefix to which the IP source address belongs is appropriate 380 for the part of the network topology from which the IP datagram 381 was received (while the individual system may be unknown, it is 382 reasonable to believe that the system is located in that part of 383 the network). 385 Filtering points farther away from the source of the datagram can 386 make decreasingly authoritative assertions about the validity of the 387 source address in the datagram. Nonetheless, there is value in 388 dropping traffic that is clearly inappropriate, and in maintaining 389 knowledge of the level of trust one can place in an address. 391 Edge Network 1 CPE-ISP _.------------. 392 _.----------------. Ingress/ ISP A `--. 393 ,--'' `---. ,' `. 394 ,' +----+ +------+ +------+ `. / +------+ +------+ \ 395 ( |Host+--+Switch+--+ CPE +---)-(---+ PE +- - - -+ NNI | ) 396 `. +----+ +------+ |Router| ,' \ |Router| |Router| / 397 `---. Host-neighbor +------+' `.+------+ +--+---+,' 398 `----------------'' '--. |_.-' 399 `------------'| 400 | 401 Edge Network 2 ISP-ISP Ingress | 402 _.----------------. _.----------.| 403 ,--'' `---. ,-'' |--. 404 ,' +----+ +------+ +------+ `. ,+------+ +--+---+. 405 ( |Host+--+Switch+--+ CPE +---)---+-+ PE +- - - -+ NNI | \ 406 `. +----+ +------+ |Router| ,' ( |Router| |Router| ) 407 `---. +------+' \ +------+ +------+ / 408 `----------------'' `. ,' 409 '--. ISP B _.-' 410 `----------'' 412 Figure 1: Points where an address can be validated 414 Figure 1 illustrates five places where a source address can be 415 validated: 417 o Host to host or host to switch, 419 o Host to enterprise CPE Router, 421 o Enterprise CPE Router to ISP edge PE Router, 423 o ISP NNI Router to ISP NNI Router, and the 425 o ISP edge PE Router facing the destination CPE Router. 427 In general, datagrams with spoofed addresses can be detected and 428 discarded by devices that have an authoritative mapping between IP 429 addresses and the network topology. For example, a device that has 430 an authoritative table between Link Layer and IP addresses on a link 431 can discard any datagrams in which the IP address is not associated 432 with the Link Layer address in the datagram. The degree of 433 confidence in the source address depends on where the spoofing 434 detection is performed and the prefix aggregation in place between 435 the spoofing detection and the source of the datagram. 437 4.1. Host to link layer neighbor or switch 439 The first point at which a datagram with a spoofed address can be 440 detected is on the link to which the source of the datagram is 441 connected. At this point in the network, the source Link Layer and 442 IP addresses are both available, and can be verified against each 443 other. A datagram in which the IP source address does not match the 444 corresponding Link Layer address can be discarded. Of course, the 445 trust in the filtering depends on the trust in the method through 446 which the mappings are developed. This mechanism can be applied by 447 neighboring hosts, or by the first hop router. 449 On a shared medium link, such as Ethernet, the best that can be done 450 is to verify the Link Layer and IP addresses against the mappings. 451 When the link is not shared, such as when the hosts are connected 452 through a switch, the source host can be identified precisely based 453 on the port through which the datagram is received or the MAC address 454 if it is known to the switch. Port identification prevents 455 transmission of malicious datagrams whose Link Layer and IP addresses 456 are both spoofed to mimic another host. 458 4.2. Upstream routers 460 Beyond the first hop router, subsequent routers may additionally 461 filter traffic from downstream networks. Because these routers do 462 not have access to the Link Layer address of the device from which 463 the datagram was sent, they are limited to confirming that the source 464 IP address is within a prefix that is appropriate for downstream 465 router from which the datagram was received. 467 Options include the use of simple access lists or the use of unicast 468 reverse path filtering (uRPF). Access lists are generally 469 appropriate only for the simplest cases, as management can be 470 difficult. Strict Unicast RPF accepts the source address on a 471 datagram if and only if it comes from a direction that would be 472 rational to send a datagram directed to the address, which means that 473 the filter is derived from routing information. These filtering 474 procedures are discussed in more detail in [RFC3704]. 476 4.3. ISP Edge PE Router 478 An obvious special case of the discussion is with an ISP PE router, 479 where it provides its customer with access. BCP 38 specifically 480 encourages ISPs to use ingress filtering to limit the incidence of 481 spoofed addresses in the network. 483 The question that the ISP must answer for itself is the degree to 484 which it trusts its downstream network. A contract might be written 485 between an ISP and its customer requiring that the customer apply the 486 procedures of network ingress filtering to the customer's own 487 network, although there's no way upstream networks would be able to 488 verify this. 490 4.4. ISP NNI Router to ISP NNI Router 492 The considerations explicitly related to customer networks can also 493 be applied to neighboring ISPs. An interconnection agreement might 494 be written between two companies requiring network ingress filtering 495 policy be implemented on all customers connections. ISPs might, for 496 example, mark datagrams from neighboring ISPs that do not sign such a 497 contract or demonstrably do not behave in accordance with it as 498 'untrusted'. Alternatively, the ISP might place untrusted prefixes 499 into a separate BGP community and use that to advertise the level of 500 trust to its BGP peers. 502 In this case, uRPF is less effective as a verification tool, due to 503 asymmetric routing. However, when it can be shown that spoofed 504 addresses are present, the procedure can be applied. 506 4.5. Spoofing In Local Area Network Segments 508 On Link Layer segments where multiple hosts reside, or a single MAC 509 address can be associated with a port or interface, if a binding 510 between a hardware address (e.g., MAC address) and corresponding IP 511 address(es) are not provisioned via some means (either manual or 512 dynamic mechanisms), then an attacker may exploit attack vectors that 513 enable MITM or other spoof-based attacks. 515 4.6. Cable Modem Subscriber Access 517 Cable Modem Termination Systems (CMTS) employ DOCSIS Media Access 518 Control (MAC) domains, which are similar to Ethernet LAN 519 environments. 521 4.7. DSL Subscriber Access 523 Something about DSLAMs here.. 525 4.8. BCP 38 527 If BCP 38 is implemented in LAN segments, it is typically done so on 528 subnetwork boundaries and traditionally relates only to Network Layer 529 ingress filtering policies. The result is that hosts within the 530 segment cannot spoof packets from address space outside of the local 531 segment itself, however, they may still spoof packets using sources 532 addresses that exist within the local network segment. 534 4.9. Unicast RPF 536 Unicast RPF is a crude mechanism to automate definition of BCP 38 537 style filters based on routing table information. It's applicability 538 parallels that of BCP 38, although deployment caveats exists, as 539 outlined in [RFC3704]. 541 4.10. Port-based Address Binding 543 Much of the work SAVI appears to be initially targeting is aimed at 544 minimizing source address spoofing in the LAN. In particular, if 545 mechanisms can be defined to accommodate configuration of port 546 binding information for IP and MAC layer addresses in LAN 547 environments, a large portion of the spoofing threat space in the LAN 548 can be marginalized. 550 However, establishing these binding is not trivial, and varying 551 across both topologies type and address allocation mechanisms. 553 4.10.1. Manual Binding 555 Binding of a single Link Layer and Network Layer address to a port 556 may initially seem trivial. However, two primary areas exist that 557 can complicate such techniques. In particular, these area involves 558 topologies where more than a single IP layer address may be 559 associated with a MAC address on a given port, or where multiple 560 hosts are connected to a single IP port. Furthermore, if one or more 561 dynamic address allocation mechanisms such as DHCP are employed, then 562 some mechanism must exist to associate those IP layer addresses with 563 the appropriate Link layer ports, as addresses are allocated or 564 reclaimed. 566 4.10.2. Automated Binding 568 DHCP, RADIUS, Other solutions, Cisco IP Source Guard, etc.. 570 4.10.3. IEEE 802.1X 572 4.11. Cryptographic Techniques 574 Needless to say, MITM and replay attacks can typically be mitigated 575 with cryptographic techniques. However, many of the applications 576 today either don't or can't employ cryptographic authentication and 577 protection mechanisms. ARP and DNS are two examples. DNSSEC does 578 propose to assist, but until it's deployed ubiquitously, from 579 clients, to resolvers, to authoritative roots, clients and resolvers 580 are still vulnerable to replay, cache poisoning and MITM attacks. 582 4.12. Residual Attacks 584 Stuff which these solutions don't address 586 Stuff which no one will use the existing solutions for 588 5. Topological Considerations 590 As noted previously, topological components and address allocation 591 mechanisms have significant implications on what is feasible with 592 regard to Link layer address and IP address port bindings. The 593 following sections discuss some of the various topologies and address 594 allocation mechanisms that proposed SAVI solutions should attempt to 595 address. 597 5.1. Address Provisioning Mechanisms 599 In a strictly static environment configuration management for access 600 filters that map Link Layer and Network Layer addresses on a specific 601 switch port might be a viable option. However, most networks, 602 certainly, those that accommodate actual human users, are much more 603 dynamic in nature. As such, mechanisms that provide port-MAC-IP 604 bindings need to accommodate dynamic address allocation schemes 605 enabled by protocols such as DHCP. 607 5.2. LAN devices with Multiple Addresses 609 From a topology considerations perspective, when attempting port-MAC- 610 IP bindings, host connected to switch ports that may have one or more 611 IP addresses, or certainly, devices that forward packets from other 612 network segments, are problematic. 614 5.2.1. Routers 616 The most obvious example of devices that are problematic when 617 attempting to implement port-MAC-IP bindings is that of routers. 618 Routers not only originate packets themselves and often have multiple 619 interfaces, but also forward packets from other network segments. As 620 a result, it's difficult for port-MAC-IP binding rules to be 621 established a priori, because it's likely that many addresses and IP 622 subnets should be associated with the port-MAC in question. 624 5.2.2. NATs 626 Prefix-based and multi-address NATs also become problematic, for the 627 same reasons as routers. Because they may forward traffic from an 628 array of address, a priori knowledge must exist providing what IPs 629 should be associated with a given port-MAC pair. 631 5.2.3. Multi-Instance Hosts 633 Another example that introduces complexities is that of multi- 634 instance hosts attached to a switch port. Multi clients, with the 635 same or different MACs, may be attached to the port and may either 636 have static IP addresses assigned, or may receive one or more 637 dynamically via DHCP or similar means. Accommodating multi-instance 638 hosts, or even blade-server type devices dynamic is feasible, buy may 639 introduces complexities if the solution in question does not 640 accommodate unique considerations introduced in these environments. 642 5.2.4. Multi-LAN Hosts 644 Multi-interface hosts, in particular those that are multi-homed and 645 may forward packets from any of a number of source addresses, can be 646 problematic as well. In particular, if a port-MAC-IP binding is made 647 on each of the interfaces, and then either a loopback IP or the 648 address of third interface is used as the source address of a packet 649 and forward through in interface for which the port-MAC-IP binding 650 doesn't map, the traffic may be discarded. Static configuration of 651 port-MAC-IP bindings may accommodate this scenario, although some a 652 priori knowledge on address assignment and topology is required. 654 5.2.5. Firewalls 656 Firewalls that forward packets from other network segments, or serve 657 as a source for locally originated packets, suffer from the same 658 issues as routers. 660 5.2.6. Mobile IP 662 Need to say something here, I think... Mobile IP 664 5.2.7. Other Topologies 666 Any topology that results in the possibility that a device connected 667 to a switch port may forward packets with more than a single source 668 address for packet which it originated may be problematic. 669 Additionally, address allocation schemas introduce additional 670 considerations when examining a given SAVI solutions space. 672 6. Applicability of Anti-Spoofing Solutions 674 What works where, what's needed? 676 Ingress filtering is useful, even with botnets using real addresses 678 Ingress filtering on the admin border is not sufficient, and more 679 fine-grained filtering from savi is necessary. 681 6.1. Analysis of Host Granularity Anti-Spoofing 683 Most IP spoofing validation can be provided with standard IP-based 684 policies such as those defined in BCP 38. However, at the ultimate 685 network ingress, the ability to perform a binding for port-MAC-IP 686 provides considerable benefits over vanilla prefix-based source 687 address validation. While it is true that a large array of 688 topologies and address allocation schemas will introduce complexities 689 with automation of port-MAC-IP binding specifications, application of 690 source address validation for static and common dynamic addressed 691 allocation environments (e.g., DHCP) would significantly raise the 692 bar for effectively launching spoof-based attacks. 694 7. Existing Techniques for IP Source Address Validation" 696 Existing techniques for IP source address validation are insufficient 697 for at least some of the following reasons: 699 o False negatives: Techniques may yield false negatives, 700 thus enabling an attacker to select an IP source address 701 that is spoofed, but still passes IP source address 702 validation. 704 o False positives: Techniques may yield false positives, 705 thereby causing interruption or denial of service to hosts 706 that use legitimate IP source addresses. 708 o Non-trivial configuration: Requirements for non-trivial 709 configuration imply expenditures and pose a risk for 710 misconfiguration, which may again lead to false positives 711 or false negatives. Both may discourage operators from 712 employing a given technique. 714 o Proprietary: Procurement policies oftentimes require 715 techniques that are standardized, hence hindering or 716 preventing the deployment of proprietary techniques. 718 The only standardized technique for IP source address validation is 719 ingress filtering [RFC2827]. This calls for routers to check whether 720 the prefix of a to-be-forwarded packet's IP source address is amongst 721 a list of prefixes considered legitimate for the interface through 722 which the packet arrives. Packets that fail this check are 723 discarded. 725 Ingress filtering may yield false negatives in a deterministic 726 manner. Packets with a legitimate IP source address prefix, but a 727 spoofed interface identifier, pass ingress filtering checks. Also, 728 packets with an illegitimate IP source address prefix pass the checks 729 as long as the prefix is from the list of prefixes considered 730 legitimate, if more than one prefix is considered as legitimate on 731 the ingress interface.. 733 Ingress filtering implementations that require manual establishment 734 of the list of legitimate prefixes cause considerable configuration 735 overhead. Unicast Reverse Path Forwarding (uRPF) mitigates this 736 issue by automatically deriving the list of legitimate prefixes from 737 a router's forwarding table: A to-be-forwarded packet's IP source 738 address prefix is considered legitimate if the packet is coming 739 through an interface via which return traffic would be routed. On 740 the other hand, Unicast Reverse Path Forwarding may yield false 741 positives, in particular for hosts and networks with multiple, 742 topologically separate Internet attachments [RFC3704]. 744 Consequently, there is a need for an IP source address validation 745 technique that avoids false negatives and false positives, that can 746 be set up with no or only trivial configuration, and that has been 747 standardized. The development of such a technique is the goal of the 748 proposed Source Address Validation Improvements (SAVI) working group 749 in the Internet Engineering Task Force. 751 8. Deployment Considerations 753 From a global Internet perspective, deployment of anti- spoofing 754 techniques tends to suffer from a "tragedy of the commons" situation. 755 That is, there is a general consensus that everyone should implement 756 anti-spoofing measures, yet individual organizations don't want to 757 bear the cost of deployment themselves, often because demonstrating 758 direct tangible return on investment is not possible. Upon analysis, 759 it often seems apparent that local implementation of anti-spoofing 760 measures is of more benefit to the "greater Internet" than the local 761 network domain itself. A similar situation occurs with de- 762 aggregation of Internet routing information for multi-homing and 763 traffic engineering purposes, as well as the lack of explicit inter- 764 domain routing prefix filters on the Internet. 766 Until network operators begin to accept that their local design 767 choices have global implications, and act upon this responsibility, 768 the problem is not going to go away. 770 Ideally, with additional work in the areas of SAVI to ease deployment 771 and management burdens, the deployment cost to operators will 772 decrease and more wide-scale deployment will continue. Furthermore, 773 application of SAVI-like techniques provides more obvious benefits to 774 network administrators that are concerned with MITM and similar 775 attacks. 777 9. Security Considerations 779 This document provides limited discussion of some security threats 780 source address validation improvements will help to mitigate. It is 781 not meant to be all-inclusive, either from a threat analysis 782 perspective, or from the source address verification application 783 side. 785 It is seductive to think of SAVI solutions as providing the ability 786 to use this technology to trace a datagram to the person, or at least 787 end system, that originated it. For several reasons, the technology 788 can be used to derive circumstantial evidence, but does not actually 789 solve that problem. 791 In the Internet Layer, the source address of a datagram should be the 792 address of the system that originated it and to which any reply is 793 expected to come. But systems fall into several broad categories. 794 Many are single user systems, such as laptops and PDAs. Multi-user 795 systems are commonly used in industry, and a wide variety of 796 middleware systems and application servers have no user at all, but 797 by design relay messages or perform services on behalf of users of 798 other systems (e.g., SMTP and peer-to-peer file sharing). 800 Until every Internet-connected network implements source address 801 validation at the ultimate network ingress, and assurances exist that 802 intermediate devices are to never modify datagram source addresses, 803 source addresses must not be used as an authentication mechanism. 804 The only technique to unquestionably verify source addresses of a 805 received datagram are cryptographic authentication mechanisms such as 806 IPSEC. 808 10. IANA Considerations 810 This document introduces no IANA considerations. 812 11. Acknowledgments 814 A portion of the primer text in this document came directly from 815 [savi-operational], authored by Fred Back and Ralph Droms. Many 816 thanks to Christian Vogt for contributing text and a careful review 817 of this document. 819 12. References 821 12.1. Normative References 823 12.2. Informative References 825 http://tools.ietf.org/html/draft-baker-sava-cisco-ip-source-guard 826 "Cisco IP Version 4 Source Guard", Fred Baker, 7-Nov-07, 827 829 http://tools.ietf.org/html/draft-baker-sava-implementation 830 "Source address validation in the local environment", Fred Baker, 831 8-Nov-07, 832 834 http://tools.ietf.org/html/draft-baker-sava-operational 835 "IPv4/IPv6 Source Address Verification", Fred Baker, Ralph Droms, 836 19-Jun-07, 837 839 http://tools.ietf.org/html/draft-baker-6man-multiprefix-default-route 840 "Multiprefix IPv6 Routing for Ingress Filters", Fred Baker, 841 7-Nov-07, 842 844 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, 845 September 1981. 847 [RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or 848 converting network protocol addresses to 48.bit Ethernet 849 address for transmission on Ethernet hardware", STD 37, 850 RFC 826, November 1982. 852 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 853 (IPv6) Specification", RFC 2460, December 1998. 855 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 856 Defeating Denial of Service Attacks which employ IP Source 857 Address Spoofing", BCP 38, RFC 2827, May 2000. 859 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 860 Networks", BCP 84, RFC 3704, March 2004. 862 13. Authors' Addresses 864 Danny McPherson 865 Arbor Networks, Inc. 866 Email: danny@arbor.net 868 Fred Baker 869 Cisco Systems 870 Email: fred@cisco.com 872 Acknowledgment 874 Funding for the RFC Editor function is provided by the IETF 875 Administrative Support Activity (IASA).