Source Address Validation in Intra-domain Networks Gap Analysis, Problem Statement, and Requirements
draft-ietf-savnet-intra-domain-problem-statement-10

SAVNET                                                             D. Li
Internet-Draft                                                     J. Wu
Intended status: Informational                       Tsinghua University
Expires: 25 July 2025                                             L. Qin
                                                                M. Huang
                                                 Zhongguancun Laboratory
                                                                 N. Geng
                                                                  Huawei
                                                         21 January 2025

Source Address Validation in Intra-domain Networks Gap Analysis, Problem
                      Statement, and Requirements
          draft-ietf-savnet-intra-domain-problem-statement-10

Abstract

   This document provides the gap analysis of existing intra-domain
   source address validation mechanisms, describes the fundamental
   problems, and defines the requirements for technical improvements.

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 25 July 2025.

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

Li, et al.                Expires 25 July 2025                  [Page 1]
Internet-Draft    Intra-domain SAVNET Problem Statement     January 2025

   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 . . . . . . . . . . . . . . . . . . . . . . .   4
     1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   5
   2.  Existing Intra-domain SAV Mechanisms  . . . . . . . . . . . .   5
   3.  Gap Analysis  . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  SAV on Host-facing or Customer-facing Routers . . . . . .   6
       3.1.1.  Asymmetric Routing  . . . . . . . . . . . . . . . . .   6
       3.1.2.  Hidden Prefix . . . . . . . . . . . . . . . . . . . .   8
     3.2.  SAV on AS Border Routers  . . . . . . . . . . . . . . . .  10
   4.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .  11
   5.  Requirements for New SAV Mechanisms . . . . . . . . . . . . .  12
     5.1.  Automatic Update  . . . . . . . . . . . . . . . . . . . .  12
     5.2.  Accurate Validation . . . . . . . . . . . . . . . . . . .  12
     5.3.  Working in Incremental/Partial Deployment . . . . . . . .  12
     5.4.  Fast Convergence  . . . . . . . . . . . . . . . . . . . .  13
     5.5.  Necessary Security Guarantee  . . . . . . . . . . . . . .  13
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   Source Address Validation (SAV) is important for defending against
   source address spoofing attacks.  A multi-fence architecture called
   Source Address Validation Architecture (SAVA) [RFC5210] was proposed
   to implement SAV at three levels: access-network SAV, intra-domain
   SAV, and inter-domain SAV.  The multi-fence architecture helps
   enhance the effectiveness of SAV across the whole Internet by
   preventing or mitigating source address spoofing at multiple levels.

   Access-network SAV mechanisms (such as SAVI [RFC7039], IP Source
   Guard (IPSG) [IPSG], and Cable Source-Verify [cable-verify]) can
   ensure that a host must use the source IP address assigned to the
   host.  Given numerous access networks managed by different operators
   throughout the world, it is difficult to require all access networks
   to deploy SAV simultaneously.  Therefore, intra-domain SAV and inter-
   domain SAV are needed to block source-spoofed data packets from
   access networks as close to the source as possible.  Intra-domain SAV

Li, et al.                Expires 25 July 2025                  [Page 2]
Internet-Draft    Intra-domain SAVNET Problem Statement     January 2025

   and inter-domain SAV perform SAV at the granularity of IP prefixes,
   which is coarser than the granularity of access network SAV (i.e., IP
   address), as an IP prefix covers a range of IP addresses.

   This document focuses on the analysis of intra-domain SAV.  In
   contrast to inter-domain SAV, intra-domain SAV does not require
   collaboration between different Autonomous Systems (ASes).  Intra-
   domain SAV rules can be generated by the AS itself.  Consider an AS X
   which provides its host networks or customer networks with the
   connectivity to the rest of the Internet.  Intra-domain SAV for AS X
   aims at achieving two goals: i) blocking source-spoofed packets
   originated from its host networks or customer networks using a source
   address of other networks; and ii) blocking source-spoofed packets
   coming from other ASes using a source address of AS X.

   Figure 1 illustrates the goals and function of intra-domain SAV with
   two cases.  Case i shows that the host network or customer network of
   AS X originates source-spoofed packets using a source address of
   other networks.  If AS X deploys intra-domain SAV, the spoofed
   packets can be blocked by host-facing routers or customer-facing
   routers of AS X (i.e., Goal i).  Case ii shows that AS X receives
   source-spoofed packets using a source address of AS X from other ASes
   (e.g., AS Y).  If AS X deploys intra-domain SAV, the spoofed packets
   from AS Y can be blocked by AS border routers of AS X (i.e., Goal
   ii).

   Case i: The host network or customer network of AS X originates
           packets spoofing source addresses of other networks
   Goal i: If AS X deploys intra-domain SAV,
           the spoofed packets can be blocked by AS X

                                       Spoofed packets
                                       using source addresses
     +-------------------------------+ of other networks     +------+
     | Host/Customer Network of AS X |---------------------->| AS X |
     +-------------------------------+                       +------+

   Case ii: AS X receives packets spoofing source addresses of AS X
            from other ASes (e.g., AS Y)
   Goal ii: If AS X deploys intra-domain SAV,
            the spoofed packets can be blocked by AS X

              Spoofed packets
              using source addresses
     +------+ of AS X               +------+
     | AS X |<----------------------| AS Y |
     +------+                       +------+

Li, et al.                Expires 25 July 2025                  [Page 3]
Internet-Draft    Intra-domain SAVNET Problem Statement     January 2025

           Figure 1: An example for illustrating intra-domain SAV

   The scope of intra-domain SAV includes all IP-encapsulated scenarios:

   *  Native IP forwarding: including both forwarding based on global
      routing table and VPN forwarding.

   *  IP-encapsulated Tunnel (IPsec [RFC4301], GRE [RFC2784], SRv6
      [RFC9256], etc.): focusing on the validation of the outer layer IP
      address.

   *  Validating both IPv4 and IPv6 addresses.

   Scope does not include:

   *  Non-IP packets: including MPLS label-based forwarding and other
      non-IP-based forwarding.

   In the following, this document provides gap analysis of existing
   intra-domain SAV mechanisms, concludes main problems of existing
   intra-domain SAV mechanisms, and proposes requirements for future
   ones.

1.1.  Terminology

   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.

   Host-facing Router: An intra-domain router facing an intra-domain
   host network.

   Customer-facing Router: An intra-domain router facing an intra-domain
   customer network.

   AS Border Router: An intra-domain router facing an external AS.

   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.

   SAV-specific Information: The information specialized for SAV rule
   generation, which is exchanged among routers.

Li, et al.                Expires 25 July 2025                  [Page 4]
Internet-Draft    Intra-domain SAVNET Problem Statement     January 2025

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.  Existing Intra-domain SAV Mechanisms

   This section introduces existing intra-domain SAV mechanisms,
   including BCP38 [RFC2827] and BCP84 [RFC3704].

   *  ACL-based ingress filtering or BCP38 [RFC2827] requires that
      network operators manually configure ACL rules on intra-domain
      routers to block or permit data packets using specific source
      addresses.  This mechanism can be used on interfaces of host-
      facing or customer-facing routers facing an intra-domain host/
      customer network to prevent the corresponding host/customer
      network from spoofing source prefixes of other networks
      [manrs-antispoofing].  In addition, it is also usually used on
      interfaces of AS border routers facing an external AS to block
      data packets using disallowed source addresses, such as internal
      source addresses owned by the local AS [nist-rec].  In any
      application scenario, ACL rules must be updated in time to be
      consistent with the latest filtering criteria when the network
      changes.

   *  Strict uRPF [RFC3704] is also typically used on interfaces of
      host-facing or customer-facing routers facing an intra-domain
      host/customer network.  Routers deploying strict uRPF accept a
      data packet only when i) the local FIB contains a prefix covering
      the packet's source address and ii) the corresponding outgoing
      interface for the prefix in the FIB matches the packet's incoming
      interface.  Otherwise, the packet will be blocked.

   *  Loose uRPF [RFC3704] uses a looser validation method.  A packet
      will be accepted if the router's local FIB contains a prefix
      covering the packet's source address regardless of the interface
      from which the packet is received.  In fact, interfaces of AS
      border routers facing an external AS may use loose uRPF to block
      incoming data packets using non-global addresses [nist-rec].

   *  Carrier Grade NAT has some operations on the source addresses of
      packets, but it is not an anti-spoofing tool, as described in
      [manrs-antispoofing].  If the source address of a packet is in the
      INSIDE access list, the NAT rule can translate the source address
      to an address in the pool OUTSIDE.  The NAT rule cannot determine

Li, et al.                Expires 25 July 2025                  [Page 5]
Internet-Draft    Intra-domain SAVNET Problem Statement     January 2025

      whether the source address is spoofed or not.  In addition, the
      packet using a spoofed source address will still be forwarded if
      the spoofed source address is not included in the INSIDE access
      list.  Therefore, Carrier Grade NAT cannot help identify and block
      source-spoofed data packets.

3.  Gap Analysis

   This section elaborates the key problems of current intra-domain SAV
   on host-facing or customer-facing routers and SAV on AS border
   routers, respectively.

3.1.  SAV on Host-facing or Customer-facing Routers

   Towards Goal i in Figure 1, intra-domain SAV is typically deployed on
   interfaces of host-facing or customer-facing routers facing an intra-
   domain host/customer network to validate data packets originated from
   that network, since SAV is more effective when deployed closer to the
   source.  ACL-based ingress filtering and strict uRPF are commonly
   used for this purpose.

   ACL rules must be manually updated according to prefix changes or
   topology changes in a timely manner.  Otherwise, if ACL rules are not
   updated in time, improper block or improper permit problems may
   occur.  To ensure the accuracy of ACL rules in dynamic networks, high
   operational overhead will be induced to achieve timely updates for
   ACL configurations.

   Strict uRPF can generate and update SAV rules in an automatic way but
   it will cause improper blocks in the scenario of asymmetric routing
   or hidden prefix.

3.1.1.  Asymmetric Routing

   Figure 2 shows asymmetric routing in a multi-homing scenario.  In the
   figure, Network 1 is a host/customer network of the AS.  It owns
   prefix 2001:db8::/32 [RFC6890] and is attached to two intra-domain
   routers, i.e., Router 1 and Router 2.  For the load balance purpose
   of traffic flowing to Network 1, Network 1 expects the incoming
   traffic destined for the sub-prefix 2001:db8:8000::/33 to come only
   from Router 1 and the incoming traffic destined for the other sub-
   prefix 2001:db8::/33 to come only from Router 2.  To this end, Router
   1 only learns the route to sub-prefix 2001:db8:8000::/33 from Network
   1, while Router 2 only learns the route to the other sub-prefix
   2001:db8::/33 from Network 1.  Then, Router 1 and Router 2 distribute
   the sub-prefix information to routers in the AS through intra-domain
   routing protocols such as OSPF or IS-IS.  The FIBs of Router 1 and
   Router 2 are shown in the figure.

Li, et al.                Expires 25 July 2025                  [Page 6]
Internet-Draft    Intra-domain SAVNET Problem Statement     January 2025

   Although Network 1 does not expect traffic destined for 2001:db8::/33
   to come from Router 1, it may send traffic with source addresses of
   prefix 2001:db8::/33 to Router 1 for load balance of traffic
   originated from Network 1.  As a result, there is asymmetric routing
   of data packets between Network 1 and Router 1.  Arrows in the figure
   indicate the flowing direction of traffic.  In addition to the
   traffic engineering mentioned above, other factors may also cause the
   similar asymmetric routing between host-facing/customer-facing
   routers and host/customer networks.

    +---------------------------------------------------------+
    |                                                      AS |
    |                     +----------+                        |
    |                     | Router 3 |                        |
    |                     +----------+                        |
    |                       /      \                          |
    |                      /        \                         |
    |                     /          \                        |
    |             +----------+     +----------+               |
    |             | Router 1 |     | Router 2 |               |
    |             +-----+#+--+     +-+#+------+               |
    |                   /\           /                        |
    |Traffic with        \          / Traffic with            |
    |source IP addresses  \        /  destination IP addresses|
    |of 2001:db8::/33      \      \/  of 2001:db8::/33        |
    |                  +----------------+                     |
    |                  |  Host/Customer |                     |
    |                  |    Network 1   |                     |
    |                  |(2001:db8::/32) |                     |
    |                  +----------------+                     |
    |                                                         |
    +---------------------------------------------------------+

    FIB of Router 1                 FIB of Router 2
    Dest               Next_hop     Dest               Next_hop
    2001:db8:8000::/33 Network 1    2001:db8:8000::/33 Router 3
    2001:db8::/33      Router 3     2001:db8::/33      Network 1

    The legitimate traffic originated from Network 1 with source IP
    addresses of 2001:db8::/33 will be improperly blocked by Router 1
    if Router 1 uses strict uRPF.

           Figure 2: Asymmetric routing in multi-homing scenario

   If Router 1 uses strict uRPF on interface '#', the SAV rule is that
   Router 1 only accepts packets with source addresses of
   2001:db8:8000::/33 from Network 1.  Therefore, when Network 1 sends
   packets with source addresses of 2001:db8::/33 to Router 1, strict

Li, et al.                Expires 25 July 2025                  [Page 7]
Internet-Draft    Intra-domain SAVNET Problem Statement     January 2025

   uRPF at Router 1 will improperly block these legitimate packets.
   Similarly, when Router 2 uses strict uRPF on its interface '#' and
   receives packets with source addresses of prefix 2001:db8:8000::/33
   from Network 1, it will also improperly block these legitimate
   packets because strict uRPF at Router 2 will only accept packets from
   Network 1 using source addresses of prefix 2001:db8::/33.

3.1.2.  Hidden Prefix

   For special business purposes, a host/customer network will originate
   data packets using a source address that is not distributed through
   intra-domain routing protocol.  In other words, the IP address/prefix
   is hidden from intra-domain routing protocol and intra-domain
   routers.  In this scenario, strict uRPF on host-facing or customer-
   facing routers will improperly block data packets from the host/
   customer network using source addresses in a hidden prefix.

Li, et al.                Expires 25 July 2025                  [Page 8]
Internet-Draft    Intra-domain SAVNET Problem Statement     January 2025

             +-------------------------+
             |          AS Y           | AS Y announces the route
             |   (where the anycast    | for anycast prefix P3
             |    server is located)   | in BGP
             +-----------+-------------+
                         |
                         |
             +-----------+-------------+
             |       Other ASes        |
             +-------------------------+
                /                    \
               /                      \
              /                        \
   +------------------+   +---------------------------------------+
   |      AS Z        |   |         +----------+             AS X |
   | (where the user  |   |         | Router 4 |                  |
   |    is located)   |   |         +----------+                  |
   +------------------+   |              |                        |
                          |              |                        |
                          |         +----+-----+                  |
                          |         | Router 5 |                  |
                          |         +----#-----+                  |
                          |              /\    DSR responses with |
                          |              |     source IP addresses|
                          |              |     of P3              |
                          |       +---------------+               |
                          |       | Host/Customer |               |
                          |       |   Network 2   |               |
                          |       |     (P2)      |               |
                          |       +---------------+               |
                          | (where the edge server is located)    |
                          +---------------------------------------+
   DSR response packets from edge server in Network 2 with
   source IP addresses of P3 (i.e., the anycast prefix) will
   be improperly blocked by Router 5 if Router 5 uses strict uRPF.

              Figure 3: Hidden prefix in CDN and DSR scenario

   The Content Delivery Networks (CDN) and Direct Server Return (DSR)
   scenario is a representative example of hidden prefix.  In this
   scenario, the edge server in an AS will send DSR response packets
   using a source address of the anycast server which is located in
   another remote AS.  However, the source address of anycast server is
   hidden from intra-domain routing protocol and intra-domain routers in
   the local AS.

Li, et al.                Expires 25 July 2025                  [Page 9]
Internet-Draft    Intra-domain SAVNET Problem Statement     January 2025

   While this is an inter-domain scenario, we note that DSR response
   packets may also be improperly blocked by strict uRPF when edge
   server is located in the host/customer network.  For example, in
   Figure 3, assume edge server is located in Host/Customer Network 2
   and Router 5 only learns the route to P2 from Network 2.  When edge
   server receives the request from the remote anycast server, it will
   directly return DSR response packets using the source address of
   anycast server (i.e., P3).  If Router 5 uses strict uRPF on interface
   '#', the SAV rule is that Router 5 only accepts packets with source
   addresses of P2 from Network 2.  As a result, DSR response packets
   will be blocked by strict uRPF on interface '#'.  In addition, loose
   uRPF on this interface will also improperly block DSR response
   packets if prefix P3 is not in the FIB of Router 5.

3.2.  SAV on AS Border Routers

   Towards Goal ii in Figure 1, intra-domain SAV is typically deployed
   on interfaces of AS border routers facing an external AS to validate
   packets arriving from other ASes.  Figure 4 shows an example of SAV
   on AS border routers.  In the figure, Router 3 and Router 4 deploy
   intra-domain SAV on interface '#' for validating data packets coming
   from external ASes.  ACL-based ingress filtering and loose uRPF are
   commonly used for this purpose.

    Packets with +              Packets with +
    spoofed P1/P2|              spoofed P1/P2|
   +-------------|---------------------------|---------+
   |   AS        \/                          \/        |
   |         +--+#+-----+               +---+#+----+   |
   |         | Router 3 +---------------+ Router 4 |   |
   |         +----------+               +----+-----+   |
   |          /        \                     |         |
   |         /          \                    |         |
   |        /            \                   |         |
   | +----------+     +----------+      +----+-----+   |
   | | Router 1 |     | Router 2 |      | Router 5 |   |
   | +----------+     +----------+      +----+-----+   |
   |        \             /                  |         |
   |         \           /                   |         |
   |          \         /                    |         |
   |       +---------------+         +-------+-------+ |
   |       |   Customer    |         |     Host      | |
   |       |   Network     |         |   Network     | |
   |       |     (P1)      |         |     (P2)      | |
   |       +---------------+         +---------------+ |
   |                                                   |
   +---------------------------------------------------+

Li, et al.                Expires 25 July 2025                 [Page 10]
Internet-Draft    Intra-domain SAVNET Problem Statement     January 2025

              Figure 4: An example of SAV on AS border routers

   By configuring ACL rules, data packets that use disallowed source
   addresses (e.g., non-global addresses or internal source addresses)
   can be blocked at AS border routers.  However, the operational
   overhead of maintaining updated ACL rules will be extremely high when
   there are multiple AS border routers adopting SAV as shown in
   Figure 4.

   As for loose uRPF, it sacrifices the directionality of SAV and has
   limited blocking capability, because it allows packets with source
   addresses that exist in the FIB table on all router interfaces.

4.  Problem Statement

   As analyzed above, existing intra-domain SAV mechanisms have
   significant limitations on automatic update or accurate validation.

   ACL-based ingress filtering relies on manual configurations and thus
   requires high operational overhead in dynamic networks.  To guarantee
   accuracy of ACL-based SAV, network operators have to manually update
   the ACL-based filtering rules in time when the prefix or topology
   changes.  Otherwise, improper block or improper permit problems may
   appear.

   Strict uRPF can automatically update SAV rules, but may improperly
   block legitimate traffic under asymmetric routing scenario or hidden
   prefix scenario.  It may mistakenly consider a valid incoming
   interface as invalid, resulting in improper block problems; or it may
   mistakenly consider an invalid incoming interface as valid, resulting
   in improper permit problems.

   Loose uRPF is also an automated SAV mechanism but its SAV rules are
   overly loose.  Most spoofed packets will be improperly permitted by
   loose uRPF.

   In summary, uRPF cannot guarantee the accuracy of SAV because it
   solely uses the router’s local FIB or RIB information to determine
   SAV rules.  A router cannot see the asymmetric route between itself
   and another router/network from its own perspective.  As a result,
   strict uRPF has improper block problems in the scenario of asymmetric
   route.  The network operator has a comprehensive perspective so he/
   she can configure the correct SAV rules.  However, manual
   configuration has limitations on automatic update.

Li, et al.                Expires 25 July 2025                 [Page 11]
Internet-Draft    Intra-domain SAVNET Problem Statement     January 2025

5.  Requirements for New SAV Mechanisms

   The key to overcoming the problems is to automatically combine
   perspectives of multiple routers, allowing each router to form a more
   comprehensive perspective.  To this end, new SAV solutions can allow
   routers to exchange and update the asymmetric information that
   affects the accuracy of SAV (i.e., SAV-specific information) in an
   automatic way.  Then, routers can use SAV-specific information and
   local routing information to determine accurate SAV rules.

   It is also important to reduce the complexity and overhead of SAV
   implementation.  To this end, routers MUST NOT signal too much
   information.  Only information that cannot be learned from local
   routing information and is necessary for SAV should be signaled.  In
   addition, in order to better compatibility with the current intra-
   domain network, it is recommended that existing routing protocols can
   be used to implement the SAV function.

   Specifically, this section lists the following five requirements that
   should be considered when designing new intra-domain SAV mechanisms.

5.1.  Automatic Update

   The new intra-domain SAV mechanism MUST be able to automatically
   adapt to network dynamics such as routing changes or prefix changes,
   instead of purely relying on manual update.

5.2.  Accurate Validation

   The new intra-domain SAV mechanism need to improve the validation
   accuracy upon existing intra-domain SAV mechanisms.  In a static
   network, improper block MUST be avoided to guarantee that legitimate
   traffic will not be blocked.  Improper permit SHOULD be reduced as
   much as possible so that data packets with spoofed source addresses
   can be effectively blocked.  When the network changes, the new
   mechanisms MUST efficiently update SAV rules to guarantee the
   accuracy of SAV.

5.3.  Working in Incremental/Partial Deployment

   The new intra-domain SAV mechanism SHOULD NOT assume pervasive
   adoption.  Since routers scheduled to adopt the new mechanism may not
   be able to be upgraded simultaneously, the new intra-domain SAV
   mechanism SHOULD be able to provide incremental protection under
   incremental/partial deployment.  In addition, the new intra-domain
   SAV mechanism SHOULD outperform the current ones in the same
   incremental/partial deployment scenario.

Li, et al.                Expires 25 July 2025                 [Page 12]
Internet-Draft    Intra-domain SAVNET Problem Statement     January 2025

5.4.  Fast Convergence

   The new intra-domain SAV mechanism MUST adapt to prefix changes,
   route changes, and topology changes in an intra-domain network, and
   update SAV rules in a timely manner.  In addition, it MUST consider
   how to update SAV rules proactively or reactively so as to minimize
   improper blocks during convergence.

5.5.  Necessary Security Guarantee

   Necessary security tools SHOULD be considered in the new intra-domain
   SAV mechanism.  These security tools can help protect the SAV rule
   generation process.  Section 6 details the security scope and
   considerations for the new intra-domain SAV mechanism.

6.  Security Considerations

   The new intra-domain SAV mechanisms should not introduce additional
   security vulnerabilities or confusion to the existing intra-domain
   architectures or control or management plane protocols.

   Similar to the security scope of intra-domain routing protocols,
   intra-domain SAV mechanisms should ensure integrity and
   authentication of protocol messages that deliver the required SAV
   information, and consider avoiding unintentional misconfiguration.
   It is not necessary to provide protection against compromised or
   malicious intra-domain routers which poison existing control or
   management plane protocols.  Compromised or malicious intra-domain
   routers may not only affect SAV, but also disrupt the whole intra-
   domain routing domain.  Security solutions to prevent these attacks
   are beyond the capability of intra-domain SAV.

7.  IANA Considerations

   This document does not request any IANA allocations.

8.  Acknowledgements

   Many thanks to the valuable comments from: Jared Mauch, Barry Greene,
   Fang Gao, Kotikalapudi Sriram, Anthony Somerset, Yuanyuan Zhang, Igor
   Lubashev, Alvaro Retana, Joel Halpern, Aijun Wang, Michael
   Richardson, Li Chen, Gert Doering, Mingxing Liu, Libin Liu, John
   O'Brien, Roland Dobbins, Xiangqing Chang, Tony Przygienda, Yingzhen
   Qu, Changwang Lin, James Guichard, Linda Dunbar, Robert Sparks, Yu
   Fu, Stephen Farrel etc.

9.  References

Li, et al.                Expires 25 July 2025                 [Page 13]
Internet-Draft    Intra-domain SAVNET Problem Statement     January 2025

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

9.2.  Informative 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, <https://www.rfc-editor.org/info/rfc2827>.

   [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
              Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
              2004, <https://www.rfc-editor.org/info/rfc3704>.

   [RFC5210]  Wu, J., Bi, J., Li, X., Ren, G., Xu, K., and M. Williams,
              "A Source Address Validation Architecture (SAVA) Testbed
              and Deployment Experience", RFC 5210,
              DOI 10.17487/RFC5210, June 2008,
              <https://www.rfc-editor.org/info/rfc5210>.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
              December 2005, <https://www.rfc-editor.org/info/rfc4301>.

   [RFC9256]  Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
              A., and P. Mattes, "Segment Routing Policy Architecture",
              RFC 9256, DOI 10.17487/RFC9256, July 2022,
              <https://www.rfc-editor.org/info/rfc9256>.

   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
              DOI 10.17487/RFC2784, March 2000,
              <https://www.rfc-editor.org/info/rfc2784>.

   [cable-verify]
              "Cable Source-Verify and IP Address Security", January
              2021, <https://www.cisco.com/c/en/us/support/docs/
              broadband-cable/cable-security/20691-source-verify.html>.

Li, et al.                Expires 25 July 2025                 [Page 14]
Internet-Draft    Intra-domain SAVNET Problem Statement     January 2025

   [IPSG]     "Configuring DHCP Features and IP Source Guard", January
              2016, <https://www.cisco.com/c/en/us/td/docs/switches/lan/
              catalyst2960/software/release/12-
              2_53_se/configuration/guide/2960scg/swdhcp82.html>.

   [RFC7039]  Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed.,
              "Source Address Validation Improvement (SAVI) Framework",
              RFC 7039, DOI 10.17487/RFC7039, October 2013,
              <https://www.rfc-editor.org/info/rfc7039>.

   [RFC6890]  Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
              "Special-Purpose IP Address Registries", BCP 153,
              RFC 6890, DOI 10.17487/RFC6890, April 2013,
              <https://www.rfc-editor.org/info/rfc6890>.

   [manrs-antispoofing]
              "MANRS Implementation Guide", January 2023,
              <https://www.manrs.org/netops/guide/antispoofing>.

   [nist-rec] "Resilient Interdomain Traffic Exchange - BGP Security and
              DDoS Mitigation", January 2019,
              <https://www.nist.gov/publications/resilient-interdomain-
              traffic-exchange-bgp-security-and-ddos-mitigation">.

Authors' Addresses

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

   Jianping Wu
   Tsinghua University
   Beijing
   China
   Email: jianping@cernet.edu.cn

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

Li, et al.                Expires 25 July 2025                 [Page 15]
Internet-Draft    Intra-domain SAVNET Problem Statement     January 2025

   Mingqing Huang
   Zhongguancun Laboratory
   Beijing
   China
   Email: huangmq@mail.zgclab.edu.cn

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

Li, et al.                Expires 25 July 2025                 [Page 16]