| Internet-Draft | Intra-domain SAV Architecture | October 2026 |
| Li, et al. | Expires 4 April 2027 | [Page] |
This document describes a generic architecture for intra-domain Source Address Validation (SAV). It provides a common framework for developing new intra-domain SAV mechanisms and describes the conditions under which this architecture can improve SAV accuracy and operational efficiency with respect to existing intra-domain SAV mechanisms.¶
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 4 April 2027.¶
Copyright (c) 2026 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.¶
Autonomous System (AS) operators can adopt Source Address Validation (SAV) on routers to detect and mitigate source address spoofing. Intra-domain SAV is typically applied at external interfaces of routers facing entities that are not deployed as neighboring ASes, such as a single host, a set of hosts, or a customer network with no AS (see [I-D.ietf-savnet-intra-domain-problem-statement]). Such an entity may send data packets whose source addresses are outside the source address space that the entity is authorized to use for sourcing traffic. The core task of an intra-domain SAV mechanism is to determine the source address space that each such entity is authorized to use for sourcing traffic, and to validate the source address of each incoming packet against the source address space.¶
Existing intra-domain SAV mechanisms, such as [RFC2827] and [RFC3704], have limitations in SAV accuracy or operational overhead, as described in [I-D.ietf-savnet-intra-domain-problem-statement]. To help address these limitations, this document describes an architecture for intra-domain SAV. This architecture focuses on SAV rule generation at external interfaces of routers where intra-domain SAV is applied. SAV at external interfaces facing a neighboring AS, as well as SAV at internal interfaces, is outside the scope of this architecture. This architecture assumes that intra-domain routers are trusted and operate correctly. A compromised intra-domain router is outside the threat model of this architecture.¶
The architecture is designed to be generally applicable and extensible. It does not specify a particular mechanism, protocol, or algorithm, and does not assume pervasive deployment in an AS. Instead, it provides a basis for describing the conditions under which the architecture can improve SAV accuracy and operational efficiency with respect to existing intra-domain SAV mechanisms. The reader is expected to be familiar with [I-D.ietf-savnet-intra-domain-problem-statement].¶
The rule that indicates the validity of a specific source IP address or source IP prefix per router interface. It is used by a router to make SAV decisions.¶
A logical function that obtains information used for SAV rule generation, generates SAV rules, and provides the generated SAV rules to routers for application at specific external interfaces. A SAV Agent may be implemented on a router or in an operator-managed system. This document does not require a particular deployment location for the SAV Agent. Information can be provided through operator provisioning, obtained from the routing system, or acquired through a combination of these approaches.¶
The process by which an AS operator makes information available to a SAV Agent through configuration.¶
Information specialized for SAV rule generation, such as an explicit indication that a prefix is authorized for source-address use even though it is not represented in the routing system. This term describes the purpose of the information, rather than how it is provided to a SAV Agent.¶
A mechanism by which information used for SAV rule generation is made available to a SAV Agent when it is not locally available to that Agent. The delivery considered by this architecture takes place within the AS. It can use an existing management or control mechanism, an extension, or a new mechanism; this architecture does not prescribe a particular protocol.¶
A conceptual data store maintained by a SAV Agent. It contains information used for SAV rule generation.¶
Figure 1 illustrates the conceptual components and information flow of the intra-domain SAV architecture. The architecture centers on a SAV Agent, which is a logical function that obtains information used for SAV rule generation, generates SAV rules, and provides the generated SAV rules to routers for application at specific external interfaces. A SAV Agent may be implemented on a router or in another system. This document does not require a particular deployment location for the SAV Agent.¶
A SAV Agent obtains information used for SAV rule generation from sources within the AS, including routers and operator-managed systems. This architecture describes the information content separately from the means by which it is obtained. An operator can provide relevant prefix information and interface associations through provisioning, reusing information maintained for address allocation or routing configuration. A SAV Agent can also obtain relevant routing information from the routing system. These approaches can be used individually or in combination. This architecture does not prescribe a preferred approach; the choice depends on the available information and the operational environment.¶
A SAV Agent processes the available information and generates SAV rules for the corresponding external interfaces. For the purposes of this architecture, a source prefix that an attached entity is authorized to use is permitted on all external interfaces associated with that entity. Data-plane SAV enforcement is performed by routers at those interfaces by validating incoming packets against the SAV rules and applying the configured traffic handling policy to packets classified as invalid, as described in [I-D.ietf-savnet-general-sav-capabilities].¶
+----------------------------------------------------------+ | Within the AS | | | | +----------------------+ +--------------------------+ | | | Operator-managed | | Routing system | | | | information | | | | | +----------+-----------+ +------------+-------------+ | | | | | | Operator provisioning Acquisition from | | | the routing system | | | | | | +--------------+--------------+ | | v | | +-------------+ | | | SAV Agent | | | +------+------+ | | | SAV rules | | v | | +-----------------------------------------+ | | | Routers enforcing intra-domain SAV at | | | | the associated external interfaces | | | +-----------------------------------------+ | +----------------------------------------------------------+
SAV rule generation requires information that relates an attached entity to its external interfaces and permits the SAV Agent to determine the source address space that the entity is authorized to use. Relevant inputs include interface-to-entity associations, routing prefix information associated with the entity, and explicit source-address authorization information, including information about source-only prefixes.¶
The following subsections describe information content. The acquisition approaches described in Section 3.3 are not exclusive to a particular category of information.¶
Routing information describes routes and their associated forwarding behavior within the AS. Relevant prefix and attachment information can be represented in routing configuration or in the routing or forwarding state maintained by the routing system, such as RIBs or FIBs.¶
Routing information can indicate which destination prefixes are reachable through a particular external interface. However, prefix information at one external interface does not always directly or completely represent the source address space of the entity connected to that interface, especially in asymmetric-routing or hidden-prefix scenarios (see [I-D.ietf-savnet-intra-domain-problem-statement]).¶
Using interface-to-entity associations, prefix information associated with all external interfaces facing the same entity can be aggregated for SAV.¶
SAV-specific information is information dedicated to SAV rule generation. It may by itself provide sufficient information for SAV rule generation, or may be used together with routing information, depending on the mechanism and the information available.¶
SAV-specific information can explicitly identify authorized source prefixes, including source-only prefixes that are absent from routing information. It can also supply interface-to-entity associations when these are not available from existing routing information. Such information is useful in scenarios such as asymmetric routing and hidden prefixes.¶
Operator provisioning makes information needed for SAV available through configuration or an operator-managed system. It can draw on existing customer-registration, address-allocation, and routing-configuration records. For example, a common service record can be used to generate both routing configuration and input to SAV rule generation.¶
An operator provisioning information for SAV should consider the following:¶
Attachment associations: Identify the attached entity and the routers and external interfaces connected to it. When the entity is multihomed to multiple routers of the local AS, include all associated external interfaces.¶
Entity's prefixes assigned by the local AS: Reuse address-allocation or routing-configuration records that identify the prefixes assigned to the entity.¶
Entity's prefixes obtained independently of the local AS: For Bring Your Own IP (BYOIP) prefixes or prefixes assigned by another provider, the AS operator needs to require the entity to identify those prefixes and provide evidence of its authorization to use them as source prefixes. Such authorization needs to be represented even when no route for a prefix is configured or advertised by the entity.¶
Updates and withdrawal: Reflect changes in prefix assignments, source-address authorization, and attachment associations. These changes need to trigger updates to the affected SAV rules.¶
New intra-domain SAV solutions that leverage operator provisioning should describe the mapping from operational records to SAV inputs and how changes are made available to the SAV Agent.¶
A SAV Agent can acquire relevant routing information from the routing system through local access or existing routing, management, or control mechanisms. New intra-domain SAV solutions that leverage routing information from the routing system should identify the routing information used and its association with the attached entities and their external interfaces. Relevant changes in routing state can trigger acquisition of updated information and reevaluation of the affected SAV rules. Information that cannot be obtained from the routing system, such as authorization for source-only prefixes, needs to be supplied through operator provisioning.¶
Information acquisition can be a local operation when a SAV Agent and an information source are co-located. When information is delivered between separate components, the provider and receiver need to support a common delivery mechanism. The delivery considered here takes place within the AS and does not imply inter-AS signaling. Existing management or control mechanisms can be reused; extensions or new mechanisms are matters for solution design.¶
A solution needs to describe the information semantics and the update behavior of its acquisition approach. Information changes need to reach the SAV Agent in a timely manner so that the generated SAV rules can be updated.¶
These considerations apply to information provided through provisioning as well as information obtained from the routing system.¶
A SAV Agent is the logical function responsible for obtaining information used for SAV rule generation, maintaining a SAV Information Base, and generating SAV rules. A SAV Agent may be implemented on a router or in another system.¶
Figure 2 illustrates the conceptual processing model of a SAV Agent. Information obtained through the approaches in Section 3.3 is maintained in the SAV Information Base and used for SAV rule generation. These approaches do not impose a particular implementation location: for example, a configuration-generation function in an operator-managed system can implement a SAV Agent, as can a function on a router.¶
The SAV Information Base is a conceptual data store maintained by a SAV Agent. It contains information used for SAV rule generation, such as routing information associated with external interfaces, SAV-specific information associated with external interfaces or attached entities, and associations between attached entities and external interfaces.¶
+-----------------------------------------------+ | SAV Agent | | | | Acquired prefix information | | and interface associations | | | | | v | | +-------------------------------------------+ | | | SAV Information Base | | | +---------------------+---------------------+ | | | | | v | | SAV Rule Generator | | | | | v | | SAV Rules | +-----------------------------------------------+
A SAV Agent generates SAV rules based on information available in the SAV Information Base. The rule-generation algorithm is mechanism-specific and is not defined by this document.¶
For an external interface facing an attached entity, this architecture recommends generating allowlist-based SAV rules that identify the source addresses or source prefixes permitted on that interface. When the available information is known to be incomplete, the SAV mechanism needs to account for such incompleteness when generating and applying SAV rules so as to avoid improper blocking of legitimate traffic. Further considerations for incomplete information are described in Section 5.1.¶
The SAV Agent uses interface-to-entity associations to organize the available information for each attached entity. Relevant prefix information can be provided through operator provisioning, obtained from the routing system, or acquired through both approaches. Using this information, the SAV Agent determines the permitted source address space for the entity and generates the corresponding allowlist-based rules for all associated external interfaces, consistent with the model in Section 3.1.¶
When multiple inputs are used, they can overlap or provide complementary information. A solution needs to describe how these inputs are interpreted and reconciled, including their coverage and any inconsistencies.¶
Consider a customer network C with no AS, connected to external interface i1 on R1 and external interface i2 on R2 in the same AS. C can use source prefixes P1, P2, and H on both interfaces. P1 and P2 are represented in the relevant customer-facing routing information, while H is a hidden prefix (or source-only prefix) not represented in the routing system. For this example, the operator's address-allocation and routing policies establish that the relevant routes for P1 and P2 are suitable for deriving permitted source prefixes.¶
Within the AS
+------+ +------+
| R1 | | R2 |
+--+---+ +---+--+
| i1 | i2
| |
+--+-------------+---+
| Customer network C |
| P1, P2, and H |
+--------------------+
The architecture supports the following ways of obtaining the information for this example:¶
Through operator provisioning: An operator-managed system provides the association of C with i1 and i2 and the permitted prefixes P1, P2, and H. The information for P1 and P2 can be reused from existing address-allocation or routing-configuration records; H is explicitly recorded as an authorized source prefix.¶
From the routing system together with provisioning: The SAV Agent obtains the relevant routing information for P1 and P2 from the routing system and uses the provisioned association of C with i1 and i2. Authorization for H is explicitly provided through provisioning because H is absent from the relevant routing information.¶
In either approach, the AS operator should require the customer to disclose the use of prefix H and provide evidence that the customer is authorized to use that prefix.¶
Both approaches provide the information needed to generate allowlists permitting P1, P2, and H on i1 and i2. If a further routing-visible prefix P3 is assigned to C and authorized for source use, the first approach reflects it through an update derived from the operational records. The second approach obtains it from the updated relevant routing information. In either case, the SAV Agent updates the rules for both interfaces. A change to authorization for H is reflected through provisioning in both approaches.¶
This example illustrates alternative acquisition approaches that achieve the same SAV result. The integration and update mechanisms needed for either approach depend on the existing systems and the solution design.¶
After SAV rules are generated by a SAV Agent, they are installed on routers that apply intra-domain SAV at the corresponding external interfaces. Data-plane SAV enforcement is the process of validating incoming packets against the installed SAV rules and applying the configured traffic handling policy to packets classified as invalid.¶
The action for packets classified as invalid is a matter of local policy and deployment stage. A deployment can initially use monitoring, logging, sampling, rate-limiting, redirecting, or other conservative actions before enabling strict dropping. Further considerations for data-plane SAV capabilities are described in [I-D.ietf-savnet-general-sav-capabilities].¶
Existing intra-domain SAV mechanisms can determine the permitted source address space using local forwarding information, as in uRPF [RFC3704], or explicitly configured source-prefix information, as in ACL-based ingress filtering [RFC2827]. Local forwarding information can provide an incomplete view for a multihomed entity or fail to represent hidden prefixes. Explicit ACL configuration can accurately represent permitted source prefixes, but deployments that maintain SAV rules independently through manual operations can incur maintenance overhead.¶
The architecture describes how a SAV Agent can use prefix information and interface associations, acquired through the approaches in Section 3.3, to generate and maintain SAV rules.¶
The architecture can improve SAV accuracy when the information available to the SAV Agent more completely represents the source address space permitted on an interface than the information available to existing intra-domain SAV mechanisms.¶
For example, information relating an entity's permitted source prefixes to all its associated interfaces can avoid the limitations of a single router's reverse-path view in asymmetric routing. This information can be provided through provisioning or obtained by considering relevant routing information across the associated interfaces together with their entity associations. Explicit authorization information can also identify legitimate source prefixes absent from routing information, such as hidden or source-only prefixes. The example in Section 3.5.1 illustrates how different acquisition approaches can provide the information needed for the same SAV rules.¶
With additional information, new intra-domain SAV mechanisms can generate more accurate SAV rules, avoiding or reducing improper blocks and improper permits. Improvement does not require pervasive deployment and can be achieved at the external interfaces where the required information is available and the rules are enforced.¶
Mechanisms following this architecture can reduce operational overhead by reusing information already maintained within the AS and by automating information acquisition, processing, and SAV rule updates. Reuse can be implemented through operator provisioning that draws on existing operational data, through acquisition of relevant information from the routing system, or through a combination of these approaches.¶
For example, a provisioning system can use a single customer-prefix record to generate routing configuration and input to SAV rule generation. Alternatively, a SAV Agent can acquire relevant prefix information from the routing system and receive other necessary information through provisioning. Both approaches can avoid a separately maintained SAV prefix inventory for information already available elsewhere, while explicit authorization for hidden or source-only prefixes still needs to be recorded.¶
Compared with deployments that maintain SAV rules independently through manual operations, such automation can reduce duplicate maintenance and the risk of inconsistent updates. It does not eliminate information delivery or rule installation delays. The extent of the benefit depends on existing operational systems, available information, and the additional functions and integration required.¶
Incremental deployment can proceed along two dimensions: the incremental availability of information required for SAV rule generation, and the incremental application of SAV rules at routers.¶
The information required by a mechanism may be available for some external interfaces or attached entities, but unavailable or incomplete for others. For example, a mechanism that relies on SAV-specific information may have such information available only for a subset of attached entities. In such cases, a SAV Agent may be able to determine the permitted source address space for some external interfaces or attached entities, but may be unable to do so with sufficient completeness for others. When the information required by the mechanism is unavailable or incomplete, operators are encouraged to use conservative traffic handling policies. Such policies may include logging, monitoring, rate-limiting, or other conservative actions before strict blocking is enabled.¶
Incremental application of SAV rules means that SAV rules are applied only at selected routers or external interfaces. This can occur due to phased deployment plans, multi-vendor environments, operational risk management, or differences in device capability. Such deployment can still provide protection at the interfaces where SAV rules are applied, without requiring pervasive deployment across all routers in an AS.¶
Operators should consider deployment consistency when the same entity is attached to multiple external interfaces of routers in the AS. Under the model in Section 3.1, the entity's permitted source address space applies to all associated external interfaces. Incremental enforcement at only a subset of these interfaces can leave paths through which traffic with spoofed source addresses may enter the AS without validation.¶
Operational visibility is important for deploying and maintaining intra-domain SAV. Operators need to be able to observe validation results and traffic handling outcomes at external interfaces where intra-domain SAV is applied. This helps operators assess whether incoming packets are classified as expected and whether packets classified as invalid are handled according to the configured traffic handling policy. Operators should use telemetry mechanisms to monitor the behavior of intra-domain SAV and collect relevant information for further analysis.¶
Changes to routing-derived or operator-provisioned source-prefix information may take time to be reflected in an installed SAV allowlist. An implementation should avoid enforcing a partially generated or partially installed allowlist update when doing so could improperly block legitimate traffic. During the update, the implementation may continue to use a previously installed allowlist if it remains valid, or apply a conservative traffic handling policy until the updated allowlist is ready for use.¶
Before activating an updated allowlist on an interface, the implementation should determine that the information required for the update has been obtained and that the corresponding SAV rules have been generated and installed. The means of determining completion and coordinating activation are implementation-dependent. Related synchronization considerations between SAV enforcement state and forwarding state are discussed in [I-D.haas-savnet-inter-domain-scaling].¶
The security and privacy properties of a specific intra-domain SAV mechanism depend on how the information used for SAV rule generation is obtained, delivered, stored, and used. Incorrect or unauthorized modification of such information may result in improper permitting or improper blocking of traffic. Information used for SAV rule generation needs to be obtained from sources authorized or trusted by the AS operator.¶
Information supplied by an attached entity does not by itself establish that a prefix is authorized for source-address use. In particular, authorization information for prefixes obtained independently of the local AS needs to be validated according to the operator's policy.¶
Information used for SAV rule generation may contain private or sensitive operational information. Its delivery and storage need to be controlled, and such information should not be disclosed outside the AS.¶
This document has no IANA requirements.¶
The authors thank Igor Lubashev, Alvaro Retana, Aijun Wang, Joel Halpern, Jared Mauch, Kotikalapudi Sriram, Rüdiger Volk, Jeffrey Haas, Xiangqing Chang, Changwang Lin, Xueyan Song, and others for their valuable comments.¶