Source-IP-Community Filter for BGP Flow Specification

BGP Flow Specification, originally defined in , has evolved to Flow Specification Version 2 (FSv2) as specified in . FSv2 introduces an extensible, TLV-based filter family architecture with explicit rule ordering and modular components. 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 FSv2 component type under the Routing Filter Family, Source-IP-Community (SIP COM), 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.

FSv2: Flow Specification Version 2 Source-IP-Community: The BGP Community (Standard, Extended, or Large) associated with the BGP route that best matches the source IP address of the incoming packet.

This document defines a new FSv2 component encoded within the Routing Filter Family (Type 1400). Unlike legacy FSv1 raw byte streams, FSv2 utilizes explicit TLV formatting. Filter Family: 1400 (Routing Filter Family) Component Type: 400 (SIP COM) Encoding format for the SIP COM component:

| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]> Where: Flags (4 bits): Defined in FSv2 specifications. Type (12 bits): Set to 400 for SIP COM. Length (16 bits): Length of the value field in octets. <[numeric_op, Source-IP-Community]+>: Contains a list of {numeric_op, Source-IP-Community} pairs that are used to match the Source-IP-Community. numeric_op: This component uses the Numeric Operator (numeric_op) described in Section 4.1.1 of , Type 400 component values SHOULD be encoded as 4 octets (numeric_op len=10). Source-IP-Community (32 bits): BGP Community value to match.

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 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: FIB Entry for Source Prefix A: Tagged with Community 64597:1 FIB Entry for Source Prefix B: Tagged with Community 64597:2 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 . 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: Match Condition: Destination Prefix = IP Prefix 61, Source-IP-Community = 64597:1 Action: Redirect to R3 (IP Nexthop of R3) When R2 receives a packet with Source IP = Prefix 81 and Destination IP = Prefix 61: R2 checks the Flowspec rule. R2 queries its FIB using Source IP (Prefix 81) and retrieves the stored Community value (64597:1). Since the retrieved Community (64597:1) matches the rule's Source-IP-Community parameter (64597:1), the rule is triggered, and the packet is redirected to R3.

Using traditional BGP-FS, AS64597 must inject explicit rules pairing each Source Prefix with Destination Prefix 61:

With the Source-IP-Community filter defined in this document, AS64597 only needs to advertise a single Flowspec rule on Router R2:

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 make the following allocations under the BGP Flow Specification Version 2 (FSv2) registries defined in :

This proposal extends BGP Flow Specification Version 2 (FSv2) matching capabilities. All security considerations defined in 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.

The following people made significant contributions to this document: TBA