]> Tsinghua University

Beijing China tolidan@tsinghua.edu.cn

Zhongguancun Laboratory

Beijing China lichen@zgclab.edu.cn

Huawei

Beijing China gengnan@huawei.com

Zhongguancun Laboratory

Beijing China liulb@zgclab.edu.cn

Zhongguancun Laboratory

Beijing China qinlc@mail.zgclab.edu.cn

Routing SAVNET 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.

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 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 . There are various information sources 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 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 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 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.

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 when, and only when, they appear in all capitals, as shown here.

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:

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 <Prefix, Incoming Direction> 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.

Inter-domain SAVNET Architecture Overview

Inter-domain SAVNET architecture. | +--------------------------------+ |<------|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. ]]>

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. 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.

SAV agent and SAV table within AS X.

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 , 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 .

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 <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 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 . 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.

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 , 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-related Information

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. 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 <Prefix, Incoming Direction> mappings.

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 <Prefix, Incoming Direction> mappings and result in improper blocks or improper permits.

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 <Prefix, Incoming Direction> mappings. However, the semantics, completeness, freshness, and accuracy of IRR data depend on how the corresponding objects are maintained.

SAV-specific Information 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 Base

SAV information sources and the information they provide for SAV table generation. | +----------------------------+-----------------------------+--------------------------+ |. 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.

An example of the availability of different SAV-specific and SAV-related information sources.

An example for the SAV information base of AS 4.

We use the examples shown in and to introduce the SIB and illustrate how SAV table can be generated based on the information maintained in the SIB. depicts an example of the SIB established in AS 4 in . 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 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.

SAVNET Communication Mechanism

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 , the SAVNET agent gathers available information from these sources and stores the relevant information in the SIB.

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 . 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.

SAV-specific Information Communication Mechanism

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 or rsync for retrieving RPKI objects and RTR 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. 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 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 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 , 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.

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 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.

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. 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.

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 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.

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 , 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 can be used for remote configuration and retrieval of operational state. Mechanisms such as syslog 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.

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 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.

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. 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.

IANA Considerations This document has no IANA requirements.

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:

• 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.

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.

References Normative References RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. BCP 38, RFC 2827, is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network, and to help ensure that traffic is traceable to its correct source network. As a side effect of protecting the Internet against such attacks, the network implementing the solution also protects itself from this and other attacks, such as spoofed management access to networking equipment. There are cases when this may create problems, e.g., with multihoming. This document describes the current ingress filtering operational mechanisms, examines generic issues related to ingress filtering, and delves into the effects on multihoming in particular. This memo updates RFC 2827. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document identifies a need for and proposes improvement of the unicast Reverse Path Forwarding (uRPF) techniques (see RFC 3704) for detection and mitigation of source address spoofing (see BCP 38). Strict uRPF is inflexible about directionality, the loose uRPF is oblivious to directionality, and the current feasible-path uRPF attempts to strike a balance between the two (see RFC 3704). However, as shown in this document, the existing feasible-path uRPF still has shortcomings. This document describes enhanced feasible-path uRPF (EFP-uRPF) techniques that are more flexible (in a meaningful way) about directionality than the feasible-path uRPF (RFC 3704). The proposed EFP-uRPF methods aim to significantly reduce false positives regarding invalid detection in source address validation (SAV). Hence, they can potentially alleviate ISPs' concerns about the possibility of disrupting service for their customers and encourage greater deployment of uRPF techniques. This document updates RFC 3704. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Informative References Tsinghua University Zhongguancun Laboratory Zhongguancun Laboratory Huawei USA National Institute of Standards and Technology This document analyzes the problem space and provides a gap analysis of existing inter-domain source address validation (SAV) mechanisms. Based on these findings, it outlines the technical requirements for future improvements. Tsinghua University Tsinghua University Zhongguancun Laboratory Huawei Zhongguancun Laboratory This document describes a generic architecture for intra-domain Source Address Validation (SAV). It provides a common framework for developing new intra-domain SAV mechanisms and describes the conditions under which this architecture can improve SAV accuracy and operational efficiency with respect to existing intra-domain SAV mechanisms. Zhongguancun Laboratory China Mobile Tsinghua University Huawei Technologies Zhongguancun Laboratory The SAV rules of existing source address validation (SAV) mechanisms are derived from other core data structures (e.g., FIB-based uRPF) that are not dedicatedly designed for source filtering. Consequently, these mechanisms have limitations in deployable scenarios and traffic handling policies. To overcome these limitations, this document introduces general SAV capabilities from a data plane perspective. How to implement the capabilities and how to generate SAV rules are not in the scope of this document. In the Resource Public Key Infrastructure (RPKI), Certificate Authorities (CAs) publish certificates, including end-entity certificates, Certificate Revocation Lists (CRLs), and RPKI signed objects to repositories. Relying Parties retrieve the published information from those repositories. This document specifies a new RPKI Repository Delta Protocol (RRDP) for this purpose. RRDP was specifically designed for scaling. It relies on an Update Notification File which lists the current Snapshot and Delta Files that can be retrieved using HTTPS (HTTP over Transport Layer Security (TLS)), and it enables the use of Content Distribution Networks (CDNs) or other caching infrastructures for the retrieval of these files. In order to verifiably validate the origin Autonomous Systems and Autonomous System Paths of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data and router keys from a trusted cache. This document describes a protocol to deliver them. This document describes version 1 of the RPKI-Router protocol. RFC 6810 describes version 0. This document updates RFC 6810. YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] This document describes the syslog protocol, which is used to convey event notification messages. This protocol utilizes a layered architecture, which allows the use of any number of transport protocols for transmission of syslog messages. It also provides a message format that allows vendor-specific extensions to be provided in a structured way. This document has been written with the original design goals for traditional syslog in mind. The need for a new layered specification has arisen because standardization efforts for reliable and secure syslog extensions suffer from the lack of a Standards-Track and transport-independent RFC. Without this document, each other standard needs to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. This layered architecture approach also provides a solid basis that allows code to be written once for each syslog feature rather than once for each transport. [STANDARDS-TRACK]

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.