Source address spoofing is one of the biggest security threats to today’s Internet. By forging source IP addresses, the attacker can implement many kinds of attacks (for example, attacker-in-the-middle attacks, reflective attacks, flood-based attacks and poisoning attacks) while hiding their real identity.
Among these attacks, the reflective attack is considered the most harmful. In 2020, 55% of DDoS attacks observed by China Telecom were reflective attacks.
Source Address Validation (SAV) is important to mitigate source address spoofing. In recent years, the Mutually Agreed Norms for Routing Security (MANRS) has been calling on network operators to implement SAV.
Read: Are you filtering for inbound spoofed packets? Chances are you’re not
However, it is difficult to solve source address spoofing problems at a single ‘level’ or through a single SAV solution. To address this issue, Source Address Validation Architecture (SAVA) (RFC 5210) divides SAV into three different levels:
- Access network.
- Intra-AS.
- Inter-AS.
Source Address Validation Architecture (SAVA)
At the access network level, Source Address Validation Improvement (SAVI) is the best practice. It is implemented at switches and forces each host to use legitimate source IP addresses.
SAVI can achieve host-level authentication of the source address. However, it is fully effective only when deployed by all access networks.
Considering the large number of access networks worldwide, it is impractical to require all of them to deploy SAVI simultaneously. Hence, implementing SAV at routers at intra-AS and inter-AS levels is necessary.
At the intra-AS level, SAV is implemented at intra-AS routers and avoids source address spoofing from within Autonomous Systems (ASes). It differs from SAV being implemented at access networks, as it achieves prefix-level authentication of the source address.
Static Access Control List (ACL) and strict unicast reverse path forwarding (uRPF) are two typical SAV solutions. ACL based SAV (RFC 2827) configures matching rules to specify which source prefixes are acceptable. However, it requires manual configuration to update and lacks incentives since it only verifies outbound traffic. To overcome this drawback, strict uRPF (RFC 3704) automatically achieves SAV based on local routing information. It checks each source address in the Forwarding Information Base (FIB) and requests that the incoming direction should be the same as the forwarding direction.
At the inter-AS level, SAV is implemented at AS boundary routers and avoids source address spoofing from external ASes. It can only achieve AS-level authentication of the source address, the coarsest grained SAV.
For inter-AS SAV solutions, a combination of Enhanced Feasible-Path uRPF algorithm B (EFP-uRPF) and loose uRPF is recommended (RFC 8704). Specifically, EFP-uRPF is implemented at customer interfaces and generates an individual Reverse Path Filter (RPF) list for each customer interface. However, loose uRPF is implemented at provider and peer interfaces, which only requires that the source address appears in the local FIB.
However, existing intra-AS and inter-AS SAV solutions have false-positive or false-negative problems. False-positive problems lead to traffic disruption, while false-negative problems invalidate SAV. An ideal SAV solution should avoid false positives and minimize false negatives.
Gap analysis
Existing intra-AS SAV mechanisms have false positive problems
At the intra-AS level, the best practice strict uRPF implements SAV under the assumption that routing is symmetric. Therefore, it has serious false positive problems in the case of routing asymmetry. Figure 1 illustrates an example.
The access network owns a prefix 10.0.0.0/15. Due to traffic policy, it splits the prefix into two sub prefixes. It advertises one sub prefix to Router 1 and the other to Router 2. When Router 3 forwards packets to 10.1.0.0/16, the forwarding path is Router 3 → Router 4 → Router 2 → access network. The reverse path is access network → Router1 → Router 3. When Router 3 runs strict uRPF, the SAV rule is: packets with source addresses of 10.1.0.0/16 must arrive from Router 4. So, the reverse data flow will be mistakenly dropped.
Existing inter-AS SAV mechanisms have false-negative problems
Figure 2 illustrates the false-negative problems of existing inter-AS SAV solutions.
Assuming AS4 runs EFP-uRPF and loose uRPF, AS5 is its provider, AS3 is its peer, and AS1 and AS2 are its customers.
When AS4 runs EFP-uRPF at customer interfaces, the SAV rule is: packets with source addresses belonging to AS4’s customer cone can arrive from every customer. So, ASes in AS4’s customer cone can forge each other.
When AS4 runs loose uRPF at provider and peer interfaces, the SAV rule is: packets with any source addresses existing in FIB can arrive from every provider or peer. So, ASes outside AS4’s customer cone can forge any source address in FIB.
Design considerations
The root cause of accuracy problems of existing SAV solutions is they all achieve SAV based on local routing information, which may not match the real forwarding directions from other sources. To guarantee high accuracy, SAV should follow the real data-plane forwarding paths.
To this end, a path probing method can be taken. A router can proactively send probing packets carrying local source address information to all the destinations known by the router. These packets will be propagated to each destination along the real forwarding paths. In this way, routers along the probing paths learn the source address information, valid incoming interface pair for the original router and generate accurate SAV tables based on such pairs.
To learn more and to join the discussion please refer to our IETF drafts: draft-li-sav-gap-analysis/ and draft-li-dsav-framework/.
Contributors: Jianping Wu, Mingqing Huang, Lancheng Qin, Nan Geng
Dan Li is a Professor in the Department of Computer Science and Technology, Tsinghua University.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.