]> Zhongguancun Laboratory

Beijing China qinlc@mail.zgclab.edu.cn

Huawei

Beijing China gengnan@huawei.com

Tsinghua University

Beijing China tolidan@tsinghua.edu.cn

Routing SAVNET Internet-Draft This document describes a mechanism for intra-domain source address validation (SAV), called Source Prefix Advertisement (SPA) for Intra-domain SAVNET (Intra-domain SPA). The mechanism enables intra-domain routers to generate accurate SAV rules by leveraging routing information together with SAV-specific information, including Source Entity Identifiers (SEIs) and Hidden Prefix (HP). Intra-domain SPA improves the precision and reliability of source address validation, addressing challenges such as asymmetric routing and the use of hidden prefixes by legitimate source entities.

Introduction Existing unicast Reverse Path Forwarding (uRPF) mechanisms (e.g., strict uRPF) may incorrectly drop legitimate data packets in scenarios involving asymmetric routing or hidden prefixes (see ). Similarly, ACL-based ingress filtering relies entirely on manual updates, which can be difficult to maintain. To improve accuracy and enable automatic updates, this document proposes a new intra-domain source address validation (SAV) mechanism, called Source Prefix Advertisement (SPA) for Intra-domain SAVNET (referred to as Intra-domain SPA). Intra-domain SPA allows routers in an intra-domain network to obtain and exchange SAV-specific information, including Source Entity Identifiers (SEIs) and Hidden Prefixes (HPs), in order to generate more precise SAV rules automatically. The reader is encouraged to be familiar with and .

Terminology SAV Rule: The rule that describes the mapping relationship between a source address (prefix) and its valid incoming router interface(s). SAVNET Router: An intra-domain router that deploys Intra-domain SPA. Non-BGP Customer Network: A stub network connected to one or more routers of the AS for Internet connectivity. It only originates traffic and does not participate in BGP routing exchanges with the AS. Source Entity Identifier (SEI): A unique identifier assigned by an operator to represent a specific source entity, such as a non-BGP customer network or a set of hosts within a LAN. Each SEI is associated with one or more interfaces on the SAVNET routers that connect to the corresponding source entity. Hidden Prefix: A hidden prefix is a prefix legitimately used by a source entity but not visible in the intra-domain routing system.

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.

Deployment Scope Intra-domain SPA focuses solely on source address validation (SAV) performed on the external interfaces of an intra-domain network. Each SAVNET router can automatically generate either an allowlist SAV rule (i.e., “Interface-based prefix allowlist” mode in ) or a blocklist SAV rule (i.e., “Interface-based prefix blocklist” mode in ) for a specific interface, depending on the role of the connected entity.

• Interfaces facing a set of hosts: The SAVNET router generates an allowlist SAV rule that precisely covers the source address space legitimately used by the connected hosts.
• Interfaces facing a non-BGP customer network: The SAVNET router generates an allowlist SAV rule that precisely covers the source address space legitimately used by the non-BGP customer network.
• Interfaces facing an external AS: The SAVNET router generates a blocklist SAV rule that precisely covers the source address space that is valid only within the local AS and must not be used by external networks.

Incremental Deployment Considerations Intra-domain SPA can be deployed incrementally and still provide immediate security benefits within its deployment scope. Each SAVNET router that supports Intra-domain SPA applies SAV rules on its external interfaces — whether facing hosts, non-BGP customer networks, or external ASes. When an interface is protected by Intra-domain SPA, spoofed traffic with unallowed source addresses cannot enter the domain through that interface. As a result, even partial deployment (e.g., enabling Intra-domain SPA on a subset of external interfaces) effectively reduces the potential attack surface. By using allowlist SAV rules, SAVNET routers prevent connected hosts or non-BGP customer networks from sending packets with unauthorized source addresses. By using blocklist SAV rules, SAVNET routers prevent connected external ASes from sending packets that use internal-use-only source addresses. As more SAVNET routers in the AS adopt Intra-domain SPA, the overall protection against source address spoofing attacks increases correspondingly, achieving progressive and cumulative deployment benefits without requiring full coverage from the outset.

SAV-specific Information in Intra-domain SPA Intra-domain SPA uses SAV-specific information to supplement routing data, enabling accurate and automated generation of SAV rules. Two key types of SAV-specific information are used: Source Entity Identifier (SEI) and Hidden Prefix (HP). These serve complementary roles: SEI identifies the source entity originating traffic, while HP provides authoritative information about prefixes legitimately used by the source entity but not visible in the intra-domain routing system.

Source Entity Identifier (SEI) A Source Entity Identifier (SEI) is a unique identifier assigned by the network operator to represent a source entity, which may be a non-BGP customer network or a set of hosts within a LAN connected to the SAVNET router. Each SEI is associated with one or more interfaces of SAVNET routers that connect directly to the corresponding source entity. This binding allows routers to explicitly indicate which entity a specific interface belongs to. SEIs are propagated within the domain via route advertisements. Upon receiving routes with SEIs, routers can correlate multiple routes belonging to the same entity. This capability is especially useful in asymmetric routing scenarios. For example, when a non-BGP customer network connects to multiple routers and advertises different subsets of its prefixes, uRPF-based filtering may incorrectly drop return traffic. By using SEI, routers can aggregate prefixes for the same entity and generate a unified allowlist, avoiding improper blocks.

Hidden Prefix (HP) A hidden prefix is a prefix legitimately used by a source entity but not visible in the intra-domain routing system. Examples include:

• A host that uses a source address not allocated by the operator for Direct Server Return (DSR) or similar applications.
• A non-BGP customer network that uses certain prefixes not announced to the operator.

To avoid improper permits, non-BGP customers or hosts provide their hidden prefixes to the operator, which are then used as SAV-specific information when generating rules on the corresponding interfaces. Authorization for hidden prefixes may be conveyed through a Traffic Origin Authorization (TOA) object signed by the prefix holder, indicating that traffic from the hidden prefix is legitimate. SAVNET routers can use this information to allow legitimate traffic from hidden prefixes, even when the prefixes are not visible in intra-domain routing.

SAV Rule Generation Procedure This section describes two approaches for generating SAV rules in Intra-domain SPA. The first approach relies solely on routing information and provides a simple baseline mechanism. The second approach enhances accuracy by combining routing information with SAV-specific information, addressing asymmetric routing and hidden prefix scenarios.

SAV Using Routing Information This subsection first describes how routing information can be used to generate more accurate SAV rules than existing intra-domain SAV mechanisms (e.g., strict uRPF and loose uRPF). Each SAVNET router connected to a set of hosts or a non-BGP customer network generates an allowlist SAV rule. The procedure for allowlist generation is as follows:

1. Extract prefixes from the Forwarding Information Base (FIB) or/and Routing Information Base (RIB): Select all unique prefixes in the router’s FIB or/and RIB whose next-hop interface points toward the connected set of hosts or non-BGP customer network.
2. Construct the allowlist: Include these prefixes in the allowlist SAV rule for the corresponding interface. The allowlist defines the legitimate source address space that may appear on this interface.

Each SAVNET router connected to an external AS generates a blocklist SAV rule. The procedure for blocklist generation is as follows:

1. Extract internal-use prefixes: Select all unique prefixes from the routing information learned via the intra-domain routing protocol that are originated within the local AS.
2. Construct the blocklist: Include these internal-use prefixes in the blocklist SAV rule for interfaces facing external ASes, preventing incoming traffic that uses internal source addresses.

This routing-based approach works effectively when routing visibility is complete and symmetric. However, in scenarios involving asymmetric routing or hidden prefixes, the allowlist derived solely from routing information may not fully cover the legitimate source address space of a set of hosts or a non-BGP customer network. As a result, legitimate packets may be improperly blocked. To improve SAV accuracy and avoid such improper blocking, the next subsection introduces an enhanced rule-generation procedure that combines routing information with SAV-specific information (i.e., Source Entity Identifier and Hidden Prefix).

SAV Using SAV-specific Information and Routing Information This subsection describes an enhanced rule generation approach that leverages both routing information and SAV-specific information to improve SAV accuracy under conditions such as asymmetric routing and hidden prefixes. Each SAVNET router connected to a set of hosts or a non-BGP customer network generates an allowlist SAV rule as follows:

1. Identify source entities: For all source entities connected to the router, create a set of their corresponding Source Entity Identifier (SEI) values. Denote this set as Set A.
2. Associate prefixes with SEIs: Using all available SAV-specific information, for each SEI value in Set A, obtain the set of source prefixes associated with the same SEI value.
3. Construct the allowlist: For each interface connected to a source entity, construct an allowlist that includes:
   • all prefixes associated with the SEI configured on that interface; and
   • any hidden prefixes that the source entity has explicitly provided to the operator.

Each SAVNET router connected to an external AS generates a blocklist SAV rule as follows:

1. Extract internal-use prefixes: Select all unique prefixes from the routing information learned via the intra-domain routing protocol.
2. Filter out externally valid prefixes: Exclude any prefix that is considered externally valid, including:
   • prefixes that are observed in routing information learned from external ASes via inter-domain routing; and
   • prefixes that have an external AS number (ASN) listed as the origin in a valid Route Origin Authorization (ROA) or Traffic Origin Authorization (TOA).
3. Construct the blocklist: Include the remaining prefixes in the blocklist SAV rule for interfaces facing external ASes. This prevents traffic from external ASes from using source addresses that are valid only within the local AS.

Operational Considerations

Handling SEIs

SEI Assignment and Configuration Operators are recommended to use network management or automation tools to assign and maintain SEIs consistently to reduce the risk of misconfiguration. When a source entity connects to multiple routers, all interfaces MUST use the same SEI to enable correct aggregation of prefixes and accurate identification of the entity across the domain.

Handling Hidden Prefixes Hidden prefix information can be incorporated into SAV rule generation on interfaces facing the entities, without requiring a separate synchronization mechanism. Authorization for using hidden prefixes may be conveyed, for example, via a Traffic Origin Authorization (TOA) object or other mechanisms approved by the prefix holder. Operators can leverage existing operational management and automation tools to record and apply hidden prefix information consistently when generating SAV rules.

Security Considerations The security considerations described in and also applies to this document.

IANA Considerations This document has no IANA actions.

References Normative References 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. 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. Informative References This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS (Denial of Service) attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. 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. 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, which are not dedicatedly designed for source filtering. Therefore there are some limitations related to deployable scenarios and traffic handling policies. To overcome these limitations, this document introduces the general SAV capabilities from data plane perspective. How to implement the capabilities and how to generate SAV rules are not in the scope of this document. Tsinghua University Tsinghua University Zhongguancun Laboratory Zhongguancun Laboratory Huawei This document provides a gap analysis of existing intra-domain source address validation mechanisms, describes the fundamental problems, and defines the basic requirements for technical improvements. Tsinghua University Tsinghua University Zhongguancun Laboratory Huawei Zhongguancun Laboratory This document specifies the architecture of intra-domain SAVNET, which aims to achieve accurate source address validation (SAV) at external interfaces of an intra-domain network in an automated manner. It describes the conceptual design of intra-domain SAVNET, along with its use cases and design requirements, to help ensure that the intended objectives are met. Zhongguancun Laboratory Workonline Tsinghua University Akamai This document defines a standard profile for Traffic Origin Authorizations (TOAs), a Cryptographic Message Syntax (CMS) protected content type for use with the Resource Public Key Infrastructure (RPKI). A TOA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate traffic using source IP addresses within the address block.