Inter-domain Source Address Validation (SAVNET) Architecture
draft-wu-savnet-inter-domain-architecture-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 "Replaced".
|
|
|---|---|---|---|
| Authors | Jianping Wu , Dan Li , Mingqing(Michael) Huang , Li Chen , Nan Geng , Libin Liu , Lancheng Qin | ||
| Last updated | 2023-06-01 (Latest revision 2023-03-13) | ||
| 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-02
Internet Engineering Task Force J. Wu
Internet-Draft D. Li
Intended status: Standards Track Tsinghua University
Expires: 3 December 2023 M. Huang
Huawei
L. Chen
Zhongguancun Laboratory
N. Geng
Huawei
L. Liu
Zhongguancun Laboratory
L. Qin
Tsinghua University
1 June 2023
Inter-domain Source Address Validation (SAVNET) Architecture
draft-wu-savnet-inter-domain-architecture-02
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-
related information from various sources. It integrates existing SAV
mechanisms and offers ample design space for new inter-domain SAV
mechanisms. Instead of delving into protocol extensions or
implementations, this document primarily focuses on defining the
interconnections between architectural elements, components, and the
SAV-related information required for deploying an inter-domain SAV
mechanism.
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 3 December 2023 [Page 1]
Internet-Draft Inter-domain SAVNET Architecture June 2023
This Internet-Draft will expire on 3 December 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. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Inter-domain SAVNET Architecture . . . . . . . . . . . . . . 7
4.1. SAV Information Base . . . . . . . . . . . . . . . . . . 9
4.2. SAV-tailored Protocol . . . . . . . . . . . . . . . . . . 12
4.3. SAV Information Base Manager . . . . . . . . . . . . . . 13
4.4. Data Channel and Signal Channel . . . . . . . . . . . . . 14
5. Partial Deployment . . . . . . . . . . . . . . . . . . . . . 15
6. Convergence Considerations . . . . . . . . . . . . . . . . . 16
7. Management Considerations . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
12.1. Normative References . . . . . . . . . . . . . . . . . . 20
12.2. Informative References . . . . . . . . . . . . . . . . . 21
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
Wu, et al. Expires 3 December 2023 [Page 2]
Internet-Draft Inter-domain SAVNET Architecture June 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 defining the
architectural relationships, components, and SAV-related information
used in such deployments, this document aims to promote consistency,
interoperability, and collaboration among ASes. The inter-domain
SAVNET architecture empowers ASes to generate precise SAV rules by
leveraging SAV-related information from various sources, including
Manual Configurations, Routing Information (such as RPKI ROA Objects
and ASPA Objects, and RIB), and SAV-tailored Messages from other
ASes. This information consists of legitimate or nearly legitimate
prefixes of ASes and their corresponding legitimate incoming
interfaces. By consolidating this information, the inter-domain
SAVNET architecture improves the accuracy of SAV rules beyond what
can be achieved solely based on the local RIB. Additionally, it
ensures that the source addresses of ASes providing SAV-tailored
information with SAV-tailored Messages are also protected.
This document primarily describes a high-level architecture for
consolidating SAV-related information from various sources 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 solutions, allowing implementers to adapt and
implement the architecture based on their specific requirements and
network environments.
1.1. Scope
In this architecture, the choice of protocols used for communication
between the SAVNET agent 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 of
the SAV rule generation and SAV execution depend on the specific
inter-domain SAV mechanisms employed.
Wu, et al. Expires 3 December 2023 [Page 3]
Internet-Draft Inter-domain SAVNET Architecture June 2023
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.
A detailed set of requirements for inter-domain SAV are discussed in
[inter-domain-ps]. The inter-domain SAVNET architecture is designed
to adhere to those requirements, and this document primarily
introduces a new scalability requirement in addition to the existing
ones.
1.2. Assumptions
This document makes the following assumptions:
* All ASes where the inter-domain SAVNET is deployed are assumed to
provide the necessary connectivity between SAVNET agents 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 SAVNET agents, 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 using the SAV table in the dataplane. Network
operators have the flexibility to choose their approach based on
their specific requirements and preferences. Operators can either
follow the recommendations outlined in the inter-domain SAVNET
architecture or manually define the rules governing the use of
SAV-related information, the generation of SAV rules, and the
execution of SAV in the dataplane.
Wu, et al. Expires 3 December 2023 [Page 4]
Internet-Draft Inter-domain SAVNET Architecture June 2023
* The inter-domain SAVNET architecture does not impose restrictions
on the selection of the local AS with which AS communicates SAV-
tailored information. The ASes have the flexibility to establish
SAV-tailored 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 inter-domain SAVNET messages between SAVNET agents.
It's important to note that QoS is considered as an operational
consideration rather than a functional component of the inter-
domain SAVNET architecture.
* The signal and data 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.
1.3. 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 forwading paths:
The paths that the legitimate traffic goes through in the data
plane.
SAV-related information:
The information is used to generate SAV rules and can be from
various sources, such as Manual Configurations, RIB, SAV-tailored
Messages of ASes, etc.
Wu, et al. Expires 3 December 2023 [Page 5]
Internet-Draft Inter-domain SAVNET Architecture June 2023
SAV-tailored message:
The message is used to carry the SAV-tailored information between
ASes and can be communicated following a dedicated SAV
communication protocol.
SAVNET agent:
Any SAVNET-aware software module capable of collecting SAV-related
information. It can be a module to accept Manual Configurations
or process routing information, SAV-tailored protocol speaker, or,
as a logical agent.
Improper block:
The validation results that the packets with legitimate source
addresses are blocked improperly due to inaccurate SAV rules.
Improper permit:
The validation results that the packets with spoofed source
addresses are permitted improperly due to inaccurate SAV rules.
SAV information base:
SAV information base is for storing SAV-related information
collected from various sources.
SAV information base management protocol:
SAV information base management protocol represents any protocols
for operating and managing the SAV information base.
3. Design Goals
The inter-domain SAVNET architecture aims to improve SAV accuracy and
facilitate partial deployment with low operational overhead, as well
as supporting developing a unified SAV-tailored protocol to
communicate SAV-tailored messages between ASes. The overall goal can
be broken down into the following aspects:
* First, the inter-domain SAVNET architecture should learn SAV-
related information that consists of real forwarding paths or
permissible paths of prefixes that can cover the real forwarding
paths, and generate accurate and finer-grained SAV rules
automatically based on the learned information to avoid improper
block and reduce improper permit as much as possible.
* Second, the inter-domain SAVNET architecture should adapt to
dynamic networks and asymmetric routing scenarios automatically.
Wu, et al. Expires 3 December 2023 [Page 6]
Internet-Draft Inter-domain SAVNET Architecture June 2023
* Third, 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.
* Fourth, the inter-domain SAVNET architecture should support to
communicate SAV-tailored information with a unified SAV-tailored
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.
SAV-related information can be obtained from different sources,
including RIB, Manual Configurations, or SAV-tailored Messages
communicated between ASes. The inter-domain SAVNET architecture
consolidates SAV-related information from multiple sources and
generates SAV rules automatically, and adapts proactively to route
changes in a timely manner to achieve the goals outlined above.
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 3 December 2023 [Page 7]
Internet-Draft Inter-domain SAVNET Architecture June 2023
+--------------------+
| Other ASes |
+--------------------+
|SAV-tailored
|Messages
+-------------------------------------------------------------+
| |YANG |CLI |SMP |RIB |ROA |ASPA | AS |
| \/ \/ \/ \/ \/ \/ \/ |
| +---------------+ +-----------------+ +-------------------+ |
| | Manual | | Routing | | SAV-tailored | |
| | Configuration | | Information | | 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-related information
from multiple sources, which can be categorized into three types:
Manual Configuration, Routing Information, and SAV-tailored
Information. The SAV information base manager (SIM) uses the
collected SAV-related information to maintain the SAV Information
Base (SIB), and then generate SAV rules based on the SIB and fill out
the SAV table in the dataplane.
Manual Configuration can be conducted by network operators using
various methods such as YANG, Command-Line Interface (CLI), and SIB
Management Protocol (SMP) like remote triggered black hole (RTBH)
[RFC5635] and FlowSpec [RFC8955]. The Routing Information can be
obtained within an AS and may come from RIB, Routing Information
Messages, or RPKI ROA objects and ASPA objects. And SAV-tailored
Information, which contains real forwarding paths of the prefixes, is
transmitted using SAV-tailored Messages from other ASes.
Wu, et al. Expires 3 December 2023 [Page 8]
Internet-Draft Inter-domain SAVNET Architecture June 2023
It is important to note that the inter-domain SAVNET architecture
does not require all the information sources to generate SAV rules.
All of the sources, including SAV-tailored Messages, are optional
depending on their availability and the operational needs of the
inter-domain SAV mechanisms. However, the SAV Information Base
Manager (SIM) and SAV table are necessary components for generating
SAV rules and performing SAV.
Additionally, inter-domain SAVNET architecture does not prescribe any
specific deployment models.
4.1. SAV Information Base
The SAV Information Base (SIB) is managed by the SAV Information Base
Manager, which consolidates SAV-related information from various
sources. Each row of the SIB contains an index, prefix, valid
incoming interface for the prefix, incoming direction, and the
corresponding sources of these SAV-related information.
+-----+------+------------------+---------+---------------------------+
|Index|Prefix|AS-level Interface|Direction| SAV Information Source |
+-----+------+------------------+---------+---------------------------+
| 0 | P1 | Itf.1 |Provider | SAV-tailored Message, RIB |
+-----+------+------------------+---------+---------------------------+
| 1 | P1 | Itf.2 |Provider | RIB |
+-----+------+------------------+---------+---------------------------+
| 2 | P2 | Itf.2 |Provider | Manual Configuration |
+-----+------+------------------+---------+---------------------------+
| 3 | P3 | Itf.3 | Peer | SAV-tailored Message, |
| | | | |RPKI ROA Obj. and ASPA Obj.|
+-----+------+------------------+---------+---------------------------+
| 4 | P4 | Itf.4 |Customer | SAV-tailored Message |
+-----+------+------------------+---------+---------------------------+
| 5 | P4 | Itf.5 |Customer |RPKI ROA Obj. and ASPA Obj.|
+-----+------+------------------+---------+---------------------------+
| 6 | P5 | Itf.5 |Customer | RIB |
+-----+------+------------------+---------+---------------------------+
Figure 2: An example for the SAV information base
Wu, et al. Expires 3 December 2023 [Page 9]
Internet-Draft Inter-domain SAVNET Architecture June 2023
+------------+ (P2P) +------------+
| AS 1(P1) +---------+ AS 2(P2) |
+--------/\--+ +--/\--------+
\ /
(C2P) \ / (C2P)
Itf.1 \ / Itf.2
+------------+ (P2P) +------------+
| AS X +-----------+ AS 3(P3) |
+-/\------/\-+ Itf.3 +------------+
Itf.4 | Itf.5 \
| \
| \ (C2P)
| +------------+
| | AS 5(P5) |
| +-/\---------+
| /
(C2P) | / (C2P)
+------------+
| AS 4(P4) |
+------------+
Figure 3: AS topology
In order to provide a clear illustration of the SIB, Figure 2 depicts
an example of an SIB established in AS X. As shown in Figure 3, AS X
has five interfaces, each connected to a different AS. Specifically,
Itf.1 is connected to AS 1, Itf.2 to AS 2, Itf.3 to AS 3, Itf.4 to AS
4, and Itf.5 to AS 5. The arrows in the figure represent the
commercial relationships between ASes, with AS 1 and AS 2 serving as
providers for AS X, AS X as the lateral peer of AS 3, AS X as the
provider for AS 4 and AS 5, and AS 5 as the provider for AS 4.
For example, in Figure 2, the row with index 0 indicates prefix P1's
valid incoming interface is Itf.1, the ingress direction of P1 is AS
X's Provider AS, and these information is from the SAV-tailored
Messages and RIB. Note that a SAV-related information may have
multiple sources and the SIB records them all.
In sum, the SIB can be consolidated according to the SAV-related
information from the following sources:
* Manual Configuaration: the SIB can obtain SAV-related
configurations from the Manual Configurations of network operators
using various methods, such as YANG, Command-Line Interface (CLI),
and the SIM like RTBH [RFC5635] and FlowSpec [RFC8955].
Wu, et al. Expires 3 December 2023 [Page 10]
Internet-Draft Inter-domain SAVNET Architecture June 2023
* SAV-tailored Message: the SIB can obtain real forwarding paths of
the prefixes from the processed SAV-tailored Messages from other
ASes.
* RPKI ROA Objects and ASPA Objects: the SIB can obtain the
topological information from the RPKI ROA objects and ASPA objects
over the local routing instance.
* Routing Information Base (RIB): the SIB can obtain the prefixes
and their permissible routes including the optional ones and
optional ones from the RIB.
+---------------------------------------+--------+
| SAV Information Source |Priority|
+---------------------------------------+--------+
| Manual Configuration | 1 |
+---------------------------------------+--------+
| SAV-tailored Message | 2 |
+---------------------------------------+--------+
| RPKI ROA Objects and ASPA Objects | 3 |
+---------------------------------------+--------+
| RIB | 4 |
+---------------------------------------+--------+
Figure 4: Priority ranking for the SAV information sources
The SIB is maintained according to the SAV-related information from
all the above information sources or part of them. It explicitly
records the sources of the SAV-related information and can be
compressed to reduce its size. Inter-domain SAVNET architecture
allows operators to specify how to use the SAV-related information in
the SIB by manual configurations. In fact, the SAV information
sources also give indications about how to use the SAV-related
information from them.
Wu, et al. Expires 3 December 2023 [Page 11]
Internet-Draft Inter-domain SAVNET Architecture June 2023
Notably, the SAV information sources are not equivalent, and finer-
grained information sources, such as SAV-tailored Messages, can help
generate more accurate SAV rules to reduce improper permit or avoid
improper block. Figure 4 proposes the priority ranking for the SAV
information sources in the SIB. Inter-domain SAVNET architecture can
generate SAV rules based on the priorities of SAV information
sources. For example, for the provider interfaces which can use
loose SAV rules, inter-domain SAVNET may use the SAV-related
information from all the sources (e.g., the rows with index 0, 1, and
2 in Figure 2) to generate rules, while for the customer interfaces
which need more strict SAV rules, inter-domain SAVNET architecture
may only use the ones (e.g., the rows with index 4 and 6 in
Figure 2). Here, inter-domain SAVNET architecture uses the row with
index 6 to generate SAV rules since only SAV-related information from
the RIB is available for prefix P5.
4.2. SAV-tailored Protocol
+-----------------------+ +-----------------------+
| AS | SAV-tailored | AS |
| +------------------+ | Messages | +------------------+ |
| | SAV-tailored |<-|----------------|->| SAV-tailored | |
| | Protocol Speaker | | | | Protocol Speaker | |
| +------------------+ | | +------------------+ |
+-----------------------+ +-----------------------+
Figure 5: Communicating SAV-tailored messages between SAV-
tailored protocol speakers with SAV-tailored protocol
As shown in Figure 5, SAV-tailored Messages are used to propagate or
originate the real forwarding paths of prefixes between SAV-tailored
Protocol Speakers. Within an AS, the SAV-tailored Protocol Speaker
can obtain the next hop of the corresponding prefixes based on the
routing table from the local RIB and use SAV-tailored Messages to
carry the next hops of the corresponding prefixes and propagate them
between ASes.
To generate the real forwarding paths of prefixes, the SAV-tailored
Protocol Speaker connects to other SAV-tailored Protocol Speakers in
other ASes, receives, processes, generates, or terminates SAV-
tailored Messages. Then, it obtains the ASN, the prefixes, and their
incoming AS direction for maintaining the SIB. It is important to
note that the SAV-tailored Protocol Speaker within an AS has the
capability to establish connections with multiple SAV-tailored
Protocol Speakers from different ASes, relying on either manual
configurations by operators or a predetermined automatic mechanism.
Wu, et al. Expires 3 December 2023 [Page 12]
Internet-Draft Inter-domain SAVNET Architecture June 2023
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-tailored Protocol Speaker should launch SAV-tailored Messages
to adapt to the route changes in a timely manner. Inter-domain
SAVNET should handle route changes carefully to avoid improper block.
The reasons for this include late detection of route changes, delayed
message transmission, or packet losses. However, the detailed design
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 multiple sources and generates SAV rules. It uses
the SAV-related information to initiate or update the SIB and
generates SAV rules to populate the SAV table according to the SIB.
The collection methods of 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 (Prefixes, Interface) pairs to populate
the SAV table, which represents the legitimate prefixes for each
incoming interface. It's 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 corresponding AS.
+------------------------------------+
| Source Prefix | Incoming Interface |
+---------------+--------------------+
| P1 | 1 |
| P2 | 2 |
| P3 | 3 |
+------------------------------------+
Figure 6: An example of SAV table
Wu, et al. Expires 3 December 2023 [Page 13]
Internet-Draft Inter-domain SAVNET Architecture June 2023
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. "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 structure and usage of
SAV table can refer to [sav-table].
4.4. Data Channel and Signal Channel
+-------+
| | Data Channel +--------------------------------+
| |<==========================| Network Operators |
| | +--------------------------------+
| |
| | Signal Channel +--------------------------------+
| |<--------------------------| RPKI ROA and ASPA Cache Server |
| SAV | +--------------------------------+
| Agent |
| | Signal Channel +--------------------------------+
| |<--------------------------| RIB |
| | +--------------------------------+
| |
| | Signal Channel +--------------------------------+
| |<------------------------->| SAV Agent |
| | +--------------------------------+
+-------+
Figure 7: The data channel and signal channel connected to
different SAV information sources for collecting SAV-related
information
As illustrated in Figure 7, there are different modules to receive
SAV-related information from network operators, RIB, RPKI ROA objects
and ASPA objects, and other ASes: Data Channel and Signal Channel.
SAV Agent is a general term for the modules like manual configuration
processor, module for accessing RIB, RPKI validator, and SAV-tailored
protocol speaker.
Wu, et al. Expires 3 December 2023 [Page 14]
Internet-Draft Inter-domain SAVNET Architecture June 2023
The primary purpose of the data channel is to deliver SAV-related
information from Manual Configurations of network operators and
SAVNET-specialized configurations. Examples of such information
include, but are not limited to:
* SAV configurations using YANG.
* SAV configurations using CLI.
* SAV configurations using SMP.
* SAVNET operation and management.
* Inter-domain SAVNET provisioning.
Note that the information can be delivered at anytime and is required
reliable delivery for the data channel implementation.
The signal channel serves as a means to transmit SAV-related
information from various sources, including RIB, RPKI ROA objects,
ASPA objects, SAV-tailored messages from other SAV Agents in
different ASes, and routing messages. An SAV Agent can establish
connections with multiple SAV Agents belonging to different ASes
based on manual configurations by operators or a predetermined
automatic mechanism. Additionally, it can carry telemetry
information, such as metrics pertaining to forwarding performance,
the count of spoofing packets and discarded packets, provided that
the SAV Agent has access to such data. Moreover, the signal channel
can include information regarding the prefixes associated with the
spoofing traffic, as observed by the SAV Agent up until the most
recent time. It is worth noting that the signal 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.
5. Partial Deployment
The inter-domain SAVNET architecture MUST ensure support for partial
deployment as it is not feasible to deploy it simultaneously in all
ASes. Within the architecture, certain information such as operator
configurations, topological information, and routing information can
be obtained locally when the corresponding sources are available.
Furthermore, it is not mandatory for all ASes to deploy SAV-tailored
Protocol Speakers even for SAV-tailored information. Instead, a SAV-
tailored Protocol Speaker can effortlessly establish a logical
neighboring relationship with another AS that has deployed a SAV-
tailored Protocol Speaker. This flexibility enables the architecture
to accommodate varying degrees of deployment, promoting
Wu, et al. Expires 3 December 2023 [Page 15]
Internet-Draft Inter-domain SAVNET Architecture June 2023
interoperability and collaboration among participating ASes.
In general, the ASes that implement the inter-domain SAVNET
architecture cannot engage in source address spoofing against each
other. Additionally, non-deployed ASes are unable to send spoofed
packets to the deployed ASes by falsifying their source addresses.
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.
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 improper block or reduce improper permit actions. To
effectively track these changes, the SIM should promptly collect and
consolidate SAV-related information from various SAV information
sources.
When it comes to SAV-related information obtained from Manual
Configurations, the SAV Agent can directly receive the configurations
from network operators and the SIM can promptly generate the
corresponding SAV rules.
Regarding Routing Information, the mechanism can rely on the
convergence mechanism of routing protocols such as BGP. However, it
is important to note that there may be instances of inaccurate
validation before the route convergence process is fully completed.
This challenge is also observed in existing uRPF-based mechanisms.
Although temporary inconsistencies in forwarding paths during the
convergence process may occur, it may be acceptable as the real
forwarding paths of prefixes can fluctuate during this time.
Wu, et al. Expires 3 December 2023 [Page 16]
Internet-Draft Inter-domain SAVNET Architecture June 2023
For SAV-tailored information, it is essential for the SAV-tailored
Protocol Speaker to proactively send SAV-tailored Messages and adapt
to route changes promptly. However, there are challenges that need
to be addressed. First, during the routing convergence process, real
forwarding paths can undergo rapid changes within a short period.
Relying solely on temporary SAV-tailored information during this time
may lead to incorrect block decisions. Additionally, similar to
routing protocols, there is a possibility of inaccurate validation
during the convergence process of the SAV-tailored protocol due to
delays in SAV-tailored Messages. These delays can occur due to
factors like packet loss, unpredictable network latencies, or message
processing latencies.
To prevent improper block, it is crucial for the SAV-tailored
protocol to handle these challenges carefully. One approach is to
generate SAV rules automatically based on the available Routing
Information until the convergence process of the routing changes and
the SAV-tailored protocol is finalized. This ensures that the SAV-
tailored protocol adapts to the changing network conditions and
avoids making improper blocking decisions during the convergence
phase. Furthermore, a dedicated protocol like the SAV-tailored
protocol has the capability to control the synchronization timing of
SAV-tailored information between ASes.
7. Management Considerations
It is crucial to consider the operations and management aspects of
various SAV information sources, the SAV-tailored 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. 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.
Wu, et al. Expires 3 December 2023 [Page 17]
Internet-Draft Inter-domain SAVNET Architecture June 2023
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-tailored Protocol
Speaker plays a crucial role in generating and disseminating SAV-
tailored Messages across different ASes. To safeguard against the
potential risks posed by a malicious AS generating incorrect or
forged SAV-tailored Messages, it is important for the SAV-tailored
Protocol Speakers to employ security authentication measures for each
received SAV-tailored 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-
tailored Messages.
The threats to session security include:
* 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-tailored 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:
Wu, et al. Expires 3 December 2023 [Page 18]
Internet-Draft Inter-domain SAVNET Architecture June 2023
* Message alteration: A malicious router has the ability to
manipulate or forge any portion of a SAV-tailored 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-tailored 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-
tailored 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
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-tailored Messages.
Upon receiving a SAV-tailored Message, the SAV-tailored 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.
Wu, et al. Expires 3 December 2023 [Page 19]
Internet-Draft Inter-domain SAVNET Architecture June 2023
9. Privacy Considerations
This document should not affect the privacy of the Internet.
10. IANA Considerations
This document has no IANA requirements.
11. 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.
12. References
12.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>.
[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>.
[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>.
Wu, et al. Expires 3 December 2023 [Page 20]
Internet-Draft Inter-domain SAVNET Architecture June 2023
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424,
DOI 10.17487/RFC5424, March 2009,
<https://www.rfc-editor.org/rfc/rfc5424>.
[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>.
12.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>.
Acknowledgements
Many thanks to Alvaro Retana, Kotikalapudi Sriram, Rüdiger Volk,
Xueyan Song, Ben Maddison, Jared Mauch, Joel Halpern, Aijun Wang,
Jeffrey Haas, Fang Gao, 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
Email: tolidan@tsinghua.edu.cn
Wu, et al. Expires 3 December 2023 [Page 21]
Internet-Draft Inter-domain SAVNET Architecture June 2023
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 3 December 2023 [Page 22]