| Internet-Draft | Source-IP-Community Filter | August 2026 |
| Wu, et al. | Expires 4 March 2027 | [Page] |
BGP Flow Specification (BGP-FS) propagates traffic Flow Specifications and Traffic Filtering Actions using BGP NLRI and BGP Extended Community encodings. This document specifies a new BGP-FS component type to support community-level filtering within a single administrative domain. The match condition filters traffic based on the BGP Community attributes associated with the route matching the packet's source IP address.¶
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.¶
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 4 March 2027.¶
Copyright (c) 2026 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.¶
BGP Flow Specification (BGP-FS) [RFC8955] [RFC8956] defines a BGP NLRI format to distribute traffic flow specification rules. A BGP- FS policy consists of match conditions (an n-tuple match) and actions that filter, rate-limit, or redirect packets. By leveraging BGP, filter rules can be disseminated to peers simultaneously without requiring manual router reconfigurations.¶
In large-scale networks, operators frequently group ingress traffic by assigning BGP Communities to the advertised source prefixes. When implementing edge filtering or traffic redirection based on source origins, defining rules using individual Source IP Prefixes leads to NLRI bloat and forwarding table scale issues.¶
This document specifies a new BGP-FS component type, Source-IP- Community, to support community-level traffic filtering. Rather than matching a raw field in the IP header, this component matches the BGP Community attribute associated with the Locating Route (or RIB/FIB entry) corresponding to the packet's Source IP address. This mechanism is intended for deployment within a single administrative domain.¶
This document defines a new Flow Specification component type encoded within the BGP-FS NLRI:¶
Type TBD1 - Source-IP-Community¶
Encoding: <type (1 octet), [op, value]+>¶
This component contains a set of {operator, value} pairs used to match the Source-IP-Community.¶
The operator byte (numeric_op) is encoded as defined in Section 4.2.1 of [RFC8955]:¶
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| e | a | len | 0 |lt |gt |eq |
+---+---+---+---+---+---+---+---+
Where:¶
e - End-of-list bit. Set in the last {op, value} pair.¶
a - AND bit. If unset, the logical operation with the previous term is OR. If set, the operation is AND. For the Source-IP-Community filter, the 'a' bit MUST be unset (0) unless matching multi-value community sets.¶
len - Length of the value field encoded as (1 << len). Valid lengths for Standard BGP Communities [RFC1997] are 4 octets (len=10). Future extensions MAY support 8 octets (Extended) or 12 octets (Large Communities).¶
lt, gt, eq - Less than, Greater than, and Equality comparison bits.¶
The value field contains the BGP Community value to match:¶
0 1 2 3 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 5 6 7 8 9 0 1 +---------------------------------------------------------------+ ~ Source-IP-Community (4 octets) ~ +---------------------------------------------------------------+
If a receiving BGP speaker does not support this component type, it MUST handle the unknown component in accordance with Section 10 of [RFC8955] (i.e., treating the NLRI as unparseable or handling it per the extended error handling rules).¶
The implementation of Source-IP-Community filtering relies on a cross-coupling mechanism between the Unicast BGP Forwarding Table (FIB) and the Flowspec Packet Inspection Engine. The detailed processing workflow is defined in the following three steps:¶
Control-Plane Community Dissemination and FIB Tagging: When a BGP speaker receives unicast BGP routes carrying BGP Communities (e.g., Standard, Extended, or Large Communities), and those routes are selected as best paths and installed into the Forwarding Information Base (FIB), the local system MUST preserve the associated BGP Community attributes (or a local mapped metadata tag representing the Community) within the corresponding FIB entries. For example:¶
Flowspec Rule Installation: When a BGP Flowspec rule containing the Source-IP-Community component is received, the system programs a filtering rule into the forwarding hardware. The match parameters include both standard RFC 8955/8956 n-tuples (e.g., Destination IP, Source IP, Protocol, Port) and the target Community value specified in the Source-IP-Community component (denoted as COMM_Rule, e.g., 64597:1).¶
Datapath Two-Stage Packet Matching:¶
Upon receiving a data packet:¶
The device evaluates the packet against installed Flowspec rules.¶
If a candidate rule contains a Source-IP-Community match condition, the forwarding engine performs a FIB lookup using the packet's Source IP address to extract the associated FIB entry's Community attribute (denoted as COMM_FIB).¶
Evaluation:¶
If COMM_FIB matches COMM_Rule (e.g., both are 64597:1), the Source-IP-Community match condition is satisfied, and the configured Flowspec action (e.g., redirect, drop, rate-limit) is executed.¶
If COMM_FIB does not match COMM_Rule (e.g., COMM_FIB is 64597:2 while COMM_Rule is 64597:1), the match condition fails, and packet processing continues to subsequent rules or default forwarding.¶
Consider the topology shown in Figure 3. An operator in AS64597 wants to redirect all traffic originating from AS64598 (whose source prefixes are tagged with BGP Community 64597:1) towards Destination IP Prefix 61, forcing the traffic to be routed via Router R3.¶
Operational Steps:¶
Router R2 receives routes for IP Prefixes 81, 82, 83, and 84 with Community 64597:1 from AS64598. When R2 populates its FIB, it stores the Community value (64597:1) along with each source prefix entry.¶
The BGP FS Server issues a single Flowspec rule to Router R2:¶
When R2 receives a packet with Source IP = Prefix 81 and Destination IP = Prefix 61:¶
+---------+
| BGP FS |
| Server |
+----|----+
|
|
+
\
****************\******** IP Prefix 81 w/ Comm 64597:1
* \ * IP Prefix 82 w/ Comm 64597:1
IP Prefix 61 * AS64597 \ * IP Prefix 83 w/ Comm 64597:1
* \ * IP Prefix 84 w/ Comm 64597:1
+-------+ * +---+ +--\+ * +-------+
+AS64596+-------+ R1+---------+ R2|------+AS64598+
+-------+ * +-+-+\ +---+ */ +-------+
* \ |\ /
* \ | \ /* IP Prefix 91 w/ Comm 64597:2
* \ | /\* IP Prefix 92 w/ Comm 64597:2
* \ | / \ IP Prefix 93 w/ Comm 64597:2
* \ |/ *\ IP Prefix 94 w/ Comm 64597:2
* \ +-+-+ * \ +-------+
* \-+ R3+------+AS64599+
* +---+ * +-------+
* *
*************************
Using traditional BGP-FS, AS64597 must inject explicit rules pairing each Source Prefix with Destination Prefix 61:¶
+--------------+--------------+-------------------------+
| source | Destination | Redirect to IP Nexthop |
| Prefix | Prefix | |
+--------------+--------------+-------------------------+
| IP Prefix 81 | IP Prefix 61 | R3 |
+--------------+--------------+-------------------------+
| IP Prefix 82 | IP Prefix 61 | R3 |
+--------------+--------------+-------------------------+
| IP Prefix 83 | IP Prefix 61 | R3 |
+--------------+--------------+-------------------------+
| IP Prefix 84 | IP Prefix 61 | R3 |
| More ... |
+--------------+--------------+-------------------------+
With the Source-IP-Community filter defined in this document, AS64597 only needs to advertise a single Flowspec rule on Router R2:¶
+--------------+--------------+-------------------------+ | Source | Destination | Redirect to IP Nexthop | | Community | Prefix | | +--------------+--------------+-------------------------+ | 64597:1 | IP Prefix 61 | R3 | +--------------+--------------+-------------------------+
Compared to traditional methods requiring N rules for N source prefixes, this community-based FIB lookup mechanism reduces the required Flowspec rules in the control plane and hardware TCAM to a single entry.¶
IANA is requested to allocate a new component type in the "Flow Spec Component Types" registry:¶
+---------+-----------------------+------------------+
| Type | Description | Reference |
+---------+-----------------------+------------------+
| TBD1 | Source-IP-Community | This-Document |
+---------+-----------------------+------------------+
¶
This proposal extends BGP Flow Specification matching capabilities. All security considerations defined in [RFC8955] and [RFC8956] apply.¶
Because matching relies on the BGP Community attribute of the route associated with a packet's source IP address, malicious or inaccurate community tagging within the local BGP RIB could result in incorrect packet filtering or traffic redirection. Therefore, this mechanism MUST be restricted to deployment within a single administrative domain where Community management is strictly controlled.¶
Additionally, lookups linking dynamic packet source IP addresses to BGP route attributes MUST be implemented efficiently to mitigate potential Data Plane Resource Exhaustion (DoS) attacks.¶