2.2.1. General architecture

SDN architecture is mainly composed of three planes (Figure 2.1): the application plane, data plane, and control plane. Separation between the control plane and the data plane is at the core of this architecture (ONF 2015).

The application plane contains both the SDN applications and the network applications. The SDN controller uses an application programming interface (API), known as northbound API, which interacts with the application plane. This plane contains applications enabling the implementation of purely network functionalities, such as QoS and routing. Other SDN applications whose role is to control the SDN-based network logic can also be found here (Bannour et al. 2018).

The data plane is composed of physical or virtual equipment for interconnection with a main task of data forwarding. In fact, in traditional networks, the network equipment contains the control plane and the data plane. With this new approach, the control plane is externalized in order to enhance network equipment’s efficiency. These network elements (mainly switches) contain the forwarding tables and can be remotely controlled via APIs.

The control plane is implemented at the SDN controller level, generally on a physical server or in the cloud. The controller manages the entire “intelligent” logic of the SDN-based network by programming (on-the-fly manipulation) the content of the forwarding tables at the data plane level. The SDN controller manages the infrastructure in its entirety and is able to acquire real-time information on the state and activity of the (physical or virtual) network equipment it controls.

In a routing protocols context, the control plane would correspond to the component whose task it is to find the best paths for the router and set a ready to use routing table for it. It is logically centralized but can be physically distributed between several elements (Bannour et al. 2018). When controllers are physically distributed, they can communicate using East and Westbound API.

The control plane and the data plane communicate via a class of protocols known as a Southbound interface. In 2019, the most advanced and commercially available Southbound interface for SDN-based networks was OpenFlow¹. There are however other alternatives such as ForCES, SNMP and NetConf of IETF. Furthermore, other approaches to network equipment programming exist, such as P4 (Bosshart et al. 2014; Cordeiro et al. 2017), which are currently under development.

OpenFlow was originally a Stanford University project. Today, it is a standard network protocol, published by the ONF, which serves as a link between the control plane and the data plane. This protocol is composed of instructions (rules) that enable the programming of forwarding tables of network equipment, referred to here as flow tables. The instructions define an action on the traffic (packet transmission, packet rejection, etc.). Various versions of the OpenFlow protocol have been introduced to add more flexibility and reliability including several flow tables, improved correspondence/action capacities, optical ports, group tables, etc.²

Furthermore, many OpenFlow controllers are available, such as POX (Kaur et al. 2014), Beacon (Erickson 2013) and OpenDayLight³.

2.2.2. Logical distribution of SDN control

The physical centralization of the control plane in a single programmable software component known as a “controller” raises a number of problems, particularly in terms of scalability, availability and reliability (Nkosi et al. 2016; Karakus and Durresi 2017). Hence, the higher the number of switches, the higher the load of the SDN controller, and therefore its overload in terms of bandwidth, processing power and memory capacity. The communication delays between the SDN controller and the switches increase also with the network size and extent, which consequently influences the data flow latency (Bannour et al. 2018). The scalability problem can be solved by extending the responsibilities of the data plane in order to lighten the controller load, but this requires a modification of the switches design (Rebecchi et al. 2017).

The control plane should therefore be designed as a distributed system in which several SDN controllers are in charge with the overall network management, while maintaining a logically centralized network view. Indeed, this solution provides a better scalability to the network control plane, while reducing the latencies of the control plane. Moreover, the use of several controllers improves reliability by eliminating the problem of the single point of failure.

Several works have focused on distributed control design. In Oktian et al. (2017), the various approaches to how a logically centralized view is provided to several instances of distributed controllers depending on the choice of design implemented have been discussed. They have thus identified two distributed architectures: flat architecture and hierarchical architecture (Figure 2.2). In flat architecture, each controller manages a subnetwork/field of the global network. In hierarchical architecture, local controllers manage the needs of local applications, while the main controller, generally known as the “root”, deals with the needs of applications requiring a global network view.

In Bannour et al. (2018), the authors classified control architectures depending on how knowledge is disseminated between the controller instances. Two architectures are mentioned, the first centralized and the second distributed. This classification enabled them to compare the various SDN controller platforms in terms of upgradability, reliability and performance criteria. The authors prefer the hierarchical organization of the control plane for better upgradability and better performances. Each controller can thus have different responsibilities and make decisions based on a partial view of the network. The highest level acts as a centralized controller, with the problem of a single point of failure.

Table 2.1 presents a classification of network information to be exchanged between distributed controllers in order to maintain the global view.

The distribution of SDN control raises a number of challenges, among which the identification of the required number of controllers as well as their appropriate locations with respect to the expected performance and reliability objectives. Hence, the hierarchical organization of the control plane requires a relevant diagram of control distribution taking into account both the organization of SDN control plane and the physical location of SDN controllers (Bannour et al. 2018). Finally, to preserve the logically centralized view, the requirement to share knowledge between controllers may introduce new scalability problems. Indeed, the frequent propagation of state updates can make the network unavailable, which will increase the latency between controller and switches.

Another significant challenge relates to the fault tolerance of the distributed control architecture. Hence, controller coordination strategies should be implemented to reach agreements and also solve the problems related to the competition between updates and state consistency (Bannour et al. 2018). The state consistency of logically centralized SDN controllers is a major design challenge of SDN-based networks, which involves compromises between rule application and network performances. It is indeed very difficult to reach high consistency in an SDN environment subjected to network failures without compromising its availability and without adding to the complexity of the network state management. Recent approaches have introduced the concept of adaptive consistency, according to which the controllers can adjust their consistency level to reach the expected performance level, depending on specific metrics. This consistency should be taken into account when searching for the optimal location of controllers. Indeed, minimizing the distances between controllers is important for system performances; it facilitates the communication between controllers and improves the state consistency of the network. In Canini et al. (2014), the authors dealt with this problem and proposed a robust distributed SDN control plane, known as software transactional networking (STN).

The security of the distributed SDN-based network is a further crucial challenge. Decentralization of SDN control reduces the risk associated with a single point of failure and with attacks (DDoS, for example). However, the integrity of data flows between SDN controllers and switches is not always certain. A plausible scenario would be that of an attacker being able to corrupt a network by acting as an SDN controller.

Finally, it is also difficult to ensure the interoperability of distributed SDN controllers belonging to different SDN domains and using different controller technologies.

Several researches proposed the integration of automated and adaptive approaches in the distributed control plane in order to meet the previously mentioned challenges. Hence, in Ma et al. (2018), the authors use reinforced learning for the automation of the resource management and distribution in a distributed SDN-based network.

2.3.1. Attack surfaces

In terms of attack identification and response, SDN has two essential advantages, compared to traditional networks (Fortes 2013; Tang et al. 2016):

• – the control plane enables an administrator to separate and block the attacks on any heterogeneous material (no need to individually reconfigure each component);
• – instead of investing in an expensive intrusion detection system, SDN is able to distribute a task between the nodes; moreover, each node can become a firewall, a proxy, etc.

As for the drawbacks, SDN provides an opportunity to attackers when it exposes new interfaces, which means communication between the control plane and the data plane. By compromising the SDN controller, the entire network can be compromised. Consequently, when using SDN to provide intrusion detection systems (IDS) services, the security of the latter should be kept in mind. An impenetrable access control strategy for the SDN controller should therefore be designed and implemented.

Security of the application plane: the application plane includes various types of applications. Some of them play a very important role in the elaboration of flow rules. Attacking these applications may cause a malfunction of the SDN-based network. An attacker may inject a malicious code in the application or may illegally access the SDN-based network. Developing an access control model or a code verification mode is effective approach against this type of attacks (Klaedtke et al. 2014).

Security of controllers: the SDN controller is the most important element. An attacker conducting an attack on the controller may easily gain total control of the network. The vulnerabilities in the control plane may also lead to illegally controlling the controller. Moreover, an attacker may launch a flooding attack using the vulnerabilities of the switch (sending several packets of a compromised switch to a controller may disable it) or of the OpenFlow protocol (an attacker may send packets that do not correspond to the table and therefore the switch is going to send them all to the controller, which may trigger a DoS/DDoS). The controller is the main target of the DoS attacks.

Security of the data plane: the switch is the crucial part of the data plane. It transfers packets, reads the MAC address table and the ARP requests, etc. Several attacks are possible in the data plane, such as the DoS/DDoS. A further attack can be conducted via the size of the flow tables, which can be very significant and can therefore reduce the switching speed, especially when the Southbound interface is compromised.

Security of protocols: SDN protocols are mainly protocols of the Southbound and NorthBound interfaces. OpenFlow is typically a Southbound interface protocol. Despite its wide use, it still has vulnerabilities because there is no identification and access control for the communications between the switch and the SDN controller. Protocols can be secured by adding an access control mechanism to the network resources in the data plane from the control plane.

2.3.2. Example of security services deployment in SDN-based networks: IPSec service

Previous work by Coly and Mbaye (2019) proposes a framework for the deployment of security services in an SDN-based network. IPSec tunnels are taken as a security service example to illustrate the operation of this framework. Internet Protocol Security (IPsec) (Kent and Seo 2005) is a suite of protocols securing the IP layer of the TCP/IP model. This framework can be used to provide a virtual private network (VPN) or establish secure tunnels between two sites. This protocol uses the Internet Key Exchange (IKE) protocol for key negotiation and management.

The main outcomes of this proposal are as follows: design of an architecture for the deployment of security services in SDN-based networks, a new extension of OpenFlow protocol for the management of secured tunnels and, finally, integration of an IPSec-based tunnel mechanism in SDN-based networks as use case.

2.3.2.1. General architecture

The proposed architecture is presented in Figure 2.3. The networks (networks’ costumers) are connected by an SDN core network. The core of the SDN-based network is composed of Border Gateway Switches (BGS) and Core Internal Switches (CIS). These switches communicate with the SDN controller through the OpenFlow Southbound interface. The SDN controller coordinates the deployment of security services in the SDN-based network. In the case of tunnels deployed between different end nodes, the security service is deployed only at BGS ingress and egress. In other cases, the service is deployed in all the CIS systems of the flow path.

When a client subscribes to a service level agreement (SLA) comprising a security service, the SDN controller is set up according to this contract. The costumer’s flows will henceforth drive the deployment of this service by sending a “SecTrans” message with the security policies to the (ingress/egress) BGS involved in this communication pathway. The remaining transaction is managed by the Southbound extension. As a use case illustrating the operation of this proposal, let us consider the deployment of an IPsec-based secured tunneling service, as SDN security service. For this purpose, we have extended the OpenFlow protocol for establishing an IPsec tunnel and defined an extended structure for the flow tables.

The SDN controller is in charge with the generation and transmission of IKE identification information. It is also responsible for the control and enforcement of IPsec SPD. Therefore, it has a centralized view of the network and security policies. The IKE component implemented in the network resource runs to create the IPSec security associations using these identification strategies and information. Figure 2.4 illustrates the tunnel deployment process.

If an end node communicates with another one using an IPsec tunnel, the following procedure unfolds:

• 1) the BGS connected to the source sends a “Packet_In” message (an OpenFlow message) to the controller asking how these packets should be processed;
• 2) if there is a correspondence with the traffic of a service subscriber, the controller generates the IKE identification information and the SPD policies and then sends them to the involved (input and output) BGS in addition to the SecTrans message to allow transmission in the IPsec tunnel; the message adds/modifies a flow with “yes” in the IPsec field;
• 3) the BGS implements the IKE identification information and the SPD strategies to establish security associations before starting transmission.

Once the tunnel is set up, all the messages between these two termination points are transmitted through this tunnel.

2.3.2.2. Deployment performance evaluation

The proposal was evaluated using Mininet⁴, OpenSwitch and Floodlight⁵ as SDN controller. Table 2.2 summarizes the node configurations of the test bed.

Node	Operating system	(Software) Components	CPU	RAM
Controller	Debian 8.4	Floodlight master	(4) @ 3.2 GHz	4 GB
Machine A	Debian 8.4	Mininet 2.2.2, Racoon, ipsec-tools	(4) @ 3.2 GHz	4 GB
Machine B	Ubuntu 18.04	Mininet 2.2.2, Racoon, ipsec-tools	(4) @ 2.4 GHz	4 GB
End node A	Ubuntu 18.04	Racoon, ipsec-tools, iperf, top	(8) @ 4.0 GHz	8 GB
End node B	Ubuntu 14.04	Racoon, ipsec-tools, iperf, top	(4) @ 3.2 GHz	8 GB

The core of SDN-based networks of our test bed contains 10 OpenFlow switches, five on each network (Figure 2.5). These switches are hosted on physical computers interconnected as illustrated in Figure 2.6.

Performance is evaluated in terms of delay, throughput, jitter and CPU load. During the tests, we compare the performances of an SDN-based network without IPsec with an IPsec tunnel at endpoints, at the client level, and finally in the case of an SDN-based network with an IPsec tunnel between BGS switches.

These results show that, given this configuration, the delay is more significant when the endpoints of the IPsec tunnel are at the level of terminal nodes than between the security gateways represented by BGS (Figure 2.7(A)(a)). We get a similar result if we look at the throughput (Figure 2.7(A)(b)), the jitter (Figure 2.7(B)(c)) and the process load (Figure 2.7(B)(d)).

Although the scope of these results should be confirmed, they can be an argument in favor of deploying security services at gateways (as opposed to terminal nodes). With this type of result, security could be managed as a service at the controller level.

2.4.1. Knowledge plane

In 2003, Clark et al. (2003) proposed a new plane enabling knowledge management in a network: the knowledge plane. The main objective of this new plane was to solve the Internet-specific limits, particularly the lack of reliability and adaptation when facing a new situation such as a security attack (Mbaye and Krief 2009). This work has been subsequently integrated in the architectures of autonomous networks. An autonomous network is defined as one with the capacity of management and underlying infrastructure processes to deploy, organize and operate without external aid. The administrator only guides these processes, setting high level objectives (Krief 2010). The knowledge plane plays an essential role in autonomous networks, enabling each autonomous entity to close the network control loop without administrator support. Management tasks can therefore be conducted by the network itself, each autonomous entity being capable of self-configuration, self-optimization, self-protection and self-repair. Movahedi et al. (2012) compared the various architectures of autonomous networks and underlined the role of learning in enabling intelligent adaptation and converging to optimal network operation.

In the context of SDN-based networks, the clear separation between the control and data planes and the centralization of intelligence can positively influence the development of the knowledge plane with new functionalities.

2.4.2. Knowledge-defined networking

Mestres et al. (2017) studied the reasons why AI techniques were not adopted in practice and stated that the expansion of the two recent paradigms, namely the SDN and the network analysis (NA), will facilitate the adoption of these techniques for network control and use. They also proposed a new paradigm, known as KDN, which associates SDN, NA and ML to provide automated network control. In Mestres et al. (2018), they explored the possibility of applying various ML models and techniques for modeling complex network elements, such as the virtual network function (VNF). They also proved that the behavior of various VNFs could be learnt using ML techniques, such as their CPU consumption depending on input traffic.

The ALLIANCE project (Careglio et al. 2018) relies on the new KDN paradigm. Its objective is to design and implement a 5G network infrastructure that is capable of dealing with ubiquitous services, while meeting the performances and commercial demands of multiple stakeholders. This project is expected to propose, compare and interconnect three different prototypes of complete network architecture (from access network to core network), autonomous and 5G oriented. Several network solutions will be studied, such as SDN/NFV, programmable overlay networks and Recursive InterNetwork Architecture (RINA). Each of the retained solutions relies on a KDN orchestrator, which takes advantage of ML techniques for automated network deployment, use, monitoring and repair.

In Hyun and Hong (2017), the authors present an autonomous network architecture combining network telemetry, KDN, SDN and P4 INT. P4 INT (In-band Network Telemetry) enables the gathering of network telemetry data. These data are then used by the KDN to bring intelligence to network management. SDN is then in charge of network management and control depending on the decision made by the knowledge plane. In Hyun et al. (2018), the authors present a first implementation of the network monitoring system.

In Lu et al. (2019), the authors take an interest in the orchestration at KDN level in order to put into operation a hybrid optical/electronic DCN in a high-performance and energy-efficient manner. This orchestration relies on three AI modules based on deep learning, namely the traffic prediction module, the module for the prediction of the virtual machine demand and the module for network reconfiguration. The experimental results show that, besides an improvement in service provision performances, this approach enables better energy efficiency in the system.

2.4.3. Intelligence-defined networks

Intelligence-defined network (IDN) approaches come as a development of SDN by adding a cognitive layer above the control layer. This also enables the introduction of AI in the network management and control. This approach is quite similar to KDN approach, but it is proposed by manufacturers, particularly by Huawei (Jiang 2016; Huawei 2018).

The latter proposed at the Mobile World Congress in 2018 a new offer referred to as an intent-driven network (IDN), aimed at upgrading the SDN-based networks into networks “driven by intent” by the addition of AI, big data and cloud technologies. Emphasis is on the capacity of the control plane to know – or to predict – the type of application/service that a client would want to use and the context in which he/she would want to do it, in order to automatically book for him/her the full bandwidth he/she needs, and provide him/her the best user experience. The network, now centered on the user, is thus capable of accurately identifying the client intent and fulfilling it. It is also capable of detecting in real time the quality of the user experience and conducting a predictive analysis in order to proactively optimize performances (Huang et al. 2018).

2.5.1. ML techniques

ML is a subdomain of AI; it can be further divided into four groups:

• 1) supervised learning: given a set of objects, each of which has an associated target value, the system must learn a model that is capable of predicting the proper target value of a new object;
• 2) unsupervised learning: given a set of objects that have no associated target value, the system must learn a model that is capable of extracting regularities in the set of objects in order to understand the data structure;
• 3) semi-supervised learning: given a small set of objects, each of which has an associated target value and a larger set of objects without target value, the system must be capable of solving supervised and/or unsupervised problems;
• 4) reinforcement learning: given a set of decision sequences in a dynamic environment and for each action of a sequence a reward value, the system must learn a model capable of predicting the best decision.

Researches in the field of computer security use mainly supervised and unsupervised learning techniques. These techniques are presented in the next sections.

2.5.2. Contribution of AI to security service: intrusion detection

The above-mentioned AI techniques have been used to solve many security problems in general, and particularly for intrusion detection (Soheily-Khah et al. 2018).

In Barapatre et al. (2008), an approach with a multilayer perceptron–back propagation (MLP-BP) is proposed. The input to the proposed system has the characteristics of the Knowledge Discovery from Database (KDD)⁶ dataset and the output the classification of normal packets and suspect packets present in the dataset. The MLP-BP neural network has been shown to detect DoS and “Probe” attacks more accurately than the user to root (U2R) attacks. In Lu et al. (2015), the authors use the radial basis function (RBF) neural networks, which are very practical in intrusion detection systems. They compared RBF and MLP-BP using a KDD dataset that was processed by the conversion of all the chains into figures, thus reducing the size of the dataset. The simulation results showed that the RBF neural network is better than MLP-BP in terms of learning time, accuracy and detection of attacks.

Canbay and Sagiroglu (2015) propose a hybrid approach for attack detection. GA and K-NN were used in combination for attack modeling and detection. K-NN was used for the classification of the attacks and GA for the selection of k neighbors in a sample of attacks. This hybrid system was applied for the first time in the field of intrusion detection. The results showed that the proposed system yields better results in terms of detection accuracy than a single system.

Most researchers used the KDD dataset, which was widely criticized for not being a faithful representation of the network. In Sahu and Mehtre (2015), the authors used a new set of labeled network data, referred to as the “Kyoto 2006+ dataset”. In Kyoto 2006+, each instant is labeled as “normal” (no attack), attack” (known attack) and “unknown attack”. The users used the Decision Tree (J48) algorithm to classify the network packet that could be used for a Network IDS (NIDS). The results showed that the decision tree has a very good classification accuracy and that it also enables the classification of unknown attacks.

As these several work samples prove, the potential of AI has not yet been exhausted in the security field, since a combination of techniques may yield better results.

2.7.1. Attack signature learning as cloud service

The proposal in Hamdi et al. (2015) is to provide attack signature learning as a Cloud service. The service is deployed in the cloud with a client/server architecture. Clients have access to the service via secured VPN.

The learning service is provided by learning nodes (LN) containing inductive logic programming (ILP) modules. The LNs receive as input malicious and normal traffics in standard formats (for example, PCAP). The system replies with a Prolog rule (signature) that can be translated into any specific target grammar.

Insiden an LN there is an ILP engine, a facts base and a grammar translator proxy (GTP). This proxy is a component of data mediation between the ILP engine and the client. It translates the input data from the client into predicates corresponding to ILP engine parameters:

• – malicious traffic positive examples (E⁺);
• – normal traffic negative examples (E⁻).

The ILP engine learns the rules corresponding to the attack signatures presented to it. This engine needs a facts base composed of background knowledge (BK) and examples that correspond to traffics classified as malicious.

Once the ILP engine learns the rules, GTP transforms these rules of Prolog grammar into the target IDS-specific grammar.

For the time being, only the grammar for IDS SNORT rules is taken charge of by the proposal. Let the learnt signature be C ⊨ P₁ …P_n, where C is the concept at the clause heading and P₁ …P_n are predicates of BK. The transformation of the SNORT signature rule involves two stages.

Stage 1: build the rule heading based on the Prolog signature by extracting the source and destination IP addresses, the port numbers in the learnt signature. The BK predicates that can be in the signature rule body are: Pi=ip_src(packet), Pj=ip_dst(packet), Pk=src_port(packet), dst_port(packet), Pl=proto(X,tcp). Table 2.4 gives an idea of the transformation done.

Stage 2: build the body of rules. In the SNORT body, C is transformed into (msg: some_text_id). The body predicates P_n …P_n are transformed in the closest SNORT filter F₁, F₂, F₃, etc. For example, syn_tcp_actif (packet) could be translated into the SNORT filter flow: (…, Flow:Established,…). The final body of the SNORT rule is: (F1, F2,…). Finally, the signature is sent to the client to feed their signature base.

Aleph (A Learning Engine for Proposing Hypotheses) (Srinivasan 2000) was used as ILP engine to realize this solution. This approach was shown to be very effective in DoS attacks. The main advantage of this solution is that the complex task of writing the signature based on network logs can now be accomplished by the cloud service.

This approach is of great interest for the design of SDN-based networks, which already integrates the principle of delocalization of network intelligence in a logically centralized controller. The next section presents the proposals on the architectural plane to enable the deployment of such services in SDN-based networks.

2.7.2. Deployment of an intrusion prevention service in SDN-based networks

One of the first challenges encountered when deploying an IDS architecture that learns the signatures on-the-fly and deploys them is the acceptable response time. The language filter systems of IDS are traditionally much richer than Southbound API in SDN networks. It is therefore a challenge to implement an intrusion prevention system (IPS) with an acceptable response time.

The objective of the proposed architecture is to provide a self-managed IPS for SDN networks. The IPS enables the extension of the security functions from one SDN controller through a P4 interface (Bosshart et al. 2014) because of AI. In fact, the controller’s task is to transfer the retransmission rules or ACL (Access Lists) to switches supporting OpenFLow inside the network. Nevertheless, it is not designed to analyze and detect the attacks inside the network. IDS and IPS are the tools dedicated to this task. The implementation of these tools is a real challenge, given the large amount of data circulating in the SDN domain and the performance constraints related to virtualization. This architecture approaches this challenge by means of three operating blocks: a signature-based intrusion detection and prevention system, a system for on-the-fly learning of attack signatures based on ILP and deep learning, and a P4 interface enabling the deployment of new detection rules in the network.

The system (Figure 2.10) operates as a processing chain that is self-optimizing with the occasional intervention of the administrator as oracle when needed. The data plane has a classical role in this architecture; on the other hand, the control plane demonstrates more intelligent activity through the knowledge plane.

In SDN-based networks, the knowledge plane manages the whole knowledge in order to improve/optimize the controller operation to ensure the security functions (policy optimization, intrusion prevention, detection of malicious operation of a switch, etc.), routing (route optimization, self-healing of disappeared routes, prediction of load distribution, etc.) and QoS.

The knowledge plane makes it possible to have a local intelligent loop for the management of a signature-based IPS service. The loop is described in Figure 2.11. In this loop, there are two learning tools with connected roles:

• – the main learning tool relies on ILP. ILP makes it possible to learn a hypothesis from examples of malicious packets as indicated in Hamdi et al. (2015);
• – the deep learning module that, based on examples of a reference dataset such as NSL-KDD, builds a BK that makes it possible to consider only those concepts that are relevant for learning an attack:

[2.1]

where Δ is the deep learning function that takes as parameter a dataset (such as NLS_KDD) and positive examples of the attack. The output of this function must be the set of p properties that are relevant for BK. Relevance is represented by the function Π(p, D_set) > 0. This formula expresses the fact that the system will use a training base to determine the fields of parameters that are potentially relevant to appear in the attack signature. Indeed, the BK of ILP module generally contains predicates that can be used to describe the attack. The choice of BK content is crucial for having the most accurate possible rules. To add bias to BK design, we use deep learning in order to determine for each attack the properties that are most susceptible to appear in BK. The deep learning module uses the bases of training traces, in our case NSL-KDD, to optimize the BK content. This optimization involves mainly the reduction of the size that enables the upstream filtering of the most relevant parameters for an attack description, and therefore the reduction of the research space of the ILP engine.

A P4 interface makes it possible to transform the filters and actions of the intrusion detection system into programs that can be deployed in programmable switches.

The intrusion detection service presented in this section is deployed by means of a single SDN controller. To allow for scalability, we recommend the existence of physically distributed but logically centralized controllers, as well as a flat model, a solution that seems to be widely accepted at present. For exchanges between controllers in order to maintain the global view, and in the absence of standardized Eastbound/Westbound API, the Pub/Sub approach should also be retained, as it makes it possible to keep a controller informed only during a change of state.