Network Working Group C. Perkins
Request for Comments: 4449 Nokia Research Center
Category: Standards Track June 2006
Network Working Group C. Perkins
Request for Comments: 4449 Nokia Research Center
Category: Standards Track June 2006
Securing Mobile IPv6 Route Optimization Using a Static Shared Key
使用静态共享密钥保护移动IPv6路由优化
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）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
A mobile node and a correspondent node may preconfigure data useful for precomputing a Binding Management Key that can subsequently be used for authorizing Binding Updates.
移动节点和对应节点可以预配置用于预计算绑定管理密钥的数据，该绑定管理密钥随后可用于授权绑定更新。
Table of Contents
目录
1. Introduction ....................................................1
2. Applicability Statement .........................................2
3. Precomputing a Binding Management Key (Kbm) .....................3
4. Security Considerations .........................................4
5. Acknowledgement .................................................5
6. References ......................................................5
6.1. Normative References .......................................5
6.2. Informative References .....................................6
1. Introduction ....................................................1
2. Applicability Statement .........................................2
3. Precomputing a Binding Management Key (Kbm) .....................3
4. Security Considerations .........................................4
5. Acknowledgement .................................................5
6. References ......................................................5
6.1. Normative References .......................................5
6.2. Informative References .....................................6
This specification introduces an alternative, low-latency security mechanism for protecting signaling related to the route optimization in Mobile IPv6. The default mechanism specified in [1] uses a periodic return routability test to verify both the "right" of the mobile node to use a specific home address, as well as the validity of the claimed care-of address. That mechanism requires no configuration and no trusted entities beyond the mobile node's home agent.
本规范介绍了一种替代的低延迟安全机制，用于保护与移动IPv6路由优化相关的信令。[1]中指定的默认机制使用定期返回可路由性测试来验证移动节点使用特定归属地址的“权利”以及所声称的转交地址的有效性。该机制不需要配置，也不需要移动节点的归属代理之外的可信实体。
The mechanism specified in this document, however, requires the configuration of a shared secret between mobile node and its correspondent node. As a result, messages relating to the routability tests can be omitted, leading to significantly smaller latency. In addition, the right to use a specific home address is ensured in a stronger manner than in [1]. On the other hand, the applicability of this mechanisms is limited due to the need for preconfiguration. This mechanism is also limited to use only in scenarios where mobile nodes can be trusted not to misbehave, as the validity of the claimed care-of addresses is not verified.
然而，本文档中指定的机制需要在移动节点及其对应节点之间配置共享密钥。因此，可以省略与路由性测试相关的消息，从而大大缩短延迟。此外，使用特定家庭地址的权利得到了比[1]更有力的保障。另一方面，由于需要预配置，这种机制的适用性受到限制。该机制也仅限于在可信任移动节点不会出现不当行为的情况下使用，因为未验证所声明的转交地址的有效性。
The keywords "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 [2]. Other terminology is used as already defined in [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[2]中所述进行解释。其他术语已在[1]中定义。
This mechanism is useful in scenarios where the following conditions are all met:
此机制在满足以下条件的情况下非常有用：
- Mobile node and correspondent node are administered within the same domain.
- 移动节点和对应节点在同一域中管理。
- The correspondent node has good reason to trust the actions of the mobile node. In particular, the correspondent node needs to be certain that the mobile node will not launch flooding attacks against a third party as described in [5].
- 通信节点有充分的理由信任移动节点的操作。具体而言，对应节点需要确保移动节点不会像[5]中所述那样对第三方发起泛洪攻击。
- The configuration effort related to this mechanism is acceptable. Users MUST be able to generate/select a sufficiently good value for Kcn (see [3])
- 与此机制相关的配置工作是可以接受的。用户必须能够为Kcn生成/选择足够好的值（参见[3]）
- There is a desire to take advantage of higher efficiency or greater assurance with regards to the correctness of the home address offered via this mechanism.
- 人们希望在通过该机制提供的家庭地址的正确性方面利用更高的效率或更大的保证。
- This mechanism is used only for authenticating Binding Update messages (and not, e.g., data), so the total volume of traffic is low (see RFC 4107 [4], and the discussion in section 4).
- 此机制仅用于验证绑定更新消息（而不是数据），因此总通信量较低（请参阅RFC 4107[4]，以及第4节中的讨论）。
This mechanism can also be useful in software development, testing, and diagnostics related to mobility signaling.
该机制也可用于与移动性信令相关的软件开发、测试和诊断。
Generally speaking, the required level of trust that the correspondent node needs for enabling a precomputable Kbm with a mobile node is more often found within relatively small, closed groups of users who are personally familiar with each other, or who
一般来说，对应节点为使用移动节点启用可预计算Kbm而需要的所需信任级别通常在相对较小的、封闭的用户组中找到，这些用户组个人熟悉彼此，或者
have some external basis for establishing trustworthy interactions. A typical example scenario where this mechanism is applicable is within a corporation, or between specific users. Application in the general Internet is typically not possible due to the effort that is required to manually configure the correspondent nodes. Application at a public network operator is typically not possible due to requirements placed on the trustworthiness of mobile nodes.
有一些外部基础来建立可信的交互。该机制适用于公司内部或特定用户之间的典型示例场景。由于需要手动配置相应的节点，因此通常无法在通用Internet中应用程序。由于对移动节点的可信性的要求，公共网络运营商的应用通常是不可能的。
A mobile node and a correspondent node may preconfigure data useful for creating a Binding Management Key (Kbm), which can then be used for authorizing binding management messages, especially Binding Update and Binding Acknowledgement messages. This data is as follows:
移动节点和对应节点可预配置用于创建绑定管理密钥（Kbm）的数据，该密钥随后可用于授权绑定管理消息，尤其是绑定更新和绑定确认消息。这些数据如下：
- A shared key (Kcn) used to generate keygen tokens, at least 20 octets long
- 一种共享密钥（Kcn），用于生成密钥生成令牌，长度至少为20个八位字节
- A nonce for use when generating the care-of keygen token
- 生成转交密钥生成令牌时使用的一个nonce
- A nonce for use when generating the home keygen token
- 生成home keygen令牌时使用的nonce
The keygen tokens MUST be generated from Kcn and the nonces as specified in Mobile IPv6 [1] return routability. Likewise, the binding management key Kbm must subsequently be generated from the keygen tokens in the same way as specified in Mobile IPv6 [1]. The preconfigured data is associated to the mobile node's home address. Kcn MUST be generated with sufficient randomness (see RFC 4086 [3]).
keygen令牌必须由Kcn生成，并且必须按照移动IPv6[1]中的规定返回可路由性。同样，绑定管理密钥Kbm随后必须以移动IPv6[1]中指定的相同方式从keygen令牌生成。预配置的数据与移动节点的家庭地址相关联。必须以足够的随机性生成Kcn（参见RFC 4086[3]）。
Replay protection for Binding Update messages using Kbm computed from the preconfigured data depends upon the value of the Sequence Number field in the Binding Update. If the correspondent node does not maintain information about the recently used values of that field, then there may be an opportunity for a malicious node to replay old Binding Update messages and fool the correspondent node into routing toward an old care-of address. For this reason, a correspondent node that uses a precomputable Kbm also MUST keep track of the most recent value of the Sequence Number field of Binding Update messages using the precomputable Kbm value (for example, by committing it to stable storage).
使用根据预配置数据计算的Kbm对绑定更新消息进行重播保护取决于绑定更新中的序号字段的值。如果对应节点不维护关于该字段最近使用的值的信息，则恶意节点可能有机会重播旧绑定更新消息，并欺骗对应节点向旧转交地址路由。因此，使用可预计算Kbm的对应节点还必须使用可预计算Kbm值跟踪绑定更新消息的序列号字段的最新值（例如，通过将其提交到稳定存储）。
When a Binding Update is to be authenticated using such a precomputable binding key (Kbm), the Binding Authorization Data suboption MUST be present. The Nonce Indices option SHOULD NOT be present. If it is present, the nonce indices supplied SHOULD be ignored and are not included as part of the calculation for the authentication data, which is to be performed exactly as specified in [1].
当要使用这种预计算绑定密钥（Kbm）对绑定更新进行身份验证时，必须存在绑定授权数据子选项。“当前索引”选项不应存在。如果存在，则应忽略提供的nonce索引，并且不将其作为验证数据计算的一部分，验证数据将完全按照[1]中的规定执行。
A correspondent node and a mobile node may use a precomputable binding management key (Kbm) to manage the authentication requirements for binding cache management messages. Such keys must be handled carefully to avoid inadvertent exposure to the threats outlined in [5]. Many requirements listed in this document are intended to ensure the safety of the manual configuration. In particular, Kcn MUST be generated with sufficient randomness (see RFC 4086 [3]), as noted in Section 3.
对应节点和移动节点可以使用可预计算的绑定管理密钥（Kbm）来管理绑定缓存管理消息的认证需求。必须小心处理此类钥匙，以避免无意中暴露于[5]中概述的威胁。本文件中列出的许多要求旨在确保手动配置的安全性。特别是，如第3节所述，必须以足够的随机性生成Kcn（见RFC 4086[3]）。
Manually configured keys MUST be used in conformance with RFC 4107 [4]. Used according to the applicability statement, and with the other security measures mandated in this specification, the keys will satisfy the properties in that document. In order to ensure protection against dictionary attacks, the configured security information is intended to be used ONLY for authenticating Binding Update messages.
必须按照RFC 4107[4]使用手动配置的密钥。根据适用性声明和本规范规定的其他安全措施使用，密钥将满足该文档中的属性。为了确保防止字典攻击，配置的安全信息仅用于验证绑定更新消息。
A mobile node MUST use a different value for Kcn for each node in its Binding Update List, and a correspondent node MUST ensure that every mobile node uses a different value of Kcn. This ensures that the sender of a Binding Update can always be uniquely determined. This is necessary, as this authorization method does not provide any guarantee that the given care-of address is legitimate. For the same reason, this method SHOULD only be applied between nodes that are under the same administration. The return routability procedure is RECOMMENDED for all general use and MUST be the default, unless the user explicitly overrides this by entering the aforementioned preconfigured data for a particular peer.
移动节点必须为其绑定更新列表中的每个节点使用不同的Kcn值，对应节点必须确保每个移动节点使用不同的Kcn值。这确保绑定更新的发送方始终可以唯一确定。这是必要的，因为这种授权方法不能保证给定的转交地址是合法的。出于同样的原因，此方法只应应用于处于相同管理下的节点之间。返回可路由性过程建议用于所有一般用途，并且必须是默认过程，除非用户通过输入特定对等方的上述预配置数据来明确覆盖此过程。
Replay protection for the Binding Authorization Data option authentication mechanism is provided by the Sequence Number field of the Binding Update. This method of providing replay protection fails when the Binding Update sequence numbers cycle through the 16 bit counter (i.e., not more than 65,536 distinct uses of Kbm), or if the sequence numbers are not protected against reboots. If the mobile node were to send a fresh Binding Update to its correspondent node every hour, 24 hours a day, every day of the year, this would require changing keys every 7 years. Even if the mobile node were to do so
绑定授权数据选项身份验证机制的重播保护由绑定更新的序列号字段提供。当绑定更新序列号在16位计数器中循环时（即，不超过65536次不同的Kbm使用），或者如果序列号没有防止重新启动，则提供重播保护的这种方法将失败。如果移动节点要每小时、每天24小时、一年中的每一天向其对应节点发送一个新的绑定更新，这将需要每7年更换一次密钥。即使移动节点要这样做
every minute, this would provide protection for over a month. Given typical mobility patterns, there is little danger of replay problems; nodes for which problems might arise are expected to use methods other than manual configuration for Kcn and the associated nonces. When the Sequence Number field rolls over, the parties SHOULD configure a new value for Kcn, so that new Kbm values will be computed.
每分钟，这将提供超过一个月的保护。考虑到典型的移动模式，回放问题的危险性很小；可能出现问题的节点应使用手动配置Kcn和相关nonce以外的方法。当序列号字段滚动时，各方应为Kcn配置一个新值，以便计算新的Kbm值。
If a correspondent node does NOT keep track of the sequence number for Binding Update messages from a particular mobile node, then the correspondent node could be fooled into accepting an old value for the mobile node's care-of address. In the unlikely event that this address was reallocated to another IPv6 node in the meantime, that IPv6 node would then be vulnerable to unwanted traffic emanating from the correspondent node.
如果对应节点不跟踪用于绑定来自特定移动节点的更新消息的序列号，则对应节点可能会被愚弄而接受移动节点的转交地址的旧值。在不太可能的情况下，此地址同时被重新分配到另一个IPv6节点，该IPv6节点将容易受到来自对应节点的不必要流量的攻击。
Note that where a node has been configured to use the mechanism specified in this document with a particular peer, it SHOULD NOT attempt to use another mechanism, even if the peer requests this or claims not to support the mechanism in this document. This is necessary in order to prevent bidding down attacks.
请注意，如果节点已配置为对特定对等方使用本文档中指定的机制，则不应尝试使用其他机制，即使对等方请求此机制或声称不支持本文档中的机制。这是必要的，以防止出价下降的攻击。
There is no upper bound on the lifetime defined for the precomputable Kbm. As noted, the key is very likely to be quite secure over the lifetime of the security association and usefulness of applications between a mobile node and correspondent node that fit the terms specified in section 2.
为可预计算Kbm定义的生存期没有上限。如前所述，密钥很可能在符合第2节中规定的条款的移动节点和对应节点之间的安全关联和应用程序有用性的生命周期内是非常安全的。
Thanks are due to everyone who reviewed the discussion of issue #146. Thanks to Jari Arkko for supplying text for the Introduction.
感谢所有回顾了146号议题讨论的人。感谢Jari Arkko为介绍提供文本。
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[1] Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[3] Eastlake，D.，3rd，Schiller，J.和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[4] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[4] Bellovin，S.和R.Housley，“加密密钥管理指南”，BCP 107，RFC 4107，2005年6月。
[5] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, "Mobile IP Version 6 Route Optimization Security Design Background", RFC 4226, December 2005.
[5] Nikander，P.，Arkko，J.，Aura，T.，黑山，G.，和E.Nordmark，“移动IP版本6路由优化安全设计背景”，RFC 42262005年12月。
Author's Address
作者地址
Charles E. Perkins Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 USA
查尔斯·E·珀金斯诺基亚研究中心313飞兆半导体山景大道，加利福尼亚州94043
Phone: +1 650 625-2986
Fax: +1 650 625-2502
EMail: charles.perkins@nokia.com
Phone: +1 650 625-2986
Fax: +1 650 625-2502
EMail: charles.perkins@nokia.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。