[要約] RFC 6622は、モバイルアドホックネットワーク（MANETs）におけるIntegrity Check Value（ICV）とTimestamp TLVの定義に関するものです。このRFCの目的は、MANETsにおけるデータの整合性とタイムスタンプの保護を向上させるための仕組みを提供することです。
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.
このドキュメントでは、暗号化された整合性チェック値（ICV）（つまり、デジタル署名またはメッセージ認証コード（MAC））とタイムスタンプを表すための一般的で柔軟なTLVについて、一般的なモバイルアドホックネットワーク（MANET）パケット/メッセージ形式を使用して説明しています。 RFC5444。ICVとタイムスタンプをパケット、メッセージ、アドレスにそれぞれ付加するために、2つのパケットTLV、2つのメッセージTLV、2つのアドレスブロックTLVを定義しています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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 [RFC5444]で定義されているように、パケット、メッセージ、およびアドレスブロックで整合性チェック値（ICV）とタイムスタンプを伝達するための2つのTLV。
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.
このドキュメントでは、ハッシュ関数とICV計算のコードポイントをそれぞれ記録するためのIANAレジストリを設定します。
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を生成する一般的な方法の1つ。
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].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[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>は、[RFC5444]のセクション5.4.1で指定されている、オクテット単位のTLVの長さです。
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.
[RFC5444]で定義されたフォーマットを使用するMANETルーティングプロトコルには、TLVを含めることにより、制御メッセージおよびパケットで追加情報を伝送する機能が付与されています。そのように含まれている情報は、その仕様に従って、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>フィールドを処理する方法についても規定しています。受信者によって正しく検証されていること、および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ルーティングプロトコルの仕様は、多くの場合「セキュリティに気付かない」ものです。ただし、メッセージが処理または転送される前に、制御メッセージを「不正な形式」または「安全でない」として拒否することを許可する句があります。 Neighborhood Discovery Protocol（NHDP）[RFC6130]やOptimized Link State Routing Protocol version 2 [OLSRv2]などのMANETルーティングプロトコルは、「ICVの検証に失敗した」などの外部の理由を認識します。処理"。このアーキテクチャは、MANETのセキュリティに関して、「1つのサイズですべてに適合することはめったにありません」、そしてMANETルーティングプロトコルのデプロイメントドメインには、「壊れない」から「ほぼなし」までのさまざまなセキュリティ要件があるという観察の結果です。このアプローチの利点は、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]に準拠するハッシュ関数と暗号化関数のコードポイントに対して2つの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タイプを割り当てます。これらのレジストリーの1つからTLVタイプが割り当てられると、そのTLVタイプのタイプ拡張のレジストリーがIANAによって作成されます。このドキュメントでは、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>
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>は、<length>オクテットのフィールドであり、タイプ拡張で指定された、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を参照してください。このドキュメントでは、このような2つのタイプ拡張を指定しています。1つは事前定義された構造のないICV用で、もう1つはハッシュ値に対する暗号化操作によって構築されたICV用です。
The value of the Timestamp TLV is
タイムスタンプTLVの値は
<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.
これは、<time-value>の計算方法やその内部構造（存在する場合）を規定しないことに注意してください。このような情報は、TIMESTAMP 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.
2つのパケットTLVが定義されています。1つはパケットの暗号化ICVを含めるため、もう1つは暗号化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 パケットTLVブロックにすでに存在するパケットICV TLVは、ICVを計算する前に削除する必要があり、それに応じてパケットTLVブロックサイズを再計算する必要があります。削除されたICV TLVは、ICV値を計算した後に復元する必要があります。
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.
パケットのTIMESTAMP TLVは、セクション7で説明されているタイムスタンプTLVの例です。パケットにTIMESTAMP TLVとICV TLVが含まれている場合、ICV TLVを含める前に、TIMESTAMP 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.
2つのメッセージTLVが定義されています。1つはメッセージの暗号化ICVを含めるため、もう1つは暗号化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-value>を決定するときは、次の考慮事項を適用する必要があります。
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 フィールド<msg-hop-limit>および<msg-hop-count>（存在する場合）は、ICVを計算するときに両方の値が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 メッセージTLVブロックにすでに存在するメッセージICV TLVは、ICVを計算する前に削除する必要があり、メッセージサイズとメッセージTLVブロックサイズをそれに応じて再計算する必要があります。削除されたICV TLVは、ICV値を計算した後に復元する必要があります。
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.
メッセージのTIMESTAMP TLVは、セクション7で説明されているタイムスタンプTLVの例です。メッセージにTIMESTAMP TLVとICV TLVが含まれている場合、メッセージにICV TLVを追加する前に、TIMESTAMP TLVをメッセージに追加する必要があります（SHOULD）。 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.
2つのアドレスブロックTLVが定義されています。1つは暗号ICVをアドレスに関連付けるため、もう1つは暗号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 in the verification process of the ICV. When determining the <ICV-value> for an address, the following consideration MUST be applied:
アドレスブロックICV TLVは、セクション6で説明したICV TLVの例です。ICVは、アドレスに基づいて計算され、他の値（たとえば、他のアドレスブロックTLV <値>フィールド）と連結されます。住所。アドレスブロックICV TLVを使用するMANETルーティングプロトコルまたはMANETルーティングプロトコル拡張は、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 ICVを計算するために他のTLV値がアドレスと連結されている場合、これらの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).
アドレスブロックTIMESTAMP TLVは、セクション7で説明されているタイムスタンプTLVの例です。TIMESTAMPTLVとICV TLVの両方がアドレスに関連付けられている場合、ICVの値を計算するときにTIMESTAMP TLV <値>をカバーする必要があります。 ICV TLV値に含まれている（つまり、関連するアドレスと、セクション10.1で説明されている他の値と連結されている）。
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
タイプ拡張= 0のICV TLVで表される基本ICVは、暗号化ICVを含む単純なビットフィールドです。これは、ICVの計算と検証の方法を規定するメカニズムが、たとえば管理構成や外部の帯域外シグナリングによって、この仕様の外で確立されることを前提としています。したがって、タイプ拡張= 0を使用する場合、<ICV-value>は
<ICV-value> := <ICV-data>
where
ただし
<ICV-data> is an unsigned integer field, of length <length>, which contains the cryptographic ICV.
<ICV-data>は、暗号化ICVを含む、長さが<length>の符号なし整数フィールドです。
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を計算する一般的な方法の1つは、コンテンツのハッシュ値に暗号関数を適用することです。この分解は、このセクションで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>
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の場合、<key-id>フィールドはTLVに含まれず、事前にインストールされた共有キーが使用されます。
<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))
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.
ハッシュ関数と暗号化関数は、この仕様で設定され、セクション13で説明されている2つのIANAレジストリのエントリに対応しています。
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.
単一のオクテットにすべての組み合わせを含めるのではなく、ハッシュ関数と暗号化関数を2つのオクテットに分離する理由（おそらく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.
暗号化ICVのパラメーターをリストするフィールドをTLVに含めない理由は、暗号化ICVを検証できるようになる前に、ルーターはキー（公開キーなど）を交換または取得する必要があるということです。追加のパラメータは、そのブートストラッププロセスのキーと一緒に提供できます。したがって、すべてのメッセージ内でパラメータを送信する必要はなく、追加のオーバーヘッドが必要になることさえあります。暗黙的に使用可能なパラメーターの1つは、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はフィールド<ハッシュ関数>、<暗号関数>、<キーIDの長さ>、および-存在する場合-<キーID >（この順序で）、セクション8.1に従って、パケットヘッダー、すべてのパケットTLV（パケットICV TLVを除く）、および含まれるすべてのメッセージとそのメッセージヘッダーを含む、パケット全体と連結されます。
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-value>を決定するとき、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 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-value>を決定するとき、ICVはフィールド<hash-function>、<cryptographic-function>、<key-id-length>、および-存在する場合-<key-id >（その順序で）、アドレスと連結され、他の値と連結されます-たとえば、そのアドレスに関連付けられている他のアドレスブロックTLV <値>。アドレスブロック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で、セクション12で指定されているように、ICVをハッシュ値で暗号化関数に特定に分解します。
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 [RFC5444]の「Packet TLV Types」リポジトリの0〜223の範囲から割り当てられた2つのパケットTLVタイプ。表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 [RFC5444]の「メッセージTLVタイプ」リポジトリの0〜127の範囲から割り当てられた2つのメッセージTLVタイプ。表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 [RFC5444]の「アドレスブロックTLVタイプ」リポジトリの0〜127の範囲から割り当てられた2つのアドレスブロックTLVタイプ。表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 表1、2、および3にリストされている初期値を持つこれらの各TLVタイプのタイプ拡張レジストリ。
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].
Expert Reviewが必要なTLVタイプ拡張レジストリの場合、Designated Expertは、[RFC5444]で指定されているものと同じ一般的な推奨事項を考慮に入れる必要があります（SHOULD）。
For the Timestamp TLV, the same type extensions for all Packet, Message, and Address Block TLVs SHOULD be numbered identically.
タイムスタンプTLVの場合、すべてのパケット、メッセージ、およびアドレスブロックTLVの同じタイプの拡張には、同じ番号を付ける必要があります（SHOULD）。
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 |
+-----------+------+-----------+------------------------------------+
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 |
+-----------+------+-----------+------------------------------------+
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 |
+-----------+------+-----------+------------------------------------+
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は、このドキュメントのセクション12で指定されているように、ICVの作成時に使用できるハッシュ関数用の新しいレジストリを作成しました。初期割り当てと割り当てポリシーを表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 |
+-------------+-----------+-----------------------------------------+
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 |
+----------------+-----------+--------------------------------------+
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が有効である場合、メッセージが有効であると見なされるというセキュリティの前提を示す必要があります。 。また、この対策によって打ち消されるセキュリティの問題（リンクやIDのなりすましなど）と、打ち消されない問題（キーの侵害など）を示す必要があります（SHOULD）。
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）、およびセキュリティ総局のドナルドイーストレイク（Huawei）による詳細なレビューにも感謝しています。
[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] American National Standards Institute、「金融サービス業界の公開鍵暗号化：楕円曲線デジタル署名アルゴリズム（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、「RFCで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 Computer Society、「1003.1-2008 Standard for Information Technology-Portable Operating System Interface（POSIX）Base Specifications、Issue 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]米国国立標準技術研究所、「Secure Hash Standardの仕様」、FIPS 180-2、2002年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]国立標準技術研究所、「Federal Information Processing Standards Publication 180-2（+ Change Notice to include 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]米国国立標準技術研究所、「Advanced Encryption Standard（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：Keyed-Hashing for Message Authentication」、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、「Public-Key Cryptography Standards（PKCS）＃1：RSA Cryptography Specifications Version 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、「Generalized Mobile Ad Hoc Network（MANET）Packet / Message Format」、RFC 5444、2009年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、「Network Time Protocol Version 4：Protocol and Algorithms Specification」、RFC 5905、2010年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、「The Optimized Link State Routing Protocol version 2」、Work in Progress、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、「Mobile Ad Hoc Network（MANET）Neighborhood Discovery Protocol（NHDP）」、RFC 6130、2011年4月。
Authors' Addresses
著者のアドレス
Ulrich Herberg Fujitsu Laboratories of America 1240 E. Arques Ave. Sunnyvale, CA 94085 USA
うｌりｃｈ へｒべｒｇ ふじつ ぁぼらとりえｓ おｆ あめりか １２４０ え。 あｒくえｓ あゔぇ。 すんｙゔぁぇ、 か ９４０８５ うさ
EMail: ulrich@herberg.name
URI: http://www.herberg.name/
Thomas Heide Clausen LIX, Ecole Polytechnique 91128 Palaiseau Cedex France
Thomas Heide Clausen LIX、Ecole Polytechnique 91128 Palaiseau Cedex France
Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org
URI: http://www.thomasclausen.org/