Intra-domain Source Address Validation Architecture
draft-ietf-savnet-intra-domain-architecture-05
| Document | Type | Active Internet-Draft (savnet WG) | |
|---|---|---|---|
| Authors | Dan Li , Jianping Wu , Lancheng Qin , Nan Geng , Li Chen | ||
| Last updated | 2026-09-30 | ||
| Replaces | draft-li-savnet-intra-domain-architecture | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Associated WG milestone |
|
||
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-savnet-intra-domain-architecture-05
SAVNET D. Li
Internet-Draft J. Wu
Intended status: Informational Tsinghua University
Expires: 4 April 2027 L. Qin
Zhongguancun Laboratory
N. Geng
Huawei
L. Chen
Zhongguancun Laboratory
1 October 2026
Intra-domain Source Address Validation Architecture
draft-ietf-savnet-intra-domain-architecture-05
Abstract
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.
Status of This Memo
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 Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Li, et al. Expires 4 April 2027 [Page 1]
Internet-Draft Intra-domain SAV Architecture October 2026
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Information Used for SAV Rule Generation . . . . . . . . 6
3.2.1. Routing Information . . . . . . . . . . . . . . . . . 6
3.2.2. SAV-specific Information . . . . . . . . . . . . . . 6
3.3. Information Acquisition and Delivery . . . . . . . . . . 7
3.3.1. Operator Provisioning . . . . . . . . . . . . . . . . 7
3.3.2. Acquisition from the Routing System . . . . . . . . . 7
3.3.3. Information Delivery Considerations . . . . . . . . . 8
3.4. SAV Agent and SAV Information Base . . . . . . . . . . . 8
3.5. SAV Rule Generation . . . . . . . . . . . . . . . . . . . 9
3.5.1. Example of Information Acquisition and Rule
Generation . . . . . . . . . . . . . . . . . . . . . 10
3.6. SAV Rule Installation and Data-plane Enforcement . . . . 11
4. Improvement over Existing SAV Mechanisms . . . . . . . . . . 11
4.1. Accuracy Improvement . . . . . . . . . . . . . . . . . . 11
4.2. Operational Efficiency Improvement . . . . . . . . . . . 12
5. Operational Considerations . . . . . . . . . . . . . . . . . 13
5.1. Incremental Deployment . . . . . . . . . . . . . . . . . 13
5.2. Operational Visibility and Troubleshooting . . . . . . . 13
5.3. SAV Allowlist Update Consistency . . . . . . . . . . . . 14
6. Security and Privacy Considerations . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
Li, et al. Expires 4 April 2027 [Page 2]
Internet-Draft Intra-domain SAV Architecture October 2026
1. Introduction
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].
2. Terminology
SAV Rule:
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.
SAV Agent:
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-
Li, et al. Expires 4 April 2027 [Page 3]
Internet-Draft Intra-domain SAV Architecture October 2026
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.
Operator Provisioning:
The process by which an AS operator makes information available to
a SAV Agent through configuration.
SAV-specific Information:
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.
Information Delivery Mechanism:
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.
SAV Information Base:
A conceptual data store maintained by a SAV Agent. It contains
information used for SAV rule generation.
3. Architecture
3.1. Overview
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
Li, et al. Expires 4 April 2027 [Page 4]
Internet-Draft Intra-domain SAV Architecture October 2026
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 | |
| +-----------------------------------------+ |
+----------------------------------------------------------+
Figure 1: Conceptual components and information flow of the
intra-domain SAV architecture.
Li, et al. Expires 4 April 2027 [Page 5]
Internet-Draft Intra-domain SAV Architecture October 2026
3.2. Information Used for SAV Rule Generation
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.
3.2.1. Routing 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.
3.2.2. SAV-specific Information
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.
Li, et al. Expires 4 April 2027 [Page 6]
Internet-Draft Intra-domain SAV Architecture October 2026
3.3. Information Acquisition and Delivery
3.3.1. Operator Provisioning
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.
3.3.2. Acquisition from the Routing System
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
Li, et al. Expires 4 April 2027 [Page 7]
Internet-Draft Intra-domain SAV Architecture October 2026
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.
3.3.3. Information Delivery Considerations
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.
3.4. SAV Agent and SAV Information Base
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.
Li, et al. Expires 4 April 2027 [Page 8]
Internet-Draft Intra-domain SAV Architecture October 2026
+-----------------------------------------------+
| SAV Agent |
| |
| Acquired prefix information |
| and interface associations |
| | |
| v |
| +-------------------------------------------+ |
| | SAV Information Base | |
| +---------------------+---------------------+ |
| | |
| v |
| SAV Rule Generator |
| | |
| v |
| SAV Rules |
+-----------------------------------------------+
Figure 2: Conceptual SAV Agent processing model
3.5. SAV Rule Generation
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.
Li, et al. Expires 4 April 2027 [Page 9]
Internet-Draft Intra-domain SAV Architecture October 2026
3.5.1. Example of Information Acquisition and Rule Generation
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 |
+--------------------+
Figure 3: A customer network attached through two external
interfaces.
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
Li, et al. Expires 4 April 2027 [Page 10]
Internet-Draft Intra-domain SAV Architecture October 2026
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.
3.6. SAV Rule Installation and Data-plane Enforcement
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].
4. Improvement over Existing SAV Mechanisms
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.
4.1. Accuracy Improvement
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.
Li, et al. Expires 4 April 2027 [Page 11]
Internet-Draft Intra-domain SAV Architecture October 2026
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.
4.2. Operational Efficiency Improvement
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.
Li, et al. Expires 4 April 2027 [Page 12]
Internet-Draft Intra-domain SAV Architecture October 2026
5. Operational Considerations
5.1. Incremental Deployment
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.
5.2. Operational Visibility and Troubleshooting
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.
Li, et al. Expires 4 April 2027 [Page 13]
Internet-Draft Intra-domain SAV Architecture October 2026
5.3. SAV Allowlist Update Consistency
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].
6. Security and Privacy Considerations
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.
7. IANA Considerations
This document has no IANA requirements.
Li, et al. Expires 4 April 2027 [Page 14]
Internet-Draft Intra-domain SAV Architecture October 2026
8. Contributors
Mingqing Huang
Email: huangmq@vip.sina.com
Fang Gao
Email: fredagao520@sina.com
9. Acknowledgements
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.
10. References
10.1. Normative References
[I-D.ietf-savnet-intra-domain-problem-statement]
Qin, L., Li, D., Wu, J., Huang, M., and N. Geng, "Problem
Statement, Gap Analysis, and Requirements for Intra-domain
Source Address Validation", Work in Progress, Internet-
Draft, draft-ietf-savnet-intra-domain-problem-statement-
26, 1 June 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-savnet-intra-domain-problem-statement-26>.
10.2. Informative References
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
2004, <https://www.rfc-editor.org/info/rfc3704>.
[I-D.ietf-savnet-general-sav-capabilities]
Huang, M., Cheng, W., Li, D., Geng, N., and L. Chen,
"General Source Address Validation Capabilities", Work in
Progress, Internet-Draft, draft-ietf-savnet-general-sav-
capabilities-03, 21 June 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-savnet-
general-sav-capabilities-03>.
Li, et al. Expires 4 April 2027 [Page 15]
Internet-Draft Intra-domain SAV Architecture October 2026
[I-D.haas-savnet-inter-domain-scaling]
Haas, J., "Inter-domain scaling considerations for source
address validation (SAV)", Work in Progress, Internet-
Draft, draft-haas-savnet-inter-domain-scaling-00, 4 July
2025, <https://datatracker.ietf.org/doc/html/draft-haas-
savnet-inter-domain-scaling-00>.
Authors' Addresses
Dan Li
Tsinghua University
Beijing
China
Email: tolidan@tsinghua.edu.cn
Jianping Wu
Tsinghua University
Beijing
China
Email: jianping@cernet.edu.cn
Lancheng Qin
Zhongguancun Laboratory
Beijing
China
Email: qinlc@mail.zgclab.edu.cn
Nan Geng
Huawei
Beijing
China
Email: gengnan@huawei.com
Li Chen
Zhongguancun Laboratory
Beijing
China
Email: lichen@zgclab.edu.cn
Li, et al. Expires 4 April 2027 [Page 16]