]> HPE

1133 Innovation Way Sunnyvale CA 94089 United States of America jhaas@juniper.net

HPE

1133 Innovation Way Sunnyvale CA 94089 United States of America jgs@juniper.net

RTG idr Path Attributes in the BGP-4 protocol (RFC 4271) carry data associated with BGP routes. Many of the Path Attributes carried in BGP are intended for limited scope deployment. However, the extension mechanism defined by BGP that carries these attributes often carries them farther than necessary, sometimes with unfortunate results. This document defines a mechanism using BGP Capabilities (RFC 5492) that permits eBGP speakers to determine what Path Attributes should be permitted to cross external BGP routing boundaries.

Introduction A BGP Route (Section 1.1 of ) is a tuple consisting of a set of Path Attributes (Section 5 of ) and sets of network reachability carried as Network Layer Reachability Information (NLRI). Some of these Path Attributes are defined as part of the core BGP-4 protocol. Path Attributes are the main extension mechanism defined by BGP, and may be scoped as "transitive" or "non- transitive." Non-Transitive Path Attributes require the BGP speaker to understand the attribute in order to determine if it will be locally used and perhaps later propagated to additional BGP speakers. Unrecognized non-transitive Path Attributes are discarded by the receiving BGP speaker. Transitive Path Attributes, when not understood by the receiving BGP speaker, are required to be propagated to other BGP speakers. Some Path Attributes defined by BGP extensions are intended to be used in limited scopes, such as a single BGP Autonomous System (AS). When such attributes are distributed beyond the expected scope, this is called an "Attribute Escape" . Such attribute escapes may lead to improper BGP protocol behavior when received outside of their expected scope, and may lead to incorrect forwarding, or be a serious security consideration. This document defines a mechanism exchanged through BGP Capabilities where BGP speakers can more appropriately scope both Path Attributes to prevent escape, and to limit the distribution of routes that carry escaped Path Attributes.

Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

BGP Path Attribute Filtering Capability The BGP Path Attribute Filtering Capability is encoded as follows: Capability Code of (TBD). Capability Length of 0..32 octets. Capability Value contains a bit-string padded to an octet boundary where a bit is set if this BGP speaker considers the corresponding BGP Path Attribute from the remote BGP speaker to be unwanted.

Bits 1, 2, 3, 6, 7, 14, 15, 17, 18 MUST be clear (value 0), because support for , , and procedures are required when this specification is in use. Any bit not explicitly represented (e.g., bits 24 and beyond in the above example) is deemed to be clear (value 0). That is, the default is to accept any path attribute not explicitly unwanted.

Operation A clear (value 0) bit in the Path Attribute Filtering capability indicates that the BGP speaker advertising it is willing to accept the corresponding Path Attribute and will process it according to the normal rules of the BGP protocol and the attribute in question. A set (value 1) bit in the Path Attribute Filtering capability indicates that the BGP speaker advertising it is not willing to accept the corresponding Path Attribute. We refer to such Path Attributes as "unwanted Path Attributes". A BGP speaker MUST NOT send an unwanted Path Attribute to its peer. (Of course, this expectation will be met only by BGP speakers that support this specification; therefore a BGP speaker that implements this specification SHOULD be prepared for the possibility it will receive unwanted Path Attributes; this is discussed below.) One strategy to accomplish the above requirement is for the BGP speaker to not advertise BGP routes containing the unwanted Path Attribute in question. This might require a withdraw to be sent instead. This is similar to treat-as-withdraw as defined in . Another strategy that could be used, when appropriate for the procedure covering a given BGP Path Attribute, is for the BGP speaker to remove the unwanted Path Attributes when it distributes the route to the remote BGP speaker. This is similar to the Attribute Discard behavior defined in . Receiving BGP speakers SHOULD filter routes or discard unwanted Path Attributes if they are incorrectly sent by the remote BGP speaker. Minimally, a receiving BGP speaker receiving an unwanted Path Attribute SHOULD use treat-as-withdraw procedures. Receiving BGP speakers MAY accept the route and discard the unwanted Path Attribute if permitted to by local configuration.

Selecting supported Path Attributes Implementations MUST, as described in , clear the bits covering required core eBGP Path Attributes. Common BGP features that are defined for Internet use SHOULD be clear by default between two BGP speakers. These include: Communities (8) Extended Communities (16) Large BGP Communities (32) BGPsec_Path (33) Only To Customer (OTC) (35) BGP features required to support a given AFI/SAFI MUST also be clear when that address family is configured. An example of this is the BGP-LS attribute (29) when the BGP-LS feature is in use.

Operational Considerations The feature described in this document does not change the semantics of when a Path Attribute is intended to be transitive per RFC-4271 definition. However, it does act as a policy to limit the distribution of routes containing a transitive Path Attribute, or may cause that attribute to be filtered. eBGP speakers using this features must be cognizant of the impact their filtering policies will have on the incremental deployment of new BGP features.

IANA Considerations This document requests a new BGP Capability Code to be allocated from the First Come First Served range of the Capability Codes registry.

Security Considerations The motivation for this feature is to attempt to address the numerous BGP security implications where BGP Path Attributes propagate beyond their intended scope. The definition of a feature that limits the distribution of BGP Path Attributes unfortunately moves BGP's default behavior away from "distribute unknown things easily" and thus hampers incremental deployment of new features. However, operators have already begun indiscriminate filtering of Path Attributes they do not themselves require. This feature attempts to provide a more flexible negotiated mode to permit such filtering while at the same time not completely precluding incremental deployment of new features.

Recommendations for Filtering Path Attributes BGP Path Attributes that are in the table below have a suggested default filtering behavior. It is recommended that they should not be filtered by default. Is is not recommended that BGP Path Attributes that are deprecated should be filtered by default. This permits their long term reassignment and re-use. Operators with a strong filtering policy may consider filtering these to block routes from older implementations of these features that may still be deployed. Code Point Name Should Filter By Default 0 Reserved Yes 1 ORIGIN [RFC4271] Never 2 AS_PATH [RFC4271] Never 3 NEXT_HOP [RFC4271] Never 4 MULTI_EXIT_DISC [RFC4271] No 5 LOCAL_PREF [RFC4271] Yes 6 ATOMIC_AGGREGATE [RFC4271] No 7 AGGREGATOR [RFC4271] No 8 COMMUNITIES [RFC1997] No 9 ORIGINATOR_ID [RFC4456] Yes 10 CLUSTER_LIST [RFC4456] Yes 11 DPA (deprecated) [RFC6938] - 12 ADVERTISER (historic) (deprecated) [RFC1863][RFC4223][RFC6938] - 13 RCID_PATH / CLUSTER_ID (Historic) (deprecated) [RFC1863][RFC4223][RFC6938] - 14 MP_REACH_NLRI [RFC4760] Never 15 MP_UNREACH_NLRI [RFC4760] Never 16 EXTENDED COMMUNITIES [Eric_Rosen][draft-ramachandra-bgp-ext-communities-00][RFC4360] No 17 AS4_PATH [RFC6793] Never 18 AS4_AGGREGATOR [RFC6793] Never 19 SAFI Specific Attribute (SSA) (deprecated) [Gargi_Nalawade][draft-kapoor-nalawade-idr-bgp-ssa-00][draft-nalawade-idr-mdt-safi-00][draft-wijnands-mt-discovery-00] - 20 Connector Attribute (deprecated) [RFC6037] - 21 AS_PATHLIMIT (deprecated) [draft-ietf-idr-as-pathlimit-02] - 22 PMSI_TUNNEL [RFC6514] Yes 23 Tunnel Encapsulation [RFC9012] Yes 24 Traffic Engineering [RFC5543] Yes 25 IPv6 Address Specific Extended Community [RFC5701] No 26 AIGP [RFC7311] Yes 27 PE Distinguisher Labels [RFC6514] Yes 28 BGP Entropy Label Capability Attribute (deprecated) [RFC6790][RFC7447] - 29 BGP-LS Attribute [RFC9552] Yes 30 Deprecated [RFC8093] - 31 Deprecated [RFC8093] - 32 LARGE_COMMUNITY [RFC8092] No 33 BGPsec_Path [RFC8205] Never 34 BGP Community Container Attribute (TEMPORARY - registered 2017-07-28, extension registered 2024-08-22, expires 2025-07-28) [draft-ietf-idr-wide-bgp-communities-11] No 35 Only to Customer (OTC) [RFC9234] Never 36 BGP Domain Path (D-PATH) (TEMPORARY - registered 2019-07-08, extension registered 2025-06-06, expires 2026-07-08) [draft-ietf-bess-evpn-ipvpn-interworking-10] Yes 37 SFP attribute [RFC9015] Yes 38 BFD Discriminator [RFC9026] Yes 39 BGP Next Hop Dependent Capabilities (NHC) (TEMPORARY - registered 2022-12-20, extension registered 2024-12-10, expires 2025-12-20) [draft-ietf-idr-entropy-label-13] Yes 40 BGP Prefix-SID [RFC8669] Yes 41 BIER [RFC9793] Yes 42 Edge Metadata Path Attribute (TEMPORARY - registered 2025-04-23, expires 2026-04-23) [draft-ietf-idr-5g-edge-service-metadata-27] Yes 128 ATTR_SET [RFC6368] Yes 129 Deprecated [RFC8093] - 241 Deprecated [RFC8093] - 242 Deprecated [RFC8093] - 243 Deprecated [RFC8093] - 255 Reserved for development [RFC2042] Yes

Acknowledgements TBD.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 1771. [STANDARDS-TRACK] This document defines an Optional Parameter, called Capabilities, that is expected to facilitate the introduction of new capabilities in the Border Gateway Protocol (BGP) by providing graceful capability advertisement without requiring that BGP peering be terminated. This document obsoletes RFC 3392. [STANDARDS-TRACK] The Autonomous System number is encoded as a two-octet entity in the base BGP specification. This document describes extensions to BGP to carry the Autonomous System numbers as four-octet entities. This document obsoletes RFC 4893 and updates RFC 4271. [STANDARDS-TRACK] According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable because a session reset would impact not only routes with the offending attribute but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for a number of existing attributes. This document updates error handling for RFCs 1997, 4271, 4360, 4456, 4760, 5543, 5701, and 6368. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Juniper Networks BGP-4 [RFC 4271] has been very successful in being extended over the years it has been deployed. A significant part of that success is due to its ability to incrementally add new features to its Path Attributes when they are marked "optional transitive". Implementations that are ignorant of a feature for an unknown Path Attribute that are so marked will propagate BGP routes with such attributes. Unfortunately, this blind propagation of unknown Path Attributes may happen for features that are intended to be used in a limited scope. When such Path Attributes inadvertently are carried beyond that scope, it can lead to things such as unintended disclosure of sensitive information, or cause improper routing. In their worst cases, such propagation may be for malformed Path Attributes and lead to BGP session resets or crashes. This document calls such inadvertent propagation of BGP Path Attributes, "attribute escape". This document further describes some of the scenarios that leads to this behavior and makes recommendations on practices that may limit its impact. This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, etc.). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. [STANDARDS-TRACK]