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

BGP Flow Specification (FlowSpec), defined in and , allows for the dissemination of traffic filtering rules. Current FlowSpec components support filtering by destination prefix, source prefix, and various Layer 4 parameters. 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 FlowSpec component that allows operators to use the Destination Origin AS as a matching criterion.

FS: Flow Specification 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 Flow Specification component type that is encoded in the BGP FlowSpec NLRI . Type TBD1 - Destination-IP-Origin-AS Encoding: <type (1 octet), [op, value]+> It contains a set of {operator, value} pairs used to match the Destination-IP-Origin-AS. The operator byte (numeric_op) is encoded as specified in Section 4.2 of :

Where: e - End-of-list bit. Set in the last {op, value} pair in the list. a - AND bit. If unset, the previous term is logically ORed with the current one. If set, the operation is a logical AND. It MUST be unset (0) in the Destination-IP-Origin-AS filter. len - The length of the value field for this operator given as (1 << len). This encodes 1 (len=00), 2 (len=01), 4 (len=10), and 8 (len=11) octets. For 4-byte AS numbers, len MUST be set to 10 (4 octets). lt, gt, eq - Less than, Greater than, and Equal comparison bits. The value field contains a 4-octet Autonomous System Number encoded in network byte order:

As defined in [RFC8955], a strict ordering of components MUST be followed to ensure a deterministic comparison of FlowSpec NLRIs. The Destination-IP-Origin-AS component (Type TBD1) MUST be ordered after Type 2 (Source Prefix) and before Type 3 (IP Protocol). [Note to IANA: The exact numeric order will depend on the assigned Type value.]

When a BGP speaker receives and installs a FlowSpec route containing the Destination-IP-Origin-AS component, 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 FlowSpec rule, the packet matches this component. In multi-homing or multipath scenarios where a destination prefix is reachable via paths with different Origin ASes, the match MUST succeed if ANY valid active path to the destination prefix matches the Origin AS defined in the FlowSpec rule. If a receiving BGP speaker cannot support this new component type, it MUST follow the error handling and component skipping procedures defined in and .

This section describes a representative use case for traffic redirection and rate-limiting using the Destination-IP-Origin-AS filter. Consider the topology shown in Figure 3. 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. Security considerations discussed in and apply directly. In addition, operators MUST consider the following: Routing Inconsistency: Packet classification relies on the local BGP RIB state of the forwarding router. If different ingress routers have different active routes (and thus different Origin AS views) for a destination IP, filtering actions may be applied inconsistently. BGP Origin Validation: Malicious or misconfigured networks may spoof AS_PATH attributes. Operators SHOULD deploy RPKI-based Route Origin Validation (ROV) in their networks to ensure that the Origin AS matching is performed against validated BGP routes. Validation of FlowSpec Routes: BGP FlowSpec routes MUST be validated against origin BGP peers according to the FlowSpec validation rules (Section 6 of ) to prevent cross-administrative-domain traffic hijacking.

IANA is requested to allocate a new component type in the "Flow Spec Component Types" registry defined in :

TBD

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.