Skip to main content

BGP Extensions for Source Address Validation Networks (BGP SAVNET)
draft-geng-idr-bgp-savnet-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Nan Geng , Zhenbin Li , Zhen Tan , Mingxing Liu , Dan Li , Fang Gao
Last updated 2023-07-09 (Latest revision 2023-03-13)
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-geng-idr-bgp-savnet-01
IDR                                                              N. Geng
Internet-Draft                                                     Z. Li
Intended status: Standards Track                                  Z. Tan
Expires: 11 January 2024                                          M. Liu
                                                     Huawei Technologies
                                                                   D. Li
                                                     Tsinghua University
                                                                  F. Gao
                                                 Zhongguancun Laboratory
                                                            10 July 2023

   BGP Extensions for Source Address Validation Networks (BGP SAVNET)
                      draft-geng-idr-bgp-savnet-01

Abstract

   Many source address validation (SAV) mechanisms have been proposed
   for preventing source address spoofing.  However, existing SAV
   mechanisms are faced with the problems of inaccurate validation or
   high operational overhead in some cases.  This paper proposes BGP
   SAVNET by extending BGP protocol for SAV.  This protocol can
   propagate SAV-related information through BGP messages.  The
   propagated information will help routers automatically generate
   accurate SAV rules which are for checking the validity of data
   packets.

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

Copyright Notice

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

Geng, et al.             Expires 11 January 2024                [Page 1]
Internet-Draft          BGP Extensions for SAVNET              July 2023

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
     1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  BGP Protocol Relationship . . . . . . . . . . . . . . . . . .   4
   3.  BGP SAVNET Solution . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Application Scenarios and Goals . . . . . . . . . . . . .   5
     3.2.  SAV within an AS: Solution for Edge/Border Routers  . . .   6
     3.3.  SAV within an AS: Solution for Aggregation Routers  . . .  11
     3.4.  SAV between ASes: Solution for Border Routers . . . . . .  11
   4.  BGP SAVNET Peering Models . . . . . . . . . . . . . . . . . .  12
     4.1.  Full-mesh IBGP Peering  . . . . . . . . . . . . . . . . .  12
     4.2.  Singe-hop IBGP Peering between Directly Connected
           Routers . . . . . . . . . . . . . . . . . . . . . . . . .  12
     4.3.  EBGP Peering between ASes . . . . . . . . . . . . . . . .  12
   5.  BGP SAVNET Protocol Extension . . . . . . . . . . . . . . . .  13
     5.1.  BGP SAVNET SAFI . . . . . . . . . . . . . . . . . . . . .  13
     5.2.  BGP SAVNET NLRI . . . . . . . . . . . . . . . . . . . . .  13
       5.2.1.  SPA TLVs within an AS . . . . . . . . . . . . . . . .  13
       5.2.2.  SPA TLVs between ASes . . . . . . . . . . . . . . . .  15
     5.3.  BGP SAVNET Refresh  . . . . . . . . . . . . . . . . . . .  16
       5.3.1.  The SPD TLVs within an AS . . . . . . . . . . . . . .  16
       5.3.2.  The SPD TLVs between ASes . . . . . . . . . . . . . .  17
       5.3.3.  The SPD Optional Data Sub-TLVs  . . . . . . . . . . .  19
   6.  Decision Process with BGP SAVNET  . . . . . . . . . . . . . .  20
     6.1.  BGP SAVNET NLRI Selection . . . . . . . . . . . . . . . .  20
       6.1.1.  Self-Originated NLRI  . . . . . . . . . . . . . . . .  20
   7.  Error Handling  . . . . . . . . . . . . . . . . . . . . . . .  20
     7.1.  Process of BGP SAVNET NLRIs . . . . . . . . . . . . . . .  21
     7.2.  Process of BGP SAVNET SPA TLVs  . . . . . . . . . . . . .  21
     7.3.  Process of BGP SAVNET Refresh . . . . . . . . . . . . . .  21
     7.4.  Process of BGP SAVNET SPD TLVs  . . . . . . . . . . . . .  22
   8.  Management Considerations . . . . . . . . . . . . . . . . . .  22
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  22
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  23
   References  . . . . . . . . . . . . . . . . . . . . . . . . . . .  23
     Normative References  . . . . . . . . . . . . . . . . . . . . .  23

Geng, et al.             Expires 11 January 2024                [Page 2]
Internet-Draft          BGP Extensions for SAVNET              July 2023

     Informative References  . . . . . . . . . . . . . . . . . . . .  23
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24

1.  Introduction

   Source address validation (SAV) is essential for preventing source
   address spoofing attacks (e.g., DDoS based on source address spoofing
   [RFC6959]) and tracing back network attackers.  For a network, SAV
   mechanisms can be deployed on edge routers or aggregation routers for
   validating the packets from the connected subnets or neighboring ASes
   [manrs-antispoofing].

   ACL-based ingress filtering can be used for SAV, which, however, has
   high operational overhead problems in dynamic networks [I-D.ietf-savn
   et-intra-domain-problem-statement][I-D.wu-savnet-inter-domain-problem
   -statement] and also has limited capacity of rules.  Many SAV
   mechanisms, such as strict uRPF, loose uRPF, and EFP-uRPF
   [RFC3704][RFC8704], leverage routing information to automatically
   generate SAV rules.  The rules indicate the wanted incoming
   directions of source addresses.  The packets with specified source
   addresses but from unwanted directions will be considered invalid
   [I-D.huang-savnet-sav-table].  However, there may be inaccurate
   validation problems under asymmetric routing [I-D.ietf-savnet-intra-d
   omain-problem-statement][I-D.wu-savnet-inter-domain-problem-statement
   ].  This is because these uRPF mechanisms are "single-point" designs.
   They leverage the local FIB or local RIB table to determine the
   incoming interfaces for source addresses, which may not match the
   real incoming directions.  That is, purely relying on the original
   IGP or BGP protocols to obtain routing information for SAV rule
   generation cannot well meet the requirement of accurate validation.

   This document proposes an extension of BGP protocol for SAV, i.e.,
   BGP SAVNET.  Unlike existing "single-point" mechanisms, BGP SAVNET
   allows coordination between the routers within the network or the
   ASes outside the network by propagating SAV-related information
   through extended BGP messages.  The propagated information can
   provide more accurate source address information and incoming
   direction information than the local FIB and RIB tables.  The routers
   with BGP SAVNET can automatically generate accurate SAV rules with
   reduced operational overhead.

   The BGP SAVNET protocol is suitable to generating SAV rules for both
   IPv4 and IPv6 addresses.  The SAV rules can be used for validating
   any native IP packets or IP-encapsulated packets.

Geng, et al.             Expires 11 January 2024                [Page 3]
Internet-Draft          BGP Extensions for SAVNET              July 2023

1.1.  Terminology

   SAV: Source address validation, an approach to preventing source
   address spoofing.

   SAV Rule: The rule that indicates the valid incoming interfaces for a
   specific source prefix.

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

   SPA: Source prefix advertisement, i.e., the process for advertising
   the origin source addresses/prefixes of a router or an AS.

   SPD: Source path discovery, i.e., the process for discovering the
   real incoming directions of particular source addresses/prefixes.

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.  BGP Protocol Relationship

   The BGP extensions for BGP SAVNET follow a backward compatible manner
   without impacting existing BGP functions.  New BGP SAVNET subsequent
   address families will be introduced under the IPv4 address family and
   the IPv6 address family, respectively.  The BGP UPDATE message
   (specifically the MP_REACH_NLRI and the MP_UNREACH_NLRI attributes)
   and the BGP Refresh message will be extended.  AFI and SAFI can be
   used for distinguishing the BGP SAVNET messages from other messages.

   A few existing path attributes such as Originator_ID and Clister_list
   or new defined path attributes MAY be used for BGP SAVNET.  Actually,
   most existing path attributes are not necessarily required for BGP
   SAVNET.  However, if the unnecessary path attributes are carried in
   BGP updates, they will be accepted, validated, and propagated
   consistent with the BGP protocol.

3.  BGP SAVNET Solution

Geng, et al.             Expires 11 January 2024                [Page 4]
Internet-Draft          BGP Extensions for SAVNET              July 2023

3.1.  Application Scenarios and Goals

   BGP SAVNET aims to generate accurate SAV rules for most use cases
   including asymmetric routing.  An SAV rule indicates the valid
   incoming interfaces for a specific source address/prefix.  A router
   with BGP SVANET will locally maintain a SAV table storing the SAV
   rules.  The SAV table can be used for validating data packets.

   Figure 1 shows the application scenarios where BGP SAVNET will enable
   SAV in data plane.  There are generally two kinds of scenarios: SAV
   within an AS and SAV between ASes.  SAV within an AS can prevent
   local customer networks (subnets or stub ASes) from generating source
   address spoofed packets and block external packets with internal
   source addresses.  SAV rules are generated without any cooperations
   or interactions (such as prefix advertisements) between the local AS
   and subnets/other ASes.  In contrast, SAV between ASes aims to
   checking the external packets spoofing other ASes' source addresses.
   Cooperations or interactions between the local AS and other ASes are
   required.

   *  SAV within an AS

      -  Edge/Border routers: SAV can be deployed at '*' or '#' for
         checking the validity of the packets from customer networks and
         Internet.

      -  Aggregation routers: Aggregation routers can do validation at
         'x' for any arrival packets.

   *  SAV between ASes

      -  Border routers connecting other ASes: SAV can be deployed at
         '#' for checking the validity of the packets from other ASes.

Geng, et al.             Expires 11 January 2024                [Page 5]
Internet-Draft          BGP Extensions for SAVNET              July 2023

           +-----+           +-----+
           | AS1 |           | AS2 |
           +-----+           +-----+
                \             /
   +-------------\-----------/-------------+
   | AS3        +-#--+   +--#-+            |
   |            | R7 |---| R8 |            |
   |            +----+   +----+            |
   |              |         |              |
   |            +-x--+   +--x-+            |
   |      ------x R5 x---x R6 x------      |
   |      |     +-x--+   +--x-+     |      |
   |      |       |         |       |      |
   |   +----+   +----+   +----+   +----+   |
   |   | R1 |   | R2 |---| R3 |   | R4 |   |
   |   +--*-+   +-*--+   +--#-+   +-#--+   |
   +-------\-----/-----------\-----/-------+
          +-------+          +-----+
          |Subnet1|          | AS4 |
          +-------+          +-----+

                 Figure 1: BGP SAVNET application scenarios

3.2.  SAV within an AS: Solution for Edge/Border Routers

   Figure 2 shows a comprehensive example of application scenarios which
   includes different kinds of external interfaces.  On the edge routers
   that connect to customers, BGP SAVNET can be enabled at access
   interfaces for validating outbound packets from subnets or stub ASes.
   On the border router, BGP SAVENT also can be applied at the external
   interfaces for validating the inbound packets from the Internet.

Geng, et al.             Expires 11 January 2024                [Page 6]
Internet-Draft          BGP Extensions for SAVNET              July 2023

   +-----------------------------------------+
   |               Internet                  |
   +-----------------------------------------+
                 |      |                |
                 |      |                |
   +-------------+------+----------------+---+
   | AS          |      |                |   |
   |       Intf.6|      |Intf.7          |   |
   |           ┌─*──────*─┐              |   |
   |           │ Router 3 │              |   |
   |           └──────────┘              |   |
   |              /     \                |   |
   |             /       \               |   |
   |            /         \              |   |
   |   ┌──────────┐     ┌──────────┐     |   |
   |   │ Router 1 │     │ Router 2 │     |   |
   |   └──#─────#─┘     └─#──#──*──┘     |   |
   |intf.1|intf.2\ intf.3/   |   \Intf.5 |   |
   |      |       \     /  Intf.4 \      |   |
   |      |        \   /     |     \     |   |
   |   Subnet1    Subnet2    |      Subnet3  |
   |                         |               |
   +-------------------------+---------------+
                             |
                             |
                      +-------------+
                      |   Stub AS   |
                      +-------------+

   intf '#': Mode "Interface-based prefix allowlist"
   intf '*': Mode "Interface-based prefix blocklist"

                 Figure 2: BGP SAVNET application scenarios

   In general, there are four types of external interface:

   *  Single-homing interface.  When a customer network has only one
      uplink connects to the upper-layer network, the connected
      interface at the edge of upper-layer network can be defined as a
      "Sigle-homing interface", which corresponds to Intf.1 and Intf.4
      in Figure 2.

   *  Complete Multi-homing interface.  When a customer network has dual
      or multiple uplinks that connect to a single upper-layer network
      with BGP SAVNET deployed, the connected interfaces at the edge
      router of upper-layer network are called "Complete Multi-homing
      interface", which corresponds to Intf.2 and Intf.3 in Figure 2.

Geng, et al.             Expires 11 January 2024                [Page 7]
Internet-Draft          BGP Extensions for SAVNET              July 2023

   *  Incomplete multi-homing interface. when a customer network has
      dual or multiple uplinks, all of which are not connected to a
      single upper-layer network, the interfaces at the edge of upper-
      layer network are called the "Incomplete Multi-homing interface",
      which corresponds to Intf.5 in Figure 2.  Specifically, Incomplete
      Multi-home interface exists in circumstances where source prefixes
      cannot be fully acknowledged, such as when only a portion of
      interfaces in upper-layer AS is BGP SAVNET enabled, or these
      interfaces belong to different upper-layer ASes.

   *  Internet interface.  It's the external interfaces that connected
      to the Internet on border routers.  Typically, a network contains
      multiple internet interfaces for load balancing, which corresponds
      to Intf.6 and Intf.7 as shown in Figure 2.

   In order to perform accurate validation on different types of
   external interface, two typical modes are provided: "Interface-based
   prefix allowlist" and "Interface-based prefix blocklist"
   [I-D.huang-savnet-sav-table].  For interfaces that can learn all its
   legitimate source prefixes, the" Interface-based prefix allowlist"
   mode is recommended.  For interfaces that cannot learn all its
   legitimate source prefixes, but in turns know the source prefixes
   that are surely not allowed, the "Interface-based prefix blocklist"
   mode is suitable.

   For the first two type of interfaces in the example scenario shown in
   Figure 2, which are defined as "Single-homing interface" and
   "Complete Multi-homing interface", the "Interface-based prefix
   allowlist" mode is suitable.  In this case, the allowlist should
   contain all source prefixes of the connected subnets or stub ASes.
   The key challenge to fulfill a complete list is to solve asymmetric
   routing problem in multi-homing scenarios, and the legacy uRPF
   approach is not sufficient.

   For the last two types of interfaces in the example scenario, which
   are defined as "Incomplete multi-homing interface" and "Internet
   interface", the "Interface-based prefix blocklist" mode is suitable.
   For a specific interface, its blocklist could contain the prefixes
   that are learned from other interfaces, such as "Single-homing
   interface" or "Complete Multi-homing interface".  The key challenge
   in this case is how to maintain the source prefixes blocklist
   dynamically and efficiently.

Geng, et al.             Expires 11 January 2024                [Page 8]
Internet-Draft          BGP Extensions for SAVNET              July 2023

   To address these two challenges mentioned above, BGP SAVNET is
   introduced in this document.  The primary idea is to allow routers to
   advertise SAV-related information on the control plane, thus
   automatically generate accurate SAV rules on the data plane.  The
   information advertised by BGP SAVNET requires to be concise and
   efficient.

   The main goal is to generate source prefixes allowlist/blocklist on
   border routers or edge routers.  The corresponding solution consists
   of one major process, which is named Source Prefix Advertisement
   (SPA).  During the SPA procedure, the router will advertise its local
   source prefixes information with the MIIG-type, MIIG-tag, and Prefix
   attributes:

   *  BGP SAVNET defines the Multi-homing Interface Group Type (MIIG-
      Type) to indicate the exact type of each external interface, which
      should be one of the four types mentioned above.  MIIG-type
      determines the local validation mode of the interface (i.e.,
      interface-based prefix allowlist/blocklist), and also assists
      remote peer route in generating prefixes allowlist/blocklist.

   *  BGP SAVNET defines the Multi-homing Interface Group Tag (MIIG-Tag)
      to identify customers.  It is an identifier that represents a
      customer subnet, a lower-layer stub AS or the internet.  In the
      design, different customer subnets/stub ASes use different MIIG-
      tag values, while the internet usually takes the same MIIG-tag
      value.

   *  In BGP SAVENT, the MIIG-Type and MIIT-Tag work together to
      generate source prefixes list on remote peer routers.  On the
      remote router, source prefixes in SPA message that take the same
      MIIG-Type and same MIIT-Tag value as one of its local interfaces,
      will be recognized as legitimate prefixes of that interface.

   *  BGP SAVNET also defines the "Prefix attribute" to indicate the
      "Source" and "Dest" type of a prefix.  "Source" attribute
      represents whether all origin interfaces of the prefix are known
      and learned.  "Dest" attribute indicates whether route for this
      prefix exists in local RIB of this SPA advertising router.
      "Prefix Attribute" values are determined by the "MIIT-Type" of the
      prefixes in typical cases.  For example, prefixes belonging to
      "Single-homing interface" and "Complete Multi-homing interface"
      will take both "Source" type value and "Dest" type value, while
      prefixes of "Incomplete multi-homing interface" and "Internet
      interface" are only assigned "Dest" type value.  However, in same
      special cases, the prefix attribute value needs to be specified.
      For example, in the direct server return (DSR) scenario
      [I-D.wu-savnet-inter-domain-problem-statement], the hidden prefix

Geng, et al.             Expires 11 January 2024                [Page 9]
Internet-Draft          BGP Extensions for SAVNET              July 2023

      should be a "Source" type prefix but not a "Dest" type prefix, as
      it's not a reachable prefix in local routing table.  Normally, the
      "Prefix attribute" value is set manually in this special hidden
      prefix scenario.

   Routers will announce the source prefixes within the above attribute
   values via SPA messages.  In "Single-homing interface" and "Complete
   Multi-homing interface" scenarios, the router should advertise all
   prefixes of this interface.  In the other scenarios, the prefixes
   could be determined to be published or not on the local router.

   Routers with "Single-homing interface" or "Complete Multi-homing
   interface" will generate "Interface-based prefix allowlist", and the
   building approach of the allowlist is different in these two
   scenarios.  In the case of "Single-homing interface", the allowlist
   can be generated only through local routing information (local RIB),
   without the engagement of SPA message.  The method building the
   allowlist is, each Dest Prefix in RIB that records this interface as
   an outgoing interface will be added to the" Interface-based prefix
   allowlist".  In the case of "Complete Multi-homing interface", in
   addition to collecting prefixes of the interface itself in local RIB,
   routers also need merge prefixes from received SPA message or other
   local interfaces into allowlist to construct a complete list.  First,
   the prefixes in received SPA, which take the same "MIIG-Type" and
   "MIIG-Tag" values as the local interface, are added to the allowlist.
   Second, if there are multiple interfaces having the same "MIIG-Type"
   and "MIIG-Tag" values, they will share prefixes collected from local
   RIB into each other’s allowlist.

   Routers with "Incomplete Multi-homing interface" or "Internet
   interface" will generate "Interface-based prefix blocklist" for the
   interface.  Generally, the interface-based blocklist contains
   prefixes that surely not enter this interface.  To construct the
   blocklist, there are three types of situations need to be taken into
   consideration separately.  First, the local prefixes of other
   "Single-homing interface" or "Complete Multi-homing interface" on the
   same router could be recorded into the blocklist.  Second, the
   prefixes in received SPA message, which belongs to the remote
   "Single-homing interface" or "Complete Multi-homing interface", also
   could be added into the blocklist.  Third, the prefixes from any
   scenario taking the "source" type attribute which may be manually
   configured or set by RTBH, also can be added into the blocklist, even
   if the prefixes belong to the "Incomplete Multi-homing interface" or
   "Internet interface".

Geng, et al.             Expires 11 January 2024               [Page 10]
Internet-Draft          BGP Extensions for SAVNET              July 2023

3.3.  SAV within an AS: Solution for Aggregation Routers

   The solution consists of two main processes: SPA and Source Path
   Discovery (SPD).  Edge routers can generate SAV rules through SPA on
   the interfaces connecting subnets.  SPA and SPD can help aggregation
   routers generate SAV rules on the interfaces connecting other
   routers.

   Aggregation routers are to generate SAV rules for checking the
   validity of recorded source prefixes and ignore the validation of
   unrecorded source prefixes.  Each edge router can first send SPA
   messages for propagating its router-id and its source prefixes that
   need to be validated.  Aggregation routers will record the mapping
   from router-id to source prefixes.  Then, each edge router will send
   an SPD messages to each neighbor router.  The message carries the
   source router-id of the edge router and the destination router-ids
   whose mapped source prefixes take the neighbor router as the next
   forwarding hop.  The neighbor router (e.g., aggregation router)
   receiving the message will record the incoming interface of the
   message, and SAV rules will be generated locally by binding the
   source router-id's source prefixes to the recorded incoming
   interface.  Then neighbor router will remove its own router-id from
   the destination router-id list and relay the message to its neighbors
   according to local forwarding rules.  The routers receiving the
   message will repeat the above process until the destination router-id
   list is empty.  More details can be found in the version-00 of
   [I-D.li-savnet-intra-domain-architecture].

3.4.  SAV between ASes: Solution for Border Routers

   The solution consists of two main processes: SPA and SPD.  Border
   routers can generate SAV rules at interfaces connecting to other ASes
   through SPA and SPD.

   Let AS X be the local AS which acts as a validation AS and generates
   SAV rules for other ASes.  Let AS Y be one of the ASes deploying BGP
   SAVNET, which is named as source AS.  Validation AS X will generate
   SAV rules for protecting the source prefixes of source AS Y.

   AS Y first advertise its own AS number and its own source prefixes to
   AS X through SPA messages.  SPA is necessary because AS Y cannot
   learn the complete set of source prefixes of AS Y purely through BGP
   updates.  Some hidden source prefixes that do not appear can be
   advertised to AS X through SPA messages.

Geng, et al.             Expires 11 January 2024               [Page 11]
Internet-Draft          BGP Extensions for SAVNET              July 2023

   After SPA, AS Y can send SPD messages for notifying its preferred AS
   paths from AS Y to AS X.  AS X will learn the incoming direction of
   AS Y's packets.  Then, SAV rules can be generated.  SPD can help AS X
   for discovering the real forwarding paths that do not match the
   control plane paths learned by AS X.

   Note that, the SAV solutions either within an AS or between ASes are
   under working on.  The BGP SAVNET will be updated if the solutions
   are revised.

4.  BGP SAVNET Peering Models

   Several BGP SAVNET solutions are introduced that can be applied in
   different scenarios.  Depending on the solution's feature, different
   peering models need to be taken.

4.1.  Full-mesh IBGP Peering

   This peering model is required by the SAV solution within an AS so
   that the edge/border routers can generate SAV rules.  In this model,
   routers enabling BGP SAVNET MUST establish full-mesh iBGP sessions
   either through direct iBGP sessions or route-reflector.  The BGP
   SAVNET sessions can be established only when the BGP SAVNET address
   family has been successfully negotiated.  SPA messages within an AS
   can be advertised through the full-mesh BGP SAVNET sessions.  The
   extensions of BGP messages for carrying SPA messages will be
   introduced in Section 5.

4.2.  Singe-hop IBGP Peering between Directly Connected Routers

   This peering model meets the requirement of the SAV solution within
   an AS so that the aggregation routers can generate SAV rules.  In
   this model, routers enabling BGP SAVNET MUST establish single-hop
   iBGP sessions through direct point-to-point links.  For each link, a
   single-hop iBGP session needs to be established, and the messages
   transmitted over the session MUST be carried by the corresponding
   link.  SPD messages within an AS can be advertised through these
   sessions.  The extensions of BGP messages for carrying SPD messages
   will be introduced in Section 5.

4.3.  EBGP Peering between ASes

   The SAV solution between ASes requires eBGP sessions which can be
   single-hop or multi-hop.  In this model, for the AS enabling BGP
   SAVNET, at least one border router in the AS MUST establish the BGP
   SAVNET sessions with other border routers in the neighboring or
   remote ASes.  SPA and SPD messages between ASes will be advertised
   through these sessions.  The extensions of BGP messages for carrying

Geng, et al.             Expires 11 January 2024               [Page 12]
Internet-Draft          BGP Extensions for SAVNET              July 2023

   SPA and SPD messages will be introduced in Section 5.

5.  BGP SAVNET Protocol Extension

5.1.  BGP SAVNET SAFI

   In order to transmitting and exchanging data needed to generate an
   independent SAV table, the document introduces the BGP SAVNET SAFI.
   The value is TBD and requires IANA registration as specified in
   Section 9.  In order for two BGP SAVNET speakers to exchange BGP
   SAVNET NLRI (SPA message), they MUST establish a BGP SAVNET peer and
   MUST exchange the Multiprotocol Extensions Capability [RFC5492] to
   ensure that they are both capable of processing such NLRI properly.
   Two BGP SAVNET speakers MUST exchange Route Refresh Capability
   [RFC2918] to ensure that they are both capable of processing the SPD
   message carried in the BGP Refresh message.

5.2.  BGP SAVNET NLRI

   The BGP SAVNET NLRI is used to transmit Source Prefix (either IPv4 or
   IPv6) information to form a uniform Source Prefix list within a
   deployment domain.

   The BGP SAVNET NLRI TLVs are carried in BGP UPDATE messages as (1)
   route advertisement carried within Multiprotocol Reachable NLRI
   (MP_REACH_NLRI) [RFC4760], and (2) route withdraw carried within
   Multiprotocol Unreachable NLRI (MP_UNREACH_NLRI).

   While encoding an MP_REACH_NLRI attribute containing BGP SAVNET NLRI
   TLVs, the "Length of Next Hop Network Address" field SHOULD be set to
   0 upon the sender.  The "Network Address of Next Hop" field should
   not be encoded upon the sender, because it has a 0 length and MUST be
   ignored upon the receiver.

5.2.1.  SPA TLVs within an AS

   The BGP SAVNET NLRI TLV each carries a Source Prefix and related
   information, therefore it is called an SPA TLV.  This type of TLVs
   are used in SPA process within an AS.  The format is shown below:

Geng, et al.             Expires 11 January 2024               [Page 13]
Internet-Draft          BGP Extensions for SAVNET              July 2023

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | RouteType (1) |   Length (1)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Origin router-id (4)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  MaskLen (1)  |        IP Prefix (variable)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | MIIG-Type (1) | Flags (1) |D|S|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         MIIG-Tag (32)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 3: SPA TLV format

   The meaning of these fields are as follows:

   *  RouteType(key): Type of the BGP SAVNET NLRI TLV, the value is 1
      for SPA TLV within an AS.

   *  Length: The length of the BGP SAVNET NLRI value, the RouteType and
      Length fields are excluded.

   *  Origin router-id(key): The router ID of the originating node of
      the source prefix in the deployment domain.

   *  MaskLen(key): The mask length in bits, which also indicates the
      valid bits of the IP Prefix field.

   *  IP Prefix(key): IP address.  The length ranges from 1 to 4 bytes
      for IPv4 and ranges from 1 to 16 bytes for IPv6.  Format is
      consistent with BGP IPv4/IPv6 unicast address.

   *  MIIG-Type(non-key): Multi-homing Ingress Interface Group type, see
      Section 5.2.1.1 for details.

   *  Flags(non-key): Bitmap, indicating the attribute flag of the SPA
      prefix, currently taken:

      -  bit 0(S bit) : source flag, indicates that the SPA prefix can
         be used as a source prefix.

      -  bit 1(D bit) : dest flag, indicates that the SPA prefix can be
         used as a destination prefix.

Geng, et al.             Expires 11 January 2024               [Page 14]
Internet-Draft          BGP Extensions for SAVNET              July 2023

   *  MIIG-Tag(non-key): Multi-homing Ingress Interface Group Tag. The
      value ranges from 1 to 0xFFFFFFFF.  The value 0 is invalid and the
      value 0xFFFFFFFF is reserved.

5.2.1.1.  Multi-homing Ingress Interface Group Type

   *  Type value 0: Unknown.  Indicates that this prefix does not come
      from any subnets.  It can be a local prefix or a local domain
      prefix.

   *  Type value 1: Single-homed.  Indicates that this prefix comes from
      a subnet that is single-homed to the local domain.

   *  Type value 2: Complete-multi-homed.  Indicates that this prefix
      comes from a subnet that is multi-homed to the local domain, and
      is connected only to the local domain.

   *  Type value 3: Incomplete-multi-homed.  Indicates that this prefix
      comes from a subnet that is multi-homed to the local domain and
      and other domains.

   *  Type value 4: Internet-Ingress.  Indicates that this prefix comes
      from a interface that is connected to the Internet.

   *  Type value 5~255: Reserved for future use.

5.2.2.  SPA TLVs between ASes

   This type of TLVs are used in SPA process between ASes.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | RouteType (1) |   Length (1)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Source AS Number (4)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  MaskLen (1)  |        IP Prefix (variable)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Flags (1)    |
   +-+-+-+-+-+-+-+-+

                          Figure 4: SPA TLV format

   The meaning of these fields are as follows:

   *  RouteType(key): Type of the BGP SAVNET NLRI TLV, the value is 2
      for SPA TLV between ASes.

Geng, et al.             Expires 11 January 2024               [Page 15]
Internet-Draft          BGP Extensions for SAVNET              July 2023

   *  Length: The length of the BGP SAVNET NLRI value, the RouteType and
      Length fields are excluded.

   *  Source AS Number(key): The AS number of the originating AS of this
      advertised source prefix.

   *  MaskLen(key): The mask length in bits, which also indicates the
      valid bits of the IP Prefix field.

   *  IP Prefix(key): IP address.  The length ranges from 1 to 4 bytes
      for IPv4 and ranges from 1 to 16 bytes for IPv6.  Format is
      consistent with BGP IPv4/IPv6 unicast address.

   *  Flags(non-key): Reserved for future use.

5.3.  BGP SAVNET Refresh

   The SPD TLV is carried in a BGP Refresh message after the BGP Refresh
   message body, as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              AFI (2)          |  Reserved (1) |     SAFI (1)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       SPD TLV (variable)                      |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 5: BGP-REFRESH with SPD TLV format

   By carrying an SPD TLV, a BGP SAVNET Refresh message MUST NOT be
   processed as a Route-Refresh (as a re-advertisement request) and
   SHOULD only be used in the SPD process.  A BGP SAVNET Refresh message
   without an SPD TLV SHOULD be processed as a Route-Refresh as defined
   in Route Refresh Capability [RFC2918].

5.3.1.  The SPD TLVs within an AS

   The SPD TLV carries the information that the Source Path Discovery
   process needed.  This type of TLVs are used in SPD process within an
   AS.  The format is shown below:

Geng, et al.             Expires 11 January 2024               [Page 16]
Internet-Draft          BGP Extensions for SAVNET              July 2023

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type (1)   |   SubType (1)  |            Length (2)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number (4)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Origin router-id (4)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Optional Data Length (2)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Optional Data (variable)               |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Dest List (variable)                 |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 6: SPD TLV format

   The meaning of these fields are as follows:

   *  Type: TLV Type, the value is 2 for SPD TLV.

   *  SubType: TLV Sub-Type, value is 1 for SPD TLV within an AS.

   *  Length: The length of the SPD TLV value, the Type, SubType and
      Length fields are excluded.

   *  Sequence Number: Indicates the sequence of Source Path Discovery
      process.  The initial value is 0 and the value increases
      monotonically.

   *  Origin router-id: The router ID of the originating node of the
      Source Path Discovery process.

   *  Optional Data Length: The length of the optional data field in
      bytes.  The value can be 0 when there is no optional data.

   *  Optional Data: In Sub-TLV format, see Section 5.3.3 for details.

   *  Dest List: List of destination router-ids, using 4-bytes route-id,
      indicates the destinations of this Source Path Discovery process.

5.3.2.  The SPD TLVs between ASes

   This type of TLVs are used in SPD process between ASes.

Geng, et al.             Expires 11 January 2024               [Page 17]
Internet-Draft          BGP Extensions for SAVNET              July 2023

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type (1)   |   SubType (1)  |            Length (2)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number (4)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Origin router-id (4)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Source AS Number (4)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Validation AS Number (4)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Optional Data Length (2)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Optional Data (variable)               |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Neighbor AS Number List (variable)        |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 7: SPD TLV format

   The meaning of these fields are as follows:

   *  Type: TLV Type, the value is 2 for SPD TLV.

   *  SubType: TLV Sub-Type, value is 2 for SPD TLV between an AS.

   *  Length: The length of the SPD TLV value, the Type, SubType and
      Length fields are excluded.

   *  Sequence Number: Indicates the sequence of Source Path Discovery
      process.  The initial value is 0 and the value increases
      monotonically.

   *  Origin router-id: The router ID of the originating node of the
      Source Path Discovery process.

   *  Source AS Number(key): The AS number of the source AS whose source
      prefixes need to be validated in the validation AS.

   *  Validation AS Number(key): The AS number of the validation AS who
      conducts validation for the source prefixes of source AS.

   *  Optional Data Length: The length of the optional data field in
      bytes.  The value can be 0 when there is no optional data.

Geng, et al.             Expires 11 January 2024               [Page 18]
Internet-Draft          BGP Extensions for SAVNET              July 2023

   *  Optional Data: In Sub-TLV format, see Section 5.3.3 for details.

   *  Neighbor AS Number List: List of neighbor AS, from which the
      validation AS will receive the data packets with the source
      prefixes of the source AS.

5.3.3.  The SPD Optional Data Sub-TLVs

   Information in the Optional Data field of the SPD TLV is encoded in
   Sub-TLV format.  The format is shown below and applies to all types
   of Sub-TLVs.  Each type of Sub-TLV SHOULD appear no more than once in
   an SPD TLV.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type (2)   |             Length (2)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         values (variable)                     |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 8: SPD Optional Data Sub-TLV format

   The meaning of these fields are as follows:

   *  Type: Sub-TLV Type.  The value 1 and 2 have been taken.  The
      sequence of values is TBD and requires IANA registration as
      specified in Section 9.

   *  Length: The length of the Sub-TLV value, the Type and Length
      fields are excluded.

5.3.3.1.  Sub-TLV Type 1: Origin Router-id List

   List of agent original router-ids, using 4-bytes route-id.  This
   information is used in the SPD convergence process and can carry a
   maximum of 254 router-ids.

5.3.3.2.  Sub-TLV Type 2: Path Router-id List

   List of path router-ids, using 4-bytes route-id, record all the
   router-id of the routers that the SPD process has passed through.
   This information is used to prevent loops and can carry a maximum of
   254 router-ids.

   Currently, the above two sub-TLVs are only used in SAV within an AS.

Geng, et al.             Expires 11 January 2024               [Page 19]
Internet-Draft          BGP Extensions for SAVNET              July 2023

6.  Decision Process with BGP SAVNET

   The Decision Process described in [RFC4271] works to determines a
   degree of preference among routes with the same prefix.  The Decision
   Process involves many BGP Path attributes, which are not necessary
   for BGP SAVNET SPA and SPD process, such as next-hop attributes and
   IGP-metric attributes.  Therefore, this document introduces a
   simplified Decision Process for SAVNET SAFI.

   The purpose of SPA is to maintain a uniform Source Prefix list, which
   is the mapping from original router-id to IP addresses, across all
   routers in the deploy domain.  To ensure this, it is RECOMMENDED that
   all routers deploy no ingress or egress route-policies.

6.1.  BGP SAVNET NLRI Selection

   The Decision Process described in [RFC4271] no longer apply, and the
   Decision Process for BGP SAVNET NLRI are as follows:

   1.  The locally imported route is preferred over the route received
       from a peer.

   2.  The route received from a peer with the numerically larger
       originator is preferred.

   3.  The route received from a peer with the numerically larger Peer
       IP Address is preferred.

6.1.1.  Self-Originated NLRI

   BGP SAVNET NLRI with origin router-id matching the local router-id is
   considered self-originated.  All locally imported routes should be
   considered self-originated by default.

   Since the origin router-id is part of the NLRI key, it is very
   unlikely that a self-originated NLRI would be received from a peer.
   Unless a router-id conflict occurs due to incorrect configuration.
   In this case, the self-originated NLRI MUST be discarded upon the
   receiver, and appropriate error logging is RECOMMENDED.

   On the other hand, besides the route learn from peers, a BGP SAVNET
   speaker MUST NOT advertise NLRI which is not self-originated.

7.  Error Handling

Geng, et al.             Expires 11 January 2024               [Page 20]
Internet-Draft          BGP Extensions for SAVNET              July 2023

7.1.  Process of BGP SAVNET NLRIs

   When a BGP SAVNET speaker receives a BGP Update containing a
   malformed MP_REACH_NLRI or MP_UNREACH_NLRI, it MUST ignore the
   received TLV and MUST NOT pass it to other BGP peers.  When
   discarding a malformed TLV, a BGP SAVNET speaker MAY log a specific
   error.

   If duplicate NLRIs exist in a MP_REACH_NLRI or MP_UNREACH_NLRI
   attribute, only the last one SHOULD be used.

7.2.  Process of BGP SAVNET SPA TLVs

   When a BGP SAVNET speaker receives an SPA TLV with an undefined type,
   it MUST be considered malformed.

   When a BGP SAVNET speaker receives an SPA TLV with a 0 origin router-
   id, or the origin router-id is the same as the local router-id, it
   MUST be considered malformed.

   When a BGP SAVNET speaker receives an SPA TLV with an invalid MaskLen
   field, which is out of the range 1~32 for IPv4 and 1~128 for IPv6, it
   MUST be considered malformed.

   When a BGP SAVNET speaker receives an SPA TLV with an address field,
   whose length in bytes do not match with the remaining data, it MUST
   be considered malformed.

   When a BGP SAVNET speaker receives an SPA TLV with an unsupported
   miig-type, it MUST be considered malformed.

   When a BGP SAVNET speaker receives an SPA TLV with a miig-type
   0(Unkonwn), its miig-tag must also be 0, vice versa.  Otherwise this
   SPA TLV MUST be considered malformed.

   When a BGP SAVNET speaker receives a malformed SPA TLV, it MUST
   ignore the received TLV and MUST NOT pass it to other BGP peers.
   When discarding a malformed TLV, a BGP SAVNET speaker MAY log a
   specific error.

   When a BGP SAVNET speaker processes Flags in an SPA TLV, the defined
   bits MUST be processed and the undefined bits MUST be ignored.

7.3.  Process of BGP SAVNET Refresh

   Each BGP Refresh message MUST contain at most one SPD TLV.  When a
   BGP SAVNET speaker receives a BGP Refresh packet with multiple SPD
   TLVs, only the first one SHOULD be processed.

Geng, et al.             Expires 11 January 2024               [Page 21]
Internet-Draft          BGP Extensions for SAVNET              July 2023

7.4.  Process of BGP SAVNET SPD TLVs

   When a BGP SAVNET speaker receives an SPD TLV with an undefined type
   or subtype, it MUST be considered malformed.

   When a BGP SAVNET speaker receives an SPD TLV with a 0 origin router-
   id, or the origin router-id is the same as the local router-id, it
   MUST be considered malformed.

   When a BGP SAVNET speaker receives an SPD TLV with a 0 source AS
   number or validation AS number, or the source AS number equals the
   validation AS number, it MUST be considered malformed.

   When a BGP SAVNET speaker receives an SPD TLV with an optional data
   sub-TLV that is an undefined type, it MUST be considered malformed.

   When a BGP SAVNET speaker receives an SPD TLV with a DestList field
   that is not a multiple of 4 in length, it MUST be considered
   malformed.

   When a BGP SAVNET speaker receives a Refresh message with a malformed
   SPD TLV, it MUST ignore the received message.  When discarding a
   malformed message, a BGP SAVNET speaker MAY log a specific error.

   When a BGP SAVNET speaker receives an SPD TLV with a sequence number
   that does not match the local recorded sequence number:

   *  If the newly received sequence number is numerically larger, the
      local recorded sequence number SHOULD be updated to the newly
      received sequence number.

   *  If the newly received sequence number is numerically smaller, the
      local recorded sequence number SHOULD NOT be updated, and the BGP
      SAVNET speaker SHOULD log a specific error.

8.  Management Considerations

   TBD

9.  IANA Considerations

   The BGP SAVNET SAFIs under the IPv4 address family and the IPv6
   address family need to be allocated by IANA.

10.  Security Considerations

   This document does not introduce any new security considerations.

Geng, et al.             Expires 11 January 2024               [Page 22]
Internet-Draft          BGP Extensions for SAVNET              July 2023

Acknowledgements

   TBD

References

Normative References

   [RFC2918]  Chen, E., "Route Refresh Capability for BGP-4", RFC 2918,
              DOI 10.17487/RFC2918, September 2000,
              <https://www.rfc-editor.org/info/rfc2918>.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              DOI 10.17487/RFC4760, January 2007,
              <https://www.rfc-editor.org/info/rfc4760>.

   [RFC5492]  Scudder, J. and R. Chandra, "Capabilities Advertisement
              with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February
              2009, <https://www.rfc-editor.org/info/rfc5492>.

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

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

Informative References

   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
              DOI 10.17487/RFC4271, January 2006,
              <https://www.rfc-editor.org/info/rfc4271>.

Geng, et al.             Expires 11 January 2024               [Page 23]
Internet-Draft          BGP Extensions for SAVNET              July 2023

   [RFC6959]  McPherson, D., Baker, F., and J. Halpern, "Source Address
              Validation Improvement (SAVI) Threat Scope", RFC 6959,
              DOI 10.17487/RFC6959, May 2013,
              <https://www.rfc-editor.org/info/rfc6959>.

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

   [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-savnet-intra-domain-problem-statement]
              Li, D., Wu, J., Qin, L., Huang, M., and N. Geng, "Source
              Address Validation in Intra-domain Networks Gap Analysis,
              Problem Statement, and Requirements", Work in Progress,
              Internet-Draft, draft-ietf-savnet-intra-domain-problem-
              statement-01, 4 May 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-savnet-
              intra-domain-problem-statement-01>.

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

   [I-D.huang-savnet-sav-table]
              Huang, M., Cheng, W., Li, D., Geng, N., Liu, and L. Chen,
              "Source Address Validation Table Abstraction and
              Application", Work in Progress, Internet-Draft, draft-
              huang-savnet-sav-table-01, 6 March 2023,
              <https://datatracker.ietf.org/doc/html/draft-huang-savnet-
              sav-table-01>.

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

Authors' Addresses

Geng, et al.             Expires 11 January 2024               [Page 24]
Internet-Draft          BGP Extensions for SAVNET              July 2023

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

   Zhenbin Li
   Huawei Technologies
   Beijing
   China
   Email: lizhenbin@huawei.com

   Zhen Tan
   Huawei Technologies
   Beijing
   China
   Email: tanzhen6@huawei.com

   Mingxing Liu
   Huawei Technologies
   Beijing
   China
   Email: liumingxing7@huawei.com

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

   Fang Gao
   Zhongguancun Laboratory
   Beijing
   China
   Email: gaofang@zgclab.edu.cn

Geng, et al.             Expires 11 January 2024               [Page 25]