| Internet-Draft | Inter-domain SAVNET Architecture | March 2023 |
| Wu, et al. | Expires 14 September 2023 | [Page] |
Source address validation (SAV) is critical to preventing attacks based on source IP address spoofing. The proposed inter-domain SAVNET architecture enables an AS to generate SAV rules based on SAV-related information from multiple sources. This architecture integrates existing SAV mechanisms and offers ample design space for new SAV mechanisms. The document focuses on architectural components and SAV-related information in an inter-domain SAVNET deployment, without specifying any protocols or protocol extensions.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 8174 [RFC8174].¶
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 14 September 2023.¶
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.¶
Attacks based on source IP address spoofing, such as reflective DDoS and flooding attacks, continue to pose significant challenges to Internet security. To mitigate such attacks in inter-domain networks, source address validation (SAV) is essential.¶
Although BCP84 [RFC3704][RFC8704] provides some SAV solutions, such as uRPF-based mechanisms, the existing SAV mechanisms have limitations in terms of validation accuracy and operational overhead [draft-wu-savnet-inter-domain-problem-statement]. These mechanisms generate SAV rules based only on the Routing Information Base (RIB) of the local AS. In cases of asymmetric routing, the generated rules may not match the incoming direction of packets originating from a specific source address, leading to improper block or improper permit problems. Consequently, despite the deployment of SAV, an AS may still suffer from source address spoofing attacks from other ASes.¶
To address the limitations of existing SAV mechanisms, this document proposes an inter-domain source address validation architecture (SAVNET) that provides a framework for developing new SAV mechanisms. The inter-domain SAVNET architecture enables an AS to generate precise SAV rules by leveraging SAV-related information from various sources, including Manual Configurations, RPKI ROA Objects and ASPA Objects, and Collaborative Messages from other ASes. This information consists of legitimate or nearly legitimate prefixes of the ASes, ensuring that the source addresses of the ASes providing such information are also protected. By incorporating this additional information, SAVNET enhances the accuracy of SAV rules beyond those generated solely based on the local RIB.¶
This document focuses on high-level architecture designs and does not specify protocols or protocol extensions.¶
SAV rule: The rule that indicates the valid incoming interfaces for a specific source prefix or that indicates the valid source prefixes for a specific interface.¶
SAV Table: The table or data structure that implements the SAV rules and is used for source address validation in the data plane.¶
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.¶
SIB: SAV information base that is for storing SAV-related information collected from different information sources.¶
SMP: SIB management protocol that represents any protocols for managing data in SIB.¶
The inter-domain SAVNET architecture aims to enhance SAV accuracy and facilitate partial deployment with low operational overhead. Achieving high accuracy requires deployment at all peer, customer, and provider interfaces of the ASes, while avoiding improper block and reducing as much improper permit as possible. To this end, the overall goal can be broken down into the following aspects:¶
To achieve the above goals, relying solely on local RIB data to generate SAV rules (such as FP-uRPF and EFP-uRPF) is insufficient. Additional SAV-related information must be taken into account to accurately learn the source prefixes and their incoming interfaces. This information can be obtained locally, configured manually, or even propagated or advertised by other ASes. Therefore, the inter-domain SAVNET architecture consolidates SAV-related information from multiple sources and generates SAV rules automatically to achieve the aforementioned goals.¶
Some other design goals (such as low operational overhead and easy implementation, etc.) are also very important and should be considered in specific protocols or protocol extensions and are out of scope for this document.¶
+----------------------+
| Other ASes |
+----------------------+
|Collaborative
|Messages
+-----------------------------------------------------------------+
| |YANG |CLI |SMP |RIB |ROA |ASPA | AS |
| \/ \/ \/ \/ \/ \/ \/ |
| +---------------+ +------------------+ +----------------------+ |
| | Manual | | Passive Acquired | | Active Collaboration | |
| | Configuration | | Information | | Information | |
| +---------------+ +------------------+ +----------------------+ |
| | | | |
| \/ \/ \/ |
| +-------------------------------------------------------------+ |
| | +---------------------------------------------------------+ | |
| | | SAV Information Base | | |
| | +---------------------------------------------------------+ | |
| | SAV Information Base Manager | |
| +-------------------------------------------------------------+ |
| | |
| \/ |
| +---------------------------------------------------------+ |
| | SAV Table | |
| +---------------------------------------------------------+ |
+-----------------------------------------------------------------+
Figure 1 shows the overview of inter-domain SAVNET architecture. Inter-domain SAVNET architecture collects SAV-related information from multiple sources, which can be categorized into three types: Manual Configuration, Passive Acquired Information, and Active Collaboration Information. SAVNET uses the SAV-related information to maintain the SAV Information Base (SIB). Then, based on the SIB, it generates SAV rules to fill out the SAV table in the dataplane.¶
Manual Configuration can be conducted by network operators using YANG, command-line interface (CLI), and SIB Management Protocol (SMP), such as remote triggered black hole (RTBH) and FlowSpec. The Passive Acquired Information can be ontained within an AS and may come from RIB, Routing Information Messages, or RPKI ROA objects and ASPA objects. Active Collaboration Information contains Real Forwarding Paths and is transmitted using Collaborative Messages from other ASes.¶
We note that inter-domain SAVNET architecture does not require all the information sources to generate SAV rules. All of them, including the Collaborative Messages, in SAVNET are optional depending on the availability of them and operational needs. The SAV Information Base Manager (SIM) and SAV table are necessary to generate SAV rules and perform SAV.¶
SAV Information Base (SIB) is consolidated by the SAV Information Base Manager according to the SAV-related information from various sources. In SIB, each row records the index, the prefix, the prefix's valid incoming interface, the prefix's incoming direction, and the corresponding information source.¶
+-----+------+------------------+---------+---------------------------+ |Index|Prefix|AS-level Interface|Direction| Information Source | +-----+------+------------------+---------+---------------------------+ | 0 | P1 | X.1 |Provider | Collaborative Message, | | | | | |RPKI ASPA Obj. and ROA Obj.| +-----+------+------------------+---------+---------------------------+ | 1 | P1 | X.2 |Provider | RIB | +-----+------+------------------+---------+---------------------------+ | 2 | P2 | X.2 |Provider | Manual Configuration | +-----+------+------------------+---------+---------------------------+ | 3 | P3 | X.3 | Peer | Collaborative Message, | | | | | |Routing Information Message| +-----+------+------------------+---------+---------------------------+ | 4 | P4 | X.4 |Customer |Collaborative Message, RIB | +-----+------+------------------+---------+---------------------------+ | 5 | P4 | X.5 |Customer | RIB | +-----+------+------------------+---------+---------------------------+ | 6 | P5 | X.5 |Customer |Routing Information Message| +-----+------+------------------+---------+---------------------------+
+------------+ +------------+
| AS 1(P1) +-------+ AS 2(P2) |
+-------/\---+ +--/\--------+
\ /
(C2P) \ / (C2P)
\ X.1 X.2 /
+------------+ (P2P) +-------------+
| AS X +-----------+ AS 3 (P3) |
+-/\------/\-+ X.3 +-------------+
X.4 | X.5 \
| \
| \ (C2P)
| +------------+
| | AS 5(P5) |
| +-/\---------+
| /
(C2P) | /
+-------------+
| AS 4 (P4) |
+-------------+
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, X.1 is connected to AS 1, X.2 to AS 2, X.3 to AS 3, X.4 to AS 4, and X.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 the prefix P1's valid incoming interface is X.1, the ingress direction of P1 is AS X's Provider AS, and these information is from the Collaborative Messages and RPKI ASPA Objects and ROA Objects. Note that the 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 information sources:¶
+---------------------------------------+--------+ | SAV Information Source |Priority| +---------------------------------------+--------+ | Manual Configuration | 1 | +---------------------------------------+--------+ | Collaborative Message | 2 | +---------------------------------------+--------+ | RPKI ROA Objects and ASPA Objects | 3 | +---------------------------------------+--------+ | Routing Information Message | 4 | +---------------------------------------+--------+ | Routing Information Base | 5 | +---------------------------------------+--------+
The SIB may be maitained according to the SAV-related information from all the above information sources or part of them. It records the sources of the SAV information explicitly and can be compressed to reduce its size. Inter-domain SAVNET architecture can allow operators to specify how to use the SAV-related information in the SIB by manual configurations. In fact, the SAV information sources also give the indications about how to use the SAV-related information from them.¶
Notably, the information sources are not equivalent, and finer-grained information sources, such as Collaborative Messages, can help generate more accurate SAV rules to reduce improper permit or improper block. Figure 4 proposes the priority ranking for the SAV information sources in the SIB. Inter-domain SAVNET 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 sources (e.g., the rows with index 0, 1, and 2 in Figure 2) to generate rules, and for the customer interfaces which need more strict SAV rules, SAVNET may only use the ones (e.g., the row with index 4 and 6 in Figure 2). Here, for the row with index 6, inter-domain SAVNET uses it to generate SAV rules since only SAV-related information from the Routing Information Message is available for the prefix P5.¶
The Collaborative Messages propagate or originate the real forwarding paths of prefixes between the Collaborative Protocol Speakers. The Collaborative Protocol Speaker within an AS can obtain the next hop of the corresponding prefixes based on the routing table from the local RIB, and use the Collaborative Messages to carry the next hop of the corresponding prefixes and propagate them between ASes.¶
The Collaborative Protocol Speaker can generate the real forwarding paths of prefixes. It does this by connecting to the Collaborative Protocol Speakers in other ASes, receiving, processing, generating, or terminating Collaborative Messages. The Collaborative Protocol Speaker establishes connection with other Collaborative Protocol Speakers in other ASes to exchange Collaborative Messages. Then, it obtains the ASN, the prefixes, and their incoming AS direction for the SIB.¶
Besides, the preferred AS paths of an AS and the prefixes may change over time due to route changes. The Collaborative Protocol Speaker should launch Collaborative Messages to adapt to the route changes in a timely manner. In particular, inter-domain SAVNET should deal with the route changes carefully since improper block may be induced when the packet forwading path changes while the Collaborative Messages are not processed in time. The detailed design for dealing with the route changes is out of scope for this document.¶
SAV Information Manager (SIM) consolidates SAV-related information from multiple sources and generate SAV rules. It uses the SAV-related information to initiate or update the SIB, and generates SAV rules to fill out 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.¶
Based on the SIB, SIM generates SAV rules to fill out the SAV table, which consists of the <Prefixes, Interface> couples, and represents the legitimate prefixes for each incoming interface. Note that the interfaces in SIB are logical AS-level interfaces, they need to be converted to the physical interfaces of border routers within the corresponding AS.¶
+------------------------------------+ | Source Prefix | Incoming Interface | +---------------+--------------------+ | P1 | 1 | | P2 | 2 | | P3 | 3 | +------------------------------------+
Figure 5 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 SAV table can be enabled at provider, peer, or customer interfaces. Different interfaces can take on proper SAV table modes defined in [draft-huang-savnet-sav-table]. For customer interfaces, if all the customer ASes have advertised complete source prefixes and SAV Protocol Messages, Prefix Allowlist Mode can be applied ("Mode 1" in [draft-huang-savnet-sav-table]). This mode drops any packets whose source addresses are not included in the allowlist of the customer interfaces. If the legitimate source prefixes arriving at the interfaces are not complete, the Interface Blocklist Mode can be taken ("Mode 2" in [draft-huang-savnet-sav-table]). This latter mode checks whether specific source prefixes coming from the invalid interfaces. The packets with unknown prefixes will be forwarded normally. Thus, they are safer than Prefix Allowlist Mode.¶
Since it is impossible to deploy inter-domain SAVNET in all ASes simultaneously, inter-domain SAVNET must support partial deployment. In inter-domain SAVNET architecture, the manual configuration, topological information, and the known prefixes can be obtained locally. Even for the real forwarding path information, it does not suppose that all ASes deploy the Collaborative Protocol Speakers, as a Collaborative Protocol Speaker can easily find an AS which deploys another Collaborative Protocol Speaker and establishes logical neighboring relationship with the AS.¶
Overall, ASes which deploys inter-domain SAVNET cannot spoof each other, and non-deployed ASes cannot send spoofed packets to the deployed ASes by forging their source addresses. With the merger of different ASes where the inter-domain SAVNET is deployed, the "deployed area" will gradually expand, and the defense capability against source address spoofing will gradually increase. Moreover, if multiple "deployed areas" can be logically connected (by crossing the "non-deployed areas"), these "deployed areas" can form a logic alliance to protect their addresses from being forged.¶
In inter-domain SAVNET architecture, the Collaborative Protocol Speaker generates and propagates Collaborative Messages among different ASes. To prevent a malicious AS from generating incorrect or forged Collaborative Messages, the Collaborative Protocol Speakers need to perform security authentication on each received Collaborative Message. Security threats to inter-domain SAVNET come from two aspects: session security and content security. Session security means that the identities of both parties in a session can be verified and the integrity of the session content can be ensured. Content security means that the authenticity and reliability of the session content can be verified, i.e., the forged Collaborative Message can be identified.¶
The threats to session security include:¶
The threats to content security include:¶
Overall, inter-domain SAVNET faces security threats similar to those of BGP. To enhance session security, inter-domain SAVNET may use the same session authentication mechanisms as BGP, i.e., performing session authentication based on MD5, TCP-AO, or Keychain. To enhance content security, existing BGP security mechanisms (e.g., RPKI, BGPsec, and ASPA) can also help address content security threats to inter-domain SAVNET. But until these mechanisms are widely deployed, an independent security mechanism for inter-domain SAVNET is needed. In the preliminary idea, each origin AS calculates a digital signature for each AS path and adds these digital signatures into the Collaborative Message. When a Collaborative Protocol Speaker receives a Collaborative Message, it can check the digital signature to identify the authenticity of this message. Specific security designs will be included in a separate draft.¶
This document should not affect the privacy of the Internet.¶
This document has no IANA requirements.¶
Many thanks to Igor Lubashev for the significantly helpful revision suggestions.¶