| Internet-Draft | intra-domain-od-sav | July 2025 |
| Li, et al. | Expires 22 January 2026 | [Page] |
Source Address Validation (SAV) mechanisms, such as uRPF, ACLs, and BM-SPF, are applied to prevent IP source address spoofing. However, these mechanisms are typically designed for static routing scenarios and deployed at fixed network boundaries.¶
With the increasing adoption of dynamic forwarding technologies such as SRv6 Policy and Fast Reroute (TI-FRR), the network's actual forwarding path may change frequently due to policy-based traffic steering or link failures. In such cases, statically deployed SAV rules may fail to validate traffic on newly activated or alternate paths, creating validation blind spots or even leading to false positives that block legitimate traffic.¶
This draft proposes an On-Demand Source Address Validation Activation mechanism. It enables routers to dynamically activate or update SAV rules on specific interfaces only when the interface becomes part of an active forwarding path due to policy or failover triggers. This approach enhances SAV coverage, avoids unnecessary resource consumption, and ensures SAV correctness under dynamic path switching scenarios driven by SRv6-policy and TI-FRR.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 22 January 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The security of IP networks depends heavily on the ability to verify the legitimacy of source addresses in data packets. Source Address Validation (SAV) serves as a foundational mechanism to mitigate IP spoofing attacks by enforcing policies that ensure packets originate from expected locations. Common SAV mechanisms include:¶
ACL-based filtering, where packet validation rules are manually configured on specific interfaces.¶
uRPF, which verifies that a packet’s source address is reachable via the receiving interface according to the FIB.¶
BM-SPF, which opens minimal set of interfaces based on IGP.[bmspf]¶
While effective in static or stable routing environments, these mechanisms face growing limitations in modern networks that adopt path engineering and fast reroute techniques.¶
In particular, Segment Routing over IPv6 (SRv6) [RFC8987] enables operators to define customized traffic paths (SRv6 Policies) that override shortest-path routing, while Topology-Independent Fast Reroute (TI-FRR) ensures traffic continues during link or node failures by instantly switching to backup paths. These capabilities introduce highly dynamic forwarding behavior, where the actual path of a data packet may change based on traffic type, policy reconfiguration, or network failure—without corresponding updates to the existing SAV rules deployed in the network.¶
Under such conditions:¶
SAV validation may be bypassed if the forwarding path traverses interfaces without validation rules (validation blind spot).¶
Legitimate traffic may be dropped if SAV rules mismatch the active path due to delayed or missing updates (false positives).¶
Resource overhead increases if operators pre-deploy SAV rules on all possible interfaces to anticipate changes (inefficient and hard to manage).¶
To address these issues, this draft introduces a mechanism for On-Demand Source Address Validation Activation, which dynamically installs, updates, or revokes SAV rules on interfaces based on real-time detection of path changes. The mechanism supports two representative trigger types:¶
SRv6 Policy Routing, where control-plane or application policies initiate path re-selection.¶
TI-FRR, where the forwarding plane autonomously switches to a precomputed backup path upon failure detection.¶
By aligning SAV activation with the actual packet forwarding path, the proposed mechanism improves security robustness, resource efficiency, and operational adaptability in dynamic networks.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] [RFC8174].¶
The following terms are used in this draft:¶
Segment Identifier (SID): An identifier for each path segment used to guide traffic within the network.¶
Segment List: An ordered list of SIDs that defines the path for traffic from the source to the destination.¶
SR-policy: Segment Routing policy, A policy consisting of one or more Segment Lists, each representing an alternate path.¶
FIB: Forwarding Information Base.¶
SAV: Source Address Validation.¶
uRPF: Unicast Reverse Path Forwarding.¶
BM‑SPF: Bidirectional Metric based Shortest Path First Mechanism.¶
FRR: Fast Reroute¶
TI‑LFA: Topology Independent Loop-Free Alternate.¶
SRv6: Segment Routing over IPv6.¶
Ingress/Egress: The starting/ending router in a forwarding path.¶
The On-Demand Source Address Validation (SAV) Activation Mechanism is a dynamic and path-aware validation approach designed to ensure precise and efficient spoofing prevention in networks where forwarding paths may change frequently due to control-plane policies or fast reroute events. Unlike traditional SAV mechanisms that rely on static interface bindings or shortest-path assumptions, the on-demand model provides interface-level validation granularity that closely follows actual packet forwarding behavior.¶
This mechanism is particularly tailored to support intra-domain deployments where advanced routing schemes—such as SRv6 Policy-based traffic steering and Topology-Independent Fast Reroute (TI-FRR)—are actively used to improve performance, availability, and flexibility. In these cases, packet forwarding may dynamically deviate from the IGP shortest path or revert rapidly to backup routes, rendering static SAV rules insufficient or ineffective.¶
The on-demand SAV mechanism is designed to meet the following goals:¶
Path-Coupled Validation Activation: SAV rules are activated only on interfaces that currently participate in forwarding traffic for protected source prefixes, minimizing resource consumption and false positives.¶
Trigger-Based Adaptivity: SAV activation responds in real-time to forwarding path changes triggered by:¶
Distributed and Lightweight Propagation: SAV-specific information (such as prefix/interface mappings) is propagated only to affected routers, allowing scalable and incremental rule installation without network-wide updates.¶
Fine-Grained Rule Lifecycle: SAV rules are assigned explicit activation conditions and expiry policies (e.g., duration, path reversion), ensuring timely withdrawal and state consistency.¶
The mechanism operates via a coordinated process involving core Workflow:¶
1. Trigger Detection:¶
Path changes are detected through control-plane events (e.g., SRv6 policy change notifications) or data-plane reactions (e.g., TI-FRR activation).¶
Each event is associated with a set of source address prefixes that require protection.¶
2. SAV-specfic information update and SAV rule Generation:¶
Local router logic computes the updated validation scope, which includes:¶
These information is encoded in SAV-specific messages and propagated from source router to validation entities (the routers that need to perform validation).¶
3. Rule Activation and Enforcement:¶
The proposed on-demand mechanism is not intended to replace existing SAV methods, but to complement them in scenarios where static validation falls short. In particular:¶
BM-SPF (Bidirectional Metric-based Shortest Path First) continues to serve as a reliable default for symmetric or IGP-derived paths.¶
On-demand activation is selectively applied only to forwarding paths resulting from:¶
Through this hybrid approach, operators can retain static validation as a baseline while dynamically extending coverage to alternate or policy-induced routes with minimal operational overhead.¶
The on-demand SAV mechanism is explicitly scoped to support two types of dynamic forwarding scenarios within a single administrative domain:¶
SRv6 Policy Paths: Where the control plane installs an explicit SID list to steer traffic along a non-default path, typically for application-aware routing or SLA enforcement.¶
TI-FRR Backup Paths: Where data-plane-level fast reroute mechanisms instantly switch traffic to precomputed backup next hops upon failure, requiring temporary and immediate SAV activation along the backup route.¶
Table.1 Trigger conditions for on-demand activation |---------------------|----------------------------------------|-------------------------------| | Trigger Type | Example Scenario | SAV Activation Scope | |---------------------|----------------------------------------|-------------------------------| | SRv6-policy | SRv6 SID list reroute |Prefixes/Interfaces on new path| | FRR Activation | TI-LFA backup engaged after failure |Prefixes backup path interfaces| |---------------------|----------------------------------------|-------------------------------|¶
Other scenarios such as ECMP, BGP-based inter-domain routing, or multicast are outside the scope of this specification, but may be considered in future extensions.¶
The On-Demand SAV mechanism is designed to complement and extend traditional SAV enforcement models in dynamic routing environments. It particularly addresses the validation gaps caused by traffic engineering changes and fast reroute mechanisms by dynamically activating SAV rules only on affected interfaces. Below we present two representative use cases: SRv6-policy based rerouting and TI-FRR based failure recovery.¶
In this intra-domain network, multiple types of traffic coexist, including latency-sensitive voice traffic and high-bandwidth file transfer traffic. These traffic types are routed differently based on service requirements:¶
Default Path: The shortest path computed by IGP (BM-SPF) is used: R1 → R2 → R3.¶
Policy-Driven Path (File Transfer/High Bandwidth Traffic): A Segment Routing over IPv6 (SRv6) policy instructs routers to use an alternate path with higher bandwidth capacity: R1 → R4 → R3¶
An SRv6 controller programs this policy using a SID (Segment Identifier) list and updates the forwarding path dynamically.¶
+-------------+
| Controller |
+-------------+
/ SRv6-policy
+-----+ +-----+ +-----+
| R1 |-------| R2 |-------| R3 |
+-----+ eth0 +-----+ +-----+
eth1 \ | / eth3
\ | /
+-----+
eth2 | R4 |
+-----+
+-----------------------+
| Host/Customer Network|
| Prefix: P_X |
+-----------------------+
Figure 1 An example of SRv6-Policy Based On-Demand SAV usecase
¶
In this scenario, when the policy change takes effect and traffic is redirected via R1 → R4 → R3, traditional IGP-based SAV at routers like R4 may not permit traffic originating from prefix P_X if that source was not expected on that interface. On-Demand SAV solves this by:¶
Dynamically activating SAV rules for prefix P_X on R4’s ingress interface (e.g., eth2) based on the updated SAV-specific information [architecture].¶
Ensuring that only traffic matching the expected policy is accepted.¶
Avoiding blanket SAV deactivation while preserving forwarding flexibility.¶
This selective activation protects against spoofing while allowing legitimate policy-driven traffic to be validated correctly.¶
In a second scenario, the network uses Topology-Independent Loop-Free Alternate (TI-LFA) for fast failure recovery. The default routing path is again: R1 → R2 → R3.¶
If Router R2 fails, TI-FRR is automatically triggered at R1. Traffic is rerouted via the pre-calculated backup path: R1 → R4 → R3. This fast rerouting is done locally without requiring immediate global convergence.¶
Under normal conditions, prefix P_X is associated with the primary path. SAV rules are installed accordingly on the primary interfaces (e.g., R2 and R3). When failure occurs:¶
Primary Path (eth0) SAV Downgrade: SAV checks may be disabled or relaxed on the now-inactive interface eth0 at R1.¶
Backup Path (eth1 → eth2 → eth3) SAV Activation: On-demand SAV is triggered on the interfaces along the backup path based on the updated SAV-specific information:¶
This ensures that even during transient forwarding path changes, prefix-based source validation continues to be enforced only on relevant interfaces, reducing the risk of spoofing or source address misvalidation.¶
+-----+ +-----+ +-----+
| R1 |-------| R2 |-------| R3 |
+-----+ eth0 +-----+ +-----+
eth1 \ | / eth3
\ | /
+-----+
eth2 | R4 |
+-----+
+-----------------------+
| Host/Customer Network|
| Prefix: P_X |
+-----------------------+
Figure 2 An example of TI-FRR Based On-Demand SAV usecase¶
TBD¶
The On-Demand Source Address Validation (SAV) mechanism offers a practical enhancement to existing SAV frameworks by enabling dynamic, policy-aware validation capabilities. Targeting scenarios with dynamic path switching such as SRv6 Policy-based routing and TI-FRR, this mechanism ensures that traffic traversing backup or non-default paths can still undergo precise source address validation, overcoming the limitations of traditional SAV methods.¶
By coupling route-aware control with dynamic rule activation, this mechanism installs SAV rules only when and where needed—at merge points or policy egress/ingress interfaces—thus reducing the overhead of global static configurations. It also aligns well with the principles of resource efficiency, minimal control plane impact, and fast adaptability to network changes.¶
As networks increasingly adopt path-aware forwarding and dynamic policy enforcement, the On-Demand SAV mechanism provides a forward-compatible foundation to maintain security guarantees without sacrificing flexibility. Future work may include interoperable signaling extensions, coordination with SRv6 controller behavior, and operational guidelines for real-world deployments.¶
TBD¶