idnits 2.17.00 (12 Aug 2021) /tmp/idnits65123/draft-irtf-mobopts-ro-enhancements-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1442. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1419. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1426. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1432. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 -- 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 (May 5, 2006) is 5853 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) == Unused Reference: '9' is defined on line 1172, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 1235, but no explicit reference was found in the text == Unused Reference: '25' is defined on line 1243, but no explicit reference was found in the text == Unused Reference: '30' is defined on line 1267, but no explicit reference was found in the text == Unused Reference: '38' is defined on line 1298, but no explicit reference was found in the text == Unused Reference: '42' is defined on line 1315, but no explicit reference was found in the text == Unused Reference: '44' is defined on line 1321, but no explicit reference was found in the text == Unused Reference: '49' is defined on line 1338, but no explicit reference was found in the text == Unused Reference: '50' is defined on line 1341, but no explicit reference was found in the text == Unused Reference: '53' is defined on line 1353, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (ref. '1') (Obsoleted by RFC 6275) == Outdated reference: A later version (-04) exists of draft-arkko-mipshop-cga-cba-03 -- No information found for draft-daley-mip6-locpriv - is the name correct? == Outdated reference: A later version (-05) exists of draft-dupont-mipv6-3bombing-03 == Outdated reference: A later version (-06) exists of draft-dupont-mipv6-rrcookie-02 == Outdated reference: A later version (-03) exists of draft-haddad-momipriv-problem-statement-02 == Outdated reference: A later version (-09) exists of draft-ietf-dna-protocol-00 == Outdated reference: draft-ietf-hip-base has been published as RFC 5201 == Outdated reference: draft-ietf-ipv6-node-requirements has been published as RFC 4294 == Outdated reference: draft-ietf-ipv6-optimistic-dad has been published as RFC 4429 == Outdated reference: draft-ietf-mip6-bootstrap-ps has been published as RFC 4640 == Outdated reference: draft-ietf-mip6-location-privacy-ps has been published as RFC 4882 -- No information found for draft-ietf-mip6-precfgKbmm - is the name correct? == Outdated reference: draft-ietf-nemo-ro-problem-statement has been published as RFC 4888 == Outdated reference: draft-ietf-nemo-ro-space-analysis has been published as RFC 4889 -- Obsolete informational reference (is this intentional?): RFC 3344 (ref. '42') (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 4068 (ref. '49') (Obsoleted by RFC 5268) -- Obsolete informational reference (is this intentional?): RFC 4140 (ref. '50') (Obsoleted by RFC 5380) Summary: 5 errors (**), 0 flaws (~~), 24 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Vogt 3 Internet-Draft Universitaet Karlsruhe (TH) 4 Expires: November 6, 2006 J. Arkko 5 Ericsson Research NomadicLab 6 May 5, 2006 8 A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route 9 Optimization 10 draft-irtf-mobopts-ro-enhancements-08.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 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 30 http://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 November 6, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 This document describes and evaluates strategies to enhance Mobile 44 IPv6 Route Optimization, on the basis of existing proposals, in order 45 to motivate and guide further research in this context. This 46 document is a product of the IP Mobility Optimizations (MobOpts) 47 Research Group. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1 A Note on Public Key Infrastructures . . . . . . . . . . . 4 53 1.2 A Note on Source Address Filtering . . . . . . . . . . . . 5 54 2. Objectives for Route Optimization Enhancement . . . . . . . 7 55 2.1 Latency Optimizations . . . . . . . . . . . . . . . . . . 8 56 2.2 Security Enhancements . . . . . . . . . . . . . . . . . . 8 57 2.3 Signaling Optimizations . . . . . . . . . . . . . . . . . 9 58 2.4 Robustness Enhancements . . . . . . . . . . . . . . . . . 9 59 3. Enhancements Toolbox . . . . . . . . . . . . . . . . . . . . 9 60 3.1 IP-Address Tests . . . . . . . . . . . . . . . . . . . . . 9 61 3.2 Protected Tunnels . . . . . . . . . . . . . . . . . . . . 10 62 3.3 Optimistic Behavior . . . . . . . . . . . . . . . . . . . 10 63 3.4 Proactive IP-Address Tests . . . . . . . . . . . . . . . . 11 64 3.5 Concurrent Care-of Address Tests . . . . . . . . . . . . . 12 65 3.6 Diverted Routing . . . . . . . . . . . . . . . . . . . . . 13 66 3.7 Credit-Based Authorization . . . . . . . . . . . . . . . . 14 67 3.8 Heuristic Monitoring . . . . . . . . . . . . . . . . . . . 17 68 3.9 Crypto-Based Identifiers . . . . . . . . . . . . . . . . . 18 69 3.10 Pre-Configuration . . . . . . . . . . . . . . . . . . . 19 70 3.11 Semi-Permanent Security Associations . . . . . . . . . . 20 71 3.12 Delegation . . . . . . . . . . . . . . . . . . . . . . . 21 72 3.13 Mobile Networks . . . . . . . . . . . . . . . . . . . . 21 73 3.14 Location Privacy . . . . . . . . . . . . . . . . . . . . 22 74 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 22 75 4.1 Cross-Layer Interactions . . . . . . . . . . . . . . . . . 23 76 4.2 Experimentation and Measurements . . . . . . . . . . . . . 23 77 4.3 Future Research . . . . . . . . . . . . . . . . . . . . . 24 78 5. Security Considerations . . . . . . . . . . . . . . . . . . 24 79 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 25 80 7. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 25 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 82 8.1 Normative References . . . . . . . . . . . . . . . . . . . 26 83 8.2 Informative References . . . . . . . . . . . . . . . . . . 26 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31 85 Intellectual Property and Copyright Statements . . . . . . . 32 87 1. Introduction 89 Mobility support for IPv6, or Mobile IPv6, enables mobile nodes to 90 migrate active transport connections and application sessions from 91 one IPv6 address to another. The Mobile IPv6 specification, RFC 3775 92 [1], introduces a "home agent", which proxies a mobile node at a 93 permanent "home address". A roaming mobile node connects to the home 94 agent through a bidirectional tunnel and can so communicate, from its 95 local "care-of address", as if it was present at the home address. 96 The mobile node keeps the home agent updated on its current care-of 97 address via IPsec-protected signaling messages. 99 In case the correspondent node lacks appropriate mobility support, it 100 communicates with the mobile node's home address, and thus all data 101 packets are routed via the home agent. This mode, Bidirectional 102 Tunneling, increases packet-propagation delays. RFC 3775 hence 103 defines an additional mode for Route Optimization, which allows peers 104 to communicate on the direct path. It requires that the 105 correspondent node can cache a binding between the mobile node's home 106 address and current care-of address. The challenge with Route 107 Optimization is that an administrative relationship between the 108 mobile node and the correspondent node can generally not be 109 presupposed. So how can the two authenticate and authorize the 110 signaling messages that they exchange? 112 Mobile IPv6 solves this problem by verifying a routing property of 113 the mobile node. Specifically, the mobile node is checked to be 114 reachable at its home address and current care-of address. This is 115 called the "return-routability procedure". It takes place right 116 before a mobile node registers a new care-of address with a 117 correspondent node and is periodically repeated in case the mobile 118 node does not move for a while. 120 The advantage of the return-routability procedure is that it is 121 lightweight and does not require pre-shared authentication material. 122 It also requires no state at the correspondent node. On the other 123 hand, the two reachability tests can lead to a handoff delay 124 unacceptable for many real-time or interactive applications like 125 voice over IP (VoIP) and video conferencing. Also, the security that 126 the return-routability procedure guarantees might not be sufficient 127 for security-sensitive applications. And finally, periodically 128 refreshing a registration at a correspondent node implies a hidden 129 signaling overhead that may prevent mobile nodes from hibernation 130 during times of inactivity. 132 Manifold enhancements for Route Optimizations have hence been 133 suggested. This document describes and evaluates various strategies 134 on the basis of existing proposals. It is meant to provide a 135 conceptual framework for further work, which was found to be 136 inevitable in the context of Route Optimization. Many scientists 137 volunteered to review this document. Their names are duly recorded 138 in Section 7. Section 2 analyzes the strengths and weaknesses of 139 Route Optimization and identifies potential objectives for 140 enhancement. Different enhancement strategies are discussed, based 141 on existing proposals, in Section 3. Section 4 discusses the 142 different approaches and identifies opportunities for further 143 research. Section 5 and Section 6 conclude the document. 145 This document represents the consensus of the MobOpts Research Group. 146 It has been reviewed by the Research Group members active in the 147 specific area of work. At the request of their chairs, this document 148 has been comprehensively reviewed by multiple active contributors to 149 the IETF MIP6 Working Group. 151 1.1 A Note on Public Key Infrastructures 153 Mobile IPv6 Route Optimization verifies a mobile node's authenticity 154 through a routing property. An alternative is cryptographic 155 authentication, which requires a binding between a node's identity 156 and some sort of secret information. While some proposals suggest to 157 install shared secrets into end nodes when possible (cf. 158 Section 3.10), pre-configuration is not an option for general 159 Internet use for scalability reasons. Authentication based on a 160 public-key infrastructure (PKI) does not require pair-wise pre- 161 configuration. Here, the secret information is the private component 162 of a public/private key pair, and the binding between a node's 163 identity and private key exists indirectly through the cryptographic 164 properties of public/private key pairs and a binding between the 165 identity and the public key. An authority trusted by both end nodes 166 issues a certificate which effects this latter binding. 168 Large-scale use of a PKI, however, was considered unsuitable for 169 mobility management due to the following reasons. 171 o There are differing opinions on whether a PKI could scale up to 172 hundreds of millions of mobile nodes. Some people argue they do, 173 as there are already examples of certification authorities 174 responsible for millions of certificates. But more important than 175 the expected increase in the number of certificates would be a 176 shift in application patterns. Nowadays, public-key cryptography 177 is used only for those applications that require strong, 178 cryptographic authentication. If it was used for mobility 179 management as well, certificate checks would become mandatory for 180 any type of application, leading to more checks per user. Busy 181 servers with mobility support might be unwilling to spent the 182 processing resources required for this depending on the service 183 they provide. 185 o Revoked certificates are identified on Certificate Revocation 186 Lists (CRLs), which correspondent nodes with mobility support 187 would have to acquire from certification authorities. CRLs must 188 be kept up to date, requiring periodic downloads. This and the 189 act of checking a certificate against a CRL create overhead which 190 some correspondent nodes might be unwilling to spend. 192 o Certificate verification may take some time and hence interrupt 193 ongoing applications. This can be disturbing from the user's 194 perspective, especially when Route Optimization starts in the 195 middle of a session, or the session is very short-term anyway. 197 o The bigger a PKI grows, the more attractive it becomes as an 198 attack target, endangering the Internet as a whole. 200 o There is little experience with using home addresses as 201 identifiers in certificates. Although the home address could 202 theoretically be placed into a certificate's Alternate Name field, 203 the entities responsible for IP-address assignment and 204 certification are usually not the same, and it may not be easy to 205 coordinate the two. 207 For these reasons, this document does not consider direct 208 authentication of mobile nodes based on a PKI. Nevertheless, it does 209 evaluate certificate-based techniques which make the problems 210 identified above more tractable (cf. Section 3.12). 212 1.2 A Note on Source Address Filtering 214 RFC 3775 uses care-of-address tests to probe a mobile node's presence 215 at its claimed location. Alternatively, verification of care-of 216 addresses may be based on infrastructure in the mobile node's local 217 access network. For instance, the infrastructure can verify that the 218 IP source addresses of all packets leaving the network are correct. 219 "Ingress filtering" [41][47] provides this feature to the extent that 220 it inspects the prefix of IP source addresses and ensures topological 221 correctness. Network-access providers who use ingress filtering 222 normally deploy the technique in their first-hop and site-exit 223 routers. Similarly, ISPs may filter packets originating from a 224 downstream network. 226 Ingress filtering may eventually provide a way to replace care-of- 227 address tests. But there are still a number of uncertainties today: 229 o By definition, ingress filtering can prevent source-address 230 spoofing only from those networks that do deploy the technique. 231 As a consequence, ingress filtering needs to be widely, preferably 232 universally, deployed in order to constitute Internet-wide 233 protection. As long as an attacker can get network access without 234 filters, all Internet nodes remain vulnerable. 236 o There is little incentive for ISPs to deploy ingress filtering 237 other than conscientiousness. Legal or regulatory prescription as 238 well as financial motivation does not exist. A corrupt ISP might 239 even have a financial incentive to not deploy the technique, if 240 redirection-based DoS attacks using Route Optimization ever become 241 possible and are exploited for financial gain. A similar issue 242 was, e.g., observed with email spam. 244 o Ingress filtering is most effective, and easiest to configure, at 245 the first-hop router. However, since only prefixes are checked, 246 the filters inevitably get less precise the further upstream they 247 are enforced. This issue is inherent in the technique, so the 248 best solution is checking packets as close to the originating 249 nodes as possible, preferably in the first-hop routers themselves. 251 o A popular implementation of ingress filtering is "Reverse Path 252 Forwarding" (RPF). This technique relies on routes to be 253 symmetric, which is oftentimes the case between edge networks and 254 ISPs, but far less often between peering ISPs. Alternatives to 255 RPF are either manual configured access lists, or dynamic 256 approaches which are more relaxed, and thereby less secure, than 257 RPF [47]. 259 o Another problem with ingress filtering is multi-homing. When a 260 router attempts to forward to one ISP a packet with a source- 261 address prefix from another ISP, filters at the second ISP would 262 block the packet. The IETF seeks to find a way around this [43]. 263 For instance, one could tunnel the packet to the topologically 264 correct ISP, or one could allow source-address changes by means of 265 a locator-identifier split [51]. 267 o Finally, RFC 3775 defines an Alternative Care-of Address option 268 that mobile nodes can use to carry a care-of address within a 269 Binding Update message outside of the IPv6 header. Such an 270 address is not subject to inspection by ingress filtering and 271 would have to be verified through other means [14]. 273 Although these problems are expected to get solved eventually, there 274 is currently little knowledge on how applicable and deployable, as a 275 candidate for care-of-address verification, ingress filtering will 276 be. High investments or administrative hurdles could prevent a 277 large, preferably universal deployment of ingress filtering, which 278 would hinder Internet-wide protection, as mentioned in the first 279 bullet. For these reasons, this document does not consider ingress 280 filtering as a viable alternative to care-of-address tests, although 281 things may be different in the future. 283 2. Objectives for Route Optimization Enhancement 285 Wireless environments with frequently moving nodes feature a number 286 of salient properties that distinguish them from environments with 287 stationary nodes or nodes that move only occasionally. One important 288 aspect is the efficiency of mobility management. Nodes may not 289 bother about a few round-trip times of handoff latency if they do not 290 change their point of IP attachment often. But the negative impact 291 that a mobility protocol can have on application performance 292 increases with the level of mobility. Therefore, in order to 293 maximize user satisfaction, it is important to reduce the handoff 294 latency which the mobility protocol adds to existing delays in other 295 places of the network stack. A related issue is the robustness of 296 the mobility protocol, given that temporary outage of mobility 297 support can render mobile nodes incapable of continuing to 298 communicate. 300 Furthermore, the wireless nature of data transmissions makes it 301 potentially easier for an attacker to eavesdrop on other nodes' data 302 or send data on behalf of other nodes. While applications can 303 usually authenticate and encrypt their payload if need be, similar 304 security measures may not be feasible for signaling packets of a 305 mobility protocol, in particular if communicating end nodes have no 306 pre-existing relationship. 308 Given the typically limited bandwidth in a wireless medium, resources 309 ought to be spent in an economic matter. This is especially 310 important for the amount of signaling that a mobility protocol 311 requires. 313 Endeavors to enhance RFC 3775 Route Optimization generally strive for 314 reduced handoff latency, higher security, lower signaling overhead, 315 or increased protocol robustness. These objectives are herein 316 discussed from a requirements perspective; the technical means to 317 reach the objectives is not considered, nor is the feasibility of 318 achieving them. 320 2.1 Latency Optimizations 322 One important objective for improving Route Optimization is to reduce 323 handoff latencies. Assuming that the home-address test dominates the 324 care-of-address test in terms of latency, a Mobile IPv6 handoff takes 325 one round-trip time between the mobile node and the home agent for 326 the home registration, a round-trip time between the mobile node and 327 the home agent plus a round-trip time between the home agent and the 328 correspondent node for the home-address test, and a one-way time from 329 the mobile node to the correspondent node for the propagation of the 330 Binding Update message. The first packet sent to the new care-of 331 address requires an additional one-way time to propagate from the 332 correspondent node to the mobile node. The mobile node can resume 333 communications right after it has dispatched the Binding Update 334 message. But if it requests a Binding Acknowledgment message from 335 the correspondent node, communications are usually delayed until this 336 is received. 338 These delays are additive and are not subsumed by other delays at IP 339 layer or link layer. They can cause perceptible quality degradations 340 for interactive and real-time applications. TCP bulk-data transfers 341 are likewise affected since long handoff latencies may lead to 342 successive retransmission timeouts and degraded throughput. 344 2.2 Security Enhancements 346 The return-routability procedure was designed with the objective to 347 provide a level of security which compares to that of today's non- 348 mobile Internet [52]. As such, it protects against impersonation, 349 denial of service, and redirection-based flooding attacks that would 350 not be possible without Route Optimization. This approach is based 351 on an assumption that a mobile Internet cannot become any safer than 352 the non-mobile Internet. 354 Applications that require a security level higher than what the 355 return-routability procedure can provide are generally advised to use 356 end-to-end protection such as IPsec or TLS. But even then are they 357 vulnerable to denial of service. This motivates research for 358 stronger Route Optimization security. Security enhancements may also 359 become necessary if future technological improvements mitigate some 360 of the existing mobility-unrelated vulnerabilities. 362 One particular issue with Route Optimization is location privacy 363 because route-optimized packets carry both home and care-of addresses 364 in plaintext. A standard workaround is to fall back to Bidirectional 365 Tunneling when location privacy is needed. Packets with the care-of 366 address are then transferred only between the mobile node and the 367 home agent, where they can be encrypted through IPsec ESP [46]. But 368 even Bidirectional Tunneling requires the mobile node to periodically 369 re-establish IPsec security associations with the home agent so as to 370 become 0 through SPIs. 372 2.3 Signaling Optimizations 374 Route Optimization requires periodic signaling even when the mobile 375 node does not move. The signaling overhead amounts to 7.16 bits per 376 second if the mobile node communicates with a stationary node [6]. 377 It doubles if both peers are mobile. This overhead may be negligible 378 when the nodes communicate, but it can be an issue for mobile nodes 379 that are inactive and stay at the same location for a while. These 380 nodes typically prefer to go to standby mode to conserve battery 381 power. Also, the periodic refreshments consume a fraction of the 382 wireless bandwidth that one could use more efficiently. 383 Optimizations for reduced signaling overhead could mitigate these 384 issues. 386 2.4 Robustness Enhancements 388 Route Optimization could conceptually enable continued communications 389 during periods of temporary home-agent unavailability. The protocol 390 defined in RFC 3775 does not achieve this independence, however, as 391 the home agent plays an active role in the return-routability 392 procedure. Appropriate enhancements could increase the independence 393 from the home agent and thus enable robust Route Optimization even in 394 the absence of the home agent. 396 3. Enhancements Toolbox 398 A large body of effort has recently gone into improving Mobile IPv6 399 Route Optimization. Some of the proposed techniques are 400 modifications to the return-routability procedure, while others 401 replace the procedure by alternative mechanisms. Some of them 402 operate end-to-end, others introduce network-side mobility support. 403 In most cases, it is the combination of a set of techniques that is 404 required to gain a complete---i.e., efficient and secure---route- 405 optimization mechanism. 407 3.1 IP-Address Tests 409 RFC 3775 uses IP-address tests to ensure that a mobile node is live 410 and on the path to a specific destination address: The home-address 411 test provides evidence that the mobile node is the legitimate owner 412 of its home address; the care-of-address test detects spoofed care-of 413 addresses and prevents redirection-based flooding attacks. Both 414 tests can be performed in parallel. 416 A home-address test should be initiated by the mobile node so that 417 the correspondent node can delay state creation until the mobile node 418 has authenticated. The care-of-address test can conceptually be 419 initiated by either side. It originates with the mobile node in RFC 420 3775, but with the correspondent node in [16] and [22]. The 421 correspondent-node-driven approach suggests itself when 422 authentication is done through other means than a home-address test. 424 Important advantages of IP-address tests are zero-configurability and 425 the independence of ancillary infrastructure. As a disadvantage, IP- 426 address tests can only guarantee that a node is on the path to the 427 probed address, not that the node truly owns this address. This does 428 not lead to new security threats, however, because the types of 429 attacks that an on-path attacker can do with Route Optimization are 430 already possible in the non-mobile Internet [52]. 432 3.2 Protected Tunnels 434 RFC 3775 protects certain signaling messages, exchanged between a 435 mobile node and its home agent, through an authenticated and 436 encrypted tunnel. This prevents unauthorized nodes on that path, 437 including eavesdroppers in the mobile node's wireless access network, 438 from reading a home keygen token. 440 Given that a pre-existing end-to-end security relationship between 441 the mobile node and the correspondent node cannot generally be 442 assumed, this protection exists only for the mobile node's side. If 443 the correspondent node is immobile, the path between the home agent 444 and the correspondent node remains unprotected. This is a path 445 between two stationary nodes, so all types of attacks that a villain 446 could wage on this path are already possible in the non-mobile 447 Internet. In case the correspondent node is mobile, it has its own 448 home agent, and only the path between the two (stationary) home 449 agents remains unprotected. 451 3.3 Optimistic Behavior 453 Many Mobile IPv6 implementations [31][33] defer a correspondent 454 registration until the associated home registration has been 455 completed successfully. In contrast to such "conservative" behavior, 456 a more "optimistic" approach is to begin the return-routability 457 procedure in parallel with the home registration [59]. Conservative 458 behavior avoids a useless return-routability procedure in case the 459 home registration fails. This comes at the cost of additional 460 handoff delay when the home registration is successful. Optimistic 461 behavior saves this delay, but the return-routability procedure will 462 be in vain should the corresponding home registration be 463 unsuccessful. 465 While a parallelization of the home registration and the return- 466 routability procedure is feasible within the bounds of RFC 3775, the 467 specification does not permit mobile nodes to continue with the 468 correspondent registration, by sending a Binding Update message to 469 the correspondent node, until a Binding Acknowledgment message 470 indicating successful home registration has been received. This is 471 usually not a problem because the return-routability procedure is 472 likely to take longer than the home registration anyway. However, 473 some optimizations (cf. Section 3.4) reduce the delay caused by the 474 return-routability procedure. A useful improvement is then to allow 475 Binding Update messages to be sent to correspondent nodes even before 476 the home registration has been acknowledged. 478 The drawback of optimistic behavior is that a lost, reordered, or 479 rejected Binding Update message can cause data packets to be 480 discarded. Nevertheless, packet loss would have similar, negative 481 impacts on conservative approaches, so the mobile node needs to be 482 prepared for the possible loss of these packets in any case. 484 3.4 Proactive IP-Address Tests 486 The critical handoff phase, during which the mobile node and the 487 correspondent node cannot fully communicate, spans the home 488 registration and the correspondent registration, including the 489 return-routability procedure. One technique to shorten this phase is 490 to accomplish part of the signaling proactively before the handoff. 491 In particular, the home-address test can be done in advance without 492 violating the specifications of RFC 3775 [59][58]. 494 In order to have a fresh home keygen token ready for a future 495 handoff, the mobile node should initiate a proactive home-address 496 test at least once per token lifetime, i.e., every 3.5 minutes. This 497 does at most double the signaling overhead spent on home-address 498 tests given that correspondent registrations must be refreshed every 499 7 minutes even when the mobile node does not move for a while. An 500 optimization is possible where the mobile node's local link layer can 501 anticipate handoffs and trigger the home-address test in such a case. 502 [6] or [61] reduce the frequency of home-address tests even further. 504 Proactive care-of-address tests are possible only if the mobile node 505 is capable of attaching to two networks simultaneously. Dual 506 attachment is possible if the link-layer technology enables it with a 507 single interface [10], or if the mobile node is endowed with multiple 508 interfaces [7]. 510 3.5 Concurrent Care-of Address Tests 512 Without the assumption that a mobile node can simultaneously attach 513 to multiple networks, proactive care-of-address tests, executed prior 514 to handoff, are not an option. A correspondent node may instead 515 authorize a mobile node to defer the care-of-address test until an 516 early, tentative binding has been registered [59][58]. This in 517 combination with a technique to eliminate the handoff delay of home- 518 address tests (cf. Section 3.4 and Section 3.9) facilitates early 519 resumption of bidirectional communications subsequent to handoff. 520 The care-of address is called "unverified" during the concurrent 521 care-of-address test, and it is said to be "verified" once the 522 correspondent node has obtained evidence that the mobile node is 523 present at the address. A tentative binding's lifetime can be 524 limited to a few seconds. 526 Home-address tests must not be accomplished concurrently, however, 527 given that they serve the purpose of authentication. They guarantee 528 that only the legitimate mobile node can create or update a binding 529 pertaining to a particular home address. 531 mobile node home agent correspondent node 532 | | | 533 | | | 534 |--Home Test Init------>|---------------------->| 535 | | | 536 | | | 537 |<----------------------|<-----------Home Test--| 538 | | | 539 | | 540 ~~+~~ handoff | 541 | | 542 |--Early Binding Update------------------------>| -+- 543 |--Care-of Test Init -------------------------->| | 544 | | | 545 | | | care-of 546 |<----------------Early Binding Acknowledgment--| | address 547 |<-------------------------------Care-of Test---| | unverified 548 | | | 549 | | | 550 |--Binding Update------------------------------>| -+- 551 | | 552 | | 553 |<----------------------Binding Acknowledgment--| 554 | | 556 Figure 1: Concurrent Care-of Address Tests 558 Figure 1 illustrates how concurrent care-of-address tests are used in 559 [59][58]: As soon as the mobile node has configured a new care-of 560 address after a handoff, it sends to the correspondent node an Early 561 Binding Update message. Only a home keygen token, obtained from a 562 proactive home-address test, is required to sign this message. The 563 correspondent node creates a tentative binding for the new, 564 unverified care-of address when it receives the Early Binding Update 565 message. This address can be used immediately. The mobile node 566 finally sends a (standard) Binding Update message to the 567 correspondent node when the concurrent care-of-address test is 568 complete. Credit-Based Authorization (cf. Section 3.7) prevents 569 misuse of care-of addresses while they are unverified. 571 3.6 Diverted Routing 573 Given that a home registration is faster than a correspondent 574 registration in the absence of additional optimizations, the mobile 575 node may request its traffic to be routed through the home address 576 until a new binding has been set up at the correspondent node 578 [59][58]. The performance of such diverted routing depends on the 579 propagation properties of the involved routes, however. 581 For packets to be diverted via the home address, signaling is 582 necessary with both the home agent and the correspondent node. The 583 home agent must be informed about the new care-of address so that it 584 can correctly forward packets intercepted at the home address. The 585 correspondent node continues to send packets to the old care-of 586 address until it receives a Binding Update message indicating that 587 the current binding is no longer valid and ought to be removed. This 588 request requires authentication through a home-address test in order 589 to prevent denial of service by unauthorized nodes. The test can be 590 accomplished in a proactive way (cf. Section 3.4). 592 The mobile node may send packets via the home address as soon as it 593 has dispatched the Binding Update message to the home agent. It may 594 send outgoing packets along the direct path once a Binding Update 595 message for the new care-of address has been sent to the 596 correspondent node. 598 It depends on the propagation latency on the end-to-end path via the 599 home agent relative to the latency on the direct path for how long 600 the correspondent node should continue to send packets to the home 601 address. If the former path is slow, it may be better to queue some 602 of the packets until the correspondent registration is complete and 603 packets can be sent along the direct route. 605 3.7 Credit-Based Authorization 607 Concurrent care-of-address tests (cf. Section 3.5) require protection 608 against spoofed unverified care-of addresses and redirection-based 609 flooding attacks. Credit-Based Authorization [57] is a technique 610 that provides such protection based on the following three 611 hypotheses: 613 1. A flooding attacker typically seeks to somehow multiply the 614 packets it assembles for the purpose of the attack because 615 bandwidth is an ample resource for many attractive victims. 617 2. An attacker can always cause unamplified flooding by generating 618 bogus packets itself and sending them to its victim directly. 620 3. Consequently, the additional effort required to set up a 621 redirection-based flooding attack pays off for the attacker only 622 if amplification can be obtained this way. 624 On this basis, rather than eliminating malicious packet redirection 625 in the first place, Credit-Based Authorization prevents any 626 amplification that can be reached through it. This is accomplished 627 by limiting the data a correspondent node can send to an unverified 628 care-of address of a mobile node by the data that the correspondent 629 node has recently received from that mobile node. (See Section 3.5 630 for a definition on when a care-of address is verified and when it is 631 unverified.) A redirection-based flooding attack is thus no more 632 attractive than pure direct flooding, where the attacker itself sends 633 bogus packets to the victim. It is actually less attractive given 634 that the attacker must keep Mobile IPv6 state to coordinate the 635 redirection. 637 mobile node correspondent node 638 | | 639 | | 640 address |--data----------------->| credit += size(data) 641 verified | | 642 |--data----------------->| credit += size(data) 643 |<-----------------data--| don't change credit 644 | | 645 address + address change | 646 unverified |<-----------------data--| credit -= size(data) 647 |--data----------------->| credit += size(data) 648 |<-----------------data--| credit -= size(data) 649 | | 650 |<-----------------data--| credit -= size(data) 651 | X credit < size(data) ==> drop! 652 | | 653 address | | 654 verified |<-----------------data--| don't change credit 655 | | 657 Figure 2: Credit-Based Authorization 659 Figure 2 illustrates Credit-Based Authorization for an exemplifying 660 exchange of data packets: The correspondent node measures the bytes 661 received from the mobile node. When the mobile node registers a new 662 care-of address, the correspondent node labels this address 663 "unverified" and sends packets there as long as the sum of the packet 664 sizes does not exceed the measured, received data volume. A 665 concurrent care-of-address test is meanwhile performed. Once the 666 care-of address has been verified, the correspondent node relabels 667 the address from "unverified" to "verified". Packets can then be 668 sent to the new care-of address without restrictions. When 669 insufficient credit is left while the care-of address is still 670 "unverified", the correspondent node stops sending further packets to 671 the address until the verification completes. The correspondent node 672 may drop these packets, direct them to the mobile node's home 673 address, or buffer them for later transmission when the care-of 674 address is verified. Figure 2 does not show Mobile IPv6 signaling 675 packets. 677 The correspondent node ensures that the mobile node's acquired credit 678 gradually decreases over time. This "aging" prevents the mobile node 679 from building up credit over a long time. A malicious node with a 680 slow Internet connection could otherwise provision for a burst of 681 redirected packets which does not relate to its own upstream 682 capacity. 684 Allocating the mobile node's credit based on the packets that the 685 mobile node sends and reducing the credit based on packets that the 686 mobile node receives is defined as "Inbound Mode". (The 687 correspondent node is in control of credit allocation, and it 688 computes the credit based on inbound packets received from the mobile 689 node.) A nice property of Inbound Mode is that it does not require 690 support from the mobile node. The mobile node neither needs to 691 understand that Credit-Based Authorization is effective at the 692 correspondent node, nor does it have to have an idea of how much 693 credit it has at a particular point in time. 695 Inbound Mode works fine with applications that send comparable data 696 volumes into both directions. On the other hand, the mode may 697 prevent the mobile node from collecting the amount of credit it needs 698 for a handoff when applications with asymmetric traffic patterns are 699 in use. For instance, file transfers and media streaming are 700 characterized by high throughput towards the client, typically the 701 mobile node, and comparably little throughput towards the serving 702 correspondent node. 704 An additional "Outbound Mode" was designed to better accommodate 705 applications with asymmetric traffic patterns. In Outbound Mode, 706 packets that the correspondent node sends to the mobile node 707 determine both, how much the credit increases while the current 708 care-of address is verified, and how much the credit shrinks while 709 the care-of address is unverified. This resolves the issue with 710 asymmetric traffic patterns. 712 The security of Outbound Mode is based on the further hypothesis that 713 the mobile node invests comparable effort for packet reception and 714 transmission in terms of bandwidth, memory, and processing capacity. 715 This justifies why credit, allocated for packets received by the 716 mobile node, can be turned into packets that the correspondent node 717 sends. The question is, though, how the correspondent node can 718 determine how many of the packets sent to a mobile node are actually 719 received and processed by that mobile node. Relying on transport- 720 layer acknowledgments is not an option as such messages can easily be 721 faked. Outbound Mode hence defines its own feedback mechanism, 722 Care-of Address Spot Checks, which is robust to spoofing. The 723 correspondent node periodically tags packets that it sends to the 724 mobile node with a random, unguessable number, a so-called Spot Check 725 Token. When the mobile node receives a packet with an attached Spot 726 Check Token, it buffers the token until it sends the next packet to 727 the correspondent node. The Spot Check Token is then included in 728 this packet. Upon reception, the correspondent node verifies whether 729 the returned Spot Check Token matches a token recently sent to the 730 mobile node. New credit is allocated in proportion to the ratio 731 between the number of successfully returned Spot Check Tokens and the 732 total number of tokens sent. This implies that new credit is 733 approximately proportional to the fraction of packets that have made 734 their way at least up to the mobile node's IP stack. The preciseness 735 of Care-of Address Spot Checks can be traded with overhead through 736 the frequency with which packets are tagged with Spot Check Tokens. 738 An interesting question is whether Outbound Mode could be misused by 739 an attacker with asymmetric Internet connection. Wide-spread digital 740 subscriber lines (DSL), e.g., typically have a much higher download 741 rate than upload rate. The limited upload rate would render most 742 denial-of-service attempts through direct flooding meaningless. But 743 the attacker could leverage the strong download rate to build up 744 credit at one or multiple correspondent nodes. It could then 745 illegitimately spend the credit on a stronger, redirection-based 746 flooding attack. The reason why this has so far not been considered 747 an issue is that, in order to accumulate enough credit at the remote 748 end, the attacker would first have to expose itself to the same 749 packet flood that it could then redirect towards the victim. 751 3.8 Heuristic Monitoring 753 Heuristic approaches to prevent misuse of unverified care-of 754 addresses are conceivable as well. A heuristic, implemented at the 755 correspondent node and possibly supplemented by a restrictive 756 lifetime limit for tentative bindings, can prevent, or at least 757 effectually discourage, such misuse. The challenge here seems to be 758 a feasible heuristic: On one hand, the heuristic must be 759 sufficiently rigid to quickly respond to malicious intents at the 760 other side. On the other hand, it should not have a negative impact 761 on a fair-minded mobile node's communications. 763 Another problem with heuristics is that they are usually reactive. 764 The correspondent node can only respond to misbehavior after it 765 appeared. If sanctions are imposed quickly, attacks may simply not 766 be worthwhile. Yet premature measures should be avoided. One must 767 also bear in mind that an attacker may be able to use different home 768 addresses, and it is in general impossible for the correspondent node 769 to see that the set of home addresses belongs to the same node. The 770 attacker may furthermore exploit multiple correspondent nodes for its 771 attack in an attempt to amplify the result. 773 3.9 Crypto-Based Identifiers 775 A Crypto-Based Identifier (CBID) is an identifier with a strong 776 cryptographic binding to the public component of its owner's public/ 777 private key pair [35]. This allows the owner to prove its claim on 778 the CBID: It signs a piece of data with its private key and send 779 this to the verifier along with its public key and the parameters 780 necessary to recompute the CBID. The verifier recomputes the CBID 781 and checks the owner's knowledge of the corresponding private key. 783 CBIDs offer three main advantages: First, spoofing attacks against a 784 CBID are much harder than attacks against a non-cryptographic 785 identifier like a domain name or a Mobile IPv6 home address. Though 786 an attacker can always create its own CBID, it is unlikely to find a 787 public/private key pair that produces someone else's. Second, a CBID 788 does not depend on a public-key infrastructure given its inherent 789 binding to the owner's public key. Third, a CBID can be used to bind 790 a public key to an IP address, in which case it is called a 791 Cryptographically Generated Address (CGA) [48][36][54]. A CGA is 792 syntactically just an ordinary IPv6 address. It has a standard 793 routing prefix and an interface identifier generated from a hash on 794 the CGA owner's public key and additional parameters. 796 Many applications are conceivable where CGAs are advantageous. In 797 Mobile IPv6, CGAs can bind a mobile node's home address to its public 798 key [37][5] and so avoid the home-address test in most correspondent 799 registrations. This accelerates the registration process and allows 800 the peers to communicate independently of home-agent availability. 802 Since only the interface identifier of a CGA is cryptographically 803 protected, its network prefix can be spoofed, and flooding attacks 804 against networks are still an issue. An initial home-address test is 805 hence required to validate the network prefix even when the home 806 address is a CGA. For the same reason, CGAs are rarely used as 807 care-of addresses. 809 One limitation of CGAs compared to other types of CBIDs is that the 810 cryptographically protected portion is only 62 bits long. The rest 811 of the address is occupied by a 64-bit network prefix as well as the 812 universal/local and individual/group bits. A brute-force attack 813 might thus reveal a public/private key pair that produces a certain 814 CGA. This vulnerability can be contained by including the network 815 prefix in the hash computation for the interface identifier so that 816 an attacker, in case it did find the right public/private key pair, 817 could not form CGAs for multiple networks from it. 819 To resolve collisions in generating CGAs, a collision count is part 820 of the input to the hash function. Changing this produces a 821 different CGA. Unfortunately, the collision count also reduces the 822 complexity of a brute-force attack against a CGA because it allows 823 the same private/public-key pair to be used to generate multiple 824 CGAs. The collision count is therefore limited to a few bytes only. 826 Higher security can be achieved through longer CBIDs. E.g., a node's 827 primary identifier in the Host Identity Protocol [21] is a 128-bit 828 hash on the node's public key. It is used as an IP-address 829 replacement at stack layers above IP. This CBID is not routable, so 830 there needs to be some external location mechanism if a node wants to 831 contact a peer of which it only knows the identifier. 833 3.10 Pre-Configuration 835 Where mobile and correspondent nodes can be pre-configured with a 836 shared key, bound to the mobile node's home address, authentication 837 through a home-address test can be replaced by a cryptographic 838 mechanism. This has three advantages: First, cryptography allows 839 for stronger authentication than address tests. Second, strong 840 authentication facilitates binding lifetimes longer than the seven- 841 minute limit which RFC 3775 defines for correspondent registrations. 842 Third, handoff delays are usually shorter with cryptographic 843 approaches because the round trips of the home-address test can be 844 spared. The disadvantage of pre-configuration is its limited 845 applicability. 847 Two proposals for pre-configuration are currently under discussion 848 within the IETF. [27] endows mobile nodes with the information they 849 need to compute home and care-of keygen tokens themselves rather than 850 having to obtain them through the return-routability procedure. [15] 851 uses the Internet Key Exchange protocol to establish an IPsec 852 security association between the peers. 854 From a technical standpoint, pre-configuration can only replace a 855 home-address test. A test of the care-of address is still necessary 856 to verify the mobile node's presence at that address. The problem is 857 circumvented in [27] by postulating that the correspondent node has 858 sufficient trust in the mobile node to believe that the care-of 859 address is correct. This assumption discourages the use of pre- 860 configuration in scenarios where such trust is unavailable, however. 862 E.g., a mobile-phone operator may be able to configure subscribers 863 with secret keys for authorization to a particular service, but it 864 may not be able to vouch that all subscribers use this service in a 865 responsible manner. And even if users are trustworthy, their mobile 866 nodes may become infected with malware and start behaving unreliably. 868 Another way to avoid care-of-address verification is to rely on 869 access networks to filter out packets with incorrect IP source 870 addresses [41][47]. This approach is taken in [15]. The problem 871 with local filtering is that it can only protect a network from 872 becoming the source of an attack, not from falling victim to an 873 attack. The technique is hence potentially unreliable unless 874 deployed in access networks worldwide (cf. Section 1.2). 876 Care-of-address tests facilitate the use of pre-configuration in 877 spite of lacking trust relationships or the existence of access 878 networks without local filtering techniques. For increased 879 performance, concurrent care-of-address tests can be used in 880 combination with Credit-Based Authorization or heuristic monitoring. 882 3.11 Semi-Permanent Security Associations 884 A compromise between the return-routability procedure and pre- 885 configuration are semi-permanent security associations. A semi- 886 permanent security association is established between a mobile node 887 and a correspondent node upon first contact, and used to authenticate 888 the mobile node during subsequent correspondent registrations. Semi- 889 permanent security associations eliminate the need for periodic home- 890 address tests and permit correspondent registrations with lifetimes 891 longer than the seven-minute limit specified in RFC 3775. 893 It is important to verify a mobile node's home address before a 894 security association is bound to it. An impersonator could otherwise 895 create a security association for a victim's IP address and then 896 redirect the victim's traffic at will until the security association 897 expires. An initial home-address test mitigates this vulnerability 898 because it requires the attacker to be on the path between the victim 899 and the victim's peer at least while the security association is 900 being established. Stronger security can be obtained through 901 cryptographically generated home addresses (cf. Section 3.9). 903 Semi-permanent security associations alone provide no verification of 904 care-of addresses and must therefore be supplemented by care-of- 905 address tests. These may be performed concurrently for reduced 906 handoff delays (cf. Section 3.5). Semi-permanent security 907 associations were first developed in [8] where they were called 908 "purpose-built keys". 910 3.12 Delegation 912 Section 1.1 lists numerous problems of public-key infrastructures 913 with respect to authentication of mobile nodes. These problems 914 become more tractable, however, if correspondent nodes authenticate 915 home agents rather than mobile nodes, and the home agents vouch for 916 the authenticity and trustworthiness of the mobile nodes [40]. Such 917 delegation of responsibilities solves the scalability issue with 918 public-key infrastructures given that home agents can be expected to 919 be much less numerous than mobile nodes. Certificate revocation 920 becomes less delicate as well because home agents are commonly 921 administrated by a mobility provider and should as such be more 922 accountable than mobile nodes. 924 Another advantage of delegation is that it avoids public-key 925 computations at mobile nodes. On the other hand, the processing 926 overhead at correspondent nodes increases. This may or may not be an 927 issue depending on resources available at the correspondent node 928 relative to the services that the correspondent node provides. The 929 correspondent node may also be mobile itself, in which case 930 cryptographic operations would be problematic. Furthermore, the 931 increased overhead implies a higher risk to resource-exhaustion 932 attacks. 934 3.13 Mobile Networks 936 Mobile nodes may move as a group and attach to the Internet via a 937 "mobile router" that stays with the group. This happens, e.g., in 938 trains or aircrafts where passengers communicate via a local wireless 939 network that is globally interconnected through a satellite link. 941 It is straightforward to support such network mobility [45] with a 942 single home agent and a tunnel between the mobile router and this 943 home agent. The mobile nodes themselves then do not have to be 944 mobility-aware. However, Route Optimization for moving networks 945 [39][28][29] is more complicated. One possibility is to have the 946 mobile router handle Route Optimization on behalf of the mobile 947 nodes. This requires the mobile router to modify incoming and 948 outgoing packets such that they can be routed on the direct path 949 between the end nodes. The mobile router would also have to perform 950 Mobile IPv6 signaling on behalf of the mobile nodes. Similarly, a 951 network of correspondent nodes can communicate with mobile nodes, 952 through a "correspondent router", in a route-optimized way without 953 themselves being mobility-aware. 955 3.14 Location Privacy 957 RFC 3775 fails to conceal a mobile node's current position as route- 958 optimized packets always carry both home and care-of addresses. Both 959 the correspondent node and a third party can therefore track the 960 mobile node's whereabouts. A workaround is to fall back to 961 bidirectional tunneling where location privacy is needed. Packets 962 carrying the mobile node's care-of address are thus only transferred 963 between the mobile node and the home agent, where they can be 964 encrypted through IPsec ESP [46][46]. But even then should the 965 mobile node periodically re-establish its IPsec security associations 966 so as to become untrackable through its SPIs. Early efforts on 967 location privacy in Route Optimization include [17][13][26][32]. 969 4. Discussion 971 Common to the proposals discussed in Section 3 is that all of them 972 affect a trade-off between effectiveness on one hand and economical 973 deployability, administrative overhead, as well as wide applicability 974 on the other. Effectiveness may be equated with low latency, strong 975 security, reduced signaling, or increased robustness. Economicalness 976 implies no, or only moderate, requirements in terms of hardware 977 upgrades and software modifications. Administrative overhead relates 978 to the amount of manual configuration and intervention that a 979 technique needs. 981 The standard return-routability procedure avoids costly pre- 982 configuration or new network entities. This minimizes both 983 deployment investments as well as administrative expenses. Variants 984 with optimistic behavior and proactive or concurrent IP-address tests 985 have these advantages as well. CBIDs allow for public-key 986 authentication without a public-key infrastructure. They constitute 987 a more secure alternative to home-address tests and are as such most 988 effective when combined with concurrent reachability verification. 989 CBID-based authentication may require nodes to be programmed with a 990 mapping between human-readable identifiers and the corresponding 991 CBIDs. Pre-configuration is another approach to avoid home address 992 tests. It does without computationally expensive public-key 993 algorithms, but requires pair-wise credentials and, therefore, 994 administrative maintenance. Where suitable infrastructure is 995 available, end nodes may delegate authentication and encryption tasks 996 to trusted network entities which, in turn, vouch for the end nodes. 997 Delegation could resurrect the use of certificates for the purpose of 998 mobility support. But it introduces a dependency on the delegatees, 999 adds the provisioning costs for new network entities, and is likely 1000 to be limited to communities of authorized nodes. 1002 4.1 Cross-Layer Interactions 1004 The performance of Route Optimization, as evaluated in this document, 1005 should be put into perspective of handoff-related activities in other 1006 parts of the network stack. These include link-layer attachment 1007 procedures; link-layer security mechanisms such as negotiation, 1008 authentication, and key agreement; as well as IPv6 router discovery, 1009 address configuration, and movement detection. A complete network 1010 attachment in a typical IEEE 802.11 commercial deployment requires 1011 over twenty link- and IP-layer messages. Current protocol stacks 1012 also have a number of limitations in addition to long attachment 1013 delays, such as denial-of-service vulnerabilities, difficulties in 1014 trusting a set of access nodes distributed to physically insecure 1015 locations, or the inability to retrieve sufficient information for 1016 making a handoff decision [2]. 1018 A number proposals have been put forth to improve handoff performance 1019 on different parts of the network stack, mostly focusing on handoff 1020 performance. These include link-layer parameter tuning [56], 1021 network-access authentication [18][34], as well as IPv6 router 1022 discovery [11][12], address configuration [24], and movement 1023 detection [19][20]. It is uncertain how far this optimization can be 1024 taken by only looking at the different parts individually. An 1025 integrated approach may eventually become necessary [4][60]. 1027 4.2 Experimentation and Measurements 1029 The number and diversity of mobility-related activities within a 1030 typical network stack oftentimes renders theoretical analyses 1031 insufficient and calls for additional, extensive experimentation or 1032 simulation. The following is a non-exhaustive list of areas where 1033 practical experience is likely to yield valuable insight. 1035 o Conception of a set of standard scenarios that can be used as a 1036 reference for comparable measurements and experimentation. 1037 Ideally, such standard scenarios ought to be derived from real- 1038 world environments, and they should include all features that 1039 would likely be needed in a commercial deployment. These features 1040 include link-layer access control, for instance. 1042 o Measurements of the performance impacts that existing enhancement 1043 proposals have on the different parts of the stack. 1045 o Comparisons of different implementations that are based on the 1046 same specification. For instance, it would be valuable to know 1047 how much implementations differ with regards to the use of 1048 parallelism that RFC 3775 allows in home and correspondent 1049 registrations. 1051 o Measurements of the impact that network conditions such as packet 1052 loss can have on existing and new Optimizations. 1054 o Statistical data collection on the behavior of mobile nodes in 1055 different networks. Several Route Optimization techniques behave 1056 differently depending on the degree of mobility. 1058 o Measurements of the performance that Route Optimization schemes 1059 show under different application scenarios, such as the use of 1060 applications with symmetric vs. asymmetric traffic patterns. 1062 4.3 Future Research 1064 Future research that goes beyond the techniques discussed in this 1065 document may consider the following items. 1067 o Local mobility support or local route-repair mechanisms that do 1068 not require expensive configuration. This includes 1069 infrastructure-based Route Optimization like [55]. 1071 o Care-of-address verification mechanisms that are based on Secure 1072 Neighbor Discovery. 1074 o The introduction of optimizations developed in the context of 1075 Mobile IPv6 to other mobility protocols, such as the Host Identity 1076 Protocol, the Stream Control Transmission Protocol, the Datagram 1077 Congestion Control Protocol, or link-layer mobility solutions. 1079 o The extension of the developed mobility techniques to full multi- 1080 addressing, including multi-homing. 1082 o Further strategies that are based on "asymmetric cost wars" [3], 1083 such as Credit-Based Authorization. 1085 o Integrated techniques taking into account both link- and IP-layer 1086 mobility tasks. 1088 5. Security Considerations 1090 Security issues related to Route Optimization are an integral part of 1091 this document and are as such discussed throughout the document. 1093 6. Conclusions 1095 Mobile IPv6 Route Optimization reduces packet-propagation latencies 1096 so as to facilitate interactive and real-time applications in mobile 1097 environments. Unfortunately, the end-to-end protocol's high handoff 1098 latencies hinder exactly these applications. A large body of effort 1099 has therefore recently been dedicated to Route Optimization 1100 improvements. Some of the proposed techniques operate on an end-to- 1101 end basis, others require new or extended infrastructure in the 1102 network; some need pre-configuration, others are zero-configurable. 1103 This document has compared and evaluated the different strategies 1104 based on a selected set of enhancement proposals. It stands out that 1105 all proposals make a trade-off between effectiveness on one hand---be 1106 it in terms of reduced handoff latency, increased security, or lower 1107 signaling overhead---and pre-configuration costs or requisite network 1108 upgrades on the other. An optimization's prospective investments, in 1109 turn, are in relation to its suitability for widespread deployment. 1111 However, the real-life performance of end-to-end mobility does not 1112 only depend on enhancements of Route Optimization, but ultimately on 1113 all parts of the protocol stack [2]. Related optimization endeavors 1114 are in fact gaining momentum, and a comprehensive approach towards 1115 Route Optimization must incorporate the most suitable solutions 1116 amongst them [4]. Whichever proposals will eventually reach a 1117 maturity level sufficient for standardization, any effort should be 1118 expended to arrive at that point within the foreseeable future. 1119 Route Optimization requires support from both peers and depends on a 1120 solid basis of installed implementations in correspondent nodes. 1121 This should hence be included in emerging IPv6 stacks early on. 1122 While IPv6 deployment is yet far away from becoming widespread, the 1123 sooner efficient Route Optimization will be available, the more 1124 likely that it will in the end be ubiquitously supported. 1126 7. Acknowledgment 1128 This document was thoroughly reviewed, in alphabetical order, by 1129 Samita Chakrabarti, Francis Dupont, Thierry Ernst, Gerardo Giaretta, 1130 James Kempf, Rajeev Koodli, Gabriel Montenegro, Vidya Narayanan, and 1131 Fan Zhao. The authors wish to thank these folks for their valuable 1132 comments and suggestions. 1134 8. References 1136 8.1 Normative References 1138 [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1139 IPv6", RFC 3775, June 2004. 1141 8.2 Informative References 1143 [2] Alimian, A. and B. Aboba, "Analysis of Roaming Techniques", 1144 IEEE Contribution 802.11-04/0377r1, March 2004. 1146 [3] Arkko, J. and P. Nikander, "Weak Authentication: How to 1147 Authenticate Unknown Principals without Trusted Parties", 1148 Proceedings of Security Protocols Workshop 2002, Cambridge, UK, 1149 April 16-19, 2002. 1151 [4] Arkko, J., Eronen, P., Nikander, P., and V. Torvinen, "Secure 1152 and Efficient Network Access", Proceedings of the DIMACS 1153 Workshop on Mobile and Wireless Security, November 2004. 1155 [5] Arkko, J., "Applying Cryptographically Generated Addresses and 1156 Credit-Based Authorization to Mobile IPv6", IETF Internet 1157 Draft draft-arkko-mipshop-cga-cba-03.txt (work in progress), 1158 March 2006. 1160 [6] Arkko, J. and C. Vogt, "Credit-Based Authorization for Binding 1161 Lifetime Extension", IETF Internet Draft 1162 draft-arkko-mipv6-binding-lifetime-extension-00.txt (work in 1163 progress), May 2004. 1165 [7] Bahl, P., Adya, A., Padhye, J., and A. Walman, "Reconsidering 1166 Wireless Systems With Multiple Radios", ACM SIGCOMM Computer 1167 Communication Review, ACM Press, Vol. 34, No. 5, October 2004. 1169 [8] "A Framework for Purpose-Built Keys (PBK)", IETF Internet Draft 1170 draft-bradner-pbk-frame-06.txt (work in progress). 1172 [9] Castellucia, C., Montenegro, G., Laganier, J., and C. Neumann, 1173 "Hindering Eavesdropping via IPv6 Opportunistic Encryption", 1174 Proceedings of the European Symposium on Research in Computer 1175 Security, Lecture Notes in Computer Science, Springer-Verlag, 1176 September 2004. 1178 [10] Chandra, R., Bahl, P., and P. Bahl, "MultiNet: Connecting to 1179 Multiple IEEE 802.11 Networks Using a Single Wireless Card", 1180 Proceedings of the IEEE INFOCOM, IEEE, Vol. 2, March 2004. 1182 [11] Daley, G., Pentland, B., and R. Nelson, "Effects of Fast 1183 Routers Advertisement on Mobile IPv6 Handovers", Proceedings of 1184 the International Symposium on Computers and Communication, 1185 IEEE, Vol. 1, June 2003. 1187 [12] Daley, G., Pentland, B., and R. Nelson, "Movement Detection 1188 Optimizations in Mobile IPv6", Proceedings of the IEEE 1189 International Conference on Networks, IEEE, September 2003. 1191 [13] Daley, G., "Location Privacy and Mobile IPv6", IETF Internet 1192 Draft draft-daley-mip6-locpriv-00.txt (work in progress), 1193 January 2004. 1195 [14] Dupont, F., "A note about 3rd party bombing in Mobile IPv6", 1196 IETF Internet Draft draft-dupont-mipv6-3bombing-03.txt (work in 1197 progress), December 2005. 1199 [15] "Using IPsec between Mobile and Correspondent IPv6 Nodes", 1200 IETF Internet Draft draft-dupont-mipv6-cn-ipsec-01.txt (work in 1201 progress), June 2004. 1203 [16] Dupont, F. and J. Combes, "Care-of Address Test for MIPv6 using 1204 a State Cookie", IETF Internet Draft 1205 draft-dupont-mipv6-rrcookie-02.txt (work in progress), 1206 December 2005. 1208 [17] Haddad, W., Nordmark, E., Dupont, F., Bagnulo, M., and B. 1209 Patil, "Privacy for Mobile and Multi-homed Nodes: MoMiPriv 1210 Problem Statement", IETF Internet Draft 1211 draft-haddad-momipriv-problem-statement-02.txt (work in 1212 progress), October 2005. 1214 [18] "IEEE Standard for Local and Metropolitan Area Networks: Port- 1215 Based Netowrk Access Control", IEEE Standard 802.1X, 1216 December 2004. 1218 [19] Choi, J. and E. Nordmark, "DNA with Unmodified Routers: Prefix 1219 List Based Approach", IETF Internet Draft 1220 draft-ietf-dna-cpl-02.txt (work in progress), January 2006. 1222 [20] Kempf, J., "Detecting Network Attachment in IPv6 Networks 1223 (DNAv6)", IETF Internet Draft draft-ietf-dna-protocol-00.txt 1224 (work in progress), February 2006. 1226 [21] Moskowitz, R., "Host Identity Protocol", IETF Internet Draft 1227 draft-ietf-hip-base-05.txt (work in progress), March 2006. 1229 [22] Henderson, T., Nikander, P., Arkko, J., Perkins, G., and C. 1231 Vogt, "End-Host Mobility and Multihoming with the Host Identity 1232 Protocol", IETF Internet Draft draft-ietf-hip-mm-03.txt (work 1233 in progress), March 2006. 1235 [23] Loughney, J., "IPv6 Node Requirements", IETF Internet Draft 1236 draft-ietf-ipv6-node-requirements-11.txt (work in progress), 1237 August 2004. 1239 [24] Moore, N., "Optimistic Duplicate Address Detection for IPv6", 1240 IETF Internet Draft draft-ietf-ipv6-optimistic-dad-07.txt (work 1241 in progress), December 2005. 1243 [25] Giaretta, G. and A. Patel, "Problem Statement for bootstrapping 1244 Mobile IPv6", IETF Internet Draft 1245 draft-ietf-mip6-bootstrap-ps-04.txt (work in progress), 1246 February 2006. 1248 [26] Koodli, R., "IP Address Location Privacy and Mobile IPv6: 1249 Problem Statement", IETF Internet Draft 1250 draft-ietf-mip6-location-privacy-ps-01.txt (work in progress), 1251 March 2006. 1253 [27] Perkins, C., "Preconfigured Binding Management Keys for Mobile 1254 IPv6", IETF Internet Draft draft-ietf-mip6-precfgKbmm-00.txt 1255 (work in progress), April 2004. 1257 [28] Ng, C., "Network Mobility Route Optimization Problem 1258 Statement", IETF Internet Draft 1259 draft-ietf-nemo-ro-problem-statement-02.txt (work in progress), 1260 December 2005. 1262 [29] Ng, C., "Network Mobility Route Optimization Solution Space 1263 Analysis", IETF Internet Draft 1264 draft-ietf-nemo-ro-space-analysis-02.txt (work in progress), 1265 February 2006. 1267 [30] Arbaugh, W. and B. Aboba, "Experimental Handoff Extension to 1268 RADIUS", IETF Internet Draft draft-irtf-aaaarch-handoff-04.txt 1269 (work in progress), November 2003. 1271 [31] "Kame-Shisa", Mobile IPv6 for FreeBSD. 1273 [32] Koodli, R., "Solutions for IP Address Location Privacy in the 1274 presence of IP Mobility", IETF Internet Draft 1275 draft-koodli-mip6-location-privacy-solutions-00.txt (work in 1276 progress), February 2005. 1278 [33] Nuorvala, V., Petander, H., and A. Tuominen, "Mobile IPv6 for 1279 Linux (MIPL)". 1281 [34] Mishra, A., Ho, M., L., N., Charles, T., and W. A., "Proactive 1282 Key Distribution Using Neighbor Graphs", IEEE Wireless 1283 Communications, Vol. 11, No. 1, February 2004. 1285 [35] Montenegro, G. and Claude. Castelluccia, "Crypto-Based 1286 Identifiers (CBIDs): Concepts and Applications", ACM 1287 Transactions on Information and System Security Vol. 7, No. 1288 1, February 2004. 1290 [36] Nikander, P., "Denial-of-Service, Address Ownership, and Early 1291 Authentication in the IPv6 World", Revised papers from the 1292 International Workshop on Security Protocols, Springer-Verlag, 1293 April 2002. 1295 [37] O'Shea, G. and M. Roe, "Child-proof Authentication for MIPv6", 1296 Computer Communications Review, April 2001. 1298 [38] Paxson, V., "An Analysis of Using Reflectors for Distributed 1299 Denial-of-Service Attacks", Computer Communication Review 1300 31(3)., July 2001. 1302 [39] Perera, E., Sivaraman, V., and A. Seneviratne, "Survey on 1303 Network Mobility Support", ACM SIGCOMM Computer Communication 1304 Review, Vol. 8, No. 2, ACM Press, April 2004. 1306 [40] Bao, F., "Certificate-based Binding Update Protocol (CBU)", 1307 IETF Internet Draft 1308 draft-qiu-mip6-certificated-binding-update-03.txt (work in 1309 progress), March 2005. 1311 [41] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1312 Defeating Denial of Service Attacks which employ IP Source 1313 Address Spoofing", BCP 38, RFC 2827, May 2000. 1315 [42] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1316 August 2002. 1318 [43] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- 1319 Multihoming Architectures", RFC 3582, August 2003. 1321 [44] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 1322 Protect Mobile IPv6 Signaling Between Mobile Nodes and Home 1323 Agents", RFC 3776, June 2004. 1325 [45] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 1326 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 1327 January 2005. 1329 [46] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, 1330 December 2005. 1332 [47] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1333 Networks", BCP 84, RFC 3704, March 2004. 1335 [48] Aura, T., "Cryptographically Generated Addresses (CGA)", 1336 IETF Request for Comments 3972, March 2005. 1338 [49] Koodli,, R., "Fast Handoffs for Mobile IPv6", IETF Request for 1339 Comments 4068, July 2005. 1341 [50] Soliman, H., Castelluccia, C., El, K., and L. Bellier, 1342 "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", 1343 IETF Request for Comments 4140, August 2005. 1345 [51] Huston, G., "Architectural Approaches to Multi-homing for 1346 IPv6", IETF Request for Comments 4177, September 2005. 1348 [52] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 1349 Nordmark, "Mobile IP Version 6 Route Optimization Security 1350 Design Background", IETF Request for Comments 4225, 1351 December 2005. 1353 [53] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, 1354 "Authentication Protocol for Mobile IPv6", IETF Request for 1355 Comments 4285, January 2006. 1357 [54] Roe, M., "Authentication of Mobile IPv6 Binding Updates and 1358 Acknowledgments", IETF Internet Draft 1359 draft-roe-mobileip-updateauth-02.txt (work in progress), 1360 March 2002. 1362 [55] Vadali, R., Li, J., Wu, Y., and G. Cao, "Agent-Based Route 1363 Optimization for Mobile IP", Proceedings of the IEEE Vehicular 1364 Technology Conference, October 2001. 1366 [56] Velayos, H. and G. Karlsson, "Techniques to Reduce IEEE 802.11b 1367 MAC Layer Handoff Time", Laboratory for Communication Networks, 1368 KTH, Royal Institute of Technology, Stockholm, Sweden, TRITA- 1369 IMIT-LCN R 03:02, April 2003. 1371 [57] Vogt, C., "Credit-Based Authorization for Concurrent IP-Address 1372 Tests", Proceedings of the IST Mobile and Wireless 1373 Communications Summit, June 2005. 1375 [58] Vogt, C., Bless, R., Doll, M., and T. K\\"ufner, "Early Binding 1376 Updates for Mobile IPv6", Proceedings of the IEEE Wireless 1377 Communications and Networking Conference, IEEE, Vol. 3, 1378 March 2005. 1380 [59] Vogt, C. and M. Doll, "Efficient End-to-End Mobility Support in 1381 IPv6", Proceedings of the IEEE Wireless Communications and 1382 Networking Conference, IEEE, April 2006. 1384 [60] Vogt, C., "A Comprehensive Delay Analysis for Reactive and 1385 Proactive Handoffs with Mobile IPv6 Route Optimization", 1386 January 2006. 1388 [61] Zhao, F., "Extensions to Return Routability Test in MIP6", 1389 IETF Internet Draft draft-zhao-mip6-rr-ext-01.txt (work in 1390 progress), February 2005. 1392 Authors' Addresses 1394 Christian Vogt 1395 Institute of Telematics 1396 Universitaet Karlsruhe (TH) 1397 P.O. Box 6980 1398 76128 Karlsruhe 1399 Germany 1401 Email: chvogt@tm.uka.de 1403 Jari Arkko 1404 Ericsson Research NomadicLab 1405 FI-02420 Jorvas 1406 Finland 1408 Email: jari.arkko@ericsson.com 1410 Intellectual Property Statement 1412 The IETF takes no position regarding the validity or scope of any 1413 Intellectual Property Rights or other rights that might be claimed to 1414 pertain to the implementation or use of the technology described in 1415 this document or the extent to which any license under such rights 1416 might or might not be available; nor does it represent that it has 1417 made any independent effort to identify any such rights. Information 1418 on the procedures with respect to rights in RFC documents can be 1419 found in BCP 78 and BCP 79. 1421 Copies of IPR disclosures made to the IETF Secretariat and any 1422 assurances of licenses to be made available, or the result of an 1423 attempt made to obtain a general license or permission for the use of 1424 such proprietary rights by implementers or users of this 1425 specification can be obtained from the IETF on-line IPR repository at 1426 http://www.ietf.org/ipr. 1428 The IETF invites any interested party to bring to its attention any 1429 copyrights, patents or patent applications, or other proprietary 1430 rights that may cover technology that may be required to implement 1431 this standard. Please address the information to the IETF at 1432 ietf-ipr@ietf.org. 1434 Disclaimer of Validity 1436 This document and the information contained herein are provided on an 1437 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1438 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1439 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1440 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1441 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1442 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1444 Copyright Statement 1446 Copyright (C) The Internet Society (2006). This document is subject 1447 to the rights, licenses and restrictions contained in BCP 78, and 1448 except as set forth therein, the authors retain all their rights. 1450 Acknowledgment 1452 Funding for the RFC Editor function is currently provided by the 1453 Internet Society.