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
        
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).

本文档提供了定位器/ID分离协议(LISP)的威胁分析。

Status of This Memo

关于下段备忘

This document is not an Internet Standards Track specification; it is published for informational purposes.

本文件不是互联网标准跟踪规范;它是为了提供信息而发布的。

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)的产品。它代表了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.

版权所有(c)2016 IETF信托基金和确定为文件作者的人员。版权所有。

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)自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本,并提供简化BSD许可证中所述的无担保。

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
        
   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
        
1. Introduction
1. 介绍

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).

[RFC6830]中规定了定位器/ID分离协议(LISP)。如果LISP部署在Internet上(即公共不可信任环境),本文档将评估当前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.

该文件由三个主要部分组成。第一部分定义了攻击者用来发起攻击的通用威胁模型。第二部分,使用此威胁模型,描述了攻击者可能用于构造攻击的基于LISP的技术及其体系结构。第三部分讨论了保护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.

该文档不考虑在[RCFC3030]和[RCF7215]中讨论的LISP的所有可能用途,并且不包括由于特定实现而产生的威胁。本文档重点介绍LISP单播,包括LISP互通[RFC6832]、LISP映射服务器[RFC6833]和LISP映射版本控制[RFC6834]。在未来继续部署时,可能会发现其他威胁。假定读者熟悉这些文件以理解本文件。

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之间的区别。

2. Threat Model
2. 威胁模型

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.

本文档假设攻击者可以位于Internet上的任何位置(在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.

攻击目标是旨在承受攻击后果的实体(即连接到网络或网络的设备)。其他实体可能会受到攻击的副作用,即使它们不是攻击的直接目标。攻击目标可以具体选择,即特定实体,也可以任意选择,即任何实体。最后,攻击者可以通过一次攻击瞄准一个或多个目标。

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节规定了攻击者可以构建的不同类型的攻击。

2.1. Operation Modes of Attackers
2.1. 攻击者的操作模式

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.

在本文档中,攻击者根据其操作模式进行分类,即攻击者的时间和空间多样性。这些模式并不相互排斥;攻击者可以任意组合使用它们,将来可能会发现其他模式。此外,攻击者完全不受我们的分类方案的约束,因此实现者和部署者始终需要为自己进行额外的风险分析。

2.1.1. On-Path vs. Off-Path Attackers
2.1.1. 路径上与路径外攻击者

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.

如果攻击者无法访问在通信过程中交换的数据包或没有通信,则称为非路径攻击者。为了使攻击成功,非路径攻击者必须生成数据包并将其注入网络。

2.1.2. Internal vs. External Attackers
2.1.2. 内部攻击者与外部攻击者

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站点外部发起攻击。

2.1.3. Live vs. Time-Shifted Attackers
2.1.3. 实时与时移攻击者

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.

相反,时移攻击者装载的攻击在与Internet断开连接后仍处于活动状态。

2.1.4. Control-Plane vs. Data-Plane Attackers
2.1.4. 控制平面与数据平面攻击者

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).

由于控制平面和数据平面之间没有完全隔离,攻击者可以在控制平面(或数据平面)中操作,以发起针对数据平面(或控制平面)的攻击,或将被攻击平面和目标平面保持在同一层(即从控制平面到控制平面或从数据平面到数据平面)。

2.1.5. Cross-Mode Attackers
2.1.5. 跨模式攻击者

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站点(即内部+控制平面攻击者)中使用控制平面发起攻击,以在其目标上创建漏洞,然后(即时移+外部攻击者)在数据平面(即数据平面攻击者)上发起攻击这充分利用了该漏洞。

2.2. Threat Categories
2.2. 威胁类别

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.

攻击可根据以下十一个类别进行分类。这些类别不是互斥的,攻击者可以任意组合使用。

2.2.1. Replay Attack
2.2.1. 重放攻击

A replay attack happens when an attacker retransmits a packet (or a sequence of packets) without modifying it.

当攻击者在不修改数据包(或数据包序列)的情况下重新传输数据包时,就会发生重播攻击。

2.2.2. Packet Manipulation
2.2.2. 数据包操作

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.

当攻击者接收数据包、修改数据包(即,更改数据包中包含的某些信息)并最终将数据包传输到其最终目的地(可以是数据包的初始目的地,也可以是其他目的地)时,就会发生数据包操纵攻击。

2.2.3. Packet Interception and Suppression
2.2.3. 包截获和抑制

In a packet interception and suppression attack, the attacker captures the packet and drops it before it can reach its final destination.

在数据包拦截和抑制攻击中,攻击者捕获数据包并在其到达最终目的地之前将其丢弃。

2.2.4. Spoofing
2.2.4. 欺骗

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,数据包欺骗与当前部署在Internet上的任何其他现有隧道技术的欺骗相似。通常,术语“伪造数据包”表示包含不是数据包实际发起人的源IP地址的数据包。因此,由于LISP使用封装,伪造的地址可以在外部报头中,也可以在内部报头中;这转化为两种类型的欺骗。

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封装的情况下,对应于欺骗封装数据包的源端点标识符(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

请注意,这两种类型的欺骗并不相互排斥;相反,所有的组合都是可能的,可以用来执行不同类型的攻击。例如,LISP站点之外的攻击者可以生成具有伪造源IP地址(即外部地址欺骗)的数据包,并将其转发到LISP目标。然后,该数据包最终由代理入口隧道路由器(PITR)封装,因此一旦封装,攻击对应于内部地址欺骗。你也可以想象攻击者伪造了一个

packet with encapsulation where both inner and outer source addresses are spoofed.

具有封装的数据包,其中内部和外部源地址都是伪造的。

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.

需要注意的是,内部和外部欺骗的结合使得攻击者的识别变得复杂,因为数据包可能不包含允许检测攻击来源的信息。

2.2.5. Rogue Attack
2.2.5. 无赖攻击

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).

在流氓攻击中,攻击者设法显示为合法的信息源,而不伪造其身份(与欺骗攻击者相反)。

2.2.6. Denial-of-Service (DoS) Attack
2.2.6. 拒绝服务(DoS)攻击

A DoS attack aims to disrupt a specific targeted service to make it unable to operate properly.

DoS攻击旨在破坏特定的目标服务,使其无法正常运行。

2.2.7. Performance Attack
2.2.7. 性能攻击

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.

性能攻击旨在利用目标节点的计算资源(如内存、处理器)使其无法正常运行。

2.2.8. Intrusion Attack
2.2.8. 入侵攻击

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.

在入侵攻击中,攻击者可以远程访问其合法不应访问的资源(例如主机、路由器或网络)或信息。入侵攻击可能导致隐私泄露。

2.2.9. Amplification Attack
2.2.9. 放大攻击

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.

在某些情况下,数据平面在处理数据包时可以比控制平面快几个数量级。可以利用此差异通过数据平面重载控制平面,而不重载数据平面。

2.2.10. Passive Monitoring Attacks
2.2.10. 被动监视攻击

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.

攻击者可以使用普适监视,这是一种技术攻击[RFC7258],其目标是有关LISP流量的信息,这些信息可能用于或可能不用于发起其他类型的攻击。

2.2.11. Multi-category Attacks
2.2.11. 多类别攻击

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。

3. Attack Vectors
3. 攻击向量

This section presents attack techniques that may be used by attackers when leveraging LISP and/or its architecture.

本节介绍攻击者在利用LISP和/或其体系结构时可能使用的攻击技术。

3.1. Gleaning
3.1. 搜集

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封装的数据包和它接收的映射请求包中学习映射。LISP封装的数据包包含源RLOC、目标RLOC、源EID和目标EID。当xTR接收到来自源EID的封装数据包时,它还不知道该源EID的映射,它可以将源RLOC和源EID之间的映射插入其EID到RLOC缓存中。当xTR接收到映射请求时,可以使用相同的技术,因为映射请求还包含源EID地址和源RLOC。一旦收集到的条目添加到EID到RLOC缓存中,xTR将发送一个映射请求,以从映射系统检索收集到的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.

如果攻击者发送的数据包包含伪造的外部地址而不是伪造的内部地址,则它可能会实现DoS或性能攻击,因为通常发送给攻击者的流量将重定向到伪造的源RLOC。此类通信可能会使伪造源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

如果注入的数据包同时使用内部和外部欺骗,攻击者可以实现欺骗、性能攻击或放大攻击,因为通常发送到欺骗的EID地址的流量将被破坏

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.

将发送到伪造的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.

收集攻击不仅会影响数据平面,还会在创建收集条目后发送映射请求时对控制平面产生影响。然后,攻击者可以在控制平面上实现DoS和性能攻击。例如,如果攻击者向xTR的RLOC缓存发送尚未缓存在EID中的前缀的每个地址的数据包,则xTR可能会为每个此类数据包发送映射请求,直到安装映射为止,这会导致控制平面的过度利用,因为每个数据包都会生成控制平面事件。为了使此攻击成功,攻击者可能不需要使用欺骗。即使关闭了收集,也会发生此问题,因为无论是否使用收集,ITR都可能需要发送Map请求以响应EID当前不在缓存中的传入数据包。

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;它可以是任何地址。

3.2. Locator Status Bits
3.2. 定位器状态位

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头的第二个32位长字包含定位器状态位(LSB)。在该字段中,每个位位置反映映射到封装包中找到的源EID的一个RLOC的状态。在[RFC6830]中,接收此类数据包的LISP xTR的反应作为操作选择。

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.

当攻击者向xTR发送包含非法制作的LSB的LISP封装数据包时,它会影响xTR选择与源EID关联的前缀的定位器。如果是非路径攻击者,攻击者必须在网络中注入伪造的数据包,其中包含伪造的内部地址。路径上攻击者可以操纵通过它的合法数据包的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)、将所有通信量集中到一个RLOC(例如,除一个LSB设置为0外的所有通信量)并因此使RLOC过载(集中来自xTR的所有通信量)或通过强制将数据包发送到实际上不可访问的RLOC来装载DoS攻击(例如,反转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之间的路径上,则强制数据包通过该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使用从LSB收集的可达性信息来决定要使用的RLOC,攻击就可能持续。

3.3. Map-Version
3.3. 地图版本

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头的映射版本位设置为1时,表示LISP头的前32位长字的低位24位包含源和目标映射版本。当LISP xTR接收到映射版本位设置为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 它将在报头中找到的目标映射版本与在封装的数据包中找到的目标EID的自己配置的EID到RLOC映射的当前版本进行比较。如果接收到的目的地地图版本比当前版本小(即旧),出口隧道路由器(ETR)应应用[RFC6830]中描述的请求地图请求(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到RLOC缓存中存在映射,则会将该条目的映射版本与数据包头中找到的源映射版本进行比较。如果存储的映射比LISP封装数据包的源版本旧(即映射版本小),则xTR应发送源EID的映射请求。

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

跨模式攻击者可以使用Map版本位发起DoS攻击、放大攻击或欺骗攻击。例如,如果在xTR缓存的映射已过时,xTR将发送一个映射请求来检索新映射,如果攻击者发送的数据平面数据包较小,或者使用较少的资源,则可能导致DoS攻击(通过过多的信令流量)或放大攻击,而不是响应发送的控制平面数据包

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.

到攻击者的数据包。通过欺骗攻击,如果xTR认为欺骗的ITR具有过时的映射,它将向欺骗的ITR发送SMR,这也可能导致性能、放大或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.

地图版本攻击者本质上是跨模式的,因为地图版本是将控制信息放入数据平面的方法。此外,该向量还涉及活攻击者。然而,与非路径攻击者相比,路径上攻击者没有特定的优势。

3.4. Routing Locator Reachability
3.4. 路由定位可达性

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报头中包含随机Nonce。接收到这些数据包后,被测xTR存储nonce,并在将LISP封装的数据包返回给测试xTR时回显它。接收回响的nonce确认可到达被测xTR。

An attacker can interfere with the reachability test by sending two different types of packets:

攻击者可以通过发送两种不同类型的数据包来干扰可达性测试:

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. LISP使用Nonce-Present位集和随机Nonce封装数据包。这种包通常用于响应可达性测试。

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. LISP封装了Nonce Present和Echo Nonce位都已设置的数据包。这些数据包将强制接收ETR存储接收到的nonce,并在其发送的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是可访问的,而它不是。因此,这是一种发起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.

第二类数据包可被利用来攻击基于nonce的可达性测试。如果攻击者发送一个连续的数据包流,每个数据包都具有不同的随机nonce,则接收此类数据包的ETR将持续更改其返回到远程ITR的nonce,从而导致性能攻击。如果远程ITR尝试进行nonce可达性测试,此测试可能会失败,因为ETR可能会回显无效的nonce。因此,这会导致拒绝服务攻击。

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到RLOC缓存中条目的活动性(如[RFC6830]第6.3节所述),则这可能会放大导致插入被检查条目的攻击。

3.5. Instance ID
3.5. 实例ID

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位值;它在ITR上用于指示已使用哪个本地实例ID进行封装,而在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功能发起入侵攻击。

3.6. Interworking
3.6. 互通

[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]定义代理ITR和代理ETR网络元素,以允许LISP和非LISP站点通信。代理ITR具有与ITR类似的功能;然而,它的主要目的是封装来自默认自由区(DFZ)的数据包,以便到达LISP站点。代理出口隧道路由器(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互通在网络中隐藏其确切来源。

3.7. Map-Request Messages
3.7. 映射请求消息

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

控制平面偏离路径攻击者可以利用映射请求消息来装载DoS、性能或放大攻击。通过高速发送映射请求消息,攻击者可以使映射系统中涉及的节点过载。例如,以高速率发送Map请求可显著增加Map解析器中维护的状态,或消耗ETR上的CPU周期,ETR必须处理其在慢速路径中接收的Map请求数据包(即性能或DoS攻击)。当Map应答数据包大于攻击者发送的Map请求时,会产生放大

attack. The attacker can combine the attack with a spoofing attack to overload the node to which the spoofed address is actually attached.

袭击攻击者可以将攻击与欺骗攻击结合起来,使欺骗地址实际连接到的节点过载。

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.

请注意,如果攻击者在映射请求中设置P位(探测位),则映射请求将合法地直接发送到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.

出于效率原因,可以将映射记录附加到映射请求消息中。当xTR接收到带有附加映射记录的映射请求时,它执行与其他映射请求消息相同的操作,因此受到相同的攻击。但是,它还将映射请求中包含的映射记录安装在EID到RLOC缓存中。然后,攻击者可以使用此向量强制在其目标xTR中安装映射。因此,xTR的EID到RLOC缓存受到潜在伪造映射的污染,使得攻击者能够装载第2.2节中分类的任何攻击(有关详细信息,请参阅第3.8节)。请注意,攻击者无需伪造映射请求中的映射即可实现性能或DoS攻击。实际上,如果攻击者拥有足够大的EID前缀,它可以将其分解为许多小前缀,每个小前缀对应于另一个映射,并通过映射请求将它们安装到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.

此外,攻击者可以使用地图解析程序和/或地图服务器网络元素中继其攻击并隐藏攻击来源。事实上,一方面,映射解析程序用于向映射系统发送映射请求,另一方面,映射服务器用于将来自映射系统的映射请求发送到对映射请求中的EID具有权威性的ETR。

3.8. Map-Reply Messages
3.8. 映射回复消息

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.

与映射回复消息相关的大多数安全风险将取决于映射请求中包含并在映射回复中返回的64位nonce。给定nonce的大小(64位),如果使用当前最佳实践[RFC4086],并且如果ETR不接受带有无效nonce的映射回复消息,则发生非路径攻击的风险是有限的。然而,nonce仅确认接收到的Map应答是响应发送的Map请求而发送的;它不会验证该映射答复的内容。

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

如果攻击者成功地向ITR发送有效(即响应映射请求并使用正确的nonce)映射回复,那么它可以执行第2.2节中分类的任何攻击,因为它可以将伪造映射直接注入ITR EID到RLOC缓存。对于

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的映射指向由攻击者控制的节点的地址,它可以装载重播、数据包操纵、数据包截获和抑制或DoS攻击,因为它将接收每个发送到位于注入映射的EID前缀中的目的地的数据包。此外,攻击者可以在ITR中注入大量映射,通过填充ITR的EID到RLOC缓存来发起性能攻击。如果ITR当时正在向匹配注入映射的EID发送大量数据包,则攻击者还可以发起放大攻击。在这种情况下,与映射相关联的RLOC地址是攻击者实际目标的地址,因此ITR的所有通信量都将发送到目标,这意味着攻击者可能通过一个数据包向其最终目标生成非常高的通信量。

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,则如果它使用前缀overclaiming,则可以发起恶意攻击。在这种情况下,攻击者ETR使用包含EID前缀的映射回复消息回复其收到的合法映射请求消息,该前缀大于攻击者拥有的前缀。例如,如果拥有的前缀为192.0.2.0/25,但映射回复包含192.0.2.0/24的映射,则该映射将影响发送到EID的数据包,而不是攻击者有权访问的数据包。通过这种技术,攻击者可以装载上述攻击,因为它可以(部分)控制安装在其目标ITR上的映射。要强制其目标ITR发送Map请求,攻击者无法启动与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应答响应通过映射系统发送的Map请求(即,不直接从ITR发送到ETR)时,攻击者不需要使用欺骗攻击来实现其攻击,因为通过设计,ITR事先不知道Map应答的源IP地址。

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.

映射请求和映射回复消息会暴露给任何类型的攻击者,包括路径上或路径外的攻击者,以及外部或内部攻击者。此外,即使它们是控制消息,数据平面攻击者也可以利用它们。由于删除映射的决定基于映射中指示的TTL,时移攻击者也可以利用注入伪造映射。

3.9. Map-Register Messages
3.9. 映射寄存器消息

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.

映射寄存器消息由ETR发送到映射服务器,以向映射系统指示与其关联的EID前缀。Map Register消息提供EID前缀和ETR列表,这些ETR能够为EID前缀覆盖的EID提供映射回复。

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服务器。

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请求所遵循的路由(过度欺诈攻击列表见第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.

类似地,受损的映射服务器可以接受无效的注册或向映射系统公布无效的EID前缀。

3.10. Map-Notify Messages
3.10. 映射通知消息

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服务器发送至ETR,以确认Map Register消息的接收和处理。

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 Notify受nonce保护,使得攻击者难以向ETR注入伪造的通知,以使该ETR在未成功注册时相信注册成功。

4. Note on Privacy
4. 关于隐私的说明

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

与任何其他控制平面协议的公共部署类似,在Internet部署中,LISP映射是公共的,因此提供有关LISP站点的基础设施和可访问性的信息(即边缘路由器的地址)。取决于部署

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 map回复可能提供也可能不提供比当前部署的路由和控制协议更细粒度和更详细的信息。

5. Threat Mitigation
5. 减轻威胁

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]相结合,可在不可信任的环境(如Internet)中大大减轻威胁。此外,为映射请求消息和封装的控制消息分配了认证数据字段[RFC6830]。此字段为LISP控制平面提供通用身份验证机制技术,将来的规范可能会使用该技术,同时保持向后兼容。确切的技术仍然需要设计和定义。为了最大限度地缓解映射系统上的威胁,必须尽可能对映射请求和映射回复消息以及映射系统元素之间内部交换的消息使用身份验证,如[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]。

6. Security Considerations
6. 安全考虑

This document provides a threat analysis and proposes mitigation techniques for the Locator/ID Separation Protocol.

本文件提供了威胁分析,并提出了定位器/ID分离协议的缓解技术。

7. References
7. 工具书类
7.1. Normative References
7.1. 规范性引用文件

[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]Farinaci,D.,Fuller,V.,Meyer,D.,和D.Lewis,“定位器/身份分离协议(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]Lewis,D.,Meyer,D.,Farinaci,D.,和V.Fuller,“定位器/ID分离协议(LISP)和非LISP站点之间的互通”,RFC 6832,DOI 10.17487/RFC6832,2013年1月<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.Farinaci,“定位器/ID分离协议(LISP)地图服务器接口”,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,“定位器/ID分离协议(LISP)地图版本控制”,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>.

7.2. Informative References
7.2. 资料性引用

[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委托数据库树”,正在进行的工作,草案-ietf-LISP-DDT-032015年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安全(LISP-SEC)”,正在进行的工作,草案-ietf-LISP-SEC-10,2015年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.,“初步LISP威胁分析”,正在进行的工作,草稿-Bagnulo-LISP-THREAT-012007年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.,和S.Crocker,“安全的随机性要求”,BCP 106,RFC 4086,DOI 10.17487/RFC4086,2005年6月<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,“定位器/标识符分离协议(LISP)网元部署注意事项”,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,“普遍监控是一种攻击”,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未来互联网暑期学校,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三部曲项目的部分支持<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 Ianone的工作得到了ANR-13-INFR-0009 LISP实验室项目的部分支持<http://www.lisp-lab.org>以及EIT KIC ICT实验室沙发项目。

Authors' Addresses

作者地址

Damien Saucez INRIA 2004 route des Lucioles BP 93 06902 Sophia Antipolis Cedex France

Damien Saucez INRIA 2004 Lucioles路线BP 93 06902 Sophia Antipolis Cedex法国

   Email: damien.saucez@inria.fr
        
   Email: damien.saucez@inria.fr
        

Luigi Iannone Telecom ParisTech 23, Avenue d'Italie, CS 51327 75214 Paris Cedex 13 France

路易吉·伊安诺电信巴黎公司,意大利大道23号,CS 51327 75214巴黎Cedex 13法国

   Email: ggx@gigix.net
        
   Email: ggx@gigix.net
        

Olivier Bonaventure Universite catholique de Louvain Place St. Barbe 2 Louvain la Neuve Belgium

Olivier Bonaventure Universite catholique de Louvain Place St.Barbe 2 Louvain la Neuve比利时

   Email: olivier.bonaventure@uclouvain.be
        
   Email: olivier.bonaventure@uclouvain.be