



Source Address Validation in Intra-domain and Inter-domain NetworksT. Tong
Internet-Draft                                              China Unicom
Intended status: Informational                                    C. Lin
Expires: 7 March 2026                               New H3C Technologies
                                                                 N. Wang
                                                            China Unicom
                                                        3 September 2025


        Source Address Validation Enhanced by Network Controller
            draft-tong-savnet-sav-enhanced-by-controller-03

Abstract

   Many newly proposed Source Address Validation (SAV) mechanisms such
   as IGP-based and BGP-based SAVNET solutions take a distributed manner
   to generate SAV rules, but they are faced with accuracy and
   managability challenges in incremental/partial deployment scenarios.
   This document proposes a network controller-based solution for
   enhancing SAVNET capability in intra-domain and inter-domain
   networks, which supports accurate verification, automated
   configuration, threat analysis, traceability and visualization.

About This Document

   This note is to be removed before publishing as an RFC.

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-tong-savnet-sav-enhanced-by-
   controller/.

   Discussion of this document takes place on the Source Address
   Validation in Intra-domain and Inter-domain Networks Working Group
   mailing list (mailto:savnet@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/savnet/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/savnet/.

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





Tong, et al.              Expires 7 March 2026                  [Page 1]

Internet-Draft         SAV Enhanced by Controller         September 2025


   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 7 March 2026.

Copyright Notice

   Copyright (c) 2025 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Scenarios and Requirements for Centralized SAVNET . . . . . .   4
     2.1.  Challenges and Limitations of Distributed SAVNET in
           Incremental/partial deployment  . . . . . . . . . . . . .   5
     2.2.  Obtain information from external systems  . . . . . . . .   7
     2.3.  Automated configuration . . . . . . . . . . . . . . . . .   7
     2.4.  Analysis and traceability requirements  . . . . . . . . .   8
   3.  Centralized SAVNET capability enhancement solution  . . . . .   9
     3.1.  Key technologies in Intra-domain SAVNET enhancement . . .  10
     3.2.  Key technologies in Inter-domain SAVNET enhancement . . .  12
   4.  Use Case  . . . . . . . . . . . . . . . . . . . . . . . . . .  14
     4.1.  Case 1: More effective intra-domain edge and boundary
           protection in incremental/partial deployment scenario . .  14
     4.2.  Case 2: More effective inter-domain boundary protection
           with Non-SAVNET Border Devices  . . . . . . . . . . . . .  15
     4.3.  Case 3: More accurate anycast IP protection . . . . . . .  16
     4.4.  Case 4: Enhanced inter-domain SAV via SDN controller  . .  17
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  18
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  18
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19



Tong, et al.              Expires 7 March 2026                  [Page 2]

Internet-Draft         SAV Enhanced by Controller         September 2025


1.  Introduction

   Distributed SAVNET solutions utilize protocol message exchanges among
   SAVNET routers to acquire source prefix information related to other
   subnets within intra-domain networks or inter-domain networks, such
   as Source Prefix Announcement (SPA) technology for intra-domain
   SAVNET, which can be transmitted by a new protocol or an extension to
   an existing protocol [I-D.li-savnet-source-prefix-advertisement].
   Nonetheless, under circumstances characterized by device
   heterogeneity, partial upgrades, asymmetric routing, and peculiar
   address, these solutions face diminished accuracy in Source Address
   Validation (SAV).  Furthermore，there are necessities for enhancement
   in areas such as automated configuration, threat analysis,
   traceability, and visualization.

   In this document, on the basis of distributed intra-domain and inter-
   domain SAVNET architecture, we propose a controller-based and
   centralized SAVNET enhancement solution.  The distributed SAVNET
   solutions rely on local routing information and SAV-specific
   information.  In this solution, the controller can generate and
   deliver SAV rules based on the global information, and can also
   obtain ROA and other external information to generate inter-domain
   SAV rules, so as to achieve accurate source address verification
   (SAV) in both intra-domain and inter-domain in a combination of
   centralized and distributed ways.

   In this solution, SAVNET routers and non-SAVNET routers can cooperate
   via the network controller.  More accurate source address
   verification rules can be generated based on more comprehensive
   information in the scenario of partial/incremental deployment of
   SAVNET.  Concurrently, the SAVNET can support accurate verification,
   automated configuration, threat analysis, traceability and
   visualization.

1.1.  Terminology

   *  SAV: Source Address Validation

   *  AS: Autonomous System

   *  SAV-Specific Information: Information specialized for SAV rule
      generation, exchanged between routers or from the network
      controller.

   *  SAV-related Information: The information used by a router to make
      SAV decisions.  For intra-domain SAV, SAV-related information
      includes both local routing information and SAV-specific
      information.



Tong, et al.              Expires 7 March 2026                  [Page 3]

Internet-Draft         SAV Enhanced by Controller         September 2025


   *  SAV-specific Information Communication Mechanism: The mechanism
      for exchanging SAV-specific information between routers.  It can
      be either a new protocol or an extension to an existing protocol.


   *  SAV Information Base: A table or data structure in a router that
      stores specific SAV information and local routing information.

   *  SAV Rule: The rule in a router that describes the mapping
      relationship between a source address (prefix) and the valid
      incoming interface(s).  It is used by a router to make SAV
      decisions and is inferred from the SAV Information Base or from
      network controller.

   *  SAVNET Router: An intra-domain router which runs intra-domain
      SAVNET.

   *  SAVNET Agent: The agent in a SAVNET router that is responsible for
      communicating SAV-specific information, processing SAV-related
      information, and generating SAV rules.

   *  AS Edge Router: An intra-domain router of an AS which is connected
      to client subnets.

   *  AS Border Router: An intra-domain router of an AS which is
      connected to other ASes.

   *  Improper Block: The validation results that the packets with
      legitimate source addresses are blocked improperly due to
      inaccurate SAV rules.

   *  Improper Permit: The validation results that the packets with
      spoofed source addresses are permitted improperly due to
      inaccurate SAV rules.

   *  ISP: Internet Service Provider.

2.  Scenarios and Requirements for Centralized SAVNET

   This section introduces the scenarios and requirements of centralized
   SAVNET, including incremental/partial deployment scenario, obtain
   information from external systems, automated configuration, analysis
   and traceability requirements,etc.








Tong, et al.              Expires 7 March 2026                  [Page 4]

Internet-Draft         SAV Enhanced by Controller         September 2025


2.1.  Challenges and Limitations of Distributed SAVNET in Incremental/
      partial deployment

   The current distributed solution which exchanges SAV-specific
   information between SAVNET routers depends on devices upgrade.
   Devices utilize the source prefix advertisement (SPA) information to
   notify other routers about their subnet and prefix information.
   Unique subnet ID for each subnet should be planned by network
   manager, and additional identification information such as subnet ID
   and access mode on the corresponding port of the device should be
   configured manually, so as to generate more accurate SAV rules.

   However, devices are upgraded gradually due to various limitations
   such as device performance、version and vendor.  As a result, in an
   AS, there are some routers support SAVNET and others do not.

   Routers with distributed solution could not generate accurate SAV
   rules in incremental/partial deployment scenario.  Refer to
   [I-D.li-savnet-intra-domain-architecture] and
   [I-D.li-savnet-inter-domain-architecture].Though the SAVNET router
   can obtain routing information from the local RIB/FIB and generate
   SAV rules for certain prefixes, in the absence of SAV-specific
   information, the SAV generated based on the local RIB/FIB has the
   risk of the improper block and improper permit in special scenarios
   such as asymmetric routing scenario.

   Figure 1 illustrates the asymmetric routing in a multi-homing subnet
   scenario which has been raised in [I-D.ietf-savnet-intra-domain-
   problem-statement].  Subnet 1 has a prefix of 10.0.0.0/15 and is
   connected to two edge routers, Router 1 and Router 2.  Due to the
   load balancing policy in the inbound direction of subnet 1, R1 can
   only learn subnet prefix 10.1.0.0/16 from subnet 1, while R2 can only
   learn subfix 10.0.0.0/16 from subnet 1.  After that, R1 learns
   another subnet prefix through the intra-domain routing protocol, and
   so does R2.  The FIB of R1 and R2 are shown in Figure 1.  R1 is a
   SAVNET router and R2 is a non-SAVNET router, and R1 and R2
   communicate with each other through R3, regardless of whether R3 is a
   SAVNET router or not, the SPA message cannot be delivered and R2
   cannot generate its own SAV-specific information or recognize the
   SAV-specific information transmitted from R1.  Therefore, R1 can only
   collect part of the prefix information of the subnet to generate SAV
   rules, and R2 uses the FIB for SAV, then improper block will occur in
   both R1 and R2 due to incomplete information.








Tong, et al.              Expires 7 March 2026                  [Page 5]

Internet-Draft         SAV Enhanced by Controller         September 2025


  +--------------------------------------------------------------------+
  |     AS                                                             |
  |                            +----------+                            |
  |                            | Router 3 |                            |
  | FIB on Router 1            +----------+     FIB on Router 2        |
  | Dest         Next_hop       / \     \       Dest         Next_hop  |
  | 10.1.0.0/16  Subnet 1       /        \      10.0.0.0/16  Subnet 1  |
  | 10.0.0.0/16  Router 3      /  SPA     \     10.1.0.0/16  Router 3  |
  |                        +----------+   +----------+                 |
  |                SAVNET  | Router 1 |   | Router 2 | Non-SAVNET      |
  |                        +---+#+----+   +---+#+----+                 |
  |                             \            /                         |
  |                              \          /                          |
  |                             +------------+                         |
  |                             |  Customer  |                         |
  |                             |  Network   |                         |
  |                             +------------+                         |
  |                             (10.0.0.0/15)                          |
  |                                                                    |
  +--------------------------------------------------------------------+

       Figure 1: Asymmetric multi-homing scenario in incremental
                      deployment of intra- domain

   Incremental/partial deployment for inter-domain include: (1) devices
   partially support SAVNET in an AS; (2) some ASs support SAVNET, while
   others do not.  Figure 2 shows that ASBR1/2/3 are SAVNET routers
   while ASBR4 is a non-SAVNET router, ASBR4 cannot generate accurate
   source address verification rules without obtaining SAV-specific
   information from other AS and other routers in its AS.

        +-----------------------+          +------------------------+
        | AS1     +----------+  |          |  +--------- +      AS2 |
        | SAVNET  |  ASBR 1  |  | -------- |  |  ASBR 3  |  SAVNET  |
        |         +----------+  |          |  +----------+          |
        |         +----------+  |          |  +----------+          |
        | SAVNET  |  ASBR 2  |  | -------- |  |  ASBR 4  |  Non-    |
        |         +----------+  |          |  +----------+  SAVNET  |
        +-----------------------+          +------------------------+

          Figure 2: Partial deployment of Savnet for inter-domain

   As a result, there is a problem of low accuracy in partial/
   incremental deployment scenarios.  In addition, how to improve the
   protection effect and enhance the incentive is also one of the
   enhanced capabilities.





Tong, et al.              Expires 7 March 2026                  [Page 6]

Internet-Draft         SAV Enhanced by Controller         September 2025


2.2.  Obtain information from external systems

   ASBR in each AS collects the SAV-specific information in its AS
   domain and synchronizes the SAV-specific information with the ASBR of
   the adjacent AS domain, and also obtains the RPKI ROA and ASPA
   information, as well as general information such as RIB, FIB, IRR,
   etc.Based on the above information sources, each AS generates a
   relatively complete source address verification table.  So each AS
   needs to establish an information exchange channel and mechanism with
   the RPKI ROA to ensure network security, but routers shouldn’t
   directly interact with the RPKI ROA and other external systems, and a
   controller is appropriate to obtain information such as RPKI ROA and
   ASPA.

2.3.  Automated configuration

   Due to the existence of special addresses in the network, such as
   anycast addresses, the existing distributed SAVNET solutions need to
   manually identify special addresses and adopt corresponding policies,
   which brings high management overhead.

   For example, in Figure 3, P1~P4 are common prefixes, P5 is an anycast
   prefix with multiple legitimate origins including customer network 1,
   customer network 3 and external Internet.  SAVNET with whitelist to
   be generated on interfaces a, b, and c, and SAVNET blacklist can be
   generated on interfaces d and e.  If subnet 1 could not recognize P5
   as an anycast prefix, the blacklist of interfaces d and e includes
   prefix P5, causing legitimate packets with P5 as the source to be
   filtered by mistake when they enter from interfaces d and e.
   Therefore, in order not to include an anycast prefix in a blacklist,
   it needs to use a special flag to indicate the anycast prefix when
   subnet 1 advertises the prefix P5 through the SPA.  Prefix type can
   be obtained and configured on the edge router through the controller
   if centralized management is possible,.

















Tong, et al.              Expires 7 March 2026                  [Page 7]

Internet-Draft         SAV Enhanced by Controller         September 2025


    +----------------------------------+     +--------------+
    |  AS  1                           |     |   Other AS   |
    |            +-----------+         |     |              |
    |            |  Router 3 |        e|---- |   Internet   |
    |            +-----------+         |     |              |
    |               /     \            |     |              |
    |              /       \           |     |              |
    |    +----------+   +----------+   |     | +----------+ |
    |    | Router 1 |   | Router 2 |   |     | | Router 4 | |
    |    +---+#+----+   +- -+#+---+    |     | +---+#+----+ |
    |       a |    \b       c|    d\   |     |      |       |
    +---------|-----\--------|------\--+     +------|-------+
              |       \      |        \             |
              |         \    |          \           |
              |           \  |            \         |
         +------------+   +------------+  +------------+
         |  Customer  |   |  Customer  |  |  Customer  |
         |  Network 1 |   |  Network 2 |  |  Network 3 |
         +------------+   +------------+  +------------+
     （prefix-1 and 5）（prefix-2 and 3）（ prefix-4 and 5）

                     Figure 3: Impact of anycast prefix

   In addition, network providers assign access devices, access ports,
   and public IP addresses to users who connect to their networks, so
   that the address allocation system in the carrier's network contains
   information about the customer's network.  Source address
   verification technology can be combined with address allocation
   systems to automate configuration and achieve traceability based on
   source prefix.  Centralized network controller can switch the
   authentication mode of all SAVNET routers flexibly through the
   delivery configuration.

2.4.  Analysis and traceability requirements

   Current scheme provides flexible verification modes such as dropping,
   rate limiting, or allow for the forged packets in the latest draft
   sav_table [I-D.huang-savnet-sav-table].  It will play a great role if
   the controller can collect more source address forgery information
   from the router, analyze and trace the source in a centralized
   manner, visualize the source and target of the attack and threat
   tracing.  Besides, with the continuous expansion of the network scale
   and the increasing allocation of IP addresses, IP address conflicts
   include IP address conflicts and IP prefix conflicts will appear,
   which affects the normal network operation.  The controller can find
   whether the prefixes are reused by checking the prefixes and their
   binding subnet ID.




Tong, et al.              Expires 7 March 2026                  [Page 8]

Internet-Draft         SAV Enhanced by Controller         September 2025


3.  Centralized SAVNET capability enhancement solution

   A high-level view of the Centralized SAVNET framework, without
   expanding the functional entities in network controller and Savnet
   devices, is illustrated in Figure 4.

        +---------------------------------------------------------+
        | Controller                                              |
        |     +----------------------------------------+          |
        |     |      SAVNET Management Plane           |          |
        |     +----------------------------------------+          |
        |     +----------------------------------------+          |
        |     |      SAVNET Control Plane              |          |
        |     +----------------------------------------+          |
        |                                                         |
        +---------------------------------------------------------+
                                   /|\
                                    |
                                    |
                                   \|/
        +---------------------------------------------------------+
        | Savnet Devices                                          |
        |                  SAVNET Device Plane                    |
        +---------------------------------------------------------+

   Figure 4: SAVNET capability enhancement architecture based on network
                                 controller

   The following planes are defined: SAVNET Management Plane：Responsible
   for monitoring, configuring and maintaining SAVNET devices and Non-
   SAVNET devices,including delivering configuration to the devices,
   displaying and managing source address prefixes and SAV rules on
   devices.

   SAVNET Control Plane: Responsible for generating SAV rules.  The
   incoming interfaces of source address prefixes are calculated based
   on topology informations，the source address prefixes，roles of
   devices.  Finally, SAVNET entries/rules are generated and sent to the
   corresponding network devices.

   SAVNET device data plane: Responsible for maintaining and updating
   SAVNET entries from different sources, source address verification on
   the data forwarding plane and forwarding packets.  The SAVNET entries
   can have multiple sources.  SAV rules may be derived from intra-
   domain or inter-domain control plane protocols, see [I-D. draft-ietf-
   savnet-intra-domain-architecture-01] and [I-D.Raft -wu-savnet-inter-
   domain-architecture-11] for detail.  SAV rules may be from the
   controller as well.



Tong, et al.              Expires 7 March 2026                  [Page 9]

Internet-Draft         SAV Enhanced by Controller         September 2025


   The following interfaces are defined: Report the network topology:
   The basic BGP-LS as specified in [RFC9552] applies to this document
   to advertise the network information to the controller.  Report
   source address prefixes and SAVNET capabilities of network devices:
   Extend BGP-LS or YANG model to report source address prefixes and
   SAVNET capabilities of devices.  For BGP-LS extensions, see [I-
   D.draft-cheng-lsr-adv-savnet-capbility].

   Report SAV rules: Monitor and manage SAV rules through a centralized
   controller.  The protocol extensions of BGP Link-State to collect
   source address validation (SAV) rules generated by different
   protocols/mechanisms in [I-D.draft-tong-idr-bgp-ls-sav-rule] can
   facilitate multi-sourced SAV rule monitoring and management.

   Deliver SAV rules: SAV rules can be delivered through YANG [I-
   D.draft-Li-savnet-sav-yang], BGP-LS[I-D.draft-haas-savnet-bgp-sav-
   distribution], and BGP-FS [I-D.draft-geng-idr-flowspec-sav].
   Detailed definition of SAV rules can see [I-D.draft-ietf-savnet-
   general-sav-capabilities].  When some network devices do not support
   SAVNET, the controller can deliver other protection policies, such as
   ACL rules, to the corresponding network devices.

3.1.  Key technologies in Intra-domain SAVNET enhancement

   This section describes the intra-Domain SAV Enhancement based on
   Controller.  Figure 5 illustrates Centralized SAVNET capability
   enhancement architecture in an intra-domain network.  Centralized
   Controller can support accurate verification, automated
   configuration, threat analysis, traceability and visualization.






















Tong, et al.              Expires 7 March 2026                 [Page 10]

Internet-Draft         SAV Enhanced by Controller         September 2025


        +---------------------------------------------------------+
        |                                                         |
        |                    SAVNET Controller                    |
        +---------------------------------------------------------+
                                   /|\
                                    |
                                   \|/
        +---------------------------------------------------------+
        |           +--------+            +--------+              |
        |           | ASBR1  |            | ASBR2  |              |
        |           +--------+            +--------+              |
        |               |                      |                  |
        |           +------------------------------+              |
        |           |         other Routers        |              |
        |           +------------------------------+              |
        |             |             |            |                |
        |        +--------+    +--------+    +--------+           |
        |        |  R1    |    |  R2    |    |  R3    |           |
        |        +--------+    +--------+    +--------+           |
        +---------------------------------------------------------+

     Figure 5: intra-domain SAVNET capability enhancement architecture
                        based on network controller

   As shown in the figure above, when SAVNET is deployed in the intra-
   domain, controller can implement different control policies based on
   roles of devices.  For the boundary devices in the domain, the
   blacklist policy is adopted.  For the multi-homing access devices in
   the domain, the controller delivers multi-homing SAV rules in a
   centralized manner.

   Deliver SAV rules in intra-domain: (1) AS Boundary Router (ASBR): The
   controller collects source address prefixes of all subnets in the AS
   domain, first removes special IP addresses or prefixes, such as
   anycast IP addresses, then generates the SAV rules/policies（in
   blacklist mode） containing all source address prefixes of the AS, and
   sends the SAV rules/policies to the ASBR.  The SAV rules are
   generated and delivered to the routers that support SAVNET, and other
   defense policies, such as ACL (filtering specific source addresses on
   specific incoming interfaces), are generated and delivered to the
   routers that do not support SAVNET.










Tong, et al.              Expires 7 March 2026                 [Page 11]

Internet-Draft         SAV Enhanced by Controller         September 2025


        +-------------------------------------------------+
        |                                                 |
        |                SAVNET Controller                |
        +-------------------------------------------------+
                    /|\                   /|\
                     |                     |
                    \|/                   \|/
                 +--------+            +--------+
                 | ASBR1  |            | ASBR2  |
                 +--------+            +--------+
               SAVNET Router         Non-SAVNET Router

              Figure 6: Deliver SAV rules to AS Border Routers

   (2) Access Router: If a subnet is connected to two access routers and
   only one router supports SAVNET and the other does not, the
   controller can generate the SAV entry of P2 and send it to access
   router R1.  The prefix-interface whitelist of access router R1
   includes P1 and P2 to avoid false blocking.  The controller can also
   generate ACL entries with prefixes P1 and P2 and send them to the
   access interface of access router R2 which does not support SAVNET.

        +-------------------------------------------------+
        |                                                 |
        |                SAVNET Controller                |
        +-------------------------------------------------+
                    /|\                   /|\
                     |                     |
                    \|/                   \|/
            +---------------+      +---------------+
            | Access Router |      | Access Router |
            +---------------+      +---------------+
     SAVNET Router      \             /       Non-SAVNET Router
                     P1  \           / P2
                       +---------------+
                       |   Customer    |
                       |   Network     |
                       +---------------+

               Figure 7: Deliver SAV rules to access routers

3.2.  Key technologies in Inter-domain SAVNET enhancement

   In inter-domain source address verification, the controller can also
   play an important role.

   *  Generation and Receipt of Inter-domain SAV-specific Messages：




Tong, et al.              Expires 7 March 2026                 [Page 12]

Internet-Draft         SAV Enhanced by Controller         September 2025


   Inter-domain Source Address Validation (SAV) consists of a Source
   Autonomous System (AS) and a Validation Autonomous System (AS).  And
   the controller of the Source AS can assist in generating and sending
   inter-domain SAV-specific messages, while the controller of the
   Validation AS can assist in receiving and propagating such inter-
   domain SAV-specific messages.  The following takes inter-domain
   Source Prefix Assertion (SPA) messages as an example for
   illustration.

   A SPA message contains the AS number of the Source AS and the source
   prefixes included in this AS.  Since the controller of the Source AS
   can centrally generate intra-domain SAV rules, it can conveniently
   obtain the source prefixes of the Source AS and further generate
   inter-domain SPA messages.

   Inter-domain SPA messages are sent from the Source AS to the
   Validation AS.  If the designated ASBR in the Source AS or the
   Validation AS does not support SAVNET , the SPA messages can be sent
   from the controller of the Source AS to the controller of the
   Validation AS.

   *  Centralized Generation of Inter-domain SAV Rules

   Inter-domain SAV rules are generated by the Validation AS.  The
   controller of the Validation AS can integrate information such as
   RIB, FIB, ROA and ASPA objects of the RPKI, IRR data, and SAV-
   specific information.  Then it generates inter-domain SAV rules based
   on a priority policy, where SAV-specific information has the highest
   priority.

       +-------------------------------+  +--------------+
       |  RPKI ROA Obj. and ASPA Obj.  |  | IRR Database |
       +-------------------------------+  +--------------+
                  /|\                       /|\
    +--------------|-------------------------|------+
    |             \|/                       \|/     |
    |  +----------------------------------------+   |   +-------------------+
    |  |         AS2 network controller         |<----->|  AS1 controller   |
    |  +----------------------------------------+   |   +-------------------+
    |          /|\                /|\        SAV-Specific information
    |           |                  |                |
    |           |  SAV rules       |  ACL           |
    |          \|/                \|/               |
    |  +-------------------+   +-----------------+  |
    |  |     AS2 ASBR      |   |     AS2 ASBR    |  |
    |  +-------------------+   +-----------------+  |
    |     SAVNET Router         Non-SAVNET Router   |
    +-----------------------------------------------+



Tong, et al.              Expires 7 March 2026                 [Page 13]

Internet-Draft         SAV Enhanced by Controller         September 2025


   Figure 8: Inter-domain SAV rules generation based on Centralized
                              controller

   The controller of the Validation AS can distribute the centrally
   generated inter-domain SAV rules to ASBRs, in order to perform inter-
   domain source address validation.  Specifically, it generates and
   distributes SAV rules to ASBRs that support SAVNET, and generates and
   distributes ACL rules to ASBRs that do not support SAVNET, which
   enhances the incentives in partial deployment scenarios.

4.  Use Case

   Several use cases will illustrate that centralized SAVNET can achieve
   more accurate and comprehensive SAV when SAVNET is partially deployed
   in network.

4.1.  Case 1: More effective intra-domain edge and boundary protection
      in incremental/partial deployment scenario

   Figure 11 illustrates the asymmetric routing in a multi-homing subnet
   scenario.  R1 and R2 serves as the edge router.  R3 serves as the
   border egress.  Partial SAVNET deployment: R1 lacks SAVNET support,
   while R2 and R3 are SAVNET-enabled.

        +-------------------------------------------------+
        |                   Controller                    |
        +-------------------------------------------------+
               /|\          /|\            /|\
                |            |              |
                |           \|/ IF3         |
                |         +-----+           |
                |         | R3  |           |
                |         +-----+           |
               \|/       SAVNET Router     \|/
             +-----+                     +-----+
             | R1  | Non-SAVNET Router   | R2  | SAVNET Router
             +-----+                     +-----+
               IF1 \    Edge router      / IF2
                    \                   /
       Prefix 1 (P1) \                 /  Prefix 2 (P2)
       AS             \               /
                       +-------------+
                       |   subnet    |
                       +-------------+

       Figure 9: asymmetric routing in a multi-homing subnet scenario

   (1)Distributed SAVNET limitations:



Tong, et al.              Expires 7 March 2026                 [Page 14]

Internet-Draft         SAV Enhanced by Controller         September 2025


   R1 (SAVNET-disabled): Fails to advertise P1 via SAVNET protocol.
   Thus:R2's interface IF2 cannot generate a whitelist covering both P1
   and P2.R3's interface IF3 cannot create a blacklist for P1, leaving
   it unprotected.  R2 (SAVNET-enabled): Advertises P2 via SAVNET
   protocol successfully.  R3 (SAVNET-enabled): blocks P2 traffic on IF3
   but allows P1 spoofing.

   Test Results: Tester A sending P1/P2/P3 traffic to R1 and R2: --R1
   (IF1): No blocking (No protection). --R2 (IF2): P1 blocked (improper
   block).

   Tester B spoofing P1/P2/P3 to R3: --R3 (IF3): P2 blocked, P1/P3
   allowed (insufficient protection).

   (2)SAVNET enhancement with centralized controller:

   Controller Actions: --Collects subnet prefix P1 from R1 and P2 from
   R2. --Delivers ACL whitelist (P1+P2) to R1's IF1 and SAV rules to
   R2's IF2. --Delivers blacklist (P1+P2) to R3's IF3.

   Test Results: Tester A: P1/P2 allowed on R1's IF1 and R2's IF2.  P3
   blocked.  No improper blocking (full protection).  Tester B: P1/P2
   blocked on IF3, P3 allowed (precise control).

4.2.  Case 2: More effective inter-domain boundary protection with Non-
      SAVNET Border Devices

   Edge routers R1/R2 support SAVNET, but border router R3 does not
   (Figure 12).






















Tong, et al.              Expires 7 March 2026                 [Page 15]

Internet-Draft         SAV Enhanced by Controller         September 2025


        +-------------------------------------------------+
        |                   Controller                    |
        +-------------------------------------------------+
               /|\          /|\            /|\
                |            |              |
                |           \|/ IF3         |
                |         +-----+           |
                |         | R3  |           |
                |         +-----+           |
               \|/   Non-SAVNET Router     \|/
             +-----+                     +-----+
             | R1  | SAVNET Router       | R2  | SAVNET Router
             +-----+                     +-----+
               IF1 \   Edge router       / IF2
                    \                   /
       Prefix 1 (P1) \                 /  Prefix 2 (P2)
       AS             \               /
                       +-------------+
                       |   subnet    |
                       +-------------+

         Figure 10: More effective intra-domain boundary protection

   (1)Distributed SAVNET limitations: R3 cannot process SAVNET messages
   from R1/R2, leaving P1/P2 unprotected.

   Test Results: Tester B(spoofing P1/P2/P3 to R3): All traffic
   permitted (zero protection).

   (2)SAVNET enhancement with centralized controller:

   Controller Actions: - Aggregates P1 (from R1) and P2 (from R2). -
   Delivers unified blacklist (P1+P2) to R3's IF3.

   Test Results: Tester B: P1/P2 blocked; P3 allowed (boundary secured).

4.3.  Case 3: More accurate anycast IP protection

   Edge routers R1/R2 and border router R3 all support SAVNET.  Subnet
   advertises sub prefixe P1 (anycast IP) via R1 and P2 via R2.











Tong, et al.              Expires 7 March 2026                 [Page 16]

Internet-Draft         SAV Enhanced by Controller         September 2025


        +-------------------------------------------------+
        |                   Controller                    |
        +-------------------------------------------------+
               /|\          /|\            /|\
                |            |              |
                |           \|/ IF3         |
                |         +-----+           |
                |         | R3  |           |
                |         +-----+           |
               \|/   Non-SAVNET Router     \|/
             +-----+                     +-----+
             | R1  | SAVNET Router       | R2  | SAVNET Router
             +-----+                     +-----+
               IF1 \   Edge router       / IF2
      (anycast IP)  \                   /
       Prefix 1 (P1) \                 /  Prefix 2 (P2)
       AS             \               /
                       +-------------+
                       |   subnet    |
                       +-------------+

               Figure 11: More accurate anycast IP protection

   (1)Distributed SAVNET Challenge: Anycast conflict: P1 is also
   advertised by other AS, leading to ambiguous SAV rules.  Risk:
   Legitimate P1 traffic may be incorrectly blocked by boundary router.

   Test Results: Tester B sending P1/P2 traffic to R3: P2 blocked;
   anycast P1 blocked (improper block).

   (2)SAVNET enhancement with centralized controller: Controller
   Actions: Correlates P1 with AS-specific topology data.  Generates
   context-aware SAV rules to distinguish legitimate anycast traffic.

   Test Results: Tester B: P2 blocked; P1 permitted (Prevent improper
   block).

4.4.  Case 4: Enhanced inter-domain SAV via SDN controller

   Operators obtain IP blocks and AS numbers from registries, assigning
   them to network segments or business units.  Controller-Driven
   Optimization: SDN controller aggregates AS-number-to-IP mappings from
   carrier registries.Delivers complete SAV tables to ASBRs.  Impact:
   Eliminates spoofed inter-domain traffic (e.g., forged source IPs
   outside assigned ranges).Achieves more accuracy in inter-domain
   SAVNET.





Tong, et al.              Expires 7 March 2026                 [Page 17]

Internet-Draft         SAV Enhanced by Controller         September 2025


5.  Security Considerations

   TBD.

6.  IANA Considerations

   TBD.

7.  Acknowledgments

   TBD.

8.  References

8.1.  Normative References

   [RFC9552]  Talaulikar, K., Ed., "Distribution of Link-State and
              Traffic Engineering Information Using BGP", RFC 9552,
              DOI 10.17487/RFC9552, December 2023,
              <https://www.rfc-editor.org/rfc/rfc9552>.

8.2.  Informative References

   [I-D.huang-savnet-sav-table]
              Huang, M., Cheng, W., Li, D., Geng, N., Liu, Chen, L., and
              C. Lin, "General Source Address Validation Capabilities",
              Work in Progress, Internet-Draft, draft-huang-savnet-sav-
              table-08, 10 December 2024,
              <https://datatracker.ietf.org/doc/html/draft-huang-savnet-
              sav-table-08>.

   [I-D.li-savnet-inter-domain-architecture]
              "*** BROKEN REFERENCE ***".

   [I-D.li-savnet-intra-domain-architecture]
              Li, D., Wu, J., Qin, L., Geng, N., Chen, L., Huang, M.,
              and F. Gao, "Intra-domain Source Address Validation
              (SAVNET) Architecture", Work in Progress, Internet-Draft,
              draft-li-savnet-intra-domain-architecture-07, 16 March
              2024, <https://datatracker.ietf.org/doc/html/draft-li-
              savnet-intra-domain-architecture-07>.










Tong, et al.              Expires 7 March 2026                 [Page 18]

Internet-Draft         SAV Enhanced by Controller         September 2025


   [I-D.li-savnet-intra-domain-problem-statement]
              Li, D., Wu, J., Qin, L., Huang, M., and N. Geng, "Source
              Address Validation in Intra-domain Networks Gap Analysis,
              Problem Statement, and Requirements", Work in Progress,
              Internet-Draft, draft-li-savnet-intra-domain-problem-
              statement-07, 11 March 2023,
              <https://datatracker.ietf.org/doc/html/draft-li-savnet-
              intra-domain-problem-statement-07>.

   [I-D.li-savnet-source-prefix-advertisement]
              Li, D., Geng, N., and L. Qin, "Source Prefix Advertisement
              for Intra-domain SAVNET", Work in Progress, Internet-
              Draft, draft-li-savnet-source-prefix-advertisement-04, 8
              April 2025, <https://datatracker.ietf.org/doc/html/draft-
              li-savnet-source-prefix-advertisement-04>.

Authors' Addresses

   Tian Tong
   China Unicom
   Email: tongt5@chinaunicom.cn


   Changwang Lin
   New H3C Technologies
   Email: linchangwang.04414@h3c.com


   Nan Wang
   China Unicom
   Email: wangn161@chinaunicom.cn




















Tong, et al.              Expires 7 March 2026                 [Page 19]
