RFC 7454

BGP Operations and Security

📅 published February 2015, from ietf

BGP Operations and Security 🎀

Okay bestie, let's start with the basics 💅. This is RFC 7454, called BGP Operations and Security. It's a Best Current Practice (that's BCP: 194 🌸), and it was published in February 2015. The authors are J. Durand from Cisco Systems, Inc., I. Pepelnjak (no affiliation, so it says NIL), and G. Doering from SpaceNet. It's from the IETF, and its ISSN is 2070-1721. The header doesn't list anything it obsoletes or updates, so it's standing on its own, no cap 🧚.

Abstract ✨

BGP is basically the protocol the whole Internet uses to swap routing info between network domains 🌈. Because it's so central, you really need to know which security measures you can and should use to stop accidental or intentional routing chaos 💀.

This doc covers ways to protect the BGP sessions themselves, like Time to Live (TTL), the TCP Authentication Option (TCP-AO), and control-plane filtering 🔥. It also covers how to control the flow of routing information better, using prefix filtering and automating 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, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). More info on BCPs is in Section 2 of RFC 5741 📚.

For the current status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc7454 🦋.

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

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 publication date. Please read these carefully, because they spell out your rights and restrictions for this document 👑. Code Components pulled from this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License 🙈.

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 ✨

BGP, which is specified in RFC 4271 [2], is the protocol the Internet uses to exchange routing information between network domains 🌸. BGP doesn't directly have mechanisms that check whether the routes being swapped follow the various guidelines the Internet community has defined 🙈. This doc wants to do two things: sum up the common guidelines that already exist, and help network admins apply BGP policies that actually make sense together 🧚.

1.1. Requirements Language 🦋

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] 📚.

2. Scope of the Document 💖

These guidelines are meant for generic Internet BGP peerings 🌈. The Internet is set up so that Autonomous Systems can always agree on exceptions to a common framework for their local needs, so they can configure a BGP session differently from what this doc recommends 🫶. That's perfectly fine, but every exception you configure could affect the entire inter-domain routing environment, so network administrators SHOULD carefully appraise this impact before implementation 👑.

3. Definitions and Acronyms 🍓

Here's the acronym list 💅:

  • ACL: Access Control List
  • ASN: Autonomous System Number
  • IRR: Internet Routing Registry
  • IXP: Internet Exchange Point
  • LIR: Local Internet Registry
  • PMTUD: Path MTU Discovery
  • RIR: Regional Internet Registry
  • Tier 1 transit provider: an IP transit provider that can reach any network on the Internet without purchasing transit services.
  • uRPF: Unicast Reverse Path Forwarding

Besides that list, these terms have a specific meaning in this doc 🦋:

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

4. Protection of the BGP Speaker 🛡️

The BGP speaker needs protection from anyone trying to mess with the BGP session 😭. This protection SHOULD be achieved with an Access Control List (ACL) that discards all packets aimed at TCP port 179 on the local device and sourced from an address that isn't known or permitted to become a BGP neighbor 🔥. Experience has shown that the natural protection TCP should offer isn't always enough, since it's sometimes run in control-plane software 💀. Without ACLs, an attacker can hit a BGP speaker just by sending a huge volume of connection requests to it 🙈.

If the router supports it, an ACL specific to its control plane SHOULD be used (receive-ACL, control-plane policing, etc.) 💖. That way you don't have to configure data-plane filters for packets just passing through the router, which never reach the control plane anyway ✨. If the hardware can't do that, interface ACLs can block packets addressed to the local router 🫶.

Some routers set up this kind of ACL automatically when you configure BGP 🧚. On other devices, this ACL should be configured and maintained manually or with scripts 🎀.

On top of strict filtering, rate-limiting MAY be configured for accepted BGP traffic 🌸. Rate-limiting means only letting a certain number of bits per second (or packets per second) of BGP traffic reach the control plane 🔥. That protects the BGP router's control plane in case the BGP traffic goes over what the platform can handle 👑.

Filtering and rate-limiting control-plane traffic is a bigger topic than just BGP 🌈. (If a network admin takes down a router by overloading some other protocol remotely, BGP gets hurt too 😭.) For a more detailed guide on protecting the router's control plane, see RFC 6192 [11] 📚.

5. Protection of BGP Sessions 💜

The current security issues with TCP-based protocols (so that includes BGP) are documented in RFC 6952 [14] 🦋. The subsections below list the major points that RFC raises and give the best practices for TCP session protection in BGP operations ✨.

5.1. Protection of TCP Sessions Used by BGP 🔐

Attacks on the TCP sessions BGP uses (aka BGP sessions) can bring a BGP peering down, for example by sending spoofed TCP RST packets 💀. After a successful ARP spoofing attack (or a similar man-in-the-middle attack), an attacker might even be able to inject packets into the TCP stream, which means routing attacks 😱.

There are a bunch of ways to secure BGP sessions 🎀. MD5 protection of the TCP session header, described in RFC 2385 [7], was the first one 🌸. It's been obsoleted by the TCP Authentication Option (TCP-AO; RFC 5925 [4]), which offers stronger protection 💅. MD5 is still the most-used option because vendors' equipment has it, but TCP-AO SHOULD be preferred when it's implemented 👑.

IPsec could also be used for session protection 🧚. At the time of publication, there wasn't enough experience with IPsec for BGP peerings to know its impact, so more analysis is needed before guidelines can be defined 🙈.

The downside of TCP session protection is the extra configuration and management overhead of maintaining authentication info (like MD5 passwords) 😭. So protecting TCP sessions used by BGP is NOT REQUIRED, even when peerings run over shared networks where spoofing is possible (like IXPs) 🫶. Operators are RECOMMENDED to weigh the trade-offs and apply TCP session protection where it makes sense 💖.

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

5.2. BGP TTL Security (GTSM) 🎀

okay bestie, BGP sessions can be made way harder to spoof with the Generalized TTL Security Mechanisms (GTSM aka TTL security), which are defined in RFC 5082 [3] 💅. Instead of sending TCP packets with a TTL value of 1, the BGP speakers send them with a TTL value of 255, and the receiver checks that the TTL value equals 255 ✨. It's impossible to send an IP packet with a TTL of 255 to an IP host that isn't directly connected, so BGP TTL security effectively blocks all spoofing attacks from third parties that aren't directly connected to the same subnet as the BGP-speaking routers 🙈. Network administrators SHOULD implement TTL security on directly connected BGP peerings 🫶.

GTSM could also be applied to multi-hop BGP peering 🌸. To make it work, you need to configure the TTL with a proper value based on the distance between the BGP speakers (using the principle we just went over) 🧚. Honestly, it's 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 💖

the main thing about securing BGP is controlling which prefixes get received and advertised on the BGP peerings 👑. Prefixes exchanged between BGP peers are controlled with inbound and outbound filters. These 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, like BGP communities (as described in Section 11) 🌈.

6.1. Definition of Prefix Filters 🍓

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.1. IPv4 Special-Purpose Prefixes

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 the value "False" in the column "Global" SHOULD be discarded on Internet BGP peerings 🚫.

6.1.1.2. IPv6 Special-Purpose Prefixes

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 the value "False" in the column "Global" SHOULD be discarded on Internet BGP peerings 🌸.

6.1.2. Unallocated Prefixes 🎀

okay so IANA allocates prefixes to RIRs, and those RIRs allocate prefixes to LIRs (Local Internet Registries) 🌍. It is wise not to accept routing table prefixes that weren't allocated by IANA and/or RIRs 🧠. This section details the options for building a list of allocated prefixes at every level. It's really important to understand that filtering unallocated prefixes needs constant updates, since prefixes keep getting allocated 😩. So automating these prefix filters is key for this approach to work 🤖. Network administrators SHOULD NOT consider the solutions in this section if they aren't capable of maintaining updated prefix filters, because the damage would probably be worse than the intended security policy 💀.

6.1.2.1. IANA-Allocated Prefix Filters 💜

IANA has allocated all the available IPv4 space 🥲. There's no reason for network administrators to keep checking that the prefixes they receive from BGP peers are in the IANA-allocated IPv4 address space [25]. Administrators who want to make sure the IPv4 prefixes they receive in BGP updates were allocated by IANA don't need to put any specific filters in place 💁‍♀️.

For IPv6, given how big the address space is, 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]. Since IANA keeps allocating prefixes to RIRs, the list above should be checked regularly for changes. If changes happen, prefix filters should be computed and pushed onto network devices 🔁. The list could also be pulled directly by routers, if they implement such mechanisms 🫶. There's a delay between the time a RIR receives a new prefix and the moment it starts allocating portions of it to its LIRs, so there's no need to do 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) can't guarantee that the list is updated regularly, then it's better not to configure any filters based on allocated networks 🙅‍♀️. The IPv4 experience showed that many network operators implemented filters for prefixes not allocated by IANA but didn't update them on a regular basis 😬. This created problems for the latest allocations, and it required extra work for RIRs, who had to "de-bogonize" the newly allocated prefixes (see [18] for information on de-bogonizing) 🧹.

6.1.2.2. RIR-Allocated Prefix Filters 🌷

a more precise check can be performed when you want to make sure the prefixes you receive are being originated or transited by Autonomous Systems (ASes) that are 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 need to make sure BGP advertisements correspond to the information in the existing registries 📚. At this stage, two options can be considered: short- and long-term options. They are described in the following subsections 💅.

6.1.2.2.1. Prefix Filters Created from Internet Routing Registries (IRRs) 🗂️

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 the routing policies of their own networks in the IRR, and that information is published, usually publicly 📢. A majority of Regional Internet Registries also operate an IRR, and they 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 isn't necessarily complete, so the list of routes in an IRR isn't the same as the set of RIR-allocated prefixes 🤔.

it's possible to use the IRR information to build, for a given neighbor AS, a list of originated or transited prefixes that you may accept ✨. This can be done relatively easily with scripts and existing tools that retrieve this information from the registries 🛠️. This approach is exactly the same for both IPv4 and IPv6 👯‍♀️.

Here's the macro-algorithm for the script 🧠. For the peer being 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-SETs of connected operators, which in turn describe the AS numbers of their customers 🏢. Using recursion, it's 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's 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 they should be originated from 🎉. You could also decide not to use the origin information and only build monolithic prefix filters from the fetched data 🧱.

As prefixes, AS numbers, and AS-SETs may not all be under the same RIR authority, it's difficult to choose the appropriate IRR to poll for each object 😵‍💫. Some IRRs have been created that aren't restricted to a given region or authoritative RIR 🌐. They allow RIRs to publish the 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 making requests inside such an IRR, you can specify the source of information to get the most reliable data 🎯. You 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) 🛡️.

Objects in IRRs can change frequently over time, so it's important that prefix filters computed this way are refreshed regularly ⏰. Refreshing the filters on a daily basis SHOULD be considered, because routing changes sometimes have to be made in an emergency, and registries may be updated at the very last moment 🚨. Be warned: this approach significantly increases the complexity of router configurations, since 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 that simplifies creating 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 one is available 💖.

6.1.2.2.2. SIDR - Secure Inter-Domain Routing ✨

okay so there's this whole infrastructure called SIDR (Secure Inter-Domain Routing), described in RFC 6480 [12], and it was built to lock down Internet advertisements 🔒. when this was written, a bunch of documents were already out there, and a full framework of protocols was being proposed so advertisements can get checked against signed routing objects held by RIRs. SIDR basically gives you two services 💅

  • Origin validation, described in RFC 6811 [5], is all about making sure the attributes on routes are legit. (the big one is checking that the AS number originating a route is the right one 👀) Origin validation is operational now (registries, protocols, and implementations on some routers are all live 🎉). In theory you can implement it, even though the number of signed resources was still pretty low when this was written 🥺
  • Path validation, provided by BGPsec [29], is there to make sure nobody announces fake or wrong BGP paths that would pull traffic toward a destination. see RFC 7132 [16] for that 🕵️‍♀️. BGPsec was still an ongoing work item when this was written, so it could not be implemented yet 🚧

implementing SIDR mechanisms is expected to fix a lot of BGP routing security problems in the long run ⏳, but deployments and signed objects can take a minute to show up 🫠. also, SIDR is complementing the security best practices in this document, not replacing them 💖. so network administrators SHOULD implement any SIDR-proposed mechanism (route origin validation, for example) on top of the other existing mechanisms, even if they seem to be going after the same goal 🫶.

if you do implement route origin validation, the reader SHOULD refer to the rules in RFC 7115 [15]. the short version: each external route received on a router SHOULD be checked against the Resource Public Key Infrastructure (RPKI) data set 🔍
  • if a corresponding ROA (Route Origin Authorization) is found and is valid, then the prefix SHOULD be accepted ✅
  • if the ROA is found and is INVALID, then the prefix SHOULD be discarded 🗑️
  • if a ROA is not found, then the prefix SHOULD be accepted, but the corresponding route SHOULD be given a low preference 🥀

on top of all that, network administrators SHOULD sign their routing objects so other networks running origin validation can validate their routes 📝✨

ngl the RPKI model brings some new and genuinely interesting challenges 🤯. the paper "On the Risk of Misbehaving RPKI Authorities" [31] explains how the RPKI model can affect the Internet if authorities don't behave the way they're supposed to 😬. more analysis on RPKI is definitely needed, since it carries part of BGP security 🧐.

6.1.3. Prefixes That Are Too Specific 🔎

most ISPs won't accept advertisements past a certain level of specificity, and in return they don't announce prefixes they consider too specific 🤝. that acceptable specificity is decided for each peering between the two BGP peers. some ISP communities have tried to write this down. this document doesn't judge what the best approach is 🙅‍♀️. it just notes that there are existing practices on the Internet and recommends that the reader look at them 📚. for example, the RIPE community documented that, when this was written, IPv4 prefixes longer than /24 and IPv6 prefixes longer than /48 are generally neither announced nor accepted on the Internet [20] [21] 💀. those values may change in the future 🔄.

6.1.4. Filtering Prefixes Belonging to the Local AS and Downstreams 🏠

a network SHOULD filter its own prefixes on peerings with all of its peers (inbound direction) 🛑. this stops local traffic (from a local source to a local destination) from leaking out over an external peering, in case someone else is announcing that prefix over the Internet 😤. it also protects the infrastructure that could directly suffer if the backbone's prefix suddenly gets preferred over the Internet 🫣.

in some cases, like multihoming scenarios, such filters SHOULD NOT be applied, since that would break the redundancy you want 🙅‍♀️💔.

to an extent, these filters can also be set up on a network for its downstreams' prefixes to protect them too 🛡️. but they have to be defined with caution, because they can break existing redundancy mechanisms ⚠️. for example, when an operator has a multihomed customer, it should keep accepting the customer's prefix from its peers and upstreams 🎀. that way the customer can keep reaching the 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.1. 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 those routes may create a black hole for connectivity to the IXP LAN 🕳️.

if the IXP LAN prefix is accepted as an "exact match", you have to be careful that other routers in the network don't send IXP traffic toward the externally learned IXP LAN prefix (a recursive route lookup pointing the wrong way 🙃). this can be handled by preferring IGP routes over External BGP (EBGP), or by using "BGP next-hop-self" on all routes learned on that IXP 🧭.

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 usually happens automatically when you filter announcements using the IRR database 🪄.

6.1.5.2. PMTUD and the Loose uRPF Problem 📦

to get PMTUD working with loose uRPF, all the networks that may source traffic that could flow through the IXP (IXP members and their downstreams) need a route for the IXP LAN prefix 🗺️. this matters because "packet too big" ICMP messages sent by IXP members' routers may be sourced from an address in the IXP LAN prefix. with loose uRPF, that ICMP packet gets dropped if there's no route for the IXP LAN prefix, or for a less specific route covering it 💥.

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 of 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 the IRR-generated filters described in Section 6.1.2.2.1, as well as the "prefixes that are too specific" filters described in Section 6.1.3 ✅. the easiest way to do this is for the IXP itself to originate its prefix and advertise it to all IXP members through a BGP peering 🎁. most likely, BGP route servers would be used for this, and the IXP would send its entire prefix, which is equal to or less specific than the IXP LAN prefix 🖥️.

Appendix A gives an example of guidelines for the IXP LAN prefix 📖.

6.1.6. The Default Route 🛣️

6.1.6.1. IPv4

typically, the 0.0.0.0/0 prefix isn't meant to be accepted or advertised, except in specific customer/provider configurations. general filtering outside of those is RECOMMENDED 🧹.

6.1.6.2. IPv6

typically, the ::/0 prefix isn't meant to be accepted or advertised, except in specific customer/provider configurations. general filtering outside of those is RECOMMENDED 🧹.

6.2. Prefix Filtering Recommendations in Full Routing Networks 🌍

for networks that carry 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 of its borders, since this protects the network and its peer even if there's a misconfiguration 🛡️💕. the most commonly used filtering policy is proposed in this section, and it uses the prefix filters defined in Section 6.1 🧁.

6.2.1. Filters with Internet Peers 🌐

6.2.1.1. Inbound Filtering 📥

there are basically two options. the loose one doesn't check anything against RIR allocations, and the strict one verifies that announcements strictly conform to what's declared in routing registries 🧐.

6.2.1.1.1. Inbound Filtering Loose Option 😌

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

  • prefixes that are not globally routable (Section 6.1.1)
  • prefixes not allocated by IANA (IPv6 only) (Section 6.1.2.1)
  • routes that are too specific (Section 6.1.3)
  • prefixes belonging to the local AS (Section 6.1.4)
  • IXP LAN prefixes (Section 6.1.5)
  • the default route (Section 6.1.6)

6.2.1.1.2. Inbound Filtering Strict Option 🧠

in this case, filters are applied to make sure advertisements strictly conform to what's declared in routing registries (Section 6.1.2.2). ⚠️ heads up: registries aren't always accurate (prefixes missing, wrong information, etc.), and this varies across 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 isn't worse than the problem 🔬.

also, if the script fails, each administrator may decide whether all routes are accepted or rejected, depending on routing policy 🤷‍♀️. accepting routes during that time frame could break BGP routing security, but rejecting them might re-route too much traffic over transit peers and cause more harm than a loose policy would have 😵‍💫.

in addition, network administrators could apply the following filters beforehand, in case the routing registry the script uses as its source of information isn't fully trusted 🫡:

  • prefixes that are not globally routable (Section 6.1.1)
  • routes that are too specific (Section 6.1.3)
  • prefixes belonging to the local AS (Section 6.1.4)
  • IXP LAN prefixes (Section 6.1.5)
  • the default route (Section 6.1.6)

6.2.1.2. Outbound Filtering 📤

the configuration should make sure only appropriate prefixes are sent 💌. these can be, for example, prefixes belonging to both the network in question and its downstreams. you can do this with BGP communities, AS paths, or both 🏷️. it may also be desirable to add the following filters before any policy, to avoid unwanted route announcements caused by bad configuration 🙈:

  • Prefixes that are not globally routable (Section 6.1.1)
  • Routes that are too specific (Section 6.1.3)
  • IXP LAN prefixes (Section 6.1.5)
  • The default route (Section 6.1.6)

if it's 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.1. Inbound Filtering 💖

okay so the inbound policy with end customers is seriously simple, bestie 🙅‍♀️: only customer prefixes SHOULD be accepted, and all the others SHOULD be discarded. You can write the accepted list out by hand, but only after you've verified the prefixes are valid. That check happens with the appropriate IP address management authorities 🧚.

The same rules apply when the customer is a network that connects other customers, like a Tier 1 transit provider linking up service providers 🦋. The exception is when the customer network applies strict inbound/outbound prefix filtering and announces too many prefixes to list in the router config. In that case, filters as in Section 6.2.1.1 can be applied 💅.

6.2.2.2. Outbound Filtering ✨

The outbound policy with customers depends on which routes the customer wants to get 👀. The simplest case is when they only want the default route. That's easy: apply a filter with the default route only 🎀.

If the customer wants the full routing table (maybe because they're multihomed, or they just want to see the whole Internet table 🌍), these filters can go on the BGP peering:

  • prefixes that are not globally routable (Section 6.1.1)
  • routes that are too specific (Section 6.1.3)
  • the default route (Section 6.1.6)

Sometimes the customer wants the default route on top of the full BGP table. The provider can do that by simply removing the filter for the default route 🍓. Heads up, though: the default route might not be in the routing table, so network admins may choose to originate it only for the peerings where it has to be advertised 🧚.

6.2.3. Filters with Upstream Providers 🌷

6.2.3.1. Inbound Filtering 🎯

If you want the full routing table from your upstream, the prefix filtering is the same as the one for peers (Section 6.2.1.1), except for the default route. Sometimes the default route (on top of the full BGP table) is desired from an upstream provider. If that upstream is supposed to announce only the default route, a simple filter does the job: accept only the default prefix and nothing else 🧁.

6.2.3.2. Outbound Filtering 💅

The filters would most likely not look that different from the ones used for Internet peers (Section 6.2.1.2). Still, 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.1. Inbound Filtering 🍃

The leaf network will deploy the filters that match the routes it's requesting from its upstream. If it requests a default route, a simple inbound filter can accept only the default route (Section 6.1.6). If the leaf network can't list the prefixes because there are too many (for example, if it needs the full Internet routing table), then it should configure the following filters to avoid receiving bad announcements from its upstream 🛡️:

  • prefixes not routable (Section 6.1.1)
  • routes that are too specific (Section 6.1.3)
  • prefixes belonging to local AS (Section 6.1.4)
  • the default route (Section 6.1.6) depending on whether or not the route is requested

6.3.2. Outbound Filtering 📤

A leaf network will most likely have a super straightforward policy: it only announces its local routes 🏡. It can also configure the prefix filters described in Section 6.2.1.2 so it doesn't announce invalid routes to its upstream provider.

7. BGP Route Flap Dampening 🔥

The BGP route flap dampening mechanism gives penalties to routes every time they change in the BGP routing table 📉. It was originally created to protect the entire Internet from the many events that hit a single network. Studies have shown that implementations of BGP route flap dampening could do more harm than good, so in the past the RIPE community recommended against using it [19] 😬. Later on, studies were done to propose new dampening thresholds to make it "usable" (see RFC 7196 [6] and [22], where RIPE reviewed its own recommendations) 🧠. This document RECOMMENDS following the IETF and RIPE recommendations and using BGP route flap dampening with the adjusted, configured thresholds ✨.

8. Maximum Prefixes on a Peering 🚧

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

  • 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, based on the number of routes they're supposed to advertise, plus some headroom to allow for growth 📈.
  • 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 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 routers can actually handle.

It's important to review the limits regularly because the Internet can change fast 🏃‍♀️💨. Some vendors offer two thresholds: the higher number shuts down the peering, while the first threshold only triggers a log. You can use that log to passively adjust limits based on what you observe on the network 👀.

9. AS Path Filtering 🛣️

This section lists the RECOMMENDED practices for processing BGP AS paths 💅.

  • Network administrators SHOULD accept from customers only 2-byte or 4-byte AS paths containing ASNs that belong to (or are authorized to transit through) the customer 🪪. If network administrators can't build and generate filtering expressions to do this, they SHOULD consider accepting only the path lengths that fit the type of customer they have (like whether those customers are a leaf or have customers of their own), and they SHOULD try to discourage excessive prepending in such paths 🙄. This loose policy could be combined with filters for specific 2-byte or 4-byte AS paths that must not be accepted if the customer advertises them, such as upstream transit providers or peer ASNs 🚫.
  • Network administrators SHOULD NOT accept prefixes with private AS numbers in the AS path unless the prefixes come from customers 🔒. There's an exception: when an upstream offers a particular service like black-hole origination based on a private AS number, prefixes SHOULD be accepted in that case 🕳️. Customers should be informed by their upstream so they can set up ad hoc policy to use those services 📣.
  • Network administrators SHOULD NOT accept prefixes when the first AS number in the AS path isn't the peer's own, unless the peering is done toward a BGP route server [17] (for example, at an IXP) with transparent AS path handling 🤝. In that case, this verification needs to be turned off, because the first AS number will belong to an IXP member, while the peer AS number will belong to the BGP route server 🧩.
  • Network administrators SHOULD NOT advertise prefixes with a nonempty AS path unless they intend to provide transit for those prefixes 🚚.
  • 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 those prefixes 🙅‍♀️.
  • Private AS numbers are conventionally used in "private" contexts. They SHOULD NOT be used in advertisements to BGP peers that aren't party to those private arrangements, and they SHOULD be stripped when received from BGP peers that aren't party to those private arrangements 🤫.
  • Network administrators SHOULD NOT override BGP's default behavior, i.e., they should not accept their own AS number in the AS path 🙅‍♀️. If they're thinking about an exception, the impact (which may be severe on routing) should be studied carefully ⚠️.

AS path filtering should be analyzed further when ASN renumbering happens. It's a super common operation, and there are mechanisms for smooth ASN migration [28] 🦋. The usual migration technique, local to a router, changes the AS path so it's presented to a peer with the previous ASN, as if no renumbering happened 🪄. That makes it possible to change a router's ASN without reconfiguring all EBGP peers at the same time (which would otherwise require synchronizing with every peer attached to that router) 🫶. During this renumbering, the rules described above may be adjusted 🌈.

10. Next-Hop Filtering 🎀

If you're peering on a shared network like an IXP, BGP can advertise prefixes with a third-party next hop, which sends packets somewhere other than the peer that announced the prefix 🗺️.

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

In direct peerings between ISPs, though, this is undesirable 😤. One peer could trick the other into sending packets into a black hole (an unreachable next hop) or to an unsuspecting third party who then has to carry the traffic 💀. Especially for black-holing, the root cause is hard to spot without inspecting BGP prefixes at the receiving router of the IXP 🔍.

So, an inbound route policy SHOULD be applied on IXP peerings to set the next hop for accepted prefixes to the BGP peer IP address (on the IXP LAN) that sent the prefix. That's what "next-hop-self" would enforce on the sending side 🧚.

This policy SHOULD NOT be used on route-server peerings, or on peerings where network administrators intentionally let the other side 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 to routes they want to filter (for example, if an Internet threat is observed from or to that route) 🚨. That well-known next hop is statically routed to a null interface. Combined with a unicast RPF check, this discards traffic from and toward the prefix 🧹. Peers can exchange black-hole information using, for example, particular BGP communities 💬. Network administrators could also propagate black-hole information to their peers using an agreed-upon BGP community: when a route with that community is received, a configured policy could change the next hop to create the black hole 🖤.

That's the whole vibe, bestie! 🌈

11. BGP Community Scrubbing 🧹✨

okay so bestie, this section is basically about being a tidy little neighbor with your communities 💅. "Optionally" means you can think about these rules on BGP AS paths, no pressure 🌸.

  • 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 🧼💖
  • 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 🙈🌈.

12. Security Considerations 🔐💀

okay this one is SERIOUS bestie, but also iconic 😭🔥. 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.1. Normative References 💜

13.2. Informative References 🌸

Appendix A. IXP LAN Prefix Filtering - Example 🌐🦋

okay bestie, this example is giving real-world vibes 🌍✨. 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).

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

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 🌈💖.

Acknowledgements 🫶🎀

okay the authors wanna thank everyone who helped out, so here's the squad 💜: 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.

The authors would also 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 🌸✨.

Authors' Addresses 📮

  • Jerome Durand Cisco Systems, Inc. 11 rue Camille Desmoulins Issy-les-Moulineaux 92782 CEDEX France EMail: jerduran@cisco.com
  • Ivan Pepelnjak NIL Data Communications Tivolska 48 Ljubljana 1000 Slovenia EMail: ip@ipspace.net
  • Gert Doering SpaceNet AG Joseph-Dollinger-Bogen 14 Muenchen D-80807 Germany EMail: gert@space.net

That's the whole RFC, bestie! 🌈💖 BGP operational security, all wrapped up 🎀✨

📦 where this page comes from