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

Introduction Source Address Validation (SAV) is important for defending against source address spoofing attacks. Network operators can implement SAV mechanisms at multiple levels: access-network SAV, intra-domain SAV, and inter-domain SAV (see ). Access-network SAV (e.g., SAVI , IP Source Guard (IPSG) based on DHCP snooping , and Cable Source-Verify ) is typically deployed on switches inside the access network to prevent a host from using the source address of another host. When access-network SAV is not universally deployed, intra-domain SAV on routers can help block spoofing traffic as close to the source as possible. The "domain" used in this document means the Autonomous System (AS). For example, an AS that consists of multiple IGP instances is a single domain. If an Internet Service Provider (ISP) consists of multiple ASes, each AS is a single domain. This document focuses only on the analysis of intra-domain SAV. Unlike inter-domain SAV which requires information (e.g., Border Gateway Protocol (BGP) data) provided by other ASes to determine SAV rules, intra-domain SAV for an AS determines SAV rules solely by the AS itself without communication with other ASes. Intra-domain SAV for an AS aims at achieving two goals: i) blocking spoofed data packets originated from customer networks or host networks of the AS that use a source address of other networks; and ii) blocking spoofed data packets coming from external ASes that use a source address of the local AS. illustrates the goals of intra-domain SAV with two cases. Case i shows that the customer network or host network of AS X originates spoofed data packets using a source address of other networks. If AS X deploys intra-domain SAV, the spoofed data packets can be blocked (i.e., Goal i). Case ii shows that AS X receives spoofed data packets using a source address of AS X from an external AS. If AS X deploys intra-domain SAV, the spoofed data packets can be blocked (i.e., Goal ii).

Two Goals of intra-domain SAV | AS X | +-------------------------------+ +------+ Case ii: AS X receives spoofed data packets using a source address of AS X from an external AS Goal ii: If AS X deploys intra-domain SAV, the spoofed data packets can be blocked Spoofed data packets using a source address +------+ of AS X +------+ | AS X |<----------------------| AS Y | +------+ +------+ ]]> This document clarifies that the scope of SAV is to check the validity of the source address of data packets in IP-encapsulated scenarios including:

Native IP forwarding: including global routing table forwarding and VPN forwarding scenarios.
IP-encapsulated Tunnel (IPsec , GRE , SRv6 , etc.): focusing on the validation of the outer layer IP address.
Both IPv4 and IPv6 addresses.

SAV does not check non-IP packets in MPLS label-based forwarding and other non-IP-based forwarding scenarios. In the following, this document provides a gap analysis of existing intra-domain SAV mechanisms, concludes key problems to solve, and proposes basic requirements for future ones.

Terminology SAV Rule: The rule in a router that describes the mapping relationship between a source address (prefix) and the valid incoming interface(s). It is used by a router to make SAV decisions. Host-facing Router: An intra-domain router that is connected to hosts or switches through a layer-2 connection. Host Network: An intra-domain user network that only originates traffic and consists of hosts or/and switches. It sends traffic to other networks through the host-facing router. Customer-facing Router: An intra-domain router that is connected to customer networks through a layer-3 connection (e.g., the static route). Customer Network: An intra-domain user network that only originates traffic and consists of hosts and routers. It sends traffic to other networks through the customer-facing router. Different from host network, routers within the customer network run routing protocols. 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. SAV-specific Information: The information specialized for SAV rule generation, which is exchanged among intra-domain routers.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Existing Intra-domain SAV Mechanisms This section introduces existing intra-domain SAV mechanisms, including BCP38 and BCP84 .

ACL-based ingress filtering or BCP38 requires that network operators manually configure ACL rules on routers to block or permit data packets with specific source addresses. This mechanism can be used on interfaces of customer-facing or host-facing routers facing a customer network or host network to prevent the corresponding network from spoofing source prefixes of other networks. In addition, it is also usually used on interfaces of AS border routers facing an external AS to block data packets using disallowed source addresses, such as internal source addresses owned by the local AS . In any application scenario, ACL rules must be updated in time to be consistent with the latest filtering criteria when the network changes.
Strict uRPF is also typically used on interfaces of customer-facing or host-facing routers facing a customer network or host network. Routers deploying strict uRPF accept a data packet only when i) the local Forwarding Information Base (FIB) contains a prefix covering the packet's source address and ii) the corresponding outgoing interface for the prefix in the FIB matches the packet's incoming interface. Otherwise, the packet will be blocked.
Loose uRPF uses a looser validation method. A packet will be accepted if the router's local FIB contains a prefix covering the packet's source address regardless of the interface from which the packet is received. In fact, interfaces of AS border routers facing an external AS may use loose uRPF to block incoming data packets using non-global addresses . EFP-uRPF is another SAV mechanism which can be used on AS border routers as well. This document does not analyze EFP-uRPF because it is an inter-domain SAV mechanism with a different goal from those described in .

In summary, ACL-based ingress filtering and uRPF are the two most commonly used intra-domain SAV mechanisms. This document provides a gap analysis of these two mechanisms in .

Gap Analysis This section elaborates the key problems of current intra-domain SAV on customer-facing or host-facing routers and intra-domain SAV on AS border routers, respectively.

Intra-domain SAV on Customer-facing or Host-facing Routers Towards Goal i in , intra-domain SAV is typically deployed on interfaces of customer-facing routers or host-facing routers facing a customer network or host network to validate data packets originated from that network, since SAV is more effective when deployed closer to the source. ACL-based ingress filtering and strict uRPF are commonly used for this purpose. ACL rules must be manually updated according to prefix changes or topology changes in a timely manner. Otherwise, if ACL rules are not updated in time, improper block or improper permit problems may occur. To ensure the accuracy of ACL rules in dynamic networks, high operational overhead will be induced to achieve timely updates for ACL configurations. Strict uRPF can generate and update SAV rules in an automatic way but it will cause improper blocks in the scenario of asymmetric routing or hidden prefix.

Asymmetric Routing Asymmetric routing means a packet traverses from a source to a destination in one path and takes a different path when it returns to the source. For example, shows asymmetric routing in a multi-homing scenario. In the figure, the customer network (e.g., a campus network or an enterprise network) owns prefix 2001:db8::/32 and is connected to two routers of the AS, i.e., Router 1 and Router 2. For quality of service and backup reasons, although the customer network is connected to two routers, it expects the incoming traffic destined for prefix 2001:db8:0:1::/64 to come preferentially from Router 2. To this end, only Router 2 advertises the routing information of prefix 2001:db8:0:1::/64 in the AS. shows the FIB entries associated with prefix 2001:db8:0:1::/64 for Router 1 and Router 2 (other prefixes in the FIB are omitted for brevity). While the customer network does not expect traffic destined for prefix 2001:db8:0:1::/64 to come from Router 1, it can send traffic with source addresses of prefix 2001:db8:0:1::/64 to Router 1. As a result, there is asymmetric routing of data packets between the customer network and Router 1. Arrows in the figure indicate the flowing direction of traffic. In addition to the example, other factors (e.g., load balancing) can lead to similar asymmetric routing.

Asymmetric routing in a multi-homing scenario If Router 1 uses strict uRPF, by checking the FIB entry that matches prefix 2001:db8:0:1::/64, the SAV rule is that Router 1 only accepts data packets with source addresses of 2001:db8:0:1::/64 from Router 3. Therefore, when customer network sends data packets with source addresses of 2001:db8:0:1::/64 to Router 1, strict uRPF on Router 1 will improperly block these legitimate data packets.

Hidden Prefix In the hidden prefix scenario, the host originates data packets using a source address that is not advertised through the intra-domain routing protocol. The Content Delivery Networks (CDN) and Direct Server Return (DSR) technology is a representative example of hidden prefix scenario. The edge server in an AS will send DSR response packets using a source address of the anycast server which is located in another remote AS. However, the source address of anycast server is hidden from the intra-domain routing protocol and intra-domain routers in the AS. While this is an inter-domain scenario, DSR response packets will be improperly blocked by strict uRPF when edge server is located in a customer network or a host network.

Hidden prefix in CDN and DSR scenario For example, in , assume the edge server is located in the host network and Router 5 only learns prefix P2 from the interface connected to the host network. When edge server receives the request from the remote anycast server, it will directly return DSR response packets using the source address of anycast server (i.e., P3). If Router 5 adopts strict uRPF, the SAV rule is that Router 5 only accepts packets with source addresses of P2 from the host network. As a result, DSR response packets will be blocked by strict uRPF on Router 5. In addition, loose uRPF at this interface will also improperly block DSR response packets if prefix P3 only matches the default route in the FIB of Router 5.

Intra-domain SAV on AS Border Routers Towards Goal ii in , intra-domain SAV is typically deployed on interfaces of AS border routers facing an external AS to validate packets arriving from other ASes. shows an example of SAV on AS border routers. In the figure, Router 3 and Router 4 deploy intra-domain SAV on interface '#' for validating data packets coming from external ASes. ACL-based ingress filtering and loose uRPF are commonly used for this purpose.

An example of SAV on AS border routers By configuring ACL rules, data packets that use disallowed source addresses (e.g., non-global addresses or internal source addresses) can be blocked at AS border routers. However, the operational overhead of maintaining updated ACL rules will be extremely high when there are multiple AS border routers adopting SAV as shown in . As for loose uRPF, it sacrifices the directionality of SAV and has limited blocking capability, because it allows packets with source addresses that exist in the FIB table on all router interfaces.

Problem Statement As analyzed above, existing intra-domain SAV mechanisms have significant limitations on automatic update or accurate validation. ACL-based ingress filtering relies on manual configurations and thus requires high operational overhead in dynamic networks. To guarantee accuracy of ACL-based SAV, network operators have to manually update the ACL-based filtering rules in time when the prefix or topology changes. Otherwise, improper block or improper permit problems may appear. Strict uRPF can automatically update SAV rules, but may improperly block legitimate traffic under asymmetric routing scenario or hidden prefix scenario. As analyzed in , it may mistakenly consider a valid incoming interface as invalid, resulting in legitimate data packets being blocked (i.e., improper block problem). In summary, strict uRPF cannot guarantee the accuracy of SAV because it solely uses the router’s local FIB information to determine SAV rules, which may not match the incoming interfaces of legitimate data packets from the source in the case of asymmetric routing. As a result, strict uRPF will improperly block legitimate data packets. The network operator has a comprehensive perspective so it can configure the correct SAV rules. However, manual configuration has limitations on automatic update. Loose uRPF is also an automated SAV mechanism but its SAV rules are overly loose. As analyzed in , any spoofed data packet using a source address covered by the FIB will be accepted by loose uRPF (i.e., improper permit problem).

Requirements for New SAV Mechanisms To address the problems of current intra-domain SAV mechanisms, this section lists five basic requirements for technical improvements and related discussions that should be considered when designing the new intra-domain SAV mechanism.

Accurate Validation The new intra-domain SAV mechanism MUST improve the accuracy upon existing intra-domain SAV mechanisms. It MUST achieve the two goals described in to block those spoofing traffic from customer networks, host networks, and external ASes. Meanwhile, it MUST avoid blocking legitimate data packets, especially when there are asymmetric routes or network changes. Intra-domain SAV on a customer-facing router or host-facing router can generate an allowlist SAV rule at the interface facing the customer network or host network. The allowlist contains the source IP address space of traffic originated from the corresponding customer network or host network. Intra-domain SAV on an AS border router can generate a blocklist SAV rule at the interface facing an external AS. The blocklist contains the source IP address space of traffic originated from the local AS. To overcome the improper block problems, routers may need to use more information (e.g., SAV-specific information provided by other routers inside the same AS) other than the local FIB information to determine SAV decisions. By integrating more information, routers can learn asymmetric forwarding or routing behaviors, resulting in more accurate SAV rules.

Automatic Update The new intra-domain SAV mechanism MUST be able to automatically generate and update SAV rules on routers, rather than relying entirely on manual updates like ACL-based ingress filtering. Although some necessary configurations may be needed to improve the accuracy of SAV, automation helps reduces operational overhead in SAV rule generation.

Working in Incremental Deployment The new intra-domain SAV mechanism MUST specify the deployment scope (i.e., which routers the mechanism is used on) and MUST provide incremental benefits when incrementally deployed within the specified deployment scope. That is, it MUST NOT be effective only when fully deployed. In the incremental deployment scenario, it MUST be able to fulfill or partially fulfill the goals described in and MUST avoid improper blocks.

Fast Convergence The new intra-domain SAV mechanism MUST update SAV rules in time when prefix changes, route changes, or topology changes occur in an AS. Two considerations must be taken into account if SAV-specific information is designed and used by the new intra-domain SAV mechanism. First, the mechanism MUST allow routers to exchange the updated SAV-specific information in a timely manner. Second, the mechanism MUST NOT require routers to signal too much SAV-specific information for the SAV function, because this may greatly increase the burden on the control plane of routers and even compromise the performance of the current protocols.

Security The new intra-domain SAV mechanisms MUST NOT introduce additional security vulnerabilities or confusion to the existing intra-domain architectures or protocols. details the security scope and security considerations for the new intra-domain SAV mechanism.

Security Considerations Similar to the security scope of intra-domain routing protocols, intra-domain SAV mechanisms can ensure integrity and authentication of protocol messages that deliver the required SAV-specific information, and consider avoiding unintentional misconfiguration. It is not necessary to provide protection against compromised or malicious intra-domain routers which poison existing control or management plane protocols. Compromised or malicious intra-domain routers may not only affect SAV, but also disrupt the whole intra-domain routing domain. Security mechanisms to prevent these attacks are beyond the capability of intra-domain SAV.

IANA Considerations This document does not request any IANA allocations.

Acknowledgements Many thanks to the valuable comments from: Jared Mauch, Barry Greene, Fang Gao, Kotikalapudi Sriram, Anthony Somerset, Yuanyuan Zhang, Igor Lubashev, Alvaro Retana, Joel Halpern, Aijun Wang, Michael Richardson, Li Chen, Gert Doering, Mingxing Liu, Libin Liu, John O'Brien, Roland Dobbins, Xiangqing Chang, Tony Przygienda, Yingzhen Qu, Changwang Lin, James Guichard, Linda Dunbar, Robert Sparks, Yu Fu, Stephen Farrel etc.