BEST CURRENT PRACTICE

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 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 1 . Introduction 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 RFC 2119 [1]. 2 . Scope of the Document 3 . Definitions and Acronyms Durand, et al. Best Current Practice [Page 4]

RFC 7454 BGP OPSEC February 2015 5 . Protection of BGP Sessions 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 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) 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 6 . Prefix Filtering Section 9) or any other attributes of a BGP prefix (for example, BGP communities, as described in Section 11). 6.1 . Definition of Prefix Filters 6.1.1 . Special-Purpose Prefixes 6.1.1.1 . IPv4 Special-Purpose Prefixes 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 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 6.1.2.1 . IANA-Allocated Prefix Filters 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 6.1.2.2.1 . Prefix Filters Created from Internet Routing Registries 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 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 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 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 20] [21]. These values may change in the future. 6.1.4 . Filtering Prefixes Belonging to the Local AS and Downstreams 6.1.5 . IXP LAN Prefixes 6.1.5.1 . Network Security Durand, et al. Best Current Practice [Page 12]

RFC 7454 BGP OPSEC February 2015 6.1.5.2 . PMTUD and the Loose uRPF Problem 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 Durand, et al. Best Current Practice [Page 13]

RFC 7454 BGP OPSEC February 2015 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 9 . AS Path Filtering Durand, et al. Best Current Practice [Page 18]

RFC 7454 BGP OPSEC February 2015 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 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 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 Appendix A . IXP LAN Prefix Filtering - Example 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]