]> 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 generating interface-based prefix allowlists for intra-domain source address validation (SAV) on external interfaces facing directly connected hosts or non-BGP customer networks. The mechanism derives source prefixes from routing information and combines them with source prefixes provisioned by the AS operator. Routers use the combined source prefixes to generate SAV allowlists.

Introduction This document focuses on SAV performed on external interfaces facing entities that are not deployed as neighboring ASes, including directly connected hosts and non-BGP customer networks, consistent with . Each router generates and applies an allowlist (i.e., the "Interface-based prefix allowlist" mode in ) for each interface within the scope of this document. The allowlist contains the source prefixes that are permitted on the interface for the attached entity. A router can derive source prefixes from existing routing information. An operator can also provision source prefixes when routing information is insufficient. The router combines the routing-derived and operator-provisioned source prefixes and uses the resulting prefix set to generate the SAV allowlist. The mechanism can be deployed incrementally and provides security benefits on interfaces where complete and correctly generated allowlists are enforced. When an interface deploys an allowlist, spoofed traffic with source addresses not covered by the allowlist cannot enter the AS through that interface. As a result, even partial deployment (e.g., enabling the mechanism on a subset of such external interfaces) reduces the potential attack surface. As the mechanism is deployed on more external interfaces within the AS, the overall protection against source address spoofing attacks increases correspondingly, provided that the additional allowlists are complete and correctly generated. The reader is encouraged to be familiar with and .

SAV Allowlist Generation Procedure

Routing-Derived Source Prefixes For each entity, the mechanism derives a set of source prefixes by aggregating routing information associated with the interfaces connecting to that entity. The mechanism needs to know which interfaces connect to the same entity and the prefix reachability information associated with each of these interfaces. For each such interface, the mechanism obtains the prefixes for which routing information maintained by the corresponding router indicates reachability through that interface. A prefix contributes to the entity's set only when the route retains sufficient attachment or origin context to associate the prefix with that entity; reachability through an internal next hop alone is not sufficient. The union of the accepted prefixes forms the set of routing-derived source prefixes for the entity, denoted as R. The routing-derived source prefixes can be obtained and updated automatically as routing information changes.

Source Entity Identifier (SEI) A Source Entity Identifier (SEI) is an identifier assigned by the network operator to represent a source entity. An SEI is unique within the intra-AS routing domain in which it is used. Each SEI is associated with one or more interfaces of routers that connect directly to the corresponding source entity. This binding allows routers to explicitly indicate which entity a specific interface belongs to. An SEI and its prefix associations can be distributed through intra-AS routing messages. If route advertisements carry an SEI, the receiving router can correlate prefixes that belong to the same entity. This correlation is useful in asymmetric routing scenarios. For example, a multihomed customer network may advertise different subsets of its prefixes at different attachment points while legitimately sending traffic using any of those prefixes through any of the attachment points. An allowlist derived only from prefixes learned at the local attachment point could then improperly block legitimate customer-originated traffic. Correlating the attachment points by SEI allows the mechanism to form the entity-wide R and apply it to each interface in the same authorization context. Each router can identify routing-derived source prefixes 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 S.
2. Using all received intra-AS rouing messages, for each SEI value in Set S, obtain the set of source prefixes associated with the same SEI value.

Operator-Provisioned Source Prefixes The AS operator can provision source prefixes for an entity using existing network management or automation mechanisms. These prefixes explicitly authorize source address space that the entity is legitimately allowed to use for originating traffic. The operator may maintain this information as either a complete authorization inventory or a supplementary set containing only prefixes that cannot be derived from routing information. The provisioned source address space can include, for example:

• prefixes assigned to the entity by the local AS; and
• prefixes obtained by the entity independently of the local AS, such as prefixes assigned by another provider or prefixes brought by the entity itself (e.g., BYOIP prefixes).

For prefixes that are not assigned by the local AS, the AS operator should require the entity to provide sufficient information or evidence demonstrating that the entity is authorized to use those prefixes for source traffic. The source prefixes provisioned by the AS operator for an entity form the set of operator-provisioned source prefixes for that entity, denoted as O. The mechanism needs to know which interfaces connect to the entity so that these source prefixes can be used when generating SAV allowlists on the corresponding interfaces.

SAV Allowlist Generation The router combines the routing-derived source prefixes R and the operator-provisioned source prefixes O. The combined source prefix set A is the union of the two sets: A = R ∪ O The router uses A to generate the SAV allowlist for the interfaces facing the entity. As a result, a source prefix covered by either routing-derived information or operator provisioning is included in the allowlist, reducing the risk of improper blocking when the two information sources are temporarily inconsistent or when one information source does not contain all legitimate source prefixes.

Operational Considerations

Maintaining Entity-Interface Associations The mechanism requires knowledge of which interfaces connect to the same entity so that routing information and operator-provisioned source prefixes can be applied consistently across those interfaces. When an entity is connected through multiple interfaces or routers, the association information should identify all interfaces facing that entity.

Handling Operator-Provisioned Source Prefixes Operators can leverage existing network management and automation tools to maintain and distribute operator-provisioned source prefixes for the corresponding entity. These source prefixes can include prefixes that are not represented in routing information. The provisioning system should record whether O is a complete authorization inventory or a supplementary set. When routing configuration changes before a complete authorization inventory is updated, the routing-derived source prefix set can update automatically. Combining the routing-derived and operator-provisioned source prefixes allows the generated SAV allowlist to include the updated routing-derived prefixes during this period.

Security Considerations Security considerations described in also apply.

IANA Considerations This document has no IANA actions.

Informative References 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. Zhongguancun Laboratory Tsinghua University Tsinghua University Zhongguancun Laboratory Huawei Source address validation (SAV) is an important means to mitigate IP source address spoofing [RFC2827]. This document analyzes the gaps in current operational mechanisms for intra-domain SAV. It also identifies the properties that new intra-domain SAV mechanisms are expected to provide. 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 such mechanisms can improve SAV accuracy with respect to existing intra-domain SAV mechanisms.