SIDROPS                                                            D. Li
Internet-Draft                                       Tsinghua University
Intended status: Standards Track                                  L. Qin
Expires: 2 April 2025                                            L. Chen
                                                                  L. Liu
                                                 Zhongguancun Laboratory
                                                       29 September 2024


                    Bicone Source Address Validation
                     draft-li-sidrops-bicone-sav-05

Abstract

   The primary design goal of source address validation (SAV) is
   avoiding improper blocks (i.e., blocking legitimate traffic) while
   maintaining directionality, especially in partial deployment
   scenarios (see [I-D.ietf-savnet-inter-domain-problem-statement] and
   [RFC8704]).  Existing advanced SAV solutions (e.g., EFP-uRPF
   [RFC8704]) typically generate ingress SAV allowlist filters on
   interfaces facing a customer or lateral peer AS.  This document
   analyzes the potential improper block problems when using an
   allowlist.  To avoid improper blocks, this document proposes a new
   SAV solution by generating an ingress SAV blocklist filter based on
   BGP updates, ROAs, and ASPAs related to the provider cone.  In
   practice, network operators can flexibly decide to use a blocklist or
   an allowlist according to their requirements and actual conditions.

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 2 April 2025.







Li, et al.                Expires 2 April 2025                  [Page 1]

Internet-Draft                 Bicone SAV                 September 2024


Copyright Notice

   Copyright (c) 2024 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
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Improper Block When the Allowlist is Incomplete . . . . . . .   4
   4.  Goals of Bicone SAV . . . . . . . . . . . . . . . . . . . . .   5
   5.  Blocklist Generation  . . . . . . . . . . . . . . . . . . . .   6
     5.1.  Key Idea  . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.2.  Generation Procedure  . . . . . . . . . . . . . . . . . .   7
     5.3.  Incremental and Partial Deployment of ASPAs . . . . . . .   9
   6.  A Challenging Scenario  . . . . . . . . . . . . . . . . . . .   9
   7.  Implementation and Operations Considerations  . . . . . . . .  10
     7.1.  Meeting the Goals . . . . . . . . . . . . . . . . . . . .  10
     7.2.  Storage Overhead  . . . . . . . . . . . . . . . . . . . .  11
     7.3.  Implementation and Operations Recommendations . . . . . .  11
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     11.2.  Informative References . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   Source address spoofing is one of the most serious security threats
   to today's Internet.  It serves as a main attack vector for large-
   scale Distributed Denial of Service (DDoS) attacks and is commonly
   used in reflective DDoS attacks.  To mitigate source address
   spoofing, many source address validation (SAV) solutions (e.g., BCP38
   [RFC2827] and BCP84 [RFC3704] [RFC8704]) have been proposed.  The
   primary design goal of SAV solutions is avoiding improper block
   (i.e., blocking legitimate traffic) while maintaining directionality,



Li, et al.                Expires 2 April 2025                  [Page 2]

Internet-Draft                 Bicone SAV                 September 2024


   especially in partial deployment scenarios (see
   [I-D.ietf-savnet-inter-domain-problem-statement] and [RFC8704]).

   Existing advanced SAV solutions (e.g., EFP-uRPF [RFC8704]) typically
   generate ingress SAV allowlist filters on interfaces facing a
   customer or lateral peer AS by using information related to the
   customer cone of that AS.  When adopting SAV based on the allowlist,
   the interface only allows incoming data packets using source
   addresses that are covered in the allowlist.  Therefore, the
   allowlist must contain all prefixes belonging to the corresponding
   customer cone.  Otherwise, if the allowlist is incomplete, it will
   improperly block legitimate traffic from the corresponding customer
   cone.

   This document analyzes the potential improper block problems when
   using an allowlist.  To avoid improper blocks, this document proposes
   a new SAV solution by generating an ingress SAV blocklist filter
   based on BGP updates, ROAs, and ASPAs related to the provider cone.
   The blocklist should contain as many prefixes belonging to the
   provider cone as possible.  When adopting SAV based on the blocklist,
   the interface blocks incoming data packets using source addresses
   that are covered in the blocklist.  In practice, network operators
   can flexibly decide to use a blocklist or an allowlist according to
   their requirements and actual conditions.

   The reader is encouraged to be familiar with
   [I-D.ietf-savnet-inter-domain-problem-statement], [RFC8704],
   [I-D.ietf-sidrops-aspa-profile], [RFC6482], and
   [I-D.ietf-sidrops-aspa-verification].

1.1.  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.  Terminology

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

   Provider Cone: The set of ASes an AS can reach by using only
   Customer-to-Provider (C2P) links.





Li, et al.                Expires 2 April 2025                  [Page 3]

Internet-Draft                 Bicone SAV                 September 2024


3.  Improper Block When the Allowlist is Incomplete

   The basic idea of existing allowlist-based SAV solutions is
   generating an allowlist by using information related to the customer
   cone of a customer or lateral peer AS.  Specifically, they identify
   prefixes belonging to the corresponding customer cone and only allows
   data packets using source addresses in these prefixes on the
   interface facing that customer or lateral peer AS.  This is because
   data packets received from a customer or lateral peer AS should use
   source addresses belonging to the customer cone of that AS unless
   there is a route leak [RFC7908].

   EFP-uRPF (BCP84 [RFC8704]) generates allowlists by using BGP UPDATE
   messages related to the corresponding customer cone.  However, if a
   multi-homed AS in customer cone limits propagation of its prefixes,
   EFP-uRPF may miss these prefixes in the allowlist, resulting in
   improper blocks.  Section 3.3 of [RFC8704] has given such an example
   of limited propagation of prefixes where a multi-homed customer AS
   attaches NO_EXPORT to all prefixes announced to one transit provider.

                           P1[AS5 AS3 AS1]
                           P2[AS5 AS3 AS1]
                  +---------+ (P2P/P2C) +---------+
                  |   AS4   +<----------+   AS5   |
                  +---------+           +---------+
                       /\                 /\
         P1 and P2 not /                  / P1[AS3 AS1]
          propagated  /                  /  P2[AS3 AS1]
               (C2P) /                  /   (C2P)
              +---------+       +---------+
              |   AS2   |       |   AS3   |
              +---------+       +---------+
                    /\           /\
   P1[AS1] NO_EXPORT \           / P1[AS1]
   P2[AS1] NO_EXPORT  \         /  P2[AS1]
               (C2P)   \       /   (C2P)
                      +---------+
                      |   AS1   |
                      +---------+
                         P1, P2 (prefixes originated)

       Figure 1: An example of limited propagation of prefixes in the
                               customer cone

   Figure 1 illustrates a similar scenario of limited propagation of
   prefixes in the customer cone of AS4.  Arrows in the figure indicate
   propagation direction of BGP announcements as well as AS relationship
   (i.e., Provider-to-Customer (P2C), Customer-to-Provider (C2P), or



Li, et al.                Expires 2 April 2025                  [Page 4]

Internet-Draft                 Bicone SAV                 September 2024


   Peer-to-Peer (P2P)) from sending AS to receiving AS.  AS1 announces
   the route for prefixes P1 and P2 to its two provider ASes, i.e., AS2
   and AS3.  Since AS1 attaches NO_EXPORT in the BGP UPDATE message sent
   to AS2, AS2 will not propagate the route to AS4.  As a result, AS4
   only receives the route to prefixes P1 and P2 from its lateral peer
   or provider AS5.  If AS4 uses EFP-uRPF (including Algorithm A and
   Algorithm B) to generate an allowlist on AS4-AS2 interface, the
   allowlist will not contain prefixes P1 and P2, and thus will
   improperly block data packets using source addresses in prefixes P1
   or P2.

   More recent SAV solutions (e.g., BAR-SAV [I-D.ietf-sidrops-bar-sav])
   additionally use Autonomous System Provider Authorization (ASPA)
   [I-D.ietf-sidrops-aspa-profile] and Route Origin Authorization (ROA)
   [RFC6482] related to the customer cone to generate a more robust
   allowlist.  Since registering ASPAs and ROAs is optional for network
   operators, ASPAs and ROAs would be partially deployed for a long
   time.  When some ASes in the customer cone (e.g., AS1 in Figure 1) do
   not register ASPAs or ROAs, this kind of solutions will still fail to
   discover all prefixes belonging to the customer cone, leading to an
   incomplete allowlist.  If the allowlist is incomplete, it will
   improperly block data packets using legitimate source addresses.

   Overall, considering the complexity of inter-domain routing, existing
   SAV solutions which use allowlist filters on interfaces facing a
   customer or lateral peer AS may fail to identify all prefixes of the
   corresponding customer cone.  In this case, the incomplete allowlist
   will have improper blocks.

4.  Goals of Bicone SAV

   Bicone SAV aims to achieve more robust ingress SAV filtering on
   interfaces facing a customer or lateral peer AS by flexibly using
   allowlist or blocklist filters.  It has two main goals:

   1.  Avoiding improper blocks.  Bicone SAV aims to avoid blocking
       legitimate data packets received from a customer or lateral peer
       AS.  As described in Section 3, if the allowlist is incomplete,
       it will improperly block legitimate data packets.  In this case,
       it is recommended to use a blocklist to avoid improper blocks.

   2.  Maintaining directionality.  Unlike Loose uRPF [RFC3704] which
       completely loses directionality, Bicone SAV aims to identify more
       source-spoofed data packets by maintaining directionality.  In
       general, the allowlist filter has stricter directionality than
       the blocklist filter, so using an allowlist will have less
       improper admits.




Li, et al.                Expires 2 April 2025                  [Page 5]

Internet-Draft                 Bicone SAV                 September 2024


5.  Blocklist Generation

   This section introduces how to generate a blocklist by using BGP
   updates, ROAs, and ASPAs related to the provider cone.

5.1.  Key Idea

   The provider cone of an AS is defined as the set of ASes an AS can
   reach by using only Customer-to-Provider (C2P) links.  Considering
   prefixes only associated with ASes in the provider cone should not be
   used as source addresses in data packets received from any customer
   or lateral peer AS unless there is a route leak [RFC7908].  The
   blocklist can contain prefixes only belonging to the provider cone.
   When using the blocklist on an interface facing a customer or lateral
   peer AS, it will block data packets received from that interface
   using any source address in the blocklist.

             P1 (prefix originated)
                  +---------+
                  |   AS6   |
                  +---------+
                       |
               P1[AS6] |
               (P2C)   |   P1[AS5 AS3 AS1]
                      \/   P2[AS5 AS3 AS1]
                  +---------+ (P2P/P2C) +---------+
                  |   AS4   +<----------+   AS5   |
                  +---------+           +---------+
                       /\                 /\
         P1 and P2 not /                  / P1[AS3 AS1]
          propagated  /                  /  P2[AS3 AS1]
               (C2P) /                  /   (C2P)
              +---------+       +---------+
              |   AS2   |       |   AS3   |
              +---------+       +---------+
                    /\           /\
   P1[AS1] NO_EXPORT \           / P1[AS1]
   P2[AS1] NO_EXPORT  \         /  P2[AS1]
               (C2P)   \       /   (C2P)
                      +---------+
                      |   AS1   |
                      +---------+
               P1, P2 (prefixes originated)

               Figure 2: An example of the multi-homed prefix






Li, et al.                Expires 2 April 2025                  [Page 6]

Internet-Draft                 Bicone SAV                 September 2024


   To generate such a blocklist, an AS can first identify ASes in its
   provider cone by using ASPAs and AS-PATH in BGP UPDATE messages.
   Then, it can discover prefixes belonging to these ASes by using ROAs
   and BGP UPDATE messages.  Subsequently, it must remove prefixes that
   also belong to its customer cone.  For example, in Figure 2, both AS1
   and AS6 announce the route for prefix P1.  If the blocklist on
   AS4-AS2 interface contains Prefix P1, it will cause improper blocks.
   Since an AS may not know if a prefix is belonging to its customer
   cone (as analyzed in Section 3), it should remove all suspicious
   prefixes.  To this end, it can use all BGP UPDATE messages and ROAs
   to identify prefixes that are belonging to both ASes in the provider
   cone and ASes not in the provider cone.  These prefixes should not be
   contained in the blocklist to avoid any potential improper block.
   Finally, it can include the remaining prefixes in the blocklist.

5.2.  Generation Procedure

   A detailed description of blocklist generation procedure is as
   follows:

   1.   Create the set of all directly connected Provider ASNs.  Call it
        AS-set Z(1).

   2.   Create the set of all unique AS_PATHs in Adj-RIBs-In of all
        interfaces facing Providers.

   3.   For each unique AS_PATH with N (N>1) ASNs, i.e., [ASN_{1},
        ASN_{2}, ..., ASN_{i}, ASN_{i+1}, ..., ASN_{N}] where ASN_{i} is
        the ith ASN in AS_PATH and the first ASN (i.e., ASN_{1}) is a
        directly connected Provider ASN.  If all unique AS_PATHs have
        been processed, go to Step 8.

   4.   Let i = N

   5.   Decrement i to i-1.

   6.   If ASN_{i} authorizes ASN_{i+1} as a Provider in ASN_{i}'s ASPA,
        ASNs from ASN_{1} to ASN_{i+1} (i.e., ASN_{1}, ASN_{2}, ...,
        ASN_{i}, and ASN_{i+1}) are included in AS-set Z(1) and go to
        Step 3.

   7.   If i == 1, go to Step 3.  Else, go to Step 5.

   8.   Let k = 1.

   9.   Increment k to k+1.





Li, et al.                Expires 2 April 2025                  [Page 7]

Internet-Draft                 Bicone SAV                 September 2024


   10.  Create AS-set Z(k) of ASNs that are not in AS-set Z(k-1) but are
        authorized as Providers in ASPAs of any ASN in AS-set Z(k-1).

   11.  If AS-set Z(k) is null, then set k_max = k-1 and go to Step 12.
        Else, form the union of AS-set Z(k) and AS-set Z(k-1) as AS-set
        Z(k) and go to Step 9.

   12.  Select all ROAs in which the authorized origin ASN is in AS-set
        Z(k_max).  Form the union of the sets of prefixes in the
        selected ROAs.  Call it Prefix-set S1.

   13.  Using the routes in Adj-RIBs-In of all interfaces facing
        Providers, create a set of prefixes originated by any ASN in AS-
        set Z(k_max).  Call it Prefix-set S2.

   14.  Form the union of Prefix-set S1 and Prefix-set S2 as Prefix-set
        S3.

   15.  For each unique Prefix P in Prefix-set S3, check origin ASNs of
        Prefix P and its sub prefixes by using all ROAs and in Adj-RIBs-
        In of all interfaces.  If all unique Prefixes in Prefix-set S3
        have been processed, go to Step 17.

   16.  For each prefix of Prefix P and its sub prefixes, if the prefix
        has at least one origin ASN not in AS-set Z(k_max), remove the
        prefix from Prefix-set S3.  Go to Step 15.

   17.  Apply Prefix-set S3 as a blocklist on interfaces facing a
        customer or lateral peer AS.

   By following the above procedure, AS4 in Figure 1 and Figure 2 can
   generate a blocklist on AS4-AS2 interface.  The blocklist contains
   prefixes that belong only to the provider cone of AS4 and does not
   contain prefixes P1 and P2.  If AS4 uses this blocklist SAV filter on
   the interface facing AS2, it will not improperly block data packets
   using source addresses in prefixes P1 and P2.  Meanwhile, it can
   accurately identify and block source-spoofed data packets using
   source addresses in the blocklist.  Therefore, this blocklist SAV
   filter can address the improper block problems of existing allowlist
   SAV filters, while maintaining directionality.











Li, et al.                Expires 2 April 2025                  [Page 8]

Internet-Draft                 Bicone SAV                 September 2024


5.3.  Incremental and Partial Deployment of ASPAs

   Note that it is difficult for an AS to identify all ASes in its
   provider cone when some ASes in the provider cone do not register
   ASPAs.  Therefore, the generated blocklist may not include all
   prefixes in the provider cone under incremental and partial
   deployment of ASPAs.  The main advantage of blocklist over allowlist
   is that, when the blocklist is incomplete, the blocklist will not
   improperly block legitimate data packets and will still block source-
   spoofed data packets using source addresses in the blocklist,
   providing immediate incremental benefits to adopters.

6.  A Challenging Scenario

   The Content Delivery Networks (CDN) and Direct Server Return (DSR)
   scenario is a challenging scenario for both allowlist-based SAV and
   blocklist-based SAV.  In Figure 3, AS6 announces the route for
   anycast prefix P3.  However, although AS1 does not announce the route
   for prefix P3 or register a ROA for prefix P3, it will send data
   packets using source addresses in prefix P3 due to the DSR
   technology.  If AS4 applies an allowlist on interface AS4-AS2, the
   allowlist will not contain prefix P3.  If AS4 applies a blocklist on
   interface AS4-AS2, the blocklist will contain prefix P3.  Therefore,
   both allowlist and blocklist on interface AS4-AS2 will improperly
   block data packets using source addresses in prefix P3.  One possible
   solution is that the network operator manually identifies the special
   purpose prefixes for anycast and DSR, and either removes them from
   the blocklist or adds them to the allowlist.























Li, et al.                Expires 2 April 2025                  [Page 9]

Internet-Draft                 Bicone SAV                 September 2024


       P3 (anycast prefix)
           +---------+
           |   AS6   |-Anycast Server
           +---------+
                |
        P3[AS6] |
        (P2C)   |
               \/
           +---------+ (P2P/P2C) +---------+
           |   AS4   +<----------+   AS5   |
           +---------+           +---------+
                /\                 /\
                /                  /
         (C2P) /                  / (C2P)
              /                  /
       +---------+       +---------+
       |   AS2   |       |   AS3   |
       +---------+       +---------+
             /\           /\
              \           /
         (C2P) \         / (C2P)
                \       /
               +---------+
               |   AS1   |-Edge Server
               +---------+
   (AS1 never announces the route for P3)

              Figure 3: An example of the CDN and DSR scenario

7.  Implementation and Operations Considerations

   Network operators are advised to flexibly use either allowlist or
   blocklist on interfaces facing different customer or lateral peer
   ASes according to their requirements and actual conditions.

7.1.  Meeting the Goals

   Avoiding improper blocks is more important because discarding
   legitimate traffic will cause serious traffic interruption.  On the
   basis of avoiding improper blocks, the less improper admits of SAV,
   the better.










Li, et al.                Expires 2 April 2025                 [Page 10]

Internet-Draft                 Bicone SAV                 September 2024


   If the allowlist on an interface is complete, it will have no
   improper block and no improper admit.  But if the allowlist is
   incomplete due to hidden prefixes (e.g., prefixes P1 and P2 in
   Figure 1) in the customer cone and lack of necessary ASPAs, the
   allowlist will have improper blocks, thus failing to meet the goal.
   For a blocklist, it will not improperly block legitimate data packets
   whether the blocklist is complete or not.

   Therefore, if the allowlist on an interface is complete, network
   operators are advised to use the allowlist.  Otherwise, network
   operators are advised to use the blocklist.  For small ISPs with a
   smaller customer cone size, it is easier to determine whether an
   allowlist is complete because there are fewer ASes in the customer
   cone and the routing should be relative simple.  For example, they
   can ask a customer or lateral peer AS whether all ASes in its
   customer cone have deployed ASPAs.  But for large ISPs with a larger
   customer cone size, it is more challenging.  If network operators
   cannot determine the integrity of the allowlist, the blocklist is
   recommended to avoid possible improper blocks.

7.2.  Storage Overhead

   Additional memory (i.e., ternary content-addressable memory (TCAM))
   is required to store the allowlist or blocklist in line cards.
   Network operators need to take storage overhead into consideration
   when deploying allowlists or blocklists.  Generally, a small ISP will
   generate a smaller allowlist and a larger blocklist, while a large
   ISP will generate a larger allowlist and a smaller blocklist.  A
   possible way to save memory is to store the original list in the
   control plane, with only the aggregated list stored in memory.  For
   example, if the original list contains prefixes P1 and P2 and prefix
   P1 is a less-specific prefix of prefix P2, then only prefix P1 is
   stored in memory.

7.3.  Implementation and Operations Recommendations

   For an interface facing a customer or lateral peer AS:

   1.  If the network operator can determine that the allowlist covers
       all prefixes of the facing customer cone, it is recommended to
       use an allowlist on the interface because the complete allowlist
       would have neither improper blocks nor improper admits.

   2.  If the network operator cannot determine the integrity of the
       allowlist, it is recommended to use a blocklist filter to avoid
       improper blocks.  It is highly recommended to use Loose uRPF and
       the blocklist together to block more spoofing data packets than
       solely using Loose uRPF or the blocklist.  Loose uRPF is used to



Li, et al.                Expires 2 April 2025                 [Page 11]

Internet-Draft                 Bicone SAV                 September 2024


       block data packets using unallocated or unrouteable source
       addresses.  The blocklist is used to block data packets using
       source addresses that only belong to the provider cone.

   Network operators are allowed to manually modify or configure the
   allowlist or the blocklist according to their local knowledge.  For
   example, to improve the use of blocklist, they can add special
   purpose prefixes that will not be used as source addresses of data
   packets or remove prefixes that would be used for anycast and DSR.
   This operation can also be achieved automatically if there is a
   public prefix list that contains the required prefixes, e.g., IANA
   IPv4 Special-Purpose Address Registry [IANA].

8.  Security Considerations

   The security considerations described in [RFC8704],
   [I-D.ietf-sidrops-bar-sav], [I-D.ietf-sidrops-aspa-profile],
   [RFC6482], and [I-D.ietf-sidrops-aspa-verification] also applies to
   this document.

9.  IANA Considerations

   This document has no IANA requirements.

10.  Acknowledgements

   The authors would like to thank Ben Maddison, Kotikalapudi Sriram,
   Nan Geng, Aijun Wang, Shengnan Yue, Siyuan Teng, Igor Lubashev, Job
   Snijders, and many other members of the SIDROPS and SAVNET working
   groups for comments and discussion.

11.  References

11.1.  Normative References

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

   [I-D.ietf-sidrops-aspa-profile]
              Azimov, A., Uskov, E., Bush, R., Snijders, J., Housley,
              R., and B. Maddison, "A Profile for Autonomous System
              Provider Authorization", Work in Progress, Internet-Draft,
              draft-ietf-sidrops-aspa-profile-18, 25 June 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
              aspa-profile-18>.




Li, et al.                Expires 2 April 2025                 [Page 12]

Internet-Draft                 Bicone SAV                 September 2024


   [RFC6482]  Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
              Origin Authorizations (ROAs)", RFC 6482,
              DOI 10.17487/RFC6482, February 2012,
              <https://www.rfc-editor.org/info/rfc6482>.

   [I-D.ietf-sidrops-aspa-verification]
              Azimov, A., Bogomazov, E., Bush, R., Patel, K., Snijders,
              J., and K. Sriram, "BGP AS_PATH Verification Based on
              Autonomous System Provider Authorization (ASPA) Objects",
              Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa-
              verification-19, 27 September 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
              aspa-verification-19>.

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

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

   [I-D.ietf-savnet-inter-domain-problem-statement]
              Li, D., Wu, J., Liu, L., Huang, M., and K. Sriram, "Source
              Address Validation in Inter-domain Networks Gap Analysis,
              Problem Statement, and Requirements", Work in Progress,
              Internet-Draft, draft-ietf-savnet-inter-domain-problem-
              statement-05, 8 September 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-savnet-
              inter-domain-problem-statement-05>.









Li, et al.                Expires 2 April 2025                 [Page 13]

Internet-Draft                 Bicone SAV                 September 2024


   [I-D.ietf-sidrops-bar-sav]
              Sriram, K., Lubashev, I., and D. Montgomery, "Source
              Address Validation Using BGP UPDATEs, ASPA, and ROA (BAR-
              SAV)", Work in Progress, Internet-Draft, draft-ietf-
              sidrops-bar-sav-04, 1 September 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
              bar-sav-04>.

   [RFC7908]  Sriram, K., Montgomery, D., McPherson, D., Osterweil, E.,
              and B. Dickson, "Problem Definition and Classification of
              BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June
              2016, <https://www.rfc-editor.org/info/rfc7908>.

   [IANA]     "IANA IPv4 Special-Purpose Address Registry", n.d.,
              <https://www.iana.org/assignments/iana-ipv4-special-
              registry/iana-ipv4-special-registry.xhtml>.

Authors' Addresses

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


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


   Li Chen
   Zhongguancun Laboratory
   Beijing
   China
   Email: lichen@zgclab.edu.cn


   Libin Liu
   Zhongguancun Laboratory
   Beijing
   China
   Email: liulb@zgclab.edu.cn






Li, et al.                Expires 2 April 2025                 [Page 14]