BGP Extensions for Source Address Validation Networks (BGP SAVNET)
draft-geng-idr-bgp-savnet-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
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 "Active".
|
|
|---|---|---|---|
| Authors | Nan Geng , Zhenbin Li , Zhen Tan , Mingxing Liu , Dan Li , Fang Gao | ||
| Last updated | 2023-11-05 (Latest revision 2023-07-09) | ||
| 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-02
IDR N. Geng
Internet-Draft Z. Li
Intended status: Standards Track Z. Tan
Expires: 9 May 2024 M. Liu
Huawei Technologies
D. Li
Tsinghua University
F. Gao
Zhongguancun Laboratory
6 November 2023
BGP Extensions for Source Address Validation Networks (BGP SAVNET)
draft-geng-idr-bgp-savnet-02
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 edge/border routers automatically
generate accurate SAV rules. These rules construct a validation
boundary for the network and help check the validity of incoming 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 9 May 2024.
Geng, et al. Expires 9 May 2024 [Page 1]
Internet-Draft BGP Extensions for SAVNET November 2023
Copyright Notice
Copyright (c) 2023 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 . . . . . . . . . . . . . . . . . . . . . . . . 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 for Protecting Internal Source Prefixes . . . . . . . 6
3.3. SAV for Protecting Remote Source Prefixes . . . . . . . . 10
4. BGP SAVNET Peering Models . . . . . . . . . . . . . . . . . . 11
4.1. Full-mesh IBGP Peering . . . . . . . . . . . . . . . . . 11
4.2. EBGP Peering between ASes . . . . . . . . . . . . . . . . 11
5. BGP SAVNET Protocol Extension . . . . . . . . . . . . . . . . 11
5.1. BGP SAVNET SAFI . . . . . . . . . . . . . . . . . . . . . 11
5.2. BGP SAVNET NLRI . . . . . . . . . . . . . . . . . . . . . 11
5.2.1. SPA TLVs within an AS . . . . . . . . . . . . . . . . 12
5.2.2. SPA TLVs between ASes . . . . . . . . . . . . . . . . 13
5.3. BGP SAVNET Refresh . . . . . . . . . . . . . . . . . . . 14
5.3.1. The SPD TLVs between ASes . . . . . . . . . . . . . . 15
6. Decision Process with BGP SAVNET . . . . . . . . . . . . . . 16
6.1. BGP SAVNET NLRI Selection . . . . . . . . . . . . . . . . 16
6.1.1. Self-Originated NLRI . . . . . . . . . . . . . . . . 17
7. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Process of BGP SAVNET NLRIs . . . . . . . . . . . . . . . 17
7.2. Process of BGP SAVNET SPA TLVs . . . . . . . . . . . . . 17
7.3. Process of BGP SAVNET Refresh . . . . . . . . . . . . . . 18
7.4. Process of BGP SAVNET SPD TLVs . . . . . . . . . . . . . 18
8. Management Considerations . . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Normative References . . . . . . . . . . . . . . . . . . . . . 19
Geng, et al. Expires 9 May 2024 [Page 2]
Internet-Draft BGP Extensions for SAVNET November 2023
Informative References . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
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 9 May 2024 [Page 3]
Internet-Draft BGP Extensions for SAVNET November 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 9 May 2024 [Page 4]
Internet-Draft BGP Extensions for SAVNET November 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 for protecting internal source prefixes. SAV can be deployed
at '*' or '#' to prevent local customer networks (subnets or stub
ASes) from generating source address spoofed packets and to 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.
* SAV for protecting remote source prefixes. SAV can be deployed at
'#' for blocking the source addresses of packets coming from
unwanted directions (i.e., coming from unwanted neighbor ASes).
Cooperations or interactions between the local AS and other ASes
are required.
+-----+ +-----+
| AS1 | | AS2 |
+-----+ +-----+
\ /
+-------------\-----------/-------------+
| AS3 +-#--+ +--#-+ |
| | R7 |---| R8 | |
| +----+ +----+ |
| | | |
| +----+ +----+ |
| ------| R5 |---| R6 |------ |
| | +----+ +----+ | |
| | | | | |
| +----+ +----+ +----+ +----+ |
| | R1 | | R2 |---| R3 | | R4 | |
| +--*-+ +-*--+ +--#-+ +-#--+ |
+-------\-----/-----------\-----/-------+
+-------+ +-----+
|Subnet1| | AS4 |
+-------+ +-----+
Figure 1: BGP SAVNET application scenarios
Geng, et al. Expires 9 May 2024 [Page 5]
Internet-Draft BGP Extensions for SAVNET November 2023
3.2. SAV for Protecting Internal Source Prefixes
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.
+-----------------------------------------+
| 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:
Geng, et al. Expires 9 May 2024 [Page 6]
Internet-Draft BGP Extensions for SAVNET November 2023
* 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.
* 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.
Geng, et al. Expires 9 May 2024 [Page 7]
Internet-Draft BGP Extensions for SAVNET November 2023
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.
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.
Geng, et al. Expires 9 May 2024 [Page 8]
Internet-Draft BGP Extensions for SAVNET November 2023
"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
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
Geng, et al. Expires 9 May 2024 [Page 9]
Internet-Draft BGP Extensions for SAVNET November 2023
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".
3.3. SAV for Protecting Remote Source Prefixes
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 can contain the complete set of
source prefixes of AS Y or only the own source prefixes that need to
be protected. Some hidden source prefixes that do not appear can
also be advertised to AS X through SPA messages. Note that, there
should be ROAs covering the prefixes of AS Y, and AS X should conduct
ROV on AS Y's messages.
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.
Validation AS BGP SAVNET can provide services such as 1) proactive
SAV for customer's prefixes, 2) reactive source address filtering for
mitigating DDoS suffered by customers, 3) key source address
forwarding path protection (i.e., keeping control plane and data
plane paths consistent).
The above solution has good deployability, i.e., any pair of ASes can
upgrade and work well, and good convergence, i.e., 1) similar
propagation speed to route and 2) supporting independent and
incremental update (no need to wait for complete information).
Besides, the trust model is simple, and the communication between
source AS and validation AS can be protected by TLS.
Geng, et al. Expires 9 May 2024 [Page 10]
Internet-Draft BGP Extensions for SAVNET November 2023
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. 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
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.
Geng, et al. Expires 9 May 2024 [Page 11]
Internet-Draft BGP Extensions for SAVNET November 2023
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:
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 (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Geng, et al. Expires 9 May 2024 [Page 12]
Internet-Draft BGP Extensions for SAVNET November 2023
* 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.
* 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.
Geng, et al. Expires 9 May 2024 [Page 13]
Internet-Draft BGP Extensions for SAVNET November 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
* 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) | Subtype (1) | SAFI (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPD TLV (variable) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Geng, et al. Expires 9 May 2024 [Page 14]
Internet-Draft BGP Extensions for SAVNET November 2023
Figure 5: BGP-REFRESH with SPD TLV format
The AFI field is either 1 (IPv4) or 2 (IPv6). The SAFI field is the
newly defined SAVNET SAFI. The Subtype field should be a new value
assigned to SAVNET [RFC7313]. 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 between ASes
This type of TLVs are used in SPD 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 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 2 for SPD TLV between an AS.
* Length: The length of the SPD TLV value, the Type, SubType and
Length fields are excluded.
Geng, et al. Expires 9 May 2024 [Page 15]
Internet-Draft BGP Extensions for SAVNET November 2023
* 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.
* Optional Data: Reserved for future use.
* 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.
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.
Geng, et al. Expires 9 May 2024 [Page 16]
Internet-Draft BGP Extensions for SAVNET November 2023
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
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 SHOULD be ignored or stored without parsing.
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.
Geng, et al. Expires 9 May 2024 [Page 17]
Internet-Draft BGP Extensions for SAVNET November 2023
When a BGP SAVNET speaker receives an SPA TLV with an unsupported
miig-type, it SHOULD be ignored or stored without parsing.
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.
7.4. Process of BGP SAVNET SPD TLVs
When a BGP SAVNET speaker receives an SPD TLV with an undefined type
or subtype, it SHOULD be ignored.
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 validation AS
number, 0 source AS number, AS_TRANS number (23456), 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 SHOULD be ignored.
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:
Geng, et al. Expires 9 May 2024 [Page 18]
Internet-Draft BGP Extensions for SAVNET November 2023
* 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.
Acknowledgements
Many thanks to the comments from Zhibin Dai, Shunwan Zhuang, etc.
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>.
[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>.
Geng, et al. Expires 9 May 2024 [Page 19]
Internet-Draft BGP Extensions for SAVNET November 2023
[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>.
[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>.
[RFC7313] Patel, K., Chen, E., and B. Venkatachalapathy, "Enhanced
Route Refresh Capability for BGP-4", RFC 7313,
DOI 10.17487/RFC7313, July 2014,
<https://www.rfc-editor.org/info/rfc7313>.
[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-02, 17 August 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-savnet-
intra-domain-problem-statement-02>.
[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>.
Geng, et al. Expires 9 May 2024 [Page 20]
Internet-Draft BGP Extensions for SAVNET November 2023
[I-D.huang-savnet-sav-table]
Huang, M., Cheng, W., Li, D., Geng, N., Liu, Chen, L., and
C. Lin, "General Source Address Validation Capabilities",
Work in Progress, Internet-Draft, draft-huang-savnet-sav-
table-03, 5 November 2023,
<https://datatracker.ietf.org/doc/html/draft-huang-savnet-
sav-table-03>.
[manrs-antispoofing]
"MANRS Implementation Guide", January 2023,
<https://www.manrs.org/netops/guide/antispoofing>.
Authors' Addresses
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
Geng, et al. Expires 9 May 2024 [Page 21]
Internet-Draft BGP Extensions for SAVNET November 2023
Fang Gao
Zhongguancun Laboratory
Beijing
China
Email: gaofang@zgclab.edu.cn
Geng, et al. Expires 9 May 2024 [Page 22]