SAVNET D. Li Internet-Draft Tsinghua University Intended status: Standards Track L. Chen Expires: 15 April 2027 Zhongguancun Laboratory N. Geng Huawei L. Liu L. Qin Zhongguancun Laboratory 12 October 2026 Inter-domain Source Address Validation (SAVNET) Architecture draft-ietf-savnet-inter-domain-architecture-04 Abstract This document specifies an architecture for inter-domain source address validation (SAV). The architecture provides a common framework for collecting SAV-specific and SAV-related information from multiple sources, determining the legitimate incoming directions of source prefixes, and using this information to generate SAV table for inter-domain SAV. A SAV agent maintains the collected information in a SAV Information Base (SIB), and the SAV Information Base Manager (SIM) uses the available information to determine the corresponding prefix and legitimate incoming-direction mappings and generate or update the SAV table. This document also defines the architectural components and communication framework of inter-domain SAV, and discusses deployment, operation, convergence, manageability, security, and privacy considerations. It does not define a specific SAV protocol, protocol extension, or SAV table generation algorithm. 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 15 April 2027. Li, et al. Expires 15 April 2027 [Page 1] Internet-Draft Inter-domain SAVNET Architecture October 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. 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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Inter-domain SAVNET Architecture Overview . . . . . . . . . . 6 3.1. SAV Table Generation Design Recommendations . . . . . . . 10 4. SAV Information Sources . . . . . . . . . . . . . . . . . . . 11 4.1. SAV-related Information . . . . . . . . . . . . . . . . . 11 4.1.1. RPKI ROA objects and ASPA Objects . . . . . . . . . . 11 4.1.2. Routing Information . . . . . . . . . . . . . . . . . 12 4.1.3. IRR Data . . . . . . . . . . . . . . . . . . . . . . 12 4.2. SAV-specific Information . . . . . . . . . . . . . . . . 12 5. SAV Information Base . . . . . . . . . . . . . . . . . . . . 13 6. SAVNET Communication Mechanism . . . . . . . . . . . . . . . 18 6.1. SAV-related Information Communication Mechanism . . . . . 19 6.2. SAV-specific Information Communication Mechanism . . . . 19 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 23 8. Operational Considerations . . . . . . . . . . . . . . . . . 24 9. Convergence Considerations . . . . . . . . . . . . . . . . . 25 10. Manageability Considerations . . . . . . . . . . . . . . . . 26 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 28 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 14. Scope and Assumptions . . . . . . . . . . . . . . . . . . . . 29 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 16.1. Normative References . . . . . . . . . . . . . . . . . . 31 16.2. Informative References . . . . . . . . . . . . . . . . . 31 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Li, et al. Expires 15 April 2027 [Page 2] Internet-Draft Inter-domain SAVNET Architecture October 2026 1. Introduction Attacks based on source IP address spoofing, such as reflective DDoS and flooding attacks, continue to present significant challenges to Internet security. Mitigating these attacks in inter-domain networks requires effective source address validation (SAV). While BCP84 [RFC3704] [RFC8704] offers some SAV solutions, such as ACL-based ingress filtering and uRPF-based mechanisms, existing inter-domain SAV mechanisms have limitations in terms of validation accuracy and operational overhead in different scenarios [I-D.ietf-savnet-inter-domain-problem-statement]. There are various information sources Section 4 that can contribute to inter-domain SAV, including SAV-specific information, RPKI ROA and ASPA objects, routing information in the RIB or FIB, IRR data, and operator-provided configuration information. For accurate SAV table generation, the architecture aims to provide the guidance for determining the legitimate incoming directions for each source prefix. Ideally, the validation AS Section 2 obtains the complete set of legitimate incoming directions for a prefix; when only partial information is available, a SAV mechanism can generate more conservative rules according to the completeness and confidence of the available information. This information can be represented as a set of pairs. For a given source prefix, knowledge of all its legitimate incoming directions enables the validation AS to distinguish interfaces from which legitimate traffic using the prefix may arrive from interfaces from which such traffic should not arrive. Different SAV information sources provide different information for determining these pairs. SAV-specific information Section 2 is produced specifically for SAV and may directly describe legitimate incoming directions of source prefixes or provide SAV-specific information from which these directions can be determined. SAV- related information Section 2 is originally produced for other purposes but can also provide evidence for determining legitimate incoming directions. For example, a ROA associates a prefix with its authorized origin AS, an ASPA provides information about provider authorizations made by customer ASes, routing information reflects locally learned routing or forwarding information for prefixes, and IRR data can provide registered associations between prefixes and ASes and AS-set membership information. Operator-provided configuration information can additionally describe prefixes and forwarding behavior that may not be visible through inter-domain routing. Li, et al. Expires 15 April 2027 [Page 3] Internet-Draft Inter-domain SAVNET Architecture October 2026 No individual SAV information source is able to provide the complete set of legitimate incoming directions for every prefix. For example, routing information alone may not identify all legitimate incoming directions in asymmetric routing, limited propagation, or hidden- prefix scenarios. RPKI-derived information can provide cryptographically verifiable prefix-origin authorization and customer-provider authorization information, but its usefulness for SAV depends on deployment coverage. SAV-specific information can provide information more directly targeted at SAV, but its availability may also depend on deployment of the corresponding SAV mechanism. The inter-domain SAVNET architecture therefore allows a SAV agent to gather information from multiple SAV-specific and SAV-related information sources into the SAV Information Base (SIB). The SAV Information Base Manager (SIM) uses the available information to determine or verify the legitimate incoming directions associated with source prefixes and to generate the corresponding SAV table. Different information sources may complement each other. A specific SAV mechanism can determine how they are combined according to factors such as their availability, scope, completeness, freshness, trustworthiness, and the applicable SAV scenario. When SAV-specific information needs to be exchanged between SAV agents, a SAV-specific information communication mechanism can be used for originating, processing, communicating, updating, and withdrawing such information. The mechanism can be implemented using a new protocol or an extension of an existing protocol. Other SAV information can continue to be obtained through the mechanisms associated with its original information source. This document specifies a high-level architecture for gathering SAV information, maintaining the information in the SIB, and generating SAV table. It does not specify a particular protocol extension, SAV table generation algorithm, or data-plane implementation. Specific inter-domain SAV mechanisms can instantiate these architectural components according to their implementation and deployment requirements. 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. Li, et al. Expires 15 April 2027 [Page 4] Internet-Draft Inter-domain SAVNET Architecture October 2026 2. Terminology SAV table: The table of prefixes that indicates the validity of a specific source IP address or source IP prefix per interface. Sometimes the terms 'RPF (Reverse Path Forwarding) list' or 'SAV rules' are used interchangeably with 'SAV table'. SAV-specific Information: Information dedicated to SAV, which may be defined and exchanged between ASes using potentially new inter-AS communication protocol or an extension of an existing protocol. The information may also take the form of new RPKI object type(s). It may also come from the local configuration information provided by the AS operator. SAV-specific Information Communication Mechanism: The mechanism that is used to communicate SAV-specific information between ASes and can be implemented by a new inter-AS communication protocol or an extension of an existing protocol. Configuration Information: This information is configured locally by the AS operator. For example, an AS provisions (suballocates) prefixes p1 and p2 for a non-BGP customer network, which also owns an RIR-allocated prefix p3. The customer instructs the AS to advertise p1 via eBGP on the public Internet, restrict p2 strictly to internal use (in the customer network), and refrain from advertising p3 while still allowing it to source outbound traffic. The AS locally configures these prefixes accordingly. This configuration information is valuable for both intra-domain SAV to permit expected prefixes and inter-domain SAV at other interfaces to block unexpected prefixes. SAV-related Information: Routing information (e.g., RIBs and FIBs populated by routing protocols or by the local configuration information -- described below -- provided by the AS operator) and objects published in the Resource Public Key Infrastructure (RPKI) that were originally proposed for non-SAV purposes but may also be used for SAV. The RPKI objects include existing RPKI object types (e.g., ROAs and ASPAs) as well as any new types that may be proposed. Routing Information: The information that is stored in ASBR's local RIB or FIB and can be used to generate SAV table in addition to the routing purpose. Incoming Direction: Li, et al. Expires 15 April 2027 [Page 5] Internet-Draft Inter-domain SAVNET Architecture October 2026 An ingress direction at a validation AS from which traffic with a source prefix may arrive. Depending on the granularity required by a specific SAV mechanism, an incoming direction may distinguish a neighboring AS, an inter-AS link or interface, or another locally identifiable ingress direction. The representation of an incoming direction is mechanism-specific and is outside the scope of this architecture. SAV Agent: The agent within a SAVNET-adopting AS that is responsible for gathering SAV-specific and SAV-related information and utilizing it to generate SAV table. SAV Information Base: A table or data structure maintained by a SAVNET agent for storing SAV-specific and SAV-related information collected from different SAV information sources, and the resulting mappings. SAV Information Base Manager: A component of the SAVNET agent that maintains the SIB, uses the available SAV information to determine or verify the legitimate incoming directions associated with source prefixes, and generates or updates the corresponding SAV table. Improper Block: The validation results in packets with legitimate source addresses being blocked improperly due to an inaccurate SAV table. (The terms 'improper block' and 'false positive' are used synonymously.) Improper Permit: The validation results in packets with spoofed source addresses being permitted improperly due to an inaccurate SAV table. (The terms 'improper permit' and 'false negative' are used synonymously.) Source AS: The AS which deploys SAVNET agent and communicates its own SAV- specific information to other ASes for generating SAV table. Validation AS: The AS which deploys SAVNET agent and generates SAV table according to the received SAV-specific information from source ASes. 3. Inter-domain SAVNET Architecture Overview Li, et al. Expires 15 April 2027 [Page 6] Internet-Draft Inter-domain SAVNET Architecture October 2026 +~~~~~~~~~~~~~~~~~~~~~~~~+ +--------------------+ |RPKI Cache Server/IRR DB| | AS X's Provider AS | +~~~~~~~~~~~~~~~~~~~~~~~~+ +------------+/\+/\+-+ ROA & ASPA | BGP / | | Obj./IRR Data | Message / | | | / | | BGP +-----------+\/+----------------+\/+-+ | | Message +~~~~~~~~~+ Conf. | AS X | BGP +--------------+ |Operators|------>| +--------------------------------+ |<------|AS X's Lateral| +~~~~~~~~~+ Info. | | SAV Agent | |Message| Peer AS | | +--------------------------------+ | +--------------+ +-----+/\+/\+----------------+/\+/\+-+ | | | | BGP | | SAV-specific | | Message | | Message | | +------------------+ | | |AS X's Customer AS| | | +-------+/\+-------+ | | | | | BGP | SAV-specific | | BGP Message | Message | | Message +------------------------------------+ | AS X's Customer AS | | +--------------------------------+ | | | SAV Agent | | | +--------------------------------+ | +------------------------------------+ AS X and one of its customer ASes have deployed SAVNET agent and can exchange SAV-specific information with each other. Figure 1: Inter-domain SAVNET architecture. Figure 1 provides an overview of the inter-domain SAVNET architecture, showcasing an AS topology and the flow of SAV-specific and SAV-related information among ASes and their sources. The topology captures the full spectrum of AS relationships in the Internet, displaying all peer ASes of AS X including customers, lateral peers, and providers and the existence of multiple physical links between ASes. Arrows in the figure indicate the direction of the corresponding information from its source to AS X, such as gathering RPKI ROA objects and ASPA objects from RPKI cache server and delivering SAV-specific information to AS X from AS X's customer AS. SAV-specific and SAV-related information can be obtained through the communication or collection mechanisms associated with their respective information sources. Based on the available information, AS X can generate its SAV table. Li, et al. Expires 15 April 2027 [Page 7] Internet-Draft Inter-domain SAVNET Architecture October 2026 Figure 1 uses AS X as a representative example to illustrate what SAV-specific and SAV-related information its SAV agent may collect and where such information may originate. AS X has deployed SAV agent and can generate SAV table to perform inter-domain SAV by consolidating the SAV-specific and SAV-related information. It can obtain SAV-specific information from its customer AS which deploys SAV agent and routing information originating from the BGP update messages of its neighbor ASes. Also, AS X can obtain RPKI ROA objects and ASPA objects from RPKI cache server and IRR data from IRR database. Operators of AS X may operate its SAV table based on the local policies. SAV-specific information is designed to provide information that is directly relevant to determining legitimate incoming directions. When its provenance, correctness, and freshness can be validated, it can improve the accuracy of the mappings used for SAV table generation. When SAV-specific information is exchanged between SAV agents, a SAV- specific information communication mechanism is needed. The mechanism may define the representation or encoding of the communicated SAV-specific information and the procedures and triggering conditions for originating, transmitting, receiving, processing, updating, and withdrawing the information. The detailed communication model is mechanism-specific and is outside the scope of this architecture. During incremental or partial deployment, SAV-specific information for some prefixes or forwarding directions may be unavailable or incomplete. In such cases, available SAV-related information and operator-provided information can continue to contribute to the determination of legitimate incoming directions. A specific SAV mechanism determines how these information sources are selected and combined according to their availability, scope, completeness, freshness, trustworthiness, and applicability. When SAV-specific information is exchanged between SAV agents, the corresponding communication mechanism may be implemented by defining a new protocol or extending an existing protocol. Meanwhile, inter- domain SAV mechanisms may also be designed using existing SAV-related information sources, such as RPKI-derived information and routing information, without depending on inter-SAV-agent communication. Li, et al. Expires 15 April 2027 [Page 8] Internet-Draft Inter-domain SAVNET Architecture October 2026 For ASes that support a network controller, such as a multi-AS or single-AS controller, operators can deploy the SAV agent on the controller to represent the ASes it manages and communicate SAV- specific information with others. Additionally, ASes managed by the same controller may obtain SAV-specific information directly from the controller without needing to communicate with each other. +-----------------------------------------------------------+ | AS X | | +-------------------------------------------------------+ | | | SAV Agent | | | | +-----------------------+ +--------------------------+| | | | |SAV-related Information| | SAV-specific Information || | | | +-----------------------+ +--------------------------+| | | | | | | | | | \/ \/ | | | | +---------------------------------------------------+ | | | | | +-----------------------------------------------+ | | | | | | | SAV Information Base | | | | | | | +-----------------------------------------------+ | | | | | | SAV Information Base Manager | | | | | +---------------------------------------------------+ | | | | |. | | | +-------------------------------------------------------+ | | | | | \/ | | +-------------------------------------------------------+ | | | SAV Table | | | +-------------------------------------------------------+ | +-----------------------------------------------------------+ Figure 2: SAV agent and SAV table within AS X. Figure 2 displays the SAV agent and SAV table within AS X. The SAV agent can obtain SAV-specific and SAV-related information from multiple SAV information sources, including SAV-specific information from other SAV agents, RPKI-derived information, routing information from the RIB or FIB, and operator-provided configuration. The SAV Information Base (SIB) stores the collected information and is maintained by the SAV Information Base Manager (SIM), which uses the available information to generate or update the SAV table. The SIB and related SAV configuration and operational state can be managed through mechanisms such as YANG [RFC7950], NETCONF, or CLI. The detailed collection and management mechanisms depend on the implementation of a specific inter-domain SAV mechanism and are outside the scope of this document. Li, et al. Expires 15 April 2027 [Page 9] Internet-Draft Inter-domain SAVNET Architecture October 2026 In the data plane, packets arriving from other ASes are validated according to the SAV rules generated by the SIM. Depending on the specific SAV mechanism, these rules may be generated using an allowlist, a blocklist, or a combination of both. Conceptually, the validation result for a packet can be "Valid", "Invalid", or "Unknown". "Valid" indicates that the available SAV information and generated rules are sufficient to determine that the packet may legitimately arrive from the actual incoming direction. "Invalid" indicates that the available SAV information and generated rules are sufficient to determine that the packet should not legitimately arrive from that direction. "Unknown" indicates that the available information is insufficient to make either determination. The data- plane action associated with each state, including forwarding, dropping, rate limiting, or monitoring, depends on the specific SAV mechanism and operator policy. The structure and detailed usage of SAV table can refer to [I-D.ietf-savnet-general-sav-capabilities]. 3.1. SAV Table Generation Design Recommendations As described above, a validation AS uses the available SAV information to determine legitimate incoming directions for source prefixes. The more complete the resulting mapping is, the more precisely the SAV mechanism can distinguish legitimate from illegitimate incoming traffic. A new inter-domain SAV solution following this architecture is expected to improve validation accuracy. In particular, the solution should seek to reduce improper permits compared with existing mechanisms, while avoiding improper blocks. The completeness of the information about legitimate incoming directions is therefore an important consideration when determining whether an allowlist or a blocklist is appropriate at a particular interface. At an interface facing a provider AS, Loose uRPF [RFC3704] may permit a packet as long as a route to its source prefix exists through any interface. As a result, spoofed packets may still be improperly permitted at a provider-facing interface [I-D.ietf-savnet-inter-domain-problem-statement]. A new inter-domain SAV solution can improve the filtering accuracy by using available SAV information to identify source prefixes that are known not to legitimately arrive from that provider-facing interface. For example, when sufficiently complete and trustworthy information establishes that prefixes belonging to the local AS's customer cone can legitimately arrive only from customer-side directions, these prefixes can be included in a blocklist at provider-facing interfaces. Similarly, if the complete legitimate incoming-direction set of a prefix is known to contain only a subset of the provider- facing interfaces, packets using that prefix as the source can be Li, et al. Expires 15 April 2027 [Page 10] Internet-Draft Inter-domain SAVNET Architecture October 2026 blocked at the other provider-facing interfaces. For prefixes whose legitimate incoming directions cannot be determined with sufficient completeness, the solution can continue to permit them so as to avoid introducing improper blocks. At an interface facing a customer AS or lateral peer AS, an allowlist can provide stronger filtering when sufficiently complete and trustworthy information is available to determine the legitimate source prefixes for that incoming direction. In this case, the SAV table can permit the prefixes whose legitimate incoming-direction sets include the interface and reject other prefixes. When the available information does not have sufficient coverage, or when avoiding improper blocks is an operational priority, a blocklist can instead be used to reject only prefixes that are known not to legitimately arrive from that interface while permitting prefixes whose validity cannot yet be determined. Therefore, the choice between allowlist and blocklist is not determined solely by the AS relationship of an interface. It also depends on the completeness and confidence of the available information used to determine legitimate incoming directions. In general, more complete information enables a SAV mechanism to apply more restrictive filtering. 4. SAV Information Sources This section describes the SAV information sources that can be used to determine the legitimate incoming directions of source prefixes. As described in Section 2, these sources are categorized as SAV- specific information sources and SAV-related information sources. Different sources provide different types of information, and a SAV mechanism may use one or more of them to determine the mappings used for SAV table generation. 4.1. SAV-related Information 4.1.1. RPKI ROA objects and ASPA Objects RPKI ROA objects provide cryptographically verifiable information about prefix-origin authorization, including the prefix, maximum prefix length, and authorized origin AS. RPKI ASPA objects provide cryptographically verifiable information about the provider authorizations made by customer ASes. Neither ROA nor ASPA by itself directly specifies the complete legitimate incoming-direction set of a source prefix. Li, et al. Expires 15 April 2027 [Page 11] Internet-Draft Inter-domain SAVNET Architecture October 2026 By combining ROA-derived prefix-origin authorization information, ASPA-derived customer-provider information, and other available topology or routing information, a SAV mechanism can associate source prefixes with origin ASes or customer cones and constrain or infer candidate incoming directions. Such information can therefore contribute to deriving mappings. 4.1.2. Routing Information Routing information in the local RIB or FIB provides information about prefixes that are currently learned or reachable and the routes or forwarding next hops associated with them. It can therefore provide locally observed evidence for determining incoming directions of source prefixes. Existing uRPF-based mechanisms use such routing information to generate SAV rules. However, locally selected routing or forwarding information does not necessarily describe all directions through which legitimate source traffic may arrive. Asymmetric routing, limited propagation, hidden prefixes, policy- based routing, and other forwarding behavior may therefore cause routing-information-only SAV mechanisms to produce incomplete mappings and result in improper blocks or improper permits. 4.1.3. IRR Data IRR data can provide registered associations between prefixes and ASes through route and route6 objects. IRR AS-set objects can provide information about groups of ASes and, when such sets represent customer or other policy-relevant AS groups, can help associate source prefixes with customer cones or constrain the incoming directions from which those prefixes may legitimately arrive. Therefore, IRR data can be used as supplementary information for deriving mappings. However, the semantics, completeness, freshness, and accuracy of IRR data depend on how the corresponding objects are maintained. 4.2. SAV-specific Information SAV-specific information is produced specifically for determining the validity of source addresses. It can directly describe a legitimate pair or provide SAV-specific information from which such a pair can be derived. Compared with information originally produced for routing or routing security, SAV-specific information can be designed to represent forwarding-direction information that is otherwise unavailable or difficult to infer. SAV-specific information may have different sources. Information exchanged between SAVNET agents can describe legitimate incoming directions learned or derived by participating ASes and can be Li, et al. Expires 15 April 2027 [Page 12] Internet-Draft Inter-domain SAVNET Architecture October 2026 updated when the relevant forwarding information changes. A dedicated RPKI object, if defined for SAV, can provide cryptographically validated SAV-specific information according to the semantics of that object. Operator-provided configuration can provide local knowledge about prefixes and forwarding behavior, including prefixes that are not visible in BGP, expected incoming directions, or constraints known to the operator. The trustworthiness, completeness, and freshness of SAV-specific information depend on its source and the mechanism used to obtain it. Therefore, SAV-specific information is not assumed to be correct merely because it is SAV-specific; the corresponding protocol, RPKI object, or management mechanism needs to provide appropriate validation and provenance. 5. SAV Information Base Li, et al. Expires 15 April 2027 [Page 13] Internet-Draft Inter-domain SAVNET Architecture October 2026 +----------------------------+-----------------------------+--------------------------+ | SAV Information Source | Information Provided | Contribution to SAV | +----------------------------+-----------------------------+--------------------------+ | SAV-specific messages |SAV-specific information for |Provides or updates | | |determining legitimate |information used to | | |incoming directions |determine | +----------------------------+-----------------------------+--------------------------+ |. Dedicated SAV RPKI object |SAV-specific authenticated |Provides cryptographically| | |information, depending on |validated evidence for | | |object semantics |determining the mapping. | +----------------------------+-----------------------------+--------------------------+ | Operator configuration. |Local/customer prefixes, |Provides authoritative | | |hidden/non-advertised |local information | | |prefixes, expected directions|unavailable from public | | |or forwarding constraints. |routing | +----------------------------+-----------------------------+--------------------------+ | RPKI ROA |Prefix, maxLength, |Associates source prefix. | | |authorized origin AS |with authorized origin AS | +----------------------------+-----------------------------+--------------------------+ | RPKI ASPA |AS and authorized |Provides AS-relationship | | |provider set |information used to infer | | | |customer cones and | | | |permissible directions. | +----------------------------+-----------------------------+--------------------------+ | RIB/FIB |Locally learned routes and |Provides observed routing | | |forwarding next hops. |evidence for | | | |incoming-direction | | | |inference | +----------------------------+-----------------------------+--------------------------+ | IRR |Registered AS-prefix |Provides supplementary | | |associations and AS-set |prefix-to-AS information | | |membership information. |and groups of ASes for | | | |incoming-direction | | | |inference | +----------------------------+-----------------------------+--------------------------+ Figure 3: SAV information sources and the information they provide for SAV table generation. The SIB consolidates information obtained from different SAV information sources. The objective of the SIM is to use the available information to determine, for each relevant source prefix, the set of legitimate incoming directions and then generate the corresponding SAV table. In particular, the SIM needs to distinguish between a direction that is known to be illegitimate and a direction for which sufficient information is not yet available. Li, et al. Expires 15 April 2027 [Page 14] Internet-Draft Inter-domain SAVNET Architecture October 2026 Different information sources may provide complementary evidence for the same prefix. For example, a ROA can identify the authorized origin AS of a prefix, ASPA information can help determine the customer-provider relationships associated with that AS, routing information can provide locally observed routing information, and SAV-specific information can provide forwarding-direction information that is not available from these general sources. The SIM can combine such information when this improves the completeness or confidence of the resulting mapping. The architecture does not mandate that every available information source be used, nor does it define a universal priority among information sources. A specific SAV mechanism determines how sources are selected and combined according to their scope, completeness, freshness, trustworthiness, and applicability. In particular, absence of information from an incomplete source should not automatically be interpreted as evidence that a source prefix is invalid on an incoming direction. When RPKI-derived SAV-related information is reused for SAV, the SAV mechanism should preserve the semantics and operation of the corresponding RPKI objects for their original routing-security purposes. Li, et al. Expires 15 April 2027 [Page 15] Internet-Draft Inter-domain SAVNET Architecture October 2026 +----------------+ | AS 3(P3) | +-+/\-----+/\+/\++ / \ \ P3[AS 3] / \ \ P3[AS 3] / \ \ / (C2P) \ \ +----------------+ \ \ | AS 4(P4) | \ \ ++/\+/\+/\+/\+/\++ \ \ P6[AS 1, AS 2] / / | | \ \ \ P2[AS 2] / / | | \ \ \ / / | | \ \ \ / / | | \ P5[AS 5] \ \ P5[AS 5] / / | | \ \ \ / /(C2P) | | \ \ \ +----------------+ | | \ \ \ | AS 2(P2) | | | P1[AS 1] \ \ \ +--------+/\+----+ | | P6[AS 1] \ \ \ P6[AS 1] \ | | NO_EXPORT \ \ \ P1[AS 1] \ | | \ \ \ NO_EXPORT \ | | \ \ \ \ (C2P) | | (C2P/P2P) (C2P)\ (C2P) \ \ +----------------+ +----------------+ | AS 1(P1, P6) | | AS 5(P5) | +----------------+ +----------------+ Both AS 1 and AS 4 support the inter-domain SAVNET architecture and can exchange the SAV-specific information with each other, while other ASes do not support it. Figure 4: An example of the availability of different SAV- specific and SAV- related information sources. Li, et al. Expires 15 April 2027 [Page 16] Internet-Draft Inter-domain SAVNET Architecture October 2026 +-----+------+------------------+--------+------------------------+ |Index|Prefix|Incoming Direction|Relation| SAV Information Source | +-----+------+------------------+--------+------------------------+ | 0 | P1 | AS 2 |Customer|SAV-specific Information| +-----+------+------------------+--------+------------------------+ | 1 | P1 | AS 1 |Customer|SAV-related Information | +-----+------+------------------+--------+------------------------+ | 2 | P2 | AS 2 |Customer|SAV-related Information | +-----+------+------------------+--------+------------------------+ | 3 | P3 | AS 3 |Provider|SAV-related Information | +-----+------+------------------+--------+------------------------+ | 4 | P5 | AS 3 |Provider|SAV-related Information | +-----+------+------------------+--------+------------------------+ | 5 | P5 | AS 5 |Customer|SAV-related Information | +-----+------+------------------+--------+------------------------+ | 6 | P6 | AS 2 |Customer|SAV-related Information | | | | | |SAV-specific Information| +-----+------+------------------+--------+------------------------+ | 7 | P6 | AS 1 |Customer|SAV-related Information | +-----+------+------------------+--------+------------------------+ Figure 5: An example for the SAV information base of AS 4. We use the examples shown in Figure 4 and Figure 5 to introduce the SIB and illustrate how SAV table can be generated based on the information maintained in the SIB. Figure 5 depicts an example of the SIB established in AS 4 in Figure 4. Each row contains an index, a source prefix, an incoming direction, the AS relationship associated with that direction, and the SAV information source or sources supporting the mapping. In this example, incoming directions are represented at the neighboring-AS granularity, while the Relation column indicates whether the neighboring AS is a customer, provider, or lateral peer of AS 4. For example, the row with index 0 indicates that AS 2 is a legitimate incoming direction for P1 and that this mapping is supported by SAV-specific information. The same mapping may be supported by multiple SAV information sources, as illustrated by the row indexed 6. The SIB should be implemented carefully to avoid imposing excessive state or processing overhead, and implementation-specific optimizations similar to those used for routing information bases may be applied. How the information maintained in the SIB is converted into SAV rules depends on both the AS relationship of an interface and the completeness of the information available for determining legitimate incoming directions. At provider-facing interfaces, a blocklist is generally suitable for conservatively blocking prefixes that are known not to legitimately arrive from the corresponding provider. With sufficiently complete information, such a blocklist can, for Li, et al. Expires 15 April 2027 [Page 17] Internet-Draft Inter-domain SAVNET Architecture October 2026 example, exclude prefixes belonging to the local customer cone or prefixes whose legitimate incoming directions are known to include only other provider-facing interfaces. At customer-facing or lateral-peer-facing interfaces, an allowlist can be used when sufficiently complete and authoritative information is available for the corresponding customer cone or peer. When such information is incomplete, a blocklist can instead be used to avoid treating the absence of information as evidence that legitimate traffic is invalid. Assuming that AS 4 has sufficient information to apply an allowlist at its customer-facing interfaces and a blocklist at its provider- facing interfaces, taking the SIB in Figure 5 as an example, AS 4 can generate SAV rules as follows: SAV at the interfaces facing AS 3 blocks P1, P2, and P6 according to the rows indexed 0, 1, 2, 6, and 7 in the SIB, SAV at the interfaces facing AS 2 permits P1, P2, and P6 according to the rows indexed 0, 2, and 6 in the SIB, SAV at the interfaces facing AS 1 permit P1 and P6 according to the rows indexed 1 and 7 in the SIB, and SAV at the interfaces facing AS 5 permits P5 according to the row indexed 5 in the SIB. 6. SAVNET Communication Mechanism +------+ +--------------------------------+ | | | +----------------------------+ | | | | | SAV Agent in other ASes | | | | | +----------------------------+ | | |SAV-specific Information | +----------------------------+ | | |<========================| | New RPKI Obj. | | | | | +----------------------------+ | | | | +----------------------------+ | | | | | Network Operators. | | | | | +----------------------------+ | | SAV | +--------------------------------+ |Agent | +---------------------------------+ | | | +-----------------------------+ | | | | | RPKI ROA Obj. and ASPA Obj. | | | | | +-----------------------------+ | | | | +-----------------------------+ | | | | | RIB | | | | SAV-related Information | +-----------------------------+ | | |<------------------------| +-----------------------------+ | | | | | FIB | | | | | +-----------------------------+ | | | | +-----------------------------+ | | | | | IRR Database | | | | | +-----------------------------+ | +------+ +---------------------------------+ Li, et al. Expires 15 April 2027 [Page 18] Internet-Draft Inter-domain SAVNET Architecture October 2026 Figure 6: Gathering SAV-specific and SAV-related information from different SAV information sources. SAV-related information may be obtained from existing information sources such as RPKI ROA and ASPA objects, the local RIB or FIB, and IRR data. SAV-specific information may be obtained through communication among SAV agents, dedicated SAV-specific RPKI objects, or operator-provided configuration. As illustrated in Figure 6, the SAVNET agent gathers available information from these sources and stores the relevant information in the SIB. 6.1. SAV-related Information Communication Mechanism SAV-related information is obtained using the existing communication or collection mechanisms associated with its original source. For example, routing information may be learned through BGP and maintained in the local RIB or FIB. RPKI objects may be retrieved using the applicable RPKI repository distribution mechanisms, while validated RPKI information may be delivered to routers using RTR [RFC8210]. IRR information may be obtained using the access mechanisms provided by the corresponding IRR service. This architecture does not define new communication mechanisms for SAV- related information. 6.2. SAV-specific Information Communication Mechanism Li, et al. Expires 15 April 2027 [Page 19] Internet-Draft Inter-domain SAVNET Architecture October 2026 +------------------------+ | AS 3(P3, P3') | | +----------------+ | | | SAV Agent | | | +----------------+ | +-+/\+---------------+/\++ / | | SAV-specific / | | Messages[ / SAV-specific | | (P1, AS 2)] / Messages[ | | / (P3, AS 3), | | / (P3', AS 3)] | | +------------+ | | | AS 2(P2) | | | +------+/\+--+ | | SAV-specific SAV-specific \ | | Messages[ Messages[ \ | | (P1, AS 1)] (P1, AS 2)] \ | | \ | | +-------------------+\/+--+ | AS 1(P1) | | +--------------+ | | | SAV Agent | | | +--------------+ | +-------------------------+ (1) The path of the legitimate traffic with source addresses in P1 and destination addresses in P3 is [AS 1, AS 2, AS 3]. (2) The path of the legitimate traffic with source addresses in P1 and destination addresses in P3' is [AS 1, AS 3]. (3) The path of the legitimate traffic with source addresses in P3 or P3' and destination addresses in P1 is [AS 3, AS 1]. Figure 7: An example illustrating SAV-specific information required by AS 1 and AS 3. SAV-specific information may be obtained through different mechanisms depending on its source. When SAV-specific information is exchanged among SAV agents, a SAV-specific information communication mechanism is used. When SAV-specific information is represented by a newly defined RPKI object, existing RPKI distribution mechanisms can be used, including RRDP [RFC8182] or rsync for retrieving RPKI objects and RTR [RFC8210] for delivering the corresponding validated information to routers. When SAV-specific information is obtained from operator configuration, management mechanisms such as YANG or CLI can be used to provide the information to the SAVNET agent. The remainder of this section focuses on the communication of SAV- specific information among SAV agents. The selection of communicating SAV agents and the underlying connectivity or transport Li, et al. Expires 15 April 2027 [Page 20] Internet-Draft Inter-domain SAVNET Architecture October 2026 model are determined by the specific SAV-specific information communication mechanism and are outside the scope of this architecture. Figure 7 illustrates an example in which SAV-specific information is exchanged between AS 1 and AS 3 through SAV-specific messages. In this example, incoming directions are represented at the neighboring- AS granularity, and the resulting SAV-specific information is represented as pairs, such as (P1, AS 1), (P1, AS 2), (P3, AS 3), and (P3', AS 3). A specific SAV mechanism may use a finer-grained representation when different inter-AS links or interfaces toward the same neighboring AS need to be distinguished. The information exchange illustrated in Figure 7 is intended only to demonstrate the SAV information needed by the participating ASes and does not imply a particular communication topology or transport relationship among SAV agents. For traffic with source addresses in P1, AS 1 needs to determine the legitimate incoming directions at AS 3 and provide the corresponding SAV-specific information, such as (P1, AS 1) and (P1, AS 2), to AS 3. The SAVNET agent in AS 1 can assemble this information into SAV- specific messages and send them to the SAV agent in AS 3. AS 3 can then use the received information to generate or update its SAV table. Obtaining such information may require AS 1 to collaborate with intermediate ASes along the forwarding paths between AS 1 and AS 3. Similarly, for prefixes P3 and P3', AS 3 needs to determine the legitimate incoming directions at AS 1 and communicate SAV-specific information, such as (P3, AS 3) and (P3', AS 3), to AS 1. AS 1 can generate or update its SAV table based on the received information. AS 3 may need to collaborate with intermediate ASes to obtain the information required for constructing the corresponding SAV-specific information. The SAV-specific information communication mechanism provides the means for SAV agents in different ASes to exchange SAV-specific information. A SAV agent may originate, receive, process, update, or withdraw SAV-specific information as required by the specific mechanism. Information received through this mechanism can be used to determine or update the corresponding mappings maintained in the SIB. Whether and how SAV-specific information is relayed or propagated among SAV agents is mechanism- specific and is outside the scope of this architecture. The SAV-specific information communication mechanism may be implemented either by defining a new protocol or by extending an existing protocol. The mechanism needs to specify the information Li, et al. Expires 15 April 2027 [Page 21] Internet-Draft Inter-domain SAVNET Architecture October 2026 representation or encoding required for SAV-specific communication, as well as the procedures for originating, transmitting, receiving, processing, updating, and withdrawing the information. It also needs to specify the conditions that trigger these operations so that relevant changes in the underlying information can be reflected in a timely manner. If an existing protocol is extended for this purpose, the extension should avoid adversely affecting the existing functions of that protocol. A SAV agent may communicate SAV-specific information with one or more other SAV agents as determined by the specific SAV-specific information communication mechanism and operator policy. The communication mechanism needs to identify and authenticate the communicating entities and protect SAV-specific information against unauthorized modification, replay, or other attacks during communication. The procedures for selecting communication peers, configuring or discovering them, and establishing the corresponding communication are mechanism-specific and are outside the scope of this architecture. Before originating SAV-specific information, a SAV agent also needs to obtain the information required to construct it. For example, the inter-domain SAVNET architecture may interact with the intra-domain SAVNET architecture [I-D.ietf-savnet-intra-domain-architecture] to obtain the source prefixes belonging to the local AS. The legitimate incoming directions may be derived from routing or forwarding information and, when necessary, through collaboration with other SAV agents. When BGP AS_PATH information is used for this purpose, it should be noted that the AS_PATH alone may not expose all inter-AS forwarding interfaces, for example in topological fork-and-merge scenarios. In some scenarios, forwarding behavior cannot be completely inferred from BGP routing information. For example, policy-based routing or static routes may cause legitimate traffic to traverse a forwarding path different from the path indicated by BGP. In Figure 7, AS 2 may forward legitimate traffic with source addresses in P1 through another AS that does not appear in the AS path [AS 1, AS 2, AS 3]. In such cases, obtaining accurate SAV-specific information may require deployment of SAV agents in additional ASes or additional interaction among the relevant SAV agents. The forwarding paths between ASes may also change over time because of routing changes, operator configurations, or network failures. The SAV agent therefore needs to detect relevant changes and update the corresponding SAV-specific information in a timely manner. The SAV-specific information communication mechanism needs to support such updates carefully because stale or delayed information may Li, et al. Expires 15 April 2027 [Page 22] Internet-Draft Inter-domain SAVNET Architecture October 2026 result in improper blocking of legitimate traffic. Such problems may arise from delayed detection of forwarding changes, delayed transmission or processing of SAV-specific messages, or message loss. Wider deployment of SAV agents may improve the ability to obtain information about forwarding-path changes. The detailed mechanisms for handling routing changes and failures are outside the scope of this document. 7. Deployment Considerations The inter-domain SAVNET architecture is designed to accommodate incremental and partial deployment. SAV agents are not expected to be deployed simultaneously in all ASes, as deployment may depend on factors such as device capabilities, software versions, vendor support, and operator policies. Incremental and partial deployment does not require a particular SAV- specific information communication topology. A specific SAV-specific information communication mechanism determines which SAV agents exchange information and how the corresponding communication is established. The architecture only requires that available SAV- specific information can be provided to the SAV agents that use it for SAV table generation; the procedures for peer selection, discovery, and communication establishment are outside the scope of this document. Under partial deployment, some SAV-specific information may be unavailable or incomplete when its derivation depends on ASes that do not participate in SAVNET. In such cases, the SAV agent can continue to use available SAV-related information in the SIB, such as routing information and validated information obtained from RPKI, as inputs to the SIM. Operator-provided information may also supplement information learned automatically. The SIM determines how the available information sources are combined to generate SAV table for a particular SAV mechanism and application scenario. As deployment expands, SAV agents may obtain SAV-specific information for a larger set of prefixes and forwarding directions. This additional information can allow the SIM to determine more complete legitimate incoming-direction sets and generate more precise SAV table in scenarios where SAV-related information alone is insufficient. Operators may introduce SAV enforcement in stages to reduce deployment risks. For example, an implementation can initially operate in a monitoring mode in which generated SAV tables are evaluated without discarding traffic. The resulting statistics can be used to examine validation results, forwarding performance, and Li, et al. Expires 15 April 2027 [Page 23] Internet-Draft Inter-domain SAVNET Architecture October 2026 operational overhead. An operator may subsequently apply less disruptive actions, such as rate limiting traffic identified by SAV table, before enabling packet filtering. Direct blocking can then be enabled when the operator has sufficient confidence in the generated SAV table and the operational behavior of the deployment. These deployment stages are operational choices and do not change the components or information processing model of the SAVNET architecture. 8. Operational Considerations The information used by inter-domain SAVNET can change during normal network operation. Such changes may originate from routing information, RPKI information, operator configuration, or SAV- specific information received from other SAVNET agents. The architecture therefore allows SAV table to be updated as their underlying information changes without requiring operators to manually maintain individual SAV table. When an information source changes, the corresponding information in the SIB is updated. The SIM can then identify the SAV table affected by the change and generate updated rules. The resulting rules are installed in the SAV table and subsequently used for data-plane validation. This forms an information processing path from SAV information sources, through the SIB and SIM, to the SAV table. Updates include not only the addition of new information but also modification, withdrawal, expiration, or loss of previously available information. The SIB therefore needs to maintain sufficient information about the provenance, scope, freshness, completeness, and state of its entries, as applicable, so that the SIM can react appropriately when the underlying information changes or becomes unavailable. Multiple information sources may provide information relevant to the same source prefix. Their availability, scope, and freshness may differ. The architecture does not prescribe a single policy for resolving such information. Instead, the SIM associated with a particular SAV mechanism determines how these information sources are interpreted and combined. This separation allows different SAV mechanisms to apply different policies while using the common SIB and SAV table abstractions. Li, et al. Expires 15 April 2027 [Page 24] Internet-Draft Inter-domain SAVNET Architecture October 2026 Operational failures may also affect the availability of SAV information. For example, a SAV-specific communication session may be temporarily unavailable, an RPKI information source may become unreachable, or an operator-provided configuration may be changed. Implementations need to account for such changes when maintaining SIB entries and generating SAV table rather than assuming that previously learned information remains valid. 9. Convergence Considerations Because inter-domain routing and other SAV information sources change over time, the SAV state maintained by the architecture also undergoes convergence. From the perspective of this architecture, SAV convergence covers the process from detecting a change in an information source, through updating the corresponding SIB entries and recomputing the affected SAV rules through the SIM, to installing the updated rules in the SAV table. Different information sources may change and propagate at different timescales. For example, routing changes may be observed through BGP, SAV-specific information may be communicated between SAV agents, RPKI-derived information may be updated independently, and operator configuration may change at any time. Consequently, the SIB may temporarily contain information learned at different points in time. During such transitions, the forwarding path of legitimate traffic may change before the corresponding SAV-specific information and SAV table have converged. Conversely, obsolete rules may remain in the SAV table for some period after the forwarding state has changed. These transient inconsistencies can result in improper block or improper permit. Delays may arise from change detection, SAV- specific information communication, message processing, SAV table computation, or data-plane rule installation. The SAV-specific information communication mechanism and the SIM therefore need to account for the freshness and changes of the information on which SAV tables depend. The architecture does not prescribe a particular convergence algorithm. Mechanism-specific designs can determine how to coordinate updates and how to treat information that is changing, delayed, or temporarily unavailable. When SAV-specific information is temporarily unavailable or has not yet converged, other information already maintained in the SIB may provide additional input for SAV table generation. For example, validated RPKI-derived information may provide relatively stable information about prefixes, origins, or AS relationships. Such information does not necessarily provide the same forwarding- direction information as SAV-specific information, but a SIM may use Li, et al. Expires 15 April 2027 [Page 25] Internet-Draft Inter-domain SAVNET Architecture October 2026 it as auxiliary or fallback information when supported by the corresponding SAV mechanism. The appropriate behavior during convergence is therefore determined by the information available in the SIB and the SAV table generation logic of the SIM. 10. Manageability Considerations The inter-domain SAVNET architecture introduces several components that require appropriate management support, including SAV information sources, the SAV-specific information communication mechanism, the SIB, the SIM, and the SAV table. Implementations should provide mechanisms for configuring these components, monitoring their operational status, and diagnosing failures or inconsistencies. A common data modeling approach, such as YANG [RFC7950], can be used to represent SAVNET configuration and operational state across implementations. Such a data model can include SAVNET enablement and enforcement mode, configured information sources, SAVNET communication peers, operator-provided SAV information or rules, resource limits, SIB state, SIM state, and the status of SAV table. Management protocols such as NETCONF [RFC6241] can be used for remote configuration and retrieval of operational state. Mechanisms such as syslog [RFC5424] can be used for event, alarm, and exception reporting. These mechanisms are particularly relevant when SAVNET functions are deployed across a large number of routers within an AS. Operator-provided information can also serve as an input to SAVNET. For example, operators may configure SAV-specific information, SAV table, communication peers, enforcement modes, or other deployment parameters through management mechanisms such as YANG-based interfaces or CLI. Management information communication therefore constitutes one of the ways in which information can enter the SAVNET architecture, in addition to information obtained from routing systems, RPKI, and other SAV agents. Operational visibility is useful across both the SAVNET control plane and data plane. Relevant state can include the status of SAV- specific communication sessions, the availability and provenance of information maintained in the SIB, SAV table generated by the SIM, and the installation status of those rules in the SAV table. Implementations can also expose statistics such as the number of packets accepted or discarded by SAV table, processing or forwarding performance associated with SAV, and the source prefixes associated with rejected traffic. Li, et al. Expires 15 April 2027 [Page 26] Internet-Draft Inter-domain SAVNET Architecture October 2026 Maintaining the provenance of SAV information is particularly useful for management and troubleshooting. When an unexpected SAV rule is generated, an operator should be able to determine which information source contributed to the relevant SIB entry and which SIM generated the rule. This helps distinguish problems caused by stale or incorrect source information, SAV-specific information communication, SAV table generation, or data-plane rule installation. 11. Security Considerations The inter-domain SAVNET architecture introduces additional information sources and, when SAV-specific information is exchanged between ASes, additional inter-domain communication. Compromise or manipulation of this information can result in incorrect SAV rules and can consequently cause legitimate traffic to be improperly blocked or spoofed traffic to be improperly permitted. Security considerations apply to all inputs to the SIB, including routing information, RPKI-derived information, operator-provided information, and SAV-specific information received from other SAV agents. The security properties of an information source depend on the mechanism through which the information is obtained. Existing security mechanisms associated with BGP, RPKI, and network management can continue to protect information obtained through those mechanisms. For communication between SAV agents, two security aspects need to be distinguished: protection of the communication relationship and trustworthiness of the SAV-specific information itself. Protection of the communication relationship includes authentication of communicating SAV agents and protection against unauthorized modification or replay of messages in transit. Existing secure transport or session authentication mechanisms may be used by a SAV- specific information communication mechanism for these purposes. Authentication of a communication peer, however, does not by itself establish that all SAV-specific information originated by that peer is correct. An authenticated but misconfigured or malicious SAV agent could provide incorrect information. Similarly, an attacker may attempt to inject, alter, replay, or suppress SAV-specific information. Mechanisms that exchange SAV-specific information therefore need to consider both message provenance and freshness in addition to peer authentication. RPKI-based mechanisms can provide cryptographically validated information about properties for which corresponding RPKI objects are defined, such as prefix-origin authorization and AS relationships. Such validation can provide supporting evidence for SAV table Li, et al. Expires 15 April 2027 [Page 27] Internet-Draft Inter-domain SAVNET Architecture October 2026 generation, but it does not in general authenticate arbitrary SAV- specific information exchanged between SAV agents. A SAV-specific information communication mechanism that requires stronger validation of the communicated information may therefore need additional mechanisms appropriate to the semantics of that information. Availability is another security consideration. An attacker may attempt to disrupt SAV-specific information communication or exhaust SAVNET control-plane resources by generating excessive sessions, messages, or updates. Such attacks should not cause uncontrolled growth of SAVNET state or prevent the continued operation of unrelated routing and forwarding functions. In particular, SAV- specific communication may itself traverse networks experiencing source address spoofing attacks, so interruption or degradation of that communication needs to be treated as a possible operational condition. Management interfaces used to configure SAVNET or provide SAV information are also part of the security boundary. Unauthorized modification of operator-provided SAV information, SIM configuration, communication peers, or enforcement modes can directly affect SAV behavior. Access control, authentication, and other security mechanisms provided by the corresponding management protocols therefore apply. This architecture identifies these security properties and trust boundaries but does not define a particular security protocol for SAV-specific information communication. Protocols or extensions that implement such communication need to specify the security mechanisms appropriate to their message semantics and deployment model. 12. Privacy Considerations The information processed by inter-domain SAVNET is primarily network-layer and routing-related information rather than user- specific information. Nevertheless, some SAV information can reveal operational information about an AS that is not otherwise publicly visible. In particular, SAV-specific information may reveal legitimate incoming directions for particular source prefixes. Depending on how such information is derived, it may indirectly expose information about traffic engineering policies, forwarding paths, inter-AS connectivity, backup paths, or routing policies that cannot be inferred from publicly visible BGP information. This is particularly relevant in scenarios involving policy-based routing, static routes, limited propagation of a prefix, or other forwarding behavior that is not represented by the public routing system. Li, et al. Expires 15 April 2027 [Page 28] Internet-Draft Inter-domain SAVNET Architecture October 2026 The communication of SAV-specific information should therefore be scoped to the information required by the receiving SAV agent for SAV table generation. A SAV-specific information communication mechanism does not need to expose unrelated routing, forwarding, or topology information merely to support SAV. Where SAV-specific information is considered sensitive, the communication mechanism can provide confidentiality in addition to peer authentication and integrity protection. Management and telemetry information can introduce additional privacy considerations. For example, SAV-related logs or telemetry may contain source prefixes, packet counters, information about rejected packets, communication peers, or operational events. Access to such information should be restricted according to the operator's management policy. Implementations should also avoid collecting or retaining packet-level information that is not necessary for SAV operation or troubleshooting. This architecture does not require the exchange of end-user identity information. Protocols that instantiate the SAV-specific information communication mechanism should evaluate whether the specific SAV information they exchange introduces additional privacy exposure and provide appropriate confidentiality, access control, and data- minimization mechanisms. 13. IANA Considerations This document has no IANA requirements. 14. Scope and Assumptions This architecture does not prescribe the protocols or mechanisms used to obtain information from different SAV information sources. It provides architectural considerations for gathering and consolidating SAV-specific and SAV-related information, determining legitimate incoming directions, and generating SAV table. The detailed design and implementation of SAV table generation and data-plane enforcement depend on the specific inter-domain SAV mechanism. This document does not cover administrative or business agreements that may be established between the involved inter-domain SAVNET parties. These considerations are beyond the scope of this document. However, it is assumed that authentication and authorization mechanisms can be implemented to ensure that only authorized ASes can communicate SAV information. This document makes the following assumptions: Li, et al. Expires 15 April 2027 [Page 29] Internet-Draft Inter-domain SAVNET Architecture October 2026 * All ASes where the inter-domain SAVNET is deployed are assumed to provide the necessary connectivity between SAV agent and any intermediate network elements. However, the architecture does not impose any specific limitations on the form or nature of this connectivity. * Congestion, communication failures, and resource exhaustion can affect the availability or timeliness of SAV information. Implementations should therefore account for temporary disruption or degradation of SAV information sources and communication mechanisms. Such failures should not cause uncontrolled SAV state or interfere with unrelated routing and forwarding functions. The behavior of a specific SAV mechanism when SAV information is temporarily unavailable or stale is mechanism-specific. * The inter-domain SAVNET architecture does not mandate a particular set or universal priority of SAV information sources. A specific SAV mechanism may select and combine SAV-specific and SAV-related information according to their availability, scope, completeness, freshness, trustworthiness, and applicability. The corresponding SAV table generation and data-plane actions are determined by the specific mechanism and operator policy. * The inter-domain SAVNET architecture does not prescribe which SAV agents exchange SAV-specific information with each other. The selection of communicating SAV agents and the procedures used to establish such communication are determined by the specific SAV- specific information communication mechanism and operator policy. 15. Contributors Mingqing Huang Zhongguancun Laboratory Beijing China Email: huangmq@mail.zgclab.edu.cn Igor Lubashev Akamai Technologies 145 Broadway Cambridge, MA, 02142 United States of America Email: ilubashe@akamai.com Many thanks to Mingqing Huang and Igor Lubashev for the significantly helpful discussions and revision suggestions. 16. References Li, et al. Expires 15 April 2027 [Page 30] Internet-Draft Inter-domain SAVNET Architecture October 2026 16.1. Normative References [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, . [RFC8704] Sriram, K., Montgomery, D., and J. Haas, "Enhanced Feasible-Path Unicast Reverse Path Forwarding", BCP 84, RFC 8704, DOI 10.17487/RFC8704, February 2020, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 16.2. Informative References [I-D.ietf-savnet-inter-domain-problem-statement] Li, D., Qin, L., Liu, L., Huang, M., and K. Sriram, "Problem Statement, Gap Analysis, and Requirements for Inter-Domain Source Address Validation", Work in Progress, Internet-Draft, draft-ietf-savnet-inter-domain-problem- statement-21, 19 July 2026, . [I-D.ietf-savnet-intra-domain-architecture] Li, D., Wu, J., Qin, L., Geng, N., and L. Chen, "Intra- domain Source Address Validation Architecture", Work in Progress, Internet-Draft, draft-ietf-savnet-intra-domain- architecture-05, 30 September 2026, . [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, . Li, et al. Expires 15 April 2027 [Page 31] Internet-Draft Inter-domain SAVNET Architecture October 2026 [RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, "The RPKI Repository Delta Protocol (RRDP)", RFC 8182, DOI 10.17487/RFC8182, July 2017, . [RFC8210] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1", RFC 8210, DOI 10.17487/RFC8210, September 2017, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, DOI 10.17487/RFC5424, March 2009, . Acknowledgements Many thanks to Alvaro Retana, Kotikalapudi Sriram, Rüdiger Volk, Xueyan Song, Ben Maddison, Jared Mauch, Joel Halpern, Aijun Wang, Jeffrey Haas, Xiangqing Chang, Changwang Lin, Mingxing Liu, Zhen Tan, Yuanyuan Zhang, Yangyang Wang, Antoin Verschuren, Olaf Struck, Siyuan Teng, Gert Doering etc. for their reviews, comments, and suggestions. Apologies to any others whose names the authors may have inadvertently missed mentioning. Authors' Addresses Dan Li Tsinghua University Beijing China Email: tolidan@tsinghua.edu.cn Li Chen Zhongguancun Laboratory Beijing China Email: lichen@zgclab.edu.cn Li, et al. Expires 15 April 2027 [Page 32] Internet-Draft Inter-domain SAVNET Architecture October 2026 Nan Geng Huawei Beijing China Email: gengnan@huawei.com Libin Liu Zhongguancun Laboratory Beijing China Email: liulb@zgclab.edu.cn Lancheng Qin Zhongguancun Laboratory Beijing China Email: qinlc@mail.zgclab.edu.cn Li, et al. Expires 15 April 2027 [Page 33]