Internet Engineering Task Force (IETF)                         J. Durand
Request for Comments: 7454                           Cisco Systems, Inc.
BCP: 194                                                    I. Pepelnjak
Category: Best Current Practice                                      NIL
ISSN: 2070-1721                                               G. Doering
                                                           February 2015
Internet Engineering Task Force (IETF)                         J. Durand
Request for Comments: 7454                           Cisco Systems, Inc.
BCP: 194                                                    I. Pepelnjak
Category: Best Current Practice                                      NIL
ISSN: 2070-1721                                               G. Doering
                                                           February 2015

BGP Operations and Security




The Border Gateway Protocol (BGP) is the protocol almost exclusively used in the Internet to exchange routing information between network domains. Due to this central nature, it is important to understand the security measures that can and should be deployed to prevent accidental or intentional routing disturbances.


This document describes measures to protect the BGP sessions itself such as Time to Live (TTL), the TCP Authentication Option (TCP-AO), and control-plane filtering. It also describes measures to better control the flow of routing information, using prefix filtering and automation of prefix filters, max-prefix filtering, Autonomous System (AS) path filtering, route flap dampening, and BGP community scrubbing.


Status of This Memo


This memo documents an Internet Best Current Practice.


This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.

本文件是互联网工程任务组(IETF)的产品。它代表了IETF社区的共识。它已经接受了公众审查,并已被互联网工程指导小组(IESG)批准出版。有关BCP的更多信息,请参见RFC 5741第2节。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at


Copyright Notice


Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( 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文件的法律规定的约束(自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本,并提供简化BSD许可证中所述的无担保。

Table of Contents


   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  Scope of the Document . . . . . . . . . . . . . . . . . . . .   4
   3.  Definitions and Acronyms  . . . . . . . . . . . . . . . . . .   4
   4.  Protection of the BGP Speaker . . . . . . . . . . . . . . . .   5
   5.  Protection of BGP Sessions  . . . . . . . . . . . . . . . . .   6
     5.1.  Protection of TCP Sessions Used by BGP  . . . . . . . . .   6
     5.2.  BGP TTL Security (GTSM) . . . . . . . . . . . . . . . . .   6
   6.  Prefix Filtering  . . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  Definition of Prefix Filters  . . . . . . . . . . . . . .   7
       6.1.1.  Special-Purpose Prefixes  . . . . . . . . . . . . . .   7
       6.1.2.  Unallocated Prefixes  . . . . . . . . . . . . . . . .   8
       6.1.3.  Prefixes That Are Too Specific  . . . . . . . . . . .  12
       6.1.4.  Filtering Prefixes Belonging to the Local AS and
               Downstreams . . . . . . . . . . . . . . . . . . . . .  12
       6.1.5.  IXP LAN Prefixes  . . . . . . . . . . . . . . . . . .  12
       6.1.6.  The Default Route . . . . . . . . . . . . . . . . . .  13
     6.2.  Prefix Filtering Recommendations in Full Routing Networks  14
       6.2.1.  Filters with Internet Peers . . . . . . . . . . . . .  14
       6.2.2.  Filters with Customers  . . . . . . . . . . . . . . .  16
       6.2.3.  Filters with Upstream Providers . . . . . . . . . . .  16
     6.3.  Prefix Filtering Recommendations for Leaf Networks  . . .  17
       6.3.1.  Inbound Filtering . . . . . . . . . . . . . . . . . .  17
       6.3.2.  Outbound Filtering  . . . . . . . . . . . . . . . . .  17
   7.  BGP Route Flap Dampening  . . . . . . . . . . . . . . . . . .  17
   8.  Maximum Prefixes on a Peering . . . . . . . . . . . . . . . .  18
   9.  AS Path Filtering . . . . . . . . . . . . . . . . . . . . . .  18
   10. Next-Hop Filtering  . . . . . . . . . . . . . . . . . . . . .  20
   11. BGP Community Scrubbing . . . . . . . . . . . . . . . . . . .  21
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  21
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  21
     13.2.  Informative References . . . . . . . . . . . . . . . . .  22
   Appendix A.  IXP LAN Prefix Filtering - Example . . . . . . . . .  25
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  25
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  26
   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  Scope of the Document . . . . . . . . . . . . . . . . . . . .   4
   3.  Definitions and Acronyms  . . . . . . . . . . . . . . . . . .   4
   4.  Protection of the BGP Speaker . . . . . . . . . . . . . . . .   5
   5.  Protection of BGP Sessions  . . . . . . . . . . . . . . . . .   6
     5.1.  Protection of TCP Sessions Used by BGP  . . . . . . . . .   6
     5.2.  BGP TTL Security (GTSM) . . . . . . . . . . . . . . . . .   6
   6.  Prefix Filtering  . . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  Definition of Prefix Filters  . . . . . . . . . . . . . .   7
       6.1.1.  Special-Purpose Prefixes  . . . . . . . . . . . . . .   7
       6.1.2.  Unallocated Prefixes  . . . . . . . . . . . . . . . .   8
       6.1.3.  Prefixes That Are Too Specific  . . . . . . . . . . .  12
       6.1.4.  Filtering Prefixes Belonging to the Local AS and
               Downstreams . . . . . . . . . . . . . . . . . . . . .  12
       6.1.5.  IXP LAN Prefixes  . . . . . . . . . . . . . . . . . .  12
       6.1.6.  The Default Route . . . . . . . . . . . . . . . . . .  13
     6.2.  Prefix Filtering Recommendations in Full Routing Networks  14
       6.2.1.  Filters with Internet Peers . . . . . . . . . . . . .  14
       6.2.2.  Filters with Customers  . . . . . . . . . . . . . . .  16
       6.2.3.  Filters with Upstream Providers . . . . . . . . . . .  16
     6.3.  Prefix Filtering Recommendations for Leaf Networks  . . .  17
       6.3.1.  Inbound Filtering . . . . . . . . . . . . . . . . . .  17
       6.3.2.  Outbound Filtering  . . . . . . . . . . . . . . . . .  17
   7.  BGP Route Flap Dampening  . . . . . . . . . . . . . . . . . .  17
   8.  Maximum Prefixes on a Peering . . . . . . . . . . . . . . . .  18
   9.  AS Path Filtering . . . . . . . . . . . . . . . . . . . . . .  18
   10. Next-Hop Filtering  . . . . . . . . . . . . . . . . . . . . .  20
   11. BGP Community Scrubbing . . . . . . . . . . . . . . . . . . .  21
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  21
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  21
     13.2.  Informative References . . . . . . . . . . . . . . . . .  22
   Appendix A.  IXP LAN Prefix Filtering - Example . . . . . . . . .  25
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  25
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  26
1. Introduction
1. 介绍

The Border Gateway Protocol (BGP), specified in RFC 4271 [2], is the protocol used in the Internet to exchange routing information between network domains. BGP does not directly include mechanisms that control whether the routes exchanged conform to the various guidelines defined by the Internet community. This document intends to both summarize common existing guidelines and help network administrators apply coherent BGP policies.

RFC 4271[2]中规定的边界网关协议(BGP)是互联网中用于在网络域之间交换路由信息的协议。BGP不直接包括控制交换的路由是否符合互联网社区定义的各种准则的机制。本文档旨在总结现有的通用指南,并帮助网络管理员应用一致的BGP策略。

1.1. Requirements Language
1.1. 需求语言

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].

本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。

2. Scope of the Document
2. 文件的范围

The guidelines defined in this document are intended for generic Internet BGP peerings. The nature of the Internet is such that Autonomous Systems can always agree on exceptions to a common framework for relevant local needs, and therefore configure a BGP session in a manner that may differ from the recommendations provided in this document. While this is perfectly acceptable, every configured exception might have an impact on the entire inter-domain routing environment, and network administrators SHOULD carefully appraise this impact before implementation.


3. Definitions and Acronyms
3. 定义和首字母缩略词

o ACL: Access Control List

o 访问控制列表

o ASN: Autonomous System Number

o ASN:自治系统编号

o IRR: Internet Routing Registry

o 互联网路由注册

o IXP: Internet Exchange Point

o 互联网交换点

o LIR: Local Internet Registry

o 本地互联网注册

o PMTUD: Path MTU Discovery


o RIR: Regional Internet Registry

o RIR:区域互联网注册处

o Tier 1 transit provider: an IP transit provider that can reach any network on the Internet without purchasing transit services.

o Tier 1 transit provider:一家IP transit provider,无需购买transit服务即可访问Internet上的任何网络。

o uRPF: Unicast Reverse Path Forwarding

o uRPF:单播反向路径转发

In addition to the list above, the following terms are used with a specific meaning.


o Downstream: any network that is downstream; it can be a provider or a customer network.

o 下游:下游的任何网络;它可以是提供商或客户网络。

o Upstream: any network that is upstream.

o 上游:上游的任何网络。

4. Protection of the BGP Speaker
4. BGP扬声器的保护

The BGP speaker needs to be protected from attempts to subvert the BGP session. This protection SHOULD be achieved by an Access Control List (ACL) that would discard all packets directed to TCP port 179 on the local device and sourced from an address not known or permitted to become a BGP neighbor. Experience has shown that the natural protection TCP should offer is not always sufficient, as it is sometimes run in control-plane software. In the absence of ACLs, it is possible to attack a BGP speaker by simply sending a high volume of connection requests to it.


If supported, an ACL specific to the control plane of the router SHOULD be used (receive-ACL, control-plane policing, etc.), to avoid configuration of data-plane filters for packets transiting through the router (and therefore not reaching the control plane). If the hardware cannot do that, interface ACLs can be used to block packets addressed to the local router.


Some routers automatically program such an ACL upon BGP configuration. On other devices, this ACL should be configured and maintained manually or using scripts.


In addition to strict filtering, rate-limiting MAY be configured for accepted BGP traffic. Rate-limiting BGP traffic consists in permitting only a certain quantity of bits per second (or packets per second) of BGP traffic to the control plane. This protects the BGP router control plane in case the amount of BGP traffic surpasses platform capabilities.


Filtering and rate-limiting of control-plane traffic is a wider topic than "just for BGP". (If a network administrator brings down a router by overloading one of the other protocols remotely, BGP is harmed as well.) For a more detailed recommendation on how to protect the router's control plane, see RFC 6192 [11].

控制平面流量的过滤和速率限制是比“仅针对BGP”更广泛的主题。(如果网络管理员通过远程过载其他协议之一使路由器停机,BGP也会受到损害。)有关如何保护路由器控制平面的更详细建议,请参阅RFC 6192[11]。

5. Protection of BGP Sessions
5. 保护BGP会话

Current security issues of TCP-based protocols (therefore including BGP) have been documented in RFC 6952 [14]. The following subsections list the major points raised in this RFC and give the best practices related to TCP session protection for BGP operation.

基于TCP的协议(因此包括BGP)的当前安全问题已记录在RFC 6952[14]中。以下小节列出了本RFC中提出的要点,并给出了与BGP操作的TCP会话保护相关的最佳实践。

5.1. Protection of TCP Sessions Used by BGP
5.1. 保护BGP使用的TCP会话

Attacks on TCP sessions used by BGP (aka BGP sessions), for example, sending spoofed TCP RST packets, could bring down a BGP peering. Following a successful ARP spoofing attack (or other similar man-in-the-middle attack), the attacker might even be able to inject packets into the TCP stream (routing attacks).

对BGP使用的TCP会话(也称为BGP会话)的攻击,例如,发送伪造的TCP RST数据包,可能导致BGP对等中断。在成功的ARP欺骗攻击(或其他类似的中间人攻击)之后,攻击者甚至可以将数据包注入TCP流(路由攻击)。

BGP sessions can be secured with a variety of mechanisms. MD5 protection of the TCP session header, described in RFC 2385 [7], was the first such mechanism. It has been obsoleted by the TCP Authentication Option (TCP-AO; RFC 5925 [4]), which offers stronger protection. While MD5 is still the most used mechanism due to its availability in vendors' equipment, TCP-AO SHOULD be preferred when implemented.

BGP会话可以通过多种机制进行保护。RFC 2385[7]中描述的TCP会话头的MD5保护是第一个这样的机制。TCP身份验证选项(TCP-AO;RFC 5925[4])已将其淘汰,该选项提供了更强的保护。虽然MD5仍然是最常用的机制,因为它在供应商的设备中可用,但在实现时,TCP-AO应该是首选。

IPsec could also be used for session protection. At the time of publication, there is not enough experience of the impact of using IPsec for BGP peerings, and further analysis is required to define guidelines.


The drawback of TCP session protection is additional configuration and management overhead for the maintenance of authentication information (for example, MD5 passwords). Protection of TCP sessions used by BGP is thus NOT REQUIRED even when peerings are established over shared networks where spoofing can be done (like IXPs), but operators are RECOMMENDED to consider the trade-offs and to apply TCP session protection where appropriate.


Furthermore, network administrators SHOULD block spoofed packets (packets with a source IP address belonging to their IP address space) at all edges of their network (see RFC 2827 [8] and RFC 3704 [9]). This protects the TCP session used by Internal BGP (IBGP) from attackers outside the Autonomous System.

此外,网络管理员应在其网络的所有边缘阻止伪造数据包(源IP地址属于其IP地址空间的数据包)(参见RFC 2827[8]和RFC 3704[9])。这可以保护内部BGP(IBGP)使用的TCP会话免受自治系统之外的攻击者的攻击。

5.2. BGP TTL Security (GTSM)
5.2. BGP TTL安全(GTSM)

BGP sessions can be made harder to spoof with the Generalized TTL Security Mechanisms (GTSM aka TTL security), defined in RFC 5082 [3]. Instead of sending TCP packets with TTL value of 1, the BGP speakers send the TCP packets with TTL value of 255, and the receiver checks

使用RFC 5082[3]中定义的通用TTL安全机制(GTSM又名TTL安全机制),BGP会话更难欺骗。BGP扬声器不发送TTL值为1的TCP数据包,而是发送TTL值为255的TCP数据包,接收器进行检查

that the TTL value equals 255. Since it's impossible to send an IP packet with TTL of 255 to an IP host that is not directly connected, BGP TTL security effectively prevents all spoofing attacks coming from third parties not directly connected to the same subnet as the BGP-speaking routers. Network administrators SHOULD implement TTL security on directly connected BGP peerings.

TTL值等于255。由于无法将TTL为255的IP数据包发送到未直接连接的IP主机,BGP TTL安全性可有效防止来自与BGP路由器未直接连接到同一子网的第三方的所有欺骗攻击。网络管理员应在直接连接的BGP对等上实施TTL安全。

GTSM could also be applied to multi-hop BGP peering as well. To achieve this, TTL needs to be configured with a proper value depending on the distance between BGP speakers (using the principle described above). Nevertheless, it is not as effective because anyone inside the TTL diameter could spoof the TTL.


Like MD5 protection, TTL security has to be configured on both ends of a BGP session.


6. Prefix Filtering
6. 前缀过滤

The main aspect of securing BGP resides in controlling the prefixes that are received and advertised on the BGP peerings. Prefixes exchanged between BGP peers are controlled with inbound and outbound filters that can match on IP prefixes (as described in this section), AS paths (as described in Section 9) or any other attributes of a BGP prefix (for example, BGP communities, as described in Section 11).


6.1. Definition of Prefix Filters
6.1. 前缀过滤器的定义

This section lists the most commonly used prefix filters. The following sections will clarify where these filters should be applied.


6.1.1. Special-Purpose Prefixes
6.1.1. 专用前缀 IPv4 Special-Purpose Prefixes IPv4专用前缀

The IANA IPv4 Special-Purpose Address Registry [23] maintains the list of IPv4 special-purpose prefixes and their routing scope, and it SHOULD be used for prefix-filter configuration. Prefixes with value "False" in column "Global" SHOULD be discarded on Internet BGP peerings.

IANA IPv4专用地址注册表[23]维护IPv4专用前缀及其路由范围的列表,该列表应用于前缀筛选器配置。应在Internet BGP对等上丢弃列“全局”中值为“False”的前缀。 IPv6 Special-Purpose Prefixes IPv6专用前缀

The IANA IPv6 Special-Purpose Address Registry [24] maintains the list of IPv6 special-purpose prefixes and their routing scope, and it SHOULD be used for prefix-filter configuration. Only prefixes with value "False" in column "Global" SHOULD be discarded on Internet BGP peerings.

IANA IPv6专用地址注册表[24]维护IPv6专用前缀及其路由范围的列表,该列表应用于前缀筛选器配置。在Internet BGP对等上,只应丢弃“全局”列中值为“False”的前缀。

6.1.2. Unallocated Prefixes
6.1.2. 未分配前缀

IANA allocates prefixes to RIRs that in turn allocate prefixes to LIRs (Local Internet Registries). It is wise not to accept routing table prefixes that are not allocated by IANA and/or RIRs. This section details the options for building a list of allocated prefixes at every level. It is important to understand that filtering unallocated prefixes requires constant updates, as prefixes are continually allocated. Therefore, automation of such prefix filters is key for the success of this approach. Network administrators SHOULD NOT consider solutions described in this section if they are not capable of maintaining updated prefix filters: the damage would probably be worse than the intended security policy.

IANA将前缀分配给RIR,而RIR又将前缀分配给LIR(本地互联网注册中心)。明智的做法是不接受IANA和/或RIR未分配的路由表前缀。本节详细介绍了在每个级别构建已分配前缀列表的选项。重要的是要理解,过滤未分配的前缀需要不断更新,因为前缀是不断分配的。因此,这种前缀过滤器的自动化是这种方法成功的关键。如果网络管理员不能维护更新的前缀过滤器,则不应考虑本节中描述的解决方案:损坏可能比预期的安全策略更差。 IANA-Allocated Prefix Filters IANA分配前缀筛选器

IANA has allocated all the IPv4 available space. Therefore, there is no reason why network administrators would keep checking that prefixes they receive from BGP peers are in the IANA-allocated IPv4 address space [25]. No specific filters need to be put in place by administrators who want to make sure that IPv4 prefixes they receive in BGP updates have been allocated by IANA.


For IPv6, given the size of the address space, it can be seen as wise to accept only prefixes derived from those allocated by IANA. Administrators can dynamically build this list from the IANA-allocated IPv6 space [26]. As IANA keeps allocating prefixes to RIRs, the aforementioned list should be checked regularly against changes, and if they occur, prefix filters should be computed and pushed on network devices. The list could also be pulled directly by routers when they implement such mechanisms. As there is delay between the time a RIR receives a new prefix and the moment it starts allocating portions of it to its LIRs, there is no need for doing this step quickly and frequently. However, network administrators SHOULD ensure that all IPv6 prefix filters are updated within a maximum of one month after any change in the list of IPv6 prefixes allocated by IANA.


If the process in place (whether manual or automatic) cannot guarantee that the list is updated regularly, then it's better not to configure any filters based on allocated networks. The IPv4 experience has shown that many network operators implemented filters for prefixes not allocated by IANA but did not update them on a regular basis. This created problems for the latest allocations, and required extra work for RIRs that had to "de-bogonize" the newly allocated prefixes. (See [18] for information on de-bogonizing.)

如果现有流程(手动或自动)不能保证定期更新列表,那么最好不要根据分配的网络配置任何过滤器。IPv4的经验表明,许多网络运营商对IANA未分配的前缀实施了过滤器,但没有定期更新前缀。这给最新的分配带来了问题,并且需要为RIR做额外的工作,RIR必须“去bogonize”新分配的前缀。(有关脱硼的信息,请参见[18]) RIR-Allocated Prefix Filters RIR分配前缀过滤器

A more precise check can be performed when one would like to make sure that prefixes they receive are being originated or transited by Autonomous Systems (ASes) entitled to do so. It has been observed in the past that an AS could easily advertise someone else's prefix (or more specific prefixes) and create black holes or security threats. To partially mitigate this risk, administrators would need to make sure BGP advertisements correspond to information located in the existing registries. At this stage, two options can be considered: short- and long-term options. They are described in the following subsections.

当人们希望确保他们收到的前缀是由有权这样做的自治系统(ASE)发起或传输时,可以执行更精确的检查。过去有人观察到AS很容易宣传其他人的前缀(或更具体的前缀),并造成黑洞或安全威胁。为了部分缓解这一风险,管理员需要确保BGP广告与现有注册中心中的信息相对应。在这个阶段,可以考虑两种选择:短期选择和长期选择。以下各小节对其进行了描述。 Prefix Filters Created from Internet Routing Registries (IRRs) 从Internet路由注册表(IRR)创建的前缀筛选器

An Internet Routing Registry (IRR) is a database containing Internet routing information, described using Routing Policy Specification Language objects as described in RFC 4012 [10]. Network administrators are given privileges to describe routing policies of their own networks in the IRR, and that information is published, usually publicly. A majority of Regional Internet Registries do also operate an IRR and can control whether registered routes conform to the prefixes that are allocated or directly assigned. However, it should be noted that the list of such prefixes is not necessarily a complete list, and as such the list of routes in an IRR is not the same as the set of RIR-allocated prefixes.

Internet路由注册表(IRR)是包含Internet路由信息的数据库,使用RFC 4012[10]中描述的路由策略规范语言对象进行描述。网络管理员有权在IRR中描述他们自己网络的路由策略,这些信息通常是公开发布的。大多数区域互联网注册中心也运行IRR,可以控制注册的路由是否符合分配或直接分配的前缀。然而,应当注意的是,这些前缀的列表不一定是完整的列表,因此,IRR中的路由列表与分配给RIR的前缀集不同。

It is possible to use the IRR information to build, for a given neighbor AS, a list of originated or transited prefixes that one may accept. This can be done relatively easily using scripts and existing tools capable of retrieving this information from the registries. This approach is exactly the same for both IPv4 and IPv6.


The macro-algorithm for the script is as follows. For the peer that is considered, the distant network administrator has provided the AS and may be able to provide an AS-SET object (aka AS-MACRO). An AS-SET is an object that contains AS numbers or other AS-SETs. An operator may create an AS-SET defining all the AS numbers of its customers. A Tier 1 transit provider might create an AS-SET describing the AS-SET of connected operators, which in turn describe the AS numbers of their customers. Using recursion, it is possible to retrieve from an AS-SET the complete list of AS numbers that the peer is likely to announce. For each of these AS numbers, it is also easy to look in the corresponding IRR for all associated prefixes. With these two mechanisms, a script can build, for a given peer, the


list of allowed prefixes and the AS number from which they should be originated. One could decide not use the origin information and only build monolithic prefix filters from fetched data.


As prefixes, AS numbers, and AS-SETs may not all be under the same RIR authority, it is difficult to choose for each object the appropriate IRR to poll. Some IRRs have been created and are not restricted to a given region or authoritative RIR. They allow RIRs to publish information contained in their IRR in a common place. They also make it possible for any subscriber (probably under contract) to publish information too. When doing requests inside such an IRR, it is possible to specify the source of information in order to have the most reliable data. One could check a popular IRR containing many sources (such as RADb [27], the Routing Assets Database) and only select as sources some desired RIRs and trusted major ISPs (Internet Service Providers).


As objects in IRRs may frequently vary over time, it is important that prefix filters computed using this mechanism are refreshed regularly. Refreshing the filters on a daily basis SHOULD be considered because routing changes must sometimes be done in an emergency and registries may be updated at the very last moment. Note that this approach significantly increases the complexity of the router configurations, as it can quickly add tens of thousands of configuration lines for some important peers. To manage this complexity, network administrators could use, for example, IRRToolSet [30], a set of tools making it possible to simplify the creation of automated filter configuration from policies stored in an IRR.


Last but not least, network administrators SHOULD publish and maintain their resources properly in the IRR database maintained by their RIR, when available.

最后但并非最不重要的一点是,网络管理员应在其RIR维护的IRR数据库中适当发布和维护其资源(如果可用)。 SIDR - Secure Inter-Domain Routing 安全域间路由

An infrastructure called SIDR (Secure Inter-Domain Routing), described in RFC 6480 [12], has been designed to secure Internet advertisements. At the time of writing this document, many documents have been published and a framework with a complete set of protocols is proposed so that advertisements can be checked against signed routing objects in RIRs. There are basically two services that SIDR offers:

RFC 6480[12]中描述的一种称为SIDR(安全域间路由)的基础设施被设计用于保护互联网广告。在编写本文档时,已经发布了许多文档,并提出了一个包含完整协议集的框架,以便可以根据RIR中的签名路由对象检查广告。SIDR基本上提供两种服务:

o Origin validation, described in RFC 6811 [5], seeks to make sure that attributes associated with routes are correct. (The major point is the validation of the AS number originating a given route.) Origin validation is now operational (Internet

o RFC 6811[5]中描述的原产地验证旨在确保与路线相关的属性是正确的。(主要的一点是验证源自给定路线的AS编号。)原点验证现在可以运行(互联网)

registries, protocols, implementations on some routers), and in theory it can be implemented knowing that the number of signed resources is still low at the time of writing this document.


o Path validation provided by BGPsec [29] seeks to make sure that no one announces fake/wrong BGP paths that would attract traffic for a given destination; see RFC 7132 [16]. BGPsec is still an ongoing work item at the time of writing this document and therefore cannot be implemented.

o BGPsec[29]提供的路径验证旨在确保没有人宣布会吸引给定目的地流量的伪造/错误BGP路径;参见RFC 7132[16]。在编写本文件时,BGPsec仍然是一个正在进行的工作项目,因此无法实施。

Implementing SIDR mechanisms is expected to solve many of the BGP routing security problems in the long term, but it may take time for deployments to be made and objects to become signed. Also, note that the SIDR infrastructure is complementing (not replacing) the security best practices listed in this document. Therefore, network administrators SHOULD implement any SIDR proposed mechanism (for example, route origin validation) on top of the other existing mechanisms even if they could sometimes appear to be targeting the same goal.


If route origin validation is implemented, the reader SHOULD refer to the rules described in RFC 7115 [15]. In short, each external route received on a router SHOULD be checked against the Resource Public Key Infrastructure (RPKI) data set:

如果实施了路线起点验证,读者应参考RFC 7115[15]中描述的规则。简言之,应根据资源公钥基础设施(RPKI)数据集检查路由器上接收的每个外部路由:

o If a corresponding ROA (Route Origin Authorization) is found and is valid, then the prefix SHOULD be accepted.

o 如果找到相应的ROA(路由来源授权)且该ROA有效,则应接受前缀。

o If the ROA is found and is INVALID, then the prefix SHOULD be discarded.

o 如果找到ROA且该ROA无效,则应丢弃前缀。

o If a ROA is not found, then the prefix SHOULD be accepted, but the corresponding route SHOULD be given a low preference.

o 如果未找到ROA,则应接受前缀,但应给予相应路由较低的优先权。

In addition to this, network administrators SHOULD sign their routing objects so their routes can be validated by other networks running origin validation.


One should understand that the RPKI model brings new, interesting challenges. The paper "On the Risk of Misbehaving RPKI Authorities" [31] explains how the RPKI model can impact the Internet if authorities don't behave as they are supposed to. Further analysis is certainly required on RPKI, which carries part of BGP security.


6.1.3. Prefixes That Are Too Specific
6.1.3. 过于具体的前缀

Most ISPs will not accept advertisements beyond a certain level of specificity (and in return, they do not announce prefixes they consider to be too specific). That acceptable specificity is decided for each peering between the two BGP peers. Some ISP communities have tried to document acceptable specificity. This document does not make any judgement on what the best approach is, it just notes that there are existing practices on the Internet and recommends that the reader refer to them. As an example, the RIPE community has documented that, at the time of writing of this document, IPv4 prefixes longer than /24 and IPv6 prefixes longer than /48 are generally neither announced nor accepted in the Internet [20] [21]. These values may change in the future.


6.1.4. Filtering Prefixes Belonging to the Local AS and Downstreams
6.1.4. 过滤属于本地AS和下游的前缀

A network SHOULD filter its own prefixes on peerings with all its peers (inbound direction). This prevents local traffic (from a local source to a local destination) from leaking over an external peering, in case someone else is announcing the prefix over the Internet. This also protects the infrastructure that may directly suffer if the backbone's prefix is suddenly preferred over the Internet.


In some cases, for example, multihoming scenarios, such filters SHOULD NOT be applied, as this would break the desired redundancy.


To an extent, such filters can also be configured on a network for the prefixes of its downstreams in order to protect them, too. Such filters must be defined with caution as they can break existing redundancy mechanisms. For example, when an operator has a multihomed customer, it should keep accepting the customer prefix from its peers and upstreams. This will make it possible for the customer to keep accessing its operator network (and other customers) via the Internet even if the BGP peering between the customer and the operator is down.


6.1.5. IXP LAN Prefixes
6.1.5. IXP局域网前缀 Network Security 网络安全

When a network is present on an IXP and peers with other IXP members over a common subnet (IXP LAN prefix), it SHOULD NOT accept more-specific prefixes for the IXP LAN prefix from any of its external BGP peers. Accepting these routes may create a black hole for connectivity to the IXP LAN.

当网络存在于IXP上并且通过公共子网(IXP LAN前缀)与其他IXP成员对等时,它不应接受来自任何外部BGP对等的IXP LAN前缀的更具体前缀。接受这些路由可能会为IXP LAN的连接创建一个黑洞。

If the IXP LAN prefix is accepted as an "exact match", care needs to be taken to prevent other routers in the network from sending IXP traffic towards the externally learned IXP LAN prefix (recursive route lookup pointing into the wrong direction). This can be achieved by preferring IGP routes over External BGP (EBGP), or by using "BGP next-hop-self" on all routes learned on that IXP.

如果IXP LAN前缀被接受为“精确匹配”,则需要注意防止网络中的其他路由器向外部学习的IXP LAN前缀发送IXP流量(指向错误方向的递归路由查找)。这可以通过优先选择IGP路由而不是外部BGP(EBGP)来实现,或者通过在该IXP上学习的所有路由上使用“BGP下一跳自”来实现。

If the IXP LAN prefix is accepted at all, it SHOULD only be accepted from the ASes that the IXP authorizes to announce it -- this will usually be automatically achieved by filtering announcements using the IRR database.

如果IXP LAN前缀完全被接受,那么它应该只从IXP授权发布它的ASE接受——这通常会通过使用IRR数据库过滤发布来自动实现。 PMTUD and the Loose uRPF Problem PMTUD与松散uRPF问题

In order to have PMTUD working in the presence of loose uRPF, it is necessary that all the networks that may source traffic that could flow through the IXP (i.e., IXP members and their downstreams) have a route for the IXP LAN prefix. This is necessary as "packet too big" ICMP messages sent by IXP members' routers may be sourced using an address of the IXP LAN prefix. In the presence of loose uRPF, this ICMP packet is dropped if there is no route for the IXP LAN prefix or a less specific route covering IXP LAN prefix.

为了使PMTUD在松散的uRPF存在的情况下工作,所有可能产生可能流经IXP的流量的网络(即IXP成员及其下游)都必须具有IXP LAN前缀的路由。这是必要的,因为IXP成员路由器发送的“数据包太大”ICMP消息可能使用IXP LAN前缀的地址来源。在存在松散uRPF的情况下,如果没有用于IXP LAN前缀的路由或覆盖IXP LAN前缀的不太具体的路由,则丢弃此ICMP数据包。

In that case, any IXP member SHOULD make sure it has a route for the IXP LAN prefix or a less specific prefix on all its routers and that it announces the IXP LAN prefix or the less specific route (up to a default route) to its downstreams. The announcements done for this purpose SHOULD pass IRR-generated filters described in Section as well as "prefixes that are too specific" filters described in Section 6.1.3. The easiest way to implement this is for the IXP itself to take care of the origination of its prefix and advertise it to all IXP members through a BGP peering. Most likely, the BGP route servers would be used for this, and the IXP would send its entire prefix, which would be equal to or less specific than the IXP LAN prefix.

在这种情况下,任何IXP成员应确保其所有路由器上都有IXP LAN前缀或不太特定的前缀的路由,并向其下游宣布IXP LAN前缀或不太特定的路由(最多为默认路由)。为此目的所做的公告应通过第6.节所述IRR生成的过滤器以及第6.1.3节所述的“过于具体的前缀”过滤器。实现这一点的最简单方法是IXP本身负责其前缀的起源,并通过BGP对等将其通告给所有IXP成员。最有可能的情况是,BGP路由服务器将用于此目的,而IXP将发送其整个前缀,该前缀将等于或低于IXP LAN前缀。

Appendix A gives an example of guidelines regarding IXP LAN prefix.

附录A给出了有关IXP LAN前缀的指南示例。

6.1.6. The Default Route
6.1.6. 默认路线 IPv4 IPv4

Typically, the prefix is not intended to be accepted or advertised except in specific customer/provider configurations; general filtering outside of these is RECOMMENDED.

通常,前缀不打算被接受或公布,除非在特定的客户/提供商配置中;建议在这些范围之外进行常规过滤。 IPv6 IPv6

Typically, the ::/0 prefix is not intended to be accepted or advertised except in specific customer/provider configurations; general filtering outside of these is RECOMMENDED.


6.2. Prefix Filtering Recommendations in Full Routing Networks
6.2. 全路由网络中的前缀过滤建议

For networks that have the full Internet BGP table, some policies should be applied on each BGP peer for received and advertised routes. It is RECOMMENDED that each Autonomous System configures rules for advertised and received routes at all its borders, as this will protect the network and its peer even in case of misconfiguration. The most commonly used filtering policy is proposed in this section and uses prefix filters defined in Section 6.1.

对于具有完整的Internet BGP表的网络,对于接收和公布的路由,应在每个BGP对等方上应用一些策略。建议每个自治系统在其所有边界处为广告和接收的路由配置规则,因为这样即使在配置错误的情况下也能保护网络及其对等方。本节提出了最常用的过滤策略,并使用第6.1节中定义的前缀过滤器。

6.2.1. Filters with Internet Peers
6.2.1. 使用Internet对等点进行筛选 Inbound Filtering 入站筛选

There are basically two options -- the loose one where no check will be done against RIR allocations and the strict one where it will be verified that announcements strictly conform to what is declared in routing registries.

基本上有两种选择——松散的一种是不对RIR分配进行检查,严格的一种是验证公告是否严格符合路由注册中声明的内容。 Inbound Filtering Loose Option 入站过滤松散选项

In this case, the following prefixes received from a BGP peer will be filtered:


o prefixes that are not globally routable (Section 6.1.1)

o 不可全局路由的前缀(第6.1.1节)

o prefixes not allocated by IANA (IPv6 only) (Section

o IANA未分配的前缀(仅限IPv6)(第6.1.2.1节)

o routes that are too specific (Section 6.1.3)

o 过于具体的路线(第6.1.3节)

o prefixes belonging to the local AS (Section 6.1.4)

o 属于本地AS的前缀(第6.1.4节)

o IXP LAN prefixes (Section 6.1.5)

o IXP LAN前缀(第6.1.5节)

o the default route (Section 6.1.6)

o 默认路线(第6.1.6节) Inbound Filtering Strict Option 入站筛选严格选项

In this case, filters are applied to make sure advertisements strictly conform to what is declared in routing registries (Section Warning is given as registries are not always


accurate (prefixes missing, wrong information, etc.). This varies across the registries and regions of the Internet. Before applying a strict policy, the reader SHOULD check the impact on the filter and make sure the solution is not worse than the problem.


Also, in case of script failure, each administrator may decide if all routes are accepted or rejected depending on routing policy. While accepting the routes during that time frame could break the BGP routing security, rejecting them might re-route too much traffic on transit peers, and could cause more harm than what a loose policy would have done.


In addition to this, network administrators could apply the following filters beforehand in case the routing registry that's used as the source of information by the script is not fully trusted:


o prefixes that are not globally routable (Section 6.1.1)

o 不可全局路由的前缀(第6.1.1节)

o routes that are too specific (Section 6.1.3)

o 过于具体的路线(第6.1.3节)

o prefixes belonging to the local AS (Section 6.1.4)

o 属于本地AS的前缀(第6.1.4节)

o IXP LAN prefixes (Section 6.1.5)

o IXP LAN前缀(第6.1.5节)

o the default route (Section 6.1.6)

o 默认路线(第6.1.6节) Outbound Filtering 出站筛选

The configuration should ensure that only appropriate prefixes are sent. These can be, for example, prefixes belonging to both the network in question and its downstreams. This can be achieved by using BGP communities, AS paths, or both. Also, it may be desirable to add the following filters before any policy to avoid unwanted route announcements due to bad configuration:


o Prefixes that are not globally routable (Section 6.1.1)

o 不可全局路由的前缀(第6.1.1节)

o Routes that are too specific (Section 6.1.3)

o 过于具体的路线(第6.1.3节)

o IXP LAN prefixes (Section 6.1.5)

o IXP LAN前缀(第6.1.5节)

o The default route (Section 6.1.6)

o 默认路线(第6.1.6节)

If it is possible to list the prefixes to be advertised, then just configuring the list of allowed prefixes and denying the rest is sufficient.


6.2.2. Filters with Customers
6.2.2. 与客户沟通 Inbound Filtering 入站筛选

The inbound policy with end customers is pretty straightforward: only customer prefixes SHOULD be accepted, all others SHOULD be discarded. The list of accepted prefixes can be manually specified, after having verified that they are valid. This validation can be done with the appropriate IP address management authorities.


The same rules apply when the customer is a network connecting other customers (for example, a Tier 1 transit provider connecting service providers). An exception is when the customer network applies strict inbound/outbound prefix filtering, and there are too many prefixes announced by that network to list them in the router configuration. In that case, filters as in Section can be applied.

当客户是连接其他客户的网络时(例如,连接服务提供商的一级运输提供商),同样的规则也适用。例外情况是,当客户网络应用严格的入站/出站前缀过滤,并且该网络宣布的前缀太多,无法在路由器配置中列出它们时。在这种情况下,可使用第6.2.1.1节中的过滤器。 Outbound Filtering 出站筛选

The outbound policy with customers may vary according to the routes the customer wants to receive. In the simplest possible scenario, the customer may want to receive only the default route; this can be done easily by applying a filter with the default route only.


In case the customer wants to receive the full routing (if it is multihomed or if it wants to have a view of the Internet table), the following filters can be applied on the BGP peering:


o prefixes that are not globally routable (Section 6.1.1)

o 不可全局路由的前缀(第6.1.1节)

o routes that are too specific (Section 6.1.3)

o 过于具体的路线(第6.1.3节)

o the default route (Section 6.1.6)

o 默认路线(第6.1.6节)

In some cases, the customer may desire to receive the default route in addition to the full BGP table. This can be done by the provider simply by removing the filter for the default route. As the default route may not be present in the routing table, network administrators may decide to originate it only for peerings where it has to be advertised.


6.2.3. Filters with Upstream Providers
6.2.3. 与上游提供商的筛选器 Inbound Filtering 入站筛选

If the full routing table is desired from the upstream, the prefix filtering to apply is the same as the one for peers Section with the exception of the default route. Sometimes, the default


route (in addition to the full BGP table) can be desired from an upstream provider. If the upstream provider is supposed to announce only the default route, a simple filter will be applied to accept only the default prefix and nothing else.

可以从上游提供商处获得路由(除了完整的BGP表)。如果上游提供者应该只宣布默认路由,那么将应用一个简单的过滤器,只接受默认前缀,而不接受其他内容。 Outbound Filtering 出站筛选

The filters to be applied would most likely not differ much from the ones applied for Internet peers (Section However, different policies could be applied if a particular upstream should not provide transit to all the prefixes.


6.3. Prefix Filtering Recommendations for Leaf Networks
6.3. 叶网络的前缀过滤建议
6.3.1. Inbound Filtering
6.3.1. 入站筛选

The leaf network will deploy the filters corresponding to the routes it is requesting from its upstream. If a default route is requested, a simple inbound filter can be applied to accept only the default route (Section 6.1.6). If the leaf network is not capable of listing the prefixes because there are too many (for example, if it requires the full Internet routing table), then it should configure the following filters to avoid receiving bad announcements from its upstream:


o prefixes not routable (Section 6.1.1)

o 前缀不可路由(第6.1.1节)

o routes that are too specific (Section 6.1.3)

o 过于具体的路线(第6.1.3节)

o prefixes belonging to local AS (Section 6.1.4)

o 属于本地AS的前缀(第6.1.4节)

o the default route (Section 6.1.6) depending on whether or not the route is requested

o 默认路由(第6.1.6节)取决于是否请求路由

6.3.2. Outbound Filtering
6.3.2. 出站筛选

A leaf network will most likely have a very straightforward policy: it will only announce its local routes. It can also configure the prefix filters described in Section to avoid announcing invalid routes to its upstream provider.


7. BGP Route Flap Dampening
7. 路由襟翼阻尼

The BGP route flap dampening mechanism makes it possible to give penalties to routes each time they change in the BGP routing table. Initially, this mechanism was created to protect the entire Internet from multiple events that impact a single network. Studies have shown that implementations of BGP route flap dampening could cause


more harm than benefit; therefore, in the past, the RIPE community has recommended against using BGP route flap dampening [19]. Later, studies were conducted to propose new route flap dampening thresholds in order to make the solution "usable"; see RFC 7196 [6] and [22] (in which RIPE reviewed its recommendations). This document RECOMMENDS following IETF and RIPE recommendations and using BGP route flap dampening with the adjusted configured thresholds.

弊大于利;因此,在过去,成熟社区建议不要使用BGP路由襟翼阻尼[19]。后来,进行了研究,提出了新的路线襟翼阻尼阈值,以使解决方案“可用”;参见RFC 7196[6]和[22](其中RIME审查了其建议)。本文件建议遵循IETF和CREAME建议,并使用BGP路由襟翼阻尼和调整后的配置阈值。

8. Maximum Prefixes on a Peering
8. 对等网络上的最大前缀数

It is RECOMMENDED to configure a limit on the number of routes to be accepted from a peer. The following rules are generally RECOMMENDED:


o From peers, it is RECOMMENDED to have a limit lower than the number of routes in the Internet. This will shut down the BGP peering if the peer suddenly advertises the full table. Network administrators can also configure different limits for each peer, according to the number of routes they are supposed to advertise, plus some headroom to permit growth.

o 对于同行,建议其限制低于Internet中的路由数。如果BGP对等方突然播发整个表,则会关闭BGP对等方。网络管理员还可以根据他们应该公布的路由数量以及允许增长的净空,为每个对等点配置不同的限制。

o From upstreams that provide full routing, it is RECOMMENDED to have a limit higher than the number of routes in the Internet. A limit is still useful in order to protect the network (and in particular, the routers' memory) if too many routes are sent by the upstream. The limit should be chosen according to the number of routes that can actually be handled by routers.

o 对于提供完整路由的上游,建议具有高于Internet中路由数的限制。如果上游发送的路由过多,则限制仍然有用,以保护网络(尤其是路由器的内存)。限制应该根据路由器实际可以处理的路由数量来选择。

It is important to regularly review the limits that are configured as the Internet can quickly change over time. Some vendors propose mechanisms to have two thresholds: while the higher number specified will shut down the peering, the first threshold will only trigger a log and can be used to passively adjust limits based on observations made on the network.


9. AS Path Filtering
9. AS路径过滤

This section lists the RECOMMENDED practices when processing BGP AS paths.


o Network administrators SHOULD accept from customers only 2-byte or 4-byte AS paths containing ASNs belonging to (or authorized to transit through) the customer. If network administrators cannot build and generate filtering expressions to implement this, they SHOULD consider accepting only path lengths relevant to the type of customer they have (as in, if these customers are a leaf or have customers of their own) and SHOULD try to discourage excessive prepending in such paths. This loose policy could be

o 网络管理员应仅接受来自客户的2字节或4字节路径,作为包含属于(或授权通过)客户的ASN的路径。如果网络管理员不能建立和生成过滤表达式来实现这一点,那么他们应该考虑只接受与他们拥有的客户类型相关的路径长度(如,如果这些客户是一片叶子或有自己的客户),并且应该设法阻止在这样的路径中过度的提前准备。这种宽松的政策可能是错误的

combined with filters for specific 2-byte or 4-byte AS paths that must not be accepted if advertised by the customer, such as upstream transit providers or peer ASNs.


o Network administrators SHOULD NOT accept prefixes with private AS numbers in the AS path unless the prefixes are from customers. An exception could occur when an upstream is offering some particular service like black-hole origination based on a private AS number: in that case, prefixes SHOULD be accepted. Customers should be informed by their upstream in order to put in place ad hoc policy to use such services.

o 网络管理员不应接受AS路径中带有专用AS编号的前缀,除非前缀来自客户。当上游基于私有AS编号提供某些特定服务(如黑洞起源)时,可能会发生异常:在这种情况下,应接受前缀。上游应通知客户,以便制定使用此类服务的特别政策。

o Network administrators SHOULD NOT accept prefixes when the first AS number in the AS path is not the one of the peer's unless the peering is done toward a BGP route server [17] (for example, on an IXP) with transparent AS path handling. In that case, this verification needs to be deactivated, as the first AS number will be the one of an IXP member, whereas the peer AS number will be the one of the BGP route server.

o 当AS路径中的第一个AS编号不是对等方的AS编号时,网络管理员不应接受前缀,除非使用透明AS路径处理朝BGP路由服务器[17](例如,在IXP上)进行对等。在这种情况下,需要停用此验证,因为第一个as编号将是IXP成员的编号,而对等as编号将是BGP路由服务器的编号。

o Network administrators SHOULD NOT advertise prefixes with a nonempty AS path unless they intend to provide transit for these prefixes.

o 网络管理员不应使用非空AS路径播发前缀,除非他们打算为这些前缀提供传输。

o Network administrators SHOULD NOT advertise prefixes with upstream AS numbers in the AS path to their peering AS unless they intend to provide transit for these prefixes.

o 除非网络管理员打算为这些前缀提供传输,否则不应在其对等AS的AS路径中公布带有上游AS编号的前缀。

o Private AS numbers are conventionally used in contexts that are "private" and SHOULD NOT be used in advertisements to BGP peers that are not party to such private arrangements, and they SHOULD be stripped when received from BGP peers that are not party to such private arrangements.

o 私人AS号码通常用于“私人”的上下文中,不应用于向未参与此类私人安排的BGP对等方发布的广告中,并且当从未参与此类私人安排的BGP对等方收到这些号码时,应将其删除。

o Network administrators SHOULD NOT override BGP's default behavior, i.e., they should not accept their own AS number in the AS path. When considering an exception, the impact (which may be severe on routing) should be studied carefully.

o 网络管理员不应覆盖BGP的默认行为,即,他们不应在AS路径中接受自己的AS编号。在考虑例外情况时,应仔细研究影响(可能对路由造成严重影响)。

AS path filtering should be further analyzed when ASN renumbering is done. Such an operation is common, and mechanisms exist to allow smooth ASN migration [28]. The usual migration technique, local to a router, consists in modifying the AS path so it is presented to a peer with the previous ASN, as if no renumbering was done. This makes it possible to change the ASN of a router without reconfiguring all EBGP peers at the same time (as that operation would require synchronization with all peers attached to that router). During this renumbering operation, the rules described above may be adjusted.


10. Next-Hop Filtering
10. 下一跳滤波

If peering on a shared network, like an IXP, BGP can advertise prefixes with a third-party next hop, thus directing packets not to the peer announcing the prefix but somewhere else.


This is a desirable property for BGP route-server setups [17], where the route server will relay routing information but has neither the capacity nor the desire to receive the actual data packets. So, the BGP route server will announce prefixes with a next-hop setting pointing to the router that originally announced the prefix to the route server.


In direct peerings between ISPs, this is undesirable, as one of the peers could trick the other one into sending packets into a black hole (unreachable next hop) or to an unsuspecting third party who would then have to carry the traffic. Especially for black-holing, the root cause of the problem is hard to see without inspecting BGP prefixes at the receiving router of the IXP.


Therefore, an inbound route policy SHOULD be applied on IXP peerings in order to set the next hop for accepted prefixes to the BGP peer IP address (belonging to the IXP LAN) that sent the prefix (which is what "next-hop-self" would enforce on the sending side).

因此,应在IXP对等上应用入站路由策略,以便将接受前缀的下一跳设置为发送前缀的BGP对等IP地址(属于IXP LAN)(这是“下一跳自我”将在发送端强制执行的)。

This policy SHOULD NOT be used on route-server peerings or on peerings where network administrators intentionally permit the other side to send third-party next hops.


This policy also SHOULD be adjusted if the best practice of Remote Triggered Black Holing (aka RTBH as described in RFC 6666 [13]) is implemented. In that case, network administrators would apply a well-known BGP next hop for routes they want to filter (if an Internet threat is observed from/to this route, for example). This well-known next hop will be statically routed to a null interface. In combination with a unicast RPF check, this will discard traffic from and toward this prefix. Peers can exchange information about black holes using, for example, particular BGP communities. Network administrators could propagate black-hole information to their peers using an agreed-upon BGP community: when receiving a route with that community, a configured policy could change the next hop in order to create the black hole.

如果实施远程触发黑洞(RFC 6666[13]中所述的RTBH)的最佳实践,也应调整该政策。在这种情况下,网络管理员将为他们想要筛选的路由应用一个众所周知的BGP下一跳(例如,如果观察到来自/到该路由的互联网威胁)。这个众所周知的下一跳将静态路由到空接口。结合单播RPF检查,这将丢弃来自和朝向该前缀的通信量。对等方可以使用特定的BGP社区交换有关黑洞的信息。网络管理员可以使用商定的BGP社区将黑洞信息传播给他们的对等方:当接收到该社区的路由时,配置的策略可以更改下一跳以创建黑洞。

11. BGP Community Scrubbing
11. 社区清洗

Optionally, we can consider the following rules on BGP AS paths:


o Network administrators SHOULD scrub inbound communities with their number in the high-order bits, and allow only those communities that customers/peers can use as a signaling mechanism

o 网络管理员应将入站社区的编号保留在高位,并仅允许客户/对等方将这些社区用作信令机制

o Networks administrators SHOULD NOT remove other communities applied on received routes (communities not removed after application of the previous statement). In particular, they SHOULD keep original communities when they apply a community. Customers might need them to communicate with upstream providers. In particular, network administrators SHOULD NOT (generally) remove the no-export community, as it is usually announced by their peer for a certain purpose.

o 网络管理员不应删除已接收路由上应用的其他社区(在应用上一条语句后未删除的社区)。特别是,他们在申请社区时应保留原始社区。客户可能需要他们与上游供应商沟通。特别是,网络管理员不应该(通常)删除no export社区,因为它通常是由他们的对等方出于某种目的宣布的。

12. Security Considerations
12. 安全考虑

This document is entirely about BGP operational security. It depicts best practices that one should adopt to secure BGP infrastructure: protecting BGP router and BGP sessions, adopting consistent BGP prefix and AS path filters, and configuring other options to secure the BGP network.


This document does not aim to describe existing BGP implementations, their potential vulnerabilities, or ways they handle errors. It does not detail how protection could be enforced against attack techniques using crafted packets.


13. References
13. 工具书类
13.1. Normative References
13.1. 规范性引用文件

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997, <>.

[1] Bradner,S.,“RFC中用于表示需求水平的关键词”,RFC 211997年3月<>.

[2] Rekhter,, Y., Li,, T., and S. Hares,, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006, <>.

[2] Rekhter,Y.,Li,,T.,和S.Hares,,“边境网关协议4(BGP-4)”,RFC 42712006年1月<>.

[3] Gill, V., Heasley, J., Meyer, D., Savola,, P., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007, <>.

[3] Gill,V.,Heasley,J.,Meyer,D.,Savola,,P.,和C.Pignataro,“广义TTL安全机制(GTSM)”,RFC 5082,2007年10月<>.

[4] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010, <>.

[4] Touch,J.,Mankin,A.,和R.Bonica,“TCP认证选项”,RFC 59252010年6月<>.

[5] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, January 2013, <>.

[5] Mohapatra,P.,Scudder,J.,Ward,D.,Bush,R.,和R.Austein,“BGP前缀来源验证”,RFC 68112013年1月<>.

[6] Pelsser, C., Bush, R., Patel, K., Mohapatra, P., and O. Maennel, "Making Route Flap Damping Usable", RFC 7196, May 2014, <>.

[6] Pelsser,C.,Bush,R.,Patel,K.,Mohapatra,P.,和O.Maennel,“使路线襟翼阻尼可用”,RFC 71962014年5月<>.

13.2. Informative References
13.2. 资料性引用

[7] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998, <>.

[7] Heffernan,A.,“通过TCP MD5签名选项保护BGP会话”,RFC 2385,1998年8月<>.

[8] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", RFC 2827, May 2000, <>.

[8] Ferguson,P.和D.Senie,“网络入口过滤:击败利用IP源地址欺骗的拒绝服务攻击”,RFC 2827,2000年5月<>.

[9] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", RFC 3704, March 2004, <>.

[9] Baker,F.和P.Savola,“多址网络的入口过滤”,RFC 37042004年3月<>.

[10] Blunk, L., Damas, J., Parent, F., and A. Robachevsky, "Routing Policy Specification Language next generation (RPSLng)", RFC 4012, March 2005, <>.

[10] Blunk,L.,Damas,J.,Parent,F.,和A.Robachevsky,“下一代路由策略规范语言(RPSLng)”,RFC4012,2005年3月<>.

[11] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the Router Control Plane", RFC 6192, March 2011, <>.

[11] Dugal,D.,Pignataro,C.,和R.Dunn,“保护路由器控制平面”,RFC 61922011年3月<>.

[12] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012, <>.

[12] Lepinski,M.和S.Kent,“支持安全互联网路由的基础设施”,RFC 64802012年2月<>.

[13] Hilliard, N. and D. Freedman, "A Discard Prefix for IPv6", RFC 6666, August 2012, <>.

[13] Hilliard,N.和D.Freedman,“IPv6的丢弃前缀”,RFC 66662012年8月<>.

[14] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, May 2013, <>.

[14] Jethanandani,M.,Patel,K.,和L.Zheng,“根据路由协议键控和认证(KARP)设计指南分析BGP,LDP,PCEP和MSDP问题”,RFC 6952,2013年5月<>.

[15] Bush, R., "Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)", RFC 7115, January 2014, <>.

[15] Bush,R.,“基于资源公钥基础设施(RPKI)的来源验证操作”,RFC 7115,2014年1月<>.

[16] Kent, S. and A. Chi, "Threat Model for BGP Path Security", RFC 7132, February 2014, <>.

[16] Kent,S.和A.Chi,“BGP路径安全的威胁模型”,RFC 71322014年2月<>.

[17] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, "Internet Exchange Route Server", Work in Progress, draft-ietf-idr-ix-bgp-route-server-06, December 2014.

[17] Jasinska,E.,Hilliard,N.,Raszuk,R.,和N.Bakker,“互联网交换路由服务器”,正在进行的工作,草稿-ietf-idr-ix-bgp-Route-Server-062014年12月。

[18] Karrenberg, D., "RIPE-351 - De-Bogonising New Address Blocks", October 2005.

[18] Karrenberg,D.,“RIMME-351-去Bogonising新地址块”,2005年10月。

[19] Smith, P. and C. Panigl, "RIPE-378 - RIPE Routing Working Group Recommendations On Route-flap Damping", May 2006.

[19] Smith,P.和C.Panigl,“RIME-378-RIME路由工作组关于路由襟翼阻尼的建议”,2006年5月。

[20] Smith, P., Evans, R., and M. Hughes, "RIPE-399 - RIPE Routing Working Group Recommendations on Route Aggregation", December 2006.

[20] Smith,P.,Evans,R.,和M.Hughes,“RIME-399-RIME路由工作组关于路由聚合的建议”,2006年12月。

[21] Smith, P. and R. Evans, "RIPE-532 - RIPE Routing Working Group Recommendations on IPv6 Route Aggregation", November 2011.

[21] Smith,P.和R.Evans,“RIME-532-RIME路由工作组关于IPv6路由聚合的建议”,2011年11月。

[22] Smith, P., Bush, R., Kuhne, M., Pelsser, C., Maennel, O., Patel, K., Mohapatra, P., and R. Evans, "RIPE-580 - RIPE Routing Working Group Recommendations On Route-flap Damping", January 2013.

[22] Smith,P.,Bush,R.,Kuhne,M.,Pelsser,C.,Maennel,O.,Patel,K.,Mohapatra,P.,和R.Evans,“RIME-580-RIME路由工作组关于路由襟翼阻尼的建议”,2013年1月。

[23] IANA, "IANA IPv4 Special-Purpose Address Registry", <>.

[23] IANA,“IANA IPv4专用地址注册表”<>.

[24] IANA, "IANA IPv6 Special-Purpose Address Registry", <>.

[24] IANA,“IANA IPv6专用地址注册表”<>.

[25] IANA, "IANA IPv4 Address Space Registry", <>.

[25] IANA,“IANA IPv4地址空间注册表”<>.

[26] IANA, "Internet Protocol Version 6 Address Space", <>.

[26] IANA,“互联网协议版本6地址空间”<>.

[27] Merit Network Inc., "Merit RADb", <>.

[27] 美德网络公司,“美德无线电广播公司”<>.

[28] George, W. and S. Amante, "Autonomous System (AS) Migration Features and Their Effects on the BGP AS_PATH Attribute", Work in Progress, draft-ga-idr-as-migration-03, January 2014.

[28] George,W.和S.Amante,“自主系统(AS)迁移特征及其对BGP AS_路径属性的影响”,正在进行的工作,草稿-ga-idr-AS-Migration-03,2014年1月。

[29] Bellovin, S., Bush, R., and D. Ward, "Security Requirements for BGP Path Validation", RFC 7353, August 2014, <>.

[29] Bellovin,S.,Bush,R.,和D.Ward,“BGP路径验证的安全要求”,RFC 73532014年8月<>.

[30] "IRRToolSet project page", <>.

[30] “IRRToolSet项目页面”<>.

[31] Cooper, D., Heilman, E., Brogle, K., Reyzin, L., and S. Goldberg, "On the Risk of Misbehaving RPKI Authorities", <>.

[31] Cooper,D.,Heilman,E.,Brogle,K.,Reyzin,L.,和S.Goldberg,“关于RPKI当局行为不端的风险”<>。

Appendix A. IXP LAN Prefix Filtering - Example
附录A.IXP LAN前缀过滤-示例

An IXP in the RIPE region is allocated an IPv4 /22 prefix by RIPE NCC (X.Y.0.0/22 in this example) and uses a /23 of this /22 for the IXP LAN (let say X.Y.0.0/23). This IXP LAN prefix is the one used by IXP members to configure EBGP peerings. The IXP could also be allocated an AS number (AS64496 in our example).

成熟区域中的IXP由成熟NCC(本例中为X.Y.0.0/22)分配IPv4/22前缀,并将此/22的a/23用于IXP LAN(假设为X.Y.0.0/23)。这个IXP LAN前缀是IXP成员用来配置EBGP对等的前缀。IXP也可以分配一个AS号(在我们的示例中是AS64496)。

Any IXP member SHOULD make sure it filters prefixes more specific than X.Y.0.0/23 from all its EBGP peers. If it received X.Y.0.0/24 or X.Y.1.0/24 this could seriously impact its routing.


The IXP SHOULD originate X.Y.0.0/22 and advertise it to its members through an EBGP peering (most likely from its BGP route servers, configured with AS64496).


The IXP members SHOULD accept the IXP prefix only if it passes the IRR generated filters (see Section


IXP members SHOULD then advertise X.Y.0.0/22 prefix to their downstreams. This announce would pass IRR based filters as it is originated by the IXP.




The authors would like to thank the following people for their comments and support: Marc Blanchet, Ron Bonica, Randy Bush, David Freedman, Wesley George, Daniel Ginsburg, David Groves, Mike Hugues, Joel Jaeggli, Tim Kleefass, Warren Kumari, Jacques Latour, Lionel Morand, Jerome Nicolle, Hagen Paul Pfeifer, Thomas Pinaud, Carlos Pignataro, Jean Rebiffe, Donald Smith, Kotikalapudi Sriram, Matjaz Straus, Tony Tauber, Gunter Van de Velde, Sebastian Wiesinger, and Matsuzaki Yoshinobu.

作者要感谢以下人士的评论和支持:马克·布兰切特、罗恩·博尼卡、兰迪·布什、大卫·弗里德曼、韦斯利·乔治、丹尼尔·金斯堡、大卫·格罗夫斯、迈克·胡格斯、乔尔·贾格利、蒂姆·克莱法斯、沃伦·库马里、雅克·拉图尔、莱昂内尔·莫兰、杰罗姆·尼科尔、哈根·保罗·普费弗、托马斯·皮诺德、卡洛斯·皮格纳塔罗、,Jean Rebiffe、Donald Smith、Kotikalapudi Sriram、Matjaz Straus、Tony Tauber、Gunter Van de Velde、Sebastian Wiesinger和Matsuzaki Yoshinobu。

The authors would like to thank once again Gunter Van de Velde for presenting the document at several IETF meetings in various working groups, indeed helping dissemination of this document and gathering of precious feedback.

作者要再次感谢Gunter Van de Velde在各个工作组的几次IETF会议上介绍了该文件,确实帮助了本文件的传播和宝贵反馈的收集。

Authors' Addresses


Jerome Durand Cisco Systems, Inc. 11 rue Camille Desmoulins Issy-les-Moulineaux 92782 CEDEX France

Jerome Durand Cisco Systems,Inc.法国西德克斯卡米尔德斯穆林街11号


Ivan Pepelnjak NIL Data Communications Tivolska 48 Ljubljana 1000 Slovenia

Ivan Pepelnjak NIL数据通信Tivolska 48卢布尔雅那1000斯洛文尼亚


Gert Doering SpaceNet AG Joseph-Dollinger-Bogen 14 Muenchen D-80807 Germany

Gert Doering SpaceNet AG Joseph Dollinger Bogen 14 Muenchen D-80807德国