Internet Engineering Task Force (IETF) U. Herberg
Request for Comments: 7183 Fujitsu Laboratories of America
Updates: 6130, 7181 C. Dearlove
Category: Standards Track BAE Systems ATC
ISSN: 2070-1721 T. Clausen
LIX, Ecole Polytechnique
April 2014
Internet Engineering Task Force (IETF) U. Herberg
Request for Comments: 7183 Fujitsu Laboratories of America
Updates: 6130, 7181 C. Dearlove
Category: Standards Track BAE Systems ATC
ISSN: 2070-1721 T. Clausen
LIX, Ecole Polytechnique
April 2014
Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)
邻域发现协议（NHDP）和优化链路状态路由协议版本2（OLSRv2）的完整性保护
Abstract
摘要
This document specifies integrity and replay protection for the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) and the Optimized Link State Routing Protocol version 2 (OLSRv2). This protection is achieved by using an HMAC-SHA-256 Integrity Check Value (ICV) TLV and a Timestamp TLV based on Portable Operating System Interface (POSIX) time.
本文档规定了移动自组网（MANET）邻居发现协议（NHDP）和优化链路状态路由协议版本2（OLSRv2）的完整性和重播保护。该保护通过使用HMAC-SHA-256完整性检查值（ICV）TLV和基于便携式操作系统接口（POSIX）时间的时间戳TLV来实现。
The mechanism in this specification can also be used for other protocols that use the generalized packet/message format described in RFC 5444.
本规范中的机制也可用于使用RFC 5444中描述的通用分组/消息格式的其他协议。
This document updates RFC 6130 and RFC 7181 by mandating the implementation of this integrity and replay protection in NHDP and OLSRv2.
本文件更新了RFC 6130和RFC 7181，规定在NHDP和OLSRv2中实施完整性和重放保护。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7183.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7183.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Applicability Statement .........................................5
4. Protocol Overview and Functioning ...............................6
5. Parameters ......................................................7
6. Message Generation and Processing ...............................9
6.1. Message Content ............................................9
6.2. Message Generation ........................................10
6.3. Message Processing ........................................11
6.3.1. Validating a Message Based on Timestamp ............11
6.3.2. Validating a Message Based on Integrity Check ......12
7. Provisioning of Routers ........................................12
8. Security Considerations ........................................12
8.1. Mitigated Attacks .........................................13
8.1.1. Identity Spoofing ..................................13
8.1.2. Link Spoofing ......................................13
8.1.3. Replay Attack ......................................13
8.2. Limitations ...............................................13
9. Acknowledgments ................................................14
10. References ....................................................14
10.1. Normative References .....................................14
10.2. Informative References ...................................14
Table of Contents
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Applicability Statement .........................................5
4. Protocol Overview and Functioning ...............................6
5. Parameters ......................................................7
6. Message Generation and Processing ...............................9
6.1. Message Content ............................................9
6.2. Message Generation ........................................10
6.3. Message Processing ........................................11
6.3.1. Validating a Message Based on Timestamp ............11
6.3.2. Validating a Message Based on Integrity Check ......12
7. Provisioning of Routers ........................................12
8. Security Considerations ........................................12
8.1. Mitigated Attacks .........................................13
8.1.1. Identity Spoofing ..................................13
8.1.2. Link Spoofing ......................................13
8.1.3. Replay Attack ......................................13
8.2. Limitations ...............................................13
9. Acknowledgments ................................................14
10. References ....................................................14
10.1. Normative References .....................................14
10.2. Informative References ...................................14
This specification updates [RFC6130] and [RFC7181] by defining mandatory-to-implement security mechanisms (for integrity and replay protection). A deployment of these protocols may choose to employ an alternative(s) to these mechanisms; in particular, it may choose to protect packets rather than messages, it may choose to use an alternative Integrity Check Value (ICV) with preferred properties, and/or it may use an alternative timestamp. A deployment may choose to use no such security mechanisms, but this is not recommended.
本规范更新了[RFC6130]和[RFC7181]，定义了实现安全机制（完整性和重播保护）的强制要求。这些协议的部署可以选择采用这些机制的替代方案；特别地，它可以选择保护分组而不是消息，它可以选择使用具有优选属性的替代完整性检查值（ICV），和/或它可以使用替代时间戳。部署可以选择不使用此类安全机制，但不建议这样做。
The mechanisms specified are the use of an ICV for protection of the protocols' control messages and the use of timestamps in those messages to prevent replay attacks. Both use the TLV mechanism specified in [RFC5444] to add this information to the messages. These ICV and TIMESTAMP TLVs are defined in [RFC7182]. Different ICV TLVs are used for HELLO messages in NHDP and TC (Topology Control) messages in OLSRv2, the former also protecting the source address of the IP datagram that contains the HELLO message. This is because the IP datagram source address is used by NHDP to determine the address of a neighbor interface, and it is not necessarily otherwise contained in the HELLO message, while OLSRv2's TC message is forwarded in a new packet; thus, it has no single IP datagram source address.
指定的机制是使用ICV来保护协议的控制消息，以及在这些消息中使用时间戳来防止重播攻击。两者都使用[RFC5444]中指定的TLV机制将此信息添加到消息中。[RFC7182]中定义了这些ICV和时间戳TLV。NHDP中的HELLO消息和OLSRv2中的TC（拓扑控制）消息使用不同的ICV TLV，前者还保护包含HELLO消息的IP数据报的源地址。这是因为NHDP使用IP数据报源地址来确定邻居接口的地址，并且它不一定包含在HELLO消息中，而OLSRv2的TC消息在新分组中转发；因此，它没有单一的IP数据报源地址。
The mechanism specified in this document is placed in the packet/ message processing flow as indicated in Figure 1. It exists between the packet parsing/generation function of [RFC5444] and the message processing/generation function of NHDP and OLSRv2.
如图1所示，本文档中指定的机制位于数据包/消息处理流中。它存在于[RFC5444]的数据包解析/生成功能和NHDP和OLSRv2的消息处理/生成功能之间。
| |
Incoming | /|\ Outgoing
packet \|/ | packet
| |
+--------------------------------+
| |
| RFC 5444 packet |
| parsing/generation |
| |
+--------------------------------+
| |
Messages | /|\ Messages with
\|/ | added TLVs
| |
D +--------------------------------+
R /__________________ | |
O \ Messages | Mechanism specified in |
P (failed check) | this document |
| |
+--------------------------------+
| |
Messages | /|\ Messages
(passed check) \|/ |
| |
+--------------------------------+
| |
| NHDP/OLSRv2 message |
| processing/generation |
| |
+--------------------------------+
| |
Incoming | /|\ Outgoing
packet \|/ | packet
| |
+--------------------------------+
| |
| RFC 5444 packet |
| parsing/generation |
| |
+--------------------------------+
| |
Messages | /|\ Messages with
\|/ | added TLVs
| |
D +--------------------------------+
R /__________________ | |
O \ Messages | Mechanism specified in |
P (failed check) | this document |
| |
+--------------------------------+
| |
Messages | /|\ Messages
(passed check) \|/ |
| |
+--------------------------------+
| |
| NHDP/OLSRv2 message |
| processing/generation |
| |
+--------------------------------+
Figure 1: Relationship with RFC 5444 and NHDP/OLSRv2
图1：与RFC 5444和NHDP/OLSRv2的关系
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
Additionally, this document uses the terminology and notation of [RFC5444], [RFC6130], [RFC7181], and [RFC7182].
此外，本文件使用了[RFC5444]、[RFC6130]、[RFC7181]和[RFC7182]的术语和符号。
[RFC6130] and [RFC7181] enable specifications of extensions to recognize additional reasons for rejecting a message as "badly formed and therefore invalid for processing", and mention security (integrity protection) as an explicit example. This document specifies a mechanism that provides this functionality.
[RFC6130]和[RFC7181]使扩展规范能够识别拒绝消息的其他原因，即“格式错误，因此无法处理”，并将安全性（完整性保护）作为一个明确的示例。本文档指定了提供此功能的机制。
Implementations of [RFC6130] and [RFC7181] MUST include this mechanism, and deployments of [RFC6130] and [RFC7181] SHOULD use this mechanism, except when a different security mechanism is more appropriate.
[RFC6130]和[RFC7181]的实现必须包括此机制，[RFC6130]和[RFC7181]的部署应使用此机制，除非更适合使用其他安全机制。
The applicability of this mechanism is determined by its characteristics, which are that it:
该机制的适用性取决于其特点，即：
o Specifies a security mechanism that is required to be included in conforming implementations of [RFC6130] and [RFC7181].
o 指定[RFC6130]和[RFC7181]的一致性实现中需要包含的安全机制。
o Specifies an association of ICVs with protocol messages, and specifies how to use a missing or invalid ICV as a reason to reject a message as "badly formed and therefore invalid for processing".
o 指定ICV与协议消息的关联，并指定如何使用丢失或无效的ICV作为拒绝消息的理由，以“格式错误，因此无法处理”。
o Specifies the implementation of an ICV Message TLV, defined in [RFC7182], using a SHA-256-based Hashed Message Authentication Code (HMAC) applied to the appropriate message contents (and for HELLO messages also including the IP datagram source address). Implementations of [RFC6130] and [RFC7181] MUST support an HMAC-SHA-256 ICV TLV, and deployments SHOULD use it except when use of a different algorithm is more appropriate. An implementation MAY use more than one ICV TLV in a message, as long as they each use a different algorithm or key to calculate the ICV.
o 指定[RFC7182]中定义的ICV消息TLV的实现，使用基于SHA-256的哈希消息身份验证码（HMAC）应用于适当的消息内容（对于HELLO消息，还包括IP数据报源地址）。[RFC6130]和[RFC7181]的实现必须支持HMAC-SHA-256 ICV TLV，部署应使用它，除非使用不同的算法更合适。一个实现可以在消息中使用多个ICV TLV，只要它们各自使用不同的算法或密钥来计算ICV。
o Specifies the implementation of a TIMESTAMP Message TLV, defined in [RFC7182], to provide message replay protection. Implementations of [RFC6130] and [RFC7181] using this mechanism MUST support a timestamp based on POSIX time, and deployments SHOULD use it if the clocks in all routers in the network can be synchronized with sufficient precision.
o 指定[RFC7182]中定义的时间戳消息TLV的实现，以提供消息重播保护。使用此机制的[RFC6130]和[RFC7181]的实现必须支持基于POSIX时间的时间戳，如果网络中所有路由器的时钟能够以足够的精度同步，则部署应使用它。
o Assumes that a router that is able to generate correct integrity check values is considered trusted.
o 假设能够生成正确完整性检查值的路由器被视为受信任的路由器。
This mechanism does not:
该机制不：
o Specify which key identifiers are to be used in a MANET in which the routers share more than one secret key. (Such keys will be differentiated using the <key-id> field defined in an ICV TLV in [RFC7182].)
o 指定路由器共享多个密钥的MANET中要使用的密钥标识符。（将使用[RFC7182]中ICV TLV中定义的<key id>字段区分这些密钥。）
o Specify how to distribute cryptographic material (shared secret key(s)).
o 指定如何分发加密材料（共享密钥）。
o Specify how to detect compromised routers with valid keys.
o 指定如何使用有效密钥检测受损路由器。
o Specify how to handle (revoke) compromised routers with valid keys.
o 指定如何使用有效密钥处理（撤销）受损路由器。
The mechanism specified in this document provides the following functionalities for use with messages specified by [RFC6130] and [RFC7181]:
本文档中指定的机制提供了以下功能，用于[RFC6130]和[RFC7181]指定的消息：
o Generation of ICV Message TLVs (as defined in [RFC7182]) for inclusion in an outgoing message. An implementation of [RFC6130] and [RFC7181] MAY use more than one ICV TLV in a message, even with the same type extension, but these ICV TLVs MUST each use different keys or they MUST use a different algorithm to calculate the ICV, e.g., with different hash and/or cryptographic functions when using type extension 1 or 2. An implementation of [RFC6130] and [RFC7181] MUST at least be able to generate an ICV TLV using HMAC-SHA-256 and one or more secret keys shared by all routers.
o 生成ICV消息TLV（定义见[RFC7182]），以包含在传出消息中。[RFC6130]和[RFC7181]的实现可能在消息中使用多个ICV TLV，即使具有相同的类型扩展，但这些ICV TLV必须各自使用不同的密钥，或者它们必须使用不同的算法来计算ICV，例如，使用类型扩展1或2时使用不同的哈希和/或加密函数。[RFC6130]和[RFC7181]的实现必须至少能够使用HMAC-SHA-256和所有路由器共享的一个或多个密钥生成ICV TLV。
o Generation of TIMESTAMP Message TLVs (as defined in [RFC7182]) for inclusion in an outgoing message. An implementation of [RFC6130] and [RFC7181] MAY use more than one ICV TLV in a message, but it MUST NOT use the same type extension. An implementation of [RFC6130] and [RFC7181] that is able to synchronize the clocks in all routers in the network with sufficient precision MUST at least be able to generate a TIMESTAMP TLV using POSIX time.
o 生成时间戳消息TLV（如[RFC7182]中定义）以包含在传出消息中。[RFC6130]和[RFC7181]的实现可以在消息中使用多个ICV TLV，但不能使用相同的类型扩展。[RFC6130]和[RFC7181]能够以足够的精度同步网络中所有路由器中的时钟的实现必须至少能够使用POSIX time生成时间戳TLV。
o Verification of ICV Message TLVs contained in a message, in order to determine if this message MUST be rejected as "badly formed and therefore invalid for processing" [RFC6130] [RFC7181]. An implementation of [RFC6130] and [RFC7181] MUST at least be able to verify an ICV TLV using HMAC/SHA-256 and one or more secret keys shared by all routers.
o 验证报文中包含的ICV报文TLV，以确定该报文是否必须被拒绝为“格式错误，因此无法处理”[RFC6130][RFC7181]。[RFC6130]和[RFC7181]的实现必须至少能够使用HMAC/SHA-256和所有路由器共享的一个或多个密钥验证ICV TLV。
o Verification of TIMESTAMP Message TLVs (as defined in [RFC7182]) contained in a message, in order to determine if this message MUST be rejected as "badly formed and therefore invalid for processing" [RFC6130] [RFC7181]. An implementation of [RFC6130] and [RFC7181] that is able to synchronize the clocks in all routers in the network with sufficient precision MUST at least be able to verify a TIMESTAMP TLV using POSIX time.
o 验证消息中包含的时间戳消息TLV（定义见[RFC7182]），以确定此消息是否必须被拒绝为“格式错误，因此无法处理”[RFC6130][RFC7181]。[RFC6130]和[RFC7181]能够以足够的精度同步网络中所有路由器中的时钟的实现必须至少能够使用POSIX time验证时间戳TLV。
ICV Packet TLVs (as defined in [RFC7182]) MAY be used by a deployment of the multiplexing process defined in [RFC5444], either as well as or instead of the protection of the NHDP and OLSRv2 messages. (Note that in the case of NHDP, the packet protection is equally good, and also protects the packet header. In the case of OLSRv2, the packet protection has different properties than the message protection, especially for some forms of ICV. When packets contain more than one message, the packet protection has lower overheads in space and computation time.)
ICV数据包TLV（如[RFC7182]中所定义）可由[RFC5444]中所定义的多路复用过程的部署使用，以及或代替NHDP和OLSRv2消息的保护。（注意，在NHDP的情况下，数据包保护同样良好，并且还保护数据包报头。在OLSRv2的情况下，数据包保护具有不同于消息保护的属性，特别是对于某些形式的ICV。当数据包包含多条消息时，数据包保护在空间和计算方面的开销较低准时。）
When a router generates a message on a MANET interface, this mechanism:
当路由器在MANET接口上生成消息时，此机制：
o Specifies how to calculate an ICV for the message.
o 指定如何计算消息的ICV。
o Specifies how to include that ICV using an ICV Message TLV.
o 指定如何使用ICV消息TLV包含该ICV。
[RFC6130] and [RFC7181] allow for the rejection of incoming messages prior to processing by NHDP or OLSRv2. This mechanism, when used, specifies that a message MUST be rejected if the ICV Message TLV is absent, or its value cannot be verified. Note that this means that routers whose implementation of NHDP and/or OLSRv2 does not include this specification will be ignored by routers using this mechanism, and these two sets of routers will, by design, form disjoint MANETs. (The unsecured MANET will retain some information about the secured MANET, but be unable to use it, not having any recognized symmetric links with the secured MANET.)
[RFC6130]和[RFC7181]允许在NHDP或OLSRv2处理之前拒绝传入消息。使用此机制时，指定如果ICV消息TLV不存在或无法验证其值，则必须拒绝消息。注意，这意味着使用该机制的路由器将忽略其NHDP和/或OLSRv2的实现不包括该规范的路由器，并且这两组路由器将通过设计形成不相交的MANET。（不安全的MANET将保留有关安全MANET的一些信息，但无法使用它，与安全MANET没有任何可识别的对称链路。）
The following router parameters are specified for use by the two protocols; the first is required only by NHDP, but may be visible to OLSRv2, the second is required only by OLSRv2:
以下路由器参数由两个协议指定使用；第一个仅由NHDP要求，但OLSRv2可能可见，第二个仅由OLSRv2要求：
o MAX_HELLO_TIMESTAMP_DIFF - The maximum age that a HELLO message to be validated may have. If the current POSIX time of the router validating the HELLO message, minus the timestamp indicated in the TIMESTAMP TLV of the HELLO message, is greater than MAX_HELLO_TIMESTAMP_DIFF, the HELLO message MUST be silently discarded.
o MAX_HELLO_TIMESTAMP_DIFF-要验证的HELLO消息可能具有的最大期限。如果路由器验证HELLO消息的当前POSIX时间减去HELLO消息的时间戳TLV中指示的时间戳大于MAX_HELLO_timestamp_DIFF，则HELLO消息必须以静默方式丢弃。
o MAX_TC_TIMESTAMP_DIFF - The maximum age that a TC message to be validated may have. If the current POSIX time of the router validating the TC message, minus the timestamp indicated in the TIMESTAMP TLV of the TC message, is greater than MAX_TC_TIMESTAMP_DIFF, the TC message MUST be silently discarded.
o MAX_TC_TIMESTAMP_DIFF-要验证的TC消息可能具有的最大期限。如果路由器验证TC消息的当前POSIX时间减去TC消息的时间戳TLV中指示的时间戳大于MAX_TC_timestamp_DIFF，则必须以静默方式丢弃TC消息。
The following constraints apply to these parameters:
以下约束适用于这些参数：
o MAX_HELLO_TIMESTAMP_DIFF > 0
o 最大\u HELLO\u时间戳\u差异>0
o MAX_TC_TIMESTAMP_DIFF > 0
o 最大时间戳差异>0
However, these bounds are insufficient: MAX_HELLO_TIMESTAMP_DIFF and MAX_TC_TIMESTAMP_DIFF MUST be least as great as the maximum expected "age" of a message (i.e., the time difference between a message has been sent by a router and received by all intended destinations). For HELLO messages, this needs only cover a single hop, but TC messages may have been forwarded a number of times. In particular, for TC messages, if using jitter as specified in [RFC7181] and [RFC5148], the largest contribution the age may be a delay of up to F_MAXJITTER per hop (except the final hop) that the message has traveled. Other factors in the delay of both message types, per hop, may include the link-layer that is used in the MANET, and CPU and memory resources of routers (e.g., queuing delays, and delays for processing ICVs). An implementation MAY set lower and/or upper bounds on these parameters, if so, then these MUST allow values meeting these requirements. An implementation MAY make its value of MAX_TC_TIMESTAMP_DIFF dependent on the number of hops that a TC message has traveled.
然而，这些界限是不够的：MAX_HELLO_TIMESTAMP_DIFF和MAX_TC_TIMESTAMP_DIFF必须至少与消息的最大预期“年龄”相同（即，消息已由路由器发送和所有预期目的地接收之间的时间差）。对于HELLO消息，这只需要覆盖一个跃点，但TC消息可能已转发多次。特别是，对于TC消息，如果使用[RFC7181]和[RFC5148]中规定的抖动，则年龄的最大贡献可能是消息已移动的每跳（最后一跳除外）最多F_MAXJITTER的延迟。这两种消息类型的每跳延迟中的其他因素可能包括MANET中使用的链路层，以及路由器的CPU和内存资源（例如，排队延迟和处理ICV的延迟）。实现可以设置这些参数的下限和/或上限，如果是，那么这些参数必须允许满足这些要求的值。一个实现可以使其MAX_TC_TIMESTAMP_DIFF的值取决于TC消息所经过的跳数。
The above constraints assume ideal time synchronization of the clock in all routers in the network. The parameters MAX_HELLO_TIMESTAMP_DIFF and MAX_TC_TIMESTAMP_DIFF (and any constraints on them) MAY be increased to allow for expected timing differences between routers (between neighboring routers for MAX_HELLO_TIMESTAMP_DIFF, allowing for greater separation, but usually not per hop, for MAX_TC_TIMESTAMP_DIFF).
上述约束假设网络中所有路由器的时钟都是理想的时间同步。可以增加参数MAX_HELLO_TIMESTAMP_DIFF和MAX_TC_TIMESTAMP_DIFF（以及对它们的任何约束）以允许路由器之间的预期定时差异（对于MAX_HELLO_TIMESTAMP_DIFF，相邻路由器之间允许更大的分离，但是对于MAX_TC_TIMESTAMP_DIFF，通常不是每跳）。
Note that excessively large values of these parameters defeats their objectives, so these parameters SHOULD be as large as is required, but not significantly larger.
请注意，这些参数的值过大会破坏它们的目标，因此这些参数应尽可能大，但不能太大。
Using POSIX time allows a resolution of no more than one second. In many MANET use cases, time synchronization much below one second is not possible because of unreliable and high-delay channels, mobility, interrupted communication, and possible resource limitations.
使用POSIX时间允许不超过1秒的分辨率。在许多MANET使用情况下，由于不可靠和高延迟信道、移动性、通信中断以及可能的资源限制，不可能实现远低于1秒的时间同步。
In addition, when using the default message intervals and validity times as specified in [RFC6130] and [RFC7181], where the shortest periodic message interval is 2 seconds, repeating the message within a second is actually beneficial rather than harmful (at a small bandwidth cost). Also, the use of [RFC5148] jitter can cause a message to take that long or longer to traverse the MANET, thus even in a perfectly synchronized network, the TC maximum delay would usually be greater than 1 second.
此外，当使用[RFC6130]和[RFC7181]中规定的默认消息间隔和有效时间时，其中最短的周期性消息间隔为2秒，在一秒钟内重复消息实际上是有益的，而不是有害的（以较小的带宽成本）。此外，使用[RFC5148]抖动可能会导致消息在移动自组网中花费如此长或更长的时间，因此，即使在完全同步的网络中，TC最大延迟通常也会大于1秒。
A finer granularity than 1 second, and thus the use of an alternative timestamp, is however RECOMMENDED in cases where, possibly due to fast moving routers, message validity times are below 1 second.
然而，在可能由于快速移动的路由器，消息有效时间低于1秒的情况下，建议使用比1秒更细的粒度，并因此使用替代时间戳。
This section specifies how messages are generated and processed by [RFC6130] and [RFC7181] when using this mechanism.
本节指定使用此机制时，[RFC6130]和[RFC7181]如何生成和处理消息。
Messages MUST have the content specified in [RFC6130] and [RFC7181], respectively. In addition, messages that conform to this mechanism MUST contain:
消息必须分别具有[RFC6130]和[RFC7181]中指定的内容。此外，符合此机制的消息必须包含：
o At least one ICV Message TLV (as specified in [RFC7182]), generated according to Section 6.2. Implementations of [RFC6130] and [RFC7181] MUST support the following version of the ICV TLV, but other versions MAY be used instead, or in addition, in a deployment, if more appropriate:
o 根据第6.2节生成的至少一条ICV信息TLV（如[RFC7182]中规定）。[RFC6130]和[RFC7181]的实现必须支持以下版本的ICV TLV，但也可以使用其他版本，或者在部署中使用（如果更合适）：
* For TC messages:
* 对于TC消息：
+ type-extension := 1
+ 类型扩展：=1
* For HELLO messages:
* 有关HELLO消息：
+ type-extension := 2
+ 类型扩展：=2
* hash-function := 3 (SHA-256)
* 散列函数：=3（SHA-256）
* cryptographic-function := 3 (HMAC)
* 加密函数：=3（HMAC）
The ICV Value MAY be truncated as specified in [RFC7182]; the selection of an appropriate length MAY be administratively configured. A message MAY contain several ICV Message TLVs.
ICV值可以按照[RFC7182]中的规定进行截断；适当长度的选择可在管理上配置。一条消息可能包含多个ICV消息TLV。
o At least one TIMESTAMP Message TLV (as specified in [RFC7182]), generated according to Section 6.2. Implementations of [RFC6130] and [RFC7181] using this mechanism MUST support the following version of the TIMESTAMP TLV, but other versions MAY be used instead, or in addition, in a deployment, if more appropriate:
o 根据第6.2节生成的至少一条时间戳消息TLV（如[RFC7182]中规定）。使用此机制的[RFC6130]和[RFC7181]的实现必须支持以下版本的时间戳TLV，但可以使用其他版本，或者在部署中使用其他版本（如果更合适）：
* type-extension := 1
* 类型扩展：=1
After message generation (Section 11.1 of [RFC6130] and Section 16.1. of [RFC7181]) and before message transmission (Section 11.2 of [RFC6130] and Section 16.2 of [RFC7181]), the additional TLVs specified in Section 6.1 MUST (unless already present) be added to an outgoing message when using this mechanism.
在消息生成之后（RFC6130第11.1节和RFC7181第16.1节）和消息传输之前（RFC6130第11.2节和RFC7181第16.2节），在使用此机制时，必须将第6.1节中规定的附加TLV（除非已经存在）添加到传出消息中。
The following processing steps (when using a single timestamp version and a single ICV algorithm) MUST be performed for a cryptographic algorithm that is used for generating an ICV for a message:
对于用于生成消息ICV的加密算法，必须执行以下处理步骤（当使用单个时间戳版本和单个ICV算法时）：
1. All ICV TLVs (if any) are temporarily removed from the message. Any temporarily removed ICV TLVs MUST be stored, in order to be reinserted into the message in step 5. The message size and Message TLV Block size are updated accordingly.
1. 所有ICV TLV（如果有）将从消息中临时删除。必须存储任何临时移除的ICV TLV，以便在步骤5中重新插入到消息中。相应地更新消息大小和消息TLV块大小。
2. <msg-hop-count> and <msg-hop-limit>, if present, are temporarily set to 0.
2. <msg hop count>和<msg hop limit>如果存在，则临时设置为0。
3. A TLV of type TIMESTAMP, as specified in Section 6.1, is added to the Message TLV Block. The message size and Message TLV Block size are updated accordingly.
3. 第6.1节中规定的时间戳类型的TLV被添加到消息TLV块中。相应地更新消息大小和消息TLV块大小。
4. A TLV of type ICV, as specified in Section 6.1, is added to the Message TLV Block. The message size and Message TLV Block size are updated accordingly.
4. 第6.1节中规定的ICV类型TLV被添加到消息TLV块中。相应地更新消息大小和消息TLV块大小。
5. All ICV TLVs that were temporary removed in step 1, are restored. The message size and Message TLV Block size are updated accordingly.
5. 恢复步骤1中临时移除的所有ICV TLV。相应地更新消息大小和消息TLV块大小。
6. <msg-hop-count> and <msg-hop-limit>, if present, are restored to their previous values.
6. <msg-hop-count>和<msg-hop-limit>如果存在，将恢复为以前的值。
An implementation MAY add either alternative TIMESTAMP and/or ICV TLVs or more than one TIMESTAMP and/or ICV TLVs. All TIMESTAMP TLVs MUST be inserted before adding ICV TLVs.
实现可以添加备选时间戳和/或ICV TLV或多个时间戳和/或ICV TLV。在添加ICV TLV之前，必须插入所有时间戳TLV。
Both [RFC6130] and [RFC7181] specify that:
[RFC6130]和[RFC7181]都指定：
On receiving a ... message, a router MUST first check if the message is invalid for processing by this router
在收到。。。消息，路由器必须首先检查该消息是否对此路由器的处理无效
[RFC6130] and [RFC7181] proceed to give a number of conditions that, each, will lead to a rejection of the message as "badly formed and therefore invalid for processing". When using a single timestamp version, and a single ICV algorithm, add the following conditions to that list, each of which, if true, MUST cause NHDP or OLSRv2 (as appropriate) to consider the message as invalid for processing when using this mechanism:
[RFC6130]和[RFC7181]继续给出许多条件，每种条件都会导致拒绝消息，因为“格式错误，因此无法处理”。当使用单个时间戳版本和单个ICV算法时，将以下条件添加到该列表中，每个条件（如果是真的）必须导致NHDP或OLSRv2（适当时）认为在使用该机制时，消息对于处理无效：
1. The Message TLV Block of the message does not contain exactly one TIMESTAMP TLV of the selected version. This version specification includes the type extension. (The Message TLV Block may also contain TIMESTAMP TLVs of other versions.)
1. 消息的消息TLV块不包含所选版本的一个时间戳TLV。此版本规范包括类型扩展。（消息TLV块还可能包含其他版本的时间戳TLV。）
2. The Message TLV Block does not contain exactly one ICV TLV using the selected algorithm and key identifier. This algorithm specification includes the type extension, and for type extensions 1 and 2, the hash function and cryptographic function. (The Message TLV Block may also contain ICV TLVs using other algorithms and key identifiers.)
2. 消息TLV块不包含使用所选算法和密钥标识符的一个ICV TLV。该算法规范包括类型扩展，对于类型扩展1和2，则包括哈希函数和加密函数。（消息TLV块还可能包含使用其他算法和密钥标识符的ICV TLV。）
3. Validation of the identified (in step 1) TIMESTAMP TLV in the Message TLV Block of the message fails, as according to Section 6.3.1.
3. 根据第6.3.1节，验证消息TLV块中已识别（步骤1）的时间戳TLV失败。
4. Validation of the identified (in step 2) ICV TLV in the Message TLV Block of the message fails, as according to Section 6.3.2.
4. 根据第6.3.2节，验证消息的消息TLV块中已识别（步骤2中）的ICV TLV失败。
An implementation MAY check the existence of, and verify, either an alternative TIMESTAMP and/or ICV TLVs or more than one TIMESTAMP and/ or ICV TLVs.
实现可以检查和验证替代时间戳和/或ICV tlv或多个时间戳和/或ICV tlv的存在。
For a TIMESTAMP Message TLV with type extension 1 (POSIX time) identified as described in Section 6.2:
对于类型扩展名为1（POSIX time）的时间戳消息TLV，如第6.2节所述：
1. If the current POSIX time minus the value of that TIMESTAMP TLV is greater than MAX_HELLO_TIMESTAMP_DIFF (for a HELLO message) or MAX_TC_TIMESTAMP_DIFF (for a TC message), then the message validation fails.
1. 如果当前POSIX时间减去时间戳TLV的值大于MAX_HELLO_TIMESTAMP_DIFF（对于HELLO消息）或MAX_TC_TIMESTAMP_DIFF（对于TC消息），则消息验证失败。
2. Otherwise, the message validation succeeds.
2. 否则，消息验证将成功。
If a deployment chooses to use a different type extension from 1, appropriate measures MUST be taken to verify freshness of the message.
如果部署选择使用与1不同的类型扩展，则必须采取适当的措施来验证消息的新鲜度。
For an ICV Message TLV identified as described in Section 6.2:
对于第6.2节所述的ICV信息TLV：
1. All ICV Message TLVs (including the identified ICV Message TLV) are temporarily removed from the message, and the message size and Message TLV Block size are updated accordingly.
1. 所有ICV消息TLV（包括识别的ICV消息TLV）将从消息中临时删除，消息大小和消息TLV块大小将相应更新。
2. The message's <msg-hop-count> and <msg-hop-limit> fields are temporarily set to 0.
2. 消息的<msg hop count>和<msg hop limit>字段临时设置为0。
3. Calculate the ICV for the parameters specified in the identified ICV Message TLV, as specified in [RFC7182].
3. 根据[RFC7182]中的规定，计算识别ICV消息TLV中指定参数的ICV。
4. If this ICV differs from the value of <ICV-data> in the ICV Message TLV, then the message validation fails. If the <ICV-data> has been truncated (as specified in [RFC7182], the ICV calculated in the previous step MUST be truncated to the TLV length of the ICV Message TLV before comparing it with the <ICV-data>.
4. 如果此ICV与ICV消息TLV中的<ICV data>值不同，则消息验证失败。如果<ICV data>已被截断（如[RFC7182]中所述），则在与<ICV data>进行比较之前，必须将上一步中计算的ICV截断为ICV消息TLV的TLV长度。
5. Otherwise, the message validation succeeds. The message's <msg-hop-count> and <msg-hop-limit> fields are restored to their previous value, and the ICV Message TLVs are returned to the message, whose size is updated accordingly.
5. 否则，消息验证将成功。消息的<msg-hop-count>和<msg-hop-limit>字段将恢复为其以前的值，ICV消息TLV将返回到消息，其大小将相应更新。
Before a router using this mechanism is able to generate ICVs or validate messages, it MUST acquire the shared secret key(s) to be used by all routers that are to participate in the network. This specification does not define how a router acquires secret keys. Once a router has acquired suitable key(s), it MAY be configured to use, or not use, this mechanism. Section 23.6 of [RFC7181] provides a rationale based on [BCP107] why no key management is specified for OLSRv2.
在使用此机制的路由器能够生成ICV或验证消息之前，它必须获取共享密钥，以供参与网络的所有路由器使用。本规范未定义路由器获取密钥的方式。一旦路由器获得了合适的密钥，就可以将其配置为使用或不使用该机制。[RFC7181]第23.6节根据[BCP107]提供了OLSRv2未指定密钥管理的理由。
This document specifies a security mechanism for use with NHDP and OLSRv2 that allows for mitigating several security threats.
本文件规定了与NHDP和OLSRv2一起使用的安全机制，该机制允许缓解多种安全威胁。
This section briefly summarizes security threats that are mitigated by the mechanism presented in this document.
本节简要总结了通过本文档中介绍的机制缓解的安全威胁。
As only routers possessing the selected shared secret key are able to add a valid ICV TLV to a message, identity spoofing, where an attacker falsely claims an identity of a valid router, is countered. When using one or more shared keys for all routers in the MANET, it is only possible to determine that it is a valid router in the network, not to discern particular routers. Therefore, a malicious router in possession of valid keys (e.g., a compromised router) may still spoof the identity of another router using the same key.
由于只有拥有所选共享密钥的路由器才能将有效的ICV TLV添加到消息中，因此会反击身份欺骗，即攻击者虚假声明有效路由器的身份。当对MANET中的所有路由器使用一个或多个共享密钥时，只能确定它是网络中的有效路由器，而不能识别特定的路由器。因此，拥有有效密钥的恶意路由器（例如，受损路由器）仍可能使用相同密钥欺骗另一路由器的身份。
Link spoofing, where an attacker falsely represents the existence of a nonexistent link, or otherwise misrepresents a link's state, is countered by the mechanism specified in this document, using the same argument as in Section 8.1.1.
链接欺骗，即攻击者错误地表示不存在的链接的存在，或以其他方式歪曲链接的状态，由本文档中指定的机制进行反击，使用与第8.1.1节中相同的参数。
Replay attacks are partly countered by the mechanism specified in this document, but this depends on synchronized clocks of all routers in the MANET. An attacker that records messages to replay them later can only do so in the selected time interval after the timestamp that is contained in message. As an attacker cannot modify the content of this timestamp (as it is protected by the identity check value), an attacker cannot replay messages after this time. Within this time interval, it is still possible to perform replay attacks; however, the limits on the time interval are specified so that this will have a limited effect on the operation of the protocol.
本文档中指定的机制可以部分抵御重放攻击，但这取决于MANET中所有路由器的同步时钟。记录消息以便稍后重播的攻击者只能在消息中包含的时间戳之后的选定时间间隔内执行此操作。由于攻击者无法修改此时间戳的内容（因为它受到身份检查值的保护），因此在此之后，攻击者无法重播消息。在此时间间隔内，仍然可以执行重放攻击；但是，规定了时间间隔的限制，以便对协议的操作产生有限的影响。
If no synchronized clocks are available in the MANET, replay attacks cannot be countered by the mechanism provided by this document. An alternative version of the TIMESTAMP TLV defined in [RFC7182], with a monotonic sequence number, may have some partial value in this case, but will necessitate adding state to record observed message sequence number information.
如果MANET中没有可用的同步时钟，则本文档提供的机制无法反击重播攻击。[RFC7182]中定义的具有单调序列号的时间戳TLV的替代版本在这种情况下可能具有部分值，但需要添加状态以记录观察到的消息序列号信息。
The mechanism provided by this document does not avoid or detect security attacks by routers possessing the shared secret key that is used to generate integrity check values for messages.
本文档提供的机制不会避免或检测路由器的安全攻击，这些路由器拥有用于生成消息完整性检查值的共享密钥。
This mechanism relies on an out-of-band protocol or mechanism for distributing the shared secret key(s) (and if an alternative integrity check value is used, any additional cryptographic parameters).
此机制依赖于带外协议或用于分发共享密钥的机制（如果使用替代完整性检查值，则使用任何其他加密参数）。
This mechanism does not provide a key management mechanism. Refer to Section 23.6 of [RFC7181] for a detailed discussion why the automated key management requirements specified in [BCP107] do not apply for OLSRv2 and NHDP.
此机制不提供密钥管理机制。有关[BCP107]中规定的自动密钥管理要求为何不适用于OLSRv2和NHDP的详细讨论，请参阅[RFC7181]第23.6节。
The authors would like to gratefully acknowledge the following people: Justin Dean (NRL) and Henning Rogge (Frauenhofer FKIE).
作者要感谢以下人士：贾斯汀·迪恩（NRL）和汉宁·罗格（弗劳恩霍夫·夫基）。
[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月。
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format", RFC 5444, February 2009.
[RFC5444]Clausen，T.，Dearlove，C.，Dean，J.，和C.Adjih，“通用移动自组网（MANET）数据包/消息格式”，RFC 54442009年2月。
[RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, April 2011.
[RFC6130]Clausen，T.，Dearlove，C.，和J.Dean，“移动自组织网络（MANET）邻域发现协议（NHDP）”，RFC6130，2011年4月。
[RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, "The Optimized Link State Routing Protocol Version 2", RFC 7181, April 2014.
[RFC7181]Clausen，T.，Dearlove，C.，Jacquet，P.，和U.Herberg，“优化链路状态路由协议版本2”，RFC 7181，2014年4月。
[RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)", RFC 7182, April 2014.
[RFC7182]Herberg，U.，Clausen，T.，和C.Dearlove，“移动自组网（MANET）的完整性检查值和时间戳TLV定义”，RFC 7182，2014年4月。
[BCP107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[BCP107]Bellovin，S.和R.Housley，“加密密钥管理指南”，BCP 107，RFC 4107，2005年6月。
[RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter Considerations in Mobile Ad Hoc Networks (MANETs)", RFC 5148, February 2008.
[RFC5148]Clausen，T.，Dearlove，C.，和B.Adamson，“移动自组网（MANET）中的抖动考虑”，RFC 5148，2008年2月。
Authors' Addresses
作者地址
Ulrich Herberg Fujitsu Laboratories of America 1240 E. Arques Ave. Sunnyvale, CA, 94085 USA
美国加州桑尼维尔阿克斯大道东1240号乌尔里希·赫伯格富士通实验室，邮编94085
EMail: ulrich@herberg.name
URI: http://www.herberg.name/
EMail: ulrich@herberg.name
URI: http://www.herberg.name/
Christopher Dearlove BAE Systems Advanced Technology Centre West Hanningfield Road Great Baddow, Chelmsford United Kingdom
克里斯托弗·迪尔洛夫英国切姆斯福德大巴德西汉宁菲尔德路BAE系统先进技术中心
Phone: +44 1245 242194
EMail: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/
Phone: +44 1245 242194
EMail: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/
Thomas Heide Clausen LIX, Ecole Polytechnique 91128 Palaiseau Cedex France
托马斯·海德·克劳森·利克斯，法国塞德克斯宫91128理工学院
Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org
URI: http://www.thomasclausen.org/
Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org
URI: http://www.thomasclausen.org/