BGP-4 Path Attribute Filtering Capability

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 22 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 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

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

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.¶

2. 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 [RFC4271], [RFC4760], and [RFC6793] 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.¶

3. 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 [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 unwanted 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 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.¶

4. Selecting supported Path Attributes

Implementations MUST, as described in Figure 1, 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.¶

5. 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.¶

6. 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.¶

7. 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.¶

8. 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.¶

Acknowledgements

TBD.¶

References

Authors' Addresses