Network Working Group H. Li Internet Draft M. Chen Intended status: Informational New H3C Technologies Expires: April 24, 2023 D. Li Tsinghua University F. Gao Zhongguancun Laboratory M. Huang Huawei October 24, 2022 Analysis of Source Address Validation Data Plane Performance draft-li-savnet-dataplane-performance-00 Abstract Source address validation (SAV) is one important way to mitigate source address spoofing attacks. However, there may be concern about whether the source address check action of the data plane would cause a great performance loss and even affect SAV deployment. This document provides an analysis of data plane implementation of SAV mechanisms, including the existing mechanisms and a new mechanism using independent SAV table. The data plane performances of different mechanisms are tested respectively. 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 April 24, 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Li, et al. Expire April 24, 2023 [Page 1] Internet-Draft SAVNET Data Plane Performance October 2022 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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. Data Plane Implementation of SAV Mechanisms....................3 2.1. ACL.......................................................3 2.2. Strict uRPF...............................................4 2.3. Loose uRPF................................................5 2.4. Independent SAV Table Mechanism...........................5 3. Performance Testing............................................7 3.1. Test Setup................................................8 3.2. Test Procedure............................................8 3.3. Test Result...............................................9 4. Conclusion....................................................11 5. Security Considerations.......................................12 6. IANA Considerations...........................................12 7. References....................................................12 7.1. Normative References.....................................12 7.2. Informative References...................................13 Authors' Addresses...............................................14 1. Introduction Source address validation (SAV) is one important way to mitigate source address spoofing attacks. Therefore, from the perspective of ensuring safety, it is desirable to deploy SAV in intra-domain and inter-domain networks. [I-D.li-savnet-intra-domain-problem-statement] and [I-D.wu-savnet- inter-domain-problem-statement] describe the current gaps, fundamental problems and core requirements for intra-domain SAV and inter-domain SAV respectively. Existing SAV mechanisms like uRPF- related technologies may improperly permit spoofed traffic or block legitimate traffic. The accuracy of the new SAVNET mechanisms is expected to improve upon the current ones. The generation of SAV table should be according to the real data plane forwarding path. Independent SAV table may be required in the data plane implementation of new SAVNET mechanisms. Li, et al. Expires April 24, 2023 [Page 2] Internet-Draft SAVNET Data Plane Performance October 2022 However, for any SAV mechanism, existing or new ones, source address checking actions are added to the data plane, which affects the forwarding performance of network devices. There may be concern about whether the source address check action of the data plane would cause a great performance loss and even affect the deployment. This document provides an analysis of data plane implementation of SAV mechanisms, including the existing mechanisms and a new mechanism using independent SAV table. The data plane performances of different mechanisms are tested respectively to quantify performance impact. 2. Data Plane Implementation of SAV Mechanisms On the data plane, the key idea of SAV is to check the validity of a packet by its source IP address and incoming interface. So, in theory, a SAV rule can be represented by a 2-tuple of {source prefix, valid incoming interface(s)}. The SAV rules are stored in a SAV table. When a router receives a packet, it queries the SAV table to check whether the source IP address and incoming interface match any rule in the table. +----------+---------------+---------------------------+ | SAV rule | Source Prefix | Valid incoming interfaces | +----------+---------------+---------------------------+ | 1 | p1 | if1, if2 | +----------+---------------+---------------------------+ | 2 | p2 | if3 | +----------+---------------+---------------------------+ | 3 | p3 | if1, if2, if3 | +----------+---------------+---------------------------+ Figure 1: Schematic of Generic SAV Table Figure 1 shows a schematic of generic SAV table. However, for different SAV mechanisms, the data plane implementations could be quite different. In this section, some of the common SAV mechanisms are analyzed as follows, based on the implementations of H3C Devices. 2.1. ACL Access Control List (ACL) is a user-ordered set of rules that is used to filter traffic. Each ACL rule is represented by an Access Control Entry (ACE). Each ACE has a group of match criteria and a group of actions. Li, et al. Expires April 24, 2023 [Page 3] Internet-Draft SAVNET Data Plane Performance October 2022 ACL is a typical implementation of ingress filtering for SAV. Operators may configure ACL rules to specify which source addresses are acceptable (or unacceptable) for which interfaces. Schematic of ACL rules for SAV is shown as Figure 2. +----------+---------------------------------------+--------+ | ACL rule | Criteria | Action | +----------+---------------------------------------+--------+ | 1 | 1) SourceAddress match p1 | Permit | | | 2) IngressInterface match if1,if2 | | +----------+---------------------------------------+--------+ | 2 | 1) SourceAddress match p2 | Permit | | | 2) IngressInterface match if3 | | +----------+---------------------------------------+--------+ | 3 | 1) SourceAddress match p3 | Permit | | | 2) IngressInterface match if1,if2,if3 | | +----------+---------------------------------------+--------+ Figure 2: Data Plane ACL Rules for SAV Each ACL rule in Figure 2 corresponds to a SAV rule in Figure 1, which maps the 2-tuple of {source prefix, valid incoming interface(s)} into match criteria of source address and ingress interface. 2.2. Strict uRPF Strict unicast Reverse Path Forwarding (uRPF) is also a typical way to implement an ingress filter for SAV [RFC3704]. The procedure is that the source address is looked up in the Forwarding Information Base (FIB) - and if the packet is received on the interface which would be used to forward the traffic to the source of the packet, it passes the check. +-----------+------------------------------------------+ | FIB Entry | Destination Prefix | Outgoing Interface | +-----------+------------------------------------------+ | 1 | p1 | ECMP -> if1,if2 | +-----------+------------------------------------------+ | 2 | p2 | if3 | +-----------+------------------------------------------+ | 3 | p3 | ECMP -> if1,if2,if3 | +-----------+------------------------------------------+ Figure 3: FIB-based Strict uRPF Data Plane On the data plane, strict uRPF needs no additional table to store SAV rules, since it re-uses the FIB. Assuming that the FIB on a Li, et al. Expires April 24, 2023 [Page 4] Internet-Draft SAVNET Data Plane Performance October 2022 router is as Figure 3, strict uRPF will perform the same function as the SAV rules in Figure 1. 2.3. Loose uRPF Loose Reverse Path Forwarding (Loose RPF) is algorithmically similar with strict RPF, but differs in that it checks only for the existence of a route, not where the route points to. +-----------+--------------------+ | FIB Entry | Destination Prefix | +-----------+--------------------+ | 1 | p1 | +-----------+--------------------+ | 2 | p2 | +-----------+--------------------+ | 3 | p3 | +-----------+--------------------+ Figure 4: FIB-based Loose uRPF Data Plane Figure 4 shows the loose uRPF based on the same FIB in Figure 3. The 'Outgoing Interface' column is omitted, since loose uRPF does not care that information. 2.4. Independent SAV Table Mechanism In order to achieve high accuracy, the new SAVNET mechanisms are expected to generate SAV rules based on the real data plane forwarding path. So, unlike uRPF, independent SAV table is required in the data plane implementation of new SAVNET mechanisms (In fact, EFP-uRPF [RFC8704] has the similar requirements). The storage and query method of SAV table can be one key factor of data plane performance, and it must be carefully designed in order to apply to multiple source address verification scenarios and achieve high scalability. If required to support incremental deployment, a SAVNET mechanism should only reject the packets with known source prefixes coming from wrong interfaces. That is to say, if the source address of a packet does not match any SAV rules, the packet should not be regarded as invalid, because the SAV table is not complete due to incremental deployment. This document provides a possible way to implement the SAVNET mechanism on data plane by using independent SAV table. Figure 6 and Figure 7 show the implementation of the generic SAV table in Figure 1 by using independent SAV table. Li, et al. Expires April 24, 2023 [Page 5] Internet-Draft SAVNET Data Plane Performance October 2022 Line Card 1 (including if1) +---------------+--------------------------+ | Key-1: | Key-2: | | Source Prefix | Valid Incoming Interface | +---------------+--------------------------+ | p1 | if1 | +---------------+--------------------------+ | p3 | if1 | +---------------+--------------------------+ Line Card 2 (including if2 and if3) +---------------+--------------------------+ | Key-1: | Key-2: | | Source Prefix | Valid Incoming Interface | +---------------+--------------------------+ | p1 | if2 | +---------------+--------------------------+ | p2 | if3 | +---------------+--------------------------+ | p3 | if2 | +---------------+--------------------------+ | p3 | if3 | +---------------+--------------------------+ Figure 6: Local SAV Table for Line Card +---------------+ | Key: | | Source Prefix | +---------------+ | p1 | +---------------+ | p2 | +---------------+ | p3 | +---------------+ Figure 7: Global SAV Table Each line card has its local SAV table which stores only part of the SAV rules related with its own interfaces. Each entry has two keys, one for source prefix, the other for valid incoming interface, and has no value field. If required to support incremental deployment, a global SAV table is also created to store all the known source prefixes. In terms of source prefixes, the global table is the union of all the local tables in different line cards. When a packet does not match any Li, et al. Expires April 24, 2023 [Page 6] Internet-Draft SAVNET Data Plane Performance October 2022 entry in the local SAV table, if its source address matches global SAV table, it is rejected, otherwise it is permitted. For example, a packet from p2 entering if1 will be rejected, and a packet from p4 entering if1 will be permitted. When a packet with Source Address of S is received from interface I, the SAV procedure is as follows: Look up both S (by longest-prefix-match) and I in local SAV table If (matched entry in local SAV table) { The packet is valid } Else { If (support Incremental-Deployment) { Look up S (by longest-prefix-match) in global SAV table If (matched entry in global SAV table) { The packet is invalid } Else { The packet is valid } } Else { The packet is invalid } } To improve the processing speed, an implementation may lookup the local SAV table and the global SAV table in parallel. The optimized procedure is as follows: Look up both S (by longest-prefix-match) and I in local SAV table Meanwhile, look up S (by longest-prefix-match) in global SAV table If (matched entry in local SAV table) { The packet is valid } Else { If (support Incremental-Deployment) and (matched entry in global SAV table) { The packet is invalid } Else { The packet is valid } } 3. Performance Testing There may be concern that the data plane performance would be a drag on the deployment of SAV. Li, et al. Expires April 24, 2023 [Page 7] Internet-Draft SAVNET Data Plane Performance October 2022 To demonstrate the data plane performance of SAV, a test is carried out on the H3C Core Router (CR) Device. All the mechanisms mentioned in Section 2 are included. For the new mechanism in Section 2.4, a rapid prototype is implemented based on H3C router for testing purposes. In addition, plain forwarding without any SAV mechanism is also tested as a basis. 3.1. Test Setup A +-------+ C ----Flow-In-->| |-->Flow-Out---- | | DUT | | | --Flow-In-->| |-->Flow-Out-- | | | B +-------+ D | | | | | | | | +-------+ | | | ------------| |------------- | | | TC | | --------------| |--------------- +-------+ Figure 8: Test Setup All the physical links are 100Gbps ethernet. The Test Center (TC) sends traffic flows to the Device Under Test (DUT). The DUT performs SAV function for the import packets. Then, the export flows are counted by the TC, and the measurement of packets per second (pps) is used to evaluate the data plane performance of SAV. Two import interfaces and two export interfaces are used in order to cover the ECMP cases. 3.2. Test Procedure The test traffic consists of small-packet flows from 1,000 different source prefixes. And the DUT is configured with the SAV rules for those prefixes. The import flows are at line rate. Li, et al. Expires April 24, 2023 [Page 8] Internet-Draft SAVNET Data Plane Performance October 2022 Test Traffic: SAV rules on DUT: Index|SrcAddr Index|SrcPfx |Intf -----+------- -----+------------------+---- 1 |s1 1 |p1(cover s1) |A&B 2 |s2 2 |p2(cover s2) |A&B ... |... ... |... |... 1000 |s1000 1000 |p1000(cover s1000)|A&B Packet Type: IPv6 Packet Size: 78 Byte Traffic Rate: 100 Gbps (Line Rate) The following mechanisms are tested respectively: o Non-SAV (Plain Forwarding without any SAV Mechanism) o ACL o Strict uRPF o Loose uRPF o Independent SAV Table Mechanism (for SAVNET) Then, the scale of sources of test traffic is raised to 10,000 and 100,000 prefixes respectively, and the test is repeated for independent SAV table mechanism to check out the scaling issue. 3.3. Test Result The test results of data plane performance of different SAV mechanisms are shown as the following: Li, et al. Expires April 24, 2023 [Page 9] Internet-Draft SAVNET Data Plane Performance October 2022 +-------+-----------------------+---------------------+ | Index | SAV Mechanism | pps of Export Flows | | | | (Ratio to Non-SAV) | +-------+-----------------------+---------------------+ | 0 | Non-SAV | 100% | +-------+-----------------------+---------------------+ | 1 | ACL | 96.6% | +-------+-----------------------+---------------------+ | 2 | Strict uRPF | 94.4% | +-------+-----------------------+---------------------+ | 3 | Loose uRPF | 94.4% | +-------+-----------------------+---------------------+ | 4 | Independent SAV Table | 94.5% | +-------+-----------------------+---------------------+ Figure 8: Test Results of Different SAV Mechanisms Compared with the plain forwarding without SAV, the loss of data plane performance after enabling any of the above SAV mechanism is about 5 percent, which can be acceptable for the deployment of SAV. According to the results, ACL has the best performance. This is not due to ACL mechanism itself, but because the DUT's NP (Network Processor) chooses to look up FIB table and ACL table on the TCAM (Ternary Content-Addressable Memory) in parallel because it regards ACL as a very common basic function. But for the other SAV mechanisms, NP looks up the FIB table by destination IP Address for forwarding and look up the FIB table (used by uRPF) or the SAV table (used by SAVNET) by source IP Address for SAV function in a serial manner. So, the outstanding test result of ACL benefits from the specific implementation. Implementations by other manufacturers may look up the FIB table and ACL table in a serial manner, in which case the test result of ACL would probably not be better than the other mechanisms. Since the scale of ACL table is usually not very large, the ACL based SAV applies to networks that are statically configured and of small scale. The performance of Strict uRPF, Loose uRPF and Independent SAV Table Mechanism are roughly equivalent. The Independent SAV Table Mechanism works slightly better than uRPF on the data plane, due to the difference between the implementation of SAV table and FIB table. Since ACL is commonly deployed in existing networks and usually supports QOS by matching various information other than source address, not only for SAV purposes, the performance test for Strict uRPF and Independent SAV Table Mechanism are repeated with 1,000 Li, et al. Expires April 24, 2023 [Page 10] Internet-Draft SAVNET Data Plane Performance October 2022 background ACL rules set for QoS. The results do not change (accurate to 0.1%), as shown in the following: +-------+-----------------------+---------------------+ | Index | SAV Mechanism | pps of Export Flows | | | | (Ratio to Non-SAV) | +-------+-----------------------+---------------------+ | 0 | Strict uRPF | 94.4% | +-------+-----------------------+---------------------+ | 1 | Independent SAV Table | 94.5% | +-------+-----------------------+---------------------+ Figure 9: Test Results with Background ACL Rules for QoS The test results of independent SAV table mechanism under different source prefix scales are shown as the following: +------------------------------------------------------+ | Independent SAV Table Mechanism | +-------+------------------------+---------------------+ | Index | Scale of Source Prefix | pps of Export Flows | | | | (Ratio to Non-SAV) | +-------+------------------------+---------------------+ | 0 | 1,000 | 94.5% | +-------+------------------------+---------------------+ | 1 | 10,000 | 94.5% | +-------+------------------------+---------------------+ | 2 | 100,000 | 94.5% | +-------+------------------------+---------------------+ Figure 10: Test Results of Different Source Prefix Scales As the scale of source prefix grows, the scale of SAV table also grows, but the pps measurement of export flows has no substantial changes. From the perspective of data plane performance, the Independent SAV Table mechanism works well in large-scale cases. 4. Conclusion Data plane performance is crucial for SAV. New SAVNET mechanisms should be carefully designed to achieve a high level of performance. A possible data plane implementation of SAVNET is analyzed, along with the comparison with the existing mechanisms. Furthermore, the data plane performances of existing SAV mechanisms and independent SAV table mechanism for SAVNET are tested on a real router. According to the test results, the loss of data plane performance compared with pure forwarding after enabling any of the above SAV Li, et al. Expires April 24, 2023 [Page 11] Internet-Draft SAVNET Data Plane Performance October 2022 mechanism is about 5 percent, which can be acceptable for the deployment of SAV. Test data shows that the Ratio to Non-SAV of independent SAV table mechanism is 94.5%,and the Ratio to Non-SAV of uRPF is 94.4%. That means independent SAV table mechanism for SAVNET is as good as the existing mechanisms on data plane. So, based on the test data, the data plane performance would not be a weak spot of SAV, whether the new SAVNET mechanisms or the existing SAV mechanisms. 5. Security Considerations TBD 6. IANA Considerations TBD 7. References 7.1. 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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [I-D.li-savnet-intra-domain-problem-statement] Li, D., Wu, J., Qin, L., Huang, M., and N. Geng, "Source Address Validation in Intra-domain Networks (Intra-domain SAVNET) Gap Analysis, Problem Statement and Requirements", Work in Progress, Internet-Draft, draft-li-savnet-intra-domain-problem- statement-01, 26 September 2022, . [I-D.wu-savnet-inter-domain-problem-statement] Wu, J., Li, D., Qin, L., Huang, M., and N. Geng, " Source Address Validation in Inter-domain Networks (Inter-domain SAVNET) Gap Analysis, Problem Statement, and Requirements", Work in Progress, Internet-Draft, draft-wu-savnet-inter-domain-problem- statement-01, 26 September 2022, . Li, et al. Expires April 24, 2023 [Page 12] Internet-Draft SAVNET Data Plane Performance October 2022 7.2. Informative References [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, . [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, . Li, et al. Expires April 24, 2023 [Page 13] Internet-Draft SAVNET Data Plane Performance October 2022 Authors' Addresses Hao Li New H3C Technologies Beijing China Email: lihao@h3c.com Mengxiao Chen New H3C Technologies Hangzhou China Email: chen.mengxiao@h3c.com Dan Li Tsinghua University Beijing China Email: tolidan@tsinghua.edu.cn Fang Gao Zhongguancun Laboratory Beijing China Email: gaofang@mail.zgclab.edu.cn Mingqing Huang Huawei Beijing China Email: huangmingqing@huawei.com Li, et al. Expires April 24, 2023 [Page 14]