Network Working Group D. Li Internet-Draft J. Wu Intended status: Informational L. Qin Expires: 3 June 2023 Tsinghua University M. Huang N. Geng Huawei 30 November 2022 Source Address Validation in Intra-domain Networks (Intra-domain SAVNET) Gap Analysis, Problem Statement and Requirements draft-li-savnet-intra-domain-problem-statement-04 Abstract Source Address Validation in Intra-domain Networks (Intra-domain SAVNET) aims to make improvements to existing intra-domain Source Address Validation (SAV). This document provides the gap analysis of existing intra-domain SAV mechanisms, describes the fundamental problems, and defines the requirements for improvements. 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 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here. 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 3 June 2023. Li, et al. Expires 3 June 2023 [Page 1] Internet-Draft Intra-domain SAVNET Problem Statement November 2022 Copyright Notice Copyright (c) 2022 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Improper Block . . . . . . . . . . . . . . . . . . . . . 4 3.2. Vulnerability in Inbound Direction . . . . . . . . . . . 6 3.2.1. Spoofing from outside the AS . . . . . . . . . . . . 6 3.2.2. Spoofing from non-deploying edge routers . . . . . . 7 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Inaccurate Validation . . . . . . . . . . . . . . . . . . 9 4.2. Limited Protection . . . . . . . . . . . . . . . . . . . 9 4.3. High Operational Overhead . . . . . . . . . . . . . . . . 9 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Accurate SAV . . . . . . . . . . . . . . . . . . . . . . 10 5.2. All-direction Protection . . . . . . . . . . . . . . . . 10 5.3. Acceptable Overhead . . . . . . . . . . . . . . . . . . . 10 6. Intra-domain SAVNET Scope . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. Normative References . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction 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[RFC7039]). When some access networks do not deploy SAV, intra-domain SAV helps filter out spoofed packets as close to the source as possible. Li, et al. Expires 3 June 2023 [Page 2] Internet-Draft Intra-domain SAVNET Problem Statement November 2022 Ingress filtering [RFC2827] [RFC3704] 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 spoofed traffic from the subnet. A subnet refers to a user network attached to the edge router. +-------------------------------------------------------------+ | AS | | +----------+ +----------+ | | | Router 5 +------------+ Router 6 | | | +----------+ +----------+ | | / \ \ | | / \ \ | | / \ +----------+ | | +----------+ +----------+ | Router 4 | | | | Router 1 | | Router 2 | +--------#-+ | | +------#---+ +--#-------+ / | | | \ / / | | | \ / +----------+ Subnet3(p3) | | \ / | Router 3 | | | \ / +-----#----+ | | Subnet1(p1) | | | Subnet2(p2) | | | +-------------------------------------------------------------+ Router 1, 2, 3,and 4 implement ingress filtering at interface # to block spoofed traffic from subnet 1, 2, and 3. Figure 1: The typical adoption of ingress filtering. 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) [RFC3704] 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 [RFC3704] are two other alternative implementations of ingress filtering, but Li, et al. Expires 3 June 2023 [Page 3] Internet-Draft Intra-domain SAVNET Problem Statement November 2022 their filtering rules are very loose and generally permit all (spoofed) 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. 2. Terminology 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. 3. Gap Analysis 3.1. Improper Block 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 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 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 Li, et al. Expires 3 June 2023 [Page 4] Internet-Draft Intra-domain SAVNET Problem Statement November 2022 learns the route to 10.1.0.0/16 from Router 5. Although Subnet 1 only expects incoming traffic destined for 10.0.0.0/16 to come from Router 2, it still sends outgoing traffic with source addresses of prefix 10.0.0.0/16 to Router 1, resulting in routing asymmetry. +-------------------------------------------------------------+ | AS | | +----------+ | | | Router 5 | | | FIB for Router 1 +----------+ FIB for Router 2 | | Dest Next_hop / \ Dest Next_hop | | 10.1.0.0/16 Subnet 1 / \ 10.0.0.0/16 Subnet 1 | | 10.0.0.0/16 Router 5 / \/ 10.1.0.0/16 Router 5 | | +----------+ +----------+ | | | Router 1 | | Router 2 | | | +-----+#+--+ +-+#+------+ | | /\ / | | Outgoing traffic with \ / Incoming traffic with | | source IP addresses \ / destination IP addresses | | of 10.0.0.0/16 \ \/ of 10.0.0.0/16 | | +----------+ | | | Subnet 1 | | | +----------+ | | (10.0.0.0/15 ) | | | +-------------------------------------------------------------+ If Router 1 and 2 apply ingress filtering at interface #: - Strict uRPF has improper block problem; - ACL-based ingress filtering requires manual update given prefix or topology update in Subnet 1 Figure 2: Asymmetric routing in multi-homed subnet scenario. Li, et al. Expires 3 June 2023 [Page 5] Internet-Draft Intra-domain SAVNET Problem Statement November 2022 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. If Router 1 and 2 apply ACL-based ingress filtering 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. 3.2. Vulnerability in Inbound Direction 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 originated from the subnet to other networks) but does not work for inbound traffic (traffic originated from other networks to the subnet). It prevents subnets from originating spoofed-source traffic, but does not protect subnets from receiving spoofed-source traffic. 3.2.1. Spoofing from outside the AS Figure 3 shows a scenario of source address spoofing from outside AS. Although the AS has applied ingress filtering at all edge routers, the spoofed traffic (even with forged intra-domain source addresses) can easily enter from inbound direction due to the lack of inbound SAV. Li, et al. Expires 3 June 2023 [Page 6] Internet-Draft Intra-domain SAVNET Problem Statement November 2022 + Spoofed traffic with source addresses | of p1, p2, or p3 +--------------|----------------------------------------------+ | | AS | | +--\/------+ +----------+ | | | Router 5 +------------> Router 6 | | | +----------+ +----------+ | | / \ \ | | / \ \/ | | \/ \/ +----------+ | | +----------+ +----------+ | Router 4 | | | | Router 1 | | Router 2 | +--------#-+ | | +------#---+ +--#-------+ / | | | \ / \/ \/ | | \ / +----------+ Subnet3(p3) | | \ / | Router 3 | | | \/ \/ +-----#----+ | | Subnet1(p1) | | | \/ | | Subnet2(p2) | +-------------------------------------------------------------+ Spoofed traffic can easily enter subnets from inbound direction without being detected by ingress filtering Figure 3: Spoofing from outside AS. 3.2.2. Spoofing from non-deploying edge routers 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 capabilities, versions, and vendors. However, when ingress filtering is partially deployed, the effectiveness of existing intra-domain SAV will be significantly degraded. Li, et al. Expires 3 June 2023 [Page 7] Internet-Draft Intra-domain SAVNET Problem Statement November 2022 +-------------------------------------------------------------+ | AS | | +----------+ +----------+ | | | Router 5 +------------> Router 6 | | | +----------+ +----------+ | | / /\ \ | | / \ \/ | | / \ +----------+ | | +----------+ +----------+ | Router 4 | | | | Router 1 | | Router 2 | +--------#-+ | | +----------+ +----------+ / | | | \ /\ / \/ | | \ / forged +----------+ Subnet3(p3) | | \ / request | Router 3 | | | | \ / +-----#----+ + | | Subnet1(p1) | Reflector | | | | | | + Subnet2(p2)-+Victim | | Attacker(spoof p2) | +-------------------------------------------------------------+ Partial deployment scenario: - Router 3 and 4 deploy 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, while Router 1 and 2 do not apply ingress filtering. In this case, although Subnet 2 and Subnet 3 cannot originate spoofed-source traffic, they may receive spoofed- source traffic or being the victim of attacks from Subnet 1. In Figure 4, to conduct a reflection attack to the victim in Subnet 2, the attacker in Subnet 1 sends a forged request with victim's source address to the reflector. Since Router 2 does not apply ingress filtering, the forged request will successfully enter the intra-domain network. The forged request cannot be identified and rejected by Router 5, Router 6, and Router 4. 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. Li, et al. Expires 3 June 2023 [Page 8] Internet-Draft Intra-domain SAVNET Problem Statement November 2022 4. Problem Statement This section summarizes the fundamental problems existing in current intra-domain SAV from the above gap analysis. The inaccurate validation, limited protection, and high operational overhead are three main factors that hinder the deployment and compromise the effectiveness of intra-domain SAV. 4.1. Inaccurate Validation 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. 4.2. Limited Protection Currently, ingress filtering is applied at edge routers and only works for traffic from directly connected subnets, resulting in the inability to block spoofed traffic from inbound direction. Therefore, spoofed traffic with intra-domain source addresses can easily flow to any subnet from outside AS or non-deploying edge routers (when intra-domain SAV is partially deployed). 4.3. High Operational Overhead Since existing intra-domain SAV mechanisms fail to adapt to dynamic or asymmetric routing scenarios, 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 impose significant operational overhead on network operators. 5. Requirements To make improvements to existing intra-domain SAV mechanisms, a new intra-domain SAV mechanism MUST satisfy the following requirements. Li, et al. Expires 3 June 2023 [Page 9] Internet-Draft Intra-domain SAVNET Problem Statement November 2022 5.1. Accurate SAV The new intra-domain SAV mechanism MUST improve the accuracy upon existing intra-domain SAV mechanisms. To achieve more accurate validation than strict uRPF, it MUST avoid improper block problems under asymmetric routing. Meanwhile, it MUST have as few improper permit problems as possible than loose uRPF. Routers MUST 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 MUST match the real data-plane forwarding path from the source. Since this requirement cannot be met by using local FIB information, additional mechanisms are needed to deliver the required information for accurate SAV. 5.2. All-direction Protection The new intra-domain SAV mechanism MUST work for traffic coming from all directions (i.e. for traffic coming from both subnet and neighboring router). To block spoofed traffic from outside the AS and from non-deploying edge routers as close to the source as possible, it MUST be deployed in more routers than just the edge routers. Especially, when partially deployed, it SHOULD be able to limit the malicious behavior of non-deploying subnets to some extent. At least, to prevent intra-domain reflection attacks, it should prevent non-deploying subnets from forging source addresses of deployed subnets. 5.3. Acceptable Overhead The new intra-domain SAV mechanism MUST be able to automatically update and adapt to dynamic or asymmetric routing scenarios, instead of relying entirely on manual update. At least, it MUST induce lower operational overhead than ACL-based SAV. In addition, the new SAV mechanism MUST avoid data-plane packet modification. Existing architectures or protocols or mechanisms can be used in the new SAV mechanism to achieve better SAV function. 6. Intra-domain SAVNET Scope 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; Li, et al. Expires 3 June 2023 [Page 10] Internet-Draft Intra-domain SAVNET Problem Statement November 2022 * Both IPv4 and IPv6 addresses Scope does not include: * Non-IP packets: including MPLS label-based forwarding and other non-IP-based forwarding. 7. Security Considerations 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 SAVNET 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. 8. IANA Considerations This document does not request any IANA allocations. 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, . [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, . [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, . Li, et al. Expires 3 June 2023 [Page 11] Internet-Draft Intra-domain SAVNET Problem Statement November 2022 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Authors' Addresses Dan Li Tsinghua University Beijing China Email: tolidan@tsinghua.edu.cn Jianping Wu Tsinghua University Beijing China Email: jianping@cernet.edu.cn Lancheng Qin Tsinghua University Beijing China Email: qlc19@mails.tsinghua.edu.cn Mingqing Huang Huawei Beijing China Email: huangmingqing@huawei.com Nan Geng Huawei Beijing China Email: gengnan@huawei.com Li, et al. Expires 3 June 2023 [Page 12]