SAVNET K. Sriram Internet-Draft US NIST Updates: 2827 3704 8704 (if approved) L. Qin Intended status: Best Current Practice Zhongguancun Laboratory Expires: 6 May 2027 I. Lubashev Akamai Technologies N. Geng Huawei D. Li Tsinghua University 2 November 2026 IntraSAV - A Solution for Intra-Domain Source Address Validation draft-sriram-savnet-intrasav-solution-01 Abstract This document specifies a solution, named IntraSAV, for intra-domain source address validation (SAV). This solution addresses the problem stated in the ietf-savnet-intra-domain-problem-statement (RFC-to-be) document. This document updates BCP 38 ([RFC2827]) and BCP 84 ([RFC3704], [RFC8704]) by providing a more comprehensive solution methodology and accommodating prefixes that are not routed but used for sourcing traffic originating from an AS. Status of This Memo 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 6 May 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Sriram, et al. Expires 6 May 2027 [Page 1] Internet-Draft IntraSAV November 2026 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. IntraSAV Solution . . . . . . . . . . . . . . . . . . . . . . 3 3. Implementation and Deployment Considerations . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction The scope of intra-domain SAV is stated in [I-D.ietf-savnet-intra-domain-problem-statement] as follows: "Intra- domain SAV is applied at external interfaces (on routers) facing entities that are not deployed as neighboring ASes and are therefore not covered by inter-domain SAV. For example, an entity can be a single host, a set of hosts, or a customer network with no AS that manages one or more IP prefixes. The entity may source traffic using prefixes assigned by the AS or its own BYOIP prefixes. From the perspective of other ASes, such traffic is originated by the AS." This document specifies a solution, named IntraSAV, for intra-domain source address validation (SAV). This solution addresses the problem stated in the ietf-savnet-intra-domain-problem-statement (RFC-to-be) document. 1.1. Terminology The terminology used in this document follows Section 1.1 in [I-D.ietf-savnet-intra-domain-problem-statement]. Sriram, et al. Expires 6 May 2027 [Page 2] Internet-Draft IntraSAV November 2026 1.2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. IntraSAV Solution The focus here is on SAV at router interfaces, where traffic sourced from prefixes used (or originated) at the local AS (i.e., the SAV- performing AS) arrives from either (1) directly connected hosts, or (2) customers with non-BGP interfaces [I-D.ietf-savnet-intra-domain-problem-statement]. In these scenarios, the AS may support two types of prefixes for route or traffic origination: (1) its own provider-owned prefixes, and (2) Bring Your Own IP (BYOIP) prefixes. The proposed SAV solution requires BYOIP customers to inform the local AS about the specific prefixes they intend to use on their respective interfaces for routing and/or source addressing. This data becomes part of the configuration information at the local AS (as defined in the Terminology section of [I-D.ietf-savnet-inter-domain-problem-statement]). The local AS similarly incorporates the routing and source addressing requirements (on a per-interface basis) for its own (provider-owned) prefixes into this configuration. Finally, possibly using a SAV agent, the local AS uses the consolidated configuration information to construct and deploy an intra-domain SAV table (allowlist) for each relevant interface of its Customer Edge (CE) routers. The prefix owners (whether the BYOIP customers or the local AS) should register ROAs for their prefixes, authorizing the local AS as the origin. For prefixes originating at the local AS (for either routing or sourcing), the local configuration information takes precedence over the ROA information for both route origination and SAV. However, the local AS should still check the ROAs against its configuration and alert customers to any inconsistencies. This verification is important because remote ASes (one or more hops away) rely on these ROAs (along with other information) to compute their own inter-domain SAV tables [I-D.ietf-savnet-inter-domain-problem-statement] [I-D.ietf-sidrops-bar-sav]. The IntraSAV solution method is illustrated below in Figure 1. The figure also illustrates an internal AS topology. IntraSAV is applied at CE routers 1 and 2 on Interfaces 1 and 2 that support Customers 1 and 2, respectively. The Configuration Manager (CM), including a SAV Sriram, et al. Expires 6 May 2027 [Page 3] Internet-Draft IntraSAV November 2026 Agent, plays a key role in facilitating IntraSAV. The role of the CM is to authenticate the customers and collect their configuration information for routing and SAV purposes. Customer 1 registers prefixes {p, q} and specifies that both prefixes are routed (i.e., announced). Note that "can be routed (announced)" implies that the prefix can also be used for sourcing traffic. On the other hand, Customer 2 registers prefixes {r, s} and specifies that r is routed while s is not routed but used for sourcing at this AS. The SAV agent in the CM makes use of this configuration information and programs CE router interfaces 1 and 2 with SAV tables (allowlists) {p, q} and {r, s}, respectively. As long as the configuration information available to the local Configuration Manager is complete, IntraSAV guarantees zero improper blocks and zero improper admits. [ External AS / Internet ] | +-----------------------------------AS boundary--------+ | | | | +-------------+ | | | ASBR | | | +-------------+ | | | Interface 3 | | +-------------+ | | | Core router | | | +-------------+ | | / \ | | +-----------------+ +------------------+ | | | Customer Edge | | Customer Edge | | | | CE router 1 | | CE router 2 | | | +-----------------+ +------------------+ | | Interface 1 /\{p, q} {r, s}/\ Interface 2 | | | \ SAV tables for / | | | | \ Interfaces 1 / | | | | \ and 2 / | | | | +-----------------------+ | | | | | Configuration Manager | | | | | | [SAV Agent] | | | | | +-----------------------+ | | | | /\ (configuration /\ | | | | | information) | | | +-----|------------|-----------------|-----------------+ | | | | | | | | Prefixes {p, q} | | Prefixes {r, s} Customer 1 -----+ +------ Customer 2 (both p and q are routed) (r is routed but s is used only for sourcing) Sriram, et al. Expires 6 May 2027 [Page 4] Internet-Draft IntraSAV November 2026 Figure 1: Illustration of internal AS topology and the IntraSAV solution method. ** To be Discussed (by authors and the WG): The AS operator may choose to apply IntraSAV on Interface 3 at the ASBR in Figure 1. This type of ingress SAV may be done in addition to or as an alternative to doing IntraSAV at the CE router interfaces described above. The important consideration is that the operator should be certain, based on knowledge of the local topology and information in the CM, that all the traffic the ASBR interface receives is expected to be sourced from known prefixes and originating from the local AS. It is clear in the topology of Figure 1 that the expected set of traffic-sourcing prefixes at Interface 3 is equal to the superset of the sets of prefixes configured for the CE router interfaces (Interfaces 1 and 2). So, the operator can confidently apply the prefix-superset {p, q, r, s} as the SAV table (allowlist) on Interface 3 at the ASBR (see Figure 1). It may be noted that this proposal (i.e., SAV at an internal ASBR interface) likely goes beyond the scope stated in [I-D.ietf-savnet-intra-domain-problem-statement] except when the ASBR interface in consideration is directly serving a set of hosts or a non-AS customer. Generally, this proposal is useful for cases when the AS operator determines that it is much more feasible to upgrade their ASBR rather than the CE routers for SAV. ** 3. Implementation and Deployment Considerations The local AS maintains a Configuration Manager (CM). For the prefixes provisioned by the local AS, the AS operator enters in the CM the configuration information that associates the prefixes to specific interfaces for the purposes of route announcements and SAV. Non-AS customers with BYOIP prefixes also register configuration information for their prefixes in the CM. An example data structure for the configuration information is shown in Figure 2. Each such record lists routing and sourcing-only prefixes applicable for each {customer, interface} pair. The interface ID is provided by the AS operator. The routed prefixes (Figure 2) are included by default in the SAV table for the given interface; the SAV agent (Figure 1) performs this work. If a set of sourcing-only prefixes is present in the record (Figure 2), this set is also included in the SAV table. The configuration information in the CM is updated whenever any changes occur in prefixes regarding their routing or sourcing usage at an interface. Sriram, et al. Expires 6 May 2027 [Page 5] Internet-Draft IntraSAV November 2026 +--------------------------------------------------+ | Customer ID | +--------------------------------------------------+ | Interface ID | +--------------------------------------------------+ | Prefixes routed (announced) | | (allowed by default for traffic sourcing also) | +--------------------------------------------------+ | Prefixes used for traffic sourcing only | +--------------------------------------------------+ | Special instructions from customer (optional) | +--------------------------------------------------+ Figure 2: Illustration of a Configuration Manager data structure. A customer may use the bottommost field (Figure 2) to provide an optional special instruction such as "the union of all our prefixes must be included in the SAV table at all router interfaces where we are present (at this AS)". In this example, the customer's registered configuration information conveys that they may be routing different sets of prefixes from different interfaces but use a common union set of prefixes for source addresses at all those interfaces. This is a form of asymmetric routing and sourcing. The data structure illustrated in Figure 2 allows the customer to register (configure) any form of asymmetric routing or sourcing. 4. Security Considerations Checking the configuration information against ROA information helps in affirming accuracy and avoiding improper blocks and improper permits in IntraSAV at the local AS. This, in turn, helps with avoiding improper blocks and improper permits in inter-domain SAV (e.g., BAR-SAV [I-D.ietf-sidrops-bar-sav]) at ASes one or more hops away. The AS operator or its CM should cross-check the customer ID (or organization name) and associated prefixes against the corresponding RPKI resource certificate or prefix registration in the RIR. This check serves as an enhanced form of authentication (reinforcing the customer registration process) for the configuration information for a given customer. 5. IANA Considerations This document does not have IANA considerations. Sriram, et al. Expires 6 May 2027 [Page 6] Internet-Draft IntraSAV November 2026 6. Acknowledgements The authors wish to thank Paul Vixie, Doug Montgomery, Jeff Haas, Joel Halpern, and Ron Bonica for suggestions and discussions. 7. References 7.1. Normative References [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, . [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, . [RFC8704] Sriram, K., Montgomery, D., and J. Haas, "Enhanced Feasible-Path Unicast Reverse Path Forwarding", BCP 84, RFC 8704, DOI 10.17487/RFC8704, February 2020, . [I-D.ietf-savnet-intra-domain-problem-statement] Qin, L., Li, D., Wu, J., Huang, M., and N. Geng, "Problem Statement, Gap Analysis, and Requirements for Intra-domain Source Address Validation", Work in Progress, Internet- Draft, draft-ietf-savnet-intra-domain-problem-statement- 26, 1 June 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 7.2. Informative References Sriram, et al. Expires 6 May 2027 [Page 7] Internet-Draft IntraSAV November 2026 [I-D.ietf-savnet-inter-domain-problem-statement] Li, D., Qin, L., Liu, L., Huang, M., and K. Sriram, "Problem Statement, Gap Analysis, and Requirements for Inter-domain Source Address Validation", Work in Progress, Internet-Draft, draft-ietf-savnet-inter-domain-problem- statement-22, 2 November 2026, . [I-D.ietf-sidrops-bar-sav] Sriram, K., Lubashev, I., and D. Montgomery, "Source Address Validation Using BGP UPDATEs, ASPA, and ROA (BAR- SAV)", Work in Progress, Internet-Draft, draft-ietf- sidrops-bar-sav-10, 19 July 2026, . Authors' Addresses Kotikalapudi Sriram US NIST Gaithersburg, MD 20899, United States of America Email: ksriram@nist.gov Lancheng Qin Zhongguancun Laboratory Beijing China Email: qinlc@zgclab.edu.cn Igor Lubashev Akamai Technologies Cambridge, MA 02142, United States of America Email: ilubashe@akamai.com Nan Geng Huawei Beijing China Email: gengnan@huawei.com Sriram, et al. Expires 6 May 2027 [Page 8] Internet-Draft IntraSAV November 2026 Dan Li Tsinghua University Beijing China Email: tolidan@tsinghua.edu.cn Sriram, et al. Expires 6 May 2027 [Page 9]