idnits 2.17.1 draft-nikander-mobileip-v6-ro-sec-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 167 has weird spacing: '...oposals take ...' == Line 292 has weird spacing: '...d route optim...' == Line 689 has weird spacing: '... return routa...' == Line 998 has weird spacing: '... Low lifet...' == Line 1003 has weird spacing: '... Low heuri...' == (3 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 1, 2003) is 7452 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'ND01' on line 605 -- Looks like a reference, but probably isn't: 'Sav02' on line 929 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group P. Nikander 2 Internet-Draft J. Arkko 3 Expires: May 31, 2004 Ericsson Research Nomadic Lab 4 T. Aura 5 Microsoft Research 6 G. Montenegro 7 E. Nordmark 8 Sun Microsystems 9 December 1, 2003 11 Mobile IP version 6 Route Optimization Security Design Background 12 draft-nikander-mobileip-v6-ro-sec-02 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at http:// 29 www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 31, 2004. 36 Copyright Notice 38 Copyright (C) The Internet Society (2003). All Rights Reserved. 40 Abstract 42 This document is a succint account of the rationale behind the Mobile 43 IPv6 (MIPv6) Route Optimization Security Design. The purpose of this 44 document is to present the thinking and to preserve the reasoning 45 behind the Mobile IPv6 Security Design in 2001-2002. 47 The document has two target audiences: (1) MIPv6 implementors so that 48 they can better understand the design choices in MIPv6 security 49 procedures; and (2) people dealing with mobility or multi-homing so 50 that they can avoid a number of potential security pitfalls in their 51 design. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.1 Assumptions about the Existing IP Infrastructure . . . . . . 5 57 1.1.1 A note on source addresses and ingress filtering . . . . . . 6 58 1.2 The Mobility Problem and the Mobile IPv6 Solution . . . . . 6 59 1.3 Design Principles and Goals . . . . . . . . . . . . . . . . 8 60 1.3.1 End-to-end principle . . . . . . . . . . . . . . . . . . . . 8 61 1.3.2 Trust assumptions . . . . . . . . . . . . . . . . . . . . . 9 62 1.3.3 Protection level . . . . . . . . . . . . . . . . . . . . . . 9 63 1.4 About Mobile IPv6 Mobility and its Variations . . . . . . . 9 64 2. Dimensions of Danger . . . . . . . . . . . . . . . . . . . . 11 65 2.1 Target . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 2.2 Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 2.3 Location . . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 3. Threats and limitations . . . . . . . . . . . . . . . . . . 13 69 3.1 Attacks against address 'owners' aka. address 'stealing' . . 13 70 3.1.1 Basic address stealing . . . . . . . . . . . . . . . . . . . 14 71 3.1.2 Stealing addresses of stationary nodes . . . . . . . . . . . 14 72 3.1.3 Future address stealing . . . . . . . . . . . . . . . . . . 15 73 3.1.4 Attacks against Secrecy and Integrity . . . . . . . . . . . 16 74 3.1.5 Basic Denial of Service Attacks . . . . . . . . . . . . . . 17 75 3.1.6 Replaying and Blocking Binding Updates . . . . . . . . . . . 17 76 3.2 Attacks against other nodes and networks (flooding) . . . . 17 77 3.2.1 Basic flooding . . . . . . . . . . . . . . . . . . . . . . . 18 78 3.2.2 Return-to-home flooding . . . . . . . . . . . . . . . . . . 19 79 3.3 Attacks against binding update protocols . . . . . . . . . . 19 80 3.3.1 Inducing Unnecessary Binding Updates . . . . . . . . . . . . 20 81 3.3.2 Forcing Non-Optimized Routing . . . . . . . . . . . . . . . 21 82 3.3.3 Reflection and Amplification . . . . . . . . . . . . . . . . 22 83 3.4 Classification of attacks . . . . . . . . . . . . . . . . . 23 84 3.5 Problems with infrastructure based authorization . . . . . . 23 85 4. The solution selected for Mobile IPv6 . . . . . . . . . . . 26 86 4.1 Return Routability . . . . . . . . . . . . . . . . . . . . . 26 87 4.1.1 Home Address check . . . . . . . . . . . . . . . . . . . . . 28 88 4.1.2 Care-of-Address check . . . . . . . . . . . . . . . . . . . 29 89 4.1.3 Forming the first Binding Update . . . . . . . . . . . . . . 29 90 4.2 Creating state safely . . . . . . . . . . . . . . . . . . . 29 91 4.2.1 Retransmissions and state machine . . . . . . . . . . . . . 31 92 4.3 Quick expiration of the Binding Cache Entries . . . . . . . 31 93 5. Security considerations . . . . . . . . . . . . . . . . . . 33 94 5.1 Residual Threats as Compared to IPv4 . . . . . . . . . . . . 33 95 5.2 Interaction with IPsec . . . . . . . . . . . . . . . . . . . 34 96 5.3 Pretending to be your neighbor . . . . . . . . . . . . . . . 34 97 5.4 Two mobile nodes talking to each other . . . . . . . . . . . 35 98 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 36 99 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 100 References (informative) . . . . . . . . . . . . . . . . . . 38 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 38 102 Intellectual Property and Copyright Statements . . . . . . . 40 104 1. Introduction 106 Mobile IPv4 is based on the idea of supporting mobility on top of 107 existing IP infrastructure, without requiring any modifications to 108 the routers, the applications, or the stationary end hosts. However, 109 in Mobile IPv6 [7] (as opposed to Mobile IPv4) the stationary end 110 hosts may provide support for mobility, i.e., route optimization. In 111 route optimization a correspondent node (CN), i.e., a peer for a 112 mobile node, learns a binding between the mobile node's stationary 113 home address and its current temporary care-of-address. This binding 114 is then used to modify the handling of outgoing (as well as the 115 processing of incoming) packets, leading to security risks. The 116 purpose of this document is the provide a relatively compact source 117 of the background assumptions, design choices, and other information 118 needed to understand the route optimization security design. This 119 document does not seek to compare the relative security of Mobile 120 IPv6 and other mobility protocols, or to list all the alternative 121 security mechanisms that were discussed during the Mobile IPv6 design 122 process. For a summary of the latter, we refer the reader to [1]. 123 The goal of this document is to explain the design choices and 124 rationale behind the current route optimization design. The authors 125 participated in the design team which produced the design, and hope, 126 via this note, to capture some of the lessons and reasoning behind 127 that effort. 129 To fully understand the security implications of the relevant design 130 constraints it is necessary to briefly explore the nature of the 131 existing IP infrastructure, the problems Mobile IP aims to solve, and 132 the design principles applied. In the light of this background, we 133 can then explore IP based mobility in more detail, and have a brief 134 look at the security problems. The background is given in the rest of 135 this section, starting from Section 1.1. 137 While the introduction in Section 1.1 may appear redundant to those 138 readers who are already familiar with Mobile IPv6, it may be valuable 139 to read it anyway. The approach taken in this document is very 140 different from the one in the Mobile IPv6 specification. That is, we 141 have explicitly aimed to expose the implicit assumptions and design 142 choices made in the base Mobile IPv6 design, while the Mobile IPv6 143 specification aims to state the result of the design. By 144 understanding the background it is much easier to understand the 145 source of some of the related security problems, and to understand 146 the limitations intrinsic to the provided solutions. 148 In particular, this document explains how the adopted design for 149 "Return Routability" (RR) protects against the identified threats 150 (Section 3). This is true except for attacks on the RR protocol 151 itself, which require other countermeasures based on heuristics and 152 judicious implementation (Section 3.3). 154 The rest of this document is organized as follows. After this 155 introductory section, we start by considering the dimensions of the 156 danger in Section 2. The security problems and countermeasures are 157 studied in detail in Section 3. Section 4 explains the overall 158 operation and design choices behind the current security design. In 159 Section 5 we analyze the design and discuss the remaining threats. 160 Finally Section 6 concludes this document. 162 1.1 Assumptions about the Existing IP Infrastructure 164 One of the design goals in the Mobile IP design was to make mobility 165 possible without changing too much. This was especially important for 166 IPv4, with its large installed base, but the same design goals was 167 inherited by Mobile IPv6. Some alternative proposals take a 168 different approach and propose larger modifications to the Internet 169 architecture (see Section 1.4). 171 To understand Mobile IPv6, it is important to understand the MIPv6 172 design view to the base IPv6 protocol and infrastructure. The most 173 important base assumptions can be expressed as follows: 175 The routing prefixes available to a node are determined by its 176 current location, and therefore the node must change its IP 177 address as its moves. 179 The routing infrastructure is assumed to be secure and well 180 functioning, delivering packets to their intended destinations as 181 identified by the destination address. 183 While these may appear as trivial, let us explore them a little 184 further. Firstly, in the current IPv6 operational practise the IP 185 address prefixes are distributed in a hierarchical manner. This 186 limits the amount of routing table entries each single router needs 187 to handle. An important implication is that the topology determines 188 what globally routable IP addresses are available at a given 189 location. That is, the nodes cannot freely decide what globally 190 routable IP address to use, but must rely on the routing prefixes 191 served by the local routers via Router Advertisements or by a DHCP 192 server. In other words, IP addresses are just what the name says, 193 addresses, i.e., locators. 195 Secondly, in the current Internet structure, the routers collectively 196 maintain a distributed database of the network topology, and forward 197 each packet towards the location determined by the destination 198 address carried in the packet. To maintain the topology information, 199 the routers must trust each other, at least to a certain extent. The 200 routers learn the topology information from the other routers, and 201 they have no option but to trust their neighbor routers about distant 202 topology. At the borders of administrative domains, policy rules are 203 used to limit the amount of perhaps faulty routing table information 204 received from the peer domains. While this is mostly used to weed out 205 administrative mistakes, it also helps with security. The aim is to 206 maintain a reasonably accurate idea of the network topology even if 207 someone is feeding faulty information to the routing system. 209 In the current Mobile IPv6 design it is explicitly assumed that the 210 routers and the policy rules are configured in a reasonable way, and 211 that the resulting routing infrastructure is trustworthy enough. That 212 is, it is assumed that the routing system maintains accurate 213 information of the network topology, and that it is therefore able to 214 route packets to their destination locations. If this assumption is 215 broken, the Internet itself is broken in the sense that packets go to 216 wrong locations. Such a fundamental malfunction of the Internet would 217 render hopeless any other effort to assure correct packet delivery 218 (e.g., any efforts due to Mobile IP security considerations). 220 1.1.1 A note on source addresses and ingress filtering 222 Some of the threats and attacks discussed in this document take 223 advantage of the ease of source address spoofing. That is, in the 224 current Internet it is possible to send packets with false source IP 225 address. Ingress filtering is assumed to eventually prevent this. 226 When ingress filtering is used, the source address of all packets are 227 screened by the Internet service provider, and if the source address 228 has a routing prefix that should not be used by the customer, the 229 packets are dropped. 231 It should be noted that ingress filtering is relatively easy to apply 232 at the edges of the network, but almost impossible in the core 233 network. Basically, ingress filtering is easy only when the network 234 topology and prefix assignment do follow the same hierarchical 235 structure. Secondly, ingress filtering helps if and only if a large 236 part of the Internet uses it. Thirdly, ingress filtering has its own 237 technical problems, e.g. with respect to site multi-homing, and these 238 problems are likely to limit its usefulness. 240 1.2 The Mobility Problem and the Mobile IPv6 Solution 242 The Mobile IP design aims to solve two problems at the same time. 243 Firstly, it allows transport layer sessions (TCP connections, 244 UDP-based transactions) to continue even if the underlying host(s) 245 move and change their IP addresses. Secondly, it allows a node to be 246 reached through a static IP address, a home address (HoA). 248 The latter design choice can also be stated in other words: Mobile 249 IPv6 aims to preserve the identifier nature of IP addresses. That is, 250 Mobile IPv6 takes the view that IP addresses can be used as natural 251 identifiers of nodes, as they have been used since the beginning of 252 the Internet. This must be contrasted to proposed and existing 253 alternative designs where the identifier and locator natures of the 254 IP addresses have been separated (see Section 1.4) 256 The basic idea in Mobile IP is to allow a home agent (HA) to work as 257 a stationary proxy for a mobile node (MN). Whenever the mobile node 258 is away from its home network, the home agent intercepts packets 259 destined to the node, and forwards the packets by tunneling them to 260 the node's current address, the care-of-address (CoA). The transport 261 layer (e.g., TCP, UDP) uses the home address as a stationary 262 identifier for the mobile node. Figure 1 illustrates this basic 263 arrangement. 265 +----+ +----+ 266 | MN |=#=#=#=#=#=#=#=#=tunnel=#=#=#=#=#=#=#=#|#HA | 267 +----+ ____________ +-#--+ 268 | CoA ___/ \_____ # Home Link 269 -+-------/ Internet * * *-*-*-*-#-#-#-#----- 270 | * * | * Home Address 271 \___ * * _____/ + * -+ 272 \_____*______/ | MN | 273 * + - -+ 274 +----+ 275 | CN | Data path as * * * * 276 +----+ it appears to correspondent node 278 Real data path # # # # 280 Figure 1 282 The basic solution requires tunneling through the home agent, thereby 283 leading to longer paths and degraded performance. This tunneling is 284 sometimes called triangular routing since it was originally planned 285 that the packets from the mobile node to its peer could still 286 traverse directly, bypassing the home agent. 288 To alleviate the performance penalty, Mobile IPv6 includes a mode of 289 operation that allows the mobile node and its peer, a correspondent 290 node (CN), to exchange packets directly, bypassing the home agent 291 completely after the initial setup phase. This mode of operation is 292 called route optimization (RO). When route optimization is used, the 293 mobile node sends its current care-of-address to the correspondent 294 node using binding update (BU) messages. The correspondent node 295 stores the binding between the home address and care-of address into 296 its Binding Cache. 298 Whenever MIPv6 route optimization is used, the correspondent node 299 effectively functions in two roles. Firstly, it is the source of the 300 packets it sends, as usual. Secondly, it acts as the first router for 301 the packets, effectively performing source routing. That is, when the 302 correspondent node is sending out packets, it consults its MIPv6 303 route optimization data structures, and reroutes the packets if 304 necessary. A Binding Cache Entry (BCE) contains the home address and 305 the care-of-address of the mobile node, and records the fact that 306 packets destined to the home address should now be sent to the 307 destination address. Thus, it represents a local routing exception. 309 The packets leaving the correspondent node are source routed to the 310 care-of-address. Each packet includes a routing header that contains 311 the home address of the mobile node. Thus, logically, the packet is 312 first routed to the care-of-address, and then virtually from the 313 care-of-address to the home address. In practise, of course, the 314 packet is consumed by the mobile node at the care-of-address, and the 315 header just allows the mobile node to select a socket associated with 316 the home address instead of one with the care-of-address. However, 317 the mechanism resembles source routing since there is routing state 318 involved at the correspondent node, and a routing header is used. 319 Nevertheless, this routing header is special (type 2) to avoid the 320 risks associated with using the more general (type 0) variant. 322 1.3 Design Principles and Goals 324 The MIPv6 design and security design aimed to follow the end-to-end 325 principle, to duly notice the differences in trust relationships 326 between the nodes, and to establish an explicit goal in the provided 327 level of protection. 329 1.3.1 End-to-end principle 331 Perhaps the leading design principle for Internet protocols is the so 332 called end-to-end principle [2] [3]. According to this principle, it 333 is beneficial to avoid polluting the network with state, and to limit 334 new state creation to the involved end nodes. 336 In the case of Mobile IPv6, the end-to-end principle is applied by 337 restricting mobility related state primarily to the home agent. 338 Additionally, if route optimization is used, the correspondent nodes 339 also maintain a soft state about the mobile nodes' current 340 care-of-addresses, the Binding Cache. This can be contrasted to an 341 approach that would use individual host routes within the basic 342 routing system. Such an approach would create state on a huge number 343 of routers around the network. In Mobile IPv6, only the home agent 344 and the communicating nodes need to create state. 346 1.3.2 Trust assumptions 348 In the Mobile IPv6 security design, different approaches were chosen 349 for securing the communication between the mobile node and its home 350 agent and between the mobile node and its correspondent nodes. In the 351 home agent case it was assumed that the mobile node and the home 352 agent know each other through a prior arrangement, e.g., due to a 353 business relationships. In contrast, it was strictly assumed that the 354 mobile node and the correspondent node do not need to have any prior 355 arrangement, thereby allowing Mobile IPv6 to function in a scalable 356 manner, without requiring any configuration at the correspondent 357 nodes. 359 1.3.3 Protection level 361 As a security goal, Mobile IPv6 design aimed to be "as secure as the 362 (non-mobile) IPv4 Internet" was at the time of the design, in the 363 period 2001-2002. In particular, that means that there is little 364 protection against attackers that are able to attach themselves 365 between a correspondent node and a home agent. The rational is 366 simple: in the 2001 Internet, if a node was able to attach itself to 367 the communication path between two arbitrary nodes, it was able to 368 disrupt, modify, and eavesdrop all the traffic between the two nodes, 369 unless IPsec protection was used. Even when IPsec was used, the 370 attacker was still able to selectively block communication by simply 371 dropping the packets. The attacker in control of a router between 372 the two nodes could also mount a flooding attack by redirecting the 373 data flows between the two nodes (or, more practically, an equivalent 374 flow of bogus data) to a third party. 376 1.4 About Mobile IPv6 Mobility and its Variations 378 Taking a more abstract angle, IPv6 mobility can be defined as a 379 mechanism for managing local exceptions to routing information in 380 order to direct packets that are sent to one address (the home 381 address) to another address (the care-of-address). It is managing in 382 the sense that the local routing exceptions (source routes) are 383 created and deleted dynamically, based on the instructions sent by 384 the mobile node. It is local in the sense that the routing exceptions 385 are valid only at the home agent, and in the correspondent nodes if 386 route optimization is used. The created pieces of state are 387 exceptions in the sense that they override the normal topological 388 routing information carried collectively by the routers. 390 Using the terminology introduced by J. Noel Chiappa [6], we can say 391 that the home address functions in the dual role of being an 392 end-point identifier (EID) and a permanent locator. The 393 care-of-address is a pure, temporary locator, which identifies the 394 current location of the mobile node. The correspondent nodes 395 effectively perform source routing, redirecting traffic destined to 396 the home address to the care-of-address. This is even reflected in 397 the packet structure: the packets carry an explicit routing header. 399 The relationshiop between EID's and permanent locators has been 400 exploited by other proposals. Their technical merits and security 401 problems, however, are beyond the scope of this document. 403 2. Dimensions of Danger 405 Based on the discussion above it should now be clear that the dangers 406 in Mobile IPv6 lie in creation (or deletion) of the local routing 407 exceptions. In Mobile IPv6 terms, the danger is in the possibility of 408 unauthorized creation of Binding Cache Entries (BCE). The effects of 409 an attack differ depending on the target of the attack, the timing of 410 the attack, and the location of the attacker. 412 2.1 Target 414 Basically, the target of an attack can be any node or network in the 415 Internet (stationary or mobile). The basic differences lie in the 416 goals of the attack: does the attacker aim to divert (steal) the 417 traffic destined to and/or sourced at the target node, or does it aim 418 to cause denial-of-service to the target node or network. The target 419 does not typically play much of an active role attack. As an example, 420 an attacker may launch a denial-of-service attack on a given node A 421 by contacting a large number of nodes, claiming to be A, and 422 subsequently diverting the traffic at these other nodes so that A is 423 harmed by no longer being able to receive packets from those nodes. A 424 itself need not be involved at all before its communications start to 425 break. Furthermore, A is not necessarily a mobile node; it may very 426 well be stationary. 428 Mobile IPv6 uses the same class of IP addresses for both mobile nodes 429 (i.e., home and care-of addresses) and stationary nodes. That is, 430 mobile and stationary addresses are indistinguishable from each 431 other. Attackers can take advantage of this by taking any IP address 432 and using it in a context where normally only mobile (home or care-of 433 addresses) appear. This means that attacks that otherwise would only 434 concern mobiles are, in fact, a threat to all IPv6 nodes. 436 In fact, the role of being a mobile node appears to be most 437 protected, since in that role a node does not need to maintain state 438 about the whereabouts of some remote nodes. Conversely, the role of 439 being a correspondent node appears to be the weakest point since 440 there are very few assumptions upon which it can base its state 441 formation. That is, an attacker has much easier task to fool a 442 correspondent node to believe that a presumably mobile node is 443 somewhere it is not, than to fool a mobile node itself into believing 444 something similar. On the other hand, since it is possible to attack 445 a node indirectly by first targetting its peers, all nodes are 446 equally vulnerable in some sense. Furthermore, a (usually) mobile 447 node often also plays the role of being a correspondent node, since 448 it can exchange packets with other mobile nodes (see also Section 449 5.4). 451 2.2 Timing 453 An important aspect in understanding Mobile IPv6 related dangers is 454 timing. In a stationary IPv4 network, an attacker must be between the 455 communication nodes at the same time as the nodes communicate. With 456 the Mobile IPv6 ability of creating binding cache entries, the 457 situation changes. A new danger is created. Without proper 458 protection, an attacker could attach itself between the home agent 459 and a correspondent node for a while, create a BCE at the 460 correspondent node, leave the position, and continuously update the 461 correspondent node about the mobile node's whereabouts. This would 462 make the correspondent node send packets destined to the mobile node 463 to an incorrect address as long as the BCE remained valid, i.e., 464 typically until the correspondent node is rebooted. The converse 465 would also be possible: an attacker could also launch an attack by 466 first creating a BCE and then letting it expire at a carefully 467 selected time. If a large number of active BCEs carrying large 468 amounts of traffic expired at the same time, the result might be an 469 overload towards the home agent or the home network. (See Section 470 3.2.2 for a more detailed explanation.) 472 2.3 Location 474 In a static IPv4 Internet, an attacker can only receive packets 475 destined to a given address if it is able to attach itself to or 476 control a node on the topological path between the sender and the 477 recipient. On the other hand, an attacker can easily send spoofed 478 packets from almost anywhere. If Mobile IPv6 allowed sending 479 unprotected Binding Updates, an attacker could create a BCE on any 480 correspondent node from anywhere in the Internet, simply by sending a 481 fraudulent Binding Update to the correspondent node. Instead of being 482 required to be between the two target nodes, the attacker could act 483 from anywhere in the Internet. 485 In summary, by introducing the new routing exception (binding cache) 486 at the correspondent nodes, Mobile IPv6 introduces the dangers of 487 time and space shifting. Without proper protection, Mobile IPv6 would 488 allow an attacker to act from anywhere in the Internet and well 489 before the time of the actual attack. In contrast, in the static IPv4 490 Internet the attacking nodes must be present at the time of the 491 attack and they must be positioned in a suitable way, or the attack 492 would not be possible in the first place. 494 3. Threats and limitations 496 This section describes attacks against Mobile IPv6 Route Optimization 497 and related protection mechanisms. The goal of the attacker can be to 498 corrupt the correspondent node's binding cache and to cause packets 499 to be delivered to a wrong address. This can compromise secrecy and 500 integrity of communication and cause denial-of-service (DoS) both at 501 the communicating parties and at the address that receives the 502 unwanted packets. The attacker may also exploit features of the 503 Binding Update (BU) mechanism to exhaust the resources of the mobile 504 node, the home agent, or the correspondent nodes. The aim of this 505 section is to describe the major attacks and to overview various 506 protocol mechanisms and their limitations. The details of the 507 mechanisms are covered in Section 4. 509 It is essential to understand that some of the threats are more 510 serious than others, some can be mitigated but not removed, some 511 threats may represent acceptable risk, and some threats may be 512 considered too expensive to be prevented. 514 We consider only active attackers. The rationale behind this is that 515 in order to corrupt the binding cache, the attacker must sooner or 516 later send one or more messages. Thus, it makes little sense to 517 consider attackers that only observe messages but do not send any. In 518 fact, some active attacks are easier, for the average attacker, to 519 launch than a passive one would be. That is, in many active attacks 520 the attacker can initiate binding update processing at any time, 521 while most passive attacks require the attacker to wait for suitable 522 messages to be sent by the targets nodes. 524 We first consider attacks against nodes that are supposed to have a 525 specified address (Section 3.1), continuing with flooding attacks 526 (Section 3.2) and attacks against the basic Binding Update protocol 527 (Section 3.3). After that we present a classification of the attacks 528 (Section 3.4). Finally, we considering the applicability of solutions 529 relying on some kind of a global security infrastructure (Section 530 3.5). 532 3.1 Attacks against address 'owners' aka. address 'stealing' 534 The most obvious danger in Mobile IPv6 is address "stealing", i.e., 535 an attacker illegitimately claiming to be a given node at a given 536 address, and then trying to "steal" traffic destined to that address. 537 There are several variants of this attack. We first describe the 538 basic variant, followed by a description how the situation is 539 affected if the target is a stationary node, and continuing more 540 complicated issues related to timing (the so called "future" 541 attacks), confidentiality and integrity, and DoS aspects. 543 3.1.1 Basic address stealing 545 If Binding Updates were not authenticated at all, an attacker could 546 fabricate and send spoofed binding updates from anywhere in the 547 Internet. All nodes that support the correspondent node functionality 548 would become unwitting accomplices to this attack. As explained in 549 Section 2.1, there is no way of telling which addresses belong to 550 mobile nodes that really could send binding updates and which 551 addresses belong to stationary nodes (see below), so potentially any 552 node (including "static" nodes) are vulnerable. 554 +---+ original +---+ new packet +---+ 555 | B |<----------------| A |- - - - - - ->| C | 556 +---+ packet flow +---+ flow +---+ 557 ^ 558 | 559 | False BU: B -> C 560 | 561 +----------+ 562 | Attacker | 563 +----------+ 565 Figure 2 567 Consider an IP node A sending IP packets to another IP node B. The 568 attacker could redirect the packets to an arbitrary address C by 569 sending a Binding Update to A. The home address (HoA) in the binding 570 update would be B and the care-of address (CoA) would be C. After 571 receiving this binding update, A would send all packets intended for 572 the node B to the address C. See Figure 2. 574 The attacker might select the care-of address to be either its own 575 current address, another address in its local network, or any other 576 IP address. If the attacker selected a local care-of address allowing 577 it to receive the packets, it would be able to send replies to the 578 correspondent node. Ingress filtering at the attacker's local network 579 does not prevent the spoofing of Binding Updates but forces the 580 attacker either to choose a care-of address from inside its own 581 network or to use the Alternate care-of address sub-option. 583 The binding update authorization mechanism used in the MIPv6 security 584 design is primarily intended to mitigate this threat, and to limit 585 the location of attackers to the path between a correspondent node 586 and the home agent. 588 3.1.2 Stealing addresses of stationary nodes 589 The attacker needs to know or guess the IP addresses of both the 590 source of the packets to be diverted (A in the example above) and the 591 destination of the packets (B). This means that it is difficult to 592 redirect all packets to or from a specific node because the attacker 593 would need to know the IP addresses of all the nodes with which it is 594 communicating. 596 Nodes with well-known addresses, such as servers and those using 597 stateful configuration, are most vulnerable. Nodes that are a part of 598 the network infrastructure, such as DNS servers, are particularly 599 interesting targets for attackers, and particularly easy to identify. 601 Nodes that frequently change their address and use random addresses 602 are relatively safe. However, if they register their address into 603 Dynamic DNS, they become more exposed. Similarly, nodes that visit 604 publicly accessible networks such as airport wireless LANs risk 605 revealing their addresses. IPv6 addressing privacy features [ND01] 606 mitigate these risks to an extent but it should be noted that 607 addresses cannot be completely recycled while there are still open 608 sessions that use those addresses. 610 Thus, it is not the mobile nodes that are most vulnerable to address 611 stealing attacks, it is the well known static servers. Furthermore, 612 the servers often run old or heavily optimized operating systems, and 613 may not have any mobility related code at all. Thus, the security 614 design cannot be based on the idea that mobile nodes might somehow be 615 able to detect if someone has stolen their address, and reset the 616 state at the correspondent node. Instead, the security design must 617 make reasonable measures to prevent the creation of fraudulent 618 binding cache entries in the first place. 620 3.1.3 Future address stealing 622 If an attacker knows an address that a node is likely to select in 623 the future, it can launch a "future" address stealing attack. The 624 attacker creates a Binding Cache Entry using the home address that it 625 anticipates the target node will use. If the Home Agent allows 626 dynamic home addresses, the attacker may be able to do this 627 legitimately. That is, if the attacker is a client of the Home Agent, 628 and able to acquire the home address temporarily, it may be able to 629 do so, and then return the home address back to the Home Agent once 630 the BCE is in place. 632 Now, if the BCE state had a long expiration time, the target node 633 would acquire the same home address while the BCE is still effective, 634 and the attacker would be able to launch a successful 635 man-in-the-middle or denial-of-service attack. The mechanism applied 636 in the MIPv6 security design is to limit the lifetime of Binding 637 Cache Entries to a few minutes. 639 Note that this attack applies only to fairly specific conditions. 640 There are also some variations of this attack that are theoretically 641 possible under some other conditions. However, all of these attacks 642 are limited by the Binding Cache Entry lifetime, and therefore not a 643 real concern under the current design. 645 3.1.4 Attacks against Secrecy and Integrity 647 By spoofing Binding Updates, an attacker could redirect all packets 648 between two IP nodes to itself. By sending a spoofed binding update 649 to A, it could capture the data intended to B. That is, it could 650 pretend to be B and highjack A's connections with B, or establish new 651 spoofed connections. The attacker could also send spoofed binding 652 updates to both A and B and insert itself in the middle of all 653 connections between them (man-in-the-middle attack). Consequently, 654 the attacker would be able to see and modify the packets sent between 655 A and B. See Figure 3. 657 Original data path, before man-in-the-middle attack 659 +---+ +---+ 660 | A | | B | 661 +---+ +---+ 662 \___________________________________/ 664 Modified data path, after the falsified binding updates 666 +---+ +---+ 667 | A | | B | 668 +---+ +---+ 669 \ / 670 \ / 671 \ +----------+ / 672 \---------| Attacker |-------/ 673 +----------+ 675 Figure 3 677 Strong end-to-end encryption and integrity protection, such as 678 authenticated IPSec, can prevent all the attacks against data secrecy 679 and integrity. When the data is cryptographically protected, spoofed 680 binding updates could result in denial of service (see below) but not 681 in disclosure or corruption of sensitive data beyond revealing the 682 existence of the traffic flows. Two fixed nodes could also protect 683 communication between themselves by refusing to accept binding 684 updates from each other. Ingress filtering, on the other hand, does 685 not help because the attacker is using its own address as the care-of 686 address and is not spoofing source IP addresses. 688 The protection adopted in MIPv6 Security Design is to authenticate 689 (albeit weakly) the addresses by return routability (RR), which 690 limits the topological locations from which the attack is possible 691 (see Section 4.1). 693 3.1.5 Basic Denial of Service Attacks 695 By sending spoofed binding updates, the attacker could redirect all 696 packets sent between two IP nodes to a random or nonexistent 697 address(es). This way, it might be able to stop or disrupt 698 communication between the nodes. This attack is serious because any 699 Internet node could be targeted, also fixed nodes belonging to the 700 infrastructure (e.g., DNS servers) are vulnerable. Again, the 701 selected protection mechanism is return routability (RR). 703 3.1.6 Replaying and Blocking Binding Updates 705 Any protocol for authenticating binding update has to consider replay 706 attacks. That is, an attacker may be able to replay recent 707 authenticated binding updates to the correspondent and, that way, 708 direct packets to the mobile node's previous location. Like spoofed 709 binding updates, this could be used both for capturing packets and 710 for DoS. The attacker could capture the packets and impersonate the 711 mobile node if it reserved the mobile's previous address after the 712 mobile node has moved away and then replayed the previous binding 713 update to redirect packets back to the previous location. 715 In a related attack, the attacker blocks binding updates from the 716 mobile at its new location, e.g., by jamming the radio link or by 717 mounting a flooding attack, and takes over its connections at the old 718 location. The attacker will be able to capture the packets sent to 719 the mobile and to impersonate the mobile until the correspondent's 720 Binding Cache entry expires. 722 Both of the above attacks require the attacker to be on the same 723 local network with the mobile, where it can relatively easily observe 724 packets and block them even if the mobile does not move to a new 725 location. Therefore, we believe that these attacks are not as serious 726 as ones that can be mounted from remote locations. The limited 727 lifetime of the Binding Cache entry and the associated nonces limit 728 the time frame within which the replay attacks are possible. 730 3.2 Attacks against other nodes and networks (flooding) 731 By sending spoofed binding updates, an attacker could redirect 732 traffic to an arbitrary IP address. This could be used to bomb an 733 arbitrary Internet address with excessive amounts of packets. The 734 attacker could also target a network by redirecting data to one or 735 more IP addresses within the network. There are two main variations 736 of flooding: basic flooding and return-to-the-home flooding. We 737 consider them separately. 739 3.2.1 Basic flooding 741 In the simplest attack, the attacker knows that there is a heavy data 742 stream from node A to B and redirects this to the target address C. 743 However, A would soon stop sending the data because it is not 744 receiving acknowledgments from B. 746 (B is attacker) 748 +---+ original +---+ flooding packet +---+ 749 | B |<================| A |==================>| C | 750 +---+ packet flow +---+ flow +---+ 751 | ^ 752 \ / 753 \__________________/ 754 False binding update + false acknowledgements 756 Figure 4 758 A more sophisticated attacker would act itself as B; see Figure 4. It 759 would first subscribe to a data stream (e.g. a video stream) and then 760 redirects this stream to the target address C. The attacker would 761 even be able to spoof the acknowledgements. For example, consider a 762 TCP stream. The attacker would perform the TCP handshake itself and 763 thus know the initial sequence numbers. After redirecting the data to 764 C, the attacker would continue to send spoofed acknowledgments. It 765 would even be able to accelerate the data rate by simulating a fatter 766 pipe [4]. 768 This attack might be even easier with UDP/RTP. The attacker could 769 create spoofed RTCP acknowledgements. Either way, the attacker would 770 be able to redirect an increasing stream of unwanted data to the 771 target address without doing much work itself. It could carry on 772 opening more streams and refreshing the Binding Cache entries by 773 sending a new binding update every few minutes. Thus, the limitation 774 of BCE lifetime to a few minutes does not help here alone. 776 During the Mobile IPv6 design process, the effectiveness of this 777 attack was debated. It was mistakenly assumed that the target node 778 would send a TCP Reset to the source of the unwanted data stream, 779 which would then stop sending. In reality, all practical TCP/IP 780 implementations fail to send the Reset. The target node drops the 781 unwanted packets at the IP layer because it does not have a Binding 782 Update List entry corresponding to the Routing Header on the incoming 783 packet. Thus, the flooding data is never processed at the TCP layer 784 of the target node and no Reset is sent. This means that the attack 785 using TCP streams is more effective than was originally believed. 787 This attack is serious because the target can be any node or network, 788 not only a mobile one. What makes it particularly serious compared to 789 the other attacks is that the target itself cannot do anything to 790 prevent the attack. For example, it does not help if the target 791 network stops using Route Optimization. The damage is the worst if 792 these techniques are used to amplify the effect of other distributed 793 denial of service (DDoS) attacks. Ingress filtering in the attacker's 794 local network prevents the spoofing of source addresses but the 795 attack would still be possible by setting the Alternate care-of 796 address sub-option to the target address. 798 Again, the protection mechanism adopted for MIPv6 is return 799 routability. This time it is necessary to check that there is indeed 800 a node at the new care-of-address, and that the node is the one that 801 requested redirecting packets to that very address (see Section 802 4.1.2). 804 3.2.2 Return-to-home flooding 806 A variation of the bombing attack targets the home address or the 807 home network instead of the care-of-address or a visited network. The 808 attacker would claim to be a mobile with the home address equal to 809 the target address. While claiming to be away from home, the attacker 810 would start downloading a data stream. The attacker would then send a 811 binding update cancellation (i.e. a request to delete the binding 812 from the Binding Cache), or just allow the cache entry to expire. 813 Either would redirect the data stream to the home network. Just like 814 when bombing a care-of-address, the attacker can keep the stream 815 alive and even increase data rate by spoofing acknowledgments. When 816 successful, the bombing attack against the home network is just as 817 serious as the one against a care-of-address. 819 The basic protection mechanism adopted is return routability. 820 However, it is hard to fully protect against this attack; see Section 821 4.1.1. 823 3.3 Attacks against binding update protocols 824 Security protocols that successfully protect the secrecy and 825 integrity of data can sometimes make the participants more vulnerable 826 to denial-of-service attacks. In fact, the stronger the 827 authentication, the easier it may be for an attacker to use the 828 protocol features to exhaust the mobile's or the correspondent's 829 resources. 831 3.3.1 Inducing Unnecessary Binding Updates 833 When a mobile node receives an IP packet from a new correspondent via 834 the home agent, it may initiate the binding update protocol. An 835 attacker can exploit this by sending the mobile node a spoofed IP 836 packet (e.g. ping or TCP SYN packet) that appears to come from a new 837 correspondent node. Since the packet arrives via the home agent, the 838 mobile node may start the binding update protocol with the 839 correspondent node. The decision whether or not to initiate the 840 binding update procedure may depend on several factors (including 841 heuristics, cross layer information, configuration options, etc) and 842 is not specified by Mobile IPv6. Not initiating the binding update 843 procedure automatically may alleviate these attacks, but will not, in 844 general, avoid them completely. 846 In a real attack the attacker would induce the mobile node to 847 initiate binding update protocols with a large number of 848 correspondent nodes at the same time. If the correspondent addresses 849 are real addresses of existing IP nodes, then most instances of the 850 binding update protocol might even complete successfully. The entries 851 created in the Binding Cache are correct but useless. This way, the 852 attacker can induce the mobile to execute the binding update protocol 853 unnecessarily, which can drain the mobile's resources. 855 A correspondent node (i.e., any IP node) can also be attacked in a 856 similar way. The attacker sends spoofed IP packets to a large number 857 of mobiles with the target node's address as the source address. 858 These mobiles will initiate the binding update protocol with the 859 target node. Again, most of the binding update protocol executions 860 will complete successfully. By inducing a large number of unnecessary 861 binding updates, the attacker is able to consume the target node's 862 resources. 864 This attack is possible against any binding update authentication 865 protocol. The more resources the binding update protocol consumes, 866 the more serious the attack. Hence, strong cryptographic 867 authentication protocol is more vulnerable to the attack than a weak 868 one or unauthenticated binding updates. Ingress filtering helps a 869 little, since it makes it harder to forge the source address of the 870 spoofed packets, but it does not completely eliminate this threat. 872 A node should protect itself from the attack by setting a limit on 873 the amount of resources, i.e., processing time, memory, and 874 communications bandwidth, which it uses for processing binding 875 updates. When the limit is exceeded, the node can simply stop 876 attempting route optimization. Sometimes it is possible to process 877 some binding updates even when a node is under the attack. A mobile 878 node may have a local security policy listing a limited number of 879 addresses to which binding updates will be sent even when the mobile 880 node is under DoS attack. A correspondent node (i.e. any IP node) may 881 similarly have a local security policy listing a limited set of 882 addresses from which binding updates will be accepted even when the 883 correspondent is under a binding update DoS attack. 885 The node may also recognize addresses with which they have had 886 meaningful communication in the past and sent binding updates to or 887 accept them from those addresses. Since it may be impossible for the 888 IP layer to know about the protocol state in higher protocol layers, 889 a good measure of the meaningfulness of the past communication is 890 probably per-address packet counts. 892 Section 11.7.2 ("Correspondent Registration") in [7] does not specify 893 when such a route optimization procedure should be initiated. It does 894 indicate when it may justifiable to do so, but these hints are not 895 enough. This remains an area where more work is needed. Obviously, 896 given that route optimization is optional, any node that finds the 897 processing load excessive or unjustified may simply turn it off 898 (either selectively or completely). 900 3.3.2 Forcing Non-Optimized Routing 902 As a variant of the previous attack, the attacker can prevent a 903 correspondent node from using route optimization by filling its 904 Binding Cache with unnecessary entries so that most entries for real 905 mobiles are dropped. 907 Any successful DoS attack against a mobile or a correspondent node 908 can also prevent the processing of binding updates. We have 909 repeatedly suggested that the target of a DoS attack may respond by 910 stopping route optimization for all or some communication. Obviously, 911 an attacker can exploit this fallback mechanism and force the target 912 to use the less efficient home agent based routing. The attacker only 913 needs to mount a noticeable DoS attack against the mobile or 914 correspondent, and the target will default to non-optimized routing. 916 The target node can mitigate the effects of the attack by reserving 917 more space for the Binding Cache, by reverting to non-optimized 918 routing only when it cannot otherwise cope with the DoS attack, by 919 trying aggressively to return to optimized routing, or by favoring 920 mobiles with which it has an established relationship. This attack is 921 not as serious as the ones described earlier, but applications that 922 rely on Route Optimization could still be affected. For instance, 923 conversational multimedia sessions can suffer drastically from the 924 additional delays caused by triangle routing. 926 3.3.3 Reflection and Amplification 928 Attackers sometimes try to hide the source of a packet flooding 929 attack by reflecting the traffic from other nodes [Sav02]. That is, 930 instead of sending the flood of packets directly to the target, the 931 attacker sends data to other nodes, tricking them to send the same 932 number, or more, packets to the target. Such reflection can hide the 933 attacker's address even when ingress filtering prevents source 934 address spoofing. Reflection is particularly dangerous if the packets 935 can be reflected multiple times, if they can be sent into a looping 936 path, or if the nodes can be tricked into sending many more packets 937 than they receive from the attacker, because such features can be 938 used to amplify the traffic by a significant factor. When designing 939 protocols, one should avoid creating services that can be used for 940 reflection and amplification. 942 Triangle routing would easily create opportunities for reflection: a 943 correspondent node receives packets (e.g. TCP SYN) from the mobile 944 node and replies to the home address given by the mobile node in the 945 Home Address Option (HAO). The mobile might not really be a mobile 946 and the home address could actually be the target address. The target 947 would only see the packets sent by the correspondent and could not 948 see the attacker's address (even if ingress filtering prevents the 949 attacker from spoofing its source address). 951 +----------+ TCP SYN with HAO +-----------+ 952 | Attacker |-------------------->| Reflector | 953 +----------+ +-----------+ 954 | 955 | TCP SYN-ACK to HoA 956 V 957 +-----------+ 958 | Flooding | 959 | target | 960 +-----------+ 962 Figure 5 964 A badly designed binding update protocol could also be used for 965 reflection: the correspondent would respond to a data packet by 966 initiating the binding update authentication protocol, which usually 967 involves sending a packet to the home address. In that case, the 968 reflection attack can be discouraged by copying the mobile's address 969 into the messages sent by the mobile to the correspondent. (The 970 mobile's source address is usually the same as the care-of address 971 but an Alternative care-of address suboption can specify a different 972 care-of address.) Some of the early proposals for MIPv6 security used 973 this approach, and were prone to the reflection attacks. 975 In some of the proposals for binding update authentication protocols, 976 the correspondent node responded to an initial message from the 977 mobile with two packets (one to the home address, one to the care-of 978 address). It would have been possible to use this to amplify a 979 flooding attack by a factor of two. Furthermore, with public-key 980 authentication, the packets sent by the correspondent might have been 981 significantly larger than the one that triggers them. 983 These types of reflection and amplification can be avoided by 984 ensuring that the correspondent only responds to the same address 985 from which it received a packet, and only with a single packet of the 986 same size. These principles have been applied to MIPv6 security 987 design. 989 3.4 Classification of attacks 991 Sect. Attack name Target Sev. Mitigation 992 --------------------------------------------------------------------- 993 3.1.1 Basic address stealing MN Med. RR 994 3.1.2 Stealing addresses of stationary nodes Any High RR 995 3.1.3 Future address stealing MN Low RR, lifetime 996 3.1.4 Attacks against Secrecy and Integrity MN Low RR, IPsec 997 3.1.5 Basic Denial of Service Attacks Any Med. RR 998 3.1.6 Replaying and Blocking Binding Updates MN Low lifetime, 999 cookies 1000 3.2.1 Basic flooding Any High RR 1001 3.2.2 Return-to-home flooding Any High RR 1002 3.3.1 Inducing Unnecessary Binding Updates MN, CN Med. heuristics 1003 3.3.2 Forcing Non-Optimized Routing MN Low heuristics 1004 3.3.3 Reflection and Amplification N/A Med. BU design 1006 Figure 6 1008 Figure 6 gives a summary of the discussed attacks. As it stands 1009 today, the return-to-the-home flooding and the induction of 1010 unnecessary binding updates look like the threats that we have the 1011 least amount of protection, compared to their severity. 1013 3.5 Problems with infrastructure based authorization 1014 Early in the MIPv6 design process it was assumed that plain IPsec 1015 could be used for securing Binding Updates. However, this turned out 1016 to be impossible for two reasons. The first reason can be inferred 1017 from the attack descriptions above: IPsec is not designed to protect 1018 against the kinds of DoS attacks that would be possible with MIPv6. 1019 Protecting against the flooding attacks would be very difficult or 1020 even impossible with plain vanilla IPsec. The second reason is 1021 scalability. 1023 Relying on IPsec requires key management, and key management requires 1024 infrastructure to distribute the keys. Furthermore, in MIPv6 it is 1025 important to show whom an IP address belongs to, i.e., who has the 1026 authority to control where packets destined to the given address may 1027 be redirected to. Only the "owner" of an address may send Binding 1028 Updates to redirect packets to a care-of-address. [5] 1030 On way of providing a global key infrastructure for mobile IP would 1031 be DNSSEC. If there was secure reverse DNS that provided a public key 1032 for each IP address, that could be used for verifying that a binding 1033 update is indeed signed by an authorized party. However, in order to 1034 be secure, each link in such a system must be secure. That is, there 1035 must be a chain of keys and signatures all the way down from the root 1036 to the given IP address. Furthermore, it is not enough that each key 1037 is signed by the key above, it is also necessary that each signature 1038 carries the meaning of authorizing the lower key to manage the 1039 address block below it. 1041 For example, consider the reverse DNS entry e.f.f.3.ip6.arpa . It 1042 could be associated with a key, say K_3ffe. In order to be valid, 1043 that key should be signed by an upper level key, let's say K_3ff, 1044 etc., up to the top level. Similarly, any subrange of addresses below 1045 3ff0::/16 would need to be signed by K_3ffe. Additionally, when the 1046 human managing the K_3ffe key signs subkeys, he or she should make 1047 sure that the signed subkey really belongs to a party that is 1048 authorized to assign address blocks in the said address range. In 1049 other words, the keys and signatures should form a tree reflecting 1050 the actual address allocations. 1052 Even though it would be theoretically possible to build a secure 1053 reverse DNS infrastructure along the lines show above, the practical 1054 problems would be insurmountable. That is, while the delegation and 1055 key signing might work close to the root of the tree, it would 1056 probably break down somewhere between the root and the individual 1057 nodes. Furthermore, checking all the signatures up the tree would 1058 place a considerable burden to the correspondent nodes, making route 1059 optimization computationally very expensive. As the last nail on the 1060 coffin, checking just that the mobile node is authorized to send 1061 binding updates containing a given Home Address would not be enough, 1062 since a malicious mobile node would still be able to launch flooding 1063 attacks. On the other hand, relying on such an infrastructure to 1064 assign and verify "ownership" of care-of-addresses would be even 1065 harder than verifying home address "ownership". 1067 4. The solution selected for Mobile IPv6 1069 The current Mobile IPv6 route optimization security has been 1070 carefully designed to prevent or mitigate the threats that were 1071 discussed in Section 3. The goal has been to produce a design whose 1072 security is close to that of a static IPv4 based Internet, and whose 1073 cost in terms of packets, delay and processing is not excessive. The 1074 result is not what one would expect: the result is definitely not a 1075 traditional cryptographic protocol. Instead, the result relies 1076 heavily on the assumption of an uncorrupted routing infrastructure, 1077 and builds upon the idea of checking that an alleged mobile node is 1078 indeed reachable both through its home address and its 1079 care-of-address. Furthermore, the lifetime of the state created at 1080 the corresponded nodes is deliberately restricted to a few minutes, 1081 in order to limit the potential ability of time shifting. 1083 In this section we describe the solution in reasonable detail (for 1084 further details see the specification), starting from Return 1085 Routability (Section 4.1), continuing with a discussion about state 1086 creation at the correspondent node (Section 4.2), and completing the 1087 description with a discussion about the lifetime of Binding Cache 1088 Entries (Section 4.3). 1090 4.1 Return Routability 1092 Return Routability (RR) is the name of the basic mechanism deployed 1093 by Mobile IPv6 route optimization security design. Basically, it 1094 means that a node verifies that there is a node that is able to 1095 respond to packets sent to a given address. The check yields false 1096 positives if the routing infrastructure is compromised or if there is 1097 an attacker between the verifier and the address to be verified. With 1098 these exceptions, it is assumed that a successful reply indicates 1099 that there is indeed a node at the given address, and that the node 1100 is willing to reply to the probes sent to it. 1102 The basic return routability mechanism consist of two checks, a Home 1103 Address check (see Section 4.1.1) and a care-of-address check (see 1104 Section 4.1.2). The packet flow is depicted in Figure 7. First the 1105 mobile node sends two packets to the correspondent node: a Home Test 1106 Init (HoTI) packet is sent through the home agent, and a Care-of Test 1107 Init (CoTI) directly. The correspondent node replies to both of these 1108 independently by sending a Home Test (HoT) in response to the Home 1109 Test Init and a Care-of Test (CoT) in response to the Care-of Test 1110 Init. Finally, once the mobile node has received both the Home Test 1111 and Care-of Test packets, it sends a Binding Update to the 1112 correspondent node. 1114 +------+ 1a) HoTI +------+ 1115 | |---------------------->| | 1116 | MN | 2a) HoT | HA | 1117 | |<----------------------| | 1118 +------+ +------+ 1119 1b) CoTI | ^ | / ^ 1120 | |2b| CoT / / 1121 | | | / / 1122 | | | 3) BU / / 1123 V | V / / 1124 +------+ 1a) HoTI / / 1125 | |<----------------/ / 1126 | CN | 2a) HoT / 1127 | |------------------/ 1128 +------+ 1130 Figure 7 1132 It might appear that the actual design was somewhat convoluted. That 1133 is, the real return routability checks are the message pairs < Home 1134 Test, Binding Update > and < Care-of Test, Binding Update >. The Home 1135 Test Init and Care-of Test Init packets are only needed to trigger 1136 the test packets, and the Binding Update acts as a combined 1137 routability response to both of the tests. 1139 There are two main reasons behind this design: 1141 avoidance of reflection and amplification (see Section 3.3.3), and 1143 avoidance of state exhaustion DoS attacks (see Section 4.2). 1145 The reason for sending two Init packets instead of one is the 1146 avoidance of amplication. The correspondent node does not know 1147 anything about the mobile node, and therefore it just suddenly 1148 receives an IP packet from some arbitrary IP address. In a way, this 1149 is similar to a server receiving a TCP SYN from a previously unknown 1150 client. If the correspondent node would send two packets in response 1151 to an initial trigger, that would create a DoS amplification effect, 1152 as discussed in Section 3.3.3. 1154 Reflection avoidance is directly related. If the correspondent node 1155 would reply to another address but the source address of the packet, 1156 that would create a reflection effect. Thus, since the correspondent 1157 node does not know better, the only safe way is to reply to the 1158 received packet with just one packet, and to send the reply to the 1159 source address of the received packet. Hence, two initial triggers 1160 are needed instead of just one. 1162 Let us now consider the two return routability tests separately. 1163 Below, the derivation of cryptographic material from each of these is 1164 shown in a simplified manner. For the real formulas and more detail, 1165 please refer to [7]. 1167 4.1.1 Home Address check 1169 The Home Address check consists of a Home Test (HoT) packet and a 1170 subsequent Binding Update (BU). It is triggered by the arrival of a 1171 Home Test Init (HoTI). A correspondent node replies to a Home Test 1172 Init by sending a Home Test to the source address of the Home Test 1173 Init. The source address is assumed to be the home address of a 1174 mobile node, and therefore the Home Test is assumed to be tunneled by 1175 the Home Agent to the mobile node. The Home Test contains a 1176 cryptographically generated token, home keygen token, which is formed 1177 by calculating a hash function over the concatenation of a secret key 1178 Kcn known only by the correspondent node, the source address of the 1179 Home Test Init packet, and a nonce. 1181 home keygen token = hash(Kcn | home address | nonce | 0) 1183 An index to the nonce is also included in the Home Test packet, 1184 allowing the correspondent node to easier find the appropriate nonce. 1186 The token allows the correspondent node to make sure that the 1187 subsequently received binding update is created by a node that has 1188 seen the Home Test packet; see Section 4.2. 1190 In most cases the Home Test packet is forwarded over two different 1191 segments of the Internet. It first traverses from the correspondent 1192 node to the Home Agent. On this trip, it is not protected and any 1193 eavesdropper on the path can learn its contents. The Home Agent then 1194 forwards the packet to the mobile node. This path is taken inside the 1195 IPsec ESP protected tunnel, making it impossible for the outsiders to 1196 learn the contents of the packet. 1198 At first it may sound unnecessary to protect the packet between the 1199 home agent and the mobile node since it travelled unprotected between 1200 the correspondent node and the mobile node. If all links in the 1201 Internet were equally insecure, the situation would indeed be so, 1202 that would be unnecessary. However, in most practical settings the 1203 network is likely to be more secure near the Home Agent than near the 1204 Mobile Node. For example, if the home agent hosts a virtual home link 1205 and the mobile nodes are never actually at home, an eavesdropper 1206 should be close to the correspondent node or on the path between the 1207 correspondent node and the home agent, since it could not eavesdrop 1208 at the home agent. If the correspondent node is a big server, all the 1209 links on the path between it and the Home Agent are likely to be 1210 fairly secure. On the other hand, the Mobile Node is probably using 1211 wireless access technology, making it sometimes trivial to eavesdrop 1212 its access link. Thus, it is fairly easy to eavesdrop packets that 1213 arrive at the mobile node. Consequently, protecting the HA-MN path is 1214 likely to provide real security benefits even when the CN-HA path 1215 remains unprotected. 1217 4.1.2 Care-of-Address check 1219 From the correspondent node's point of view, the Care-of check is 1220 very similar to the Home check. The only difference is that now the 1221 source address of the received Care-of Test Init packet is assumed to 1222 be the care-of-address of the mobile node. Furthermore, the token is 1223 created in a slightly different manner in order to make it impossible 1224 to use home tokens for care-of tokens or vice versa. 1226 care-of keygen token = hash(Kcn | care-of address | nonce | 1) 1228 The Care-of Test traverses only one leg, directly from the 1229 correspondent node to the mobile node. It remains unprotected all 1230 along the way, making it vulnerable to eavesdroppers near the 1231 correspondent node, on the path from the correspondent node to the 1232 mobile node, or near the mobile node. 1234 4.1.3 Forming the first Binding Update 1236 When the mobile node has received both the Home Test and Care-of Test 1237 messages, it creates a binding key Kbm by taking a hash function over 1238 the concatenation of the tokens received. 1240 This key is used to protect the first and the subsequent binding 1241 updates, as long as the key remains valid. 1243 Note that the key Kbm is available to anyone that is able to receive 1244 both the Care-of Test and Home Test messages. However, they are 1245 normally routed through different routes through the network, and the 1246 Home Test is transmitted over an encrypted tunnel from the home agent 1247 to the mobile node (see also Section 5.4). 1249 4.2 Creating state safely 1251 The correspondent node may remain stateless until it receives the 1252 first Binding Update. That is, it does not need to record receiving 1253 and replying to the Home Test Init and Care-of Test Init messages. 1254 The Home Test Init/Home Test and Care-of Test Init/Care-of Test 1255 exchanges take place in parallel but independently from each other. 1256 Thus, the correspondent can respond to each message immediately and 1257 it does not need to remember doing that. This helps in potential 1258 Denial-of-Service situations: no memory needs to be reserved when 1259 processing Home Test Init and Care-of Test Init messages. 1260 Furthermore, Home Test Init and Care-of Test Init processing is 1261 designed to be lightweight, and it can be rate limited if necessary. 1263 When receiving a first binding update, the correspondent node goes 1264 through a rather complicated procedure. The purpose of this procedure 1265 is to ensure that there is indeed a mobile node that has recently 1266 received a Home Test and a Care-of Test that were sent to the claimed 1267 home and care-of-addresses, respectively, and to make sure that the 1268 correspondent node does not unnecessarily spend CPU or other 1269 resources while performing this check. 1271 Since the correspondent node does not have any state when the binding 1272 update arrives, the binding update itself must contain enough 1273 information so that relevant state can be created. The binding update 1274 contains the following pieces of information for that: 1276 The care-of address specified in the Binding Update must be equal 1277 to the source address used in the Care-of Test Init message. 1278 Notice that this applies to the effective Care-of Address of the 1279 Binding Update. In particular, if the Binding Update includes an 1280 Alternate Care-of Address (AltCoA) [7], the effective CoA is, of 1281 course, this AltCoA. Thus, the Care-of Test Init must have 1282 originated from the AltCoA. 1284 The home address specified in the Binding Update must be equal to 1285 the source address used in the Home Test Init message. 1287 These are copied over from the Home Test and Care-of Test 1288 messages, and together with the other information they allow the 1289 correspondent node to re-create the tokens sent in the Home Test 1290 and Care-of Test messages and used for creating Kbm. Without them 1291 the correspondent node might need to try the 2-3 latest nonces, 1292 leading to unnecessary resource consumption. 1294 The binding update is authenticated by computing a MAC function 1295 over the care-of-address, the correspondent node's address and the 1296 binding update message itself. The MAC is keyed with the key Kbm. 1298 Given the addresses, the nonce indices and thereby the nonces, and 1299 the key Kcn, the correspondent node can re-create the home and 1300 care-of tokens at the cost of a few memory lookups and computation of 1301 one MAC and one hash function. 1303 Once the correspondent node has re-created the tokens, it hashes the 1304 tokens together, giving the key Kbm. If the Binding Update is 1305 authentic, Kbm is cached together with the binding. This key is then 1306 used to verify the MAC that protects integrity and origin of the 1307 actual Binding Update. Note that the same Kbm may be used for a 1308 while, until either the mobile node moves (and needs to get a new 1309 care-of-address token), the care-of token expires, or the home token 1310 expires. 1312 4.2.1 Retransmissions and state machine 1314 Note that since the correspondent node may remain stateless until it 1315 receives a valid binding update, the mobile node is solely 1316 responsible for retransmissions. That is, the mobile node should keep 1317 sending the Home Test Init / Care-of Test Init messages until it 1318 receives a Home Test / Care-of Test, respectively. Similarly, it may 1319 need to send the binding update a few times in the case it is lost 1320 while in transit. 1322 4.3 Quick expiration of the Binding Cache Entries 1324 A Binding Cache Entry, along the key Kbm, represents the return 1325 routability state of the network at the time when the Home Test and 1326 Care-of Test messages were sent out. Now, it is possible that a 1327 specific attacker is able to eavesdrop a Home Test message at some 1328 point of time but not later. If the Home Test had an infinite or a 1329 long lifetime, that would allow the attacker to perform a time 1330 shifting attack (see Section 2.2). That is, in the current IPv4 1331 architecture an attacker at the path between the correspondent node 1332 and the home agent is able to perform attacks only as long as the 1333 attacker is able to eavesdrop (and possibly disrupt) communications 1334 on that particular path. A long living Home Test, and consequently 1335 the ability to send valid binding updates for a long time, would 1336 allow the attacker to continue its attack even after the attacker is 1337 not any more able to eavesdrop the path. 1339 To limit the seriousness of this and other similar time shifting 1340 threats, the validity of the tokens is limited to a few minutes. This 1341 effectively limits the validity of the key Kbm and the lifetime of 1342 the resulting binding updates and binding cache entries. 1344 While short life times are necessary given the other aspects of the 1345 security design and the goals, they are clearly detrimental for 1346 efficiency and robustness. That is, a Home Test Init / Home Test 1347 message pair must be exchanged through the home agent every few 1348 minutes. These messages are unnecessary from a pure functional point 1349 of view, thereby representing overhead. What is worse, though, is 1350 that they make the home agent a single point of failure. That is, if 1351 the Home Test Init / Home Test messages were not needed, the existing 1352 connections from a mobile node to other nodes could continue even 1353 when the home agent fails, but the current design forces the bindings 1354 to expire after a few minutes. 1356 This concludes our walkthrough of the selected security design. The 1357 cornerstones of the design were the employment of the return 1358 routability idea in the Home Test, Care-of Test and binding update 1359 messages, the ability to remain stateless until a valid binding 1360 update is received, and the limiting of the binding life times to a 1361 few minutes. Next we briefly discuss some of the remaining threats 1362 and other problems inherent to the design. 1364 5. Security considerations 1366 In this section we give a brief analysis of the security design, 1367 mostly in the light of what was know at the time the design was 1368 completed in fall 2002. It should be noted that this section does not 1369 present a proper security analysis of the protocol, but merely 1370 discusses a few issues that were known at the time the design was 1371 completed. 1373 It should be kept in mind that the MIPv6 RO security design was never 1374 intended to be fully secure. Instead, as we stated earlier, to goal 1375 was to be roughly as secure as non-mobile IPv4 was known to be at the 1376 time of the design. As it turns out, the result is slightly less 1377 secure than IPv4, but the difference is small and most likely to be 1378 insignificant in real life. 1380 The known residual threats as compared with IPv4 are discussed in 1381 Section 5.1. Considerations related to the application of IPsec to 1382 authorize route optimization are discussed in Section 5.2. Section 1383 5.3 discusses an attack against neighboring nodes. Finally, Section 1384 5.4 deals with the special case of two mobile nodes conversing and 1385 performing the route optimization procedure with each other. 1387 5.1 Residual Threats as Compared to IPv4 1389 As we mentioned in Section 4.2, the lifetime of a binding represents 1390 a potential time shift in an attack. That is, an attacker that is 1391 able to create a false binding is able to reap the benefits of the 1392 binding as long as the binding lasts, or, alternatively, is able to 1393 delay a return-to-the-home flooding attack (Section 3.2.2) until the 1394 binding expires. This is a difference from IPv4 where an attacker may 1395 continue an attack only as long as it is at the path between the two 1396 hosts. 1398 Since the binding lifetimes are severely restricted in the current 1399 design, the ability to do a time shifting attack is respectively 1400 restricted. 1402 Threats possible because of the introduction of route optimization 1403 are, of course, not present in a baseline IPv4 internet (Section 1404 3.3). In particular, inducing unnecessary binding updates could 1405 potentially be a severe attack, but this would be more due to faulty 1406 implementations. As an extreme measure, a correspondent node can 1407 protect against these attacks by turning off route optimization. If 1408 so, it becomes obvious that the only residual attack against which 1409 there is no clear-cut prevention (other than its severe limitation as 1410 currently specified) is the time shifting attack mentioned above. 1412 5.2 Interaction with IPsec 1414 A major motivation behind the current binding update design was 1415 scalability, the ability to run the protocol without any existing 1416 security infrastructure. An alternative would have been to rely on 1417 existing trust relationships, perhaps in the form of a special 1418 purpose Public Key Infrastructure and IPsec. That would have limited 1419 scalability, making route optimization available in environments 1420 where it is possible to create appropriately authorized IPsec 1421 security associations between the mobile nodes and the corresponding 1422 nodes. 1424 There clearly are situations where there exists an appropriate 1425 relationship between a mobile node and the correspondent node. For 1426 example, if the correspondent node is a server that has 1427 pre-established keys with the mobile node, that would be the case. 1428 However, entity authentication or an authenticated session key is not 1429 necessarily sufficient for accepting Binding Updates. If one wants 1430 to replace the home address check with some cryptographic 1431 credentials, the credentials must carry proper authorization for the 1432 specific home address. For example, if the mobile nodes hands out a 1433 certificate to the correspondent node and they consequently create a 1434 pair of IPsec security associations, it is not necessarily clear that 1435 those security associations could be used to replace the home address 1436 check. Instead, if and only if the certificate explicitly states what 1437 the mobile node's home address is and that the mobile node is 1438 authorized to create bindings for its home address, home address 1439 checks may be dropped. Furthermore, care must be taken to make sure 1440 that the issuer of the certificate is entitled to express such 1441 authorization. 1443 In practise, it seems highly unlikely that the nodes were ever able 1444 to replace the care-of address check with credentials. The care-of 1445 addresses are ephemeral, and it is highly unlikely that a mobile node 1446 would be able to present credentials that show it authorized to use 1447 the care of address without any check. 1449 Mobile IPv6 [7] does not specify how to use IPsec together with the 1450 mobility procedures between the mobile node and correspondent node. 1451 Hence, currently there are no standard way of replacing the home 1452 address check. On the other hand, the specification is carefully 1453 written to allow the creation of the binding management key Kbm 1454 through some different means. 1456 5.3 Pretending to be your neighbor 1458 One possible attack against the security design is to pretend to be a 1459 neighboring node. To launch this attack, the mobile nodes establishes 1460 route optimization with some arbitrary correspondent node. While 1461 performing the return routability tests and creating the binding 1462 management key Kbm, the attacker uses its real home address but a 1463 faked care-of address. Indeed, the care-of address would be the 1464 address of the neighboring node on the local link. The attacker is 1465 able to create the binding since it receives a valid Home Test 1466 normally, and it is able to eavesdrop the Care-of Test as it appears 1467 on the local link. 1469 This attack would allow the mobile node to divert unwanted traffic 1470 towards the neighboring node, resulting in an flooding attack. 1472 However, this attack is not very serious in practise. Firstly, it is 1473 limited in the terms of location, since it is only possible against 1474 neighbors. Secondly, the attack works also against the attacker, 1475 since it shares the local link with the target. Thirdly, a similar 1476 attack is possible with Neighbor Discovery spoofing. 1478 5.4 Two mobile nodes talking to each other 1480 When two mobile nodes want to establish route optimization with each 1481 other, some care must be exercised in order not to reveal the reverse 1482 tokens to an attacker. In this situation, both mobile nodes act 1483 simultaneously in the mobile node and the correspondent node roles. 1484 In the correspondent node role, the nodes are vulnerable to attackers 1485 that are co-located at the same link. Such an attacker is able to 1486 learn both the Home Test and Care-of Test sent by the mobile node, 1487 and therefore it is able to spoof the location of the other mobile 1488 host to the neighboring one. What is worse is that the attacker can 1489 obtain a valid Care-of Test itself, combine it with the Home Test, 1490 and the claim to the neighboring node that the other node has just 1491 arrived at the same link. 1493 There is an easy way to avoid this attack. In the correspondent node 1494 role, the mobile node should tunnel the sent Home Test messages 1495 through its home agent. This prevents the co-located attacker from 1496 learning any valid Home Test messages. 1498 6. Conclusions 1500 In this document we have discussed the security design rationale for 1501 the Mobile IPv6 Route Optimization. We have tried to describe the 1502 dangers created by Mobile IP Route Optimization, the security goals 1503 and background of the design, and the actual mechanisms employed. 1505 We started the discussion with a background tour to the IP routing 1506 architecture the definition of the mobility problem. After that we 1507 covered the dimensions of the danger: the targets, the time shifting 1508 abilities, and the possible locations of an attacker. We outlined a 1509 number of identified threat scenarios, and discussed how they are 1510 mitigated in the current design. Finally, in Section 4 we gave an 1511 overview of the actual mechanisms employed, and the rational behind 1512 them. 1514 As far as we know today, the only significant difference between the 1515 security of an IPv4 internet and that of an internet with Mobile IPv6 1516 (and route optimization): time shifting attacks. Nevertheless, these 1517 are severely retricted in the current design. 1519 We have also briefly covered some of the known subtleties and 1520 shortcomings, but that discussion cannot be exhaustive. It is quite 1521 probable that new subtle problems will be discovered from the design. 1522 As a consequence, it is most likely that the design needs to be 1523 revised in the light of experience and insights. 1525 7. Acknowledgements 1527 Hesham Soliman for reminding us about the threat explained in Section 1528 5.3. Francis Dupont for first discussing the case of two mobile 1529 nodes talking to each other Section 5.4. 1531 References (informative) 1533 [1] Aura, T., Roe, M. and J. Arkko, "Security of Internet Location 1534 Management", Proc. 18th Annual Computer Security Applications 1535 Conference, pages 78-87, Las Vegas, NV USA, IEEE Press., 1536 December 2002. 1538 [2] Bush, R. and D. Meyer, "Some Internet Architectural Guidelines 1539 and Philosophy", RFC 3439, December 2002. 1541 [3] Chiappa, J., "Will The Real "End-End Principle" Please Stand 1542 Up?", date unknown. 1544 [4] Savage, S., Cardwell, N., Wetherall, D. and T. Anderson, "TCP 1545 Congestion Control with a Misbehaving Receiver", Computer 1546 Communication Review 29:5, 1999. 1548 [5] Nikander, P., "Denial-of-Service, Address Ownership, and Early 1549 Authentication in the IPv6 World", Security Protocols 9th 1550 International Workshop, Cambridge, UK, April 25-27 2001, LNCS 1551 2467, pages 12-26, Springer, 2002. 1553 [6] Chiappa, J., "Endpoints and Endpoint Names: A Proposed 1554 Enhancement to the Internet Architecture", date unknown. 1556 [7] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 1557 IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), July 1558 2003. 1560 Authors' Addresses 1562 Pekka Nikander 1563 Ericsson Research Nomadic Lab 1565 JORVAS FIN-02420 1566 FINLAND 1568 Phone: +358 9 299 1 1569 EMail: pekka.nikander@nomadiclab.com 1571 Jari Arkko 1572 Ericsson Research Nomadic Lab 1573 Tuomas Aura 1574 Microsoft Research 1576 Gabriel Montenegro 1577 Sun Microsystems 1579 Erik Nordmark 1580 Sun Microsystems 1582 Intellectual Property Statement 1584 The IETF takes no position regarding the validity or scope of any 1585 intellectual property or other rights that might be claimed to 1586 pertain to the implementation or use of the technology described in 1587 this document or the extent to which any license under such rights 1588 might or might not be available; neither does it represent that it 1589 has made any effort to identify any such rights. Information on the 1590 IETF's procedures with respect to rights in standards-track and 1591 standards-related documentation can be found in BCP-11. Copies of 1592 claims of rights made available for publication and any assurances of 1593 licenses to be made available, or the result of an attempt made to 1594 obtain a general license or permission for the use of such 1595 proprietary rights by implementors or users of this specification can 1596 be obtained from the IETF Secretariat. 1598 The IETF invites any interested party to bring to its attention any 1599 copyrights, patents or patent applications, or other proprietary 1600 rights which may cover technology that may be required to practice 1601 this standard. Please address the information to the IETF Executive 1602 Director. 1604 Full Copyright Statement 1606 Copyright (C) The Internet Society (2003). All Rights Reserved. 1608 This document and translations of it may be copied and furnished to 1609 others, and derivative works that comment on or otherwise explain it 1610 or assist in its implementation may be prepared, copied, published 1611 and distributed, in whole or in part, without restriction of any 1612 kind, provided that the above copyright notice and this paragraph are 1613 included on all such copies and derivative works. However, this 1614 document itself may not be modified in any way, such as by removing 1615 the copyright notice or references to the Internet Society or other 1616 Internet organizations, except as needed for the purpose of 1617 developing Internet standards in which case the procedures for 1618 copyrights defined in the Internet Standards process must be 1619 followed, or as required to translate it into languages other than 1620 English. 1622 The limited permissions granted above are perpetual and will not be 1623 revoked by the Internet Society or its successors or assignees. 1625 This document and the information contained herein is provided on an 1626 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1627 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1628 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1629 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1630 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1632 Acknowledgement 1634 Funding for the RFC Editor function is currently provided by the 1635 Internet Society.