Source Address Validation in Inter-domain Networks Gap Analysis, Problem Statement, and Requirements

Source address validation (SAV) protects the network from the source address spoofing attacks. To be maximally effective, SAV mechanisms should be applied as close to the source as possible. However, it is not possible to deploy SAV at all network edges . Therefore, a multi-fence architecture called Source Address Validation Architecture (SAVA) proposes to implement SAV at three levels: access network SAV, intra-domain SAV, and inter-domain SAV. SAVA can help validate source addresses across the whole Internet and reduce the opportunities and areas of source address spoofing attacks. Different operators may choose to deploy different SAV mechanisms at different levels in the Internet. Besides, given numerous access networks and ASes managed by different ISPs throughout the world, as well as routers from various vendors, it is difficult to deploy access-network SAV across all access networks. Therefore, intra-domain SAV and inter-domain SAV are necessary to defend against source address spoofing along the network paths of spoofed packets. Intra-domain SAV prevents an AS's source addresses from being spoofed inside or outside of an AS without the help of other ASes, and is analyzed in . Inter-domain SAV prevents an AS's source addresses from being spoofed with the help of other ASes which the spoofed packets go through. This document focuses on the analysis of inter-domain SAV. For an AS deploying inter-domain SAV, the traffic entering the AS and spoofing other ASes' source addresses will be blocked. As shown in , take AS 1, AS 2, AS 3, and AS 4 as an example to illustrate inter-domain SAV: P1 is the source prefix of AS 1, and spoofed packets with source addresses in P1 from AS 4 pass through AS 2 to AS 3. If AS 1 and AS 2 deploy the inter-domain SAV, the spoofed packets can be blocked at AS 2. Therefore, inter-domain SAV can prevent source address spoofing as close to the spoofing AS by the collaboration between ASes.

An example for illustrating inter-domain SAV There are many mechanisms for inter-domain SAV. This document analyzes the existing inter-domain SAV mechanisms and answers: i) what are the technical gaps, ii) what are the major problems needing to be solved, and iii) what are the requirements for further enhancing inter-domain SAV.

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

This section reviews the existing inter-domain SAV mechanisms using the ingress filtering , including ACL-based ingress filtering, loose uRPF, strict uRPF, FP-uRPF, VRF uRPF, and EFP-uRPF.

ACL-based Ingress Filtering : ACL rules permit or discard the packets with particular source addresses designated by manual ACL configurations. This mechanism is commonly deployed at the customer interfaces of the edge routers connected to the stub customer ASes or the aggregation routers when ACLs at the edge are not possible , which aims to prevent the customer ASes from spoofing source addresses of other ASes. Also, it can be deployed at provider interfaces of an AS to block the obviously disallowed source prefixes, such as prefixes from the suballocated address space and internal-use only prefixes of the AS's customer AS . Besides, the ACL rules need to be updated in a timely manner to keep consistent with the most updated filtering criteria by manual configurations.
Strict uRPF : This mechanism permits an incoming packet only if the forwarding information base (FIB) contains a prefix which encompasses its source address and packet forwarding for that prefix points to its incoming interface. It is recommended to deploy at the customer interfaces which directly connected to customer ASes with suballocated address space .
Loose uRPF : This mechanism permits an incoming packet when the FIB has one or more prefixes which encompass its source address, and the incoming interface of the packet is not checked. Loose uRPF can be deployed at any interfaces of the ASes. Usually, it is recommended to deploy at provider interfaces for blocking obviously disallowed source prefixes, e.g., non-global prefixes or the enterprise's own prefixes .
FP-uRPF : This mechanism maintains a reverse path forwarding (RPF) list, which contains the permissible prefixes and their optimal and alternative routes. It permits an incoming packet only if the source address is encompassed in the RPF list and the incoming interface matches any of the optimal or alternative routes. FP-uRPF is recommended to deploy at the peer interfaces and customer interfaces, especially for the ones connected to the multi-homed customers .
VRF uRPF : Virtual routing and forwarding (VRF) uRPF maintains a dedicated VRF table for each external BGP peer, which stores the prefixes and their permissible routes advertised by the external BGP peer. It permits an incoming packet from an external BGP peer only if the source address is encompassed in the prefixes of the VRF table for that peer. Besides, VRF uRPF may be used as BCP38 , but has not been operaionally proven .
EFP-uRPF : This mechanism improves the flexibility and accuracy of the uRPF-based methods with two algorithms, i.e., Algorithm A and Algorithm B, by following the principle: if BGP updates for multiple prefixes with the same origin AS were received on different interfaces (at border routers), then incoming data packets with source addresses in any of those prefixes should be accepted on any of those interfaces. The two algorithms of EFP-uRPF have not been implemented. BCP84 recommends that EFP-uRPF with Algorithm B SHOULD be applied at the customer interfaces of an AS.
Source-based remote triggered black hole filtering (RTBH) : Source-based RTBH provide the ability to drop traffic based on a specific source address or ranges of source addresses. The implementation of source-based RTBH depends on uRPF, most often loose uRPF. For loose uRPF with source-based RTBH, if there is not an FIB entry for an incoming packet's source address, or if the FIB entry points to the black hole (i.e., Null0), the reverse path forwarding check will fail, and as a result, the packet will be dropped. Source-based RTBH allows operators to drop the identified attack traffic at specified devices (e.g., edge router) of their network based on source addresses.
Carrier Grade NAT: It has some operations on the source addresses of packets but is not an antispoofing tool as described in . If the source address of a packet is in the INSIDE access list, the NAT rule can translate the source address to an address in the pool OUTSIDE. The NAT rule cannot judge whether the source address is spoofed or not. Besides, the packet with a spoofed source address will be forwarded directly if the spoofed source address is not included in the INSIDE access list. Therefore, Carrier Grade NAT cannot help block or traceback spoofed packets, and other SAV mechanisms still need to be deployed.
BGP origin validation (BGP-OV) : An attacker can subvert any of the uRPF-based methods by performing prefix hijacking followed by source address spoofing. When the attacker falsely announces a less-specific prefix, which does not have the legitimate announcement, existing uRPF-based SAV mechanisms may be deceived, and the attacker would be able to successfully perform address spoofing. One way to protect against this type of attack is to employ the combination of BGP-OV and uRPF-based mechanisms, e.g., FP-uRPF or EFP-uRPF . A BGP router can use the ROA information (i.e., a validated list of {prefix, maxlength, origin AS}) to mitigate the risk of prefix hijacks in advertised routes.

Inter-domain SAV defends against source address spoofing attacks in different directions of ASes including provider interface, customer interface, and peer interface. Therefore, in the following, this section performs gap analysis of existing SAV mechanisms at provider interface, customer interface, and peer interface to see their technical limitations.

SAV at provider interface can utilize ACL-based ingress filtering and/or loose uRPF to prevent spoofing source addresses from provider AS.

A scenario of the reflection attack from provider AS shows a scenario of the reflection attack from provider AS. The arrow indicates the direction of the commercial relationship between two ASes. AS 3 is the provider of AS 4. AS 4 is the provider of AS 1 and AS 2. Assume AS 4 has deployed inter-domain SAV and that AS 3 does not. For example, ACL-based ingress filtering can be deployed at provider interface of AS 4. To avoid improper block or improper permit problem, network operators must perform timely update of ACL rules based on the prefix or topology changes of AS 1 and AS 2, in order to be consistent with the real forwarding paths. Therefore, high operaional overhead will be induced. Loose uRPF can be deployed at provider interfaces, and it can adapt to the network changes using the local FIB. Take as an example. Loose uRPF is enabled at AS 4's provider interface and EFP-uRPF is deployed at AS 4's customer interfaces. A reflection attacker may be inside of AS 3 or connected to AS 3 through other ASes. It sends packets spoofing source addresses of P1 to the server located in AS 2 to attack the victim in AS 1. Since AS 3 does not deploy SAV, the malicious packets will arrive at the provider interfaces of AS 4. However, these attack packets cannot be successfully blocked by AS 4 with loose uRPF, and thus improper permit problem arises.

SAV at customer interface can utilize strict uRPF, FP-uRPF, VRF uRPF, or EFP-uRPF to prevent spoofing source addresses within a customer cone. However, they may have improper block problems in the two use cases: limited propagation of prefixes and hidden prefixes.

The limited propagation of prefixes would lead to asymmetric routing and thus result in improper block problems when taking SAV. There are many factors which can cause limited propagation of prefixes, such as NO_EXPORT community, NO_ADVERTISE community, and other route filtering policies. For brevity, we only analyze EFP-uRPF in the following. The other mechanisms (i.e., strict uRPF, FP-uRPF, and VRF uRPF) share the same problems.

Limited propagation of prefixes caused by NO_EXPORT presents a scenario of limited propagation of prefixes caused by NO_EXPORT. AS 1 is the common customer of AS 2 and AS 3. AS 4 is the provider of AS 2. The relationship between AS 3 and AS 4 is customer-to-provider (C2P) or peer-to-peer (P2P). All arrows in represent BGP advertisements. AS 1 has prefix P1 and advertises the prefix to the providers, i.e., AS 2 and AS 3. After receiving the route for prefix P1 from AS 1, AS 3 propagates this route to AS 4. In contrast, AS 2 does not propagate the route for prefix P1 to AS 4, since AS 1 adds the NO_EXPORT community attribute in the BGP advertisement destined to AS 2. Besides, AS 4 deploys EFP-uRPF at customer interfaces and other ASes do not take SAV. In this case, AS 4 only learns the route for prefix P1 from AS 3. Assume that AS 3 is the customer of AS 4. If AS 4 runs EFP-uRPF with algorithm A at customer interfaces, the packets with source addresses of P1 are required to arrive only from AS 3. When AS 1 sends the packets with legitimate source addresses of prefix P1 to AS 4 through AS 2, AS 4 will improperly block these packets. In addition, strict uRPF, FP-uRPF, and VRF uRPF also have the improper block problems. EFP-uRPF with algorithm B works well in this case. Assume that AS 3 is the peer of AS 4. AS 4 will never learn the route of P1 from its customer interfaces. So, no matter EFP-uRPF with algorithm A or that with algorithm B are used by AS 4, there will be improper block problems. Again, besides the NO_EXPORT configuration above, there are also many other route filtering configurations that can result in limited propagation of prefixes. Improper block may be induced by existing inter-domain SAV mechanisms when using such configurations, and it is hard to prevent networks from using these configurations.

In the case of hidden prefixes, the source addresses of some servers are not advertised through BGP. This would lead to improper block problems when using existing inter-domain SAV mechanisms, e.g., strict uRPF, FP-uRPF, VRF uRPF, and EFP-uRPF, since they block the legitimate traffic with unknown prefixes. Anycast is widely used in Content Delivery Network (CDN) to improve the quality of service by bringing the content to the user as close as possible. An anycast IP address is shared by devices in multiple locations, and incoming requests are routed to the location closest to the sender. In practice, anycast IP addresses are usually announced only from some locations with multiple connectivity. Upon receiving incoming requests from users, the CDN server will create tunnels for the requests to the edge locations. Subsequently, the edge locations perform direct server return (DSR), i.e., directly sending the content to the users. To ensure that DSR works, servers in edge locations must send response packets with anycast IP address as the source address. However, since edge locations never advertise the anycast prefixes through BGP, an intermediate AS with existing inter-domain SAV mechanisms may improperly block these response packets.

A Direct Server Return (DSR) scenario shows an example of DSR scenario. The anycast IP prefix (i.e., P3) is only advertised from AS 3 through BGP. Assume AS 3 is the provider of AS 4. AS 4 is the provider of AS 1 and AS 2. AS 4 takes SAV at customer interfaces and other ASes do not. When users in AS 1 send requests to the anycast destination IP, the forwarding path from users to anycast servers is AS 1 -> AS 4 -> AS 3. Anycast servers in AS 3 receive the requests and then tunnel them to the edge servers in AS 2. Finally, the edge servers send the content to the users with source addresses of prefix P3. The reverse forwarding path is AS 2 -> AS 4 -> AS 1. Since AS 4 never receives routing information for prefix P3 from AS 2, EFP-uRPF with algorithm A/B or other existing uRPF-based mechanisms, e.g., FP-uRPF, VRF uRPF, or strict uRPF, at AS 4 will improperly block the response packets from AS 2.

SAV at peer interface can utilize FP-uRPF, VRF uRPF, or EFP-uRPF to prevent spoofing source addresses from peer AS. And these inter-domain SAV mechanisms have the same improper block problems as they take SAV at customer interface in the cases of limited propagation of prefixes and hidden prefixes.

A scenario of the reflection attack from peer AS shows a scenario of the reflection attack from peer AS. The arrow indicates the direction of the commercial relationship between two ASes. AS 3 and AS 4 are peers, and AS 4 is the provider of AS 1 and AS 2. Assume AS 4 has deployed inter-domain SAV and other ASes do not. EFP-uRPF with algorithm B is deployed at AS 4's peer and customer interfaces. A reflection attacker may be directly attached to AS 3 or indirectly attached to AS 3 through other ASes. It sends packets spoofing source addresses of P1 to the server located in AS 2 for attacking the victim in AS 1. Since AS 3 does not take SAV, the malicious packets will arrive at the peer interface of AS 4. However, this attack cannot be successfully blocked by AS 4, since EFP-uRPF with algorithm B permits prefix P1 on any of AS 4's peer interfaces.

According to the gap analysis above, existing inter-domain SAV mechanisms do have improper block or improper permit problems in asymmetric routing scenarios, and high operaional overhead problem in dynamic networks. ACL-based ingress filtering relies on manual configurations of operators to update ACL rules and adapt to network changes. The ACL lists need to be updated in a timely manner to be consistent with the most updated filtering criteria. Otherwise, improper block or improper permit problems may appear. As a result, high operaional overhead will be induced to achieve timely updates of ACL rules, especially for networks with frequent policy and route changes. Strict uRPF and loose uRPF can generate SAV rules automatically without manual effort. However, strict uRPF may improperly block legitimate traffic in asymmetric routing scenarios, while loose uRPF may improperly permit spoofing traffic. The root cause is that they both only reply on the local FIB to obtain SAV-related information. Strict uRPF leverages the local FIB table of routers to learn the source prefixes and determine their valid incoming interfaces, which may not match the real data-plane forwarding paths of the source prefixes, due to the existence of asymmetric routing. Loose uRPF is a looser version of SAV and only validates the existence of source prefixes in the local FIB table without checking the incoming interfaces. FP-uRPF and VRF uRPF partially solves the improper block problems identified with the strict uRPF in the multihoming scenarios. They still have improper block problems in the asymmetric routing scenarios, e.g., limited propagation of prefixes with NO_EXPORT. The root cause is that they only rely on the local routing information base (RIB) to learn the source prefixes and determine the valid incoming interfaces, which may not match the real data-plane forwarding paths of the source prefixes. EFP-uRPF can solve the improper block problems of FP-uRPF and VRF uRPF in the multihoming scenarios by permiting the prefixes from the same customer cone at all customer interfaces. However, it may improperly permit the spoofing traffic from the customer cone. Besides, improper block problems will be incurred when legitimate source prefixes are not learned by EFP-uRPF, e.g., DSR. The root cause is that it cannot learn the real-forwarding paths of the legitimate source prefixes. As a result, it may mistakenly consider an invalid incoming interface as valid, resulting in improper permit problems; or consider a valid incoming interface as invalid, resulting in improper block problems. In addition, no one of existing inter-domain SAV mechanisms can be applied at all the directions of ASes to realize effective SAV in dynamic or asymmetric routing scenarios. Network operators need to figure out the network environments accurately to deploy the suitable SAV mechanisms at the corresponding interfaces with manual configurations. This also incurs extra operational overhead.

This section lists the requirements for the new SAV mechanisms, which serve as technical directions for narrowing the technical gaps of existing inter-domain SAV mechanisms. The requirements are practical points that can be fully or partially fulfilled by proposing new techniques.

The new inter-domain SAV mechanisms SHOULD improve the validation accuracy upon existing mechanisms at all directions of ASes. It SHOULD avoid the improper block problems and reduce the improper permit problems of existing inter-domain SAV mechanisms, e.g., loose uRPF and EFP-uRPF with algorithm B, in the asymmetric routing scenarios. An AS deploying the new inter-domain SAV mechanisms SHOULD be able to acquire the real incoming interfaces of the source prefixes from other ASes which also adopt the new inter-domain SAV mechanisms. In other words, accurate validation requires that SAV rules SHOULD match the real data-plane forwarding paths. Even for the cases where it is impossible or hard to acquire all the real forwarding paths, it MUST acquire the mimimal set of acceptable paths which SHOULD cover the real forwarding ones. This can help avoid improper block and minimize improper permit. Therefore, the SAV-related information from multiple sources, such as RPKI ROA objects and ASPA objects and advertisements of other ASes, can help improve the accuracy.

The new inter-domain SAV mechanism MUST be able to adapt to dynamic networks and asymmetric routing scenarios automatically, instead of entirely relying on manual update.

The new inter-domain SAV mechanisms MUST provide effective protection for source addresses even when they partially deployed in the Internet. Some ASes' routers may not be able to be easily upgraded for supporting the new SAV mechanisms due to their limitations of capabilities, versions, or vendors. Thus, it is impractical to ensure that all the ASes or most of the ASes take SAV simultaneously, partial deployment or incremental deployment has to be considered for a new inter-domain SAV mechanism. In particular, the effectiveness of protection in all directions of ASes under partial deployment SHOULD NOT be worse than existing uRPF-based SAV mechanisms.

The new inter-domain SAV mechanism should work in the same scenarios as existing inter-domain SAV mechanisms. Generally, it includes all IP-encapsulated scenarios: Native IP forwarding: including both global routing table forwarding and CE site forwarding of VPN. IP-encapsulated Tunnel (IPsec, GRE, SRv6, etc.): focusing on the validation of the outer layer IP address. Both IPv4 and IPv6 addresses. Scope does not include: Non-IP packets: including MPLS label-based forwarding and other non-IP-based forwarding. In addition, the new inter-domain SAV mechanism should not modify data-plane packets. Existing architectures or protocols or mechanisms can be used in the new SAV mechanism to achieve better SAV function.

SAV rules can be generated based on route information (FIB/RIB) or non-route information. If the information is poisoned by attackers, the SAV rules will be false. Lots of legal packets may be dropped improperly or malicious traffic with spoofed source addresses may be permitted improperly. Route security should be considered by routing protocols. Non-route information should also be protected by corresponding mechanisms or infrastructure. If SAV mechanisms or protocols require information exchange, there should be some considerations on the avoidance of message alteration or message injection. The SAV procedure referred in this document modifies no field of packets. So, security considerations on data-plane are not in the scope of this document.

This document does not request any IANA allocations.

Many thanks to Jared Mauch, Barry Greene, Fang Gao, Anthony Somerset, Kotikalapudi Sriram, Yuanyuan Zhang, Igor Lubashev, Alvaro Retana, Joel Halpern, Aijun Wang, Michael Richardson, Li Chen, Lancheng Qin, Gert Doering, Mingxing Liu, John O'Brien, Roland Dobbins, etc. for their valuable comments on this document.