Source Address Validation in Inter-domain Networks (Inter-domain SAVNET) Gap Analysis, Problem Statement, and Requirements
draft-wu-savnet-inter-domain-problem-statement-04

Network Working Group                                              J. Wu
Internet-Draft                                                     D. Li
Intended status: Informational                                    L. Qin
Expires: 3 June 2023                                 Tsinghua University
                                                                M. Huang
                                                                 N. Geng
                                                                  Huawei
                                                        30 November 2022

Source Address Validation in Inter-domain Networks (Inter-domain SAVNET)
           Gap Analysis, Problem Statement, and Requirements
           draft-wu-savnet-inter-domain-problem-statement-04

Abstract

   Source Address Validation in Inter-domain Networks (Inter-domain
   SAVNET) focuses on narrowing the technical gaps of existing source
   address validation (SAV) mechanisms in inter-domain scenarios.  This
   document provides a gap analysis of existing inter-domain SAV
   mechanisms, describes the problem statement based on the analysis
   results, and concludes the requirements for improving inter-domain
   SAV.

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.

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 3 June 2023.

Wu, et al.                 Expires 3 June 2023                  [Page 1]
Internet-Draft    Inter-domain SAVNET Problem Statement    November 2022

Copyright Notice

   Copyright (c) 2022 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Gap Analysis  . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Improper Permit . . . . . . . . . . . . . . . . . . . . .   4
       3.1.1.  Spoofing from Provider and Peer . . . . . . . . . . .   4
       3.1.2.  Spoofing within a Customer Cone . . . . . . . . . . .   5
     3.2.  Improper Block  . . . . . . . . . . . . . . . . . . . . .   6
       3.2.1.  NO_EXPORT in BGP Advertisement  . . . . . . . . . . .   6
       3.2.2.  Direct Server Return (DSR) Scenario . . . . . . . . .   7
     3.3.  Misaligned Incentive  . . . . . . . . . . . . . . . . . .   8
   4.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   9
     4.1.  Inaccurate Validation . . . . . . . . . . . . . . . . . .   9
     4.2.  Misaligned Incentive  . . . . . . . . . . . . . . . . . .  10
   5.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .  10
     5.1.  Accurate SAV  . . . . . . . . . . . . . . . . . . . . . .  10
     5.2.  Direct Incentive  . . . . . . . . . . . . . . . . . . . .  10
     5.3.  Working in Partial Deployment . . . . . . . . . . . . . .  11
     5.4.  Acceptable Overhead . . . . . . . . . . . . . . . . . . .  11
   6.  Inter-domain SAVNET Scope . . . . . . . . . . . . . . . . . .  11
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   Source address validation in inter-domain networks (Inter-domain
   SAVNET) is vital to mitigate source address spoofing between
   Autonomous Systems (ASes).  Inter-domain SAV is essential to the
   Internet security [RFC5210].  Many efforts have been taken on the
   tasks of inter-domain SAV.

Wu, et al.                 Expires 3 June 2023                  [Page 2]
Internet-Draft    Inter-domain SAVNET Problem Statement    November 2022

   Ingress filtering [RFC2827] [RFC3704] is a typical method of inter-
   domain SAV.  Strict uRPF [RFC3704] reversely looks up the FIB table
   and requires that the valid incoming interface must be the same
   interface which would be used to forward traffic to the source
   address in the FIB table.  Feasible-path uRPF (FP-uRPF) [RFC3704],
   taking a looser SAV than strict uRPF, is designed to add more
   alternative valid incoming interfaces for the source address.  To be
   more flexible about directionality, BCP 84 [RFC3704][RFC8704]
   recommends that i) the loose uRPF method which loses directionality
   completely SHOULD be applied on lateral peer and transit provider
   interfaces, and that ii) the Enhanced FP-uRPF (EFP-uRPF) method with
   Algorithm B, looser than strict uRPF, FP-uRPF, and EFP-uRPF with
   Algorithm A, SHOULD be applied on customer interfaces.  Routers
   deploying EFP-uRPF accept a data packet from customer interfaces only
   when the source address of the packet is contained in that of the
   customer cone.

   Despite the diversity of inter-domain SAV mechanisms, there are still
   some points that are under considered but important for enhancing
   Internet security.  Moreover, in the currently focused SAV work
   scope, these mechanisms may lead to improper permit or improper block
   problems in some scenarios.

   This document does an analysis of the existing inter-domain SAV
   mechanisms and answers: i) what are the technical gaps, ii) what are
   the major problems needing to be solved, and iii) what are the
   potential directions for further enhancing inter-domain SAV.

2.  Terminology

   SAV: Source Address Validation, i.e., validating the authenticity of
   a packet's source IP address.

   SAV rule: The rule generated by intra-domain SAV mechanisms that
   determines valid incoming interfaces for a specific source prefix.

   SAV table: The data structure that stores SAV rules on the data
   plane.  The router queries its local SAV table to validate the
   authenticity of source addresses.

   Improper block: The packets with legitimate source IP addresses are
   blocked improperly due to inaccurate SAV rules.

   Improper permit: The packets with spoofed source IP addresses are
   permitted improperly due to inaccurate SAV rules.

Wu, et al.                 Expires 3 June 2023                  [Page 3]
Internet-Draft    Inter-domain SAVNET Problem Statement    November 2022

3.  Gap Analysis

   BCP 84 recommends loose uRPF at provider/peer interfaces and EFP-uRPF
   at customer interfaces.  The followings are the gap analysis of these
   SAV mechanisms.

3.1.  Improper Permit

   Existing SAV mechanisms may have improper permit problems that the
   packets with spoofed source addresses are considered as legal.  Here
   are two cases where improper permit will appear.

3.1.1.  Spoofing from Provider and Peer

   The first case is at provider or peer interfaces where loose uRPF is
   deployed.  Loose uRPF almost accepts any source address, which fails
   to protect ASes in the customer cone from externally injected
   attacks.

                             +----------+
             Attacker(P1') +-+  AS3(P3) |
                             +----+-----+
                                  |
                            (P2C) |
                                  |
                             +----v-----+
                             |  AS4(P4) |
                             +/\+----+/\+
                              /        \
                             /          \
                      (C2P) /            \ (C2P)
                    +----------+       +----------+
           Victim +-+  AS1(P1) |       |  AS2(P2) +-+Server
                    +----------+       +----------+

            P1' is the spoofed source prefix P1 by the attacker
            which is attached to AS3

            Figure 1: A reflection attack scenario

   Figure 1 shows a reflection attack scenario.  The arrow indicates the
   direction of the commercial relationship between two ASes.  AS 3 is
   the provider of AS 4.  AS 4 is the provider of AS 1 and AS 2.  Assume
   AS4 has deployed inter-domain SAV.  EFP-uRPF is deployed at AS 4's
   customer interfaces, and loose uRPF is implemented at AS 4's provider
   interface.  Assume a reflection attacker is attached to AS 3.  It
   sends packets spoofing source addresses of P1 to the server located

Wu, et al.                 Expires 3 June 2023                  [Page 4]
Internet-Draft    Inter-domain SAVNET Problem Statement    November 2022

   in AS 2 for attacking the victim in AS 1.  However, this attack
   cannot be successfully blocked though AS 4 has deployed inter-domain
   SAV.

3.1.2.  Spoofing within a Customer Cone

   The second case is at customer interfaces where EFP-uRPF with
   algorithm B is deployed.  It allows packets with source addresses of
   the customer cone to enter from any customer interfaces to avoid
   potential improper block problems that EFP-uRPF with algorithm A may
   have.  However, vulnerability is imported.  Although EFP-uRPF with
   algorithm B can prevent ASes inside the customer cone from using
   source addresses of ASes outside the customer cone, it compromises
   the directionality of traffic from different customers, which will
   lead to improper permit problems.

                           +----------+
                           + AS 3(P3) |
                           +----------+
                                |
                          (P2C) |
                                |
                           +----v-----+
                           | AS 4(P4) |
                           +/\+----+/\+
                            /        \
                           /          \
                    (C2P) /            \ (C2P)
                   +----------+       +----------+
           Victim+-+ AS 1(P1) |       | AS 2(P2) +-+Attacker(P1')
                   +----------+       +----------+

          P1' is the spoofed source prefix P1 by the attacker
          which is attached to AS2

          Figure 2: Spoofing within a customer cone

   In Figure 2, assume AS 4 implements EFP-uRPF with algorithm B at
   customer interfaces.  Under EFP-uRPF with algorithm B, AS 4 will
   generate SAV rules with legitimate P1 and P2 at both customer
   interfaces.  When the attacker in AS 2 spoofs source address of AS 1,
   AS 4 will improperly permit these packets with spoofed source
   addresses of prefix P1.  The same also applies when the attacker in
   AS 1 forges source prefix P2.  That is to say, EFP-uRPF algorithm B
   cannot prevent ASes inside the customer cone from spoofing each
   other.

Wu, et al.                 Expires 3 June 2023                  [Page 5]
Internet-Draft    Inter-domain SAVNET Problem Statement    November 2022

3.2.  Improper Block

   In some cases, existing inter-domain SAV mechanisms may improperly
   block the packets with legitimate source addresses.  Here are two
   cases where improper permit will appear.

3.2.1.  NO_EXPORT in BGP Advertisement

   Figure 3 presents a NO_EXPORT scenario.  AS 1 is the common customer
   of AS 2 and AS 3.  AS 4 is the provider of AS 2.  The relationship
   between AS 3 and AS 4 is customer-to-provider (C2P) or peer-to-peer
   (P2P).  All arrows in Figure 2 represent BGP advertisements.  AS 2
   owns prefix P2 and advertises it to AS 4 through BGP.  AS 3 also
   advertises its own prefix P3 to AS 4.  AS 1 has prefix P1 and
   advertises the prefix to the providers, i.e., AS 2 and AS 3.  After
   receiving the route for prefix P1 from AS 1, AS 3 propagates this
   route to AS 4.  Differently, AS 2 does not propagate the route for
   prefix P1 to AS 4, since AS 1 adds the NO_EXPORT community attribute
   in the BGP advertisement destined to AS 2.  In the end, AS 4 only
   learns the route for prefix P1 from AS 3.

   Assume that AS 3 is the customer of AS 4.  If AS 4 runs EFP-uRPF with
   algorithm A at customer interfaces, the packets with source addresses
   of P1 are required to arrive only from AS 3.  When AS 1 sends the
   packets with legitimate source addresses of prefix P1 to AS 4 through
   AS 2, AS 4 will improperly block these packets.  EFP-uRPF with
   algorithm B works well in this case.

   Assume that AS 3 is the peer of AS 4.  AS 4 will never learn the
   route of P1 from its customer interfaces.  So, no matter EFP-uRPF
   with algorithm A or that with algorithm B are used by AS 4, there
   will be improper block problems.

   Besides the NO_EXPORT case above, there are also many route filtering
   policies that can result in interruption of BGP advertisement.
   Improper block may be induced by existing inter-domain SAV mechanisms
   in such cases, and it is hard to prevent networks from taking these
   configurations.

Wu, et al.                 Expires 3 June 2023                  [Page 6]
Internet-Draft    Inter-domain SAVNET Problem Statement    November 2022

                              +-----------------+
                              |       AS 4      |
                              +-+/\+-------+/\+-+
                                /           \
                               /             \
                      P3[AS 3]/(P2P/C2P) (C2P)\ P2[AS 2]
              P1[AS 3, AS 1] /                 \
                            /                   \
                  +----------------+    +----------------+
             P3---+      AS 3      |    |      AS 2      +---P2
                  +--------/\------+    +-------/\-------+
                             \                   /
                      P1[AS 1]\(C2P)       (C2P)/P1[AS 1]
                               \               / NO_EXPORT
                              +-----------------+
                              |       AS 1      +---P1
                              +-----------------+

          Figure 3: Interrupted BGP advertisement caused by NO_EXPORT

3.2.2.  Direct Server Return (DSR) Scenario

   Anycast is a network addressing and routing methodology.  An anycast
   IP address is shared by devices in multiple locations, and incoming
   requests are routed to the location closest to the sender.
   Therefore, anycast is widely used in Content Delivery Network (CDN)
   to improve the quality of service by bringing the content to the user
   as soon as possible.  In practice, anycast IP addresses are usually
   announced only from some locations with a lot of connectivity.  Upon
   receiving incoming requests from users, requests are then tunneled to
   the edge locations where the content is.  Subsequently, the edge
   locations do direct server return (DSR), i.e., directly sending the
   content to the users.  To ensure that DSR works, servers in edge
   locations must send response packets with anycast IP address as the
   source address.  However, since edge locations never advertise the
   anycast prefixes through BGP, an intermediate AS with EFP-uRPF may
   improperly block these response packets.

Wu, et al.                 Expires 3 June 2023                  [Page 7]
Internet-Draft    Inter-domain SAVNET Problem Statement    November 2022

                           +----------+
           Anycast Server+-+  AS3(P3) |
                           +----------+
                                |
                          (P2C) | P3[AS3]
                                |
                           +----v-----+
                           |   AS4    |
                           +/\+----+/\+
                            /        \
                   P1[AS1] /          \ P2[AS2]
                    (C2P) /            \ (C2P)
                +----------+          +----------+
          User+-+  AS1(P1) |          |  AS2(P2) +-+Edge Server
                +----------+          +----------+

          P3 is the anycast prefix and is only advertised from AS3

          Figure 4: A Direct Server Return (DSR) scenario

   Figure 4 shows a specific DSR scenario.  The anycast IP prefix (i.e.,
   prefix P3) is only advertised from AS 3 through BGP.  Assume AS 3 is
   the provider of AS 4.  AS 4 is the provider of AS 1 and AS 2.  When
   users in AS 1 send requests to the anycast destination IP, the
   forwarding path from users to anycast servers is AS 1 -> AS 4 -> AS
   3.  Anycast servers in AS 3 receive the requests and then tunnel them
   to the edge servers in AS 2.  Finally, the edge servers send the
   content to the users with source addresses of prefix P3.  The reverse
   forwarding path is AS 2 -> AS 4 -> AS 1.  Since AS 4 never receives
   routing information for prefix P3 from AS 2, EFP-uRPF algorithm A/
   EFP-uRPF algorithm B or other existing uRPF-like mechanisms at AS 4
   will improperly block the response packets from AS 2.

3.3.  Misaligned Incentive

   Misaligned incentive is often cited as a major reason why some ASes
   do not deploy BCP38 [RFC2827].  Specifically, BCP38 only prevents the
   AS who deploys SAV from originating spoofed-source traffic, but does
   not protect the AS from receiving spoofed-source traffic or being the
   victim of source address spoofing attacks.  As a result, the costs of
   deploying SAV are paid by the AS itself, but the benefits are
   experienced by the rest of the Internet.

Wu, et al.                 Expires 3 June 2023                  [Page 8]
Internet-Draft    Inter-domain SAVNET Problem Statement    November 2022

   Compared with BCP38, the EFP-uRPF mechanism proposed in [RFC8704] can
   protect the AS which deploys SAV from receiving spoofed-source
   traffic from customer interfaces.  However, the combination of EFP-
   uRPF and loose uRPF validates upstream (i.e., the packets from
   customers to providers) strictly but takes a loose validation for
   downstream (i.e., the packets from providers/peers to customers).  It
   aims to prevent the customer cone from originating spoofed-source
   traffic, but does not protect the customer cone from receiving
   spoofed-source traffic or being the victim of attacks from ASes
   outside the customer cone.  Particularly, in the case of partial
   deployment, even an AS as well as its provider deploy SAV following
   the recommendations in [RFC8704], the AS may still suffer source
   address spoofing attacks.  For example, in the reflection attack
   scenario in Figure 1, even if the victim network (i.e.  AS1) and its
   provider (i.e.  AS4) deploy SAV, AS1 is still vulnerable to the
   reflection attack from AS3, because it cannot help AS4 accurately
   identify and reject the forged request from AS3.  The victim network
   in a reflection attack cannot gain additional protection even if it
   has deployed existing SAV mechanisms.

   Overall, the combination of EFP-uRPF and loose uRPF makes a
   significant improvement upon BCP38, but it is still not well-aligned
   with the direct incentive that protects the AS which deploys SAV from
   being the victim of source address spoofing attacks (especially
   reflection attacks).  A detailed discussion about misaligned
   incentive can be found in [draft-qin-savnet-incentive].

4.  Problem Statement

4.1.  Inaccurate Validation

   Existing inter-domain SAV mechanisms have accuracy gaps in some
   scenarios like routing asymmetry induced by BGP route policies or
   configurations.  Particularly, EFP-uRPF takes the RPF list in data-
   plane, which means the packets from customer interfaces with unknown
   source prefixes (not appear in the RPF list) will be discarded
   directly.  Improper block issues will arise when legitimate source
   prefixes are not accurately learned by EFP-uRPF.  The root cause is
   that these mechanisms leverage local RIB table of routers to learn
   the source addresses and determine the valid incoming interface,
   which may not match the real data-plane forwarding path from the
   source.  It may mistakenly consider a valid incoming interface as
   invalid, resulting in improper block problems; or consider an invalid
   incoming interface as valid, resulting in improper permit problems.
   Essentially, it is impossible to generate an accurate SAV table
   solely based on the router's local information due to the existence
   of asymmetric routes.

Wu, et al.                 Expires 3 June 2023                  [Page 9]
Internet-Draft    Inter-domain SAVNET Problem Statement    November 2022

4.2.  Misaligned Incentive

   Existing inter-domain SAV mechanisms pay more attention to upstream
   (traffic from customer to provider/peer), resulting in weak source
   address checking of downstream (traffic from provider/peer to
   customer).  The "strict upstream but weak downstream checking" makes
   the benefits of deploying SAV mainly flow to ASes outside the
   customer cone.  Moreover, the victim is still vulnerable to
   reflection attacks even when it has deployed existing inter-domain
   SAV mechanisms, because the victim with SAV deployment does not
   participate in protecting its source addresses from being forged.

5.  Requirements

   Inter-domain SAVNET focuses on narrowing the technical gaps of
   existing inter-domain SAV mechanisms.  The new inter-domain SAV
   mechanism MUST satisfy the following requirements.

5.1.  Accurate SAV

   The new inter-domain SAV mechanism MUST ensure accurate SAV.  It MUST
   avoid the improper block problems of EFP-uRPF and minimize the
   improper permit problems of existing inter-domain SAV mechanisms.
   Generating SAV rules solely depending on local routing information
   (e.g., RIB) results in inaccurate SAV in the case of asymmetric
   routing.  Accurate SAV requires that SAV rules MUST match real data-
   plane paths.  Therefore, to ensure the accuracy of SAV, extra
   information out of local routing information is required as a
   supplement.

5.2.  Direct Incentive

   The new inter-domain SAV mechanism MUST provide direct incentives.
   It would be attractive if the network who deploys SAV can protect
   itself from source address spoofing attacks (especially reflection
   attacks).  In particular, the mechanism MUST work for both upstream
   and downstream traffic, and downstream SHOULD be under the same SAV
   criteria as upstream.  It would be easy to achieve perfect all-round
   protection supposing SAV is fully deployed.  But when some ASes do
   not deploy SAV, efforts are needed to narrow the gaps as much as
   possible.

Wu, et al.                 Expires 3 June 2023                 [Page 10]
Internet-Draft    Inter-domain SAVNET Problem Statement    November 2022

5.3.  Working in Partial Deployment

   The new inter-domain SAV mechanism MUST provide protection for source
   addresses even the mechanism is partially deployed.  It is
   impractical to ensure that all the ASes or most of the ASes enable
   SAV simultaneously.  Partial deployment or incremental deployment
   have to be considered during the work of SAV.

5.4.  Acceptable Overhead

   The new inter-domain SAV mechanism MUST not modify data-plane
   packets, which keeps same as existing inter-domain SAV mechanisms.
   Existing architectures or protocols or mechanisms can be used in the
   new SAV mechanism to achieve better SAV function.

6.  Inter-domain SAVNET Scope

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

   *  Native IP forwarding: including both global routing table
      forwarding and CE site forwarding of VPN;

   *  IP-encapsulated Tunnel (IPsec, GRE, SRv6, etc.): focusing on the
      validation of the outer layer IP address;

   *  Both IPv4 and IPv6 addresses

   Scope does not include:

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

7.  Security Considerations

   SAV rules can be generated based on route information (FIB/RIB) or
   non-route information.  If the information is poisoned by attackers,
   the SAV rules will be false.  Lots of legal packets may be dropped
   improperly or malicious traffic with spoofed source addresses may be
   permitted improperly.  Route security should be considered by routing
   protocols.  Non-route information should also be protected by
   corresponding mechanisms or infrastructure.  If SAV mechanisms or
   protocols require information exchange, there should be some
   considerations on the avoidance of message alteration or message
   injection.

Wu, et al.                 Expires 3 June 2023                 [Page 11]
Internet-Draft    Inter-domain SAVNET Problem Statement    November 2022

   The SAV procedure referred in this document modifies no field of
   packets.  So, security considerations on data-plane is not in the
   scope of this document.

8.  IANA Considerations

   This document does not request any IANA allocations.

9.  Normative References

   [draft-qin-savnet-incentive]
              Qin, L., Li, D., Wu, J., Chen, L., and F. Gao, "The
              Incentive Consideration for Defense Against Reflection
              Attacks", 30 November 2022.

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

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

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

   [RFC8704]  Sriram, K., Montgomery, D., and J. Haas, "Enhanced
              Feasible-Path Unicast Reverse Path Forwarding", BCP 84,
              RFC 8704, DOI 10.17487/RFC8704, February 2020,
              <https://www.rfc-editor.org/info/rfc8704>.

Authors' Addresses

Wu, et al.                 Expires 3 June 2023                 [Page 12]
Internet-Draft    Inter-domain SAVNET Problem Statement    November 2022

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

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

   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

Wu, et al.                 Expires 3 June 2023                 [Page 13]