| Internet-Draft | SAV Use Case & Gap Analysis | October 2021 |
| Li, et al. | Expires 28 April 2022 | [Page] |
This document identifies the importance and use cases of source address validation (SAV) at both intra-AS level and inter-AS level (see [RFC5210]). However, existing intra-AS and inter-AS SAV mechanisms, either Ingress ACL filtering [RFC2827], unicast Reverse Path Forwarding (uRPF) [RFC3704], or Enhanced Feasible-Path uRPF (EFP-uRPF) [RFC8704] has limitations in scalability or accuracy. This document provides the gap analysis of the existing SAV mechanisms followed with some design considerations.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 28 April 2022.¶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
Source Address Validation (SAV) is important for defensing against source address forgery attacks and accurately tracing back to the attackers [RFC5210]. Consider that the Internet is extremely large and complex. It is much difficult to solve the source address spoofing problem at a single "level" or through a single SAV mechanism. On the one hand, it is unrealistic to require all networks to deploy a single SAV mechanism. On the other hand, the failure of a single SAV mechanism will completely disable SAV.¶
To address the issue, Source Address Validation Architecture (SAVA) was proposed [RFC5210]. According to the operating feature of the Internet, SAVA presents a hierarchical architecture which carries out source IP address validation at three checking levels, i.e., access network, intra-AS, and inter-AS. Different levels provide different granularities of source IP address authenticity. In contrast to the single-level/point model, SAVA allows incremental deployment of SAV mechanisms while keeps effective because of its multiple-fence design. So, enhancing the source IP address validity in all the three checking levels is of high importance. Furthermore, one or more independent and loosely-coupled SAV mechanisms can coexist and cooperate under SAVA, which is friendly to different users (e.g., providers) with different policies or considerations. Obviously, the quality of SAV mechanisms for their target checking levels is key to the performance of SAV.¶
There are many SAV mechanisms for different checking levels. For the access network level, Source Address Validation Improvement (SAVI) was proposed to force each host to use legitimate source IP address [RFC7039]. SAVI acts as a purely network-based solution without special dependencies on hosts. It dynamically binds each legitimate IP address to a specific port/MAC address and verifies each packet's source address through the binding relationship. One of the most attractive features of SAVI is that it supports the maximally fine granularity of individual IP addresses, which is much finer than the previous ingress filtering mechanisms.¶
At the intra-AS level, static Access Control List (ACL) is a typical solution of SAV. Operators can configure some matching rules to specify which kind of packets 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. Loose unicast Reverse Path Forwarding (uRPF) is another solution suitable to intra-AS SAV [RFC8704]. The routers deploying loose uRPF accept any packets whose source addresses appear in the local FIB tables. Due to the loss of directionality, loose uRPF may induce false negative problems. Strict uRPF was proposed with the consideration of directionality [RFC8704]. Routers deploying strict uRPF accepts a data packet only when i) the local FIB contains a prefix encompassing the packet's source address and ii) the corresponding forwarding action for the prefix matches the packet's incoming interface. Otherwise, the packet will be dropped. However, in the scenarios (e.g., multihoming cases) where data packets are under asymmetric routing, strict uRPF often results in serious false positive problem [RFC8704].¶
At the inter-AS level, a combination of Enhanced Feasible-Path uRPF (EFP-uRPF) and loose uRPF is recommended in [RFC8704]. Particularly, EFP-uRPF is suggested to be applied on customer interfaces. EPF-uRPF on an AS can prevent its customers spoofing its upstream ASes' source addresses but fails in the case of two customers spoofing each other. On lateral peer interfaces and transit provider interfaces, loose uRPF is taken. As described previously, false negative problems may arise.¶
SAVI provides a complete and maximally fine-grained access validation, but it is impossible to deploy SAVI on every access point in the universe. The "fences" at intra- and inter-AS levels are much important for filtering source address forgery packets that are let go by access networks. However, there exist some instinctive drawbacks in the existing SAV mechanisms designed for both the intra- and inter-AS levels, which leads to inevitable false negative or false negative problems. A more complete SAV mechanism is required for both intra- and inter-AS levels.¶
This document identifies the use cases of intra- and inter-AS SAVs. These cases will help analyze the instinctive drawbacks of the existing SAV mechanisms. After that, some design considerations of overcoming the drawbacks will be presented.¶
False positive means the legitimate data packets are dropped unexpectedly. False negative indicates that the data packets with spoofed source IP addresses fail to be filtered.¶
Intra-AS SAV denotes the SAV at intra-AS level, which checks the source address validity of the data packets (i.e., EAST-WEST traffic) within an AS. Intra-AS SAV can prevent hosts/routers from spoofing other source IP blocks in the same AS.¶
Inter-AS SAV denotes the SAV at inter-AS level, which verifies the authenticity of the source address of incoming traffic (i.e., NORTH-SOUTH traffic). Particularly, the traffic arriving from the customer AS is Northward traffic. The traffic received from the provider/peer AS is Southward traffic.¶
Two types of SAV modes are defined, i.e., allowlist and blocklist. Both of them can be applied to one or more specified interfaces of a device (router or switch). The data packets with source addresses appearing in the allowlist and entering the device at the interface specified by the allowlist will be accepted. The device will drop the data packets that i) are with source addresses not included in the allowlist or ii) are with legal source addresses but enter the device at wrong interfaces. The SAV tables of all uRPF-like mechanisms belong to allowlist. On the contrary, blocklist only focus on validity of the source addresses included in the list. Specifically, the data packets with source addresses included in the blocklist will be dropped if the arrival interfaces are not expected. Otherwise, they will be accepted. As for the data packets with source addresses not included in the blocklist, the device will accept them all the time, which is the main difference from the SAV mode of allowlist. Since allowlist and blocklist can work on specified interfaces of a device, the decision on the SAV mode choice can be made for an interface adaptively.¶
Figure 1 illustrates the requirements of SAV in both intra- and inter-AS levels. AS1-AS5 belong to the same customer cone, and AS1 is the stub AS. The topology of AS2 is presented while other ASes' inner structures are hidden for brevity.¶
+---------------------+
| AS5 |
+-/\---------------/\-+
/ \
/ \
+-------------------/----------+ \
| AS2 +----------+ | \
| | Router 4 | | +------------+
| +----------+ | | AS4 |--P1''
| / \ | +-----/\-----+
| +----------+ +----------+ | |
| | Router 2 |----| Router 3 | | |
| +----------+ +----------+ | |
| | \ / | | +------------+
| P1' +----------+ P1 | | AS3 |
| | Router 1 | | +-----/\-----+
| +----------+ | /
+------------------\-----------+ /
\ /
\ /
+-----------------------+
| AS1 |
+-----------------------+
P1 is the source IP address prefix of Router3.
P1' is the spoofed P1 by Router2 located in the same AS as Router3.
P1" is the spoofed P1 by Routers located in another AS, i.e., AS4.
Figure 1: Illustration of the requirements of SAV in both intra-
and inter-AS levels¶
In some scenarios especially very large ASes, hosts/routers in the same AS may spoof each other's IP addresses. In Figure 1, Router2 spoofs P1 that originates from Router3. With Intra-AS SAV, EAST-WEST traffic can be checked, and source address spoofing attacks can be prevented. In the figure, Router1, Router3, and Router4 will drop the packets with P1' while accept those with P1, when they deploy Intra-AS SAV mechanisms. Overall, Intra-AS SAV can prevent the source address spoofing from the same AS.¶
In Figure 1, AS4 spoofs AS2's IP address prefix, i.e., P1 originated from Router3. AS5 will receive the Northward traffic from AS2 and AS4 with legitimate and spoofed IP addresses, respectively. An SAV mechanism is necessary for AS5 to drop the illegal traffic. From the view point of Southward traffic, AS1 may also receive spoofed traffic from AS3 (if AS3 accepts the data packets with source prefix P1"). So, the deployment of SAV on AS1 is also important. Overall, Inter-AS SAV is necessary and can improve the confidence of the source IP address validity among ASes.¶
Furthermore, most of the existing mechanisms applied to Intra-AS or Inter-AS SAV only take the manner of allowlist. However, a allowlist may result in false positive when a legitimate IP address does not appear in the allowlist. That is, allowlist can be incomplete.¶
In contrast, blocklist can avoid false positive in some way as it only drop illegal packets currently known by it, even though incomplete blocklist may result in false negative. The choice between allowlist and blocklist is important for improving the accuracy of SAV.¶
High accuracy is the basic requirement of any intra- or inter-AS SAV mechanism. For any SAV mechanism, false positive must be avoided because legitimate traffic must not be influenced. On that basis, SAV should also reduce false negative as much as possible. However, existing SAV mechanisms can not well meet these requirements.¶
Operators can configure static ACLs on border nodes to validate source addresses. The main drawback of ACL-based SAV is high operational overhead. Limited application scenarios make the ACL-based method unable to do sufficient SAV on EAST-WEST traffic.¶
Strict uRPF can generate SAV tables automatically, but it also has limited application scenarios. Figure 2 illustrates an intra-AS SAV scenario. In the scenario, AS1 runs strict uRPF. An access network having IP address prefix 10.0.0.0/15 is attached to two border routers (Router1 and Router2) of AS1. Due to customer's policy, it advertises 10.0.0.0/16 to Router1 and 10.1.0.0/16 to Router2. Then, Router1 and Router2 will advertise the learned IP address prefixes to other routers in AS1 through intra-domain routing protocols such as OSPF and IS-IS.¶
Although customer only advertises 10.0.0.0/16 to Router1, it may send packets with source IP addresses belonging to 10.1.0.0/16 to Router1 due to load balancing requirements. Suppose the destination node is Router5. Then the path to destination is Customer->Router1->Router3->Router5, while the reverse path is Router5->Router4->Router2->Customer. The round trip routing path is asymmetric, which cannot be dealt with well by strict uRPF.¶
Specifically speaking, strict uRPF is faced with the false positive problem under asymmetric routing scenarios. When Router1/Router3 runs strict uRPF, it learns SAV rules that packets with source address prefix of 10.0.0.0/16 should enter the router on interface '#'. Note that strict uRPF takes allowlist in which the rule <10.0.0.0/16,interface '#> is maintained. When the packets with source addresses of 10.1.0.0/16 arrive, they will be dropped, which results in false positive. Similarly, when strict uRPF is deployed on Router2, the false positive problem still exists.¶
+-----------------------------------+
| AS1 +----------+ |
| | Router 5 | |
| +----------+ |
| / \ |
| / \ |
| +----------+ +----------+ |
| | Router 3 |------| Router 4 | |
| +----#-----+ +----------+ |
| | | |
| | | |
| +----------+ +----------+ |
| | Router 1 | | Router 2 | |
| +----#-----+ +----------+ |
| \ / |
+--------\---------------/----------+
\ /
10.0.0.0/16 10.1.0.0/16
\ /
+-------------------+
| access network |----10.0.0.0/15
+-------------------+
Figure 2: An intra-AS SAV scenario¶
The most popular inter-AS SAV is suggested by [RFC8704], which combines EFP-uRPF algorithm B and loose uRPF. In particular, EFP-uRPF algorithm B is for Northward traffic validation. It sacrifices the directionality of customer interfaces for reducing false positive cases [RFC8704]. Loose uRPF is for validating Southward traffic on lateral peer and transit provider interfaces. It sacrifices directionality of Southward traffic completely. Such a combined method sacrificing directionality will leads to false negative sometimes.¶
Figure 3 illustrates an inter-AS SAV scenario where the above inter-AS SAV method will fail. In the figure, there are two customer ASes, i.e., AS1 and AS2. Both of them are attached to a provider AS, i.e., AS4. AS4 has a lateral peer and a provider, i.e., AS3 and AS5. Particularly, AS1 has IP address prefix P1 and advertises it to AS4. IP address prefix P2 is allocated to AS2 and is also advertised to AS4. AS3 has IP address prefix P3 and AS5 has IP address prefix P5. P3 and P5 are also advertised to AS4 through BGP. AS4 deploys SAV policies, i.e., a combination of EFP-uRPF algorithm B and loose uRPF.¶
+-----------------+
| AS5 (provider) +---+P5
+--------+--------+
|
| P5[AS5]
P3 |
+----------+ [AS3] +-------\/--------+
|AS3 (peer)+------>+ AS4 |
+-----+----+ +-+/\+-------+/\+-+
| / \
+ / \
P3 P1[AS1]/ \ P2[AS2]
/ \
/ \
+----------------+ +----------------+
P1+---+ AS1 (customer) | | AS2 (customer) +---+P2
+----------------+ +----------------+
Figure 3: An inter-AS SAV scenario
¶
For Northward traffic, AS4 applies EFP-uRPF. Under EFP-uRPF, AS4 will generate allowlists considering P1 and P2 are legitimate on both the two customer interfaces. When AS1 spoofs IP address prefix P2 of AS2, the malicious Northward traffic cannot be filtered by AS4. The same is true when AS2 forges P1 of AS1. That is to say, EPF-uRPF cannot prevent source address spoofing among customers even though it only focus on Northward traffic.¶
For Southward traffic, AS4 deploys loose uRPF for the interfaces of AS3 and AS5. It will learn that the packets with source addresses of P3 or P5 can be accepted without validating the specific arrival interface. Since loose uRPF loses directionality completely, it obviously will fail in dealing with the source address spoofing between its lateral peer and provider, i.e., AS3 and AS5.¶
The instinctive drawbacks of uRPF-like SAV mechanisms come from the dependence on local FIB and RIB. Local FIB and RIB roughly describe the relationship among customers, providers, and lateral peers, which inherently cannot completely restore directionality information of network traffic. The mismatching of advertised routing information and real data path (e.g., asymmetric routing) will do reduce the accuracy of source address validation.¶
The key to address the instinctive drawbacks of existing intra- and inter-AS SAV mechanisms is to overcome the limitations of advertised routing information (expressed as RIB and FIB). That is to say, SAV should follow the real data forwarding path. To this end, a path probing method can be taken. Particularly, a router (called a start router) can proactively send probing packets carrying source addresses originated locally to all the destinations known by the router. These packets will be forwarded to each destination along the real forwarding paths. Routers along the forwarding paths will relay these packets. At the same time, these traversed routers learn the pair <source address prefix, interface> infomration for the start router and could generate SAV tables based on such information. SAV tables will be used to filter packets to prevent spoofing IP addresses originated from the start router.¶
The goal of the design is to achieve zero false positive while trying best to reduce false negative in both Intra-AS and Inter-AS SAVs. In practice, it cannot be guaranteed that complete forwarding information is always learned from all interfaces. Therefore, a combination of allowlist and blocklist is an alternative way to improve the accuracy of SAV. If an interface is able to learn the complete forwarding information, allowlist is fine. Otherwise, blocklist would be better than allowlist since the former only validates the legality of learned address information.¶
Besides high accuracy, designing a practical SAV mechanism needs to consider many practical issues:¶
TBD¶
TBD¶