Network Working Group D. Li Internet-Draft J. Wu Intended status: Informational Tsinghua Expires: 28 April 2022 M. Huang Huawei L. Qin Tsinghua N. Geng Huawei 25 October 2021 Source Address Validation: Use Cases and Gap Analysis draft-li-sav-gap-analysis-00 Abstract 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. Requirements Language 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]. Status of This Memo 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. Li, et al. Expires 28 April 2022 [Page 1] Internet-Draft SAV Use Case & Gap Analysis October 2021 Copyright Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Use Case 1: Intra-AS SAV . . . . . . . . . . . . . . . . 6 3.2. Use Case 2: Inter-AS SAV . . . . . . . . . . . . . . . . 7 4. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Existing Intra-AS SAV mechanisms . . . . . . . . . . . . 7 4.2. Existing Inter-AS SAV mechanisms . . . . . . . . . . . . 9 5. Design Considerations . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 9. Normative References . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction 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 Li, et al. Expires 28 April 2022 [Page 2] Internet-Draft SAV Use Case & Gap Analysis October 2021 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]. Li, et al. Expires 28 April 2022 [Page 3] Internet-Draft SAV Use Case & Gap Analysis October 2021 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. 2. Terminology 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 Li, et al. Expires 28 April 2022 [Page 4] Internet-Draft SAV Use Case & Gap Analysis October 2021 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. 3. Use Cases 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. Li, et al. Expires 28 April 2022 [Page 5] Internet-Draft SAV Use Case & Gap Analysis October 2021 +---------------------+ | 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 3.1. Use Case 1: Intra-AS SAV 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. Li, et al. Expires 28 April 2022 [Page 6] Internet-Draft SAV Use Case & Gap Analysis October 2021 3.2. Use Case 2: Inter-AS SAV 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. 4. Gap Analysis 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. 4.1. Existing Intra-AS SAV mechanisms 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. Li, et al. Expires 28 April 2022 [Page 7] Internet-Draft SAV Use Case & Gap Analysis October 2021 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 Li, et al. Expires 28 April 2022 [Page 8] Internet-Draft SAV Use Case & Gap Analysis October 2021 4.2. Existing Inter-AS SAV mechanisms 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 Li, et al. Expires 28 April 2022 [Page 9] Internet-Draft SAV Use Case & Gap Analysis October 2021 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. 5. Design Considerations 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 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. Li, et al. Expires 28 April 2022 [Page 10] Internet-Draft SAV Use Case & Gap Analysis October 2021 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: * High scalability. The design should not induce much overhead (e.g., bandwidth cost of path probing). A fast convergence performance under environment changes is also important for improving the scalability in different scales of networks. * High deployability. SAV tables should be generated automatically to reduce the operational cost in practice. A strategy of incremental deployment also needs to be considered. * High security. The design should include mechanisms to guarantee the integrity of probing packets. The path probing-based SAV should be free of Man-in-the-Middle Attack. 6. Security Considerations TBD 7. Contributors TBD 8. Acknowledgments TBD 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Li, et al. Expires 28 April 2022 [Page 11] Internet-Draft SAV Use Case & Gap Analysis October 2021 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, . [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, . [RFC5210] Wu, J., Bi, J., Li, X., Ren, G., Xu, K., and M. Williams, "A Source Address Validation Architecture (SAVA) Testbed and Deployment Experience", RFC 5210, DOI 10.17487/RFC5210, June 2008, . [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., "Source Address Validation Improvement (SAVI) Framework", RFC 7039, DOI 10.17487/RFC7039, October 2013, . [RFC8704] Sriram, K., Montgomery, D., and J. Haas, "Enhanced Feasible-Path Unicast Reverse Path Forwarding", BCP 84, RFC 8704, DOI 10.17487/RFC8704, February 2020, . Authors' Addresses Dan Li Tsinghua Beijing China Email: tolidan@tsinghua.edu.cn Jianping Wu Tsinghua Beijing China Email: jianping@cernet.edu.cn Mingqing Huang Huawei Beijing China Li, et al. Expires 28 April 2022 [Page 12] Internet-Draft SAV Use Case & Gap Analysis October 2021 Email: huangmingqing@huawei.com Lancheng Qin Tsinghua Beijing China Email: qlc19@mails.tsinghua.edu.cn Nan Geng Huawei Beijing China Email: gengnan@huawei.com Li, et al. Expires 28 April 2022 [Page 13]