Source Address Validation in Intra-domain Networks Gap Analysis, Problem Statement and RequirementsTsinghua UniversityBeijingChinatolidan@tsinghua.edu.cnTsinghua UniversityBeijingChinajianping@cernet.edu.cnTsinghua UniversityBeijingChinaqlc19@mails.tsinghua.edu.cnHuaweiBeijingChinahuangmingqing@huawei.comHuaweiBeijingChinagengnan@huawei.comThis document provides the gap analysis of existing intra-domain source address validation mechanisms, describes the fundamental problems, and defines the requirements for technical improvements. 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.Source Address Validation (SAV) is important for defending against
source address spoofing attacks and allowing accurate traceback.
A multi-fence architecture called Source Address Validation Architecture (SAVA) was proposed to validate source addresses at three levels: access network SAV, intra-domain SAV, and inter-domain SAV.
When SAV is not fully enabled at the edge of the Internet, the multi-fence architecture can help enhance the validation across the whole Internet and thus reduce the opportunities of launching source address spoofing attacks. Particularly, access network SAV ensures a host uses a valid address assigned to the host statically or dynamically. The host cannot use the source address of another host. There are many mechanisms for SAV in access networks. Static ACL rules can be statically configured for validation by specifying which source addresses are acceptable or unacceptable. Dynamic ACL is another efficient mechanism which is associated with authentication servers (e.g., RADIUS and DIAMETER). The servers receive access requests and then install or enable ACL rules on the device to permit particular users' packets. SAVI represents a kind of mechanism enforcing that the legitimate IP address of a host matches the link-layer property of the host's network attachment. For example, SAVI solution for DHCP creates a binding between a DHCPv4/DHCPv6-assigned IP address and a link-layer property (like MAC address or switch port) on a SAVI device. IP Source Guard (IPSG) combined with DHCP snooping is an implementation of SAVI solution for DHCP. Cable Source-Verify also shares some features of SAVI and is used in cable modem networks. Cable modem termination system (CMTS) devices with Cable Source-Verify will maintain the bindings of the CPE's IP address, the CPE's MAC address, and the corresponding cable modem identifier. When receiving packets, the device will check the validity of the packets according to the bindings. Given numerous access networks managed by different operators throughout the world, it is difficult to require all access networks to effectively deploy SAV. Therefore, behind access network SAV, intra-domain SAV and inter-domain SAV are needed to provide the second- and third-level protection, respectively. Both intra-domain SAV and inter-domain SAV usually perform validation at the granularity of IP prefixes, which is coarser than access network SAV as they covers a range of IP addresses. This document focuses on the analysis of intra-domain SAV. In contrast to inter-domain SAV, intra-domain SAV does not require collaboration between networks (e.g., ASes) for SAV. The SAV rules can be generate by the network itself. Consider an AS which provides its own subnets with the connectivity to other ASes or the Internet.
The intra-domain SAV for the network has two goals: i) blocking the spoofed packets originated by the subnets from entering the network and ii) blocking the packets with the AS's prefixes as source addresses from other networks or the Internet. shows two cases for showing the effectiveness of intra-domain SAV. In case i, AS X sends the packets spoofing the source addresses of AS Z to AS Y. If AS X deploys intra-domain SAV at '#', the spoofed packets can be blocked (i.e., Goal i). In case ii, If AS Z deploys intra-domain SAV at '#', the spoofed packets will be blocked (i.e., Goal ii). There are many mechanisms for intra-domain SAV. This document provides the gap analysis of existing intra-domain SAV mechanisms. According to the gap analysis, the document concludes the main problems of existing mechanisms and describes the requirements for future intra-domain SAV mechanisms. 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 data plane. 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. Ingress filtering is the current practice of intra-domain SAV. This section briefly introduces the existing intra-domain SAV mechanisms. ACL-based ingress filtering is a typical mechanism for intra-domain SAV. ACL rules can be configured for dropping or permitting particular packets. The mechanism can be applied at the downstream interfaces of edge routers connecting the subnets or at the downstream interfaces of aggregation routers . The validation at downstream interfaces will prevent local subnets from spoofing source prefixes of other subnets. Besides, at the upstream interfaces connected to other networks or the Internet, ACL can be enabled for blocking disallowed source prefixes like the internal source prefixes owned by the subnets . In any application scenarios, ACL rules should be updated in a timely manner so as to be consistent with the most updated filtering criteria. Strict 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 FIB contains a prefix encompassing the packet's source address and ii) the corresponding outgoing interface for the prefix matches the packet's incoming interface. Otherwise, the packet will be blocked. Strict uRPF is usually used at downstream interfaces of edge routers connecting the subnets. Loose uRPF takes a looser validation approach than strict uRPF. A packet will be accepted if there is a route entry for the source address of the packet in the local FIB. The incoming interface of the packet is not checked. Loose uRPF can be enabled at any point in the network. Usually, upstream interfaces enable loose uRPF for blocking obviously disallowed source prefixes like non-global addresses . Source-based RTBH filtering is another filtering tool based on uRPF, mostly loose uRPF. Blackhole routes to specific IP addresses can be installed on the edge routers through the iBGP updates sent by a remote trigger router. The packets with the specific source addresses will be dropped after the uRPF check. Source-based RTBH filtering makes the edge routers connecting other networks or the Internet be able to drop packets with a specific source address or source prefix. Carrier Grade NAT has some operations on the source addresses of packets but is not an anti-spoofing 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. Existing intra-domain SAV mechanisms may improperly block the traffic with legitimate source addresses (i.e., improper block) or improperly permit the traffic with spoofed source addresses (i.e., improper permit) due to their technical limitations. Significant operational attention is required to keep intra-domain SAV accurate. Outbound traffic validation is used at downstream interfaces of routers to validate the packets from the connected subnets. As described previously, ACL rules can be configured at downstream interfaces for ingress filtering.
These rules need to be updated when the prefixes or topologies of subnets change. If rules updates are not conducted in time, resulting in the discrepancy between ACL configurations and routing status, ACL-based ingress filtering will cause improper block problems or improper permit problems. However, high operational overhead will be induced to achieve timely updates of ACL configurations. Strict uRPF can also be used for outbound traffic validation, but there are improper block problems in the multi-homing scenario.
shows the intra-domain scenario of
a multi-homed subnet. In the figure, Subnet 1 owns prefix 10.0.0.0/15
and is attached to two edge routers, i.e., Router 1 and Router 2.
For the load balance purposes of inbound traffic, Subnet 1 expects
the inbound traffic destined for 10.1.0.0/16 to come only from Router 1
and the inbound traffic destined for 10.0.0.0/16 to come only from Router 2.
To this end, Router 1 only learns the route to sub prefix 10.1.0.0/16
from Subnet 1, while Router 2 only learns the route to the other sub
prefix 10.0.0.0/16 from Subnet 1. Then, Router 1 and Router 2 advertise
the learned sub prefix to the 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 3, and Router 2 learns the route to 10.1.0.0/16
from Router 3. The FIBs on Router 1 and Router 2 are shown in the figure.
Although Subnet 1 only expects inbound traffic destined for 10.0.0.0/16
to come from Router 2, it may send outbound traffic with source addresses
of prefix 10.0.0.0/16 to Router 1 for outbound traffic load balancing.
Similarly, Subnet 1 may send outbound traffic with source addresses of
prefix 10.1.0.0/16 to Router 2. As a result, asymmetric routing is created. Strict uRPF takes the entries in FIB for SAV. It can improperly block the packets with legitimate source prefixes when asymmetric routing exists. In the figure, if Router 1 applies strict uRPF at 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 packets 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. So, under asymmetric routing, strict uRPF cannot be applied directly. Inbound traffic validation is performed at upstream interfaces of routers to validate the packets from other networks or the Internet. shows an example of inbound SAV.
In the figure, Router 3 and Router 4 deploy SAV mechanisms at interface '#' for validating external packets. That is, there are multiple points for inbound traffic validation. ACL-based ingress filtering is usually used for validating inbound traffic. By configuring specified ACL rules, disallowed source prefixes,
such as non-global addresses and the internal source prefixes,
can be blocked. As analyzed previously, ACL-based ingress filtering requires timely updates especially for possibly dynamic internal source prefixes. When the rules are not updated in time, there may be improper block or improper permit problems.
The ACL rules on routers for diversified purposes (not only for filtering) also induce operation challenges. Besides, the operational overhead will increase significantly when there are multiple inbound validation points as shown in . Source-based RTBH filtering improves the automation of installing SAV rules on multiple edge routers. However, the configurations on the trigger router still needs to be updated in time, which is similar to ACL-based ingress filtering. Otherwise, there will be improper block problems. Loose uRPF considers FIB as a SAV table. It is more adaptive than ACL-based ingress filtering. However, loose uRPF has limited blocking capability, e.g., cannot "generate" SAV rules for blocking internal prefixes. Some source address spoofing packets may be improperly permitted. Accurate validation and low operational overhead are two important design goals of intra-domain SAV mechanisms. As analyzed above, asymmetric routing and dynamic networks are two challenging scenarios for the two goals. In these scenarios, existing SAV mechanisms have problems of inaccurate validation and high operational overhead. ACL-based ingress filtering relies on configurations and thus faces limitations in efficiency and accuracy in dynamic networks. The limitations mainly come from the lack of automation. Operators have to update the ACL-based filtering rules in time when the subnet's prefix or topology changes. Otherwise, improper block or improper permit problems may appear. Source-based RTBH filtering has the similar gap to ACL-based ingress filtering. 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 it may consider an invalid incoming interface as valid,
resulting in improper permit problems. Loose uRPF is also an automated mechanism, but it has improper permit problems. The limitation comes from that the validation of loose uRPF depends on FIB, and FIB is not enough for achieving accurate validation. Existing intra-domain SAV mechanisms are lacking in adaptiveness in dynamic or asymmetric routing scenarios. If network operators want to apply intra-domain SAV and avoid improper block, they have to figure out which edge routers have asymmetric routing to the directly connected subnet, and implement ACL-based ingress filtering at those edge routers instead of strict uRPF. Identifying asymmetric routes also imposes operational overhead on network operators. This section lists the requirements which can be a guidance for narrowing the gaps. The requirements are some practical points that can be fully or partially fulfilled by proposing new mechanisms. The new intra-domain SAV mechanism needs to improve the accuracy upon
existing intra-domain SAV mechanisms. It SHOULD be able to learn the
real incoming interfaces for packets originated from the subnet which
owns the corresponding source prefix. In other words, accurate SAV
SHOULD match the real data-plane forwarding path from the source and
adapt to routing changes automatically. Specially, in the case of
asymmetric routing, it MUST avoid improper block problems of strict
uRPF and have no more improper permit problems than existing uRPF-based
mechanisms (e.g., strict uRPF and loose uRPF). There are cases where it is impossible or hard to guarantee that every learned path is a real forwarding path. In such cases, the learned paths MUST cover the real forwarding paths so as to avoid improper block. By finding the least number of paths while covering all the real forwarding paths, improper permit can be minimized. The new intra-domain SAV mechanism MUST be able to adapt to dynamic scenarios automatically, instead of entirely relying
on manual update. At least, it MUST require less operational
overhead than existing ACL-based ingress filtering. The new intra-domain SAV mechanism SHOULD NOT assume pervasive adoption. Some routers may not be able to be easily upgraded for supporting the new SAV mechanism due to their limitations of capabilities, versions, or vendors. The mechanism SHOULD be able to provide protection even when it is partially deployed. The effectiveness of protection under partial deployment SHOULD be no worse than automated SAV mechanisms of strict uRPF and loose uRPF. The new intra-domain SAV mechanism should work in the same scenarios
as 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-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 intra-domain SAV mechanism should avoid
data-plane packet modification. Existing architectures or protocols or
mechanisms can be used in the new SAV mechanism to achieve better SAV
function.The new intra-domain SAV mechanism MUST NOT introduce additional
security vulnerabilities or confusion to the existing intra-domain
architectures or control or management plane protocols. Similar to the
security scope of intra-domain routing protocols, intra-domain SAV mechanism
should ensure integrity and authentication of protocol packets that
deliver the required SAV information.The new intra-domain SAV mechanism 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.Many thanks to the valuable comments from: Jared Mauch, Barry Greene, Fang Gao, Anthony Somerset, Kotikalapudi Sriram, 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, etc. Source Address Validation in Inter-domain Networks Gap Analysis, Problem Statement, and RequirementsMANRS Implementation GuideMANRSResilient Interdomain Traffic Exchange: BGP Security and DDos MitigationNISTNISTConfiguring DHCP Features and IP Source GuardCiscoCable Source-Verify and IP Address SecurityCisco