Internet Engineering Task Force (IETF) U. Herberg
Request for Comments: 6622 Fujitsu Laboratories of America
Category: Standards Track T. Clausen
ISSN: 2070-1721 LIX, Ecole Polytechnique
May 2012
Internet Engineering Task Force (IETF) U. Herberg
Request for Comments: 6622 Fujitsu Laboratories of America
Category: Standards Track T. Clausen
ISSN: 2070-1721 LIX, Ecole Polytechnique
May 2012
Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)
移动自组织网络（MANET）的完整性检查值和时间戳TLV定义
Abstract
摘要
This document describes general and flexible TLVs for representing cryptographic Integrity Check Values (ICVs) (i.e., digital signatures or Message Authentication Codes (MACs)) as well as timestamps, using the generalized Mobile Ad Hoc Network (MANET) packet/message format defined in RFC 5444. It defines two Packet TLVs, two Message TLVs, and two Address Block TLVs for affixing ICVs and timestamps to a packet, a message, and an address, respectively.
本文件描述了使用RFC 5444中定义的通用移动自组织网络（MANET）数据包/消息格式表示密码完整性检查值（ICV）（即数字签名或消息认证码（MAC））以及时间戳的通用灵活TLV。它定义了两个数据包TLV、两个消息TLV和两个地址块TLV，分别用于将ICV和时间戳附加到数据包、消息和地址。
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/rfc6622.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6622.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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 .....................................................3
3. Applicability Statement .........................................3
4. Security Architecture ...........................................4
5. Overview and Functioning ........................................5
6. General ICV TLV Structure .......................................6
7. General Timestamp TLV Structure .................................6
8. Packet TLVs .....................................................7
8.1. Packet ICV TLV .............................................7
8.2. Packet TIMESTAMP TLV .......................................7
9. Message TLVs ....................................................8
9.1. Message ICV TLV ............................................8
9.2. Message TIMESTAMP TLV ......................................8
10. Address Block TLVs .............................................8
10.1. Address Block ICV TLV .....................................8
10.2. Address Block TIMESTAMP TLV ...............................9
11. ICV: Basic .....................................................9
12. ICV: Cryptographic Function over a Hash Value ..................9
12.1. General ICV TLV Structure ................................10
12.1.1. Rationale .........................................11
12.2. Considerations for Calculating the ICV ...................11
12.2.1. Packet ICV TLV ....................................11
12.2.2. Message ICV TLV ...................................11
12.2.3. Address Block ICV TLV .............................11
12.3. Example of a Message Including an ICV ....................12
13. IANA Considerations ...........................................13
13.1. Expert Review: Evaluation Guidelines .....................13
13.2. Packet TLV Type Registrations ............................14
13.3. Message TLV Type Registrations ...........................15
13.4. Address Block TLV Type Registrations .....................16
13.5. Hash Functions ...........................................17
13.6. Cryptographic Functions ..................................18
14. Security Considerations .......................................18
15. Acknowledgements ..............................................19
16. References ....................................................19
16.1. Normative References .....................................19
16.2. Informative References ...................................21
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Applicability Statement .........................................3
4. Security Architecture ...........................................4
5. Overview and Functioning ........................................5
6. General ICV TLV Structure .......................................6
7. General Timestamp TLV Structure .................................6
8. Packet TLVs .....................................................7
8.1. Packet ICV TLV .............................................7
8.2. Packet TIMESTAMP TLV .......................................7
9. Message TLVs ....................................................8
9.1. Message ICV TLV ............................................8
9.2. Message TIMESTAMP TLV ......................................8
10. Address Block TLVs .............................................8
10.1. Address Block ICV TLV .....................................8
10.2. Address Block TIMESTAMP TLV ...............................9
11. ICV: Basic .....................................................9
12. ICV: Cryptographic Function over a Hash Value ..................9
12.1. General ICV TLV Structure ................................10
12.1.1. Rationale .........................................11
12.2. Considerations for Calculating the ICV ...................11
12.2.1. Packet ICV TLV ....................................11
12.2.2. Message ICV TLV ...................................11
12.2.3. Address Block ICV TLV .............................11
12.3. Example of a Message Including an ICV ....................12
13. IANA Considerations ...........................................13
13.1. Expert Review: Evaluation Guidelines .....................13
13.2. Packet TLV Type Registrations ............................14
13.3. Message TLV Type Registrations ...........................15
13.4. Address Block TLV Type Registrations .....................16
13.5. Hash Functions ...........................................17
13.6. Cryptographic Functions ..................................18
14. Security Considerations .......................................18
15. Acknowledgements ..............................................19
16. References ....................................................19
16.1. Normative References .....................................19
16.2. Informative References ...................................21
This document specifies
本文件规定
o Two TLVs for carrying Integrity Check Values (ICVs) and timestamps in packets, messages, and address blocks as defined by [RFC5444].
o 两个TLV，用于在[RFC5444]定义的数据包、消息和地址块中承载完整性检查值（ICV）和时间戳。
o A generic framework for ICVs, accounting (for Message TLVs) for mutable message header fields (<msg-hop-limit> and <msg-hop-count>), where these fields are present in messages.
o ICV的通用框架，用于计算可变消息头字段（<msg-hop-limit>和<msg-hop-count>）的（消息TLV），其中这些字段存在于消息中。
This document sets up IANA registries for recording code points for hash-function and ICV calculation, respectively.
本文档建立了IANA注册表，分别用于记录哈希函数和ICV计算的代码点。
Moreover, in Section 12, this document defines the following:
此外，在第12节中，本文件定义了以下内容：
o One common method for generating ICVs as a cryptographic function, calculated over the hash value of the content.
o 将ICV生成为加密函数的一种常用方法，通过内容的哈希值进行计算。
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]中的说明进行解释。
This document uses the terminology and notation defined in [RFC5444]. In particular, the following TLV fields from [RFC5444] are used in this specification:
本文件使用[RFC5444]中定义的术语和符号。特别是，本规范中使用了[RFC5444]中的以下TLV字段：
<msg-hop-limit> is the hop limit of a message, as specified in Section 5.2 of [RFC5444].
<msg hop limit>是[RFC5444]第5.2节中规定的消息的跃点限制。
<msg-hop-count> is the hop count of a message, as specified in Section 5.2 of [RFC5444].
<msg hop count>是[RFC5444]第5.2节中规定的消息的跃点计数。
<length> is the length of a TLV in octets, as specified in Section 5.4.1 of [RFC5444].
<length>是TLV的长度，单位为八位字节，如[RFC5444]第5.4.1节所述。
MANET routing protocols using the format defined in [RFC5444] are accorded the ability to carry additional information in control messages and packets, through the inclusion of TLVs. Information so included MAY be used by a MANET routing protocol, or by an extension of a MANET routing protocol, according to its specification.
通过包含TLV，使用[RFC5444]中定义的格式的MANET路由协议被赋予在控制消息和数据包中携带附加信息的能力。根据MANET路由协议的规范，这样包括的信息可以由MANET路由协议使用，或者由MANET路由协议的扩展使用。
This document specifies how to include an ICV for a packet, a message, and addresses in address blocks within a message, by way of such TLVs. This document also specifies a) how to treat "mutable" fields, specifically the <msg-hop-count> and <msg-hop-limit> fields, if present in the message header when calculating ICVs, such that the resulting ICV can be correctly verified by any recipient, and b) how to include this ICV.
本文档规定了如何通过此类TLV将数据包、消息和地址块中的地址包含在ICV中。本文档还规定了a）如何处理“可变”字段，特别是<msg-hop-count>和<msg-hop-limit>字段（如果在计算ICV时出现在消息头中），以便任何收件人都能正确验证生成的ICV，以及b）如何包含此ICV。
This document describes a generic framework for creating ICVs, and how to include these ICVs in TLVs. In Section 12, an example method for calculating such ICVs is given, using a cryptographic function over the hash value of the content.
本文档描述了创建ICV的通用框架，以及如何将这些ICV包括在TLV中。在第12节中，给出了使用对内容的散列值的加密函数来计算此类icv的示例方法。
Basic MANET routing protocol specifications are often "oblivious to security"; however, they have a clause allowing a control message to be rejected as "badly formed" or "insecure" prior to the message being processed or forwarded. MANET routing protocols such as the Neighborhood Discovery Protocol (NHDP) [RFC6130] and the Optimized Link State Routing Protocol version 2 [OLSRv2] recognize external reasons (such as failure to verify an ICV) for rejecting a message that would be considered "invalid for processing". This architecture is a result of the observation that with respect to security in MANETs, "one size rarely fits all" and that MANET routing protocol deployment domains have varying security requirements ranging from "unbreakable" to "virtually none". The virtue of this approach is that MANET routing protocol specifications (and implementations) can remain "generic", with extensions providing proper security mechanisms specific to a deployment domain.
基本的MANET路由协议规范通常是“忽略安全性”；但是，它们有一个子句，允许在处理或转发消息之前，将控制消息作为“格式错误”或“不安全”拒绝。MANET路由协议，如邻域发现协议（NHDP）[RFC6130]和优化链路状态路由协议版本2[OLSRv2]识别拒绝被视为“处理无效”的消息的外部原因（如未能验证ICV）。这种体系结构是一种观察结果，即在移动自组网的安全性方面，“一刀切”很少适合所有人，并且移动自组网路由协议部署域具有从“不可破解”到“几乎没有”的不同安全要求。这种方法的优点是MANET路由协议规范（和实现）可以保持“通用”，扩展提供特定于部署域的适当安全机制。
The MANET routing protocol "security architecture", in which this specification situates itself, can therefore be summarized as follows:
因此，本规范所处的MANET路由协议“安全架构”可概括如下：
o Security-oblivious MANET routing protocol specifications, with a clause allowing an extension to reject a message (prior to processing/forwarding) as "badly formed" or "insecure".
o 不考虑安全的MANET路由协议规范，其中有一个条款允许扩展以“格式错误”或“不安全”为由拒绝消息（在处理/转发之前）。
o MANET routing protocol security extensions, rejecting messages as "badly formed" or "insecure", as appropriate for a given security requirement specific to a deployment domain.
o MANET路由协议安全扩展，拒绝“格式错误”或“不安全”的消息，适用于特定于部署域的给定安全需求。
o Code points and an exchange format for information, necessary for specification of such MANET routing protocol security extensions.
o 规范这种MANET路由协议安全扩展所必需的代码点和信息交换格式。
This document addresses the last of the issues listed above by specifying a common exchange format for cryptographic ICVs, making reservations from within the Packet TLV, Message TLV, and Address Block TLV registries of [RFC5444], to be used (and shared) among MANET routing protocol security extensions.
本文档通过指定加密ICV的通用交换格式，在[RFC5444]的数据包TLV、消息TLV和地址块TLV注册表中进行保留，以在MANET路由协议安全扩展中使用（和共享），解决上述问题中的最后一个。
For the specific decomposition of an ICV into a cryptographic function over a hash value (specified in Section 12), this document establishes two IANA registries for code points for hash functions and cryptographic functions adhering to [RFC5444].
为了将ICV具体分解为哈希值上的加密函数（在第12节中规定），本文件为哈希函数和遵守[RFC5444]的加密函数的代码点建立了两个IANA注册表。
With respect to [RFC5444], this document is
关于[RFC5444]，本文件为
o Intended to be used in the non-normative, but intended, mode of use described in Appendix B of [RFC5444].
o 拟用于[RFC5444]附录B所述的非规范性但预期的使用模式。
o A specific example of the Security Considerations section of [RFC5444] (the authentication part).
o [RFC5444]（认证部分）的安全注意事项部分的具体示例。
This document specifies a syntactical representation of security-related information for use with [RFC5444] addresses, messages, and packets, and also establishes IANA registrations of TLV types and type extension registries for these TLV types.
本文件规定了与[RFC5444]地址、消息和数据包一起使用的安全相关信息的语法表示，并建立了TLV类型的IANA注册和这些TLV类型的类型扩展注册。
Moreover, this document provides guidelines for how MANET routing protocols and MANET routing protocol extensions using this specification should treat ICV and Timestamp TLVs, and mutable fields in messages. This specification does not represent a stand-alone protocol; MANET routing protocols and MANET routing protocol extensions, using this specification, MUST provide instructions as to how to handle packets, messages, and addresses with security information, associated as specified in this document.
此外，本文档还提供了使用本规范的MANET路由协议和MANET路由协议扩展应如何处理ICV和时间戳TLV以及消息中的可变字段的指南。本规范不代表独立协议；使用本规范的MANET路由协议和MANET路由协议扩展必须提供有关如何处理包含安全信息的数据包、消息和地址的说明，这些信息与本文档中指定的信息相关。
This document assigns TLV types from the registries defined for Packet, Message, and Address Block TLVs in [RFC5444]. When a TLV type is assigned from one of these registries, a registry for type extensions for that TLV type is created by IANA. This document utilizes these type extension registries so created, in order to specify internal structure (and accompanying processing) of the <value> field of a TLV.
本文档从[RFC5444]中为数据包、消息和地址块TLV定义的注册表中分配TLV类型。当从其中一个注册表分配TLV类型时，IANA将创建该TLV类型的类型扩展注册表。本文档利用这样创建的这些类型扩展注册表，以指定TLV的<value>字段的内部结构（以及伴随的处理）。
For example, and as defined in this document, an ICV TLV with type extension = 0 specifies that the <value> field has no pre-defined internal structure but is simply a sequence of octets. An ICV TLV with type extension = 1 specifies that the <value> field has a pre-defined internal structure and defines its interpretation.
例如，如本文档中所定义，类型扩展为0的ICV TLV指定<value>字段没有预定义的内部结构，只是一个八位字节序列。扩展类型为1的ICV TLV指定<value>字段具有预定义的内部结构并定义其解释。
(Specifically, the <value> field consists of a cryptographic operation over a hash value, with fields indicating which hash function and cryptographic operation have been used; this is specified in Section 12.)
（具体而言，<value>字段由哈希值上的加密操作组成，字段指示使用了哪个哈希函数和加密操作；这在第12节中有详细说明。）
Other documents can request assignments for other type extensions; if they do so, they MUST specify their internal structure (if any) and interpretation.
其他文档可以请求其他类型扩展的分配；如果他们这样做，他们必须指定其内部结构（如果有）和解释。
The value of the ICV TLV is
ICV TLV的值为
<value> := <ICV-value>
<value> := <ICV-value>
where
哪里
<ICV-value> is a field, of <length> octets, which contains the information to be interpreted by the ICV verification process, as specified by the type extension.
<ICV value>是一个八位字节的字段，它包含由类型扩展指定的ICV验证过程解释的信息。
Note that this does not stipulate how to calculate the <ICV-value> nor the internal structure thereof, if any; such information MUST be specified by way of the type extension for the ICV TLV type. See Section 13. This document specifies two such type extensions -- one for ICVs without pre-defined structures, and one for ICVs constructed by way of a cryptographic operation over a hash value.
注意，这没有规定如何计算<ICV值>，也没有规定其内部结构（如有）；必须通过ICV TLV类型的类型扩展来指定此类信息。见第13节。本文档指定了两个这样的类型扩展——一个用于没有预定义结构的ICV，另一个用于通过哈希值上的加密操作构造的ICV。
The value of the Timestamp TLV is
时间戳TLV的值为
<value> := <time-value>
<value> := <time-value>
where
哪里
<time-value> is an unsigned integer field, of length <length>, which contains the timestamp.
<time value>是一个长度为<length>的无符号整数字段，其中包含时间戳。
Note that this does not stipulate how to calculate the <time-value> nor the internal structure thereof, if any; such information MUST be specified by way of the type extension for the TIMESTAMP TLV type. See Section 13.
注意，这没有规定如何计算<时间值>或其内部结构（如果有）；必须通过时间戳TLV类型的类型扩展来指定此类信息。见第13节。
A timestamp is essentially "freshness information". As such, its setting and interpretation are to be determined by the MANET routing protocol, or MANET routing protocol extension, that uses the timestamp and can, for example, correspond to a UNIX timestamp, GPS timestamp, or a simple sequence number.
时间戳本质上是“新鲜度信息”。因此，其设置和解释将由使用时间戳的MANET路由协议或MANET路由协议扩展来确定，并且可以例如对应于UNIX时间戳、GPS时间戳或简单序列号。
Two Packet TLVs are defined: one for including the cryptographic ICV of a packet and one for including the timestamp indicating the time at which the cryptographic ICV was calculated.
定义了两个分组tlv：一个用于包括分组的加密ICV，另一个用于包括指示计算加密ICV的时间的时间戳。
A Packet ICV TLV is an example of an ICV TLV as described in Section 6.
分组ICV TLV是第6节中描述的ICV TLV的示例。
The following considerations apply:
以下注意事项适用：
o Because packets as defined in [RFC5444] are never forwarded by routers, no special considerations are required regarding mutable fields (e.g., <msg-hop-count> and <msg-hop-limit>), if present, when calculating the ICV.
o 由于[RFC5444]中定义的数据包从不由路由器转发，因此在计算ICV时，不需要特别考虑可变字段（例如，<msg hop count>和<msg hop limit>）。
o Any Packet ICV TLVs already present in the Packet TLV block MUST be removed before calculating the ICV, and the Packet TLV block size MUST be recalculated accordingly. Removed ICV TLVs MUST be restored after having calculated the ICV value.
o 在计算ICV之前，必须移除已经存在于数据包TLV块中的任何数据包ICV TLV，并且必须相应地重新计算数据包TLV块大小。计算ICV值后，必须恢复移除的ICV TLV。
The rationale for removing any Packet ICV TLV already present prior to calculating the ICV is that several ICVs may be added to the same packet, e.g., using different ICV functions.
在计算ICV之前移除已经存在的任何分组ICV TLV的基本原理是，可以将多个ICV添加到同一分组中，例如，使用不同的ICV功能。
A Packet TIMESTAMP TLV is an example of a Timestamp TLV as described in Section 7. If a packet contains a TIMESTAMP TLV and an ICV TLV, the TIMESTAMP TLV SHOULD be added to the packet before any ICV TLV, in order that it be included in the calculation of the ICV.
分组时间戳TLV是如第7节所述的时间戳TLV的示例。如果数据包包含时间戳TLV和ICV TLV，则时间戳TLV应在任何ICV TLV之前添加到数据包中，以便将其包括在ICV的计算中。
Two Message TLVs are defined: one for including the cryptographic ICV of a message and one for including the timestamp indicating the time at which the cryptographic ICV was calculated.
定义了两个消息TLV：一个用于包含消息的加密ICV，另一个用于包含指示加密ICV计算时间的时间戳。
A Message ICV TLV is an example of an ICV TLV as described in Section 6. When determining the <ICV-value> for a message, the following considerations MUST be applied:
信息ICV TLV是第6节所述ICV TLV的一个示例。确定消息的<ICV值>时，必须考虑以下因素：
o The fields <msg-hop-limit> and <msg-hop-count>, if present, MUST both be assumed to have the value 0 (zero) when calculating the ICV.
o 计算ICV时，必须假定字段<msg hop limit>和<msg hop count>的值均为0（零）。
o Any Message ICV TLVs already present in the Message TLV block MUST be removed before calculating the ICV, and the message size as well as the Message TLV block size MUST be recalculated accordingly. Removed ICV TLVs MUST be restored after having calculated the ICV value.
o 在计算ICV之前，必须删除消息TLV块中已经存在的任何消息ICV TLV，并且必须相应地重新计算消息大小以及消息TLV块大小。计算ICV值后，必须恢复移除的ICV TLV。
The rationale for removing any Message ICV TLV already present prior to calculating the ICV is that several ICVs may be added to the same message, e.g., using different ICV functions.
在计算ICV之前删除已存在的任何信息ICV TLV的基本原理是，可以将多个ICV添加到同一信息中，例如，使用不同的ICV功能。
A Message TIMESTAMP TLV is an example of a Timestamp TLV as described in Section 7. If a message contains a TIMESTAMP TLV and an ICV TLV, the TIMESTAMP TLV SHOULD be added to the message before the ICV TLV, in order that it be included in the calculation of the ICV.
消息时间戳TLV是第7节中描述的时间戳TLV的示例。如果消息包含时间戳TLV和ICV TLV，则时间戳TLV应添加到ICV TLV之前的消息中，以便将其包括在ICV的计算中。
Two Address Block TLVs are defined: one for associating a cryptographic ICV to an address and one for including the timestamp indicating the time at which the cryptographic ICV was calculated.
定义了两个地址块TLV：一个用于将加密ICV关联到地址，另一个用于包含指示加密ICV计算时间的时间戳。
An Address Block ICV TLV is an example of an ICV TLV as described in Section 6. The ICV is calculated over the address, concatenated with any other values -- for example, any other Address Block TLV <value> fields -- associated with that address. A MANET routing protocol or MANET routing protocol extension using Address Block ICV TLVs MUST specify how to include any such concatenated attribute of the address
地址块ICV TLV是第6节中描述的ICV TLV的示例。ICV在地址上计算，并与任何其他值连接在一起——例如，与该地址关联的任何其他地址块TLV<value>字段。使用地址块ICV TLV的MANET路由协议或MANET路由协议扩展必须指定如何包含地址的任何此类连接属性
in the verification process of the ICV. When determining the <ICV-value> for an address, the following consideration MUST be applied:
在ICV的验证过程中。确定地址的<ICV值>时，必须考虑以下因素：
o If other TLV values are concatenated with the address for calculating the ICV, these TLVs MUST NOT be Address Block ICV TLVs already associated with the address.
o 如果其他TLV值与用于计算ICV的地址连接，则这些TLV不得是已与该地址关联的地址块ICV TLV。
The rationale for not concatenating the address with any ICV TLV values already associated with the address when calculating the ICV is that several ICVs may be added to the same address, e.g., using different ICV functions.
在计算ICV时，不将地址与已与地址关联的任何ICV TLV值连接的基本原理是，可以将多个ICV添加到同一地址，例如，使用不同的ICV功能。
An Address Block TIMESTAMP TLV is an example of a Timestamp TLV as described in Section 7. If both a TIMESTAMP TLV and an ICV TLV are associated with an address, the TIMESTAMP TLV <value> MUST be covered when calculating the value of the ICV to be contained in the ICV TLV value (i.e., concatenated with the associated address and any other values as described in Section 10.1).
地址块时间戳TLV是第7节中描述的时间戳TLV的示例。如果时间戳TLV和ICV TLV都与地址相关联，则在计算ICV TLV值中包含的ICV值（即，与相关地址和第10.1节所述的任何其他值连接）时，必须涵盖时间戳TLV<value>。
The basic ICV, represented by way of an ICV TLV with type extension = 0, is a simple bit-field containing the cryptographic ICV. This assumes that the mechanism stipulating how ICVs are calculated and verified is established outside of this specification, e.g., by way of administrative configuration or external out-of-band signaling. Thus, the <ICV-value>, when using type extension = 0, is
基本ICV由类型扩展为0的ICV TLV表示，是包含加密ICV的简单位字段。这假设规定如何计算和验证ICV的机制是在本规范之外建立的，例如，通过管理配置或外部带外信令。因此，当使用类型扩展=0时，<ICV值>
<ICV-value> := <ICV-data>
<ICV-value> := <ICV-data>
where
哪里
<ICV-data> is an unsigned integer field, of length <length>, which contains the cryptographic ICV.
<ICV data>是一个长度为<length>的无符号整数字段，其中包含加密ICV。
One common way of calculating an ICV is applying a cryptographic function over a hash value of the content. This decomposition is specified in this section, using a type extension = 1 in the ICV TLVs.
计算ICV的一种常见方法是对内容的哈希值应用加密函数。本节使用ICV TLV中的类型扩展=1指定了此分解。
The following data structure allows representation of a cryptographic ICV, including specification of the appropriate hash function and cryptographic function used for calculating the ICV:
以下数据结构允许表示加密ICV，包括指定用于计算ICV的适当哈希函数和加密函数：
<ICV-value> := <hash-function>
<cryptographic-function>
<key-id-length>
<key-id>
<ICV-data>
<ICV-value> := <hash-function>
<cryptographic-function>
<key-id-length>
<key-id>
<ICV-data>
where
哪里
<hash-function> is an 8-bit unsigned integer field specifying the hash function.
<hash function>是一个8位无符号整数字段，用于指定哈希函数。
<cryptographic-function> is an 8-bit unsigned integer field specifying the cryptographic function.
<cryptographic function>是一个8位无符号整数字段，用于指定加密函数。
<key-id-length> is an 8-bit unsigned integer field specifying the length of the <key-id> field in number of octets. The value 0x00 is reserved for using a pre-installed, shared key.
<key id length>是一个8位无符号整数字段，指定<key id>字段的长度（以八位字节为单位）。值0x00保留为使用预安装的共享密钥。
<key-id> is a field specifying the key identifier of the key that was used to calculate the ICV of the message, which allows unique identification of different keys with the same originator. It is the responsibility of each key originator to make sure that actively used keys that it issues have distinct key identifiers. If <key-id-length> equals 0x00, the <key-id> field is not contained in the TLV, and a pre-installed, shared key is used.
<key id>是一个字段，用于指定用于计算消息ICV的密钥的密钥标识符，该字段允许使用同一发起者对不同密钥进行唯一标识。每个密钥发起人都有责任确保其发出的主动使用的密钥具有不同的密钥标识符。如果<key id length>等于0x00，则TLV中不包含<key id>字段，并使用预安装的共享密钥。
<ICV-data> is an unsigned integer field, whose length is <length> - 3 - <key-id-length>, and which contains the cryptographic ICV.
<ICV data>是一个无符号整数字段，其长度为<length>-3-<key id length>，包含加密ICV。
The version of this TLV, specified in this section, assumes that calculating the ICV can be decomposed into
本节规定的TLV版本假设计算ICV可以分解为
ICV-value = cryptographic-function(hash-function(content))
ICV-value = cryptographic-function(hash-function(content))
The hash function and the cryptographic function correspond to the entries in two IANA registries, which are set up by this specification and are described in Section 13.
哈希函数和加密函数对应于两个IANA注册中心中的条目，这两个注册中心由本规范设置，并在第13节中描述。
The rationale for separating the hash function and the cryptographic function into two octets instead of having all combinations in a single octet -- possibly as a TLV type extension -- is that adding further hash functions or cryptographic functions in the future may lead to a non-contiguous number space.
将哈希函数和加密函数分成两个八位字节，而不是将所有组合都放在一个八位字节中（可能是TLV类型的扩展）的基本原理是，将来添加更多的哈希函数或加密函数可能会导致非连续的数字空间。
The rationale for not including a field that lists parameters of the cryptographic ICV in the TLV is that, before being able to validate a cryptographic ICV, routers have to exchange or acquire keys (e.g., public keys). Any additional parameters can be provided together with the keys in that bootstrap process. It is therefore not necessary, and would even entail an extra overhead, to transmit the parameters within every message. One implicitly available parameter is the length of the ICV, which is <length> - 3 - <key-id-length>, and which depends on the choice of the cryptographic function.
在TLV中不包括列出加密ICV参数的字段的理由是，在能够验证加密ICV之前，路由器必须交换或获取密钥（例如，公钥）。在引导过程中，任何附加参数都可以与密钥一起提供。因此，在每条消息中传输参数是不必要的，甚至会带来额外的开销。一个隐式可用的参数是ICV的长度，它是<length>-3-<key id length>，取决于加密函数的选择。
The considerations listed in the following subsections MUST be applied when calculating the ICV for Packet, Message, and Address ICV TLVs, respectively.
在分别计算数据包、消息和地址ICV TLV的ICV时，必须应用以下小节中列出的注意事项。
When determining the <ICV-value> for a packet, the ICV is calculated over the fields <hash-function>, <cryptographic-function>, <key-id-length>, and -- if present -- <key-id> (in that order), concatenated with the entire packet, including the packet header, all Packet TLVs (other than Packet ICV TLVs), and all included Messages and their message headers, in accordance with Section 8.1.
当确定数据包的<ICV值>时，ICV通过字段<hash function>、<cryptographic function>、<key id length>，以及（如果存在）与整个数据包（包括数据包头、所有数据包TLV（数据包ICV TLV除外））连接而计算，以及所有包含的消息及其消息头，符合第8.1节。
When determining the <ICV-value> for a message, the ICV is calculated over the fields <hash-function>, <cryptographic-function>, <key-id-length>, and -- if present -- <key-id> (in that order), concatenated with the entire message. The considerations in Section 9.1 MUST be applied.
当确定消息的<ICV值>时，ICV通过字段<hash function>、<cryptographic function>、<key id length>，以及（如果存在）与整个消息连接的<key id>（按该顺序）进行计算。必须应用第9.1节中的注意事项。
When determining the <ICV-value> for an address, the ICV is
calculated over the fields <hash-function>, <cryptographic-function>,
<key-id-length>, and -- if present -- <key-id> (in that order),
concatenated with the address, and concatenated with any other values
-- for example, any other address block TLV <value> that is
When determining the <ICV-value> for an address, the ICV is
calculated over the fields <hash-function>, <cryptographic-function>,
<key-id-length>, and -- if present -- <key-id> (in that order),
concatenated with the address, and concatenated with any other values
-- for example, any other address block TLV <value> that is
associated with that address. A MANET routing protocol or MANET routing protocol extension using Address Block ICV TLVs MUST specify how to include any such concatenated attribute of the address in the verification process of the ICV. The considerations in Section 10.1 MUST be applied.
与该地址关联。使用地址块ICV TLV的MANET路由协议或MANET路由协议扩展必须指定如何在ICV的验证过程中包括地址的任何此类连接属性。必须应用第10.1节中的注意事项。
The sample message depicted in Figure 1 is derived from Appendix D of [RFC5444]. The message contains an ICV Message TLV, with the value representing an ICV that is 16 octets long of the whole message, and a key identifier that is 4 octets long. The type extension of the Message TLV is 1, for the specific decomposition of an ICV into a cryptographic function over a hash value, as specified in Section 12.
图1所示的示例消息源自[RFC5444]的附录D。该消息包含ICV消息TLV，其值表示整个消息中16个八位字节长的ICV，以及4个八位字节长的密钥标识符。消息TLV的类型扩展为1，用于将ICV具体分解为散列值上的加密函数，如第12节所述。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PV=0 | PF=8 | Packet Sequence Number | Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MF=15 | MAL=3 | Message Length = 44 | Msg. Orig Addr|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Originator Address (cont) | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | Message Sequence Number | Msg. TLV Block|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length = 27 | ICV | MTLVF = 144 | MTLVExt = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Value Len = 23 | Hash Func | Crypto Func |Key ID length=4|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICV Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICV Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICV Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICV Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PV=0 | PF=8 | Packet Sequence Number | Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MF=15 | MAL=3 | Message Length = 44 | Msg. Orig Addr|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Originator Address (cont) | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | Message Sequence Number | Msg. TLV Block|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length = 27 | ICV | MTLVF = 144 | MTLVExt = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Value Len = 23 | Hash Func | Crypto Func |Key ID length=4|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICV Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICV Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICV Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICV Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Example Message with ICV
图1：带有ICV的示例消息
This specification defines the following:
本规范规定了以下内容：
o Two Packet TLV types, which have been allocated from the 0-223 range of the "Packet TLV Types" repository of [RFC5444], as specified in Table 1.
o 两种数据包TLV类型，从[RFC5444]的“数据包TLV类型”存储库的0-223范围内分配，如表1所示。
o Two Message TLV types, which have been allocated from the 0-127 range of the "Message TLV Types" repository of [RFC5444], as specified in Table 2.
o 两种消息TLV类型，从[RFC5444]的“消息TLV类型”存储库的0-127范围内分配，如表2所示。
o Two Address Block TLV types, which have been allocated from the 0-127 range of the "Address Block TLV Types" repository of [RFC5444], as specified in Table 3.
o 两种地址块TLV类型，从[RFC5444]的“地址块TLV类型”存储库的0-127范围内分配，如表3所示。
This specification created the following:
本规范创建了以下内容：
o A type extension registry for each of these TLV types with initial values as listed in Tables 1, 2, and 3.
o 每个TLV类型的类型扩展注册表，初始值如表1、2和3所示。
IANA has assigned the same numerical value to the Packet TLV, Message TLV, and Address Block TLV types with the same name.
IANA为具有相同名称的数据包TLV、消息TLV和地址块TLV类型分配了相同的数值。
The following terms are used as defined in [BCP26]: "Namespace", "Registration", and "Designated Expert".
以下术语按照[BCP26]中的定义使用：“名称空间”、“注册”和“指定专家”。
The following policy is used as defined in [BCP26]: "Expert Review".
按照[BCP26]中的定义使用以下政策：“专家评审”。
For TLV type extensions registries where an Expert Review is required, the Designated Expert SHOULD take the same general recommendations into consideration as those specified by [RFC5444].
对于需要专家审查的TLV类型扩展登记处，指定专家应考虑与[RFC5444]规定的一般建议相同的一般建议。
For the Timestamp TLV, the same type extensions for all Packet, Message, and Address Block TLVs SHOULD be numbered identically.
对于时间戳TLV，所有数据包、消息和地址块TLV的相同类型扩展都应该相同地编号。
IANA has made allocations from the "Packet TLV Types" namespace of [RFC5444] for the Packet TLVs specified in Table 1.
IANA已从[RFC5444]的“数据包TLV类型”命名空间为表1中指定的数据包TLV进行分配。
+-----------+------+-----------+------------------------------------+
| Name | Type | Type | Description |
| | | Extension | |
+-----------+------+-----------+------------------------------------+
| ICV | 5 | 0 | ICV of a packet |
| | | | |
| | | 1 | ICV, decomposed into cryptographic |
| | | | function over a hash value, as |
| | | | specified in Section 12 of this |
| | | | document |
| | | | |
| | | 2-251 | Unassigned; Expert Review |
| | | | |
| | | 252-255 | Experimental Use |
| | | | |
| TIMESTAMP | 6 | 0 | Unsigned timestamp of arbitrary |
| | | | length, given by the TLV Length |
| | | | field. The MANET routing protocol |
| | | | has to define how to interpret |
| | | | this timestamp |
| | | | |
| | | 1 | Unsigned 32-bit timestamp, as |
| | | | specified in [IEEE 1003.1-2008 |
| | | | (POSIX)] |
| | | | |
| | | 2 | NTP timestamp format, as defined |
| | | | in [RFC5905] |
| | | | |
| | | 3 | Signed timestamp of arbitrary |
| | | | length with no constraints such as |
| | | | monotonicity. In particular, it |
| | | | may represent any random value |
| | | | |
| | | 4-251 | Unassigned; Expert Review |
| | | | |
| | | 252-255 | Experimental Use |
+-----------+------+-----------+------------------------------------+
+-----------+------+-----------+------------------------------------+
| Name | Type | Type | Description |
| | | Extension | |
+-----------+------+-----------+------------------------------------+
| ICV | 5 | 0 | ICV of a packet |
| | | | |
| | | 1 | ICV, decomposed into cryptographic |
| | | | function over a hash value, as |
| | | | specified in Section 12 of this |
| | | | document |
| | | | |
| | | 2-251 | Unassigned; Expert Review |
| | | | |
| | | 252-255 | Experimental Use |
| | | | |
| TIMESTAMP | 6 | 0 | Unsigned timestamp of arbitrary |
| | | | length, given by the TLV Length |
| | | | field. The MANET routing protocol |
| | | | has to define how to interpret |
| | | | this timestamp |
| | | | |
| | | 1 | Unsigned 32-bit timestamp, as |
| | | | specified in [IEEE 1003.1-2008 |
| | | | (POSIX)] |
| | | | |
| | | 2 | NTP timestamp format, as defined |
| | | | in [RFC5905] |
| | | | |
| | | 3 | Signed timestamp of arbitrary |
| | | | length with no constraints such as |
| | | | monotonicity. In particular, it |
| | | | may represent any random value |
| | | | |
| | | 4-251 | Unassigned; Expert Review |
| | | | |
| | | 252-255 | Experimental Use |
+-----------+------+-----------+------------------------------------+
Table 1: Packet TLV Types
表1：数据包TLV类型
IANA has made allocations from the "Message TLV Types" namespace of [RFC5444] for the Message TLVs specified in Table 2.
IANA已从[RFC5444]的“消息TLV类型”命名空间为表2中指定的消息TLV进行分配。
+-----------+------+-----------+------------------------------------+
| Name | Type | Type | Description |
| | | Extension | |
+-----------+------+-----------+------------------------------------+
| ICV | 5 | 0 | ICV of a message |
| | | | |
| | | 1 | ICV, decomposed into cryptographic |
| | | | function over a hash value, as |
| | | | specified in Section 12 of this |
| | | | document |
| | | | |
| | | 2-251 | Unassigned; Expert Review |
| | | | |
| | | 252-255 | Experimental Use |
| | | | |
| TIMESTAMP | 6 | 0 | Unsigned timestamp of arbitrary |
| | | | length, given by the TLV Length |
| | | | field |
| | | | |
| | | 1 | Unsigned 32-bit timestamp, as |
| | | | specified in [IEEE 1003.1-2008 |
| | | | (POSIX)] |
| | | | |
| | | 2 | NTP timestamp format, as defined |
| | | | in [RFC5905] |
| | | | |
| | | 3 | Signed timestamp of arbitrary |
| | | | length with no constraints such as |
| | | | monotonicity. In particular, it |
| | | | may represent any random value |
| | | | |
| | | 4-251 | Unassigned; Expert Review |
| | | | |
| | | 252-255 | Experimental Use |
+-----------+------+-----------+------------------------------------+
+-----------+------+-----------+------------------------------------+
| Name | Type | Type | Description |
| | | Extension | |
+-----------+------+-----------+------------------------------------+
| ICV | 5 | 0 | ICV of a message |
| | | | |
| | | 1 | ICV, decomposed into cryptographic |
| | | | function over a hash value, as |
| | | | specified in Section 12 of this |
| | | | document |
| | | | |
| | | 2-251 | Unassigned; Expert Review |
| | | | |
| | | 252-255 | Experimental Use |
| | | | |
| TIMESTAMP | 6 | 0 | Unsigned timestamp of arbitrary |
| | | | length, given by the TLV Length |
| | | | field |
| | | | |
| | | 1 | Unsigned 32-bit timestamp, as |
| | | | specified in [IEEE 1003.1-2008 |
| | | | (POSIX)] |
| | | | |
| | | 2 | NTP timestamp format, as defined |
| | | | in [RFC5905] |
| | | | |
| | | 3 | Signed timestamp of arbitrary |
| | | | length with no constraints such as |
| | | | monotonicity. In particular, it |
| | | | may represent any random value |
| | | | |
| | | 4-251 | Unassigned; Expert Review |
| | | | |
| | | 252-255 | Experimental Use |
+-----------+------+-----------+------------------------------------+
Table 2: Message TLV Types
表2：消息TLV类型
IANA has made allocations from the "Address Block TLV Types" namespace of [RFC5444] for the Packet TLVs specified in Table 3.
IANA已从[RFC5444]的“地址块TLV类型”命名空间为表3中指定的数据包TLV进行分配。
+-----------+------+-----------+------------------------------------+
| Name | Type | Type | Description |
| | | Extension | |
+-----------+------+-----------+------------------------------------+
| ICV | 5 | 0 | ICV of an object (e.g., an |
| | | | address) |
| | | | |
| | | 1 | ICV, decomposed into cryptographic |
| | | | function over a hash value, as |
| | | | specified in Section 12 of this |
| | | | document |
| | | | |
| | | 2-251 | Unassigned; Expert Review |
| | | | |
| | | 252-255 | Experimental Use |
| | | | |
| TIMESTAMP | 6 | 0 | Unsigned timestamp of arbitrary |
| | | | length, given by the TLV Length |
| | | | field |
| | | | |
| | | 1 | Unsigned 32-bit timestamp, as |
| | | | specified in [IEEE 1003.1-2008 |
| | | | (POSIX)] |
| | | | |
| | | 2 | NTP timestamp format, as defined |
| | | | in [RFC5905] |
| | | | |
| | | 3 | Signed timestamp of arbitrary |
| | | | length with no constraints such as |
| | | | monotonicity. In particular, it |
| | | | may represent any random value |
| | | | |
| | | 4-251 | Unassigned; Expert Review |
| | | | |
| | | 252-255 | Experimental Use |
+-----------+------+-----------+------------------------------------+
+-----------+------+-----------+------------------------------------+
| Name | Type | Type | Description |
| | | Extension | |
+-----------+------+-----------+------------------------------------+
| ICV | 5 | 0 | ICV of an object (e.g., an |
| | | | address) |
| | | | |
| | | 1 | ICV, decomposed into cryptographic |
| | | | function over a hash value, as |
| | | | specified in Section 12 of this |
| | | | document |
| | | | |
| | | 2-251 | Unassigned; Expert Review |
| | | | |
| | | 252-255 | Experimental Use |
| | | | |
| TIMESTAMP | 6 | 0 | Unsigned timestamp of arbitrary |
| | | | length, given by the TLV Length |
| | | | field |
| | | | |
| | | 1 | Unsigned 32-bit timestamp, as |
| | | | specified in [IEEE 1003.1-2008 |
| | | | (POSIX)] |
| | | | |
| | | 2 | NTP timestamp format, as defined |
| | | | in [RFC5905] |
| | | | |
| | | 3 | Signed timestamp of arbitrary |
| | | | length with no constraints such as |
| | | | monotonicity. In particular, it |
| | | | may represent any random value |
| | | | |
| | | 4-251 | Unassigned; Expert Review |
| | | | |
| | | 252-255 | Experimental Use |
+-----------+------+-----------+------------------------------------+
Table 3: Address Block TLV Types
表3：地址块TLV类型
IANA has created a new registry for hash functions that can be used when creating an ICV, as specified in Section 12 of this document. The initial assignments and allocation policies are specified in Table 4.
IANA为哈希函数创建了一个新的注册表，可在创建ICV时使用，如本文件第12节所述。表4规定了初始分配和分配策略。
+-------------+-----------+-----------------------------------------+
| Hash | Algorithm | Description |
| Function | | |
| Value | | |
+-------------+-----------+-----------------------------------------+
| 0 | none | The "identity function": The hash value |
| | | of an object is the object itself |
| | | |
| 1 | SHA1 | [NIST-FIPS-180-2] |
| | | |
| 2 | SHA224 | [NIST-FIPS-180-2-change] |
| | | |
| 3 | SHA256 | [NIST-FIPS-180-2] |
| | | |
| 4 | SHA384 | [NIST-FIPS-180-2] |
| | | |
| 5 | SHA512 | [NIST-FIPS-180-2] |
| | | |
| 6-251 | | Unassigned; Expert Review |
| | | |
| 252-255 | | Experimental Use |
+-------------+-----------+-----------------------------------------+
+-------------+-----------+-----------------------------------------+
| Hash | Algorithm | Description |
| Function | | |
| Value | | |
+-------------+-----------+-----------------------------------------+
| 0 | none | The "identity function": The hash value |
| | | of an object is the object itself |
| | | |
| 1 | SHA1 | [NIST-FIPS-180-2] |
| | | |
| 2 | SHA224 | [NIST-FIPS-180-2-change] |
| | | |
| 3 | SHA256 | [NIST-FIPS-180-2] |
| | | |
| 4 | SHA384 | [NIST-FIPS-180-2] |
| | | |
| 5 | SHA512 | [NIST-FIPS-180-2] |
| | | |
| 6-251 | | Unassigned; Expert Review |
| | | |
| 252-255 | | Experimental Use |
+-------------+-----------+-----------------------------------------+
Table 4: Hash-Function Registry
表4：哈希函数注册表
IANA has created a new registry for the cryptographic functions, as specified in Section 12 of this document. Initial assignments and allocation policies are specified in Table 5.
IANA已为加密功能创建了一个新的注册表，如本文件第12节所述。表5规定了初始分配和分配策略。
+----------------+-----------+--------------------------------------+
| Cryptographic | Algorithm | Description |
| Function Value | | |
+----------------+-----------+--------------------------------------+
| 0 | none | The "identity function": The value |
| | | of an encrypted hash is the hash |
| | | itself |
| | | |
| 1 | RSA | [RFC3447] |
| | | |
| 2 | DSA | [NIST-FIPS-186-3] |
| | | |
| 3 | HMAC | [RFC2104] |
| | | |
| 4 | 3DES | [NIST-SP-800-67] |
| | | |
| 5 | AES | [NIST-FIPS-197] |
| | | |
| 6 | ECDSA | [ANSI-X9-62-2005] |
| | | |
| 7-251 | | Unassigned; Expert Review |
| | | |
| 252-255 | | Experimental Use |
+----------------+-----------+--------------------------------------+
+----------------+-----------+--------------------------------------+
| Cryptographic | Algorithm | Description |
| Function Value | | |
+----------------+-----------+--------------------------------------+
| 0 | none | The "identity function": The value |
| | | of an encrypted hash is the hash |
| | | itself |
| | | |
| 1 | RSA | [RFC3447] |
| | | |
| 2 | DSA | [NIST-FIPS-186-3] |
| | | |
| 3 | HMAC | [RFC2104] |
| | | |
| 4 | 3DES | [NIST-SP-800-67] |
| | | |
| 5 | AES | [NIST-FIPS-197] |
| | | |
| 6 | ECDSA | [ANSI-X9-62-2005] |
| | | |
| 7-251 | | Unassigned; Expert Review |
| | | |
| 252-255 | | Experimental Use |
+----------------+-----------+--------------------------------------+
Table 5: Cryptographic Function Registry
表5：加密函数注册表
This document does not specify a protocol. It provides a syntactical component for cryptographic ICVs of messages and packets, as defined in [RFC5444]. It can be used to address security issues of a MANET routing protocol or MANET routing protocol extension. As such, it has the same security considerations as [RFC5444].
本文档未指定协议。它为[RFC5444]中定义的消息和数据包的加密ICV提供了一个语法组件。它可以用来解决MANET路由协议或MANET路由协议扩展的安全问题。因此，它具有与[RFC5444]相同的安全考虑因素。
In addition, a MANET routing protocol or MANET routing protocol extension that uses this specification MUST specify how to use the framework, and the TLVs presented in this document. In addition, the protection that the MANET routing protocol or MANET routing protocol extensions attain by using this framework MUST be described.
此外，使用此规范的MANET路由协议或MANET路由协议扩展必须指定如何使用该框架，以及本文档中介绍的TLV。此外，还必须描述MANET路由协议或MANET路由协议扩展通过使用该框架实现的保护。
As an example, a MANET routing protocol that uses this component to reject "badly formed" or "insecure" messages if a control message does not contain a valid ICV SHOULD indicate the security assumption that if the ICV is valid, the message is considered valid. It also SHOULD indicate the security issues that are counteracted by this measure (e.g., link or identity spoofing) as well as the issues that are not counteracted (e.g., compromised keys).
例如，如果控制消息不包含有效的ICV，则使用此组件拒绝“格式错误”或“不安全”消息的MANET路由协议应指示安全性假设，即如果ICV有效，则消息被视为有效。它还应指出该措施所抵消的安全问题（如链接或身份欺骗）以及未抵消的问题（如泄露的密钥）。
The authors would like to thank Bo Berry (Cisco), Alan Cullen (BAE), Justin Dean (NRL), Christopher Dearlove (BAE), Paul Lambert (Marvell), Jerome Milan (Ecole Polytechnique), and Henning Rogge (FGAN) for their constructive comments on the document.
作者要感谢Bo Berry（Cisco）、Alan Cullen（BAE）、Justin Dean（NRL）、Christopher Dearlove（BAE）、Paul Lambert（Marvell）、Jerome Milan（Ecole Polytechnique）和Henning Rogge（FGAN）对该文件的建设性评论。
The authors also appreciate the detailed reviews from the Area Directors, in particular Stewart Bryant (Cisco), Stephen Farrell (Trinity College Dublin), and Robert Sparks (Tekelec), as well as Donald Eastlake (Huawei) from the Security Directorate.
作者还感谢区域主管的详细审查，特别是斯图尔特·布莱恩特（Cisco）、斯蒂芬·法雷尔（都柏林三一学院）、罗伯特·斯帕克斯（Tekelec）以及安全董事会的唐纳德·伊斯特莱克（华为）。
[ANSI-X9-62-2005] American National Standards Institute, "Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI X9.62-2005, November 2005.
[ANSI-X9-62-2005]美国国家标准协会，“金融服务业的公钥加密：椭圆曲线数字签名算法（ECDSA）”，ANSI X9.62-2005，2005年11月。
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[BCP26]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[IEEE 1003.1-2008 (POSIX)] IEEE Computer Society, "1003.1-2008 Standard for Information Technology-Portable Operating System Interface (POSIX) Base Specifications, Issue 7", December 2008.
[IEEE 1003.1-2008（POSIX）]IEEE计算机协会，“1003.1-2008信息技术标准便携式操作系统接口（POSIX）基本规范，第7期”，2008年12月。
[NIST-FIPS-180-2] National Institute of Standards and Technology, "Specifications for the Secure Hash Standard", FIPS 180-2, August 2002.
[NIST-FIPS-180-2]国家标准与技术研究所，“安全哈希标准规范”，FIPS 180-22002年8月。
[NIST-FIPS-180-2-change] National Institute of Standards and Technology, "Federal Information Processing Standards Publication 180-2 (+ Change Notice to include SHA-224)", FIPS 180-2, August 2002, <http:// csrc.nist.gov/publications/fips/ fips180-2/fips180-2withchangenotice.pdf>.
[NIST-FIPS-180-2-change]国家标准与技术研究所，“联邦信息处理标准出版物180-2（+包括SHA-224的变更通知）”，FIPS 180-2，2002年8月，<http://csrc.NIST.gov/publications/FIPS/fips180-2/fips180-2withchangenotice.pdf>。
[NIST-FIPS-186-3] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS 186-3, June 2009.
[NIST-FIPS-186-3]国家标准与技术研究所，“数字签名标准（DSS）”，FIPS 186-3，2009年6月。
[NIST-FIPS-197] National Institute of Standards and Technology, "Specification for the Advanced Encryption Standard (AES)", FIPS 197, November 2001.
[NIST-FIPS-197]国家标准与技术研究所，“高级加密标准（AES）规范”，FIPS 197，2001年11月。
[NIST-SP-800-67] National Institute of Standards and Technology, "Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher", Special Publication 800-67, May 2004.
[NIST-SP-800-67]国家标准与技术研究所，“三重数据加密算法（TDEA）分组密码建议”，特别出版物800-67，2004年5月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[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月。
[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月。
[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月。
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC5905]Mills，D.，Martin，J.，Ed.，Burbank，J.，和W.Kasch，“网络时间协议版本4：协议和算法规范”，RFC 59052010年6月。
[OLSRv2] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, "The Optimized Link State Routing Protocol version 2", Work in Progress, March 2012.
[OLSRv2]Clausen，T.，Dearlove，C.，Jacquet，P.，和U.Herberg，“优化链路状态路由协议版本2”，正在进行的工作，2012年3月。
[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月。
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/
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/