Dissemination of Flow Specification Rules
obsoletes
- rfc-5575 — Dissemination of Flow Specification Rules
- rfc-7674 — Clarification of the Flowspec Redirect Extended Community
updated by
Extracted elements (34)
All Traffic Filtering Action Extended Communities are defined as transitive, correcting RFC 5575 which left traffic-rate as non-transitive and left the transitivity of other actions undefined. Transitive communities allow actions to propagate appropriately across AS boundaries.
BGP was chosen as the carrier for Flow Specification dissemination because it allows reuse of existing internal route distribution infrastructure (route reflectors, confederation design) and existing external BGP sessions, providing an incremental addition to already-deployed mechanisms rather than requiring a new protocol.
The validation procedure ties Flow Specification acceptance to the originator of the best-match unicast route (Section 6) because the neighboring AS that advertises the best unicast route for a destination is effectively the traffic's immediate destination; if it requests drops, that cannot constitute a self-inflicted denial of service.
The ICMP Type (Type 7) and ICMP Code (Type 8) components never match when the IP protocol is not 1 (ICMP), when the packet is a non-first fragment, or when the transport header cannot be located. Implementations may or may not decode the transport header in the presence of IP options or ESP NULL encryption.
The Port (Type 4), Destination Port (Type 5), and Source Port (Type 6) components never match when the packet's IP protocol is not 6 (TCP) or 17 (UDP), when the packet is a non-first fragment, or when the system cannot locate the transport header.
The TCP Flags (Type 9) component never matches when the IP protocol is not 6 (TCP), when the packet is a non-first fragment, or when the transport header cannot be located. When a 2-octet bitmask is used, the leftmost 4 bits (data offset) are always treated as 0.
An NLRI value not encoded as specified, including one containing an unknown component type, is considered malformed and error handling according to Section 10 (RFC 7606) is performed.
BGP implementations MUST enforce that the AS_PATH of a route received via eBGP contains the neighboring AS in the left-most position. This rule is made mandatory here for security reasons.
Flow Specification components MUST follow strict type ordering by increasing numerical order. A given component type MAY appear exactly once and MUST precede any component of higher numeric type value.
For traffic-rate-bytes and traffic-rate-packets Extended Communities, the floating-point rate value MUST NOT be negative on encoding; on decoding, negative values MUST be treated as zero (discard all traffic for the flow).
Implementations wishing to exchange Flow Specifications MUST use BGP's Capability Advertisement facility to exchange the Multiprotocol Extension Capability Code (Code 1). The (AFI, SAFI) pair MUST be (AFI=1, SAFI=133) for IPv4 Flow Specification and (AFI=1, SAFI=134) for VPNv4 Flow Specification.
In the absence of explicit configuration, a Flow Specification NLRI MUST be validated as feasible if and only if: (a) a destination prefix component is present, (b) the originator of the Flow Specification matches the originator of the best-match unicast route, and (c) there are no more-specific unicast routes from a different neighboring AS.
In the first operator octet of a sequence, the AND bit (a) MUST be encoded as unset and MUST be treated as always unset on decoding. The reserved zero bit MUST be set to 0 on NLRI encoding and MUST be ignored during decoding.
The best-match unicast route may change independently of the Flow Specification NLRI. Therefore, a revalidation of the Flow Specification NLRI MUST be performed whenever unicast routes change.
When advertising Flow Specifications, the Length of the Next-Hop Network Address MUST be set to 0 and the Network Address of the Next-Hop field MUST be ignored.
A Flow Specification NLRI is an ordered list of components of the form <[component]+>, where each component begins with a 1-octet type field. A packet matches the Flow Specification only when it matches the logical AND of all components present.
Flow Specification ordering for conflict resolution compares components left-to-right by type number; lower type number has higher precedence. For IP prefixes, more-specific prefixes have higher precedence; for all other types, binary memcmp() ordering is used with longer strings having higher precedence when common prefixes are equal.
The default Traffic Filtering Action for a matching Flow Specification is to accept the packet (normal forwarding). All Traffic Filtering Actions are specified as transitive BGP Extended Communities.
The rt-redirect Extended Community (sub-type 0x08) supports three encoding formats: 0x8008 (2-octet AS, 4-octet value), 0x8108 (4-octet IPv4, 2-octet value), 0x8208 (4-octet AS, 2-octet value), redirecting matching traffic to the VRF whose import policy lists the specified route-target.
Twelve component types are defined for IPv4: Type 1 (Destination Prefix), Type 2 (Source Prefix), Type 3 (IP Protocol), Type 4 (Port), Type 5 (Destination Port), Type 6 (Source Port), Type 7 (ICMP Type), Type 8 (ICMP Code), Type 9 (TCP Flags), Type 10 (Packet Length), Type 11 (DSCP), and Type 12 (Fragment).
IANA maintains registries for Extended Community Flow Specification Actions sub-types: 0x06 (traffic-rate-bytes), 0x0c (traffic-rate-packets), 0x07 (traffic-action), 0x08 (rt-redirect in three format variants), and 0x09 (traffic-remarking/marking). A separate 'Traffic Action Fields' registry covers bits 47 (Terminal Action) and 46 (Sample) of the traffic-action community.
IANA maintains the 'Flow Spec Component Types' registry with 8-bit type values; types 1-12 are defined by RFC 8955. The allocation policy is: 0 reserved, 1-127 Specification Required, 128-254 Expert Review, 255 reserved.
IANA maintains the 'SAFI Values' registry; this document assigns SAFI 133 ('Dissemination of Flow Specification rules') and SAFI 134 ('L3VPN Dissemination of Flow Specification rules'), both referencing RFC 8955.
Flow Specification BGP speakers (e.g., automated DDoS controllers) that are improperly programmed or rogue may announce unintended Flow Specifications, send updates at a high rate, or generate a large number of specifications, potentially stressing receiving systems or exceeding their capacity. Service providers need to consider device capacity and may need to limit accepted Flow Specifications.
Non-traffic-rate actions (rt-redirect, traffic-marking) may allow a third party to modify packet forwarding and gain access to other routing tables or VPNs. Operators SHOULD filter Traffic Filtering Action communities at network borders and expose only a predefined subset to third parties, or map user-defined communities to internal actions rather than accepting action communities from third parties.
The security properties of Flow Specification are equivalent to BGP unicast routing only as long as the validation procedure (Section 6) is enforced. Any relaxation may allow unwanted Flow Specifications to propagate, enabling denial-of-service via unwanted traffic filtering, remarking, or redirection. Specifications relaxing validation MUST include security considerations detailing required additional filtering.
The Bitmask Operator (bitmask_op) is a 1-octet field sharing the e, a, len, and two zero bits from numeric_op, but uses a NOT bit and a Match (m) bit instead of lt/gt/eq. When m=1, the match is '(data AND value) == value'; when m=0, any bit in the value mask being set in data evaluates to TRUE.
The Flow Specification NLRI length field uses variable-length encoding: if the NLRI length is less than 240 octets it is encoded as a single octet (0xnn); otherwise it is encoded as a 2-octet extended-length value where the most significant nibble is 0xf (0xfnnn), supporting lengths up to 4095 octets.
The Numeric Operator (numeric_op) is a 1-octet field with bits: e (end-of-list), a (AND), len (2 bits encoding value length as 1<<len bytes), one reserved zero bit, and comparison bits lt, gt, eq. Combinations of lt/gt/eq encode all standard relational operators.
The traffic-action Extended Community (0x8007) is 6 octets; only bits 47 (Terminal Action, T) and 46 (Sample, S) are defined. T causes the filtering engine to continue evaluating subsequent Flow Specifications; S enables traffic sampling and logging. All other bits MUST be set to 0 on encoding.
The traffic-marking Extended Community (0x8009) encodes the new DSCP value in the 6 least significant bits of the final octet of the Extended Community; all other bits are reserved and MUST be set to 0 on encoding.
The traffic-rate-bytes (0x8006) and traffic-rate-packets (0x800c) Extended Communities encode a 2-octet informational AS number followed by a 4-octet IEEE 754 floating-point rate value (bytes/s or packets/s respectively). A value of 0 discards all matching traffic.
The Type 12 Fragment component uses a 1-octet bitmask operand (MUST be single octet) with four defined bits: DF (don't fragment), IsF (non-first fragment), FF (first fragment: offset=0 AND MF=1), and LF (last fragment: offset!=0 AND MF=0).
The VPNv4 Flow Specification NLRI (AFI=1, SAFI=134) prepends a fixed 8-octet Route Distinguisher to the standard Flow Specification NLRI value. The NLRI length field includes both the 8-octet RD and the subsequent NLRI value.