Intra-domain Source Address Validation Architecture
draft-ietf-savnet-intra-domain-architecture-04
| Document | Type | Active Internet-Draft (savnet WG) | |
|---|---|---|---|
| Authors | Dan Li , Jianping Wu , Lancheng Qin , Nan Geng , Li Chen | ||
| Last updated | 2026-06-29 | ||
| 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-04
SAVNET D. Li
Internet-Draft J. Wu
Intended status: Informational Tsinghua University
Expires: 31 December 2026 L. Qin
Zhongguancun Laboratory
N. Geng
Huawei
L. Chen
Zhongguancun Laboratory
29 June 2026
Intra-domain Source Address Validation Architecture
draft-ietf-savnet-intra-domain-architecture-04
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 such mechanisms can improve SAV accuracy 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 31 December 2026.
Copyright Notice
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.
Li, et al. Expires 31 December 2026 [Page 1]
Internet-Draft Intra-domain SAV Architecture June 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Information Used for SAV Rule Generation . . . . . . . . 5
3.2.1. Routing Information . . . . . . . . . . . . . . . . . 5
3.2.2. SAV-specific Information . . . . . . . . . . . . . . 6
3.3. SAV-specific Information Delivery . . . . . . . . . . . . 6
3.4. SAV Agent and SAV Information Base . . . . . . . . . . . 7
3.5. SAV Rule Generation . . . . . . . . . . . . . . . . . . . 8
3.6. SAV Rule Installation and Data-plane Enforcement . . . . 8
4. Conditions for Improvement over Existing SAV Mechanisms . . . 9
5. Operational Considerations . . . . . . . . . . . . . . . . . 9
5.1. Incremental Deployment . . . . . . . . . . . . . . . . . 9
5.2. Operational Visibility and Troubleshooting . . . . . . . 10
6. Security and Privacy Considerations . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
Autonomous System (AS) operators can adopt Source Address Validation
(SAV) on routers to detect and mitigate data packets with spoofed
source addresses. 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.
Li, et al. Expires 31 December 2026 [Page 2]
Internet-Draft Intra-domain SAV Architecture June 2026
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 data
packets with spoofed source addresses that arrive 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 with respect to
existing intra-domain SAV mechanisms. The reader is expected to be
familiar with [I-D.ietf-savnet-intra-domain-problem-statement].
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
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-specific Information:
Information specialized for SAV rule generation. SAV-specific
information may be exchanged among routers within an AS, or may be
provided by an operator-managed system operated by the AS
operator. It can describe the source address space that an
attached entity, such as a single host, a set of hosts, or a
customer network with no AS, is authorized to use for sourcing
traffic.
SAV-specific Information Delivery Mechanism:
Li, et al. Expires 31 December 2026 [Page 3]
Internet-Draft Intra-domain SAV Architecture June 2026
A mechanism by which SAV-specific information is made available to
a SAV Agent when the information is not locally available to that
SAV Agent. Such a mechanism may be realized by reusing an
existing mechanism/protocol, extending an existing mechanism/
protocol, or defining a new mechanism/protocol.
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 another system.
This document does not require a particular deployment location
for the SAV Agent. The information used by a SAV Agent includes
SAV-specific information and may also include routing information,
depending on the mechanism.
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 can obtain information used for SAV rule generation from
information sources within the AS, including routers within the AS
and operator-managed systems. Such information includes SAV-specific
information and routing information. A SAV Agent processes the
available information and generates SAV rules. The generated SAV
rules are made available to routers for application at the
corresponding external interfaces. Data-plane SAV enforcement is
performed by routers at those external interfaces by validating
incoming packets against those SAV rules and applying the configured
traffic handling policy to packets classified as invalid, as
described in [I-D.ietf-savnet-general-sav-capabilities].
Li, et al. Expires 31 December 2026 [Page 4]
Internet-Draft Intra-domain SAV Architecture June 2026
+--------------------------------------+
| Information Sources |
| |
| +----------------+ +--------------+ |
| | Routers within | | Operator- | |
| | the AS | | managed | |
| | | | System | |
| +----------------+ +--------------+ |
+------------------+-------------------+
|
| SAV-specific information
| and routing information
v
+------------------+------------------+
| SAV Agent |
+------------------+------------------+
|
| SAV rules
v
+------------------+------------------+
| Specific external interfaces |
| of routers where intra- |
| domain SAV is applied |
+-------------------------------------+
Figure 1: Conceptual components and information flow of the
intra-domain SAV architecture.
3.2. Information Used for SAV Rule Generation
A SAV Agent uses information available to it to generate SAV rules.
For intra-domain SAV, such information includes SAV-specific
information and routing information.
3.2.1. Routing Information
Routing information includes information in RIBs or FIBs on routers
within the AS, as well as information locally configured by the AS
operator to populate or interpret routing and forwarding state. Such
configuration information may include prefix allocation, route
origination configuration, or other routing-related configuration
provided by the AS operator.
Routing information expresses reachability and forwarding behavior.
For example, it can indicate which destination prefixes are reachable
through a particular interface, or which prefixes are originated by a
customer network of the AS operator.
Li, et al. Expires 31 December 2026 [Page 5]
Internet-Draft Intra-domain SAV Architecture June 2026
An intra-domain SAV mechanism may use routing information as an input
for SAV rule generation. For example, routing prefixes associated
with an attached entity may be used as part of the source address
space that the entity is able to use for sourcing traffic. However,
routing information does not always directly or completely represent
source-address authorization, especially in asymmetric routing or
hidden-prefix scenarios (see
[I-D.ietf-savnet-intra-domain-problem-statement]).
3.2.2. SAV-specific Information
SAV-specific information is information dedicated to SAV rule
generation. It describes source-address authorization information
that cannot be directly or completely inferred from routing
information alone. Such information is expected to indicate the
source address space that an attached entity is authorized to use for
sourcing traffic.
SAV-specific information can be provided by routers within the AS. A
router may have local information about an attached entity, such as
the external interface facing the entity, the local attachment
context, or source-prefix information associated with that
attachment. When the same entity is attached to multiple external
interfaces of routers within the AS, SAV-specific information from
these routers can help a SAV Agent identify that these interfaces are
associated with the same entity and should be considered in the same
source-address authorization context. Such information is useful in
asymmetric-route scenarios.
SAV-specific information can also be provided by operator-managed
systems within the AS. Such systems may provide SAV-specific
information that is not available from routers alone, including
source prefixes that are not advertised to the AS but are authorized
for use as source addresses by an attached entity. Such information
is useful in hidden-prefix scenarios.
A SAV Agent may use SAV-specific information obtained from routers,
operator-managed systems, or both, depending on the mechanism.
3.3. SAV-specific Information Delivery
A SAV-specific information delivery mechanism makes SAV-specific
information available to a SAV Agent when the information is not
locally available to that SAV Agent. The information provider and
the information receiver need to support a common delivery mechanism.
Such a mechanism may be realized by reusing an existing mechanism/
protocol, extending an existing mechanism/protocol, or defining a new
mechanism/protocol.
Li, et al. Expires 31 December 2026 [Page 6]
Internet-Draft Intra-domain SAV Architecture June 2026
A solution that defines a SAV-specific information delivery mechanism
should define the information semantics, encoding, transport or
management method, update behavior, and error handling appropriate
for that mechanism. When SAV-specific information changes, the SAV
Agent (or information receiver) needs to be able to obtain the
updated information in a timely manner so that the generated SAV
rules can remain consistent with the latest state.
The SAV-specific information delivery mechanism should provide
appropriate session security protection. This includes
authentication of the communicating entities and integrity protection
for the delivered information. When SAV-specific information
contains private or sensitive operational information, the delivery
mechanism also needs to provide confidentiality protection or
otherwise prevent disclosure to unauthorized entities.
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.
The SAV Agent obtains SAV-specific information and routing
information from routers and operator-managed systems within the AS.
The SAV Agent maintains the SAV Information Base and uses it to
generate SAV rules.
The SAV Information Base is a conceptual data store maintained by a
SAV Agent. It contains information used for SAV rule generation. It
may also contain metadata needed by the SAV Agent to interpret or
select information for rule generation, such as information source or
freshness.
Li, et al. Expires 31 December 2026 [Page 7]
Internet-Draft Intra-domain SAV Architecture June 2026
+-----------------------------------------------+
| SAV Agent |
| |
| SAV-specific information Routing information |
| + + |
| | | |
| | | |
| v 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.
The generated SAV rules identify whether a source address or source
prefix is valid for a particular external interface. Any new intra-
domain SAV mechanism needs to define how the SAV Agent uses SAV-
specific information and routing information for SAV rule generation.
It also needs to define how the SAV Agent handles missing, stale, or
conflicting information according to the mechanism design and
operator policy.
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.
Li, et al. Expires 31 December 2026 [Page 8]
Internet-Draft Intra-domain SAV Architecture June 2026
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. Conditions for Improvement over Existing SAV Mechanisms
The architecture can improve SAV accuracy with respect to existing
mechanisms when a SAV Agent can use SAV-specific information to
complement routing information for SAV rule generation. Routing
information can indicate reachability and forwarding behavior, but it
does not always directly or completely represent the source address
space that an attached entity is authorized to use for sourcing
traffic. Therefore, improvement depends on whether the required SAV-
specific information is available to provide information beyond the
routing information available within the AS, as described in
Section 3.2.2.
In particular, SAV-specific information can help a SAV Agent more
completely determine the source address space authorized for an
attached entity. For example, SAV-specific information may indicate
that the same entity is attached to multiple external interfaces of
routers within the AS, or that the entity is authorized to use source
prefixes that are not advertised to the AS as routing information.
Such information can improve SAV rule accuracy in asymmetric-route or
hidden-prefix scenarios, and can reduce or avoid improper blocking of
legitimate traffic and improper permitting of traffic with spoofed
source addresses.
In addition, SAV-specific information needs to be authoritative or
trusted according to the trust model and operational policy of the AS
operator. The architecture can also reduce operational overhead with
respect to manually configured filtering when SAV-specific
information can be automatically obtained, updated, and used for SAV
rule generation. SAV-specific information delivery needs to support
automatic updates when the information at the corresponding
information source changes, so that a SAV Agent can learn the latest
SAV-specific information in a timely manner.
5. Operational Considerations
5.1. Incremental Deployment
Incremental deployment can occur in two different aspects: the
incremental availability of SAV-specific information, and the
incremental application of SAV rules at routers.
Li, et al. Expires 31 December 2026 [Page 9]
Internet-Draft Intra-domain SAV Architecture June 2026
Incremental availability of SAV-specific information means that the
SAV-specific information required by a mechanism may be available for
some external interfaces or attached entities, but unavailable for
others. In such cases, a SAV Agent may be able to determine the
source address space authorized for some attached entities, but may
be unable to do so for others. When the required SAV-specific
information is unavailable for some external interfaces or attached
entities, operators are encouraged to use conservative traffic
handling policies. Such policies may include logging, monitoring,
rate-limiting, or other non-dropping 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.
For example, if the entity is authorized to use a particular source
address space, SAV rules for that source address space may need to be
applied at all relevant external interfaces facing that entity. If
SAV rules are applied only at a subset of these interfaces, traffic
with spoofed source addresses may still enter the AS through
interfaces where SAV rules are not applied.
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.
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.
Li, et al. Expires 31 December 2026 [Page 10]
Internet-Draft Intra-domain SAV Architecture June 2026
Information used for SAV rule generation needs to be authoritative or
trusted within the AS. A SAV Agent needs to use such information
according to the trust model and operational policy of the AS
operator.
When SAV-specific information is delivered to a SAV Agent, the
delivery mechanism needs to provide session security protection.
This includes authentication of the communicating entities and
integrity protection for the delivered information. These
protections are needed to ensure that the SAV Agent can verify the
source of the information and that the information is not modified
during delivery.
SAV-specific information may contain private or sensitive operational
information. Therefore, delivery of SAV-specific information needs
to be controlled within the AS and must not disclose such information
outside the AS unless explicitly authorized by the AS operator. A
SAV Information Base stores information used for SAV rule generation.
Access to the SAV Information Base needs to be controlled so that
only authorized components or operators can read or modify the stored
information.
7. IANA Considerations
This document has no IANA requirements.
8. Contributors
Mingqing Huang
Email: huangmq@vip.sina.com
Fang Gao
Email: fredagao520@sina.com
9. Acknowledgements
Many thanks to the valuable comments from: Igor Lubashev, Alvaro
Retana, Aijun Wang, Joel Halpern, Jared Mauch, Kotikalapudi Sriram,
Rüdiger Volk, Jeffrey Haas, Xiangqing Chang, Changwang Lin, Xueyan
Song, etc.
10. References
10.1. Normative References
Li, et al. Expires 31 December 2026 [Page 11]
Internet-Draft Intra-domain SAV Architecture June 2026
[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>.
[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>.
[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>.
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>.
Authors' Addresses
Dan Li
Tsinghua University
Beijing
China
Email: tolidan@tsinghua.edu.cn
Li, et al. Expires 31 December 2026 [Page 12]
Internet-Draft Intra-domain SAV Architecture June 2026
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 31 December 2026 [Page 13]