| Internet-Draft | Inter-domain SAVNET Architecture | October 2026 |
| Li, et al. | Expires 15 April 2027 | [Page] |
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.¶
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.¶
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.¶
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 <Prefix, Incoming Direction> 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.¶
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.¶
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.¶
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'.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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 <Prefix, Incoming Direction> mappings.¶
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.¶
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.)¶
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.)¶
The AS which deploys SAVNET agent and communicates its own SAV-specific information to other ASes for generating SAV table.¶
The AS which deploys SAVNET agent and generates SAV table according to the received SAV-specific information from source ASes.¶
+~~~~~~~~~~~~~~~~~~~~~~~~+ +--------------------+
|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 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.¶
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 <Prefix, Incoming Direction> 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.¶
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 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.¶
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].¶
As described above, a validation AS uses the available SAV information to determine legitimate incoming directions for source prefixes. The more complete the resulting <Prefix, Incoming Direction> 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 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.¶
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 <Prefix, Incoming Direction> mappings used for SAV table generation.¶
SAV-specific information is produced specifically for determining the validity of source addresses. It can directly describe a legitimate <Prefix, Incoming Direction> 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 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.¶
+----------------------------+-----------------------------+--------------------------+ | 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 <Prefix, | | | |Incoming Direction> | +----------------------------+-----------------------------+--------------------------+ |. 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 | +----------------------------+-----------------------------+--------------------------+
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.¶
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 <Prefix, Incoming Direction> 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.¶
+----------------+
| 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.
+-----+------+------------------+--------+------------------------+ |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 | +-----+------+------------------+--------+------------------------+
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 <Prefix, Incoming Direction> 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 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.¶
+------+ +--------------------------------+ | | | +----------------------------+ | | | | | 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 | | | | | +-----------------------------+ | +------+ +---------------------------------+
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.¶
+------------------------+
| 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].
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 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 <Prefix, Incoming Direction> 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 <Prefix, Incoming Direction> 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 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 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.¶
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 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.¶
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.¶
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.¶
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 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.¶
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.¶
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.¶
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 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.¶
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.¶
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.¶
This document has no IANA requirements.¶
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:¶
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.¶
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.¶
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.¶