| Internet-Draft | Inter-domain SAVNET Architecture | October 2022 |
| Wu, et al. | Expires 27 April 2023 | [Page] |
Source address validation (SAV) plays a significant role in defending against various attacks based on source IP address spoofing. BCP84 [RFC3704][RFC8704] provides practical SAV mechanisms, i.e., uRPF-based approaches, for inter-domain scenarios. However, current uRPF-based SAV mechanisms have limitations in accuracy and incentive [draft-wu-savnet-inter-domain-problem-statement]. This document provides an architecture of inter-domain SAVNET which actively advertises AS paths to other ASes for generating accurate SAV rules and improving incentive.¶
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 27 April 2023.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Many attacks based on source IP address spoofing, such as reflective DDoS, continue to pose a significant challenge to the Internet security. Source address validation (SAV) in inter-domain networks is important to mitigate source address spoofing. BCP84 [RFC3704][RFC8704] provides practical SAV mechanisms, i.e., uRPF-based approaches, for inter-domain scenarios. In particular, it is recommended that i) the loose uRPF[RFC3704] mechanism SHOULD be applied on lateral peer and transit provider interfaces, and that ii) the EFP-uRPF mechanism with Algorithm B SHOULD be applied on customer interfaces.¶
However, current uRPF-based SAV mechanisms have limitations in accuracy and incentive [draft-wu-savnet-inter-domain-problem-statement]. They generate SAV rules based on the RIB information of the local AS. In the case of asymmetric routing, the rules may not exactly match the incoming direction of packets originated from a specific source address. Besides, in the design of existing SAV mechanisms, the victim network in a reflective DDoS attack does not effectively participate in preventing its own source address from being forged. As a result, the victim network still suffers from reflective attack from other networks even though it has deployed SAV.¶
To address the above issues, this document presents an inter-domain source address validation (inter-domain SAVNET) architecture. An AS deploying inter-domain SAVNET can actively advertise locally preferred AS paths to neighboring ASes or remote ASes. Other ASes will learn the valid incoming directions for the source prefixes of the origin AS through these advertisement messages. Moreover, by deploying inter-domain SAVNET, each AS is more likely to protect itself from reflective DDoS attacks.¶
This document presents the core workflow of inter-domain SAVNET. After that, some considerations are introduced including convergence, incremental and partial deployment, and security. This document focuses on high-level designs and does not describe how to implement inter-domain SAVNET by using existing routing protocols.¶
SAV rule: The rule that defines valid incoming interfaces for the specific source prefix.¶
SAV table: The data structure that stores SAV rules on the data plane. The router queries its local SAV table to validate the authenticity of source addresses.¶
Improper block: The packets with valid source addresses are blocked improperly due to inaccurate SAV rules.¶
Improper permit: The packets with spoofed source addresses are accepted as normal packets due to inaccurate SAV rules.¶
SPA message: Source Prefix Advertisement message that helps other ASes to associate the origin AS to a list of origin source prefixes.¶
SPD message: Source Path Discovery message that carries the ASN of the origin AS and is propagated along the AS paths preferred by the origin AS. Through SPD message, other ASes discover the real incoming direction for the source prefixes of the origin AS.¶
The inter-domain SAV targets to reject packets with forged source addresses without impacting legitimate packets. To this end, inter-domain SAVNET needs to achieve these following goals:¶
Overhead is also an important consideration for the design of inter-domain SAVNET. The validation overhead on the data plane should be limited by avoiding packet modification, which keeps consistent with existing SAV mechanisms. The control-plane overhead (e.g., the number of control-plane messages) should be limited to a reasonable level under current network hardware and software conditions.¶
To achieve the above goals, inter-domain SAVNET makes ASes to actively notifty locally preferred AS paths to neighbor ASes or remote ASes in a hop-by-hop way. ASes receiving such notifications will identify the neighbor AS from which packets with specific source prefixes should come. Then, the boundary routers of the ASes can establish accurate SAV rules by associating the source prefixes with corresponding incoming interfaces. The SAV rules can be generated at any kind of AS interfaces, including provider, peer, and customer interfaces. Besides, by notifying the real incoming interfaces for its source prefixes to other ASes, each deployed AS can better protect its source addresses from being forged, because other ASes will perform more accurate SAV for packets with its source addresses.¶
Overall, six different operations will be conducted in the procedures of inter-domain SAVNET architecture: ¶
The overall process of the control-plane workflow of inter-domain SAVNET is described as follows:¶
Suppose AS X conducts the operation of SPD origination. AS X will first identify the set of preferred AS paths reaching other ASes. Then, it sends an SPD message to each next-hop AS Y according to the preferred AS paths. Each SPD message carries two main fields:¶
After conducting the operation of SAV rule generation, AS Y checks the AS paths in the propagation scope field of the received SPD message. There are two behavior branches:¶
+-------+
-----------------------+ AS1 + -- + P1
| +---+---+
| | msg 1:
| | origin_ASN=AS1,
| | scope={[AS1,AS2,AS3,AS5],
| msg 1.1: | [AS1,AS2,AS6],
| origin_ASN=AS1, \/ [AS1,AS2,AS4,AS5]}
+---#---+ scope={[AS2,AS6]}+---#---+--- + P2
| AS6 # <----------------+ AS2 + ------------------
+---+---+ +---+---+ |
+ msg 1.2: | msg 1.3: |
P6 origin_ASN=AS1,| origin_ASN=AS1, |
scope={[AS2,AS3,AS5]} \/scope={[AS2,AS4,AS5]}\/
+---#---+ +---#---+
P3 + ---+ AS3 | P4 + ---+ AS4 |
+---+---+ +---+---+
msg 1.2.1: | msg 1.3.1: |
origin_ASN=AS1, | origin_ASN=AS1, |
scope={[AS3,AS5]} | scope={[AS4,AS5]} |
\/ |
+---#---+ |
P5,P7 + ---+ AS5 # <-----------------
+-------+
AS1 is the origin AS which generates original
SPD messages.
'#' means the valid incoming interface for packets with
source addresses of P1.
'scope' represents the propagation scope field.
The forwarding AS path preferred by AS1 is as follows:
+---------------------------------------+
+ Dest. Prefix | AS Path +
+---------------------------------------+
+ P2 | AS1 AS2 +
+ P3 | AS1 AS2 AS3 +
+ P4 | AS1 AS2 AS4 +
+ P5 | AS1 AS2 AS3 AS5 +
+ P6 | AS1 AS2 AS6 +
+ P7 | AS1 AS2 AS4 AS5 +
+---------------------------------------+
Figure 1: An example of the overall process
¶
Figure 1 illustrates the overall process of SAV rule generation for prefix P1. Suppose the process of source prefix advertisement and collection has been finished.¶
Any AS owning IP prefixes can conduct the operation of SPD origination, and the other ASes will generate SAV rules for the source prefixes of the origin AS. Finally, every AS will learn the SAV rules for other ASes. In inter-domain SAVNET, with the exception of some special cases, such as multipath routing to the same destination AS, each AS usually receive only one SPD message originated from each origin AS.¶
In the above description, inter-domain SAVNET treats an AS as a logical node and the process within an AS is not discussed. As shown in Figure 2, an AS usually have multiple ASBRs (Autonomous System Boundary Routers). All ASBRs of an AS should be able to collaborate with each other. The two key aspects of collaboration are SAV rule generation and SPD message relaying within an AS.¶
AS 1
|
\/ msg 1
+---#---+
------------+ ASBR1 +-------------
| +---+---+ |
| |
| AS 2 |
| |
msg 1.1 +---+---+ +---+---+
AS 6<----# ASBR2 +------------------------+ ASBR3 |
+---#---+ <SAV rules> +---#---+
msg 1.2| | msg 1.3
\/ \/
AS 3 AS 4
msg 1 is an SPD message from AS 1 and received by AS 2.
msg 1.1, msg 1.2, msg 1.3 are the SPD messages
after being relayed by AS 2.
'#' means the ingress interface of the ASBR.
Figure 2: An example of ASBR collaboration within an AS
¶
Following the example in Figure 1, Figure 2 illustrates how an ASBR collaborates with other ASBRs in the same AS. In Figure 2, there are three ASBRs in AS2. When AS2 receives an SPD message from AS1, it will send the message to other ASBRs. As shown in Figure 1, the message has the origin ASN field of AS1 and the propagation scope field of {[AS1,AS2,AS3,AS5], [AS1,AS2,AS4,AS5], [AS1,AS2, AS6]}.¶
First, all the ASBRs will figure out that AS1 is the previous-hop AS, and the packets with source addresses of P1 should come from AS1. So, ASBR1 will consider its interface '#' as the legal incoming interface for source prefix P1. Since ASBR2 and ASBR3 do not have interfaces connected to AS1, the interfaces '#' of ASBR2 and ASBR3 will be considered as illegal incoming interfaces for source prefix P1.¶
Second, each ASBR will decide whether to generate relaying SPD messages its directly connected ASes. The next-hop ASs of the three AS paths are AS3, AS4, and AS6, respectively. ASBR1 connects none of the three next-hop ASs, so it conducts the operation of SPD termination. ASBR2 has an interface connected to AS6, so it will generate a relaying SPD message to AS6, i.e., the msg 1.1 in Figure 1. Since another interface of ASBR2 is connected to AS3, a relaying SPD message will be also generated to AS3, i.e., msg 1.2 in Figure 1. Similarly, ASBR3 will generate a relaying SPD message to AS4, i.e., msg 1.3 in Figure 1.¶
The AS paths preferred by each AS may change with time. Inter-domain SAVNET does not take the explicit SAV rule withdraw mechanism so as to eliminate the impact of route flapping. Instead, the combination of rule aging and periodical timer refreshing is taken. More details can be found in section 6.¶
Through the workflow of the control plane, the ASBRs will learn the SAV rules indicating which interfaces are valid or invalid for specific source prefixes. These rules will form SAV tables which will be enabled in the data plane. Figure 3 shows an example of SAV table.¶
The packets coming from other ASes will be validated by ASBRs. The router looks up each packet's source address in its local SAV table and gets one of three validity states: "Valid", "Invalid" or "Unknown". "Valid" means that there is a source prefix in SAV table covering the source address of the packet and the valid incoming interfaces covering the actual incoming interface of the packet. According to the SAV principle, "Valid" packets will be forwarded. "Invalid" means there is a source prefix in SAV table covering the source address, but the incoming interface of the packet does not match any valid incoming interface so that such packets will be dropped. "Unknown" means there is no source prefix in SAV table covering the source address. The packet with "unknown" addresses can be dropped or permitted, which depends on the choice of operators.¶
The SAV table can be enabled at provider, peer, or customer interfaces. Different interfaces can take on proper SAV table modes defined in [draft-huang-savnet-sav-table]. For customer interfaces, if all the customer ASes have advertised complete source prefixes and SPD messages, Prefix Allowlist Mode can be applied ("Mode 1" in [draft-huang-savnet-sav-table]). This mode drops any packets whose source addresses are not included in the allowlist of the customer interfaces. If the legitimate source prefixes arriving at the interfaces are not learned completely, the Interface Allowlist/Blocklist Mode can be taken ("Mode 3" and "Mode 4" in[draft-huang-savnet-sav-table]). This latter mode checks whether specific source prefixes coming from the valid or invalid interfaces. The packets with unknown prefixes will be forwarded normally. Thus, they are safer than Prefix Allowlist Mode.¶
For provider or peer interfaces which connected to a large network area, it is difficult to get the complete legitimate source prefixes. To provide as much protection as possible, the Interface Allowlist/Blocklist Mode can be taken, which will be more strict than loose uRPF.¶
+----------------------------------------+
+ Source prefix | Incoming interface +
+----------------------------------------+
+ P1 | Interface 1 +
+ P2 | Interface 2 +
+ P3 | Interface 3 +
+----------------------------------------+
Figure 3: SAV table format¶
ACL redirection is usually used to steer traffic for traffic engineering or some other objectives. The ACL redirection rules can be configurated manually or installed through FlowSpec. They may change the AS path used to forward the traffic, leading to AS-level inconsistency between control-plane routing path and data-plane forwarding path. Note that, origin AS obtains AS paths from control plane and put them into the propagation scope field for guiding the propagation of SPD messages. In this way, each AS generates SAV rules following the AS paths learned from control plane. If the AS-level inconsistency exists, improper block or improper permit problems may appear.¶
One possible solution is to require the AS to notify the affected source AS when it attempts to change the AS paths of traffic on data plane, which allows the origin AS to be aware of the real AS paths. In other words, the real data-plane AS paths of inter-domain traffic should be visible to the origin AS on the control plane.¶
When the change of AS paths is sensed, the origin AS immediately re-conducts the SPD process to guide the AS along the new AS path to update SAV rules.¶
The preferred AS paths of an origin AS will change with time due to route changes. For some ASes, the valid incoming directions of the source prefixes of the origin AS may need to be updated so as to keep SAV rules accurate. Inaccurate SAV rules will induce improper permit problems or improper block problems. Improper block will affect the forwarding of legitimate data packets, which is more serious than improper permit. So, one of the design goals of inter-domain SAVNET is to eliminate improper block first and try best to reduce improper permit.¶
For the route changes resulting in new SAV rules, the basic idea of inter-domain SAVNET is to add the new SAV rules in time to eliminate improper block as quickly as possible. For the route changes resulting in SAV rule deletion, inter-domain SAVNET does not explicitly withdraw these SAV rules. As mentioned previously, invalid SAV rules are removed by using an aging timer. The aging design is to reduce the impact of route flapping. To refresh aging timers, SPD messages will be propagated periodically.¶
Generally, route changes include source prefix change and AS path change. The followings are some convergence considerations of inter-domain SAVNET when there are route changes.¶
There are two types of source prefix change: announcing a new source prefix and withdrawing an existing source prefix.¶
A new source prefix with its origin ASN can be advertised by a BGP message or an SPA message. Upon receiving the announcement by other ASes, these ASes will update local SAV rules immediately, i.e., binding the new source prefix with the valid interfaces learned through SPD messages before. An alternative method is to advertise the new source prefix by SPA message before really using the new source prefix in the network. In this way, other ASes can update local SAV rules in advance.¶
When an existing prefix will be revoked, the origin AS sends a BGP message or an SPA message to other ASes to withdraw the prefix. Other ASes will remove the prefix from the list of source prefixes of the origin ASN in the control plane. The SAV rule keeps installed in data plane untile the aging timer is timeout.¶
For an origin AS, the preferred AS paths may change due to new route announcement, route policy changes, link failures, etc. Upon sensing AS path changes, the origin AS will generate new SPD messages carrying the new AS paths to advertise related ASes updating SAV rules. Similarly, new SAV rules will be enabled immediately, but invalid SAV rules will be removed only when the aging timer expires.¶
Fast reroute (FRR) is a particular scenario. FRR requires the router to set up a backup path in advance. When network failure happends, the router is able to fastly steer the affected traffic to the backup path so as to satisfy some SLA requirements. The normal convergence process, i.e., updating SAV rules through new SPD messages, may sometimes be not fast enough for FRR scenarios. To meet the performance requirements of FRR, ASes can send SPD messages to the backup forwarding AS paths in advance, and the generated SAV rules will also be enabled in the data plane. When network failures happend, the affected data packets can be forwarded normally through the backup path without worrying about improper block problems during the normal convergence process of inter-domain SAVNET.¶
Since it is impossible to deploy inter-domain SAVNET in all ASes simultaneously, inter-domain SAVNET must support incremental and partial deployment. In inter-domain SAVNET architecture, the SPD message is hop-by-hop propagated along the AS path predefined by the origin AS. Hence, even if an intermediate AS does not support inter-domain SAVNET, an AS can easily find the next deployed AS on the AS path and establishes logical neighboring relationship with that AS. After that, it can generate SPD messages directly to that AS. In this way, SPD messages can be propagated across non-deploying ASes. However, as mentioned in Section 5, the control-plane routing path and data-plane forwarding path are required to be consistent to ensure the accuracy of source path discovery.¶
To reduce the overhead of maintaining logic neighboring relationships and mitigate the affect of ACL redirection, it is suggested to incrementally deploy inter-domain SAVNET on a customer cone basis. On the one hand, given the hierarchical topology of ASes in the Internet, logical neighboring relationships are mainly established between the top-level ASes of different deployed customer cones. On the other hand, it is more feasible to exchange policy-based routing information within the same customer cone as the first step.¶
Overall, in incremental and partial deployment condition, each deployed customer cone should at least gain the benefits: "ASes within the deployed area cannot spoof each other, and ASes in the undeployed area cannot send spoofed packets to the deployed area by forging the source addresses of the deployed area ". With the merger of different customer cones where the inter-domain SAVNET is deployed, the "deployed area" will gradually expand, and the defense capability against source address spoofing will gradually increase. Moreover, if multiple "deployed areas" can be logically connected (by crossing the "non-deploying areas"), these "deployed areas" can form a logic alliance to protect their addresses from being forged by non-deploying networks.¶
In inter-domain SAVNET architecture, the SPD message are hop-by-hop propagated among different ASes. To prevent a malicious AS from generating incorrect or forged SPD messages, routers need to perform security authentication on each received SPD message. Security threats to inter-domain SAVNET come from two aspects: session security and content security. Session security means that the identities of both parties in a session can be verified and the integrity of the session content can be ensured. Content security means that the authenticity and reliability of the session content can be verified, i.e., the forged SPD message can be identified.¶
Specifically, the threats to session security include:¶
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 can use the same session authentication mechanisms as BGP, i.e., performing session authentication based on MD5, TCP-AO, or Keychain. To enhance content security, existing BGP security mechanisms (such as RPKI, BGPsec, ASPA) can also help address content security threats to inter-domain SAVNET. But until these mechanisms are widely deployed, an independent security mechanism for inter-domain SAVNET is needed. In the preliminary idea, each origin AS calculates a digital signature for each AS path and adds these digital signatures into the SPD message. When a router receiving an SPD message, it can check the digital signature to identify the authenticity of this SPD message. Specific security designs will be included in a separate draft.¶