Les risques dOpenFlow et du SDN

Maxence Tury
maxence.tury@ssi.gouv.fr
ANSSI

Rsum Par opposition aux rseaux traditionnels, le paradigme

Software-Defined Networking prne une sparation des fonctions de rou-
tage et de celles de transfert de paquets. Lchange dinformation entre
ces deux plans passe par le dveloppement de nouveaux protocoles et
outils dont la scurit na t prouve que par encore peu dtudes. Ces
technologies suscitent beaucoup dintrt mais leur dploiement expose
les rseaux des risques mconnus. Cet article prsente les spcificits
du standard ouvert OpenFlow en mettant laccent sur certaines de ses
faiblesses. La mise en place dun cosystme SDN complet et les failles
observes au sein dimplmentations rcentes font lobjet de mises en
garde supplmentaires.

1 Introduction

1.1 Le paradigme Software-Defined Networking

Lindustrie des rseaux se dveloppe depuis une vingtaine dannes

sur la base dun modle o les routeurs assurent la fois le contrle de la
topologie du rseau (cest--dire laccomplissement des fonctions de rou-
tage) et le transfert des paquets. La gestion de la topologie saccompagne
souvent dune charge de calcul significative. Par exemple, le protocole de
routage OSPF exige de chaque routeur un travail important chaque fois
quune modification topologique du rseau lui est signale. Ce calcul est
en effet ncessaire pour appliquer lalgorithme de Dijkstra, qui permet de
dterminer les routes optimales vers les htes distants.
Un paradigme alternatif, cependant, attire actuellement lattention
dun nombre croissant dacteurs du march. Le SDN 1 se caractrise par la
sparation physique du plan de contrle et du plan de donnes, ainsi que
la centralisation des fonctions de contrle. Administration mise part, le
fonctionnement dun routeur traditionnel est reproduit grce deux types
doutil distincts. Un contrleur, dune part, est charg du calcul et de la
mise jour des tables de routage de plusieurs quipements, dautre part.
Ces dispositifs, que lon appellera abusivement switchs, sont responsables
1. Software-Defined Networking
2 Les risques dOpenFlow et du SDN

du transfert des paquets dune interface une autre en fonction des rgles
tablies par le contrleur. OpenFlow est une des solutions dveloppes
pour permettre la communication entre contrleurs et switchs.

Figure 1. Schma dun rseau SDN simple

Dans une approche SDN, la charge de calcul associe au contrle est

en grande partie retire des routeurs. La figure 1 illustre le routage dun
paquet entre deux rseaux distants via une implmentation de SDN avec le
protocole OpenFlow. Les routeurs discriminent les paquets et dterminent
leur interface de sortie, mais ce comportement dcoule de rgles mises
par le contrleur. Le routeur qui rceptionne le paquet de lenvoi (1)
signale lvnement au contrleur et reoit en retour des rgles au cours
dun change (2), afin de dcider du transfert (3) vers le routeur suivant
appropri. Ce comportement est dit ractif ; un comportement proactif
consisterait en la transmission de rgles avant que le routeur ne reoive les
paquets associs. Les routeurs effectuent ainsi essentiellement des fonctions
de commutationdo la dsignation de switchs OpenFlow .
Dans un souci de clarification, un seul contrleur figure sur le schma,
mais il est envisageable et conseill, principalement pour des questions de
M. Tury 3

rsilience, dintgrer au rseau dautres contrleurs qui pourront prendre

le relais en cas dincident.

1.2 Historique
Bien que des formulations des concepts sous-jacents puissent tre re-
tracs au dbut des annes 2000, la dsignation SDN est rcente, prcde
de peu par les premiers travaux sur OpenFlow en 2008 [9]. La version
1.0.0 des spcifications du protocole, destine la production, tait pu-
blie dbut 2010. Le pont avec lindustrie a rapidement t franchi, en
2011, avec la cration de lOpen Networking Foundation par Deutsche
Telekom, Facebook, Google, Microsoft, Verizon et Yahoo. LONF est lor-
ganisme principal encourageant ladoption des pratiques SDN, et encadre
lvolution du protocole OpenFlow.
En 2012, Google a prsent son installation pionnire : une architecture
SDN qui effectue dsormais le routage de leur backbone utilisateur ainsi
que de leur backbone interne, mise en place en deux ans [5]. Les premires
observations mettaient notamment en vidence lutilit de la centralisation
des mcanismes de contrle de bande passante, de perte de trames, ou
encore de diffrenciation dapplications. Le modle SDN aurait ainsi
facilit la gestion de la qualit de service, et permis une amlioration
de la tolrance aux incidents. Dautres groupes ont plus tard annonc
avoir implment OpenFlow, parmi lesquels Amazon, Microsoft ou encore
AT&T. Ladoption semble ce jour limite aux datacenters et aux WAN
les plus vastes. Malgr ces dploiements, trs peu de donnes quantitatives
sur les performances des installations SDN ont t rendues publiques.
La plupart des quipements rseau qui prennent en charge OpenFlow
sont aussi capables deffectuer du routage traditionnel, ce qui autorise
une transition progressive vers un dploiement SDN. NEC, HP ou encore
Brocade produisent ces switchs OpenFlow hybrides depuis 2011. Par
ailleurs, la communaut travaille sur la compatibilit de switchs virtuels
tels quOpen vSwitch, avec une forte contribution de VMware.
Il faut noter quOpenFlow nest pas lunique implmentation des
concepts SDN. Par exemple, le systme ONE de Cisco exploite le protocole
OpFlex et propose une approche intgre, depuis la couche matrielle
jusquaux interfaces dadministration.

1.3 tat de lart

Bien que certains dveloppeurs envisagent dj des solutions de d-
ploiement SDN des fins de consolidation de la scurit des rseaux, la
4 Les risques dOpenFlow et du SDN

scurit des implmentations en gnral et dOpenFlow en particulier font

encore lobjet de peu dtudes. Les publications OpenFlow Vulnerability
Assessment [3] et OpenFlow : A Security Analysis [6], proposent deffectuer
une analyse exhaustive des faiblesses du protocole. Les rsultats rapports
dans le prsent document mettent plus fortement laccent sur la faisabilit
des attaques et le rle des diffrentes implmentations, dans lesprit de
Floodlight DDoS Vulnerability [7] et A denial of service attack against the
Open Floodlight SDN controller [4], tudes dates de fin 2013.

2 Aperu du protocole OpenFlow : le traitement par flux

Les versions les plus couramment implmentes du protocole sur les

switchs OpenFlow actuels correspondent aux spcifications 1.0 et 1.3. Bien
quelles ne soient pas compatibles entre elles, la 1.3 peut tre envisage
dans sa globalit comme une extension de la 1.0. La description et les
tests qui suivent portent donc sur la 1.3, sauf mention contraire.
OpenFlow sert de lien entre le plan de contrle et le plan de donnes.
Lchange de messages se fait au cours dune session TCP tablie via le
port 6653 du serveur contrleur. Le comportement dun switch OpenFlow
est alors dtermin par une ou plusieurs tables de flux (flow table). Chaque
table sassimile un ensemble de flux, qui consistent chacun en une liste
de discriminants relatifs au contenu dune trame, associe des actions
de traitement appliquer aux trames correspondantes. Lorsquun paquet
parvient au switch, les valeurs contenues dans ses en-ttes sont compares
aux diffrents jeux de valeurs enregistrs dans la premire table de flux du
switch. Les actions qui peuvent suivre sont de diverses natures : transfert de
la trame par une interface, suppression, modification de champs den-ttes,
et/ou transmission du traitement une table de flux ultrieure.
Le regroupement des flux dfinit lintgralit des fonctions qui pourront
tre appliques aux paquets reus par le switch. Un flux par dfaut doit
tre dfini pour chaque table, explicitant le comportement adopter
lorsquune trame ne correspond aucun flux plus spcifique. Un cas
courant consiste envoyer au contrleur un message de type PACKET_IN.
Selon le paramtrage, celui-ci peut contenir lintgralit de la trame, un
nombre limit de ses octets (possiblement aucun) ou encore une rfrence de
mmoire tampon. Le contrleur rpondra gnralement par un PACKET_OUT
donnant linstruction suivre.
En mettant en relation une adresse de destination prcise, contenue
dans len-tte des paquets IP, avec une des interfaces en particulier, il
est possible dtablir une rgle de routage classique. Les spcifications
M. Tury 5

Figure 2. Schmatisation du modle par flux OpenFlow

prennent en charge plusieurs types de champs den-tte : adresses MAC,

EtherType, identifiants de VLAN, adresses IPv4 et IPv6, ports TCP et
UDP, labels MPLS, etc. La figure 2 illustre le traitement dune trame
parvenant un switch OpenFlow contenant une seule table de flux : parmi
les diffrents champs den-ttes de la trame, lappartenance au VLAN 10
la fait correspondre un des flux du switch, dont laction associe consiste
en un transfert par linterface 1.

des fins de disponibilit, un switch peut entretenir des sessions

OpenFlow avec diffrents contrleurs. Pour chacune des connexions, le
contrleur peut adopter un rle desclave ou de matre. Un esclave est
inform de certains changements de statut, par exemple de ltat des
interfaces, mais ne peut pas agir sur la configuration ; un matre possde
tous les droits (comme le rle par dfaut) mais il ne peut en exister quun
seul. Ce rle peut tre redfini auprs du switch tout moment.

Dans le cas o le switch nest plus en mesure de joindre aucun des

contrleurs auxquels il est li, deux comportements sont dfinis : le mode
fail secure, o toutes les actions denvoi de paquet au contrleur sont
ignores, mais les flux dj prsents persistent, ainsi que le mode fail
standalone, o les paquets sont tous traits avec les fonctions de routage
traditionnelles (si le switch est hybride).
6 Les risques dOpenFlow et du SDN

3 Faiblesses du protocole

3.1 Permabilit de la liaison contrleurswitch

Du point de vue de la scurit, une diffrence majeure du modle SDN

avec les installations traditionnelles est la centralisation du contrle. Le
contrleur est un point critique du rseau (dautant plus si aucun contrleur
auxiliaire na t dploy), et il doit tre lunique source des consignes
OpenFlow envoyes aux switchs. Si lenvoi de celles-ci a lieu sur le rseau
de production, ce qui nest pas dcourag par les spcifications, la scurit
de linstallation repose alors sur lauthentification des communications.
Cependant, la prise en charge de TLS exige pour OpenFlow 1.0 a t
rendue optionnelle partir dOpenFlow 1.1 : The OpenFlow channel is
usually encrypted using TLS, but may be run directly over TCP. [8]
Jusqu mi-2014, trs peu de switchs et aucun contrleur libre nassu-
raient ce service. Plusieurs implmentations TLS ont t publies depuis,
qui devront tre privilgies. En effet, en labsence de mcanisme dauthen-
tification, la centralisation au niveau du contrleur opre par OpenFlow
permet tout attaquant ayant gagn accs au rseau dadministration
dagir tout moment sur le paramtrage du switch et de configurer le
rseau de production comme souhait. Il est aussi envisageable pour un
attaquant de se placer en man-in-the-middle afin de filtrer les commandes
dun administrateur lgitime ainsi que les remontes dinformation des
switchs. Enfin, lcoute passive de messages OpenFlow non chiffrs permet
dobtenir de nombreux renseignements sur les rseaux maintenus par le
contrleur.
La protection dun switch OpenFlow passe donc par le cloisonne-
ment des rseaux dadministration et de production, ainsi que
lutilisation exclusive de TLS sur le rseau dadministration. Le
cloisonnement et lintgrit des communications sont des pratiques tablies
et disponibles sur des protocoles de routage historiques tels que BGP et
OSPF, et restent valables pour OpenFlow.

3.2 Risques de dni de service ct switch

Comme avec les switchs traditionnels, il est possible de provoquer un

DoS sur un switch OpenFlow en le soumettant un trafic soutenu. Un
switch incapable de traiter lensemble des paquets qui lui parviennent
en supprimera une partie, si ce nest lintgralit, parfois silencieusement
[9]. Bien que lattaque ne soit pas propre au protocole, il est important
de noter que plusieurs modles de switchs OpenFlow physiques traitent
M. Tury 7

certaines actions au niveau logiciel et non matriel : les dbits ncessaires

pour provoquer un dni de service seront alors bien moindres.
Une premire approche propre au protocole vise surcharger la m-
moire tampon du switch (sil en dispose) avec des paquets en attente dtre
envoys au contrleur. La mmoire pourrait saturer pour deux raisons
principales : la rception intensive de paquets envoyer au contrleur,
et labsence de rponse du contrleur aux PACKET_IN. Il nexiste pas de
message derreur signalant au contrleur cette saturation. Les spcifica-
tions ne permettent pas de vider la mmoire tampon du switch de faon
indpendante (par exemple en supprimant les trames non traites au bout
dun certain dlai), mais elles proposent si besoin de dsactiver lutilisa-
tion de la mmoire tamponau risque de transfrer trop de donnes et
de surcharger le contrleur. Par ailleurs, OpenFlow 1.0 exige lenvoi de
PACKET_IN pour chaque paquet ne correspondant aucun flux connu, mais
OpenFlow 1.3 permet ladministrateur de dfinir les actions appliquer
de tels paquets, notamment leur suppression.
En supposant la possibilit denvoyer des messages OpenFlow au contr-
leur, un attaquant pourrait aussi chercher surcharger une table de flux
dun switch. Dans le cas dune table pleine, la version 1.3 des spcifications
prvoit simplement denvoyer un message derreur un contrleur qui
tenterait dajouter une nouvelle rgle : si ladministrateur nintervient pas
pour supprimer certains flux, aucune nouvelle rgle ne sera accepte par
le switch. Seule la version suivante du protocole rpond ces problmes
avec les mcanismes dexpulsion et dalerte de taux doccupation dune
table. Reste tablir une politique dexpulsion approprie, et valuer pour
chaque switch le taux doccupation partir duquel les performances seront
notablement dgrades. Par ailleurs, les implmentations du protocole sur
certains switchs sont mises mal par une forte occupation des tables de
flux, comme prsent dans la section 4.3.

3.3 Risques de dni de service ct contrleur

Dans la mesure o les ressources en mmoire du contrleur sont suscep-
tibles dtre suprieures celles du switch de plusieurs ordres de grandeur,
surcharger la base de flux du contrleur est une mthode potentiellement
coteuse pour lattaquant. Ce modle dattaque prsuppose la possibilit
denregistrer des flux sur le contrleur.
Un risque plus important se prsente par rapport au systme de
matreesclaves. Sans mcanisme dauthentification, il est simple pour un
contrleur adverse dusurper le rle de matre, ou du moins dempcher
quun contrleur lgitime qui souhaite tre matre puisse paramtrer le
8 Les risques dOpenFlow et du SDN

switch. En effet, quand bien mme ce contrleur lgitime effectuerait

une requte de rle chaque fois quil serait averti de son passage au
statut desclave, il suffirait ladversaire dadopter exactement le mme
comportement pour empcher le contrleur lgitime deffectuer des actions
de configuration. Bien que les changements de droits ny soient toujours
pas restreints, la version 1.4 dfinit des messages davertissement quun
switch devra envoyer un esclave qui vient dtre dmis de son rle de
matre.

4 Implmentations sur le switch de test

Lexamen du protocole nest pas suffisant pour valuer la scurit dune
installation OpenFlow : il faut aussi en tudier les implmentations. Nous
avons donc choisi de mener plusieurs exprimentations sur des switchs de
test. La vise de cet article ntant pas dvaluer la qualit dun produit
mais de faire tat des enjeux de scurit actuels associs au protocole
OpenFlow, la marque des switchs utiliss nest pas rvle. Nous sommes
entrs en contact avec lquipementier concern pour lui prsenter nos
rsultats et rsoudre les problmes qui ntaient pas encore traits dans
les versions de firmware les plus rcentes.
Les premires observations ont t faites laide du firmware v1,
qui prend en charge la version 1.0 dOpenFlow, mais qui nassure pas
les fonctions dveloppes dans les versions ultrieures du protocole. Au
cours de ltude, un firmware v2 a t publi, ajoutant la prise en charge
dOpenFlow 1.3. La version utilise est prcise pour chaque test.
Le contrleur open source Floodlight a dabord t utilis pour envoyer
des messages OpenFlow aux switchs. Les commandes dadministration
passent dabord par lenvoi de requtes HTTP Floodlight, qui se charge
ensuite de lenvoi des messages OpenFlow. Cependant lAPI de Floodlight
ne couvre pas lcriture de tous les messages dfinis dans les spcifications,
et formate parfois les rponses reues sans expliciter chacun des champs.
Afin de pallier ces manques deux modules OpenFlow ont t dvelopps
pour Scapy [1], pour les versions 1.0 puis 1.3, qui sont accessibles depuis
les sources du projet. En complment, un contrleur rudimentaire a t
dvelopp pour la gestion des sessions OpenFlow, dont le code figure en
annexe A, accompagn dun exemple de client en B.

4.1 carts par rapport aux spcifications

Bien que les spcifications prennent en charge la gestion de diffrents
VLAN, les implmentations testes dfinissent des rseaux de productions,
M. Tury 9

ou instances OpenFlow, qui sont chacun associs un seul VLAN

dfini par ladministrateur linitiation du dploiement.

Prise en charge de TLS. Parmi les autres carts annoncs par la docu-
mentation du firmware v1 figure labsence de prise en charge des paquets
IP fragments et, plus notablement, celle de TLS. Avec le firmware v2,
le constructeur annonce cette prise en charge. ce stade, nous navons
cependant pas t en mesure dtablir manuellement une session TLS
entre un switch et un serveur openssl accompagn de notre script contr-
leur. Nous avons contact lquipementier propos des caractristiques
ncessaires un contrleur en vue dexploiter la prise en charge de TLS.

carts aux spcifications non annoncs. Chaque rponse OpenFlow

doit contenir dans son en-tte un identifiant de transaction identique
celui utilis pour la requte. Sil est vrai que chaque rponse envoye
par le switch comprend un identifiant identique celui qui figurait dans
la requte, il faut cependant noter que le switch accepte nimporte quel
identifiant lorsque le contrleur rpond un HELLO (pour initier la session)
ou un ECHO_REQUEST (pour maintenir la session ouverte). Tant que les
implmentations ne cherchent pas exploiter cet identifiant au-del de
la facilit dappairage entre requtes et rponses quil est cens apporter,
cet cart aux spcifications ne devrait pas porter consquence. En
labsence de dfinition par les spcifications dun comportement suivre,
ce choix devrait tre document par lquipementier. De faon annexe,
les spcifications requirent quun FEATURES_REQUEST soit envoy par le
contrleur en dbut de session, mais les switchs tests ne lexigent pas.

Mcanisme de gestion de rles. Aprs rception dun ROLE_REQUEST,

un switch est cens rpondre avec un ROLE_REPLY qui contient en en-tte la
mme valeur de generation_id que celle prsente dans le premier message.
Pour les switchs tests, cette valeur est toujours 0. De plus, la comparaison
des generation_id utilise pour valider les requtes de matre est fausse.
La distance dfinie entre les generation_id est circulaire , de sorte
que, sur 4 octets, par exemple toute valeur entre 0 et 0x7fffffff est
cense tre considre plus grande que 0xffffffff. Or sur le modle test,
0xffffffff est une valeur absolument maximale, et toute requte de rle
de matre ou desclave dans lintervalle de valeur prcdent sera refuse.
En fait, si le generation_id a atteint 0xffffffff il nest plus possible
deffectuer les prochaines requtes autrement quavec la mme valeur de
0xffffffff. (Les spcifications sont ambiges quant la validit de telles
10 Les risques dOpenFlow et du SDN

requtes car il nest pas dit que la nouvelle valeur devrait tre strictement
suprieure la prcdente ; cette implmentation semble contrevenir
lesprit de la dfinition mais permet au moins de conserver la fonctionnalit
des changements de rle.) De ce fait il suffit quune requte soit effectue
avec 0xffffffff pour prvenir toute incrmentation et rendre inutile ce
mcanisme de gestion des matres.

4.2 Concurrence de flux

Pour un paquet qui correspond deux flux, la version 1.0 des sp-
cifications dOpenFlow utilisait un attribut de priorit qui dterminait
laquelle des deux listes dactions appliquer. Nous appelons concurrence
la situation dans laquelle ces flux sont de priorit identique. En cas de
concurrence, les spcifications indiquent que le flux appliquer est un choix
dimplmentation. Afin dtablir les choix suivis par les switchs tests,
nous avons utilis trois flux de priorits identiques dont les conditions de
correspondance sont dcrites dans le tableau 1.

interface adresse IP autres

ethertype
dentre source attributs
champs 1 1 * * *
champs 2 1 0x0800 * *
champs 3 1 0x0800 192.168.10.3 *

Table 1. Champs de correspondance des 3 flux

Le tableau 2 prsente les flux privilgis en fonction de la version de

firmware utilise, ainsi que du triplet dactions associes aux flux retenus.
Ces actions consistaient, soit en le transfert du paquet vers une interface
prdfinie (reprsent par un F, pour Forward), soit en la suppression
du paquet (D pour Drop). Les champs griss montrent laquelle des trois
actions a t applique un paquet reu via linterface 1 et originaire de
192.168.10.3 (quand laction applique est associe plusieurs flux lors
dun mme test, les compteurs maintenus par le module OpenFlow du
switch permettent dtablir lequel des flux a t appliqu).
Contrairement lintuition selon laquelle le switch choisirait dap-
pliquer les flux les plus prcis, le flux 3 nest jamais appliqu. Les flux
privilgis ne sont pas non plus les plus gnriques, comme en tmoigne le
fait que le flux 1 nest pas toujours appliqu. Les tests effectus avec le
M. Tury 11

v1 v2
action 1 F D F D F D
action 2 D F D F F D
action 3 F D F D F D

Table 2. Actions privilgies par le switch de test

firmware v1 laissent penser que la slection dpend des champs de corres-

pondance et non des actions associes, mais ce jugement nest plus valable
avec le firmware v2. En labsence dindications de la part du constructeur,
il est difficile dtablir les rgles de ce processus dlection.
Afin de prvenir toute action dcoulant dune concurrence involontaire,
une solution consiste utiliser le drapeau CHECK_OVERLAP dans chaque
requte dajout de flux. Lactivation de ce drapeau permet au switch de
rejeter une demande dajout de flux avec un message derreur si celui-ci
rentre en concurrence avec un flux dj enregistr. Les modules Scapy ont
permis de vrifier que cette option tait correctement implmente, mais
elle reste inaccessible depuis lAPI propose par le contrleur Floodlight.

4.3 Performances en fonction des flux

Nous tudions ici certaines rponses en performance dun switch sous
firmware v1 en fonction des flux qui y sont enregistrs dans la table dune
instance OpenFlow 1.0. Ces rsultats sappuient sur des relevs quantitatifs
effectus laide de loutil iperf. Ceux-ci nont quun intrt relatif et
non absolu : ils varient en fonction de nombreux paramtres de flux (en
plus de dpendre des modles de switch). La plupart des rsultats restent
valables en utilisant la table dune instance OpenFlow 1.0 de v2, ou bien
la premire des deux tables modifiables dune instance OpenFlow 1.3.

Recherche de flux dans une table. On pourrait supposer que, lors-

quun switch cherche savoir si une trame appartient un flux pour lequel
il possde des consignes de traitement, le parcours de la table de flux du
switch se fait par ordre de priorit dcroissante et sarrte une fois quun
flux correspondant a t trouv (vu quau plus un seul flux doit sappli-
quer). Les observations laissent cependant penser que la recherche nest
pas optimise de cette faon. En effet, lorsquon fait appliquer deux flux
de priorit maximale (qui tablissent un simple transfert dune interface
une autre), les performances seront notablement moins bonnes si la table
contient quelques milliers dautres flux de priorit faible ou nulle. Quand
12 Les risques dOpenFlow et du SDN

bien mme les priorits taient prises en compte pour parcourir la table
de flux, le switch est susceptible dutiliser dautres critres de recherche
qui auront un impact sur les performances. La section traitant des flux
concurrents tmoigne de linfluence des champs de correspondance et des
actions sur lapplication dun flux. Avec le firmware v2, on peut aussi
observer quil est assez simple de remplir une table de flux en faisant
varier lattribut EtherType ; mais en faisant varier dautres champs (par
exemple le port TCP source), le switch est susceptible de redmarrer de
manire impromptue aprs lenregistrement de quelques milliers de flux,
ce qui saccompagne de la perte de tous les flux enregistrs jusque-l.

Limite de la taille dune table. Lorsquon envoie un

FEATURES_REQUEST au switch sous v1, celui-ci rpond avec un nombre
dentres maximal de 1048576 = 220 . La table atteint cependant sa
capacit maximale avec 65536 = 216 flux, et toute tentative ultrieure
dajout de flux provoque un message davertissement. Cet cart semble
sexpliquer par la faon non standardise dont les flux sont enregistrs
dans les switchs ( partir de la version 1.2 les spcifications prcisent
dailleurs a flow table entry might consume more than one table entry,
depending on its match parameters ). En dpit de variations apportes
aux attributs des flux, chacun semble occuper 24 entres de la table de
flux des switchs sous v1. Quoi quil en soit, les versions ultrieures du
firmware sollicites par un FEATURES_REQUEST renvoient une valeur de
216 qui reflte directement les capacits du switch.

Indisponibilit saturation. Le serveur est en mesure de gnrer des

flux en temps constant envoyer au switch. Une instruction transmise
linterface dadministration du switch permet dafficher le nombre de flux
rellement enregistrs. Le temps de rponse de la CLI augmente au fur
et mesure de laccroissement de la table de flux du switch. Par contre,
les performances de transfert du switch (en fonction des flux) ne sen
ressentent pas tant que la table contient moins de dix mille flux. Pass
ce seuil, le switch peut rompre la connexion OpenFlow avec le contrleur
et/ou redmarrer, ce qui est parfois susceptible de provoquer un dni de
service au bout de moins de cinq minutes denvoi de flux. Plus rarement,
le contrle du switch peut tre perdu et un redmarrage physique tre
ncessaire. Cette rupture peut aussi tre dclenche par une sollicitation
du CLI, ou mme par un ping. La figure 3 reprsente les dlais de rponse
200 pings traversant le switch, envoys chacun une seconde dintervalle.
Le profil linaire dcroissant montre que le switch est muet pendant des
M. Tury 13

priodes de 16-17 secondes avant de renvoyer un ensemble de rponses

quasi-simultanment. Les dlais minimaux correspondent des priodes
de rponses nominales, de lordre de la dizaine de millisecondes. Enfin
les relevs rpts dune ou deux rponses avec un dlai de 4-5 secondes
restent ce stade inexpliqus.

18
16
14
Response time (seconds)

12
10
8
6
4
2
00 50 100 150 200
Ping no.

Figure 3. Temps de rponse pour chaque ping

4.4 Recherches dans la table de flux

Sous certaines conditions, les fonctions de recherche de flux partir du

CLI exhibent un comportement anormal, pouvant mener un redmarrage
indsirable de lquipement et la perte des flux enregistrs jusque-l.
Les tests prsents ci-dessous ont t raliss avec le firmware v2 et la
version 1.0 du protocole. Les rsultats avec le firmware v1 (forcment
OpenFlow 1.0) sont qualitativement identiques ; par contre les recherches
effectues avec le firmware v2 sur une instance OpenFlow 1.3 fonctionnent
correctement. Cette erreur concernant les instances OpenFlow 1.0 semble
avoir t corrige avec le firmware v3.
Nous avons dabord transmis deux flux au switch, qui vont supprimer
dune part toutes les trames ARP, dautre part tous les segments TCP. Une
premire recherche sur tous les flux du switch renvoie correctement les deux
14 Les risques dOpenFlow et du SDN

flux prsents. Ensuite, la recherche de tous les flux qui sappliquent aux
trames ARP renvoie comme attendu le premier flux enregistr. Par contre,
la recherche de tous les flux qui sappliquent aux segments TCP renvoie
en double le second flux enregistr. Enfin, la dernire recherche sur les flux
sappliquant aux trames LLDP, qui ne devrait rien renvoyer, provoque
le redmarrage du switch. Aprs deux trois minutes dinterruption de
service, il est possible dy raccder en SSH. On constate par ailleurs que
tous les flux ont t supprims.
Nous avons reproduit ces rsultats (flux en double et redmarrage
intempestif) plusieurs fois, avec des champs den-tte distincts, et de
diffrentes valeurs. Le dclenchement du redmarrage ne semble pas non
plus dpendre de lordre denregistrement des flux. La configuration la
plus simple consiste enregistrer un flux sans restriction (pour OpenFlow
1.0, cela signifie des valeurs de champs toutes nulles et des wildcards tous
activs) et un autre flux avec un attribut non nul. Une recherche sur le
champ et la valeur particulire est susceptible de renvoyer deux fois le
second flux. A quelques exceptions prs, les autres recherches provoqueront
le redmarrage du switch.

5 Implmentation sur un contrleur de test

Les premiers tests ont t effectus avec le contrleur Floodlight,

par lintermdiaire de son API SFP 2 . Il sagit dune API de type
REST : ladministrateur envoie des requtes HTTP au contrleur,
qui envoie ensuite les messages OpenFlow appropris aux switchs
concerns. Par exemple, avec Floodlight v0.90, une requte POST sur
http://<control>/wm/staticflowentrypusher/clear/<switch>/json
provoque au niveau du contrleur une recherche de tous les flux grs
par le module SFP. Floodlight envoie ensuite au switch cibl des
messages OpenFlow de type FLOW_MOD et de code OFPFC_DELETE, dont les
attributs correspondent aux flux identifis. Au cours des tests, un dfaut
dimplmentation a t dtect, qui permet un attaquant ayant accs
lAPI de masquer des flux aux administrateurs lgitimes.
Le principal problme est li lutilisation par le module SFP de
noms fournis par ladministrateur en tant que cls primaires au sein de sa
base locale de flux. Lorsquun flux est soumis au module pour insertion
dans la base, en cas de conflit avec le nom dun flux dj prsent, cest le
flux le plus ancien qui est supprim. En rgle gnrale, le contrleur se
charge de transmettre la commande de suppression du flux en question,
2. Interface de programmation Static Flow Pusher [2]
M. Tury 15

mais si lancien et le nouveau flux sont relatifs des switchs diffrents, le

contrleur oubliait de supprimer lancien flux.
Le scnario consiste alors pour lattaquant dabord envoyer son flux
malveillant fl1 sur le switch sw1 par lintermdiaire de SFP, avec un nom
quelconque. Ensuite, il rutilise ce nom pour indexer un flux quelconque
fl2, envoy sur un second switch sw2. Dans la base de flux entretenue par
SFP, les attributs de fl1 sont crass par ceux de fl2. Il suffit ensuite
de supprimer fl2 pour revenir la base de flux initiale, bien quun flux
supplmentaire fl1 soit dsormais prsent sur sw1.
Dans la mesure o le module SFP a t dvelopp de sorte quil
ninteragisse pas avec les flux grs par dautres modules de Floodlight,
lorsquune requte comme celle donne en exemple est effectue, SFP
sappuie sur sa base de flux et non sur les flux prsents sur le switch.
Aussi, les destinataires des FLOW_MOD peuvent ne pas correspondre avec
lensemble des flux prsents sur le switch, et dans ltat correspondant
la fin du scnario prcdent, le flux fl1 ne serait pas supprim.
Le module StaticFlowPusher reste capable de lister tous les flux pr-
sents sur un switch avec dautres commandes, mais, par design, ne cher-
chera pas synchroniser sa base avec la liste obtenue. Le problme a t
remont aux dveloppeurs du contrleur, et le test omis a t patch dans
Floodlight v1.0. Cette version permet aussi lutilisation de HTTPS pour
les requtes transmises lAPI, forcerait a priori lauthentification des
administrateurs souhaitant agir sur les switchs via lAPI.

6 Conclusion

Les architectures Software-Defined Networking modifient le paysage de

lindustrie des rseaux. Il est difficile daffirmer si les technologies associes
vont simplanter durablement parmi les produits lis aux rseaux, mais
il est ncessaire dtudier leur scurit avant quils nmergent, et le cas
chant de guider leur dveloppement selon des pratiques saines.
Bien que le protocole soit fonctionnel, nous avons prsent dans cet
article plusieurs lments des spcifications dOpenFlow qui sont suscep-
tibles de porter atteinte la scurit dun rseau. Le SDN diffre des
paradigmes rseaux classiques, ce qui introduit de nouveaux enjeux de
scurit aux cts de pratiques essentielles (bien que non explicites dans
les normes) telles que lutilisation dun rseau dadministration ddi, la
mise en place dune solution dauthentification et dintgrit telle que TLS,
ou encore la redondance des quipements en charge du routage.
16 Les risques dOpenFlow et du SDN

Nous avons ensuite mis en vidence plusieurs failles dimplmentations

dOpenFlow sur un modle de switch. Nous insistons sur le fait que les
anomalies releves sont propres un modle particulier, et que les plus
graves dentre elles ont spontanment t rsolues par lquipementier
dans les versions les plus rcentes du firmware, ne laissant essentiellement
que certains soucis de performance en cas de table de flux sature. Dautre
part, bien que les tests effectus pour cet article portent sur le produit
dun seul quipementier, cela ne prjuge en rien de la confiance accorder
au reste des produits de cet quipementier, ni aux switchs OpenFlow
dautres quipementiers qui nont pas t examins. Ces rsultats suffisent
cependant montrer que les administrateurs rseau souhaitant dvelopper
des prototypes innovants doivent avoir conscience du manque de robus-
tesse et du caractre imprvisible de certaines technologies SDN encore
immatures. Ce jugement dpasse le cadre des switchs, comme illustr avec
le dfaut corrig dans le contrleur Floodlight.
Lusage dOpenFlow, alli la mise en uvre dautres tudes pratiques
de scurit, sera ncessaire au standard pour bnficier des retours nces-
saires laffermissement de ses spcifications et des outils associs. Dans
lattente de ces amliorations, il faut considrer que les ventuels bnfices
de performance associs un dploiement du protocole OpenFlow en
production se feraient au dtriment de la scurit gnrale du rseau, par
rapport lutilisation de protocoles de routage historiques conformment
des principes de protection connus.

Rfrences
1. Scapy. http://bb.secdev.org/scapy/.
2. Static Flow Pusher API Floodlight Controller. http://www.openflowhub.org/
display/floodlightcontroller/Floodlight+REST+API.
3. K. Benton, L.J. Camp, and C. Small. OpenFlow Vulnerability Assessment. http://
conferences.sigcomm.org/sigcomm/2013/papers/hotsdn/p151.pdf, August 2013.
4. J.M. Dover. A denial of service attack against the Open Floodlight
SDN controller. http://dovernetworks.com/wp-content/uploads/2014/03/
OpenFloodlight-03052014.pdf, December 2013.
5. Urs Hoelzle. OpenFlow @ Google. http://www.youtube.com/watch?v=VLHJUfgxEO4,
May 2012.
6. R. Klti. Openflow : A security analysis. ftp://ftp.tik.ee.ethz.ch/pub/
students/2012-HS/MA-2012-20.pdf, April 2013.
7. N. Solomon and Y. Francis and L. Eitan. Floodlight DDoS Vulnerability. http://
www.slideshare.net/YoavFrancis/floodlight-openflow-ddos, September 2013.
8. OpenFlow Switch Specification. https://www.opennetworking.org/images/
stories/downloads/sdn-resources/onf-specifications/openflow/
openflow-spec-v1.1.0.pdf, February 2011. Rev. 1.1.0.
M. Tury 17

9. OpenFlow Switch Specification. https://www.opennetworking.org/images/

stories/downloads/sdn-resources/onf-specifications/openflow/
openflow-spec-v1.4.0.pdf, October 2013. Rev. 1.4.0.

A Serveur contrleur OpenFlow 1.0 et 1.3

# !/ usr / bin / python

from select import select
import getopt , signal , socket , struct , sys
from scapy . contrib import o p e n f l o w as OF
from scapy . contrib import o p e n f l o w 3 as OF_04
from scapy . all import *

class S e rv e r O F ( object ) :

def __ i n i t _ _ ( self , portN , portS ) :

self . outputs = []
self . serverN = socket . socket ( socket . AF_INET , socket .
SOCK_STREAM )
self . serverN . s e t s o c k o p t ( socket . SOL_SOCKET , socket .
SO_REUSEADDR , 1)
print Binding North on port {0}... . format ( portN )
self . serverN . bind (( , portN ) )
self . serverN . listen (5)
self . serverS = socket . socket ( socket . AF_INET , socket .
SOCK_STREAM )
self . serverS . s e t s o c k o p t ( socket . SOL_SOCKET , socket .
SO_REUSEADDR , 1)
print Binding South on port {0}... . format ( portS )
self . serverS . bind (( , portS ) )
self . serverS . listen (5)
self . verb = False
signal . signal ( signal . SIGINT , self . s i g h a n d l e r )

def s i g h a n d l e r ( self , signum , frame ) :

for o in self . outputs :
o . close ()
self . serverS . close ()
self . serverN . close ()

def display ( self , data , msg_type , cls ) :

try :
msg = cls . get ( map ( ord , m s g _ t y p e ) [0]) ( data )
msg . show ()
except :
print \ nError during message parsing !\ n
hexdump ( data )
print \ n

def p r o c e s s _ s w _ m s g ( self , data , s ) :

if data [0] != \ x01 and data [0] != \ x04 :
print Received wire protocol is neither OFv1 .0 nor OFv1
.3.\ n
hexdump ( data )
18 Les risques dOpenFlow et du SDN

print data
else :
mod = OF if data [0] == \ x01 else OF_04
if not self . verb and data [1] != \ x02 :
mod . O p e n F l o w ( None , data ) ( data ) . show ()
print

if data [1] == \ x00 :

s . send ( str ( mod . O F P T H e l l o () ) )
elif data [1] == \ x02 :
s . send ( str ( mod . O F P T E c h o R e p l y () ) )

def serve ( self ) :

inputs = [ self . serverS , self . serverN ]
self . outputs = []
admins = []
running = 1

while running :
inputready , outputready , e x c e p t r e a d y = select . select (
inputs , self . outputs , [])

for s in i n p u t r e a d y :

if s == self . serverS :
self . sw , address = self . serverS . accept ()
print Switch connection {0} from {1} . format (
self . sw , address )
inputs . append ( self . sw )
self . outputs . append ( self . sw )

elif s == self . serverN :

admin , address = self . serverN . accept ()
print Connection {0} from {1} . format ( admin ,
address )
inputs . append ( admin )
self . outputs . append ( admin )
admins . append ( admin )

else :
data = s . recv (1024)
if data :
if s in admins and self . sw in o u t p u t r e a d y :
self . sw . send ( data )
elif s in o u t p u t r e a d y : # should be sw
self . p r o c e s s _ s w _ m s g ( data , s )
else :
s . close ()
inputs . remove ( s )
self . outputs . remove ( s )
self . serverS . close ()
self . serverN . close ()

if _ _ n a m e _ _ == __main__ :
portN = 4242
portS = 6653
M. Tury 19

try :
opts , args = getopt . getopt ( sys . argv [1:] , " hn : s : " ,[ " nport = " ,"
sport = " ])
except getopt . G e t o p t E r r o r :
print srv_OF . py -n < northPort > -s < southPort >
sys . exit (2)
for opt , arg in opts :
if opt == -h :
print srv_OF . py -n < northPort > -s < southPort >
sys . exit ()
elif opt in ( " -n " , " -- nport " ) :
portN = int ( arg )
elif opt in ( " -s " , " -- sport " ) :
portS = int ( arg )
S e r v e r O F ( portN , portS ) . serve ()

B Example dadministrateur client OpenFlow 1.3

# !/ usr / bin / python

import getopt , socket , sys , time
from scapy . contrib . o p e n f l o w 3 import *

class C l ie n t O F ( object ) :

def __ i n i t _ _ ( self , portN , host = 127.0.0.1 ) :

try :
self . sock = socket . socket ( socket . AF_INET , socket .
SOCK_STREAM )
self . sock . connect (( host , portN ) )
print Connected to server on port {0} . format ( portN )
except socket . error , e :
print Could not connect to server
sys . exit (1)

def ru n _ t e s t ( self ) :
m = O F P T F e a t u r e s R e q u e s t ()
self . sock . send ( str ( m ) )
self . sock . close ()

if _ _ n a m e _ _ == __main__ :
portN = 4242
try :
opts , args = getopt . getopt ( sys . argv [1:] , " hn : " ,[ " nport = " ])
except getopt . G e t o p t E r r o r :
print srv_OF . py -n < northPort >
sys . exit (2)
for opt , arg in opts :
if opt == -h :
print srv_OF . py -n < northPort >
sys . exit ()
elif opt in ( " -n " , " -- nport " ) :
portN = int ( arg )
C l i e n t O F ( portN ) . r u n _ t e s t ()