SDN-Enabled Digital Twin Networks Architecture for Proactive Detection and Mitigation of Malicious Encrypted Traffic

Hesselbach, Xavier; Claro, Juan Parada

doi:10.3390/fi18080415

Abstract

Classification algorithms for encrypted traffic are an effective means of improving the security of private networks. However, they operate a posteriori because they require collecting flow level features (packet length, inter-arrival time, and flow identifiers), which can only be extracted after observing multiple packets before reaching a classification decision. Furthermore, to achieve accurate classification, the analyzed flows must be processed by the target server or by a server that faithfully replicates its behavior. This paper proposes a Digital Twin Network (DTN) architecture to prevent unknown traffic from being initially processed by the Original Network, thereby reducing the risk of attacks that cannot be immediately detected by encrypted traffic classification. The architecture integrates SDN and P4 to implement the monitoring and traffic redirection required by the DTN, and a proof-of-concept prototype is presented to validate its functionality. This work identifies a trade-off regarding access to previously unknown external services due to redirection via the DTN until classification is complete, which can introduce significant delays.

Keywords:

DTN; SDN; P4; classification algorithms for encrypted traffic; network security

1. Introduction

Encrypted traffic classification algorithms typically require observing an undetermined number of packets before they can accurately classify a flow. During this process, the corresponding services must continue to be provided; otherwise, the traffic characteristics required for reliable classification cannot be observed. Consequently, malicious flows may reach the production network before a classification decision is available. Furthermore, if the requested services do not behave as expected, an attacker may detect the anomaly and interrupt or modify the attack.

To address this issue, the proposed architecture isolates unknown traffic from the Original Network (ON) while it is analyzed and served. Unknown flows are redirected to an external entity, where they are processed until the classification algorithm determines whether they are benign or malicious. This approach prevents potentially harmful traffic from directly reaching the ON while preserving realistic service behavior for accurate classification.

Although honeypots and sandboxes can provide similar isolation, they may be identifiable by sophisticated attackers. A Digital Twin Network (DTN) overcomes this limitation by replicating the relevant characteristics of the ON, enabling realistic service responses while maintaining isolation from the production environment.

DTN allows for the mirroring of a network in an efficient way, giving the same service perception of the ON if the virtualized part is good enough [1,2]. Other technologies used for this purpose, such as simulators or analytical models, are heavier and are not valid for big networks.

Then, while the classification algorithm decides if a flow is malicious or not, those flow packets could be served by the DTN to achieve two benefits: not loading the ON with flows that could be threats and, of course, protecting the ON from receiving possible malicious packets because this virtual network is isolated from the original one. The usage of this solution instead of a classic Intrusion Detection System (IDS) is due to the power of classification algorithms to better differentiate encrypted malicious traffic [3,4]. The other reason is that IDSs work better with known attacks, and classification algorithms have greater chances of discovering new attacks.

If the DTN is well modeled, the attacker has little chance of noticing that he is not receiving services at the ON, meaning that the information received in the classification algorithm is not manipulated on purpose by the attacker.

For example, honeypots only decoy the final system, and maybe not completely if it is a low-level one. If the attacker is smart enough, he could detect it [5]. But, if DTN is used, it is mirroring latencies, link bandwidth, paths followed by packets, and, of course, the final system in a high level of complexity, leaving fewer variables to monitor for attackers.

SDN is able to separate the control plane from the data plane [6]. Giving to the controller (agent that receives the responsibilities of managing the control part of the network) programmability to aid the system to:

1.: Interpret the logs of the classification algorithm and apply policies based on it.
2.: Leverage some actions that are needed in the DTN context to distribute some of the responsibilities of DTN actors (Original Network Manager (ONM) and Digital Twin Network Manager (DTNM)) through the network devices (in this case P4 switches).
3.: Implement redirection at the switch in a transparent, automatic, easier, and faster way than using a proxy server.
4.: Deploy control actions of DTN thought the control channel of SDN leaving the data plane only for data, enhancing its performance.
5.: Easier management of the needed DTN data due to the centralization of it.
6.: If some functionality does not require the expected computational needs, it can be moved to the controller eliminating another middle-box (for example, the classification algorithm).

These functionalities are centralized in the SDN controller, eliminating the need for multiple dedicated middleboxes.

For encrypted traffic classification, P4 switches extract the flow-level features required by the classification algorithm, avoiding the need to forward complete packets to external monitoring devices and moving part of the feature extraction process into the data plane.

P4 switches also monitor the state of the Original Network (ON) and report relevant changes to the controller through the control channel, such as configuration updates or changes in the services provided by servers.

Based on the controller’s decisions, the switches redirect selected flows either to the ON or the DTN and enforce filtering policies by dropping malicious traffic when required.

The combination of SDN and P4 distributes monitoring, traffic steering, and feature extraction across the control and data planes, allowing the ON monitoring (ONM) functionality to be implemented as an SDN application rather than as a dedicated middlebox.

This paper provides the following contributions:

1.: Proposal for using DTN for security, not just in terms of testing configurations about security at the network but rather including the real time usage (sending real packets to the mirror) to improve security.
2.: Design for embedding DTN within an SDN network, including the tasks related to ONM in the network controller (pick up ON information to maintain the updated DTN), giving the possibility of not placing this needed middle-box in another server, avoiding its costs.
3.: Idea of monitoring the ON state with the aid of P4 switches, moving this load needed at DTN to the network. Monitoring is not just in case for the state of network elements like switches/routers, but also for noticing about of the load state of the emulated hosts.
4.: Development of a prototype of the whole system, joining various systems in one design (classification algorithm for encrypted traffic, data model for DTN, monitoring generated in P4 switches, network control applications on a Python-based controller). Remark that DTN implementations are a lack in state of the art because the majority of articles stop at the architecture level. This prototype is at a really early stage and is not considered for getting empirical conclusions in this work.

The state of the art related with “DTN to improve security” is in its infancy, because the concept of DTN is also really new, born approximately in 2019–2020 [7].

2. State of Art

This section provides the background necessary to understand the proposed architecture. It reviews the main technologies employed in this work, namely Software-Defined Networking (SDN), Digital Twin Networks (DTNs), Protocol-Independent Packet Processors (P4), Graph Neural Networks (GNNs) for network modeling, and encrypted traffic classification. Where appropriate, comparisons with alternative approaches and the relevant concepts are presented to facilitate understanding of the proposed design.

2.1. SDN

The fundamental concept of Software-Defined Networking (SDN) is the separation of the control plane from the data plane. The control plane, implemented by the SDN controller, is responsible for computing forwarding policies and populating the forwarding tables of the network switches. The data plane consists of switches that execute these forwarding rules, processing and forwarding packets according to the policies installed by the controller [6].

The tasks of control are centered on an entity called controller. Normally, this entity is a unique device, but in some scenarios the tasks could be divided between different controllers [6,8].

The controller functionality is implemented through applications running on top of the SDN controller. These applications support services such as security, traffic engineering, quality of service (QoS), and network management. They interact with the controller through the Northbound API, which provides abstractions that simplify network programming. Communication between the controller and the data plane is performed through the Southbound API, whose implementation depends on the forwarding technology used by the switches. The most widely adopted Southbound protocol, and the one that popularized the SDN paradigm, is OpenFlow [6].

Deploying an SDN infrastructure may require additional investment in controller platforms and programmable forwarding devices, depending on the target environment. Another limitation of SDN is that the controller may become a single point of failure if no redundancy mechanisms are implemented. Therefore, high-availability controller deployments are typically required in production networks [6,8].

2.1.1. OpenFlow

OpenFlow is one of the most popular (in terms of usage) and the first Southbound API for SDN standardized. It is based on tables formed by rules or entries at each switch. Normally, the entries are matched depending on the flow ID [9]. Flows are identified by source IP, destination IP, transport protocol, source port, and destination port [10].

Each OpenFlow switch has a pipeline where all packets pass through. It is divided into two parts, the ingress and the egress processing (not mandatory). Both parts are composed with tables, each one formed with their respective flow entries. Each packet can be redirected to a table or not depending on the action executed. Each table adds an action in a set to be executed with the global actions (affect every packet) at the end of each processing [11].

Each entry is assigned an action to perform. If a packet does not have a match and there is not a miss flow entry (default entry), the packet is dropped [11].

OpenFlow uses TCP as its transport protocol, with optional TLS support to secure communications between the SDN controller and the switches [11].

2.1.2. P4

P4 (Programming Protocol-independent Packet Processors) is the most widely used paradigm for programming the data plane [12]. As its name indicates, P4 is a programming language dedicated to set up switches that support it. P4 is protocol unlimited thanks to include a personalized packet parser, making them completely configurable in terms of the protocols able to handle [13].

P4 extends programmability to the data plane, allowing packet processing behavior to be defined through P4 programs and dynamically updated under the control of the control plane [13].

A P4 goal is also the independence of the P4 program with the target switch under it [13]. Different brands implementing P4 provides several options in terms of extra functionalities [12]. The goal is maintained in the basic programming workflow of the language.

P4 brings some advantages over OpenFlow switches:

The ability to parse any protocol. OpenFlow switches are limited in the header fields that can parse [13].
Programmability in the data plane or the packet plane. OpenFlow allows programmability at the control level [12]. The programming in both planes is open since P4 exits.

Every P4 switch implements a parser to extract the different header fields needed. At least one match-action pipeline is required with various match-action tables, which have entries related with a key and associated with an action (function for selecting the output, modify packets, send packets to control, etc.). Actions can have associated parameters needed in their processing as an output port or a MAC destination. Finally, the deparser appears to select the expelled headers [12,14].

There are different P4 architectures for P4 switches. These architectures differ between them in the way of processing the packets, because they are composed of different blocks. The next are the most used [12]:

V1 Model: inherit from P4₁₄ with a programmable general parser, with separate egress and ingress tables, and with a programmable deparser. Ingress and egress pipelines are only made up of match-action tables.
Portable Switch Architecture (PSA): evolution of the V1 Model with different parsers and deparsers in the ingress and egress pipeline.
Simple Sume Architecture: thought for FPGAs without differentiation of ingress and egress pipelines. Only includes parser, deparser and one match action pipeline.

P4 also has several limitations. One of the most significant is the limited availability of production-grade programmable switches. Although Intel’s Tofino family became the de facto hardware platform for P4, it has been discontinued, reducing the availability of dedicated commercial targets [15]. Also, the hardware is usually quite expensive. In addition, it is a technology that has not been actually adopted [14].

2.1.3. SDN for Security

The programmability of SDN (in both planes) and the central vision of the network given by the controller are key factors that allow this paradigm to enhance network security [16].

SDN permits substituting in the controller the typical security middle-boxes in a basic manner; for example, firewalls or IDS and to help other middle-boxes like honeypots (emulators of final systems for deceiving attackers) [16].

Park et al. [17] proposed the addition of security actions for OpenFlow switches. This goal is reached through managed SDN applications. All improves efficiency of the general security services owing to an allocation of them closer to the data plane level.

Alzahrani and Alenazi [4] showed a Machine Learning (ML) IDS to protect key SDN devices. The security system is integrated in SDN owe to make the recovery of flow information with the aid of switches statistics.

Li et al. [18] demonstrated a way to defend an SDN network from DDoS attacks. To do it, they use a separated module connected to the switch with OpenFlow to not slow the performance of the controller. This module is a detector, receives features and processes if there is attack and at the same time gives orders to the switch in terms of flow rules to drop attack packets.

Franco et al. [5] proposed a Multi-level IDS for SDN networks aided with honeypots. To achieve it, they use “Demilitarized Zone” for an SDN network formed by honeypots. The traffic recovered by them is processed at an IDS which clone it to an ML algorithm to obtain a second opinion. The flow rules derived by all this process are copied in the real network to avoid attacks.

P4 switches also allow the possibility of enhancing network security due to programmability in first term. It gives the possibility of running partially security functions with direct access to the packets [19].

With direct contact with packets, a P4 switch can drop those with suspicious header values for the network. In addition, it can help in some parts of the detection of IDS [19].

Kang et al. [20] showed how to secure Bring Your Own Device networks with the P4 aid. They created Poise, a language that generates P4 programs with context aware security policies. Poise enables role-based services and time-restricted applications by associating context-aware policies with hardware actions like drop, forward, flood, and log.

Hauser et al. [21] demonstrated the possibility of moving the creation of IPsec endpoints to P4 switches. They use the P4 pipeline for the necessary encryption and decryption present at the endpoints of IPsec tunnels while maintaining layer 3 forwarding. To achieve this purpose, they used P4 externs for ciphering.

Lewis et al. [22] proposed putting some intrusion detection at the P4 switch level. They translate some Snort IDS rules to active P4 tables at the switch to accelerate the detection of intruders in an early stage. They declare that it is not possible with every rule. It is a way of decongesting the real IDS.

Gupta et al. [23] showed Deep Packet Inspection (DPI) at the P4 level to avoid doing it in a middle-box. Every packet is recirculated several times with an extra byte of information needed in the analysis process to find specific malicious payload string in the packet. This process is performed in a state machine. Since the packet is modded in the recirculation, there is a duplication of it as well to maintain it as original.

2.2. DTN

DTN comes from the concept of Digital Twin (DT) as a digital image and accurate portrait of an original system. The concept appears in the 2020s. There is no consensus itself on the notation, IETF bets lastly to use Network Digital Twin (NDT) [24], but ITU-T published in 2022 the name DTN [25]. In a wide sense, in this work DTN is considered the technology, and NDT the instances of the technology. In the case of a network, the NDT includes a set of basic elements and devices (switches, links, firewalls, routers, proxys, etc.) to replicate a complete network [1,2,7,26,27].

There is some discussion in the way of achieving an operational DTN, some authors allow the possibility of using network emulators/simulators (like NS-3, Mininet, etc.), others appreciate the possibility of using analytical models (use of queuing theory and network formulas) and the most promising way is the use of data-driven models accelerated by some kind of ML (most Graph Neural Network (GNN) owe to the graph form of the communication networks) [7,26,27,28].

Simulators or Emulators:
–
Benefits: easy deployment and high accuracy if the network entities are present in the simulator.
–
Drawbacks: impossible for real time DTN, reduced scalability, slow execution, and hard to update ON changes automatically.
Analytical models:
–
Benefits: easy deployment, available for real time, not bad in scaling depending the number of emulated metrics, accurate for basic estimations.
–
Drawbacks: the accuracy for the vast majority of metrics is not good.
AI data-driven models:
–
Benefits: available for real time, high accuracy if the training process is good, good scalability, but when the size of the network increases the number of metrics can be reduced without many losses.
–
Drawbacks: previous training required, need knowledge of ML or Artificial Intelligence (AI).

Simulators and emulators are well suited for DTNs intended to validate network configurations, but they present the limitations discussed previously, particularly when modeling large-scale or highly dynamic networks.

Analytical models are appropriate for relatively simple network scenarios with limited complexity, whereas AI-based data-driven models can accurately represent complex networks when trained with representative data.

The application of DTNs to cybersecurity remains at an early stage of development, largely because DTN technology itself is still evolving.

Another motivation for this work is the limited research on the use of DTNs for cybersecurity. To the best of our knowledge, only two previous studies have addressed this topic, both employing the DTN as a sandbox for testing and validating security mechanisms [29,30].

Grasselli et al. [29] use DTN as a place of validation of the network security configurations of Cyber Physical Systems (CPS) avoiding the risks of these tests in real systems.

Mozo et al. [30] present a DTN for mobile 5G technologies and beyond called B5GEMINI. Presenting a use case for network security: the possibility of designing ML detectors with the aid of testing at B5GEMINI.

DTN technology is still in its early stages, and only a limited number of mature models are currently available for practical deployment. Furthermore, SDN environments require DTN models specifically designed for their architecture. Maintaining a DTN also demands considerable computational resources, increasing both deployment costs and operational complexity [1,2,25].

2.3. Network Modeling with GNN

Graph Neural Networks (GNNs) are neural networks designed to process graph-structured data. Unlike conventional neural networks, which typically operate on vectors or matrices, GNNs take as input a graph composed of vertices (nodes) connected by edges, together with their associated features [31].

GNNs are specifically designed to exploit graph topology and naturally adapt to changes in the graph structure, unlike conventional neural networks [31,32].

Ferriol-Galmés et al. [32] implement a GNN model capable of estimating delay, packet loss, and jitter using as main inputs:

1.: A graph representation of a network in Graph Modeling Language (GML), which includes the type of queues (FIFO, DRR, etc.) present in the different nodes including buffer sizes and the capacity of the links joining them.
2.: A traffic matrix representing the current traffic present in the network with different types of traffic definition (Poisson, CBR, real traces, etc.).
3.: A routing matrix representing how packets are forwarded in the actual network.

RouteNet-Fermi is a custom GNN model designed for network performance analysis. This paper integrates the existing model within the DTN framework to enable real-time network behavior prediction, with no modifications or enhancements of the model itself. RouteNet-Fermi has been selected regarding its capacity to support a wide range of configuration parameters related to routing, queue scheduling, and traffic models. Regarding this, it is expected excellent performance since RouteNet-Fermi outperforms the state-of-the-art queuing theory model, especially in scenarios with complex and realistic traffic models, as stated in Ferriol-Galmés et al. [32]. RouteNet-Fermi models the network as a graph comprising 3 interdependent entities: flows, queues and links. The model employs a 3-stage message-passing algorithm to resolve circular dependencies: flow states are updated based on traversed queues and links, queue states depend on the flows passing through them, and link states are influenced by their associated queues and scheduling policies. To achieve scalability for large topologies, it utilizes scale-independent features, using link load (aggregated traffic divided by capacity) rather than raw numerical values and estimates effective queue occupancy Ferriol-Galmés et al. [32].

Fadhil and Oliveira [33] presented a modeling of the end-to-end delay not based on GNN. They achieve good accuracy in this metric using Generalized Extreme Value (GEV) distribution. They avoid the retraining typically required by conventional neural networks when the network topology changes. One of the main features used to estimate the end-to-end delay is the packet length.

Suzuki et al. [34] presents a Convolutional GNN for communication delay prediction based on a semi-supervised learning approach, demonstrating accurate predictions with limited training data.

2.4. Classification Algorithms for Detecting Malicious Encrypted Traffic

This term includes a broad range of approaches for detecting malicious encrypted traffic beyond conventional Intrusion Detection Systems (IDSs). Traditional IDSs have limited visibility into encrypted traffic because they cannot inspect packet payloads. Consequently, encrypted traffic detection relies on alternative techniques, including fingerprinting, clustering, and machine learning (ML)-based classification algorithms [3,35,36,37].

The vast majority of them share one aspect in common. They need, as a functioning basis, to extract features (header values) from the packets that they are classifying. Those features are flow-based, and the most classic used are the following:

Flow identification: to differentiate between flows and which type of attack could be. These features are source and destination IP address, transport protocol, and source and destination port number.
Packet length and Inter-arrival time: to classify between types of traffic or types of attacks.
Other kinds of features: like specific TCP flags, bandwidth occupied by the flow, number of packets received in total, protocol over transport, etc.

In fingerprinting algorithms, the features are basic to identify if the flow corresponds to a specific fingerprint in the database.

In clustering algorithms, features are essential in the cluster process, because thresholds will be based on those features.

In ML algorithms, features act as the data input for the model itself. Without features, the ML algorithm cannot be executed.

Fu et al. [3] presented an unsupervised learning algorithm to detect in binary way, malicious or benign. It recovers flows classifying them into long or short (depending on the number of packets). Long flows are aggregated statistically and short flows by similarity. From this they create the flow interaction graph used in the detection with packet features. They use the following parameters: flow id, packet length, timestamp (to calculate Inter-Arrival Times (IAT)), and TCP flags.

Boero et al. [35] showed an IDS that first uses fingerprinting and then ML to choose the best classification decision. As fingerprinting is key, they use a greater number of features (flow id., total packets, total bytes, flow duration, avg. and Std. dev. IAT, entropy of packet length, length of first packet, max., min., avg. and std. dev. packet length). They tested several ML models. It is real time and binary.

Zhao et al. [36] demonstrated an algorithm that is only valid for DDoS attacks and is not usable in real time. It is capable of distinguishing between different DDoS attacks. It is used to translate the insights to firewall rules. First, fingerprints and then cluster. Extract features in different time windows with various durations. The parameters used are the following: flow id, TLS header features, if possible DNS and HTTP features, ICMP types, flow direction, TCP flags, flow duration, packet number, IP frag. info., max, min, avg. and std. dev. of packet length, IAT, TTL and TCP window.

Diallo and Patras [37] presented a model that uses fingerprinting first and then adaptive clustering. It could use payloads if possible. It differs between different types of attack. With payloads, the accuracy increases, but without them it is enough. The features used are the following: flow id and statistical features (packet length, IAT, ...).

Classification algorithms are not perfect, and depending on the used one, the accuracy is not a 100%. With algorithms that try to differentiate between attacks, the accuracy is lower. In addition, there is a possibility of false positives [3,35,36,37].

2.5. Threat Model

The proposed architecture is designed to protect the ON against previously unseen or suspicious incoming traffic by exploiting a DTN as an isolated analysis environment. The threat model assumes that attackers can generate arbitrary network traffic from external hosts including encrypted traffic. The attackers may attempt to perform flooding attacks, malware delivery, reconnaissance, or other malicious actions intended to compromise network services or degrade their availability.

The proposed threat model primarily targets attacks for which encrypted traffic classification is most beneficial, namely zero-day attacks, whose signatures are not yet available, and DDoS attacks that threaten the availability of the Original Network.

It is assumed the attacker to have knowledge of communication protocols and publicly available information about the target network but does not have privileged access to the ON, the SDN controller, the DTN management components, or the programmable data plane. However, physical attacks, insider threats, and compromises of trusted infrastructure components are considered outside the scope of this work.

The proposed architecture in this work assumes that the SDN controller, P4 switches, and DTN management infrastructure operate correctly and are adequately protected. Communications between these trusted components are also assumed to be secure through existing deployment mechanisms. Under these assumptions, the proposed architecture is intended to prevent unknown traffic from directly reaching the ON until its behavior has been evaluated: Traffic associated with previously unknown flows is first redirected to the DTN, where encrypted traffic classification and network performance prediction will be performed. Only traffic classified as benign is subsequently admitted to the ON, while malicious or suspicious traffic remains isolated within the DTN.

Therefore, the proposed architecture does not claim to detect every possible attack or eliminate false classifications, but rather to provide a secure architectural framework that minimizes the risks.

Regarding security guarantees, the proposed architecture does not guarantee the immediate detection of every malicious flow, but it reduces the exposure of the Original Network by isolating unknown traffic within the DTN while sufficient information is collected for classification. Although an attacker may initially exploit benign-looking traffic, continuous monitoring and dynamic evaluation of trusted flows enable security policies to be updated, significantly limiting the duration and impact of such attacks.

3. Proposal

3.1. General Description

The overall concept of the proposed architecture is illustrated in Figure 1. It includes all the subsystems required to achieve the objectives presented in Section 1.

Figure 1. Presented Architecture with example devices.

The novelty of the proposed architecture lies not in the use of DTNs alone, but in how the DTN is integrated into the security workflow.

The proposed architecture is intended for private networks that primarily receive traffic from external sources. Although internal communications also exist, they are considered outside the scope of this work, as the proposal focuses on protecting the network against threats originating from external traffic. Consequently, the proposed architecture addresses only one aspect of network security and should be regarded as a complementary protection mechanism rather than a complete security solution.

The Original Network (ON) represents a generic private network comprising multiple servers providing different services and a wireless segment that introduces dynamic hosts and links. This heterogeneous environment serves as the reference network to be replicated by the Digital Twin Network (DTN).

As stated before, in ref. [29], DTN is used simply as a sandbox to validate security configurations before deployment, not to protect the operational network in real time. In ref. [30], DTN is used as an experimental platform to develop and test ML-based security mechanisms, again not in-line with production traffic. Our proposal, however, is conceptually different because the DTN is part of the operational forwarding path: unknown traffic is redirected to the DTN while the encrypted-traffic classifier reaches a decision, preventing the original network from processing potentially malicious traffic. The SDN controller and P4 switches implement the redirection, monitoring, and feature extraction needed for this workflow.

The architecture proposed introduces the following novel aspects:

Real-time operational use of the DTN. Unknown traffic is redirected to the DTN while the encrypted traffic classification algorithm reaches a decision, preventing potentially malicious traffic from reaching the Original Network.
Tight integration with SDN. The SDN controller manages traffic redirection policies dynamically according to the classification results.
P4-assisted monitoring and feature extraction. P4 switches collect flow features required by the encrypted traffic classifier and monitor the ON state, distributing monitoring tasks within the data plane instead of relying on dedicated middleboxes.
Integrated DTN synchronization. The proposed architecture continuously updates the DTN using information gathered from the production network, allowing the DTN to provide realistic responses during the classification period.

The DTN block in Figure 1 is just a replica of the elements of ON, in terms of perceived performance and the hosts functionalities. It is in opacity format to represent that is not a physical network. It is important to note that sensitive information stored by the ON servers and hosts is not replicated in the DTN. Instead, it is replaced with carefully selected synthetic data or, where appropriate, randomly generated data. The firewall presented here enforces access control policies, ensuring that sensitive information is accessible only to authorized servers.

DTN Manager (DTNM) concept, from Calle-Heredia and Hesselbach [2], is located at the DTN entry because it is deployed on the same hardware hosting the DTN and manages all traffic redirected to it. Specifically, it forwards packets to the corresponding emulated hosts, interacts with the network delay calculator, and processes the responses generated by the emulated services. In addition, the DTNM receives updates from the Original Network Manager (ONM) and applies them to the DTN, while maintaining the DTN state in a database synchronized with the monitored state of the Original Network (ON).

The DTN, hosted within the DTNM, processes all traffic redirected to it while emulating the behavior of the Original Network (ON) to minimize the risk of detection by an attacker. To achieve this objective, it reproduces both network and host processing delays. Packets are served by virtual hosts that replicate the operating system, software versions, and services of their ON counterparts, reducing the effectiveness of fingerprinting techniques.

By closely reproducing the behavior of the ON, the DTN makes attackers believe they are interacting with the production network. Consequently, attacks can continue within the isolated DTN while the encrypted traffic classification algorithm analyzes the corresponding flows and determines the appropriate mitigation actions before malicious traffic reaches the ON.

As shown in Figure 1, the P4 switch monitor performs several functions. It executes the commands issued by the ONM, some of which require a dedicated protocol developed for this purpose. It also monitors DHCP messages to detect newly connected devices in the Original Network (ON) and performs the standard forwarding functions of an SDN switch by applying the flow rules installed by the controller.

The P4 switch Gatherer and Redirector performs three main functions: extracting the flow-level features required by the classification algorithm and forwarding them to the classifier; notifying the ONM whenever traffic from the Original Network (ON) is destined for an untrusted external service, enabling the appropriate redirection policies; and performing the standard forwarding functions of an SDN switch by applying the flow rules installed by the controller.

Figure 1 depicts two P4 switches to distinguish their different roles within the proposed architecture and to simplify its description. However, if only a single programmable switch is available, both sets of responsibilities can be combined into one device, at the cost of a higher processing load. P4 switches are adopted because they support custom packet formats and programmable packet processing, enabling network monitoring, the implementation of dedicated control protocols, and the extraction of the flow-level features required by the classification algorithm.

The classification algorithm server performs two main functions: classifying the flows received from the Gatherer and Redirector P4 switch and reporting the classification results to the SDN controller. The Gatherer and Redirector prepares the flow-level features required by the classifier, reducing the processing burden on the classification server. The classifier is implemented as a separate entity to avoid overloading the SDN controller, thereby preserving the responsiveness of latency-sensitive controller applications.

The SDN application responsible for flow rules and security policies generates forwarding rules for unknown flows, receives the classification results, and updates the forwarding policies accordingly by installing either redirection or drop rules.

The SDN application implementing the Original Network Manager (ONM) is responsible for monitoring the ON. It periodically collects information about the status of hosts, switches, and services, processes notifications from the P4 switches (e.g., DHCP events from the Monitor switch and requests to access unknown external services from the Gatherer and Redirector), and issues monitoring commands to build and synchronize the DTN with the current state of the ON. Integrating the ONM into the SDN controller eliminates the need for a dedicated monitoring middlebox and shifts monitoring traffic from the data plane to the control plane, reducing network overhead.

After describing the responsibilities of the main components and their role within the architecture, the operation of the proposed design is presented. Incoming packets received by the Gatherer and Redirector P4 switch are processed according to four different scenarios. The SDN controller determines the appropriate action based on three IP address lists that it maintains:

Fully-trusted: packets from completely known stated sources (for example, other sections of the company). Redirected directly to the ON, but their features are gathered to give theoretical benign flows to feed the classification algorithm.
Algorithm-trusted: packets from stated sources defined by the algorithm. Redirected directly to the ON. Information is also collected to continue the analysis of other flows from these sources.
Non-trusted: packets coming from banned sources classified by the algorithm are directly dropped by the “Gatherer and Redirecter” switch (the controller has created an entry for them in it).
Unknown: packets from sources not yet analyzed are redirected directly to the DTN until an analysis is complete and a decision is made about them. Only for sources that are not in any of the other categories.

While packets are processed according to one of the previously described scenarios, the classification algorithm receives the flow-level features required to distinguish between benign and malicious traffic. The main features extracted for classification are the flow identifier (source IP address, destination IP address, source port, destination port, and transport-layer protocol), packet length, and packet timestamp, from which the Inter-Arrival Time (IAT) is computed [3,35,36,37].

Additional features may also be extracted, depending on the selected classification algorithm, although the features described above are commonly used by most approaches. These features are extracted and formatted by the Gatherer and Redirector P4 switch, avoiding the need to forward complete packets to the classification server and thereby reducing its computational load.

Once a flow has been classified, the classification server reports the result to the SDN controller through the control channel. The controller then updates the corresponding forwarding policy by assigning the source IP address to the appropriate trust group and installing the required forwarding rule. If a malicious flow originates from a previously trusted source (either fully trusted or algorithm trusted), its IP address is immediately removed from the trusted list and blocked. Since all incoming traffic from external networks is analyzed, compromised trusted hosts can also be detected and isolated.

The monitoring is needed because the DTN must be synchronized with the ON, in terms of the network entities (forwarding devices and final systems) at least [2,7,26,27]. During the initial DTN deployment, the queue capacities and link bandwidths of the switches are configured to match those of the Original Network (ON). Subsequently, monitoring focuses on collecting flow statistics (number of packets, number of bytes, and flow duration) from the Monitor P4 switch, together with CPU and memory utilization from the ON hosts. These measurements are used to reproduce the delays experienced in the ON, enabling the DTN to emulate the perceived network performance. If an attacker observes the same performance and receives the same services as in the ON, distinguishing the DTN from the production network becomes considerably more difficult.

The Gatherer and Redirector P4 switch is also responsible for detecting attempts by ON clients to access previously unknown external services. Since these destinations are not yet trusted, the corresponding traffic is redirected to the DTN. The DTNM is then notified to establish the external connection on behalf of the ON client and replicate the requested service within the DTN.

This mechanism introduces additional latency for ON clients accessing previously unknown external services. However, such services are typically not part of the normal operation of the target environments considered in this work, such as data centers, and this trade-off is necessary to preserve the security guarantees of the proposed architecture by preventing attackers from exploiting external services. If a service is essential and trusted, the network administrator can permanently add its IP address to the controller’s whitelist, avoiding any additional delay. Otherwise, access remains redirected until the flow is classified. Once a previously unknown service is classified as benign, its destination is added to the algorithm-trusted list, and subsequent communications proceed without the additional latency introduced by the DTN. So, when the unknown non-essential external services are cataloged as benign, this delay introduced by the architecture disappears, and these destinations are registered as “Algorithm-trusted IPs”.

All the functionalities of DTN will be performed at the DTNM. Then the DTNM will save the information of the model in its database to compare the new model with the previous ones and implement an efficient generation, generate the replica of ON based on the predictions of the last model, and forward packets to the virtual network generated by it. Information about changes is sent by the ONM, but is processed at DTNM. The network is also virtualized on the same machine.

3.2. Detailed Description of the Architecture Components

This section provides a detailed explanation of each component, including its functionality and its role within the overall system.

3.2.1. P4 Switches

In general, normal forwarding refers to being processed as other packets, looking for output port and MAC destination, reducing the TTL (P4 switches considered as routers and even more because they look also at the transport header) and egressing the packet with those changes. In addition, they have to request the flow entry to the controller for unknown destinations. This process is performed by every P4 switch.

“Monitor” acts as a normal P4 switch that is flow based, but also must attend to the requests that ONM sends to it. Those are:

Request of switch information: the “Monitor” must send SNMP requests to the MIB where the layer 2 switches save their basic information (type, management IP, queue sizes and types, link bandwidth, etc.). These requests are sent in all the ports except the one connected to “Gatherer and Redirecter”. The response is sent to ONM with the port where it comes. The ONM processes this answer.
Request of final system information: the “Monitor” must send proprietary protocol message to the specific host. The response contains the number of cores, the total RAM, and the host data (operating system and services running). The response is sent to ONM with the port from which it comes.
Request of what petition did the final system: “Monitor” must send a message of the proprietary protocol to the final system to recover. The host must respond with the protocol used and the content of the request that was launching. This petition is launched by the ONM when “Gatherer and Redirecter” detects a new access from the ON to the Internet (when it detects a new TCP connection).
Request of flow statistics: as a normal P4 switch, with P4 direct counters of the different table entries. The controller must recover and send this information to the Classification algorithm server.
Request of final system status: “Monitor” must send a multicast request in the proprietary protocol in all the ports (except the “Gatherer and Redirecter” one). Each host responds in a unicast way with the CPU and RAM usage. The switch sends responses to the controller when it detects them.
Request of new files: “Monitor” must send a multicast request in the proprietary protocol in all the ports (except the “Gatherer and Redirecter” one). Each host responds if it is serving new files with respect to the last request that has arrived. The response to ONM is just the path of the file and the IP of the host, of course.
DHCP monitoring: “Monitor” also checks when DHCP ACK packets pass inside it, processing them normally but passing the new IP to ONM to save it and to order a new request of host information (if needed). This extraction requires the P4 clone of that packet.

The Algorithm 1 explains in a different manner how this P4 switch performs its extra functionalities on active monitoring.

Algorithm 1 “Monitor” active operation.

Require: Packet from control channel that is not a flow entry

1:: if Request of switch info. then
2:: for each ON port do
3:: for each oid needed do
4:: Clone request packet
5:: Transform it to correspondent SNMP GET request
6:: Send through current ON port
7:: end for
8:: end for
9:: else if Request of final sys. info. || Request of final sys. petition then
10:: Encapsulate the request in an UDP datagram
11:: Forward it normally through the correspondent port
12:: else if Request of final sys. status || Request of new files then
13:: Encapsulate the request in a multicast UDP datagram
14:: for each ON port do
15:: Clone the packet for the next port
16:: Send through current ON port
17:: end for
18:: else if Request of flow stats. then
19:: Recover direct counters of specified flow
20:: Send the response through control channel
21:: end if

The Algorithm 2 explains in a different manner how this P4 switch performs its extra functionalities on passive monitoring.

Algorithm 2 “Monitor” passive operation.

Require: Data packet from an ON port

1:: if Response to a request then
2:: Forward to the control channel to be processed at controller
3:: else
4:: if It is a DHCP ACK packet then
5:: Clone it to extract relevant info. from it
6:: Send info. to the controller
7:: else
8:: Normal flow treatment
9:: end if
10:: end if

“Gatherer and Redirecter” acts as a normal P4 switch that is flow based and just perform the following 2 extra actions:

1.: If a packet is received from the port connected to the Internet, it extracts the packet features and saves them in local metadata. This is needed because the packet must be processed normally and at the same time send its features to the classification algorithm. For achieving that, cloning is needed again. The replica of the packet is used to generate a totally different packet in a proprietary protocol that carries the features.
2.: If a TCP SYN that comes from the interior network is received from the port connected to “Monitor”, that means that a host is trying to access an external service. Then, “Gatherer and Redirecter” notices the ONM with the host IP of the trier. After this, the ONM will request to “Monitor” more information about this try to access to an external service from the ON.

In this work, the functions performed by P4 switches are divided to reach an easier explanation (they perform completely different extra roles), but these functions can be merged into just one P4 switch if it is more adequate for the real scenario in which this architecture will be used (for example, the future user can afford a unique P4 switch).

3.2.2. DTNM

The decision of making the DTNM based on VNF with OSM is due to the auto-scalability properties that it brings. Those are key for correct performance of a real time DTN that needs to estimate current delays being faster than them, if there is more stress at the DTN, more hardware resources are needed to accomplish this fact.

Another reason is that some of the research found uses it to achieve a good performing DTN, even if they do not need real time execution of the DTN [29,30]. Some research prefers to simply base the DTN in OpenStack or a similar private cloud infrastructure management tool [2].

Still another reason is the possibility of reusing diverse VNF for some of the needs that DTN has, like host applications, switching capabilities, etc.

In Figure 2, the architecture designed for the DTNM is presented, it is based on the OSM and ETSI NFV for the reasons mentioned above. The part that composes this entity are the applications that act as OSS/BSS of the respective scenario of NFV. These applications are explained in the following lines.

Figure 2. DTNM architecture based on ETSI NFV architecture.

The application for updating the topology is responsible for comparing if the data received from ONM implies any difference from the last saved in the database. This data is the last flow statistics. If data have changed, a new iteration of the network model is run.

The application responsible for updating the Key Performance Indicators (KPIs) of the end systems receives CPU and memory utilization measurements and compares them with the values stored in the database. Whenever a change is detected, the corresponding Entity Managers (EMs) responsible for processing time emulation are notified to update their models.

The application responsible for adding new end systems uses the information provided by the ONM to instantiate new hosts in the DTN. It relies on host templates, where a larger template repository enables more accurate processing time emulation. The application also updates the MANO platform by instantiating the required Virtual Network Functions (VNFs) and synchronizes the DTN database.

The packet processing application forwards each incoming packet to 3 VNFs in parallel: First, the service emulation VNF, which generates the corresponding response according to the host type; second, the network delay estimation VNF, which predicts the end-to-end network delay based on the packet path and the current network model; and third, the processing time estimation VNF associated with the destination host type. Once all three operations have completed, the response is delayed for the remaining emulated time before being returned to the requester.

On of the first proposals indicating the need for security in DTN architectures appears published in the works of Banisadr and Hesselbach Serra [1]:

1.: Take care of all the transmission of information that involves the DTNM. This can be solved using secure protocols like TLS. In the case of communication with the controller, there is the possibility of using P4 Runtime with TLS encryption active. In the case of file exchanges between actual hosts and virtual replicas, it can be managed with SFTP.
2.: Avoid that not allowed users can pick up information from the DTNM, accessing per example to the model database. This fact can be solved directly by applying some rules to requests sent to the DTNM, only allowing certain source IPs.

The application responsible for processing the information received from the ONM notifies the Entity Managers (EMs) whenever new connections must be established in the DTN. This occurs in two situations: when a new file becomes available on an ON host, requiring an SFTP transfer to synchronize the DTN; and when an ON host attempts to access a previously unknown external IP address, requiring the DTN to establish a mirrored connection to the requested service.

3.2.3. SDN Application for ONM

The ONM has three key functions to perform. The first is to listen for switch notifications, specifically the DHCP notification and the notification for connections to external networks. Both notifications generate a monitoring request: one to obtain information about the final system, and the other to retrieve data about the request made by the host, respectively.

The final system information request is intended to collect hardware information about the new host connected to the ON. This information mainly includes the number of CPU cores, the maximum available RAM, and the installed operating system. This data helps the DTN estimate the time required to process a specific type of request in the emulated host.

The request to determine which action was performed by the host is designed to identify the intentions of the ON device (destination, port used, and request information). Based on this information, the DTN generates the corresponding request on behalf of the host. In this way, the classification algorithm can verify that the response provided by the external service is not malicious before it reaches the real device.

Additionally, the ONM is responsible for sending periodic monitoring requests. These requests include flow statistics (managed directly by the “Monitor” switch through counters in table entries), new file detection (using a multicast request sent to all hosts, which only respond if new files are detected), and final system status monitoring (also using a multicast request sent to all hosts, which always generate a response). The timing of these requests depends on the traffic received by the network. For example, higher variability in traffic demands requires a shorter statistics collection interval.

The final role of the ONM is to initiate the creation of the first DTN. This process consists of requesting basic information from the switches and waiting until all responses from the switches have been received.

3.2.4. SDN Application for Generating Flow Rules

This application consists of two main roles: the generation of flow rules for both presented P4 switches and the updating of the different IP lists based on the logs generated by the Classification Algorithm.

To generate flow entries for the “Gatherer and Redirecter”, the controller maintains three previously described IP lists. If an IP address is included in the banned list, the action of the corresponding flow rule is to drop the packet. If a packet arrives from an external network and the source IP address is not included in any list, the flow rule redirects it to the DTN. If the packet matches one of the permitted lists, the flow rule redirects it to the internal network.

To generate flow entries for the “Monitor”, the controller stores information about the switch port from which each host is connected. This information is used to generate the corresponding flow rules. In this case, the IP lists are not required because, if a packet reaches the “Monitor”, it means that it has already been considered trusted by the “Gatherer and Redirecter”.

The application also listens to the logs received from the Classification Algorithm and updates the IP lists accordingly. If any change occurs, it updates the flow rules in the “Gatherer and Redirecter” based on the maliciousness classification result (benign or malicious).

3.2.5. Classification Algorithm

The classification algorithm server consists of two parts: an application responsible for collecting the packets sent by the “Gatherer and Redirecter” switch, extracting the features of each packet, and forwarding them directly to the classification algorithm; and the classification algorithm software itself, which runs in the background waiting for features to process and determining whether the flows are malicious or benign.

The results generated by the classification algorithm are reported to the controller, which updates its IP lists accordingly.

3.3. Proprietary Protocols and Messages

In order to send the features to the classification algorithm, the “Gatherer and Redirecter” switch needs to generate packets containing this information. Since these packets are generated directly by the switch, UDP is the most suitable option due to its connectionless nature. The UDP payload of each packet contains the different features required by the classification algorithm. This defines the communication protocol between the “Gatherer and Redirecter” and the classification algorithm.

For the monitoring component, multicast messages are generated by the “Monitor” switch. Therefore, UDP is also the most appropriate option due to its connectionless nature and common use for multicast communication. In this case, the payload depends on the type of request. The request type is a mandatory field, while the message length is represented using a single byte. The proposed unicast requests follow the same format, defining the monitoring communication protocol.

4. Analysis and Results

4.1. Prototype Description

In order to validate the presented design, a prototype has been developed with the aid of Containernet [38] (a Mininet [39] modification to include Docker container hosts). This prototype uses BMv2 P4 switches with code in version 1.6 [40]. For the Classification Algorithm, it uses an adaptation of Fu et al. [3] the implementation also known as HyperVision. For the DTN data model, RouteNet-Fermi (Ferriol-Galmés et al. [32]) is used. The controller is based on Python using a modified P4 Runtime shell library [41] to easily control the switches. The hardware used is the following: Intel i7 4770 (2013, 4 cores and 8 threads), 12 GB of RAM and an nVidia GTX 1070 (8 GB VRAM) with enough disk space.

The objective of the current prototype is to validate the feasibility of the proposed architecture. A comprehensive quantitative evaluation using production-grade programmable switches and a complete implementation of all DTN modules is left for future work, as the present prototype is intentionally limited to demonstrating architectural integration rather than optimized performance. Once this work demonstrates the feasibility of the proposal, a complete implementation must be analyzed using production-grade P4 targets to quantify the performance of the architecture, scalability, and resilience against different types of cyberattacks.

The developed prototype aims to verify that the proposed architecture can be implemented and to provide insights into how the design can be improved in the future. It is functional, but it does not fully represent the complete proposed architecture. The following simplifications have been introduced to create a lighter prototype, due to hardware limitations and because some of the tools used imposed certain requirements:

1.: There is no presence of a DHCP server located at the ON, then this monitoring part is not implemented.
2.: There is no dynamism in the hosts (it cannot be new ones), then the monitoring of this part is not present.
3.: The network is not connected to the Internet, then there is a need to generate traffic to properly test the prototype.
4.: BMv2 used in the implementation of P4 switches does not support SNMP, so the basic information of the switches to replicate them in the DTN will be static and predefined [40].
5.: The emulation of processing time of hosts is not implemented, since the applications hosting on them are light (HTTP server with only one kind of response and SSH server). Also, because this emulation of time is not itself the goal of the document.
6.: The unique processing performed at DTNM is to call the data model when it is needed. Some other monitoring stuff is implemented in the switches, but it is not used at DTNM because there is no dynamic host and emulation of processing time.
7.: In Figure 1 of the architecture, the switch that connects the hosts to the ”Monitor” switch (“Connector” in Figure 3) is not defined in type (P4, OpenFlow, regular, etc.); here is a P4 switch for simplicity of running it on Mininet.

Figure 3. Prototype Containernet scenario.

This prototype is summarized in Figure 3 and can be found in the next GitHub repository: https://github.com/JohnStopped/DTN-TFM/tree/main2 (accessed on 29 July 2026).

4.2. Design Results

After presenting the prototype implementation, this section discusses the potential limitations and challenges of the proposed design, as well as possible solutions to overcome them.

If the protected network usually has users who need (or are required by their work) to access external services, implementing the complete proposed design may introduce significant delays in those accesses. This is because the fundamental principle of the architecture is not to trust most external IP addresses (except those included in the fully trusted set). The design assumes that these accesses are redirected to the DTN, where the necessary information about the request is collected through monitoring from inside the network and then replicated by the DTN. Therefore, the proposed design is more suitable for networks that primarily receive incoming traffic, such as server farms or data centers.

Implementing the architecture in a real network can be costly, both in terms of hardware requirements and human resources. However, costs are always relative; if the implementation can prevent attacks against real hosts and reduce the impact of security incidents, the investment may be justified. If the protected network is a data center, some of the available hardware resources could potentially be allocated to implement the architecture. Nevertheless, this also represents a cost, as those computational resources would no longer be available for other purposes, such as providing services.

It is also possible that storing only IP addresses in the trusted list is not the most secure approach. The main concern is that, if an attacker identifies that the target network uses this system, they could first send a benign request that is classified as trustworthy and then launch an actual attack from the same IP address. In this case, the attack would only be detected after the inherent delay of classification algorithms for encrypted traffic. One possible improvement would be to associate trusted IP addresses with a list of destination transport ports that have been classified as benign. If an attacker launches an attack using a different destination port, the traffic would be redirected to the DTN for further analysis.

Sensitive host information must be carefully considered during the duplication process, avoiding the replication of data that may contain passwords, critical company information, or other confidential content. Such information should not be duplicated; instead, it should be excluded from servers accessible from external networks, as attackers should not expect to find this type of information there. Additionally, this information could be randomized so that an attacker cannot distinguish it from potentially real data.

A migration module could also be considered for moving benign users directly to the ON once they have been identified as trustworthy. In the current design, this scenario is addressed by completing the communication through the DTN and only redirecting subsequent communications to the ON. If a migration module is implemented, the best approach would be to integrate it with the controller. The controller could recover the connectivity information from the P4 switches and use it when migration is required after the classification algorithm has made a decision about the flow.

The inclusion of NFV in the DTNM is certainly a point that can be discussed. In this design, it is included for two main reasons: the possibility of reusing existing VNFs and the fact that the two references found regarding DTN implementation also use this approach [29,30]. In addition, the automatic scalability that it provides is a second reason, but this feature is in other cloud infrastructure tools such as OpenStack [2].

P4 enables the generation of monitoring packets directly from the switches instead of requiring them to be generated by the ONM, by using the packet cloning features provided by P4. This reduces the processing load on the ONM by transferring part of the workload to the network devices.

SDN is essential for ensuring fast packet redirection. Instead of forwarding packets directly to the ON, they can be redirected to the DTN when required. This technology is also useful for collecting the flow statistics needed for the prediction models used by the DTN.

4.3. Prototype Results

The prototype has undergone different types of tests, most of which were functional tests aimed at verifying whether the proposed design could be fully implemented (although the complete design is not implemented, some components of each module are). Other tests focused more on performance evaluation, such as the response time of the HTTP servers deployed in the ON and DTN, as well as UDP flooding tests.

During the response time tests, a problem was identified with the BMv2 switches: the delay introduced during flow entry generation is approximately 0.9 s. This delay is extremely high compared with the delay introduced by the model itself, which is normally around 0.00005 s. To partially mitigate this issue, the approximate delay introduced by the switch was considered when scheduling the generation of flow entries sent from and to the DTN at the controller. After applying this correction, the average response time measured for HTTP requests in the ON was 5.2 s, while the corresponding result for the DTN was 3.2 s.

This represents the main limitation of the presented prototype. Due to this issue, the current implementation cannot yet be considered suitable for obtaining definitive experimental results for the paper. Therefore, the main results considered in the evaluation are the theoretical ones.

Another limitation is that BMv2 switches have a generally limited queue length of 64 packets, using the system RAM memory to store queued packets. However, RouteNet-Fermi requires queue values to be expressed in bits [32,40]. The queue size value of the links was maintained at 32,000 bits, considering that the packets transmitted through the network are small (100 B on average). In the future, the prototype could be improved by using more powerful software implementations, such as the P4 Data Plane Development Kit (DPDK) target, which would provide better performance [42] because it is a direct translator of P4 code to use it at Intel DPDK. Also, real switches like, at least, Intel Tofino’s, can provide even greater performance [15], despite the fact that they are currently discontinued.

The purpose of the UDP flooding test is twofold: to evaluate how the algorithm identifies this type of attack and to perform a basic stress test of the prototype. The generated packets are large (1000 B), and the script continuously sends packets at a rate of 10 packets per second. The traffic is directed towards a single IP address.

The algorithm assigns a score of 0 to every analyzed packet, indicating that something is not working correctly internally, as this type of traffic should not be classified as benign. The feature extraction process was verified and is working correctly. A possible explanation is that HyperVision is a self-supervised algorithm and requires additional data before it can perform accurate classification [3].

On the other hand, this type of traffic severely affects the performance of the testbed. It is not possible to keep Wireshark running to capture packets, and the only processes that can remain active are the Containernet topology, the controller, and the flooder (running inside a container within the topology). The computer used as the testbed is close to being insufficient for this prototype, despite the fact that the emulated network is small.

Considering the previously presented issues, some insights can be extracted from the prototype implementation:

1.: About the prediction model, basis of the DTN, it is clear that there is a need of specific training, thinking in using P4 switches, because some delay will be included in a real scenario even if the switches are better in response time than the BMv2 ones. The prototype only uses a trained model from RouteNet-Fermi because they declare that training is not mandatory for little networks [32]. This fact does not apply here, clearly watching the results because these models are not trained with SDN switches.
In addition, there are some prediction models that are prepared for SDN in the State of Art [28], despite the fact that they are for OpenFlow SDN, those switches also send the packet of an unknown flow to the controller and should be more prepared for P4 switches that work similarly in that way with OpenFlow switches.
2.: Regarding the adaptation of HyperVision, it is identified a potential performance issue; however, since it appears to be a well-established approach, the error is more likely related to the adaptation process or the installation of its dependencies.
3.: It may be better to isolate the DTN and the DTNM in 2 separate machines (or containers running on the same machine). This approach can prevent connectivity problems between real hosts and the DTNM. However, sufficiently fast connections between both components are required to avoid synchronization issues. Considering this last point, a single-machine solution with virtual separation may be the best option, using an internal interface to provide communication between the DTN and the DTNM.

The prototype demonstrates the feasibility of a real-time security architecture that integrates SDN and DTN. By utilizing Containernet, P4 switches, and RouteNet-Fermi GNN-based modeling, the system successfully validates the monitoring of network states and the redirection of unknown flows to a virtual mirror for analysis. While the proof-of-concept is functional, testing revealed performance bottlenecks in the BMv2 software switch, which introduced delays of about 1 s, significantly higher than the model’s prediction time, about 50 µs. This suggests that real-world deployment requires production-grade hardware, such as Intel Tofino. Regarding costs, the estimated implementation budget is about EUR 5250. This includes a high-performance DTNM server (3441.50 euros) equipped with an AMD Ryzen Threadripper and a dedicated GPU to handle ML algorithms efficiently, along with two P4-enabled switches (EUR 1796.96). The architecture is highly viable for data centers, which can leverage existing virtualization infrastructure and general-purpose computational power to host the DTN.

So, the current prototype validates the proposed architecture. However, the future work must include a complete implementation enabling quantitative benchmarking, including performance, scalability, and operational overhead analyses.

4.4. DTN Impact

Without the proposed DTN design, classification algorithms cannot protect a network in real time. Instead, their results are used a posteriori to create security mechanisms, such as firewall rules. Meanwhile, these algorithms need to collect all the information required to classify flows, meaning that the ON must handle the entire load generated by network traffic. Even worse, when attacks of any type are launched (e.g., flooding, malware, etc.), attackers can degrade the performance experienced by legitimate users of the ON. The DTN is essential to achieve the expected service perception provided by the ON because it emulates the behavior and performance of the ON. If the network used to analyze unknown sources does not replicate this aspect, attackers may adapt their behavior to be classified as benign, increasing the possibility of successful attacks against the network.

The proposed architecture prioritizes security over immediate access to previously unknown external services. Consequently, traffic associated with unknown flows is redirected to the DTN until the classification process reaches a decision. In the current design made in the prototype, the decision typically requires observing the complete flow. Therefore, the additional latency is variable and potentially can be significant (seconds) depending on the characteristics of the analyzed traffic. This design trade-off makes the proposed solution particularly suitable for environments such as data centers, where protecting critical services is indeed more important than the delay introduced for previously unknown external communications. A comprehensive quantitative assessment of latency, throughput, scalability, deployment costs, and the impact on benign traffic requires a complete production-grade implementation and is included in the future work.

The DTN therefore has a second role: acting as a sandbox environment where potentially malicious traffic can be redirected, protecting real hosts from damage caused by malicious users.

5. Conclusions and Future Work

This paper presents an approach to improve the security of classification algorithms by preventing unknown incoming flows from reaching the real network that must be protected (the ON). These detection systems need to collect a certain number of packets, or even the complete flow, to differentiate between malicious and benign traffic.

Previous research has studied how DTN can improve the security provided by these algorithms by addressing this limitation. The main idea is that attackers must perform their activities without realizing that they have been redirected to the digital twin of the network. The DTN estimates the delays introduced by the real network when processing packets, including queuing, forwarding, and service delays. Without this emulation, attackers may adapt their behavior to the analysis environment, allowing malicious traffic to be classified as benign by the algorithm.

This paper presents a design that integrates SDN to achieve fast traffic redirection towards the DTN and P4 switches to perform the required monitoring directly at the network level, reducing the need for dedicated monitoring hardware.

The document also presents a prototype implementation of the proposed architecture, validating the feasibility of monitoring and traffic redirection using SDN and P4 switches, as well as evaluating the behavior of the prediction model used in an SDN environment. However, this prototype is not yet suitable for obtaining empirical conclusions about the benefits provided by DTN, as it represents an initial step in the research process.

The results of this work highlight the importance of correctly selecting and combining security mechanisms for network protection. Security must be considered at different levels: intrusion detection systems (IDS) are effective against known attacks, firewalls are essential for blocking unauthorized traffic, and classification algorithms help identify unknown threats. Each technology provides valuable protection, but each also has inherent limitations. The research presented in this paper proposes a method to improve one of these technologies while mitigating one of its main weaknesses.

The proposed design also presents several limitations. The main limitation is the increased delay when users inside the network attempt to access unknown external services. This occurs because the architecture first redirects the request to the DTN, which replicates the communication and analyzes the response using the Classification Algorithm before allowing the traffic to reach the real network.

Additionally, the management of trusted IP addresses in the controller could be improved by storing additional information, such as destination transport ports, to reduce the possibility of attackers bypassing the protection mechanism. If an attacker discovers the existence of the DTN, they could first generate a benign flow that is classified as trustworthy, causing subsequent traffic from the same IP address to be redirected directly to the ON, potentially allowing a malicious flow to reach the protected network.

Another challenge is the difficulty of deploying such an architecture in real environments. Both SDN-enabled P4 hardware and the additional servers required to implement the DTN may represent a significant cost. A suitable deployment scenario would be data centers, as they can virtualize SDN components through VNFs and potentially reuse available computing resources to deploy the DTN, increasing the protection provided by classification algorithms when such systems are already in use.

Several future improvements can be explored to address the limitations identified in this work. These include:

1.: Based on the prototype presented in this paper, other strategies should be considered to address the problem of accessing unknown external services from the protected network. The proposed approach introduces significant delays in these communications.
2.: Implement a more sophisticated mechanism for storing information about banned and permitted flows, for example by including the destination port used by each flow. The current approach could be bypassed if an attacker identifies the architecture and performs a flow escalation attack by sending a benign flow before launching the malicious one.
3.: Perform a complete implementation for a real environment testing using current hardware (real P4 switches and servers) to evaluate the performance under stress conditions and verify whether the time emulation requirements are maintained in such scenarios. If this is not feasible, the prototype could be improved by increasing the available hardware resources to achieve performance closer to existing devices and by adopting more optimized software implementations of P4 switches. With these improvements, more valuable empirical results could be obtained.
4.: Measure the performance achieved by the proposed architecture, especially in terms of maximum supported throughput, and develop a scaling strategy to improve this key metric.
5.: A full security audit, requiring a mature implementation and extensive testing.
6.: A comprehensive quantitative evaluation to assess the performance, scalability, and security effectiveness in realistic deployment scenarios of the architecture validated in this work using the presented prototype.
7.: A detailed analysis of the synchronization mechanisms between the Original Network and the Digital Twin Network must be considered in the next works, through a complete implementation, in order to quantifying their latency, communication overhead, and computational cost.
8.: A comprehensive scalability evaluation and complexity analysis through a complete implementation and large-scale experimental evaluation.

Author Contributions

Conceptualization, X.H. and J.P.C.; methodology, X.H. and J.P.C.; software, J.P.C.; validation, J.P.C.; formal analysis, X.H. and J.P.C.; investigation, X.H. and J.P.C.; resources, X.H. and J.P.C.; data curation, J.P.C.; writing—original draft preparation, X.H. and J.P.C.; writing—review and editing, X.H. and J.P.C.; visualization, J.P.C.; supervision, X.H.; project administration, X.H.; funding acquisition, X.H. All authors have read and agreed to the published version of the manuscript.

Funding

This work is part of the I+D+i project PID2022-137329OB-C41, supported by MICIU/AEI/10.13039/501100011033 and FEDER, UE.

Data Availability Statement

The original contributions presented in this study are included in the article. Further inquiries can be directed to the corresponding author.

Conflicts of Interest

The authors declare no conflicts of interest.

Abbreviations

The following abbreviations are used in this manuscript:

AI	Artificial Intelligence
BMv2	Behavioral Model version 2
CPS	Cyber Physical Systems
DPI	Deep Packet Inspection
DTN	Digital Twin Networks
DTNM	Digital Twin Network Manager
GML	Graph Modeling Language
GNN	Graph Neural Networks
IDS	Intrusion Detection System
IETF	Internet Engineering Task Force
ITU-T	International Telecommunication Union Telecommunication Standardization Sector
ML	Machine Learning
NDT	Network Digital Twin
NFV	Network Function Virtualization
ON	Original Network
ONM	Original Network Manager
OSM	Open Source MANO
P4	Programming Protocol-independent Packet Processors
SDN	Software Defined Networks
VNF	Virtual Network Function

References

Banisadr, A.H.; Hesselbach Serra, X. A novel architecture for virtual network twin deployment. Electronics 2024, 13, 5045. [Google Scholar] [CrossRef] [Scilit]
Calle-Heredia, X.; Hesselbach, X. Digital Twin-Driven Virtual Network Architecture for Enhanced Extended Reality Capabilities. Appl. Sci. 2024, 14, 10352. [Google Scholar] [CrossRef] [Scilit]
Fu, C.; Li, Q.; Xu, K. Detecting Unknown Encrypted Malicious Traffic in Real Time via Flow Interaction Graph Analysis. arXiv 2023, arXiv:2301.13686. [Google Scholar]
Alzahrani, A.O.; Alenazi, M.J. ML-IDSDN: Machine learning based intrusion detection system for software-defined network. Concurr. Comput. Pract. Exp. 2023, 35, e7438. [Google Scholar]
Franco, J.; Aris, A.; Babun, L.; Uluagac, A.S. S-pot: A smart honeypot framework with dynamic rule configuration for SDN. In Proceedings of the GLOBECOM 2022-2022 IEEE Global Communications Conference; IEEE: New York, NY, USA, 2022; pp. 2818–2824. [Google Scholar]
Kreutz, D.; Ramos, F.M.V.; Veríssimo, P.E.; Rothenberg, C.E.; Azodolmolky, S.; Uhlig, S. Software-Defined Networking: A Comprehensive Survey. Proc. IEEE 2015, 103, 14–76. [Google Scholar] [CrossRef] [Scilit]
Wu, Y.; Zhang, K.; Zhang, Y. Digital twin networks: A survey. IEEE Internet Things J. 2021, 8, 13789–13804. [Google Scholar] [CrossRef] [Scilit]
Zhang, Y.; Cui, L.; Wang, W.; Zhang, Y. A survey on software defined networking with multiple controllers. J. Netw. Comput. Appl. 2018, 103, 101–118. [Google Scholar] [CrossRef] [Scilit]
McKeown, N.; Anderson, T.; Balakrishnan, H.; Parulkar, G.; Peterson, L.; Rexford, J.; Shenker, S.; Turner, J. OpenFlow: Enabling innovation in campus networks. ACM SIGCOMM Comput. Commun. Rev. 2008, 38, 69–74. [Google Scholar] [CrossRef] [Scilit]
Hu, F.; Hao, Q.; Bao, K. A survey on software-defined network and openflow: From concept to implementation. IEEE Commun. Surv. Tutor. 2014, 16, 2181–2206. [Google Scholar] [CrossRef] [Scilit]
Open Networking Foundation. OpenFlow Switch Specification; Version 1.5.1; Open Networking Foundation: Palo Alto, CA, USA, 2014. [Google Scholar]
Hauser, F.; Häberle, M.; Merling, D.; Lindner, S.; Gurevich, V.; Zeiger, F.; Frank, R.; Menth, M. A survey on data plane programming with p4: Fundamentals, advances, and applied research. J. Netw. Comput. Appl. 2023, 212, 103561. [Google Scholar] [CrossRef] [Scilit]
Bosshart, P.; Daly, D.; Gibb, G.; Izzard, M.; McKeown, N.; Rexford, J.; Schlesinger, C.; Talayco, D.; Vahdat, A.; Varghese, G.; et al. P4: Programming protocol-independent packet processors. ACM SIGCOMM Comput. Commun. Rev. 2014, 44, 87–95. [Google Scholar]
P4 Language Consortium. P4₁₆ Language Specification. 2024. Available online: https://p4.org/ (accessed on 29 July 2026).
Intel Tofino Switches. Available online: https://www.intel.com/content/www/us/en/ark/products/series/210606/intel-tofino.html (accessed on 12 May 2025).
Shin, S.; Xu, L.; Hong, S.; Gu, G. Enhancing network security through software defined networking (SDN). In Proceedings of the 2016 25th International Conference on Computer Communication and Networks (ICCCN); IEEE: New York, NY, USA, 2016; pp. 1–9. [Google Scholar]
Park, T.; Kim, Y.; Yegneswaran, V.; Porras, P.; Xu, Z.; Park, K.; Shin, S. Dpx: Data-plane extensions for sdn security service instantiation. In Proceedings of the Detection of Intrusions and Malware, and Vulnerability Assessment: 16th International Conference, DIMVA 2019, Gothenburg, Sweden, 19–20 June 2019; Springer: Berlin/Heidelberg, Germany, 2019; pp. 415–437. [Google Scholar]
Li, C.; Wu, Y.; Yuan, X.; Sun, Z.; Wang, W.; Li, X.; Gong, L. Detection and defense of DDoS attack–based on deep learning in OpenFlow-based SDN. Int. J. Commun. Syst. 2018, 31, e3497. [Google Scholar] [CrossRef] [Scilit]
Gao, Y.; Wang, Z. A review of P4 programmable data planes for network security. Mob. Inf. Syst. 2021, 2021, 1257046. [Google Scholar] [CrossRef] [Scilit]
Kang, Q.; Xue, L.; Morrison, A.; Tang, Y.; Chen, A.; Luo, X. Programmable In-Network security for context-aware BYOD policies. In Proceedings of the 29th USENIX Security Symposium (USENIX Security 20), Boston, MA, USA, 12–14 August 2020; pp. 595–612. [Google Scholar]
Hauser, F.; Häberle, M.; Schmidt, M.; Menth, M. P4-ipsec: Site-to-site and host-to-site vpn with ipsec in p4-based sdn. IEEE Access 2020, 8, 139567–139586. [Google Scholar] [CrossRef] [Scilit]
Lewis, B.; Broadbent, M.; Race, N. P4ID: P4 enhanced intrusion detection. In Proceedings of the 2019 IEEE Conference on Network Function Virtualization and Software Defined Networks (NFV-SDN); IEEE: New York, NY, USA, 2019; pp. 1–4. [Google Scholar]
Gupta, S.; Gosain, D.; Kwon, M.; Acharya, H.B. Deep4r: Deep packet inspection in p4 using packet recirculation. In Proceedings of the IEEE INFOCOM 2023-IEEE Conference on Computer Communications; IEEE: New York, NY, USA, 2023; pp. 1–10. [Google Scholar]
Internet Engineering Task Force (IETF). Network Digital Twin: Concepts and Reference Architecture; Internet Engineering Task Force (IETF): Fremont, CA, USA, 2025. [Google Scholar]
International Telecommunication Union Telecommunication Standardization Sector (ITU-T). Digital Twin Network—Requirements and Architecture; International Telecommunication Union Telecommunication Standardization Sector (ITU-T): Geneva, Switzerland, 2022. [Google Scholar]
Almasan, P.; Ferriol-Galmés, M.; Paillisse, J.; Suárez-Varela, J.; Perino, D.; López, D.; Perales, A.A.P.; Harvey, P.; Ciavaglia, L.; Wong, L.; et al. Network digital twin: Context, enabling technologies, and opportunities. IEEE Commun. Mag. 2022, 60, 22–27. [Google Scholar] [CrossRef] [Scilit]
Almasan, P.; Ferriol-Galmés, M.; Paillisse, J.; Suárez-Varela, J.; Perino, D.; López, D.; Perales, A.A.P.; Harvey, P.; Ciavaglia, L.; Wong, L.; et al. Digital twin network: Opportunities and challenges. arXiv 2022, arXiv:2201.01144. [Google Scholar]
Raj, D.R.R.; Shaik, T.A.; Hirwe, A.; Tammana, P.; Kataoka, K. Building a digital twin network of sdn using knowledge graphs. IEEE Access 2023, 11, 63092–63106. [Google Scholar] [CrossRef] [Scilit]
Grasselli, C.; Melis, A.; Rinieri, L.; Berardi, D.; Gori, G.; Al Sadi, A. An industrial network digital twin for enhanced security of cyber-physical systems. In Proceedings of the 2022 International Symposium on Networks, Computers and Communications (ISNCC); IEEE: New York, NY, USA, 2022; pp. 1–7. [Google Scholar]
Mozo, A.; Karamchandani, A.; Gómez-Canaval, S.; Sanz, M.; Moreno, J.I.; Pastor, A. B5GEMINI: AI-driven network digital twin. Sensors 2022, 22, 4106. [Google Scholar] [CrossRef] [Scilit] [PubMed]
Wu, Z.; Pan, S.; Chen, F.; Long, G.; Zhang, C.; Yu, P.S. A comprehensive survey on graph neural networks. IEEE Trans. Neural Netw. Learn. Syst. 2020, 32, 4–24. [Google Scholar] [CrossRef] [Scilit] [PubMed]
Ferriol-Galmés, M.; Paillisse, J.; Suárez-Varela, J.; Rusek, K.; Xiao, S.; Shi, X.; Cheng, X.; Barlet-Ros, P.; Cabellos-Aparicio, A. RouteNet-Fermi: Network Modeling with Graph Neural Networks They also have a GitHub with an implementation. IEEE/ACM Trans. Netw. 2023, 31, 3080–3095. [Google Scholar]
Fadhil, D.; Oliveira, R. A novel packet end-to-end delay estimation method for heterogeneous networks. IEEE Access 2022, 10, 71387–71397. [Google Scholar] [CrossRef] [Scilit]
Suzuki, T.; Yasuda, Y.; Nakamura, R.; Ohsaki, H. On estimating communication delays using graph convolutional networks with semi-supervised learning. In Proceedings of the 2020 International Conference on Information Networking (ICOIN); IEEE: New York, NY, USA, 2020; pp. 481–486. [Google Scholar]
Boero, L.; Cello, M.; Marchese, M.; Mariconti, E.; Naqash, T.; Zappatore, S. Statistical fingerprint-based intrusion detection system (SF-IDS). Int. J. Commun. Syst. 2017, 30, e3225. [Google Scholar] [CrossRef] [Scilit]
Zhao, Z.; Li, Z.; Zhou, Z.; Yu, J.; Song, Z.; Xie, X.; Zhang, F.; Zhang, R. DDoS family: A novel perspective for massive types of DDoS attacks. Comput. Secur. 2024, 138, 103663. [Google Scholar] [CrossRef] [Scilit]
Diallo, A.F.; Patras, P. Cluster and conquer: Malicious traffic classification at the edge. IEEE Trans. Netw. Serv. Manag. 2023, 21, 2700–2714. [Google Scholar] [CrossRef] [Scilit]
Containernet. Available online: https://containernet.github.io/ (accessed on 4 October 2024).
Mininet. Available online: https://mininet.org/ (accessed on 15 July 2024).
Reference Software for a Virtual P4 Switch (BMv2). Available online: https://github.com/p4lang/behavioral-model (accessed on 6 February 2025).
P4 Runtime Shell Capable of Control BMv2 Switches from Python. Available online: https://github.com/p4lang/p4runtime-shell (accessed on 10 March 2025).
P4-DPDK Target. Available online: https://github.com/p4lang/p4-dpdk-target (accessed on 16 June 2025).

Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

Article Metrics

Citations

Article Access Statistics

Journal Statistics

Multiple requests from the same IP address are counted as one view.