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