Network Working Group J. Luciani
Request for Comments: 2520 Nortel Networks
Category: Experimental H. Suzuki
Cisco Systems
N. Doraswamy
Nortel Networks
D. Horton
CiTR Pty Ltd
February 1999
Network Working Group J. Luciani
Request for Comments: 2520 Nortel Networks
Category: Experimental H. Suzuki
Cisco Systems
N. Doraswamy
Nortel Networks
D. Horton
CiTR Pty Ltd
February 1999
NHRP with Mobile NHCs
带有移动NHC的NHRP
Status of this Memo
本备忘录的状况
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
This document describes an extension to NHRP [1] which would allow Mobile NHCs to perform a registration with and attach to an NHS in their home LIS in an authenticated manner.
本文件描述了NHRP[1]的一个扩展，该扩展允许移动NHC以认证方式在其家庭LIS中向NHS进行注册并连接到NHS。
As described in this document, Mobile NHCs are NHCs which are not configured with enough information to find a specific serving NHS in their home LIS, but which have a mechanism to find an NHS (which may or may not be a serving NHS) to which they will attach. As described in [1], an NHC may attach to a 'surrogate' NHS by using a mechanism such as an anycast address. In this case, the NHC may use the surrogate NHS to send a NHRP Registration Request toward the NHC's home LIS where a serving NHS resides. However, as defined in [1], packet authentication is performed on a hop by hop basis. In the mobile NHC case, it is not practical for the mobile NHC be in a security relationship with every surrogate NHS, thus it is presumably desirable to have some form of end to end only authentication for the case of a mobile NHC's registration. This document describes an authentication extension for NHRP which has such end to end only semantics.
如本文件所述，移动NHC是未配置足够信息以在其家庭LIS中查找特定服务NHS的NHC，但其具有查找其将连接的NHS（可能是或可能不是服务NHS）的机制。如[1]所述，NHC可通过使用选播地址等机制连接到“代理”NHS。在这种情况下，NHC可以使用代理NHS向NHC的家庭LIS发送NHRP注册请求，其中服务NHS居住。然而，如[1]中所定义，分组认证是在逐跳的基础上执行的。在移动NHC的情况下，移动NHC与每个代理NHS处于安全关系中是不实际的，因此，对于移动NHC的注册情况，可能希望具有某种形式的仅端到端认证。本文档描述了NHRP的身份验证扩展，它具有这样的端到端语义。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [4].
本文件中出现的关键词必须、不得、必需、应、不应、应、不应、建议、可能和可选时，应按照[4]中的说明进行解释。
This document describes an extension for Mobile NHCs to use when they wish to register with their home LIS but initially connect to a non-serving NHS to do so. The reader is encouraged to read [1] for more details on the NHRP registration process.
本文档描述了当移动NHC希望在其家庭LIS中注册，但最初连接到非服务NHS时使用的扩展。鼓励读者阅读[1]，了解NHRP注册过程的更多详情。
Compulsory = 1 Type = 10 (proposed) Length = variable
强制=1类型=10（建议）长度=变量
The NHRP Mobile NHC Authentication Extension is carried in NHRP Registration packets to convey end to end authentication Information. This extension is defined in contrast to the NHRP Authentication Extension defined in [1] which has hop by hop semantics.
NHRP移动NHC认证扩展被携带在NHRP注册分组中以传送端到端认证信息。此扩展的定义与[1]中定义的NHRP身份验证扩展不同，后者具有逐跳语义。
This new extension is used when a mobile NHC initially connects to an NHS which is not one of its serving NHSs and the mobile NHC and nonserving NHS are not in a security relationship. The mobile NHC does this in order to send an NHRP Registration Request, via normal routing and forwarding processes, to one of its serving NHSs with which it does have a security relationship. As defined in [1], a serving NHS is an NHS in the NHC's home LIS with which the NHC will register. Upon receiving such an NHRP Registration Request, the serving NHS will do the following: authenticate the sender NHC, set up a VC to the NHC, and then send an NHRP Resolution Reply in response on that new VC.
当移动NHC最初连接到不是其服务NHS之一的NHS，并且移动NHC和非服务NHS不处于安全关系时，使用此新扩展。移动NHC这样做是为了通过正常路由和转发过程将NHRP注册请求发送到其与之具有安全关系的服务nhs之一。如[1]所定义，服务NHS是NHC家庭LIS中的NHS，NHC将向其注册。在收到此类NHRP注册请求后，服务NHS将执行以下操作：验证发送方NHC，向NHC设置VC，然后在新VC上发送NHRP解决回复。
Note that, as defined in [1], a transit NHS (such as the one to which the mobile NHC initially connects) must ignore an extension which it does not understand and that an NHS must not change the order of extensions in an NHRP packet. Thus, the end to end semantics of this extension are preserved without causing changes to existing implementations.
注意，如[1]中所定义，中转NHS（如移动NHC最初连接的那个）必须忽略它不理解的扩展，并且NHS不得改变NHRP数据包中扩展的顺序。因此，在不改变现有实现的情况下，保留了该扩展的端到端语义。
If a serving NHS receives a packet which fails the hop by hop authentication test defined in [1] then the NHS MUST generate an Error Indication of type 'Authentication Failure' and discard the packet. However in the case where the NHRP Mobile NHC Authentication Extension is used as described above, sending an Error Indication is not possible since no route exists back toward the mobile NHC assuming a VC does not already exist between the mobile NHC and the
如果服务NHS接收到的数据包未通过[1]中定义的逐跳验证测试，则NHS必须生成“验证失败”类型的错误指示，并丢弃该数据包。然而，在如上所述使用NHRP移动NHC认证扩展的情况下，不可能发送错误指示，因为假设移动NHC和移动NHC之间不存在VC，则不存在返回移动NHC的路由
serving NHS which received the NHRP Registration Request. In this case, the NHRP Registration Request is merely dropped.
服务于接收到NHRP注册请求的NHS。在这种情况下，仅丢弃NHRP注册请求。
The authentication header has the following format:
身份验证标头具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Security Parameter Index (SPI)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Addr... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Security Parameter Index (SPI)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Addr... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Security Parameter Index (SPI) can be thought of as an index into a table that maintains the keys and other information such as a hash algorithm. Src and Dst communicate either offline using manual keying or online using a key management protocol to populate this table. The sending NHRP entity always allocates the SPI and the parameters associated with it.
安全参数索引（SPI）可以看作是一个表的索引，该表维护键和其他信息，如哈希算法。Src和Dst使用手动键控进行离线通信，或使用密钥管理协议进行在线通信以填充此表。发送NHRP实体始终分配SPI及其相关参数。
The Src Addr field is a variable length field which contains the address assigned to the outgoing interface. The length of the field is obtained from the source protocol length field in the mandatory part of the NHRP header. The tuple <spi, src addr> uniquely identifies the key and the other parameters that are used in authentication.
Src Addr字段是一个可变长度字段，其中包含分配给传出接口的地址。该字段的长度从NHRP头的必填部分的源协议长度字段中获取。元组<spi，src addr>唯一地标识用于身份验证的密钥和其他参数。
The length of the authentication data field is dependent on the hash algorithm used. The Authentication Data field contains the keyed hash calculated over the following fields: fixed part (with hop count, packet size and checksum being treated as if set to zero), mandatory part, and extensions up to and including the Mobile NHC Authentication extension.
身份验证数据字段的长度取决于所使用的哈希算法。身份验证数据字段包含通过以下字段计算的密钥散列：固定部分（跳数、数据包大小和校验和被视为设置为零）、强制部分以及移动NHC身份验证扩展（包括）之前的扩展。
Note that [1] defines an explicit ordering of extensions such that:
请注意，[1]定义了扩展的显式顺序，以便：
(a) If the Responder Address extension exists then it must appear before the Authentication Extension.
(a) 如果响应者地址扩展存在，则它必须出现在身份验证扩展之前。
(b) Any extensions that may be modified in transit (e.g., Forward Transit Extension, Hop by Hop Authentication Extension) must appear after the Mobile NHC Authentication Extension.
(b) 任何可能在传输中修改的扩展（例如，前向传输扩展、逐跳认证扩展）必须出现在移动NHC认证扩展之后。
SPI's can be negotiated either manually or using an Internet Key Management protocol. Manual keying MUST be supported. The following parameters are associated with the tuple <SPI, src>- lifetime, Algorithm, Key. Lifetime indicates the duration in seconds for which the key is valid. In case of manual keying, this duration can be infinite. Also, in order to better support manual keying, there may be multiple tuples active at the same time (Dst being the same).
SPI可以手动协商，也可以使用Internet密钥管理协议协商。必须支持手动键控。以下参数与元组<SPI，src>-生存期、算法、密钥相关。生存期表示密钥有效的持续时间（秒）。在手动键控的情况下，此持续时间可以是无限的。此外，为了更好地支持手动键控，可能同时有多个元组处于活动状态（Dst相同）。
Algorithm specifies the hash algorithm agreed upon by the two entities. HMAC-MD5-128 [2] is the default algorithm and MUST be implemented. Other algorithms MAY be supported by defining new values. IANA will assign the numbers to identify the algorithm being used as described in [1].
算法指定两个实体商定的哈希算法。HMAC-MD5-128[2]是默认算法，必须实现。通过定义新值，可以支持其他算法。IANA将按照[1]中所述分配数字，以识别正在使用的算法。
Any Internet standard key management protocol MAY so be used to negotiate the SPI and parameters.
因此，可以使用任何因特网标准密钥管理协议来协商SPI和参数。
Unauthenticated 'Mobile' Registration Request processing proceeds as follows [1]:
未经验证的“移动”注册请求处理过程如下[1]：
- the NHC inserts the internetwork address of a serving NHS in the 'Destination Protocol Address' field; If the NHS address is unknown, then the NHC inserts its own internetwork address. A ' responder address' extension is optionally added. - the non-serving NHS forwards the packet along the routed path based on the contents of the 'Destination Protocol Address' field. - the serving NHS which receives the NHRP Registration Request will set up a direct VCC to NHC after authenticating the request - the serving NHS will then send the NHRP Registration Reply back to the NHC on that new VCC. Note that the NHS MUST wait some configured interval before doing this reply in order to prevent a race condition from occurring between the VC setup and sending the NHRP reply packet. - the NHC will subsequently send all NHRP traffic to the serving NHS on the direct VCC.
- NHC在“目的地协议地址”字段中插入服务NHS的互联网地址；如果NHS地址未知，则NHC插入其自己的互联网地址。可选添加“响应者地址”扩展名。-非服务NHS根据“目的地协议地址”字段的内容沿路由路径转发数据包。-接收NHRP注册请求的服务NHS将在验证该请求后建立一个直接向NHC发送的VCC-服务NHS然后将NHRP注册回复发送回该新VCC上的NHC。请注意，NHS在执行此回复之前必须等待一些配置的时间间隔，以防止VC设置和发送NHRP回复数据包之间发生竞争情况。-NHC随后将通过直接VCC向服务NHS发送所有NHRP流量。
When the NHC adds the authentication extension header, it performs a table look up in order to fetch the SPI and the security parameters based on the outgoing interface address. If there are no entries in the table and if there is support for key management, the NHC initiates the key management protocol to fetch the necessary parameters. The NHC constructs the Authentication Extension payload and calculates the hash by zeroing out the authentication data field. The result is placed in the authentication data field. The src address field in the payload is the internetwork address assigned to the outgoing interface.
当NHC添加认证扩展头时，它会执行一个表查找，以便根据传出接口地址获取SPI和安全参数。如果表中没有条目并且支持密钥管理，NHC将启动密钥管理协议以获取必要的参数。NHC构造身份验证扩展负载，并通过将身份验证数据字段置零来计算哈希值。结果将放置在“身份验证数据”字段中。有效负载中的src地址字段是分配给传出接口的网络间地址。
If key management is not supported and authentication is mandatory, the packet is dropped and this information is logged.
如果不支持密钥管理且必须进行身份验证，则会丢弃数据包并记录此信息。
On the receiving end, the serving NHS fetches the parameters based on the SPI and the internetwork address in the authentication extension payload. The authentication data field is extracted before being zeroed out in order to calculate the hash. It computes the hash on the entire payload and if the hash does not match, then an "abnormal event" has occurred.
在接收端，服务NHS根据SPI和认证扩展负载中的网络地址获取参数。身份验证数据字段在清零之前被提取，以便计算哈希值。它计算整个有效负载上的哈希，如果哈希不匹配，则发生“异常事件”。
The keys used by the mobile NHC for communicating with the serving NHS in NHRP Registration Requests can be used in subsequent resolution and purge requests made directly to the serving NHS after receiving the NHRP Registration Reply. However, the authentication extension defined in [1] MUST be used when these keys are applied to resolution and purge packets.
移动NHC在NHRP注册请求中用于与服务NHS通信的密钥可用于接收NHRP注册回复后直接向服务NHS发出的后续解析和清除请求。但是，当这些密钥应用于解析和清除数据包时，必须使用[1]中定义的身份验证扩展。
Hop by Hop Authentication[1] and End to End authentication MAY be used in combination to provide protection against both spoofing and denial of service attacks. If only an end-to-end Mobile NHC Authentication Extension is present, it MAY be the policy of each transit NHS to reject the NHRP Registration Request based on the requirement for having a Hop by Hop authentication present. Such a requirement is a local matter.
逐跳身份验证[1]和端到端身份验证可结合使用，以提供针对欺骗和拒绝服务攻击的保护。如果仅存在端到端移动NHC认证扩展，则每个中转NHS的策略可能是基于存在逐跳认证的要求拒绝NHRP注册请求。这种要求是地方性的。
It is important that the keys chosen are strong since the security of the entire system depends on the keys being chosen properly.
由于整个系统的安全性取决于正确选择的密钥，因此选择的密钥必须牢固，这一点很重要。
End-to-end authentication counters spoofing attacks on the home subnet through not relying on the potentially compromised chain of trust. The use of end-end authentication is further described in [3].
端到端身份验证通过不依赖可能受到危害的信任链来阻止对主子网的欺骗攻击。[3]中进一步描述了端认证的使用。
Hop-by-hop authentication prevents denial of service attacks by introducing access control at the first point of contact to the NHRP infrastructure.
逐跳身份验证通过在NHRP基础设施的第一个接触点引入访问控制来防止拒绝服务攻击。
The security of this extension is performed on an end to end basis. The data received can be trusted only so much as one trusts the end point entities in the path traversed. A chain of trust is established amongst NHRP entities in the path of the NHRP Message. If the security in an NHRP entity is compromised, then security in the entire NHRP domain is compromised.
此扩展的安全性是在端到端的基础上执行的。接收到的数据可以被信任的程度仅与人们信任所穿越路径中的端点实体的程度相同。在NHRP消息路径中的NHRP实体之间建立信任链。如果NHRP实体中的安全性受损，则整个NHRP域中的安全性受损。
Data integrity covers the entire NHRP payload up to and including the Mobile NHC Authentication Extension. This guarantees that the data and extensions covered by this authentication hash were not modified and that the source is authenticated as well. If the authentication extension is not used or if the security is compromised, then NHRP entities are liable to both spoofing attacks, active attacks, and passive attacks.
数据完整性涵盖整个NHRP有效载荷，包括移动NHC认证扩展。这保证了此身份验证哈希所涵盖的数据和扩展未被修改，并且源也经过身份验证。如果未使用身份验证扩展或安全性受损，则NHRP实体容易受到欺骗攻击、主动攻击和被动攻击。
There is no mechanism to encrypt the messages. It is assumed that a standard layer 3 confidentiality mechanism will be used to encrypt and decrypt messages. It is recommended to use an Internet standard key management protocol to negotiate the keys between the neighbors. Transmitting the keys in clear text, if other methods of negotiation is used, compromises the security completely.
没有加密消息的机制。假定将使用标准的第3层保密机制对消息进行加密和解密。建议使用Internet标准密钥管理协议在邻居之间协商密钥。如果使用其他协商方法，以明文形式传输密钥将完全危及安全性。
References
工具书类
[1] Luciani, J., Katz, D., Piscitello, D., Cole, B. and N. Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.
[1] Luciani，J.，Katz，D.，Piscitello，D.，Cole，B.和N.Doraswamy，“NBMA下一跳解析协议（NHRP）”，RFC 2332，1998年4月。
[2] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed Hashing for Message Authentication", RFC 2104, February 1997.
[2] Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息身份验证的键控哈希”，RFC2104，1997年2月。
[3] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[3] Perkins，C.，“IP移动支持”，RFC 2002，1996年10月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
Authors' Addresses
作者地址
James V. Luciani Nortel Networks 3 Federal Street Mail Stop: BL3-03 Billerica, MA 01821
James V.Luciani Nortel Networks 3联邦街道邮件站：BL3-03马萨诸塞州比尔里卡01821
Phone: +1 978 916 4734
EMail: luciani@baynetworks.com
Phone: +1 978 916 4734
EMail: luciani@baynetworks.com
Hiroshi Suzuki Cisco Systems 170 West Tasman Dr. San Jose, CA 96134
Hiroshi Suzuki Cisco Systems 170西塔斯曼加利福尼亚州圣何塞博士96134
Phone: +1 408 525 6006
EMail: hsuzuki@cisco.com
Phone: +1 408 525 6006
EMail: hsuzuki@cisco.com
Naganand Doraswamy Nortel Networks 3 Federal Street Mail Stop: BL3-03 Billerica, MA 01821
Naganand Doraswamy Nortel Networks 3联邦街道邮件站：BL3-03马萨诸塞州比尔里卡01821
Phone: +1 978 916 4734
EMail: naganand@baynetworks.com
Phone: +1 978 916 4734
EMail: naganand@baynetworks.com
David Horton CiTR PTY Ltd Level 2 North Tower 339 Coronation Drive Milton, Australia 4064
澳大利亚米尔顿加冕大道339号北塔2层David Horton CiTR私人有限公司4064
Phone: +61 7 32592222
EMail: d.horton@citr.com.au
Phone: +61 7 32592222
EMail: d.horton@citr.com.au
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。