OVS Meets PQ-TLS: Exploring Post-Quantum TLS for SDN's Southbound API

OVS Meets PQ-TLS: Exploring Post-Quantum TLS for SDN’s Southbound API Majd Latah

Kubra Kalkan

Ozyegin University Istanbul, Turkey majd.latah@ozu.edu.tr

Ozyegin University Istanbul, Turkey kubra.kalkan@ozyegin.edu.tr

arXiv:2608.16582v1 [cs.NI] 17 Aug 2026

Abstract Software-defined networking (SDN) is a novel networking paradigm that enables network programmability and centralized control for network devices. The southbound application programming interface (API) is used to control and manage the underlying data plane devices. The existing southbound API relies on TLS with legacy cryptographic algorithms such as RSA and ECDSA. In this paper, we explore the performance of the southbound API with postquantum TLS (PQ-TLS) support. We present a proof-of-concept of using PQ-TLS in SDN’s southbound API. We study the performance of pure and hybrid PQ-TLS modes across different security levels and compare them with legacy TLS in terms of latency and CPU utilization. We also compare the performance of different post-quantum signature and key establishment schemes.

CCS Concepts • Networks → Security protocols; • Security and privacy → Authentication.

Keywords PQ-TLS, OVS, SDN, Southbound API ACM Reference Format: Majd Latah and Kubra Kalkan. 2026. OVS Meets PQ-TLS: Exploring PostQuantum TLS for SDN’s Southbound API. In Proceedings of (ICFNDS ’26). ACM, New York, NY, USA, 5 pages. https://doi.org/XXXXXXX.XXXXXXX

SDN Controller with legacy TLS Southbound API SDN Switch (OVS) with legacy TLS

Figure 1: SDN’s southbound API protected using legacy TLS

security categories [7] for post-quantum alternatives. PQ-TLS relies on cryptographic algorithms that claim to satisfy those security levels. In this work, we explore PQ-TLS for protecting the southbound API in SDN. We focus on a well-known SDN switch (i.e., OVS), which is a software switch widely used in SDN. We present a proof of concept in which PQ-TLS is compared with legacy TLS in terms of handshake latency and CPU utilization. In addition, we compare the performance of different PQ signature and key establishment schemes for securing the southbound API in SDN environments.

2 1

Introduction

SDN consists of three main planes: 1) data plane 2) control plane, and 3) application plane [1, 10]. SDN planes are connected through two main Application Programming Interfaces (APIs) [1, 10]: • Southbound API: an interface between the SDN controller and a corresponding SDN switch. • Northbound API: an interface between the SDN applications and a corresponding SDN controller. Our work focuses on the security of the southbound API. In this context, SDN uses the Transport Layer Security (TLS) protocol to secure its southbound API (See Fig. 1). Existing approaches based on legacy TLS do not provide security against post-quantum (PQ) adversaries. It is worth noting that the cryptographic algorithms used in legacy TLS, such as ECDSA and RSA, do not provide security against quantum attacks. In this regard, NIST defined five ICFNDS ’26, Izmir, Turkey © 2026 Copyright held by the owner/author(s). Publication rights licensed to ACM. This is the author’s version of the work. It is posted here for your personal use. Not for redistribution. The definitive Version of Record was published in Proceedings of (ICFNDS ’26), https://doi.org/XXXXXXX.XXXXXXX.

Related work

The southbound API of SDN relies on the TLS protocol to protect the communication channel between the controller and SDN switches. Several approaches focus on a secure southbound API, such as [3–5, 11]. In [3], the authors study packet-in delays of SDN switches when TLS encryption is used. In [11], the authors focus on improving the security of SDN by combining Access Control Lists (ACLs) with TLS hardening. In [5], the authors propose a solution based on Host Identity Protocol (HIP) to secure the communication channel in software-defined mobile networks. In [4], the authors introduce a blockchain-based solution to authenticate SDN switches and SDN hosts. In [8], the authors suggest a combination of blockchain and post-quantum cryptography for securing cross-domain SDN environments. Adding blockchain results in additional complexity and is considered more suitable solution for cross-domain SDNs [4, 8]. In [2], the authors propose a solution that integrates Quantum Key Distribution (QKD) and post-quantum cryptography (PQC) in SDN integration. Our work provides a more practical solution than [2] since it does not relay on QKD. Furthermore, our solution is integrated directly into existing SDN components such as OVS switches.

ICFNDS ’26, Nov 04–06,2026, Izmir, Turkey

Majd Latah and Kubra Kalkan

In [6], the authors explored the integration of post-quantum algorithms for securing SDN environments. However, the paper did not provide a comprehensive and systematic comparison across legacy, hybrid, and pure PQ-TLS. Our work covers three main security levels across legacy, hybrid and pure PQ-TLS. We also evaluate other alternatives for PQ algorithms. Furthermore, the paper did not include detailed information on switch integration, which is a key focus of our work. Other works, such as [9], focus on providing PQ-TLS measurements for non-SDN environments. Our work, on the other hand, focuses on SDN environments with emphasis on the southbound API.

3

Southbound API with PQ-TLS

To achieve PQ-resiliency for the southbound API, SDN controllers and SDN switches need to provide support for PQ-TLS. Therefore, both SDN components need to use PQ-TLS to communicate with each other (see Fig. 2). In this paper, we consider the following modes: • Pure PQ-TLS mode: uses only post-quantum cryptographic algorithms. This mode uses ML-DSA for digital signatures and ML-KEM for key establishment. Both ML-DSA and MLKEM are module-lattice-based algorithms standardized by NIST. • Hybrid PQ-TLS mode: uses a combination of classical and post-quantum algorithms. This mode combines ECDSA with ML-DSA for digital signatures and ECDH with ML-KEM for key establishment.

SDN Controller with PQ-TLS support Southbound API with PQ-TLS SDN Switch (OVS) with PQ-TLS support

3.2

SDN controller with PQ-TLS support

The SDN controller uses PQ-TLS to create a secure channel to communicate with the data plane. For this part, we integrate PQTLS into an existing SDN controller (Ryu). We choose Ryu due to its simplicity, which allows rapid testing of new functionalities in the SDN environment. Both pure and hybrid modes are also supported at the controller side through OpenSSL, liboqs and oqs-provider. The controller also uses a Python C extension module to call the PQ-enabled OpenSSL. In addition, the controller runs a L2 learning switch application.

4

Experimental Work

The experimental work is conducted on a bare-metal machine with the Ubuntu 25.04 operating system. The machine has an AMD Ryzen 7 (7840HS) CPU and 16 GB of RAM. Our testbed is shown in Fig. 3. The details of our experimental setup are shown in Table 1. During our AI-assisted analysis using Claude Code, we noticed that the TLS socket is not monitored by the switch event loop, causing additional latency during the handshake process. This issue is fixed by registering the SSL socket in the corresponding event loop. Table 1: Experimental setup Setting Operating system SDN controller OpenSSL Liboqs SDN switch Containerization Network isolation Number of switches Switch arrival rates

Description Ubuntu 25.04 Ryu 4.0.0-dev 0.15.0 PQ Open vSwitch (OVS) 3.6.90 One container per switch Dedicated L2 network per switch 𝑁 = 60 𝑅 ∈ {10, 20, 30} switches per second

In our setup, each switch starts an independent TLS 1.3 session with the controller. Therefore, each OVS switch runs in a separate Docker container and has its own certificate and cryptographic keys. Each container is associated with a dedicated Docker bridge, which provides connectivity to the SDN controller.

Figure 2: SDN’s southbound API protected using PQ-TLS

Bare Metal Ubuntu 25.04 Host

3.1

SDN switches with PQ-TLS support

The SDN data plane, which consists mainly of OVS switches1 , relies on PQ-TLS to communicate with the SDN controller. To achieve PQ-TLS support for the pure PQ-TLS mode, the switch uses the new OpenSSL library with PQ-TLS support. In addition, to achieve PQ-TLS support for hybrid PQ-TLS mode, we use a combination of OpenSSL 2 and liboqs 3 from the Open Quantum Safe (OQS) project. Note that oqs-provider 4 is used to enable liboqs in OpenSSL. The source code of the switch is compiled with the new OpenSSL library with PQ-TLS support.

PQ-OVS Switch 1

Docker Bridge 1

. . .

. . .

PQ-OVS Switch N (N=60)

Docker Bridge N

Ryu

1 OVS, https://github.com/openvswitch/ovs 2 OpenSSL, https://github.com/openssl/openssl 3 Liboqs, https://github.com/open-quantum-safe/liboqs 4 Oqs-provider, https://github.com/open-quantum-safe/oqs-provider

PQ-SDN Controller

Figure 3: Our testbed

OVS Meets PQ-TLS: Exploring Post-Quantum TLS for SDN’s Southbound API

ICFNDS ’26, Nov 04–06,2026, Izmir, Turkey

The network consists of 𝑁 = 60 switches. The switch arrival rate (𝑅) is varied over three values: 10, 20, and 30 switches per second. The SDN controller runs directly on the host machine. We use CPU affinity to bind the controller to a single CPU core. We consider both pure and hybrid PQ-TLS modes. The parameters for TLS configuration are shown below in Table 2. We consider three NIST security levels: L1, L3, and L5 (128, 192, and 256 bit).

The symmetric cipher suite is TLS_AES_256_GCM_SHA384. It is worth noting that each experiment is repeated 10 times.

Table 2: Parameters used for TLS configuration

The handshake latency is reported in Fig. 4. The results show that using a higher security level results in higher latency. For L1, legacy TLS shows the least latency. However, for L3 and L5, pure PQ-TLS demonstrates the lowest latency. The results confirm that classical algorithms constrain the performance of hybrid algorithms at higher security levels, which is consistent with [9]. The hybrid PQTLS mode shows the highest latency across different security levels, which is expected since it combines both classical and quantumresistant algorithms. We also measure CPU utilization for both legacy TLS and PQ-TLS at the controller side. The results for CPU utilization are shown in Fig. 5. We observe that CPU utilization increases linearly with switch arrival rate (𝑅). For L1, legacy TLS shows the least CPU utilization, whereas for high security levels (L3 and L5) pure PQ-TLS shows the lowest utilization.

L1∗

L3

L5

TLS Mode Legacy Pure PQ Hybrid PQ Legacy Pure PQ Hybrid PQ Legacy Pure PQ Hybrid PQ

Digital Sig p256 MLDSA44 p256_mldsa44 p384 MLDSA65 p384_mldsa65 p521 MLDSA87 p521_mldsa87

Key Establishment secp256r1 MLKEM512 p256_mlkem512 secp384r1 MLKEM768 p384_mlkem768 secp521r1 MLKEM1024 p521_mlkem1024

∗ For digital signature, since no NIST Level 1 variant for ML-DSA, we choose the

lowest variant MLDSA44, which is NIST Level 2.

35 30

40

Legacy TLS Pure PQ-TLS Hybrid PQ-TLS

25 20 15 10 5 0

1.72 2.63

10

13.14

12.27

12.07

1.74 2.62

1.73 2.75

20

30

R (Switches per Second)

Average Handshake Latency (ms)

Average Handshake Latency (ms)

40

Comparing handshake latency and CPU utilization for legacy TLS and PQ-TLS:

40

Pure PQ-TLS Legacy TLS Hybrid PQ-TLS

35 30 25 20

17.76

18.45

17.75

15 10 5

3.39

3.33

0

10

7.28

7.07

7.05

3.39

20

R (Switches per Second)

(a) L1

Average Handshake Latency (ms)

Level

4.1

30

Pure PQ-TLS Legacy TLS Hybrid PQ-TLS

35 30

24.98

25

25.50

24.63

20 15

15.31

14.73

14.71

10 5

4.06

0

4.03

3.84

10

20

30

R (Switches per Second)

(b) L3

(c) L5

Figure 4: Handshake latency for legacy TLS and PQ-TLS in the data plane across different security levels

20 15 11.23

10 5 0

8.59 5.70 2.02 2.11

10

2.69 3.34

20

2.93

R (Switches per Second) (a) L1

4.14

30

30

Pure PQ-TLS Legacy TLS Hybrid PQ-TLS

25 20

15.87

15

12.67

10 5 0

8.43 2.78

4.16

10

6.18 4.08

20

7.76 4.72

R (Switches per Second) (b) L3

30

Average CPU Utilization (%)

25

30

Legacy TLS Pure PQ-TLS Hybrid PQ-TLS

Average CPU Utilization (%)

Average CPU Utilization (%)

30

Pure PQ-TLS Legacy TLS Hybrid PQ-TLS

25

21.70

20

17.68

15 11.82

10 5 0

13.66 10.91

7.23

5.47

4.27

3.09

10

20

R (Switches per Second) (c) L5

Figure 5: CPU utilization for legacy TLS and PQ-TLS in the control plane across different security levels

30

ICFNDS ’26, Nov 04–06,2026, Izmir, Turkey

4.2

Majd Latah and Kubra Kalkan

Comparing with other PQ digital signatures and key establishment schemes:

For digital signatures, we consider both SPHINCS+ and Falcon. SPHINCS+ is a hash-based post-quantum digital signature scheme, which is also standardized by NIST as SLH-DSA. Falcon is a latticebased post-quantum signature scheme, which is also standardized by NIST as FN-DSA. For key establishment, we consider BIKE, FrodoKEM and HQC. Note that Falcon has only two security levels (L1 and L5). We use the fast variants of SPHINCS+. We fix the switch arrival rate at 𝑅 = 10. We compare the performance of MLDSA with SPHINCS+ and Falcon across different security levels and different key establishment schemes. Case 1 - ML-KEM As shown in Fig. 6, ML-DSA and Falcon outperform SPHINCS+ in terms of latency and CPU utilization. In addition, Falcon-1024 shows the lower latency compared to MLDSA-87. In addition, using ML-KEM for key establishment results

SPHINCS+-SHA2-256f SPHINCS+-SHA2-192f SPHINCS+-SHA2-128f

44.25 21.99 16.03

Falcon-1024 Falcon-512

3.85 3.79

ML-DSA-87 ML-DSA-65 ML-DSA-44

4.06 3.33 2.63

0

10

20

30

40

Level 1 Level 3 Level 5 50 60

Average Handshake Latency (ms)

(a) Handshake latency in data plane

in higher latency and CPU utilization compared to BIKE, FrodoKEM and HQC (See Fig. 7, 8, and 9). Case 2 - BIKE As shown in Fig. 7, using BIKE for key establishment results in higher latency and CPU utilization compared to ML-KEM. However it has slightly better results compared to FrodoKEM ( Fig. 7) and HQC (Fig. 9). Case 3 - FrodoKEM: As shown in Fig. 8, using FrodoKEM for key establishment results in higher latency and CPU utilization compared to ML-KEM and BIKE. However, it achieves better results in terms of latency and CPU utilization compared to HQC (Fig. 9). Case 4 - HQC As shown in Fig. 9, the worst results are achieved using HQC in terms of latency and CPU utilization. Overall, the results show that the choice of digital signature and key establishment methods affects the performance. For L1 and L3, the best results are achieved by combining ML-DSA and ML-KEM. For L5, Falcon achieves slightly better results compared to ML-DSA. The worst results are achieved with SPHINCS+.

SPHINCS+-SHA2-256f SPHINCS+-SHA2-192f SPHINCS+-SHA2-128f

17.09 9.92 7.25

Falcon-1024 Falcon-512

2.94 2.82

ML-DSA-87 ML-DSA-65 ML-DSA-44 0

3.09 2.78 2.11

5

10

15

20

Level 1 Level 3 Level 5 25 30

Average CPU Utilization (%)

(b) CPU utilization in control plane

Figure 6: Comparing ML-DSA with SPHINCS+ and Falcon (ML-KEM is used for key establishment)

SPHINCS+-SHA2-256f SPHINCS+-SHA2-192f SPHINCS+-SHA2-128f

45.06 22.32 16.86

Falcon-1024 Falcon-512

8.68 4.44

ML-DSA-87 ML-DSA-65 ML-DSA-44

9.14 5.78 4.13

0

10

20

30

40

Level 1 Level 3 Level 5 50 60

Average Handshake Latency (ms)

(a) Handshake latency in data plane

SPHINCS+-SHA2-256f SPHINCS+-SHA2-192f SPHINCS+-SHA2-128f

17.54 9.98 7.60

Falcon-1024 Falcon-512

3.78 3.04

ML-DSA-87 ML-DSA-65 ML-DSA-44 0

3.90 3.02 2.88

5

10

15

20

Level 1 Level 3 Level 5 25 30

Average CPU Utilization (%)

(b) CPU utilization in control plane

Figure 7: Comparing ML-DSA with SPHINCS+ and Falcon (BIKE is used for key establishment)

OVS Meets PQ-TLS: Exploring Post-Quantum TLS for SDN’s Southbound API

SPHINCS+-SHA2-256f SPHINCS+-SHA2-192f SPHINCS+-SHA2-128f

45.91 24.29 17.52

Falcon-1024 Falcon-512

6.96 4.45

ML-DSA-87 ML-DSA-65 ML-DSA-44

7.10 5.24 3.97

0

10

20

30

40

Level 1 Level 3 Level 5 50 60

Average Handshake Latency (ms)

(a) Handshake latency in data plane

ICFNDS ’26, Nov 04–06,2026, Izmir, Turkey

SPHINCS+-SHA2-256f SPHINCS+-SHA2-192f SPHINCS+-SHA2-128f

18.05 11.20 8.00

Falcon-1024 Falcon-512

4.34 3.26

ML-DSA-87 ML-DSA-65 ML-DSA-44 0

4.43 3.65 3.15

5

10

15

20

Level 1 Level 3 Level 5 25 30

Average CPU Utilization (%)

(b) CPU utilization in control plane

Figure 8: Comparing ML-DSA with SPHINCS+ and Falcon across (FrodoKEM is used for key establishment)

SPHINCS+-SHA2-256f SPHINCS+-SHA2-192f SPHINCS+-SHA2-128f Falcon-1024 Falcon-512 ML-DSA-87 ML-DSA-65 ML-DSA-44

0

206.74 88.92 36.05

Falcon-1024 Falcon-512

144.34 29.57 145.45 79.63 28.45

50

100

150

SPHINCS+-SHA2-256f SPHINCS+-SHA2-192f SPHINCS+-SHA2-128f

Level 1 Level 3 Level 5 200 250

Average Handshake Latency (ms)

(a) Handshake latency in data plane

ML-DSA-87 ML-DSA-65 ML-DSA-44 0

50.19 30.64 14.72 38.13 10.46 38.00 24.77 10.10

10

20

30

40

Level 1 Level 3 Level 5 50 60 70

Average CPU Utilization (%)

(b) CPU utilization in control plane

Figure 9: Comparing ML-DSA with SPHINCS+ and Falcon (HQC is used for key establishment)

5

Conclusion

In this work, we provide a proof-of-concept for a southbound API with PQ-TLS for secure SDN. Overall, the results show that for high security levels pure PQ-TLS, based on ML-DSA and ML-KEM, has better results in terms of latency and CPU utilization compared to legacy TLS and hybrid PQ-TLS. We compare the performance of MLDSA with SPHINCS+ and Falcon. We also measure the performance with different key establishment schemes. For L1 and L3, the best results are achieved when ML-DSA and ML-KEM are used. For L5, the selection of Falcon and ML-KEM results in slightly better results compared to the selection of ML-DSA and ML-KEM.

References [1] Fetia Bannour, Sami Souihi, and Abdelhamid Mellouk. 2017. Distributed SDN control: Survey, taxonomy, and challenges. IEEE Communications Surveys & Tutorials 20, 1 (2017), 333–354. [2] Jaime S Buruaga, Ruben B Méndez, Juan P Brito, and Vicente Martin. 2025. Hybrid Quantum-Safe integration of TLS in SDN networks. Computer Networks 267 (2025), 111355. [3] Raphael Durner and Wolfgang Kellerer. 2015. The cost of security in the SDN control plane. In ACM CoNEXT 2015-student workshop. [4] Majd Latah and Kübra Kalkan. 2020. DPSec: A blockchain-based data plane authentication protocol for SDNs. In 2020 Second International Conference on

Blockchain Computing and Applications (BCCA). IEEE, 22–29. [5] Madhusanka Liyanage, Mika Ylianttila, and Andrei Gurtov. 2014. Securing the control channel of software-defined mobile networks. In Proceeding of IEEE International Symposium on a World of Wireless, Mobile and Multimedia Networks 2014. IEEE, 1–6. [6] Kumar Mrinal and S Veena. 2025. Performance Analysis of Post-Quantum Cryptographic Algorithms in Software-Defined Networks. In 2025 9th International Conference on Computing, Communication, Control and Automation (ICCCBEA). IEEE, 1–6. [7] NIST Security Levels. 2026. https://csrc.nist.gov/projects/post-quantumcryptography/post-quantum-cryptography-standardization/evaluationcriteria/security-(evaluation-criteria) Accessed: 2026-01-07. [8] Javier José Díaz Rivera, Ricard Vilalta, Raul Muñoz, Pol Alemany, and Lluis Gifre Renom. 2025. Leveraging PQC and Blockchain for Secure and Verifiable SDN Controller Communication. In 2025 IEEE 11th International Conference on Network Softwarization (NetSoft). IEEE, 567–572. [9] Markus Sosnowski, Florian Wiedner, Eric Hauser, Lion Steger, Dimitrios Schoinianakis, Sebastian Gallenmüller, and Georg Carle. 2023. The performance of post-quantum tls 1.3. In Companion of the 19th international conference on emerging networking experiments and technologies. 19–27. [10] Wenfeng Xia, Yonggang Wen, Chuan Heng Foh, Dusit Niyato, and Haiyong Xie. 2014. A survey on software-defined networking. IEEE Communications Surveys & Tutorials 17, 1 (2014), 27–51. [11] Beytullah Yigit, Gurkan Gur, Bernhard Tellenbach, and Fatih Alagoz. 2019. Secured communication channels in software-defined networks. IEEE Communications Magazine 57, 10 (2019), 63–69.

Related documents

• OVS Meets PQ-TLS: Exploring Post-Quantum TLS for SDN's Southbound API#625160
• OVS Meets PQ-TLS: Exploring Post-Quantum TLS for SDN's Southbound API#622887
• Exterior Gateway Protocol implementation schedule#231837
• A dynamic policy-aware conditional proxy re-encryption system for fine-grained access control in IoT pub/sub systems.#221089
• On the Security Implications of PQC in TLS: Handshake Exhaustion and IDS Degradation#366202