idnits 2.17.1 draft-ietf-mipshop-handover-key-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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 605. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 581. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 588. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 594. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 21 has weird spacing: '... other grou...' == Line 25 has weird spacing: '... months and ...' == Line 53 has weird spacing: '...; that is, ...' == Line 95 has weird spacing: '...bitrary time ...' == Line 105 has weird spacing: '... when the ...' == (27 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'FMIP' ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 James Kempf 2 Internet Draft DoCoMo Labs USA 3 Document: draft-ietf-mipshop-handover-key-03.txt Rajeev Koodli 4 Intended Status: Proposed Standard Nokia-Siemens 5 Research 6 Center 7 Expires: May, 2008 November, 2007 9 Distributing a Symmetric FMIPv6 Handover Key using SEND 10 (draft-ietf-mipshop-handover-key-03.txt) 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet-Drafts 27 as reference material or to cite them other than as "work in 28 progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 Fast Mobile IPv6 requires that a Fast Binding Update is secured 39 using a security association shared between an Access Router and a 40 Mobile Node in order to avoid certain attacks. In this document, a 41 method for provisioning a shared key from the Access Router to the 42 Mobile Node is defined to protect this signaling. The Mobile Node 43 generates a public/private key pair using the same public key 44 algorithm as for SEND (RFC 3971). The Mobile Node sends the public 45 key to the Access Router. The Access Router encrypts a shared 46 handover key using the public key and sends it back to the Mobile 47 Node. The Mobile Node decrypts the shared handover key using the 48 matching private key, and the handover key is then available for 49 generating an authenticator on a Fast Binding Update. The Mobile 50 Node and Access Router use the Router Solicitation for Proxy 51 Advertisement and Proxy Router Advertisement from Fast Mobile IPv6 52 for the key exchange. The key exchange messages are required to 53 have SEND security; that is, the source address is a 54 Cryptographically Generated Address and the messages are signed 55 using the CGA private key of the sending node. This allows the 56 Access Router, prior to providing the shared handover key, to 57 verify the authorization of the Mobile Node to claim the address 58 so that the previous care-of CGA in the Fast Binding Update can 59 act as the name of the key. 61 Table of Contents 63 1.0 Introduction.............................................2 64 2.0 Overview of the Protocol.................................3 65 3.0 Handover Key Provisioning and Use........................4 66 4.0 Message Formats..........................................7 67 5.0 Security Considerations.................................10 68 6.0 IANA Considerations.....................................10 69 7.0 Normative References....................................10 70 8.0 Informative References..................................11 71 9.0 Author Information......................................11 72 10.0 IPR Statements.........................................11 73 11.0 Disclaimer of Validity.................................12 74 12.0 Copyright Statement....................................12 75 13.0 Acknowledgment.........................................12 77 1.0 Introduction 79 In Fast Mobile IPv6 (FMIPv6) [FMIP], a Fast Binding Update (FBU) 80 is sent from a Mobile Node (MN), undergoing IP handover, to the 81 previous Access Router (AR). The FBU causes a routing change so 82 traffic sent to the MN's previous care-of address on the previous 83 AR's link is tunneled to the new care-of address on the new AR's 84 link. Only a MN authorized to claim the address should be able to 85 change the routing for the previous care-of address. If such 86 authorization is not established, an attacker can redirect a 87 victim MN's traffic at will. 89 In this document, a lightweight mechanism is defined by which a 90 shared handover key for securing FMIP can be provisioned on the MN 91 by the AR. The mechanism utilizes SEND [SEND] and an additional 92 public/private key pair, generated on the MN using the same public 93 key algorithm as SEND, to encrypt/decrypt a shared handover key 94 sent from the AR to the MN. The key provisioning occurs at some 95 arbitrary time prior to handover, thereby relieving any 96 performance overhead on the handover process. The message exchange 97 between the MN and AR to provision the handover key is required to 98 be protected by SEND; that is, the source address for the key 99 provisioning messages must be a CGA and the messages must be signed 100 with the CGA private key. This allows the AR to establish the MN's 101 authorization to operate on the CGA. The AR uses the CGA to name 102 the handover key. The SEND key pair is, however, independent from 103 the handover encryption/decryption key pair and from the actual 104 handover key. Once the shared handover key has been established, 105 when the MN undergoes IP handover, the MN generates an 106 authorization MAC on the FBU. The previous care-of CGA included in 107 the FBU is used by the AR to find the right handover key for 108 checking the authorization. 110 Handover keys are an instantiation of the purpose built key 111 architectural principle [PBK]. 113 1.1 Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 116 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 117 "OPTIONAL" in this document are to be interpreted as described in 118 RFC 2119 [RFC2119]. 120 In addition, the following terminology is used: 122 CGA public key 124 Public key used to generate the CGA according to RFC 3972 125 [CGA]. 127 CGA private key 129 Private key corresponding to the CGA public key. 131 Handover key encryption public key 133 Public key generated by the MN and sent to the current AR to 134 encrypt the shared handover key 136 Handover key encryption private key 138 Private key corresponding to handover key encryption public 139 key, held by the MN 141 2.0 Overview of the Protocol 143 2.1 Brief Review of SEND 145 SEND protects against a variety of threats to local link address 146 resolution (also known as Neighbor Discovery) and last hop router 147 (AR) discovery in IPv6 [RFC3756]. These threats are not exclusive 148 to wireless networks, but they generally are easier to mount on 149 certain wireless networks because the link between the access 150 point and MN can't be physically secured. 152 SEND utilizes CGAs in order to secure Neighbor Discovery signaling 153 [CGA]. Briefly, a CGA is formed by hashing together the IPv6 154 subnet prefix for a node's subnet, a random nonce, and an RSA 155 public key, called the CGA public key. The CGA private key is used 156 to sign a Neighbor Advertisement (NA) message sent to resolve the 157 link layer address to the IPv6 address. The combination of the CGA 158 and the signature on the NA proves to a receiving node the 159 sender's authorization to claim the address. The node may 160 opportunistically generate one or several keys specifically for 161 SEND, or it may use a certified key that it distributes more 162 widely. 164 2.2 Protocol Overview 166 The protocol utilizes the SEND secured Router Solicitation for 167 Proxy Advertisement (RtSolPr)/Proxy Router Advertisement (PrRtAdv) 168 [FMIP] exchange between the MN and the AR to transport an 169 encrypted, shared handover key from the AR to the MN. First, the 170 MN generates the necessary key pair and associated CGA addresses 171 so that the MN can employ SEND. Then the MN generates a 172 public/private key pair for encrypting/decrypting the shared 173 handover key, using the same public key algorithm as was used for 174 SEND. The MN then sends a RtSolPr message with a Handover Key 175 Request Option containing the handover key encryption public key. 176 The source address of the RtSolPr message is the MN's care-of CGA 177 on the AR's link, the RtSolPr message is signed with the MN's CGA 178 key, and contains the CGA Parameters option, in accordance with 179 RFC 3971 [SEND]. The AR verifies the message using SEND, then 180 utilizes the handover key encryption public key to encrypt a 181 shared handover key, which is included with the PrRtAdv in the 182 Handover Key Reply Option. The MN decrypts the shared handover key 183 and uses it to establish an authorization MAC when it sends an FBU 184 to the previous AR. 186 3.0 Handover Key Provisioning and Use 188 3.1 Sending Router Solicitations for Proxy Advertisement 190 At some time prior to handover, the MN MUST generate a handover 191 key encryption public/private key pair, using exactly the same 192 public key algorithm with exactly the same parameters (key size, 193 etc.) as for SEND [SEND]. The MN can reuse the key pair on 194 different access routers but MUST NOT use the key pair for any 195 other encryption or for signature operation. In order to prevent 196 cryptanalysis, the key pair SHOULD be discarded after either a 197 duration of HKEPK-LIFETIME or HKEPK-HANDOVERS number of handovers, 198 whichever occurs first. See Section 3.7 for definitions of 199 protocol constants. 201 The MN MUST send a Router Solicitation for Proxy Advertisement 202 (RtSolPr) containing a Handover Key Request Option with the 203 handover encryption public key. A CGA for the MN MUST be the 204 source address on the packet, and the MN MUST include the SEND CGA 205 Option and SEND Signature Option with the packet, as specified in 206 [SEND]. The SEND signature covers all fields in the RtSolPr, 207 including the 128 bit source and destination addresses and ICMP 208 checksum as described in RFC 3971, except for the Signature Option 209 itself. The MN also sets the handover authentication Algorithm 210 Type (AT) extension field in the Handover Key Request Option to 211 the MN's preferred FBU authentication algorithm. The SEND Nonce 212 MUST also be included for anti-replay protection. 214 3.2 Receiving Router Solicitations for Proxy Advertisement and Sending 215 Proxy Router Advertisements 217 When an FMIPv6 capable AR with SEND receives a RtSolPr from a MN 218 protected with SEND and including a Handover Key Request Option, 219 the AR MUST first validate the RtSolPr using SEND as described in 220 RFC 3971. If the RtSolPr can not be validated, the AR MUST NOT 221 include a Handover Key Reply Option in the reply. The AR also MUST 222 NOT change any existing key record for the address, since the 223 message may be an attempt by an attacker to disrupt communications 224 for a legitimate MN. The AR SHOULD respond to the RtSolPr but MUST 225 NOT perform handover key provisioning. 227 If the RtSolPr can be validated, the AR MUST then determine 228 whether the CGA is already associated with a shared handover key. 229 If the CGA is associated with an existing handover key, the AR 230 MUST return the existing handover key to the MN. If the CGA does 231 not have a shared handover key, the AR MUST construct a shared 232 handover key as described in Section 3.6. The AR MUST encrypt the 233 handover key with the handover key encryption public key included 234 in the Handover Key Request Option. The AR MUST insert the 235 encrypted handover key into a Handover Key Reply Option and MUST 236 attach the Handover Key Reply Option to the PrRtAdv. The lifetime 237 of the key, HK-LIFETIME, MUST also be included in the Handover Key 238 Reply Option. The AR SHOULD set the AT field of the Handover Key 239 Option to the MN's preferred algorithm type indicated in the AT 240 field of the Handover Key Request Option, if it is supported; 241 otherwise, the AR MUST select an authentication algorithm which is 242 of equivalent strength or stronger and set the field to that. The 243 AR MUST also include the SEND nonce from the RtSolPr for anti- 244 replay protection. The AR MUST use the CGA constructed from its 245 certified key as the source address for the PrRtAdv and include a 246 SEND CGA Option and a SEND Signature Option with the SEND 247 signature of the message. The SEND signature covers all fields in 248 the PrRtAdv, including the 128 bit source and destination 249 addresses and ICMP checksum as described in RFC 3971, except for 250 the Signature Option itself. The PrRtAdv is then unicast back to 251 the MN at the MN's care-of CGA that was the source address on the 252 RtSolPr. The handover key MUST be stored by the AR for future use, 253 indexed by the CGA, and the authentication algorithm type (i.e., 254 the resolution of the AT field processing) and HK-LIFETIME MUST be 255 recorded with the key. 257 3.3 Receiving Proxy Router Advertisements 259 Upon receipt of one or more PrRtAdvs secured with SEND and having 260 the Handover Key Reply Option, the MN MUST first validate the 261 PrRtAdvs as described in RFC 3971. Normally the MN will have 262 obtained the router's certification path to validate an RA prior 263 to sending the PrRtSol and the MN MUST check to ensure that the 264 key used to sign the PrRtAdv is the router's certified public key. 266 If the MN does not have the router's certification path cached, it 267 MUST use the SEND CPS/CPA messages to obtain the certification 268 path to validate the key. If a certified key from the router was 269 not used to sign the message, the message MUST be dropped. 271 From the messages that validate, the MN SHOULD choose one with an 272 AT flag in the Handover Key Reply Option indicating an 273 authentication algorithm that the MN supports. From that message, 274 the MN MUST determine which handover key encryption public key to 275 use in the event the MN has more than one. The MN finds the right 276 public key to use by matching the SEND nonce from the RtSolPr. If 277 no such match occurs, the MN MUST drop the PrRtAdv. The MN MUST 278 use the matching private key to decrypt the handover key using its 279 handover key encryption private key, and store the handover key 280 for later use, named with the AR's CGA, along with the algorithm 281 type and HK-LIFETIME. The MN MUST use the returned algorithm type 282 indicated in the PrRtAdv. The MN MUST index the handover keys with 283 the AR's IPv6 address, to which the MN later sends the FBU, and 284 the MN's CGA to which the handover key applies. This allows the MN 285 to select the proper key when communicating with a previous AR. 286 Prior to HK-LIFETIME expiring, the MN MUST request a new key from 287 the AR if FMIPv6 service is still required from the router. 289 If more than one router responds to the RtSolPr, the MN MAY keep 290 track of all such keys. If none of the PrRtAdvs contains an 291 algorithm type indicator corresponding to an algorithm the MN 292 supports, the MN MAY re-send the RtSolPr requesting a different 293 algorithm, but to prevent bidding down attacks from compromised 294 routers, the MN SHOULD NOT request an algorithm that is weaker 295 than its original request. 297 3.4 Sending FBUs 299 When the MN needs to signal the Previous AR (PAR) using an FMIPv6 300 FBU, the MN MUST utilize the handover key and the corresponding 301 authentication algorithm to generate an authenticator for the 302 message. The MN MUST select the appropriate key for the PAR using 303 the PAR's CGA and the MN's previous care-of CGA on the PAR's link. 304 As defined by the FMIPv6 [FMIP], the MN MUST generate the 305 authentication MAC using the handover key and the appropriate 306 algorithm and MUST include the MAC in the FBU message. As 307 specified by FMIPv6, the MN MUST include the old care-of CGA in a 308 Home Address Option. The FMIPv6 document provides more detail 309 about the construction of the authenticator on the FBU. 311 3.5 Receiving FBUs 313 When the PAR receives an FBU message containing an authenticator, 314 the PAR MUST find the corresponding handover key using the MN's 315 care-of CGA in the Home Address Option as the index. If a handover 316 key is found, the PAR MUST utilize the handover key and the 317 appropriate algorithm to verify the authenticator. If the handover 318 key is not found, the PAR MUST NOT change forwarding for the care- 319 of CGA. The FMIPv6 document [FMIP] provides more detail on how the 320 AR processes an FBU containing an authenticator. 322 3.6 Key Generation and Lifetime 324 The AR MUST randomly generate a key having sufficient strength to 325 match the authentication algorithm. Some authentication algorithms 326 specify a required key size. The AR MUST generate a unique key for 327 each CGA public key, and SHOULD take care that the key generation 328 is uncorrelated between handover keys, and between handover keys 329 and CGA keys. The actual algorithm used to generate the key is not 330 important for interoperability since only the AR generates the 331 key; the MN simply uses it. 333 A PAR SHOULD NOT discard the handover key immediately after use if 334 it is still valid. It is possible that the MN may undergo rapid 335 movement to another AR prior to the completion of Mobile IPv6 336 binding update on the PAR, and the MN MAY as a consequence 337 initialize another, subsequent handover optimization to move 338 traffic from the PAR to another new AR. The default time for 339 keeping the key valid corresponds to the default time during which 340 forwarding from the PAR to the new AR is performed for FMIP. The 341 FMIPv6 document [FMIP] provides more detail about the FMIP 342 forwarding time default. 344 If the MN returns to a PAR prior to the expiration of the handover 345 key, the PAR MAY send and the MN MAY receive the same handover key 346 as was previously returned, if the MN generates the same CGA for 347 its care-of address. However, the MN MUST NOT assume that it can 348 continue to use the old key without actually receiving the 349 handover key again from the PAR. The MN SHOULD discard the 350 handover key after MIPv6 binding update is complete on the new AR. 351 The PAR MUST discard the key after FMIPv6 forwarding for the 352 previous care-of address times out or when HK-LIFETIME expires. 354 3.7 Protocol Constants 356 The following are protocol constants with suggested defaults: 358 HKEPK-LIFETIME: The maximum lifetime for the handover key 359 encryption public key. Default is 12 hours. 361 HKEPK-HANDOVERS: The maximum number of handovers for which the 362 handover key encryption public key should be 363 reused. Default is 10. 365 HK-LIFETIME: The maximum lifetime for the handover key. 366 Default is 12 hours (43200 seconds). 368 4.0 Message Formats 370 4.1 Handover Key Request Option 371 The Handover Key Request Option is a standard IPv6 Neighbor 372 Discovery [RFC2461] option in TLV format. The Handover Key Request 373 Option is included in the RtSolPr message along with the SEND CGA 374 Option, RSA Signature Option, and Nonce Option. 376 0 1 2 3 377 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 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Type | Length | Pad Length | AT |Resrvd.| 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | | 382 . . 383 . Handover Key Encryption Public Key . 384 . . 385 | | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | | 388 . . 389 . Padding . 390 . . 391 | | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 Fields: 396 Type: To be assigned by IANA. 398 Length: The length of the option in units of 8 octets, 399 including the Type and Length fields. The value 0 400 is invalid. The receiver MUST discard a message 401 that contains this value. 403 Pad Length: The number of padding octets beyond the end of the 404 Handover Key Encryption Public Key field but 405 within the length specified by the Length field. 406 Padding octets MUST be set to zero by senders and 407 ignored by receivers. 409 AT: A 4-bit algorithm type field describing the 410 algorithm used by FMIPv6 to calculate the 411 authenticator. See [FMIP] for details. 413 Resrvd.: A 4-bit field reserved for future use. The value 414 MUST be initialized to zero by the sender and MUST 415 be ignored by the receiver. 417 Handover Key Encryption Public Key: 419 The handover key encryption public key. The key 420 MUST be formatted according to the same 421 specification as the CGA key in the CGA Parameters 422 Option [CGA] of the message, and MUST have the 423 same parameters as the CGA key. 425 Padding: A variable-length field making the option length a 426 multiple of 8, containing as many octets as 427 specified in the Pad Length field. 429 4.2 Handover Key Reply Option 431 The Handover Key Reply Option is a standard IPv6 Neighbor 432 Discovery [RFC2461] option in TLV format. The Handover Key Reply 433 Option is included in the PrRtAdv message along with the SEND CGA 434 Option, RSA Signature Option, and Nonce Option. 436 0 1 2 3 437 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 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Type | Length | Pad Length | AT |Resrvd.| 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Key Lifetime | | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | | 444 | | 445 . . 446 . Encrypted Handover Key . 447 . . 448 | | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | | 451 . . 452 . Padding . 453 . . 454 | | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 Fields: 459 Type: To be assigned by IANA. 461 Length: The length of the option in units of 8 octets, 462 including the Type and Length fields. The value 0 463 is invalid. The receiver MUST discard a message 464 that contains this value. 466 Pad Length: The number of padding octets beyond the end of the 467 Encrypted Handover Key field but within the length 468 specified by the Length field. Padding octets MUST 469 be set to zero by senders and ignored by 470 receivers. 472 AT: A 4-bit algorithm type field describing the 473 algorithm used by FMIPv6 to calculate the 474 authenticator. See [FMIP] for details. 476 Resrvd.: A 4-bit field reserved for future use. The value 477 MUST be initialized to zero by the sender and MUST 478 be ignored by the receiver. 480 Key Lifetime: Lifetime of the handover key, HK-LIFETIME, in 481 seconds. 483 Encrypted Handover Key: 485 The shared handover key, encrypted with the MN's 486 handover key encryption public key, using the 487 RSAES-PKCS1-v1_5 format [RFC3447]. 489 Padding: A variable-length field making the option length a 490 multiple of 8, containing as many octets as 491 specified in the Pad Length field. 493 5.0 Security Considerations 495 This document describes a shared key provisioning protocol for the 496 FMIPv6 handover optimization protocol. The key provisioning 497 protocol utilizes a public key generated with the same public key 498 algorithm as SEND to bootstrap a shared key for authorizing 499 changes due to handover associated with the MN's former address on 500 the PAR. General security considerations involving CGAs apply to 501 the protocol described in this document, see [CGA] for a 502 discussion of security considerations around CGAs. This protocol 503 is subject to the same risks from replay attacks and DoS attacks 504 using the RtSolPr as the SEND protocol [SEND] for RS. The measures 505 recommended in RFC 3971 for mitigating replay attacks and DoS 506 attacks apply here as well. An additional consideration involves 507 when to generate the handover key on the AR. To avoid state 508 depletion attacks, the handover key SHOULD NOT be generated prior 509 to SEND processing that verifies the originator of RtSolPr. State 510 depletion attacks can be addressed by techniques such as rate 511 limiting RtSolPr, restricting the amount of state reserved for 512 unresolved solicitations, and clever cache management. These 513 techniques are the same as used in implementing Neighbor 514 Discovery. 516 For other FMIPv6 security considerations, please see the FMIPv6 517 document [FMIP]. 519 6.0 IANA Considerations 521 Two new IPv6 Neighbor Discovery options, the Handover Key Request 522 Option and Handover Key Reply Option, are defined, and require a 523 IPv6 Neighbor Discovery option type code from IANA. 525 7.0 Normative References 527 [FMIP] Koodli, R., editor, "Fast Handovers for Mobile IPv6", 528 Internet Draft, Work in Progress. 530 [SEND] Arkko, J., editor, Kempf, J., Zill, B., and Nikander, P., 531 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 533 [CGA] Aura, T., "Cryptographically Generated Addresses", RFC 3972, 534 March 2005. 536 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 537 Requirement Levels", RFC 2119, March 1997. 539 [RFC2461] Narten, T., and Nordmark, E., "Neighbor Discovery for IP 540 version 6 (IPv6)", RFC 2461, December 1998. 542 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 543 Standards (PKCS) #1: RSA Cryptography Specifications 544 Version 2.1", RFC 3447, February 2003. 546 8.0 Informative References 548 [RFC3756] Nikander, P., editor, Kempf, J., and Nordmark, E., " 549 IPv6 Neighbor Discovery (ND) Trust Models and Threats", 550 RFC 3756, May 2004. 552 [PBK] Bradner, S., Mankin, A., and Schiller, J., "A Framework for 553 Purpose-Built Keys (PBK)", Internet Draft, work in 554 progress. 556 9.0 Author Information 558 James Kempf Phone: +1 650 496 4711 559 DoCoMo Labs USA Email: kempf@docomolabs-usa.com 560 3240 Hillview Avenue 561 Palo Alto, CA 562 94303 563 USA 565 Rajeev Koodli Phone: +1 650 625 2359 566 Nokia-Siemens Research Center Fax: +1 650 625 2502 567 313 Fairchild Drive Email: Rajeev.Koodli@nokia.com 568 Mountain View, CA 569 94043 570 USA 572 10.0 IPR Statements 574 The IETF takes no position regarding the validity or scope of any 575 Intellectual Property Rights or other rights that might be claimed 576 to pertain to the implementation or use of the technology described 577 in this document or the extent to which any license under such 578 rights might or might not be available; nor does it represent that 579 it has made any independent effort to identify any such rights. 580 Information on the procedures with respect to rights in RFC 581 documents can be found in BCP 78 and BCP 79. 583 Copies of IPR disclosures made to the IETF Secretariat and any 584 assurances of licenses to be made available, or the result of an 585 attempt made to obtain a general license or permission for the use 586 of such proprietary rights by implementers or users of this 587 specification can be obtained from the IETF on-line IPR repository 588 at http://www.ietf.org/ipr. 590 The IETF invites any interested party to bring to its attention any 591 copyrights, patents or patent applications, or other proprietary 592 rights that may cover technology that may be required to implement 593 this standard. Please address the information to the IETF at 594 ietf-ipr@ietf.org. 596 11.0 Disclaimer of Validity 598 This document and the information contained herein are provided on 599 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 600 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 601 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 602 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 603 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 604 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 605 FOR A PARTICULAR PURPOSE. 607 12.0 Copyright Statement 609 Copyright (C) The IETF Trust (2007). 611 This document is subject to the rights, licenses and restrictions 612 contained in BCP 78, and except as set forth therein, the authors 613 retain all their rights. 615 13.0 Acknowledgments 617 Funding for the RFC Editor function is currently provided by the 618 Internet Society. 620 The authors would like to thank John C. Mitchell and Arnab Roy, of 621 Stanford University, for their review of the design and suggestions 622 for improving it.