Destination-IP-Origin-AS Filter for BGP Flow Specification

BGP Flow Specification, originally defined in and , 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 certain DDoS mitigation and traffic engineering scenarios, an operator may need to apply rate-limiting, redirection, or filtering to traffic destined for a particular network (Autonomous System), even when the specific target IP prefixes within that AS are numerous or rapidly changing. Manually updating hundreds of prefix-based FlowSpec rules is inefficient and consumes significant Hardware Forwarding Information Base (FIB) / TCAM resources. This document introduces a new FSv2 component under the Routing Filter Family that allows operators to use the Destination Origin AS as a matching criterion.

FSv2: Flow Specification Version 2 Destination-IP-Origin-AS: The origin AS number of the destination IP address, determined from the rightmost AS in the AS_PATH attribute of the matching BGP route.

This document proposes 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: 100 (DIP-AS) Encoding format for the DIP-AS component:

| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]> Where: Flags (4 bits): Defined in FSv2 specifications. Type (12 bits): Set to 100 for DIP-AS. Length (16 bits): Length of the value field in octets. <[numeric_op, Destination-IP-Origin-AS]+>: Contains a list of {numeric_op, Destination-IP-Origin-AS} pairs that are used to match the Destination-IP-Origin-AS. numeric_op: This component uses the Numeric Operator (numeric_op) described in Section 4.1.1 of , Type 100 component values SHOULD be encoded as 4 octets (numeric_op len=10). Destination-IP-Origin-AS (32 bits): A 4-octet Autonomous System Number encoded in network byte order.

As defined in , rules and components follow strict ordering principles. The DIP-AS component (Type 100) within the Routing Filter Family (1400) MUST be evaluated deterministically according to FSv2 component sequencing rules.

When a BGP speaker receives and installs an FSv2 route containing the Routing Filter Family with the DIP-AS component (Type 100), the matching process for a transit data packet MUST proceed as follows: The router extracts the packet's Destination IP address. The router performs a longest-prefix match (LPM) lookup for the Destination IP in its local BGP Loc-RIB / FIB to retrieve the associated active BGP route. The router evaluates the AS_PATH attribute of the retrieved BGP route: The Origin AS is defined as the rightmost AS number in the AS_SEQUENCE segment of the AS_PATH. If the AS_PATH ends with an AS_SET or AS_CONFED_SEQUENCE, the match fails unless all ASes in the set match, or the implementation supports evaluating each AS in the AS_SET against the filter. If the evaluated Origin AS matches the criterion in the FSv2 rule, the packet matches this component. In multi-homing or multipath scenarios, the match succeeds if ANY valid active path to the destination prefix matches the Origin AS defined in the rule.

This section describes a representative use case for traffic redirection and rate-limiting using the Destination-IP-Origin-AS filter under the FSv2 framework. Consider the topology shown in . ISP AS64597 receives traffic from AS64596 (Source IP Prefix 61) destined for AS64598.

Using traditional FlowSpec (RFC 8955), if AS64598 announces dozens or hundreds of individual prefixes (Prefix 81, 82, 83, 84...), AS64597 must inject separate FlowSpec rules for each destination prefix to redirect traffic coming from Source IP Prefix 61 towards Router R3:

Using the extension defined in this draft, the BGP FlowSpec Server needs to generate only a single FlowSpec rule:

This significantly reduces BGP NLRI messaging overhead, control plane churn, and hardware FIB/TCAM entry consumption on network elements.

This document extends BGP FlowSpec Version 2 (FSv2). Security considerations discussed in apply directly. In addition, operators MUST consider routing inconsistencies, RPKI-based Route Origin Validation (ROV) [RFC6811], and FSv2 route validation procedures.

IANA is requested to make the following allocations under the BGP Flow Specification Version 2 (FSv2) registries defined in :

The following people made significant contributions to this document:

The authors would like to acknowledge the review and inputs from Gang Yan, Robert Raszuk, Jeffray Haas, Linda Dunbar, Zhenbin Li, Rainbow Wu, Jie Dong and Ziqing Cao.