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]
