diff options
Diffstat (limited to 'doc/rfc/rfc7454.txt')
| -rw-r--r-- | doc/rfc/rfc7454.txt | 1459 |
1 files changed, 1459 insertions, 0 deletions
diff --git a/doc/rfc/rfc7454.txt b/doc/rfc/rfc7454.txt new file mode 100644 index 0000000..5ed133b --- /dev/null +++ b/doc/rfc/rfc7454.txt @@ -0,0 +1,1459 @@ + + + + + + +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 + SpaceNet + February 2015 + + + BGP Operations and Security + +Abstract + + 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. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7454. + + + + + + + + + + + +Durand, et al. Best Current Practice [Page 1] + +RFC 7454 BGP OPSEC February 2015 + + +Copyright Notice + + 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 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Durand, et al. Best Current Practice [Page 2] + +RFC 7454 BGP OPSEC February 2015 + + +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 + + + + + + + + + + + + + +Durand, et al. Best Current Practice [Page 3] + +RFC 7454 BGP OPSEC February 2015 + + +1. Introduction + + 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. + +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 + + 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 + + o ACL: Access Control List + + o ASN: Autonomous System Number + + o IRR: Internet Routing Registry + + o IXP: Internet Exchange Point + + o LIR: Local Internet Registry + + o PMTUD: Path MTU Discovery + + o RIR: Regional Internet Registry + + o Tier 1 transit provider: an IP transit provider that can reach any + network on the Internet without purchasing transit services. + + o uRPF: Unicast Reverse Path Forwarding + + + +Durand, et al. Best Current Practice [Page 4] + +RFC 7454 BGP OPSEC February 2015 + + + 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 Upstream: any network that is upstream. + +4. Protection of the BGP Speaker + + 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]. + + + + + + + + +Durand, et al. Best Current Practice [Page 5] + +RFC 7454 BGP OPSEC February 2015 + + +5. Protection of BGP Sessions + + 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. + +5.1. Protection of TCP Sessions Used by BGP + + 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 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. + + 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. + +5.2. BGP TTL Security (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 + + + +Durand, et al. Best Current Practice [Page 6] + +RFC 7454 BGP OPSEC February 2015 + + + 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. + + 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 + + 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 + + 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 value + "False" in 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 + value "False" in column "Global" SHOULD be discarded on Internet BGP + peerings. + + + +Durand, et al. Best Current Practice [Page 7] + +RFC 7454 BGP OPSEC February 2015 + + +6.1.2. Unallocated Prefixes + + 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. + +6.1.2.1. IANA-Allocated Prefix Filters + + 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.) + + + + + +Durand, et al. Best Current Practice [Page 8] + +RFC 7454 BGP OPSEC February 2015 + + +6.1.2.2. RIR-Allocated Prefix Filters + + 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. + +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 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. + + 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 + + + + +Durand, et al. Best Current Practice [Page 9] + +RFC 7454 BGP OPSEC February 2015 + + + 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. + +6.1.2.2.2. 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: + + 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 + + + + +Durand, et al. Best Current Practice [Page 10] + +RFC 7454 BGP OPSEC February 2015 + + + 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. + + 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: + + o If a corresponding ROA (Route Origin Authorization) is found and + is valid, then the prefix SHOULD be accepted. + + o If the ROA is found and is INVALID, then the prefix SHOULD be + discarded. + + o If a ROA is not found, then the prefix SHOULD be accepted, but the + corresponding route SHOULD be given a low preference. + + 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. + + + + + + + + +Durand, et al. Best Current Practice [Page 11] + +RFC 7454 BGP OPSEC February 2015 + + +6.1.3. Prefixes That Are Too Specific + + 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 + + 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.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 these routes may create a black hole for + connectivity to the IXP LAN. + + + + + +Durand, et al. Best Current Practice [Page 12] + +RFC 7454 BGP OPSEC February 2015 + + + 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. + + 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. + +6.1.5.2. PMTUD and the Loose uRPF Problem + + 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. + + 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 6.1.2.2.1 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. + + Appendix A gives an example of guidelines regarding IXP LAN prefix. + +6.1.6. The Default Route + +6.1.6.1. IPv4 + + Typically, the 0.0.0.0/0 prefix is not intended to be accepted or + advertised except in specific customer/provider configurations; + general filtering outside of these is RECOMMENDED. + + + + + + +Durand, et al. Best Current Practice [Page 13] + +RFC 7454 BGP OPSEC February 2015 + + +6.1.6.2. 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 + + 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. + +6.2.1. Filters with Internet Peers + +6.2.1.1. 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. + +6.2.1.1.1. 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 prefixes not allocated by IANA (IPv6 only) (Section 6.1.2.1) + + o routes that are too specific (Section 6.1.3) + + o prefixes belonging to the local AS (Section 6.1.4) + + o IXP LAN prefixes (Section 6.1.5) + + o 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 is declared in routing registries + (Section 6.1.2.2). Warning is given as registries are not always + + + +Durand, et al. Best Current Practice [Page 14] + +RFC 7454 BGP OPSEC February 2015 + + + 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 routes that are too specific (Section 6.1.3) + + o prefixes belonging to the local AS (Section 6.1.4) + + o IXP LAN prefixes (Section 6.1.5) + + o the default route (Section 6.1.6) + +6.2.1.2. 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 Routes that are too specific (Section 6.1.3) + + o IXP LAN prefixes (Section 6.1.5) + + o The default route (Section 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. + + + + + +Durand, et al. Best Current Practice [Page 15] + +RFC 7454 BGP OPSEC February 2015 + + +6.2.2. Filters with Customers + +6.2.2.1. 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 6.2.1.1 can be applied. + +6.2.2.2. 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 routes that are too specific (Section 6.1.3) + + o the default route (Section 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.1. 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 6.2.1.1 + with the exception of the default route. Sometimes, the default + + + +Durand, et al. Best Current Practice [Page 16] + +RFC 7454 BGP OPSEC February 2015 + + + 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. + +6.2.3.2. Outbound Filtering + + The filters to be applied would most likely not differ much from the + ones applied for Internet peers (Section 6.2.1.2). 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.1. Inbound Filtering + + 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 routes that are too specific (Section 6.1.3) + + o prefixes belonging to local AS (Section 6.1.4) + + o 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 very straightforward policy: + it will only announce its local routes. It can also configure the + prefix filters described in Section 6.2.1.2 to avoid announcing + invalid routes to its upstream provider. + +7. BGP Route Flap Dampening + + 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 + + + +Durand, et al. Best Current Practice [Page 17] + +RFC 7454 BGP OPSEC February 2015 + + + 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. + +8. Maximum Prefixes on a Peering + + 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 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. + + 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 + + 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 + + + + +Durand, et al. Best Current Practice [Page 18] + +RFC 7454 BGP OPSEC February 2015 + + + 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 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 Network administrators SHOULD NOT advertise prefixes with a + nonempty AS path unless they intend to provide transit for these + prefixes. + + 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 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 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. + + 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. + + + +Durand, et al. Best Current Practice [Page 19] + +RFC 7454 BGP OPSEC February 2015 + + +10. Next-Hop Filtering + + 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). + + 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. + + + + + + + + + +Durand, et al. Best Current Practice [Page 20] + +RFC 7454 BGP OPSEC February 2015 + + +11. BGP Community Scrubbing + + 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 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 + + 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 + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", RFC 2119, March 1997, + <http://www.rfc-editor.org/info/rfc2119>. + + [2] Rekhter,, Y., Li,, T., and S. Hares,, "A Border Gateway + Protocol 4 (BGP-4)", RFC 4271, January 2006, + <http://www.rfc-editor.org/info/rfc4271>. + + [3] Gill, V., Heasley, J., Meyer, D., Savola,, P., and C. + Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC + 5082, October 2007, <http://www.rfc-editor.org/info/rfc5082>. + + + + + + +Durand, et al. Best Current Practice [Page 21] + +RFC 7454 BGP OPSEC February 2015 + + + [4] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication + Option", RFC 5925, June 2010, + <http://www.rfc-editor.org/info/rfc5925>. + + [5] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. + Austein, "BGP Prefix Origin Validation", RFC 6811, January + 2013, <http://www.rfc-editor.org/info/rfc6811>. + + [6] Pelsser, C., Bush, R., Patel, K., Mohapatra, P., and O. + Maennel, "Making Route Flap Damping Usable", RFC 7196, May + 2014, <http://www.rfc-editor.org/info/rfc7196>. + +13.2. Informative References + + [7] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 + Signature Option", RFC 2385, August 1998, + <http://www.rfc-editor.org/info/rfc2385>. + + [8] Ferguson, P. and D. Senie, "Network Ingress Filtering: + Defeating Denial of Service Attacks which employ IP Source + Address Spoofing", RFC 2827, May 2000, + <http://www.rfc-editor.org/info/rfc2827>. + + [9] Baker, F. and P. Savola, "Ingress Filtering for Multihomed + Networks", RFC 3704, March 2004, + <http://www.rfc-editor.org/info/rfc3704>. + + [10] Blunk, L., Damas, J., Parent, F., and A. Robachevsky, "Routing + Policy Specification Language next generation (RPSLng)", RFC + 4012, March 2005, <http://www.rfc-editor.org/info/rfc4012>. + + [11] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the Router + Control Plane", RFC 6192, March 2011, + <http://www.rfc-editor.org/info/rfc6192>. + + [12] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure + Internet Routing", RFC 6480, February 2012, + <http://www.rfc-editor.org/info/rfc6480>. + + [13] Hilliard, N. and D. Freedman, "A Discard Prefix for IPv6", RFC + 6666, August 2012, <http://www.rfc-editor.org/info/rfc6666>. + + [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, <http://www.rfc-editor.org/info/rfc6952>. + + + + + +Durand, et al. Best Current Practice [Page 22] + +RFC 7454 BGP OPSEC February 2015 + + + [15] Bush, R., "Origin Validation Operation Based on the Resource + Public Key Infrastructure (RPKI)", RFC 7115, January 2014, + <http://www.rfc-editor.org/info/rfc7115>. + + [16] Kent, S. and A. Chi, "Threat Model for BGP Path Security", RFC + 7132, February 2014, <http://www.rfc-editor.org/info/rfc7132>. + + [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. + + [18] Karrenberg, D., "RIPE-351 - De-Bogonising New Address Blocks", + October 2005. + + [19] Smith, P. and C. Panigl, "RIPE-378 - RIPE Routing Working Group + Recommendations On Route-flap Damping", May 2006. + + [20] Smith, P., Evans, R., and M. Hughes, "RIPE-399 - RIPE Routing + Working Group Recommendations on Route Aggregation", December + 2006. + + [21] Smith, P. and R. Evans, "RIPE-532 - RIPE Routing Working Group + Recommendations on IPv6 Route Aggregation", November 2011. + + [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. + + [23] IANA, "IANA IPv4 Special-Purpose Address Registry", + <http://www.iana.org/assignments/iana-ipv4-special-registry>. + + [24] IANA, "IANA IPv6 Special-Purpose Address Registry", + <http://www.iana.org/assignments/iana-ipv6-special-registry>. + + [25] IANA, "IANA IPv4 Address Space Registry", + <http://www.iana.org/assignments/ipv4-address-space>. + + [26] IANA, "Internet Protocol Version 6 Address Space", + <http://www.iana.org/assignments/ipv6-address-space>. + + [27] Merit Network Inc., "Merit RADb", <http://www.radb.net>. + + [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. + + + + + +Durand, et al. Best Current Practice [Page 23] + +RFC 7454 BGP OPSEC February 2015 + + + [29] Bellovin, S., Bush, R., and D. Ward, "Security Requirements for + BGP Path Validation", RFC 7353, August 2014, + <http://www.rfc-editor.org/info/rfc7353>. + + [30] "IRRToolSet project page", <http://irrtoolset.isc.org>. + + [31] Cooper, D., Heilman, E., Brogle, K., Reyzin, L., and S. + Goldberg, "On the Risk of Misbehaving RPKI Authorities", + <http://www.cs.bu.edu/~goldbe/papers/hotRPKI.pdf>. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Durand, et al. Best Current Practice [Page 24] + +RFC 7454 BGP OPSEC February 2015 + + +Appendix A. IXP LAN Prefix Filtering - Example + + 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 + + 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. + + 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. + + + + + + + + + + + + + +Durand, et al. Best Current Practice [Page 25] + +RFC 7454 BGP OPSEC February 2015 + + +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 + + + + + + + + + + + + + + + + + + + + + + + + +Durand, et al. Best Current Practice [Page 26] + |