Source Prefix Advertisement for Intra-domain SAVNET
draft-li-savnet-source-prefix-advertisement-07

SAVNET                                                            L. Qin
Internet-Draft                                   Zhongguancun Laboratory
Intended status: Informational                                   N. Geng
Expires: 28 March 2027                                            Huawei
                                                                   D. Li
                                                     Tsinghua University
                                                       24 September 2026

          Source Prefix Advertisement for Intra-domain SAVNET
             draft-li-savnet-source-prefix-advertisement-07

Abstract

   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.

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 28 March 2027.

Copyright Notice

   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

Qin, et al.               Expires 28 March 2027                 [Page 1]
Internet-Draft              Intra-domain SPA              September 2026

   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
   2.  SAV Allowlist Generation Procedure  . . . . . . . . . . . . .   3
     2.1.  Routing-Derived Source Prefixes . . . . . . . . . . . . .   3
       2.1.1.  Source Entity Identifier (SEI)  . . . . . . . . . . .   3
     2.2.  Operator-Provisioned Source Prefixes  . . . . . . . . . .   4
     2.3.  SAV Allowlist Generation  . . . . . . . . . . . . . . . .   5
   3.  Operational Considerations  . . . . . . . . . . . . . . . . .   5
     3.1.  Maintaining Entity-Interface Associations . . . . . . . .   5
     3.2.  Handling Operator-Provisioned Source Prefixes . . . . . .   5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.  Informative References  . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  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 [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.

Qin, et al.               Expires 28 March 2027                 [Page 2]
Internet-Draft              Intra-domain SPA              September 2026

   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].

2.  SAV Allowlist Generation Procedure

2.1.  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.

2.1.1.  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.

Qin, et al.               Expires 28 March 2027                 [Page 3]
Internet-Draft              Intra-domain SPA              September 2026

   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.

2.2.  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).

Qin, et al.               Expires 28 March 2027                 [Page 4]
Internet-Draft              Intra-domain SPA              September 2026

   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.

2.3.  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.

3.  Operational Considerations

3.1.  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.

3.2.  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

Qin, et al.               Expires 28 March 2027                 [Page 5]
Internet-Draft              Intra-domain SPA              September 2026

   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.

4.  Security Considerations

   Security considerations described in
   [I-D.ietf-savnet-intra-domain-architecture] also apply.

5.  IANA Considerations

   This document has no IANA actions.

6.  Informative References

   [I-D.ietf-savnet-general-sav-capabilities]
              Huang, M., Cheng, W., Li, D., Geng, N., and L. Chen,
              "General Source Address Validation Capabilities", Work in
              Progress, Internet-Draft, draft-ietf-savnet-general-sav-
              capabilities-03, 21 June 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-savnet-
              general-sav-capabilities-03>.

   [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, <https://datatracker.ietf.org/doc/html/
              draft-ietf-savnet-intra-domain-problem-statement-26>.

   [I-D.ietf-savnet-intra-domain-architecture]
              Li, D., Wu, J., Qin, L., Geng, N., and L. Chen, "Intra-
              domain Source Address Validation Architecture", Work in
              Progress, Internet-Draft, draft-ietf-savnet-intra-domain-
              architecture-04, 29 June 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-savnet-
              intra-domain-architecture-04>.

Authors' Addresses

   Lancheng Qin
   Zhongguancun Laboratory
   Beijing
   China
   Email: qinlc@mail.zgclab.edu.cn

Qin, et al.               Expires 28 March 2027                 [Page 6]
Internet-Draft              Intra-domain SPA              September 2026

   Nan Geng
   Huawei
   Beijing
   China
   Email: gengnan@huawei.com

   Dan Li
   Tsinghua University
   Beijing
   China
   Email: tolidan@tsinghua.edu.cn

Qin, et al.               Expires 28 March 2027                 [Page 7]