Inter-domain Source Address Validation (SAVNET) Architecture

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 provides practical SAV mechanisms, i.e., uRPF-based approaches, for inter-domain scenarios. In particular, it is recommended that i) the loose uRPF 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 . 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: Providing as much source address protection as possible at provider, peer, and customer interfaces. Generating accurate SAV rules that avoid improper block and reduce improper permit as much as possible. Providing sufficient and aligned incentives for the ASes that deploy SAV. 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: Source prefix advertisement: An AS identifies the complete origin source prefixes and advertises its origin source prefixes through BGP or SPA messages. Source prefix collection: An AS collects the source prefixes owned by other ASes when receiving source prefix advertisement. SPD origination: An AS generates original SPD messages and sends them to other ASes. SPD relaying: An AS generates a relaying SPD message to the next hop AS along the preferred AS path after receiving one SPD message. SPD termination: An AS terminates the received SPD message and does not generate any relaying SPD message. SAV rule generation: An AS generates corresponding SAV rules after receiving an SPD message.

The overall process of the control-plane workflow of inter-domain SAVNET is described as follows: Each AS conducts the operation of source prefix advertisement. The origin source prefixes of the AS will be identified and advertised through BGP or SPA messages. Actually, most of source prefixes can be advertised through BGP. SPA messages are used for adding or removing specific source prefixes. Each AS conducts the operation of source prefix collection to get the complete origin source prefixes of other ASes. The mappings from ASN to a set of source prefixes will be maintained in each AS. 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: origin ASN: the ASN of the origin AS (i.e., X). propagation scope: the list of local preferred AS paths which start with AS X and take AS Y as the next-hop AS. To reduce propagation overhead, a shorter AS path does not need to be carried if there is a longer one covering it. When AS Y receives the SPD message, it first conducts the operation of SAV rule generation. AS Y learns from which neighboring AS it will receive the packets originated from AS X through the AS paths in the propagation scope field. Specifically, it locates the previous-hop AS in each AS path, and consider all interfaces connnected to the previous-hop AS as valid incoming interfaces for the source prefixes of the origin AS X. The source prefixes of AS X have been collected in advance through source prefix collection. As a result, the SAV rules with the format of <source prefix, incoming interface> will be learned and installed in data plane. 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: i) If the field only contains its own ASN (i.e., Y), it will conduct the operation of SPD termination, i.e., stop propagating the information in the SPD message to other ASes after generating SAV rules. ii) Otherwise, it conducts the operation of SPD relaying to generate relaying SPD messages to other ASes. It removes the previous ASes (e.g., X) from the AS paths in the propagation scope of the received SPD message and then groups the processed AS paths according to the next-hop AS. For each next-hop AS Z, it generates a new SPD message to AS Z. The new origin ASN field keeps the same as the received SPD message. The new propagation scope field contains the processed AS paths that take AS Z as the next-hop AS. The other ASes on AS pathes of the propagation scope field will receive SPD messages in sequence and conduct the same process as step d and step e until the SPD message is terminated.

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. AS1 conducts the operation of SPD origination, and P2~P7 are locally reachable addresses. According to the AS paths selected by AS1, AS2 is the common next-hop AS in all AS paths. So, AS1 only generates one original SPD message to AS2 with "AS1" in the origin ASN field and {[AS1,AS2,AS3,AS5], [AS1,AS2,AS4,AS5], [AS1,AS2, AS6]} in the propagation scope. Note that AS paths to P3 and P4 are not carried in the message because they are covered by AS paths to P5 and P7. When receiving the SPD message from AS1, AS2 identifies the source prefix of AS1 and generates the SAV rule <source prefix P1, incoming interface #>. AS2 then checks each AS path in the propagation scope and finds that AS path [AS1,AS2,AS3,AS5], [AS1,AS2,AS4,AS5], and [AS1,AS2, AS6] take AS3, AS4, and AS6 as the next hop, respectively. Then, it will conduct the operation of SPD relaying and generate one new SPD message for each of AS3, AS4, and AS6. The relayed SPD message destined to each next-hop AS carries corresponding AS paths (starting from the local AS, i.e., AS2) in the propagation field. The origin ASN in each relaying SPD message keeps the same as the received SPD message. When receiving the SPD message from AS2, AS6 generates the SAV rule for prefix P1 and terminate the message since the propagation scope only contains AS6. When AS3 or AS4 receives the SPD message from AS2, it generates the SAV rule and conducts the operation of SPD relaying because the AS path in the propagation scope takes AS5 as the next hop. When AS5 receives the relayed SPD message from AS3 or AS4, it generates the SAV rule and terminates the propagation. In the end, AS2~AS6 can generate the SAV rule <source prefix P1, interface '#'>. It is noted that AS5 specifies two valid incoming interfaces for source prefix P1 because it receives SPD messages with the origin ASN A1 from two different neighboring ASes. 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. i) When an ASBR receives an SPD message from another AS, it will send the message to other ASBRs within the same AS after generating the SAV rules. Then, all other ASBRs will identify the previous-hop AS, from which the source prefixes of the origin AS will come. Therefore, the ASBR with interfaces connected to the previous-hop AS will consider all these interfaces as valid for the source prefixes of the origin AS. The interfaces that are connected to other ASes are considered invalid for the source prefixes of the origin AS. ii) After that, the other ASBRs will decide whether to relay or terminate the received SPD message from an ASBR. Note that, ASBRs may be connected to different neighboring ASes. For an ASBR, if the AS paths in the propagation scope field of the received SPD message only contains the local ASN or the next-hop AS is not its neighbor, the ASBR will conduct SPD termination. Otherwise, the ASBR will generate a relaying SPD message to the connected next-hop AS with the propagation scope field filled with the AS paths that take the connected AS as the next hop.

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

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: Session identity impersonation: A malicious router masquerades as a peer of another router to establish a session with the router. Session integrity destroying: A malicious intermediate router between two peering routers destroys the content of the passed SPD message. The threats to content security include: Message alteration: A malicious router forges any part of an SPD message, for example, using a spoofed ASN or AS Path. Message injection: A malicious router injects a "legitimate" SPD message and sends it to the corresponding next-hop AS, such as replay attacks. Path deviation: A malicious router sends an SPD message to a wrong next-hop AS which conflicts with the AS Path. 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.