Network Working Group D. Li Internet-Draft J. Wu Intended status: Informational Tsinghua Expires: 14 June 2022 M. Huang Huawei L. Qin Tsinghua N. Geng Huawei 11 December 2021 Distributed Source Address Validation (DSAV) Framework draft-li-dsav-framework-00 Abstract This document provides an overall framework of Distributed Source Address Validation (DSAV) including both intra-AS and inter-AS levels. It also describes related 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 14 June 2022. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. Li, et al. Expires 14 June 2022 [Page 1] Internet-Draft DSAV Framework December 2021 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. DSAV Framework . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Multicast Tree-like Path Probing . . . . . . . . . . . . 5 3.2. Separate Address Information Advertisement . . . . . . . 7 4. Accuracy . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Consistency . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Deployability . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Normative References . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Source address validation (SAV) is important to mitigate source address spoofing and contribute to the Internet security. However, existing SAV mechanisms have limitations in accuracy. Specifically, intra-AS SAV mechanisms (e.g. strict uRPF[RFC3704]) have serious false positive problems in the case of routing asymmetry, while inter-AS SAV mechanisms (e.g. loose uRPF[RFC3704] and EFP- uRPF[RFC8704]) have inherent false negative problems. The root cause of their limitations is that they all achieve SAV based on local forwarding information base (FIB) or routing information base (RIB), which may not match the real forwarding direction from the source. In order to guarantee the accuracy, SAV should follow the real data- plane forwarding path. Li, et al. Expires 14 June 2022 [Page 2] Internet-Draft DSAV Framework December 2021 This document provides a path probing-based framework to generate accurate SAV tables on routers at both intra-AS and inter-AS levels. In Distributed Source Address Validation (DSAV) framework, each router or AS originates probing packets carrying source address information as well as destination address information. Routers or ASes along the forwarding path can identify valid incoming interfaces for related source prefixes and relay new probing packets based on the destination address information. In particular, multicast tree- like path probing and separate address information advertisement are proposed in DSAV to reduce the communication overhead. This document also describes basic considerations related to DSAV, including accuracy, consistency, and deployability. 2. Terminology Distributed Source Address Validation (DSAV) Some definitions during a path probing process: * Node: A router or AS in this document. * Probe initiation node: The node generating original probing packets. * On-path node: The node along any of the forwarding paths of probing packets. On-path nodes with respect to a probing packet include both the traversed and destination nodes. * Probing packet: The packet originated from probe initiation nodes for generating SAV rules along its forwarding paths. 3. DSAV Framework DSAV is a path probing-based SAV framework for generating SAV rules on routers. It supports SAV at both the intra-AS and inter-AS levels. Intra-AS SAV avoids source address spoofing from within AS. Inter-AS SAV prevents source address spoofing among ASes. Despite of different application scenarios, DSAVs at the two levels hold the same key idea. The core workflow of DSAV is briefly described as follows: a. A probe initiation node (router or AS) generates probing packets carrying the source prefixes originated locally and the destination prefixes reachable by the node. Li, et al. Expires 14 June 2022 [Page 3] Internet-Draft DSAV Framework December 2021 b. Each probing packet will be forwarded from the probe initiation node to the corresponding destination node specified by the packets. c. Each on-path node along the forwarding path of the probing packet will learn the arrival interface of the probing packet. The learned interface will be considered as a legitimate arrival interface for data packets with same source IP addresses carried by the probing packet. The pair will be taken as SAV rules on on-path nodes. d. These on-path nodes will enable the learned SAV rule at their data plane. Any data packets mismatching the SAV rule will be considered as forged traffic and be dropped immediately. e. Every node can act as a probe initiation node as well as an on- path node at the same time. It can send original probing packets to protect its source addresses from be forged by attackers. Meanwhile, it can be an on-path node and generates SAV rules for source addresses of other probe initiation node. f. The above steps can be executed periodically or when any of source address information, destination address information, or forwarding rules change. Figure 1 illustrates the workflow of DSAV. There are total of four nodes in the network shown in Figure 1. The network runs some routing protocols such as OSPF, IS-IS, and BGP. Thus, Prefixes P1 and P2, belonging to Node 1 and Node 3 respectively, are reachable by all the nodes. Let's consider a path probing process where Node 1 is the probe initiation node. Node 1 sends a probing packet carrying source address information (i.e., P1) and destination address information (i.e., P2). According to the destination address information, the probe packet will be forwarded through the path of Node 1 -> Node 2 -> Node 3. Node 2 and Node 3 (i.e., on-path nodes) will learn the SAV rule for P1, i.e., the pair . The rule indicates that data packets with source addresses of P1 should arrive at Node 2 and Node 3 from interface '#'. In this way, when Node 4 forwards packets with spoofed addresses of P1' to Node 2, Node 2 will drop them immediately based on the SAV rules. Li, et al. Expires 14 June 2022 [Page 4] Internet-Draft DSAV Framework December 2021 +---------------+ | Node 1 +---+P1 +-------+-------+ | | probing pkt:src_v=[P1],dst_v=[P2] | +----------+ +-------#-------+ | Node 4 +------+ Node 2 | +-----+----+ +-------+-------+ | | + | probing pkt:src_v=[P1],dst_v=[P2] P1' | +-------#--------+ | Node 3 +---+P2 +----------------+ P1 is the source prefix of Node 1. P1' is the spoofed P1 by Node 4. P2 is the source prefix of Node 3. '#' means the legitimate interface for packets with source addresses of P1. Figure 1: An illustration of DSAV The example in Figure 1 shows a very simple DSAV scenario. In real networks, there can be lots of nodes as well as a large number of IP address prefixes. To provide a complete protection for the target network, every node can act as a probe initiation node and send probing packets, which will inevitably result in much overhead and limit the scalability of DSAV. To address the issue, two mechanisms, i.e., multicast tree-like path probing and separate prefix information advertisement, are proposed and presented next. 3.1. Multicast Tree-like Path Probing Consider that the number of probe initiation nodes and their reachable destination prefixes can be extremely large. The communication overhead of DSAV is unacceptable for each node sending an individual probing packet to each reachable destination prefix. Multicast tree-like path probing is such a mechanism that can greatly reduce the number of probing packets. Particularly, a probe initiation node only needs to send one probing packet to each of its neighboring nodes (Here, packet fragmentation is not considered for brevity). Each probing packet carries a source prefix list and a destination prefix list. The source prefix list includes all the source address prefixes originated locally. The destination prefix list contains all the reachable destination Li, et al. Expires 14 June 2022 [Page 5] Internet-Draft DSAV Framework December 2021 prefixes corresponding to the same next hop in the FIB. Then, the probing packet is sent to the corresponding next-hop node, i.e., the on-path node of the probing packet. The on-path node receives the probing packet and generates SAV rules in the same way as described previously. After that, the on-path node relays the received probing packet and sends packets to one or more neighboring nodes according to the destination prefix list of the received packet. Each probing packet relayed by the on-path node carries an updated destination prefix list that is a subset of the original list. The updated list contains only the destination prefixes of the original list corresponding to the same neighboring node. Note that, the source prefix list has no need to be updated. The relayed probing packet will then continue probing forwarding paths through the updated destination prefix list. The following on-path nodes will generate SAV rules accordingly and relay the probing packets until reaching all the destination nodes. The traversed forwarding paths during a path probing process look like a multicast tree, and the probe initiation node of the process is the root of the tree. +----------+ | Node 1 +---+P1 +----+-----+ | pkt:src_v=[P1], | dst_v=[P2,P3,P4] pkt:src_v=[P1], | +----------+ dst_v=[P4] +-----#-----+ | Node 4 #-------------+ Node 2 |---+P2 +-----+----+ +-----+-----+ | | pkt:src_v=[P1], + | dst_v=[P3] P4 | +-----#-----+ | Node 3 +---+P3 +-----------+ P1, P2, P3, and P4 are IP address prefixes belonging to Node 1, 2, 3, and 4, respectively. Node 1 is the probe initiation node, and the other nodes are on-path nodes. '#' means the legitimate interface for the packets with source addresses of P1. Figure 2: An example of multicast tree-like path probing An example of multicast tree-like path probing is shown in Figure 2. Node 1 is the probe initiation node, and P2~P4 are reachable locally. Node 1 sends a probing packet to Node 2 with source prefix list [P1] and destination prefix list [P2, P3, P4]. Node 2 learns the SAV rule from the probing packet and relays the packet with updated Li, et al. Expires 14 June 2022 [Page 6] Internet-Draft DSAV Framework December 2021 destination prefix list to Node 3 and 4. The source prefix list keeps unchanged, while the destination prefix list is updated according to the forwarding rules on Node 2. Finally, Node 2~4 learn and enable the SAV rule, i.e., . With multicast tree-like path probing, DSAV can reduce much unnecessary probing packets in networks and thus consumes less network resources. 3.2. Separate Address Information Advertisement Probing packets may have large packet sizes because their source and destination prefix lists can be very large. Besides, a binding of prefix information advertisement and path probing will sometimes induce much unnecessary overhead. For example, a change on either destination prefix information or forwarding rules will make the probe initiation node advertise its source address information again even though no changes happen on source address information at all. Separate address information advertisement is taken to tackle the above problem by decoupling address information advertisement and path probing. Particularly, a node can be represented by a node ID (e.g., the router-ID for a router or the ASN for an AS). For each probe initiation node, its source addresses together with its node ID can be advertised to other nodes through broadcast or existing underlay routing protocols (such as OSPF, IS-IS, and BGP). Then, every node will know the mappings from a node ID to a list of source addresses. Now, probing packets do not need to carry a long list of source address prefixes whose field can be replaced with just one source node ID. Similarly, the reachable destination information of each probe initiation node can also be advertised separately, and then the destination prefix list in a probing packet can be replaced with a list of destination node IDs. However, the replacement of source and destination prefix lists may result in false negative problems in some scenarios where the destination prefixes belonging to the same destination node have different forwarding paths. Some additional mechanisms need to be imported into these scenarios. Li, et al. Expires 14 June 2022 [Page 7] Internet-Draft DSAV Framework December 2021 4. Accuracy The goal of DSAV is to achieve high accuracy, i.e., achieve zero false positive and try best to reduce false negative. Zero false positive guarantees legitimate traffic not being dropped by mistake, while reducing false negative means filtering source address forgery traffic as much as possible. The accuracy of DSAV is determined by the accuracy of source address information advertisement, destination address information advertisement, and path probing results. The completeness of address information advertisement is important for the accuracy improvement of DSAV. So, each probe initiation node should discover and advertise local address information carefully with the help of either automatic programs or manual configurations. In the case of incomplete address information advertisement, on-path nodes can take a remedy method in their data planes, i.e., a combination of allowlist and blocklist. Allowlist blocks any packets with unknown source addresses or illegal arrival interfaces, which requires complete address information advertisement. In contrast, blocklist only drops packets with known source addresses but illegal arrival interfaces. Packets with unknown source addresses are accepted under blocklist. Combining allowlist and blocklist properly is helpful to eliminate false positive cases. The accuracy of path probing is also challenging. Path probing should fully discover all the real forwarding paths of each destination prefix. Any factor that can affect forwarding should be considered. Here are three kinds of common forwarding cases: * FIBs only match destination address prefixes. * ECMP (Equal-cost multi-path routing) or UCMP (Unequal-cost multi- path routing). To achieve multi-path routing, hashing functions are usually taken, which map packet header field values (e.g., source/destination IP address, source/destination port number, protocol number) to candidate next hops. Packets with the same destination IP address may be forwarding to different next hops. * ACL redirection. An ACL rule can have multiple match fields, and the match field of destination IP addresses can be included or not in an ACL rule. So, similar to ECMP/UCMP, the packets with the same destination IP address may have different next-hop interfaces. Li, et al. Expires 14 June 2022 [Page 8] Internet-Draft DSAV Framework December 2021 To achieve high accuracy of path probing, either a probe initiation node or an on-path node need to answer two questions accurately: which set of next-hop interfaces are for probing and what is the destination prefix list of the probing packet for each next-hop interface. Before sending/relaying probing packets, a node should look up all the local forwarding rules to answer the above two questions. 5. Consistency The factors influencing the accuracy of DSAV may change with time. Such changes will lower the performance of SAV and lead to false positive/negative problems. The SAV rules generated through DSAV should be updated in time so as to keep consistent with new source address information, destination address information or path probing results. The consistency of DSAV is important for the SAV framework working well in real networks. A simple method is to update source/destination address information and probe forwarding paths periodically. An aging mechanism can also be used for SAV rules. That is, SAV rules will expire after a period of time. However, these solutions may take much time before eliminating false positive/negative. Some quick convergence mechanisms are necessary to achieve consistency of DSAV in time. Here are some preliminary ideas for different cases: * Address information changes. A node sends new information advertisements immediately upon discovering its local source/ destination address information changes. * Forwarding path changes. On-path nodes can store the probing information of recently relayed probing packets. When route configuration or topology changes, some nodes' forwarding rules become different. These nodes can generate probing packets for themselves as well as the nodes whose probing packets were ever relayed by them. Then, new forwarding paths can be probed quickly. For the scenarios where fast reroute (FRR) is deployed, the backup forwarding paths can be pre-probed, and the corresponding SAV rules can be installed in advance for fast convergence under failures. Li, et al. Expires 14 June 2022 [Page 9] Internet-Draft DSAV Framework December 2021 6. Deployability It is difficult to ensure that all nodes deploy DSAV simultaneously, especially at inter-AS level. In this case, each node only learns partial source address information or incomplete legitimate incoming interfaces for a source prefix, which can lead to false positive problems. Therefore, DSAV should support incremental and partial deployment. When deployed incrementally or partially, nodes should still achieve zero false positive and minimize false negative based on incomplete SAV tables. The process of data-plane SAV is as follows: * For the source address whose source address information and incoming interface information are fully learned, nodes can strictly validate the authenticity by querying in SAV tables, i.e. allowlist mode. * For the source address whose source address information or incoming interface information is only partially learned or even not learned, nodes should pass those packets by default to avoid false positive problems, i.e. blocklist mode, since it is hard to identify the authenticity with incomplete information. Since inter-AS topology is greatly complex and ASes are managed by individual network operators, determining wheter the incoming interface information for a source prefix is learned completely is a real challenge. Besides, in DSAV framework, neighboring (next-hop) node plays an important role in the propagation of probing packets, namely, a node cannot send or receive any probing packet if its neighboring nodes don't support DSAV. Hence, at inter-AS level, DSAV recommends incremental deployment by customer cones. This deployment pattern ensures that each AS learns complete source address information and incoming interface information for other ASes within the same customer cone. With the merger of different customer cones where DSAV is deployed, the deployment scope of DSAV will gradually expand, and the defense capability against source address spoofing will gradually increase. 7. Security TBD 8. Normative References Li, et al. Expires 14 June 2022 [Page 10] Internet-Draft DSAV Framework December 2021 [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, . [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 Li, et al. Expires 14 June 2022 [Page 11] Internet-Draft DSAV Framework December 2021 Mingqing Huang Huawei Beijing China 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 14 June 2022 [Page 12]