Internet Engineering Task Force J. Haas Internet-Draft J. Scudder Intended status: Standards Track HPE Expires: 7 January 2026 6 July 2025 BGP-4 Path Attribute Filtering Capability draft-haas-idr-path-attribute-filtering-00 Abstract 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 7 January 2026. Copyright Notice Copyright (c) 2025 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 (https://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 Haas & Scudder Expires 7 January 2026 [Page 1] Internet-Draft Path Attribute Filtering July 2025 and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. BGP Path Attribute Filtering Capability . . . . . . . . . . . 3 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. If both eBGP speakers exchange the Path Attribute Filtering capability . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. If only one peer supports the Path Attribute Filtering capability . . . . . . . . . . . . . . . . . . . . . . . 5 4. Selecting supported Path Attributes . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . 6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction A BGP Route (Section 1.1 of [RFC4271]) is a tuple consisting of a set of Path Attributes (Section 5 of [RFC4271]) 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" [I-D.haas-idr-bgp-attribute-escape]. Haas & Scudder Expires 7 January 2026 [Page 2] Internet-Draft Path Attribute Filtering July 2025 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 [RFC5492] 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. 1.1. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. BGP Path Attribute Filtering Capability The BGP Path Attribute Filtering Capability is encoded as follows: * Capability Code of (TBD). * Capability Length of 1..32. * Capability Value contains a bit-string where a bit is set if the underlying BGP Path Attribute is desired to be advertised by this BGP speaker to the remote BGP speaker. Example encoding for Capability Value: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|1|1|1|1|0|1|1|1|0|0|0|0|0|1|1|0|1|1|0|0|0|0|0|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bits are set for Path Attributes: Origin (1), AS_PATH (2), NEXT_HOP (3), MULTI_EXIT_DISCR (4), ATOMIC_AGGREGATE (6), AGGREGATOR (7), COMMUNITIES (8), MP_REACH_NLRI (14), MP_UNREACH_NLRI (15), AS4_PATH (17), AS4_AGGREGATOR (18). Haas & Scudder Expires 7 January 2026 [Page 3] Internet-Draft Path Attribute Filtering July 2025 Figure 1 Bits 1, 2, 3, 6, 7, 14, 15, 17, 18 MUST be set, because support for [RFC4271], [RFC4760], and [RFC6783] procedures are required when this specification is in use. 3. Operation 3.1. If both eBGP speakers exchange the Path Attribute Filtering capability The intersection of the sent and the received Path Attribute Filtering capabilies's bits represents the set of Path Attributes that the BGP speakers are willing to exchange with each other. When both bits for a given Path Attribute Type Code are 1, the Path Attribute is negotiated; otherwise it is not negotiated. Routes with Path Attributes that have been negotiated MAY be exchanged between both BGP speakers, depending on the procedures associated with those Path Attributes. When a Path Attribute has not been negotiated, a BGP speaker MUST NOT send a BGP route that contains a Path Attribute for that Path Attribute Type Code. One strategy to accomplish the above requirement is for the BGP speaker to not advertise BGP routes containing that Path Attribute in question. This might require a withdraw to be sent instead. This is similar to treat-as-withdraw as defined in [RFC7606]. 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 not negotiated Path Attributes when it distributes the route to the remote BGP speaker. This is similar to the Attribute Discard behavior defined in [RFC7606]. 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 a Path Attribute that was not negotiated SHOULD use treat-as-withdraw procedures. Receiving BGP speakers MAY accept the route and discard the not negotiated Path Attribute if permitted to by local configuration. Haas & Scudder Expires 7 January 2026 [Page 4] Internet-Draft Path Attribute Filtering July 2025 3.2. If only one peer supports the Path Attribute Filtering capability When only one BGP speaker supports or sends the Path Attribute Filtering capability that BGP implementation is demonstrating a preference to not receive Path Attributes where the bit representing the Path Attribute Type Code is zero. It is, in fact, representing a filtering policy for routes containing those Path Attributes. BGP speakers sending a Path Attribute Filtering capability but not receiving one from the remote BGP speaker SHOULD filter the routes according to their own locally set and supported bits for the capability, as described in the final paragraph of the previous subsection. 4. Selecting supported Path Attributes Implementations MUST, as described in Figure 1, exchange the required bits covering required core eBGP Path Attributes. Common BGP features that are defined for Internet use SHOULD be included 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 included when that address family is configured. An example of this is the BGP-LS attribute (29) when the BGP-LS feature is in use. Other BGP features desiring eBGP distribution MAY include their bits in the capability when their procedures require it. It is RECOMMENDED that this require explicit configuration to prevent attribute escape. 5. 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. 6. 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. Haas & Scudder Expires 7 January 2026 [Page 5] Internet-Draft Path Attribute Filtering July 2025 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. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 2009, . [RFC6783] Levine, J. and R. Gellens, "Mailing Lists and Non-ASCII Addresses", RFC 6783, DOI 10.17487/RFC6783, November 2012, . [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 7.2. Informative References [I-D.haas-idr-bgp-attribute-escape] Haas, J., "BGP Attribute Escape", Work in Progress, Internet-Draft, draft-haas-idr-bgp-attribute-escape-03, 9 April 2025, . Haas & Scudder Expires 7 January 2026 [Page 6] Internet-Draft Path Attribute Filtering July 2025 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, . Acknowledgements TBD. Contributors TBD. Authors' Addresses Jeffrey Haas HPE 1133 Innovation Way Sunnyvale, CA 94089 United States of America Email: jhaas@juniper.net John Scudder HPE 1133 Innovation Way Sunnyvale, CA 94089 United States of America Email: jgs@juniper.net Haas & Scudder Expires 7 January 2026 [Page 7]