idnits 2.17.1 draft-ietf-mipshop-cga-cba-03.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2674. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2685. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2692. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2698. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (February 9, 2007) is 6284 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) ** Obsolete normative reference: RFC 3775 (ref. '1') (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 3447 (ref. '4') (Obsoleted by RFC 8017) == Outdated reference: A later version (-03) exists of draft-bagnulo-multiple-hash-cga-02 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft Ericsson Research NomadicLab 4 Expires: August 13, 2007 C. Vogt 5 Universitaet Karlsruhe (TH) 6 W. Haddad 7 Ericsson Research 8 February 9, 2007 10 Enhanced Route Optimization for Mobile IPv6 11 draft-ietf-mipshop-cga-cba-03.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 13, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document specifies an enhanced version of Mobile IPv6 route 45 optimization, providing lower handoff delays, increased security, and 46 reduced signaling overhead. 48 Intended Status 50 The intended status of this document is "Proposed Standard". 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 2.1. Handoff Latency . . . . . . . . . . . . . . . . . . . . . 6 57 2.2. Security . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 2.3. Signaling Overhead . . . . . . . . . . . . . . . . . . . . 8 59 3. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 8 60 3.1. Cryptographically Generated Home Addresses . . . . . . . . 9 61 3.2. Non-Cryptographic Care-of Addresses . . . . . . . . . . . 9 62 3.3. Semi-Permanent Security Associations . . . . . . . . . . . 9 63 3.4. Initial Home Address Tests . . . . . . . . . . . . . . . . 10 64 3.5. Concurrent Care-of Address Tests . . . . . . . . . . . . . 10 65 3.6. Credit-Based Authorization . . . . . . . . . . . . . . . . 10 66 3.7. Parallel home and correspondent registrations . . . . . . 11 67 4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 12 68 4.1. Sending Binding Update Messages . . . . . . . . . . . . . 12 69 4.2. Receiving Binding Update Messages . . . . . . . . . . . . 20 70 4.3. Sending Binding Acknowledgment Messages . . . . . . . . . 24 71 4.4. Receiving Binding Acknowledgment Messages . . . . . . . . 25 72 4.5. Sending CGA Parameters . . . . . . . . . . . . . . . . . . 27 73 4.6. Receiving CGA Parameters . . . . . . . . . . . . . . . . . 28 74 4.7. Sending Permanent Home Keygen Tokens . . . . . . . . . . . 29 75 4.8. Receiving Permanent Home Keygen Tokens . . . . . . . . . . 30 76 4.9. Renewing Permanent Home Keygen Tokens . . . . . . . . . . 30 77 4.10. Handling Payload Packets . . . . . . . . . . . . . . . . . 30 78 4.11. Credit Aging . . . . . . . . . . . . . . . . . . . . . . . 33 79 4.12. Simultaneous Movements . . . . . . . . . . . . . . . . . . 34 80 5. Option Formats and Status Codes . . . . . . . . . . . . . . . 34 81 5.1. CGA Parameters Option . . . . . . . . . . . . . . . . . . 34 82 5.2. Signature Option . . . . . . . . . . . . . . . . . . . . . 35 83 5.3. Permanent Home Keygen Token Option . . . . . . . . . . . . 36 84 5.4. Care-of Test Init Option . . . . . . . . . . . . . . . . . 37 85 5.5. Care-of Test Option . . . . . . . . . . . . . . . . . . . 37 86 5.6. CGA Parameters Request Option . . . . . . . . . . . . . . 38 87 5.7. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 39 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 41 89 6.1. Home Address Ownership . . . . . . . . . . . . . . . . . . 42 90 6.2. Care-of Address Ownership . . . . . . . . . . . . . . . . 44 91 6.3. Credit-Based Authorization . . . . . . . . . . . . . . . . 45 92 6.4. Time Shifting Attacks . . . . . . . . . . . . . . . . . . 48 93 6.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 49 94 6.6. Resource Exhaustion . . . . . . . . . . . . . . . . . . . 49 95 6.7. IP Address Ownership of Correspondent Node . . . . . . . . 50 96 7. Protocol Constants and Configuration Variables . . . . . . . . 51 97 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 98 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53 99 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 100 10.1. Normative References . . . . . . . . . . . . . . . . . . . 54 101 10.2. Informative References . . . . . . . . . . . . . . . . . . 54 102 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 55 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 59 104 Intellectual Property and Copyright Statements . . . . . . . . . . 60 106 1. Introduction 108 Mobile IPv6 route optimization [1] enables mobile and correspondent 109 nodes to communicate via a direct routing path despite changes in IP 110 connectivity on the mobile node side. Both end nodes use a stable 111 "home address" in identifying the mobile node at stack layers above 112 IP, while payload packets are sent or received via a "care-of 113 address" that routes to the mobile node's current network attachment. 114 Mobile IPv6 swaps the home and care-of addresses when a payload 115 packet traverses the IP layer. The association between a mobile 116 node's home address and care-of address is called a "binding" for the 117 mobile node. It is the responsibility of the mobile node to update 118 its binding at the correspondent node through a "correspondent 119 registration" when it changes IP connectivity. A correspondent 120 registration further involves the mobile node's home agent, which 121 proxies the mobile node at the home address and mainly serves as a 122 relay for payload packets exchanged with correspondent nodes that do 123 not support route optimization. The mobile node keeps the home agent 124 up to date about its current care-of address by means of "home 125 registrations". 127 From a security perspective, the establishment of a binding during a 128 correspondent registration requires the correspondent node to verify 129 the mobile node's ownership of both the home address and the care-of 130 address. Unprecedented impersonation and flooding threats [5] would 131 arise if correspondent nodes took liberties with respect to these 132 obligations. A correspondent registration hence incorporates a "home 133 address test" and a "care-of address test", collectively called the 134 "return routability procedure". These tests allow the correspondent 135 node to probe the mobile node's reachability at the home and care-of 136 addresses in an ad-hoc, non-cryptographic manner. Successful 137 reachability verification at both IP addresses indicates (though it 138 does not guarantee) the mobile node's ownership of the IP addresses, 139 and hence that a binding between the home address and the care-of 140 address is legitimate. 142 The advantage of the return routability procedure is that it is 143 lightweight and does not depend on a public-key infrastructure or on 144 a preexisting relationship between the mobile node and the 145 correspondent node. This facilitates a broad deployment. On the 146 other hand, the procedure has an adverse impact on handoff delays 147 since both the home address test and the care-of address test consist 148 of an end-to-end message exchange between the mobile node and the 149 correspondent node. The latency of the home address test may be 150 particularly high because it routes through the home agent. The 151 return routability procedure is also vulnerable to attackers that are 152 in a position where they can interpose in the home or care-of address 153 test. The value of interposing is limited in that the return 154 routability procedure must be repeated in intervals of at most 7 155 minutes, even in the absence of changes in IP connectivity on the 156 mobile node side. But this comes at the cost of an increased 157 signaling overhead. Much effort has therefore gone into improvements 158 for Mobile IPv6 route optimization [6] that mitigate these 159 disadvantages. 161 This document specifies Enhanced Route Optimization, an amendment to 162 route optimization in base Mobile IPv6. Enhanced Route Optimization 163 secures a mobile node's home address against impersonation through an 164 interface identifier that is cryptographically and verifiably bound 165 [2] to the public component of the mobile node's public/private-key 166 pair. The mobile node proves ownership of the home address by 167 providing evidence that it knows the corresponding private key. An 168 initial home address test validates the home address prefix; 169 subsequent home address tests are unnecessary. Enhanced Route 170 Optimization further allows mobile and correspondent nodes to resume 171 bidirectional communications in parallel with pursuing a care-of 172 address test. The latency of the home and care-of address tests are 173 therefore eliminated in most cases. The use of cryptographically 174 generated home addresses also mitigates the threat of impersonators 175 that can interpose on the home address test and thereby facilitate 176 longer binding lifetimes. This leads to increased security and a 177 reduction in signaling overhead. Cryptographically generated home 178 addresses and concurrent care-of address test are preferably applied 179 together, but a mobile node may choose to use only one of these 180 enhancements. 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 184 document are to be interpreted as described in [3]. 186 2. Objectives 188 The design of route optimization in base Mobile IPv6 is in many ways 189 conservative, leaving room to optimize handoff delay, security, and 190 signaling overhead. Enhanced Route Optimization tackles these issues 191 and thus constitutes a more progressive variant of Mobile IPv6. 193 Despite any Mobile IPv6 optimizations, it is important to take into 194 account that mobility-related activities elsewhere in the protocol 195 stack may have their own impact. For example, attachment procedures, 196 access control, and authentication at the link layer contribute their 197 own handoff delays. So do IP layer tasks such as router discovery, 198 neighbor discovery, movement detection, and IP address configuration. 200 The handoff delays and signaling overhead of Mobile IPv6 are 201 typically small compared to the total delay and overhead. The 202 improvements of Enhanced Route Optimization hence ought to be seen in 203 view of the entire protocol stack. 205 2.1. Handoff Latency 207 The typical handoff delay in base Mobile IPv6 route optimization is 208 one round-trip time between the mobile node and the home agent for 209 the home registration, one round-trip time between the mobile node 210 and the home agent plus one round-trip time between the home agent 211 and the correspondent node for the return routability procedure, and 212 one one-way time from the mobile node to the correspondent node for 213 the propagation of the Binding Update message. (The assumption here 214 is that the latency of the return routability procedure is dominated 215 by the home address test.) The first payload packet sent to the new 216 care-of address requires one additional one-way time to propagate 217 from the correspondent node to the mobile node. The mobile node can 218 resume transmissions right after it has dispatched the Binding Update 219 message. But if it requests a Binding Acknowledgment message from 220 the correspondent node, communications are usually delayed until this 221 is received. 223 Handoff delays in base Mobile IPv6 route optimization are additive to 224 other delays at IP layer or link layer. They can cause perceptible 225 quality degradations for interactive and real-time applications. TCP 226 bulk-data transfers are likewise affected since long handoff 227 latencies may lead to successive retransmission timeouts and degraded 228 throughput [7]. An objective of Enhanced Route Optimization is hence 229 a reduction of the handoff latency. 231 2.2. Security 233 The return routability procedure was designed with the objective to 234 provide a level of security which compares to that of today's non- 235 mobile Internet [5]. As such, it protects against impersonation, 236 denial-of-service, and flooding threats which do not exist in the 237 non-mobile Internet, but which the introduction of mobility would 238 introduce in the absence of appropriate countermeasures. In 239 particular, the return routability procedure satisfies the following 240 requirements: 242 o An attacker off the path from a correspondent node to a victim 243 should not be able to trick a correspondent node into redirecting 244 packets, which should normally be delivered to a victim, to itself 245 or to a third IP address. The attacker could otherwise 246 impersonate the victim to the correspondent node or cause denial 247 of service against the victim. The attacker may launch these 248 attacks from an arbitrary position, which would not necessarily 249 have to be on the path between the victim and the correspondent 250 node. 252 o An attacker off the path from a correspondent node to a victim 253 should not be able to trick the correspondent node into 254 redirecting packets, which should normally be delivered to the 255 attacker itself, to the victim. The attacker could otherwise 256 flood the victim with unrequested packets. Such "redirection- 257 based flooding" may be appealing to the attacker because the 258 burden of generating the flooding packets and sending them to the 259 victim would be on correspondent node rather than on the attacker. 260 The attacker could spoof multiple correspondent nodes into 261 flooding the same victim. This would enable the attacker to 262 impact the victim much stronger than with a direct flooding 263 attack, where the attacker itself would generate and send the 264 flooding packets. Comparable amplification is today only possible 265 through an army of compromised nodes [8]. 267 One way to cause redirection-based flooding is this: The attacker 268 could accomplish the initial TCP handshake for a voluminous file 269 download through its own IP address, and subsequently bind the 270 victim's IP address (as a care-of address) to the attacker's own 271 IP address (or home address). The correspondent node thereby 272 redirects the download to the victim. The attacker could spoof 273 acknowledgments on behalf of the victim based on the sequence 274 numbers it learned during the initial handshake in order to 275 maintain or accelerate the download. The acknowledgments would be 276 smaller and typically less than the full-sized segments that the 277 correspondent node generates, hence facilitating the 278 amplification. 280 o Attackers should not be able to cause denial of service against 281 mobile or correspondent nodes through exploiting expensive 282 computations involved in the mobility protocol. 284 The return routability procedure precludes impersonation, denial of 285 service, and redirection-based flooding by attackers that are not on 286 the path from a correspondent node to a victim, and it is 287 sufficiently lightweight not to expose expensive operations. But the 288 return routability procedure fails to protect against attackers that 289 are located on the path from the correspondent node to the victim. 290 Applications that require a higher security level are generally 291 advised to use end-to-end protection such as IPsec or TLS. But even 292 then are they vulnerable to denial of service or flooding. 293 Furthermore, end-to-end security mechanisms generally require mobile 294 and correspondent nodes to be preconfigured with authentication 295 credentials, or they depend on a public-key infrastructure. Both 296 would hinder a wide deployment of Mobile IPv6 route optimization if 297 it was a prerequisite for the protocol. An objective of Enhanced 298 Route Optimization is hence to securely authenticate mobile nodes 299 without preconfigured credentials or a public-key infrastructure, 300 even in the presence of attackers on the path from the correspondent 301 node to the victim. 303 2.3. Signaling Overhead 305 A complete correspondent registration involves 6 message 306 transmissions at the mobile node, totaling about 376 bytes [9]. This 307 signaling overhead may be acceptable if movements are infrequent. 308 For example, a mobile node that moves once every 30 minutes generates 309 an average of 1.7 bits/s of signaling traffic. Higher mobility 310 causes more substantial overhead, however. A cell size of 100 meters 311 and a speed of 120 km/h yields a change in IP connectivity every 3 s 312 and about 1,000 bits/s of signaling traffic. This is significant 313 compared to a highly compressed voice stream with a typical data rate 314 of 10,000 to 30,000 bits/s. 316 Furthermore, base Mobile IPv6 requires mobile nodes to renew a 317 correspondent registration at least every 7 minutes. The signaling 318 overhead amounts to 7.16 bits/s if the mobile node communicates with 319 a stationary node [9]. It doubles if both peers are mobile. This 320 overhead may be negligible when the nodes communicate, but it can be 321 an issue for mobile nodes that are inactive and stay at the same 322 location for a while. These nodes typically prefer to go to standby 323 mode to conserve battery power. Also, the periodic refreshments 324 consume a fraction of the wireless bandwidth that one could use more 325 efficiently. These observations lead to the objective of Enhanced 326 Route Optimization to reduce the signaling overhead of a base Mobile 327 IPv6 correspondent registrations as much as possible, in particular 328 when the mobile node does not move for a while. 330 3. Protocol Design 332 Enhanced Route Optimization consists of a set of optimizations which 333 collectively afford the achievement of the objectives discussed in 334 Section 2. These optimizations are summarized in the following. 336 3.1. Cryptographically Generated Home Addresses 338 A Mobile IPv6 binding is conceptually a packet redirection from a 339 home address to a care-of address. The home address is the source of 340 the redirection and the care-of address is the destination. The 341 packets to be redirected can hence be identified based on the home 342 address. This motivates a cryptographic ownership proof for the home 343 address. Enhanced Route Optimization applies cryptographically 344 generated home addresses for this purpose [10][11]. In general, a 345 CGA provides a strong, cryptographic binding between its interface 346 identifier and the CGA owner's public key. This facilitates a 347 cryptographic home address ownership proof without a public-key 348 infrastructure, enabling other nodes to securely and autonomously 349 authenticate the CGA owner as such, modulo the correctness of the 350 CGA's subnet prefix. Cryptographically generated home addresses can 351 supersede home address tests with the exception of an initial test 352 for validating the home address prefix. This facilitates lower 353 handoff delays and longer binding lifetimes, as well as reduced 354 signaling overhead for mobile nodes which temporarily do not move. 355 Enhanced Route Optimization also optionally enables the correspondent 356 node to prove ownership of its IP address. 358 3.2. Non-Cryptographic Care-of Addresses 360 In contrast to a home address, a care-of address does not have 361 identifying functionality. There is hence little benefit in a 362 cryptographic ownership proof of a care-of address. Given that the 363 care-of address is the destination of a packet redirection, it is 364 rather the mobile node's reachability at the care-of address which 365 matters. Enhanced Route Optimization uses care-of address tests for 366 this purpose, but allows correspondent nodes to send packets to a new 367 care-of address already before the mobile node is found to be 368 reachable there. 370 3.3. Semi-Permanent Security Associations 372 CGA-based authentication involves public-key cryptography and is 373 hence computationally much less efficient than authentication through 374 a shared secret key. The technique further requires a substantial 375 amount of supplementary CGA parameters to be piggybacked onto 376 protected messages. Enhanced Route Optimization mitigates these 377 disadvantages in that it utilizes an initial CGA-based authentication 378 to securely exchange a secret permanent home keygen token between a 379 mobile node and a correspondent node. The permanent home keygen 380 token is used to authenticate the mobile node more efficiently in 381 subsequent correspondent registrations. Mobile and correspondent 382 nodes renew the permanent home keygen token on an infrequent basis. 383 The token is therefore neither constant nor short-lived, which is why 384 the security association between the mobile node and the 385 correspondent node is called "semi-permanent". 387 3.4. Initial Home Address Tests 389 An initial home address test is necessary despite a cryptographic 390 proof of home address ownership to protect against spoofed subnet 391 prefixes in home addresses. In the complete absence of home address 392 tests, a malicious node could cryptographically generate a home 393 address with the subnet prefix of a victim network, and request a 394 correspondent node to register a binding between this spoofed home 395 address and the attacker's own care-of address. The attacker then 396 tricks the correspondent node into sending a stream of packets to the 397 care-of address and subsequently deregisters the binding or lets it 398 expire. The consequence is that the correspondent node redirects the 399 packet stream "back" to the home address, causing the victim network 400 to be flooded with unrequested packets. To preclude such misuse, an 401 initial home address test is required for the mobile node and the 402 correspondent node to establish a semi-permanent security 403 association. The home address test is, if possible, executed in 404 proactive manner so as to save a potentially costly message exchange 405 via the home agent during the critical handoff period. The home 406 address test does not need to be repeated upon subsequent movements. 408 3.5. Concurrent Care-of Address Tests 410 Enhanced Route Optimization allows a correspondent node to send 411 payload packets to a mobile node's new care-of address already before 412 the mobile node has been found to be reachable at the care-of 413 address. When the mobile node changes IP connectivity, it first 414 updates its binding at the correspondent node to the new care-of 415 address without providing a proof of reachability. The correspondent 416 node registers the new care-of address on a tentative basis and sets 417 it to UNVERIFIED state. Payload packets can then be exchanged 418 bidirectionally via the new care-of address, while the mobile node's 419 reachability at the new care-of address is verified concurrently. 420 The correspondent node moves the care-of address to VERIFIED state 421 once reachability verification completes. 423 3.6. Credit-Based Authorization 425 Concurrent care-of address tests without additional protection would 426 enable an attacker to trick a correspondent node into temporarily 427 redirecting payload packets, which would otherwise be addressed to 428 the attacker itself, to the IP address of a victim. Such 429 "redirection-based flooding" [5] may be appealing to the attacker 430 because not the attacker, but the correspondent node generates the 431 flooding packets and sends them to the victim. This enables the 432 attacker to amplify the strength of the attack to a significant 433 degree compared to a direct flooding attack where the attacker itself 434 would generate the flooding packets. 436 Enhanced Route Optimization protects against redirection-based 437 flooding attacks through the use of Credit-Based Authorization. 438 Credit-Based Authorization manages the effort that a correspondent 439 node expends in sending payload packets to a care-of address in 440 UNVERIFIED state so as to ensure that a redirection-based flooding 441 attack cannot be more effective than direct flooding. The ability to 442 send unrequested packets is an inherent property of packet-oriented 443 networks, and direct flooding is a threat that results from this. 444 Since direct flooding exists with and without mobility support, and 445 redirection-based flooding attacks cannot be any more efficient than 446 this, Credit-Based Authorization increases the security level 447 provided by Enhanced Route Optimization with respect to flooding to 448 that of the non-mobile Internet. Enhanced Route Optimization 449 therefore satisfies the objective to provide a security level 450 comparable to that of the non-mobile Internet. 452 The measuring and limiting of effort is technically realized through 453 the concept of "credit", which a correspondent node maintains to put 454 its own effort in relation to the effort that a mobile node expends 455 during regular communications with the correspondent node. The 456 correspondent node increases the credit for payload packets it 457 receives from a care-of address of the mobile node in VERIFIED state, 458 and it reduces the credit in proportion to its own effort for sending 459 payload packets to a care-of address of the mobile node in UNVERIFIED 460 state. 462 3.7. Parallel home and correspondent registrations 464 Enhanced Route Optimization enables mobile nodes to pursue a 465 correspondent registration in parallel with the respective home 466 registration. This reduces handoff delays compared to base Mobile 467 IPv6, which requires mobile nodes to wait for a Binding 468 Acknowledgment message indicating a successful home registration 469 before they initiate a correspondent registration. 471 4. Protocol Operation 473 Enhanced Route Optimization allows a mobile node to securely 474 authenticate to a correspondent node based on the CGA property of its 475 home address, and to request a concurrent care-of address test for 476 increased handoff efficiency. Depending on whether the mobile node 477 wishes to take advantage of either or both of these enhancements, the 478 messages exchanged during a correspondent registration are different. 479 This is described in the following. 481 4.1. Sending Binding Update Messages 483 A mobile node may initiate a correspondent registration for any of 484 the following reasons: 486 o To establish a new binding at a correspondent node while away from 487 its home link so that subsequent packets will be route-optimized 488 and no longer be routed through the mobile node's home agent. 490 o To update an existing binding at the correspondent node while 491 moving from one point of IP attachment to another. 493 o To follow up an early Binding Update message with a complete 494 Binding Update message after receiving a Binding Acknowledgment 495 message with a Care-of Test option. 497 o To refresh an existing binding at the correspondent node without 498 changing the current point of IP attachment. 500 o To request the correspondent node to renew an existing permanent 501 home keygen token shared between the mobile node and the 502 correspondent node (see Section 4.5). 504 o To request the correspondent node to deregister an existing 505 binding. 507 Mobile node Home agent Correspondent node 508 | | | 509 | | | 510 ~ Handoff | | 511 | | | 512 |-Binding Update--------->| | 513 |-early Binding Update + Care-of Test Init option-->| 514 | | | 515 | | | 516 |<------------Binding Ack-| | 517 |<----------early Binding Ack + Care-of Test option-| 518 | | | 519 | | | 520 |-Binding Update----------------------------------->| 521 | | | 522 | | | 523 |<--------------------------------------Binding Ack-| 524 | | | 526 Figure 1: Correspondent registration with authentication by a proof 527 of the mobile node's knowledge of a permanent home keygen token; 528 concurrent care-of address test 530 In any of these cases, the mobile node sends a Binding Update message 531 to the correspondent node. The Binding Update message is 532 authenticated by one of the following three authentication methods: 534 o If the mobile node's home address is a CGA, but the mobile node 535 does not have a permanent home keygen token in its Binding Update 536 List entry for the correspondent node, the mobile node SHOULD 537 authenticate the Binding Update message based on the CGA property 538 of its home address. This requires the mobile node to send its 539 CGA parameters and signature to the correspondent node and to pass 540 a check of reachability at the home address. 542 o If the mobile node's home address is a CGA, and the mobile node 543 has a permanent home keygen token in its Binding Update List entry 544 for the correspondent node, the mobile node MUST authenticate the 545 Binding Update message by a proof of its knowledge of the 546 permanent home keygen token. 548 o If the mobile node's home address is not a CGA, the mobile node 549 MUST authenticate the Binding Update message through a proof of 550 reachability at its home address. 552 The lifetime requested by the mobile node in the Lifetime field of 553 the Binding Update message MUST NOT exceed MAX_CGA_BINDING_LIFETIME 554 (see Section 7) if the Binding Update message is to be authenticated 555 based on the CGA property of the mobile node's home address or by a 556 proof of the mobile node's knowledge of a permanent home keygen 557 token. If the selected authentication method is a proof of the 558 mobile node's reachability at the home address, the lifetime MUST NOT 559 exceed MAX_RR_BINDING_LIFETIME [1]. It is RECOMMENDED in all cases 560 that the mobile node requests the maximum permitted lifetime in order 561 to avoid unnecessary binding refreshes and thus reduce signaling 562 overhead. The Lifetime field of a Binding Update message that 563 requests the deletion of an existing binding at the correspondent 564 node MUST be set to zero. 566 If the selected authentication method is by way of the CGA property 567 of the mobile node's home address, the mobile node includes its CGA 568 parameters and signature in the Binding Update message by adding one 569 or more CGA Parameters options (see Section 5.1) directly followed by 570 a Signature option (see Section 5.2). This is described in 571 Section 4.5. Once a permanent home keygen token has been obtained 572 from the correspondent node, the mobile node MUST authenticate all 573 subsequent Binding Update messages by a proof of its knowledge of 574 this permanent home keygen token until either the binding lifetime 575 expires, the permanent home keygen token is renewed, or the mobile 576 node explicitly deregisters the binding at the correspondent node. 577 This ensures that an attacker on the path from the correspondent node 578 to the mobile node's home address cannot downgrade the mobile node's 579 chosen authentication method to a proof of reachability at the home 580 address. The mobile node MAY choose to ignore the CGA property of 581 its home address and authenticate Binding Update messages through a 582 proof of reachability at the home address. However, this behavior 583 increases the vulnerability to on-path attackers and is therefore NOT 584 RECOMMENDED. 586 Mobile node Home agent Correspondent node 587 | | | 588 | | | 589 |-Home Test Init--------->|------------------------>| 590 | | | 591 |<------------------------|<--------------Home Test-| 592 | | | 593 | | | 594 ~ Handoff | | 595 | | | 596 |-Binding Update--------->| | 597 |-early Binding Update + Care-of Test Init option-->| 598 | | | 599 | | | 600 |<------------Binding Ack-| | 601 |<----------early Binding Ack + Care-of Test option-| 602 | | | 603 | | | 604 |-Binding Update----------------------------------->| 605 | | | 606 | | | 607 |<--------------------------------------Binding Ack-| 608 | | | 610 Figure 2: Correspondent registration with authentication based on 611 reachability verification at the home address; concurrent care-of 612 address test 614 The mobile node also includes its CGA parameters in the Binding 615 Update message when it intends to renew an existing permanent home 616 keygen token shared with the correspondent node. This is 617 accomplished, as before, by adding to the message one or more CGA 618 Parameters options and a Signature option. 620 The authenticator for the Binding Update message is calculated based 621 on a permanent or temporary home keygen token. Which type of home 622 keygen token the mobile node uses in calculating the authenticator 623 depends on the authentication method: 625 o If the Binding Update message is to be authenticated based on the 626 CGA property of the mobile node's home address, the mobile node 627 MUST use a temporary home keygen token from the correspondent 628 node. The mobile node may already have a valid temporary home 629 keygen token in its Binding Update List entry for the 630 correspondent node, or it may retrieve one through the exchange of 631 a Home Test Init message and a Home Test message. 633 o If the Binding Update message is to be authenticated by a proof of 634 the mobile node's knowledge of a permanent home keygen token, the 635 mobile node MUST use the permanent home keygen token that is has 636 in its Binding Update List entry for the correspondent node. 638 o If the Binding Update message is to be authenticated through a 639 proof of reachability at the home address, the mobile node MUST 640 use a temporary home keygen token from the correspondent node. As 641 before, the mobile node may already have a valid temporary home 642 keygen token in its Binding Update List entry for the 643 correspondent node, or it may retrieve one through the exchange of 644 a Home Test Init message and a Home Test message. 646 Unless the purpose of the Binding Update message is to delete an 647 existing binding at the correspondent node, the authenticator is also 648 calculated based on a care-of keygen token. The mobile node selects 649 this as follows: 651 o If the mobile node has a valid care-of keygen token for the to-be- 652 registered care-of address in its Binding Update List entry for 653 the correspondent node, the mobile node MUST use this in 654 calculating the authenticator for the Binding Update message. The 655 Binding Update message is in this case "complete". 657 o If the mobile node does not have a valid care-of keygen token in 658 its Binding Update List entry for the correspondent node, the 659 mobile node SHOULD define the care-of keygen token to be zero and 660 use this in calculating the authenticator for the Binding Update 661 message. The Binding Update message is in this case "early". 663 o If the mobile node does not have a valid care-of keygen token in 664 its Binding Update List entry for the correspondent node, the 665 mobile node MAY choose to retrieve a care-of keygen token through 666 the exchange of a Care-of Test Init message and a Care-of Test 667 message, as defined in [1], without sending an early Binding 668 Update message. In this case, the mobile node waits for receipt 669 of the Care-of Test message and uses the care-of keygen token 670 contained therein in calculating the authenticator for a complete 671 Binding Update message. This approach increases the handoff 672 latency, however, and is therefore NOT RECOMMENDED. 674 For reduced handoff delays, the mobile node SHOULD simultaneously 675 initiate home and correspondent registrations for a particular 676 care-of address. The mobile node SHOULD also pursue home and 677 correspondent deregistrations in parallel if it wishes to discontinue 678 Mobile IPv6 service while away from its home link. However, when the 679 mobile node commits home and correspondent deregistrations after 680 returning back to the home link after a period of roaming, the mobile 681 node MUST initiate the home deregistration first, and it MUST wait 682 for a Binding Acknowledgment message indicating a successful home 683 deregistration before it initiates the correspondent deregistration. 684 This behavior ensures that the home agent does not proxy the mobile 685 node's home address while the mobile node is on the home link, hence 686 preventing interference between the mobile node and the home agent 687 during Duplicate Address Detection. Since a home deregistration 688 consumes only a link-local round-trip time when the mobile node 689 pursues it from the home link, the cost of not parallelizing it with 690 a correspondent deregistration, in terms of increased handoff delay, 691 is typically negligible. 693 Moreover, when the Binding Update message for the correspondent 694 registration is to be authenticated based on the CGA property of the 695 mobile node's home address or through a proof of reachability at the 696 home address, the mobile node SHOULD initiate the exchange of Home 697 Test Init and Home Test messages prior to handoff in order to 698 proactively elicit a fresh home keygen token from the correspondent 699 node. This reduces handoff delays further. A Home Test Init message 700 may be sent periodically whenever the home keygen token previously 701 acquired from the correspondent node is about to expire. Tokens are 702 valid for 3.5 minutes [1], so the interval between successive Home 703 Test Init messages should be a little less. Alternatively, the 704 mobile node may be able to send the Home Test Init message right in 705 time if its link layer provides a trigger announcing imminent 706 handoff. Proactive home address tests are technically feasible 707 because a home address does not change across handoffs. 709 If the mobile node initiates the home address test from the home 710 link, it MUST address the Home Test Init message directly to the 711 correspondent node. The Home Test message will then be received 712 directly from the correspondent node. If the home address test is 713 initiated from a visited link, the mobile node MUST tunnel the Home 714 Test Init message to the home agent. The Home Test message will then 715 be tunneled back to the mobile node by the home agent. A home 716 address test SHOULD NOT overlap with a home registration or home 717 deregistration since this could result in the loss of the Home Test 718 Init or Home Test message. 720 If the Binding Update message is early, the mobile node MUST add a 721 Care-of Test Init option (see Section 5.4) to the message, requesting 722 the correspondent node to return a new care-of keygen token. The 723 Care-of Test Init option MUST follow the CGA Parameters and Signature 724 options, if those exist in the Binding Update message. Once a 725 responding Binding Acknowledgment message with a Care-of Test option 726 (see Section 5.5) is received, the mobile node MUST use the care-of 727 keygen token contained therein in calculating the authenticator for a 728 complete Binding Update message and send this message to the 729 correspondent node. 731 If the Binding Update message is authenticated based on the CGA 732 property of the mobile node's home address, the mobile node MAY add a 733 CGA Parameters Request option (see Section 5.6) to the Binding Update 734 message so as to request the correspondent node to prove ownership of 735 its IP address within the Binding Acknowledgment message. This 736 ownership proof enables the mobile node to verify that the permanent 737 home keygen token returned in the Binding Acknowledgment message was 738 generated by the right correspondent node. 740 The mobile node includes the nonce indices associated with the 741 selected home and care-of keygen tokens in the Binding Update message 742 using a Nonce Indices option [1]. The home nonce index is thereby 743 determined as follows: 745 o If the Binding Update message is to be authenticated based on the 746 CGA property of the mobile node's home address, the mobile node 747 uses a temporary home keygen token to calculate the authenticator 748 for the Binding Update message, and the associated home nonce 749 index MUST be taken from the Home Test message with which the home 750 keygen token was obtained. 752 o If the Binding Update message is to be authenticated by a proof of 753 the mobile node's knowledge of a permanent home keygen token, the 754 home nonce index MUST be set to zero. 756 o If the Binding Update message is to be authenticated through a 757 proof of the mobile node's reachability at the home address, the 758 mobile node uses a temporary home keygen token to calculate the 759 authenticator for the Binding Update message, and the associated 760 home nonce index MUST be taken from the Home Test message with 761 which the home keygen token was obtained. 763 The care-of nonce index is determined according to the following 764 rules: 766 o If the Binding Update message is complete, the care-of nonce index 767 is taken from the Care-of Test option or Care-of Test message with 768 which the care-of keygen token (used to calculate the 769 authenticator for the Binding Update message) was obtained. 771 o If the Binding Update message is early, the care-of nonce index 772 MUST be set to zero. 774 o If the purpose of the Binding Update message is to delete a 775 binding at the correspondent node, the care-of nonce index MUST be 776 set zero. 778 The Nonce Indices option follows the CGA Parameters, Signature, 779 Care-of Test Init, and CGA Parameters Request options if those are 780 included in the Binding Update message as well. 782 The mobile node finally calculates an authenticator for the Binding 783 Update message based on the selected home and care-of keygen tokens, 784 following the rules described in Section 5.2 and Section 6.2.7 of 785 [1]. For a Binding Update message that requests the deletion of an 786 existing binding at the correspondent node, the authenticator is 787 calculated based on only a home keygen token, and it does not 788 incorporate a care-of keygen token. The authenticator is placed into 789 the Authenticator field of a Binding Authorization Data option [1], 790 which the mobile node adds to the Binding Update message as the last 791 option. 793 Mobile node Home agent Correspondent node 794 | | | 795 | | | 796 ~ Handoff | | 797 | | | 798 |-Binding Update--------->| | 799 |-Care-of Test Init-------------------------------->| 800 | | | 801 | | | 802 |<------------Binding Ack-| | 803 |<-------------------------------------Care-of Test-| 804 | | | 805 | | | 806 |-Binding Update----------------------------------->| 807 | | | 808 | | | 809 |<--------------------------------------Binding Ack-| 810 | | | 812 Figure 3: Correspondent registration with authentication by a proof 813 of the mobile node's knowledge of a permanent home keygen token; 814 explicit care-of address test 816 The time-sequence diagrams in Figure 1 through Figure 3 illustrate 817 the operation of Enhanced Route Optimization based on a few selected 818 message exchanges. Figure 1 shows the messages exchanged for a 819 correspondent registration where an early Binding Update message is 820 authenticated by a proof of the mobile node's knowledge of a 821 permanent home keygen token. A Care-of Test Init option in the early 822 Binding Update message requests the correspondent node to add to the 823 Binding Acknowledgment message a fresh care-of keygen token in a 824 Care-of Test option. The mobile node finally concludes the 825 correspondent registration with a complete Binding Update message. 826 Figure 2 shows the procedure of a correspondent registration where 827 the Binding Update message is authenticated with a proof of 828 reachability at the home address. The home address test is 829 proactively performed prior to handoff, permitting the mobile node to 830 issue a Binding Update message directly after the handoff. The 831 Binding Update message is again early, and a care-of keygen token is 832 delivered to the mobile node along with the Binding Acknowledgment 833 message. Figure 3 depicts a correspondent registration where the 834 mobile node initially obtains a fresh care-of keygen token through 835 the dedicated exchange of Care-of Test Init and Care-of Test 836 messages. It subsequently issues a complete Binding Update message 837 that is authenticated with the CGA property of the home address. 839 4.2. Receiving Binding Update Messages 841 When the correspondent node receives a Binding Update message, it 842 must first verify whether the sending mobile node is the legitimate 843 owner of the home address specified in the message. The 844 correspondent node selects the authentication method based on the 845 home nonce index given in the Nonce Indices option of the Binding 846 Update message, and on the existence of CGA Parameters and Signature 847 options in the Binding Update message: 849 o If the home nonce index is set to a non-null value and the Binding 850 Update message includes one or more CGA Parameters options 851 followed by a Signature option, the correspondent node MUST 852 authenticate the Binding Update message based on the CGA property 853 of the mobile node's home address. 855 o If the home nonce index is zero and the Binding Update message 856 does not include one or more CGA Parameters options followed by a 857 Signature option, the correspondent node MUST authenticate the 858 Binding Update message by a proof of the mobile node's knowledge 859 of a permanent home keygen token. 861 o If the home nonce index is set to a non-null value and the Binding 862 Update message does not include one or more CGA Parameters options 863 followed by a Signature option, the correspondent node MUST 864 authenticate the Binding Update message through a proof of the 865 mobile node's reachability at the home address. 867 In addition to the validation procedure for Binding Update messages 868 specified in [1], the correspondent node must take the following 869 additional steps to reject Binding Update messages that are 870 inappropriately authenticated: 872 o If the Binding Update message includes one or more CGA Parameters 873 options followed by a Signature option and the home nonce index is 874 zero, the correspondent node MUST send a Binding Acknowledgment 875 message with status code TBDd ("Non-null home nonce index 876 expected"). This ensures that a Binding Update message that is 877 authenticated based on the CGA property of the mobile node's home 878 address must also provide a proof of the mobile node's 879 reachability at the home address. 881 o If the Binding Update message is to be authenticated by a proof of 882 the mobile node's knowledge of a permanent home keygen token, the 883 correspondent node MUST verify that it has a Binding Cache entry 884 for the mobile node that includes a permanent home keygen token. 885 In case the correspondent node does not have a Binding Cache entry 886 for the mobile node, or if the existing Binding Cache entry for 887 the mobile node does not include a permanent home keygen token, 888 the correspondent node MUST reject the Binding Update message by 889 sending a Binding Acknowledgment message with status code TBDa 890 ("Permanent home keygen token unavailable"). 892 o If the Binding Update message is to be authenticated through a 893 proof of the mobile node's reachability at the home address, the 894 correspondent node MUST verify that it does not have a permanent 895 home keygen token in its Binding Cache entry for the mobile node. 896 If the correspondent node has a permanent home keygen token in its 897 Binding Cache entry for the mobile node, it MUST reject the 898 Binding Update message by sending a Binding Acknowledgment message 899 with status code TBDc ("Permanent home keygen token exists"). 900 This ensures that an attacker cannot downgrade the authentication 901 method to hijack the binding of a legitimate mobile node. 903 The authenticator for the Binding Update message is calculated based 904 on a permanent or temporary home keygen token. Which type of home 905 keygen token the correspondent node uses in validating the 906 authenticator, and how it retrieves or recomputes the home keygen 907 token, depends on the authentication method: 909 o If the Binding Update message is to be authenticated based on the 910 CGA property of the mobile node's home address, the correspondent 911 node MUST recompute the temporary home keygen token defined by the 912 (non-null) home nonce index in the Nonce Indices option of the 913 Binding Update message, and it MUST use this recomputed token in 914 validating the authenticator of the message. 916 o If the Binding Update message is to be authenticated by a proof of 917 the mobile node's knowledge of a permanent home keygen token, the 918 correspondent node MUST use the permanent home keygen token that 919 it has in its Binding Cache entry for the mobile node in 920 validating the authenticator of the Binding Update message. 922 o If the Binding Update message is to be authenticated through 923 verification of the mobile node's reachability at the home 924 address, the correspondent node MUST recompute the temporary home 925 keygen token defined by the (non-null) home nonce index in the 926 Nonce Indices option of the Binding Update message, and it MUST 927 use this recomputed token in validating the authenticator of the 928 message. 930 Unless the purpose of the Binding Update message is to delete an 931 existing binding at the correspondent node, the authenticator is also 932 calculated based on a care-of keygen token. Which care-of keygen 933 token the correspondent node uses in validating the authenticator 934 depends on whether the Binding Update message is complete or early: 936 o If the care-of nonce index in the Nonce Indices option of the 937 Binding Update message is set to a non-null value, the Binding 938 Update message is complete. In this case, the correspondent node 939 MUST recompute the care-of keygen token that is identified by the 940 care-of nonce index, and it MUST use this recomputed token in 941 validating the authenticator of the message. 943 o If the care-of nonce index in the Nonce Indices option of the 944 Binding Update message is zero, the Binding Update message is 945 early. The care-of keygen token to be used by the correspondent 946 node in validating the authenticator of the Binding Update message 947 is zero in this case. 949 The correspondent node finally validates the authenticator in the 950 Binding Update message based on the selected home and care-of keygen 951 tokens, following the algorithm described in Section 9.5.1 of [1]. 953 If the validation fails, the correspondent node MUST discard the 954 Binding Update message. The correspondent node may have to send a 955 Binding Acknowledgment message with a status code indicating the 956 failure, as described in [1]. 958 Provided that the validation of the authenticator in the Binding 959 Update message succeeds, the correspondent node registers the mobile 960 node's new care-of address, either updating an existing Binding Cache 961 entry, if one exists, or creating a new Binding Cache entry. The 962 lifetime granted for the binding depends on the lifetime requested by 963 the mobile node in the Lifetime field of the Binding Update message 964 and the method by which the Binding Update message is authenticated. 965 If the Binding Update message is authenticated based on the CGA 966 property of the mobile node's home address or by a proof of the 967 mobile node's knowledge of a permanent home keygen token, the 968 lifetime for the binding SHOULD be set to the maximum of 969 MAX_CGA_BINDING_LIFETIME and the value specified in the Lifetime 970 field of the Binding Update message. If the Binding Update message 971 is authenticated through a proof of the mobile node's reachability at 972 the home address, then the lifetime for the binding SHOULD be set to 973 the maximum of MAX_RR_BINDING_LIFETIME [1] and the value specified in 974 the Lifetime field of the Binding Update message. The correspondent 975 node may in either case grant a further reduced lifetime, but it MUST 976 NOT accept a higher lifetime. 978 The state of the new care-of address depends on whether the Binding 979 Update message is complete or early: 981 o If the Binding Update message is complete, the new care-of address 982 is set to VERIFIED state. The correspondent node may then 983 immediately send packets to the new care-of address without 984 restrictions. 986 o If the Binding Update message is early, the new care-of address is 987 set to UNVERIFIED state. The correspondent node MUST then follow 988 the rules defined in Section 4.10 for sending packets to this 989 care-of address until the care-of address is set in VERIFIED 990 state. 992 If the Binding Update message contains one or multiple CGA Parameters 993 options, the mobile node is requesting the correspondent node to 994 accept the included CGA parameters either for establishing a new, or 995 for renewing an existing permanent home keygen token shared between 996 the mobile node and the correspondent node. The correspondent node 997 MUST in this case check if the CGA Parameters options are directly 998 followed by a Signature option and, if so, validate the CGA 999 parameters and signature as described in Section 4.6. 1001 If the CGA Parameters option is not directly followed by a Signature 1002 option, or the validation of the included CGA parameters and 1003 signature fails, the correspondent node MUST discard the Binding 1004 Update message and send a Binding Acknowledgment message with status 1005 code TBDb ("CGA and signature verification failed") to the mobile 1006 node. 1008 Provided that the signature included in the Signature option is 1009 correct, the correspondent node generates a permanent home keygen 1010 token to be shared with the mobile node and stores it in its Binding 1011 Cache entry for the mobile node. The permanent home keygen token is 1012 sent to the mobile node within a Binding Acknowledgment message as 1013 described in Section 4.3. 1015 4.3. Sending Binding Acknowledgment Messages 1017 Upon receipt of a valid Binding Update message, the correspondent 1018 node returns to the mobile node a Binding Acknowledgment message in 1019 any of the following cases: 1021 o The Acknowledge flag in the Binding Update message is set. 1023 o The Binding Update message contains one or multiple CGA Parameters 1024 options directly followed by a Signature option, and the signature 1025 included in the latter was determined to be correct. 1027 o The Binding Update message is early and includes a Care-of Test 1028 Init option. 1030 If the Binding Update message further contains a CGA Parameters 1031 Request option and the correspondent node's IP address is a CGA, the 1032 correspondent node MUST include its CGA parameters and signature in 1033 the Binding Acknowledgment message by adding one or more CGA 1034 Parameters options directly followed by a Signature option. The 1035 correspondent node's CGA parameters and signature enable the mobile 1036 node to verify that the permanent home keygen token received in the 1037 Binding Acknowledgment message was generated by the right 1038 correspondent node. If the Binding Update message contains a CGA 1039 Parameters Request option, but the correspondent node's IP address is 1040 not a CGA, the correspondent node ignores the CGA Parameters Request 1041 option and processes the Binding Update message further as described 1042 below. 1044 If the Binding Update message contains one or multiple CGA Parameters 1045 options directly followed by a Signature option, and the signature 1046 included in the latter was determined to be correct, the 1047 correspondent node MUST add a Permanent Home Keygen Token option (see 1048 Section 5.3) with a new permanent home keygen token to the Binding 1049 Acknowledgment message. The correspondent node also stores this 1050 permanent home keygen token in its Binding Cache entry for the mobile 1051 node. 1053 If the Binding Update message includes a Care-of Test Init option, 1054 the correspondent node MUST append to the Binding Acknowledgment 1055 message a Care-of Test option with a pseudo-random value in the 1056 Care-of Keygen Token field. The Care-of Test option MUST appear 1057 after the Permanent Home Keygen Token option in case both options are 1058 present in the Binding Acknowledgment message. 1060 A Binding Authorization Data option must be added to the Binding 1061 Acknowledgment message as a last option, as described in Section 5.2 1062 and Section 6.2.7 of [1]. 1064 4.4. Receiving Binding Acknowledgment Messages 1066 A mobile node first verifies a received Binding Acknowledgment 1067 message according to the rules specified in [1]. Provided that the 1068 Binding Acknowledgment message is not rejected based on these rules, 1069 the mobile node takes the following additional steps. 1071 If the mobile node included a CGA Parameters Request option in the 1072 Binding Update message and the Binding Acknowledgment message 1073 contains a Permanent Home Keygen Token option, the mobile node first 1074 processes any CGA Parameters and Signature options in the Binding 1075 Acknowledgment message in the following manner. If the Binding 1076 Acknowledgment message contains one or more CGA Parameters options 1077 that are directly followed by a Signature option, the mobile node 1078 MUST check the ownership of the correspondent node's IP address by 1079 verifying the included CGA parameters and signature as described in 1080 Section 4.6. If the validation of the CGA parameters and signature 1081 fails, the mobile node MUST silently discard the Binding 1082 Acknowledgment message. The mobile node MUST also silently discard 1083 the Binding Acknowledgment message if the message includes one or 1084 more CGA Parameters options that are not directly followed by a 1085 Signature option, or if the Binding Acknowledgment message lacks any 1086 CGA Parameters options in the presence of a Signature option. 1088 If the mobile node did not include a CGA Parameters Request option in 1089 the Binding Update message or the Binding Acknowledgment message does 1090 not contain a Permanent Home Keygen Token option, the mobile node 1091 ignores any CGA Parameters and Signature options that the Binding 1092 Acknowledgment message may contain. Careful use of the CGA 1093 Parameters Request option in Binding Update messages enables the 1094 mobile node to control the processing resources it spends on the 1095 verification of a correspondent node's CGA as well as to disable such 1096 verification in the case of persistent verification failures, which 1097 may be due to misconfigured or outdated CGA software [12] on the 1098 correspondent node side or at the mobile node itself. Specifically, 1099 if the mobile node repeatedly fails to receive a Binding 1100 Acknowledgment message including valid CGA Parameters and Signature 1101 options in response to sending a Binding Update message with a CGA 1102 Parameters Request option, the mobile node SHOULD refrain from 1103 including a CGA Parameters Request option in future Binding Update 1104 messages for the same correspondent node. 1106 If the mobile node included a CGA Parameters Request option in the 1107 Binding Update message, but the Binding Acknowledgment message does 1108 not contain any CGA Parameters or Signature options, the mobile node 1109 cannot be sure if the correspondent node's IP address is simply not a 1110 CGA, or if the Binding Acknowledgment message originates from an 1111 attacker on the path from the mobile node to the correspondent node. 1113 To avoid accepting a permanent home keygen token from an on-path 1114 attacker, the mobile node MUST give precedence to Binding 1115 Acknowledgment messages that include valid CGA Parameters and 1116 Signature options over Binding Acknowledgment messages without such 1117 options. One possible algorithm for the mobile node to follow in 1118 this regard is to always accept the Binding Acknowledgment message 1119 received first, and if this message does not contain valid CGA 1120 Parameters or Signature options and another Binding Acknowledgment 1121 message including such options is received later on, to revert any 1122 state changes involved in accepting the first Binding Acknowledgment 1123 in favor of this subsequent Binding Acknowledgment message. Giving 1124 precedence to Binding Acknowledgment messages with valid CGA 1125 Parameters and Signature options over Binding Acknowledgment messages 1126 without such options enables the mobile node to communicate with 1127 correspondent nodes which do not use a CGA, and at the same time 1128 protects against most on-path attackers. The strategy does not 1129 protect against an attacker that can intercept Binding Acknowledgment 1130 messages from the correspondent node, but such an attacker could 1131 preclude mobility management between the mobile node and the 1132 correspondent node anyway. When the mobile node has permanently 1133 accepted a Binding Acknowledgment message without valid CGA 1134 Parameters and Signature options, the mobile node SHOULD refrain from 1135 including a CGA Parameters Request option in future Binding Update 1136 messages for the same correspondent node. 1138 If the Binding Acknowledgment message contains a Permanent Home 1139 Keygen Token option, the mobile node extracts the permanent home 1140 keygen token included in this option and stores it in its Binding 1141 Update List entry for the correspondent node. Future Binding Update 1142 messages will then be authenticated based on the CGA property of the 1143 mobile node's home address. 1145 If the Binding Acknowledgment message contains a Care-of Test option, 1146 the mobile node extracts the care-of keygen token included in this 1147 option, stores the token in its Binding Update List entry for the 1148 correspondent node, and sends the correspondent node a complete 1149 Binding Update message as defined in Section 4.1. Note that the 1150 complete Binding Update message will be authenticated based on the 1151 CGA property of the mobile node's home address if the Binding 1152 Acknowledgment message also includes a Permanent Home Keygen Token 1153 option. This is independent of the authentication method that was 1154 used for the corresponding early Binding Update message. 1156 A mobile node MUST ensure that, while it has a binding for a certain 1157 home address at a correspondent node, it also has a valid binding at 1158 its home agent for the same home address. This may at times require 1159 the mobile node to extend the binding lifetime at the home agent, 1160 request a correspondent node to use a binding lifetime less than the 1161 permitted maximum, or explicitly deregister an existing binding at a 1162 correspondent node. 1164 If the mobile node authenticates Binding Update messages for a 1165 particular correspondent node by proving its knowledge of a permanent 1166 home keygen token, but registrations at this correspondent node 1167 persistently fail, the mobile node SHOULD renew the permanent home 1168 keygen token by sending a Binding Update message that is 1169 authenticated based on the CGA property of its home address. This 1170 Binding Update message includes the mobile node's CGA parameters and 1171 signature, and it requests the correspondent node to generate a new 1172 permanent home keygen token and send this to the mobile node within a 1173 Binding Acknowledgment message. 1175 If the mobile node persistently receives Binding Acknowledgment 1176 messages with status code TBDb ("CGA and signature verification 1177 failed") from a correspondent node, the mobile node SHOULD 1178 authenticate future Binding Update messages for the same 1179 correspondent nodes through a proof of its reachability at the home 1180 address. This enables the mobile node to recover from misconfigured 1181 or outdated CGA software [12] on the correspondent node side or at 1182 the mobile node itself. 1184 4.5. Sending CGA Parameters 1186 A mobile node includes its CGA parameters and signature in a Binding 1187 Update message for a correspondent node in any of the following 1188 situations: 1190 o To acquire a permanent home keygen token if the mobile node's home 1191 address is a CGA, and the mobile node does not yet have a 1192 permanent home keygen token from the correspondent node. 1194 o To extent the lifetime of an existing binding if the mobile node 1195 already has a permanent home keygen token from the correspondent 1196 node, and the lifetime of the binding at the correspondent node is 1197 about to expire. 1199 o To renew an existing permanent home keygen token to prevent replay 1200 attacks in the imminent event of a sequence number rollover, or 1201 for improved protection against cryptanalysis. 1203 A correspondent node whose IP address is a CGA includes its CGA 1204 parameters and signature in a Binding Acknowledgment message for the 1205 mobile node when it receives a Binding Update message with a CGA 1206 Parameters Request option. 1208 CGA parameters are transmitted in the format of the CGA Parameters 1209 data structure defined in [2]. The CGA Parameters data structure is 1210 split over one or more CGA Parameters options as described in 1211 Section 5.1. The last CGA Parameters option MUST be directly 1212 followed by a Signature option. 1214 The value for the Signature field in the Signature option is 1215 calculated according to the signature generation algorithm defined in 1216 Section 6 of [2]. The value is calculated with the mobile or 1217 correspondent node's private key over the following sequence of 1218 octets: 1220 mobility data = 1221 care-of address | correspondent node IP address | MH data 1223 where "|" denotes concatenation. "Care-of address" is the mobile 1224 node's care-of address, and "correspondent node IP address" is the IP 1225 address of the correspondent node that is visible to protocol layers 1226 above IP. In case the correspondent node is mobile, "correspondent 1227 node IP address" refers to the correspondent node's home address. 1228 "MH data" is the content of the Binding Update or Binding 1229 Acknowledgment message including the mobility header and all options 1230 up to the last CGA Parameters option. That is, "MH data" excludes 1231 the IPv6 header and any IPv6 extension headers other than the 1232 mobility header itself. The "mobility data" constitutes what is 1233 referred to as the "message" in Section 6 of [2]. 1235 The value for the Signature field is calculated as if the Checksum 1236 field in the mobility header was zero. The Checksum field in the 1237 transmitted packet is still calculated in the usual manner, with the 1238 calculated value in the Signature field being a part of the packet 1239 protected by the checksum. 1241 4.6. Receiving CGA Parameters 1243 Mobile and correspondent nodes that receive a Binding Update or 1244 Binding Acknowledgment message including one or more CGA Parameters 1245 options directly followed by a Signature option first process the 1246 message as described in [1]. This includes a verification of the 1247 authenticator in the Authenticator field of the Binding Authorization 1248 Data option. If the Binding Update or Binding Acknowledgment message 1249 is rejected due to an incorrect authenticator or for any other 1250 reason, the message is not processed further. 1252 Otherwise, if the validation of the Binding Update or Binding 1253 Acknowledgment message succeeds, the mobile or correspondent node 1254 reassembles the CGA Parameters data structure from the CGA Parameters 1255 options included in the message as described in Section 5.1, and 1256 executes the CGA verification algorithm defined in Section 5 of [2]. 1257 The CGA verification algorithm takes the to-be-verified CGA and the 1258 reassembled CGA Parameters data structure as input. The to-be- 1259 verified CGA is the mobile node's home address when the CGA 1260 verification algorithm is executed by the correspondent node. When 1261 the mobile node executes the CGA verification algorithm, the to-be- 1262 verified CGA is the correspondent node's IP address that is visible 1263 to protocol layers above IP. This is the correspondent node's home 1264 address in case the correspondent node is mobile. The following 1265 steps are skipped if the CGA verification fails. 1267 If the CGA verification succeeds, the mobile or correspondent node 1268 performs a more time-consuming check of the signature. It extracts 1269 the signature from the Signature field in the Signature option and 1270 executes the signature verification algorithm defined in Section 6 of 1271 [2]. The signature verification algorithm takes as input the to-be- 1272 verified CGA as defined above, the reassembled CGA Parameters data 1273 structure, the MH data as defined in Section 4.5, the CGA Message 1274 Type tag of Enhanced Route Optimization as defined in Section 7, and 1275 the signature itself. 1277 4.7. Sending Permanent Home Keygen Tokens 1279 A correspondent node assigns a mobile node a new permanent home 1280 keygen token after it has received from the mobile node a Binding 1281 Update message with included CGA Parameters and Signature options, 1282 and these options have been successfully validated as described in 1283 Section 4.6. The permanent home keygen token is a 64-bit value 1284 randomly generated by the correspondent node. The correspondent node 1285 stores the permanent home keygen token in the binding cache entry 1286 that it maintains for the mobile node. 1288 The correspondent node sends the permanent home keygen token to the 1289 mobile node in encrypted form within a Permanent Home Keygen Token 1290 option in a Binding Acknowledgment message. It sends this message 1291 even if the Acknowledge flag in the corresponding Binding Update 1292 message was clear. The correspondent node encrypts the permanent 1293 home keygen token with the mobile node's public key using the RSAES- 1294 PKCS1-v1_5 format [4], and places the ciphertext into the Permanent 1295 Home Keygen Token field of the Permanent Home Keygen Token option. 1297 The Binding Authorization Data option MUST be the last option in the 1298 Binding Acknowledgment message. That is, the authenticator in the 1299 Binding Authorization Data option covers the Permanent Home Keygen 1300 Token option. 1302 4.8. Receiving Permanent Home Keygen Tokens 1304 A mobile node that receives a Binding Acknowledgment message first 1305 processes the message as described in [1], independent of whether the 1306 message includes a Permanent Home Keygen Token option. This includes 1307 a verification of the authenticator in the Authenticator field of the 1308 Binding Authorization Data option. If the Binding Acknowledgment 1309 message is rejected due to an incorrect authenticator or for any 1310 other reason, the mobile node does not process the message further. 1312 Otherwise, if the mobile node accepts the Binding Acknowledgment 1313 message and the message includes a Permanent Home Keygen Token 1314 option, the mobile node extracts the ciphertext from the Permanent 1315 Home Keygen Token field in this option and decrypts it with its 1316 private key using the RSAES-PKCS1-v1_5 format [4]. The result of the 1317 encryption is the permanent home keygen token to be used in further 1318 registrations with the correspondent node. The mobile node stores 1319 the permanent home keygen token in the Binding Update List entry that 1320 it maintains for the correspondent node. 1322 4.9. Renewing Permanent Home Keygen Tokens 1324 A mobile node that shares a permanent home keygen token with a 1325 correspondent node MUST NOT use the same sequence number twice with 1326 this permanent home keygen token in order to protect against replay 1327 attacks. The mobile node MUST renew the permanent home keygen token 1328 by including its CGA parameters and signature in a Binding Update 1329 message for the correspondent node when a sequence number rollover is 1330 imminent. In addition, the mobile node MAY renew its permanent home 1331 keygen token at any time. Periodic renewal of the permanent home 1332 keygen token provides increased protection against cryptanalysis. 1333 Finally, the mobile node may in most cases want to renew the 1334 permanent home keygen token when the lifetime of its binding at the 1335 correspondent node expires. 1337 4.10. Handling Payload Packets 1339 The immediate exchange of an early Binding Update message after a 1340 handoff on the mobile node side enables mobile and correspondent 1341 nodes to quickly reestablish route-optimized communications via the 1342 mobile node's new care-of address. The mobile node may send payload 1343 packets to the correspondent node from the new care-of address as 1344 soon as it has dispatched the early Binding Update message. The 1345 correspondent node redirects outgoing payload packets for the mobile 1346 node to the new care-of address once it has received the early 1347 Binding Update message and registered the new care-of address. Here, 1348 a "payload packet" is defined as a packet that originates at a 1349 protocol layer above IP. 1351 Inbound 1352 payload packet 1353 | 1354 | 1355 V 1356 _________________ _____________________ 1357 / \ | | 1358 / Care-of address \ Yes | Increase credit | 1359 | in |---------------------> | counter by | 1360 \ VERIFIED state? / | payload packet size | 1361 \_________________/ |_____________________| 1362 | | 1363 | | 1364 | No | 1365 | V 1366 | _____________________ 1367 | | | 1368 | | Deliver payload | 1369 +--------------------------------> | packet to upper- | 1370 | layer protocol | 1371 |_____________________| 1373 Figure 5: Handling outbound payload packets 1375 A new care-of address that was registered with an early Binding 1376 Update message is maintained in UNVERIFIED state by the correspondent 1377 node until the correspondent node receives a complete Binding Update 1378 message from the mobile node. The correspondent node then sets the 1379 care-of address to VERIFIED state. The state of the care-of address 1380 determines the maximum amount of data which the correspondent node is 1381 allowed to send to the care-of address, as is necessary to prevent 1382 amplified, redirection-based flooding attacks. For this purpose, the 1383 correspondent node maintains a "credit counter" for each mobile node 1384 with an entry in its Binding Cache. Whenever a payload packet 1385 arrives from a mobile node with a care-of address in VERIFIED state, 1386 the correspondent node SHOULD increase the mobile node's credit 1387 counter by the size of the received payload packet. The 1388 correspondent node MAY be restricted by policy to increase the credit 1389 counter by a lower value or to not increase the credit at all. The 1390 credit counter does not change when an inbound payload packet is 1391 received from a care-of address in UNVERIFIED state. Figure 5 shows 1392 a flow chart of this procedure. 1394 Outbound 1395 payload packet 1396 | 1397 | 1398 V 1399 _________________ _____________________ 1400 / \ | | 1401 / Care-of address \ Yes | Send payload | 1402 | in |---------------------> | packet to | 1403 \ VERIFIED state? / | care-of address | 1404 \_________________/ |_____________________| 1405 | 1406 | _____________________ 1407 | No | | 1408 | | Discard payload | 1409 | +---------> | packet | 1410 | | | immediately | 1411 V | |_____________________| 1412 _________________ | _____________________ 1413 / \ | | | 1414 / Credit counter \ Yes / \ | Send payload | 1415 | less than payload |-------> | |-------> | packet to | 1416 \ packet size? / \ / | home address | 1417 \_________________/ | |_____________________| 1418 | | _____________________ 1419 | | | | 1420 | No | | Buffer payload | 1421 | +---------> | packet for | 1422 | | later transmission | 1423 | |_____________________| 1424 V 1425 _____________________ _____________________ 1426 | | | | 1427 | Reduce credit | | Send payload | 1428 | counter by |---------------------> | packet to | 1429 | payload packet size | | care-of address | 1430 |_____________________| |_____________________| 1432 Figure 6: Handling outbound payload packets 1434 When the correspondent node has a payload packet to send to the 1435 mobile node, further treatment of the payload packet depends on the 1436 state of the mobile node's care-of address and the current value of 1437 the mobile node's credit counter, as illustrated in Figure 6: The 1438 correspondent node MUST send the payload packet to the mobile node's 1439 care-of address if the care-of address is in VERIFIED state. If the 1440 care-of address is in UNVERIFIED state and the value of the credit 1441 counter is higher than or equal to the size of the payload packet, 1442 the correspondent node MUST reduce the mobile node's credit counter 1443 by the size of the payload packet and send the payload packet to the 1444 care-of address as well. However, if the care-of address is in 1445 UNVERIFIED state and the credit counter is less than the size of the 1446 payload packet, the payload packet MUST NOT be sent to the mobile 1447 node's care-of address. The correspondent node SHOULD then discard 1448 the payload packet, although it MAY alternatively buffer the payload 1449 packet until the care-of address moves to VERIFIED state, or send the 1450 payload packet to the mobile node's home address. The credit counter 1451 of the mobile node does not change when the correspondent node sends 1452 a payload packet to the mobile node's care-of address while the 1453 care-of address is in VERIFIED state. 1455 The amount of data that the mobile node may send to the correspondent 1456 node is never restricted due to the state of the mobile node's 1457 care-of address. The care-of address state also does not change the 1458 addressing and routing of payload packets in either traffic 1459 direction: All payload packets that originate from the mobile node 1460 have the care-of address in the Source Address field of the IPv6 1461 header and the home address in the Home Address option of the IPv6 1462 Destination Options extension header. Vice versa, all payload 1463 packets from the correspondent node have the care-of address in the 1464 Destination Address field of the IPv6 header and the home address in 1465 the IPv6 Routing extension header. 1467 4.11. Credit Aging 1469 A correspondent node ensures that all credit counters that it 1470 maintains gradually decrease over time. Each credit counter is 1471 multiplied with a factor, CreditAgingFactor, of less than one in 1472 fixed time intervals of CreditAgingInterval length. Such "credit 1473 aging" limits the total credit that a mobile node can earn, provided 1474 that the replenishing rate for the credit is constant or nearly 1475 constant. It thereby enforces an upper bound on the rate at which 1476 the correspondent node can durably sent to the mobile node's care-of 1477 address while the care-of address is in UNVERIFIED state. In the 1478 absence of credit aging, a malicious node with poor up-link capacity 1479 could adopt the role of a mobile node, build up credit at a very slow 1480 speed and over a long period, and spend this credit during a much 1481 shorter period on redirecting a burst of payload packets to the IP 1482 address of a victim. 1484 Choosing appropriate values for CreditAgingFactor and 1485 CreditAgingInterval is important to facilitate applications where the 1486 correspondent node sends at a higher rate than the mobile node. If 1487 CreditAgingFactor or CreditAgingInterval are too small, the credit 1488 counter might persistently prevent the transmission of payload 1489 packets to a care-of address in UNVERIFIED state. The values given 1490 in Section 7 are RECOMMENDED as they work well when the correspondent 1491 node transfers a file to the mobile node via a TCP connection and the 1492 end-to-end round-trip time does not exceed 500 milliseconds. 1494 4.12. Simultaneous Movements 1496 As specified in [1], Binding Update messages are sent to a mobile 1497 correspondent node's home address. This makes it possible for two 1498 mobile nodes to continue communications even if both of them change 1499 IP connectivity at the same time. 1501 5. Option Formats and Status Codes 1503 Enhanced Route Optimization uses a set of new mobility options and 1504 status codes in addition to the mobility options and status codes 1505 defined in [1]. These are described below. 1507 5.1. CGA Parameters Option 1509 The CGA Parameters option is used in Binding Update and Binding 1510 Acknowledgment messages. It contains part of the mobile or 1511 correspondent node's CGA parameters. [1] limits mobility header 1512 options to a maximum length of 255 bytes, excluding the Option Type 1513 and Option Length fields. Since the CGA parameters are likely to 1514 exceed this limit, multiple CGA Parameters options may have to be 1515 concatenated to carry all CGA parameters. 1517 The format of the CGA Parameters option is as follows: 1519 0 1 2 3 1520 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1522 | Option Type | Option Length | 1523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1524 | | 1525 : : 1526 : CGA Parameters : 1527 : : 1528 | | 1529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1531 Option Type 1533 8-bit identifier of the type of this mobility option. Its value 1534 is . 1536 Option Length 1538 8-bit unsigned integer representing the length of the CGA 1539 Parameters field in octets. 1541 CGA Parameters 1543 This field contains up to 255 bytes of the CGA Parameters data 1544 structure defined in [2]. The concatenation of all CGA Parameters 1545 options in the order they appear in the Binding Update message 1546 MUST result in the original CGA Parameters data structure. All 1547 CGA Parameters options in the Binding Update message except the 1548 last one MUST contain exactly 255 bytes in the CGA Parameters 1549 field, and the Option Length field MUST be set to 255 accordingly. 1550 All CGA Parameters options MUST appear directly one after another, 1551 that is, a mobility option of a different type MUST NOT be placed 1552 in between two CGA Parameters options. 1554 5.2. Signature Option 1556 The Signature option is used in Binding and Binding Acknowledgment 1557 Update messages. It contains a signature that the mobile or 1558 correspondent node generates with its private key over one or more 1559 preceding CGA Parameters options. 1561 The format of the Signature option is as follows: 1563 0 1 2 3 1564 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1566 | Option Type | Option Length | 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1568 | | 1569 : : 1570 : Signature : 1571 : : 1572 | | 1573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1575 Option Type 1577 8-bit identifier of the type of this mobility option. Its value 1578 is . 1580 Option Length 1582 8-bit unsigned integer representing the length of the Signature 1583 field in octets. 1585 Signature 1587 This field contains the mobile or correspondent node's signature, 1588 generated with the mobile or correspondent node's private key as 1589 specified in Section 4.5. 1591 5.3. Permanent Home Keygen Token Option 1593 The Permanent Home Keygen Token option is used in Binding 1594 Acknowledgment messages. It contains a permanent home keygen token, 1595 which the correspondent node sends to the mobile node after it has 1596 received a Binding Update message containing one or more CGA 1597 Parameters options directly followed by a Signature option from the 1598 mobile node. 1600 The format of the Permanent Home Keygen Token option is as follows: 1602 0 1 2 3 1603 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1605 | Option Type | Option Length | 1606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1607 | | 1608 : : 1609 : Permanent Home Keygen Token : 1610 : : 1611 | | 1612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1614 Option Type 1616 8-bit identifier of the type of this mobility option. Its value 1617 is . 1619 Option Length 1621 8-bit unsigned integer representing the length of the Permanent 1622 Home Keygen Token field in octets. 1624 Permanent Home Keygen Token 1626 This field contains the permanent home keygen token generated by 1627 the correspondent node. The content of this field MUST be 1628 encrypted with the mobile node's public key as defined in 1629 Section 4.7. The length of the permanent home keygen token is 8 1630 octets before encryption, though the ciphertext [4] and, hence, 1631 the Permanent Home Keygen Token field may be longer. 1633 5.4. Care-of Test Init Option 1635 The Care-of Test Init option is included in Binding Update messages. 1636 It requests a correspondent node to return a Care-of Test option with 1637 a fresh care-of keygen token in the Binding Acknowledgment message. 1639 The format of the Care-of Test Init option is as follows: 1641 0 1 2 3 1642 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1644 | Option Type | Option Length | 1645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1647 Option Type 1649 8-bit identifier of the type of this mobility option. Its value 1650 is . 1652 Option Length 1654 This field MUST be set to zero. 1656 5.5. Care-of Test Option 1658 The Care-of Test option is used in Binding Acknowledgment messages. 1659 It contains a fresh care-of keygen token, which the correspondent 1660 node sends to the mobile node after it has received a Care-of Test 1661 Init option in a Binding Update message. 1663 The format of the Care-of Test option is as follows: 1665 0 1 2 3 1666 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1668 | Option Type | Option Length | 1669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1670 | | 1671 + Care-of Keygen Token + 1672 | | 1673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1675 Option Type 1677 8-bit identifier of the type of this mobility option. Its value 1678 is . 1680 Option Length 1682 This field MUST be set to 8. It represents the length of the 1683 Care-of Keygen Token field in octets. 1685 Care-of Keygen Token 1687 This field contains the care-of keygen token generated by the 1688 correspondent node, as specified in Section 4.3. 1690 5.6. CGA Parameters Request Option 1692 The CGA Parameters Request option is included in Binding Update 1693 messages that are authenticated based on the CGA property of the 1694 mobile node's home address. It requests a correspondent node to 1695 return its CGA parameters and signature in the Binding Acknowledgment 1696 message, enabling the mobile node to verify that the permanent home 1697 keygen token returned in the Binding Acknowledgment message was 1698 generated by the right correspondent node. 1700 The format of the CGA Parameters Request option is as follows: 1702 0 1 2 3 1703 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1705 | Option Type | Option Length | 1706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1708 Option Type 1710 8-bit identifier of the type of this mobility option. Its value 1711 is . 1713 Option Length 1715 This field MUST be set to zero. 1717 5.7. Status Codes 1719 Enhanced Route Optimization uses the following three new status codes 1720 for Binding Acknowledgment messages in addition to the status codes 1721 defined in [1]: 1723 Permanent home keygen token unavailable () 1726 A correspondent node returns a Binding Acknowledgment message with 1727 status code TBDa to a mobile node if it has received from the 1728 mobile node a Binding Update message that was authenticated 1729 through the CGA property of the mobile node's home address, but 1730 the correspondent node either does not have a Binding Cache entry 1731 for the mobile node, or the existing Binding Cache entry for the 1732 mobile node does not contain a permanent home keygen token. A 1733 Binding Acknowledgment message with status code TBDa indicates to 1734 the mobile node that it should request a new permanent home keygen 1735 token from the correspondent node by sending the correspondent 1736 node a Binding Update message including its CGA parameters and 1737 signature. This in particular enables the mobile node to quickly 1738 recover from state loss at the correspondent node. 1740 [1] does not allow a correspondent node to send a Binding 1741 Acknowledgment message with a status code indicating failure when 1742 the authenticator of a received Binding Update message turns out 1743 to be incorrect. This causes additional handoff latency with high 1744 probability because the mobile node can detect the problem only 1745 after the expiration of a retransmission timer. The mobile node 1746 is furthermore likely to assume packet loss and resend the 1747 incorrectly authenticated Binding Update message additional times. 1748 A Binding Acknowledgment message with status code TBDa helps the 1749 mobile node to identify the underlying problem more efficiently 1750 when the correspondent node could not verify the CGA property of 1751 the mobile node's home address. 1753 CGA and signature verification failed () 1756 A correspondent node returns a Binding Acknowledgment message with 1757 status code TBDb to a mobile node if it has received from the 1758 mobile node a Binding Update message that includes one or more CGA 1759 Parameters options directly followed by a Signature option, but 1760 either the CGA property of the home address cannot be verified 1761 based on the contents of the CGA Parameters options, or the 1762 verification of the signature in the Signature option has failed. 1764 Permanent home keygen token exists () 1767 A correspondent node returns a Binding Acknowledgment message with 1768 status code TBDc to a mobile node if it has received from the 1769 mobile node a Binding Update message that was authenticated 1770 through verification of the mobile node's reachability at the home 1771 address and does not include one or more CGA Parameters options 1772 directly followed by a Signature option, but the correspondent 1773 node has a permanent home keygen token in its Binding Cache entry 1774 for the mobile node. The Binding Update message is processed 1775 further if it includes one or more CGA Parameters options directly 1776 followed by a Signature option. This enables a mobile node to 1777 obtain a new permanent home keygen token from the correspondent 1778 node in case it has lost the existing one, for instance, due to a 1779 reboot. Whether the correspondent node accepts the Binding Update 1780 message in this case depends on the verification of the CGA 1781 parameters and the signature provided in the Binding Update 1782 message. 1784 Non-null home nonce index expected () 1787 A correspondent node returns a Binding Acknowledgment message with 1788 status code TBDd to a mobile node if it has received from the 1789 mobile node a Binding Update message that includes one or more CGA 1790 Parameters options directly followed by a Signature option, but 1791 the home nonce index specified in the Nonce Indices option is 1792 zero. This behavior ensures that a Binding Update message that is 1793 authenticated based on the CGA property of the mobile node's home 1794 address must also provide a proof of the mobile node's 1795 reachability at the home address. 1797 6. Security Considerations 1799 Enhanced Route Optimization differs from base Mobile IPv6 in that it 1800 applies a set of optimizations for increased handoff performance, 1801 stronger security, and reduced signaling overhead. These 1802 optimizations entail the following conceptual changes to the security 1803 model [5] of base Mobile IPv6: 1805 o Base Mobile IPv6 conducts periodic tests of a mobile node's 1806 reachability at the home address as a proof of home address 1807 ownership. Enhanced Route Optimization applies an initial 1808 cryptographic home address ownership proof in combination with a 1809 verification of the mobile node's reachability at the home address 1810 in order to securely exchange a secret permanent home keygen 1811 token. The permanent home keygen token is used for cryptographic 1812 authentication of the mobile node during subsequent correspondent 1813 registrations, so that these later correspondent registrations can 1814 be securely bound to the initial home address ownership proof. No 1815 further, periodic reachability verification at the home address 1816 tests is performed. 1818 o Base Mobile IPv6 requires a mobile node to prove its reachability 1819 at a new care-of address during a correspondent registration. 1820 This implies that the mobile node and the correspondent node must 1821 exchange Care-of Test Init and Care-of Test messages before the 1822 mobile node can initiate the binding update. Enhanced Route 1823 Optimization allows the mobile node to initiate the binding update 1824 first and follow up with a proof of reachability at the care-of 1825 address. Mobile and correspondent nodes can so resume 1826 communications early on after a handoff, while reachability 1827 verification proceeds concurrently. The amount of data that the 1828 correspondent node is permitted to send to the care-of address 1829 until reachability verification completes is governed by Credit- 1830 Based Authorization. 1832 o The maximum binding lifetime for correspondent registrations is 7 1833 minutes in base Mobile IPv6. A mobile node must hence 1834 periodically refresh a correspondent registration in cases where 1835 it does not change IP connectivity for a while. This protocol 1836 increases the maximum binding lifetime to 24 hours, reducing the 1837 need for periodic refreshes to a negligible degree. 1839 The ensuing discussion addresses the implications that these 1840 conceptual changes of the Mobile IPv6 security model have. The 1841 discussion ought to be seen in context with the security 1842 considerations of [1], [2], and [5]. 1844 6.1. Home Address Ownership 1846 Enhanced Route Optimization requires a mobile node to deliver a 1847 strong cryptographic proof [2] that it is the legitimate owner of the 1848 home address it wishes to use. The proof is based on the true home 1849 address owner's knowledge of the private component in a public/ 1850 private-key pair with the following two properties: 1852 o As an input to an irreversible CGA generation function along with 1853 a set of auxiliary CGA parameters, the public key results in the 1854 mobile node's home address. 1856 o Amongst the CGA parameters that are fed into the CGA generation 1857 function is a modifier which, as an input to an irreversable hash 1858 extension function along with the public key, results in a string 1859 with a certain minimum number of leading zeroes. Three reserved 1860 bits in the home address encode this minimum number. 1862 The first property cryptographically binds the home address to the 1863 mobile node's public key and, by virtue of public-key cryptography, 1864 to the private key. It allows the mobile node to claim ownership of 1865 the home address by proving its knowledge of the private key. The 1866 second property increases the cost of searching in brute-force manner 1867 for a public/private-key pair which suffices the first property. 1868 This increases the security of a cryptographically generated home 1869 address despite its limitation to 59 bits with cryptographic 1870 significance. Solely enforcing the first property would otherwise 1871 allow an attacker to find a suitable public/private-key pair in 1872 O(2^59) steps. By addition of the second property, the complexity of 1873 a brute-force search can be increased to O(2^(59+N)) steps, where N 1874 is the minimum number of leading zeroes that the result of the hash 1875 extension function is required to have. 1877 In practice, for a legitimate mobile node to cryptographically 1878 generate a home address, the mobile node must first accomplish a 1879 brute-force search for a suitable modifier, and then use this 1880 modifier to execute the CGA generation function. An attacker who is 1881 willing to spoof the mobile node's home address, so-called "IP 1882 address stealing" [5], then has two options: It could either generate 1883 its own public/private-key pair and perform a brute-force search for 1884 a modifier which, in combination with the generated public key, 1885 suffices the initially described two properties; or it could integer- 1886 factor the mobile node's public key, deduce the corresponding private 1887 key, and copy the mobile node's modifier without a brute-force 1888 search. The cost of the attack can be determined by the mobile node 1889 in either case: Integer-factoring a public key becomes increasingly 1890 complex as the length of the public key grows, and the key length is 1891 at the discretion of the mobile node. The cost of a brute-force 1892 search for a suitable modifier increases with the number of leading 1893 zeroes which the result of the hash extension function is required to 1894 have. This number, too, is a parameter that the mobile node can 1895 choose. Downgrading attacks, where the attacker reduces the cost of 1896 spoofing a cryptographically generated home address by choosing a set 1897 of CGA parameters that are less secure than the CGA parameters the 1898 mobile node has used to generate the home address, are hence 1899 impossible. 1901 The CGA specification [2] requires the use of RSA public and private 1902 keys, and it stipulates a minimum key length of 384 bit. This 1903 requirement that was tailored to Secure Neighbor Discovery for IPv6 1904 [13], the original CGA application. Enhanced Route Optimization does 1905 not increase the minimum key length because, in the absence of 1906 downgrading attacks as explained before, the ability to use short 1907 keys does not compromise the security of home addresses that were 1908 cryptographically generated using longer keys. Moreover, extensions 1909 to [2] may eventually permit the use of public/private key classes 1910 other than RSA. Such extensions are compatible with the CGA 1911 application of Enhanced Route Optimization. Care must be taken in 1912 selecting an appropriate key class and length, however. Home 1913 addresses are typically rather stable in nature, so the chosen 1914 parameters must be secure for a potentially long home address 1915 lifetime. Where RSA keys are used, a minimum key length of 1024 bit 1916 is therefore RECOMMENDED. 1918 While the CGA generation function cryptographically ties the 1919 interface identifier of a home address to the subnet prefix of the 1920 home address, the function accepts any subnet prefix and hence does 1921 not prevent a node from cryptographically generating a home address 1922 with a spoofed subnet prefix. As a consequence, the CGA property of 1923 a home address does not guarantee the owner's reachability at the 1924 home address. This could be misused for a "return-to-home flooding 1925 attack" [5], where the attacker uses its own public key to 1926 cryptographically generate a home address with a subnet prefix from a 1927 victim network, requests a correspondent node to bind this to the 1928 attacker's current care-of address, initiates the download of a large 1929 file via the care-of address, and finally deregisters the binding or 1930 lets it expire. the correspondent node would then redirect the 1931 packets being downloaded to the victim network identified by the 1932 subnet prefix of the attacker's spoofed home address. The protocol 1933 defined in this document performs a reachability test for the home 1934 address at the time the home address is first registered with the 1935 correspondent node. This precludes return-to-home flooding. 1937 The verification of the CGA property of a mobile node's home address 1938 involves asymmetric public-key cryptography, which is relatively 1939 complex compared to symmetric cryptography. Enhanced Route 1940 Optimization mitigates this disadvantage through the use of symmetric 1941 cryptography after an initial public-key-based verification of the 1942 mobile node's home address has been performed. Specifically, the 1943 correspondent node assigns the mobile node a permanent home keygen 1944 token during the initial correspondent registration based on which 1945 the mobile node can authenticate to the correspondent node during 1946 subsequent correspondent registrations. Such authentication enables 1947 the correspondent node to bind a subsequent correspondent 1948 registration back to the initial public-key-based verification of the 1949 mobile node's home address. The permanent home keygen token is never 1950 sent in plain text; it is encrypted with the mobile node's public key 1951 when initially assigned, and irreversibly hashed during subsequent 1952 correspondent registrations. 1954 6.2. Care-of Address Ownership 1956 A secure proof of home address ownership can mitigate the threat of 1957 IP address stealing, but an attacker may still bind a correct home 1958 address to a false care-of address and thereby trick a correspondent 1959 node into redirecting packets, which would otherwise be delivered to 1960 the attacker itself, to a third party. Neglection to verify a mobile 1961 node's reachability at its claimed care-of address could therefore 1962 cause one or multiple correspondent nodes to unknowingly contribute 1963 to a redirection-based flooding attack against a victim chosen by the 1964 attacker. 1966 Redirection-based flooding attacks may target a single node, a link, 1967 or a router or other critical network device upstream an entire 1968 network. Accordingly, the attacker's spoofed care-of address may be 1969 the IP address of a node, a random IP address from a subnet prefix of 1970 a particular link, or the IP address of a router or other network 1971 device. An attack against a network potentially impacts a larger 1972 number of nodes than an attack against a specific node, although 1973 neighbors of a victim node on a broadcast link typically suffer the 1974 same damage as the victim itself. 1976 Requiring mobile nodes to cryptographically generate care-of 1977 addresses in the same way as they generate home addresses would 1978 mitigate the threat of redirection-based flooding only marginally. 1979 While it would prevent an attacker from registering as its care-of 1980 address the IP address of a specific victim node, the attacker could 1981 still generate a different CGA-based care-of address with the same 1982 subnet prefix as that of the victim's IP address. Flooding packets 1983 redirected towards this care-of address would then not have to be 1984 received and processed by any specific node, but they would impact an 1985 entire link or network and thus cause comparable damage. CGA-based 1986 care-of addresses are therefore little effective with respect to 1987 flooding protection. On the other hand, they would require a 1988 computationally expensive, public-key-based ownership proof whenever 1989 the care-of address changes. Enhanced Route Optimization uses 1990 regular IPv6 care-of addresses for these reasons. 1992 A common misconception is that a strong proof of home address 1993 ownership would mitigate the threat of redirection-based flooding and 1994 consequently eliminate the need to verify a mobile node's 1995 reachability at a new care-of address. This notion may originate 1996 from the specification of a base Mobile IPv6 home registration in 1997 [1], which calls for the authentication of a mobile node based on an 1998 IPsec security association, but does not require this to be 1999 supplemented by a verification of the mobile nodes reachability at 2000 the care-of address. However, the reason not to mandate reachability 2001 verification for a home registration is in this case the existence of 2002 an administrative relationship between the home agent and the mobile 2003 node, rather than the fact that the home agent can securely verify 2004 the mobile node's home address ownership, or that the home 2005 registration is IPsec-protected. The administrative relationship 2006 with the mobile node allows the home agent, first, to trust in the 2007 correctness of a mobile node's care-of address and, second, to 2008 quickly identify the mobile node should it still start behaving 2009 maliciously, for example, due to infection by malware. Section 15.3 2010 in [1] and Section 1.3.2 in [5] explain these prerequisites. 2012 Assuming trust and an administrative relationship between the mobile 2013 node and its home agent is viable given that the home agent is an 2014 integral part of the mobility services which a mobile user typically 2015 subscribes to, sets up her- or himself, or receives based on a 2016 business relationship. A Mobile IPv6 extension [14] that leverages a 2017 shared authentication key, pre-configured on the mobile node and the 2018 correspondent node, preassumes the same relationship between the 2019 mobile node and a correspondent node. While this assumption limits 2020 the applicability of the protocol (Section 2 of [14] acknowledges 2021 this), it permits omission of care-of address reachability 2022 verification as in the case of the home registration. Enhanced 2023 Router Optimization does not make assumptions on the relationship 2024 between mobile and correspondent nodes. This renders the protocol 2025 applicable to arbitrary scenarios, but necessitates that 2026 correspondent nodes must verify a mobile node's reachability at every 2027 new care-of address. 2029 6.3. Credit-Based Authorization 2031 Enhanced Route Optimization enables mobile and correspondent nodes to 2032 resume bidirectional communications after a handoff on the mobile- 2033 node side already before the mobile node's reachability at the new 2034 care-of address has been verified by the correspondent node. Such 2035 concurrency would in the absence of appropriate protection 2036 reintroduce the threat of redirection-based flooding, which 2037 reachability verification was originally designed to eliminate: Given 2038 that the correspondent node is in general unaware of the round-trip 2039 time to the mobile node, and since reachability verification may fail 2040 due to packet loss, the correspondent node must accept a sufficiently 2041 long concurrency period for reachability verification to complete. 2042 An attacker could misuse this to temporarily trick the correspondent 2043 node into redirecting packets to the IP address of a victim. The 2044 attacker may also successively postpone reachability verification in 2045 that it registers with the correspondent node anew, possibly with a 2046 different spoofed care-of address, shortly before the correspondent 2047 node's maximum permitted concurrency period elapses and the 2048 correspondent node switches to waiting for the completion of 2049 reachability verification without sending further packets. This 2050 behavior cannot necessarily be considered malicious on the 2051 correspondent node side since even a legitimate mobile node's 2052 reachability may fail to become verified before the mobile node's 2053 care-of address changes again. This may be due to high mobility on 2054 the mobile node side, or to persistent packet loss on the path 2055 between the mobile node and the correspondent node. It is generally 2056 non-trivial to decide on the correspondent node side whether the 2057 party at the other end behaves legitimately under adverse conditions 2058 or maliciously. 2060 Enhanced Route Optimization eliminates the threat of redirection- 2061 based flooding despite concurrent reachability verification through 2062 the use of Credit-Based Authorization. Credit-Based Authorization 2063 manages the effort that a correspondent node expends in sending 2064 payload packets to a care-of address in UNVERIFIED state. This is 2065 accomplished based on the following three hypotheses: 2067 1. A flooding attacker typically seeks to shift the burden of 2068 assembling and sending flooding packets to a third party. 2069 Bandwidth is an ample resource for many attractive victims, so 2070 the effort for sending the high rate of flooding packets required 2071 to impair the victim's ability to communicate may exceed the 2072 attacker's own capacities. 2074 2. The attacker can always flood a victim directly by generating 2075 bogus packets itself and sending those to the victim. Such an 2076 attack is not amplified, so the attacker must be provisioned 2077 enough to generate a packet flood sufficient to bring the victim 2078 down. 2080 3. Consequently, the additional effort required to set up and 2081 coordinate a redirection-based flooding attack pays off for the 2082 attacker only if the correspondent node can be tricked into 2083 contributing to and amplifying the attack. 2085 Non-amplified redirection-based flooding is hence, from an attacker's 2086 perspective, no more attractive than pure direct flooding, where the 2087 attacker itself sends bogus packets to the victim. It is actually 2088 less attractive given that the attacker needs to maintain a context 2089 for mobility management in order to coordinate the redirection. On 2090 this basis, Credit-Based Authorization extinguishes the motivation 2091 for redirection-based flooding by preventing the amplification that 2092 could be reached through it, rather than eliminating malicious packet 2093 redirection in the first place. The ability to send unrequested 2094 packets is an inherent property of packet-oriented networks, and 2095 direct flooding is a threat that results from this. Since direct 2096 flooding exists with and without mobility support, it constitutes a 2097 reasonable measure in comparing the security provided by Enhanced 2098 Route Optimization to the security of the non-mobile Internet. 2099 Through the use of Credit-Based Authorization, Enhanced Route 2100 Optimization satisfies the objective to provide a security level 2101 comparable to that of the non-mobile Internet. 2103 Since the perpetrator of a redirection-based flooding attack would 2104 take on the role of a mobile node, Credit-Based Authorization must be 2105 enforced on the correspondent node side. The correspondent node 2106 continuously monitors the effort that the mobile node spends in 2107 communicating with the correspondent node. The mobile node's effort 2108 is then taken as a limit on the effort that the correspondent node 2109 may spend in sending payload packets when the mobile node's care-of 2110 address is in UNVERIFIED state. The permission for the correspondent 2111 node to send a limited amount of payload packets to a care-of address 2112 in UNVERIFIED state enables immediate resumption of bidirectional 2113 communications once the mobile node has registered a new IP address 2114 with the correspondent node after a handoff. 2116 If what appears to be a mobile node is in fact an attacker who tricks 2117 the correspondent node into redirecting payload packets to the IP 2118 address of a victim, Credit-Based Authorization ensures that the 2119 stream of flooding packets ceases before the effort that the 2120 correspondent node spends on generating the stream exceeds the effort 2121 that the attacker has recently spent itself. The flooding attack is 2122 therefore at most as effective as a direct flooding attack, and 2123 consequently fails to produce any amplification. 2125 Another property of Credit-Based Authorization is that it does not 2126 assign a mobile node credit while its care-of addresses is in 2127 UNVERIFIED state. This deserves justification since it would 2128 technically be feasibly to assign credit independent of the state of 2129 the mobile node's care-of address. However, the assignment of credit 2130 for packets received from a care-of address in UNVERIFIED state would 2131 introduce a vulnerability to sustained reflection attacks. 2132 Specifically, an attacker could cause a correspondent node to 2133 redirect packets for the attacker to the IP address of a victim, and 2134 sustain the packet flow towards the victim in that it continuously 2135 replenishes its credit by sending packets to the correspondent node. 2136 Although such a redirection-based reflection attack would fail to 2137 produce any amplification, it may still be appealing to an attacker 2138 who wishes to pursue an initial transport protocol handshake with the 2139 correspondent node---which typically requires the attacker to receive 2140 some unguessable data---, and redirect the download to the victim's 2141 IP address afterwards. Credit-Based Authorization ensures that the 2142 attacker in this case cannot acquire additional credit once the 2143 download has been redirected, and thereby forces the attack to end 2144 quickly. 2146 6.4. Time Shifting Attacks 2148 Base Mobile IPv6 limits the lifetime of a correspondent registration 2149 to 7 minutes and so arranges that a mobile node's reachability at its 2150 home and care-of addresses is reverified periodically. This ensures 2151 that the return routability procedure's vulnerability to 2152 eavesdropping cannot be exploited by an attacker that is only 2153 temporarily on the path between the correspondent node and the 2154 spoofed home or care-of address. Such "time shifting attacks" [5] 2155 could otherwise be misused for off-path IP address stealing, return- 2156 to-home flooding, or flooding against care-of addresses. 2158 Enhanced Route Optimization neither repeats the initial home address 2159 test nor any care-of address test in order to decrease handoff delays 2160 and signaling overhead. This does not limit the protocol's 2161 robustness to IP address stealing attacks because the required CGA- 2162 based ownership proof for home addresses already eliminates such 2163 attacks. Reachability verification does not add further protection 2164 in this regard. On the other hand, the restriction to an initial 2165 reachability verification facilitates time-shifted, off-path flooding 2166 attacks---either against home addresses with incorrect prefixes, or 2167 against spoofed care-of addresses---, if the perpetrator can 2168 interpose in the exchange before it moves to a different location. 2170 The design choice against repeated home and care-of address tests was 2171 made based on the observation that time shifting attacks are already 2172 an existing threat in the non-mobile Internet of today. 2173 Specifically, an attacker can temporarily move onto the path between 2174 a victim and a correspondent node, request a stream of packets from 2175 the correspondent node on behalf of the victim, and then move to a 2176 different location. Most transport protocols do not verify an 2177 initiator's reachability at the claimed IP address after an initial 2178 verification during connection establishment. It enables an attacker 2179 to participate only in connection establishment and then move to an 2180 off-path position, from where it can spoof acknowledgments to feign 2181 continued presence at the victim's IP address. The threat of time 2182 shifting hence already applies to the non-mobile Internet. 2184 It should still be acknowledged that the time at which Enhanced Route 2185 Optimization verifies a mobile node's reachability at a home or 2186 care-of address may well antecede the establishment of any transport 2187 layer connection. This gives an attacker more time to move away from 2188 the path between the correspondent node and the victim and so makes a 2189 time shifting attack more practicable. If the lack of periodic 2190 reachability verification is considered too risky, a correspondent 2191 node may enforce reruns of home or care-of address tests by limiting 2192 the registration lifetime, or by sending Binding Refresh Request 2193 messages to a mobile node. 2195 6.5. Replay Attacks 2197 The protocol specified in this document relies on 16-bit base Mobile 2198 IPv6 sequence numbers and periodic rekeying to avoid replay attacks. 2199 Rekeying allows mobile and correspondent nodes to reuse sequence 2200 numbers without exposing themselves to replay attacks. It must be 2201 pursued at least once every 24 hours due to the maximum permitted 2202 binding lifetime for correspondent registrations. Mobile and 2203 correspondent nodes also rekey whenever a rollover in sequence number 2204 space becomes imminent. This is unlikely to happen frequently, 2205 however, given that available sequence numbers are sufficient for up 2206 to 32768 correspondent registrations, each consisting of an early and 2207 a complete Binding Update message. The sequence number space thus 2208 permits an average rate of 22 correspondent registrations per minute 2209 without exposing a need to rekey throughout the 24-hour binding 2210 lifetime. 2212 6.6. Resource Exhaustion 2214 While a CGA-based home address ownership proof provides protection 2215 against unauthenticated Binding Update messages, it can expose a 2216 correspondent node to denial-of-service attacks since it requires 2217 computationally expensive public-key cryptography. Enhanced Route 2218 Optimization limits the use of public-key cryptography to only the 2219 first correspondent registration and if/when rekeying is needed. It 2220 is RECOMMENDED that correspondent nodes in addition track the amount 2221 of processing resources they spend on CGA-based home address 2222 ownership verification, and that they reject new correspondent 2223 registrations that involve public-key cryptography when these 2224 resources exceed a predefined limit. [2] discusses the feasibility of 2225 CGA-based resource exhaustion attacks in depth. 2227 6.7. IP Address Ownership of Correspondent Node 2229 Enhanced Route Optimization enables mobile nodes to authenticate a 2230 received Binding Acknowledgment message based on a CGA property of 2231 the correspondent node's IP address, provided that the correspondent 2232 node has a CGA. The mobile node requests this authentication by 2233 including a CGA Parameters Request option in the Binding Update 2234 message that it sends to the correspondent node, and the 2235 correspondent node responds by adding its CGA parameters and 2236 signature to the Binding Acknowledgment message within CGA Parameters 2237 and Signature options. Proving ownership of the correspondent node's 2238 IP address protects the mobile node from accepting a spoofed Binding 2239 Acknowledgment message and from storing the included permanent home 2240 keygen token for use during future correspondent registrations. Such 2241 an attack would result in denial of service against the mobile node 2242 because it would prevent the mobile node to transact any binding 2243 updates with the obtained permanent home keygen token. Enhanced 2244 Route Optimization recommends renewal of a permanent home keygen 2245 token in case of persistent correspondent registration failures, 2246 allowing mobile nodes to recover from denial-of-service attacks that 2247 involve spoofed permanent home keygen tokens. 2249 The threat of the described denial-of-service attack is to some 2250 extent mitigated by requirements on the attacker's location: A 2251 Binding Update message that requests a correspondent node to provide 2252 a permanent home keygen token is authenticated based on the CGA 2253 property of the mobile node's home address. This authentication 2254 method involves a home address test, providing the mobile node with a 2255 home keygen token based on which it can calculate the authenticator 2256 of the Binding Update message. Since the mobile node expects the 2257 authenticator of the returning Binding Acknowledgment message to be 2258 calculated with the same home keygen token, an attacker that is 2259 willing to spoof a Binding Acknowledgment message that includes a 2260 permanent home keygen token must eavesdrop on the home address test. 2261 The attacker must hence be present on the path from the correspondent 2262 node to the mobile node's home agent while the home address test 2263 proceeds. Moreover, if the Binding Update message requesting the 2264 permanent home keygen token is complete, its authenticator is further 2265 calculated based on a care-of keygen token. The attacker must then 2266 also know this care-of keygen token to generate the authenticator of 2267 the Binding Acknowledgment message. This requires the attacker to be 2268 on the path from the correspondent node to the mobile node's current 2269 IP attachment at the time the correspondent node sends the care-of 2270 keygen token to the mobile node within a Care-of Test message or the 2271 Care-of Test option of a Binding Acknowledgment message. 2273 Since a mobile node in general does not know whether a particular 2274 correspondent node's IP address is a CGA, the mobile node must be 2275 prepared to receive a Binding Acknowledgment message without CGA 2276 Parameters and Signature options in response to sending a Binding 2277 Update message with an included CGA Parameters Request option. Per 2278 se, this mandatory behavior may enable downgrading attacks where the 2279 attacker would send, on the correspondent node's behalf, a Binding 2280 Acknowledgment message without CGA Parameters and Signature options, 2281 claiming that the correspondent node's IP address is not a CGA. 2282 Enhanced Route Optimization mitigates this threat in that it calls 2283 for mobile nodes to prioritize Binding Acknowledgment messages with 2284 valid CGA Parameters and Signature options over Binding 2285 Acknowledgment messages without such options. This protects against 2286 downgrading attacks unless the attacker can intercept Binding 2287 Acknowledgment messages from the correspondent node. Given that the 2288 attacker must be on the path from the correspondent node to the 2289 mobile node's home agent at roughly the same time as explained above, 2290 the attacker may not be able to intercept the correspondent node's 2291 Binding Acknowledgment messages. On the other hand, an attacker that 2292 can intercept Binding Acknowledgment messages from the correspondent 2293 node is anyway in a position where it can pursue denial of service 2294 against the mobile node and the correspondent node. This is a threat 2295 that already exists in the non-mobile Internet, and it is not 2296 specific to Enhanced Route Optimization. 2298 External mechanisms may enable the mobile node to obtain certainty 2299 about whether a particular correspondent node's IP address is a CGA. 2300 The mobile node may then insist on an IP address ownership proof from 2301 the correspondent node, in which case it would discard any received 2302 Binding Acknowledgment messages that do not contain valid CGA 2303 Parameters and Signature options. One conceivable means for mobile 2304 nodes to distinguish between standard IPv6 addresses and CGAs might 2305 be an extension to the Domain Name System. 2307 7. Protocol Constants and Configuration Variables 2309 [2] defines a CGA Message Type name space from which CGA applications 2310 draw CGA Message Type tags to be used in signature calculations. 2311 Enhanced Route Optimization uses the following constant, randomly 2312 generated CGA Message Type tag: 2314 0x5F27 0586 8D6C 4C56 A246 9EBB 9B2A 2E13 2316 [1] bounds the lifetime for bindings that were established with 2317 correspondent nodes by way of the return routability procedure to 2318 MAX_RR_BINDING_LIFETIME. Enhanced Route Optimization adopts this 2319 limit for bindings that are authenticated through a proof of the 2320 mobile node's reachability at the home address. However, the binding 2321 lifetime is limited to the more generous constant value of 2322 MAX_CGA_BINDING_LIFETIME when the binding is authenticated through 2323 the CGA property of the mobile node's home address: 2325 MAX_CGA_BINDING_LIFETIME 86400 seconds 2327 Credit aging incorporates two configuration variables to gradually 2328 decrease a mobile node's credit counter over time. It is RECOMMENDED 2329 that a correspondent node uses the following values: 2331 CreditAgingFactor 7/8 2332 CreditAgingInterval 5 seconds 2334 8. IANA Considerations 2336 This document defines the following six new mobility options, which 2337 must be assigned type values within the mobility option numbering 2338 space of [1]: 2340 o CGA Parameters mobility option (TBD0) 2342 o CGA Parameters Request mobility option (TBD1) 2344 o Signature mobility option (TBD2) 2346 o Permanent Home Keygen Token mobility option (TBD3) 2348 o Care-of Test Init mobility option (TBD4) 2350 o Care-of Test mobility option (TBD5) 2352 This document allocates the following four new status codes for 2353 Binding Acknowledgment messages: 2355 o "Permanent home keygen token unavailable" (TBDa) 2357 o "CGA and signature verification failed" (TBDb) 2359 o "Permanent home keygen token exists" (TBDc) 2360 o "Non-null home nonce index expected" (TBDd) 2362 The values to be assigned for these status codes must all be greater 2363 than or equal to 128, indicating that the respective Binding Update 2364 message was rejected by the receiving correspondent node. 2366 This document also defines a new 128-bit value under the CGA Message 2367 Type name space [2]. 2369 9. Acknowledgments 2371 The authors would like to thank Tuomas Aura, Gabriel Montenegro, 2372 Pekka Nikander, Mike Roe, Greg O'Shea, Vesa Torvinen (in alphabetical 2373 order) for valuable and interesting discussions around 2374 cryptographically generated addresses. 2376 The authors would also like to thank Marcelo Bagnulo, Roland Bless, 2377 Zhen Cao, Samita Chakrabarti, Greg Daley, Vijay Devarapalli, Mark 2378 Doll, Lakshminath Dondeti, Francis Dupont, Eric Gray, Manhee Jo, 2379 James Kempf, Suresh Krishnan, Tobias Kuefner, Lila Madour, Vidya 2380 Narayanan, Mohan Parthasarathy, and Alice Qinxia (in alphabetical 2381 order) for their reviews of and important comments on this document 2382 and the predecessors of this document. 2384 Finally, the authors would also like to emphasize that [15] pioneered 2385 the use of cryptographically generated addresses in the context of 2386 Mobile IPv6 route optimization, and that this document consists 2387 largely of material from [16], [17], and [18] and the contributions 2388 of their authors. 2390 10. References 2392 10.1. Normative References 2394 [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 2395 IPv6", RFC 3775, June 2004. 2397 [2] Aura, T., "Cryptographically Generated Addresses (CGA)", 2398 RFC 3972, March 2005. 2400 [3] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement 2401 Levels", IETF BCP 14, RFC 2119, March 1997. 2403 [4] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards 2404 (PKCS) #1: RSA Cryptography Specifications Version 2.1", 2405 RFC 3447, February 2003. 2407 10.2. Informative References 2409 [5] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 2410 Nordmark, "Mobile IP Version 6 Route Optimization Security 2411 Design Background", RFC 4225, December 2005. 2413 [6] Vogt, C. and J. Arkko, "A Taxonomy and Analysis of Enhancements 2414 to Mobile IPv6 Route Optimization", RFC 4651, February 2007. 2416 [7] Vogt, C. and M. Doll, "Efficient End-to-End Mobility Support in 2417 IPv6", Proceedings of the IEEE Wireless Communications and 2418 Networking Conference, IEEE, April 2006. 2420 [8] Mirkovic, J. and P. Reiher, "A Taxonomy of DDoS Attack and DDoS 2421 Defense Mechanisms", ACM SIGCOMM Computer Communication Review, 2422 Vol. 34, No. 2, ACM Press, April 2004. 2424 [9] Arkko, J. and C. Vogt, "Credit-Based Authorization for Binding 2425 Lifetime Extension", Internet Draft 2426 draft-arkko-mipv6-binding-lifetime-extension-00.txt (work in 2427 progress), May 2004. 2429 [10] O'Shea, G. and M. Roe, "Child-Proof Authentication for MIPv6 2430 (CAM)", ACM SIGCOMM Computer Communication Review, ACM Press, 2431 Vol. 31, No. 2, April 2001. 2433 [11] Nikander, P., "Denial-of-Service, Address Ownership, and Early 2434 Authentication in the IPv6 World", Revised papers from the 2435 International Workshop on Security Protocols, Springer-Verlag, 2436 April 2002. 2438 [12] Bagnulo, M. and J. Arkko, "Support for Multiple Hash Algorithms 2439 in Cryptographically Generated Addresses (CGAs)", 2440 Internet Draft draft-bagnulo-multiple-hash-cga-02.txt (work in 2441 progress), January 2007. 2443 [13] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 2444 Neighbor Discovery (SEND)", RFC 3971, March 2005. 2446 [14] Perkins, C., "Securing Mobile IPv6 Route Optimization Using a 2447 Static Shared Key", RFC 4449, June 2006. 2449 [15] Roe, M., Aura, T., O'Shea, G., and J. Arkko, "Authentication of 2450 Mobile IPv6 Binding Updates and Acknowledgments", 2451 Internet Draft draft-roe-mobileip-updateauth-02.txt (work in 2452 progress), March 2002. 2454 [16] Haddad, W., Madour, L., Arkko, J., and F. Dupont, "Applying 2455 Cryptographically Generated Addresses to Optimize MIPv6 (CGA- 2456 OMIPv6)", Internet Draft draft-haddad-mip6-cga-omipv6-04.txt 2457 (work in progress), May 2005. 2459 [17] Vogt, C., Bless, R., Doll, M., and T. Kuefner, "Early Binding 2460 Updates for Mobile IPv6", Internet Draft 2461 draft-vogt-mip6-early-binding-updates-00.txt (work in 2462 progress), February 2004. 2464 [18] Vogt, C., Arkko, J., Bless, R., Doll, M., and T. Kuefner, 2465 "Credit-Based Authorization for Mobile IPv6 Early Binding 2466 Updates", Internet Draft 2467 draft-vogt-mipv6-credit-based-authorization-00.txt (work in 2468 progress), May 2004. 2470 Appendix A. Change Log 2472 The following is a list of technical changes that were made from 2473 version 02 to version 03 of this document. Editorial revisions are 2474 not explicitly mentioned. 2476 o Reference to RFC 3972 ("Cryptographically Generated Addresses") is 2477 now normative. 2479 o More detailed IANA considerations. 2481 o Fixed reference to BCP 14, RFC 2119, so that Nit Checker does no 2482 longer complain. 2484 o Clarified in Section 3.1 that CGAs do not require a public-key 2485 infrastructure, even though they make use of public-key 2486 cryptography. 2488 o Included intended status ("Proposed Standard") at beginning of 2489 document. 2491 The following is a list of technical changes that were made from 2492 version 01 to version 02 of this document. Editorial revisions are 2493 not explicitly mentioned. 2495 o Section 4.1: Included directions for the mobile node to choose the 2496 binding lifetime to be requested in a Binding Update message. 2498 o Clarified ordering of Mobility Header message options in 2499 Section 4.1. 2501 o Section 4.1 now explicitly permits parallel home and correspondent 2502 registrations (RFC 3775 recommends that they be sequential) and 2503 also recommends a proactive home address test. 2505 o Added figures (and an associated explanation of the figures) to 2506 Section 4.1 to illustrate the correspondent registration process. 2507 This was suggested by James Kempf. 2509 o Section 4.2: Specified error handling when a received Binding 2510 Update message includes the mobile node's CGA parameters and 2511 signature, but the message is authenticated by a permanent home 2512 keygen token and hence does not provide a proof of the mobile 2513 node's reachability at the home address. 2515 o Section 4.2: Included directions for the correspondent node to 2516 decide which lifetime to grant in the event of a received Binding 2517 Update message. 2519 o Section 4.3 and Section 4.4: A correspondent node MUST include a 2520 Permanent Home Keygen Token option in a Binding Acknowledgment 2521 message before a Care-of Test option, and the options MUST also be 2522 processed by the mobile node in this order. This enables the 2523 mobile node to already use the permanent home keygen token when a 2524 complete Binding Update message is sent as part of processing the 2525 subsequent Care-of Test option. 2527 o Section 4.3: Correspondent nodes now send their CGA parameters and 2528 signature within a Binding Acknowledgment message if they receive 2529 a Binding Update message including a CGA Parameters Request 2530 option. This allows mobile nodes to verify that a received 2531 permanent home keygen token originates with the right 2532 correspondent node. Without such a CN-side IP address ownership 2533 proof, the MN may be tricked into accepting an attacker's 2534 permanent home keygen token. This was discussed before; it was 2535 also brought up on the mailing list by Manhee Jo. 2537 o Added requirement in Section 4.4 for mobile nodes to ensure the 2538 existence of a home registration for a particular home address 2539 while there is at least one correspondent registration for the 2540 same home address. 2542 o Revised Section 4.10 and Section 4.11 to clarify the operation of 2543 Credit-Based Authorization. 2545 o Added discussion about public/private key class and length to 2546 Section 6.1. This was suggested by Zhen Cao. 2548 o Added explanation of Credit-Based Authorization in Section 6.3. 2550 o Rewrote discussion on IP Address ownership of correspondent nodes 2551 in Section 6.7. 2553 o The performance benefits of Enhanced Route Optimization are 2554 already described in Section 2 and Section 3. Section 2555 "Performance Considerations" (formerly Section 7) was therefore 2556 removed. 2558 o Moved protocol configuration variables to Section 7. 2560 o Added new CGA Parameters Request option to Section 5. 2562 o Added new status codes "CGA and signature verification failed" and 2563 "Non-null home nonce index expected" to Section 5 and Section 8. 2565 o Removed CGA and CBA overview appendices. CBA is now described in 2566 Section 3.6. An overview of CGAs is not necessary given that this 2567 document already refers to the CGA specification. Some details of 2568 CGAs are likely to change in the near future anyway [12], so it 2569 may be better to refer to external documents rather than including 2570 a separate description in this document. 2572 o Updated references. 2574 The following is a list of technical changes that were made from 2575 version 00 to version 01 of this document. Editorial revisions are 2576 not explicitly mentioned. 2578 o Revised Section 1 to reflect the comments from Vidya and 2579 Lakshminath. The text now makes it much clearer that there are 2580 two individual optimizations for home and care-of address 2581 verification. 2583 o Added Section 4.5 describing when the mobile node sends CGA 2584 parameters to the correspondent node and how the CGA Parameters 2585 and Signature options are used to accomplish this. 2587 o Added Section 4.6 describing the correspondent node's operation 2588 upon receiving a Binding Update message with included CGA 2589 Parameters and Signature options. 2591 o Added Section 4.7 describing how a correspondent node generates 2592 and encrypts a permanent home keygen token and sends the token in 2593 a Permanent Home Keygen Token option within a Binding 2594 Acknowledgment message to the mobile node. 2596 o Added Section 4.8 describing how a mobile node decrypts a 2597 permanent home keygen token received in a Binding Acknowledgment 2598 message with a Permanent Home Keygen Token option. 2600 o Removed Section "Renewing a Permanent Home Keygen Token" (formerly 2601 Section 4.7). The section described when the mobile node should 2602 renew an existing permanent home keygen token. This is now 2603 explained in Section 4.5. 2605 o Section 4.10 now also describes when mobile and correspondent 2606 nodes resume route-optimized payload transmission after handoff on 2607 the mobile node side. 2609 o Removed Section "Cryptographic Calculations" (formerly Section 2610 4.10). The section described how the signature in a Signature 2611 option and the contents of the former SKey option are calculated. 2612 The signature calculation is now described in Section 4.5. The 2613 SKey option was replaced by the Permanent Home Keygen Token 2614 option, and the contents of this are now described in Section 4.7. 2616 o Cleaned up section Section 5. 2618 o Replaced status code "Lost Kbmperm State" in Section 5.7 with a 2619 new status code, "Permanent Home Keygen Token Unavailable". Added 2620 a second status code "Permanent home keygen token exists". 2621 Section 4 ("Protocol Operation") and Section 8 ("IANA 2622 Considerations") were modified accordingly. 2624 o Revised Section 6 so that it now addresses the comments made by 2625 Vidya and Lakshminath. In particular, the text now explains why a 2626 care-of address test is required in spite of the more secure, CGA- 2627 based home address verification. The section also starts with an 2628 overview of the conceptual changes that the proposed protocol 2629 applies to RFC 3775. 2631 o Added Section 7 defining the CGA Message Type tag to be allocated 2632 for this protocol. 2634 Authors' Addresses 2636 Jari Arkko 2637 Ericsson Research NomadicLab 2638 FI-02420 Jorvas 2639 Finland 2641 Email: jari.arkko@ericsson.com 2643 Christian Vogt 2644 Institute of Telematics 2645 Universitaet Karlsruhe (TH) 2646 P.O. Box 6980 2647 76128 Karlsruhe 2648 Germany 2650 Email: chvogt@tm.uka.de 2652 Wassim Haddad 2653 Ericsson Research 2654 8400, Decarie Blvd 2655 Town of Mount Royal 2656 Quebec H4P 2N2, Canada 2658 Email: wassim.haddad@ericsson.com 2660 Full Copyright Statement 2662 Copyright (C) The IETF Trust (2007). 2664 This document is subject to the rights, licenses and restrictions 2665 contained in BCP 78, and except as set forth therein, the authors 2666 retain all their rights. 2668 This document and the information contained herein are provided on an 2669 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2670 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2671 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2672 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2673 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2674 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2676 Intellectual Property 2678 The IETF takes no position regarding the validity or scope of any 2679 Intellectual Property Rights or other rights that might be claimed to 2680 pertain to the implementation or use of the technology described in 2681 this document or the extent to which any license under such rights 2682 might or might not be available; nor does it represent that it has 2683 made any independent effort to identify any such rights. Information 2684 on the procedures with respect to rights in RFC documents can be 2685 found in BCP 78 and BCP 79. 2687 Copies of IPR disclosures made to the IETF Secretariat and any 2688 assurances of licenses to be made available, or the result of an 2689 attempt made to obtain a general license or permission for the use of 2690 such proprietary rights by implementers or users of this 2691 specification can be obtained from the IETF on-line IPR repository at 2692 http://www.ietf.org/ipr. 2694 The IETF invites any interested party to bring to its attention any 2695 copyrights, patents or patent applications, or other proprietary 2696 rights that may cover technology that may be required to implement 2697 this standard. Please address the information to the IETF at 2698 ietf-ipr@ietf.org. 2700 Acknowledgment 2702 Funding for the RFC Editor function is provided by the IETF 2703 Administrative Support Activity (IASA).