[要約] RFC 8116は、OLSRv2に対するセキュリティ脅威についての情報を提供するものです。このRFCの目的は、OLSRv2の脆弱性を特定し、それに対する対策を提案することです。
Internet Engineering Task Force (IETF) T. Clausen
Request for Comments: 8116
Category: Informational U. Herberg
ISSN: 2070-1721
J. Yi
Ecole Polytechnique
May 2017
Security Threats to the Optimized Link State Routing Protocol Version 2 (OLSRv2)
最適化されたリンクステートルーティングプロトコルバージョン2（OLSRv2）に対するセキュリティの脅威
Abstract
概要
This document analyzes common security threats to the Optimized Link State Routing Protocol version 2 (OLSRv2) and describes their potential impacts on Mobile Ad Hoc Network (MANET) operations. It also analyzes which of these security vulnerabilities can be mitigated when using the mandatory-to-implement security mechanisms for OLSRv2 and how the vulnerabilities are mitigated.
このドキュメントでは、最適化されたリンク状態ルーティングプロトコルバージョン2（OLSRv2）に対する一般的なセキュリティの脅威を分析し、モバイルアドホックネットワーク（MANET）の運用への潜在的な影響について説明します。また、OLSRv2の実装に必須のセキュリティメカニズムを使用する場合に軽減できるセキュリティの脆弱性と、それらの脆弱性がどのように軽減されるかについても分析します。
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 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). 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）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc8116.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8116で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. OLSRv2 Overview . . . . . . . . . . . . . . . . . . . . . 5
1.1.1. Neighborhood Discovery . . . . . . . . . . . . . . . 5
1.1.2. MPR Selection . . . . . . . . . . . . . . . . . . . . 6
1.1.3. Link State Advertisement . . . . . . . . . . . . . . 6
1.2. Link State Vulnerability Taxonomy . . . . . . . . . . . . 6
1.3. OLSRv2 Attack Vectors . . . . . . . . . . . . . . . . . . 7
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Topology Map Acquisition . . . . . . . . . . . . . . . . . . 7
3.1. Attack on Jittering . . . . . . . . . . . . . . . . . . . 8
3.2. Hop Count and Hop Limit Attacks . . . . . . . . . . . . . 8
3.2.1. Modifying the Hop Limit . . . . . . . . . . . . . . . 8
3.2.2. Modifying the Hop Count . . . . . . . . . . . . . . . 9
4. Effective Topology . . . . . . . . . . . . . . . . . . . . . 10
4.1. Incorrect Forwarding . . . . . . . . . . . . . . . . . . 10
4.2. Wormholes . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Sequence Number Attacks . . . . . . . . . . . . . . . . . 12
4.3.1. Message Sequence Number . . . . . . . . . . . . . . . 12
4.3.2. Advertised Neighbor Sequence Number (ANSN) . . . . . 12
4.4. Indirect Jamming . . . . . . . . . . . . . . . . . . . . 12
5. Inconsistent Topology . . . . . . . . . . . . . . . . . . . . 15
5.1. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 15
5.2. Link Spoofing . . . . . . . . . . . . . . . . . . . . . . 17
5.2.1. Inconsistent Topology Maps Due to Link State
Advertisements . . . . . . . . . . . . . . . . . . . 18
6. Mitigation of Security Vulnerabilities for OLSRv2 . . . . . . 19
6.1. Inherent OLSRv2 Resilience . . . . . . . . . . . . . . . 19
6.2. Resilience by Using RFC 7183 with OLSRv2 . . . . . . . . 20
6.2.1. Topology Map Acquisition . . . . . . . . . . . . . . 21
6.2.2. Effective Topology . . . . . . . . . . . . . . . . . 21
6.2.3. Inconsistent Topology . . . . . . . . . . . . . . . . 22
6.3. Correct Deployment . . . . . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Normative References . . . . . . . . . . . . . . . . . . 23
8.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
The Optimized Link State Routing Protocol version 2 (OLSRv2)
[RFC7181] is a successor to OLSR [RFC3626] as a routing protocol for
Mobile Ad Hoc Networks (MANETs). OLSRv2 retains the same basic
algorithms as its predecessor; however, it offers various
improvements, e.g., a modular and flexible architecture allowing
extensions (such as for security) to be developed as add-ons to the
basic protocol. Such building blocks and modules include [RFC5148],
[RFC5444], [RFC5497], [RFC6130], [RFC7182], [RFC7183], [RFC7187],
[RFC7188], [RFC7466], etc.
The developments reflected in OLSRv2 have been motivated by increased real-world deployment experiences, e.g., from networks such as FunkFeuer [FUNKFEUER], and the requirements to be addressed for continued successful operation of these networks. With participation in such networks increasing (the FunkFeuer community network has, e.g., roughly 400 individual participants at the time of publication of this document), operating under the assumption that participants can be "trusted" to behave in a non-destructive way, is naive. With deployment in the wider Internet, and a resultant increase in user numbers, an increase in attacks and abuses has followed necessitating a change in recommended practices. For example, SMTP servers, which were initially available for use by everyone on the Internet, require authentication and accounting for users today [RFC5068].
OLSRv2に反映された開発は、たとえばFunkFeuer [FUNKFEUER]などのネットワークからの現実の展開経験の増加と、これらのネットワークの継続的な正常な運用のために対処する必要がある要件によって動機付けられています。このようなネットワークへの参加が増加するにつれて（FunkFeuerコミュニティネットワークには、たとえば、このドキュメントの公開時点で約400人の個々の参加者がいます）、参加者は非破壊的な動作を「信頼できる」と見なすことができます。素朴。広域インターネットへの展開とそれに伴うユーザー数の増加に伴い、攻撃と悪用の増加に伴い、推奨プラクティスの変更が必要となっています。たとえば、当初インターネットの誰もが使用できるSMTPサーバーは、今日のユーザーの認証とアカウンティングを必要としています[RFC5068]。
As OLSRv2 is often used in wireless environments, it is potentially exposed to different kinds of security threats, some of which are of greater significance when compared to wired networks. As radio signals can be received as well as transmitted by any compatible wireless device within radio range, there are commonly no physical constraints on the conformation of nodes and communication links that make up the network (as could be expected for wired networks).
OLSRv2はワイヤレス環境でよく使用されるため、さまざまな種類のセキュリティの脅威にさらされる可能性があり、有線のネットワークと比較した場合、そのいくつかはより重要です。無線信号は、無線範囲内の任意の互換性のあるワイヤレスデバイスによって受信および送信できるため、通常、ネットワークを構成するノードおよび通信リンクのコンフォーメーションに物理的な制約はありません（有線ネットワークで予想されるように）。
A first step towards hardening against attacks disrupting the connectivity of a network is to understand the vulnerabilities of the routing protocol managing the connectivity. Therefore, this document analyzes OLSRv2 in order to understand its inherent vulnerabilities and resilience. The authors do not claim completeness of the analysis but hope that the identified attacks, as presented, form a meaningful starting point for developing and deploying increasingly well-secured OLSRv2 networks.
ネットワークの接続を妨害する攻撃に対する強化に向けた最初のステップは、接続を管理するルーティングプロトコルの脆弱性を理解することです。したがって、このドキュメントでは、固有の脆弱性と回復力を理解するためにOLSRv2を分析します。著者は分析の完全性を主張しませんが、提示されているように、特定された攻撃がますますセキュリティが強化されたOLSRv2ネットワークを開発および展開するための有意義な出発点を形成することを願っています。
This document describes security vulnerabilities of OLSRv2 when it is used without the mandatory-to-implement security mechanisms, as specified in Section 23.5 of [RFC7181]. It also analyzes which of these security vulnerabilities can be mitigated when using the mandatory-to-implement security mechanisms for OLSRv2 and how the vulnerabilities are mitigated. This separation is important since, as explicitly stated in [RFC7181]:
このドキュメントでは、[RFC7181]のセクション23.5で指定されている、実装が必須のセキュリティメカニズムなしでOLSRv2を使用した場合のセキュリティの脆弱性について説明します。また、OLSRv2の実装に必須のセキュリティメカニズムを使用する場合に軽減できるセキュリティの脆弱性と、それらの脆弱性がどのように軽減されるかについても分析します。 [RFC7181]で明示的に述べられているように、この分離は重要です。
Any deployment of OLSRv2 SHOULD use the security mechanism specified in [RFC7183] but MAY use another mechanism if more appropriate in an OLSRv2 deployment. For example, for longer-term OLSRv2 deployments, alternative security mechanisms (e.g., rekeying) SHOULD be considered.
OLSRv2の展開では、[RFC7183]で指定されたセキュリティメカニズムを使用する必要があります（SHOULD）が、OLSRv2の展開でより適切な場合は、別のメカニズムを使用できます（MAY）。たとえば、長期間のOLSRv2展開では、代替のセキュリティメカニズム（たとえば、キーの再生成）を検討する必要があります（SHOULD）。
Moreover, this document is also based on the assumption that no additional security mechanism such as IPsec is used in the IP layer, or other mechanisms on lower layers, as not all MANET deployments may be able to accommodate such common protection mechanisms (e.g., because of limited resources of MANET routers).
さらに、このドキュメントは、すべてのMANET展開がそのような一般的な保護メカニズムに対応できるとは限らないため、IPレイヤーや下位レイヤーの他のメカニズムでIPsecなどの追加のセキュリティメカニズムが使用されないという前提に基づいています（たとえば、 MANETルーターの限られたリソースの）。
As NHDP is a fundamental component of OLSRv2, the vulnerabilities of NHDP, discussed in [RFC7186], also apply to OLSRv2.
NHDPはOLSRv2の基本的なコンポーネントであるため、[RFC7186]で説明されているNHDPの脆弱性はOLSRv2にも当てはまります。
It should be noted that many OLSRv2 implementations are configurable, and so an attack on the configuration system (such as [RFC7939] and [RFC7184]) can be used to adversely affect the operation of an OLSRv2 implementation.
多くのOLSRv2実装は構成可能であるため、構成システムへの攻撃（[RFC7939]や[RFC7184]など）を使用して、OLSRv2実装の動作に悪影響を及ぼす可能性があることに注意してください。
OLSRv2 contains three basic processes: neighborhood discovery, Multipoint Relay (MPR) selection, and Link State Advertisements (LSAs). They are described in the sections below with sufficient details to allow elaboration of the analyses in this document.
OLSRv2には、近隣探索、マルチポイントリレー（MPR）選択、リンク状態アドバタイズ（LSA）の3つの基本的なプロセスが含まれています。これらについては、このドキュメントの分析を詳しく説明できるように、以下のセクションで詳しく説明します。
Neighborhood discovery is the process whereby each router discovers the routers that are in direct communication range of itself (1-hop neighbors) and detects with which of these it can establish bidirectional communication. Each router sends HELLO messages periodically, listing the identifiers of all the routers from which it has recently received a HELLO message as well as the "status" of the link (heard or verified bidirectional). A router A receiving a HELLO message from a neighbor router B, in which B indicates it has recently received a HELLO message from A, considers the link A-B to be bidirectional. As B lists identifiers of all its neighbors in its HELLO message, A learns the "neighbors of its neighbors" (2-hop neighbors) through this process. HELLO messages are sent periodically; however, certain events may trigger non-periodic HELLOs. OLSRv2 [RFC7181] uses NHDP [RFC6130] as its neighborhood discovery mechanism. The vulnerabilities of NHDP are analyzed in [RFC7186].
近隣探索は、各ルーターが自身の直接通信範囲内にあるルーター（1ホップの近隣）を発見し、双方向通信を確立できるルーターを検出するプロセスです。各ルーターはHELLOメッセージを定期的に送信し、HELLOメッセージを最近受信したすべてのルーターの識別子とリンクの "ステータス"（双方向またはハードウェアで確認済み）を一覧表示します。隣接ルータBからHELLOメッセージを受信するルータAは、BがAから最近HELLOメッセージを受信したことを示し、リンクA-Bが双方向であると見なします。 BはHELLOメッセージにすべてのネイバーの識別子をリストしているので、Aはこのプロセスを通じて「ネイバーのネイバー」（2ホップネイバー）を学習します。 HELLOメッセージは定期的に送信されます。ただし、特定のイベントが非定期的なHELLOをトリガーする場合があります。 OLSRv2 [RFC7181]は、NHDP [RFC6130]を近隣探索メカニズムとして使用します。 NHDPの脆弱性は[RFC7186]で分析されています。
Multipoint Relay (MPR) selection is the process whereby each router is able to identify a set of relays for efficiently conducting network-wide broadcasts. Each router designates, from among its bidirectional neighbors, a subset (the "MPR set") such that an OLSRv2-specific multicast message transmitted by the router and relayed by the MPR set can be received by all its 2-hop neighbors. MPR selection is encoded in outgoing NHDP HELLO messages.
マルチポイントリレー（MPR）の選択は、各ルーターが一連のリレーを識別して、ネットワーク全体のブロードキャストを効率的に実行できるようにするプロセスです。各ルーターは、双方向ネイバーの中からサブセット（「MPRセット」）を指定します。これにより、ルーターによって送信され、MPRセットによって中継されるOLSRv2固有のマルチキャストメッセージを、その2ホップネイバーすべてで受信できます。 MPR選択は、発信NHDP HELLOメッセージでエンコードされます。
In their HELLO messages, routers may express their "willingness" to be selected as an MPR using an integer between 0 and 7 ("will never" to "will always"). This is taken into consideration for the MPR calculation and is useful, for example, when an OLSRv2 network is "planned". The set of routers having selected a given router as an MPR is the MPR selector set of that router. A study of the MPR flooding algorithm can be found in [MPR-FLOODING].
ルーターはHELLOメッセージで、MPRとして選択される「意欲」を0〜7の整数を使用して表現できます（「決してしない」から「常に」）。これはMPR計算で考慮され、OLSRv2ネットワークが「計画されている」場合などに役立ちます。特定のルーターをMPRとして選択したルーターのセットは、そのルーターのMPRセレクターセットです。 MPRフラッディングアルゴリズムの研究は、[MPR-FLOODING]にあります。
Link State Advertisement (LSA) is the process whereby routers determine which link state information to advertise through the network. Each router must advertise, at least, all links between itself and its MPR selectors in order to allow all routers to calculate shortest paths. Such LSAs are carried in Topology Control (TC) messages, which are broadcast through the network using the MPR flooding process described in Section 1.1.2. As a router selects MPRs only from among bidirectional neighbors, links advertised in TC are also bidirectional and routing paths calculated by OLSRv2 contain only bidirectional links. TCs are sent periodically; however, certain events may trigger non-periodic TCs.
リンク状態アドバタイズ（LSA）は、ルーターがネットワークを介してアドバタイズするリンク状態情報を決定するプロセスです。すべてのルーターが最短経路を計算できるようにするために、各ルーターは少なくとも、ルーターとそのMPRセレクター間のすべてのリンクを通知する必要があります。このようなLSAは、トポロジー制御（TC）メッセージで伝送され、セクション1.1.2で説明されているMPRフラッディングプロセスを使用してネットワークを通じてブロードキャストされます。ルータは双方向ネイバーからのみMPRを選択するため、TCでアドバタイズされるリンクも双方向であり、OLSRv2によって計算されるルーティングパスには双方向リンクのみが含まれます。 TCは定期的に送信されます。ただし、特定のイベントが非定期的なTCをトリガーする場合があります。
Proper functioning of OLSRv2 assumes that:
OLSRv2の適切な機能は、以下を前提としています。
o each router signals its presence in the network and the topology information that it obtained correctly;
o 各ルーターは、ネットワーク内での存在と、正しく取得したトポロジー情報を通知します。
o each router can acquire and maintain a topology map that accurately reflects the effective network topology; and,
o 各ルーターは、有効なネットワークトポロジを正確に反映したトポロジマップを取得して維持できます。そして、
o that the network converges, i.e., that all routers in the network will have sufficiently identical topology maps.
o ネットワークが収束すること、つまり、ネットワーク内のすべてのルーターが十分に同一のトポロジマップを持つこと。
An OLSRv2 network can be disrupted by breaking any of these assumptions, specifically that (a) routers may be prevented from acquiring a topology map of the network, (b) routers may acquire a topology map that does not reflect the effective network topology, and (c) two or more routers may acquire inconsistent topology maps.
OLSRv2ネットワークは、これらの仮定のいずれかを破ることによって混乱する可能性があります。具体的には、（a）ルーターがネットワークのトポロジーマップを取得できない、（b）ルーターが有効なネットワークトポロジーを反映しないトポロジーマップを取得する、および（c）2つ以上のルーターが一貫性のないトポロジーマップを取得する場合があります。
Besides "radio jamming", attacks on OLSRv2 consist of a compromised OLSRv2 router injecting apparently correct, but invalid, control traffic (TCs, HELLOs) into the network. A compromised OLSRv2 router can either (a) advertise erroneous information about itself (its identification and its willingness to serve as an MPR), henceforth called identity spoofing, or (b) advertise erroneous information about its relationship to other routers (pretend existence of links to other routers), henceforth called link spoofing. Such attacks may disrupt the LSA process by targeting the MPR flooding mechanism or by causing incorrect link state information to be included in TCs, causing routers to have incomplete, inaccurate, or inconsistent topology maps. In a different class of attacks, a compromised OLSRv2 router injects control traffic designed so as to cause an in-router resource exhaustion, e.g., by causing the algorithms calculating routing tables or MPR sets to be invoked continuously, preventing the internal state of a router from converging, which depletes the energy of battery-driven routers, etc.
「無線妨害」に加えて、OLSRv2への攻撃は、ネットワークには、明らかに正しいが無効な制御トラフィック（TC、HELLO）を注入する、侵害されたOLSRv2ルーターで構成されています。侵害されたOLSRv2ルーターは、（a）自身に関する誤った情報（そのIDとMPRとして機能する意欲）をアドバタイズする（以降、IDスプーフィングと呼ばれる）か、または（b）他のルーターとの関係に関する誤った情報をアドバタイズする（リンクの存在を装う）他のルーター）、以降、リンクスプーフィングと呼ばれます。このような攻撃は、MPRフラッディングメカニズムをターゲットにすることによって、または不正なリンク状態情報をTCに含めることによってLSAプロセスを混乱させる可能性があり、ルーターが不完全、不正確、または一貫性のないトポロジマップを持つ原因になります。別のクラスの攻撃では、侵害されたOLSRv2ルーターが制御トラフィックを注入して、ルーター内のリソースを使い尽くすように設計されています。たとえば、ルーティングテーブルまたはMPRセットを計算するアルゴリズムが継続的に呼び出され、ルーターの内部状態が妨げられます。バッテリー駆動のルーターなどのエネルギーを枯渇させる収束から
This document uses the terminology and notation defined in [RFC5444], [RFC6130], and [RFC7181]. Additionally, it defines the following terminology:
このドキュメントでは、[RFC5444]、[RFC6130]、および[RFC7181]で定義されている用語と表記法を使用しています。さらに、次の用語を定義します。
Compromised OLSRv2 router: An attacker that eavesdrops on the network traffic and/or generates syntactically correct OLSRv2 control messages. Control messages emitted by a compromised OLSRv2 router may contain additional information or omit information, as compared to a control message generated by a non-compromised OLSRv2 router located in the same topological position in the network.
侵害されたOLSRv2ルーター：ネットワークトラフィックを盗聴したり、構文的に正しいOLSRv2制御メッセージを生成したりする攻撃者。侵害されたOLSRv2ルーターによって送信された制御メッセージは、ネットワーク内の同じトポロジ上の位置にある妥協のないOLSRv2ルーターによって生成された制御メッセージと比較して、追加情報を含むか情報を省略します。
Legitimate OLSRv2 router: An OLSRv2 router that is not a compromised OLSRv2 router.
正規のOLSRv2ルーター：侵害されたOLSRv2ルーターではないOLSRv2ルーター。
Topology Map Acquisition relates to the ability for any given router in the network to acquire a representation of the network connectivity. A router that is unable to acquire a topology map is incapable of calculating routing paths and participating in forwarding data. Topology map acquisition can be hindered by (i) TCs not being delivered to (all) routers in the network, such as what happens in case of flooding disruption, or (ii) in case of "jamming" of the communication channel.
トポロジマップの取得は、ネットワーク内の任意のルーターがネットワーク接続の表現を取得する機能に関連しています。トポロジマップを取得できないルータは、ルーティングパスを計算したり、データの転送に参加したりすることができません。トポロジーマップの取得は、（i）TCがネットワーク内の（すべての）ルーターに配信されていないこと（フラッディングが中断した場合に何が起こるか）、または（ii）通信チャネルが「妨害された」場合に妨げられる可能性があります。
The jamming and flooding disruption due to identity spoofing and link spoofing have been discussed in [RFC7186].
IDスプーフィングとリンクスプーフィングによる妨害とフラッディングの混乱については、[RFC7186]で説明されています。
OLSRv2 incorporates a jittering mechanism: a random, but bounded, delay on outgoing control traffic [RFC5148]. This may be necessary when link layers (such as 802.11 [IEEE802.11]) are used that do not guarantee collision-free delivery of frames and where jitter can reduce the probability of collisions of frames on lower layers.
OLSRv2には、ジッターメカニズムが組み込まれています。つまり、ランダムであるが制限された、発信制御トラフィックの遅延です[RFC5148]。これは、フレームの衝突のない配信を保証しないリンク層（802.11 [IEEE802.11]など）が使用され、ジッターが下位層でのフレームの衝突の確率を低減できる場合に必要になることがあります。
In OLSRv2, TC forwarding is jittered by a value between 0 and MAX_JITTER. In order to reduce the number of transmissions, when a control message is due for transmission, OLSRv2 piggybacks all queued messages into a single transmission. Thus, if a compromised OLSRv2 router sends many TCs within a very short time interval, the jitter time of the attacked router tends towards 0. This renders jittering ineffective and can lead to collisions on the link layer.
OLSRv2では、TC転送は0とMAX_JITTERの間の値によってジッターされます。送信の数を減らすために、OLSRv2は、制御メッセージの送信が予定されているときに、キューに入れられたすべてのメッセージを単一の送信にピギーバックします。したがって、侵害されたOLSRv2ルーターが非常に短い時間間隔で多くのTCを送信する場合、攻撃されたルーターのジッター時間は0に向かう傾向があります。これにより、ジッターが無効になり、リンクレイヤーでの衝突につながる可能性があります。
In addition to causing more collisions, forwarding a TC with little or no jittering can make sure that the TC message forwarded by a compromised router arrives before the message forwarded by legitimate routers. The compromised router can thus inject malicious content in the TC: for example, if the message identification is spoofed, the legitimate message will be discarded as a duplicate message. This preemptive action is important for some of the attacks introduced in the following sections.
より多くの衝突を引き起こすことに加えて、ジッターがほとんどまたはまったくない状態でTCを転送すると、侵害されたルーターによって転送されたTCメッセージが、正当なルーターによって転送されたメッセージよりも前に到着するようになります。したがって、侵害されたルーターはTCに悪意のあるコンテンツを挿入する可能性があります。たとえば、メッセージIDが偽装されている場合、正当なメッセージは重複メッセージとして破棄されます。この先制アクションは、次のセクションで紹介する攻撃のいくつかにとって重要です。
The hop count and hop limit fields are the only parts of a TC that are modified when forwarding; therefore, they are not protected by integrity check mechanisms. A compromised OLSRv2 router can modify either of these when forwarding TCs.
ホップカウントフィールドとホップリミットフィールドは、転送時に変更されるTCの唯一の部分です。したがって、整合性チェックメカニズムによって保護されません。侵害されたOLSRv2ルーターは、TCを転送するときにこれらのいずれかを変更できます。
A compromised OLSRv2 router can decrease the hop limit when forwarding a TC. This will reduce the scope of forwarding for the message and may lead to some routers in the network not receiving that TC. Note that this is not necessarily the same as not relaying the message (i.e., setting the hop limit to 0), as is illustrated in Figure 1.
侵害されたOLSRv2ルーターは、TCを転送するときにホップ制限を減らすことができます。これにより、メッセージの転送範囲が減少し、ネットワーク内の一部のルーターがそのTCを受信できなくなる可能性があります。これは、図1に示すように、メッセージをリレーしない（つまり、ホップ制限を0に設定する）と必ずしも同じではないことに注意してください。
.---.
| X |
--'---' __
/ \
/ \
.---. .---.
TC -----> | A | | C |
'---' '---'
\ .---. /
\-- | B |__/
'---'
Figure 1: Hop Limit Attack
図1：ホップ制限攻撃
A TC arrives at and is forwarded by router A such that it is received by both B and the malicious X. X can forward the TC without any delay (including without jitter) such that its transmissions arrive before that of B at C. Before forwarding, it significantly reduces the hop limit of the message. Router C receives the TC, processes (and forwards) it, and marks it as already received -- causing it to discard further copies received from B. Thus, if the TC is forwarded by C, it has a very low hop limit and will not reach the whole network.
TCはルータAに到着し、ルータAによって転送されるため、Bと悪意のあるXの両方で受信されます。Xは、遅延なく（ジッタなしを含む）TCを転送して、その送信がCのBの前に到着するようにすることができます。 、メッセージのホップ制限を大幅に削減します。ルータCはTCを受信し、処理（および転送）して、すでに受信済みとしてマークします。これにより、Bから受信したそれ以上のコピーが破棄されます。したがって、TCがCによって転送される場合、ホップ制限は非常に低く、ネットワーク全体に到達しない。
A compromised OLSRv2 router can modify the hop count when forwarding a TC. This may have two consequences: (i) if the hop count is set to the maximum value, then the TC will be forwarded no further or (ii) artificially manipulating the hop count may affect the validity time as calculated by recipients, when using distance-dependent validity times as defined in [RFC5497] (e.g., as part of a Fish Eye extension to OLSR2 [OLSR-FSR] [OLSR-FSR-Scaling]).
侵害されたOLSRv2ルーターは、TCを転送するときにホップカウントを変更できます。これは2つの結果をもたらす可能性があります：（i）ホップカウントが最大値に設定されている場合、TCはそれ以上転送されません、または（ii）ホップカウントを人工的に操作すると、距離を使用する場合、受信者が計算した有効時間に影響を与える可能性があります[RFC5497]で定義されているように（たとえば、OLSR2 [OLSR-FSR]へのフィッシュアイ拡張の一部として）[OLSR-FSR-スケーリング]に依存する有効時間。
v_time(3hops)=9s v_time(4hops)=12s v_time(5hops)=15s
.---. .---. .---. .---.
| A |-- ... --> | B | -------> | X |---------->| C |
`---' `---' `---' `---'
Figure 2: Different Validity Times Based on the Distance in Hops
図2：ホップ内の距離に基づくさまざまな有効時間
In Figure 2, router A sends a TC with a validity time of 9 seconds for routers in a 3-hop distance, 12 seconds for routers in a 4-hop distance, and 15 seconds in a 5-hop distance. If X is a compromised OLSRv2 router and modifies the hop count (say, by decreasing it to 3), then C will calculate the validity time of received information to 9 seconds -- after which it expires unless refreshed. If TCs from A are sent less frequently than that up to 4 hops, this causes links advertised in such TCs to be only intermittently available to C.
図2では、ルーターAは、3ホップ距離のルーターの場合は9秒、4ホップ距離のルーターの場合は12秒、5ホップ距離の場合は15秒の有効時間でTCを送信します。 Xが侵害されたOLSRv2ルーターであり、ホップカウントを変更する場合（たとえば、3に減らすことにより）、Cは受信した情報の有効期間を9秒に計算します。その後、更新されない限り、有効期限が切れます。 AからのTCの送信頻度が4ホップまでの頻度よりも低い場合、そのようなTCでアドバタイズされたリンクは、Cで断続的にしか利用できなくなります。
Link state protocols assume that each router can acquire an accurate topology map that reflects the effective network topology. This implies that the routing protocol is able to identify a path from a source to a destination, and this path is valid for forwarding data traffic. If an attacker disturbs the correct protocol behavior, the perceived topology map of a router can permanently differ from the effective topology.
リンク状態プロトコルは、各ルーターが有効なネットワークトポロジを反映する正確なトポロジマップを取得できることを前提としています。これは、ルーティングプロトコルが送信元から宛先へのパスを識別でき、このパスがデータトラフィックの転送に有効であることを意味します。攻撃者が正しいプロトコルの動作を妨害した場合、ルーターの認識されたトポロジーマップは、有効なトポロジーと永続的に異なる可能性があります。
Consider the example in Figure 3(a), which illustrates the topology map as acquired by router S. This topology map indicates that the routing protocol has identified that for S, a path exists to D via B, which it therefore assumes can be used for transmitting data. If B does not forward data traffic from S, then the topology map in S does not accurately reflect the effective network topology. Rather, the effective network topology from the point of view of S would be as indicated in Figure 3(b): D is not part of the network reachable from router S.
ルータSによって取得されたトポロジマップを示す図3（a）の例を考えてみます。このトポロジマップは、ルーティングプロトコルがSについて、B経由でDへのパスが存在することを識別したことを示しています。データ送信用。 BがSからのデータトラフィックを転送しない場合、Sのトポロジマップは有効なネットワークトポロジを正確に反映しません。むしろ、Sの観点から見た効果的なネットワークトポロジは、図3（b）に示すとおりです。Dは、ルーターSから到達可能なネットワークの一部ではありません。
.---. .---. .---. .---. .---.
| S |----| B |----| D | | S |----| B |
`---' `---' `---' `---' `---'
(a) (b)
（a）（b）
Figure 3: Incorrect Data Traffic Forwarding
図3：不正なデータトラフィック転送
Some of the attacks related to NHDP, such as message timing attacks and indirect channel overloading, are discussed in [RFC7186]. Other threats specific to OLSRv2 are further detailed in this section.
メッセージタイミング攻撃や間接チャネルの過負荷など、NHDPに関連する攻撃の一部は、[RFC7186]で説明されています。このセクションでは、OLSRv2に固有のその他の脅威について詳しく説明します。
OLSRv2 routers exchange information using link-local transmissions (link-local multicast or limited broadcast) for their control messages, with the routing process in each router retransmitting received messages destined for network-wide diffusion. Thus, if the operating system in a router is not configured to enable forwarding, this will not affect the operating of the routing protocol or the topology map acquired by the routing protocol. It will, however, cause a discrepancy between the effective topology and the topology map, as indicated in Figures 3(a) and 3(b).
OLSRv2ルーターは、制御メッセージのリンクローカル送信（リンクローカルマルチキャストまたは限定ブロードキャスト）を使用して情報を交換し、各ルーターのルーティングプロセスは、ネットワーク全体の拡散を宛先とする受信メッセージを再送信します。したがって、ルーターのオペレーティングシステムが転送を有効にするように構成されていない場合でも、ルーティングプロトコルの動作やルーティングプロトコルによって取得されたトポロジマップには影響しません。ただし、図3（a）および3（b）に示すように、有効なトポロジとトポロジマップの間に不一致が生じます。
This situation is not hypothetical. A common error seen when deploying OLSRv2-based networks using a Linux-based computer as a router is to neglect enabling IP forwarding, which effectively becomes an accidental attack of this type.
この状況は仮説ではありません。 Linuxベースのコンピューターをルーターとして使用してOLSRv2ベースのネットワークを展開するときによく見られるエラーは、IP転送の有効化を無視することです。これは、このタイプの偶発的な攻撃になります。
A wormhole, depicted in the example in Figure 4, may be established between two collaborating devices that are connected by an out-of-band channel. These devices send traffic through the "tunnel" to their alter ego, which "replays" the traffic. Thus, routers D and S appear as if direct neighbors and are reachable from each other in 1 hop through the tunnel, with the path through the MANET being 100 hops long.
図4の例に示されているワームホールは、帯域外チャネルによって接続されている2つの共同デバイス間に確立される可能性があります。これらのデバイスは、トラフィックを「トンネル」を介してそれらの代替エゴに送信します。これにより、トラフィックが「リプレイ」されます。したがって、ルータDとSは、直接隣接ルータのように見え、トンネルを介して1ホップで相互に到達可能であり、MANETを経由するパスは100ホップです。
.---. .---.
| S |---- ....100-hop-long path ... ---| D |
`---. / `---'
\ /
\ /
\X=============================X
1-hop path via wormhole
ワームホール経由の1ホップパス
Figure 4: Wormholing between Two Collaborating Devices Not Participating in the Routing Protocol
図4：ルーティングプロトコルに参加していない2つの共同デバイス間のウォームホール
The consequences of such a wormhole in the network depend on the detailed behavior of the wormhole. If the wormhole relays only control traffic, but not data traffic, the same considerations as in Section 4.1 apply. If, however, the wormhole relays all traffic (control and data alike), it is identical, connectivity wise, to a usable link - and the routing protocol will correctly generate a topology map reflecting the effective network topology. The efficiency of the topology obtained depends on (i) the wormhole characteristics, (ii) how the wormhole presents itself, and (iii) how paths are calculated.
ネットワークでのこのようなワームホールの影響は、ワームホールの詳細な動作に依存します。ワームホールが制御トラフィックのみを中継し、データトラフィックは中継しない場合、セクション4.1と同じ考慮事項が適用されます。ただし、ワームホールがすべてのトラフィック（制御とデータの両方）を中継する場合、接続性は使用可能なリンクと同一であり、ルーティングプロトコルは有効なネットワークトポロジを反映するトポロジマップを正しく生成します。得られるトポロジーの効率は、（i）ワームホールの特性、（ii）ワームホールがどのように現れるか、および（iii）パスの計算方法に依存します。
Assuming that paths are calculated with unit cost for all links, including the "link" presented by the wormhole, if the real characteristics of the wormhole are as if it were a path of more than 100 hops (e.g., with respect to delay, bandwidth, etc.), then the presence of the wormhole results in a degradation in performance as compared to using the non-wormhole path. Conversely, if the "link" presented by the wormhole has better characteristics, the wormhole results in improved performance.
ワームホールの実際の特性が100ホップを超えるパスであるかのように（たとえば、遅延、帯域幅に関して）、ワームホールによって提示される「リンク」を含むすべてのリンクのユニットコストでパスが計算されると仮定します。など）、ワームホールが存在すると、非ワームホールパスを使用する場合と比較してパフォーマンスが低下します。逆に、ワームホールによって提示された「リンク」がより良い特性を持っている場合、ワームホールによってパフォーマンスが向上します。
If paths are calculated using non-unit-costs for all links, and if the cost of the "link" presented by the wormhole correctly represents the actual cost (e.g., if the cost is established through measurements across the wormhole), then the wormhole may, in the worst case, cause no degradation in performance or, in the best case, improve performance by offering a better path. If the cost of the "link" presented by the wormhole is misrepresented, then the same considerations as for unit-cost links apply.
パスがすべてのリンクの非ユニットコストを使用して計算され、ワームホールによって提示された「リンク」のコストが実際のコストを正しく表している場合（たとえば、コストがワームホール全体の測定を通じて確立されている場合）、ワームホール最悪の場合、パフォーマンスが低下することはありませんが、最良の場合は、より良いパスを提供することでパフォーマンスが向上します。ワームホールによって提示された「リンク」のコストが誤って伝えられている場合は、単価のリンクと同じ考慮事項が適用されます。
An additional consideration with regard to wormholes is that they may present topologically attractive paths for the network; however, it may be undesirable to have data traffic transit such a path. An attacker could, by virtue of introducing a wormhole, acquire the ability to record and inspect transiting data traffic.
ワームホールに関する追加の考慮事項は、ワームホールがトポロジー的に魅力的なパスをネットワークに提示する可能性があることです。ただし、データトラフィックがこのようなパスを通過することは望ましくない場合があります。攻撃者はワームホールを導入することにより、通過するデータトラフィックを記録および検査する能力を獲得する可能性があります。
OLSRv2 uses two different sequence numbers in TCs to (i) avoid processing and forwarding the same message more than once (Message Sequence Number) and to (ii) ensure that old information, arriving late due to, e.g., long paths or other delays, is not allowed to overwrite more recent information generated (Advertised Neighbor Sequence Number (ANSN)).
OLSRv2はTCで2つの異なるシーケンス番号を使用して、（i）同じメッセージの2回以上の処理と転送を回避し（メッセージシーケンス番号）、（ii）長いパスやその他の遅延のために古い情報が確実に遅れて到着するようにします。生成された最新の情報（アドバタイズされたネイバーシーケンス番号（ANSN））を上書きすることはできません。
An attack may consist of a compromised OLSRv2 router spoofing the identity of another router in the network and transmitting a large number of TCs, each with different Message Sequence Numbers. Subsequent TCs with the same sequence numbers, originating from the router whose identity was spoofed, would hence be ignored until eventually information concerning these "spoofed" TCs expires.
攻撃は、侵害されたOLSRv2ルーターがネットワーク内の別のルーターのIDを偽装し、それぞれが異なるメッセージシーケンス番号を持つ多数のTCを送信することで構成される可能性があります。したがって、IDが偽装されたルータから発信された、同じシーケンス番号を持つ後続のTCは、これらの「偽装」されたTCに関する情報が期限切れになるまで無視されます。
An attack may consist of a compromised OLSRv2 router spoofing the identity of another router in the network and transmitting a single TC with an ANSN significantly larger than that which was last used by the legitimate router. Routers will retain this larger ANSN as "the most recent information" and discard subsequent TCs with lower sequence numbers as being "old".
攻撃は、ネットワーク内の別のルーターのIDを偽装し、正当なルーターが最後に使用したものよりも大幅に大きいANSNを持つ単一のTCを送信する、侵害されたOLSRv2ルーターで構成される可能性があります。ルータは、このより大きなANSNを「最新の情報」として保持し、シーケンス番号が小さい後続のTCを「古い」として破棄します。
Indirect jamming is an attack in which a compromised OLSRv2 router is, by its actions, causing legitimate routers to generate inordinate amounts of control traffic, thereby increasing both channel occupation and the overhead incurred in each router for processing this control traffic. This control traffic will be originated from legitimate routers; thus, to the wider network, the malicious device may remain undetected.
間接妨害は、侵害されたOLSRv2ルーターがその動作により、正当なルーターに制御トラフィックの量を過度に発生させ、チャネル制御とこの制御トラフィックを処理するために各ルーターで発生するオーバーヘッドの両方を増加させる攻撃です。この制御トラフィックは、正当なルーターから発信されます。したがって、より広いネットワークでは、悪意のあるデバイスが検出されないままになる可能性があります。
The general mechanism whereby a malicious router can cause indirect jamming is for it to participate in the protocol by generating plausible control traffic and to tune this control traffic to in turn trigger receiving routers to generate additional traffic. For OLSRv2, such an indirect attack can be directed at the neighborhood discovery mechanism and the LSA mechanism, respectively.
悪意のあるルーターが間接的な妨害を引き起こす可能性のある一般的なメカニズムは、妥当な制御トラフィックを生成してプロトコルに参加し、この制御トラフィックを調整して受信ルーターをトリガーして追加のトラフィックを生成することです。 OLSRv2の場合、このような間接的な攻撃は、それぞれ近隣探索メカニズムとLSAメカニズムに向けられます。
One efficient indirect jamming attack in OLSRv2 is to target control traffic destined for network-wide diffusion. This is illustrated in Figure 5.
OLSRv2の1つの効率的な間接妨害攻撃は、ネットワーク全体の拡散を宛先とする制御トラフィックを対象とすることです。これを図5に示します。
The malicious router X selects router A as an MPR at time t0 in a HELLO. This causes X to appear as MPR selector for A and, consequently, A sets X to be advertised in its "Neighbor Set" and increments the associated "Advertised Neighbor Sequence Number" (ANSN). Router A must then advertise the link between itself and X in subsequent outgoing TCs (t1), also including the ANSN in such TCs. Upon X having received this TC, it declares the link between itself and A as no longer valid (t2) in a HELLO (indicating the link to A as LOST). Since only symmetric links are advertised by OLSRv2 routers, A will (upon receipt hereof) remove X from the set of advertised neighbors and increment the ANSN. Router A will then, in subsequent TCs, advertise the remaining set of advertised neighbors (i.e., with X removed) and the corresponding ANSN (t3). Upon X having received this information in another TC from A, it may repeat this cycle, alternating advertising the link A-X as "LOST" and as "MPR".
悪意のあるルーターXは、HELLOで時刻t0にルーターAをMPRとして選択します。これにより、XがAのMPRセレクタとして表示され、その結果、AはXをその「ネイバーセット」でアドバタイズするように設定し、関連する「アドバタイズされたネイバーシーケンス番号」（ANSN）をインクリメントします。次に、ルータAは、後続の発信TC（t1）で自身とXの間のリンクを通知する必要があります。このようなTCにはANSNも含まれます。 XがこのTCを受信すると、Xはそれ自体とAの間のリンクをHELLOで無効（t2）として宣言します（AへのリンクがLOSTであることを示します）。対称リンクのみがOLSRv2ルーターによってアドバタイズされるため、Aは（その受信時に）アドバタイズされたネイバーのセットからXを削除し、ANSNをインクリメントします。次に、ルーターAは後続のTCで、アドバタイズされたネイバーの残りのセット（つまり、Xを削除したもの）と対応するANSN（t3）をアドバタイズします。 XがAから別のTCでこの情報を受信すると、このサイクルを繰り返し、リンクA-Xを「LOST」と「MPR」として交互にアドバタイズします。
broadcast TC ANS={} TC:()
(X-A) ANSN ANSN++ ANSN
.---. .---. .---. .---.
| A | | A | | A | | A |
'---' '---' '---' '---'
^ | ^ |
| | | |
| select | |indicate |
| as MPR | |as LOST |
.---. .---. .---. .---.
| X | | X | | X | | X |
'---' '---' '---' '---'
t0 t1 t2 t3
t0 t1 t2 tz
Description: The malicious X flips between link status MPR and LOST.
説明：悪意のあるXは、リンクステータスMPRとLOSTを切り替えます。
Figure 5: Indirect Jamming in Link State Advertisement
図5：リンクステートアドバタイズメントでの間接的な妨害
Routers receiving a TC message will parse and process this message, specifically updating their topology map as a consequence of successful receipt. If the ANSN between two successive TCs from the same router has incremented, then the topology has changed and routing sets are to be recalculated. This has the potential to be a computationally costly operation.
TCメッセージを受信するルーターは、このメッセージを解析して処理し、受信が成功した結果としてトポロジマップを更新します。同じルータからの2つの連続するTC間のANSNが増加した場合、トポロジが変更され、ルーティングセットが再計算されます。これは、計算コストのかかる操作になる可能性があります。
A compromised OLSRv2 router may chose to conduct this attack against all its neighbors, thus maximizing its disruptive impact on the network with relatively little overhead of its own: other than participating in the neighborhood discovery procedure, the compromised OLSRv2 router will monitor TCs generated by its neighbors and alternate the advertised status for each such neighbor between "MPR" and "LOST". The compromised OLSRv2 router will indicate its willingness to be selected as an MPR as 0 (thus avoiding selection as an MPR) and may ignore all other protocol operations while still remaining effective as an attacker.
侵害されたOLSRv2ルーターは、すべてのネイバーに対してこの攻撃を実行することを選択し、それ自体のオーバーヘッドが比較的少ないネットワークへの破壊的な影響を最大化できます。近隣の発見手順に参加することを除いて、侵害されたOLSRv2ルーターは、自身が生成したTCを監視しますネイバーおよび「MPR」と「LOST」の間でそのような各ネイバーのアドバタイズされたステータスを交互に。侵害されたOLSRv2ルーターは、MPRとして選択される意思を0として（したがって、MPRとしての選択を回避する）示し、攻撃者としての効果を維持しながら、他のすべてのプロトコル操作を無視する可能性があります。
The basic operation of OLSRv2 employs periodic message emissions, and by this attack it can be ensured that each such periodic message will entail routing table recalculation in all routers in the network.
OLSRv2の基本操作では、定期的なメッセージエミッションが使用されます。この攻撃により、このような定期的なメッセージごとに、ネットワーク内のすべてのルーターでルーティングテーブルの再計算が行われることが保証されます。
If the routers in the network have "triggered TCs" enabled, this attack may also cause an increased TC frequency. Triggered TCs are intended to allow a (stable) network to have relatively low TC emission frequencies yet still allow link breakage or link emergence to be advertised through the network rapidly. A minimum message interval (typically much smaller than the regular periodic message interval) is imposed to rate-limit worst-case message emissions.
ネットワーク内のルーターで「トリガーされたTC」が有効になっている場合、この攻撃によりTCの頻度が増加する可能性もあります。トリガーされたTCは、（安定した）ネットワークが比較的低いTC放出周波数を持つことを可能にする一方で、リンクの切断またはリンクの出現をネットワークを通じて迅速にアドバタイズできるようにすることを目的としています。最悪の場合のメッセージ送信をレート制限するために、最小メッセージ間隔（通常は、定期的な定期メッセージ間隔よりもはるかに短い）が課されます。
This attack can cause the TC interval to permanently become equal to the minimum message interval. [RFC7181] proposes as default that the minimum TC interval be 0.25 x TC_INTERVAL (TC_INTERVAL being the maximum interval between two TC messages from the same OLSRv2 router).
この攻撃により、TC間隔が永続的に最小メッセージ間隔と等しくなる可能性があります。 [RFC7181]は、デフォルトとして、最小TC間隔を0.25 x TC_INTERVALにすることを提案しています（TC_INTERVALは、同じOLSRv2ルーターからの2つのTCメッセージ間の最大間隔です）。
Indirect jamming by a compromised OLSRv2 router can thus have two effects: (i) it may cause increased frequency of TC generation and transmission, and (ii) it will cause additional routing table recalculation in all routers in the network.
したがって、侵害されたOLSRv2ルーターによる間接的な妨害は、（i）TCの生成と送信の頻度を増加させる可能性があり、（ii）ネットワーク内のすべてのルーターで追加のルーティングテーブル再計算を引き起こす可能性があります。
Inconsistent topology maps can occur by a compromised OLSRv2 router employing either identity spoofing or link spoofing for conducting an attack against an OLSRv2 network. The threats related to NHDP, such as identity spoofing in NHDP, link spoofing in NHDP, and creating loops, have been illustrated in [RFC7186]. This section mainly addresses the vulnerabilities in [RFC7181].
OLSRv2ネットワークに対する攻撃を実行するためにIDスプーフィングまたはリンクスプーフィングのいずれかを使用する、侵害されたOLSRv2ルーターによって、一貫性のないトポロジマップが発生する可能性があります。 NHDPでのIDスプーフィング、NHDPでのリンクスプーフィング、ループの作成など、NHDPに関連する脅威は、[RFC7186]で説明されています。このセクションでは、主に[RFC7181]の脆弱性を扱います。
Identity spoofing can be employed by a compromised OLSRv2 router via the neighborhood discovery process and via the LSA process. Either of them causes inconsistent topology maps in routers in the network. The creation of inconsistent topology maps due to neighborhood discovery has been discussed in [RFC7186]. For OLSRv2, the attack on the LSA process can also cause inconsistent topology maps.
IDスプーフィングは、ネイバーディスカバリープロセスおよびLSAプロセスを介して、侵害されたOLSRv2ルーターによって使用される可能性があります。これらのいずれかが原因で、ネットワーク内のルーターでトポロジマップに一貫性がなくなります。近隣探索による一貫性のないトポロジマップの作成については、[RFC7186]で説明されています。 OLSRv2の場合、LSAプロセスへの攻撃により、不整合なトポロジマップが発生する可能性もあります。
An inconsistent topology map may occur when the compromised OLSRv2 router takes part in the LSA process by selecting a neighbor as an MPR, which in turn advertises the spoofed identities of the compromised OLSRv2 router. This attack will alter the topology maps of all routers of the network.
侵害されたOLSRv2ルーターがMPRとしてネイバーを選択することによりLSAプロセスに参加すると、トポロジマップの不整合が発生する可能性があります。この攻撃は、ネットワークのすべてのルーターのトポロジマップを変更します。
A -- B -- C -- D -- E -- F -- X
(X spoofs A)
（XスプーフA）
Description: A compromised OLSRv2 router X spoofs the identity of A, leading to a wrongly perceived topology.
説明：侵害されたOLSRv2ルーターXがAのIDを偽装し、誤って認識されたトポロジーにつながります。
Figure 6: Identity Spoofing
図6：IDスプーフィング
In Figure 6, router X spoofs the address of router A. If X selects F as an MPR, all routers in the network will be informed about the link F-A by the TCs originating from F. Assuming that (the real) A selects B as an MPR, the link B-A will also be advertised in the network.
図6では、ルーターXがルーターAのアドレスを偽装しています。XがMPRとしてFを選択すると、ネットワーク内のすべてのルーターは、Fから発信されたTCによってリンクFAについて通知されます。 MPRの場合、リンクBAもネットワークでアドバタイズされます。
When calculating paths, B and C will calculate paths to A via B, as illustrated in Figure 7(a); for these routers, the shortest path to A is via B. E and F will calculate paths to A via F, as illustrated in Figure 7(b); for these routers, the shortest path to A is via the compromised OLSRv2 router X, and these are thus disconnected from the real A. D will have a choice, as the path calculated to A via B is of the same length as the path via the compromised OLSRv2 router X, as illustrated in Figure 7(c).
図7（a）に示すように、パスを計算するとき、BとCはBを介してAへのパスを計算します。これらのルーターの場合、Aへの最短パスはB経由です。EとFは、図7（b）に示すように、F経由でAへのパスを計算します。これらのルーターの場合、Aへの最短パスは侵害されたOLSRv2ルーターX経由であり、したがってこれらは実際のAから切断されます。B経由でAまで計算されたパスは経由経由のパスと同じ長さであるため、Dが選択できます図7（c）に示すように、侵害されたOLSRv2ルーターX。
In general, the following observations can be made:
一般に、以下の観察を行うことができます。
o The network will be split in two, with those routers closer to B than to X reaching A, whereas those routers closer to X than to B will be unable to reach A.
o ネットワークは2つに分割され、XよりもBに近いルーターはAに到達しますが、BよりもXに近いルーターはAに到達できません。
o Routers beyond B, i.e., routers beyond 1 hop away from A, will be unable to detect this identity spoofing.
o Bを超えるルーター、つまりAから1ホップ離れたルーターは、このIDスプーフィングを検出できません。
The identity spoofing attack via the LSA procedure has a higher impact than the attack on the neighborhood discovery procedure since it alters the topology maps of all routers in the network and not only in the 2-hop neighborhood. However, the attack is easier to detect by other routers in the network. Since the compromised OLSRv2 router is advertised in the whole network, routers whose identities are spoofed by the compromised OLSRv2 router can detect the attack. For example, when A receives a TC from F advertising the link F-A, it can deduce that some entity is injecting incorrect link state information as it does not have F as one of its direct neighbors.
LSA手順によるIDスプーフィング攻撃は、2ホップの近隣だけでなく、ネットワーク内のすべてのルーターのトポロジマップを変更するため、近隣発見手順への攻撃よりも大きな影響を与えます。ただし、攻撃はネットワーク内の他のルーターによって検出する方が簡単です。侵害されたOLSRv2ルーターはネットワーク全体でアドバタイズされるため、侵害されたOLSRv2ルーターによってIDが偽装されているルーターが攻撃を検出できます。たとえば、AがFからリンクF-AをアドバタイズするTCを受信すると、Fが直接のネイバーの1つではないため、一部のエンティティが不正なリンク状態情報を注入していると推定できます。
(X spoofs A)
（XスプーフA）
A < ---- B < ---- C E ----> F ----> X
(a) Routers B and C (b) Routers E and F
（a）ルーターBおよびC（b）ルーターEおよびF
A < --- B < --- C < --- D ---> E ---> F ----> X
(X spoofs A)
（XスプーフA）
Description: These paths appear as calculated by the different routers in the network in presence of a compromised OLSRv2 router X, spoofing the address of A.
説明：これらのパスは、侵害されたOLSRv2ルーターXが存在し、Aのアドレスを偽装している場合に、ネットワーク内のさまざまなルーターによって計算されたように見えます。
Figure 7: Routing Paths towards A
図7：Aへのパスのルーティング
As the compromised OLSRv2 router X does not itself send the TCs, but rather, by virtue of MPR selection, ensures that the addresses it spoofs are advertised in TCs from its MPR selector F, the attack may be difficult to counter. Simply ignoring TCs that originate from F may also suppress the link state information for other, legitimate, MPR selectors of F.
侵害されたOLSRv2ルーターXはそれ自体がTCを送信するのではなく、MPR選択により、スプーフするアドレスがMPRセレクターFからTCにアドバタイズされることを保証するため、攻撃に対抗することは困難です。 Fから発信されたTCを単に無視すると、Fの他の正当なMPRセレクターのリンク状態情報も抑制されます。
Thus, identity spoofing by a compromised OLSRv2 router, participating in the LSA process by selecting MPRs only, creates a situation wherein two or more routers have substantially inconsistent topology maps: traffic for an identified destination is, depending on where in the network it appears, delivered to different routers.
したがって、MPRのみを選択してLSAプロセスに参加する、侵害されたOLSRv2ルーターによるIDスプーフィングは、2つ以上のルーターが実質的に一貫性のないトポロジマップを持っている状況を作成します。別のルーターに配信されます。
Link spoofing is a situation in which a router advertises non-existing links to another router (possibly not present in the network). Essentially, TCs and HELLOs both advertise links to direct neighbor routers with the difference being the scope of the advertisement. Thus, link spoofing consists of a compromised OLSRv2 router reporting that it has neighbors routers that are either not present in the network or are effectively not neighbors of the compromised OLSRv2 router.
リンクスプーフィングとは、ルーターが存在しないリンクを別のルーターにアドバタイズする状況です（ネットワークに存在しない可能性があります）。基本的に、TCとHELLOはどちらも直接隣接ルーターにリンクをアドバタイズしますが、その違いはアドバタイズメントのスコープです。したがって、リンクスプーフィングは、ネットワークに存在しないか、侵害されたOLSRv2ルーターの実質的に隣接していない隣接ルーターがあることを報告する、侵害されたOLSRv2ルーターで構成されます。
It can be noted that a situation similar to link spoofing may occur temporarily in an OLSR or OLSRv2 network without compromised OLSRv2 routers: if A was, but is no more, a neighbor of B, then A may still be advertising a link to B for the duration of the time it takes for the neighborhood discovery process to determine this changed neighborhood.
OLSRv2ルーターが危険にさらされずに、リンクスプーフィングと同様の状況がOLSRまたはOLSRv2ネットワークで一時的に発生する可能性があることに注意してください。近隣探索プロセスがこの変更された近隣を特定するのにかかる時間。
In the context of this document, link spoofing refers to a persistent situation where a compromised OLSRv2 router intentionally advertises links to other routers for which it is not a direct neighbor.
このドキュメントのコンテキストでは、リンクスプーフィングとは、侵害されたOLSRv2ルーターが、直接隣接していない他のルーターに意図的にリンクをアドバタイズする永続的な状況を指します。
Figure 8 illustrates a network in which the compromised OLSRv2 router X spoofs links to an existing router A by participating in the LSA process and including this non-existing link in its advertisements.
図8は、LSAプロセスに参加し、この存在しないリンクをアドバタイズに含めることにより、侵害されたOLSRv2ルーターXが既存のルーターAにスプーフするネットワークを示しています。
A --- B --- C --- D --- E --- F --- G --- H --- X
(X spoofs the link to A)
（XはAへのリンクを偽装します）
Description: The compromised OLSRv2 router X advertises a spoofed link to A in its TCs; thus, all routers will record both of the links X-A and B-A.
説明：侵害されたOLSRv2ルーターXは、TCでAへのスプーフィングされたリンクをアドバタイズします。したがって、すべてのルーターはリンクX-AとB-Aの両方を記録します。
Figure 8: Link Spoofing
図8：リンクスプーフィング
As TCs are flooded through the network, all routers will receive and record information describing a link X-A in this link state information. If A has selected router B as an MPR, B will likewise flood this link state information through the network; thus, all routers will receive and record information describing a link B-A.
TCがネットワークを介してフラッディングされると、すべてのルーターがこのリンク状態情報でリンクX-Aを表す情報を受信して記録します。 AがルーターBをMPRとして選択した場合、Bも同様にこのリンク状態情報をネットワーク経由でフラッディングします。したがって、すべてのルーターはリンクB-Aを表す情報を受信して記録します。
When calculating routing paths, B, C, and D will calculate paths to A via B, as illustrated in Figure 9(a); for these routers, the shortest path to A is via B. F and G will calculate paths to A via X, as illustrated in Figure 9(b); for these routers, the shortest path to A is via X, and these are thus disconnected from the real router A. E will have a choice: the path calculated to A via B is of the same length as the path via X, as illustrated in Figure 9(b).
ルーティングパスを計算するとき、B、C、およびDは、図9（a）に示すように、Bを介してAへのパスを計算します。これらのルーターの場合、図9（b）に示すように、Aへの最短パスはB経由です。FとGはX経由でAへのパスを計算します。これらのルーターの場合、Aへの最短パスはX経由であり、したがってこれらは実際のルーターAから切断されます。Eには選択肢があります。B経由でAまで計算されたパスは、X経由のパスと同じ長さです。図9（b）
A < --- B < --- C < --- D F ---> G ---> X ---> A
(a) Routers B, C, and D (b) Routers F and G
（a）ルーターB、C、およびD（b）ルーターFおよびG
A < --- B < --- C < --- D < --- E ---> F ---> G ---> X ---> A
(c) Router E
（c）ルーターE
Description: These paths appear as calculated by the different routers in the network in the presence of a compromised OLSRv2 router X, spoofing a link to router A.
説明：これらのパスは、侵害されたOLSRv2ルーターXが存在し、ルーターAへのリンクをスプーフィングしている場合、ネットワーク内のさまざまなルーターによって計算されたように見えます。
Figure 9: Routing Paths towards Router A
図9：ルーターAへの経路のルーティング
In general, the following observations can be made:
一般に、以下の観察を行うことができます。
o The network will be separated in two: routers closer to B than X will reach A, whereas routers closer to X than B will be unable to reach A.
o ネットワークは2つに分離されます。XよりBに近いルーターはAに到達しますが、BよりXに近いルーターはAに到達できません。
o Routers beyond B, i.e., routers beyond 1 hop away from A, will be unable to detect this link spoofing.
o Bを超えるルーター、つまりAから1ホップを超えるルーターは、このリンクのスプーフィングを検出できません。
As described in Section 1, [RFC7183] specifies a security mechanism for OLSRv2 that is mandatory to implement. However, deployments may choose to use different security mechanisms if more appropriate. Therefore, it is important to understand both the inherent resilience of OLSRv2 against security vulnerabilities when not using the mechanisms specified in [RFC7183] and the protection that [RFC7183] provides when used in a deployment.
セクション1で説明されているように、[RFC7183]は、実装が必須のOLSRv2のセキュリティメカニズムを指定しています。ただし、デプロイメントは、より適切な場合、異なるセキュリティメカニズムを使用することを選択できます。したがって、[RFC7183]で指定されたメカニズムを使用しない場合のセキュリティの脆弱性に対するOLSRv2の固有の復元力と、[RFC7183]が展開で使用される場合に提供する保護の両方を理解することが重要です。
OLSRv2 (even when used without the mandatory-to-implement security mechanisms in [RFC7183]) provides some inherent resilience against part of the attacks described in this document. In particular, it provides the following resilience:
OLSRv2は（[RFC7183]の実装に必須のセキュリティメカニズムなしで使用された場合でも）、このドキュメントで説明されている攻撃の一部に対する固有の回復力を提供します。特に、次の回復力を提供します。
o Sequence numbers: OLSRv2 employs message sequence numbers, which are specific per the router identity and message type. Routers keep an "information freshness" number (ANSN) incremented each time the content of an LSA from a router changes. This allows rejecting both "old" information and duplicate messages, and it provides some protection against "message replay". However, this also presents an attack vector (Section 4.3).
o シーケンス番号：OLSRv2はメッセージシーケンス番号を使用します。メッセージシーケンス番号は、ルーターIDとメッセージタイプごとに固有です。ルーターは、ルーターからのLSAの内容が変更されるたびに、「情報フレッシュネス」番号（ANSN）を増加させます。これにより、「古い」情報と重複メッセージの両方を拒否でき、「メッセージの再生」に対する保護が提供されます。ただし、これは攻撃ベクトルも示します（セクション4.3）。
o Ignoring unidirectional links: The neighborhood discovery process detects and admits only bidirectional links for use in MPR selection and LSA. Jamming attacks may affect only reception of control traffic; however, OLSRv2 will correctly recognize, and ignore, such a link that is not bidirectional.
o 単方向リンクの無視：近隣探索プロセスでは、MPR選択とLSAで使用するための双方向リンクのみを検出して許可します。妨害攻撃は、制御トラフィックの受信のみに影響を与える可能性があります。ただし、OLSRv2は、双方向でないリンクを正しく認識して無視します。
o Message interval bounds: The frequency of control messages, with minimum intervals imposed for HELLO and TCs. This may limit the impact from an indirect jamming attack (Section 4.4).
o メッセージ間隔の境界：制御メッセージの頻度。HELLOおよびTCに課される最小間隔。これにより、間接的な妨害攻撃による影響が制限される場合があります（セクション4.4）。
o Additional reasons for rejecting control messages: The OLSRv2 specification includes a list of reasons for which an incoming control message should be rejected as malformed -- and allows that a protocol extension may recognize additional reasons for OLSRv2 to consider a message malformed. Together with the flexible message format [RFC5444], this allows addition of security mechanisms, such as digital signatures, while remaining compliant with the OLSRv2 standard specification.
o 制御メッセージを拒否するその他の理由：OLSRv2仕様には、着信制御メッセージが不正な形式として拒否される理由のリストが含まれています。これにより、プロトコル拡張機能により、OLSRv2がメッセージの不正な形式を考慮する追加の理由を認識することができます。これにより、柔軟なメッセージ形式[RFC5444]とともに、OLSRv2標準仕様に準拠したまま、デジタル署名などのセキュリティメカニズムを追加できます。
[RFC7183] specifies mechanisms for integrity and replay protection for NHDP and OLSRv2 using the generalized packet/message format described in [RFC5444] and the TLV definitions in [RFC7182]. The specification describes how to add an Integrity Check Value (ICV) in a TLV to each control message, providing integrity protection of the content of the message using Hashed Message Authentication Code (HMAC) / SHA-256. In addition, a timestamp TLV is added to the message prior to creating the ICV, enabling replay protection of messages. The document specifies how to sign outgoing messages and how to verify incoming messages, as well as under which circumstances an invalid message is rejected. Because of the HMAC/SHA-256 ICV, a shared key between all routers in the MANET is assumed. A router without valid credentials is not able to create an ICV that can be correctly verified by other routers in the MANET; therefore, such an incorrectly signed message will be rejected by other MANET routers, and the router cannot participate in the OLSRv2 routing process (i.e., the malicious router will be ignored by other legitimate routers). [RFC7183] does not address the case where a router with valid credentials has been compromised. Such a compromised router will not be excluded from the routing process, and other means of detecting such a router are necessary if required in a deployment: for example, using an asymmetric key extension to [RFC7182] that allows revocation of the access of one particular router.
[RFC7183]は、[RFC5444]で説明されている一般化されたパケット/メッセージ形式と[RFC7182]でのTLV定義を使用して、NHDPとOLSRv2の整合性とリプレイ保護のメカニズムを指定します。この仕様は、TLVの整合性チェック値（ICV）を各制御メッセージに追加し、ハッシュメッセージ認証コード（HMAC）/ SHA-256を使用してメッセージのコンテンツの整合性を保護する方法を説明しています。さらに、ICVを作成する前にタイムスタンプTLVがメッセージに追加され、メッセージの再生保護が可能になります。このドキュメントでは、送信メッセージに署名する方法と受信メッセージを確認する方法、および無効なメッセージが拒否される状況について説明しています。 HMAC / SHA-256 ICVのため、MANET内のすべてのルーター間で共有キーが想定されます。有効な資格情報がないルーターは、MANETの他のルーターによって正しく検証できるICVを作成できません。したがって、そのような誤って署名されたメッセージは他のMANETルーターによって拒否され、ルーターはOLSRv2ルーティングプロセスに参加できません（つまり、悪意のあるルーターは他の正当なルーターによって無視されます）。 [RFC7183]は、有効な資格情報を持つルーターが危険にさらされた場合に対処していません。このような危険にさらされたルーターはルーティングプロセスから除外されないため、展開で必要な場合は、そのようなルーターを検出する他の手段が必要です。たとえば、[RFC7182]の非対称キー拡張を使用して、特定の1つのアクセスの取り消しを許可するルーター。
In the following sections, each of the vulnerabilities described earlier in this document will be evaluated in terms of whether OLSRv2 with the mechanisms in [RFC7183] provides sufficient protection against the attack. It is implicitly assumed in each of the following sections that [RFC7183] is used with OLSRv2.
次のセクションでは、このドキュメントで前述した各脆弱性を、[RFC7183]のメカニズムを備えたOLSRv2が攻撃に対して十分な保護を提供するかどうかについて評価します。次の各セクションでは、[RFC7183]がOLSRv2で使用されることが暗黙的に想定されています。
Attack on Jittering: As only OLSRv2 routers with valid credentials can participate in the routing process, a malicious router cannot reduce the jitter time of an attacked router to 0 by sending many TC messages in a short time. The attacked router would reject all the incoming messages as "invalid" and not forward them. The same applies for the case where a malicious router wants to assure that by forcing a 0 jitter interval, the message arrives before the same message forwarded by legitimate routers.
ジッタへの攻撃：有効な資格情報を持つOLSRv2ルーターのみがルーティングプロセスに参加できるため、悪意のあるルーターは、短時間に多くのTCメッセージを送信して、攻撃されたルーターのジッタ時間を0に減らすことはできません。攻撃されたルーターは、すべての着信メッセージを「無効」として拒否し、転送しません。悪意のあるルーターが0のジッター間隔を強制することにより、正当なルーターによって転送された同じメッセージの前にメッセージが到着することを保証したい場合にも同じことが当てはまります。
Modifying the Hop Limit and the Hop Count: As the hop limit and hop count are not protected by [RFC7183] (since they are mutable fields that change at every hop), this attack is still feasible. It is possible to apply [RFC5444] packet-level protection by using ICV Packet TLV defined in [RFC7182] to provide hop-by-hop integrity protection -- at the expense of a requirement of pairwise trust between all neighbor routers.
ホップリミットとホップカウントの変更：ホップリミットとホップカウントは[RFC7183]によって保護されていないため（ホップごとに変化する可変フィールドであるため）、この攻撃は依然として実行可能です。 [RFC7182]で定義されたICVパケットTLVを使用して[RFC5444]パケットレベルの保護を適用し、ホップバイホップの完全性保護を提供することができます。ただし、すべての隣接ルーター間のペアワイズ信頼の要件が犠牲になります。
Incorrect Forwarding: As only OLSRv2 routers with valid credentials can participate in the routing process, a malicious router will not be part of the topology of other legitimate OLSRv2 routers. Therefore, no data traffic will be sent to the malicious router for forwarding.
不適切な転送：有効な資格情報を持つOLSRv2ルーターのみがルーティングプロセスに参加できるため、悪意のあるルーターは他の正当なOLSRv2ルーターのトポロジの一部にはなりません。したがって、データトラフィックが悪意のあるルーターに送信されて転送されることはありません。
Wormholes: Since a wormhole consists of at least two devices forwarding (unmodified) traffic, this attack is still feasible and undetectable by the OLSRv2 routing process since the attack does not involve the OLSRv2 protocol itself (but rather lower layers). By using [RFC7183], it can at least be assured that the content of the control messages is not modified while being forwarded via the wormhole. Moreover, the timestamp TLV assures that the forwarding can only be done in a short time window after the actual TC message has been sent.
ワームホール：ワームホールは少なくとも2つのデバイス転送（変更されていない）トラフィックで構成されているため、この攻撃はOLSRv2プロトコル自体（ただし、下位層）を含まないため、OLSRv2ルーティングプロセスでは実行可能であり、検出できません。 [RFC7183]を使用することにより、ワームホールを介して転送されている間、制御メッセージの内容が変更されないことが少なくとも保証されます。さらに、タイムスタンプTLVは、実際のTCメッセージが送信された後、転送が短い時間枠でのみ実行できることを保証します。
Message Sequence Number: As the message sequence number is included in the ICV calculation, OLSRv2 is protected against this attack.
メッセージシーケンス番号：メッセージシーケンス番号はICV計算に含まれるため、OLSRv2はこの攻撃から保護されます。
Advertised Neighbor Sequence Number (ANSN): As the ANSN is included in the ICV calculation, OLSRv2 is protected against this attack.
Advertised Neighbor Sequence Number（ANSN）：ANSNがICV計算に含まれているため、OLSRv2はこの攻撃から保護されています。
Indirect Jamming: Since the control messages of a malicious router will be rejected by other legitimate OLSRv2 routers in the MANET, this attack is mitigated.
間接的な妨害：悪意のあるルーターの制御メッセージはMANET内の他の正当なOLSRv2ルーターによって拒否されるため、この攻撃は軽減されます。
Identity Spoofing: Since the control messages of a malicious router will be rejected by other legitimate OLSRv2 routers in the MANET, a router without valid credentials may spoof its identity (e.g., IP source address or message originator address), but the messages will be ignored by other routers. As the mandatory mechanism in [RFC7183] uses shared keys amongst all MANET routers, a single compromised router may spoof its identity and cause harm to the network stability. Removing this one malicious router, once detected, implies rekeying all other routers in the MANET. Asymmetric keys, particularly when using identity-based signatures (such as those specified in [RFC7859]), may give the possibility of revoking single routers and verifying their identity based on the ICV itself.
IDスプーフィング：悪意のあるルーターの制御メッセージはMANET内の他の正当なOLSRv2ルーターによって拒否されるため、有効な資格情報のないルーターはそのID（IPソースアドレスやメッセージ発信者アドレスなど）を偽装する可能性がありますが、メッセージは無視されます他のルーターによって。 [RFC7183]の必須メカニズムはすべてのMANETルーター間で共有キーを使用するため、単一の危険にさらされたルーターがそのIDを偽装し、ネットワークの安定性を損なう可能性があります。この悪意のあるルーターを1つ削除すると、検出されると、MANETの他のすべてのルーターのキーが再生成されます。非対称キーは、特にIDベースの署名（[RFC7859]で指定されているものなど）を使用している場合、単一のルーターを取り消し、ICV自体に基づいてIDを検証する可能性があります。
Link Spoofing: Similar to identity spoofing, a malicious router without valid credentials may spoof links, but its control messages will be rejected by other routers, thereby mitigating the attack.
リンクスプーフィング：IDスプーフィングと同様に、有効な資格情報のない悪意のあるルーターはリンクをスプーフィングする可能性がありますが、その制御メッセージは他のルーターによって拒否されるため、攻撃が軽減されます。
Inconsistent Topology Maps Due to LSAs: The same considerations for link spoofing apply.
LSAが原因で一貫性のないトポロジマップ：リンクスプーフィングと同じ考慮事項が適用されます。
Other than implementing OLSRv2, including appropriate security mechanisms, the way in which the protocol is deployed is also important to ensure proper functioning and threat mitigation. For example, Section 4.1 discussed considerations due to an incorrect forwarding-policy setting, and Section 4.2 discussed considerations for when intentional wormholes are present in a deployment.
適切なセキュリティメカニズムを含むOLSRv2の実装以外に、プロトコルの展開方法も、適切な機能と脅威の軽減を確実にするために重要です。たとえば、セクション4.1では転送ポリシー設定が正しくないための考慮事項について説明し、セクション4.2ではデプロイメントに意図的なワームホールが存在する場合の考慮事項について説明しました。
This document does not specify a protocol or a procedure but reflects
on security considerations for OLSRv2 and for its constituent parts,
including NHDP. The document initially analyses threats to topology
map acquisition, with the assumption that no security mechanism
(including the mandatory-to-implement mechanisms from [RFC7182] and
[RFC7183]) is in use. Then, it proceeds to discuss how the use of
[RFC7182] and [RFC7183] mitigate the identified threats. When
[RFC7183] is used with routers using a single shared key, the
protection offered is not effective if a compromised router has valid
credentials.
[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>。
[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>。
[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>。
[FUNKFEUER] Funkfeuer, "Funkfeuer", <https://www.funkfeuer.at/>.
[FUNKFEUER] Funkfeuer、「Funkfeuer」、<https://www.funkfeuer.at/>。
[IEEE802.11] IEEE, "IEEE Standard for Information technology - Telecommunications and information exchange between systems Local and metropolitan area networks - Specfic requirements Part 11: Wireless LAN Medium Access Control and Physical (PHY) Specifications", IEEE Std 802.11-2016, DOI 10.1109/IEEESTD.2016.7786995, December 2016.
[IEEE802.11] IEEE、「IEEE Standard for Information technology-Telecommunications and information exchange between system Local and Metropolitan Area Networks-Specfic requirements Part 11：Wireless LAN Medium Access Control and Physical（PHY）Specifications」、IEEE Std 802.11-2016、 DOI 10.1109 / IEEESTD.2016.7786995、2016年12月。
[MPR-FLOODING] Qayyum, A., Viennot, L., and A. Laouiti, "Multipoint Relaying: An Efficient Technique for Flooding in Mobile Wireless Networks", Proceedings of the 35th Annual Hawaii International Conference on System Sciences (HICSS '01), IEEE Computer Society, 2001.
[MPR-FLOODING] Qayyum、A.、Viennot、L。、およびA. Laouiti、「Multipoint Relaying：A Efficient Technique in Flooding in Mobile Wireless Networks」、第35回ハワイ国際システム科学会議（HICSS '01 ）、IEEE Computer Society、2001年。
[OLSR-FSR] Clausen, T., "Combining Temporal and Spatial Partial Topology for MANET routing - Merging OLSR and FSR", Proceedings of the 2003 IEEE Conference of Wireless Personal Multimedia Communications (WPMC '03), 2003.
[OLSR-FSR]クラウセン、T。、「MANETルーティングの時間的および空間的部分トポロジの組み合わせ-OLSRとFSRのマージ」、2003年ワイヤレスパーソナルマルチメディア通信の会議（WPMC '03）、2003。
[OLSR-FSR-Scaling] Adjih, C., Baccelli, E., Clausen, T., Jacquet, P., and G. Rodolakis, "Fish Eye OLSR Scaling Properties", IEEE Journal of Communication and Networks (JCN), Special Issue on Mobile Ad Hoc Networks, December 2004.
[OLSR-FSR-Scaling] Adjih、C.、Baccelli、E.、Clausen、T.、Jacquet、P.、and G. Rodolakis、 "Fish Eye OLSR Scaling Properties"、IEEE Journal of Communication and Networks（JCN）、モバイルアドホックネットワークの特集、2004年12月。
[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>。
[RFC5068] Hutzler, C., Crocker, D., Resnick, P., Allman, E., and T. Finch, "Email Submission Operations: Access and Accountability Requirements", BCP 134, RFC 5068, DOI 10.17487/RFC5068, November 2007, <http://www.rfc-editor.org/info/rfc5068>.
[RFC5068] Hutzler、C.、Crocker、D.、Resnick、P.、Allman、E。、およびT. Finch、「Email Submission Operations：Access and Accountability Requirements」、BCP 134、RFC 5068、DOI 10.17487 / RFC5068、 2007年11月、<http://www.rfc-editor.org/info/rfc5068>。
[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>。
[RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, DOI 10.17487/RFC5497, March 2009, <http://www.rfc-editor.org/info/rfc5497>.
[RFC5497] Clausen、T.およびC. Dearlove、「Representing Multi-Value Time in Mobile Ad Hoc Networks（MANETs）」、RFC 5497、DOI 10.17487 / RFC5497、2009年3月、<http：//www.rfc-editor。 org / info / rfc5497>。
[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>。
[RFC7184] Herberg, U., Cole, R., and T. Clausen, "Definition of Managed Objects for the Optimized Link State Routing Protocol Version 2", RFC 7184, DOI 10.17487/RFC7184, April 2014, <http://www.rfc-editor.org/info/rfc7184>.
[RFC7184] Herberg、U.、Cole、R。、およびT. Clausen、「Definition of Managed Objects for the Optimized Link State Routing Protocol Version 2」、RFC 7184、DOI 10.17487 / RFC7184、2014年4月、<http：// www.rfc-editor.org/info/rfc7184>。
[RFC7187] Dearlove, C. and T. Clausen, "Routing Multipoint Relay Optimization for the Optimized Link State Routing Protocol Version 2 (OLSRv2)", RFC 7187, DOI 10.17487/RFC7187, April 2014, <http://www.rfc-editor.org/info/rfc7187>.
[RFC7187] Dearlove、C。およびT. Clausen、「最適化されたリンクステートルーティングプロトコルバージョン2（OLSRv2）のルーティングマルチポイントリレー最適化」、RFC 7187、DOI 10.17487 / RFC7187、2014年4月、<http：//www.rfc -editor.org/info/rfc7187>。
[RFC7188] Dearlove, C. and T. Clausen, "Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs", RFC 7188, DOI 10.17487/RFC7188, April 2014, <http://www.rfc-editor.org/info/rfc7188>.
[RFC7188] Dearlove、C。およびT. Clausen、「Optimized Link State Routing Protocol Version 2（OLSRv2）and MANET Neighborhood Discovery Protocol（NHDP）Extension TLVs」、RFC 7188、DOI 10.17487 / RFC7188、2014年4月、<http：/ /www.rfc-editor.org/info/rfc7188>。
[RFC7466] Dearlove, C. and T. Clausen, "An Optimization for the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 7466, DOI 10.17487/RFC7466, March 2015, <http://www.rfc-editor.org/info/rfc7466>.
[RFC7466] Dearlove、C。およびT. Clausen、「モバイルアドホックネットワーク（MANET）近隣探索プロトコル（NHDP）の最適化」、RFC 7466、DOI 10.17487 / RFC7466、2015年3月、<http：// www。 rfc-editor.org/info/rfc7466>。
[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>。
[RFC7939] Herberg, U., Cole, R., Chakeres, I., and T. Clausen, "Definition of Managed Objects for the Neighborhood Discovery Protocol", RFC 7939, DOI 10.17487/RFC7939, August 2016, <http://www.rfc-editor.org/info/rfc7939>.
[RFC7939] Herberg、U.、Cole、R.、Chakeres、I。、およびT. Clausen、「Definition of Managed Objects for the Neighborhood Discovery Protocol」、RFC 7939、DOI 10.17487 / RFC7939、2016年8月、<http：/ /www.rfc-editor.org/info/rfc7939>。
Authors' Addresses
著者のアドレス
Thomas Clausen
トーマス・クラウセン
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
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/