Traffic Steering using BGP FlowSpec with SR Policy

3.1. Operational Steering Modes

The traffic steering mechanism specified in this document relies on BGP FlowSpec filtering rules to perform flow-based policy encapsulation into SR Policies [RFC9256].¶

Architecturally, FlowSpec-based steering corresponds strictly to Policy-Based Routing (PBR) steering as defined in Section 8.7 of [RFC9256]. It SHALL NOT be interpreted or implemented as per-destination steering (Section 8.4 of [RFC9256]). Implementations MUST NOT apply per-destination route-resolution mechanics, BGP multipath path resolution, or On-Demand BSID recursion [RFC9256] to FlowSpec route processing.¶

When advertising a FlowSpec route to steer traffic into an SR Policy, the sender MUST construct the BGP UPDATE message according to one of the two deterministic operational modes specified below, based on the target data plane (SR-MPLS or SRv6) and egress service context requirements:¶

3.2. Procedures for the Sending BGP Speaker / Controller

A BGP speaker or controller originating or re-advertising a FlowSpec route to steer traffic into an SR Policy MUST perform the following operations:¶

1. Determine the explicit (Color, Endpoint) tuple required for transport steering. Attach the corresponding Color Extended Community [RFC9012] and set the target IP address in the Redirect-to-IP (or Redirect-to-IPv6) Extended Community [I-D.ietf-idr-flowspec-redirect-ip] to match the SR Policy Endpoint.¶

2. Evaluate whether an egress service action is required:¶

   • If no egress service action is required (Mode 1, Section 3.1.1), the speaker MUST NOT attach the BGP Prefix-SID Attribute.¶

   • If an egress SRv6 service action is required (Mode 2, Section 3.1.2), the speaker MUST attach the BGP Prefix-SID Attribute containing the SRv6 Service SID, constructed strictly per Section 3.6.¶

3. If a BGP speaker receives a FlowSpec route containing a valid Color Extended Community and a Redirect-to-IP Extended Community and re-advertises it, it MUST preserve these attributes unchanged unless local policy explicitly modifies the steering intent.¶

3.3. Procedures for the Receiving BGP Speaker (Headend / Ingress PE)

The validation and installation procedures specified in this section apply EXCLUSIVELY to BGP FlowSpec receivers acting as SR Headends (e.g., Ingress PEs) that process packet steering into SR Policies.¶

Intermediate BGP Speakers, such as Route Reflectors (RRs), that do not participate in data-plane traffic steering MUST transparently reflect and propagate the FlowSpec routes along with their attached attributes (e.g., Color Extended Community, Redirect-to-IP, and BGP Prefix-SID Attribute) per standard BGP propagation rules [RFC8955], without attempting SR Policy binding or FIB installation.¶

Upon receiving a FlowSpec route (AFI=1/2, SAFI=133), the receiving headend router MUST process the route in accordance with the following sequence:¶

1. Base NLRI & Attribute Syntactic Validation:¶

   • The receiver MUST validate the FlowSpec NLRI against the base rules defined in [RFC8955][RFC8956]. If NLRI validation fails, BGP error handling per [RFC8955][RFC8956] applies.¶

   • Syntactic attribute errors (e.g., malformed BGP Prefix-SID Attribute or Extended Communities) MUST be handled according to BGP Error Handling rules [RFC7606] (e.g., Treat-as-Withdraw).¶

2. Steering Mode Determination and Attribute Interworking Validation:¶

   • The headend MUST evaluate the co-existing steering attributes for correct interworking and mode determination:¶

     1. Mode 1 Validation: If a valid Color Extended Community and a valid Redirect-to-IP Extended Community are present, and the BGP Prefix-SID Attribute is ABSENT, the route is validated as Mode 1 (Transport Steering Only).¶

     2. Mode 2 Validation: If a valid Color Extended Community, a valid Redirect-to-IP Extended Community, AND a valid BGP Prefix-SID Attribute are present, the route is validated as Mode 2 (Transport Steering with Egress Service Action). The BGP Prefix-SID Attribute MUST contain a valid SRv6 L3 Service TLV (Type 5) and SRv6 SID Information Sub-TLV (Type 1) [RFC9252]. The carried SRv6 Endpoint Behavior MUST belong to the allowed Layer 3 behavior set specified in Section 3.6.¶

   • If any required steering attribute is missing, or if the attributes fail the interworking validation above, the headend MUST NOT perform SR Policy steering via Modes 1 or 2, and SHALL handle the route according to the failure and matrix resolution procedures defined in Section 3.7 and Section 4.¶

   • ¶

3. Steering Parameter Extraction & SR Policy Lookup:¶

   • The headend MUST extract the Color value from the Color Extended Community and the target IP address from the Redirect-to-IP Extended Community. Together, these form the explicit (Color, Endpoint) tuple used as the binding key [RFC9256].¶

   • The headend MUST perform a lookup in its local SR Policy database using the (Color, Endpoint) tuple strictly per Section 8.8.1 of [RFC9256] to resolve an active, valid SR Policy Candidate Path.¶

   • The BGP Prefix-SID Attribute, if present (Mode 2), SHALL NOT be used as part of the SR Policy database lookup key. It is extracted exclusively to provide the egress service decapsulation context during segment list synthesis.¶

4. Forwarding Action Installation & Encapsulation Synthesis:¶

   • If a matching active SR Policy candidate path is successfully resolved:¶

     1. The default Longest-Prefix-Match (LPM) lookup prescribed in [I-D.ietf-idr-flowspec-redirect-ip] SHALL NOT be performed.¶

     2. Mode 1: The headend MUST program its forwarding plane to encapsulate matching traffic using strictly the active Segment List of the resolved SR Policy.¶

     3. Mode 2: The headend MUST synthesize the active encapsulation segment list by stitching the resolved SR Policy Segment List and the Egress SRv6 Service SID, in strict adherence to Section 5 of [RFC9252]. Specifically:¶

        • When the headend device determines (with the help of the SRv6 SID Structure Sub-Sub-TLV [RFC9252]) that the Egress SRv6 Service SID belongs to the same SRv6 Locator as the last SRv6 SID of the tailend device in the resolved SRv6 Policy segment list, it MAY omit/replace the Endpoint SID with the Egress Service SID when steering the service flow (e.g., replacing segment list <S1, S2, S3> with <S1, S2, Egress_Service_SID>).¶

        • Otherwise, the Egress SRv6 Service SID MUST be appended to the resolved SR Policy segment list (e.g., <S1, S2, S3, Egress_Service_SID>).¶

     4. Coexisting FlowSpec Actions: Non-steering FlowSpec actions present in the same route (such as Traffic-Rate policing or drop per [RFC8955]) MUST be applied to matching traffic regardless of the steering resolution or programming state, unless local policy explicitly dictates otherwise.¶

5. Control Plane Route Retention and Propagation Rules:¶

   • If a FlowSpec route carrying SR Policy attributes cannot be bound to an active, valid SR Policy in the local SR Database, or if its steering entry cannot be installed into the forwarding plane:¶

     1. BGP Route Status: The receiving BGP speaker MUST NOT discard, withdraw, or mark the BGP FlowSpec route as BGP-Invalid solely due to the absence or uninstantiated state of a matching SR Policy or a forwarding programming failure. If the BGP UPDATE message and its attributes pass standard syntactic validation [RFC7606][RFC8955], the route SHALL be considered BGP-Valid and retained in the BGP Loc-RIB.¶

     2. Best-Path Selection: The route MUST remain eligible for the BGP best-path selection process per standard decision rules [RFC4271][RFC8955].¶

     3. Propagation: If selected as the best path, the BGP speaker MUST propagate the FlowSpec route along with its attached steering attributes to other BGP peers according to local policy and standard BGP propagation rules.¶

     4. Data Plane Steering Failure Enforcement: The headend router MUST decouple control plane route propagation from data plane steering. While the route is safely retained and propagated in the control plane, the data plane traffic filtering actions for packets matching the FlowSpec NLRI SHALL be handled strictly according to the steering failure and fallback procedures defined in Section 3.7 and Section 4.¶

3.4. Interaction with Redirect-to-IP Extended Community

When a FlowSpec route carries both a valid Color Extended Community [RFC9012] and a Redirect-to-IP (or Redirect-to-IPv6) Extended Community [I-D.ietf-idr-flowspec-redirect-ip]:¶

• Syntactic Validation and Attribute Reuse: The receiving router MUST perform syntactic and structural validation of the Redirect-to-IP Extended Community according to [I-D.ietf-idr-flowspec-redirect-ip]. However, the target IP address in the Redirect-to-IP Extended Community SHALL be interpreted strictly as the Endpoint of the target SR Policy, forming the explicit (Color, Endpoint) tuple [RFC9256].¶

• Precedence and Supersedence of Forwarding Behavior: In accordance with Section 2.2.2 of [I-D.ietf-idr-flowspec-redirect-ip], the SR Policy steering procedures defined in this specification take precedence over, and explicitly SUPERSEDE, the default forwarding behavior specified in Section 2.2 of [I-D.ietf-idr-flowspec-redirect-ip]. The standard Longest-Prefix-Match (LPM) lookup toward the target IP address SHALL NOT be performed. Instead, matching traffic MUST be steered into the SR Policy resolved by the (Color, Endpoint) tuple.¶

If a FlowSpec route carries multiple Color Extended Communities, the preference rule among multiple colors, as well as the fallback mechanism to the next-highest numerical color value when the highest-color SR Policy is uninstantiated or inactive, follows the procedures specified in Section 8.4.1 of [RFC9256].¶

3.5. Scope Exceptions and Explicit Constraints

3.6. BGP Prefix-SID Attribute Encoding Rules

The BGP Prefix-SID Attribute is used in this specification strictly for conveying SRv6 Service SIDs in SRv6 Mode 2 (Section 3.1.2). For SR-MPLS scenarios, the BGP Prefix-SID Attribute SHALL NOT be attached.¶

When the BGP Prefix-SID Attribute is attached to a FlowSpec route in an SRv6 environment, the following encoding rules apply per [RFC9252] and [RFC8986]:¶

• SRv6 Service TLVs: The SRv6 L3 Service TLV (Type 5) [RFC9252] SHALL be used to convey the egress service action.¶

• Sub-TLVs: The SRv6 SID Information Sub-TLV (Type 1) SHALL be included within the SRv6 Service TLV. The SRv6 SID Structure Sub-Sub-TLV (Type 1) [RFC9252] MAY be included to specify the SRv6 Locator and SID structure [RFC8986].¶

• Supported Endpoint Behaviors: The SRv6 Service SID Endpoint Behavior codepoints supported for FlowSpec egress service steering are restricted to Layer 3 behaviors defined in [RFC8986], including End.DT4, End.DT6, End.DT46, End.DX4, and End.DX6. Layer 2 behaviors (e.g., End.DX2, End.DT2M) and transit/underlay behaviors (e.g., End, End.X) SHALL NOT be used for FlowSpec egress service steering under this specification.¶

• Disallowance of Transposition Scheme: [RFC9252] Section 4 defines a Transposition Scheme where part of the SRv6 SID is transposed into the MPLS Label field of the BGP NLRI. Because FlowSpec NLRIs [RFC8955][RFC8956] do not carry an MPLS Label field, the Transposition Scheme SHALL NOT be used. The full SRv6 Service SID MUST be encoded entirely within the SRv6 SID Information Sub-TLV of the BGP Prefix-SID Attribute.¶

3.7. Steering Failure and Fallback Procedures

If a receiving headend router cannot steer matching traffic into an SR Policy for a FlowSpec route carrying a Color Extended Community and a Redirect-to-IP Extended Community - due to any of the conditions defined in Section 4 (such as an uninstantiated matching SR Policy, an invalid Prefix-SID attribute per [RFC9252], or forwarding programming resource exhaustion) - the router MUST handle matching traffic according to local steering failure policies and Section 4.3.¶

Standard fallback actions MAY include, in order of administrative preference:¶

1. Fallback Color Evaluation: If the FlowSpec route carries multiple Color Extended Communities, evaluate the remaining colors in descending numerical order per Section 8.4.1 of [RFC9256].¶

2. Native/Default Path Forwarding: Forward matching traffic using the normal IP/MPLS routing table lookup toward the packet's original destination address.¶

3. Traffic Drop: Silently drop matching traffic if configured by policy for strict traffic isolation or anti-leak enforcement.¶

3.8. Load Balancing Considerations

When traffic matching a BGP FlowSpec rule is steered into an SR Policy (under either Mode 1 or Mode 2), the target SR Policy may contain multiple active Segment Lists for multi-path load balancing (ECMP or UCMP) as specified in [RFC9256].¶

1. Flow Spec to SR Policy Mapping:¶

   • The FlowSpec rule classifies matching packets and directs them into the resolved SR Policy as a single aggregate traffic stream. The FlowSpec filtering actions MUST NOT alter or bypass the selection of Segment Lists within that SR Policy.¶

2. Multi-Path ECMP/UCMP Hashing:¶

   • When the target SR Policy consists of multiple candidate Segment Lists with equal or unequal weights:¶

     • The headend router MUST distribute the matched FlowSpec traffic across all active Segment Lists according to their defined weights.¶

     • For both SR-MPLS and SRv6 data planes, the multipath hash calculation MUST be performed using the packet's inner header fields (e.g., 5-tuple) to ensure symmetric and fine-grained per-flow load balancing.¶

3. SRv6 Flow Label Generation (RFC 8754 Alignment):¶

   • In SRv6 steering scenarios (including Mode 1 and Mode 2 with SID stitching):¶

     • The generation of the Flow Label field in the outer IPv6 header MUST NOT be affected or overwritten by the FlowSpec matching rule.¶

     • The headend node MUST compute and assign the outer IPv6 Flow Label based on a hash of the inner packet header fields in full accordance with Section 5.1 of [RFC8754].¶

     • Preserving independent, inner-flow-based IPv6 Flow Label generation is essential to prevent Hash Polarization and packet drops at downstream intermediate P routers performing ECMP over outer IPv6 headers.¶

3.9. Backward Compatibility and Coexistence with Base BGP FlowSpec

This specification defines extensions to the processing of BGP FlowSpec routes when carrying a combination of the Color Extended Community [RFC9012], Redirect-to-IP Extended Community [I-D.ietf-idr-flowspec-redirect-ip], and the BGP Prefix-SID Attribute [RFC9252].¶

A BGP speaker receiving a FlowSpec route constructed under this specification MUST process and propagate the attributes according to its capability level as follows:¶

1. Local Behavior at a Non-Supporting Receiver:¶

   • If a receiving headend router supports base BGP FlowSpec [RFC8955][RFC8956] and the Redirect-to-IP Extended Community, but does not support this specification or the BGP Prefix-SID Attribute in the context of FlowSpec, it MUST ignore the unrecognized BGP Prefix-SID Attribute. The receiver SHALL fall back to processing the Redirect-to-IP Extended Community according to standard procedures (e.g., performing a Longest-Prefix-Match lookup toward the target IP address per [I-D.ietf-idr-flowspec-redirect-ip]).¶

2. Attribute Propagation and Control Plane Filtering:¶

   • In accordance with standard BGP Optional Transitive attribute handling rules [RFC4271], a BGP speaker that does not support the BGP Prefix-SID Attribute MUST propagate the attribute un-modified to other BGP peers, setting the Partial bit in the attribute flags.¶

   • Furthermore, implementations supporting the signalling defined in this document MUST comply with the following operational control rules:¶

     • Attribute Filtering: Attribute filtering and propagation policies for the BGP Prefix-SID Attribute MUST follow Section 5 of [RFC8669].¶

     • Neighbor and Service Granularity Control: In strict adherence to Section 3.2.1 of [RFC9252], implementations MUST provide a control mechanism to enable or disable the advertisement of SRv6-based service steering attributes on a per-neighbor and per-service basis.¶

4.1. Policy-Based Steering Classification

Architecturally, traffic steering resulting from the matching of a BGP FlowSpec route corresponds strictly to Policy-Based Routing (PBR) / Policy-Based Steering as defined in Section 8.7 of [RFC9256].¶

FlowSpec steering SHALL NOT be interpreted or implemented as per-destination steering (Section 8.4 of [RFC9256]). Implementations MUST NOT apply per-destination route-resolution mechanics, BGP multipath path resolution, or On-Demand BSID recursion [RFC9256] to BGP FlowSpec route processing.¶

4.2. Deterministic Interworking Matrix

Upon receiving a BGP FlowSpec route, the headend router MUST evaluate the syntactic and semantic validity of the steering attributes and execute the corresponding steering outcome, non-steering action disposition, and diagnostic requirements defined in Table 1.¶

Legend: Color = Color EC; ReIP = Redirect-to-IP EC;
        PSID = BGP Prefix-SID Attribute;
        V = Valid; I = Invalid; A = Absent; * = Any (V/I/A).
        V(L3) = Valid L3 Service SID (e.g., End.DT4/6/DX4/6/DT46);
        [flowspec-redirect] = [I-D.ietf-idr-flowspec-redirect-ip].

 Table 1: Deterministic Multi-Attribute Interworking and
          Action Resolution Matrix

 +---+-------+------+-------+-------------------------+-------------+
 |R# | Color | ReIP | PSID  | Steering Action Outcome | Diagnostics |
 +---+-------+------+-------+-------------------------+-------------+
 | 1 | V     | V    | A     | Mode 1 SR Policy        | None        |
 |   |       |      |       | Steering (Sec 3.1.1)    |             |
 +---+-------+------+-------+-------------------------+-------------+
 | 2 | V     | V    | V(L3) | Mode 2 SR Policy        | None        |
 |   |       |      |       | Steering (Sec 3.1.2)    |             |
 +---+-------+------+-------+-------------------------+-------------+
 | 3 | V     | V    | I     | Steering Failure: NO    | Log: Invalid|
 |   |       |      |       | Policy & NO ReIP Fallbk | Service SID |
 +---+-------+------+-------+-------------------------+-------------+
 | 4 | I     | V    | *     | Steering Failure: Abort | Log: Invalid|
 |   |       |      |       | Steering Actions        | Color EC    |
 +---+-------+------+-------+-------------------------+-------------+
 | 5 | V     | I    | *     | Steering Failure: Abort | Log: Invalid|
 |   |       |      |       | Steering Actions        | ReIP Target |
 +---+-------+------+-------+-------------------------+-------------+
 | 6 | A     | V    | A/I   | Base ReIP Forwarding    | None        |
 |   |       |      |       | per [flowspec-redirect] |             |
 +---+-------+------+-------+-------------------------+-------------+
 | 7 | A     | A/I  | *     | NO Steering Action;     | None        |
 |   |       |      |       | Native Shortest Path    |             |
 +---+-------+------+-------+-------------------------+-------------+

 Note: Non-steering actions (e.g., rate-limit, drop) attached to the
 route MUST be applied in all rows (Rows 1-7).

4.3. Protection Against Silent SLA Violations

To prevent unintentional redirection and catastrophic SLA violations, implementations MUST strictly enforce the following operational rules:¶

1. Abortion of Redirection on Corrupted Intent (Table 1, Rows 3, 4, 5):¶

   • If a FlowSpec route carries an explicit intent for SR Policy steering (indicated by the presence of a Color EC or Mode 2 Prefix-SID) but any required steering attribute is determined to be INVALID, the receiver MUST NOT perform default Redirect-to-IP forwarding. Silently falling back to shortest-path IP forwarding toward the target IP address is strictly PROHIBITED, as it violates explicit SLA steering policies. The matching traffic MUST be dropped or handled strictly according to local fallback policy (Section 3.7).¶

2. Enforcement of Coexisting Non-Steering Actions:¶

   • In all failure or fallback cases (Table 1, Rows 3-7), other valid non- steering actions present in the same BGP FlowSpec route (such as Traffic- Rate/Drop [RFC8955], Rate-limiting, or DSCP remarking) MUST continue to be processed and enforced in the forwarding plane.¶

3. Multiple Redirect-to-IP Communities and Load-Sharing:¶

   • When multiple valid Redirect-to-IP Extended Communities are attached to the same FlowSpec route alongside a valid Color Extended Community, the resolution and multi-path load-sharing across multiple target SR Policies (identified by their respective Endpoint IP addresses) MUST follow the EC-level load-sharing procedures defined in Section 2.2 of [I-D.ietf-idr-flowspec-redirect-ip].¶

4. Logging and Diagnostics:¶

   • Implementations SHOULD generate diagnostic log entries (as specified in Table 1) whenever an SR Policy steering route contains corrupted or invalid steering attributes to assist network operators in rapid fault isolation.¶

4.4. Backward Compatibility and Coexistence Behavior

A BGP speaker receiving a FlowSpec route constructed under this specification MUST process and propagate the attributes according to its capability level:¶

1. Non-Supporting Headend Behavior:¶

   • If a receiving headend router supports base BGP FlowSpec [RFC8955][RFC8956] and the Redirect-to-IP Extended Community, but does not support this specification or the BGP Prefix-SID Attribute in the context of FlowSpec, it MUST ignore the unrecognized BGP Prefix-SID Attribute. The receiver SHALL fall back to processing the Redirect-to-IP Extended Community according to standard procedures (e.g., performing a Longest-Prefix-Match lookup toward the target IP address per [I-D.ietf-idr-flowspec-redirect-ip]).¶

2. Attribute Propagation and Control Plane Filtering:¶

   • In accordance with standard BGP Optional Transitive attribute handling rules [RFC4271], a BGP speaker that does not support the BGP Prefix-SID Attribute MUST propagate the attribute unmodified to other BGP peers, setting the Partial bit in the attribute flags.¶

   • Furthermore, implementations supporting the signalling defined in this document MUST comply with the following operational control rules:¶

     • Attribute Filtering: Attribute filtering and propagation policies for the BGP Prefix-SID Attribute MUST follow Section 5 of [RFC8669].¶

     • Neighbor and Service Granularity Control: In strict adherence to Section 3.2.1 of [RFC9252], implementations MUST provide a control mechanism to enable or disable the advertisement of SRv6-based service steering attributes on a per-neighbor and per-service basis.¶

5.1. Forwarding Failure Monitoring and Management

When a headend router fails to program a FlowSpec SR Policy steering entry into the forwarding plane (Section 3.3), the implementation SHOULD make relevant diagnostic information available to network operators.¶

• Logging and Notifications: The implementation SHOULD generate appropriate management notifications (e.g., Syslog messages, SNMP traps, or YANG notifications, if supported) detailing the uninstalled FlowSpec NLRI, the associated (Color, Endpoint) tuple, and the specific failure reason (e.g., resource exhaustion).¶

• Resource Recovery and Re-programming: An implementation SHOULD monitor forwarding plane resource availability. When sufficient forwarding resources become available, the implementation SHOULD automatically re-attempt to program any previously uninstalled FlowSpec steering entries.¶

Implementations SHOULD provide hardware or software counter metrics (e.g., byte/packet dropped counters) associated with uninstalled or failed FlowSpec steering entries for operational visibility.¶

6.1. Cross-VRF Traffic Injection and Service Hijacking

Exposure:¶

The BGP Prefix-SID Attribute carried in a FlowSpec route conveys an SRv6 Service SID (e.g., End.DT4, End.DT6, End.DT46, End.DX4, End.DX6) that determines the egress routing table, VRF, or interface context at the TailEnd PE. A malicious or misconfigured BGP FlowSpec Controller can utilize this mechanism to steer matched traffic into an arbitrary VRF or cross-connect interface at a remote PE, resulting in unauthorized cross-VRF data leakage or traffic interception.¶

Exploitation & Threat Actor:¶

An attacker who compromises a BGP FlowSpec speaker or a misconfigured operator controller positioned within the control plane.¶

Mitigations:¶

• Strict Control Plane Filtering: PEs MUST validate that any SRv6 Service SID received in a BGP FlowSpec route belongs to an authorized Locator range allocated for the intended target VRF or service context.¶

• Access Control: BGP FlowSpec peering sessions with controllers MUST be secured using TCP-AO [RFC5925] and restricted to trusted administrative entities.¶

6.2. Scope and Validation Limits of BGP FlowSpec Attributes

Exposure:¶

Standard BGP FlowSpec route validation mechanisms specified in [RFC8955][RFC8956][RFC9117] validate the FlowSpec NLRI and the Redirect-to-IP Extended Community against the originator of the destination prefix. However, these RFCs do not define validation rules for the Color Extended Community or the BGP Prefix-SID Attribute. Consequently, the two attributes that dictate the transport path selection and egress service context remain unvalidated by standard origin validation algorithms.¶

Exploitation & Threat Actor:¶

An internal or external entity capable of injecting or altering BGP attributes on BGP FlowSpec routes in transit.¶

Mitigations:¶

• Policy-based Validation: Headends MUST apply local policy checks to verify that the (Color, Endpoint) tuple resolves to a legitimately authorized SR Policy before binding FlowSpec traffic flows to it.¶

• Attribute Filtering: Network operators MUST strip or reject unknown or unauthorized Color Extended Communities and BGP Prefix-SID Attributes on FlowSpec routes received from untrusted BGP peers.¶

6.3. SR Domain Leakage and Boundary Security

Exposure:¶

As detailed in [RFC8402] and [RFC8669], SRv6 SIDs and BGP Prefix-SID Attributes are intended for use strictly within a single trusted SR domain. If BGP FlowSpec routes carrying Prefix-SID Attributes propagate across administrative boundaries or untrusted EBGP peers without filtering, internal SRv6 Locator information and internal topology structures could leak, exposing the network to external steering attacks.¶

Exploitation & Threat Actor:¶

An external adversary on an adjacent untrusted AS or an insider exploiting missing boundary filters.¶

Mitigations:¶

• Border Filtering: Autonomous System Border Routers (ASBRs) MUST filter out or strip the BGP Prefix-SID Attribute and SRv6-related Extended Communities from BGP FlowSpec routes traversing administrative or trust boundaries, unless explicit inter-domain trust agreements and strict policy filters are enforced.¶

6.4. Traffic Amplification and Path Pinning

Exposure:¶

Per [RFC9117], a single BGP FlowSpec route can match high-volume distributed traffic flows across multiple Ingress PEs and redirect them to a single Redirect-to-IP destination (specifically via BGP FlowSpec Redirect-to-IP fan-in/fan-out aggregate behavior). Binding such redirected flows to an SR Policy does not mitigate this amplification and concentration effect; instead, it allows an attacker to pin the amplified traffic to a specific engineered transport path, potentially overloading transit nodes along the SR Policy path or target interfaces at the TailEnd device.¶

Exploitation & Threat Actor:¶

A compromised controller or malicious BGP speaker attempting a Denial of Service (DoS) attack against specific network links or egress PEs.¶

Mitigations:¶

• Rate Limiting: Ingress PEs SHOULD combine FlowSpec redirect actions with Traffic Rate Extended Communities (Traffic-Policing) [RFC8955] to bound the maximum bandwidth redirected into an SR Policy.¶

• Policy Monitoring: Operators SHOULD implement telemetry and path utilization monitoring on SR Policies used for FlowSpec traffic steering to dynamically detect and mitigate link congestion.¶

7.1. SR-MPLS Application Examples (Mode 1)

Figure 1 illustrates a scenario where a BGP FlowSpec Controller signals steering instructions for an SR-MPLS network to a Headend device (Ingress PE).¶

In the following scenarios shown in Figure 1, BGP FlowSpec Controller signals the filter rules, the Flow-spec Redirect to IPv4/IPv6 action, and the policy color to the SR-MPLS HeadEnd device.¶

   +------------+
   |  BGP FS    |
   | Controller |
   +------------+
      | FlowSpec route to HeadEnd:
      |   NLRI: Filter Rules
      |   Redirect-to-IP Extended Community: TailEnd Address
      |   Color Extended Community: C0
      |   (Prefix-SID Attribute: ABSENT)
      |          .-----.
      |         (       )
      V     .--(         )--.
+-------+  (                 )  +-------+
|       |_(  SR-MPLS Network  )_|       |
|HeadEnd| ( ================> ) |TailEnd|
+-------+  (SR List<S1,S2,S3>)  +-------+
            '--(         )--'
                (       )
                 '-----'

In this Mode 1 scenario (Section 3.1.1):¶

• Control Plane Signalling:¶

  • The BGP FS Controller advertises a FlowSpec route carrying matching rules, Redirect-to-IP (TailEnd Address), and Color Extended Community C0. The BGP Prefix-SID Attribute is ABSENT.¶

• Headend Processing:¶

  • The Headend resolves the target SR-MPLS Policy matching the tuple (Endpoint: TailEnd, Color: C0).¶

• Data Plane Encapsulation:¶

  • Matching traffic flows are encapsulated strictly using the MPLS label stack corresponding to the resolved SR Policy segment list:¶

  •  +---------------------------------------------+
     | Outer IP / Ethernet Header                  |
     +---------------------------------------------+
     | MPLS Label S1 (Top)                         |
     | MPLS Label S2                               |
     | MPLS Label S3 (Bottom with S=1)             |
     +---------------------------------------------+
     | Inner Payload (Original IPv4/IPv6 Packet)   |
     +---------------------------------------------+
    
    

    ¶

  • Decapsulation or label popping at the TailEnd device relies on standard MPLS segment behaviors (e.g., Penultimate Hop Popping or Implicit Null).¶

When the SR-MPLS HeadEnd device (as a FlowSpec client) receives such instructions from BGP FS Controller, it will steer the traffic flows matching the criteria in the FlowSpec route into the SR-MPLS Policy matching the tuple (Endpoint: TailEnd's Address, Color: C0). And the packets of such traffic flows will be encapsulated with an MPLS stack using the SR List <S1, S2, S3> in the HeadEnd device, then send the packets to the TailEnd device along the path indicated by the SR list.¶

7.2. SRv6 Application Examples

In SRv6 networks, FlowSpec traffic steering operates under either Mode 2 (Transport Steering with Egress Service Action) or Mode 1 (Transport Steering Only).¶

   +------------+
   |  BGP FS    |
   | Controller |
   +------------+
      | FlowSpec route to HeadEnd:
      |   NLRI: Filter Rules
      |   Redirect-to-IPv6 Extended Community: TailEnd Address
      |   Color Extended Community: C1
      |   Prefix-SID Attribute: Egress_Service_SID
      |          .-----.
      |         (       )
      V     .--(         )--.
+-------+  (                 )  +-------+
|       |_( SRv6 Core Network )_|       |
|HeadEnd| ( ================> ) |TailEnd|
+-------+  (SR List<S1,S2,S3>)  +-------+
            '--(         )--'   SRv6 SID: Egress_Service_SID
                (       )       (e.g., End.DT4, End.DT6, etc.)
                 '-----'

   +------------+
   |  BGP FS    |
   | Controller |
   +------------+
      | FlowSpec route to HeadEnd:
      |   NLRI: Filter Rules
      |   Redirect-to-IPv6 Extended Community: TailEnd Address
      |   Color Extended Community: C2
      |   (Prefix-SID Attribute: ABSENT)
      |          .-----.
      |         (       )
      V     .--(         )--.
+-------+  (                 )  +-------+
|       |_( SRv6 Core Network )_|       |
|HeadEnd| ( ================> ) |TailEnd|
+-------+  (SR List<S1,S2,S3>)  +-------+
            '--(         )--'
                (       )
                 '-----'
Note: S3 is an SRv6 SID with USD flavor on the TailEnd.

8.1. Interop-test Status

The Traffic Steering using BGP FlowSpec with SR-MPLS / SRv6 Policy mechanism has been implemented on the following hardware devices, Network Operating System software, and SDN controllers. They have also successfully participated in a series of joint interoperability testing events hosted by China Mobile from July 2021 to October 2021. The following hardware devices and Network Operating System software passed the interoperability testing (in alphabetical order).¶

Routers:
+---------+---------------+--------------------------------+
| Vendors | Device Model  | Version                        |
+---------+---------------+--------------------------------+
| Huawei  | NE40-X8A      | NE40E V800R021C00SPC091T       |
+---------+---------------+--------------------------------+
| New H3C | CR16010H-FA   | Version 7.1.075, ESS 8305      |
+---------+---------------+--------------------------------+
| Ruijie  | RG-N8010-R    | N8000-R_RGOS 12.8(1)B08T1      |
+---------+---------------+--------------------------------+
| ZTE     | M6000-8S Plus | V5.00.10(5.60.5)               |
+---------+---------------+--------------------------------+

Controllers:
+----------------+---------------+-------------------------+
| Vendors        | Device Model  | Version                 |
+----------------+---------------+-------------------------+
| China Unitechs | I-T-E SC      | V1.3.6P3                |
+----------------+---------------+-------------------------+
| Huawei         | NCE-IP        | V100R021C00             |
+----------------+---------------+-------------------------+
| Ruijie         | RG-ONC-AIO-H  | RG-ION-WAN-CLOUD_2.00T1 |
+----------------+---------------+-------------------------+
| ZTE            | ZENIC ONE     | R22V16.21.20            |
+----------------+---------------+-------------------------+

8.2. Deployment Status

As of August 2022, this feature has been deployed on the IP backbone network of China Mobile.¶

China Mobile has fully transitioned to the SRv6 architecture, with no scenarios where SRv6 and SR-MPLS coexist. As a result, when utilizing Color C and IPv6 redirect addresses, traffic steering is executed exclusively via SRv6 policies.¶

In scenarios where an operator supports the coexistence of SRv6 and SR-MPLS, it is recommended to adhere to [RFC9256] to govern policy selection for traffic steering based on Color C and IPv6 endpoints.¶

12.1. Normative References

[I-D.ietf-idr-flowspec-redirect-ip]

Haas, J., Henderickx, W., and A. Simpson, "BGP Flow-Spec Redirect-to-IP Action", Work in Progress, Internet-Draft, draft-ietf-idr-flowspec-redirect-ip-16, 21 May 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-redirect-ip-16>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC4271]

Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.

[RFC4360]

Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006, <https://www.rfc-editor.org/info/rfc4360>.

[RFC4760]

Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, <https://www.rfc-editor.org/info/rfc4760>.

[RFC7606]

Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, <https://www.rfc-editor.org/info/rfc7606>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8402]

Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.

[RFC8660]

Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with the MPLS Data Plane", RFC 8660, DOI 10.17487/RFC8660, December 2019, <https://www.rfc-editor.org/info/rfc8660>.

[RFC8669]

Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah, A., and H. Gredler, "Segment Routing Prefix Segment Identifier Extensions for BGP", RFC 8669, DOI 10.17487/RFC8669, December 2019, <https://www.rfc-editor.org/info/rfc8669>.

[RFC8955]

Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. Bacher, "Dissemination of Flow Specification Rules", RFC 8955, DOI 10.17487/RFC8955, December 2020, <https://www.rfc-editor.org/info/rfc8955>.

[RFC8956]

Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed., "Dissemination of Flow Specification Rules for IPv6", RFC 8956, DOI 10.17487/RFC8956, December 2020, <https://www.rfc-editor.org/info/rfc8956>.

[RFC8986]

Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, <https://www.rfc-editor.org/info/rfc8986>.

[RFC9012]

Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, "The BGP Tunnel Encapsulation Attribute", RFC 9012, DOI 10.17487/RFC9012, April 2021, <https://www.rfc-editor.org/info/rfc9012>.

[RFC9117]

Uttaro, J., Alcaide, J., Filsfils, C., Smith, D., and P. Mohapatra, "Revised Validation Procedure for BGP Flow Specifications", RFC 9117, DOI 10.17487/RFC9117, August 2021, <https://www.rfc-editor.org/info/rfc9117>.

[RFC9252]

Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene, B., Zhuang, S., and J. Rabadan, "BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)", RFC 9252, DOI 10.17487/RFC9252, July 2022, <https://www.rfc-editor.org/info/rfc9252>.

[RFC9256]

Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", RFC 9256, DOI 10.17487/RFC9256, July 2022, <https://www.rfc-editor.org/info/rfc9256>.

12.2. Informative References

[RFC5925]

Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>.

[RFC7942]

Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, <https://www.rfc-editor.org/info/rfc7942>.

[RFC8754]

Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, <https://www.rfc-editor.org/info/rfc8754>.

[RFC9830]

Previdi, S., Filsfils, C., Talaulikar, K., Ed., Mattes, P., and D. Jain, "Advertising Segment Routing Policies in BGP", RFC 9830, DOI 10.17487/RFC9830, September 2025, <https://www.rfc-editor.org/info/rfc9830>.

[RFC9862]

Koldychev, M., Sivabalan, S., Sidor, S., Barth, C., Peng, S., and H. Bidgoli, "Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing (SR) Policy Candidate Paths", RFC 9862, DOI 10.17487/RFC9862, October 2025, <https://www.rfc-editor.org/info/rfc9862>.