Source-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 scenarios, an operator may need to apply rate-limiting, redirection, or filtering to traffic sourced from a particular network (Autonomous System), even when the specific source IP prefixes within that AS are numerous or rapidly changing. Manually updating hundreds of prefix-based FlowSpec rules is inefficient and consumes excessive Hardware Forwarding Information Base (FIB) / TCAM resources. This document introduces a new FlowSpec component that allows operators to use the Source Origin AS as a matching criterion.

FS: Flow Specification Source-IP-Origin-AS: The origin AS number associated with the source IP address of a transit packet, determined from the rightmost AS in the AS_PATH attribute of the active BGP route matching that source IP.

This document proposes a new Flow Specification component type that is encoded in the BGP FlowSpec NLRI . Type TBD1 - Source-IP-Origin-AS Encoding: <type (1 octet), [op, value]+> It contains a set of {operator, value} pairs used to match the Source-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 Source-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 , a strict ordering of components MUST be followed to ensure a deterministic comparison of FlowSpec NLRIs. The Source-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 Source-IP-Origin-AS component, the matching process for a transit data packet MUST proceed as follows: The router extracts the packet's Source IP address. The router performs a longest-prefix match (LPM) lookup for the Source 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 source prefix is reachable via paths with different Origin ASes, the match MUST succeed if ANY valid active path for the source 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 Section 10 of and .

This section describes how to use this function in a simple scenario. Consider the topology shown in Figure 3. Router R2 in AS64597 receives traffic originating from AS64598 destined for IP Prefix 61. The operator wants to redirect all traffic originating from AS64598 towards Router R3 before forwarding it to IP Prefix 61.

Using the traditional method, ISP AS64597 must inject multiple "Destination Prefix + Source Prefix" FlowSpec rules into Router R2:

Using the method defined in this draft, ISP AS64597 needs to inject only a single "Destination Prefix + Source IP Origin AS" FlowSpec rule:

This method saves significant TCAM space on network elements, reduces BGP UPDATE messaging load on the control plane, and simplifies operational management when a source AS advertises numerous dynamic prefixes.

In addition to the security considerations in and , operators MUST be aware of the following: Routing Inconsistency: Packet classification relies on the local BGP RIB state of the forwarding router. If different ingress routers have different active BGP routes (and thus different Origin AS views) for a given source IP, filtering or redirection 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 Source Origin AS matching is performed against validated BGP routes. Validation of FlowSpec Routes: BGP FlowSpec routes MUST be validated against originating 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