Revised Validation Procedure for BGP Flow Specifications
updates
- rfc-8955 — Dissemination of Flow Specification Rules
Extracted elements (19)
An empty AS_PATH or one containing only an AS_CONFED_SEQUENCE segment is used as the indicator that a Flow Specification was originated inside the Local Domain. This allows any iBGP peer within the Local Domain, including a route controller not in the forwarding path, to originate Flow Specifications that pass the revised validation.
BGP route servers (RFC 7947 Section 2.2.2.1) do not insert their own AS number into AS_PATH by design, causing the original RFC 8955 rule—which requires the neighboring AS in the left-most position—to block Flow Specification exchange at Internet exchanges. The revised rule compares only the left-most AS in AS_PATH against the left-most AS of the best-match unicast route to permit route server peering.
Network operators deploy centralized Security Operations Centers (SOCs) to detect and mitigate attacks; requiring Flow Specification origination at specific egress border routers is operationally cumbersome in ASes with thousands of ASBRs and complex policies. Centralizing origination at a BGP route controller simplifies intra-domain traffic filtering policy distribution at scale.
The RFC 8955 validation procedure requires the Flow Specification originator to match the best-match unicast route originator, which fails when Flow Specifications are originated from a centralized BGP route controller within the Local Domain that is not in the data forwarding path. This modification relaxes intra-domain validation to enable centralized origination without requiring each ASBR to originate its own Flow Specifications.
Flow Specifications originated in a different Local Domain still require a congruent topology. In a non-congruent inter-domain scenario, condition b.2 evaluates to false and only the originator-match condition b.1 is evaluated, which will fail if the topology is non-congruent.
In a confederation topology, ORIGINATOR_ID is not advertised when propagating routes across local ASes. Without condition b.2, a Flow Specification received from peer Y1 and a best-match unicast route received from peer Y2 (both in local AS Y) would fail the originator-match check; condition b.2 resolves this.
Non-congruent topologies within the Local Domain—such as separate iBGP sessions per address family or confederations where ORIGINATOR_ID is not propagated across local ASes—are now supported when Flow Specifications are originated inside the Local Domain, because condition b.2 will evaluate to true in those cases.
The original RFC 8955 mandatory AS_PATH validation rule (first AS must equal neighbor AS) is redefined as optional for the Flow Specification address family, per RFC 4271 Section 6.3. A BGP speaker may still optionally enforce it; when enforced for a non-route-server peer, security characteristics are equivalent to those in RFC 8955.
As an extension to condition b.2, a given non-empty AS_PATH (beyond AS_CONFED_SEQUENCE segments) MAY be permitted by policy, enabling validation of Flow Specifications from a set of ASes all known to belong to the same administrative domain.
BGP Flow Specification implementations MUST enforce that the AS in the left-most position of the AS_PATH of a Flow Specification received via eBGP matches the AS in the left-most position of the AS_PATH of the best-match unicast route for the destination prefix embedded in the Flow Specification NLRI.
Condition b.2—accepting Flow Specifications with empty AS_PATH or AS_CONFED_SEQUENCE only, indicating origination inside the Local Domain—SHOULD be enabled by default on BGP speakers.
Condition b.2 MAY be disabled by explicit configuration on a BGP speaker, appropriate when operators know with certainty that Flow Specifications will not be originated inside the Local Domain or when only correct egress border routers are originating Flow Specification NLRIs.
In the revised validation procedure, one of the following MUST hold true: (b.1) the originator of the Flow Specification matches the originator of the best-match unicast route for the destination prefix embedded in the Flow Specification, or (b.2) the AS_PATH attribute of the Flow Specification is empty or contains only an AS_CONFED_SEQUENCE segment.
Local Domain is defined as the local AS or local confederation of ASes (RFC 5065). eBGP is peering to a router not within the Local Domain; iBGP encompasses both classic iBGP and any eBGP peering within the same confederation (i.e., any peering that is not eBGP as defined above).
A route server that is known not to peer with any other route server is in a position to enforce the AS_PATH validation rule across all its peers, strengthening security for Flow Specifications exchanged through it.
Allowing Flow Specifications to originate from within the Local Domain (e.g., from a centralized SOC) improves overall network security by enabling faster and more scalable attack mitigation; operators can direct border routers to drop traffic or forward to pipe-cleaning locations during active attacks.
BGP updates from iBGP peers are considered trusted, so intra-domain Flow Specification originators need not match the best-match unicast route originator. However, this trustworthiness is not absolute: the relaxation introduces the new possibility that a rogue iBGP speaker could originate undesired Flow Specifications.
If configuration or other means indicate that an eBGP peer is not a route server, the original RFC 4271 Section 6.3 AS_PATH rule SHOULD be enforced for unicast and/or Flow Specification routes (enforcing it on either address family alone is sufficient). If the peer status is unknown or ambiguous, that rule SHOULD NOT be enforced.
Making the original RFC 4271 Section 6.3 AS_PATH rule optional for Flow Specification introduces risk: a rogue AS X speaker peering with a route server could advertise a Flow Specification with AS Y as the left-most AS_PATH entry; if Y is also the left-most AS of the best-match unicast route, downstream routers will validate and accept the rogue Flow Specification. This risk is unavoidable for route server peers.