Inter-domain Source Address Validation (SAVNET) Architecture
draft-wu-savnet-inter-domain-architecture-00
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 "Replaced".
|
|
|---|---|---|---|
| Authors | Jianping Wu , Dan Li , Mingqing(Michael) Huang , Lancheng Qin , Nan Geng , Tianran Zhou | ||
| Last updated | 2022-10-24 | ||
| Replaced by | draft-ietf-savnet-inter-domain-architecture | ||
| 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-wu-savnet-inter-domain-architecture-00
Network Working Group J. Wu
Internet-Draft D. Li
Intended status: Standards Track Tsinghua University
Expires: 27 April 2023 M. Huang
Huawei
L. Qin
Tsinghua University
N. Geng
T. Zhou
Huawei
24 October 2022
Inter-domain Source Address Validation (SAVNET) Architecture
draft-wu-savnet-inter-domain-architecture-00
Abstract
Source address validation (SAV) plays a significant role in defending
against various attacks based on source IP address spoofing. BCP84
[RFC3704][RFC8704] provides practical SAV mechanisms, i.e., uRPF-
based approaches, for inter-domain scenarios. However, current uRPF-
based SAV mechanisms have limitations in accuracy and incentive
[draft-wu-savnet-inter-domain-problem-statement]. This document
provides an architecture of inter-domain SAVNET which actively
advertises AS paths to other ASes for generating accurate SAV rules
and improving incentive.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 8174 [RFC8174].
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."
Wu, et al. Expires 27 April 2023 [Page 1]
Internet-Draft Inter-domain SAVNET Architecture October 2022
This Internet-Draft will expire on 27 April 2023.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Workflow of the Control Plane . . . . . . . . . . . . . . 5
4.1.1. Overall Process . . . . . . . . . . . . . . . . . . . 5
4.1.2. SPD Message Processing on ASBR . . . . . . . . . . . 9
4.1.3. SAV Rule Update . . . . . . . . . . . . . . . . . . . 11
4.2. Workflow of the Data Plane . . . . . . . . . . . . . . . 11
5. Inconsistent AS Path on Control Plane and Data Plane . . . . 12
6. Convergence Considerations . . . . . . . . . . . . . . . . . 13
6.1. Source Prefix Change . . . . . . . . . . . . . . . . . . 13
6.2. AS Path Change . . . . . . . . . . . . . . . . . . . . . 14
7. Incremental and Partial Deployment . . . . . . . . . . . . . 14
8. Security Consideration . . . . . . . . . . . . . . . . . . . 15
9. Normative References . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
Many attacks based on source IP address spoofing, such as reflective
DDoS, continue to pose a significant challenge to the Internet
security. Source address validation (SAV) in inter-domain networks
is important to mitigate source address spoofing. BCP84
[RFC3704][RFC8704] provides practical SAV mechanisms, i.e., uRPF-
based approaches, for inter-domain scenarios. In particular, it is
recommended that i) the loose uRPF[RFC3704] mechanism SHOULD be
applied on lateral peer and transit provider interfaces, and that ii)
the EFP-uRPF mechanism with Algorithm B SHOULD be applied on customer
interfaces.
Wu, et al. Expires 27 April 2023 [Page 2]
Internet-Draft Inter-domain SAVNET Architecture October 2022
However, current uRPF-based SAV mechanisms have limitations in
accuracy and incentive
[draft-wu-savnet-inter-domain-problem-statement]. They generate SAV
rules based on the RIB information of the local AS. In the case of
asymmetric routing, the rules may not exactly match the incoming
direction of packets originated from a specific source address.
Besides, in the design of existing SAV mechanisms, the victim network
in a reflective DDoS attack does not effectively participate in
preventing its own source address from being forged. As a result,
the victim network still suffers from reflective attack from other
networks even though it has deployed SAV.
To address the above issues, this document presents an inter-domain
source address validation (inter-domain SAVNET) architecture. An AS
deploying inter-domain SAVNET can actively advertise locally
preferred AS paths to neighboring ASes or remote ASes. Other ASes
will learn the valid incoming directions for the source prefixes of
the origin AS through these advertisement messages. Moreover, by
deploying inter-domain SAVNET, each AS is more likely to protect
itself from reflective DDoS attacks.
This document presents the core workflow of inter-domain SAVNET.
After that, some considerations are introduced including convergence,
incremental and partial deployment, and security. This document
focuses on high-level designs and does not describe how to implement
inter-domain SAVNET by using existing routing protocols.
2. Terminology
SAV rule: The rule that defines valid incoming interfaces for the
specific source prefix.
SAV table: The data structure that stores SAV rules on the data
plane. The router queries its local SAV table to validate the
authenticity of source addresses.
Improper block: The packets with valid source addresses are blocked
improperly due to inaccurate SAV rules.
Improper permit: The packets with spoofed source addresses are
accepted as normal packets due to inaccurate SAV rules.
SPA message: Source Prefix Advertisement message that helps other
ASes to associate the origin AS to a list of origin source prefixes.
Wu, et al. Expires 27 April 2023 [Page 3]
Internet-Draft Inter-domain SAVNET Architecture October 2022
SPD message: Source Path Discovery message that carries the ASN of
the origin AS and is propagated along the AS paths preferred by the
origin AS. Through SPD message, other ASes discover the real
incoming direction for the source prefixes of the origin AS.
3. Design Goals
The inter-domain SAV targets to reject packets with forged source
addresses without impacting legitimate packets. To this end, inter-
domain SAVNET needs to achieve these following goals:
* Providing as much source address protection as possible at
provider, peer, and customer interfaces.
* Generating accurate SAV rules that avoid improper block and reduce
improper permit as much as possible.
* Providing sufficient and aligned incentives for the ASes that
deploy SAV.
Overhead is also an important consideration for the design of inter-
domain SAVNET. The validation overhead on the data plane should be
limited by avoiding packet modification, which keeps consistent with
existing SAV mechanisms. The control-plane overhead (e.g., the
number of control-plane messages) should be limited to a reasonable
level under current network hardware and software conditions.
4. Architecture
To achieve the above goals, inter-domain SAVNET makes ASes to
actively notifty locally preferred AS paths to neighbor ASes or
remote ASes in a hop-by-hop way. ASes receiving such notifications
will identify the neighbor AS from which packets with specific source
prefixes should come. Then, the boundary routers of the ASes can
establish accurate SAV rules by associating the source prefixes with
corresponding incoming interfaces. The SAV rules can be generated at
any kind of AS interfaces, including provider, peer, and customer
interfaces. Besides, by notifying the real incoming interfaces for
its source prefixes to other ASes, each deployed AS can better
protect its source addresses from being forged, because other ASes
will perform more accurate SAV for packets with its source addresses.
Overall, six different operations will be conducted in the procedures
of inter-domain SAVNET architecture: __
* Source prefix advertisement: An AS identifies the complete origin
source prefixes and advertises its origin source prefixes through
BGP or SPA messages.
Wu, et al. Expires 27 April 2023 [Page 4]
Internet-Draft Inter-domain SAVNET Architecture October 2022
* Source prefix collection: An AS collects the source prefixes owned
by other ASes when receiving source prefix advertisement.
* SPD origination: An AS generates original SPD messages and sends
them to other ASes.
* SPD relaying: An AS generates a relaying SPD message to the next
hop AS along the preferred AS path after receiving one SPD
message.
* SPD termination: An AS terminates the received SPD message and
does not generate any relaying SPD message.
* SAV rule generation: An AS generates corresponding SAV rules after
receiving an SPD message.
4.1. Workflow of the Control Plane
4.1.1. Overall Process
The overall process of the control-plane workflow of inter-domain
SAVNET is described as follows:
a. Each AS conducts the operation of source prefix advertisement.
The origin source prefixes of the AS will be identified and
advertised through BGP or SPA messages. Actually, most of source
prefixes can be advertised through BGP. SPA messages are used
for adding or removing specific source prefixes.
b. Each AS conducts the operation of source prefix collection to get
the complete origin source prefixes of other ASes. The mappings
from ASN to a set of source prefixes will be maintained in each
AS.
c. Suppose AS X conducts the operation of SPD origination. AS X
will first identify the set of preferred AS paths reaching other
ASes. Then, it sends an SPD message to each next-hop AS Y
according to the preferred AS paths. Each SPD message carries
two main fields:
* origin ASN: the ASN of the origin AS (i.e., X).
* propagation scope: the list of local preferred AS paths which
start with AS X and take AS Y as the next-hop AS. To reduce
propagation overhead, a shorter AS path does not need to be
carried if there is a longer one covering it.
Wu, et al. Expires 27 April 2023 [Page 5]
Internet-Draft Inter-domain SAVNET Architecture October 2022
d. When AS Y receives the SPD message, it first conducts the
operation of SAV rule generation. AS Y learns from which
neighboring AS it will receive the packets originated from AS X
through the AS paths in the propagation scope field.
Specifically, it locates the previous-hop AS in each AS path, and
consider all interfaces connnected to the previous-hop AS as
valid incoming interfaces for the source prefixes of the origin
AS X. The source prefixes of AS X have been collected in advance
through source prefix collection. As a result, the SAV rules
with the format of <source prefix, incoming interface> will be
learned and installed in data plane.
e. After conducting the operation of SAV rule generation, AS Y
checks the AS paths in the propagation scope field of the
received SPD message. There are two behavior branches:
i) If the field only contains its own ASN (i.e., Y), it will
conduct the operation of SPD termination, i.e., stop
propagating the information in the SPD message to other ASes
after generating SAV rules.
ii) Otherwise, it conducts the operation of SPD relaying to
generate relaying SPD messages to other ASes. It removes the
previous ASes (e.g., X) from the AS paths in the propagation
scope of the received SPD message and then groups the
processed AS paths according to the next-hop AS. For each
next-hop AS Z, it generates a new SPD message to AS Z. The
new origin ASN field keeps the same as the received SPD
message. The new propagation scope field contains the
processed AS paths that take AS Z as the next-hop AS.
f. The other ASes on AS pathes of the propagation scope field will
receive SPD messages in sequence and conduct the same process as
step d and step e until the SPD message is terminated.
Wu, et al. Expires 27 April 2023 [Page 6]
Internet-Draft Inter-domain SAVNET Architecture October 2022
+-------+
-----------------------+ AS1 + -- + P1
| +---+---+
| | msg 1:
| | origin_ASN=AS1,
| | scope={[AS1,AS2,AS3,AS5],
| msg 1.1: | [AS1,AS2,AS6],
| origin_ASN=AS1, \/ [AS1,AS2,AS4,AS5]}
+---#---+ scope={[AS2,AS6]}+---#---+--- + P2
| AS6 # <----------------+ AS2 + ------------------
+---+---+ +---+---+ |
+ msg 1.2: | msg 1.3: |
P6 origin_ASN=AS1,| origin_ASN=AS1, |
scope={[AS2,AS3,AS5]} \/scope={[AS2,AS4,AS5]}\/
+---#---+ +---#---+
P3 + ---+ AS3 | P4 + ---+ AS4 |
+---+---+ +---+---+
msg 1.2.1: | msg 1.3.1: |
origin_ASN=AS1, | origin_ASN=AS1, |
scope={[AS3,AS5]} | scope={[AS4,AS5]} |
\/ |
+---#---+ |
P5,P7 + ---+ AS5 # <-----------------
+-------+
AS1 is the origin AS which generates original
SPD messages.
'#' means the valid incoming interface for packets with
source addresses of P1.
'scope' represents the propagation scope field.
The forwarding AS path preferred by AS1 is as follows:
+---------------------------------------+
+ Dest. Prefix | AS Path +
+---------------------------------------+
+ P2 | AS1 AS2 +
+ P3 | AS1 AS2 AS3 +
+ P4 | AS1 AS2 AS4 +
+ P5 | AS1 AS2 AS3 AS5 +
+ P6 | AS1 AS2 AS6 +
+ P7 | AS1 AS2 AS4 AS5 +
+---------------------------------------+
Figure 1: An example of the overall process
Figure 1 illustrates the overall process of SAV rule generation for
prefix P1. Suppose the process of source prefix advertisement and
collection has been finished.
Wu, et al. Expires 27 April 2023 [Page 7]
Internet-Draft Inter-domain SAVNET Architecture October 2022
* AS1 conducts the operation of SPD origination, and P2~P7 are
locally reachable addresses. According to the AS paths selected
by AS1, AS2 is the common next-hop AS in all AS paths. So, AS1
only generates one original SPD message to AS2 with "AS1" in the
origin ASN field and {[AS1,AS2,AS3,AS5], [AS1,AS2,AS4,AS5],
[AS1,AS2, AS6]} in the propagation scope. Note that AS paths to
P3 and P4 are not carried in the message because they are covered
by AS paths to P5 and P7.
* When receiving the SPD message from AS1, AS2 identifies the source
prefix of AS1 and generates the SAV rule <source prefix P1,
incoming interface #>.
* AS2 then checks each AS path in the propagation scope and finds
that AS path [AS1,AS2,AS3,AS5], [AS1,AS2,AS4,AS5], and [AS1,AS2,
AS6] take AS3, AS4, and AS6 as the next hop, respectively. Then,
it will conduct the operation of SPD relaying and generate one new
SPD message for each of AS3, AS4, and AS6. The relayed SPD
message destined to each next-hop AS carries corresponding AS
paths (starting from the local AS, i.e., AS2) in the propagation
field. The origin ASN in each relaying SPD message keeps the same
as the received SPD message.
* When receiving the SPD message from AS2, AS6 generates the SAV
rule for prefix P1 and terminate the message since the propagation
scope only contains AS6. When AS3 or AS4 receives the SPD message
from AS2, it generates the SAV rule and conducts the operation of
SPD relaying because the AS path in the propagation scope takes
AS5 as the next hop.
* When AS5 receives the relayed SPD message from AS3 or AS4, it
generates the SAV rule and terminates the propagation. In the
end, AS2~AS6 can generate the SAV rule <source prefix P1,
interface '#'>. It is noted that AS5 specifies two valid incoming
interfaces for source prefix P1 because it receives SPD messages
with the origin ASN A1 from two different neighboring ASes.
Any AS owning IP prefixes can conduct the operation of SPD
origination, and the other ASes will generate SAV rules for the
source prefixes of the origin AS. Finally, every AS will learn the
SAV rules for other ASes. In inter-domain SAVNET, with the exception
of some special cases, such as multipath routing to the same
destination AS, each AS usually receive only one SPD message
originated from each origin AS.
Wu, et al. Expires 27 April 2023 [Page 8]
Internet-Draft Inter-domain SAVNET Architecture October 2022
4.1.2. SPD Message Processing on ASBR
In the above description, inter-domain SAVNET treats an AS as a
logical node and the process within an AS is not discussed. As shown
in Figure 2, an AS usually have multiple ASBRs (Autonomous System
Boundary Routers). All ASBRs of an AS should be able to collaborate
with each other. The two key aspects of collaboration are SAV rule
generation and SPD message relaying within an AS.
i) When an ASBR receives an SPD message from another AS, it will
send the message to other ASBRs within the same AS after
generating the SAV rules. Then, all other ASBRs will identify the
previous-hop AS, from which the source prefixes of the origin AS
will come. Therefore, the ASBR with interfaces connected to the
previous-hop AS will consider all these interfaces as valid for
the source prefixes of the origin AS. The interfaces that are
connected to other ASes are considered invalid for the source
prefixes of the origin AS.
ii) After that, the other ASBRs will decide whether to relay or
terminate the received SPD message from an ASBR. Note that, ASBRs
may be connected to different neighboring ASes. For an ASBR, if
the AS paths in the propagation scope field of the received SPD
message only contains the local ASN or the next-hop AS is not its
neighbor, the ASBR will conduct SPD termination. Otherwise, the
ASBR will generate a relaying SPD message to the connected next-
hop AS with the propagation scope field filled with the AS paths
that take the connected AS as the next hop.
Wu, et al. Expires 27 April 2023 [Page 9]
Internet-Draft Inter-domain SAVNET Architecture October 2022
AS 1
|
\/ msg 1
+---#---+
------------+ ASBR1 +-------------
| +---+---+ |
| |
| AS 2 |
| |
msg 1.1 +---+---+ +---+---+
AS 6<----# ASBR2 +------------------------+ ASBR3 |
+---#---+ <SAV rules> +---#---+
msg 1.2| | msg 1.3
\/ \/
AS 3 AS 4
msg 1 is an SPD message from AS 1 and received by AS 2.
msg 1.1, msg 1.2, msg 1.3 are the SPD messages
after being relayed by AS 2.
'#' means the ingress interface of the ASBR.
Figure 2: An example of ASBR collaboration within an AS
Following the example in Figure 1, Figure 2 illustrates how an ASBR
collaborates with other ASBRs in the same AS. In Figure 2, there are
three ASBRs in AS2. When AS2 receives an SPD message from AS1, it
will send the message to other ASBRs. As shown in Figure 1, the
message has the origin ASN field of AS1 and the propagation scope
field of {[AS1,AS2,AS3,AS5], [AS1,AS2,AS4,AS5], [AS1,AS2, AS6]}.
First, all the ASBRs will figure out that AS1 is the previous-hop AS,
and the packets with source addresses of P1 should come from AS1.
So, ASBR1 will consider its interface '#' as the legal incoming
interface for source prefix P1. Since ASBR2 and ASBR3 do not have
interfaces connected to AS1, the interfaces '#' of ASBR2 and ASBR3
will be considered as illegal incoming interfaces for source prefix
P1.
Wu, et al. Expires 27 April 2023 [Page 10]
Internet-Draft Inter-domain SAVNET Architecture October 2022
Second, each ASBR will decide whether to generate relaying SPD
messages its directly connected ASes. The next-hop ASs of the three
AS paths are AS3, AS4, and AS6, respectively. ASBR1 connects none of
the three next-hop ASs, so it conducts the operation of SPD
termination. ASBR2 has an interface connected to AS6, so it will
generate a relaying SPD message to AS6, i.e., the msg 1.1 in
Figure 1. Since another interface of ASBR2 is connected to AS3, a
relaying SPD message will be also generated to AS3, i.e., msg 1.2 in
Figure 1. Similarly, ASBR3 will generate a relaying SPD message to
AS4, i.e., msg 1.3 in Figure 1.
4.1.3. SAV Rule Update
The AS paths preferred by each AS may change with time. Inter-domain
SAVNET does not take the explicit SAV rule withdraw mechanism so as
to eliminate the impact of route flapping. Instead, the combination
of rule aging and periodical timer refreshing is taken. More details
can be found in section 6.
4.2. Workflow of the Data Plane
Through the workflow of the control plane, the ASBRs will learn the
SAV rules indicating which interfaces are valid or invalid for
specific source prefixes. These rules will form SAV tables which
will be enabled in the data plane. Figure 3 shows an example of SAV
table.
The packets coming from other ASes will be validated by ASBRs. The
router looks up each packet's source address in its local SAV table
and gets one of three validity states: "Valid", "Invalid" or
"Unknown". "Valid" means that there is a source prefix in SAV table
covering the source address of the packet and the valid incoming
interfaces covering the actual incoming interface of the packet.
According to the SAV principle, "Valid" packets will be forwarded.
"Invalid" means there is a source prefix in SAV table covering the
source address, but the incoming interface of the packet does not
match any valid incoming interface so that such packets will be
dropped. "Unknown" means there is no source prefix in SAV table
covering the source address. The packet with "unknown" addresses can
be dropped or permitted, which depends on the choice of operators.
The SAV table can be enabled at provider, peer, or customer
interfaces. Different interfaces can take on proper SAV table modes
defined in [draft-huang-savnet-sav-table]. For customer interfaces,
if all the customer ASes have advertised complete source prefixes and
SPD messages, Prefix Allowlist Mode can be applied ("Mode 1" in
[draft-huang-savnet-sav-table]). This mode drops any packets whose
source addresses are not included in the allowlist of the customer
Wu, et al. Expires 27 April 2023 [Page 11]
Internet-Draft Inter-domain SAVNET Architecture October 2022
interfaces. If the legitimate source prefixes arriving at the
interfaces are not learned completely, the Interface Allowlist/
Blocklist Mode can be taken ("Mode 3" and "Mode 4"
in[draft-huang-savnet-sav-table]). This latter mode checks whether
specific source prefixes coming from the valid or invalid interfaces.
The packets with unknown prefixes will be forwarded normally. Thus,
they are safer than Prefix Allowlist Mode.
For provider or peer interfaces which connected to a large network
area, it is difficult to get the complete legitimate source prefixes.
To provide as much protection as possible, the Interface Allowlist/
Blocklist Mode can be taken, which will be more strict than loose
uRPF.
+----------------------------------------+
+ Source prefix | Incoming interface +
+----------------------------------------+
+ P1 | Interface 1 +
+ P2 | Interface 2 +
+ P3 | Interface 3 +
+----------------------------------------+
Figure 3: SAV table format
5. Inconsistent AS Path on Control Plane and Data Plane
ACL redirection is usually used to steer traffic for traffic
engineering or some other objectives. The ACL redirection rules can
be configurated manually or installed through FlowSpec. They may
change the AS path used to forward the traffic, leading to AS-level
inconsistency between control-plane routing path and data-plane
forwarding path. Note that, origin AS obtains AS paths from control
plane and put them into the propagation scope field for guiding the
propagation of SPD messages. In this way, each AS generates SAV
rules following the AS paths learned from control plane. If the AS-
level inconsistency exists, improper block or improper permit
problems may appear.
One possible solution is to require the AS to notify the affected
source AS when it attempts to change the AS paths of traffic on data
plane, which allows the origin AS to be aware of the real AS paths.
In other words, the real data-plane AS paths of inter-domain traffic
should be visible to the origin AS on the control plane.
When the change of AS paths is sensed, the origin AS immediately re-
conducts the SPD process to guide the AS along the new AS path to
update SAV rules.
Wu, et al. Expires 27 April 2023 [Page 12]
Internet-Draft Inter-domain SAVNET Architecture October 2022
6. Convergence Considerations
The preferred AS paths of an origin AS will change with time due to
route changes. For some ASes, the valid incoming directions of the
source prefixes of the origin AS may need to be updated so as to keep
SAV rules accurate. Inaccurate SAV rules will induce improper permit
problems or improper block problems. Improper block will affect the
forwarding of legitimate data packets, which is more serious than
improper permit. So, one of the design goals of inter-domain SAVNET
is to eliminate improper block first and try best to reduce improper
permit.
For the route changes resulting in new SAV rules, the basic idea of
inter-domain SAVNET is to add the new SAV rules in time to eliminate
improper block as quickly as possible. For the route changes
resulting in SAV rule deletion, inter-domain SAVNET does not
explicitly withdraw these SAV rules. As mentioned previously,
invalid SAV rules are removed by using an aging timer. The aging
design is to reduce the impact of route flapping. To refresh aging
timers, SPD messages will be propagated periodically.
Generally, route changes include source prefix change and AS path
change. The followings are some convergence considerations of inter-
domain SAVNET when there are route changes.
6.1. Source Prefix Change
There are two types of source prefix change: announcing a new source
prefix and withdrawing an existing source prefix.
A new source prefix with its origin ASN can be advertised by a BGP
message or an SPA message. Upon receiving the announcement by other
ASes, these ASes will update local SAV rules immediately, i.e.,
binding the new source prefix with the valid interfaces learned
through SPD messages before. An alternative method is to advertise
the new source prefix by SPA message before really using the new
source prefix in the network. In this way, other ASes can update
local SAV rules in advance.
When an existing prefix will be revoked, the origin AS sends a BGP
message or an SPA message to other ASes to withdraw the prefix.
Other ASes will remove the prefix from the list of source prefixes of
the origin ASN in the control plane. The SAV rule keeps installed in
data plane untile the aging timer is timeout.
Wu, et al. Expires 27 April 2023 [Page 13]
Internet-Draft Inter-domain SAVNET Architecture October 2022
6.2. AS Path Change
For an origin AS, the preferred AS paths may change due to new route
announcement, route policy changes, link failures, etc. Upon sensing
AS path changes, the origin AS will generate new SPD messages
carrying the new AS paths to advertise related ASes updating SAV
rules. Similarly, new SAV rules will be enabled immediately, but
invalid SAV rules will be removed only when the aging timer expires.
Fast reroute (FRR) is a particular scenario. FRR requires the router
to set up a backup path in advance. When network failure happends,
the router is able to fastly steer the affected traffic to the backup
path so as to satisfy some SLA requirements. The normal convergence
process, i.e., updating SAV rules through new SPD messages, may
sometimes be not fast enough for FRR scenarios. To meet the
performance requirements of FRR, ASes can send SPD messages to the
backup forwarding AS paths in advance, and the generated SAV rules
will also be enabled in the data plane. When network failures
happend, the affected data packets can be forwarded normally through
the backup path without worrying about improper block problems during
the normal convergence process of inter-domain SAVNET.
7. Incremental and Partial Deployment
Since it is impossible to deploy inter-domain SAVNET in all ASes
simultaneously, inter-domain SAVNET must support incremental and
partial deployment. In inter-domain SAVNET architecture, the SPD
message is hop-by-hop propagated along the AS path predefined by the
origin AS. Hence, even if an intermediate AS does not support inter-
domain SAVNET, an AS can easily find the next deployed AS on the AS
path and establishes logical neighboring relationship with that AS.
After that, it can generate SPD messages directly to that AS. In
this way, SPD messages can be propagated across non-deploying ASes.
However, as mentioned in Section 5, the control-plane routing path
and data-plane forwarding path are required to be consistent to
ensure the accuracy of source path discovery.
To reduce the overhead of maintaining logic neighboring relationships
and mitigate the affect of ACL redirection, it is suggested to
incrementally deploy inter-domain SAVNET on a customer cone basis.
On the one hand, given the hierarchical topology of ASes in the
Internet, logical neighboring relationships are mainly established
between the top-level ASes of different deployed customer cones. On
the other hand, it is more feasible to exchange policy-based routing
information within the same customer cone as the first step.
Wu, et al. Expires 27 April 2023 [Page 14]
Internet-Draft Inter-domain SAVNET Architecture October 2022
Overall, in incremental and partial deployment condition, each
deployed customer cone should at least gain the benefits: "ASes
within the deployed area cannot spoof each other, and ASes in the
undeployed area cannot send spoofed packets to the deployed area by
forging the source addresses of the deployed area ". With the merger
of different customer cones where the inter-domain SAVNET is
deployed, the "deployed area" will gradually expand, and the defense
capability against source address spoofing will gradually increase.
Moreover, if multiple "deployed areas" can be logically connected (by
crossing the "non-deploying areas"), these "deployed areas" can form
a logic alliance to protect their addresses from being forged by non-
deploying networks.
8. Security Consideration
In inter-domain SAVNET architecture, the SPD message are hop-by-hop
propagated among different ASes. To prevent a malicious AS from
generating incorrect or forged SPD messages, routers need to perform
security authentication on each received SPD message. Security
threats to inter-domain SAVNET come from two aspects: session
security and content security. Session security means that the
identities of both parties in a session can be verified and the
integrity of the session content can be ensured. Content security
means that the authenticity and reliability of the session content
can be verified, i.e., the forged SPD message can be identified.
Specifically, the threats to session security include:
* Session identity impersonation: A malicious router masquerades as
a peer of another router to establish a session with the router.
* Session integrity destroying: A malicious intermediate router
between two peering routers destroys the content of the passed SPD
message.
The threats to content security include:
* Message alteration: A malicious router forges any part of an SPD
message, for example, using a spoofed ASN or AS Path.
* Message injection: A malicious router injects a "legitimate" SPD
message and sends it to the corresponding next-hop AS, such as
replay attacks.
* Path deviation: A malicious router sends an SPD message to a wrong
next-hop AS which conflicts with the AS Path.
Wu, et al. Expires 27 April 2023 [Page 15]
Internet-Draft Inter-domain SAVNET Architecture October 2022
Overall, inter-domain SAVNET faces security threats similar to those
of BGP. To enhance session security, inter-domain SAVNET can use the
same session authentication mechanisms as BGP, i.e., performing
session authentication based on MD5, TCP-AO, or Keychain. To enhance
content security, existing BGP security mechanisms (such as RPKI,
BGPsec, ASPA) can also help address content security threats to
inter-domain SAVNET. But until these mechanisms are widely deployed,
an independent security mechanism for inter-domain SAVNET is needed.
In the preliminary idea, each origin AS calculates a digital
signature for each AS path and adds these digital signatures into the
SPD message. When a router receiving an SPD message, it can check
the digital signature to identify the authenticity of this SPD
message. Specific security designs will be included in a separate
draft.
9. Normative References
[draft-huang-savnet-sav-table]
Huang, M., Zhou, T., Geng, N., Li, D., Chen, L., and J.
Wu, "Source Address Validation Table Abstraction and
Application", 24 October 2022.
[draft-wu-savnet-inter-domain-problem-statement]
Wu, J., Li, D., Qin, L., Huang, M., and N. Geng, "Source
Address Validation in Inter-domain Networks (Inter-domain
SAVNET) Gap Analysis, Problem Statement and Requirements",
22 October 2022.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8704] Sriram, K., Montgomery, D., and J. Haas, "Enhanced
Feasible-Path Unicast Reverse Path Forwarding", BCP 84,
RFC 8704, DOI 10.17487/RFC8704, February 2020,
<https://www.rfc-editor.org/info/rfc8704>.
Authors' Addresses
Jianping Wu
Tsinghua University
Beijing
China
Email: jianping@cernet.edu.cn
Wu, et al. Expires 27 April 2023 [Page 16]
Internet-Draft Inter-domain SAVNET Architecture October 2022
Dan Li
Tsinghua University
Beijing
China
Email: tolidan@tsinghua.edu.cn
Mingqing Huang
Huawei
Beijing
China
Email: huangmingqing@huawei.com
Lancheng Qin
Tsinghua University
Beijing
China
Email: qlc19@mails.tsinghua.edu.cn
Nan Geng
Huawei
Beijing
China
Email: gengnan@huawei.com
Tianran Zhou
Huawei
Beijing
China
Email: zhoutianran@huawei.com
Wu, et al. Expires 27 April 2023 [Page 17]