[要約] RFC 7985は、Simplified Multicast Forwarding（SMF）に対するセキュリティ脅威についての要約を提供しています。その目的は、SMFのセキュリティ上の問題を特定し、対策を提案することです。
Internet Engineering Task Force (IETF) J. Yi
Request for Comments: 7985 T. Clausen
Updates: 7186 Ecole Polytechnique
Category: Informational U. Herberg
ISSN: 2070-1721 November 2016
Security Threats to Simplified Multicast Forwarding (SMF)
Simplified Multicast Forwarding（SMF）に対するセキュリティの脅威
Abstract
概要
This document analyzes security threats to Simplified Multicast Forwarding (SMF), including vulnerabilities of duplicate packet detection and relay set selection mechanisms. This document is not intended to propose solutions to the threats described.
このドキュメントでは、重複パケット検出およびリレーセット選択メカニズムの脆弱性を含む、Simplified Multicast Forwarding（SMF）に対するセキュリティの脅威を分析します。このドキュメントは、説明されている脅威の解決策を提案することを意図したものではありません。
In addition, this document updates RFC 7186 regarding threats to the relay set selection mechanisms using the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) (RFC 6130).
さらに、このドキュメントは、モバイルアドホックネットワーク（MANET）近隣探索プロトコル（NHDP）（RFC 6130）を使用するリレーセット選択メカニズムへの脅威に関するRFC 7186を更新します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。 Internet Engineering Steering Group（IESG）による公開が承認されています。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 7841のセクション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/rfc7985.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7985で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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. SMF Threat Overview . . . . . . . . . . . . . . . . . . . . . 4
4. Threats to Duplicate Packet Detection . . . . . . . . . . . . 5
4.1. Attack on the Hop Limit Field . . . . . . . . . . . . . . 6
4.2. Threats to Identification-Based Duplicate Packet
Detection . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.1. Pre-Activation Attacks (Pre-Play) . . . . . . . . . . 7
4.2.2. De-activation Attacks (Sequence Number Wrangling) . . 8
4.3. Threats to Hash-Based Duplicate Packet Detection . . . . 9
4.3.1. Attack on the Hash-Assistant Value . . . . . . . . . 9
5. Threats to Relay Set Selection . . . . . . . . . . . . . . . 10
5.1. Common Threats to Relay Set Selection . . . . . . . . . . 10
5.2. Threats to the E-CDS Algorithm . . . . . . . . . . . . . 10
5.2.1. Link Spoofing . . . . . . . . . . . . . . . . . . . . 11
5.2.2. Identity Spoofing . . . . . . . . . . . . . . . . . . 11
5.3. Threats to S-MPR Algorithm . . . . . . . . . . . . . . . 11
5.4. Threats to the MPR-CDS Algorithm . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
This document analyzes security threats to Simplified Multicast Forwarding (SMF) [RFC6621]. SMF aims at providing basic Internet Protocol (IP) multicast forwarding in a way that is suitable for wireless mesh and Mobile Ad Hoc Networks (MANET). SMF consists of two major functional components: duplicate packet detection (DPD) and relay set selection (RSS).
このドキュメントでは、Simplified Multicast Forwarding（SMF）[RFC6621]に対するセキュリティの脅威を分析しています。 SMFは、ワイヤレスメッシュおよびモバイルアドホックネットワーク（MANET）に適した方法で、基本的なインターネットプロトコル（IP）マルチキャスト転送を提供することを目的としています。 SMFは、重複パケット検出（DPD）とリレーセット選択（RSS）の2つの主要な機能コンポーネントで構成されています。
SMF is typically used in decentralized wireless environments and is potentially exposed to various attacks and misconfigurations. In a wireless environment, some of these attacks and misconfigurations represent threats of particular significance as compared to what they would do in wired networks. [RFC6621] briefly discusses several of these, but does not define any explicit security measures for protecting the integrity of the protocol.
SMFは通常、分散型ワイヤレス環境で使用され、さまざまな攻撃や設定ミスにさらされる可能性があります。ワイヤレス環境では、これらの攻撃や設定ミスの一部は、有線ネットワークでの攻撃と比較して、特に重要な脅威を表しています。 [RFC6621]はこれらのいくつかについて簡単に説明しますが、プロトコルの整合性を保護するための明示的なセキュリティ対策は定義していません。
This document is based on the assumption that no additional security mechanism, such as IPsec, is used in the IP layer, as not all MANET deployments may be able to support deployment of such common IP protection mechanisms (e.g., because MANET routers may have limited resources for supporting the IPsec stack). It also assumes that there is no lower-layer protection. The document analyzes possible attacks on, and misconfigurations of, SMF and outlines the consequences of such attacks/misconfigurations to the state maintained by SMF in each router.
このドキュメントは、すべてのMANET展開がそのような一般的なIP保護メカニズムの展開をサポートできるとは限らないため、IPsecなどの追加のセキュリティメカニズムはIPレイヤーで使用されないという前提に基づいています（たとえば、MANETルーターがIPsecスタックをサポートするためのリソース）。また、下位層の保護がないことも前提としています。このドキュメントでは、SMFに対する考えられる攻撃とその構成の誤りを分析し、各ルーターでSMFによって維持されている状態に対するそのような攻撃/構成の誤りの結果を概説します。
In the Security Considerations section of [RFC6621], denial-of-service-attack scenarios are briefly discussed. This document further analyzes and describes the potential vulnerabilities of, and attack vectors for, SMF. While completeness in such analysis is always a goal, no claims of being complete are made. The goal of this document is to be helpful when deploying SMF in a network and for understanding the risks incurred, as well as for providing a reference to and documented experience with SMF as input for possible future developments of SMF.
[RFC6621]のセキュリティに関する考慮事項のセクションでは、サービス拒否攻撃シナリオが簡単に説明されています。このドキュメントでは、SMFの潜在的な脆弱性と攻撃ベクトルをさらに分析して説明します。そのような分析の完全性は常に目標ですが、完全であるという主張は行われません。このドキュメントの目的は、SMFをネットワークに展開する際に発生し、発生するリスクを理解すること、およびSMFへの参照とドキュメント化された経験をSMFの将来の開発の可能性の入力として提供することです。
This document is not intended to propose solutions to the threats described. [RFC7182] provides a framework that can be used with SMF, and depending on how it is used, may offer some degree of protection against the threats related to identity spoofing described in this document.
このドキュメントは、説明されている脅威の解決策を提案することを意図したものではありません。 [RFC7182]は、SMFで使用できるフレームワークを提供し、その使用方法によっては、このドキュメントで説明されているIDスプーフィングに関連する脅威に対してある程度の保護を提供する場合があります。
This document also updates [RFC7186], specifically with respect to threats to relay set selection (RSS) mechanisms that are using MANET NHDP [RFC6130].
このドキュメントはまた、特にMANET NHDP [RFC6130]を使用しているリレーセット選択（RSS）メカニズムへの脅威に関して、[RFC7186]を更新します。
This document uses the terminology and notation defined in [RFC5444], [RFC6130], [RFC6621], and [RFC4949].
このドキュメントでは、[RFC5444]、[RFC6130]、[RFC6621]、および[RFC4949]で定義されている用語と表記法を使用しています。
Additionally, this document introduces the following terminology:
さらに、このドキュメントでは次の用語を紹介しています。
SMF router: A MANET router, running SMF as specified in [RFC6621].
SMFルーター：[RFC6621]で指定されたSMFを実行するMANETルーター。
Attacker: A device that is present in the network and intentionally seeks to compromise the information bases in SMF routers. It may generate syntactically correct SMF control messages.
攻撃者：ネットワークに存在し、SMFルーターの情報ベースを意図的に侵害しようとするデバイス。構文的に正しいSMF制御メッセージを生成する場合があります。
Legitimate SMF router: An SMF router that is correctly configured and not compromised by an attacker.
正当なSMFルーター：正しく構成され、攻撃者によって侵害されていないSMFルーター。
An SMF router requires an external dynamic neighborhood discovery mechanism in order to maintain suitable topological information describing its immediate neighborhood, and thereby allowing it to select reduced relay sets for forwarding multicast data traffic. Such an external dynamic neighborhood discovery mechanism may be provided by lower-layer interface information, by a concurrently operating MANET routing protocol that already maintains such information (e.g., [RFC7181]) or by explicitly using the MANET Neighborhood Discovery Protocol (NHDP) [RFC6130]. If NHDP is used for both 1-hop and 2-hop neighborhood discovery by SMF, SMF implicitly inherits the vulnerabilities of NHDP discussed in [RFC7186]. As SMF relies on NHDP to assist in network-layer 2-hop neighborhood discovery (no matter if other lower-layer mechanisms are used for 1-hop neighborhood discovery), this document assumes that NHDP is used in SMF. The threats that are NHDP specific are indicated explicitly.
SMFルーターは、直接の近隣を説明する適切なトポロジ情報を維持するために、外部の動的近隣探索メカニズムを必要とします。これにより、マルチキャストデータトラフィックを転送するためのリレーセットを減らすことができます。このような外部の動的近隣探索メカニズムは、下位層のインターフェース情報、そのような情報をすでに維持している並行して動作するMANETルーティングプロトコル（[RFC7181]など）、またはMANET近隣探索プロトコル（NHDP）[RFC6130を明示的に使用することで提供できます。 ]。 NHDPがSMFによる1ホップと2ホップの近隣探索の両方に使用される場合、SMFは[RFC7186]で説明されているNHDPの脆弱性を暗黙的に継承します。 SMFはネットワーク層の2ホップ近隣探索を支援するためにNHDPに依存しているため（1ホップ近隣探索に他の下位層メカニズムが使用されているかどうかに関係なく）、このドキュメントでは、NHDPがSMFで使用されていると想定しています。 NHDP固有の脅威が明示されています。
Based on neighborhood discovery mechanisms, [RFC6621] specifies two principal functional components: duplicate packet detection (DPD) and relay set selection (RSS).
近隣探索メカニズムに基づいて、[RFC6621]は2つの主要な機能コンポーネントを指定します：重複パケット検出（DPD）とリレーセット選択（RSS）。
DPD is required by SMF in order to be able to detect duplicate packets and eliminate their redundant forwarding. An attacker has two ways in which to harm the DPD mechanisms. Specifically, it can:
DPDは、重複パケットを検出して冗長転送を排除するためにSMFに必要です。攻撃者は、DPDメカニズムに危害を加える2つの方法があります。具体的には、次のことが可能です。
o "deactivate" DPD, making it such that duplicate packets are not correctly detected. As a consequence, they are (redundantly) transmitted, which increases the load on the network, drains the batteries of the routers involved, etc.
o DPDを「非アクティブ化」して、重複パケットが正しく検出されないようにします。結果として、それらは（冗長に）送信され、ネットワークの負荷が増加し、関連するルーターのバッテリーを消耗します。
o "pre-activate" DPD, making DPD detect a later arriving (valid) packet as being a duplicate and will, therefore, not be forwarded.
o DPDを「事前アクティブ化」して、後で到着する（有効な）パケットを重複として検出するため、転送されません。
Attacks on DPD can be achieved by replaying existing packets, wrangling sequence numbers, manipulating hash values, etc.; these are detailed in Section 4.
DPDに対する攻撃は、既存のパケットの再生、シーケンス番号のラングリング、ハッシュ値の操作などによって達成できます。これらについては、セクション4で詳しく説明します。
RSS produces a reduced relay set for forwarding multicast data packets across a MANET. For use in SMF, [RFC6621] specifies several relay set algorithms including E-CDS (Essential Connected Dominating Set) [RFC5614], S-MPR (Source-Based Multipoint Relay, as known from [RFC3626] and [RFC7181]), and MPR-CDS (Multipoint Relay Connected Dominating Set) [MPR-CDS]. An attacker can disrupt the RSS algorithm, and thereby the SMF operation, by degrading it to classical flooding or by "masking" certain parts of the network from the multicasting domain. Attacks on RSS algorithms are detailed in Section 5.
RSSは、MANETを介してマルチキャストデータパケットを転送するためのリレーセットを削減します。 SMFで使用するために、[RFC6621]はE-CDS（Essential Connected Dominating Set）[RFC5614]、S-MPR（Source-Based Multipoint Relay、[RFC3626]と[RFC7181]から知られている）を含むいくつかのリレーセットアルゴリズムを指定します。 MPR-CDS（マルチポイントリレー接続支配セット）[MPR-CDS]。攻撃者は、RSSアルゴリズムを破壊し、それによってSMF操作を古典的なフラッディングに低下させるか、ネットワークの特定の部分をマルチキャストドメインから「マスク」することができます。 RSSアルゴリズムへの攻撃については、セクション5で詳しく説明しています。
Other than the attacks on DPD and RSS, a common vulnerability of MANETs is "jamming", i.e., a device generates massive amounts of interfering radio transmissions, which will prevent legitimate traffic (e.g., control traffic as well as data traffic) on part of a network. The attacks on DPD and RSS can be further enhanced by jamming.
DPDとRSSへの攻撃以外に、MANETの一般的な脆弱性は「妨害」です。つまり、デバイスは大量の干渉無線送信を生成し、一部の正当なトラフィック（制御トラフィックとデータトラフィックなど）を防ぎます。ネットワーク。 DPDおよびRSSへの攻撃は、妨害によってさらに強化できます。
Duplicate packet detection (DPD) is required for packet dissemination in MANETs because: (1) packets may be retransmitted via the same physical interface as the one over which they were received, and (2) a router may receive multiple copies of the same packet (on the same or on different interfaces) from different neighbors. DPD is thus used to check whether or not an incoming packet has been previously received.
MANETでのパケット配布には重複パケット検出（DPD）が必要です。これは、（1）パケットが受信されたのと同じ物理インターフェースを介して再送信される場合があり、（2）ルーターが同じパケットの複数のコピーを受信する場合があるためです。 （同じまたは異なるインターフェイス上で）異なるネイバーから。したがって、DPDは、着信パケットが以前に受信されたかどうかを確認するために使用されます。
DPD is achieved by maintaining a record of recently processed multicast packets, and comparing later received multicast packets herewith. A duplicate packet detected is silently dropped and is not inserted into the forwarding path of that router, nor is it delivered to an application. DPD, as proposed by SMF, supports both IPv4 and IPv6 and suggests two duplicate packet detection mechanisms for each: 1) IP packet header content identification-based DPD (I-DPD), in combination with flow state, to estimate temporal uniqueness of a packet, and 2) hash-based DPD (H-DPD), employing hashing of selected IP packet header fields and payload for the same effect.
DPDは、最近処理されたマルチキャストパケットの記録を維持し、後で受信したマルチキャストパケットをこれと比較することによって実現されます。検出された重複パケットはサイレントにドロップされ、そのルーターの転送パスに挿入されることも、アプリケーションに配信されることもありません。 SMFによって提案されたDPDは、IPv4とIPv6の両方をサポートし、それぞれに2つの重複パケット検出メカニズムを提案します。1）IPパケットヘッダーコンテンツ識別ベースのDPD（I-DPD）をフロー状態と組み合わせて、パケット、および2）ハッシュベースのDPD（H-DPD）。同じ効果を得るために、選択されたIPパケットヘッダーフィールドとペイロードのハッシュを使用します。
In the Security Considerations section of [RFC6621], a selection of threats to DPD are briefly introduced. This section expands on that discussion and describes how to effectively launch the attacks on DPD -- for example, by way of manipulating jitter and/or the Hash-Assistant Value. In the remainder of this section, common threats to packet detection mechanisms are discussed first; then, the threats to I-DPD and H-DPD are introduced separately. The threats described in this section are applicable to general SMF implementations, regardless of whether NHDP is used.
[RFC6621]のセキュリティに関する考慮事項のセクションでは、DPDに対する脅威の選択が簡単に紹介されています。このセクションでは、その議論をさらに詳しく説明し、DPDへの攻撃を効果的に開始する方法について説明します。たとえば、ジッターやハッシュアシスタント値を操作する方法などです。このセクションの残りの部分では、パケット検出メカニズムに対する一般的な脅威について最初に説明します。次に、I-DPDとH-DPDに対する脅威を個別に紹介します。このセクションで説明する脅威は、NHDPが使用されているかどうかに関係なく、一般的なSMF実装に適用されます。
One immediate Denial-of-Service (DoS) attack is based on manipulating the Time-to-Live (TTL, for IPv4) or Hop Limit (for IPv6) field. As routers only forward packets with TTL > 1, an attacker can forward an otherwise valid packet while drastically reducing the TTL hereof. This will inhibit recipient routers from later forwarding the same multicast packet, even if received with a different TTL -- essentially, an attacker can thus instruct its neighbors to block the forwarding of valid multicast packets.
即時サービス拒否（DoS）攻撃の1つは、存続時間（IPv4の場合はTTL）またはホップ制限（IPv6の場合）フィールドの操作に基づいています。ルーターはTTL> 1のパケットのみを転送するため、攻撃者は、TTLを大幅に削減しながら、それ以外は有効なパケットを転送できます。これにより、異なるTTLで受信された場合でも、受信者のルーターが後で同じマルチキャストパケットを転送することが禁止されます。基本的に、攻撃者は近隣に有効なマルチキャストパケットの転送をブロックするように指示できます。
For example, in Figure 1, router A forwards a multicast packet with a TTL of 64 to the network. A, B, and C are legitimate SMF routers, and X is an attacker. In a wireless environment, jitter is commonly used to avoid systematic collisions in Media Access Control (MAC) protocols [RFC5148]. An attacker can thus increase the probability that its invalid packets arrive first by retransmitting them without applying jitter. In this example, router X forwards the packet without applying jitter and reduces the TTL to 1. Router C thus records the duplicate detection value (hash value for H-DPD or the header content of the packets for I-DPD) but does not forward the packet (due to TTL == 1). When a second copy of the same packet, with a non-maliciously manipulated TTL value (63 in this case), arrives from router B, it will be discarded as a duplicate packet.
たとえば、図1では、ルーターAはTTLが64のマルチキャストパケットをネットワークに転送します。 A、B、およびCは正当なSMFルーターであり、Xは攻撃者です。無線環境では、メディアアクセスコントロール（MAC）プロトコル[RFC5148]での体系的な衝突を回避するために、ジッターが一般的に使用されます。したがって、攻撃者は、ジッタを適用せずに再送信することにより、無効なパケットが最初に到着する確率を高めることができます。この例では、ルーターXはジッターを適用せずにパケットを転送し、TTLを1に減らします。ルーターCは重複した検出値（H-DPDのハッシュ値またはI-DPDのパケットのヘッダーコンテンツ）を記録しますが、転送しませんパケット（TTLのため== 1）。悪意のないように操作されたTTL値（この場合は63）を持つ同じパケットの2番目のコピーがルーターBから到着すると、重複したパケットとして破棄されます。
.---.
| X |
--'---' __
packet with TTL=64 / \ packet with TTL=1
/ \
.---. .---.
| A | | C |
'---' '---'
packet with TTL=64 \ .---. /
\-- | B |__/ packet with TTL=63
'---'
Figure 1
図1
As the TTL of a packet is intended to be manipulated by intermediaries forwarding it, classic methods such as integrity check values (e.g., digital signatures) are typically calculated by setting TTL fields to some predetermined value (e.g., 0) -- for example, the case for IPsec Authentication Headers -- rendering such an attack more difficult to both detect and counter.
パケットのTTLは、仲介者がパケットを転送することによって操作されることを目的としているため、完全性チェック値（デジタル署名など）などの従来の方法は、TTLフィールドを所定の値（0など）に設定することで通常計算されます-たとえば、 IPsec認証ヘッダーの場合-このような攻撃を検出し、対抗することを困難にします。
If the attacker has access to a "wormhole" through the network (a directional antenna, a tunnel to a collaborator, or a wired connection, allowing it to bridge parts of a network otherwise distant), it can make sure that the packets with such an artificially reduced TTL arrive before their unmodified counterparts.
攻撃者がネットワークを介して「ワームホール」にアクセスできる場合（指向性アンテナ、コラボレーターへのトンネル、または有線接続により、ネットワークの一部を別の方法でブリッジできるため）、そのようなパケットが人為的に削減されたTTLは、変更されていない対応の前に到着します。
I-DPD uses a specific DPD identifier in the packet header to identify a packet. By default, such packet identification is not provided by the IP packet header (for both IPv4 and IPv6). Therefore, additional identification headers, such as the fragment header, a hop-by-hop header option, or IPsec sequencing, must be employed in order to support I-DPD. The uniqueness of a packet can then be identified by the source IP address of the packet originator and the sequence number (from the fragment header, hop-by-hop header option, or IPsec). By doing so, each intermediate router can keep a record of recently received packets and determine whether or not the incoming packet has been received.
I-DPDは、パケットヘッダー内の特定のDPD識別子を使用してパケットを識別します。デフォルトでは、このようなパケット識別はIPパケットヘッダーでは提供されません（IPv4とIPv6の両方）。したがって、I-DPDをサポートするには、フラグメントヘッダー、ホップバイホップヘッダーオプション、IPsecシーケンスなどの追加の識別ヘッダーを使用する必要があります。パケットの一意性は、パケットの発信元のソースIPアドレスとシーケンス番号（フラグメントヘッダー、ホップバイホップヘッダーオプション、またはIPsecから）によって識別できます。そうすることにより、各中間ルータは最近受信したパケットの記録を保持し、着信パケットが受信されたかどうかを判断できます。
In a wireless environment, or across any other shared channel, an attacker can perceive the identification tuple (source IP address, sequence number) of a packet. It is possible to generate a packet with the same (source IP address, sequence number) pair with invalid content. If the sequence number progression is predictable, then it is trivial to generate and inject invalid packets with "future" identification information into the network. If these invalid packets arrive before the legitimate packets that they are spoofing, the latter will be treated as a duplicate and will be discarded. This can prevent multicast packets from reaching parts of the network.
ワイヤレス環境または他の共有チャネル全体で、攻撃者はパケットの識別タプル（送信元IPアドレス、シーケンス番号）を認識することができます。無効なコンテンツを含む同じ（送信元IPアドレス、シーケンス番号）ペアのパケットを生成する可能性があります。シーケンス番号の進行が予測可能な場合、「将来の」識別情報を持つ無効なパケットを生成してネットワークに注入することは簡単です。これらの無効なパケットが、それらがスプーフィングしている正当なパケットの前に到着した場合、後者は重複として扱われ、破棄されます。これにより、マルチキャストパケットがネットワークの一部に到達するのを防ぐことができます。
Figure 2 gives an example of a pre-activation attack. A, B, and C are legitimate SMF routers, and X is the attacker. The line between the routers presents the packet forwarding. Router A is the source and originates a multicast packet with sequence number n. When router X receives the packet, it generates an invalid packet with the source address of A and sequence number n. If the invalid packet arrives at router C before the forwarding of router B, the valid packet will be dropped by C as a duplicate packet. An attacker can manipulate jitter to make sure that the invalid packets arrive first. Router X can even generate packets with future sequence numbers (if they are predictable), so that the future legitimate packets with the same sequence numbers will be dropped as duplicate ones.
図2は、プレアクティベーション攻撃の例を示しています。 A、B、およびCは正当なSMFルーターであり、Xは攻撃者です。ルータ間のラインは、パケット転送を表します。ルータAが送信元であり、シーケンス番号nのマルチキャストパケットを発信します。ルータXがパケットを受信すると、Aの送信元アドレスとシーケンス番号nを持つ無効なパケットを生成します。無効なパケットがルーターBの転送前にルーターCに到着した場合、有効なパケットはCによって重複パケットとしてドロップされます。攻撃者はジッターを操作して、無効なパケットが最初に到着するようにします。ルーターXは、将来のシーケンス番号（予測可能な場合）を使用してパケットを生成することもできるため、同じシーケンス番号を使用する将来の正当なパケットは、重複したパケットとしてドロップされます。
.---.
| X |
--'---' __
packet with seq=n / \ invalid packet with seq=n
/ \
.---. .---.
| A | | C |
'---' '---'
packet with seq=n \ .---. /
\-- | B |__/ valid packet with seq=n
'---'
Figure 2
図2
As SMF does not currently have any timestamp mechanisms to protect data packets, there is no viable way to detect such pre-play attacks by way of timestamps. Especially, if the attack is based on manipulation of jitter, the validation of the timestamp would not be helpful because the timing is still valid (but, much less valuable).
SMFには現在、データパケットを保護するためのタイムスタンプメカニズムがないため、タイムスタンプを使用してこのようなプレプレイ攻撃を検出する実行可能な方法はありません。特に、攻撃がジッターの操作に基づいている場合、タイミングはまだ有効であるため、タイムスタンプの検証は役に立ちません（ただし、はるかに価値が低くなります）。
An attacker can also seek to de-activate DPD by modifying the sequence number in packets that it forwards. Thus, routers will not be able to detect an actual duplicate packet as a duplicate -- rather, they will treat them as new packets, i.e., process and forward them. This is similar to DoS attacks, as each packet that is considered unique will be multicasted: for a network with n routers, there will be n-1 retransmissions. This can easily cause the "broadcast storm" problem discussed in [MOBICOM99]. The consequence of this attack is an increased channel load, the origin of which appears to be a router other than the attacker.
攻撃者は、転送するパケットのシーケンス番号を変更することにより、DPDを非アクティブ化することもできます。したがって、ルーターは実際の重複パケットを重複として検出することはできません。むしろ、ルーターはそれらを新しいパケットとして処理します。つまり、それらを処理して転送します。これはDoS攻撃に似ています。一意であると見なされる各パケットがマルチキャストされるためです。n台のルーターがあるネットワークでは、n-1回の再送信が行われます。これは、[MOBICOM99]で説明されている「ブロードキャストストーム」の問題を簡単に引き起こす可能性があります。この攻撃の結果、チャネルの負荷が増加します。その原因は攻撃者以外のルーターにあるようです。
Given the topology shown in Figure 2, on receiving a packet with seq=n, the attacker X can forward the packet with a modified sequence number n+i. This has two consequences: firstly, router C will not be able to detect that the packet forwarded by X is a duplicate packet; secondly, the consequent packet with seq=n+i generated by router A will probably be treated as a duplicate packet and will be dropped by router C.
図2に示すトポロジを前提として、seq = nのパケットを受信すると、攻撃者Xは変更されたシーケンス番号n + iのパケットを転送できます。これには2つの影響があります。1つ目は、ルーターCは、Xによって転送されたパケットが重複パケットであることを検出できないことです。次に、ルーターAによって生成されたseq = n + iの後続のパケットは、おそらく重複パケットとして扱われ、ルーターCによってドロップされます。
When explicit sequence numbers in packet headers is undesired, hash-based DPD can be used. A hash of the non-mutable fields in the header of the data payload can be generated and recorded at the intermediate routers. A packet can thus be uniquely identified by the source IP address of the packet and its hash-value.
パケットヘッダーの明示的なシーケンス番号が望ましくない場合は、ハッシュベースのDPDを使用できます。データペイロードのヘッダー内の変更不可能なフィールドのハッシュは、中間ルーターで生成および記録できます。したがって、パケットは、パケットの送信元IPアドレスとそのハッシュ値によって一意に識別できます。
The hash algorithm used by SMF is being applied only to provide a reduced probability of collision and is not being used for cryptographic or authentication purposes. Consequently, a digest collision is still possible. In case the source router or gateway identifies that it has recently generated or injected a packet with the same hash-value, it inserts a "Hash-Assist Value (HAV)" IPv6 header option into the packet, such that also calculating the hash over this HAV will render the resulting value unique.
SMFによって使用されるハッシュアルゴリズムは、衝突の確率を減らすためにのみ適用されており、暗号化や認証の目的には使用されていません。その結果、ダイジェストの衝突がまだ可能です。ソースルーターまたはゲートウェイは、同じハッシュ値を持つパケットを最近生成または挿入したことを識別した場合、「ハッシュアシスト値（HAV）」IPv6ヘッダーオプションをパケットに挿入します。このHAVは、結果の値を一意にします。
The HAV header is helpful when a digest collision happens. However, it also introduces a potential vulnerability. As the HAV option is only added when the source or the ingress SMF router detects that the incoming packet has digest collision with previously generated packets, it can actually be regarded as a "flag" of potential digest collision. An attacker can discover the HAV header and be able to conclude that a hash collision is possible if the HAV header is removed. By doing so, the modified packet received by other SMF routers will be treated as duplicate packets and will be dropped because they have the same hash value as previously received packets.
HAVヘッダーは、ダイジェストの衝突が発生したときに役立ちます。ただし、潜在的な脆弱性も持ち込みます。 HAVオプションが追加されるのは、ソースまたは入力SMFルーターが、着信パケットに以前に生成されたパケットとのダイジェスト衝突があることを検出した場合のみなので、実際には潜在的なダイジェスト衝突の「フラグ」と見なすことができます。攻撃者はHAVヘッダーを発見し、HAVヘッダーが削除された場合にハッシュの衝突が発生する可能性があると結論付けることができます。そうすることで、他のSMFルーターが受信した変更されたパケットは重複パケットとして扱われ、以前に受信したパケットと同じハッシュ値を持っているため、ドロップされます。
In the example shown in Figure 3, routers A and B are legitimate SMF routers; X is an attacker. Router A generates two packets, P1 and P2, with the same hash value h(P1)=h(P2)=x. Based on the SMF specification, a HAV is added to the latter packet P2, so that h(P2+HAV)=x' avoids digest collision. When the attacker X detects the HAV of P2, it is able to conclude that a collision is possible by removing the HAV header. By doing so, packet P2 will be treated as a duplicate packet by router B and will be dropped.
図3に示す例では、ルーターAおよびBが正当なSMFルーターです。 Xは攻撃者です。ルータAは、同じハッシュ値h（P1）= h（P2）= xを持つ2つのパケットP1とP2を生成します。 SMF仕様に基づいて、後者のパケットP2にHAVが追加されるため、h（P2 + HAV）= x 'はダイジェストの衝突を回避します。攻撃者XがP2のHAVを検出すると、HAVヘッダーを削除することで衝突が可能であると結論付けることができます。そうすることで、パケットP2はルーターBによって重複パケットとして扱われ、ドロップされます。
P2 P1 P2 P1
.---. h(P2+HAV)=x' h(P1)=x .---. h(P2)=x h(P1)=x .---.
| A |---------------------------> | X | ----------------------> | B |
`---' `---' `---'
Figure 3
図3
A framework for an RSS mechanism, rather than a specific RSS algorithm, is provided by SMF. Relay Set Selection is normally achieved by distributed algorithms that can dynamically generate a topological Connected Dominating Set based on 1-hop and 2-hop neighborhood information. In this section, common threats to the RSS framework are first discussed. Then specific threats to the three algorithms (Essential Connection Dominating Set (E-CDS), Source-Based Multipoint Relay (S-MPR), and Multipoint Relay Connected Dominating Set (MPR-CDS)) explicitly enumerated by [RFC6621] are analyzed. As the relay set selection is based on 1-hop and 2-hop neighborhood information, which rely on NHDP, the threats described in this section are NHDP specific.
特定のRSSアルゴリズムではなく、RSSメカニズムのフレームワークがSMFによって提供されます。リレーセットの選択は、通常、1ホップおよび2ホップの近隣情報に基づいてトポロジー接続接続支配セットを動的に生成できる分散アルゴリズムによって実現されます。このセクションでは、RSSフレームワークに対する一般的な脅威について最初に説明します。次に、[RFC6621]によって明示的に列挙された3つのアルゴリズム（Essential Connection Dominationing Set（E-CDS）、Source-Based Multipoint Relay（S-MPR）、Multipoint Relay Connected Dominationing Set（MPR-CDS））に対する特定の脅威が分析されます。リレーセットの選択は、NHDPに依存する1ホップおよび2ホップの近隣情報に基づいているため、このセクションで説明する脅威はNHDPに固有のものです。
Non-algorithm-specific threats to RSS algorithms, including DoS attacks, eavesdropping, message timing attacks, and broadcast storm, are discussed in [RFC7186].
DoS攻撃、盗聴、メッセージタイミング攻撃、ブロードキャストストームなど、RSSアルゴリズムに対するアルゴリズム固有でない脅威については、[RFC7186]で説明されています。
The "Essential Connected Dominating Set" (E-CDS) algorithm [RFC5614] forms a single CDS mesh for an SMF operating region. This algorithm requires 2-hop neighborhood information (the identity of the neighbors, the link to the neighbors, and the neighbors' priority information), as collected through NHDP or another process.
「エッセンシャルコネクテッドドミネーティングセット」（E-CDS）アルゴリズム[RFC5614]は、SMF動作領域の単一のCDSメッシュを形成します。このアルゴリズムには、NHDPまたは別のプロセスを通じて収集される2ホップの近隣情報（近隣のID、近隣へのリンク、および近隣の優先情報）が必要です。
An SMF router will select itself as a relay, if:
SMFルーターは、次の場合にそれ自体をリレーとして選択します。
o The SMF router has a higher priority than all of its symmetric neighbors, or
o SMFルーターは、そのすべての対称ネイバーよりも高い優先順位を持っている、または
o A path from the neighbor with the largest priority to any other neighbor via neighbors with greater priority than the current router does not exist.
o 最大の優先度を持つネイバーから、現在のルーターよりも高い優先度を持つネイバー経由で他のネイバーへのパスは存在しません。
An attacker can disrupt the E-CDS algorithm by link spoofing or identity spoofing.
攻撃者は、リンクスプーフィングまたはIDスプーフィングによってE-CDSアルゴリズムを妨害する可能性があります。
Link spoofing implies that an attacker advertises non-existing links to another router (which may or may not be present in the network).
リンクスプーフィングとは、攻撃者が存在しないリンクを別のルーター（ネットワークに存在する場合としない場合がある）にアドバタイズすることを意味します。
An attacker can declare itself to have high route priority and spoof the links to as many legitimate SMF routers as possible to declare high connectivity. By doing so, it can prevent legitimate SMF routers from selecting themselves as relays. As the "super" relay in the network, the attacker can manipulate the traffic it relays.
攻撃者は、ルートの優先度が高いことを宣言し、できるだけ多くの正当なSMFルーターへのリンクをスプーフィングして、高い接続を宣言できます。そうすることで、正当なSMFルーターが自身をリレーとして選択するのを防ぐことができます。攻撃者はネットワークの「スーパー」リレーとして、リレーするトラフィックを操作できます。
Identity spoofing implies that an attacker determines and makes use of the identity of other legitimate routers, without being authorized to do so. The identity of other routers can be obtained by eavesdropping the control messages or the source/destination address from datagrams. The attacker can then generate control or datagram traffic by pretending to be a legitimate router.
IDスプーフィングとは、攻撃者が他の正当なルーターのIDを決定および利用することを意味します。他のルーターのIDは、データグラムから制御メッセージまたは送信元/宛先アドレスを盗聴することによって取得できます。攻撃者は、正当なルーターになりすますことにより、制御トラフィックまたはデータグラムトラフィックを生成できます。
Because E-CDS self-selection is based on the router priority value, an attacker can spoof the identity of other legitimate routers and declare a different router priority value. If it declares that a spoofed router has a higher priority, it can prevent other routers from selecting themselves as relays. On the other hand, if the attacker declares that a spoofed router has a lower priority, it can force other routers to select themselves as relays to degrade the multicast forwarding to classical flooding.
E-CDSの自己選択はルーターの優先度の値に基づいているため、攻撃者は他の正当なルーターのIDを偽装し、別のルーターの優先度の値を宣言できます。スプーフィングされたルーターの優先度が高いと宣言すると、他のルーターがリレーとして選択されるのを防ぐことができます。一方、スプーフィングされたルーターの優先度が低いことを攻撃者が宣言した場合、他のルーターを強制的にリレーとして選択して、マルチキャスト転送を従来のフラッディングに低下させることができます。
The S-MPR set selection algorithm enables individual routers, using 2-hop topology information, to select relays from among their set of neighboring routers. MPRs are selected by each router such that a message generated by it, and relayed only by its MPRs, will reach all of its 2-hop neighbors.
S-MPRセット選択アルゴリズムにより、2ホップのトポロジ情報を使用して、個々のルーターが隣接ルーターのセットの中からリレーを選択できるようになります。 MPRは、ルーターによって生成され、そのMPRによってのみ中継されるメッセージが2ホップのネイバーすべてに到達するように、各ルーターによって選択されます。
An SMF router forwards a multicast packet if and only if:
SMFルーターは、次の場合に限り、マルチキャストパケットを転送します。
o the packet has not been received before, and
o パケットは以前に受信されていません。
o the neighbor from which the packet was received has selected the router as MPR.
o パケットの受信元のネイバーがルーターをMPRとして選択しています。
Because MPR calculation is based on the willingness declared by the SMF routers and the connectivity of the routers, it can be disrupted by both link spoofing and identity spoofing. These threats and their impacts have been illustrated in Section 5.1 of [RFC7186].
MPR計算は、SMFルーターによって宣言された自発性とルーターの接続性に基づいているため、リンクスプーフィングとIDスプーフィングの両方によって中断される可能性があります。これらの脅威とその影響は、[RFC7186]のセクション5.1に示されています。
MPR-CDS is a derivative from S-MPR. The main difference between S-MPR and MPR-CDS is that while S-MPR forms a different broadcast tree for each source in the network, MPR-CDS forms a unique broadcast tree for all sources in the network.
MPR-CDSはS-MPRから派生したものです。 S-MPRとMPR-CDSの主な違いは、S-MPRはネットワーク内のソースごとに異なるブロードキャストツリーを形成するのに対し、MPR-CDSはネットワーク内のすべてのソースに対して一意のブロードキャストツリーを形成することです。
As MPR-CDS combines E-CDS and S-MPR and the simple combination of the two algorithms does not address the weaknesses; the vulnerabilities of E-CDS and S-MPR that are discussed in Sections 5.2 and 5.3 apply to MPR-CDS also.
MPR-CDSはE-CDSとS-MPRを組み合わせており、2つのアルゴリズムの単純な組み合わせでは弱点に対処できません。セクション5.2および5.3で説明されているE-CDSおよびS-MPRの脆弱性は、MPR-CDSにも適用されます。
This document does not specify a protocol or a procedure. The whole document, however, reflects on security considerations for SMF regarding packet dissemination in MANETs. Possible attacks to the two main functional components of SMF, duplicate packet detection, and relay set selection are analyzed and documented.
このドキュメントでは、プロトコルや手順を指定していません。ただし、ドキュメント全体は、MANETでのパケット配布に関するSMFのセキュリティに関する考慮事項を反映しています。 SMFの2つの主要な機能コンポーネントに対する潜在的な攻撃、重複パケット検出、およびリレーセットの選択が分析され、文書化されます。
Although neither [RFC6621] nor this document propose mechanisms to secure the SMF protocol, there are several possibilities to secure the protocol in the future and drive new work by suggesting which threats discussed in the previous sections could be addressed.
[RFC6621]もこのドキュメントもSMFプロトコルを保護するメカニズムを提案していませんが、前のセクションで説明した脅威に対処できることを示唆することにより、将来プロトコルを保護し、新しい作業を推進する可能性がいくつかあります。
For the I-DPD mechanism, employing randomized packet sequence numbers can avoid some pre-activation attacks based on sequence number prediction. If predicable sequence numbers have to be used, applying timestamps can mitigate pre-activation attacks.
I-DPDメカニズムの場合、ランダム化されたパケットシーケンス番号を使用すると、シーケンス番号の予測に基づくいくつかの事前アクティブ化攻撃を回避できます。予測可能なシーケンス番号を使用する必要がある場合、タイムスタンプを適用すると、アクティベーション前の攻撃を軽減できます。
For the H-DPD mechanism, applying cryptographically strong hashes can make the digest collisions effectively impossible, and it can avoid the use of a HAV.
H-DPDメカニズムの場合、暗号的に強力なハッシュを適用すると、ダイジェストの衝突を事実上不可能にし、HAVの使用を回避できます。
[RFC7182] specifies a framework for representing cryptographic Integrity Check Values (ICVs) and timestamps in MANETs. Based on [RFC7182], [RFC7183] specifies integrity and replay protection for NHDP using shared keys as a mandatory-to-implement security mechanism. If SMF is using NHDP as the neighborhood discovery protocol, implementing [RFC7183] remains advisable so as to enable integrity protection for NHDP control messages. This can help mitigate threats related to identity spoofing through the exchange of HELLO messages and provide some general protection against identity spoofing by admitting only trusted routers to the network using ICVs in HELLO messages.
[RFC7182]は、MANETで暗号整合性チェック値（ICV）とタイムスタンプを表すためのフレームワークを指定します。 [RFC7182]に基づいて、[RFC7183]は、実装に必須のセキュリティメカニズムとして共有キーを使用して、NHDPの整合性とリプレイ保護を指定します。 SMFがNHDPを近隣探索プロトコルとして使用している場合、NHDP制御メッセージの完全性保護を有効にするために、[RFC7183]の実装は引き続き推奨されます。これは、HELLOメッセージの交換を通じてIDスプーフィングに関連する脅威を緩和し、HELLOメッセージのICVを使用してネットワークに信頼できるルーターのみを許可することにより、IDスプーフィングに対する一般的な保護を提供します。
Using ICVs does not, of course, address the problem of attackers able to also generate valid ICVs. Detection and exclusion of such attackers is, in general, a challenge that is not unrelated to how [RFC7182] is used. If, for example, it is used with a shared key (as per [RFC7183]), excluding single attackers generally is not aided by the use of ICVs. However, if routers have sufficient capabilities to support the use of asymmetric keys (as per [RFC7859]), part of addressing this challenge becomes one of providing key revocation in a way that does not in itself introduce additional vulnerabilities.
もちろん、ICVを使用しても、有効なICVを生成できる攻撃者の問題には対処しません。そのような攻撃者の検出と除外は、一般に、[RFC7182]の使用方法と無関係ではない課題です。たとえば、（[RFC7183]のように）共有キーと共に使用される場合、単一の攻撃者を除外することは、一般にICVの使用によって支援されません。ただし、ルーターに非対称キーの使用をサポートするのに十分な機能がある場合（[RFC7859]による）、この課題への対処の一部は、それ自体が追加の脆弱性を導入しない方法でキー失効を提供することになります。
As [RFC7183] does not protect the integrity of the multicast user datagram, and as no mechanism is specified by SMF for doing so, duplicate packet detection remains vulnerable to the threats introduced in Section 4.
[RFC7183]はマルチキャストユーザーデータグラムの整合性を保護せず、SMFによってそのようにするメカニズムが指定されていないため、重複パケット検出は、セクション4で導入された脅威に対して脆弱なままです。
If pre-activation/de-activation attacks and attacks on the HAV of the multicast datagrams are to be mitigated, a datagram-level integrity protection mechanism is desired, by taking consideration of the identity field or HAV. However, this would not be helpful for the attacks on the TTL (or Hop Limit for IPv6) field, because the mutable fields are generally not considered when ICV is calculated.
事前アクティブ化/非アクティブ化攻撃およびマルチキャストデータグラムのHAVに対する攻撃を軽減する必要がある場合は、IDフィールドまたはHAVを考慮して、データグラムレベルの整合性保護メカニズムが必要です。ただし、ICVが計算されるときに変更可能なフィールドは通常考慮されないため、これはTTL（またはIPv6のホップ制限）フィールドへの攻撃には役立ちません。
[RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, DOI 10.17487/RFC6130, April 2011, <http://www.rfc-editor.org/info/rfc6130>.
[RFC6130] Clausen、T.、Dearlove、C。、およびJ. Dean、「Mobile Ad Hoc Network（MANET）Neighborhood Discovery Protocol（NHDP）」、RFC 6130、DOI 10.17487 / RFC6130、2011年4月、<http：// www.rfc-editor.org/info/rfc6130>。
[RFC6621] Macker, J., Ed., "Simplified Multicast Forwarding", RFC 6621, DOI 10.17487/RFC6621, May 2012, <http://www.rfc-editor.org/info/rfc6621>.
[RFC6621] Macker、J。、編、「Simplified Multicast Forwarding」、RFC 6621、DOI 10.17487 / RFC6621、2012年5月、<http://www.rfc-editor.org/info/rfc6621>。
[RFC7186] Yi, J., Herberg, U., and T. Clausen, "Security Threats for the Neighborhood Discovery Protocol (NHDP)", RFC 7186, DOI 10.17487/RFC7186, April 2014, <http://www.rfc-editor.org/info/rfc7186>.
[RFC7186] Yi、J.、Herberg、U。、およびT. Clausen、「Neighborhood Discovery Protocol（NHDP）のセキュリティ脅威」、RFC 7186、DOI 10.17487 / RFC7186、2014年4月、<http：//www.rfc -editor.org/info/rfc7186>。
[MOBICOM99] Ni, S., Tseng, Y., Chen, Y., and J. Sheu, "The broadcast storm problem in a mobile ad hoc network", MobiCom '99 Proceedings of the 5th annual ACM/IEEE international conference on Mobile computing and networking, DOI 10.1145/313451.313525, 1999.
[MOBICOM99] Ni、S.、Tseng、Y.、Chen、Y.、J。Sheu、「モバイルアドホックネットワークにおけるブロードキャストストームの問題」、MobiCom '99 Proceedings of the 5th Annual ACM / IEEE International Conference onモバイルコンピューティングとネットワーキング、DOI 10.1145 / 313451.313525、1999。
[MPR-CDS] Adjih, C., Jacquet, P., and L. Viennot, "Computing Connected Dominating Sets with Multipoint Relays", Journal of Ad Hoc and Sensor Wireless Networks 2002, January 2002.
[MPR-CDS] Adjih、C.、Jacquet、P。、およびL. Viennot、「マルチポイントリレーによる接続された支配セットの計算」、ジャーナルアドホックおよびセンサーワイヤレスネットワーク2002、2002年1月。
[RFC3626] Clausen, T., Ed. and P. Jacquet, Ed., "Optimized Link State Routing Protocol (OLSR)", RFC 3626, DOI 10.17487/RFC3626, October 2003, <http://www.rfc-editor.org/info/rfc3626>.
[RFC3626]クラウセン、T。、エド。およびP. Jacquet編、「Optimized Link State Routing Protocol（OLSR）」、RFC 3626、DOI 10.17487 / RFC3626、2003年10月、<http://www.rfc-editor.org/info/rfc3626>。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <http://www.rfc-editor.org/info/rfc4949>.
[RFC4949] Shirey、R。、「インターネットセキュリティ用語集、バージョン2」、FYI 36、RFC 4949、DOI 10.17487 / RFC4949、2007年8月、<http://www.rfc-editor.org/info/rfc4949>。
[RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter Considerations in Mobile Ad Hoc Networks (MANETs)", RFC 5148, DOI 10.17487/RFC5148, February 2008, <http://www.rfc-editor.org/info/rfc5148>.
[RFC5148] Clausen、T.、Dearlove、C。、およびB. Adamson、「モバイルアドホックネットワーク（MANET）におけるジッタの考慮事項」、RFC 5148、DOI 10.17487 / RFC5148、2008年2月、<http：//www.rfc -editor.org/info/rfc5148>。
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format", RFC 5444, DOI 10.17487/RFC5444, February 2009, <http://www.rfc-editor.org/info/rfc5444>.
[RFC5444] Clausen、T.、Dearlove、C.、Dean、J。、およびC. Adjih、「Generalized Mobile Ad Hoc Network（MANET）Packet / Message Format」、RFC 5444、DOI 10.17487 / RFC5444、2009年2月、< http://www.rfc-editor.org/info/rfc5444>。
[RFC5614] Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding", RFC 5614, DOI 10.17487/RFC5614, August 2009, <http://www.rfc-editor.org/info/rfc5614>.
[RFC5614] Ogier、R。およびP. Spagnolo、「モバイル接続アドホックネットワーク（MANET）のOSPFの接続された支配セット（CDS）フラッディングを使用した拡張」、RFC 5614、DOI 10.17487 / RFC5614、2009年8月、<http：// www .rfc-editor.org / info / rfc5614>。
[RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, "The Optimized Link State Routing Protocol Version 2", RFC 7181, DOI 10.17487/RFC7181, April 2014, <http://www.rfc-editor.org/info/rfc7181>.
[RFC7181] Clausen、T.、Dearlove、C.、Jacquet、P。、およびU. Herberg、「The Optimized Link State Routing Protocol Version 2」、RFC 7181、DOI 10.17487 / RFC7181、2014年4月、<http：// www.rfc-editor.org/info/rfc7181>。
[RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)", RFC 7182, DOI 10.17487/RFC7182, April 2014, <http://www.rfc-editor.org/info/rfc7182>.
[RFC7182] Herberg、U.、Clauseen、T。、およびC. Dearlove、「モバイルアドホックネットワーク（MANET）の整合性チェック値とタイムスタンプTLV定義」、RFC 7182、DOI 10.17487 / RFC7182、2014年4月、<http： //www.rfc-editor.org/info/rfc7182>。
[RFC7183] Herberg, U., Dearlove, C., and T. Clausen, "Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)", RFC 7183, DOI 10.17487/RFC7183, April 2014, <http://www.rfc-editor.org/info/rfc7183>.
[RFC7183] Herberg、U.、Dearlove、C。、およびT. Clausen、「Integrity Protection for the Neighborhood Discovery Protocol（NHDP）and Optimized Link State Routing Protocol Version 2（OLSRv2）」、RFC 7183、DOI 10.17487 / RFC7183、 2014年4月、<http://www.rfc-editor.org/info/rfc7183>。
[RFC7859] Dearlove, C., "Identity-Based Signatures for Mobile Ad Hoc Network (MANET) Routing Protocols", RFC 7859, DOI 10.17487/RFC7859, May 2016, <http://www.rfc-editor.org/info/rfc7859>.
[RFC7859] Dearlove、C。、「モバイルアドホックネットワーク（MANET）ルーティングプロトコルのIDベースの署名」、RFC 7859、DOI 10.17487 / RFC7859、2016年5月、<http://www.rfc-editor.org/info / rfc7859>。
Acknowledgments
謝辞
The authors would like to thank Christopher Dearlove (BAE Systems ATC) who provided detailed review and valuable comments.
著者は、詳細なレビューと貴重なコメントを提供してくれたChristopher Dearlove（BAE Systems ATC）に感謝します。
Authors' Addresses
著者のアドレス
Jiazi Yi Ecole Polytechnique 91128 Palaiseau Cedex France
Jiazi Yi Ecole Polytechnique 91128パレゾーセデックスフランス
Phone: +33 1 77 57 80 85
Email: jiazi@jiaziyi.com
URI: http://www.jiaziyi.com/
Thomas Heide Clausen Ecole Polytechnique 91128 Palaiseau Cedex France
Thomas Heide Clausen Ecole Polytechnique 91128パレゾーセデックスフランス
Phone: +33 6 6058 9349
Email: T.Clausen@computer.org
URI: http://www.thomasclausen.org/
Ulrich Herberg
ウルリッヒ・ヘルベルク
Email: ulrich@herberg.name
URI: http://www.herberg.name/