| Internet-Draft | Intra-domain SPA | September 2026 |
| Qin, et al. | Expires 28 March 2027 | [Page] |
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.¶
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 28 March 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.¶
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 [I-D.ietf-savnet-intra-domain-problem-statement]. Each router generates and applies an allowlist (i.e., the "Interface-based prefix allowlist" mode in [I-D.ietf-savnet-general-sav-capabilities]) 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 [I-D.ietf-savnet-intra-domain-problem-statement] and [I-D.ietf-savnet-intra-domain-architecture].¶
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.¶
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:¶
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.¶
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.¶
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.¶
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.¶
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.¶
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 described in [I-D.ietf-savnet-intra-domain-architecture] also apply.¶
This document has no IANA actions.¶