arXiv:2605.25026v1 [cs.CR] 24 May 2026
Securing High-Performance Data Transfers: Implementing AES Encryption in RDMA Systems Erik Bångsbo∗ Zakaria Hersi∗
Anna Benktson Stefan Holmgren
[email protected] [email protected] Chalmers student and Saab intern Gothenburg, Sweden
[email protected] [email protected] Saab AB Gothenburg, Sweden
Abstract Remote Direct Memory Access (RDMA) is a key enabler of highperformance systems, offering low latency, high throughput, and reduced CPU overhead by allowing direct memory-to-memory transfers between machines. However, its design bypasses traditional CPU-mediated security mechanisms, introducing critical vulnerabilities in untrusted environments. This work explores the integration of RDMA and AES-128 encryption to secure data transfers without compromising performance. We implement encryption directly within the data plane of a programmable Tofino switch using the P4 programming language. By offloading encryption from the CPU to the switch, our design preserves RDMA’s performance benefits while addressing its security shortcomings. Experimental results show that the system achieves throughput of 0.37 Gbps for 16-byte packets, 0.76 Gbps for 32-byte packets, 1.83 Gbps for 64-byte packets, and 1.9 Gbps for 128-byte packets. These findings demonstrate the feasibility of secure, high-throughput RDMA communication using programmable network hardware.
Keywords P4, AES-128 encryption, RDMA, data plane, performance evaluation, network security
1
Introduction
Remote Direct Memory Access (RDMA) [7, 11, 12], is a key technology in modern data centers and HPC environments. By enabling direct memory-to-memory transfers without CPU intervention, RDMA provides low-latency, high-throughput communication [15] for applications such as distributed storage, machine learning, and real-time analytics. This makes RDMA integral to performancecritical infrastructure. Despite its performance advantages, RDMA lacks built-in support for encryption or authentication. While beneficial for performance, this design introduces significant risks in multi-tenant or untrusted environments. Attackers can exploit RDMA’s direct memory access to read or tamper with data in transit. As a result, RDMA adoption remains limited in domains requiring strong security. Traditional RDMA security approaches rely on host-side encryption via CPUs or NICs (see e.g. [17]). However, they either reduce RDMA’s performance benefits or require higher-end custom hardware. On the other side, programmable-switch dataplane encryption has been demonstrated on Tofino [4], but only for fixedsize payloads and not for RDMA traffic. Hence, this paper addresses ∗ Both authors contributed equally to this research.
Romaric Duvignau [email protected] Chalmers University of Technology and University of Gothenburg Gothenburg, Sweden
the research question: can we secure RDMA traffic using programmable switches—without sacrificing throughput or increasing CPU load? We answer this by presenting and evaluating a practical PoC system that integrates AES-128 encryption directly into the data plane of a Tofino switch using the P4 language. State of the art. In programmable switches, even basic functions such as forwarding must be implemented in code. Establishing RDMA connectivity therefore requires implementing RDMA in P4. Previous work has shown how to do it for RoCEv1 [2] and RoCEv2 [19]. However, none of these have also implemented encryption. This becomes a problem of integration, where the correct handling of RDMA needs to work in a single program with a solution that can encrypt traffic. Prior efforts to secure high-performance data transfers have primarily focused on NIC-based encryption for RDMA, or on implementing AES within programmable switches. For example, on one hand, Taranov et al. [16] developed a NIC-based encryption mechanism that achieves low latency and high throughput for RDMA traffic. However, their approach is tightly coupled to specific hardware and incompatible with standard protocols like IPsec [9], whose performance overhead makes it unsuitable for RDMA’s stringent speed requirements. On the other hand, Chen [4] implemented AES encryption directly in the Intel Tofino switch data plane, tailoring it to the constraints of programmable switch architectures. While this solution effectively encrypts fixed 16-byte payloads, it is limited in flexibility and does not generalize well to real-world RDMA use cases that require variable packet sizes and more adaptable handling. Contributions. This work is thus the first to extend AES-based dataplane encryption specifically to high-throughput/low-latency RDMA traffic, making the following contributions: • We design and implement a dataplane encryption pipeline that supports AES-128 encryption for RDMA traffic, handling variable payload sizes in the Tofino architecture using P4. • We overcome key engineering challenges: strict switch resources and pipeline constraints, and full RDMA support. • We conduct a thorough performance evaluation, demonstrating that our solution achieves up to 1.9 Gbps throughput with minimal packet loss (<0.001%) even at smaller packet sizes, making it viable for production use. While high-end RDMA NICs offer native encryption, they are costly and introduce vendor lock-in. In contrast switch based encryption offers a compelling alternative by enabling device agnostic protection for packets from multiple sources. By centralizing the encryption process within a single unit, it simplifies system design and
,,
Erik Bångsbo, Zakaria Hersi, Anna Benktson, Stefan Holmgren, and Romaric Duvignau
RDMA Mode
Kernel
TCP/IP
Kernel
TCP/IP
RDMA
Data
Ingress Pipeline
Packet Replication Engine & Traffic Manager
Intrinsic Metadata
Packet Egress
Data
Deparser
Packet Ingress
Application Data
Packet data out
Parser
Application
User-defined Headers and Metadata
Parser
Packet data in
Deparser
Traditional Mode
Egress Pipeline
Figure 2: The pipeline architecture for TNA. Network Port
Network Port
Data
Data
Figure 1: Diagram illustrating the differences between Traditional Mode vs. RDMA Mode.
reduces the reliance on specialized hardware. Our work presents a cost-effective, centralized security PoC where the switch acts as a gatekeeper for hosts designated for other purposes. Furthermore, using pure P4 ensures architectural portability; the logic can be compiled to any P4-target. While Intel has been phasing out Tofino products from 2025 onwards, we believe that the mechanisms developed in our P4 implementation remain broadly applicable. In particular, they offer value for future switch-based processing and for the design of novel networking solutions, such as eBPF programs [10] running within the Linux kernel. Our results indicate that secure, high-throughput RDMA transfers are achievable in the dataplane without involving the host CPU, thereby preserving the original performance benefits of RDMA. This has important implications for future secure computing infrastructure in cloud and edge data centers. Threat model. We assume an adversary who can observe, replay, inject, and modify packets on the network path between RDMA hosts and the programmable switch. The primary assets are the confidentiality and integrity of RDMA traffic and the secrecy of cryptographic keys. The proposed design mitigates passive eavesdropping by offloading AES-128 encryption to the data plane, however, active attacks (e.g. replay or packet tempering) are not considered here. Paper outline. Section 2 reviews RDMA and P4 switches. Section 3 presents the design and implementation of our dataplane encryption system. Section 4 evaluates performance. Finally, Section 5 concludes insights and directions for future improvement.
2
Background
We provide here a brief overview of RDMA architecture alongside the architecture of programmable switches, relevant network programming tools and security mechanisms.
2.1
Remote Direct Memory Access
Remote Direct Memory Access (RDMA) is a key technology in HPC that enables direct memory access between servers NICs and memory, bypassing the CPU (see Figure 1’s illustration). This architecture delivers 𝜇s-level latency and data transfer speeds exceeding 100 Gbps, significantly outperforming traditional TCP/IP-based networking [15]. RDMA lacks built-in encryption, necessitating
additional security measures for broader deployment [17]. RoCEv2 (RDMA over Converged Ethernet v2) adapts RDMA for data centers by running over UDP/IP, providing scalability and compatibility with standard Ethernet infrastructure [20]. Among its transport modes, Reliable Connection (RC) is connection-oriented, guaranteeing in-order, reliable delivery between paired queue pairs (QPs) and supports Send/Receive, Write, Read, and Atomic operations while Unreliable Datagram (UD) is connectionless, with no guarantees on delivery or order and only supports Send/Receive operations. The RoCEv2 packet adds a Basic Transport Header (BTH), an Invariant Cyclic Redundancy Check (ICRC), and a Frame Check Sequence (FCS) to the standard UDP packet structure.
2.2
Intel Tofino Switch Architecture and P4
Intel’s Tofino ASIC is a programmable Ethernet switch built on the Protocol Independent Switch Architecture (PISA), programmable using the P4 language [1]. The Tofino architecture integrates multiple components—e.g. the Intelligent Fabric Processor, FPGAs/IPUs, and Xeon processors—to offer a versatile networking platform. Although Tofino lacks dedicated cryptographic hardware, it is known to offer the possibility of AES encryption directly within the data plane [4], i.e., the logical plane responsible of handling low-level protocols such as Ethernet, IP, UDP/TCP, and responsible for packet forwarding. Tofino Native Architecture (TNA) offers a P4 programming interface closely aligned with Tofino’s hardware features, enabling efficient and customized packet processing (see Figure 2). P4 (https://p4.org/) is a domain-specific language designed to program the data plane of network devices. It provides protocolindependent packet processing, allowing engineers to define headers and processing logic without being bound to specific protocols. Standard or custom packet headers can be defined within the language (via the header keyword specifying named data structures composed of typed fields with fixed bit widths, e.g., bit<48> for Ethernet addresses). First, a parser extracts headers from incoming packets via a state machine. After parsing, packet processing is driven by match-action tables that match packet header fields against entries and execute corresponding actions (e.g. modify headers, forward packets, or drop them). A deparser concludes the pipeline where packets are emitted through output ports. See [8, 14, 18] for a more comprehensive presentation of P4 and P4’s security.
2.3
Method of Encryption
This work focuses on implementing AES-128 [5], a widely used symmetric encryption standard in secure communications. We explore practical AES encryption within programmable network devices, using Scrambled Lookup Tables to overcome the absence of dedicated
Securing High-Performance Data Transfers: Implementing AES Encryption in RDMA Systems
cryptographic co-processors [4]. AES-128’s balance of hardware efficiency and adaptability makes it a standard choice for FPGA and ASIC implementations (cf. [6]). AES is a block cipher with several modes of operation offering different security and performance trade-offs. We implement here the Electronic Codebook (ECB) which encrypts each block independently by XORing plaintext with the key. Identical plaintext blocks yield identical ciphertexts, making ECB vulnerable to pattern-based attacks and is generally not recommended [3] but has the advantage of being simpler and thus more adapted for the challenging environment offered by P4 [4]. Also, it is not known if more complex and secure modes (CBC – Cipher Block Chaining, CTR – Counter Mode or GCM – Galois Counter Mode) are efficiently implementable or feasible in P4, due to programming language limitations and hardware architecture constraints.
3
Implementing RDMA and Encryption in P4
This section presents our practical implementation for secure, highperformance data transfers via RDMA, integrating AES-128 encryption on an Intel Tofino switch. We explain the AES encryption procedure and present the data plane implementation, discussing how to modify an existing AES 128-bit encryption solution to include RDMA headers and packet forwarding between hosts, limiting encryption to UDP and RDMA packets.
3.1
Data Plane Implementation
The data plane implementation builds upon an open-source solution1 for AES-128 encryption in P4 [4]. This implementation was extended to support RDMA by adding parsing and forwarding capabilities for RoCEv2 packets. In detail, the switch was modified to handle RDMA-specific headers, enable packet forwarding between hosts, and selectively apply encryption to UDP/RDMA packets. 3.1.1 Packet Types and Forwarding. During the evaluation two types of packets were used: standard UDP packets and RDMA packets. UDP packets include Ethernet (14 bytes), IP (20 bytes), and UDP (8 bytes) headers. RDMA (RoCEv2) packets have the same base structure, with an additional 16 bytes comprising the BTH and ICRC headers. While this extra header information adds slight parsing overhead, it does not affect forwarding or encryption logic beyond initial header identification. Packet forwarding in P4-enabled devices relies on programmable logic that determines packet handling based on header fields and metadata. In our implementation, we forwarded packets based on the recirculation decision. If encryption was complete, the packets were sent to the output port via the defined action set_egress_port that dynamically assigns the egress port based on parsing results, enabling flexible routing logic within the switch. Decisions were taken on a packet by packet basis through the use of match action tables that match header fields to actions; invalid packets were dropped. The forwarding logic is integrated into the ingress pipeline via the ingress control block. This ensures that all packets are subjected to forwarding decisions immediately after parsing, and before they are forwarded or further processed within the switch. 1 https://github.com/Princeton-Cabernet/p4-projects/tree/master/AES-tofino
,,
3.1.2 AES Encryption. The scrambled lookup table technique, as used in the existing AES implementation that we leverage [4], enables the deployment of AES on programmable switches, which do not support native cryptographic operations. This method exploits the large table memory of Reconfigurable Match Action Table based switches to replace complex arithmetic operations with table lookups, allowing the AES transformations to be mapped to memory-access patterns rather than sequential logic. AES is a symmetric block cipher that encrypts 128-bit data blocks through multiple rounds of transformation. Each round comprises the following steps: (1) AddRoundKey: Each byte of the data block is XORed with the corresponding byte of the round key. (2) SubBytes: Each byte is substituted using a nonlinear S-box lookup. (3) ShiftRows: Rows of the 4x4 byte matrix are cyclically shifted by varying offsets. (4) MixColumns: Each column is transformed using a fixed polynomial over a finite field to provide diffusion. These transformations are iterated over 10 rounds (for AES128), with the final round omitting the MixColumns step. In the switch pipeline, most of these transformations are precomputed and stored as lookup tables, enabling the encryption to be performed entirely through memory accesses and basic logic. The AddRoundKey and SubBytes steps were combined into a single lookup operation. This reduced the dependency chain and minimized the number of pipeline stages required. Encryption keys were uploaded to the switch via a specific control-plane Python script. This script precomputes the required lookup tables for each AES round and uses the Barefoot runtime API to populate the switch’s match-action tables with these values. To complete the full 10 rounds of AES128, packets were recirculated through the switch pipeline multiple times. Each pipeline pass handled one encryption round, resulting in a total of 10 passes per packet. On the Intel Tofino switch, two internal ports were leveraged to support this recirculation mechanism efficiently. Once encryption was complete, the packets were forwarded according to predefined rules. This ensured that encrypted traffic followed the appropriate egress path based on its destination and protocol. The use of scrambled lookup tables enabled high throughput by reducing pipeline stage consumption. The memory-efficient design allowed AES-128 encryption to be performed at approximately 11 Gbps on the Tofino switch. 3.1.3 Variable Packet Sizes. The original encryption logic was designed to handle a single 16-byte block per packet. This constraint significantly limited throughput and placed a high burden on end hosts to generate numerous small packets. Additionally, the majority of each packet consisted of protocol headers, leaving minimal room for useful payload data. To address this, we extended the implementation to support the encryption of multiple 16-byte blocks per packet. The enhanced pipeline recirculates each packet for 10 × 𝑁 rounds, where 𝑁 is the number of 16-byte blocks in the payload. This required changes to the packet parser to support variable payload sizes and additional control logic to track encryption progress and determine when recirculation should terminate.
,,
Erik Bångsbo, Zakaria Hersi, Anna Benktson, Stefan Holmgren, and Romaric Duvignau
4
Evaluation
This section outlines metrics and setups used to evaluate the tradeoff between performance and security across diverse configurations.
1
USB
7
9
11
13
15
17
19
21
23
25
27
29
31
MGMT1
2
4
6
8
10
12
14
16
18
20
22
24
26
28
30
32
UART
33
35
3
37
5
39
41
43
45
47
49
51
53
55
57
59
61
63
SYNC
34
36
38
40
42
44
46
48
50
52
54
56
58
60
62
64
40Gb/s
4.1
Evaluation Metrics
Throughput, packet loss, and latency are examined for different configurations. The objective is to explore the trade-off between performance and security, by measuring the decrease in throughput due to strengthened security. Understanding the impact of encryption on packet loss helps in assessing the feasibility and reliability of encrypted RDMA communication in practical deployment scenarios. To comprehensively assess the performance impact of RDMA with encryption, a multi-dimensional benchmarking strategy is followed. Benchmark evaluation is conducted using standardized tools such as Wireshark, Perftest, Qperf, Scapy, DPDK-Pktgen, TestPMD, and scripts to ensure repeatability and accuracy of results. The chosen benchmarks enable investigation of the following performance metrics: Throughput quantifies the volume of data successfully transmitted per unit time and is calculated as: Throughput (Mb/s) =
Total payload data transferred (Mb) (1) Total time (s)
We also measure the Mean Maximum Sustainable Throughput, i.e. averaging multiple evaluation instances conducted for different payload size. The “maximum sustainable throughput” refers to the highest level of throughput that the system can maintain while keeping packet loss at a low level. Specifically, a cap was placed on the packet loss such that the value would be below 0.001%, as was used in the 2019 Mellanox reference report from AMD. Packet loss reflects the reliability of the network, and is set as: Received (RX) packets Packet Loss (%) = 1 − × 100 (2) Transmitted (TX) packets In scenarios where RDMA is deployed, packet loss can disrupt data transmission and compromise system performance.
4.2
40Gb/s
Evaluation Setups
Our hardware topology comprises a system consisting of two servers, Computer 1 (C1) and Computer 2 (C2) with 40 Gb/sec RDMA capable Mellanox ConnectX-3 nics. The servers are interconnected via a APS BF6064X-T Tofino switch, as illustrated in Figure 3. We decided to use two baseline setups and three experimental setups to evaluate the system. For our measurements, the baseline setups were constructed in such a way as to produce data that would demonstrate the behavior of the system without our proposed improvements. Similarly, the experimental setups were constructed with the intention of producing comparable data that would be able to showcase the difference in our chosen metrics compared to the baseline setups for the proposed system. Baseline setups. The baseline configurations provide a foundation for assessing system performance with and without encryption, capturing metrics such as throughput and packet loss. These benchmarks enable direct comparisons to experimental setups, clarifying the impact of data plane encryption on overall performance. • Baseline setup 1: Generate unencrypted traffic through the switch and measure metrics (with and without RDMA).
Computer 1 Host:(.26) IP #: 192.168.1.1
NIC -> IP #: 192.168.2.1
Computer 2 Host:(.27) IP #: 192.168.1.2
NIC -> IP #: 192.168.2.2
Figure 3: Lab Setup Topology
• Baseline setup 2: Encrypt on Computer 1 and send traffic through the switch (without RDMA). Experimental setups. The experimental configurations evaluate the integration of encryption directly within the data plane. By embedding encryption within the switch, these setups help evaluate the switch’s ability to handle high-throughput encrypted traffic while maintaining RDMA performance. • Experimental setup 1: Send DPDK traffic to switch and encrypt in the switch’s dataplane. • Experimental setup 2: Generate traffic with a Python script and encrypt in the switch’s dataplane. • Experimental setup 3: Send Ib_send_bw and Qperf traffic to switch and encrypt in the switch’s dataplane and compare.
4.3
Experimental Pipeline
CPU Implementation of Encryption/Decryption. To enable unified evaluation across setups, AES-128 encryption and decryption were implemented in Python. C1 encrypts packets; C2 decrypts them. On C1, a custom packet is constructed and encrypted using AES-128 in ECB mode via the cryptography library [13], with a fixed 128-bit key. The encrypted payload is then sent to C2 over UDP, then C2 receives the packet and decrypts it using the same key/algorithm to produce the output data. Packet Generation. High-throughput packet transmission is demanding, especially for small packet sizes. As seen in the evaluation, Qperf alone could not demonstrate the full AES throughput on the Tofino switch due to inefficient small-packet generation. To address this, we used DPDK, which bypasses the kernel for faster userspace packet handling. This required a DPDK-compatible NIC and drivers.
4.4
Results
We present here the results that were obtained in the evaluation. 4.4.1 Pilot Evaluation. Preliminary measurements were conducted in a pilot study to establish typical performance figures in an unloaded scenario, the measurements were conducted between C1 and C2 through the switch. Throughput values of 21.6 Gb/sec Qperf TCP traffic and 37.2 Gb/sec for RDMA Write RC were achieved, when using a 40 Gb/sec NIC. The latency values were 8.95 𝜇s for TCP and 0.74 𝜇s for RDMA, demonstrating the clear advantages of using RDMA.
Securing High-Performance Data Transfers: Implementing AES Encryption in RDMA Systems
,,
4.4.2 Baseline Throughput and Message Rate. Our baseline measurements are shown in Figure 4 for RDMA Send UD packets and for Qperf UDP traffic, which shows that throughput increases with payload size, while message rate decreases slightly. The figure also highlights the performance advantage of RDMA. Figure 5 shows that CPU-based encryption throughput increases with payload size but remains limited overall.
4.4.4 Performance Evaluation Vs CPU-based Encryption. Integrating encryption within the switch provides substantial performance advantages compared to the computer-based encryption that was implemented with a Python script on C1. As seen in Figure 7, encryption on the switch achieves higher throughput across payload sizes and configurations. This offloading reduces CPU usage, as the CPU would otherwise be involved in both encryption and packet generation. The switch processes encryption directly, bypassing the CPU, and lowering overhead for faster data transfer rates. For example, with a payload size of 128 bytes, the switch achieves a throughput of approximately 168.98 Mb/s, vastly outperforming the computer’s 44.88 Mb/s. Both methods show increased packet loss as payload size grows, but switch-based encryption incurs slightly higher loss at larger payloads (e.g., 11.2% vs. 9.32% at 128 bytes). Despite this, its significantly higher throughput indicates more efficient handling of larger volumes of encrypted data. The rise in packet loss at higher payloads and throughput in both cases is explained by the decryption process in C2 being the bottleneck.
40
Throughput (Mb/s)
4.4.3 DPDK-Pktgen Performance Evaluation. Using DPDK-based tools for packet generation, we were able to drive high traffic rates even with smaller frames. The first evaluation of tests, therefore, examined how payload size affects our key metric—mean maximum sustainable throughput (see § 4.1). Figure 6 shows a clear upward trend: as payloads grow, sustainable throughput rises. The reason is due to the larger packets amortizing protocol overhead across more user data and reducing the number of packets the system must process, easing both CPU and I/O burdens. Practically, this means that choosing larger payload sizes can improve bandwidth utilization and overall data-transfer performance. When transmitting 256-byte payloads, packet loss rose sharply even at low load, reaching 18% at 0.03 Gbps, 38% at 0.65 Gbps, and 97% at 17.5 Gbps. This indicates that payloads above 128 bytes cannot be encrypted with acceptable loss in the current implementation. In addition, 384-byte payloads could not be compiled, suggesting that the maximum supported payload size had been reached.
Throughput vs Payload Size
Encryption on Computer
30
20
10
0 16
4.4.5 Summary of Results and Discussion. Our AES implementation on the Tofino switch achieved up to 1.9 Gbps for 128-byte payloads—competitive compared to host-based encryption but limited by hardware constraints. Parsing each 16-byte block separately likely bottlenecks performance, and added control logic restricts the number of rounds per recirculation. Optimizations, such as using the egress pipeline or dedicating physical ports to recirculation, may improve throughput.
5
Conclusion and Outlook
This work demonstrates that AES encryption for RDMA traffic can be implemented entirely in the data plane. By offloading cryptographic processing to the switch, our prototype achieved promising throughput for small to mid-sized payloads. Our results show that offloading AES-128 encryption to the data plane allows for a secure data transfer while still maintaining a tolerable RDMA performance. In particular, we achieved throughput values of 0.37 Gbps for 16-byte packets, 0.76 Gbps for 32-byte packets, 1.83 Gbps for 64-byte packets, and 1.90 Gbps for 128-byte packets when encrypting in the switch. Packet loss remained negligible below these ceilings. Larger payloads tolerated higher injection rates, whereas bursts of small packets exposed the full cost of
Qperf Throughput IB Send Throughput Qperf Msg Rate IB Send Msg Rate
1.50
4 3
10
2
5
1
0 1632 64
128
256
512
Payload Size (Bytes)
1024
Figure 4: Baseline 1: throughput and message-rate trends versus payload size in RDMA Send and Qperf tests.
Throughput (Gb/s)
15
6
Message Rate (Mpps)
Throughput (Gb/sec)
20
Mean Maximum Sustainable Throughput per Payload Size Throughput (Gb/s) 1.75
5
25
128
Figure 8 shows the throughput received in C2 as a function of the generated throughput from C1. Ideally, the two should match, while deviations indicate congestion or hardware bottlenecks. In this case, the switch became the bottleneck at higher rates, when encrypting.
7
30
64
Payload Size (bytes) Figure 5: Baseline 2: throughput vs. payload size for encrypting on C1 and sending traffic through the switch (w/o RDMA).
Qperf and RDMA ib_send: Throughput and Message Rate by Payload Size 35
32
1.25 1.00 0.75 0.50 0.25 0.00
16
32
Payload Size (Bytes)
64
128
Figure 6: DPDK-Pktgen performance metrics showing average throughput per payload size.
,,
Erik Bångsbo, Zakaria Hersi, Anna Benktson, Stefan Holmgren, and Romaric Duvignau Throughput vs Payload Size for different configurations 140
Throughput (Mb/sec)
1.0
Encryption on C1 Encryption on Switch Encryption on C1 and decryption on C2 Encryption on Switch and decryption on C2
160
0.8
120 0.6
100 80
0.4
60 40
0.2
20 0
16
32
64
0.0
128
Payload Size (Bytes)
Figure 7: Throughput comparison for encryption on switch vs. computer, with/without decryption on C2. 128 byte encryption
1.0
1.6
1.2 Received throughput (Gb/s)
Mean Packet Loss (Fraction of packet loss)
1.4 0.8
1.0
0.6
0.8 0.4
0.6 0.4
0.2
0.2 0.0
0.0 0
2
4 Generated throughput (Gb/s)
6
8
Figure 8: Received throughput on C2 as a function of generated packets on C1. encryption. Our evaluation showed robust performance for payloads up to 128 bytes. However, packet loss increased at 256 bytes, and 384-byte payloads could not be encrypted due to architectural constraint of the switch. Tofino-based encryption remains limited in terms of security. It lacks secure modes (e.g., GCM, CTR), forward secrecy, and protected host-switch links. Key areas for future work are implementing AES-CTR, enabling in-switch decryption, and implementing robust key exchange protocols to securely establish the initial encrypted session, while ensuring forward secrecy of transmitted data.
References [1] Anurag Agrawal and Changhoon Kim. 2020. Intel tofino2–a 12.9 tbps p4programmable ethernet switch. In 2020 IEEE Hot Chips 32 Symposium (HCS). IEEE Computer Society, 1–32. [2] Rutger Beltman, Silke Knossen, Joseph Hill, and Paola Grosso. 2020. Using P4 and RDMA to collect telemetry data. In 2020 IEEE/ACM Innovating the Network for Data-Intensive Science (INDIS). IEEE, 1–9. [3] Dobre Blazhevski, Adrijan Bozhinovski, Biljana Stojchevska, and Veno Pachovski. 2013. Modes of operation of the AES algorithm. The 10th Conference for Informatics and Information Technology (CIIT 2013) (2013). [4] Xiaoqi Chen. 2020. Implementing AES Encryption on Programmable Switches via Scrambled Lookup Tables. In Proceedings of the Workshop on Secure Programmable Network Infrastructure (Virtual Event, USA) (SPIN ’20). Association for Computing Machinery, New York, NY, USA, 8–14. doi:10.1145/3405669.3405819 [5] Morris J Dworkin, Elaine Barker, James R Nechvatal, James Foti, Lawrence E Bassham, E Roback, James F Dray Jr, et al. 2001. Advanced encryption standard (AES). (2001). [6] Kris Gaj and Pawel Chodowiec. 2009. FPGA and ASIC Implementations of AES. Springer, Chapter 10, 235–294. doi:10.1007/978-0-387-71817-0_10 Accessed: 2024-02-24. [7] Chuanxiong Guo, Haitao Wu, Zhong Deng, Gaurav Soni, Jianxi Ye, Jitu Padhye, and Marina Lipshteyn. 2016. RDMA over commodity ethernet at scale. In Proceedings of the 2016 ACM SIGCOMM Conference. 202–215.
[8] Frederik Hauser, Marco Häberle, Daniel Merling, Steffen Lindner, Vladimir Gurevich, Florian Zeiger, Reinhard Frank, and Michael Menth. 2023. A survey on data plane programming with p4: Fundamentals, advances, and applied research. Journal of Network and Computer Applications 212 (2023), 103561. [9] Frederik Hauser, Marco Häberle, Mark Schmidt, and Michael Menth. 2020. P4ipsec: Site-to-site and host-to-site vpn with ipsec in p4-based sdn. IEEE Access 8 (2020), 139567–139586. [10] Toke Høiland-Jørgensen, Jesper Dangaard Brouer, Daniel Borkmann, John Fastabend, Tom Herbert, David Ahern, and David Miller. 2018. The express data path: Fast programmable packet processing in the operating system kernel. In Proceedings of the 14th international conference on emerging networking experiments and technologies. 54–66. [11] Anuj Kalia, Michael Kaminsky, and David G Andersen. 2014. Using RDMA efficiently for key-value services. In Proceedings of the 2014 ACM Conference on SIGCOMM. 295–306. [12] Anuj Kalia, Michael Kaminsky, and David G Andersen. 2016. Design guidelines for high performance { RDMA } systems. In 2016 USENIX annual technical conference (USENIX ATC 16). 437–450. [13] Paul Kehrer. 2024. Python cryptography library. https://pypi.org/project/ cryptography/ Accessed: 2024-03-14. [14] Elie F. Kfoury, Jorge Crichigno, and Elias Bou-Harb. 2021. An Exhaustive Survey on P4 Programmable Data Plane Switches: Taxonomy, Applications, Challenges, and Future Trends. IEEE Access 9 (2021), 30558–30576. doi:10.1109/ACCESS.2021. 3059665 [15] Maksym Planeta, Jan Bierbaum, Michael Roitzsch, and Hermann Härtig. 2023. CoRD: Converged RDMA Dataplane for High-Performance Clouds. arXiv:2309.00898 [cs.OS] https://arxiv.org/abs/2309.00898v1 Accessed: 202406-15. [16] Benjamin Rothenberger, Konstantin Taranov, Adrian Perrig, and Torsten Hoefler. 2021. ReDMArk: Bypassing RDMA Security Mechanisms. 30th USENIX Security Symposium (USENIX Security 21) (08 2021). https://www.usenix.org/conference/ usenixsecurity21/presentation/rothenberger [17] Anna Kornfeld Simpson, Adriana Szekeres, Jacob Nelson, and Irene Zhang. 2020. Securing RDMA for High-Performance Datacenter Storage Systems. In 12th USENIX Workshop on Hot Topics in Cloud Computing (HotCloud 20). USENIX Association. https://www.usenix.org/conference/hotcloud20/presentation/kornfeldsimpson [18] Lizhuang Tan, Wei Su, Wei Zhang, Jianhui Lv, Zhenyi Zhang, Jingying Miao, Xiaoxi Liu, and Na Li. 2021. In-band Network Telemetry: A Survey. Computer Networks 186 (2021), 107763. doi:10.1016/j.comnet.2020.107763 [19] Jiarong Xing, Kuo-Feng Hsu, Yiming Qiu, Ziyang Yang, Hongyi Liu, and Ang Chen. 2022. Bedrock: Programmable Network Support for Secure { RDMA } Systems. In 31st USENIX Security Symposium (USENIX Security 22). 2585–2600. [20] Dingyu Yan, Yaping Liu, Shuo Zhang, Zhikai Yang, and Yingzhen Wang. 2023. A Survey of RoCEv2 Congestion Control. In Smart Innovation, Systems and Technologies, Vol. 350. Springer, 42–56. doi:10.1007/978-981-99-7161-9_4