Dissemination of Flow Specification Rules
obsoleted by
- rfc-8955 — Dissemination of Flow Specification Rules
updated by
- rfc-7674 — Clarification of the Flowspec Redirect Extended Community
Extracted elements (29)
BGP was chosen as the carrier for flow specification information because it already provides efficient point-to-multipoint distribution, inter-domain capabilities with routing policy support, and tight integration with unicast routing for verification. This reuses existing route reflector/confederation infrastructure and established inter-AS peering relationships.
The validation procedure ties flow specification acceptance to the unicast routing topology so that only the neighboring AS that is the immediate destination of the described traffic can request it be dropped. This prevents an AS from using flow specs to create denial-of-service attacks against traffic destined for others.
If a component type within a flow specification prefix is unknown to the receiver, that prefix cannot be used for traffic filtering. However, the prefix should still be propagated via BGP because route distribution is independent of NLRI semantics.
Port, source port, and destination port flow specification components evaluate to FALSE if the IP protocol is not TCP or UDP, if the packet is fragmented and not the first fragment, or if the system cannot locate the transport header. Implementations may or may not decode the transport header in the presence of IP options or ESP NULL encryption.
A flow specification NLRI is feasible if and only if: (a) the originator of the flow spec matches the originator of the best-match unicast route for the destination prefix, and (b) there are no more-specific unicast routes for that prefix received from a different neighboring AS than the one in step (a).
BGP implementations MUST enforce that the AS_PATH of a route received via eBGP contains the neighboring AS in the left-most position. Though optional in the base BGP specification, this rule is necessary to enforce for security reasons in the flow specification context.
Flow specification components MUST follow strict type ordering: if a component type is present, it MUST precede any component of higher numeric type value.
Implementations wishing to exchange flow specification rules MUST use BGP's Capability Advertisement facility to exchange the Multiprotocol Extension Capability Code (Code 1) as defined in RFC 4760. The (AFI, SAFI) pair carried in that capability MUST match the one used to identify the specific flow-spec application.
Standard BGP policy mechanisms such as UPDATE filtering by NLRI prefix and community matching SHOULD apply to the flow specification NLRI type. Operators can also control propagation by enabling or disabling exchange of a particular (AFI, SAFI) pair on a given BGP peering session.
Traffic filtering implementations SHOULD provide a mechanism to log the packet header of filtered traffic and a mechanism to count the number of matches for a given flow specification rule.
Flow Specification NLRI defines 12 component types encoded as <type (1 octet), operator/value pairs>: (1) Destination Prefix, (2) Source Prefix, (3) IP Protocol, (4) Port (TCP/UDP src or dst), (5) Destination Port, (6) Source Port, (7) ICMP type, (8) ICMP code, (9) TCP flags, (10) Packet length, (11) DSCP, (12) Fragment. A packet matches a flow spec only if it matches all present components (logical AND).
Four traffic filtering actions are standardized as BGP extended community values: 0x8006 (traffic-rate), 0x8007 (traffic-action bitmask), 0x8008 (redirect to VRF by Route Target), and 0x8009 (traffic-marking/DSCP remarking). The default action for a matching flow spec, absent these communities, is to accept traffic.
Traffic filtering rule ordering is deterministic and arrival-order-independent. Rules are compared component by component: the rule with the lowest numeric component type has higher precedence; for IP prefix types, the lowest IP value at the common prefix length wins, with most-specific prefix taking precedence on ties; for all other types, memcmp() determines ordering with the longer string having higher precedence on ties.
Two application-specific NLRI identifiers are defined for flow specification dissemination: AFI=1, SAFI=133 for IPv4 and AFI=1, SAFI=134 for VPNv4. BGP routing updates carrying these identifiers use the flow specification NLRI encoding and are subject to the validation procedure.
VPN flow specification rules received via SAFI=134 apply only to traffic belonging to the VRF(s) into which they are imported via Route Target matching. Traffic from remote PEs is switched via MPLS by default and is not subject to flow-spec filtering. Contrary to the non-VPN behavior, flow rules are accepted by default when received from remote PE routers.
IANA allocated SAFI 133 (IPv4 flow specification dissemination) and SAFI 134 (VPNv4 flow specification dissemination), and assigned extended community values 0x8006 (traffic-rate), 0x8007 (traffic-action), 0x8008 (redirect), and 0x8009 (traffic-remarking) from the BGP Extended Communities Type - Experimental Use registry.
IANA created the 'Flow Spec Component Types' registry with types 1–12 defined by this specification, type 0 reserved (invalid), range [13..127] requiring Specification Required policy, and range [128..255] on a First Come First Served basis.
IANA created the 'Traffic Action Fields' registry for the 48-bit traffic-action extended community field. Bit 47 (Terminal Action) and bit 46 (Sample) are assigned; bits 0–45 are unassigned. New assignments require IETF Review.
Enabling distributed firewall-like capabilities in routers without centralized management can make failures harder to diagnose. Configurations such as allowing TCP but not ICMP, or permitting only certain packet-length ranges between a pair of addresses, may create confusing behavior and should be used with care.
The security model depends on restricting flow specifications to match corresponding unicast routing paths; when this constraint holds, the security properties are equivalent to BGP unicast routing. A neighboring AS that advertises flow specs without corresponding unicast routing could cause denial-of-service by filtering legitimate traffic.
Flow specification components use a numeric operator byte with fields: e (end-of-list bit), a (AND bit for logical combination with previous term), len (value field length as 1<<len bytes), lt (less than), gt (greater than), and eq (equality). The lt, gt, and eq bits can be combined to produce ranges and inequalities.
The bitmask operator format (used for TCP flags Type 9 and Fragment Type 12) shares the most-significant nibble (e, a, len) with the numeric format but replaces the lower nibble with: not (logical negation) and m (match bit). When m is set, the match operation is '(data & value) == value'; when unset, any matching bit in the value mask suffices.
The Flow Specification NLRI is encoded as a 1- or 2-octet length field followed by a variable-length NLRI value. If the length value is less than 240 (0xf0), a single octet is used; otherwise a 2-octet extended-length form is used where the most significant nibble is all ones, supporting a maximum NLRI length of 4095 octets.
The traffic-action extended community (type 0x8007) uses 6 bytes; only the two least-significant bits of byte 6 are defined: bit 47 (Terminal Action — if set, continue evaluating subsequent rules; if unset, stop at this rule) and bit 46 (Sample — enables traffic sampling and logging for this flow).
The traffic-marking extended community (type 0x8009) instructs a system to modify the DSCP bits of transiting IP packets. It is encoded as 5 zero bytes followed by the DSCP value in the 6 least-significant bits of the 6th byte.
The traffic-rate extended community (type 0x8006) encodes a 2-octet AS number (informational only) followed by a 4-octet IEEE 754 floating-point rate in bytes per second. A rate of 0 causes all matching traffic to be discarded. This community is non-transitive across AS boundaries.
The VPNv4 Flow Specification NLRI (AFI=1, SAFI=134) prepends a fixed-length 8-byte Route Distinguisher to the standard flow specification encoding. The NLRI length field includes both the 8-byte RD and the subsequent flow specification.
Type 12 (Fragment) uses a 1-octet bitmask with four defined bits: bit 7 = DF (Don't Fragment), bit 6 = IsF (Is a Fragment), bit 5 = FF (First Fragment), bit 4 = LF (Last Fragment); bits 0–3 are reserved.
Type 9 (TCP flags) bitmask values can be encoded as 1 or 2 bytes. A 1-byte value matches byte 13 of the TCP header (bits 8–15 of the 4th 32-bit word); a 2-byte encoding matches bytes 12 and 13 with the data offset field treated as don't-care.