[要約] RFC 7835は、Locator/ID Separation Protocol（LISP）の脅威分析に関するものであり、LISPのセキュリティ上の脆弱性と攻撃手法を調査しています。このRFCの目的は、LISPのセキュリティを向上させるためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) D. Saucez
Request for Comments: 7835 INRIA
Category: Informational L. Iannone
ISSN: 2070-1721 Telecom ParisTech
O. Bonaventure
Universite catholique de Louvain
April 2016
Locator/ID Separation Protocol (LISP) Threat Analysis
ロケーター/ ID分離プロトコル（LISP）脅威分析
Abstract
概要
This document provides a threat analysis of the Locator/ID Separation Protocol (LISP).
このドキュメントは、Locator / ID Separation Protocol（LISP）の脅威分析を提供します。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7835.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7835で入手できます。
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. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Operation Modes of Attackers . . . . . . . . . . . . . . 4
2.1.1. On-Path vs. Off-Path Attackers . . . . . . . . . . . 4
2.1.2. Internal vs. External Attackers . . . . . . . . . . . 4
2.1.3. Live vs. Time-Shifted Attackers . . . . . . . . . . . 5
2.1.4. Control-Plane vs. Data-Plane Attackers . . . . . . . 5
2.1.5. Cross-Mode Attackers . . . . . . . . . . . . . . . . 5
2.2. Threat Categories . . . . . . . . . . . . . . . . . . . . 5
2.2.1. Replay Attack . . . . . . . . . . . . . . . . . . . . 5
2.2.2. Packet Manipulation . . . . . . . . . . . . . . . . . 6
2.2.3. Packet Interception and Suppression . . . . . . . . . 6
2.2.4. Spoofing . . . . . . . . . . . . . . . . . . . . . . 6
2.2.5. Rogue Attack . . . . . . . . . . . . . . . . . . . . 7
2.2.6. Denial-of-Service (DoS) Attack . . . . . . . . . . . 7
2.2.7. Performance Attack . . . . . . . . . . . . . . . . . 7
2.2.8. Intrusion Attack . . . . . . . . . . . . . . . . . . 7
2.2.9. Amplification Attack . . . . . . . . . . . . . . . . 7
2.2.10. Passive Monitoring Attacks . . . . . . . . . . . . . 7
2.2.11. Multi-category Attacks . . . . . . . . . . . . . . . 8
3. Attack Vectors . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Gleaning . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Locator Status Bits . . . . . . . . . . . . . . . . . . . 9
3.3. Map-Version . . . . . . . . . . . . . . . . . . . . . . . 10
3.4. Routing Locator Reachability . . . . . . . . . . . . . . 11
3.5. Instance ID . . . . . . . . . . . . . . . . . . . . . . . 12
3.6. Interworking . . . . . . . . . . . . . . . . . . . . . . 12
3.7. Map-Request Messages . . . . . . . . . . . . . . . . . . 12
3.8. Map-Reply Messages . . . . . . . . . . . . . . . . . . . 13
3.9. Map-Register Messages . . . . . . . . . . . . . . . . . . 15
3.10. Map-Notify Messages . . . . . . . . . . . . . . . . . . . 15
4. Note on Privacy . . . . . . . . . . . . . . . . . . . . . . . 15
5. Threat Mitigation . . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Normative References . . . . . . . . . . . . . . . . . . 17
7.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
The Locator/ID Separation Protocol (LISP) is specified in [RFC6830]. This document provides an assessment of the potential security threats for the current LISP specifications if LISP is deployed in the Internet (i.e., a public non-trustable environment).
Locator / ID Separation Protocol（LISP）は[RFC6830]で規定されています。このドキュメントは、LISPがインターネット（つまり、信頼できない公共の環境）に配備されている場合の、現在のLISP仕様に対する潜在的なセキュリティの脅威の評価を提供します。
The document is composed of three main parts. The first part defines a general threat model that attackers use to mount attacks. The second part, using this threat model, describes the techniques based on LISP and its architecture that attackers may use to construct attacks. The third part discusses mitigation techniques and general solutions to protect LISP and its architecture from attacks.
ドキュメントは3つの主要な部分で構成されています。最初の部分では、攻撃者が攻撃を仕掛けるために使用する一般的な脅威モデルを定義します。 2番目の部分では、この脅威モデルを使用して、攻撃者が攻撃を構築するために使用する可能性のあるLISPとそのアーキテクチャに基づく手法について説明します。 3番目の部分では、軽減技術とLISPとそのアーキテクチャを攻撃から保護するための一般的なソリューションについて説明します。
This document does not consider all the possible uses of LISP as discussed in [RFC6830] and [RFC7215] and does not cover threats due to specific implementations. The document focuses on LISP unicast, including as well LISP Interworking [RFC6832], LISP Map-Server [RFC6833], and LISP Map-Versioning [RFC6834]. Additional threats may be discovered in the future while deployment continues. The reader is assumed to be familiar with these documents for understanding the present document.
このドキュメントでは、[RFC6830]と[RFC7215]で説明されているLISPのすべての可能な使用法については考慮されておらず、特定の実装による脅威については説明していません。このドキュメントは、LISPインターキャスト[RFC6832]、LISP Map-Server [RFC6833]、LISP Map-Versioning [RFC6834]などのLISPユニキャストに焦点を当てています。展開が継続している間、将来、追加の脅威が発見される可能性があります。読者は、現在のドキュメントを理解するためにこれらのドキュメントに精通していることを前提としています。
This document assumes a generic IP service and does not discuss the difference, from a security viewpoint, between using IPv4 or IPv6.
このドキュメントは、一般的なIPサービスを想定しており、セキュリティの観点から、IPv4とIPv6の使用の違いについては説明していません。
This document assumes that attackers can be located anywhere in the Internet (either in LISP sites or outside LISP sites) and that attacks can be mounted either by a single attacker or by the collusion of several attackers.
このドキュメントは、攻撃者がインターネット（LISPサイト内またはLISPサイト外）のどこにでも配置でき、単一の攻撃者または複数の攻撃者の共謀によって攻撃を仕掛けられることを想定しています。
An attacker is a malicious entity that performs the action of attacking a target in a network where LISP is (partially) deployed by leveraging LISP and/or its architecture.
攻撃者は、LISPまたはそのアーキテクチャ、あるいはその両方を利用して、LISPが（部分的に）配置されているネットワーク内のターゲットを攻撃するアクションを実行する悪意のあるエンティティです。
An attack is the action of performing an illegitimate action on a target in a network where LISP is (partially) deployed.
攻撃とは、LISPが（部分的に）配置されているネットワーク内のターゲットに対して不正なアクションを実行するアクションです。
The target of an attack is the entity (i.e., a device connected to the network or a network) that is aimed to undergo the consequences of an attack. Other entities can potentially undergo side effects of an attack, even though they are not directly targeted by the attack. The target of an attack can be selected specifically, i.e., a particular entity, or arbitrarily, i.e., any entity. Finally, an attacker can aim to attack one or several targets with a single attack.
攻撃の対象は、攻撃の結果を受けることを目的としたエンティティ（つまり、ネットワークに接続されたデバイス）です。他のエンティティは、攻撃の直接の標的ではない場合でも、攻撃の副作用を受ける可能性があります。攻撃の対象は、具体的に、つまり特定のエンティティ、または任意に、つまり任意のエンティティを選択できます。最後に、攻撃者は1回の攻撃で1つまたは複数のターゲットを攻撃することを目指します。
Section 2.1 specifies the different modes of operation that attackers can follow to mount attacks, and Section 2.2 specifies the different categories of attacks that attackers can build.
セクション2.1は、攻撃者が攻撃を開始するために従うことができるさまざまな操作モードを指定し、セクション2.2は、攻撃者が作成できる攻撃のさまざまなカテゴリを指定します。
In this document, attackers are classified according to their modes of operation, i.e., the temporal and spacial diversity of the attacker. These modes are not mutually exclusive; they can be used by attackers in any combination, and other modes may be discovered in the future. Further, attackers are not at all bound by our classification scheme, so implementers and those deploying will always need to do additional risk analysis for themselves.
このドキュメントでは、攻撃者は操作モード、つまり攻撃者の時間的および空間的多様性に従って分類されています。これらのモードは相互に排他的ではありません。攻撃者はこれらを任意の組み合わせで使用でき、他のモードが将来的に発見される可能性があります。さらに、攻撃者は私たちの分類スキームにまったく拘束されないため、実装者と配備する人は常に自分自身で追加のリスク分析を行う必要があります。
On-path attackers, also known as Men-in-the-Middle, are able to intercept and modify packets between legitimate communicating entities. On-path attackers are located either directly on the normal communication path (either by gaining access to a node on the path or by placing themselves directly on the path) or outside the location path but manage to deviate (or gain a copy of) packets sent between the communication entities. On-path attackers hence mount their attacks by modifying packets initially sent legitimately between communication entities.
パス上の攻撃者は、中間者としても知られ、正当な通信エンティティ間のパケットを傍受して変更することができます。パス上の攻撃者は、通常の通信パスに直接配置されるか（パス上のノードにアクセスするか、パスに直接配置されるか）、ロケーションパスの外部に配置されますが、パケットを逸脱（またはコピーを取得）します通信エンティティ間で送信されます。そのため、パス上の攻撃者は、最初に通信エンティティ間で正当に送信されたパケットを変更することにより、攻撃を開始します。
An attacker is called an off-path attacker if it does not have access to packets exchanged during the communication or if there is no communication. In order for their attacks to succeed, off-path attackers must hence generate packets and inject them in the network.
通信中に交換されたパケットにアクセスできない場合、または通信がない場合、攻撃者はオフパス攻撃者と呼ばれます。したがって、攻撃を成功させるために、オフパス攻撃者はパケットを生成してネットワークに挿入する必要があります。
An internal attacker launches its attack from a node located within a legitimate LISP site. Such an attacker is either a legitimate node of the site or it exploits a vulnerability to gain access to a legitimate node in the site. Because of their location, internal attackers are trusted by the site they are in.
内部の攻撃者は、正当なLISPサイト内にあるノードから攻撃を仕掛けます。このような攻撃者は、サイトの正当なノードであるか、または脆弱性を利用してサイト内の正当なノードにアクセスします。その場所のため、内部の攻撃者は自分がいるサイトから信頼されています。
On the contrary, an external attacker launches its attacks from the outside of a legitimate LISP site.
逆に、外部の攻撃者は正当なLISPサイトの外部から攻撃を開始します。
A live attacker mounts attacks for which it must remain connected as long as the attack is mounted. In other words, the attacker must remain active for the whole duration of the attack. Consequently, the attack ends as soon as the attacker (or the used attack vector) is neutralized.
ライブ攻撃者は、攻撃がマウントされている限り接続を維持する必要がある攻撃をマウントします。言い換えれば、攻撃者は、攻撃の間中ずっとアクティブなままでいなければなりません。その結果、攻撃者（または使用された攻撃ベクトル）が無力化されるとすぐに攻撃は終了します。
On the contrary, a time-shifted attacker mounts attacks that remain active after it disconnects from the Internet.
逆に、タイムシフト型の攻撃者は、インターネットから切断された後もアクティブなままの攻撃を仕掛けます。
A control-plane attacker mounts its attack by using control-plane functionalities, typically the mapping system.
コントロールプレーンの攻撃者は、コントロールプレーンの機能、通常はマッピングシステムを使用して攻撃を仕掛けます。
A data-plane attacker mounts its attack by using data-plane functionalities.
データプレーンの攻撃者は、データプレーンの機能を使用して攻撃を開始します。
As there is no complete isolation between the control plane and the data plane, an attacker can operate in the control plane (or data plane) to mount attacks targeting the data plane (or control plane) or keep the attacked and targeted planes at the same layer (i.e., from control plane to control plane or from data plane to data plane).
コントロールプレーンとデータプレーンは完全に分離されていないため、攻撃者はコントロールプレーン（またはデータプレーン）で操作して、データプレーン（またはコントロールプレーン）を標的とした攻撃を仕掛けたり、攻撃対象のプレーンとターゲットプレーンを同じ状態に維持したりできます。層（つまり、コントロールプレーンからコントロールプレーンへ、またはデータプレーンからデータプレーンへ）。
The modes of operation used by attackers are not mutually exclusive; hence, attackers can combine them to mount attacks.
攻撃者が使用する操作モードは相互に排他的ではありません。したがって、攻撃者はそれらを組み合わせて攻撃を開始できます。
For example, an attacker can launch an attack using the control plane directly from within a LISP site to which it is able to get temporary access (i.e., internal + control-plane attacker) to create a vulnerability on its target and later on (i.e., time-shifted + external attacker) mount an attack on the data plane (i.e., data-plane attacker) that leverages the vulnerability.
たとえば、攻撃者は、一時的なアクセスが可能なLISPサイト（つまり、内部+コントロールプレーン攻撃者）から直接コントロールプレーンを使用して攻撃を開始し、ターゲットに脆弱性を作成することができます（つまり、 、タイムシフト+外部攻撃者）は、脆弱性を利用するデータプレーン（つまり、データプレーン攻撃者）に攻撃を仕掛けます。
Attacks can be classified according to the eleven following categories. These categories are not mutually exclusive and can be used by attackers in any combination.
攻撃は、次の11のカテゴリに分類できます。これらのカテゴリは相互に排他的ではなく、攻撃者は任意の組み合わせで使用できます。
A replay attack happens when an attacker retransmits a packet (or a sequence of packets) without modifying it.
リプレイ攻撃は、攻撃者がパケット（または一連のパケット）を変更せずに再送信すると発生します。
A packet manipulation attack happens when an attacker receives a packet, modifies the packet (i.e., changes some information contained in the packet), and finally transmits the packet to its final destination, which can be the initial destination of the packet or a different one.
パケット操作攻撃は、攻撃者がパケットを受信し、パケットを変更（つまり、パケットに含まれる一部の情報を変更）し、最後にパケットを最終宛先に送信します。最終宛先は、パケットの最初の宛先または別の宛先にすることができます。 。
In a packet interception and suppression attack, the attacker captures the packet and drops it before it can reach its final destination.
パケットの傍受および抑制攻撃では、攻撃者はパケットをキャプチャし、最終的な宛先に到達する前にドロップします。
With a spoofing attack, the attacker injects packets in the network pretending to be another node. Spoofing attacks are made by forging source addresses in packets.
スプーフィング攻撃では、攻撃者は別のノードになりすましたパケットをネットワークに挿入します。スプーフィング攻撃は、パケット内の送信元アドレスを偽造することによって行われます。
It should be noted that with LISP, packet spoofing is similar to spoofing with any other existing tunneling technology currently deployed in the Internet. Generally, the term "spoofed packet" indicates a packet containing a source IP address that is not the actual originator of the packet. Hence, since LISP uses encapsulation, the spoofed address could be in the outer header as well as in the inner header; this translates to two types of spoofing.
LISPの場合、パケットのなりすましは、現在インターネットに展開されている他の既存のトンネリングテクノロジーのなりすましに似ています。一般に、「スプーフィングされたパケット」という用語は、パケットの実際の発信元ではないソースIPアドレスを含むパケットを示します。したがって、LISPはカプセル化を使用しているため、スプーフィングされたアドレスは外部ヘッダーと内部ヘッダーの両方に存在する可能性があります。これは、2種類のなりすましに相当します。
Inner address spoofing: The attacker uses encapsulation and uses a spoofed source address in the inner packet. In case of data-plane LISP encapsulation, that corresponds to spoofing the source Endpoint Identifier (EID) address of the encapsulated packet.
内部アドレススプーフィング：攻撃者はカプセル化を使用し、内部パケットでスプーフィングされた送信元アドレスを使用します。データプレーンLISPカプセル化の場合、これはカプセル化されたパケットのソースエンドポイントID（EID）アドレスのスプーフィングに対応します。
Outer address spoofing: The attacker does not use encapsulation and spoofs the source address of the packet. In case of data-plane LISP encapsulation, that corresponds to spoofing the source Routing Locator (RLOC) address of the encapsulated packet.
外部アドレスのスプーフィング：攻撃者はカプセル化を使用せず、パケットの送信元アドレスを偽装します。データプレーンLISPカプセル化の場合、これはカプセル化されたパケットの送信元ルーティングロケータ（RLOC）アドレスのスプーフィングに対応します。
Note that the two types of spoofing are not mutually exclusive; rather, all combinations are possible and could be used to perform different kinds of attacks. For example, an attacker outside a LISP site can generate a packet with a forged source IP address (i.e., outer address spoofing) and forward it to a LISP destination. The packet is then eventually encapsulated by a Proxy Ingress Tunnel Router (PITR) so that once encapsulated, the attack corresponds to an inner address spoofing. One can also imagine an attacker forging a packet with encapsulation where both inner and outer source addresses are spoofed.
2種類のスプーフィングは相互に排他的ではないことに注意してください。むしろ、すべての組み合わせが可能であり、さまざまな種類の攻撃を実行するために使用できます。たとえば、LISPサイト外の攻撃者は、偽造された送信元IPアドレス（つまり、外部アドレスのなりすまし）を含むパケットを生成し、LISP宛先に転送することができます。その後、パケットは最終的にProxy Ingress Tunnel Router（PITR）によってカプセル化されるため、カプセル化されると、攻撃は内部アドレスのスプーフィングに対応します。攻撃者が、内部と外部の両方の送信元アドレスが偽装されているカプセル化を使用してパケットを偽造することも想像できます。
It is important to note that the combination of inner and outer spoofing makes the identification of the attacker complex as the packet may not contain information that allows detection of the origin of the attack.
パケットには攻撃の発信元の検出を可能にする情報が含まれていない可能性があるため、内部と外部のスプーフィングの組み合わせにより、攻撃者の識別が複雑になることに注意することが重要です。
In a rogue attack, the attacker manages to appear as a legitimate source of information, without faking its identity (as opposed to a spoofing attacker).
悪意のある攻撃では、攻撃者は（なりすましの攻撃者とは対照的に）そのIDを偽造することなく、正当な情報源として表示されます。
A DoS attack aims to disrupt a specific targeted service to make it unable to operate properly.
DoS攻撃は、特定のターゲットサービスを妨害して、適切に動作できないようにすることを目的としています。
A performance attack aims to exploit computational resources (e.g., memory, processor) of a targeted node so as to make it unable to operate properly.
パフォーマンス攻撃は、ターゲットノードの計算リソース（メモリ、プロセッサなど）を悪用して、適切に動作できないようにすることを目的としています。
In an intrusion attack, the attacker gains remote access to a resource (e.g., a host, a router, or a network) or information that it legitimately should not have accessed. Intrusion attacks can lead to privacy leakages.
侵入攻撃では、攻撃者はリソース（ホスト、ルーター、ネットワークなど）または正当にアクセスされるべきではない情報へのリモートアクセスを取得します。侵入攻撃はプライバシーの漏洩につながる可能性があります。
In an amplification attack, the traffic generated by the target of the attack in response to the attack is larger than the traffic that the attacker must generate.
増幅攻撃では、攻撃に応じて攻撃のターゲットによって生成されるトラフィックは、攻撃者が生成する必要があるトラフィックよりも大きくなります。
In some cases, the data plane can be several orders of magnitude faster than the control plane at processing packets. This difference can be exploited to overload the control plane via the data plane without overloading the data plane.
場合によっては、データプレーンは、パケットの処理時にコントロールプレーンよりも数桁速くなることがあります。この違いを利用して、データプレーンをオーバーロードすることなく、データプレーンを介してコントロールプレーンをオーバーロードできます。
An attacker can use pervasive monitoring, which is a technical attack [RFC7258] that targets information about LISP traffic that may or may not be used to mount other types of attacks.
攻撃者はパーベイシブモニタリングを使用できます。これは、他のタイプの攻撃のマウントに使用される場合と使用されない場合があるLISPトラフィックに関する情報を対象とする技術的な攻撃[RFC7258]です。
Attack categories are not mutually exclusive, and any combination can be used to perform specific attacks.
攻撃カテゴリは相互に排他的ではなく、任意の組み合わせを使用して特定の攻撃を実行できます。
For example, one can mount a rogue attack to perform a performance attack starving the memory of an Ingress Tunnel Router (ITR) resulting in a DoS on the ITR.
たとえば、不正な攻撃を仕掛けて、イングレストンネルルーター（ITR）のメモリを枯渇させるパフォーマンス攻撃を実行すると、ITRでDoSが発生します。
This section presents attack techniques that may be used by attackers when leveraging LISP and/or its architecture.
このセクションでは、LISPやそのアーキテクチャを活用する際に攻撃者が使用する可能性のある攻撃手法について説明します。
To reduce the time required to obtain a mapping, the optional gleaning mechanism defined for LISP allows an xTR (Ingress and/or Egress Tunnel Router) to directly learn a mapping from the LISP-encapsulated data packets and the Map-Request packets that it receives. LISP-encapsulated data packets contain a source RLOC, destination RLOC, source EID, and destination EID. When an xTR receives an encapsulated data packet coming from a source EID for which it does not already know a mapping, it may insert the mapping between the source RLOC and the source EID in its EID-to-RLOC cache. The same technique can be used when an xTR receives a Map-Request as the Map-Request also contains a source EID address and a source RLOC. Once a gleaned entry has been added to the EID-to-RLOC cache, the xTR sends a Map-Request to retrieve the actual mapping for the gleaned EID from the mapping system.
マッピングを取得するために必要な時間を短縮するために、LISPに定義されたオプションの収集メカニズムにより、xTR（入力および/または出力トンネルルーター）は、LISPカプセル化データパケットとそれが受信するMap-Requestパケットからマッピングを直接学習できます。 LISPカプセル化データパケットには、送信元RLOC、宛先RLOC、送信元EID、および宛先EIDが含まれています。 xTRが、まだマッピングがわからないソースEIDからのカプセル化されたデータパケットを受信すると、ソースRLOCとソースEIDの間のマッピングをEID-to-RLOCキャッシュに挿入する場合があります。 Map-RequestにはソースEIDアドレスとソースRLOCも含まれているため、xTRがMap-Requestを受信するときに同じ手法を使用できます。収集されたエントリがEID-to-RLOCキャッシュに追加されると、xTRはMap-Requestを送信して、収集されたEIDの実際のマッピングをマッピングシステムから取得します。
If a packet injected by an off-path attacker and with a spoofed inner address is gleaned by an xTR, then the attacker may divert the traffic meant to be delivered to the spoofed EID as long as the gleaned entry is used by the xTR. This attack can be used as part of replay, packet manipulation, packet interception and suppression, or DoS attacks as the packets are sent to the attacker.
オフパスの攻撃者によって挿入され、スプーフィングされた内部アドレスを持つパケットがxTRによって収集された場合、収集されたエントリがxTRによって使用されている限り、攻撃者はスプーフィングされたEIDに配信されるはずのトラフィックを迂回させることができます。この攻撃は、パケットが攻撃者に送信されるときに、再生、パケット操作、パケットの傍受と抑制、またはDoS攻撃の一部として使用される可能性があります。
If the packet sent by the attacker contains a spoofed outer address instead of a spoofed inner address, then it can achieve a DoS or a performance attack as the traffic normally destined to the attacker will be redirected to the spoofed source RLOC. Such traffic may overload the owner of the spoofed source RLOC, preventing it from operating properly.
攻撃者が送信したパケットに、偽装された内部アドレスではなく偽装された外部アドレスが含まれている場合、通常は攻撃者宛てのトラフィックが偽装された送信元RLOCにリダイレクトされるため、DoSまたはパフォーマンス攻撃を実行できます。このようなトラフィックは、スプーフィングされたソースRLOCの所有者に過負荷をかけ、適切に動作することを妨げる可能性があります。
If the packet injected uses both inner and outer spoofing, the attacker can achieve a spoofing, a performance, or an amplification attack as traffic normally destined to the spoofed EID address will be sent to the spoofed RLOC address. If the attacked LISP site also generates traffic to the spoofed EID address, such traffic may have a positive amplification factor.
挿入されたパケットが内部と外部の両方のスプーフィングを使用している場合、通常はスプーフィングされたEIDアドレス宛てのトラフィックがスプーフィングされたRLOCアドレスに送信されるため、攻撃者はスプーフィング、パフォーマンス、または増幅攻撃を行うことができます。攻撃されたLISPサイトがスプーフィングされたEIDアドレスへのトラフィックも生成する場合、そのようなトラフィックは正の増幅係数を持っている可能性があります。
A gleaning attack does not only impact the data plane but can also have repercussions on the control plane as a Map-Request is sent after the creation of a gleaned entry. The attacker can then achieve DoS and performance attacks on the control plane. For example, if an attacker sends a packet for each address of a prefix not yet cached in the EID-to-RLOC cache of an xTR, the xTR will potentially send a Map-Request for each such packet until the mapping is installed, which leads to an over-utilization of the control plane as each packet generates a control-plane event. In order for this attack to succeed, the attacker may not need to use spoofing. This issue can occur even if gleaning is turned off since whether or not gleaning is used, the ITR may need to send a Map-Request in response to incoming packets whose EID is not currently in the cache.
収集攻撃は、データプレーンに影響を与えるだけでなく、収集されたエントリの作成後にMap-Requestが送信されるため、コントロールプレーンにも影響を与える可能性があります。その後、攻撃者はコントロールプレーンでDoSおよびパフォーマンス攻撃を実行できます。たとえば、攻撃者がxTRのEID-to-RLOCキャッシュにまだキャッシュされていないプレフィックスのアドレスごとにパケットを送信する場合、xTRは、マッピングがインストールされるまで、そのような各パケットに対してMap-Requestを送信する可能性があります。各パケットがコントロールプレーンイベントを生成するため、コントロールプレーンの過剰利用につながります。この攻撃が成功するためには、攻撃者はスプーフィングを使用する必要がない場合があります。この問題は、グリーニングが使用されているかどうかに関係なく、グリーニングがオフになっている場合でも発生する可能性があります。ITRは、EIDが現在キャッシュにない着信パケットに応答してMap-Requestを送信する必要がある場合があります。
Gleaning attacks fundamentally involve a time-shifted mode of operation as the attack may last as long as the gleaned entry is kept by the targeted xTR. [RFC6830] recommends storing the gleaned entries for only a few seconds, which limits the duration of the attack.
収集されたエントリが対象のxTRによって保持されている限り攻撃が続くため、グリーニング攻撃は基本的にタイムシフトモードの操作を伴います。 [RFC6830]は、収集されたエントリを数秒間のみ保存することを推奨します。これにより、攻撃の期間が制限されます。
Gleaning attacks always involve external data-plane attackers but result in attacks on either the control plane or data plane.
グリーニング攻撃には常に外部のデータプレーン攻撃者が関係しますが、コントロールプレーンまたはデータプレーンのいずれかが攻撃されます。
Note that the outer spoofed address does not need to be the RLOC of a LISP site; it may be any address.
スプーフィングされた外部アドレスがLISPサイトのRLOCである必要はないことに注意してください。任意のアドレスにすることができます。
When the L bit in the LISP header is set to 1, it indicates that the second 32-bit longword of the LISP header contains the Locator-Status-Bits (LSBs). In this field, each bit position reflects the status of one of the RLOCs mapped to the source EID found in the encapsulated packet. The reaction of a LISP xTR that receives such a packet is left as an operational choice in [RFC6830].
LISPヘッダーのLビットが1に設定されている場合、LISPヘッダーの2番目の32ビットロングワードにロケーターステータスビット（LSB）が含まれていることを示します。このフィールドでは、各ビット位置は、カプセル化されたパケットで見つかったソースEIDにマップされたRLOCの1つのステータスを反映します。そのようなパケットを受信するLISP xTRの反応は、[RFC6830]の操作上の選択として残されています。
When an attacker sends a LISP-encapsulated packet with an illegitimately crafted LSB to an xTR, it can influence the xTR's choice of the locators for the prefix associated with the source EID. In case of an off-path attacker, the attacker must inject a forged packet in the network with a spoofed inner address. An on-path attacker can manipulate the LSB of legitimate packets passing through it and hence does not need to use spoofing. Instead of manipulating the LSB field, an on-path attacker can also obtain the same result of injecting packets with invalid LSB values by replaying packets.
攻撃者が不正に作成されたLSBを含むLISPカプセル化パケットをxTRに送信すると、ソースEIDに関連付けられているプレフィックスのロケーターのxTRの選択に影響を与える可能性があります。オフパス攻撃者の場合、攻撃者は偽装された内部アドレスを使用してネットワークに偽造パケットを注入する必要があります。パス上の攻撃者は、通過する正当なパケットのLSBを操作できるため、スプーフィングを使用する必要はありません。 LSBフィールドを操作する代わりに、パス上の攻撃者は、パケットを再生することにより、無効なLSB値を持つパケットを注入した同じ結果を取得することもできます。
The LSB field can be leveraged to mount a DoS attack by either declaring all RLOCs as unreachable (all LSBs set to 0), concentrating all the traffic to one RLOC (e.g., all but one LSB set to 0), and hence overloading the RLOC concentrating all the traffic from the xTR, or by forcing packets to be sent to RLOCs that are actually not reachable (e.g., invert LSB values).
LSBフィールドを利用して、すべてのRLOCを到達不能として宣言し（すべてのLSBを0に設定）、すべてのトラフィックを1つのRLOCに集中させ（たとえば、1つ以外のすべてのLSBを0に設定）、RLOCをオーバーロードすることにより、DoS攻撃を開始できます。 xTRからのすべてのトラフィックを集中させる、または実際に到達できないRLOCにパケットを強制的に送信する（LSB値を反転するなど）。
The LSB field can also be used to mount a replay, a packet manipulation, or a packet interception and suppression attack. Indeed, if the attacker manages to be on the path between the xTR and one of the RLOCs specified in the mapping, forcing packets to go via that RLOC implies that the attacker will gain access to the packets.
LSBフィールドは、リプレイ、パケット操作、またはパケット傍受と抑制攻撃のマウントにも使用できます。実際、攻撃者がxTRとマッピングで指定されたRLOCの1つとの間のパス上にいる場合、パケットがそのRLOCを経由するように強制すると、攻撃者がパケットにアクセスできるようになります。
Attacks using the LSB fundamentally involve a time-shifted mode of operation as the attack may last as long as the reachability information gathered from the LSB is used by the xTR to decide the RLOCs to be used.
LSBから収集された到達可能性情報がxTRによって使用されるRLOCを決定するために使用される限り、攻撃は継続する可能性があるため、LSBを使用する攻撃は基本的にタイムシフト動作モードを含みます。
When the Map-Version bit of the LISP header is set to 1, it indicates that the low-order 24 bits of the first 32-bit longword of the LISP header contain a Source and Destination Map-Version. When a LISP xTR receives a LISP-encapsulated packet with the Map-Version bit set to 1, the following actions are taken:
LISPヘッダーのMap-Versionビットが1に設定されている場合、LISPヘッダーの最初の32ビットロングワードの下位24ビットにSourceおよびDestination Map-Versionが含まれていることを示します。 LISP xTRが、Map-Versionビットが1に設定されたLISPカプセル化パケットを受信すると、次のアクションが実行されます。
o It compares the Destination Map-Version found in the header with the current version of its own configured EID-to-RLOC mapping for the destination EID found in the encapsulated packet. If the received Destination Map-Version is smaller (i.e., older) than the current version, the Egress Tunnel Router (ETR) should apply the Solicit-Map-Request (SMR) procedure described in [RFC6830] and send a Map-Request with the SMR bit set.
o ヘッダーにあるDestination Map-Versionと、カプセル化されたパケットにある宛先EIDの独自に構成されたEID-to-RLOCマッピングの現在のバージョンを比較します。受信した宛先マップバージョンが現在のバージョンよりも小さい（つまり、古い）場合、出力トンネルルーター（ETR）は[RFC6830]で説明されているSolicit-Map-Request（SMR）手順を適用し、 SMRビットセット。
o If a mapping exists in the EID-to-RLOC cache for the source EID, then it compares the Map-Version of that entry with the Source Map-Version found in the header of the packet. If the stored mapping is older (i.e., the Map-Version is smaller), than the source version of the LISP-encapsulated packet, the xTR, should send a Map-Request for the source EID.
o ソースEIDのEID-to-RLOCキャッシュにマッピングが存在する場合、そのエントリのMap-VersionをパケットのヘッダーにあるソースMap-Versionと比較します。保存されたマッピングが古い場合（つまり、Map-Versionが小さい場合）、LISPカプセル化パケットのソースバージョンよりもxTRがソースEIDのMap-Requestを送信する必要があります。
A cross-mode attacker can use the Map-Version bit to mount a DoS attack, an amplification attack, or a spoofing attack. For instance, if the mapping cached at the xTR is outdated, the xTR will send a Map-Request to retrieve the new mapping, which can yield to a DoS attack (by excess of signaling traffic) or an amplification attack if the data-plane packet sent by the attacker is smaller, or otherwise uses fewer resources, than the control-plane packets sent in response to the attacker's packet. With a spoofing attack, and if the xTR considers that the spoofed ITR has an outdated mapping, it will send an SMR to the spoofed ITR, which can result in a performance, amplification, or DoS attack as well.
クロスモードの攻撃者は、Map-Versionビットを使用して、DoS攻撃、増幅攻撃、またはスプーフィング攻撃を仕掛けることができます。たとえば、xTRでキャッシュされたマッピングが古くなっている場合、xTRはMap-Requestを送信して新しいマッピングを取得します。これにより、DoS攻撃（シグナリングトラフィックの過剰による）や、データプレーンが攻撃者が送信したパケットは、攻撃者のパケットに応答して送信されたコントロールプレーンパケットよりも小さいか、そうでなければ少ないリソースを使用します。スプーフィング攻撃の場合、xTRがスプーフィングされたITRに古いマッピングがあると見なすと、SMRがスプーフィングされたITRに送信され、パフォーマンス、増幅、またはDoS攻撃も発生する可能性があります。
Map-Version attackers are inherently cross-mode as the Map-Version is a method to put control information in the data plane. Moreover, this vector involves live attackers. Nevertheless, on-path attackers do not have a specific advantage over off-path attackers.
Map-Versionはデータプレーンに制御情報を配置する方法であるため、Map-Versionの攻撃者は本質的にクロスモードです。さらに、このベクトルにはライブ攻撃者が含まれます。それでも、パス上の攻撃者には、パス外の攻撃者に比べて特定の利点はありません。
The Nonce-Present and Echo-Nonce bits in the LISP header are used to verify the reachability of an xTR. A testing xTR sets the Echo-Nonce and the Nonce-Present bits in LISP-encapsulated data packets and includes a random nonce in the LISP header of the packets. Upon reception of these packets, the tested xTR stores the nonce and echoes it whenever it returns a LISP-encapsulated data packet to the testing xTR. The reception of the echoed nonce confirms that the tested xTR is reachable.
LISPヘッダーのNonce-PresentビットとEcho-Nonceビットは、xTRの到達可能性を確認するために使用されます。 xTRのテストでは、LISPカプセル化データパケットにEcho-NonceビットとNonce-Presentビットを設定し、パケットのLISPヘッダーにランダムナンスを含めます。これらのパケットを受信すると、テスト済みのxTRはnonceを格納し、LISPカプセル化されたデータパケットをテスト用xTRに返すたびにnonceをエコーします。エコーされたナンスの受信は、テストされたxTRが到達可能であることを確認します。
An attacker can interfere with the reachability test by sending two different types of packets:
攻撃者は、2つの異なるタイプのパケットを送信することにより、到達可能性テストを妨害する可能性があります。
1. LISP-encapsulated data packets with the Nonce-Present bit set and a random nonce. Such packets are normally used in response to a reachability test.
1. Nonce-Presentビットセットとランダムnonceを含むLISPカプセル化データパケット。このようなパケットは通常、到達可能性テストに応答して使用されます。
2. LISP-encapsulated data packets with the Nonce-Present and the Echo-Nonce bits both set. These packets will force the receiving ETR to store the received nonce and echo it in the LISP-encapsulated packets that it sends. These packets are normally used as a trigger for a reachability test.
2. Nonce-PresentビットとEcho-Nonceビットの両方が設定されたLISPカプセル化データパケット。これらのパケットにより、受信ETRは受信したナンスを強制的に保存し、送信するLISPカプセル化パケットにエコーします。これらのパケットは通常、到達可能性テストのトリガーとして使用されます。
The first type of packets are used to make xTRs think that another xTR is reachable when it is not. It is hence a way to mount a DoS attack (i.e., the ITR will send its packet to a non-reachable ETR when it should use another one).
最初のタイプのパケットは、xTRが到達可能でないときに別のxTRに到達可能であるとxTRに認識させるために使用されます。したがって、これはDoS攻撃を開始する方法です（つまり、ITRは別のETRを使用する必要があるときに、到達不能なETRにパケットを送信します）。
The second type of packets could be exploited to attack the nonce-based reachability test. If the attacker sends a continuous flow of packets that each have a different random nonce, the ETR that receives such packets will continuously change the nonce that it returns to the remote ITR, which can yield to a performance attack. If the remote ITR tries a nonce reachability test, this test may fail because the ETR may echo an invalid nonce. This hence yields to a DoS attack.
2番目のタイプのパケットは、nonceベースの到達可能性テストを攻撃するために悪用される可能性があります。攻撃者がランダムなナンスがそれぞれ異なるパケットの連続フローを送信すると、そのようなパケットを受信するETRは、リモートITRに返すナンスを継続的に変更し、パフォーマンス攻撃をもたらす可能性があります。リモートITRがナンス到達可能性テストを試行すると、ETRが無効なナンスをエコーする可能性があるため、このテストは失敗する可能性があります。これにより、DoS攻撃が発生します。
In the case of an on-path attacker, a packet manipulation attack is necessary to mount the attack. To mount such an attack, an off-path attacker must mount an outer address spoofing attack.
パス上の攻撃者の場合、攻撃を仕掛けるためにパケット操作攻撃が必要です。このような攻撃を仕掛けるには、パス外の攻撃者が外部アドレスのスプーフィング攻撃を仕掛ける必要があります。
If an xTR chooses to periodically check with active probes the liveness of entries in its EID-to-RLOC cache (as described in Section 6.3 of [RFC6830]), then this may amplify the attack that caused the insertion of entries being checked.
xTRがEID-to-RLOCキャッシュ内のエントリの活性を定期的にアクティブプローブでチェックすることを選択した場合（[RFC6830]のセクション6.3で説明されているように）、これにより、チェックされるエントリの挿入を引き起こした攻撃が増幅する可能性があります。
LISP allows a 24-bit value called Instance ID to be carried in its header; it's used on the ITR to indicate which local Instance ID has been used for encapsulation, while on the ETR, the Instance ID decides which forwarding table to use to forward the decapsulated packet in the LISP site.
LISPでは、インスタンスIDと呼ばれる24ビット値をヘッダーに含めることができます。これは、カプセル化に使用されたローカルインスタンスIDを示すためにITRで使用されますが、ETRでは、インスタンスIDは、LISPサイトでカプセル化解除されたパケットを転送するために使用する転送テーブルを決定します。
An attacker (either a control-plane or data-plane attacker) can use the Instance ID functionality to mount an intrusion attack.
攻撃者（コントロールプレーンまたはデータプレーンの攻撃者）は、インスタンスID機能を使用して侵入攻撃を仕掛けることができます。
[RFC6832] defines Proxy-ITR and Proxy-ETR network elements to allow LISP and non-LISP sites to communicate. The Proxy-ITR has functionality similar to the ITR; however, its main purpose is to encapsulate packets arriving from the Default-Free Zone (DFZ) in order to reach LISP sites. A Proxy Egress Tunnel Router (PETR) has functionality similar to the ETR; however, its main purpose is to inject de-encapsulated packets in the DFZ in order to reach non-LISP sites from LISP sites. As a PITR (or PETR) is a particular case of ITR (or ETR), it is subject to similar attacks as ITRs (or ETRs).
[RFC6832]は、Proxy-ITRおよびProxy-ETRネットワーク要素を定義して、LISPサイトと非LISPサイトが通信できるようにします。 Proxy-ITRにはITRと同様の機能があります。ただし、その主な目的は、LISPサイトに到達するために、デフォルトフリーゾーン（DFZ）から到着するパケットをカプセル化することです。プロキシ出力トンネルルーター（PETR）には、ETRと同様の機能があります。ただし、その主な目的は、カプセル化されていないパケットをDFZに挿入して、LISPサイトから非LISPサイトに到達することです。 PITR（またはPETR）はITR（またはETR）の特定のケースであるため、ITR（またはETR）と同様の攻撃の対象になります。
As any other system relying on proxies, LISP interworking can be used by attackers to hide their exact origin in the network.
プロキシに依存する他のシステムと同様に、攻撃者はLISPインターワーキングを使用して、ネットワーク内の正確な発信元を隠すことができます。
A control-plane off-path attacker can exploit Map-Request messages to mount DoS, performance, or amplification attacks. By sending Map-Request messages at a high rate, the attacker can overload nodes involved in the mapping system. For instance, sending Map-Requests at a high rate can considerably increase the state maintained in a Map-Resolver or consume CPU cycles on ETRs that have to process the Map-Request packets they receive in their slow path (i.e., performance or DoS attack). When the Map-Reply packet is larger than the Map-Request sent by the attacker, that yields to an amplification attack. The attacker can combine the attack with a spoofing attack to overload the node to which the spoofed address is actually attached.
コントロールプレーンのオフパス攻撃者は、Map-Requestメッセージを悪用して、DoS、パフォーマンス、または増幅攻撃を仕掛けることができます。攻撃者は、Map-Requestメッセージを高速で送信することにより、マッピングシステムに関与するノードに過負荷をかけることができます。たとえば、Map-Requestを高速で送信すると、Map-Resolverで維持される状態が大幅に増加するか、遅いパスで受信するMap-Requestパケットを処理する必要があるETRでCPUサイクルを消費する可能性があります（つまり、パフォーマンスまたはDoS攻撃） ）。 Map-Replyパケットが攻撃者によって送信されたMap-Requestより大きい場合、増幅攻撃に屈します。攻撃者は、攻撃をスプーフィング攻撃と組み合わせて、スプーフィングされたアドレスが実際に接続されているノードに過負荷をかけることができます。
Note that if the attacker sets the P bit (Probe Bit) in the Map-Request, the Map-Request will be legitimately sent directly to the ETR instead of passing through the mapping system.
攻撃者がMap-RequestでPビット（プローブビット）を設定した場合、Map-Requestは、マッピングシステムを通過する代わりに、ETRに直接合法的に送信されることに注意してください。
The SMR bit can be used to mount a variant of these attacks.
SMRビットは、これらの攻撃の変種をマウントするために使用できます。
For efficiency reasons, Map-Records can be appended to Map-Request messages. When an xTR receives a Map-Request with appended Map-Records, it does the same operations as for the other Map-Request messages and so is subject to the same attacks. However, it also installs in its EID-to-RLOC cache the Map-Records contained in the Map-Request. An attacker can then use this vector to force the installation of mappings in its target xTR. Consequently, the EID-to-RLOC cache of the xTR is polluted by potentially forged mappings allowing the attacker to mount any of the attacks categorized in Section 2.2 (see Section 3.8 for more details). Note that the attacker does not need to forge the mappings present in the Map-Request to achieve a performance or DoS attack. Indeed, if the attacker owns a large enough EID prefix, it can de-aggregate it in many small prefixes, each corresponding to another mapping, and it installs them in the xTR cache by means of the Map-Request.
効率上の理由から、Map-RecordをMap-Requestメッセージに追加できます。 xTRがMap-Recordが付加されたMap-Requestを受信すると、他のMap-Requestメッセージと同じ操作を実行するため、同じ攻撃を受ける可能性があります。ただし、EIDからRLOCへのキャッシュには、Map-Requestに含まれるMap-Recordsもインストールされます。攻撃者はこのベクトルを使用して、ターゲットxTRにマッピングを強制的にインストールできます。その結果、xTRのEIDからRLOCへのキャッシュは、潜在的に偽造されたマッピングによって汚染され、攻撃者はセクション2.2に分類された攻撃をマウントできるようになります（詳細はセクション3.8を参照）。攻撃者は、パフォーマンスまたはDoS攻撃を達成するためにMap-Requestに存在するマッピングを偽造する必要がないことに注意してください。実際、攻撃者が十分に大きなEIDプレフィックスを所有している場合、それを別のマッピングに対応する多くの小さなプレフィックスに分解し、Map-Requestを使用してxTRキャッシュにインストールすることができます。
Moreover, attackers can use Map Resolver and/or Map Server network elements to relay its attacks and hide the origin of the attack. Indeed, on the one hand, a Map Resolver is used to dispatch Map-Request to the mapping system, and on the other hand, a Map Server is used to dispatch Map-Requests coming from the mapping system to ETRs that are authoritative for the EID in the Map-Request.
さらに、攻撃者はMap ResolverやMap Serverネットワーク要素を使用して、攻撃を中継し、攻撃の発信元を隠すことができます。実際、一方ではMap Resolverを使用してMap-Requestをマッピングシステムにディスパッチし、他方ではMap Serverを使用してマッピングシステムからのMap-Requestを信頼できるETRにディスパッチします。 Map-RequestのEID。
Most of the security risks associated with Map-Reply messages will depend on the 64-bit nonce that is included in a Map-Request and returned in the Map-Reply. Given the size of the nonce (64 bits), if a best current practice is used [RFC4086] and if an ETR does not accept Map-Reply messages with an invalid nonce, the risk of an off-path attack is limited. Nevertheless, the nonce only confirms that the Map-Reply received was sent in response to a Map-Request sent; it does not validate the contents of that Map-Reply.
Map-Replyメッセージに関連するセキュリティリスクのほとんどは、Map-Requestに含まれ、Map-Replyで返される64ビットのナンスに依存します。 nonceのサイズ（64ビット）を考慮して、現在のベストプラクティスが使用されている場合[RFC4086]、ETRが無効なnonceを持つMap-Replyメッセージを受け入れない場合、パス外の攻撃のリスクが制限されます。それにもかかわらず、ノンスは、受信したMap-Replyが、送信されたMap-Requestへの応答として送信されたことを確認するだけです。そのMap-Replyの内容は検証しません。
If an attacker manages to send a valid (i.e., in response to a Map-Request and with the correct nonce) Map-Reply to an ITR, then it can perform any of the attacks categorized in Section 2.2 as it can inject forged mappings directly in the ITR EID-to-RLOC cache. For instance, if the mapping injected to the ITR points to the address of a node controlled by the attacker, it can mount replay, packet manipulation, packet interception and suppression, or DoS attacks, as it will receive every packet destined to a destination lying in the EID prefix of the injected mapping. In addition, the attacker can inject a plethora of mappings in the ITR to mount a performance attack by filling up the EID-to-RLOC cache of the ITR. The attacker can also mount an amplification attack if the ITR at that time is sending a large number of packets to the EIDs matching the injected mapping. In this case, the RLOC address associated with the mapping is the address of the real target of the attacker, so all the traffic of the ITR will be sent to the target, which means that with one single packet the attacker may generate very high traffic towards its final target.
攻撃者がITRに有効な（つまり、Map-Requestに応答し、正しいnonceを使用して）Map-Replyを送信できた場合、偽造されたマッピングを直接挿入できるため、セクション2.2に分類される攻撃を実行できます。 ITR EID-to-RLOCキャッシュ内。たとえば、ITRに挿入されたマッピングが攻撃者によって制御されているノードのアドレスを指している場合、存在する宛先に宛てられたすべてのパケットを受信するため、リプレイ、パケット操作、パケット傍受および抑制、またはDoS攻撃をマウントできます。挿入されたマッピングのEIDプレフィックス。さらに、攻撃者はITRに大量のマッピングを挿入して、ITRのEIDからRLOCへのキャッシュを埋めることにより、パフォーマンス攻撃を仕掛けることができます。注入されたマッピングと一致するEIDにその時点でITRが大量のパケットを送信している場合、攻撃者は増幅攻撃を行うこともできます。この場合、マッピングに関連付けられたRLOCアドレスは攻撃者の実際のターゲットのアドレスであるため、ITRのすべてのトラフィックがターゲットに送信されます。つまり、1つのパケットで攻撃者は非常に高いトラフィックを生成する可能性があります最終目標に向かって。
If the attacker is a valid ETR in the system, it can mount a rogue attack if it uses prefix overclaiming. In such a scenario, the attacker ETR replies to a legitimate Map-Request message that it received with a Map-Reply message that contains an EID prefix that is larger than the prefix owned by the attacker. For example, if the owned prefix is 192.0.2.0/25 but the Map-Reply contains a mapping for 192.0.2.0/24, then the mapping will influence packets destined to EIDs other than the one the attacker has authority on. With such technique, the attacker can mount the attacks presented above as it can (partially) control the mappings installed on its target ITR. To force its target ITR to send a Map-Request, nothing prevents the attacker to initiate some communication with the ITR. This method can be used by internal attackers that want to control the mappings installed in their site. To that aim, they simply have to collude with an external attacker ready to overclaim prefixes on behalf of the internal attacker.
攻撃者がシステムで有効なETRである場合、プレフィックスの過剰要求を使用すると、不正な攻撃を仕掛けることができます。このようなシナリオでは、攻撃者のETRは、受信した正当なMap-Requestメッセージに、攻撃者が所有するプレフィックスよりも大きいEIDプレフィックスを含むMap-Replyメッセージで応答します。たとえば、所有プレフィックスが192.0.2.0/25であるのに、Map-Replyに192.0.2.0/24のマッピングが含まれている場合、そのマッピングは、攻撃者が権限を持っているEID以外のEID宛てのパケットに影響します。このような手法を使用すると、攻撃者は、ターゲットITRにインストールされているマッピングを（部分的に）制御できるため、上記の攻撃を開始できます。ターゲットITRがMap-Requestを送信するように強制するために、攻撃者がITRとの通信を開始するのを妨げるものはありません。この方法は、サイトにインストールされているマッピングを制御したい内部の攻撃者によって使用される可能性があります。そのためには、内部の攻撃者に代わってプレフィックスを過剰に要求する準備ができている外部の攻撃者と共謀する必要があります。
Note that when the Map-Reply is in response to a Map-Request sent via the mapping system (i.e., not sent directly from the ITR to an ETR), the attacker does not need to use a spoofing attack to achieve its attack as by design the source IP address of a Map-Reply is not known in advance by the ITR.
Map-Replyがマッピングシステムを介して送信されたMap-Requestに応答する場合（つまり、ITRからETRに直接送信されない場合）、攻撃者はスプーフィング攻撃を使用して攻撃を行う必要がないことに注意してください。 Map-ReplyのソースIPアドレスを設計することは、ITRによって事前に認識されていません。
Map-Request and Map-Reply messages are exposed to any type of attackers, on-path or off-path but also external or internal attackers. Also, even though they are control messages, they can be leveraged by data-plane attackers. As the decision of removing mappings is based on the TTL indicated in the mapping, time-shifted attackers can take advantage of injecting forged mappings as well.
Map-RequestおよびMap-Replyメッセージは、オンパスまたはオフパスのあらゆるタイプの攻撃者に公開されますが、外部または内部の攻撃者にも公開されます。また、制御メッセージであっても、データプレーンの攻撃者がそれらを利用する可能性があります。マッピングを削除するかどうかの決定は、マッピングに示されているTTLに基づいているため、タイムシフト攻撃者は、偽造されたマッピングを注入することも利用できます。
Map-Register messages are sent by ETRs to Map Servers to indicate to the mapping system the EID prefixes associated with them. The Map-Register message provides an EID prefix and the list of ETRs that are able to provide Map-Replies for the EID covered by the EID prefix.
Map-Registerメッセージは、ETRからMap Serverに送信され、関連付けられたEIDプレフィックスをマッピングシステムに示します。 Map-Registerメッセージは、EIDプレフィックスと、EIDプレフィックスでカバーされるEIDのMap-Repliesを提供できるETRのリストを提供します。
As Map-Register messages are protected by an authentication mechanism, only a compromised ETR can register itself to its allocated Map Server.
Map-Registerメッセージは認証メカニズムによって保護されているため、侵害されたETRのみが割り当てられたMap Serverに登録できます。
A compromised ETR can overclaim the prefix it owns in order to influence the route followed by Map-Requests for EIDs outside the scope of its legitimate EID prefix (see Section 3.8 for the list of overclaiming attacks).
侵害されたETRは、それが所有するプレフィックスを過剰に要求して、正当なEIDプレフィックスの範囲外のEIDに対するMap-Requestsが続くルートに影響を与えることができます（過大な攻撃のリストについては、セクション3.8を参照してください）。
A compromised ETR can also de-aggregate its EID prefix in order to register more EID prefixes than necessary to its Map Servers (see Section 3.7 for the impact of de-aggregation of prefixes by an attacker).
侵害されたETRは、EIDプレフィックスを集約解除して、マップサーバーに必要以上のEIDプレフィックスを登録することもできます（攻撃者によるプレフィックスの集約解除の影響については、セクション3.7を参照してください）。
Similarly, a compromised Map Server can accept an invalid registration or advertise an invalid EID prefix to the mapping system.
同様に、不正使用されたMap Serverは無効な登録を受け入れるか、無効なEIDプレフィックスをマッピングシステムにアドバタイズできます。
Map-Notify messages are sent by a Map Server to an ETR to acknowledge the reception and processing of a Map-Register message.
Map-Notifyメッセージは、Map-Registerメッセージの受信と処理を確認するために、Map ServerからETRに送信されます。
Similarly, to the pair Map-Request/Map-Reply, the pair Map-Register/ Map-Notify is protected by a nonce making it difficult for an attacker to inject a falsified notification to an ETR to make this ETR believe that the registration succeeded when it has not.
同様に、Map-Request / Map-Replyのペアに対して、Map-Register / Map-Notifyのペアはナンスによって保護されているため、攻撃者がETRに偽の通知を挿入して、このETRに登録が成功したと信じ込ませることは困難です。そうでない場合。
As reviewed in [RFC6973], universal privacy considerations are difficult to establish as the privacy definitions may vary for different scenarios. As a consequence, this document does not aim to identify privacy issues related to the LISP protocol, but the security threats identified in this document could play a role in privacy threats as defined in Section 5 of [RFC6973].
[RFC6973]で確認されているように、プライバシーの定義はシナリオによって異なる可能性があるため、普遍的なプライバシーの考慮事項を確立することは困難です。結果として、このドキュメントはLISPプロトコルに関連するプライバシーの問題を特定することを目的としませんが、このドキュメントで特定されたセキュリティの脅威は、[RFC6973]のセクション5で定義されているプライバシーの脅威に役割を果たす可能性があります。
Similar to public deployments of any other control-plane protocol, in an Internet deployment, LISP mappings are public and hence provide information about the infrastructure and reachability of LISP sites (i.e., the addresses of the edge routers). Depending upon deployment details, LISP map replies might or might not provide finer-grained and more detailed information than is available with currently deployed routing and control protocols.
他のコントロールプレーンプロトコルのパブリック配置と同様に、インターネット配置では、LISPマッピングはパブリックであるため、LISPサイトのインフラストラクチャと到達可能性に関する情報（つまり、エッジルーターのアドレス）を提供します。展開の詳細に応じて、LISPマップ応答は、現在展開されているルーティングおよび制御プロトコルで利用できるよりもきめ細かい詳細情報を提供する場合としない場合があります。
Most of the above threats can be mitigated with careful deployment and configuration (e.g., filter) and also by applying the general rules of security, e.g., only activating features that are necessary for the deployment and verifying the validity of the information obtained from third parties.
上記の脅威のほとんどは、慎重な展開と構成（例：フィルター）で、またセキュリティの一般的なルールを適用することで軽減できます。たとえば、展開に必要な機能のみをアクティブ化し、サードパーティから取得した情報の有効性を検証します。 。
The control plane is the most critical part of LISP from a security viewpoint, and it is worth noticing that the LISP specifications already offer an authentication mechanism for mappings registration [RFC6833]. This mechanism, combined with LISP-SEC [LISP-SEC], strongly mitigates threats in non-trustable environments such as the Internet. Moreover, an authentication data field for Map-Request messages and Encapsulated Control messages was allocated [RFC6830]. This field provides a general authentication mechanism technique for the LISP control plane that future specifications may use while staying backward compatible. The exact technique still has to be designed and defined. To maximally mitigate the threats on the mapping system, authentication must be used, whenever possible, for both Map-Request and Map-Reply messages and for messages exchanged internally among elements of the mapping system, such as specified in [LISP-SEC] and [LISP-DDT].
コントロールプレーンはセキュリティの観点からLISPの最も重要な部分であり、LISP仕様がすでにマッピング登録の認証メカニズムを提供していることは注目に値します[RFC6833]。このメカニズムをLISP-SEC [LISP-SEC]と組み合わせると、インターネットなどの信頼できない環境での脅威を大幅に軽減できます。さらに、Map-RequestメッセージとEncapsulated Controlメッセージの認証データフィールドが割り当てられました[RFC6830]。このフィールドは、LISPコントロールプレーンの一般的な認証メカニズムテクニックを提供します。将来の仕様では、下位互換性を維持しながら使用できます。正確な手法は、依然として設計および定義する必要があります。マッピングシステムの脅威を最大限に軽減するには、可能な場合は常に、Map-RequestメッセージとMap-Replyメッセージの両方、および[LISP-SEC]で指定されているようなマッピングシステムの要素間で内部的に交換されるメッセージに認証を使用する必要があります。 [LISP-DDT]。
Systematically applying filters and rate limitation, as proposed in [RFC6830], will mitigate most of the threats presented in this document. In order to minimize the risk of overloading the control plane with actions triggered from data-plane events, such actions should be rate limited.
[RFC6830]で提案されているように、フィルターとレート制限を体系的に適用すると、このドキュメントで提示されているほとんどの脅威が軽減されます。データプレーンイベントからトリガーされるアクションでコントロールプレーンに過負荷がかかるリスクを最小限に抑えるには、そのようなアクションをレート制限する必要があります。
Moreover, all information opportunistically learned (e.g., with LSB or gleaning) should be used with care until they are verified. For example, a reachability change learned with LSB should not be used directly to decide the destination RLOC but instead should trigger a rate-limited reachability test. Similarly, a gleaned entry should be used only for the flow that triggered the gleaning procedure until the gleaned entry has been verified [Trilogy].
さらに、日和見的に学習されたすべての情報（LSBや収集など）は、検証されるまで注意して使用する必要があります。たとえば、LSBで学習された到達可能性の変更は、宛先RLOCを決定するために直接使用するのではなく、レート制限された到達可能性テストをトリガーする必要があります。同様に、収集されたエントリは、収集されたエントリが検証されるまで、収集手順をトリガーしたフローに対してのみ使用する必要があります[Trilogy]。
This document provides a threat analysis and proposes mitigation techniques for the Locator/ID Separation Protocol.
このドキュメントでは、脅威の分析を提供し、Locator / ID分離プロトコルの軽減技術を提案します。
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013, <http://www.rfc-editor.org/info/rfc6830>.
[RFC6830]ファリナッチ、D。、フラー、V。、マイヤー、D。、およびD.ルイス、「ロケータ/ ID分離プロトコル（LISP）」、RFC 6830、DOI 10.17487 / RFC6830、2013年1月、<http：/ /www.rfc-editor.org/info/rfc6830>。
[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites", RFC 6832, DOI 10.17487/RFC6832, January 2013, <http://www.rfc-editor.org/info/rfc6832>.
[RFC6832]ルイスD.、マイヤーD.、ファリナッチD.、およびV.フラー「ロケータ/ ID分離プロトコル（LISP）サイトと非LISPサイト間のインターワーキング」、RFC 6832、DOI 10.17487 / RFC6832、1月2013、<http://www.rfc-editor.org/info/rfc6832>。
[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation Protocol (LISP) Map-Server Interface", RFC 6833, DOI 10.17487/RFC6833, January 2013, <http://www.rfc-editor.org/info/rfc6833>.
[RFC6833] Fuller、V。およびD. Farinacci、「Locator / ID Separation Protocol（LISP）Map-Server Interface」、RFC 6833、DOI 10.17487 / RFC6833、2013年1月、<http://www.rfc-editor.org / info / rfc6833>。
[RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Map-Versioning", RFC 6834, DOI 10.17487/RFC6834, January 2013, <http://www.rfc-editor.org/info/rfc6834>.
[RFC6834] Iannone、L.、Saucez、D。、およびO. Bonaventure、「Locator / ID Separation Protocol（LISP）Map-Versioning」、RFC 6834、DOI 10.17487 / RFC6834、2013年1月、<http：// www。 rfc-editor.org/info/rfc6834>。
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <http://www.rfc-editor.org/info/rfc6973>.
[RFC6973] Cooper、A.、Tschofenig、H.、Aboba、B.、Peterson、J.、Morris、J.、Hansen、M。、およびR. Smith、「インターネットプロトコルのプライバシーに関する考慮事項」、RFC 6973、DOI 10.17487 / RFC6973、2013年7月、<http://www.rfc-editor.org/info/rfc6973>。
[LISP-DDT] Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP Delegated Database Tree", Work in Progress, draft-ietf-lisp-ddt-03, April 2015.
[LISP-DDT] Fuller、V.、Lewis、D.、Ermagan、V。、およびA. Jain、「LISP Delegated Database Tree」、Work in Progress、draft-ietf-lisp-ddt-03、2015年4月。
[LISP-SEC] Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Saucez, "LISP-Security (LISP-SEC)", Work in Progress, draft-ietf-lisp-sec-10, October 2015.
[LISP-SEC] Maino、F.、Ermagan、V.、Cabellos-Aparicio、A。、およびD. Saucez、「LISP-Security（LISP-SEC）」、Work in Progress、draft-ietf-lisp-sec- 2015年10月10日。
[PRELIM-LISP-THREAT] Bagnulo, M., "Preliminary LISP Threat Analysis", Work in Progress, draft-bagnulo-lisp-threat-01, July 2007.
[PRELIM-LISP-THREAT] Bagnulo、M。、「Preliminary LISP Threat Analysis」、Work in Progress、draft-bagnulo-lisp-threat-01、2007年7月。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <http://www.rfc-editor.org/info/rfc4086>.
[RFC4086] Eastlake 3rd、D.、Schiller、J.、and S. Crocker、 "Randomness Requirements for Security"、BCP 106、RFC 4086、DOI 10.17487 / RFC4086、June 2005、<http：//www.rfc-editor .org / info / rfc4086>。
[RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-Pascual, J., and D. Lewis, "Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations", RFC 7215, DOI 10.17487/RFC7215, April 2014, <http://www.rfc-editor.org/info/rfc7215>.
[RFC7215] Jakab、L.、Cabellos-Aparicio、A.、Coras、F.、Domingo-Pascual、J。、およびD. Lewis、「Locator / Identifier Separation Protocol（LISP）Network Element Deployment Considerations」、RFC 7215、 DOI 10.17487 / RFC7215、2014年4月、<http://www.rfc-editor.org/info/rfc7215>。
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7258] Farrell、S。およびH. Tschofenig、「Pervasive Monitoring Is a Attack」、BCP 188、RFC 7258、DOI 10.17487 / RFC7258、2014年5月、<http://www.rfc-editor.org/info/rfc7258 >。
[Trilogy] Saucez, D. and L. Iannone, "How to mitigate the effect of scans on mapping systems", Trilogy Future Internet Summer School, 2009.
[Trilogy] Saucez、D。およびL. Iannone、「マッピングシステムに対するスキャンの影響を緩和する方法」、Trilogy Future Internet Summer School、2009年。
Acknowledgments
謝辞
This document builds upon the document by Marcelo Bagnulo [PRELIM-LISP-THREAT], where the flooding attack and the reference environment was first described.
このドキュメントは、フラッディング攻撃とリファレンス環境が最初に説明されたMarcelo Bagnulo [PRELIM-LISP-THREAT]によるドキュメントに基づいています。
The authors would like to thank Ronald Bonica, Deborah Brungard, Albert Cabellos, Ross Callon, Noel Chiappa, Florin Coras, Vina Ermagan, Dino Farinacci, Stephen Farrell, Joel Halpern, Emily Hiltzik, Darrel Lewis, Edward Lopez, Fabio Maino, Terry Manderson, and Jeff Wheeler for their comments.
著者は、ロナルドボニカ、デボラブランガード、アルバートカベロス、ロスカロン、ノエルチアッパ、フローリンコーラス、ヴィナエルマガン、ディノファリナッチ、スティーブンファレル、ジョエルハルパーン、エミリーヒルツィク、ダレルルイス、エドワードロペス、ファビオマイノ、テリーマンダーソンに感謝します、およびジェフウィーラーのコメント。
This work has been partially supported by the INFSO-ICT-216372 TRILOGY Project <http://www.trilogy-project.org>.
この作業は、INFSO-ICT-216372 TRILOGYプロジェクト<http://www.trilogy-project.org>によって部分的にサポートされています。
The work of Luigi Iannone has been partially supported by the ANR-13-INFR-0009 LISP-Lab Project <http://www.lisp-lab.org> and the EIT KIC ICT-Labs SOFNETS Project.
Luigi Iannoneの作業は、ANR-13-INFR-0009 LISP-Labプロジェクト<http://www.lisp-lab.org>およびEIT KIC ICT-Labs SOFNETSプロジェクトによって部分的にサポートされています。
Authors' Addresses
著者のアドレス
Damien Saucez INRIA 2004 route des Lucioles BP 93 06902 Sophia Antipolis Cedex France
ダミアンサウセINRIA 2004ルートデルシオレスBP 93 06902ソフィアアンティポリスセデックスフランス
Email: damien.saucez@inria.fr
Luigi Iannone Telecom ParisTech 23, Avenue d'Italie, CS 51327 75214 Paris Cedex 13 France
Luigi Iannone Telecom ParisTech 23、Avenue d'Italie、CS 51327 75214 Paris Cedex 13 France
Email: ggx@gigix.net
Olivier Bonaventure Universite catholique de Louvain Place St. Barbe 2 Louvain la Neuve Belgium
Olivier Bonaventureカトリックルーヴァン大学Place St. Barbe 2 Louvain la Neuveベルギー
Email: olivier.bonaventure@uclouvain.be