Gestion de risques applique aux rseaux RPL

Antha Mayzaud (anthea.mayzaud@inria.fr)

Anuj Sehgal (s.anuj@jacobs-university.de)
Rmi Badonnel (remi.badonnel@inria.fr)
Isabelle Chrisment (isabelle.chrisment@loria.fr)

Rsum : Le principe de lInternet des Objets se traduit par le dploiement de rseaux avec
pertes et faible puissance appels rseaux LLN a . Ces rseaux permettent de nombreux
quipements embarqus comme des sondes ou des capteurs de pouvoir communiquer entre
eux. Un protocole de routage appel RPL b a t spcialement conu par lIETF pour rpon-
dre aux contraintes spcifiques quimpose ce type de rseaux. Nanmoins, ce protocole reste
expos de nombreuses attaques de scurit. Si des mcanismes de protection existent, leur
mise en uvre est coteuse do lintrt dune approche dynamique comme la gestion de
risques permettant didentifier, dvaluer et de traiter les risques. Dans ce papier, nous pro-
posons une approche de gestion de risques pour les rseaux RPL afin damliorer leur scurit
tout en minimisant la consommation de ressources induite par les contre-mesures. Nous en
effectuons une valuation travers deux attaques spcifiques : lattaque dincohrence DAG
et lattaque sur le numro de version.
a. Low power and Lossy Networks
b. Routing Protocol for LLN

Mots Cls : Internet des Objets, Scurit, Protocole RPL, Gestion de Risques

1 Introduction
Lmergence dquipements bas cot et faibles ressources, capables de communica-
tions sans fil rend possible lapparition de nouvelles applications allant du rseau lectrique
intelligent aux solutions de-sant. Le potentiel le plus intressant de ces quipements
rseaux contraints rside dans le fait de pouvoir tre intgrs linfrastructure Internet
existante. Ils peuvent ainsi utiliser les services dj disponibles auxquels seront alors asso-
cis le contrle des nuds et leur capacit de collecte de donnes [AIM10].
Ces nuds fortement contraints forment des rseaux dits de faible puissance et pertes
ou LLN tels que les rseaux de capteurs sans fil (Wireless Sensor Network) ou les systmes
domotiques. Ces rseaux ont gnralement des contraintes fortes en matire de ressources
(nergie, mmoire, puissance de calcul) et leurs liens sont caractriss par de faibles dbits
et un important taux de pertes. De plus, les types de trafic ne sont pas uniquement point-
-point mais aussi point--multipoint et multipoint--point. Les protocoles de routages
pour les rseaux filaires classiques (OSPF, IS-IS) et pour les rseaux ad-hoc (AODV,
OSLR) ne conviennent pas aux spcifications de ce type de rseaux [LTDH09]. Cest
. Inria Nancy Grand Est - Universit de Lorraine
. Jacobs University Bremen
. TELECOM Nancy - Universit de Lorraine
Antha Mayzaud et Anuj Sehgal et Rmi Badonnel et Isabelle Chrisment

(a) (b)

Figure 1: Scnarios dattaque dincohrence DAG. (a) Lattaquant, le nud 10, cible
le nud 2 en envoyant des paquets avec le flag R. (b) Lattaquant, le nud 3, modifie
les paquets reus de ses descendants en plaant le flag R avant de les transmettre(Rk
reprsente le rang du nud).
pourquoi le groupe de travail RoLL de lIETF 1 a conu le protocole de routage vecteur de
distance RPL sappuyant sur IPv6 [WTB+ 12]. Le protocole RPL construit des topologies
appeles graphes acycliques orients dirigs vers une destination ou DODAGs dont on
peut voir des exemples sur la Figure 1. Les besoins de ces rseaux peuvent diffrer selon
les cas : certains rseaux veulent optimiser la consommation dnergie alors que dautres
doivent garantir la bonne rception des donnes. Par consquent, RPL a t conu de
manire suffisamment flexible pour rpondre aux exigences spcifiques de chaque situation
en utilisant des mtriques disponibles sur chaque nud. Ces mtriques sont utilises pour
optimiser la position du nud dans le DODAG en calculant son rang par rapport ses
parents.
Le protocole RPL comporte des mcanismes de scurit qui peuvent tre utiliss pour
garantir lintgrit et la confidentialit des messages. Cependant, des fonctionnalits im-
portantes comme la gestion des cls ne sont pas prises en compte par le standard. En outre,
les algorithmes de chiffrement sont rputs pour tre coteux en mmoire et en cycles CPU
ce qui pourrait considrablement affecter les performances du nud. Cela signifie que la
plupart des implantations de RPL ne mettent pas en place ces modes de scurit. RPL
reste donc expos de nombreuses attaques [TAD+ 13].
Nous proposons dans ce papier une approche de gestion de risques pour dtecter et
prvenir les attaques tout en prservant les ressources du rseau. La gestion de risques
permet dadapter dynamiquement la slection de contre-mesures en fonction des menaces
observes. Nous commencerons par prsenter le protocole RPL et ses limites dans la Section
2. Nous dtaillerons ensuite dans la Section 3 notre approche de la gestion de risques pour
les rseaux RPL et valuerons sa mise en uvre dans la Section 4 travers ltude de
deux attaques : lattaque dincohrence DAG et lattaque sur le numro de version. Enfin,
la Section 5 prsente la conclusion et identifie les travaux futurs.

1. Routing over Low power and Lossy Networks

 Gestion de risques applique aux rseaux RPL

2 Protocole RPL
Le protocole RPL est un protocole de routage vecteur de distance utilisant IPv6,
spcialement conu par lIETF pour rpondre aux besoins des rseaux LLN. Cette section
prsente le fonctionnement de ce protocole et les mcanismes de protection existants.
Topologie, instance et fonction objectif. Les nuds RPL sinterconnectent en for-
mant une topologie spcifique appele DODAG 2 , cest- -dire un graphe acyclique orient
dirig vers une destination qui est la racine du rseau. Un rseau RPL contient au moins
une instance RPL qui elle-mme se compose dun ou plusieurs DODAGs. Chaque instance
RPL est associe une fonction objectif (OF) qui permet doptimiser la topologie en fonc-
tion dun ensemble de contraintes et/ou de mtriques comme la prservation de lnergie,
le chemin le plus court ou la qualit des liens. Un nud peut faire partie dun seul DODAG
par instance, mais peut participer plusieurs instances simultanment.
Messages de contrle et construction du DODAG. La construction et la mainte-
nance des DODAGs sont ralises grce des messages de contrle ICMPv6. Plus parti-
culirement, trois nouveaux messages sont dfinis : (1) DODAG Information Solicitation
(DIS), (2) DODAG Information Object (DIO) et (3) Destination Advertisement Object
(DAO). Un nouveau nud peut rejoindre un rseau dj form en diffusant un mes-
sage DIS pour solliciter en rponse un message DIO qui contient des informations sur le
DODAG comme le numro de version et lidentifiant du DODAG, lidentifiant de lin-
stance et lOF utilise. Un nud peut galement attendre de recevoir un message DIO
diffus priodiquement par ses voisins. La frquence denvoi des messages DIO est dter-
mine par un temporisateur fond sur lalgorithme Trickle [LCH+ 11] (appel galement
temporisateur Trickle). la moindre anomalie dans le rseau, le temporisateur Trickle est
rinitialis pour permettre la topologie de reconverger.
Aprs avoir reu un message DIO, le nud calcule son rang en utilisant lOF spcifie
dans ce message. Le rang dun nud correspond son emplacement dans le graphe par
rapport la racine. La valeur du rang augmente toujours en descendant dans le graphe.
Cest donc la racine qui a le rang le plus petit dans le graphe. Si un nud reoit des
DIOs de voisins diffrents, lmetteur avec le meilleur rang (le plus petit donc) est choisi
comme le parent prfr vers lequel seront envoys tous les messages destination de la
racine. la fin de ce processus seulement les routes ascendantes (i.e. vers la racine) sont
construites. Pour tablir les routes descendantes, un nud doit envoyer un message DAO
son parent contenant le prfixe des nuds situs dans son sous-DODAG. Lorsque le
message se propage vers la racine, les prfixes sont agrgs et les routes descendantes sont
alors disponibles pour les parents.
Mcanismes de protection existants. RPL intgre diffrents mcanismes afin dviter
les boucles, dtecter les incohrences et rparer le graphe. Le rang joue un rle important
pour construire une topologie sans boucle. En effet, un nud ne peut choisir quun parent
dont le rang est infrieur au sien, autrement dit tous les nuds se trouvant dans le sous-
DODAG dun nud ont un rang suprieur ce nud. Si un nud ne respecte pas cette
proprit du rang, le graphe nest plus acyclique. De plus, afin dviter les boucles, si un
nud doit changer son rang, il doit utiliser un mcanisme de poisoning (en annonant un

2. Destination Oriented Directed Acyclic Graph

Antha Mayzaud et Anuj Sehgal et Rmi Badonnel et Isabelle Chrisment

rang infini) ou de dconnexion (en formant un DODAG temporaire).

Dans les cas o des boucles apparaissent dans le graphe, le protocole RPL fournit une
fonctionnalit appele validation du chemin de donnes 3 . Des informations de contrle sont
transportes dans les paquets de donnes via des flags placs dans len-tte dextension
IPv6 Hop-By-Hop :
Le flag O indique la direction attendue du paquet, i.e., vers le haut ou le bas. Si un
nud place ce flag 1 le paquet est destin un descendant, sinon le paquet est suppos
tre envoy un parent avec un rang infrieur, vers la racine du DODAG.
Le flag R indique si une erreur de rang a t dtecte par un nud transfrant
le paquet. Ce flag est mis 1 lorsquun nud observe une incohrence entre la direction
suppose du paquet indique par le flag O et le rang du nud qui vient de le transfrer.
Le flag R est utilis pour rparer ce type danomalie appele incohrence DODAG. Con-
crtement, la premire incohrence dtecte, le nud place ce flag 1 et transfre le
message. Lors de la rception dun autre paquet avec le flag positionn 1 et lincohrence
nouveau dtecte, le paquet est supprim et le temporisateur Trickle est rinitialis de
sorte que les messages de contrle sont envoys plus rapidement, afin de refaire converger
la topologie et rparer la boucle.
Deux principaux mcanismes de rparation sont utiliss dans les rseaux RPL en cas
dincohrences ou de pannes : la rparation locale et globale. La rparation locale con-
siste trouver un chemin alternatif pour router les paquets. Par exemple, lorsque que la
communication avec le parent prfr est rompue, un nud peut choisir un autre parent
pour transfrer ses paquets. Si aucun autre parent nest disponible, il peut aussi envoyer
les paquet un frre, i.e., un nud de mme rang [KSS12]. Si les rparations locales ne
suffisent pas, la racine peut initier une rparation globale cest--dire la reconstruction
complte du graphe en incrmentant le numro de version du DODAG.
Concernant la scurit en tant que telle, RPL propose deux modes de scurit. Le
premier sappelle mode pr-install et consiste chiffrer les messages laide de cls
pr-installes sur les nuds. Le second, le mode authentifi, fonctionne comme le mode
prcdent. Cependant, si un nud veut participer en tant que routeur il doit obtenir une
autre cl dune autorit authentifie. Avec la cl pr-installe, un nud ne peut participer
quen tant que feuille dans le graphe. Nanmoins, le standard ne dfinit pas comment met-
tre en place concrtement ces deux modes de scurit, dans quel contexte les slectionner,
ni comment la gestion des cls sopre.

3 Approche de gestion de risques

La gestion de risques permet didentifier, valuer et traiter les risques auxquels sont
confronts les rseaux et les systmes dinformation. Elle offre de nouvelles perspectives
pour activer ou dsactiver dynamiquement des mcanismes de scurit dans les rseaux
RPL, et ce, dans le but de bloquer les attaques sur le rseau tout en conservant ses
performances. Nous proposons dexaminer les mthodes et techniques de gestion de risques
dans lInternet des Objets afin dtablir un compromis entre la scurit et son cot.
Le niveau de risque est traditionnellement dfini comme la combinaison de la proba-
bilit dune attaque et de ses consquences. On peut aussi le dfinir comme donn dans

3. data path validation

 Gestion de risques applique aux rseaux RPL

lquation 1 [NIS95].
X
R = P (a) E(a) C(a) (1)
aA

Prenons une attaque, note a. Le risque total du rseau se dfinit comme la somme
sur toutes les attaques possibles de chaque niveau de risque. Le niveau de risque R(a)
dpend de la potentialit P (a) de lattaque, de lexposition E(a) 4 du rseau RPL et des
consquences C(a) de lattaque sur le rseau si elle russit [DBF10]. La gestion de risques
consiste surveiller, hirarchiser et contrler les risques [BC01]. Par exemple, si on observe
une forte potentialit P (a), i.e., une attaque en cours, on peut activer un mcanisme de
scurit en prenant en compte son cot afin de rduire lexposition E(a) et maintenir le
niveau de risque R(a) une valeur raisonnable [GG04].

Figure 2: Schmatisation du processus de gestion de risques

Comme le dcrit la Figure 2, la gestion de risques se compose de deux principaux

processus : lanalyse du risque et le traitement du risque.
Lanalyse du risque se dfinit comme la quantification de la potentialit de lattaque
ainsi que ses consquences. Pour cela, il est ncessaire dvaluer la performance des tech-
niques de dtection disponibles (fondes sur la dtection danomalies ou sur des signa-
tures dattaques connues) dans les environnements RPL. Il est aussi essentiel didentifier
les nuds capables dassurer cette activit de surveillance. Pour complter lanalyse du
risque, les consquences des attaques en cas de succs doivent tre galement quantifies.
Lobjectif est destimer limportance relative des nuds dans le rseau RPL et danalyser
les effets de lattaque contre un nud donn sur lensemble du rseau.
Le traitement du risque consiste, quant lui, en la slection et lapplication des m-
canismes de scurit requis afin de rduire le niveau de risque une valeur acceptable.
Plusieurs stratgies peuvent tre envisages : (1) lvitement cest--dire que les mesures
sont prventives et appliques en anticipation de lattaque, (2) loptimisation o un en-
semble de contre-mesures sera appliqu de manire ractive afin de rduire lexposition des
nuds, et enfin (3) lacceptation si lon considre que les consquences de lattaque sont
acceptables, par exemple, si les donnes transportes par le rseau ne sont pas sensibles,
on peut ngliger les attaques dcoute dans certains contextes.
Si ce type dapproche dynamique a t mise en place dans diffrents systmes et rseaux
[GG04], [DBF10], elle na pas t rellement applique dans lInternet des Objets.

4. Ensemble des vulnrabilits du rseau

Antha Mayzaud et Anuj Sehgal et Rmi Badonnel et Isabelle Chrisment

4 Mise en uvre
Cette section prsente comment nous avons appliqu notre approche de gestion de
risques dans le cas de deux attaques que nous avons identifies et qui sont spcifiques aux
rseaux RPL. Pour cela, nous avons repris le processus expliqu dans la section prcdente,
en identifiant les mtriques utiles pour la dtection des attaques et la quantification des
consquences, puis en tudiant des contre-mesures existantes ou conues pour traiter le
risque de ces attaques.

4.1 Attaques dincohrence DAG

Description de lattaque. En thorie, le mcanisme de validation du chemin de don-
nes, prsent dans la Section 2, a pour objectif damliorer la fiabilit gnrale du rseau.
Cependant, il est possible de dtourner cette fonctionnalit pour attaquer le rseau. En
effet, un attaquant peut faire croire des nuds quil y a des boucles alors que la topologie
est stable.
Deux approches peuvent tre adoptes par lattaquant : (1) crer des paquets malveil-
lants directement avec le flag R et la mauvaise direction positionns, (2) modifier les
paquets qui transitent par lui en positionnant les flags contenus dans len-tte dexten-
sion. Dans les deux cas, la consquence immdiate de cette attaque est linondation du
rseau en messages de contrle, puisque tous les nuds victimes ayant reus les paquets
malveillants ainsi que leur voisinage rinitialiseront leur temporisateur Trickle. Ceci r-
duira terme la dure de vie du rseau. Dans le second cas plus particulirement, les
paquets modifis seront supprims par le parent de lattaquant (le nud 2 dans le sc-
nario dcrit dans la Figure 1.b.) ce qui engendrera un blackhole ou trou noir dport sur
ce parent o les paquets de donnes seront perdus.
Analyse du risque. Lanalyse du risque se dcompose en quantification de la poten-
tialit et des consquences. Quantifier la potentialit de lattaque revient trouver une
mtrique traduisant lattaque et permettant de la dtecter. Dans le cas de lincohrence
DAG, une mtrique efficace est le nombre de messages avec le flag R que nous appellerons
Counter. Si cette valeur dpasse un certain seuil, le nud peut considrer quil est attaqu.
Nous dtaillerons comment le seuil peut tre dfini en fonction de la contre-mesure choisie.
Concernant la quantification des consquences, nous avons tudi lattaque en utilisant
deux scnarios correspondant aux deux stratgies possibles pour lattaquant, comme le
dcrit la Figure 1. Les mtriques choisies pour valuer le cot de lattaque sont le surcot
en messages de contrle reus et envoys ainsi que le taux de transfert exprim comme
le rapport entre le nombre de paquets reus effectivement par la racine et le nombre
de paquets de donnes envoys. Cette dernire mtrique est seulement utilise pour le
deuxime scnario, car le taux de transfert est inchang lorsque lattaquant ne modifie pas
de paquets de donnes. Dans le premier scnario, on fait varier la frquence de lattaquant,
cest--dire le nombre de paquets malveillants envoys par heure. On constate dans la
Figure 3, que la quantit de messages de contrle gnre est multiplie par 3 pour lattaque
la moins agressive et jusqu 7 pour lattaque la plus agressive. Dans le deuxime scnario,
lattaquant positionne les flags dans chaque paquet de donnes quil doit transfrer ce
qui a pour consquence de faire chuter le taux de transfert 0% pour les nuds 4 et 5
situs dans son sous-DODAG, en plus des consquences de la premire attaque, savoir
le surcot en messages.
 Gestion de risques applique aux rseaux RPL

Figure 3: Surcharge en messages de contrle subis par le rseau lors dune attaque din-
cohrence DAG

Traitement du risque. Afin de diminuer limpact dune telle attaque sur le rseau,
plusieurs contre-mesures peuvent tre envisages et appliques. La premire est propose
par les auteurs de la RFC 6553 [HV12], il sagit de limiter le nombre de rinitialisations du
temporisateur Trickle d la dtection dincohrences DAG 20 par heure. Autrement
dit lorsque Counter atteint le seuil fixe 20, le nud applique laction ne plus rinitialiser
le temporisateur Trickle. La seconde contre-mesure que nous proposons, est de limiter
aussi le nombre de rinitialisations, mais en utilisant un seuil dynamique (r) comme
dfini par la formule 2. Epkts reprsente le nombre de paquets reus avec le flag R et
Dpkt , le nombre de paquets de donnes lgitimes qui ont t transfrs par le nud. La
variable r est calcule localement par chaque nud ; a t fix de telle manire que
le seuil natteigne jamais une valeur nulle, a t dtermin de sorte qu un tat sans
attaque le seuil soit gal la valeur du seuil fixe propose par les auteurs de la RFC6553
[HV12] savoir 20, quant lui, sert faire varier la pente de lexponentielle dcroissante
afin de prendre en compte lagressivit de lattaquant.

Epkt 15
(r) = b + e1r c avec r = , = 5, = , = 25 (2)
Dpkt e
La Figure 3 prsente le nombre de messages de contrle envoys sans mitigation, avec
mitigation par seuil fixe et enfin, avec mitigation par seuil adaptatif. On constate une
diminution significative du nombre de messages de contrle gnrs : la surcharge en mes-
sages descend en dessous de 800 pour le seuil fixe et en dessous de 700 pour lapproche
dynamique, donc un gain considrable pour lensemble des nuds du rseau. Lorsquune
contre-mesure est applique, la meilleure stratgie pour un attaquant est de limiter son at-
taque. Lavantage de lapproche dynamique par rapport au seuil fixe est quen cas dattaque
agressive le seuil est atteint plus vite et limite considrablement la surcharge du rseau.
De plus, avec un seuil fixe, lattaquant pourrait prvoir la meilleure stratgie adopter
et bnficier de la rinitialisation de Counter toutes les heures. Le seuil dynamique ne
raugmente quant lui que lorsque le nud ne reoit plus de paquets avec le flag R. La
Figure 4.a. rsume le processus de gestion de risques appliqu cette attaque.
Antha Mayzaud et Anuj Sehgal et Rmi Badonnel et Isabelle Chrisment

(a) (b)
Figure 4: Gestion de risques applique (a) lattaque dincohrence DAG et (b) lattaque
sur le numro de version

4.2 Attaques sur le numro de version

Description de lattaque. Le numro de version est un champ important dans les
messages DIO. Il doit tre propag sans tre modifi le long du DODAG. Seule la racine
peut lincrmenter afin de crer une nouvelle version du DODAG pour revalider lintgrit
du rseau et permettre une rparation globale. Si un nud annonce une version plus
ancienne, cela signifie quil na pas migr vers la nouvelle version et quil ne doit pas
tre choisi en tant que parent. Un attaquant peut changer la version du DODAG en
incrmentant illgitimement le champ correspondant dans ses messages DIO avant de les
transmettre ses voisins. Ceci aura pour consquence la gnration potentielle de boucles
dans le graphe et la reconstruction entire du DODAG impliquant un puisement de la
batterie des nuds. Afin dtudier cette attaque, nous avons utilis la structure prsente
dans la Figure 5a o nous faisons varier la position de lattaquant qui envoie un message
DIO o le numro de version est incrment toutes les 60 secondes. La topologie nest pas
reprsente dans ce schma, la nature de lattaque rendant la topologie instable durant
lexprience.

(a) Topologie en grille. Lat- (b) Reprsentation de la surcharge en messages de contrle,

taquant, la place du nud 15 du dlai, du taux de transfert et du nombre dincohrences
envoie des messages DIO dont le pour chaque position de lattaquant, 0 reprsente le scnario
numro de version est incrment. sans attaquant

Figure 5: Scnario utilis et rsultats obtenus pour lattaque sur le numro de version
 Gestion de risques applique aux rseaux RPL

Analyse du risque. Pour quantifier la potentialit de lattaque on peut utiliser le nom-

bre de boucles cres dans le graphe. En effet, il est possible dinclure des compteurs
notamment quand une incohrence est dtecte, i.e., lorsque la direction du paquet sup-
pose ne correspond pas la direction relle du paquet ; de mme lorsque cette incohrence
perdure (incohrence DAG) par le biais du flag R. Cette mtrique est reprsente dans
la Figure 5b o lon peut observer que, plus lattaquant a de voisins, plus il y aura din-
cohrences dans le rseau comme cest le cas en 10, 11, 12, 14 et 15. Cette attaque a fait
lobjet dune publication [MSB+ 14] prsentant ces rsultats en dtail.
Afin dvaluer les consquences dune telle attaque sur le rseau, on peut aussi utiliser
comme mtriques le nombre de paquets de contrle gnrs suite lattaque ainsi que le
taux de transfert afin de dterminer la quantit de paquets perdus. On remarque lvidente
corrlation entre le nombre dincohrences et la quantit de paquets de contrle gnrs,
de mme pour le taux de livraison qui est maximis lorsque le nombre dincohrences est
minimis.
Traitement du risque. Pour contrer cette attaque, Dvir et al. [DHB11] ont propos un
mcanisme de scurit appel VeRa 5 qui empche un nud compromis dusurper la racine
en modifiant le numro de version. La solution utilise un systme dauthentification fond
sur des oprations de hachage et de signatures avec des cls partages. Un nud peut
ainsi vrifier que cest la racine qui est lorigine du changement de version. Cependant
les auteurs de [LPU+ 13, PLU+ 13] ont montr que VeRa ntait pas sr. Ils ont propos
TRAIL 6 en reprenant lide gnral de VeRa mais en incluant des challenges devant tre
signs par la racine. Ils ont de plus montr que leur solution tait fiable pour un cot assez
faible en comparaison du gain en cas dattaque. On peut ainsi considrer cette contre-
mesure comme traitement du risque bien quelle ne soit pas dynamiquement activable, ce
qui pourrait faire lobjet dune extension pour cette solution.

5 Conclusion
LInternet des Objets amne au dploiement de rseaux LLNs. Ceux-ci se caractrisent
par de faibles ressources en matire dnergie, de puissance de calcul, de mmoire et re-
posent sur des liens contraints. Leur dveloppement a conduit la spcification par le
groupe de travail RoLL lIETF, dun protocole ddi, appel RPL. Ces rseaux sont
exposs de nombreuses attaques. Bien que des mcanismes de scurit soient prvus ou
peuvent tre adaptes, leur mise en uvre peut dgrader les performances du rseau. Nous
proposons une approche de gestion de risques dans ces rseaux afin dobtenir un compro-
mis entre la scurit et son cot. Lobjectif est dadapter dynamiquement lexposition du
rseau en fonction de la potentialit dune menace travers lactivation ou la dsactivation
de contre-mesures ddies. Nous avons valu, grce ltude de deux attaques spcifiques
aux rseaux RPL, comment appliquer cette approche en identifiant des mtriques pour
la quantification du risque et diffrentes contre-mesures possibles. Comme travaux futurs,
nous allons tendre notre tude dautres type dattaques contre les rseaux RPL comme
les attaques de selective forwarding et les attaques sur le rang. Afin de poursuivre nos
travaux sur la gestion de risques, nous prvoyons de quantifier les performances de dif-

5. Version Number and Rank Authentication

6. Trust Anchor Interconnection Loop
Antha Mayzaud et Anuj Sehgal et Rmi Badonnel et Isabelle Chrisment

frents algorithmes de slection dynamique des contre-mesures en environnements RPL.

Remerciements
Ce travail est en partie financ par Flamingo, un projet de rseau dexcellence (ICT-
318488), soutenu par la Commission Europenne.

Rfrences
[AIM10] L. Atzori, A. Iera, and G. Morabito. The Internet of Things : A survey.
Elsevier Journal Computer Networks, 54(15) :27872805, October 2010.
[BC01] T. Bedford and R. Cooke. Probabilistic Risk Analysis : Foundations and Meth-
ods. Cambridge University Press, 2001.
[DBF10] O. Dabbebi, R. Badonnel, and O. Festor. Managing Risks at Runtime in VoIP
Networks and Services. In IFIP AIMS2010, pages 8992, June 2010.
[DHB11] A. Dvir, T. Holczer, and B. Buttyn. VeRA - Version Number and Rank
Authentication in RPL. In MASS, pages 709714, 2011.
[GG04] A. Gehani and K. Gershon. RheoStat : Real-time Risk Management. In Proc.
of the 7th International Symposium on Recent Advances in Intrusion Detection
(RAID2014), pages 1517, 2004.
[HV12] J. Hui and J. Vasseur. The Routing Protocol for Low-Power and Lossy Net-
works (RPL) Option for Carrying RPL Information in Data-Plane Datagrams.
RFC 6553 (Proposed Standard), March 2012.
[KSS12] K. Korte, A. Sehgal, and J. Schnwlder. A Study of the RPL Repair Process
Using ContikiRPL. In IFIP AIMS, pages 5061, 2012.
[LCH+ 11] P. Levis, T. Clausen, J. Hui, O. Gnawali, and J. Ko. The Trickle Algorithm.
RFC 6206 (Proposed Standard), March 2011.
[LPU+ 13] M. Landsmann, H. Perrey, O Ugus, M. Whlisch, and T.C. Schmidt. Topology
Authentication in RPL. In Proc. of the 32nd IEEE INFOCOM. Poster. IEEE
Press, 2013.
[LTDH09] P. Levis, A. Tavakoli, and S. Dawson-Haggerty. Overview of Existing Routing
Protocols for Low Power and Lossy Networks, IETF Internet Draft : draft-
ietf-roll-protocols-survey-07, April 2009.
[MSB+ 14] A. Mayzaud, A. Sehgal, R. Badonnel, I. Chrisment, and J. Schnwlder. A
Study of RPL DODAG Version Attacks (accepted). In AIMS, 2014.
[NIS95] NIST. An Introduction to Computer Security : The NIST Handbook, 1995.
[PLU+ 13] H. Perrey, M. Landsmann, O. Ugus, M. Whlisch, and T.C. Schmidt. TRAIL :
Topology Authentication in RPL. 2013.
[TAD+ 13] T. Tsao, R. Alexander, M. Dohler, V. Daza, A Lozano, and M. Richardson.
A Security Threat Analysis for Routing Protocol for Low-power and Lossy
Networks (RPL), IETF Requirement Draft for Routing over Low power and
Lossy Networks (ROLL), Work in progress., December 2013.
[WTB+ 12] T. Winter, P. Thubert, A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister,
R. Struik, J. Vasseur, and R. Alexander. RPL : IPv6 Routing Protocol for
Low-Power and Lossy Networks. RFC 6550 (Proposed Standard), IETF, 2012.