Network Working Group J. Kempf
Request for Comments: 5269 DoCoMo Labs USA
Category: Standards Track R. Koodli
Starent Networks
June 2008
Network Working Group J. Kempf
Request for Comments: 5269 DoCoMo Labs USA
Category: Standards Track R. Koodli
Starent Networks
June 2008
Distributing a Symmetric Fast Mobile IPv6 (FMIPv6) Handover Key Using SEcure Neighbor Discovery (SEND)
使用安全邻居发现（SEND）分发对称快速移动IPv6（FMIPv6）切换密钥
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
Fast Mobile IPv6 requires that a Fast Binding Update is secured using a security association shared between an Access Router and a Mobile Node in order to avoid certain attacks. In this document, a method for provisioning a shared key from the Access Router to the Mobile Node is defined to protect this signaling. The Mobile Node generates a public/private key pair using the same public key algorithm as for SEND (RFC 3971). The Mobile Node sends the public key to the Access Router. The Access Router encrypts a shared handover key using the public key and sends it back to the Mobile Node. The Mobile Node decrypts the shared handover key using the matching private key, and the handover key is then available for generating an authenticator on a Fast Binding Update. The Mobile Node and Access Router use the Router Solicitation for Proxy Advertisement and Proxy Router Advertisement from Fast Mobile IPv6 for the key exchange. The key exchange messages are required to have SEND security; that is, the source address is a Cryptographically Generated Address (CGA) and the messages are signed using the CGA private key of the sending node. This allows the Access Router, prior to providing the shared handover key, to verify the authorization of the Mobile Node to claim the address so that the previous care-of CGA in the Fast Binding Update can act as the name of the key.
快速移动IPv6要求使用接入路由器和移动节点之间共享的安全关联来保护快速绑定更新，以避免某些攻击。在本文档中，定义了从接入路由器向移动节点提供共享密钥的方法，以保护该信令。移动节点使用与发送相同的公钥算法生成公钥/私钥对（RFC 3971）。移动节点向接入路由器发送公钥。接入路由器使用公钥加密共享切换密钥并将其发送回移动节点。移动节点使用匹配私钥解密共享切换密钥，然后切换密钥可用于在快速绑定更新上生成验证器。移动节点和接入路由器使用路由器请求代理播发和来自快速移动IPv6的代理路由器播发进行密钥交换。密钥交换消息要求具有发送安全性；也就是说，源地址是加密生成的地址（CGA），并且使用发送节点的CGA私钥对消息进行签名。这允许接入路由器在提供共享切换密钥之前，验证移动节点请求地址的授权，以便快速绑定更新中先前的CGA照顾可以充当密钥的名称。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. Overview of the Protocol ........................................3
2.1. Brief Review of SEND .......................................3
2.2. Protocol Overview ..........................................4
3. Handover Key Provisioning and Use ...............................4
3.1. Sending Router Solicitations for Proxy Advertisement .......4
3.2. Receiving Router Solicitations for Proxy
Advertisement and Sending Proxy Router Advertisements ......5
3.3. Receiving Proxy Router Advertisements ......................6
3.4. Sending FBUs ...............................................7
3.5. Receiving FBUs .............................................7
3.6. Key Generation and Lifetime ................................7
3.7. Protocol Constants .........................................8
4. Message Formats .................................................8
4.1. Handover Key Request Option ................................8
4.2. Handover Key Reply Option .................................10
5. Security Considerations ........................................11
6. IANA Considerations ............................................11
7. References .....................................................12
7.1. Normative References ......................................12
7.2. Informative References ....................................12
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. Overview of the Protocol ........................................3
2.1. Brief Review of SEND .......................................3
2.2. Protocol Overview ..........................................4
3. Handover Key Provisioning and Use ...............................4
3.1. Sending Router Solicitations for Proxy Advertisement .......4
3.2. Receiving Router Solicitations for Proxy
Advertisement and Sending Proxy Router Advertisements ......5
3.3. Receiving Proxy Router Advertisements ......................6
3.4. Sending FBUs ...............................................7
3.5. Receiving FBUs .............................................7
3.6. Key Generation and Lifetime ................................7
3.7. Protocol Constants .........................................8
4. Message Formats .................................................8
4.1. Handover Key Request Option ................................8
4.2. Handover Key Reply Option .................................10
5. Security Considerations ........................................11
6. IANA Considerations ............................................11
7. References .....................................................12
7.1. Normative References ......................................12
7.2. Informative References ....................................12
In Fast Mobile IPv6 (FMIPv6) [FMIP], a Fast Binding Update (FBU) is sent from a Mobile Node (MN), undergoing IP handover, to the previous Access Router (AR). The FBU causes a routing change so traffic sent to the MN's previous Care-of Address on the previous AR's link is tunneled to the new Care-of Address on the new AR's link. Only an MN authorized to claim the address should be able to change the routing for the previous Care-of Address. If such authorization is not established, an attacker can redirect a victim MN's traffic at will.
在快速移动IPv6（FMIPv6）[FMIP]中，快速绑定更新（FBU）从正在进行IP切换的移动节点（MN）发送到先前的接入路由器（AR）。FBU导致路由改变，因此发送到MN在前一AR链路上的前一转交地址的流量通过隧道传输到新AR链路上的新转交地址。只有授权声明该地址的MN才能更改先前转交地址的路由。如果未建立此类授权，攻击者可以随意重定向受害者MN的流量。
In this document, a lightweight mechanism is defined by which a shared handover key for securing FMIP can be provisioned on the MN by the AR. The mechanism utilizes SEND [SEND] and an additional public/private key pair, generated on the MN using the same public key algorithm as SEND, to encrypt/decrypt a shared handover key sent from the AR to the MN. The key provisioning occurs at some arbitrary time prior to handover, thereby relieving any performance overhead on the handover process. The message exchange between the MN and AR to provision the handover key is required to be protected by SEND; that is, the source address for the key provisioning messages must be a CGA and the messages must be signed with the CGA private key. This allows the AR to establish the MN's authorization to operate on the
在本文档中，定义了一种轻量级机制，通过该机制，AR可以在MN上提供用于保护FMIP的共享切换密钥。该机制利用SEND[SEND]和使用与SEND相同的公钥算法在MN上生成的附加公钥/私钥对，加密/解密从AR发送到MN的共享切换密钥。密钥提供在切换之前的任意时间发生，从而减轻切换过程中的任何性能开销。MN和AR之间用于提供切换密钥的消息交换需要受到SEND的保护；也就是说，密钥设置消息的源地址必须是CGA，并且消息必须使用CGA私钥签名。这允许AR建立MN在网络上运行的授权
CGA. The AR uses the CGA to name the handover key. The SEND key pair is, however, independent from the handover encryption/decryption key pair and from the actual handover key. Once the shared handover key has been established, when the MN undergoes IP handover, the MN generates an authorization Message Authentication Code (MAC) on the FBU. The previous care-of CGA included in the FBU is used by the AR to find the right handover key for checking the authorization.
CGA。AR使用CGA来命名切换密钥。然而，发送密钥对独立于切换加密/解密密钥对和实际切换密钥。一旦建立了共享切换密钥，当MN进行IP切换时，MN在FBU上生成授权消息认证码（MAC）。AR使用FBU中包含的先前CGA转交来查找用于检查授权的正确移交密钥。
Handover keys are an instantiation of the purpose built key architectural principle [PBK].
移交密钥是专用密钥体系结构原则[PBK]的一个实例。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
In addition, the following terminology is used:
此外，还使用了以下术语：
CGA public key
CGA公钥
Public key used to generate the CGA according to RFC 3972 [CGA].
用于根据RFC 3972[CGA]生成CGA的公钥。
CGA private key
CGA私钥
Private key corresponding to the CGA public key.
与CGA公钥对应的私钥。
Handover key encryption public key
切换密钥加密公钥
Public key generated by the MN and sent to the current AR to encrypt the shared handover key.
MN生成并发送给当前AR的公钥，用于加密共享切换密钥。
Handover key encryption private key
切换密钥加密私钥
Private key corresponding to handover key encryption public key, held by the MN.
与切换密钥加密公钥相对应的私钥，由MN持有。
SEND protects against a variety of threats to local link address resolution (also known as Neighbor Discovery) and last hop router (AR) discovery in IPv6 [RFC3756]. These threats are not exclusive to wireless networks, but they generally are easier to mount on certain wireless networks because the link between the access point and MN can't be physically secured.
SEND可针对IPv6中本地链路地址解析（也称为邻居发现）和最后一跳路由器（AR）发现的各种威胁提供保护[RFC3756]。这些威胁并不是无线网络独有的，但它们通常更容易安装在某些无线网络上，因为接入点和MN之间的链路无法物理安全。
SEND utilizes CGAs in order to secure Neighbor Discovery signaling [CGA]. Briefly, a CGA is formed by hashing together the IPv6 subnet prefix for a node's subnet, a random nonce, and an RSA public key, called the CGA public key. The CGA private key is used to sign a Neighbor Advertisement (NA) message sent to resolve the link-layer address to the IPv6 address. The combination of the CGA and the signature on the NA proves to a receiving node the sender's authorization to claim the address. The node may opportunistically generate one or several keys specifically for SEND, or it may use a certified key that it distributes more widely.
SEND利用CGA来保护邻居发现信令[CGA]。简而言之，CGA是通过将节点子网的IPv6子网前缀、随机nonce和RSA公钥（称为CGA公钥）散列在一起形成的。CGA私钥用于对发送的邻居公告（NA）消息进行签名，以将链路层地址解析为IPv6地址。CGA和NA上的签名的组合向接收节点证明了发送方声明地址的授权。节点可以机会主义地生成一个或多个专门用于发送的密钥，或者可以使用其分布更广的认证密钥。
The protocol utilizes the SEND secured Router Solicitation for Proxy Advertisement (RtSolPr)/Proxy Router Advertisement (PrRtAdv) [FMIP] exchange between the MN and the AR to transport an encrypted, shared handover key from the AR to the MN. First, the MN generates the necessary key pair and associated CGA addresses so that the MN can employ SEND. Then, the MN generates a public/private key pair for encrypting/decrypting the shared handover key, using the same public key algorithm as was used for SEND. The MN then sends an RtSolPr message with a Handover Key Request Option containing the handover key encryption public key. The source address of the RtSolPr message is the MN's care-of CGA on the AR's link, the RtSolPr message is signed with the MN's CGA key, and contains the CGA Parameters option, in accordance with RFC 3971 [SEND]. The AR verifies the message using SEND, then utilizes the handover key encryption public key to encrypt a shared handover key, which is included with the PrRtAdv in the Handover Key Reply Option. The MN decrypts the shared handover key and uses it to establish an authorization MAC when it sends an FBU to the previous AR.
该协议利用MN和AR之间的代理广告发送安全路由器请求（RtSolPr）/代理路由器广告（PrRtAdv）[FMIP]交换来将加密的共享切换密钥从AR传输到MN。首先，MN生成必要的密钥对和相关联的CGA地址，以便MN可以使用SEND。然后，MN使用与发送相同的公钥算法生成用于加密/解密共享切换密钥的公钥/私钥对。然后，MN发送具有包含切换密钥加密公钥的切换密钥请求选项的RtSolPr消息。RtSolPr消息的源地址是MN在AR链路上对CGA的照管，RtSolPr消息根据RFC 3971[发送]用MN的CGA密钥签名，并包含CGA参数选项。AR使用发送验证消息，然后利用切换密钥加密公钥加密共享切换密钥，该共享切换密钥包含在切换密钥应答选项中的PrRtAdv中。MN解密共享切换密钥，并在向前一个AR发送FBU时使用该密钥建立授权MAC。
At some time prior to handover, the MN MUST generate a handover key encryption public/private key pair, using exactly the same public key algorithm with exactly the same parameters (key size, etc.) as for SEND [SEND]. The MN can reuse the key pair on different access routers but MUST NOT use the key pair for any other encryption or for signature operation. In order to prevent cryptanalysis, the key pair SHOULD be discarded after either a duration of HKEPK-LIFETIME or HKEPK-HANDOVERS number of handovers, whichever occurs first. See Section 3.7 for definitions of protocol constants.
在切换之前的某个时间，MN必须使用与SEND[发送]完全相同的参数（密钥大小等）的完全相同的公钥算法生成切换密钥加密公钥/私钥对。MN可以在不同的访问路由器上重用密钥对，但不得将密钥对用于任何其他加密或签名操作。为了防止密码分析，密钥对应在HKEPK-LIFET或HKEPK-HANDOVERS持续时间后丢弃。切换次数以先发生者为准。协议常数的定义见第3.7节。
The MN MUST send a Router Solicitation for Proxy Advertisement (RtSolPr) containing a Handover Key Request Option with the handover encryption public key. A CGA for the MN MUST be the source address on the packet, and the MN MUST include the SEND CGA Option and SEND Signature Option with the packet, as specified in [SEND]. The SEND signature covers all fields in the RtSolPr, including the 128-bit source and destination addresses and ICMP checksum as described in RFC 3971, except for the Signature Option itself. The MN also sets the handover authentication Algorithm Type (AT) extension field in the Handover Key Request Option to the MN's preferred FBU authentication algorithm. The SEND Nonce MUST also be included for anti-replay protection.
MN必须发送路由器请求代理播发（RtSolPr），其中包含具有切换加密公钥的切换密钥请求选项。MN的CGA必须是数据包上的源地址，MN必须包括发送CGA选项和发送签名选项，如[SEND]中所述。发送签名覆盖RtSolPr中的所有字段，包括RFC 3971中描述的128位源地址和目标地址以及ICMP校验和，签名选项本身除外。MN还将切换密钥请求选项中的切换认证算法类型（AT）扩展字段设置为MN的首选FBU认证算法。还必须包含SEND Nonce以防重放。
3.2. Receiving Router Solicitations for Proxy Advertisement and Sending Proxy Router Advertisements
3.2. 接收代理播发的路由器请求并发送代理路由器播发
When an FMIPv6 capable AR with SEND receives an RtSolPr from an MN protected with SEND and including a Handover Key Request Option, the AR MUST first validate the RtSolPr using SEND as described in RFC 3971. If the RtSolPr can not be validated, the AR MUST NOT include a Handover Key Reply Option in the reply. The AR also MUST NOT change any existing key record for the address, since the message may be an attempt by an attacker to disrupt communications for a legitimate MN. The AR SHOULD respond to the RtSolPr but MUST NOT perform handover key provisioning.
当具有发送功能的FMIPv6 AR从受发送保护的MN（包括切换密钥请求选项）接收RtSolPr时，AR必须首先使用RFC 3971中所述的发送验证RtSolPr。如果无法验证RtSolPr，AR不得在应答中包含切换密钥应答选项。AR也不得更改地址的任何现有密钥记录，因为该消息可能是攻击者试图中断合法MN的通信。AR应响应RtSolPr，但不得执行切换密钥设置。
If the RtSolPr can be validated, the AR MUST then determine whether the CGA is already associated with a shared handover key. If the CGA is associated with an existing handover key, the AR MUST return the existing handover key to the MN. If the CGA does not have a shared handover key, the AR MUST construct a shared handover key as described in Section 3.6. The AR MUST encrypt the handover key with the handover key encryption public key included in the Handover Key Request Option. The AR MUST insert the encrypted handover key into a Handover Key Reply Option and MUST attach the Handover Key Reply Option to the PrRtAdv. The lifetime of the key, HK-LIFETIME, MUST also be included in the Handover Key Reply Option. The AR SHOULD set the AT field of the Handover Key Option to the MN's preferred algorithm type indicated in the AT field of the Handover Key Request Option, if it is supported; otherwise, the AR MUST select an authentication algorithm that is of equivalent strength or stronger, and set the field to that. The AR MUST also include the SEND nonce from the RtSolPr for anti-replay protection. The AR MUST have a certificate suitable for a SEND-capable router, support SEND certificate discovery, and include a SEND CGA Option and a SEND Signature Option in the PrRtAdv messages it sends. Similarly, the mobile nodes MUST be configured with one or more SEND trust anchors so that they can verify these messages. The SEND signature covers
如果可以验证RtSolPr，AR随后必须确定CGA是否已经与共享切换密钥相关联。如果CGA与现有切换密钥相关联，AR必须将现有切换密钥返回给MN。如果CGA没有共享的切换密钥，AR必须按照第3.6节所述构造共享的切换密钥。AR必须使用切换密钥请求选项中包含的切换密钥加密公钥对切换密钥进行加密。AR必须将加密的切换密钥插入切换密钥回复选项，并且必须将切换密钥回复选项附加到PrRtAdv。密钥的生存期HK-LIFETY也必须包含在移交密钥应答选项中。AR应将切换密钥选项的AT字段设置为在切换密钥请求选项的AT字段中指示的MN的首选算法类型（如果支持）；否则，AR必须选择强度相等或更强的认证算法，并将字段设置为该算法。AR还必须包括来自RtSolPr的发送nonce，以实现防重放保护。AR必须具有适用于支持发送的路由器的证书，支持发送证书发现，并在其发送的PrRtAdv消息中包括发送CGA选项和发送签名选项。类似地，移动节点必须配置一个或多个发送信任锚，以便它们能够验证这些消息。发送签名封面
all fields in the PrRtAdv, including the 128-bit source and destination addresses and ICMP checksum as described in RFC 3971, except for the Signature Option itself. The PrRtAdv is then unicast back to the MN at the MN's care-of CGA that was the source address on the RtSolPr. The handover key MUST be stored by the AR for future use, indexed by the CGA, and the authentication algorithm type (i.e., the resolution of the AT field processing) and HK-LIFETIME MUST be recorded with the key.
PrRtAdv中的所有字段，包括RFC 3971中描述的128位源地址和目标地址以及ICMP校验和，签名选项本身除外。然后，PrRtAdv单播回MN，由MN负责，CGA是RtSolPr上的源地址。AR必须存储切换密钥以备将来使用，并由CGA编制索引，认证算法类型（即AT字段处理的分辨率）和HK-LIFE必须与密钥一起记录。
Upon receipt of one or more PrRtAdvs secured with SEND and having the Handover Key Reply Option, the MN MUST first validate the PrRtAdvs as described in RFC 3971. Normally, the MN will have obtained the router's certification path to validate an RA prior to sending the PrRtSol and the MN MUST check to ensure that the key used to sign the PrRtAdv is the router's certified public key. If the MN does not have the router's certification path cached, it MUST use the SEND CPS/CPA messages to obtain the certification path to validate the key. If a certified key from the router was not used to sign the message, the message MUST be dropped.
在接收到一个或多个由SEND保护并具有切换密钥应答选项的prrtadv后，MN必须首先按照RFC 3971中所述验证prrtadv。通常，MN将在发送PrRtSol之前获得路由器的认证路径以验证RA，MN必须检查以确保用于签署PrRtAdv的密钥是路由器的认证公钥。如果MN没有缓存路由器的认证路径，它必须使用SEND CPS/CPA消息来获取认证路径以验证密钥。如果没有使用来自路由器的认证密钥对消息进行签名，则必须删除该消息。
From the messages that validate, the MN SHOULD choose one with an AT flag in the Handover Key Reply Option indicating an authentication algorithm that the MN supports. From that message, the MN MUST determine which handover key encryption public key to use in the event the MN has more than one. The MN finds the right public key to use by matching the SEND nonce from the RtSolPr. If no such match occurs, the MN MUST drop the PrRtAdv. The MN MUST use the matching private key to decrypt the handover key using its handover key encryption private key, and store the handover key for later use, named with the AR's CGA, along with the algorithm type and HK-LIFETIME. The MN MUST use the returned algorithm type indicated in the PrRtAdv. The MN MUST index the handover keys with the AR's IPv6 address, to which the MN later sends the FBU, and the MN's CGA to which the handover key applies. This allows the MN to select the proper key when communicating with a previous AR. Prior to HK-LIFETIME expiring, the MN MUST request a new key from the AR if FMIPv6 service is still required from the router.
从验证的消息中，MN应选择在切换密钥应答选项中具有AT标志的消息，该标志指示MN支持的认证算法。根据该消息，MN必须确定在MN具有多个密钥的情况下使用哪个切换密钥加密公钥。MN通过匹配来自RtSolPr的SEND nonce来找到要使用的正确公钥。如果没有发生这种匹配，MN必须删除PrRtAdv。MN必须使用匹配的私钥来使用其切换密钥加密私钥对切换密钥进行解密，并存储切换密钥供以后使用，该密钥与AR的CGA一起命名，以及算法类型和HK-LIFET。MN必须使用PrRtAdv中指示的返回算法类型。MN必须使用AR的IPv6地址（MN随后向其发送FBU）和MN的CGA（切换密钥应用于该CGA）索引切换密钥。这允许MN在与以前的AR通信时选择正确的密钥。在HK-LIFET到期之前，如果路由器仍然需要FMIPv6服务，MN必须从AR请求新密钥。
If more than one router responds to the RtSolPr, the MN MAY keep track of all such keys. If none of the PrRtAdvs contains an algorithm type indicator corresponding to an algorithm the MN supports, the MN MAY re-send the RtSolPr requesting a different algorithm, but to prevent bidding down attacks from compromised routers, the MN SHOULD NOT request an algorithm that is weaker than its original request.
如果多个路由器响应RtSolPr，MN可以跟踪所有这样的密钥。如果没有一个prrtadv包含对应于MN支持的算法的算法类型指示符，MN可以重新发送请求不同算法的RtSolPr，但是为了防止来自受损路由器的竞价拒绝攻击，MN不应该请求比其原始请求弱的算法。
When the MN needs to signal the Previous AR (PAR) using an FMIPv6 FBU, the MN MUST utilize the handover key and the corresponding authentication algorithm to generate an authenticator for the message. The MN MUST select the appropriate key for the PAR using the PAR's CGA and the MN's previous care-of CGA on the PAR's link. As defined by the FMIPv6 [FMIP], the MN MUST generate the authentication MAC using the handover key and the appropriate algorithm and MUST include the MAC in the FBU message. As specified by FMIPv6, the MN MUST include the old care-of CGA in a Home Address Option. The FMIPv6 document provides more detail about the construction of the authenticator on the FBU.
当MN需要使用FMIPv6 FBU向前一AR（PAR）发送信号时，MN必须利用切换密钥和相应的认证算法为消息生成认证器。MN必须使用PAR的CGA和MN先前对PAR链路上的CGA的关注来选择PAR的适当密钥。根据FMIPv6[FMIP]的定义，MN必须使用切换密钥和适当的算法生成认证MAC，并且必须在FBU消息中包含MAC。按照FMIPv6的规定，MN必须在家庭地址选项中包含旧的CGA照顾。FMIPv6文档提供了有关FBU上认证器构造的更多详细信息。
When the PAR receives an FBU message containing an authenticator, the PAR MUST find the corresponding handover key using the MN's care-of CGA in the Home Address Option as the index. If a handover key is found, the PAR MUST utilize the handover key and the appropriate algorithm to verify the authenticator. If the handover key is not found, the PAR MUST NOT change forwarding for the care-of CGA. The FMIPv6 document [FMIP] provides more detail on how the AR processes an FBU containing an authenticator.
当PAR接收到包含认证器的FBU消息时，PAR必须使用家庭地址选项中的MN的CGA CARD作为索引找到相应的切换密钥。如果发现了切换密钥，则PAR必须利用切换密钥和适当的算法来验证认证器。如果没有找到切换密钥，PAR就不能改变转发来维护CGA。FMIPv6文档[FMIP]提供了AR如何处理包含验证器的FBU的更多详细信息。
The AR MUST randomly generate a key having sufficient strength to match the authentication algorithm. Some authentication algorithms specify a required key size. The AR MUST generate a unique key for each CGA public key, and SHOULD take care that the key generation is uncorrelated between handover keys, and between handover keys and CGA keys. The actual algorithm used to generate the key is not important for interoperability since only the AR generates the key; the MN simply uses it.
AR必须随机生成具有足够强度以匹配认证算法的密钥。某些身份验证算法指定所需的密钥大小。AR必须为每个CGA公钥生成唯一密钥，并且应注意密钥生成在切换密钥之间以及切换密钥和CGA密钥之间不相关。用于生成密钥的实际算法对于互操作性并不重要，因为只有AR生成密钥；MN只是使用它。
A PAR SHOULD NOT discard the handover key immediately after use if it is still valid. It is possible that the MN may undergo rapid movement to another AR prior to the completion of Mobile IPv6 binding update on the PAR, and the MN MAY as a consequence initialize another, subsequent handover optimization to move traffic from the PAR to another new AR. The default time for keeping the key valid corresponds to the default time during which forwarding from the PAR to the new AR is performed for FMIP. The FMIPv6 document [FMIP] provides more detail about the FMIP forwarding time default.
如果有效的话，PAR不应该在使用后立即丢弃切换键。在完成PAR上的移动IPv6绑定更新之前，MN可能会经历快速移动到另一AR，并且MN可以作为结果初始化另一个AR。随后的切换优化以将流量从PAR移动到另一个新的AR。保持密钥有效的默认时间对应于从FAR进行从PAR转发到新AR的默认时间。FMIPv6文档[FMIP]提供了有关FMIP转发时间默认值的更多详细信息。
If the MN returns to a PAR prior to the expiration of the handover key, the PAR MAY send and the MN MAY receive the same handover key as
如果MN在切换密钥到期之前返回到PAR，则PAR可以发送，并且MN可以接收相同的切换密钥。
was previously returned, if the MN generates the same CGA for its Care-of Address. However, the MN MUST NOT assume that it can continue to use the old key without actually receiving the handover key again from the PAR. The MN SHOULD discard the handover key after MIPv6 binding update is complete on the new AR. The PAR MUST discard the key after FMIPv6 forwarding for the previous Care-of Address times out or when HK-LIFETIME expires.
如果MN为其转交地址生成相同的CGA，则先前返回。然而，MN不能假定它可以继续使用旧密钥，而实际上不从PAR再次接收切换密钥。在新的ARM上完成MIPv6绑定更新之后，MN应该丢弃切换密钥。PAR必须在FMIPv6转发之后丢弃密钥，以用于先前的地址地址超时或HK寿命到期。
The following are protocol constants with suggested defaults:
以下是具有建议默认值的协议常量：
HKEPK-LIFETIME: The maximum lifetime for the handover key encryption public key. Default is 12 hours.
HKEPK-LIFET：切换密钥加密公钥的最大生存期。默认值为12小时。
HKEPK-HANDOVERS: The maximum number of handovers for which the handover key encryption public key should be reused. Default is 10.
HKEPK-切换：应重新使用切换密钥加密公钥的最大切换次数。默认值为10。
HK-LIFETIME: The maximum lifetime for the handover key. Default is 12 hours (43200 seconds).
HK-LIFET：切换密钥的最大生存期。默认值为12小时（43200秒）。
The Handover Key Request Option is a standard IPv6 Neighbor Discovery [RFC4861] option in TLV format. The Handover Key Request Option is included in the RtSolPr message along with the SEND CGA Option, RSA Signature Option, and Nonce Option.
切换密钥请求选项是TLV格式的标准IPv6邻居发现[RFC4861]选项。RtSolPr消息中包括切换密钥请求选项以及发送CGA选项、RSA签名选项和Nonce选项。
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Pad Length | AT |Resrvd.|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Handover Key Encryption Public Key .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Pad Length | AT |Resrvd.|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Handover Key Encryption Public Key .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
领域：
Type: 27
类型：27
Length: The length of the option in units of 8 octets, including the Type and Length fields. The value 0 is invalid. The receiver MUST discard a message that contains this value.
长度：选项的长度，以8个八位字节为单位，包括类型和长度字段。值0无效。接收方必须放弃包含此值的消息。
Pad Length: The number of padding octets beyond the end of the Handover Key Encryption Public Key field but within the length specified by the Length field. Padding octets MUST be set to zero by senders and ignored by receivers.
Pad Length：超出移交密钥加密公钥字段末尾但在长度字段指定长度内的填充八位字节数。发送方必须将填充八位字节设置为零，接收方必须忽略。
AT: A 4-bit algorithm type field describing the algorithm used by FMIPv6 to calculate the authenticator. See [FMIP] for details.
AT：一个4位算法类型字段，描述FMIPv6用于计算验证器的算法。有关详细信息，请参见[FMIP]。
Resrvd.: A 4-bit field reserved for future use. The value MUST be initialized to zero by the sender and MUST be ignored by the receiver.
Resrvd：保留供将来使用的4位字段。发送方必须将该值初始化为零，接收方必须忽略该值。
Handover Key Encryption Public Key: The handover key encryption public key. The key MUST be formatted according to the same specification as the CGA key in the CGA Parameters Option [CGA] of the message, and MUST have the same parameters as the CGA key.
切换密钥加密公钥：切换密钥加密公钥。密钥必须按照与消息的CGA参数选项[CGA]中的CGA密钥相同的规范进行格式化，并且必须具有与CGA密钥相同的参数。
Padding: A variable-length field making the option length a multiple of 8, containing as many octets as specified in the Pad Length field.
Padding：一个可变长度字段，使选项长度为8的倍数，包含Pad length字段中指定的八位字节数。
The Handover Key Reply Option is a standard IPv6 Neighbor Discovery [RFC4861] option in TLV format. The Handover Key Reply Option is included in the PrRtAdv message along with the SEND CGA Option, RSA Signature Option, and Nonce Option.
切换密钥应答选项是TLV格式的标准IPv6邻居发现[RFC4861]选项。PrRtAdv消息中包括切换密钥应答选项以及发送CGA选项、RSA签名选项和Nonce选项。
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Pad Length | AT |Resrvd.|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Lifetime | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
. .
. Encrypted Handover Key .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Pad Length | AT |Resrvd.|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Lifetime | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
. .
. Encrypted Handover Key .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
领域：
Type: 28
类型：28
Length: The length of the option in units of 8 octets, including the Type and Length fields. The value 0 is invalid. The receiver MUST discard a message that contains this value.
长度：选项的长度，以8个八位字节为单位，包括类型和长度字段。值0无效。接收方必须放弃包含此值的消息。
Pad Length: The number of padding octets beyond the end of the Encrypted Handover Key field but within the length specified by the Length field. Padding octets MUST be set to zero by senders and ignored by receivers.
Pad Length：超出加密的切换密钥字段末尾但在长度字段指定的长度内的填充八位字节数。发送方必须将填充八位字节设置为零，接收方必须忽略。
AT: A 4-bit algorithm type field describing the algorithm used by FMIPv6 to calculate the authenticator. See [FMIP] for details.
AT：一个4位算法类型字段，描述FMIPv6用于计算验证器的算法。有关详细信息，请参见[FMIP]。
Resrvd.: A 4-bit field reserved for future use. The value MUST be initialized to zero by the sender and MUST be ignored by the receiver.
Resrvd：保留供将来使用的4位字段。发送方必须将该值初始化为零，接收方必须忽略该值。
Key Lifetime: Lifetime of the handover key, HK-LIFETIME, in seconds.
密钥生存期：切换密钥的生存期，HK-LIFETY，以秒为单位。
Encrypted Handover Key: The shared handover key, encrypted with the MN's handover key encryption public key, using the RSAES-PKCS1-v1_5 format [RFC3447].
加密切换密钥：共享切换密钥，使用MN的切换密钥加密公钥加密，使用RSAES-PKCS1-v1_5格式[RFC3447]。
Padding: A variable-length field making the option length a multiple of 8, containing as many octets as specified in the Pad Length field.
Padding：一个可变长度字段，使选项长度为8的倍数，包含Pad length字段中指定的八位字节数。
This document describes a shared key provisioning protocol for the FMIPv6 handover optimization protocol. The key provisioning protocol utilizes a public key generated with the same public key algorithm as SEND to bootstrap a shared key for authorizing changes due to handover associated with the MN's former address on the PAR. General security considerations involving CGAs apply to the protocol described in this document, see [CGA] for a discussion of security considerations around CGAs. This protocol is subject to the same risks from replay attacks and denial-of-service (DoS) attacks using the RtSolPr as the SEND protocol [SEND] for RS. The measures recommended in RFC 3971 for mitigating replay attacks and DoS attacks apply here as well. An additional consideration involves when to generate the handover key on the AR. To avoid state depletion attacks, the handover key SHOULD NOT be generated prior to SEND processing that verifies the originator of RtSolPr. State depletion attacks can be addressed by techniques, such as rate limiting RtSolPr, restricting the amount of state reserved for unresolved solicitations, and clever cache management. These techniques are the same as used in implementing Neighbor Discovery.
本文档描述了FMIPv6切换优化协议的共享密钥供应协议。密钥提供协议利用同一公钥算法生成的公钥作为发送来引导共享密钥，用于授权由于与MN的前地址相关联的切换而导致的更改。涉及CGA的一般安全注意事项适用于本文档中描述的协议，有关CGA的安全注意事项的讨论，请参见[CGA]。使用RtSolPr作为RS的发送协议[SEND]时，该协议会受到重播攻击和拒绝服务（DoS）攻击的相同风险。RFC 3971中建议的缓解重播攻击和DoS攻击的措施也适用于此。另一个考虑因素涉及何时在AR上生成切换密钥。为避免状态耗尽攻击，在验证RtSolPr发起者的发送处理之前，不应生成切换密钥。状态耗尽攻击可以通过诸如速率限制RtSolPr、限制为未解决请求保留的状态量以及智能缓存管理等技术来解决。这些技术与用于实现邻居发现的技术相同。
For other FMIPv6 security considerations, please see the FMIPv6 document [FMIP].
有关其他FMIPv6安全注意事项，请参阅FMIPv6文档[FMIP]。
IANA has assigned IPv6 Neighbor Discovery option type codes for the two new IPv6 Neighbor Discovery options, the Handover Key Request Option (27) and Handover Key Reply Option (28), defined in this document.
IANA已为本文档中定义的两个新IPv6邻居发现选项（切换密钥请求选项（27）和切换密钥应答选项（28））分配了IPv6邻居发现选项类型代码。
[FMIP] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5268, June 2008.
[FMIP]Koodli，R.，Ed.“移动IPv6快速切换”，RFC 5268，2008年6月。
[SEND] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[发送]Arkko，J.，Ed.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（发送）”，RFC 39712005年3月。
[CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[CGA]Aura，T.，“加密生成地址（CGA）”，RFC 39722005年3月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3447]Jonsson，J.和B.Kaliski，“公钥密码标准（PKCS）#1:RSA密码规范版本2.1”，RFC 3447，2003年2月。
[RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[RFC3756]Nikander，P.，Ed.，Kempf，J.，和E.Nordmark，“IPv6邻居发现（ND）信任模型和威胁”，RFC 3756，2004年5月。
[PBK] Bradner, S., Mankin, A., and Schiller, J., "A Framework for Purpose-Built Keys (PBK)", Work in Progress, June 2003. Progress.
[PBK]Bradner，S.，Mankin，A.，和Schiller，J.，“专用键框架（PBK）”，正在进行的工作，2003年6月。进步
Authors' Addresses
作者地址
James Kempf DoCoMo Labs USA 3240 Hillview Avenue Palo Alto, CA 94303 USA
詹姆斯·肯普夫·多科莫实验室美国加利福尼亚州帕洛阿尔托山景大道3240号，邮编94303
Phone: +1 650 496 4711
EMail: kempf@docomolabs-usa.com
Phone: +1 650 496 4711
EMail: kempf@docomolabs-usa.com
Rajeev Koodli Starent Networks 30 International Place Tewksbury, MA 01876 USA
美国马萨诸塞州托克斯伯里国际广场30号Rajeev Koodli Starent Networks 01876
Phone: +1 408 735 7679
EMail: rkoodli@starentnetworks.com
Phone: +1 408 735 7679
EMail: rkoodli@starentnetworks.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.