Source Address Validation in Intra-domain Networks (Intra-domain SAVNET) Gap Analysis, Problem Statement and Requirements

Source Address Validation (SAV) is important for defending against source address spoofing attacks and accurately tracing back to the attackers. To be as effective as possible, SAV should be implemented as close to the source as possible. Given numerous access networks managed by different operators, it is difficult to require all access networks to deploy SAV at the source (e.g., SAVI). When some access networks do not deploy SAV, intra-domain SAV helps filter out spoofed packets as close to the source as possible. Ingress filtering is the current practice of intra-domain SAV. Figure 1 shows the typical adoption scenario of ingress filtering. It is typically deployed at the edge router connected to a subnet to block spoofing traffic from the subnet. A subnet refers to a user network attached to the edge router.

Static Access Control List (ACL) is a typical implementation of ingress filtering. Operators can configure some matching rules to specify which source addresses are acceptable (or unacceptable). The information of ACL should be updated manually so as to keep consistent with the newest filtering criteria, which inevitably limits the flexibility and accuracy of SAV. Strict unicast Reverse Path Forwarding (uRPF) is another suitable solution to achieve ingress filtering in intra-domain networks. Routers deploying strict uRPF accept a data packet only when i) the local forwarding information base (FIB) contains a prefix encompassing the packet's source address and ii) the corresponding forwarding next hop for the prefix matches the packet's incoming direction. Otherwise, the packet will be blocked. However, in the scenario where data packets are under asymmetric routing, strict uRPF often improperly blocks legitimate traffic. Feasible uRPF and loose uRPF are two other alternative implementations of ingress filtering, but their filtering rules are very loose and generally permit all (spoofing) packets with source addresses in the local FIB. Therefore, a new intra-domain SAV mechanism is required to improve accuracy upon current ones. This document provides the gap analysis of existing intra-domain SAV mechanisms, describes their fundamental problems, and defines the requirements for improvements.

SAV: Source Address Validation, i.e. validating the authenticity of a packet's source IP address. SAV rule: The rule generated by intra-domain SAV mechanisms that determines valid incoming interfaces for a 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 legitimate source IP addresses are blocked improperly due to inaccurate SAV rules. Improper permit: The packets with spoofed source IP addresses are permitted improperly due to inaccurate SAV rules.

Existing intra-domain SAV mechanisms can improperly block traffic with legitimate source addresses due to their technical limitations. For example, figure 2 illustrates an intra-domain scenario of multi-homed subnet. In this scenario, Subnet 1 is attached to two edge routers, i.e. Router 1 and Router 2. Although Subnet 1 owns prefix 10.0.0.0/15, Subnet 1 expects traffic destined for 10.1.0.0/16 to come only from Router 1 and traffic destined for 10.0.0.0/16 to come only from Router 2, for traffic engineering or load balance purposes. To this end, Router 1 only learns the sub prefix 10.1.0.0/16 from Subnet 1, while Router 2 only learns the other sub prefix 10.0.0.0/16 from Subnet 1. Then, Router 1 and Router 2 advertise the learned sub prefix to other routers in the AS through intra-domain routing protocols such as OSPF or IS-IS. Finally, Router 1 learns the route to 10.0.0.0/16 from Router 5, and Router 2 also learns the route to 10.1.0.0/16 from Router 5. Although Subnet 1 only expects traffic destined for 10.0.0.0/16 to come from Router 2, it still sends packets with source addresses of prefix 10.0.0.0/16 to Router 1, resulting in routing asymmetry.

If Router 1 applies strict uRPF at the subnet interface, the SAV rule is that Router 1 only accepts packets with source addresses of 10.1.0.0/16 from Subnet 1. Therefore, when Subnet 1 sends packtes with source addresses of 10.0.0.0/16 to Router 1, strict uRPF at Router 1 will improperly block these legitimate packets. Similarly, when Router 2 with strict uRPF deployed receives packets with source addresses of prefix 10.1.0.0/16 from Subnet 1, it will also improperly block these legitimate packets. If Router 1 and 2 apply ACL-based SAV at interfaces '#', it requires manual update given prefix or topology update in Subnet 1. Once the network operator does not update the ACL in time, resulting in the ACL status is inconsistent with the routing status, it will cause improper block problems as well. Overall, strict uRPF has serious improper block problem in the case of routing asymmetry, and ACL-based SAV needs high operational overhead in dynamic networks.

As shown in Figure 1, ingress filtering is typically deployed at the edge router connected to a subnet and only works for outbound traffic (traffic from the subnet to other networks) but does not work for inbound traffic (traffic from other networks to the subnet). It prevents the deployed area from sending spoofing traffic, but does not protect the deployed area from source address spoofing attacks.

Router 6 | | | +----------+ +----------+ | | / \ \ | | / \ \/ | | \/ \/ +----------+ | | +----------+ +----------+ | Router 4 | | | | Router 1 | | Router 2 | +--------#-+ | | +------#---+ +--#-------+ / | | | \ / \/ \/ | | \ / +----------+ Subnet3(p3) | | \ / | Router 3 | | | \/ \/ +-----#----+ | | Subnet1(p1) | | | \/ | | Subnet2(p2) | +-------------------------------------------------------------+ Spoofing traffic can easily enter from inbound direction without being detected by ingress filtering Figure 3: Spoofing from inbound direction. ]]> Figure 3 shows a scenario of source address spoofing from inbound direction. Although the AS has applied ingress filtering at all edge routers, the spoofing traffic (even with forged intra-domain source addresses) can easily enter from inbound direction due to the lack of inbound SAV. In practice, it is often a challenge to apply intra-domain SAV to all edge routers. For example, the improper block problem described in Section 3.1 prevents ingress filtering from being implemented in some multi-homed scenarios. In addition, there are also some routers that cannot support SAV due to their versions, vendors, and capabilities. Besides, a large intra-domain network (such as the China Education Research Network) can be managed by multiple administrators (e.g., subnets in the education network are administered by different campuses), and some administrators may not be willing to deploy SAV. As a result, incremental and partial deployment of intra-domain SAV is common. However, when ingress filtering is partially deployed, the effectiveness of intra-domain SAV will be significantly degraded.

Router 6 | | | +----------+ +----------+ | | / /\ \ | | / \ \/ | | / \ +----------+ | | +----------+ +----------+ | Router 4 | | | | Router 1 | | Router 2 | +--------#-+ | | +----------+ +----------+ / | | | \ /\ / \/ | | \ / Spoofing +----------+ Subnet3(p3) | | \ / traffic | Router 3 | | | | \ / +-----#----+ + | | Subnet1(p1) | Reflector | | | | | | + Subnet2(p2)-+Victim | | Attacker (spoof p2) | +-------------------------------------------------------------+ Partial deployment scenario: - Router 3 and 4 apply ingress filtering - Router 1 and 2 do not deploy ingress filtering Figure 4: Reflection attack in a partial deployment scenario. ]]> Figure 4 describes a reflection attack in a partial deployment scenario. Router 1, 2, 3, and 4 are edge routers, each connected to a subnet. Router 5 and 6 are two core routers that are responsible for transmitting traffic. Assume only Router 3 and 4 apply ingress filtering at subnet interfaces, and Router 1 and 2 do not apply ingress filtering. In this case, although subnets that deploy ingress filtering at the edge router (e.g., Subnet 2 and Subnet 3) cannot forge source addresses of other subnets, they are still vulnerable to reflection attacks from other non-deploying subnets (e.g., Subnet 1). For example, to conduct a reflection attack to the victim in Subnet 2, the attacker in Subnet 1 can send a forged request with victim's source address to the reflector in Subnet 3. Since Router 2 does not apply ingress filtering, the forged request will successfully enter the intra-domain network and be forwarded to the reflector. When receiving the forged request, Router 4 will also permit the request due to the lack of inbound SAV. In the end, the reflector will receive the forged request and generate a large number of responses to the victim, and the reflection attack succeeds.

A negligent edge router with ingress filtering deployed may also improperly permit spoofing traffic from the connected subnet due to non-updated or misconfigured ACL, or possible bugs in the implementation of SAV filtering. As shown in Figure 5, if Router 4 does not strictly implement SAV filtering, spoofing traffic that leaks out of itself can successfully flow to anywhere in the intra-domain network without being blocked, because other intra-domain routers (e.g., Router 6) do not apply SAV for traffic coming from neighboring routers.

To increase the resilience of intra-domain SAV to potential negligence, it is desirable to also apply SAV at other intra-domain routers to block spoofing traffic as close to the source as possible. However, existing ingress filtering is not competent to perform accurate SAV for packets received from a neighboring router. In particular, strict uRPF can cause traffic interruption in the case of asymmetric routing.

This section summarizes the fundamental problems existing in current intra-domain SAV from the above gap analysis. The inaccurate validation, high operational overhead, and limited protection of current intra-domain SAV mechanisms are three main factors that hinder the deployment and compromise the effectiveness of intra-domain SAV.

High accuracy, i.e., avoiding improper block problems while trying best to reduce improper permit problems, is the basic and key problem of an SAV mechanism. However, ACL-based ingress filtering needs manual configuration and thus faces limitations in flexibility and accuracy in dynamic networks. Strict uRPF-based ingress filtering automatically generates SAV tables, but may improperly block legitimate traffic under asymmetric routing. The root cause is that strict uRPF leverages the local FIB table to determine the incoming interface for source addresses, which may not match the real data-plane forwarding path from the source, due to the existence of asymmetric routes. Hence, it may mistakenly consider a valid incoming interface as invalid, resulting in improper block problems; or consider an invalid incoming interface as valid, resulting in improper permit problems.

Given the problem of inaccurate validation, if network operators want to apply intra-domain SAV and avoid improper block , they has to figure out which edge routers have asymmetric routing to the directly connected subnet, and implement ACL-based SAV at those edge routers instead of strict uRPF. In addition, they have to manually update the ACL filtering rules in time when the subnet's prefix or topology changes. Both identifying asymmetric routes and manual update incur significant operational overhead for operators.

Currently, ingress filtering is applied at edge routers and only works for traffic from direcly connected subnets, resulting in the inability to block spoofing traffic from inbound direction. Therefore, spoofing traffic with even intra-domain source addresses can easily flow to any subnet from outside the AS, negligent edge routers, and non-deploying subnets (when intra-domain SAV is partially deployed).

To make improvements to existing intra-domain SAV mechanisms, a new intra-domain SAV mechanism MUST satisfy the following requirements.

To determine the accurate incoming interfaces for a specific source prefix, routers MUST be able to learn the real incoming interfaces for packets originated from the subnet which owns the source prefix. In other words, SAV table generation should follow real data-plane forwarding path information. Since this requirement cannot be met by using local FIB information, additional mechanisms are needed to deliver the required information. In this way, the improper block problem under asymmetric routing can be avoided.

The mechanism MUST not induce much overhead. First, it MUST be able to automatically generate and update the SAV rules instead of relying entirely on manual configuration. Second, it MUST be applicable to different routing scenarios, reducing the operation and management overhead. In the end, it SHOULD avoid data-plane packet modification and limit the number of control-plane protocol messages.

To provide all-round protection, the new mechanism MUST work for traffic coming from all directions (i.e. for traffic from both subnet and neighboring router) and SHOULD be deployed in more routers to block spoofing traffic (from outside the AS, negligent edge routers, and non-deploying subnets) as close to the source as possible. Especially, when partially deployed, it SHOULD be able to limit the malicious behavior of non-deploying subnets to some extent. At least, to prevent reflection attacks, it should prevent non-deploying subnets from forging source addresses of deployed subnets.

Intra-domain SAVNET focuses on the same scope corresponding to existing intra-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-encapsulation 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 encapsulation: including MPLS label-based forwarding and other non-IP-based forwarding.

Intra-domain SAVNET focuses on routing protocol-based mechanisms. It aims to use or extend existing routing architecture or protocols to implement the SAV function. The intra-domain SAVNET mechanism MUST not introduce additional security vulnerabilities or confusion to the existing intra-domain control-plane protocols. Similar to the security scope of intra-domain routing protocols, intra-domain SAVNET should ensure integrity and authentication of protocol packets that deliver the required SAV information. Intra-domain SAVNET does not provide protection against compromised or misconfigured routers that poison existing control plane protocols. Such routers can not only disrupt the SAV function, but also affect the entire routing domain.

This document does not request any IANA allocations.