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

SAVNET                                                             D. Li
Internet-Draft                                                     J. Wu
Intended status: Informational                                    L. Qin
Expires: 17 August 2024                              Tsinghua University
                                                                M. Huang
                                                                 N. Geng
                                                                  Huawei
                                                        14 February 2024

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

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 17 August 2024.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Li, et al.               Expires 17 August 2024                 [Page 1]
Internet-Draft    Intra-domain SAVNET Problem Statement    February 2024

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
     1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   5
   2.  Existing Mechanisms . . . . . . . . . . . . . . . . . . . . .   5
   3.  Gap Analysis  . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Outbound Traffic Validation . . . . . . . . . . . . . . .   6
     3.2.  Inbound Traffic Validation  . . . . . . . . . . . . . . .   8
   4.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   9
   5.  Requirements for New SAV Mechanisms . . . . . . . . . . . . .  10
     5.1.  Automatic Update  . . . . . . . . . . . . . . . . . . . .  10
     5.2.  Accurate Validation . . . . . . . . . . . . . . . . . . .  10
     5.3.  Working in Incremental/Partial Deployment . . . . . . . .  10
     5.4.  Fast Convergence  . . . . . . . . . . . . . . . . . . . .  11
     5.5.  Necessary Security Guarantee  . . . . . . . . . . . . . .  11
   6.  Intra-domain SAV Scope  . . . . . . . . . . . . . . . . . . .  11
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     10.2.  Informative References . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   Source Address Validation (SAV) is important for defending against
   source address spoofing attacks and allowing accurate traceback.  A
   multi-fence architecture called Source Address Validation
   Architecture (SAVA) [RFC5210] was proposed to validate source
   addresses at three levels: access network SAV, intra-domain SAV, and
   inter-domain SAV.  When SAV is not fully enabled at the edge of the
   Internet, the multi-fence architecture can help enhance the
   validation across the whole Internet and thus reduce the
   opportunities of launching source address spoofing attacks.

Li, et al.               Expires 17 August 2024                 [Page 2]
Internet-Draft    Intra-domain SAVNET Problem Statement    February 2024

   Particularly, access network SAV ensures that a host uses a valid
   address assigned to the host statically or dynamically.  In this way,
   the host cannot use the source address of another host.  There are
   many mechanisms for SAV in access networks.  Static ACL rules can be
   manually configured for validation by specifying which source addre-
   sses are acceptable or unacceptable.  Dynamic ACL is another
   efficient mechanism which is associated with authentication servers
   (e.g., RADIUS and DIAMETER).  The servers receive access requests and
   then install or enable ACL rules on the device to permit particular
   users' packets.  SAVI [RFC7039] represents a kind of mechanism
   enforcing that the legitimate IP address of a host matches the link-
   layer property of the host's network attachment.  For example, SAVI
   solution for DHCP [RFC7513] creates a binding between a DHCPv4/
   DHCPv6-assigned IP address and a link-layer property (like MAC
   address or switch port) on a SAVI device.  IP Source Guard (IPSG)
   [IPSG] combined with DHCP snooping is an implementation of SAVI
   solution for DHCP.  Cable Source-Verify [cable-verify] also shares
   some features of SAVI and is used in cable modem networks.  Cable
   modem termination system (CMTS) devices with Cable Source-Verify
   maintain the bindings of the CPE's IP address, the CPE's MAC address,
   and the corresponding cable modem identifier.  When receiving
   packets, the device will check the validity of the packets according
   to the bindings.

   Given numerous access networks managed by different operators
   throughout the world, it is difficult to require all access networks
   to effectively deploy SAV.  Therefore, intra-domain SAV and inter-
   domain SAV are needed to block spoofing traffic as close to the
   source as possible.  Both intra-domain SAV and inter-domain SAV
   usually perform validation at the granularity of IP prefixes, which
   is coarser than the validation granularity of access network SAV, 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 ASes.  The 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 other ASes.  The intra-
   domain SAV for AS X has two goals: i) blocking the illegitimate
   packets originated from its host networks or customer networks with
   spoofed source addresses; and ii) blocking the illegitimate packets
   coming from other ASes which spoof the source addresses of AS X.

   Figure 1 illustrates the function of intra-domain SAV with two cases.
   Case i shows that AS X forwards spoofed packets originated from its
   host networks or customer networks to other ASes (e.g., AS Y).  If AS
   X deploys intra-domain SAV, the spoofed packets from its host
   networks or customer networks can be blocked by AS X itself (i.e.,

Li, et al.               Expires 17 August 2024                 [Page 3]
Internet-Draft    Intra-domain SAVNET Problem Statement    February 2024

   Goal i).  Case ii shows that AS X receives the packets which spoof AS
   X's source addresses 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
   X (i.e., Goal ii).

   Case i: AS X forwards spoofed packets originated from its
           host networks or customer networks to other ASes (e.g., AS Y)
   Goal i: If AS X deploys intra-domain SAV,
           the spoofed packets can be blocked by AS X

     +------+  Spoofed packets  +------+
     | AS X |------------------>| AS Y |
     +------+                   +------+

   Case ii: AS X receives packets spoofing
            AS X's source addresses 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  +------+
     | AS X |<------------------| AS Y |
     +------+                   +------+

           Figure 1: An example for illustrating intra-domain SAV

   There are many mechanisms for intra-domain SAV.  This document
   provides the gap analysis of existing intra-domain SAV mechanisms.
   According to the gap analysis, the document concludes the main
   problems of existing mechanisms and describes the requirements for
   future intra-domain SAV mechanisms.

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 and is
   inferred from the SAV Information Base.

   SAV Table: The table or data structure that implements the SAV rules
   and is used for source address validation in the data plane.

   Host-facing Router: An intra-domain router of an AS which is
   connected to a host network (i.e., a layer-2 network).

   Customer-facing Router: An intra-domain router of an AS which is
   connected to a customer network running the routing protocol (i.e., a
   layer-3 network).

Li, et al.               Expires 17 August 2024                 [Page 4]
Internet-Draft    Intra-domain SAVNET Problem Statement    February 2024

   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.

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 Mechanisms

   Ingress filtering [RFC2827][RFC3704] is the current practice of
   intra-domain SAV.  This section briefly introduces the existing
   intra-domain SAV mechanisms.

   *  ACL-based ingress filtering [RFC2827][RFC3704] is a typical
      mechanism for intra-domain SAV.  ACL rules can be configured for
      blocking or permitting packets with specific source addresses.
      This mechanism can be applied at the downstream interfaces of
      host-facing routers or customer-facing routers
      [manrs-antispoofing].  The validation at downstream interfaces
      will prevent the corresponding host networks or customer networks
      from spoofing source prefixes of other networks.  In addition, at
      the upstream interfaces of AS border routers, ACL can be enabled
      for blocking packets with disallowed source prefixes, such as the
      internal source prefixes owned by the AS [nist-rec].  In any
      application scenario, ACL rules should be updated in time to be
      consistent with the latest filtering criteria.

   *  Strict uRPF [RFC3704] is another commonly used mechanism for SAV
      in intra-domain networks.  Routers deploying strict uRPF accept a
      data packet only when i) the local FIB contains a prefix
      encompassing 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.
      Strict uRPF is usually used at downstream interfaces of host-
      facing routers or customer-facing routers.

Li, et al.               Expires 17 August 2024                 [Page 5]
Internet-Draft    Intra-domain SAVNET Problem Statement    February 2024

   *  Loose uRPF [RFC3704] takes a looser validation mechanism than
      strict uRPF to avoid improper block.  A packet will be accepted if
      the local FIB contains a prefix encompassing the packet's source
      address regardless of the interface from which the packet is
      received.  Upstream interfaces of AS border routers can enable
      loose uRPF for blocking non-global addresses [nist-rec].

   *  Carrier Grade NAT has some operations on the source addresses of
      packets, but 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 judge
      whether the source address is spoofed or not.  In addition, the
      packet with a spoofed source address will be forwarded directly if
      the spoofed source address is not included in the INSIDE access
      list.  Therefore, Carrier Grade NAT cannot help block or traceback
      spoofed packets, and other SAV mechanisms are still needed.

3.  Gap Analysis

   Existing intra-domain SAV mechanisms either require high operational
   overhead or have limitations in accuracy.  They may improperly block
   the traffic with legitimate source addresses (i.e., improper block)
   or improperly permit the traffic with spoofed source addresses (i.e.,
   improper permit).

3.1.  Outbound Traffic Validation

   Outbound traffic validation is implemented at downstream interfaces
   of host-facing or customer-facing routers to validate packets
   originated from their host networks or customer networks.  As
   described previously, ACL rules can be configured at downstream
   interfaces for ingress filtering.  These rules need to be updated
   when prefixes or topologies of host networks or customer networks
   change.  If ACL rules are not updated in time, improper block or
   improper permit may occur.  To ensure the accuracy of SAV in dynamic
   networks, high operational overhead will be induced to achieve timely
   updates for ACL configurations.

   Strict uRPF can also be used for outbound traffic validation, but
   there may be improper block problem in multi-homing scenario.
   Figure 2 shows such a case.  In the figure, Network 1 is a host/
   customer network of the AS.  It owns prefix 10.0.0.0/15 and is
   attached to two intra-domain routers, i.e., Router 1 and Router 2.
   For the load balance purpose of inbound traffic, Network 1 expects
   the inbound traffic destined for 10.1.0.0/16 to come only from Router
   1 and the inbound traffic destined for 10.0.0.0/16 to come only from
   Router 2.  To this end, Router 1 only learns the route to sub prefix

Li, et al.               Expires 17 August 2024                 [Page 6]
Internet-Draft    Intra-domain SAVNET Problem Statement    February 2024

   10.1.0.0/16 from Network 1, while Router 2 only learns the route to
   the other sub prefix 10.0.0.0/16 from Network 1.  Then, Router 1 and
   Router 2 advertise the learned sub prefix to the other routers in the
   AS through intra-domain routing protocols such as OSPF or IS-IS.
   Finally, Router 1 learns the route to 10.0.0.0/16 from Router 3, and
   Router 2 learns the route to 10.1.0.0/16 from Router 3.  The FIBs on
   Router 1 and Router 2 are shown in the figure.  Although Network 1
   does not expect inbound traffic destined for 10.0.0.0/16 to come from
   Router 1, it may send outbound traffic with source addresses of
   prefix 10.0.0.0/16 to Router 1 for load balance of outbound traffic.
   As a result, there is asymmetric routing between Network 1 and Router
   1.  Similarly, Network 1 may also send outbound traffic with source
   addresses of prefix 10.1.0.0/16 to Router 2, resulting in asymmetric
   routing between Network 1 and Router 2.

    +-------------------------------------------------------------+
    |                                                      AS     |
    |                        +----------+                         |
    |                        | Router 3 |                         |
    | FIB on Router 1        +----------+  FIB on Router 2        |
    | Dest         Next_hop   /\      \    Dest         Next_hop  |
    | 10.1.0.0/16  Network 1  /        \   10.0.0.0/16  Network 1 |
    | 10.0.0.0/16  Router 3  /         \/  10.1.0.0/16  Router 3  |
    |                +----------+     +----------+                |
    |                | Router 1 |     | Router 2 |                |
    |                +-----+#+--+     +-+#+------+                |
    |                        /\         /                         |
    |   Outbound traffic with \        / Inbound traffic with     |
    |   source IP addresses    \      /  destination IP addresses |
    |   of 10.0.0.0/16          \    \/  of 10.0.0.0/16           |
    |                     +---------------+                       |
    |                     | Host/Customer |                       |
    |                     |   Network 1   |                       |
    |                     | (10.0.0.0/15) |                       |
    |                     +---------------+                       |
    |                                                             |
    +-------------------------------------------------------------+

         Figure 2: Asymmetric routing in the multi-homing scenario

   Strict uRPF takes the entries in FIB for SAV.  It can improperly
   block the packets with legitimate source prefixes when asymmetric
   routing exists.  In the figure, if Router 1 applies strict uRPF at
   interface '#', the SAV rule is that Router 1 only accepts packets
   with source addresses of 10.1.0.0/16 from Network 1.  Therefore, when
   Network 1 sends packets with source addresses of 10.0.0.0/16 to
   Router 1, strict uRPF at Router 1 will improperly block these
   legitimate packets.  Similarly, when Router 2 with strict uRPF

Li, et al.               Expires 17 August 2024                 [Page 7]
Internet-Draft    Intra-domain SAVNET Problem Statement    February 2024

   deployed receives packets with source addresses of prefix 10.1.0.0/16
   from Network 1, it will also improperly block these legitimate
   packets.  Therefore, strict uRPF may cause improper block problem in
   the case of asymmetric routing.

3.2.  Inbound Traffic Validation

   Inbound traffic validation is performed at upstream interfaces of AS
   border routers to validate the packets from other ASes.  Figure 3
   shows an example of inbound SAV.  In the figure, Router 3 and Router
   4 deploy SAV mechanisms at interface '#' for validating external
   packets.  Hence, there are multiple points for inbound traffic
   validation for the AS.

   ACL-based ingress filtering is usually used for validating inbound
   traffic.  By configuring specified ACL rules, inbound packets with
   disallowed source prefixes (e.g., non-global addresses or the
   internal source prefixes) can be blocked.  As mentioned above, ACL-
   based ingress filtering requires timely updates when the routing
   status changes dynamically.  When the ACL rules are not updated in
   time, there may be improper block or improper permit problems.  The
   operational overhead of maintaining updated ACL rules will be
   extremely high when there are multiple inbound validation points as
   shown in Figure 3.

   Loose uRPF is another inbound SAV mechanism and is more adaptive than
   ACL-based rules.  But it sacrifices the directionality of SAV and has
   limited blocking capability, because it allows packets with source
   addresses that exist in the FIB table at all router interfaces.

Li, et al.               Expires 17 August 2024                 [Page 8]
Internet-Draft    Intra-domain SAVNET Problem Statement    February 2024

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

                    Figure 3: A scenario of inbound SAV

4.  Problem Statement

   Accurate validation and low operational overhead are two important
   design goals of intra-domain SAV mechanisms.  As analyzed above,
   asymmetric routing and dynamic networks are two challenging scenarios
   for the two goals.  In these scenarios, existing SAV mechanisms have
   problems of inaccurate validation or high operational overhead.

   ACL-based SAV relies on manual configurations and thus requires high
   operational overhead in dynamic networks.  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.

Li, et al.               Expires 17 August 2024                 [Page 9]
Internet-Draft    Intra-domain SAVNET Problem Statement    February 2024

   Strict uRPF-based SAV can automatically update SAV rules, but may
   improperly block legitimate traffic under asymmetric routing.  The
   root cause is that strict uRPF leverages the local FIB table to
   determine the incoming interface for source addresses, which may not
   match the real data-plane forwarding path from the source, due to the
   existence of asymmetric routes.  Hence, it may mistakenly consider a
   valid incoming interface as invalid, resulting in improper block
   problem; or it may consider an invalid incoming interface as valid,
   resulting in improper permit problem.

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

5.  Requirements for New SAV Mechanisms

   This section lists the requirements which can be a guidance for
   narrowing the gaps of existing intra-domain SAV mechanisms.  The
   requirements can be fully or partially fulfilled when designing new
   intra-domain SAV mechanisms.

5.1.  Automatic Update

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

5.2.  Accurate Validation

   The new intra-domain SAV mechanisms needs 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 the malicious packets with forged source
   addresses can be efficiently filtered.  When there are network
   changes, the new mechanisms MUST update SAV rules efficiently for
   keeping the high accuracy of validaiton.

5.3.  Working in Incremental/Partial Deployment

   The new intra-domain SAV mechanisms SHOULD NOT assume pervasive
   adoption.  Some routers may not be able to be easily upgraded for
   supporting the new SAV mechanism due to their limitations of
   capabilities, versions, or vendors.  The mechanisms SHOULD be able to
   provide protection even when it is partially deployed.  The
   effectiveness of protection for the new intra-domain SAV mechanisms
   under partial deployment SHOULD be no worse than existing mechanisms.

Li, et al.               Expires 17 August 2024                [Page 10]
Internet-Draft    Intra-domain SAVNET Problem Statement    February 2024

5.4.  Fast Convergence

   Network changes may cause SAV rules to be inaccurate and need to be
   updated.  The new intra-domain SAV mechanism MUST consider how to
   update SAV rules quickly so as to minimize improper block and
   improper permit impacts during convergence.

5.5.  Necessary Security Guarantee

   Necessary security tools SHOULD be contained in the new intra-domain
   SAV mechanisms.  In an insecure scenario, these security tools can
   help protect the SAV rule generation process.

6.  Intra-domain SAV Scope

   The new intra-domain SAV mechanisms work in the same scenarios as
   existing intra-domain SAV mechanisms.  Generally, it includes all IP-
   encapsulated scenarios:

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

   *  IP-encapsulated Tunnel (IPsec, GRE, SRv6, 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 addition, the new intra-domain SAV mechanisms SHOULD avoid data-
   plane packet modification.  Existing architectures or protocols or
   mechanisms can be used in the new SAV mechanisms to achieve better
   SAV function.

7.  Security Considerations

   The new intra-domain SAV mechanisms MUST 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
   packets that deliver the required SAV information.

Li, et al.               Expires 17 August 2024                [Page 11]
Internet-Draft    Intra-domain SAVNET Problem Statement    February 2024

   The new intra-domain SAV mechanisms do not provide protection against
   compromised or misconfigured routers that poison existing control
   plane protocols.  Such routers can not only disrupt the SAV function,
   but also affect the entire routing domain.

8.  IANA Considerations

   This document does not request any IANA allocations.

9.  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, etc.

10.  References

10.1.  Normative References

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

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

Li, et al.               Expires 17 August 2024                [Page 12]
Internet-Draft    Intra-domain SAVNET Problem Statement    February 2024

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

10.2.  Informative References

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

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

   [RFC7513]  Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address
              Validation Improvement (SAVI) Solution for DHCP",
              RFC 7513, DOI 10.17487/RFC7513, May 2015,
              <https://www.rfc-editor.org/info/rfc7513>.

Authors' Addresses

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

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

Li, et al.               Expires 17 August 2024                [Page 13]
Internet-Draft    Intra-domain SAVNET Problem Statement    February 2024

   Lancheng Qin
   Tsinghua University
   Beijing
   China
   Email: qlc19@mails.tsinghua.edu.cn

   Mingqing Huang
   Huawei
   Beijing
   China
   Email: huangmingqing@huawei.com

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

Li, et al.               Expires 17 August 2024                [Page 14]