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