| Internet-Draft | SAV-IGP | April 2026 |
| Qin, et al. | Expires 22 October 2026 | [Page] |
SPA-based SAVNET is a new intra-domain source address validation (SAV) mechanism which requires exchanging and communicating SPA information among routers in an intra-domain network (see [I-D.li-savnet-source-prefix-advertisement]). Routers at the boundary automatically generate accurate SAV rules by using routing information and SPA information. These rules construct a validation boundary which checks the validity of the source address of any data packets flowing into the intra-domain network. This document describes a method to implement SPA-based SAVNET by using OSPF and IS-IS.¶
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 22 October 2026.¶
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.¶
SPA-based SAVNET [I-D.li-savnet-source-prefix-advertisement] is proposed to improve the accuracy of source address validation (SAV) at the intra-domain network boundary. We refer to both edge routers and border routers as routers at the boundary of an intra-domain network. Routers at the boundary automatically generate accurate SAV rules by using routing information and SAV-specific information. These rules construct a validation boundary which checks the validity of the source address of any data packets flowing into the intra-domain network.¶
Edge routers will generate a prefix allowlist on interfaces facing a sub network or a set of host, including only prefixes that can be used as the source address by the sub network or the set of hosts. To construct a prefix allowlist on the specific interface, the edge router inspects its local Routing Information Base (RIB) and identifies destination prefixes that are reachable via that interface. These prefixes should cover the complete source address space of the connected hosts, single-homed sub networks, or multi-homed sub networks with symmetric routing.¶
In asymmetric routing scenarios, these prefixes derived from the local RIB may fail to cover the complete source address space of multi-homed sub networks. To address this limitation, the Source Prefix Advertisement (SPA) process [I-D.li-savnet-source-prefix-advertisement] is required to enable the construction of a more accurate and complete allowlist.¶
Border routers aim to generate a prefix blocklist on interfaces facing an external AS, including prefixes that can be only used as the source address by the local AS (i.e., internal source addresses).¶
The detailed procedures of SPA information generation and SAV rule generation have been described in [I-D.li-savnet-source-prefix-advertisement]. This document describes a method to implement SPA information communication by using OSPF and IS-IS. The reader is encouraged to be familiar with [I-D.li-savnet-source-prefix-advertisement].¶
SAV Rule: The rule that describes the mapping relationship between a source address (prefix) and its valid incoming router interface(s).¶
SAV-specific Information: The information specialized for SAV rule generation, which is exchanged among routers.¶
Sub Network: A sub network (or subnet for short) may operate its own internal routing protocols (e.g., a separate IGP), but it is considered part of the AS in the global routing system. It is connected to one or more routers of the AS for Internet connectivity. It originates traffic but does not transit traffic for other networks.¶
Edge Router: A router connected to hosts or sub networks of the local AS. It forwards traffic from hosts or sub networks into the intra-domain network.¶
Border Router: A router positioned at the boundary between the local AS and one or more external Autonomous Systems (ASes). It runs EBGP and exchanges routing information with external peers.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The key idea is to add the SNI value into the prefix information when the edge router distributes the prefix information of the connected sub network or hosts via the IGP. As shown in Figure 1, the SAVNET Agent of a Sender Router provides its SPA information to other SAVNET routers via IGP. After receiving SPA information from other routers, the SAVNET Agent of the Receiver Router generates SAV rules by using SPA information or/and routing information. The Sender Router can be a edge router. The SPA information includes the prefix information and the SNI value of the connected sub network or hosts. The Receiver Router can be a edge router or a border router.¶
+---------------------+ +---------------------+ | Sender Router | Prefix and | Receiver Router | | +------------+ | SNI Value | +------------+ | | | IGP LSDB +------------------------->+ IGP LSDB | | | +-----^------+ | | +-----+------+ | | | | | | | | +-------+---------+ | | +--------v--------+ | | | SAVNET Agent | | | | SAVNET Agent | | | | +-------------+ | | | | +-------------+ | | | | | Information | | | | | | Information | | | | | | Provider | | | | | | Receiver | | | | | +-------------+ | | | | +-------------+ | | | +-----------------+ | | +-----------------+ | | | | | +---------------------+ +---------------------+
The overall procedure of SPA information communication is as follows:¶
At the Sender Router: The SAVNET Agent provides the SNI value of the connected sub network or hosts to the Link State Database (LSDB) of IGP. The IGP will synchronize the LSDB, which includes prefix information and SNI value, among routers runing the IGP.¶
At the Receiver Router: The SAVNET Agent extracts prefix information and SNI value from the LSDB of IGP and then generates SAV rules as described in [I-D.li-savnet-source-prefix-advertisement].¶
The existing administrative Tag Sub-TLV of IS-IS and OSPF can be used for SPA information communication. Specifically, when a edge router distributes IP prefix information of the connected sub network or hosts, it carries the SNI value of that network in the Administrative Tag Sub-TLV.¶
For routers running IS-IS, they can carry the SNI value in the Administrative Tag Sub-TLV (defined in [RFC5130]), which can be included in: SRv6 Locator TLV (27), IPv4 Algorithm Prefix Reachability TLV (126), IPv6 Algorithm Prefix Reachability (127), Extended IP Reachability TLV (135), Multi-Topology Reachable IPv4 Prefixes TLV (235), IPv6 Reachability TLV (236), Multi-Topology Reachable IPv6 Prefixes TLV (237).¶
For routers running OSPF, they can carry the SNI value in the Administrative Tag Sub-TLV [RFC9825] within the OSPF Extended Prefix TLV Sub-TLV [RFC7684].¶
For routers running OSPFv3, they can include the SNI value in the Administrative Tag Sub-TLV [RFC9825] within the OSPFv3 Intra-Area-Prefix TLV, Inter-Area-Prefix TLV, and External-Prefix TLV [RFC8362].¶
The security considerations described in [I-D.li-savnet-source-prefix-advertisement] also applies to this document.¶
TBD.¶