Routage, Sécurité & Internet : de l'innovation !

Edit : à l'appui des opinions défendues dans cet article, je vous renvoie aux échanges sur l'hypothétique usurpation des routes par la Chine en avril 2010. Je ne me prononce pas sur la véracité ou non des faits mais les expériences montrent que cela n'a rien d'impossible...

Comme vous pouvez également le lire, la capture de trafic aurait été relativement courte dans le temps, probablement parce que la surveillance de l'état des tables de routage à tout instant a permis d'alerter et de corriger.

Je vous laisse vous prononcer sur les impacts relatifs et donc la criticité associé aux éléments fondateurs d'Internet :).

Source :

http://www.cnis-mag.com/internet-plie-sous-le-poids-de-la-chine.html

==================================================================================

RPKI pour Resource Public Key Infrastructure ou, en français, Infrastructure de Gestion de Clés pour le routage est une solution technique et en cours de normalisation visant à améliorer la sécurité d’Internet en rendant le routage moins vulnérable à certaines attaques. Je parle bien de la sécurité d’Internet, c'est-à-dire la capacité des systèmes à respecter les niveaux souhaités de Disponibilité, Intégrité et Confidentialité.

1/ Problématique technique et de gouvernance

Dans de précédents articles (ici, là et encore ici), Jean-François Audenart analysait avec clarté la problématique posée par le manque de sécurité du routage sur Internet. Le principal problème du routage se pose actuellement entre les AS ou Autonomous System, c’est-à-dire les grands acteurs d’Internet, utilisant le protocole de routage BGP.

Pourquoi cela ? Tout simplement car dans leurs domaines respectifs, les AS disposent de droits extensibles sur l’ensemble des niveaux techniques. Au contraire, entre ces AS, donc sur Internet, ces droits-là ne s’appliquent plus et l’on tombe dans les processus de gestion en commun du Net ou encore Gouvernance Internet.

Le principal défaut de BGP est notamment d’être un protocole un peu naïf : il accepte toute information venant d’un autre routeur comme légitime (ou peu s’en faut). Il était donc relativement facile (pas si évident toutefois) de se positionner comme un « espion » en obligeant le trafic entre deux points à passer par ses propres infrastructures.

Plus encore, le protocole permet également la propagation des erreurs de configuration manifestes permettant ainsi quelques exemples cocasses comme le blocage de Youtube par le Pakistan alors que ce dernier ne visait qu’à restreindre l’accès en interne. Quelques années plus tôt, un infortuné AS avait également commis une telle erreur en annonçant toutes les routes de l’Internet : il s’effondra rapidement bloquant le trafic de…tout l’Internet.

Fort heureusement, une veille très active permet de pallier aux principaux problèmes rencontrés. Ainsi, le blocage de Youtube n’aura duré que quelques heures. Cette même veille autorise également des réactions très rapides en cas de ruptures de connexions par exemple afin de « re-router » le trafic comme cela se produit régulièrement lorsque des câbles sub-océaniques se rompent (tempêtes, séismes, pêche…).

Le système parait cependant quelque peu faible à long-terme notamment au vu de l’expansion d’Internet et de la croissance des utilisateurs et des usages. Cette problématique, longtemps oublié par la Gouvernance Internet, retrouve ainsi toute sa place avec une solution récente qui parait plus stable pour l’avenir.

2/ La solution : RPKI !

Sous cette solution au nom barbare se cache un ensemble d’aspects déjà bien connus. En effet, il s’agit, plus ou moins, d’appliquer au routage, ce que l’on a appliqué au DNS.

DNSSEC, bien plus connu que RPKI, est ainsi une solution qui consiste à utiliser les techniques de cryptographie pour signer chaque enregistrement DNS et authentifier ainsi la source de l’information.
D’une manière similaire, RPKI propose de garantir la légitimité des routeurs envoyant à d’autres routeurs des informations.

Pour ce faire, la solution propose d’attribuer à chaque détenteur légitime d’un espace d’adresse, un certificat (un peu de la même manière que pour les banques sur Internet) qui sera échangé avec les informations de routage. Ainsi, les annonces faites par un routeur légitime pourraient être propagées et reconnues comme légitime par un autre routeur qui pourra donc l’intégrer à sa table de routage.

Pour reconnaitre une information de routage comme légitime, la RPKI proposera une liste de Route Origin Authorizations (ROAs), c’est à dire de titulaires susceptibles d’annoncer telle ou telle plage d’adresses IP.

Dans le cas contraire, si un routeur annonce, par exemple, une route avec un préfixe plus court, alors qu’il n’est pas légitime, les routeurs pourront refuser les informations car elles ne seront pas accompagnées du certificat attestant de la légitimité des informations.

A côtés de cela, devront être constituées des autorités de certification, une ou plusieurs, ayant la possibilité d’attribuer, de contrôler et de révoquer les certificats.

3/ Limites de la solution

Cette solution est une mesure de sécurité efficace pour certaines menaces. En revanche, je ne suis pas sur qu’elle couvre l’ensemble des risques de configurations. Elle ne remplace donc que partiellement la veille active citée plus haut.

Par ailleurs, l’utilisation de certificat de ce type suppose une autorité de certification, une politique de révocation et de contrôle. Dans un autre article, je mettais en avant les limites de l’architecture de sécurité liée aux certificats, limites que la RPKI connait également.

Parmi ces limites, on peut ainsi penser à la réactivité. Le routage n’est pas une carte routière relativement statique dans le temps, bien au contraire. La pratique du « peering » consistant à transporter, pour un autre opérateur, une partie de son trafic est évolutive dans le temps et la légitimité, au sens de la RPKI, devient donc également une notion variable. Cette contrainte forte différencie donc des infrastructures à base de certificat plus traditionnelles et représente un défi.

De plus, cette solution pose également un problème de légitimité. En effet, les standards techniques d’Internet (attention : pas uniquement du Web) sont réalisés, pour la plupart, par une organisation à but non lucratif appelée IETF. Or, malgré toute la qualité des travaux et du mode d’organisation de l’institution par ailleurs, les modèles de sécurité qu'elle a proposé n'ont pas suscité une adhésion effective. RPKI doit son origine à d’autres organisations et peut ainsi souffrir d’une question de légitimité.

Enfin, cette solution modifie de manière relativement importante la répartition des pouvoirs et provoque de débats passionnés. Ainsi, par exemple, qui aura le contrôle de l’autorité chargée de délivrer les certificats ? En effet, cette autorité aura par exemple une capacité inouïe de révoquer les certificats des AS de tout un pays et donc de les rendre non légitimes et perturber ainsi fortement ses capacités de connexion. Une capacité presque plus dérangeante que celle que possèdent VeriSign sur la racine du DNS….

Conclusion : la sécurité est autant technique qu’organisationnelle voire même politique, une leçon que nous ne cessons jamais de voir s’appliquer !

On notera enfin que la solution serait déjà en cours de test et déploiement. Par ailleurs, pour satisfaire mon côté grincheux, je reprendrais la proposition exprimée dans les sources ci-dessous : la sécurité du routage est une question cruciale du net, sans doute plus que les questions du moment sur les noms du domaine. Une leçon à retenir aussi !

Source :

http://blog.internetgovernance.org/blog/_archives/2010/9/7/4624281.html

http://www.bortzmeyer.org/rpki-et-igp.html

http://www.ripe.net/ripe/policies/proposals/2008-04.html

http://www.bortzmeyer.org/certificats-ressources-internet.html

http://www.networkworld.com/news/2009/012009-internet-routing.html?page=1