[要約] RFC 7183は、NHDPとOLSRv2の完全性保護に関するプロトコルです。その目的は、ネットワークの隣接関係の発見と経路選択のプロセスを保護し、攻撃や改ざんから保護することです。
Internet Engineering Task Force (IETF) U. Herberg
Request for Comments: 7183 Fujitsu Laboratories of America
Updates: 6130, 7181 C. Dearlove
Category: Standards Track BAE Systems ATC
ISSN: 2070-1721 T. Clausen
LIX, Ecole Polytechnique
April 2014
Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)
Neighborhood Discovery Protocol（NHDP）およびOptimized Link State Routing Protocol Version 2（OLSRv2）の整合性保護
Abstract
概要
This document specifies integrity and replay protection for the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) and the Optimized Link State Routing Protocol version 2 (OLSRv2). This protection is achieved by using an HMAC-SHA-256 Integrity Check Value (ICV) TLV and a Timestamp TLV based on Portable Operating System Interface (POSIX) time.
このドキュメントでは、モバイルアドホックネットワーク（MANET）近隣探索プロトコル（NHDP）および最適化リンク状態ルーティングプロトコルバージョン2（OLSRv2）の整合性と再生保護について説明します。この保護は、HMAC-SHA-256整合性チェック値（ICV）TLVと、ポータブルオペレーティングシステムインターフェイス（POSIX）時間に基づくタイムスタンプTLVを使用することで実現されます。
The mechanism in this specification can also be used for other protocols that use the generalized packet/message format described in RFC 5444.
この仕様のメカニズムは、RFC 5444で説明されている一般化されたパケット/メッセージ形式を使用する他のプロトコルにも使用できます。
This document updates RFC 6130 and RFC 7181 by mandating the implementation of this integrity and replay protection in NHDP and OLSRv2.
このドキュメントでは、NHDPおよびOLSRv2でのこの整合性とリプレイ保護の実装を義務付けることにより、RFC 6130とRFC 7181を更新しています。
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/rfc7183.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7183で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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 .....................................................4
3. Applicability Statement .........................................5
4. Protocol Overview and Functioning ...............................6
5. Parameters ......................................................7
6. Message Generation and Processing ...............................9
6.1. Message Content ............................................9
6.2. Message Generation ........................................10
6.3. Message Processing ........................................11
6.3.1. Validating a Message Based on Timestamp ............11
6.3.2. Validating a Message Based on Integrity Check ......12
7. Provisioning of Routers ........................................12
8. Security Considerations ........................................12
8.1. Mitigated Attacks .........................................13
8.1.1. Identity Spoofing ..................................13
8.1.2. Link Spoofing ......................................13
8.1.3. Replay Attack ......................................13
8.2. Limitations ...............................................13
9. Acknowledgments ................................................14
10. References ....................................................14
10.1. Normative References .....................................14
10.2. Informative References ...................................14
This specification updates [RFC6130] and [RFC7181] by defining mandatory-to-implement security mechanisms (for integrity and replay protection). A deployment of these protocols may choose to employ an alternative(s) to these mechanisms; in particular, it may choose to protect packets rather than messages, it may choose to use an alternative Integrity Check Value (ICV) with preferred properties, and/or it may use an alternative timestamp. A deployment may choose to use no such security mechanisms, but this is not recommended.
この仕様は、[整合性とリプレイ保護のための]実装が必須のセキュリティメカニズムを定義することにより、[RFC6130]と[RFC7181]を更新します。これらのプロトコルの展開では、これらのメカニズムの代替を採用することを選択できます。特に、メッセージではなくパケットを保護することを選択したり、優先プロパティで代替の整合性チェック値（ICV）を使用したり、代替のタイムスタンプを使用したりできます。デプロイメントでは、そのようなセキュリティメカニズムを使用しないことを選択できますが、これはお勧めできません。
The mechanisms specified are the use of an ICV for protection of the protocols' control messages and the use of timestamps in those messages to prevent replay attacks. Both use the TLV mechanism specified in [RFC5444] to add this information to the messages. These ICV and TIMESTAMP TLVs are defined in [RFC7182]. Different ICV TLVs are used for HELLO messages in NHDP and TC (Topology Control) messages in OLSRv2, the former also protecting the source address of the IP datagram that contains the HELLO message. This is because the IP datagram source address is used by NHDP to determine the address of a neighbor interface, and it is not necessarily otherwise contained in the HELLO message, while OLSRv2's TC message is forwarded in a new packet; thus, it has no single IP datagram source address.
指定されたメカニズムは、プロトコルの制御メッセージの保護のためのICVの使用と、リプレイアタックを防ぐためのそれらのメッセージのタイムスタンプの使用です。どちらも[RFC5444]で指定されたTLVメカニズムを使用して、この情報をメッセージに追加します。これらのICVおよびTIMESTAMP TLVは[RFC7182]で定義されています。 NHDPのHELLOメッセージとOLSRv2のTC（トポロジー制御）メッセージには、異なるICV TLVが使用されます。前者は、HELLOメッセージを含むIPデータグラムの送信元アドレスも保護します。これは、IPデータグラムの送信元アドレスがNHDPによって隣接インターフェイスのアドレスを決定するために使用され、OLSRv2のTCメッセージが新しいパケットで転送されている間、HELLOメッセージに必ずしも含まれていないためです。したがって、単一のIPデータグラムの送信元アドレスはありません。
The mechanism specified in this document is placed in the packet/ message processing flow as indicated in Figure 1. It exists between the packet parsing/generation function of [RFC5444] and the message processing/generation function of NHDP and OLSRv2.
このドキュメントで指定されたメカニズムは、図1に示すように、パケット/メッセージ処理フローに配置されます。これは、[RFC5444]のパケット解析/生成機能とNHDPおよびOLSRv2のメッセージ処理/生成機能の間に存在します。
| |
Incoming | /|\ Outgoing
packet \|/ | packet
| |
+--------------------------------+
| |
| RFC 5444 packet |
| parsing/generation |
| |
+--------------------------------+
| |
Messages | /|\ Messages with
\|/ | added TLVs
| |
D +--------------------------------+
R /__________________ | |
O \ Messages | Mechanism specified in |
P (failed check) | this document |
| |
+--------------------------------+
| |
Messages | /|\ Messages
(passed check) \|/ |
| |
+--------------------------------+
| |
| NHDP/OLSRv2 message |
| processing/generation |
| |
+--------------------------------+
Figure 1: Relationship with RFC 5444 and NHDP/OLSRv2
図1：RFC 5444およびNHDP / OLSRv2との関係
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
Additionally, this document uses the terminology and notation of [RFC5444], [RFC6130], [RFC7181], and [RFC7182].
さらに、このドキュメントでは、[RFC5444]、[RFC6130]、[RFC7181]、および[RFC7182]の用語と表記法を使用しています。
[RFC6130] and [RFC7181] enable specifications of extensions to recognize additional reasons for rejecting a message as "badly formed and therefore invalid for processing", and mention security (integrity protection) as an explicit example. This document specifies a mechanism that provides this functionality.
[RFC6130]と[RFC7181]を使用すると、拡張の仕様で、メッセージを拒否する追加の理由を「形式が正しくないため処理が無効である」と認識し、セキュリティ（整合性保護）を明示的な例として説明できます。このドキュメントでは、この機能を提供するメカニズムを指定します。
Implementations of [RFC6130] and [RFC7181] MUST include this mechanism, and deployments of [RFC6130] and [RFC7181] SHOULD use this mechanism, except when a different security mechanism is more appropriate.
[RFC6130]と[RFC7181]の実装にはこのメカニズムが含まれている必要があり、[RFC6130]と[RFC7181]の展開ではこのメカニズムを使用する必要があります（別のセキュリティメカニズムがより適切な場合を除く）。
The applicability of this mechanism is determined by its characteristics, which are that it:
このメカニズムの適用性は、次のような特性によって決まります。
o Specifies a security mechanism that is required to be included in conforming implementations of [RFC6130] and [RFC7181].
o [RFC6130]と[RFC7181]の適合実装に含める必要があるセキュリティメカニズムを指定します。
o Specifies an association of ICVs with protocol messages, and specifies how to use a missing or invalid ICV as a reason to reject a message as "badly formed and therefore invalid for processing".
o ICVとプロトコルメッセージの関連付けを指定し、欠落または無効なICVをメッセージの「形式が正しくないため処理が無効である」と拒否する理由として使用する方法を指定します。
o Specifies the implementation of an ICV Message TLV, defined in [RFC7182], using a SHA-256-based Hashed Message Authentication Code (HMAC) applied to the appropriate message contents (and for HELLO messages also including the IP datagram source address). Implementations of [RFC6130] and [RFC7181] MUST support an HMAC-SHA-256 ICV TLV, and deployments SHOULD use it except when use of a different algorithm is more appropriate. An implementation MAY use more than one ICV TLV in a message, as long as they each use a different algorithm or key to calculate the ICV.
o [RFC7182]で定義されているICVメッセージTLVの実装を指定し、適切なメッセージコンテンツに適用されたSHA-256ベースのハッシュメッセージ認証コード（HMAC）を使用します（IPデータグラムの送信元アドレスも含むHELLOメッセージの場合）。 [RFC6130]と[RFC7181]の実装はHMAC-SHA-256 ICV TLVをサポートしなければならず（MUST）、別のアルゴリズムの使用がより適切である場合を除いて、デプロイメントはそれを使用する必要があります。実装は、それぞれが異なるアルゴリズムまたはキーを使用してICVを計算する限り、メッセージ内で複数のICV TLVを使用できます（MAY）。
o Specifies the implementation of a TIMESTAMP Message TLV, defined in [RFC7182], to provide message replay protection. Implementations of [RFC6130] and [RFC7181] using this mechanism MUST support a timestamp based on POSIX time, and deployments SHOULD use it if the clocks in all routers in the network can be synchronized with sufficient precision.
o メッセージの再生保護を提供するために、[RFC7182]で定義されているTIMESTAMPメッセージTLVの実装を指定します。このメカニズムを使用する[RFC6130]と[RFC7181]の実装は、POSIX時間に基づくタイムスタンプをサポートしなければならず（MUST）、ネットワーク内のすべてのルーターのクロックが十分な精度で同期できる場合、デプロイメントはそれを使用する必要があります。
o Assumes that a router that is able to generate correct integrity check values is considered trusted.
o 正しい整合性チェック値を生成できるルーターは信頼できると見なされます。
This mechanism does not:
このメカニズムでは、次のことは行われません。
o Specify which key identifiers are to be used in a MANET in which the routers share more than one secret key. (Such keys will be differentiated using the <key-id> field defined in an ICV TLV in [RFC7182].)
o ルーターが複数の秘密鍵を共有するMANETで使用する鍵識別子を指定します。 （このようなキーは、[RFC7182]のICV TLVで定義された<key-id>フィールドを使用して区別されます。）
o Specify how to distribute cryptographic material (shared secret key(s)).
o 暗号素材の配布方法を指定します（共有秘密鍵）。
o Specify how to detect compromised routers with valid keys.
o 侵害されたルーターを有効なキーで検出する方法を指定します。
o Specify how to handle (revoke) compromised routers with valid keys.
o 侵害されたルーターを有効なキーで処理する（取り消す）方法を指定します。
The mechanism specified in this document provides the following functionalities for use with messages specified by [RFC6130] and [RFC7181]:
このドキュメントで指定されたメカニズムは、[RFC6130]と[RFC7181]で指定されたメッセージで使用する次の機能を提供します。
o Generation of ICV Message TLVs (as defined in [RFC7182]) for inclusion in an outgoing message. An implementation of [RFC6130] and [RFC7181] MAY use more than one ICV TLV in a message, even with the same type extension, but these ICV TLVs MUST each use different keys or they MUST use a different algorithm to calculate the ICV, e.g., with different hash and/or cryptographic functions when using type extension 1 or 2. An implementation of [RFC6130] and [RFC7181] MUST at least be able to generate an ICV TLV using HMAC-SHA-256 and one or more secret keys shared by all routers.
o 発信メッセージに含めるためのICVメッセージTLV（[RFC7182]で定義）の生成。 [RFC6130]と[RFC7181]の実装は、同じタイプの拡張であっても、メッセージで複数のICV TLVを使用できますが、これらのICV TLVはそれぞれ異なるキーを使用する必要があります。 、タイプ拡張1または2を使用する場合の異なるハッシュおよび/または暗号化機能。[RFC6130]と[RFC7181]の実装は、少なくともHMAC-SHA-256と1つ以上の共有秘密鍵を使用してICV TLVを生成できなければならないすべてのルーターによって。
o Generation of TIMESTAMP Message TLVs (as defined in [RFC7182]) for inclusion in an outgoing message. An implementation of [RFC6130] and [RFC7181] MAY use more than one ICV TLV in a message, but it MUST NOT use the same type extension. An implementation of [RFC6130] and [RFC7181] that is able to synchronize the clocks in all routers in the network with sufficient precision MUST at least be able to generate a TIMESTAMP TLV using POSIX time.
o 発信メッセージに含めるためのTIMESTAMPメッセージTLV（[RFC7182]で定義）の生成。 [RFC6130]と[RFC7181]の実装では、メッセージで複数のICV TLVを使用できますが、同じタイプの拡張を使用してはなりません（MUST NOT）。ネットワーク内のすべてのルーターのクロックを十分な精度で同期できる[RFC6130]と[RFC7181]の実装は、少なくともPOSIX時間を使用してTIMESTAMP TLVを生成できる必要があります。
o Verification of ICV Message TLVs contained in a message, in order to determine if this message MUST be rejected as "badly formed and therefore invalid for processing" [RFC6130] [RFC7181]. An implementation of [RFC6130] and [RFC7181] MUST at least be able to verify an ICV TLV using HMAC/SHA-256 and one or more secret keys shared by all routers.
o メッセージに含まれるICVメッセージTLVの検証。このメッセージを「形式が正しくないため、処理に無効」[RFC6130] [RFC7181]として拒否する必要があるかどうかを判断します。 [RFC6130]と[RFC7181]の実装は、HMAC / SHA-256とすべてのルーターで共有される1つ以上の秘密鍵を使用して、ICV TLVを検証できる必要があります。
o Verification of TIMESTAMP Message TLVs (as defined in [RFC7182]) contained in a message, in order to determine if this message MUST be rejected as "badly formed and therefore invalid for processing" [RFC6130] [RFC7181]. An implementation of [RFC6130] and [RFC7181] that is able to synchronize the clocks in all routers in the network with sufficient precision MUST at least be able to verify a TIMESTAMP TLV using POSIX time.
o メッセージに含まれるTIMESTAMPメッセージTLV（[RFC7182]で定義）の検証。このメッセージを「形式が正しくないため、処理に無効」[RFC6130] [RFC7181]として拒否する必要があるかどうかを判断します。ネットワーク内のすべてのルーターのクロックを十分な精度で同期できる[RFC6130]と[RFC7181]の実装は、少なくともPOSIX時間を使用してTIMESTAMP TLVを検証できる必要があります。
ICV Packet TLVs (as defined in [RFC7182]) MAY be used by a deployment of the multiplexing process defined in [RFC5444], either as well as or instead of the protection of the NHDP and OLSRv2 messages. (Note that in the case of NHDP, the packet protection is equally good, and also protects the packet header. In the case of OLSRv2, the packet protection has different properties than the message protection, especially for some forms of ICV. When packets contain more than one message, the packet protection has lower overheads in space and computation time.)
ICVパケットTLV（[RFC7182]で定義）は、[RFC5444]で定義された多重化プロセスの配備、およびNHDPおよびOLSRv2メッセージの保護の代わりに、またはその代わりに使用できます（MAY）。 （NHDPの場合、パケット保護は同等に良好であり、パケットヘッダーも保護することに注意してください。OLSRv2の場合、パケット保護には、特に一部の形式のICVの場合に、メッセージ保護とは異なるプロパティがあります。パケットに複数のメッセージの場合、パケット保護のスペースと計算時間のオーバーヘッドは低くなります。）
When a router generates a message on a MANET interface, this mechanism:
ルータがMANETインターフェイスでメッセージを生成すると、このメカニズムは次のようになります。
o Specifies how to calculate an ICV for the message.
o メッセージのICVを計算する方法を指定します。
o Specifies how to include that ICV using an ICV Message TLV.
o ICVメッセージTLVを使用してそのICVを含める方法を指定します。
[RFC6130] and [RFC7181] allow for the rejection of incoming messages prior to processing by NHDP or OLSRv2. This mechanism, when used, specifies that a message MUST be rejected if the ICV Message TLV is absent, or its value cannot be verified. Note that this means that routers whose implementation of NHDP and/or OLSRv2 does not include this specification will be ignored by routers using this mechanism, and these two sets of routers will, by design, form disjoint MANETs. (The unsecured MANET will retain some information about the secured MANET, but be unable to use it, not having any recognized symmetric links with the secured MANET.)
[RFC6130]と[RFC7181]では、NHDPまたはOLSRv2による処理の前に着信メッセージを拒否できます。このメカニズムを使用する場合、ICVメッセージTLVが存在しない場合、またはその値を確認できない場合、メッセージを拒否する必要があることを指定します。これは、NHDPやOLSRv2の実装にこの仕様が含まれていないルーターは、このメカニズムを使用するルーターによって無視され、これらの2つのルーターセットは、設計上、ばらばらのMANETを形成することを意味します。 （保護されていないMANETは保護されたMANETに関するいくつかの情報を保持しますが、それを使用できず、保護されたMANETとの認識された対称リンクがありません。）
The following router parameters are specified for use by the two protocols; the first is required only by NHDP, but may be visible to OLSRv2, the second is required only by OLSRv2:
次のルータパラメータは、2つのプロトコルで使用するために指定されています。 1つ目はNHDPでのみ必要ですが、OLSRv2からは見えますが、2つ目はOLSRv2でのみ必要です。
o MAX_HELLO_TIMESTAMP_DIFF - The maximum age that a HELLO message to be validated may have. If the current POSIX time of the router validating the HELLO message, minus the timestamp indicated in the TIMESTAMP TLV of the HELLO message, is greater than MAX_HELLO_TIMESTAMP_DIFF, the HELLO message MUST be silently discarded.
o MAX_HELLO_TIMESTAMP_DIFF-検証されるHELLOメッセージの最大存続期間。 HELLOメッセージを検証するルーターの現在のPOSIX時間から、HELLOメッセージのTIMESTAMP TLVに示されているタイムスタンプを引いた値がMAX_HELLO_TIMESTAMP_DIFFよりも大きい場合、HELLOメッセージは通知なく破棄されなければなりません（MUST）。
o MAX_TC_TIMESTAMP_DIFF - The maximum age that a TC message to be validated may have. If the current POSIX time of the router validating the TC message, minus the timestamp indicated in the TIMESTAMP TLV of the TC message, is greater than MAX_TC_TIMESTAMP_DIFF, the TC message MUST be silently discarded.
o MAX_TC_TIMESTAMP_DIFF-検証されるTCメッセージの最大経過時間。 TCメッセージを検証するルーターの現在のPOSIX時間から、TCメッセージのTIMESTAMP TLVに示されているタイムスタンプを引いた値がMAX_TC_TIMESTAMP_DIFFよりも大きい場合、TCメッセージは通知なく破棄される必要があります。
The following constraints apply to these parameters:
これらのパラメーターには、次の制約が適用されます。
o MAX_HELLO_TIMESTAMP_DIFF > 0
o MAX_HELLO_TIMESTAMP_DIFF> 0
o MAX_TC_TIMESTAMP_DIFF > 0
o MAX_TC_TIMESTAMP_DIFF> 0
However, these bounds are insufficient: MAX_HELLO_TIMESTAMP_DIFF and MAX_TC_TIMESTAMP_DIFF MUST be least as great as the maximum expected "age" of a message (i.e., the time difference between a message has been sent by a router and received by all intended destinations). For HELLO messages, this needs only cover a single hop, but TC messages may have been forwarded a number of times. In particular, for TC messages, if using jitter as specified in [RFC7181] and [RFC5148], the largest contribution the age may be a delay of up to F_MAXJITTER per hop (except the final hop) that the message has traveled. Other factors in the delay of both message types, per hop, may include the link-layer that is used in the MANET, and CPU and memory resources of routers (e.g., queuing delays, and delays for processing ICVs). An implementation MAY set lower and/or upper bounds on these parameters, if so, then these MUST allow values meeting these requirements. An implementation MAY make its value of MAX_TC_TIMESTAMP_DIFF dependent on the number of hops that a TC message has traveled.
ただし、これらの境界は不十分です。MAX_HELLO_TIMESTAMP_DIFFとMAX_TC_TIMESTAMP_DIFFは、メッセージの予想される最大「年齢」（つまり、メッセージがルーターによって送信され、すべての目的の宛先によって受信された時間）と同じかそれ以上でなければなりません。 HELLOメッセージの場合、これは1つのホップのみをカバーする必要がありますが、TCメッセージは何度も転送されている可能性があります。特に、TCメッセージの場合、[RFC7181]と[RFC5148]で指定されているジッターを使用すると、経過時間の最大の寄与は、メッセージが移動したホップ（最終ホップを除く）あたり最大F_MAXJITTERの遅延になる可能性があります。ホップごとの両方のメッセージタイプの遅延の他の要因には、MANETで使用されるリンク層、ルーターのCPUおよびメモリリソース（キューの遅延、ICVの処理の遅延など）が含まれます。実装は、これらのパラメーターの下限または上限、あるいはその両方を設定してもよい（MAY）、そうであれば、これらはこれらの要件を満たす値を許可しなければならない（MUST）。実装は、TCメッセージが移動したホップ数に応じて、MAX_TC_TIMESTAMP_DIFFの値を作成する場合があります。
The above constraints assume ideal time synchronization of the clock in all routers in the network. The parameters MAX_HELLO_TIMESTAMP_DIFF and MAX_TC_TIMESTAMP_DIFF (and any constraints on them) MAY be increased to allow for expected timing differences between routers (between neighboring routers for MAX_HELLO_TIMESTAMP_DIFF, allowing for greater separation, but usually not per hop, for MAX_TC_TIMESTAMP_DIFF).
上記の制約は、ネットワーク内のすべてのルーターのクロックの理想的な時刻同期を前提としています。パラメーターMAX_HELLO_TIMESTAMP_DIFFおよびMAX_TC_TIMESTAMP_DIFF（およびそれらの制約）は、ルーター間（MAX_HELLO_TIMESTAMP_DIFFの隣接ルーター間で予想されるタイミングの違いを可能にするために大きくすることができますが、MAX_TC_TIMESTAMP_DIFFの場合、ホップごとではなく、より大きな分離が可能です）。
Note that excessively large values of these parameters defeats their objectives, so these parameters SHOULD be as large as is required, but not significantly larger.
これらのパラメーターの値が大きすぎると、目的が達成されないため、これらのパラメーターは必要なだけ大きくする必要がありますが、大幅に大きくすることはできません。
Using POSIX time allows a resolution of no more than one second. In many MANET use cases, time synchronization much below one second is not possible because of unreliable and high-delay channels, mobility, interrupted communication, and possible resource limitations.
POSIX時間を使用すると、1秒以下の分解能が可能になります。多くのMANETユースケースでは、信頼性のない高遅延チャネル、モビリティ、通信の中断、およびリソースの制限により、1秒を大幅に下回る時刻同期は不可能です。
In addition, when using the default message intervals and validity times as specified in [RFC6130] and [RFC7181], where the shortest periodic message interval is 2 seconds, repeating the message within a second is actually beneficial rather than harmful (at a small bandwidth cost). Also, the use of [RFC5148] jitter can cause a message to take that long or longer to traverse the MANET, thus even in a perfectly synchronized network, the TC maximum delay would usually be greater than 1 second.
さらに、[RFC6130]と[RFC7181]で指定されているデフォルトのメッセージ間隔と有効時間を使用する場合、最短の定期的なメッセージ間隔は2秒であり、メッセージを1秒以内に繰り返すことは（狭い帯域幅で）害を及ぼすのではなく、実際に有益です。費用）。また、[RFC5148]ジッターを使用すると、メッセージがMANETを通過するのに長い時間がかかる場合があるため、完全に同期されたネットワークでも、TCの最大遅延は通常1秒を超えます。
A finer granularity than 1 second, and thus the use of an alternative timestamp, is however RECOMMENDED in cases where, possibly due to fast moving routers, message validity times are below 1 second.
ただし、1秒よりも細かいため、代替タイムスタンプを使用することをお勧めします。これは、ルーターの移動が速いために、メッセージの有効時間が1秒未満の場合に推奨されます。
This section specifies how messages are generated and processed by [RFC6130] and [RFC7181] when using this mechanism.
このセクションでは、このメカニズムを使用するときに、[RFC6130]と[RFC7181]がメッセージを生成および処理する方法を指定します。
Messages MUST have the content specified in [RFC6130] and [RFC7181], respectively. In addition, messages that conform to this mechanism MUST contain:
メッセージは、[RFC6130]と[RFC7181]でそれぞれ指定された内容を持たなければなりません。さらに、このメカニズムに準拠するメッセージには、以下が含まれている必要があります。
o At least one ICV Message TLV (as specified in [RFC7182]), generated according to Section 6.2. Implementations of [RFC6130] and [RFC7181] MUST support the following version of the ICV TLV, but other versions MAY be used instead, or in addition, in a deployment, if more appropriate:
o セクション6.2に従って生成された、少なくとも1つのICVメッセージTLV（[RFC7182]で指定）。 [RFC6130]と[RFC7181]の実装は、次のバージョンのICV TLVをサポートする必要がありますが、他のバージョンを代わりに、またはさらに適切な場合は、展開で使用できます（MAY）。
* For TC messages:
* TCメッセージの場合：
+ type-extension := 1
+ type-extension：= 1
* For HELLO messages:
* HELLOメッセージの場合：
+ type-extension := 2
+ タイプ拡張：= 2
* hash-function := 3 (SHA-256)
* ハッシュ関数：= 3（SHA-256）
* cryptographic-function := 3 (HMAC)
* 暗号機能：= 3（HMAC）
The ICV Value MAY be truncated as specified in [RFC7182]; the selection of an appropriate length MAY be administratively configured. A message MAY contain several ICV Message TLVs.
ICV値は、[RFC7182]で指定されているように切り捨てられる場合があります。適切な長さの選択は、管理上構成することができます。メッセージには複数のICVメッセージTLVが含まれる場合があります。
o At least one TIMESTAMP Message TLV (as specified in [RFC7182]), generated according to Section 6.2. Implementations of [RFC6130] and [RFC7181] using this mechanism MUST support the following version of the TIMESTAMP TLV, but other versions MAY be used instead, or in addition, in a deployment, if more appropriate:
o セクション6.2に従って生成された、少なくとも1つのTIMESTAMPメッセージTLV（[RFC7182]で指定）。このメカニズムを使用した[RFC6130]と[RFC7181]の実装は、次のバージョンのTIMESTAMP TLVをサポートする必要がありますが、他のバージョンを代わりに、またはさらに適切な場合はデプロイメントで使用できます（MAY）。
* type-extension := 1
* type-extension：= 1
After message generation (Section 11.1 of [RFC6130] and Section 16.1. of [RFC7181]) and before message transmission (Section 11.2 of [RFC6130] and Section 16.2 of [RFC7181]), the additional TLVs specified in Section 6.1 MUST (unless already present) be added to an outgoing message when using this mechanism.
メッセージ生成後（[RFC6130]のセクション11.1および[RFC7181]のセクション16.1）、およびメッセージ送信（[RFC6130]のセクション11.2]および[RFC7181]のセクション16.2）の前に、セクション6.1で指定された追加のTLVが必須present）このメカニズムを使用する場合、送信メッセージに追加されます。
The following processing steps (when using a single timestamp version and a single ICV algorithm) MUST be performed for a cryptographic algorithm that is used for generating an ICV for a message:
メッセージのICVの生成に使用される暗号化アルゴリズムに対して、次の処理手順（単一のタイムスタンプバージョンと単一のICVアルゴリズムを使用する場合）を実行する必要があります。
1. All ICV TLVs (if any) are temporarily removed from the message. Any temporarily removed ICV TLVs MUST be stored, in order to be reinserted into the message in step 5. The message size and Message TLV Block size are updated accordingly.
1. すべてのICV TLV（存在する場合）は、メッセージから一時的に削除されます。一時的に削除されたICV TLVは、手順5でメッセージに再挿入するために保存する必要があります。メッセージサイズとメッセージTLVブロックサイズはそれに応じて更新されます。
2. <msg-hop-count> and <msg-hop-limit>, if present, are temporarily set to 0.
2. <msg-hop-count>と<msg-hop-limit>（存在する場合）は一時的に0に設定されます。
3. A TLV of type TIMESTAMP, as specified in Section 6.1, is added to the Message TLV Block. The message size and Message TLV Block size are updated accordingly.
3. セクションTIMで指定されているタイプTIMESTAMPのTLVがメッセージTLVブロックに追加されます。メッセージサイズとメッセージTLVブロックサイズはそれに応じて更新されます。
4. A TLV of type ICV, as specified in Section 6.1, is added to the Message TLV Block. The message size and Message TLV Block size are updated accordingly.
4. セクション6.1で指定されているタイプICVのTLVがメッセージTLVブロックに追加されます。メッセージサイズとメッセージTLVブロックサイズはそれに応じて更新されます。
5. All ICV TLVs that were temporary removed in step 1, are restored. The message size and Message TLV Block size are updated accordingly.
5. 手順1で一時的に削除されたすべてのICV TLVが復元されます。メッセージサイズとメッセージTLVブロックサイズはそれに応じて更新されます。
6. <msg-hop-count> and <msg-hop-limit>, if present, are restored to their previous values.
6. <msg-hop-count>および<msg-hop-limit>（存在する場合）は、以前の値に復元されます。
An implementation MAY add either alternative TIMESTAMP and/or ICV TLVs or more than one TIMESTAMP and/or ICV TLVs. All TIMESTAMP TLVs MUST be inserted before adding ICV TLVs.
実装は、代替のTIMESTAMPおよび/またはICV TLV、または複数のTIMESTAMPおよび/またはICV TLVを追加してもよい（MAY）。 ICV TLVを追加する前に、すべてのTIMESTAMP TLVを挿入する必要があります。
Both [RFC6130] and [RFC7181] specify that:
[RFC6130]と[RFC7181]はどちらも次のように指定しています。
On receiving a ... message, a router MUST first check if the message is invalid for processing by this router
...メッセージを受信すると、ルーターはまず、メッセージがこのルーターによる処理に無効かどうかを確認する必要があります
[RFC6130] and [RFC7181] proceed to give a number of conditions that, each, will lead to a rejection of the message as "badly formed and therefore invalid for processing". When using a single timestamp version, and a single ICV algorithm, add the following conditions to that list, each of which, if true, MUST cause NHDP or OLSRv2 (as appropriate) to consider the message as invalid for processing when using this mechanism:
[RFC6130]と[RFC7181]は、それぞれが「不正な形式であり、したがって処理には無効である」というメッセージの拒否につながるいくつかの条件を提供します。単一のタイムスタンプバージョンと単一のICVアルゴリズムを使用する場合は、次の条件をそのリストに追加します。それぞれの条件がtrueの場合、NHDPまたはOLSRv2（適切な場合）で、このメカニズムを使用する場合、メッセージを処理に対して無効であると見なす必要があります。
1. The Message TLV Block of the message does not contain exactly one TIMESTAMP TLV of the selected version. This version specification includes the type extension. (The Message TLV Block may also contain TIMESTAMP TLVs of other versions.)
1. メッセージのメッセージTLVブロックには、選択したバージョンのTIMESTAMP TLVが1つだけ含まれていません。このバージョン仕様には、タイプ拡張が含まれています。 （メッセージTLVブロックには、他のバージョンのTIMESTAMP TLVも含まれる場合があります。）
2. The Message TLV Block does not contain exactly one ICV TLV using the selected algorithm and key identifier. This algorithm specification includes the type extension, and for type extensions 1 and 2, the hash function and cryptographic function. (The Message TLV Block may also contain ICV TLVs using other algorithms and key identifiers.)
2. メッセージTLVブロックには、選択したアルゴリズムとキー識別子を使用するICV TLVが1つだけ含まれていません。このアルゴリズム仕様には、型拡張が含まれ、型拡張1および2の場合は、ハッシュ関数と暗号関数が含まれます。 （メッセージTLVブロックには、他のアルゴリズムとキー識別子を使用したICV TLVも含まれる場合があります。）
3. Validation of the identified (in step 1) TIMESTAMP TLV in the Message TLV Block of the message fails, as according to Section 6.3.1.
3. セクション6.3.1に従って、メッセージのメッセージTLVブロック内の（ステップ1で）識別されたTIMESTAMP TLVの検証が失敗します。
4. Validation of the identified (in step 2) ICV TLV in the Message TLV Block of the message fails, as according to Section 6.3.2.
4. セクション6.3.2に従って、メッセージのメッセージTLVブロック内の（ステップ2で）識別されたICV TLVの検証が失敗します。
An implementation MAY check the existence of, and verify, either an alternative TIMESTAMP and/or ICV TLVs or more than one TIMESTAMP and/ or ICV TLVs.
実装は、代替のTIMESTAMPやICV TLV、または複数のTIMESTAMPやICV TLVの存在をチェックし、検証することができます（MAY）。
For a TIMESTAMP Message TLV with type extension 1 (POSIX time) identified as described in Section 6.2:
セクション6.2で説明されているように識別されたタイプ拡張1（POSIX時間）のTIMESTAMPメッセージTLVの場合：
1. If the current POSIX time minus the value of that TIMESTAMP TLV is greater than MAX_HELLO_TIMESTAMP_DIFF (for a HELLO message) or MAX_TC_TIMESTAMP_DIFF (for a TC message), then the message validation fails.
1. 現在のPOSIX時間からTIMESTAMP TLVの値を引いた値がMAX_HELLO_TIMESTAMP_DIFF（HELLOメッセージの場合）またはMAX_TC_TIMESTAMP_DIFF（TCメッセージの場合）より大きい場合、メッセージの検証は失敗します。
2. Otherwise, the message validation succeeds.
2. それ以外の場合、メッセージの検証は成功します。
If a deployment chooses to use a different type extension from 1, appropriate measures MUST be taken to verify freshness of the message.
デプロイメントが1とは異なるタイプの拡張を使用することを選択した場合、メッセージの鮮度を検証するために適切な対策を講じる必要があります。
For an ICV Message TLV identified as described in Section 6.2:
セクション6.2で説明されているように識別されたICVメッセージTLVの場合：
1. All ICV Message TLVs (including the identified ICV Message TLV) are temporarily removed from the message, and the message size and Message TLV Block size are updated accordingly.
1. すべてのICVメッセージTLV（識別されたICVメッセージTLVを含む）はメッセージから一時的に削除され、それに応じてメッセージサイズとメッセージTLVブロックサイズが更新されます。
2. The message's <msg-hop-count> and <msg-hop-limit> fields are temporarily set to 0.
2. メッセージの<msg-hop-count>および<msg-hop-limit>フィールドは一時的に0に設定されます。
3. Calculate the ICV for the parameters specified in the identified ICV Message TLV, as specified in [RFC7182].
3. [RFC7182]で指定されているように、識別されたICVメッセージTLVで指定されたパラメーターのICVを計算します。
4. If this ICV differs from the value of <ICV-data> in the ICV Message TLV, then the message validation fails. If the <ICV-data> has been truncated (as specified in [RFC7182], the ICV calculated in the previous step MUST be truncated to the TLV length of the ICV Message TLV before comparing it with the <ICV-data>.
4. このICVがICVメッセージTLVの<ICV-data>の値と異なる場合、メッセージの検証は失敗します。 <ICV-data>が切り捨てられている場合（[RFC7182]で指定されているように）、前のステップで計算されたICVは、<ICV-data>と比較する前に、ICVメッセージTLVのTLV長に切り捨てられる必要があります。
5. Otherwise, the message validation succeeds. The message's <msg-hop-count> and <msg-hop-limit> fields are restored to their previous value, and the ICV Message TLVs are returned to the message, whose size is updated accordingly.
5. それ以外の場合、メッセージの検証は成功します。メッセージの<msg-hop-count>および<msg-hop-limit>フィールドが以前の値に復元され、ICVメッセージTLVがメッセージに返され、それに応じてサイズが更新されます。
Before a router using this mechanism is able to generate ICVs or validate messages, it MUST acquire the shared secret key(s) to be used by all routers that are to participate in the network. This specification does not define how a router acquires secret keys. Once a router has acquired suitable key(s), it MAY be configured to use, or not use, this mechanism. Section 23.6 of [RFC7181] provides a rationale based on [BCP107] why no key management is specified for OLSRv2.
このメカニズムを使用するルーターがICVを生成したり、メッセージを検証したりする前に、ネットワークに参加するすべてのルーターが使用する共有秘密鍵を取得する必要があります。この仕様では、ルーターが秘密鍵を取得する方法は定義されていません。ルーターが適切なキーを取得したら、このメカニズムを使用するように、または使用しないように設定できます。 [RFC7181]のセクション23.6は、[BCP107]に基づいて、OLSRv2にキー管理が指定されていない理由を提供します。
This document specifies a security mechanism for use with NHDP and OLSRv2 that allows for mitigating several security threats.
このドキュメントでは、NHDPおよびOLSRv2で使用するためのセキュリティメカニズムを指定します。これにより、いくつかのセキュリティ上の脅威を軽減できます。
This section briefly summarizes security threats that are mitigated by the mechanism presented in this document.
このセクションでは、このドキュメントで提示されているメカニズムによって軽減されるセキュリティの脅威を簡単に要約します。
As only routers possessing the selected shared secret key are able to add a valid ICV TLV to a message, identity spoofing, where an attacker falsely claims an identity of a valid router, is countered. When using one or more shared keys for all routers in the MANET, it is only possible to determine that it is a valid router in the network, not to discern particular routers. Therefore, a malicious router in possession of valid keys (e.g., a compromised router) may still spoof the identity of another router using the same key.
選択した共有秘密鍵を所有するルーターのみが有効なICV TLVをメッセージに追加できるため、攻撃者が有効なルーターのIDを誤って要求するIDスプーフィングが対抗されます。 MANET内のすべてのルーターに1つ以上の共有キーを使用する場合、特定のルーターを識別するのではなく、それがネットワーク内の有効なルーターであると判断することのみが可能です。したがって、有効なキーを所有している悪意のあるルーター（侵害されたルーターなど）は、同じキーを使用している別のルーターのIDを偽装する可能性があります。
Link spoofing, where an attacker falsely represents the existence of a nonexistent link, or otherwise misrepresents a link's state, is countered by the mechanism specified in this document, using the same argument as in Section 8.1.1.
攻撃者が存在しないリンクの存在を誤って表す、またはリンクの状態を誤って表すリンクスプーフィングは、セクション8.1.1と同じ引数を使用して、このドキュメントで指定されたメカニズムによって対抗されます。
Replay attacks are partly countered by the mechanism specified in this document, but this depends on synchronized clocks of all routers in the MANET. An attacker that records messages to replay them later can only do so in the selected time interval after the timestamp that is contained in message. As an attacker cannot modify the content of this timestamp (as it is protected by the identity check value), an attacker cannot replay messages after this time. Within this time interval, it is still possible to perform replay attacks; however, the limits on the time interval are specified so that this will have a limited effect on the operation of the protocol.
リプレイ攻撃は、このドキュメントで指定されたメカニズムによって部分的に対抗されますが、これはMANET内のすべてのルーターの同期されたクロックに依存します。メッセージを記録して後で再生する攻撃者は、メッセージに含まれているタイムスタンプの後の選択された時間間隔でのみそれを行うことができます。攻撃者はこのタイムスタンプの内容を変更できないため（IDチェック値によって保護されているため）、この時間を過ぎるとメッセージを再生できなくなります。この期間内でも、リプレイ攻撃を実行することは可能です。ただし、時間間隔の制限は、プロトコルの動作に影響が限定されるように指定されています。
If no synchronized clocks are available in the MANET, replay attacks cannot be countered by the mechanism provided by this document. An alternative version of the TIMESTAMP TLV defined in [RFC7182], with a monotonic sequence number, may have some partial value in this case, but will necessitate adding state to record observed message sequence number information.
MANETで同期クロックが使用できない場合、このドキュメントで提供されているメカニズムではリプレイ攻撃に対抗できません。 [RFC7182]で定義されているTIMESTAMP TLVの代替バージョンは、単調なシーケンス番号を持ち、この場合は部分的な値を持つ可能性がありますが、観測されたメッセージシーケンス番号情報を記録するために状態を追加する必要があります。
The mechanism provided by this document does not avoid or detect security attacks by routers possessing the shared secret key that is used to generate integrity check values for messages.
このドキュメントで提供されるメカニズムは、メッセージの整合性チェック値を生成するために使用される共有秘密鍵を所有するルータによるセキュリティ攻撃を回避または検出しません。
This mechanism relies on an out-of-band protocol or mechanism for distributing the shared secret key(s) (and if an alternative integrity check value is used, any additional cryptographic parameters).
このメカニズムは、共有秘密キーを配布するための帯域外プロトコルまたはメカニズムに依存しています（代替の整合性チェック値が使用されている場合は、追加の暗号化パラメーターがあります）。
This mechanism does not provide a key management mechanism. Refer to Section 23.6 of [RFC7181] for a detailed discussion why the automated key management requirements specified in [BCP107] do not apply for OLSRv2 and NHDP.
このメカニズムは、キー管理メカニズムを提供しません。 [BCP107]で指定された自動キー管理要件がOLSRv2およびNHDPに適用されない理由の詳細については、[RFC7181]のセクション23.6を参照してください。
The authors would like to gratefully acknowledge the following people: Justin Dean (NRL) and Henning Rogge (Frauenhofer FKIE).
著者は以下の人々に感謝の意を表します：Justin Dean（NRL）とHenning Rogge（Frauenhofer FKIE）。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format", RFC 5444, February 2009.
[RFC5444] Clausen、T.、Dearlove、C.、Dean、J。、およびC. Adjih、「Generalized Mobile Ad Hoc Network（MANET）Packet / Message Format」、RFC 5444、2009年2月。
[RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, April 2011.
[RFC6130] Clausen、T.、Dearlove、C。、およびJ. Dean、「Mobile Ad Hoc Network（MANET）Neighborhood Discovery Protocol（NHDP）」、RFC 6130、2011年4月。
[RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, "The Optimized Link State Routing Protocol Version 2", RFC 7181, April 2014.
[RFC7181] Clausen、T.、Dearlove、C.、Jacquet、P。、およびU. Herberg、「The Optimized Link State Routing Protocol Version 2」、RFC 7181、2014年4月。
[RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)", RFC 7182, April 2014.
[RFC7182] Herberg、U.、Clauseen、T。、およびC. Dearlove、「Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks（MANETs）」、RFC 7182、2014年4月。
[BCP107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[BCP107] Bellovin、S。およびR. Housley、「暗号鍵管理のガイドライン」、BCP 107、RFC 4107、2005年6月。
[RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter Considerations in Mobile Ad Hoc Networks (MANETs)", RFC 5148, February 2008.
[RFC5148] Clausen、T.、Dearlove、C。、およびB. Adamson、「モバイルアドホックネットワーク（MANET）におけるジッタの考慮事項」、RFC 5148、2008年2月。
Authors' Addresses
著者のアドレス
Ulrich Herberg Fujitsu Laboratories of America 1240 E. Arques Ave. Sunnyvale, CA, 94085 USA
うｌりｃｈ へｒべｒｇ ふじつ ぁぼらとりえｓ おｆ あめりか １２４０ え。 あｒくえｓ あゔぇ。 すんｙゔぁぇ、 か、 ９４０８５ うさ
EMail: ulrich@herberg.name
URI: http://www.herberg.name/
Christopher Dearlove BAE Systems Advanced Technology Centre West Hanningfield Road Great Baddow, Chelmsford United Kingdom
Christopher Dearlove BAE Systems Advanced Technology Center West Hanningfield Roadイギリス、チェルムズフォード、グレートバッドウ
Phone: +44 1245 242194
EMail: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/
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/