Internet-Draft Inter-domain SAVNET Architecture July 2023
Wu, et al. Expires 26 January 2024 [Page]
Workgroup:
Internet Engineering Task Force
Internet-Draft:
draft-wu-savnet-inter-domain-architecture-03
Published:
Intended Status:
Standards Track
Expires:
Authors:
J. Wu
Tsinghua University
D. Li
Tsinghua University
M. Huang
Huawei
L. Chen
Zhongguancun Laboratory
N. Geng
Huawei
L. Liu
Zhongguancun Laboratory
L. Qin
Tsinghua University

Inter-domain Source Address Validation (SAVNET) Architecture

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

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.

▲

Table of Contents

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.

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.

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:

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 

                           +--------------------------+
                           |         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 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

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

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

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

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:

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.

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:

The threats to content security include:

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-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:

13. Contributors

Igor Lubashev
Akamai Technologies
145 Broadway
Cambridge, MA, 02142
United States of America
Email: [email protected]

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, , <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, , <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, , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc6241>.
[RFC5424]
Gerhards, R., "The Syslog Protocol", RFC 5424, DOI 10.17487/RFC5424, , <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, , <https://www.rfc-editor.org/rfc/rfc2119>.

14.2. Informative References

[sav-table]
"Source Address Validation Table Abstraction and Application", , <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", , <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, , <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, , <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
Dan Li
Tsinghua University
Beijing
China
Mingqing Huang
Huawei
Beijing
China
Li Chen
Zhongguancun Laboratory
Beijing
China
Nan Geng
Huawei
Beijing
China
Libin Liu
Zhongguancun Laboratory
Beijing
China
Lancheng Qin
Tsinghua University
Beijing
China