HAL Id: tel-02884297
https://hal.archives-ouvertes.fr/tel-02884297
Submitted on 29 Jun 2020
HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci- entific research documents, whether they are pub- lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.
Gestion dynamique et evolutive de règles de securite pour l’Internet des Objets
Salim Mahamat Charfadine
To cite this version:
Salim Mahamat Charfadine. Gestion dynamique et evolutive de règles de securite pour l’Internet des
Objets. Informatique [cs]. Université de Reims Champagne-Ardenne, 2019. Français. �tel-02884297�
UNIVERSITÉ DE REIMS CHAMPAGNE-ARDENNE
ÉCOLE DOCTORALE SCIENCES DU NUMÉRIQUE ET DE L’INGÉNIEUR
THÈSE
Pour obtenir le grade de
DOCTEUR DE L’UNIVERSITÉ DE REIMS CHAMPAGNE-ARDENNE
Discipline : INFORMATIQUE
Spécialité : Réseaux et Télécommunications
Présentée et soutenue publiquement par
MAHAMAT CHARFADINE SALIM
Le 2 juillet 2019
Gestion dynamique et évolutive de règles de sécurité pour l’Internet des Objets
Thèse dirigée par OLIVIER FLAUZAC ET FLORENT NOLOT
JURY
M. Hacène FOUCHAL, Professeur, Université de Reims Champagne-Ardenne, Président M. Olivier FLAUZAC, Professeur, Université de Reims Champagne-Ardenne, Directeur de thèse M. Florent NOLOT, Maître de Conférences HDR, Université de Reims Champagne-Ardenne, Co-Directeur de thèse M. Ibrahima NIANG, Professeur, Université Cheikh Anta Diop, Dakar, Sénégal, Rapporteur
M. Antoine GALLAIS, Maître de Conférences HDR, Université de Strasbourg, Rapporteur
Mme Manuele KIRSCH PINHEIRO, Maître de Conférences , Université Paris 1 Panthéon-Sorbonne, Examinateur
“ ` A la m´ emoire de ma m` ere ”
Remerciements
A ` Olivier FLAUZAC, Professeur des Universit´ es et Florent NOLOT, Maˆıtre de Conf´ erences et HDR, pour leur encadrement, leurs pr´ ecieux conseils ainsi que leur soutien moral tout au long de mes recherches.
Aux membres du jury de m’avoir fait l’honneur de bien vouloir accepter d’´ evaluer mes travaux.
A ` Cyril RABAT, Maˆıtre de Conf´ erences, pour nos nombreux ´ echanges, ses pertinents conseils et orientations durant mes travaux.
A Fr´ ` ed´ erique RABAT pour sa bienveillante relecture.
A ` Ida Lenclume, secr´ etaire du CReSTIC, pour sa disponibilit´ e et toute l’aide qu’elle m’a apport´ ee durant ces ann´ ees de th` ese.
Aux membres de l’´ equipe CASH et du CReSTIC pour ces moments d’´ echanges et de par- tage.
A ` Carlos GONZALES et ` a mes amis doctorants Abdel-nassir MAHAMAT NASSOUR, Livinus TUYISENGE et Erick GALLEGOS, pour leur aide, conseils pertinents et ces moments de collaboration plein de bonne humeur.
Au personnel de l’Universit´ e de Reims Champagne-Ardenne dans son ensemble et ` a tous ceux qui ont particip´ e de fa¸con directe ou indirecte au bon d´ eroulement de cette th` ese.
A ma famille et ` ` a mes amis, pour leur pr´ esence en toutes circonstances.
Table des mati` eres
Table des mati` eres vii
Liste des figures xi
Liste des tableaux xiii
Introduction 1
Contribution de la th` ese . . . . 2
Organisation de la th` ese . . . . 3
Liste des publications 5 Conf´ erences Internationales . . . . 5
Posters . . . . 5
I Etat de l’art des nouvelles architectures r´ eseaux 7 1 Le Software Defined Networking (SDN) 9 1.1 Introduction . . . . 9
1.2 Le concept du SDN . . . . 11
1.3 Diff´ erence entre un r´ eseau SDN et un r´ eseau traditionnel . . . . 12
1.4 Architecture . . . . 13
1.4.1 La couche infrastructure . . . . 13
1.4.2 La couche de contrˆ ole . . . . 16
1.4.3 La couche application . . . . 19
1.5 Les interfaces de programmation du SDN . . . . 20
1.5.1 La Southbound API . . . . 20
1.5.2 La Northbound API . . . . 25
1.5.3 La East-Westbound API . . . . 26
URCA Table des mati` eres
1.6 Conclusion . . . . 27
2 L’Internet des Objets 29 2.1 Introduction . . . . 29
2.2 Les enjeux de l’IoT . . . . 30
2.3 Architecture de l’IoT . . . . 31
2.3.1 La couche perception . . . . 32
2.3.2 La couche r´ eseau . . . . 33
2.3.3 La couche application . . . . 33
2.4 Les protocoles de l’IoT . . . . 34
2.5 Les architectures SDN pour l’IoT . . . . 35
2.6 Conclusion . . . . 37
3 La s´ ecurit´ e des r´ eseaux avec le SDN 39 3.1 Introduction . . . . 39
3.2 M´ ecanismes de s´ ecurit´ e des r´ eseaux traditionnels . . . . 40
3.2.1 Protection par firewall . . . . 40
3.2.2 Protection par IDS/IPS . . . . 41
3.2.3 Protection par Network Access Control (NAC) . . . . 42
3.3 Avantages du SDN par rapport aux r´ eseaux traditionnels . . . . 43
3.4 D´ efis de s´ ecurit´ e des architectures SDN . . . . 44
3.5 Historique de la s´ ecurit´ e des r´ eseaux programmables . . . . 44
3.6 Analyse des menaces de s´ ecurit´ e du SDN . . . . 45
3.7 Solutions de s´ ecurit´ e pour les diff´ erentes couches du SDN . . . . 50
3.7.1 Solutions de s´ ecurit´ e pour la couche infrastructure . . . . 50
3.7.2 Solutions de s´ ecurit´ e pour la couche de contrˆ ole . . . . 52
3.7.3 Solutions de s´ ecurit´ e pour la couche application . . . . 54
3.7.4 Conclusion . . . . 55
II Nouvelles architectures de s´ ecurit´ e pour les r´ eseaux du futur 57 4 Gestion intelligente de la s´ ecurit´ e dans un r´ eseau avec le SDN 59 4.1 Introduction . . . . 59
4.2 Approches existantes de s´ ecurit´ e avec le SDN . . . . 60
4.3 Gestion intelligente de la s´ ecurit´ e avec le SDN . . . . 61
4.3.1 Gestion imp´ erative des politiques de s´ ecurit´ e avec OpenFlow . . . . 62
4.3.2 Gestion d´ eclarative des politiques de s´ ecurit´ e avec OpFlex . . . . 62
Table des mati` eres URCA
4.3.3 Notre solution de firewall Intelligent . . . . 63
4.3.4 Conclusion . . . . 69
5 Gestion automatis´ ee du r´ eseau en fonction des vuln´ erabilit´ es d´ etect´ ees 71 5.1 Introduction . . . . 71
5.2 S´ ecurit´ e IoT et SDN . . . . 72
5.3 Architecture de gestion distribu´ ee et collaborative de s´ ecurit´ e dans un r´ eseau . . 73
5.3.1 Collecte des donn´ ees du r´ eseau . . . . 75
5.3.2 Analyse, d´ etection et g´ en´ eration des alertes . . . . 76
5.3.3 Suppression des flux malveillants . . . . 76
5.4 Conclusion . . . . 77
6 Impl´ ementation 79 6.1 Introduction . . . . 79
6.2 Les outils utilis´ es . . . . 80
6.2.1 Le contrˆ oleur OpenDaylight . . . . 80
6.2.2 Open vSwitch (OVS) . . . . 82
6.2.3 Cr´ eation des machines virtuelles . . . . 83
6.2.4 Surveillance de trafic et gestion de flux malveillants . . . . 83
6.3 M´ ecanisme d’´ echanges de flux dans un r´ eseau . . . . 85
6.3.1 M´ ecanisme d’´ echanges dans un r´ eseau traditionnel . . . . 86
6.3.2 M´ ecanisme d’´ echanges dans un r´ eseau SDN . . . . 87
6.3.3 D´ ecouverte de topologie dans un r´ eseau SDN . . . . 88
6.4 Impl´ ementation . . . . 90
6.4.1 Installation d’OpenDaylight . . . . 90
6.4.2 R´ ealisation de l’architecture . . . . 93
6.4.3 S´ ecurisation du lien entre le contrˆ oleur OpenDaylight et l’OVS . . . . 93
6.4.4 Mise en place de Snort . . . . 95
6.4.5 Liaison de Snort avec OpenDaylight . . . . 96
6.4.6 Analyse, d´ etection et suppression de flux . . . . 96
6.5 Quelques exemples d’attaques simul´ ees . . . 100
6.5.1 D´ eni de services . . . 100
6.5.2 Scan de ports . . . 100
6.5.3 Usurpation d’adresse IP ou MAC . . . 100
6.6 Conclusion . . . 101
URCA Table des mati` eres
Conclusion et perspectives 103
Conclusion . . . 103 Perspectives . . . 104
Liste des acronymes 105
Bibliographie 107
Table des figures
1.1 Processus d’encapsulation et de d´ esencapsulation du mod` ele OSI . . . . 10
1.2 Comparaison entre un r´ eseau traditionnel et un r´ eseau SDN . . . . 12
1.3 Architecture d´ etaill´ ee d’un r´ eseau SDN [1] . . . . 13
1.4 Architecture d’un commutateur OpenFlow . . . . 15
1.5 Diagramme de traitement d’un paquet dans un commutateur OpenFlow . . . . . 16
1.6 Architecture du contrˆ oleur OpenDaylight (version Beryllium) . . . . 19
1.7 Echanges des messages OpenFlow entre le contrˆ ´ oleur et le commutateur . . . . 22
1.8 Architecture OpFlex [2] . . . . 24
2.1 Comparaison entre le mod` ele TCP/IP et l’architecture IoT de l’IETF[3]. . . . . 32
2.2 Architecture pour l’Internet des Objets [4]. . . . 32
3.1 Exemple d’un r´ eseau prot´ eg´ e par un firewall . . . . 41
3.2 Analyse des vuln´ erabilit´ es du SDN . . . . 46
4.1 S´ ecurit´ e r´ eseau avec SDN utilisant le protocole OpFlex . . . . 64
4.2 M´ ecanisme d’´ echanges de flux dans un r´ eseau OpenFlow . . . . 65
4.3 Diagramme d’´ echanges OpenFlow . . . . 66
4.4 Principe de fonctionnement du protocole OpFlex . . . . 67
4.5 Diagramme d’´ echanges lors de l’ex´ ecution du firewall . . . . 68
4.6 Exemple d’enregistrement d’un Endpoint . . . . 69
5.1 Architecture distribu´ ee et collaborative de s´ ecurisation d’un r´ eseau avec du SDN 74 5.2 Approche th´ eorique de la solution . . . . 75
5.3 Int´ egration d’un port mirroring dans le contexte SDN . . . . 76
6.1 Architecture simplifi´ ee d’une plateforme OpenDaylight . . . . 81
6.2 Sch´ ema th´ eorique d’une plateforme OpenDaylight pour la programmation r´ eseau 82
6.3 Sch´ ema de l’architecture Snort . . . . 85
URCA Table des figures
6.4 Echanges de flux dans un r´ ´ eseau en IPv4 . . . . 86
6.5 M´ ecanisme d’´ echanges de flux dans un r´ eseau OpenFlow . . . . 87
6.6 Messages OpenFlow ´ echang´ es entre le contrˆ oleur SDN et l’OVS . . . . 88
6.7 Structure d’un LLDPDU . . . . 89
6.8 D´ ecouverte des liens avec OFDP . . . . 89
6.9 Maquette de mise en oeuvre de s´ ecurisation d’un r´ eseau avec du SDN . . . . 90
6.10 Ecran de lancement OpenDaylight . . . . 91
6.11 Interface graphique d’OpenDaylight Beryllium-SR4 . . . . 92
6.12 Inventaire des noeuds sur l’interface graphique d’OpenDaylight Beryllium-SR4 . 92 6.13 Fichier de configuration OpenFlow pour supporter TLS . . . . 94
6.14 Ecran d’affichage de flux install´ es sur l’OVS . . . . 98
6.15 R´ esultats de l’´ ecran d’ex´ ecution d’alerte et de d´ esinstallation automatis´ ee de flux malveillants . . . . 98
6.16 Ecran d’ex´ ecution de l’algorithme . . . . 99
Liste des tableaux
1.1 Exemple des commutateurs OpenFlow disponibles sur le march´ e . . . . 14
1.2 Champs de correspondance OpenFlow . . . . 15
1.3 Quelques types de contrˆ oleurs et leurs caract´ eristiques . . . . 18
1.4 Fonctionnalit´ es des diff´ erentes sp´ ecifications d’OpenFlow . . . . 21
2.1 Technologies de Communications pour l’Internet des Objets [5] . . . . 34
3.1 Quelques types de menaces de s´ ecurit´ e du SDN [6] . . . . 50
Introduction
Les r´ eseaux permettent de communiquer, de collaborer et d’interagir de plusieurs mani` eres.
Ils sont utilis´ es pour acc´ eder aux pages web, pour participer ` a des ´ echanges vid´ eo, pour acheter sur Internet, pour suivre des formations sur Internet et bien plus encore avec les terminaux mobiles et les objets connect´ es.
En 2030, il est annonc´ e plus de 500 milliards
1d’´ equipements connect´ es ` a Internet avec une vari´ et´ e d’usage entraˆınant des probl` emes de s´ ecurit´ e et une augmentation du trafic sur les r´ eseaux qui sera estim´ ee en Zeta(10
21) octets. Or, actuellement, les architectures de s´ ecurit´ e d´ eploy´ ees dans les r´ eseaux sont principalement issues de l’exp´ erience et des travaux sur les r´ eseaux filaires. Ces architectures sont principalement bas´ ees sur des ´ equipements centralis´ es, dont le rˆ ole principal est de contrˆ oler les informations qui sont ´ echang´ ees entre le r´ eseau de l’en- treprise et l’ext´ erieur. Il n’est donc pas possible de contrˆ oler les informations ´ echang´ ees entre un ´ equipement terminal qu’un utilisateur va venir connecter sur son ordinateur. L’exemple du t´ el´ ephone est un des cas les plus probl´ ematiques. Sur un r´ eseau d’entreprise, les utilisateurs peuvent connecter leur t´ el´ ephone sur leur ordinateur, via du Bluetooth par exemple et ainsi, l’ordinateur devient une nouvelle porte d’entr´ ee sur le r´ eseau. Avec l’Internet des Objets ou Internet of Things (IoT), nous avons des capteurs, des thermostats, des webcams, des montres connect´ ees ` a nos t´ el´ ephones, eux-mˆ emes ´ eventuellement connect´ es ` a Internet ou ` a nos ordi- nateurs. Comment pouvons-nous donc effectuer le contrˆ ole des informations qui proviennent de cette grande masse d’´ equipements h´ et´ erog` enes ? Avec l’augmentation du nombre de ces
´
equipements h´ et´ erog` enes, la complexit´ e dans leur administration devient croissante. Ce qui n´ ecessite une v´ erification de la coh´ erence des configurations de tous les ´ equipements r´ eseaux d’une entreprise, par exemple les r` egles de s´ ecurit´ e et les droits utilisateurs.
Depuis ces derni` eres ann´ ees, il se d´ eveloppe un nouveau concept de gestion de r´ eseau appel´ e Software Defined Networking (SDN)
2. Son objectif principal est de simplifier la gestion et la
1. https://www.cisco.com/c/dam/en/us/products/collateral/se/internet-of-things/
at-a-glance-c45-731471.pdf(Online : accessed on 04/09/2018)
2. https://www.opennetworking.org/sdn-definition/(Online : accessed on 04/09/2018)
URCA Liste des tableaux
configuration des r´ eseaux et de faciliter l’innovation. Son principe est la s´ eparation du plan de contrˆ ole des ´ equipements r´ eseaux (commutateurs, routeurs...) du plan de donn´ ees et le placer vers un point de contrˆ ole centralis´ e. Appel´ e contrˆ oleur SDN, ce point de contrˆ ole centralis´ e permet de programmer les ´ equipements r´ eseaux ` a travers des interfaces programmables. Il permet ´ egalement d’avoir une vue globale du r´ eseau. Avec le SDN, les administrateurs r´ eseaux n’ont plus ` a configurer chaque ´ equipement s´ epar´ ement comme dans les r´ eseaux traditionnels o` u le risque d’erreur est ´ elev´ e.
Du point de vue s´ ecurit´ e, le SDN permet de programmer des politiques de s´ ecurit´ e et de pousser sur les ´ equipements r´ eseaux grˆ ace au contrˆ oleur SDN. Le SDN pr´ esente aussi des avantages multiples, entre autres : la programmabilit´ e, l’´ evolutivit´ e, la flexibilit´ e, la scalabilit´ e, la r´ eduction des coˆ uts d’investissement et d’exploitation des r´ eseaux, mais soul` eve ´ egalement des pr´ eoccupations li´ ees ` a la centralisation du contrˆ ole sur un ´ equipement unique, qui devient un point critique et l’introduction des nouvelles interfaces vuln´ erables aux attaques.
Dans le cadre de ce travail de th` ese, notre objectif est d’´ etudier et de r´ ealiser de nouvelles solutions de s´ ecurit´ e des ´ echanges dans un r´ eseau en exploitant le concept du SDN.
Contribution de la th` ese
Nos contributions dans ce projet de recherche sont la conception et la mise en oeuvre d’un nouveau type d’architecture de s´ ecurisation des ´ echanges dans un r´ eseau exploitant le concept du SDN. Ce nouveau paradigme de gestion des r´ eseaux, nous a permis de proposer une architecture de gestion centralis´ ee, distribu´ ee et collaborative de la s´ ecurit´ e grˆ ace ` a son contrˆ oleur. L’avantage du contrˆ oleur SDN est qu’il permet, non seulement d’avoir une vue globale du r´ eseau, mais aussi de programmer les politiques de s´ ecurit´ e sur les ´ equipements. Ce qui fait que notre solution est programmable, ´ evolutive et adapt´ ee aux r´ eseaux IoT.
Apr` es une ´ etude des architectures des solutions de s´ ecurit´ e avec le SDN, nous avons propos´ e notre solution globale de s´ ecurisation des ´ echanges bas´ ee sur le SDN, combin´ ee ` a un syst` eme d’analyse pour d´ etecter et isoler une menace en cas de besoin. Notre travail, qui vient compl´ eter la limitation des techniques existantes bas´ ees sur les firewalls et les IDS pour s´ ecuriser un r´ eseau traditionnel, sera ´ etendu aux objets connect´ es.
Nos exp´ erimentations ont ´ et´ e faites en environnement virtuel. Ce qui nous a permis de simuler des r´ eseaux SDN et de tester nos solutions de s´ ecurit´ e. Nous avons mis en oeuvre plusieurs sc´ enarios d’attaques comme du d´ eni de service (DoS) ou des scans de port. Cette solution est ´ evolutive et adaptable.
Les r´ esultats obtenus pr´ esentent une simplification de la gestion des r´ eseaux et de leur
s´ ecurit´ e, mˆ eme en cas d’augmentation de leur taille. Grˆ ace ` a nos tests de mise en oeuvre
Liste des tableaux URCA
d’un r´ eseau SDN et l’impl´ ementation des politiques de s´ ecurit´ e, nous pouvons dire que des perspectives s’ouvrent pour s´ ecuriser les objets connect´ es.
Nos simulations nous permettront ` a l’avenir de tester et de valider des solutions sur des r´ eseaux de grandes tailles.
Organisation de la th` ese
Notre travail de th` ese est structur´ e de la mani` ere suivante :
— Le premier chapitre pr´ esente un aper¸cu du concept de SDN. Ce chapitre introduit la d´ efinition du SDN, puis une pr´ esentation de son architecture, de ses protocoles, de son d´ eploiement et d’autres services r´ eseaux qui le caract´ erisent. Ce nouveau concept d’archi- tecture r´ eseau propose une architecture centralis´ ee et programmable des r´ eseaux grˆ ace ` a son protocole OpenFlow que nous allons d´ etailler dans ce chapitre.
— Le deuxi` eme chapitre d´ ecrit les g´ en´ eralit´ es sur la notion de l’IoT. Ensuite, nous pr´ esenterons les protocoles utilis´ es dans l’IoT et leur interconnexion.
— Nous proposerons dans le troisi` eme chapitre un ´ etat de l’art sur la s´ ecurit´ e des r´ eseaux utilisant le concept du SDN. Il s’agit de faire une ´ etude sur les solutions existantes de s´ ecurisation des ´ echanges dans un r´ eseau afin de connaˆıtre leurs performances et leurs limites. Ce qui nous permettra de proposer notre approche pour s´ ecuriser un r´ eseau en utilisant le concept du SDN ´ etendu ` a l’IoT.
— Au quatri` eme chapitre, nous allons pr´ esenter notre solution de gestion distribu´ ee de la s´ ecurit´ e dans un r´ eseau avec le paradigme SDN.
— Nous proposons au cinqui` eme chapitre une nouvelle solution de gestion automatis´ ee de la s´ ecurit´ e dans un r´ eseau en fonction des vuln´ erabilit´ es d´ etect´ ees.
— Le sixi` eme chapitre sera exclusivement consacr´ e ` a l’impl´ ementation de notre solution et ` a la discussion des r´ esultats obtenus lors des sc´ enarios des tests, pour d´ emontrer la faisabilit´ e et l’efficacit´ e de notre solution.
Nous concluons cette th` ese par des perspectives que nous avons identifi´ ees.
Liste des publications
Conf´ erences Internationales
1. C. GONZALES, S. MAHAMAT CHARFADINE, O. FLAUZAC, and F. NOLOT, SDN-based security framework for the IoT in distributed grid. In : The IEEE In- ternational Multidisciplinary Conference on Computer and Energy Science (SPLITECH) 2016, Split, Croatia.
2. S. MAHAMAT CHARFADINE, O. FLAUZAC, F. NOLOT, C.RABAT and C. GON- ZALES, Secure exchanges activity in function of event detection with the SDN.
In : 10th EAI International Conference on e-Infrastructure and e-Services for Developing Countries AFRICOMM 2018, Dakar , S´ en´ egal.
Posters
1. S. MAHAMAT CHARFADINE, O. FLAUZAC, F. NOLOT, Perspectives de s´ ecurit´ e pour l’Internet des Objets (IoT) : Journ´ ee des Doctorants du CReSTIC 2016 Reims, France.
2. S. MAHAMAT CHARFADINE, O. FLAUZAC, F. NOLOT S´ ecurisation des
´ echanges via du SDN, pour l’Internet des Objets (IoT). SDN DAY 2017 ` a l’IRT
SystemX PARIS, France.
Premi` ere partie
Etat de l’art des nouvelles
architectures r´ eseaux
Chapitre 1
Le Software Defined Networking (SDN)
R´ esum´ e : Dans ce chapitre, nous allons pr´ esenter le SDN, un nouveau concept ´ emergent d’architecture r´ eseau qui a introduit la programmabilit´ e des r´ eseaux et qui a fait ´ emerger des nouveaux protocoles tels que OpenFlow et OpFlex. Nous expliquerons en d´ etails le principe de fonctionnement du protocole OpenFlow pour comprendre le comportement des paquets dans un r´ eseau SDN, ainsi que les diff´ erents types de messages ´ echang´ es. Ensuite nous allons d´ ecrire le protocole OpFlex qui est aussi propos´ e pour d´ efinir et impl´ ementer des politiques de s´ ecurit´ e dans un r´ eseau bas´ e sur l’approche SDN.
1.1 Introduction
D’une mani` ere g´ en´ erale, un r´ eseau informatique est un ensemble d’´ equipements h´ et´ erog` enes (commutateurs, routeurs, ordinateurs etc.) interconnect´ es entre eux pour ´ echanger des infor- mations. Des mod` eles standards permettent aux diff´ erents ´ equipements du r´ eseau de s’´ echanger des informations. Les deux principaux mod` eles utilis´ es pour la planification et la mise en oeuvre des r´ eseaux sont : le mod` ele Open System Interconnexion (OSI) [7] et TCP/IP
1. Le mod` ele OSI est une norme de communication r´ eseau, d´ evelopp´ e par International Organisation for Standardization (ISO) en 1984, pr´ ecisant comment les ´ equipements doivent communiquer entre eux. Son architecture est compos´ ee de sept couches, ` a savoir de haut en bas : application, pr´ esentation, session, transport, r´ eseau, liaison de donn´ ees et physique. Les quatre premi` eres couches (1-4) sont des couches r´ eseau et servent, de service de communication aux couches ap- plicatives (5-7). Chaque couche est ind´ ependante des autres avec un rˆ ole sp´ ecifique ` a accomplir.
A titre d’exemple, lors de l’envoi de donn´ ` ees, on parcourt le mod` ele OSI de haut en bas comme l’indique la figure 1.1, en traversant toutes les couches.
1. https://tools.ietf.org/html/rfc1180(Online : accessed on 04/09/2018)
URCA 1.1. Introduction
Physique Liaison de
données Réseau Transport
Session Présentation
Application
Physique Liaison de
données Réseau Transport
Session Présentation
Application
données données
données
données
1001011100010101100101011
données données
données
En tête
trame En tête données réseau
En tête
Trame (Ethernet) En tête données Réseau (IP)
données En tête
réseau données En tête
Réseau (IP)
SEGMENTS
PAQUETS DONNEES
TRAMES
BITS
DESTINATION SOURCE
7
6
5
4
3
2
1 1
2 3 4 5 6 7
Encapsulation Desencapsulation
RESEAU
Figure 1.1 – Processus d’encapsulation et de d´ esencapsulation du mod` ele OSI
Le mod` ele TCP/IP est un mod` ele de communication en couches, similaire au mod` ele OSI, compos´ e de quatre couches : Application, Transport, Internet et Acc` es R´ eseau.
Ces r´ eseaux traditionnels sont devenus de plus en plus complexe ` a administrer et ` a s´ ecuriser [8] malgr´ e leur large adoption. C’est-` a-dire que les administrateurs des r´ eseaux passent beaucoup de temps ` a configurer manuellement les ´ equipements r´ eseaux ` a travers des lignes de commande.
En plus, ces ´ equipements r´ eseaux sont int´ egr´ es verticalement et tournent le plus souvent avec
des logiciels propri´ etaires [9]. Par exemple, dans un ´ equipement r´ eseau traditionnel, la partie
qui contrˆ ole le routage des paquets et la partie qui g` ere l’acheminement des paquets sont
ensemble sur un seul dispositif ce qui rend difficile son ´ evolution. Autrement, ce couplage limite
l’innovation puisque toute introduction d’un nouveau protocole ou service sur l’´ equipement
r´ eseau, passe obligatoirement par le fabricant et peut ˆ etre parfois tr` es long. C’est pour pallier
ces probl` emes de rigidit´ e architecturale, et bien d’autres encore, que le SDN a ´ et´ e introduit
depuis 2011.
1.2. Le concept du SDN URCA
1.2 Le concept du SDN
Le SDN est n´ e d’un large mouvement intellectuel, motiv´ e par la question du pourquoi les
´
equipements r´ eseaux ne devraient-ils pas ˆ etre programmables comme les autres plates-formes informatiques, et de la n´ ecessit´ e de r´ esoudre les probl` emes que l’on rencontre dans les r´ eseaux informatiques : difficult´ e ` a g´ erer et ` a faire ´ evoluer les r´ eseaux. Le terme SDN a ´ et´ e introduit pour la premi` ere fois par Martin Casado
2, de l’Universit´ e de Stanford en Californie. Il n’´ etait pas le seul ` a travailler sur le SDN mais il y avait aussi d’autres personnes comme Nick McKeown ou Scott Shenker qui font partie des gens souvent cit´ es dans le domaine du SDN. Autrement dit, le SDN est le r´ esultat des efforts de plusieurs chercheurs travaillant sur la probl´ ematique de l’architecture des r´ eseaux, visant ` a rendre les r´ eseaux programmables, flexibles, ´ evolutifs et innovants [10, 11].
Le SDN est un nouveau concept ´ emergent de gestion des r´ eseaux. C’est une nouvelle fa¸con de concevoir, de construire, d’exploiter et de s´ ecuriser les r´ eseaux. Il est bas´ e sur une gestion centralis´ ee des flux r´ eseaux par le d´ ecouplage du plan de contrˆ ole, responsable d’associer une d´ ecision de routage aux paquets du plan de donn´ ees repr´ esentant l’infrastructure physique ou virtuelle et qui s’occupe uniquement de l’acheminement des paquets rendant les r´ eseaux flexibles et programmables
3.
Avec le SDN, l’intelligence du r´ eseau est externalis´ ee et g´ er´ ee par un ´ equipement externe appel´ e ”contrˆ oleur” qui g` ere les fonctions du plan de contrˆ ole. Cette entit´ e intelligente qu’est le contrˆ oleur peut ˆ etre sur une ou plusieurs machines physiques ou virtuelles distribu´ ees. La configuration du r´ eseau reviendra ` a programmer le contrˆ oleur via des Application Programming Interface (API) ouvertes appel´ ees Northbound API. La communication entre le contrˆ oleur et les ´ equipements r´ eseaux se fait ` a travers le Southound API (par exemple OpenFlow) via un canal s´ ecuris´ e.
L’engouement des acteurs du num´ erique, tels que Google et Microsoft [12, 13] dans le d´ eploiement du SDN au niveau de leurs data center, donne des belles perspectives au concept du SDN qui commence ` a devenir une r´ ealit´ e.
En d’autres termes, l’objectif du SDN est de permettre aux r´ eseaux d’ˆ etre agiles, flexibles et programmables afin de rendre leur gestion simple. Ce concept de SDN est aujourd’hui glo- balement reconnu comme une architecture permettant d’ouvrir les r´ eseaux aux applications et offre beaucoup d’avantages [14].
2. https://en.wikipedia.org/wiki/Martin_Casado(Online : accessed on 04/09/2018)
3. https://www.opennetworking.org/sdn-definition/(Online : accessed on 04/09/2018)
URCA 1.3. Diff´ erence entre un r´ eseau SDN et un r´ eseau traditionnel
1.3 Diff´ erence entre un r´ eseau SDN et un r´ eseau tradi- tionnel
Le principe de fonctionnement des r´ eseaux actuels a ´ et´ e d´ efini dans les ann´ ees 50-60, par l’arm´ ee des ´ Etats-Unis dans le cadre d’un projet de recherche. L’objectif ´ etait de mettre en place un r´ eseau de communication r´ esilient. C’est ainsi que les chercheurs ont invent´ e le syst` eme d’ar- chitecture des r´ eseaux distribu´ es. Avec une architecture distribu´ ee, par exemple, les ´ equipements r´ eseaux tels que commutateurs ou routeurs sont actifs et capables de prendre une d´ ecision pour l’acheminement des paquets en cas d’indisponibilit´ e d’un de leurs voisins. Cette mani` ere de g´ erer les r´ eseaux est certes r´ esiliente mais avec le besoin d’int´ egrer des nouveaux services (s´ ecurit´ e, la qualit´ e de service...), la n´ ecessit´ e d’ajouter des ´ equipements tels que firewalls, IDS/IPS... pour assurer ces services s’est fait sentir. Ainsi, ` a chaque ajout d’un nouvel ´ equipement, l’architecture se complexifie et devient plus difficile ` a maintenir. De plus, avec cette approche traditionnelle de gestion des r´ eseaux, chaque ´ equipement doit ˆ etre configur´ e ind´ ependamment. Ce qui est non seulement lourd et fastidieux, mais induit aussi le risque de ne pas avoir l’uniformit´ e dans les configurations. D’o` u le SDN pour permettre la centralisation des configurations.
L’id´ ee du SDN a ´ et´ e de simplifier la gestion des r´ eseaux comme nous l’avions annonc´ e pr´ ec´ edemment et de quitter l’architecture distribu´ ee, pour revenir ` a un syst` eme de gestion centralis´ e du r´ eseau afin de g´ erer plus facilement les r´ eseaux. La figure 1.2 donne un aper¸cu sur la diff´ erence entre l’architecture traditionnelle et le SDN.
Contrôleur
Principe : Un contrôleur centralise la gestion des flux
Réseau traditionnel (Contrôle décentralisé)
Switch Borne Wifi
- Plan de données - Plan de contrôle
Réseau SDN (Contrôle centralisé)
Protocole OpenFlow
Principe: Plan de données et plan de contrôle gérés par un seul équipement
- Plan de données
- Plan de contrôle
Internet
Switch
Switch Switch
Internet
Switch
Switch Borne Wifi
Routeur Routeur
Lien physique Lien de contrôle
Figure 1.2 – Comparaison entre un r´ eseau traditionnel et un r´ eseau SDN
1.4. Architecture URCA
1.4 Architecture
Comme repr´ esent´ e sur la figure 1.3, l’architecture d’un r´ eseau SDN est divis´ ee en trois couches ` a savoir la couche infrastructure, la couche de contrˆ ole et la couche application [9, 1].
La communication entre ces diff´ erentes couches est faite ` a travers les Southbound, Northbound et East-Westbound APIs comme l’indique la figure 1.3. Dans cette partie, nous allons d´ etailler
´
etape par ´ etape ces diff´ erentes couches et APIs pour mieux expliquer l’architecture du SDN.
OpenDayLight, ONOS, POX...
Contrôleur
Supervision de Trafic/Sécurité
Contrôleur Contrôleur
Contrôle
d'accès Découverte de
topologie Gestion de la
mobilité
Commutateurs
virtuels Point d'accès
sans fil Commutateurs
Routeurs
Équipements réseau Applications
Westbound API Eastbound API
Northbound API
Southbound API
Figure 1.3 – Architecture d´ etaill´ ee d’un r´ eseau SDN [1]
1.4.1 La couche infrastructure
Cette couche d´ efinit la fonctionnalit´ e du plan de donn´ ees. Le plan de donn´ ees est constitu´ e des ´ equipements r´ eseaux tels que commutateurs, routeurs... incluant des composants d’achemi- nement des paquets et des APIs [10]. Un ´ equipement r´ eseau est une entit´ e qui re¸coit des paquets dans ses ports et r´ ealise une ou plusieurs fonctions r´ eseaux (par exemple un paquet re¸cu sur un port peut ˆ etre transf´ er´ e, supprim´ e ou son entˆ ete modifi´ ee pour une action sp´ ecifique).
D’une mani` ere g´ en´ erale, un commutateur est un ´ equipement r´ eseau qui a pour fonction le
transfert des paquets. Il est compos´ e de deux parties fonctionnelles : le plan de donn´ ees et le
URCA 1.4. Architecture
plan de contrˆ ole. Le plan de donn´ ees est responsable de l’acheminement des paquets de la source
`
a la destination. Il r´ ecup` ere les paquets de l’interface d’entr´ ee, puis consulte la table de routage pour d´ eterminer l’interface de sortie avant de transf´ erer les paquets. Le plan de contrˆ ole, quant
`
a lui, est charg´ e de la construction et du maintien de la table de routage. Avec les commutateurs classiques le plan de donn´ ees et le plan de contrˆ ole sont sur un mˆ eme ´ equipement.
Le SDN a introduit une s´ eparation entre le plan de donn´ ees et le plan de contrˆ ole. Le plan de donn´ ees est toujours g´ er´ e par le commutateur qu’on appelle commutateur OpenFlow. Il est con¸cu autour d’une interface de programmation ouverte et standard, qui lui permet d’assurer sa configuration et son interop´ erabilit´ e avec le plan de contrˆ ole et autres commutateurs SDN. Le plan de contrˆ ole qui g` ere les d´ ecisions de routage de haut niveau est externalis´ e vers un dispositif de contrˆ ole appel´ e Contrˆ oleur SDN que nous avons pr´ ec´ edemment ´ evoqu´ e. Le commutateur OpenFlow et le contrˆ oleur communiquent via le protocole OpenFlow que nous allons d´ etailler par la suite. Il y a deux types de commutateurs OpenFlow [15] : le commutateur OpenFlow Only qui supporte uniquement OpenFlow et le commutateur OpenFlow Enable qui joue en mˆ eme temps le rˆ ole de commutateur traditionnel et OpenFlow. Il y a sur le march´ e plusieurs marques de commutateurs OpenFlow comme l’indique le tableau 1.1.
Fabricant S´ erie
Arista Arista extensible modular operating system (EOS), Arista 7124FX application switch
Ciena Ciena Coredirector running firmware version 6.1.1 Cisco Cisco cat6k, catalyst 3750, 6500 series
Juniper Juniper MX-240, T-640
HP HP procurve series- 5400 zl, 8200 zl, 6200 yl, 3500 yl, 6600
NEC NEC IP8800
Pronto Pronto 3240, 3290 Toroki Toroki Lightswitch 4810 Dell Dell Z9000 and S4810
Quanta Quanta LB4G
Open vSwitch Software switch. Latest version : 2.6
Table 1.1 – Exemple des commutateurs OpenFlow disponibles sur le march´ e
Comme l’indique la figure 1.4, un commutateur OpenFlow est compos´ e des tables de flux en pipeline, une table de groupe et un canal s´ ecuris´ e pour l’´ echange avec le contrˆ oleur OpenFlow.
Le contrˆ oleur OpenFlow g` ere le commutateur OpenFlow ` a travers le protocole OpenFlow.
Une table de flux d’un commutateur OpenFlow est une liste de flux d’entr´ ees. Chaque flux
d’entr´ ees est compos´ e principalement : (1) d’un champ de correspondance dont le contrˆ oleur se
base pour faire correspondre les paquets, afin de v´ erifier le port d’entr´ ee ou l’entˆ ete du paquet
pour appliquer une action, (2) des instructions pour appliquer une liste d’actions sur les paquets
1.4. Architecture URCA
Contrôleur OpenFlow
Table de Flux 0
Canal OpenFlow
Table de Flux 1
Table de Flux n
Protocole OpenFlow
Table de Groupe
Pipeline OpenFlow
Port Port
Port Port
Figure 1.4 – Architecture d’un commutateur OpenFlow
et (3) des compteurs qui tiennent des statistiques sur le nombre de paquets trait´ es.
Le nombre des champs de correspondance support´ es par le protocole OpenFlow 1.3 est d´ etaill´ e sur le tableau 1.2. Ils sont au nombre de 14. Ce nombre varie en fonction des versions d’OpenFlow.
Field Description
OXM OF IN PORT Physical or logical port OXM OF ACTSET OUTPUT Egress port from action set OXM OF ETH DST Ethernet destination address OXM OF ETH SRC Ethernet source address
OXM OF ETH TYPE Ethernet type of the OpenFlow packet payload OXM OF IP PROTO IPv4 or IPv6 protocol number
OXM OF IPV4 SRC IPv4 source address OXM OF IPV4 DST IPv4 destination address OXM OF IPV6 SRC IPv6 source address OXM OF IPV6 DST IPv6 destination address
OXM OF TCP SRC TCP source port
OXM OF TCP DST TCP destination port
OXM OF UDP SRC UDP source port
OXM OF UDP DST UDP destination port
Table 1.2 – Champs de correspondance OpenFlow
Les actions appliqu´ ees par un commutateur OpenFlow sont similaires ` a celles d’un commu-
tateur traditionnel et sont : (1) transf´ erer un paquet vers un ou plusieurs ports de sortie, (2)
rejeter ou supprimer le paquet, (3) modifier les champs d’entˆ ete d’un paquet et (4) encapsu-
URCA 1.4. Architecture
ler un paquet et ensuite l’envoyer au contrˆ oleur SDN. Cette derni` ere action est sp´ ecifique aux commutateurs OpenFlow.
Quand un paquet arrive sur un port d’entr´ ee du commutateur OpenFlow, le processus de correspondance des paquets commence par la Table 0, premi` ere table du pipeline comme l’indique la figure 1.5 et peut continuer au cas o` u plusieurs tables de flux existent. La corres- pondance des paquets se fait par ordre de priorit´ e, si une correspondance est trouv´ ee, alors les instructions associ´ ees aux flux d’entr´ ees seront ex´ ecut´ ees. Si aucune correspondance n’est trouv´ ee, la suite du processus d´ ependra de la configuration par d´ efaut du commutateur. Trois cas de figure sont possibles ; le paquet peut ˆ etre envoy´ e au contrˆ oleur supprim´ e ou pass´ e ` a la table de flux suivante. En interne, un commutateur utilise une m´ emoire adressable de contenu ternaire, en anglais Ternary Content Addressable Memory (TCAM), et une m´ emoire d’acc` es al´ eatoire (Random Access Memory (RAM)) pour traiter les paquets.
Packet IN Début par la table 0
Mettre à jour les compteurs Exécution des instructions Mettre à jour l'ensemble des actions Mettre à jour le paquet 'champ de correspondance'
Mettre à jour la MetaData
Exécuter l'ensemble des actions
Abandonner le paquet Existe-t-il une entrée
''Table miss''
Table de Flow Vérifier la correspondance
Aller à la table de flow numéro n
Oui
Non Non
Non Oui
Oui
Figure 1.5 – Diagramme de traitement d’un paquet dans un commutateur OpenFlow
4
1.4.2 La couche de contrˆ ole
La couche de contrˆ ole de l’architecture SDN est constitu´ ee d’un contrˆ oleur logiciel appel´ e
contrˆ oleur SDN qui centralise toute l’intelligence du r´ eseau. Consid´ er´ e comme la composante
1.4. Architecture URCA
la plus importante du concept SDN, le contrˆ oleur SDN est un programme logiciel comparable
`
a un syst` eme d’exploitation r´ eseau, responsable de la manipulation de la table de flux d’un commutateur ` a travers le Southbound API. Autrement dit, le contrˆ oleur SDN a la charge de la gestion et de la configuration du r´ eseau en installant des r` egles d’acheminement des paquets, appropri´ ees sur les ´ equipements r´ eseaux (commutateurs, routeurs) de la couche infrastructure
`
a travers le Southbound API. Cette interface de programmation est tr` es importante car elle offre la possibilit´ e d’innovations pour les programmeurs et permet d’acc´ el´ erer le d´ eveloppement et l’impl´ ementation des services r´ eseaux [16]. OpenFlow est le Southbound le plus utilis´ e. Il permet au contrˆ oleur SDN d’ajouter, de modifier et de supprimer des entr´ ees dans la table de transfert d’un commutateur OpenFlow. Un canal s´ ecuris´ e relie le contrˆ oleur ` a un commutateur OpenFlow. Grˆ ace ` a ce canal qui sert d’interface de connexion, le contrˆ oleur g` ere les commu- tateurs OpenFlow, re¸coit des paquets des commutateurs OpenFlow et envoie des paquets aux commutateurs OpenFlow [17].
Il y a plusieurs types de contrˆ oleur logiciel dont les plus connus sont ONOS
5, OpenDay- light
6, POX
7, RYU
8, Floodlight
9et Beacon
10. Ils se distinguent par les langages de program- mation utilis´ es et le protocole support´ e. ` A titre d’exemple, et comme l’indique le tableau 1.3, le contrˆ oleur OpenDaylight exploit´ e dans le cadre de nos travaux est con¸cu en Java et en Python.
Le contrˆ oleur tient une vue globale du r´ eseau ` a travers son service de d´ ecouverte de topologie, tr` es important pour une exploitation correcte des autres services r´ eseaux du contrˆ oleur, comme la configuration r´ eseau par exemple. Certains contrˆ oleurs sont centralis´ es (Beacon, Floodlight) et d’autres distribu´ es (ONOS, OpenDaylight) et int` egrent des API suppl´ ementaires comme Eastbound et Westbound. Les contrˆ oleurs distribu´ es permettent de relever les limites sur l’usage d’un contrˆ oleur unique, qui peut non seulement devenir un point critique du point de vue de la s´ ecurit´ e, mais ne permet pas de g´ erer des larges r´ eseaux avec un nombre ´ elev´ e des ´ equipements r´ eseaux.
OpenDaylight est un contrˆ oleur SDN Open source modulaire qui permet de concr´ etiser la virtualisation des fonctions r´ eseaux ` a travers une d´ efinition coh´ erente de ses interfaces de programmation. Consid´ er´ e comme une r´ ef´ erence dans la programmabilit´ e des r´ eseaux, Open- Daylight permet ` a ses utilisateurs et ´ equipementiers de personnaliser leurs solutions de gestion des r´ eseaux selon leurs besoins.
Il y aussi des contrˆ oleurs SDN propri´ etaires tels que XNC (Extensible Network Controler)
5. http://www.onosproject.org(Online : accessed on 14/09/2018) 6. https://www.opendaylight.org/(Online : accessed on 14/09/2018)
7. https://openflow.stanford.edu/display/ONL/POX+Wiki(Online : accessed on 14/09/2018) 8. https://osrg.github.io/ryu/(Online : accessed on 14/09/2018)
9. http://www.projectfloodlight.org/floodlight/(Online : accessed on 14/09/2018)
10. http://www.beacon-project.eu/(Online : accessed on 14/09/2018)
URCA 1.4. Architecture Contrˆ oleur Langages de program-
mation
D´ evelopp´ e par Version Open- Flow sup- port´ ee
Open Source
NOX C++ Nicira 1.0 , 1.3 oui
POX Python Nicira 1.0 , 1.3 oui
Trema Ruby et C NEC 1.0 oui
Maestro Java Rice University 1.0 oui
Beacon Java Stanford University 1.0 oui
Floodlight Java Big Switch 1.0 , 1.3, 1.4 oui
Ryu Python NEC 1.0, 1.2, 1.3, 1.4,
1.5
oui
ONOS Java ON.Lab 1.0 oui
Helio C NTT 1.0, 1.3 non
OpenDaylight Java, Python ONF 1.0 , 1.3 oui
Node.Flow JavaScript DreamersLab 1.0 oui
HP VAN Controller Java, REST HP 1.0 , 1.3 non
Cisco XNC Java, Python, REST, C Cisco 1.0 , 1.3 non
Table 1.3 – Quelques types de contrˆ oleurs et leurs caract´ eristiques
d´ evelopp´ e par Cisco et compatible avec le protocole OpenFlow et OnePk (Cisco ONE Platform Kit).
Depuis son introduction, OpenDaylight a connu plusieurs versions dont chaque version ap- porte soit des correctifs, des nouveaux services ou le support des nouveaux protocoles. Open- Daylight est tr` es largement adopt´ e par les int´ egrateurs et par l’industrie des ´ equipements.
L’architecture de la plateforme OpenDaylight, repr´ esent´ ee sur la figure 1.6, est bas´ ee sur le Model-Driven Service Abstraction Layer (MD-SAL) o` u les ´ equipements r´ eseaux et les appli- cations sont repr´ esent´ es sous forme d’objets ou de mod` eles dont les interactions sont trait´ ees dans la couche d’abstraction appel´ ee Service Abstraction Layer (SAL). Le SAL est un ´ el´ ement tr` es important du contrˆ oleur OpenDaylight, permettant d’assurer le m´ ecanisme d’´ echange et d’adaptation de donn´ ees entres les mod` eles YANG
11, repr´ esentant les ´ equipements r´ eseaux et les applications. Il permet aussi de faciliter l’int´ egration d’une nouvelle Southbound API pour le d´ eveloppement des services sans lien avec les API utilis´ ees pour les impl´ ementer.
OpenDaylight est un framework modulaire et multi-protocoles. Cet aspect permet aux uti- lisateurs d’OpenDaylight de choisir et d’installer uniquement les services et protocoles adapt´ es
`
a leurs contextes. Cela permet aussi aux utilisateurs de r´ esoudre des probl` emes complexes en choisissant une combinaison des outils et protocoles qui les int´ eressent.
Du point de vue s´ ecurit´ e, OpenDaylight est con¸cu pour fournir l’authentification, l’auto- risation, la tra¸cabilit´ e ainsi que la d´ etection et la s´ ecurisation automatique des ´ equipements
11. https://tools.ietf.org/html/rfc7950(Online : accessed on 14/09/2018)
1.4. Architecture URCA
r´ eseaux.
Base Network Functions
OpenFlow Enabled Devices
Graphical User Interface Application and Toolkit (DLUX / NeXT UI)
Open vSwitches Additional Virtual &
Physical Devices
Controller Platform Services/Applications Host Tracker
OVSDB NET-
CONF PCMM/C
SNBI OPS LIS
P BGP PCEP SNM
SXP P Southbound Interfaces &
Protocol Plugins OpenFlow
L2 Switch
CAPWAP OPFLEX USC HTTP CoAP
OpenFlow Forwarding Rules Mgr OpenFlow Stats Manager OpenFlow Switch Manager Topology processing
OpenDaylight APIs REST/RESTCONF/NETCONF/AMQP
Service Abstraction Layer/Core
Data Store (Config & Operational) Messaging (Notifications / RPCs)
LACP Enhanced Network Services
AAA Centinel-Streaming Data Hdlr
Controller Shield Dev Discovery, ID & Drvr Mgmt
DOCSIS Abstraction
Messaging 4Transport NetIDE
OVSDB Neutron SDN Integration Aggregator
Service Function Chaining
Unified Secure Channel Mgr User Network Interface Mgr Virtual Private Network
Network Abstractions (Policy/Intent)
ALTO Protocol Manager Fabric as a Service Group Based Policy Service
NEMO Network Intent Composition Link Aggregation Ctl Protocol
LISP Service
Netron Northbound
SNMP4SDN Time Series Data Repository
Virtual Tenant Network Mgr
Data Plane Elements (Virtual Switches & Physical
Devices Interfaces) AAA AuthN Filter
AAA AuthN Filter
OF- Config
Figure 1.6 – Architecture du contrˆ oleur OpenDaylight (version Beryllium)
12
1.4.3 La couche application
Elle est la couche la plus haute de l’architecture SDN o` u les r` egles de gestion sont d´ efinies et impl´ ement´ ees. Ces r` egles sont un ensemble d’applications telles que IDS, firewalls, load balancing... con¸cues pour fournir un service sp´ ecifique au r´ eseau. Cette couche apporte l’auto- matisation des applications grˆ ace aux APIs et permet ´ egalement d’interagir et de manipuler le comportement des ´ equipements r´ eseaux ` a travers le contrˆ oleur SDN. Grˆ ace ` a la couche applica- tion, les applications b´ en´ eficient de la visibilit´ e des ressources r´ eseaux de mani` ere sp´ ecifique, par exemple pour la d´ ecouverte des liens ou de la topologie du r´ eseau, il est n´ ecessaire de faire un couplage entre les applications et les ´ equipements r´ eseaux sous-jacents tels que commutateurs et routeurs. C’est ainsi qu’en SDN, les fournisseurs des services et op´ erateurs pourront utiliser les applications pour la configuration, le contrˆ ole et la supervision de leur r´ eseau.
Dans l’approche SDN, le plan de contrˆ ole fournit une vue globale du r´ eseau et l’ensemble des informations sur les ´ el´ ements du r´ eseau aux applications via le southbound API du contrˆ oleur.
Comme nous l’avons d´ ej` a ´ evoqu´ e pr´ ec´ edemment, OpenFlow est l’API standard de facto pour
impl´ ementer les fonctions r´ eseaux sous la forme d’applications OpenFlow.
URCA 1.5. Les interfaces de programmation du SDN
Avec cette couche, du point de vue de la s´ ecurit´ e, divers services peuvent ˆ etre impl´ ement´ es au-dessus du contrˆ oleur OpenFlow en tant qu’applications de s´ ecurit´ e.
1.5 Les interfaces de programmation du SDN
Le SDN a introduit plusieurs types d’interfaces de programmation afin de permettre aux diff´ erents ´ el´ ements de son architecture SDN d’interagir entre eux [18]. Dans cette section, nous allons d´ etailler ces interfaces de programmation qui sont les Southbound API, les Northboud API et les East-Westbound API.
1.5.1 La Southbound API
L’interface entre la couche infrastructure et la couche de contrˆ ole est appel´ ee Southbound API. Cette API est la cl´ e du concept SDN car c’est elle qui permet concr` etement l’externali- sation du plan de contrˆ ole [1]. OpenFlow est la Southbound API le plus souvent utilis´ ee dans l’architecture SDN permettant la programmation du plan de donn´ ees. ` A travers cette inter- face, le contrˆ oleur g` ere l’ensemble des flux des commutateurs ou routeurs sous son autorit´ e.
Bien qu’OpenFlow est la Southbound API la plus utilis´ ee et mˆ eme le standard de facto, il y a aussi plusieurs autres Southbound API pour g´ erer les communications entre ces deux niveaux de l’architecture SDN, telles que Forwarding and Controle Element Separation (ForCES)
13et OpFlex
14que nous allons aussi aborder dans cette partie.
Protocole OpenFlow
OpenFlow est un protocole standardis´ e par Open Network Fundation (ONF)
15, un consor- tium industriel ` a but non lucratif de plusieurs membres, cr´ e´ e en 2011 qui travaille dans le d´ eveloppement du SDN. Il a ´ et´ e propos´ e pour faciliter la configuration des r´ eseaux, simplifier leurs gestions et virtualiser les r´ eseaux afin de d´ eployer plus facilement tous types de services (mobiles, s´ ecurit´ e...). OpenFlow est un bon moyen pour innover les r´ eseaux mais aussi faire face ` a plusieurs challenges notamment de s´ ecurit´ e. Il existe plusieurs versions (voir le tableau 1.4) de sp´ ecification d’OpenFlow dont la plus r´ ecente au moment o` u nous ´ ecrivons ces lignes est la version 1.5.
La communication entre le contrˆ oleur et le commutateur OpenFlow se fait ` a travers le protocole OpenFlow. Il traite la d´ efinition du format des messages ´ echang´ es entre le contrˆ oleur
13. https://tools.ietf.org/html/rfc5810(Online : accessed on 14/09/2018)
14. http://tools.ietf.org/pdf/draft-smith-opflex-00.pdf(Online : accessed on 14/09/2018)
15. https://www.opennetworking.org/sdn-resources/openflow(Online : accessed on 17/09/2018)
1.5. Les interfaces de programmation du SDN URCA Sp´ ecification OpenFlow 1.0 1.1 1.2 1.3
Large d´ eploiement oui non non oui
Nombre de table de flux Une Multiple Multiple Multiple
Matching MPLS non oui oui oui
Table de groupe non oui oui oui
Support IPv6 non non oui oui
Contrˆ oleur multiples non non oui oui
Table 1.4 – Fonctionnalit´ es des diff´ erentes sp´ ecifications d’OpenFlow
et le commutateur OpenFlow via le canal s´ ecuris´ e en SSL
16. Les messages doivent ˆ etre g´ en´ er´ es et compris par le contrˆ oleur et le commutateur SDN. Le protocole OpenFlow donne la possibilit´ e au contrˆ oleur de modifier, d’ajouter, de mettre ` a jour et de supprimer des flux d’entr´ ee dans la table de flux. Les messages entre le contrˆ oleur OpenFlow et le commutateur OpenFlow sont ´ echang´ es ` a travers le canal s´ ecuris´ e et impl´ ement´ es via une connexion SSL en TCP. C’est le commutateur qui initie la connexion SSL s’il connaˆıt l’adresse IP du contrˆ oleur. Tous les messages ´ echang´ es entre le contrˆ oleur et le commutateur commencent par une entˆ ete OpenFlow sp´ ecifiant la version du protocole OpenFlow avec un num´ ero, le type de message, la longueur et l’identificateur du message. Il y a trois types de messages :
Messages sym´ etriques : les messages HELLO , ECHO REQUEST, ECHO REPLY et VENDOR sont les principaux types de messages sym´ etriques ´ echang´ es entre le contrˆ oleur et le commutateur OpenFlow. Ils peuvent ˆ etre initi´ es par le contrˆ oleur ou le commutateur sans sollicitation. Apr` es l’´ etablissement du canal s´ ecuris´ e SSL avec TCP, les messages HELLO sont
´
echang´ es entre le commutateur et le contrˆ oleur pour d´ eterminer le num´ ero de la version du pro- tocole OpenFlow utilis´ e. Une fois le num´ ero ´ echang´ e, comme sp´ ecifie le protocole OpenFlow, la plus petite des deux versions doit ˆ etre utilis´ ee. Les messages ECHO (ECHO REQUEST et ECHO REPLY) sont aussi utilis´ es par le commutateur et le contrˆ oleur pendant leur fonctionne- ment, pour suivre si le lien est toujours actif et en mˆ eme temps v´ erifier le d´ ebit de la connexion et mesurer la latence.
Messages asynchrones : les messages asynchrones sont initi´ es par le commutateur sans aucune requˆ ete du contrˆ oleur. Ils sont utilis´ es pour informer le contrˆ oleur des arriv´ ees de pa- quets, des changements d’´ etat au commutateur et des erreurs.
PACKET IN est le type message utilis´ e par le commutateur pour envoyer des paquets au contrˆ oleur pour leur prise en charge. Ce type de message est envoy´ e, par exemple, lorsqu’aucune entr´ ee de flux du commutateur ne correspond au paquet entrant, ou lorsqu’il est sp´ ecifi´ e au niveau de l’action de l’entr´ ee correspondante que le paquet doit ˆ etre transf´ er´ e au contrˆ oleur.
D’une mani` ere g´ en´ erale le trafic du plan de contrˆ ole est relay´ e au contrˆ oleur via le message
16. Secure Socket Layer
URCA 1.5. Les interfaces de programmation du SDN
PACKET IN.
Le Message FLOW REMOVED permet au commutateur d’informer le contrˆ oleur en cas d’une suppression de flux d’entr´ ee de la table de flux. Le commutateur supprime un flux d’entr´ ee lorsqu’aucun paquet entrant n’a de correspondance avec cette entr´ ee pendant un temps d´ efini par le contrˆ oleur lors de la cr´ eation de ce flux d’entr´ ee dans la table de flux du commutateur.
PORT STATUS est le message qui permet au commutateur d’annoncer au contrˆ oleur tous changements de configuration ou d’´ etat du port.
Le message ERROR est utilis´ e pour notifier les erreurs au contrˆ oleur. Par exemple, ce message ERROR est envoy´ e au contrˆ oleur lorsque ce dernier tente d’ajouter une entr´ ee de flux contenant des actions non support´ ees par le commutateur.
Messages entre le contrˆ oleur et le commutateur : les messages OpenFlow ´ echang´ es entre le contrˆ oleur et le commutateur, d´ etaill´ es sur la figure 1.7, sont responsables de la d´ etection des fonctionnalit´ es, de la configuration, de la programmation du commutateur et de la r´ ecup´ eration d’informations. Ces messages sont, entre autres : switch configuration, com- mand from controller, statistics, queue configuration et barrier.
Contrôleur
OFPT_HELLO (V1.1)
OFPT_FEATURES_REPLY
Commutateur
Etstablish TCP Connection Etstablish SSL Tunnel
OFPT_HELLO (V1.3)
OFPT_FEATURES_REQUEST
OFPT_FLOW_MOD (ADD) OFPT_FLOW_MOD (ADD) OFPT_ECHO_REQUEST OFPT_ECHO_REPLY OFPT_PACKET_IN
OFPT_PACKET_OUT OFPT_FLOW_MOD (ADD)
OFPT_ECHO_REQUEST
Commutateur Contrôleur
OFPT_ECHO_REPLY OFPT_FLOW_MOD (MODIFY) OFPT_FLOW_REMOVED
OFPT_ECHO_REQUEST OFPT_ECHO_REPLY OFPT_PORT_STATUS OFPT_STATS_REQUEST OFPT_ECHO_REPLY
OFPT_STATS_REPLY OFPT_PACKET_IN OFPT_FLOW_MOD (ADD)
OFPT_PACKET_OUT
Figure 1.7 – ´ Echanges des messages OpenFlow entre le contrˆ oleur et le commutateur
Switch configuration : regroupe un message unidirectionnel et deux paires de messages
requˆ ete-r´ eponse. SET CONFIG est le message unidirectionnel envoy´ e par le contrˆ oleur au com-
1.5. Les interfaces de programmation du SDN URCA
mutateur pour charger les param` etres de configuration du commutateur. La paire de messages FEATURES REQUEST et FEATURES REPLY est utilis´ ee par le contrˆ oleur pour interroger le commutateur sur ses fonctionnalit´ es de base et optionnelles support´ ees. Pour obtenir la confi- guration du commutateur, le contrˆ oleur utilise GET CONFIG REQUEST
et GET CONFIG REPLY
Command from controller : PACKET OUT, FLOW MOD et PORT MOD sont les mes- sages de command from controller. PACKET OUT est utilis´ e par le contrˆ oleur pour envoyer des paquets de donn´ ees au commutateur pour leur acheminement via le plan de donn´ ees. Le message PORT MOD permet au contrˆ oleur de modifier l’´ etat d’un port d’un commutateur OpenFlow. FLOW MOD permet au contrˆ oleur de modifier les entr´ ees des flux existants dans le commutateur.
Statistics : pour recueillir les statistiques du commutateur par le contrˆ oleur, la paire de messages STATS REQUEST et STATS REPLY est utilis´ ee par ce dernier.
Queue configuration : la paire de messages QUEUE GET CONFIG REQUEST et
QUEUE GET CONFIG REPLY permet au contrˆ oleur d’interroger sur la configuration, pour apprendre la configuration des files d’attente et la fourniture aux paquets des informations de niveau de qualit´ e de service souhait´ e.
Barrier : BARRIER REQUEST est utilis´ e par le contrˆ oleur pour s’assurer que tous les messages envoy´ es avant ce message ont ´ et´ e r´ eceptionn´ es et trait´ es par le commutateur . BAR- RIER REPLY est le message de confirmation retourn´ e par le commutateur.
ForCES
ForCES est un protocole standard d´ efinit par Internet Engineering Task Force (IETF) depuis 2004 et qui propose de s´ eparer le contrˆ ole IP de l’acheminement des paquets dans les ´ equipements r´ eseaux. Dans cette approche, les dispositifs d’acheminement des paquets sont mod´ elis´ es ` a l’aide de blocs de fonctions logiques appel´ es Logical Fonction Blocks (LFB), pouvant ˆ
etre compos´ es de mani` ere modulaire pour former des m´ ecanismes de transmission complexes.
Chaque LFB fournit une fonctionnalit´ e telle que le routage IP. Les LFB mod´ elisent un dispositif de transfert et coop` erent pour former encore plus de p´ eriph´ eriques r´ eseaux complexes. Les
´
el´ ements de contrˆ ole utilisent le protocole ForCES pour configurer les LFB interconnect´ es,
pour modifier le comportement des dispositifs d’acheminement des paquets. ForCES n’est pas
adopt´ e par les acteurs des r´ eseaux en raison du manque de langage clair de communication
entre le contrˆ oleur et l’´ equipement r´ eseau.
URCA 1.5. Les interfaces de programmation du SDN
OpFlex
OpFlex
17est un protocole utilis´ e dans le concept SDN pour permettre ` a un Policy Reposi- tory (PR) d’´ echanger avec un Policy Element (PE) pour la r´ ealisation des actions abstraites.
Il int` egre un syst` eme d’´ echanges permettant ` a un noeud r´ eseau de fournir des informations essentielles au PR afin de l’assister ` a prendre des d´ ecisions. Standardis´ e par l’IETF, OpFlex est un protocole open source d´ evelopp´ e par Cisco. Il est con¸cu initialement pour permettre l’´ echange de donn´ ees d’objets dans le cadre d’un mod` ele informationnel.
Policy Repository
Observer
Endpoint
Registry
Policy
Element Endpoint
Declaration EP 2 EP 3 EP 1
EP 6 EP 5 EP 4 Groupe A Groupe B
Root
….
….
….
Group
Group
Root
….
….
Group Network
Hardware Policy
Resolution Endpoint
Request
State Report Deploy
Implicit Render (Subset)
Logical Model
Logical Model
Policy Update EP Policy
Update
