Inter-domain Source Address Validation (SAVNET) Architecture
draft-wu-savnet-inter-domain-architecture-03
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 | Jianping Wu , Dan Li , Mingqing(Michael) Huang , Li Chen , Nan Geng , Libin Liu , Lancheng Qin | ||
| Last updated | 2023-07-25 (Latest revision 2023-06-01) | ||
| 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-03
Internet Engineering Task Force J. Wu
Internet-Draft D. Li
Intended status: Standards Track Tsinghua University
Expires: 26 January 2024 M. Huang
Huawei
L. Chen
Zhongguancun Laboratory
N. Geng
Huawei
L. Liu
Zhongguancun Laboratory
L. Qin
Tsinghua University
25 July 2023
Inter-domain Source Address Validation (SAVNET) Architecture
draft-wu-savnet-inter-domain-architecture-03
Abstract
This document presents an inter-domain SAVNET architecture that
serves as a comprehensive framework for the development of inter-
domain source address validation (SAV) mechanisms. The proposed
architecture empowers AS to generate SAV rules by leveraging SAV-
specific Information communicated between ASes, and during the
incremental/partial deployment of the SAV-specific Information, it
can leverage the general information such as the routing information
from the RIB to generate the SAV table when the SAV-specific
Information for an AS's prefixes are not available. Instead of
delving into protocol extensions or implementations, this document
primarily focuses on proposing the SAV-specific Information and
general information for deploying an inter-domain SAV mechanism, and
defining the architectural components and interconnections between
them for generating the SAV table.
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/.
Wu, et al. Expires 26 January 2024 [Page 1]
Internet-Draft Inter-domain SAVNET Architecture July 2023
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 26 January 2024.
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. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Inter-domain SAVNET Architecture . . . . . . . . . . . . . . 5
4.1. SAV Information Base . . . . . . . . . . . . . . . . . . 7
4.2. SAV-specific Protocol . . . . . . . . . . . . . . . . . . 10
4.3. SAV Information Base Manager . . . . . . . . . . . . . . 11
4.4. Management Channel and Information Channel . . . . . . . 12
5. Partial/Incremental Deployment . . . . . . . . . . . . . . . 14
6. Convergence Considerations . . . . . . . . . . . . . . . . . 15
7. Management Considerations . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
11. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
12. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 18
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
14.1. Normative References . . . . . . . . . . . . . . . . . . 20
14.2. Informative References . . . . . . . . . . . . . . . . . 21
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
Wu, et al. Expires 26 January 2024 [Page 2]
Internet-Draft Inter-domain SAVNET Architecture July 2023
1. Introduction
Attacks based on source IP address spoofing, such as reflective DDoS
and flooding attacks, continue to present significant challenges to
Internet security. Mitigating these attacks in inter-domain networks
requires effective source address validation (SAV). While BCP84
[RFC3704] [RFC8704] offers some SAV solutions, such as ACL-based
ingress filtering and uRPF-based mechanisms, existing inter-domain
SAV mechanisms have limitations in terms of validation accuracy and
operational overhead in different scenarios [inter-domain-ps].
To address these issues, the inter-domain SAVNET architecture focuses
on providing a comprehensive framework and guidelines for the design
and implementation of inter-domain SAV mechanisms. By proposing the
SAV-specific Information which consists of legitimate prefixes of
ASes and their corresponding legitimate incoming interfaces and is
specialized for generating the SAV table, the inter-domain SAVNET
architecture empowers ASes to generate precise SAV table. Meanwhile,
a SAV-specific protocol is used to defining the data structure or
format for communicating the information, and the operations and
timing for origination, processing, propagation, and termination of
the messages which carry the SAV-specific Information, to achieve the
delivery and automatic update of SAV-specific Information. Moreover,
during the incremental/partial deployment period of the SAV-specific
Information, the inter-domain SAVNET architecture can leverage the
general information, such as the routing information from the RIB or
topological information from the RPKI ROA Objects and ASPA Objects,
to generate the SAV table when the SAV-specific Information for an
AS's prefixes are not available. To achieve this, the inter-domain
SAVNET architecture assigns priorities to the SAV-specific
Information and general information and generate the SAV table based
on priorities of the information in the SAV Information Base, and the
SAV-specific Information has higher priority compared to the general
information.
In addition, by defining the architectural components, relationships,
and the SAV-specific information and general information used in
inter-domain SAV deployments, this document aims to promote
consistency, interoperability, and collaboration among ASes. This
document primarily describes a high-level architecture for
consolidating SAV-specific information and general information and
deploying an inter-domain SAV mechanism between ASes. The document
does not specify protocol extensions or implementations. Its purpose
is to provide a conceptual framework and guidance for the development
of inter-domain SAV mechanisms, allowing implementers to adapt and
implement the architecture based on their specific requirements and
network environments.
Wu, et al. Expires 26 January 2024 [Page 3]
Internet-Draft Inter-domain SAVNET Architecture July 2023
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Terminology
SAV Rule:
The rule that indicates the validity of a specific source IP
address or source IP prefix.
SAV Table:
The table or data structure that implements the SAV rules and is
used for source address validation in the data plane.
Real Forwarding Paths:
The paths that the legitimate traffic goes through in the data
plane.
SAV-specific Information:
The information consists of the source prefixes and their
legitimate incoming interfaces of an AS.
SAV-related Information:
The information is used to generate SAV rules and can be from SAV-
specific Information or general information.
False Positive:
The validation results that the packets with legitimate source
addresses are considered invalid improperly due to inaccurate SAV
rules.
False Negative:
The validation results that the packets with spoofed source
addresses are considered valid improperly due to inaccurate SAV
rules.
SAV Information Base:
A table or data structure for storing SAV-related information
collected from SAV-specific Information and general information.
Wu, et al. Expires 26 January 2024 [Page 4]
Internet-Draft Inter-domain SAVNET Architecture July 2023
3. Design Goals
The inter-domain SAVNET architecture aims to improve SAV accuracy and
facilitate partial deployment with low operational overhead, as well
as developing a SAV-specific protocol to communicate SAV-specific
Information between ASes. The overall goal can be broken down into
the following aspects:
* First, the inter-domain SAVNET architecture should learn the real
forwarding paths or permissible paths of source prefixes that can
cover their real forwarding paths, and generate accurate SAV rules
automatically based on the learned information to avoid false
positives and reduce false negatives as much as possible.
* Second, the inter-domain SAVNET architecture should provide
sufficient protection for the source prefixes of ASes that deploy
it, even if only a portion of Internet implements the
architecture.
* Third, the inter-domain SAVNET architecture should adapt to
dynamic networks and asymmetric routing scenarios automatically.
* Fourth, the inter-domain SAVNET architecture should support to
communicate SAV-specific information automatically with a SAV-
specific protocol between ASes.
* Last, the inter-domain SAVNET architecture should scale
independently from the SAV information sources and the growth of
the deployed Internet devices.
The inter-domain SAVNET architecture can achive the goals outlined
above as follows: SAV-specific Information can be communicated
between ASes to carry prefixes and their legitimate incoming
interfaces and enpowers an AS to generate an accurate SAV table for
the ASes which support the cummunication of SAV-specific Information.
During the incremental/partial deployment period of the SAV-specific
Information, the inter-domain SAVNET architecture can leverage the
general information to generate the SAV table. Moreover, it should
proactively adapt to route changes in a timely manner.
Other design goals, such as low operational overhead and easy
implementation, are also very important and should be considered in
specific protocols or protocol extensions and are out of scope for
this document.
4. Inter-domain SAVNET Architecture
Wu, et al. Expires 26 January 2024 [Page 5]
Internet-Draft Inter-domain SAVNET Architecture July 2023
+--------------------------+
| Other ASes |
+--------------------------+
|SAV-specific
|Messages
+-------------------------------------------------------+
| | AS |
| \/ |
| +~~~~~~~~~~~~~~~~~~~~~+ +--------------------------+ |
| | General Information | | SAV-specific Information | |
| +~~~~~~~~~~~~~~~~~~~~~+ +--------------------------+ |
| | | |
| \/ \/ |
| +---------------------------------------------------+ |
| | +-----------------------------------------------+ | |
| | | SAV Information Base | | |
| | +-----------------------------------------------+ | |
| | SAV Information Base Manager | |
| +---------------------------------------------------+ |
| |SAV Rules |
| \/ |
| +------------------------------------------------+ |
| | SAV Table | |
| +------------------------------------------------+ |
+-------------------------------------------------------+
Figure 1: The inter-domain SAVNET architecture
Figure 1 shows the overview of the inter-domain SAVNET architecture.
The inter-domain SAVNET architecture collects SAV-specific
Information from the SAV-specific Messages of other ASes. The SAV-
specific Information consists of the legitimate prefixes and their
legitimate incoming interfaces of the ASes. As a result, the SAV-
specific information can be used to generate SAV rules and build an
accurate SAV table on each AS directly. In order to exchange SAV-
specific Information between ASes, a new SAV-specific protocol should
be developed to carry the SAV-specific information. Compared against
existing inter-domain SAV mechanisms which rely on the general
information such as routing information from the RIB, the SAV-specifc
information can generate more accurate SAV table, the root cause is
that the SAV-specific information is dedicately design for inter-
domain SAV, while the general information is not.
The SAV-specific protocol should define the data structure or format
for communicating the SAV-specific information and the operations and
timing for originating, processing, propagating, and terminating the
messages which carry the information. Additionally, the SAV-specific
Wu, et al. Expires 26 January 2024 [Page 6]
Internet-Draft Inter-domain SAVNET Architecture July 2023
Information will not be avaiable for all ASes when the SAV-specific
protocol is on the incremental/partial deployment. Therefore, in the
stage of incremental/partial deployment, the inter-domain SAVNET
architecture can use the general information to generate SAV table.
The SAV Information Base (SIB) can store the information from the
SAV-specific Information and general information and is maintained by
the SAV Information Base Manager (SIM), and then the SIM generate SAV
rules based on the SIB and fill out the SAV table in the dataplane.
The SIB can be managed by network operators using various methods
such as YANG, Command-Line Interface (CLI), remote triggered black
hole (RTBH) [RFC5635], and Flowspec [RFC8955].
Inter-domain SAVNET architecture does not prescribe any specific
deployment models.
4.1. SAV Information Base
The SIB is managed by the SAV Information Base Manager, which can
consolidate SAV-related information from different sources. The SAV
information sources of SIB include SAV-specific Information and
general information, which are illustrated below:
* SAV-specific Information is the specifically collected information
for SAV and exactly consists of the legitimate prefixes and their
incoming interfaces.
* General information refers to the information that are not
directly related to SAV but can be utilized to generate the SAV
table, such as routing information from the RIB or FIB, the
relationships between prefixes and ASes from the RPKI ROA Objects,
and the AS relationships from the RPKI ASPA Objects.
+---------------------------------------------------+----------+
| SAV Information Sources |Priorities|
+---------------------------------------------------+----------+
| SAV-specific Information | 1 |
+---------------------+-----------------------------+----------+
| | RPKI ROA Obj. and ASPA Obj. | 2 |
| +-----------------------------+----------+
| General Information | RIB | 3 |
| +-----------------------------+----------+
| | FIB | 4 |
+---------------------+-----------------------------+----------+
Figure 2: Priority ranking for the SAV information sources
Wu, et al. Expires 26 January 2024 [Page 7]
Internet-Draft Inter-domain SAVNET Architecture July 2023
Figure 2 presents a priority ranking for the SAV-specific Information
and general information. SAV-specific Information has higher
priority (i.e., 1) than the general information (i.e., 2), since the
inter-domain SAVNET architecture uses the SAV-specific information to
carry the more accurate information which comprises ASes' prefixes
and their legitimate incoming interfaces. Therefore, once the SAV-
specific information for a prefix is available within the SIB, the
inter-domain SAVNET generate the SAV table based on the information
from the SAV-specific information; otherwise, the inter-domain SAVNET
generate the SAV table based on the information from the general
information. In other words, the inter-domain SAVNET architecture
assigns priorities to the information from different SAV information
sources, and always generate the SAV table using the information with
the high priority.
+-----+------+------------------+---------+------------------------+
|Index|Prefix|AS-level Interface|Direction| SAV Information Source |
+-----+------+------------------+---------+------------------------+
| 0 | P3 | Itf.1 |Provider | General Information |
+-----+------+------------------+---------+------------------------+
| 1 | P2 | Itf.2 |Customer | General Information |
+-----+------+------------------+---------+------------------------+
| 2 | P1 | Itf.2 |Customer |SAV-specific Information|
+-----+------+------------------+---------+------------------------+
| 3 | P1 | Itf.3 |Customer | General Information |
+-----+------+------------------+---------+------------------------+
| 4 | P6 | Itf.2 |Customer | General Information |
+-----+------+------------------+---------+------------------------+
| 5 | P6 | Itf.3 |Customer |SAV-specific Information|
| | | | | General Information |
+-----+------+------------------+---------+------------------------+
| 6 | P5 | Itf.4 |Customer | General Information |
+-----+------+------------------+---------+------------------------+
| 7 | P5 | Itf.1 |Provider | General Information |
+-----+------+------------------+---------+------------------------+
Figure 3: An example for the SAV information base in AS 4
Wu, et al. Expires 26 January 2024 [Page 8]
Internet-Draft Inter-domain SAVNET Architecture July 2023
+------------------+
| AS 3(P3) |
+-+/\------+/\+----+
/ \
/ \
/ \
Itf.1 / (C2P) \
+------------------+ \
| AS 4(P4) | \
++/\+---+/\+---+/\++ \
Itf.2 / | Itf.3 \ Itf.4 \
P6[AS 1, AS 2] / | \ \
P2[AS 2] / | \ \
/ (C2P) | \ \
+----------------+ | \ \
| AS 2(P2) | | P1[AS 1] \ P5[AS 5] \ P5[AS 5]
+----------+/\+--+ | P6[AS 1] \ \
\ | NO_EXPORT \ \
P6[AS 1] \ | \ \
P1[AS 1] \ | \ \
NO_EXPORT \ (C2P) | (C2P) (C2P) \ (C2P) \
+----------------+ +----------------+
| AS 1(P1, P6) | | AS 5(P5) |
+----------------+ +----------------+
Figure 4: An example of AS topology
Each row of the SIB contains an index, prefix, AS-level valid
incoming interface for the prefix, incoming direction, and the
corresponding sources of these information. The incoming direction
consists of customer, provider, and peer. In order to provide a
clear illustration of the SIB, Figure 3 depicts an example of an SIB
established in AS 4. As shown in Figure 4, AS 4 has four AS-level
interfaces, each connected to a different AS. Specifically, Itf.1 is
connected to AS 3, Itf.2 to AS 2, Itf.3 to AS 1, and Itf.4 to AS 5.
The arrows in the figure represent the commercial relationships
between ASes. AS 3 is the provider of AS 4 and AS 5, while AS 4 is
the provider of AS 1, AS 2, and AS 5, and AS 2 is the provider of AS
1. Assuming prefixes P1, P2, P3, P4, P5, and P6 are all the prefixes
in the network.
For example, in Figure 3, the row with index 0 indicates prefix P3's
valid incoming interface is Itf.1, the ingress direction of P3 is AS
4's provider AS (AS 3), and these information is from the RIB. Note
that the same SAV-related information may have multiple sources and
the SIB records them all, such as the rows with indexes 3, 5, and 6.
Wu, et al. Expires 26 January 2024 [Page 9]
Internet-Draft Inter-domain SAVNET Architecture July 2023
Recall that the inter-domain SAVNET architecture generates the SAV
table based on the SAV-related information in the SIB and their
priorities. Besides, in the case of an AS's provider/peer interfaces
where loose SAV rules are applicable, the inter-domain SAVNET
architecture generates blocklist to only block the prefixes that are
sure not to come from the provider interfaces, while in the case of
an AS's customer interfaces that necessitate stricter SAV rules, the
inter-domain SAVNET architecture generates allowlist to only permit
the prefixes in the SAV table.
Additionally, take the SIB in Figure 3 as an example to illustrate
how the inter-domain SAVNET architecture generates the SAV table to
perform SAV in the data plane. AS 4 can conduct SAV at its
interfaces as follows: SAV at the interface Itf.1 blocks P1, P2, and
P6 according to the rows with indexes 0, 1, 2, and 5 in the SIB, SAV
at the interface Itf.2 permits P1 and P2 according to the rows with
indexes 1 and 2 in the SIB, SAV at the interface Itf.3 permits P6
according to the row with index 5 in the SIB, and SAV at the
interface Itf.4 permits P5 according to the row with index 6 in the
SIB.
4.2. SAV-specific Protocol
+---------------------+ +---------------------+
| AS | SAV-specific | AS |
| +----------------+ | Messages | +----------------+ |
| | SAV-specific |<-|--------------|->| SAV-specific | |
| |Protocol Speaker| | | |Protocol Speaker| |
| +----------------+ | | +----------------+ |
+---------------------+ +---------------------+
Figure 5: Communicating SAV-specific Messages with SAV-specific
Protocol between ASes
As shown in Figure 5, SAV-specific Messages are used to propagate or
originate the information on prefixes and their incoming interfaces
between ASes by the SAV-specific Protocol Speakers. Within an AS,
the SAV-specific Protocol Speaker can obtain the next hop of the
corresponding prefixes based on the routing table from the local RIB
and use SAV-specific Messages to carry the next hops of the
corresponding prefixes and propagate them between ASes with SAV-
specific Protocol.
The SAV-specific protocol should define the SAV-specific information
to be communicated, the data structure or format to communicate the
information, and the operations and timing for originating,
processing, propagating, and terminating the messages which carry the
information. The SAV-specific protocol speaker is the entity to
Wu, et al. Expires 26 January 2024 [Page 10]
Internet-Draft Inter-domain SAVNET Architecture July 2023
support the SAV-specific protocol. To generate the SAV-specific
Information, the SAV-specific Protocol Speaker connects to other SAV-
specific Protocol Speakers in other ASes, receives, processes,
generates, or terminates SAV-specific Messages. Then, it obtains the
ASN, the prefixes, the AS-level interfaces to receive the messages,
and their incoming AS direction for maintaining the SIB. It is
important to note that the SAV-specific Protocol Speaker within an AS
has the capability to establish connections with multiple SAV-
specific Protocol Speakers from different ASes, relying on either
manual configurations by operators or an automatic mechanism.
The need for a SAV-specific protocol arises from the facts that the
SAV-specific Information needs to be obtained and communicated
between ASes. Different from the general information such routing
information from the RIB, there is no existing mechanisms which can
support the perception and communication of SAV-specific information
between ASes. Hence, a unified SAV-tailored protocol is needed to
provide a medium and set of rules to establish communication between
different ASes for the exchange of SAV-specific information.
Moreover, the preferred AS paths of an AS may change over time due to
route changes, including source prefix change and AS path change.
The SAV-specific Protocol Speaker should launch SAV-specific Messages
to adapt to the route changes in a timely manner. Inter-domain
SAVNET should handle route changes carefully to avoid false
positives. The reasons for leading to false positives may include
late detection of route changes, delayed message transmission, or
packet losses. However, the detailed design of the SAV-specific
protocol for dealing with route changes is outside the scope of this
document.
4.3. SAV Information Base Manager
SAV Information Base Manager (SIM) consolidates SAV-related
information from the SAV-specific information and general information
to initiate or update the SIB, while it generates SAV rules to
populate the SAV table in the dataplane according to the SIB. The
detailed collection methods of the SAV-related information depend on
the deployment and implementation of the inter-domain SAV mechanisms
and are out of scope for this document.
Using the SIB, SIM produces <Prefix, Interface> pairs to populate the
SAV table, which represents the prefix and its legitimate incoming
interface. It is worth noting that the interfaces in the SIB are
logical AS-level interfaces and need to be mapped to the physical
interfaces of border routers within the AS.
Wu, et al. Expires 26 January 2024 [Page 11]
Internet-Draft Inter-domain SAVNET Architecture July 2023
+------------------------------------+
| Source Prefix | Incoming Interface |
+---------------+--------------------+
| P1 | 1 |
+---------------+--------------------+
| P2 | 2 |
+---------------+--------------------+
| P3 | 3 |
+------------------------------------+
Figure 6: An example of SAV table
Figure 6 shows an example of the SAV table. The packets coming from
other ASes will be validated by the SAV table. 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 or reported.
"Unknown" means there is no source prefix in SAV table covering the
source address. The packet with "unknown" addresses can be dropped
or permitted or reported, which depends on the choice of operators.
The structure and usage of SAV table can refer to [sav-table].
4.4. Management Channel and Information Channel
+------+
| | Management Channel +--------------------------------+
| |<========================| Network Operators |
| | +--------------------------------+
| |
| | Information Channel +--------------------------------+
| |<----------------------->| SAV-specific Protocol Speaker |
| | +--------------------------------+
| SIM |
| | Information Channel +--------------------------------+
| |<------------------------| RPKI ROA Obj. and ASPA Obj. |
| | +--------------------------------+
| |
| | Information Channel +--------------------------------+
| |<------------------------| RIB |
| | +--------------------------------+
+------+
Wu, et al. Expires 26 January 2024 [Page 12]
Internet-Draft Inter-domain SAVNET Architecture July 2023
Figure 7: The management channel and information channel for
collecting SAV- related information from different SAV
information sources
The SAV-specific Information relies on the communication between SAV-
specific Protocol Speakers within ASes and the general information
may be from multiple sources, such as the RIB and RPKI ROA objects
and ASPA objects. Therefore, as illustrated in Figure 7, the SIM
needs to receive the SAV-related information from SAV-specific
Protocol Speaker, RIB, and RPKI ROA objects and ASPA objects. We
abstract the connections used to collect the SAV-related information
from the sources as Infomation Channel. Also, the network operators
can operate the SIB by manual configurations, such as YANG, CLI, RTBH
[RFC5635], and Flowspec [RFC8955], where the approaches to implement
these are abstracted as Management Channel.
The primary purpose of the management channel is to deliver manual
configurations of network operators. Examples of such information
include, but are not limited to:
* SAV configurations using YANG, CLI, RTBH, or Flowspec.
* SAVNET operation and management.
* Inter-domain SAVNET provisioning.
Note that the information can be delivered at anytime and is required
reliable delivery for the management channel implementation.
The information channel serves as a means to transmit the SAV-
specific Information and general information from various sources
including the RIB and RPKI ROA objects and ASPA Objects.
Additionally, it can carry telemetry information, such as metrics
pertaining to forwarding performance, the count of spoofing packets
and discarded packets, provided that the inter-domain SAVNET has
access to such data. The information channel can include information
regarding the prefixes associated with the spoofing traffic, as
observed until the most recent time. It is worth noting that the
information channel may need to operate over a network link that is
currently under a source address spoofing attack. As a result, it
may experience severe packet loss and high latency due to the ongoing
attack.
Wu, et al. Expires 26 January 2024 [Page 13]
Internet-Draft Inter-domain SAVNET Architecture July 2023
5. Partial/Incremental Deployment
The inter-domain SAVNET architecture MUST ensure support for partial/
incremental deployment as it is not feasible to deploy it
simultaneously in all ASes. Within the architecture, the general
information like the topological information from RPKI ROA Objects
and ASPA Objects and the routing information from the RIB can be
obtained locally when the corresponding sources are available.
Furthermore, it is not mandatory for all ASes to deploy SAV-specific
Protocol Speakers even for SAV-specific Information. Instead, a SAV-
specific Protocol Speaker can effortlessly establish a logical
neighboring relationship with another AS that has deployed a SAV-
specific Protocol Speaker. This flexibility enables the architecture
to accommodate varying degrees of deployment, promoting
interoperability and collaboration among participating ASes.
During the partial/incremental deployment of SAV-specific protocol
speaker, the SAV-specific Information for the ASes which do not
deploy SAV-specific protocol speaker can not be obtained. To protect
the prefixes of these ASes, inter-domain SAVNET architecture can use
the SAV-related information from the general information in the SIB
to generate SAV rules. At least, the routing information from the
RIB or FIB can be always available in the SIB.
As more ASes adopt the inter-domain SAVNET architecture, the
"deployed area" expands, thereby increasing the collective defense
capability against source address spoofing. Furthermore, if multiple
"deployed areas" can be logically interconnected across "non-deployed
areas", these interconnected "deployed areas" can form a logical
alliance, providing enhanced protection against address spoofing.
Especially, along with more ASes deploy SAV-specific protocol speaker
and support the communication of SAV-specific Information, the
generated SAV rules of the inter-domain SAVNET architecture to
protect these ASes will become more accurate, as well as enchancing
the protection capability agaist source address spoofing for the
inter-domain SAVNET architecture.
In addition, releasing the SAV functions of the inter-domain SAVNET
architecture incrementally is one potential way to reduce the
deployment risks and can be considered in its deployment by network
operators:
* First, the inter-domain SAVNET can only do the measurement in the
data plane and do not take any other actions. Based on the
measurement data, the operators can evaluate the effect of the
inter-domain SAVNET on the legitimate traffic, including
validation accuracy and forwarding performance, as well as the
operational overhead.
Wu, et al. Expires 26 January 2024 [Page 14]
Internet-Draft Inter-domain SAVNET Architecture July 2023
* Second, the inter-domain SAVNET can open the function to limit the
rate of the traffic that is justified as spoofing traffic. The
operators can further evaluate the effect of the inter-domain
SAVNET on the legitimate traffic and spoofing traffic, such as
limiting the rate of all the spoofing traffic without hurting the
legitimate traffic.
* Third, when the validation accuracy, forwarding performance, and
operational overhead have been verified on a large scale by the
live network, the inter-domain SAVNET can open the function to
directly block the spoofing traffic that is justified by the SAV
table in the data plane.
6. Convergence Considerations
Convergence issues SHOULD be carefully considered in inter-domain SAV
mechanisms due to the dynamic nature of the Internet. Internet
routes undergo continuous changes, and SAV rules MUST proactively
adapt to these changes, such as prefix and topology changes, in order
to prevent false positives or reduce false negatives. To effectively
track these changes, the SIM should promptly collect SAV-related
information from various SAV information sources and consolidate them
in a timely manner.
In particular, it is essential for the SAV-specific Protocol Speakers
to proactively communicate the changes of the SAV-specific
Information between ASes and adapt to route changes promptly.
However, during the routing convergence process, the real forwarding
paths of prefixes can undergo rapid changes within a short period.
The changes of the SAV-specific Information may not communicated in
time between ASes to update SAV rules, false positives or false
negatives may happen. Such inaccurate validation is caused by the
delays in communicating SAV-specific Information between ASes, which
occur due to the factors like packet losses, unpredictable network
latencies, or message processing latencies. The design of the SAV-
specific protocol should consider these issues to reduce the
inaccurate validation.
Besides, for the inter-domain SAVNET architecture, the potential ways
to handle the convergence issues of the SAV-specific protocol is to
consider using the general information such as routing information
from the RIB to generate temporary SAV rules until the convergence
process of the SAV-specific protocol is finished. The inter-domain
SAVNET architecture can generate looser SAV rules to reduce false
positives based on the general information, and thus reduce the
impact to the legitimate traffic.
Wu, et al. Expires 26 January 2024 [Page 15]
Internet-Draft Inter-domain SAVNET Architecture July 2023
7. Management Considerations
It is crucial to consider the operations and management aspects of
SAV information sources, the SAV-specific protocol, SIB, SIM, and SAV
table in the inter-domain SAVNET architecture. The following
guidelines should be followed for their effective management:
First, management interoperability should be supported across devices
from different vendors or different releases of the same product,
based on a unified data model such as YANG [RFC6020]. This is
essential because the Internet comprises devices from various vendors
and different product releases that coexist simultaneously.
Second, scalable operation and management methods such as NETCONF
[RFC6241] and syslog protocol [RFC5424] should be supported. This is
important as an AS may have hundreds or thousands of border routers
that require efficient operation and management.
Third, management operations, including default initial
configuration, alarm and exception reporting, logging, performance
monitoring and reporting for the control plane and data plane, as
well as debugging, should be designed and implemented in the
protocols or protocol extensions. These operations can be performed
either locally or remotely, based on the operational requirements.
By adhering to these rules, the management of SAV information sources
and related components can be effectively carried out, ensuring
interoperability, scalability, and efficient operations and
management of the inter-domain SAVNET architecture.
8. Security Considerations
In the inter-domain SAVNET architecture, the SAV-specific Protocol
Speaker plays a crucial role in generating and disseminating SAV-
specific Messages across different ASes. To safeguard against the
potential risks posed by a malicious AS generating incorrect or
forged SAV-specific Messages, it is important for the SAV-specific
Protocol Speakers to employ security authentication measures for each
received SAV-specific Message. The security threats faced by inter-
domain SAVNET can be categorized into two aspects: session security
and content security. Session security pertains to verifying the
identities of both parties involved in a session and ensuring the
integrity of the session content. Content security, on the other
hand, focuses on verifying the authenticity and reliability of the
session content, thereby enabling the identification of forged SAV-
specific Messages.
The threats to session security include:
Wu, et al. Expires 26 January 2024 [Page 16]
Internet-Draft Inter-domain SAVNET Architecture July 2023
* Session identity impersonation: This occurs when a malicious
router deceitfully poses as a legitimate peer router to establish
a session with the targeted router. By impersonating another
router, the malicious entity can gain unauthorized access and
potentially manipulate or disrupt the communication between the
legitimate routers.
* Session integrity destruction: In this scenario, a malicious
intermediate router situated between two peering routers
intentionally tampers with or destroys the content of the relayed
SAV-specific Message. By interfering with the integrity of the
session content, the attacker can disrupt the reliable
transmission of information, potentially leading to
miscommunication or inaccurate SAV-related data being propagated.
The threats to content security include:
* Message alteration: A malicious router has the ability to
manipulate or forge any portion of a SAV-specific Message. For
example, the attacker may employ techniques such as using a
spoofed Autonomous System Number (ASN) or modifying the AS Path
information within the message. By tampering with the content,
the attacker can potentially introduce inaccuracies or deceive the
receiving ASes, compromising the integrity and reliability of the
SAV-related information.
* Message injection: A malicious router injects a seemingly
"legitimate" SAV-specific Message into the communication stream
and directs it to the corresponding next-hop AS. This type of
attack can be likened to a replay attack, where the attacker
attempts to retransmit previously captured or fabricated messages
to manipulate the behavior or decisions of the receiving ASes.
The injected message may contain malicious instructions or false
information, leading to incorrect SAV rule generation or improper
validation.
* Path deviation: A malicious router intentionally diverts a SAV-
specific Message to an incorrect next-hop AS, contrary to the
expected path defined by the AS Path. By deviating from the
intended routing path, the attacker can disrupt the proper
dissemination of SAV-related information and introduce
inconsistencies or conflicts in the validation process. This can
undermine the effectiveness and accuracy of source address
validation within the inter-domain SAVNET architecture.
Overall, inter-domain SAVNET shares similar security threats with BGP
and can leverage existing BGP security mechanisms to enhance both
session and content security. Session security can be enhanced by
Wu, et al. Expires 26 January 2024 [Page 17]
Internet-Draft Inter-domain SAVNET Architecture July 2023
employing session authentication mechanisms used in BGP, such as MD5,
TCP-AO, or Keychain. Similarly, content security can benefit from
the deployment of existing BGP security mechanisms like RPKI, BGPsec,
and ASPA. While these mechanisms can address content security
threats, their widespread deployment is crucial. Until then, it is
necessary to develop an independent security mechanism specifically
designed for inter-domain SAVNET. One potential approach is for each
origin AS to calculate a digital signature for each AS path and
include these digital signatures within the SAV-specific Messages.
Upon receiving a SAV-specific Message, the SAV-specific Protocol
Speaker can verify the digital signature to ascertain the message's
authenticity. Detailed security designs and considerations will be
addressed in a separate draft, ensuring the robust security of inter-
domain SAVNET.
9. Privacy Considerations
TBD
10. IANA Considerations
This document has no IANA requirements.
11. Scope
In this architecture, the choice of protocols used for communication
between the SIM and different SAV information sources is not limited.
The inter-domain SAVNET architecture presents considerations on how
to consolidate SAV-related information from various sources to
generate SAV rules and perform SAV using the SAV table in the
dataplane. The detailed design and implementation for SAV rule
generation and SAV execution depend on the specific inter-domain SAV
mechanisms employed.
This document does not cover administrative or business agreements
that may be established between the involved inter-domain SAVNET
parties. These considerations are beyond the scope of this document.
However, it is assumed that authentication and authorization
mechanisms can be implemented to ensure that only authorized ASes can
communicate SAV-related information.
12. Assumptions
This document makes the following assumptions:
Wu, et al. Expires 26 January 2024 [Page 18]
Internet-Draft Inter-domain SAVNET Architecture July 2023
* All ASes where the inter-domain SAVNET is deployed are assumed to
provide the necessary connectivity between SAV-specific protocol
speaker and any intermediate network elements. However, the
architecture does not impose any specific limitations on the form
or nature of this connectivity.
* Congestion and resource exhaustion can occur at various points in
the inter-domain networks. Hence, in general, network conditions
should be assumed to be hostile. The inter-domain SAVNET
architecture must be capable of functioning reliably under all
circumstances, including scenarios where the paths for delivering
SAV-related information are severely impaired. It is crucial to
design the inter-domain SAVNET system with a high level of
resilience, particularly under extremely hostile network
conditions. The architecture should ensure uninterrupted
communication between inter-domain SAV-specific protocol speakers,
even when data-plane traffic saturates the link.
* The inter-domain SAVNET architecture does not impose rigid
requirements for the SAV information sources that can be used to
generate SAV rules. Similarly, it does not dictate strict rules
on how to utilize the SAV-related information from diverse sources
or perform SAV in the dataplane. Network operators have the
flexibility to choose their approaches to generate SAV rules and
perform SAV based on their specific requirements and preferences.
Operators can either follow the recommendations outlined in the
inter-domain SAVNET architecture or manually specify the rules for
governing the use of SAV-related information, the generation of
SAV rules, and the execution of SAV in the dataplane.
* The inter-domain SAVNET architecture does not impose restrictions
on the selection of the local AS with which AS to communicate SAV-
specific information. The ASes have the flexibility to establish
SAV-specific protocol connections based on the manual
configurations set by operators or other automatic mechanisms.
* The inter-domain SAVNET architecture provides the flexibility to
accommodate Quality-of-Service (QoS) policy agreements between
SAVNET-enabled ASes or local QoS prioritization measures, but it
does not make assumptions about their presence. These agreements
or prioritization efforts are aimed at ensuring the reliable
delivery of SAV-specific Information between SAV-specific protocol
speakers. It is important to note that QoS is considered as an
operational consideration rather than a functional component of
the inter-domain SAVNET architecture.
Wu, et al. Expires 26 January 2024 [Page 19]
Internet-Draft Inter-domain SAVNET Architecture July 2023
* The information and management channels are loosely coupled and
are used for collecting SAV-related information from different
sources, and how the inter-domain SAVNET synchronize the
management and operation configurations is out of scope of this
document.
13. Contributors
Igor Lubashev
Akamai Technologies
145 Broadway
Cambridge, MA, 02142
United States of America
Email: ilubashe@akamai.com
Many thanks to Igor Lubashev for the significantly helpful revision
suggestions.
14. References
14.1. Normative References
[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/rfc/rfc8174>.
[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/rfc/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/rfc/rfc8704>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/rfc/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/rfc/rfc6241>.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424,
DOI 10.17487/RFC5424, March 2009,
<https://www.rfc-editor.org/rfc/rfc5424>.
Wu, et al. Expires 26 January 2024 [Page 20]
Internet-Draft Inter-domain SAVNET Architecture July 2023
[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/rfc/rfc2119>.
14.2. Informative References
[sav-table]
"Source Address Validation Table Abstraction and
Application", 2023, <https://datatracker.ietf.org/doc/
draft-huang-savnet-sav-table/>.
[inter-domain-ps]
"Source Address Validation in Inter-domain Networks Gap
Analysis, Problem Statement, and Requirements", 2023,
<https://datatracker.ietf.org/doc/draft-wu-savnet-inter-
domain-problem-statement/>.
[RFC5635] Kumari, W. and D. McPherson, "Remote Triggered Black Hole
Filtering with Unicast Reverse Path Forwarding (uRPF)",
RFC 5635, DOI 10.17487/RFC5635, August 2009,
<https://www.rfc-editor.org/rfc/rfc5635>.
[RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M.
Bacher, "Dissemination of Flow Specification Rules",
RFC 8955, DOI 10.17487/RFC8955, December 2020,
<https://www.rfc-editor.org/rfc/rfc8955>.
Acknowledgements
Many thanks to Alvaro Retana, Kotikalapudi Sriram, Rüdiger Volk,
Xueyan Song, Ben Maddison, Jared Mauch, Joel Halpern, Aijun Wang,
Jeffrey Haas, Xiangqing Chang, Changwang Lin, Mingxing Liu, Zhen Tan,
etc. for their valuable comments on this document.
Authors' Addresses
Jianping Wu
Tsinghua University
Beijing
China
Email: jianping@cernet.edu.cn
Dan Li
Tsinghua University
Beijing
China
Wu, et al. Expires 26 January 2024 [Page 21]
Internet-Draft Inter-domain SAVNET Architecture July 2023
Email: tolidan@tsinghua.edu.cn
Mingqing Huang
Huawei
Beijing
China
Email: huangmingqing@huawei.com
Li Chen
Zhongguancun Laboratory
Beijing
China
Email: lichen@zgclab.edu.cn
Nan Geng
Huawei
Beijing
China
Email: gengnan@huawei.com
Libin Liu
Zhongguancun Laboratory
Beijing
China
Email: liulb@zgclab.edu.cn
Lancheng Qin
Tsinghua University
Beijing
China
Email: qlc19@mails.tsinghua.edu.cn
Wu, et al. Expires 26 January 2024 [Page 22]