Internet DRAFT - draft-li-savnet-dataplane-performance

draft-li-savnet-dataplane-performance



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, <https://www.rfc-
             editor.org/info/rfc2119>.

   [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
             2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
             May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [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,
             <https://www.ietf.org/archive/id/draft-li-savnet-intra-
             domain-problem-statement-01.txt>.

   [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,
             <https://www.ietf.org/archive/id/draft-wu-savnet-inter-
             domain-problem-statement-01.txt>.


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, <https://www.rfc-editor.org/info/rfc3704>.

   [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,
             <https://www.rfc-editor.org/info/rfc8704>.






































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]