Dans un article précédent, j'évoquais les travaux menés par un groupe de travail de l'IETF et portant sur la sécurisation du routage. En effet, entre les acteurs principaux (AS - Autonomous System) comme le sont les fournisseurs d'accès ou de services...le routage est effectué de manière complexe.
Sans entrer dans les détails, il existe peu de sécurité sur les échanges entre les routeurs permettant de suivre l'évolution des routes sur Internet (ou encore des chemins permettant de joindre un point d'un autre). Ces lacunes ont été évoqués lors de cas relativement récents de détournement de trafic : dans le climat actuel, cela représente donc d'importants problèmes potentiels. Cela a notamment conduit aux travaux de l'IETF.
Conduit par le groupe de travail SIDR, nous devons notamment à Stéphane Bortzmeyer une analyse exhaustive des multiples RFC qui établissent l'architecture technique de la solution. Ils sont listés à la fin de cet article.
Quel est l'objectif ?
L'objectif premier de cette solution est d'assurer que les routeurs qui annoncent des routes ont la légitimité pour le faire. Cette question n'a rien de simple et c'est la solution d'une infrastructure à clé publique pour le routage ou RPKI, Routing Public Key Infrastructure qui a été choisie.
En effet, en annonçant, par exemple, que j'ai la route la plus intéressante (la plus rapide, la moins consommatrice de ressources...) pour un site que je ne connais pas et héberge encore moins, j'ai de fortes chances, si bien évidemment, j'ai un routeur permettant d'émettre des annonces BGP, d'obtenir qu'une partie du trafic à sa destination passe par mes infrastructures.
Parfois, il s'agit d'une erreur - ex. : lorsque le Pakistan "coupe" Youtube" ou quand "tout" l'internet est annoncé par un seul AS - mais parfois, l'objectif peut-être d'étudier ou d'obtenir des informations sur certaines portions du trafic.
Quel sont les principes ?
Le principe de base est relativement simple : lorsqu'un organisme détiendra légitimement un bloc d'adresse IP, il sera également titulaire d'un certificat (de type x.509) permettant de signer des objets et autorisant ainsi certains AS à l'annoncer et donc, les routeurs en suivant à en vérifier la légitimité...
Cette architecture rappellera sans doute à certains celle de SSL, ce qui n'est pas tout à fait exact, mais le nouveau système emprunte certaines caractéristiques comme les certificats X.509.
Selon l'article de S. Bortzmeyer, on trouve 3 éléments principaux dans cette solution :
=> une infrastructure de clé, plaquée sur la logique actuelle d'attribution des blocs IP. L'IANA d'abord, suivi des RIR puis des attributeurs locaux (LIR) éventuels.
=> des objets numériques (signés par les certificats pour en attester la validité) qui expriment les autorisations de routage accordés ou non.
=> un mécanisme sécurisé de distribution (et de révocation)
Notons toutefois une distinction importante : cette première étape de la solution permet de valider l'origine de l'annonce. En bref, elle permet de certifier techniquement que celui qui annonce "détenir" une adresse IP (ou plutôt un bloc) en est bien le détenteur légitime. On valide donc l'origine.
Le chemin annoncé et pris par un paquet au départ d'une machine et à destination d'une autre est un problème qui sera traité plus tard : il est en effet bien plus compliqué car les chemins ne sont pas forcément stables et dépendent de relations entre opérateurs. La validation du chemin est donc encore à attendre.
3/ Quelques changements...
Bien que ne rentrant pas sciemment dans les détails techniques, quelques éléments sont à noter. Tout d'abord, il assiste à un renforcement de la pérennité de la structure de distribution d'adressage, structure très certainement contestable sur certains points : le cas de blocs entiers attribués à des structures privées et favorisées au détriment de pays et régions arrivés plus tard dans l'internet.
Cette structure apporte cependant ici une notion de pérennité et de constance et donc de sécurité. Le fait de pouvoir apporter une preuve technique, aux routeurs, de la légitimité de l'origine d'une annonce repose sur une chaine de confiance : IANA atteste des blocs attribués aux 5 RIRs qui eux-mêmes attestent avoir distribué les blocs à des LIRs ou à des FAI.
Cependant, auparavant, comme cette chaine n'avait pas de répercussion technique dans la validation, le processus de retrait d'un bloc à son détenteur précédent n'avait aucun effet pratique : désormais, en envoyant des informations de révocation, les annonces relatives à l'origine d'un bloc d'adresse ne seront plus valides et le détenteur en sera...dépossédé.
Cependant, pour le moment, IANA ne constitue pas la racine de certification : ce sont les RIRs qui sont chacun une racine de certification, ce qui tendrait à prouver que certains ne souhaitent pas que le pouvoir soit concentré à l'IANA. Vous pouvez lire quelques articles sur la modification de la structure de pouvoirs et opérationnelle de la gouvernance.
Enfin, cette solution nécessite cependant des changements au niveau des routeurs et des organisations offrant des services réseaux. Pour le moment, rien n'oblige un routeur à utiliser un système de vérification : il peut accepter les routes sans effectuer de contrôle...Cela pourrait varier mais pas pour le moment.
Conclusion :
Pour ceux qui persistent à croire qu'Internet est un espace absolument non-sécurisé, force est de constater la profonde évolution du milieu.
La fin d'IPv4 pousse à une adoption d'IPv6, la mise en place de DNSSEC est croissante et l'arrivée de RPKI représente, pour moi, une révolution du même acabit. Cette ensemble de solutions, issues de la gouvernance, apporte des fonctionnalités de sécurité importantes à un système qui en avait certainement besoin, notamment depuis que les attentes à son égard ont évoluées.
Il est à noter que sa naissance au sein de l'IETF est intéressante car elle est aussi une preuve de la capacité des mécanismes de la gouvernance à faire évoluer positivement ce système. Il faudra cependant demeurer attentif quant à son adoption et au développement de la seconde étape, plus compliquée mais déjà très attendue.
Source :
Une description globale du système et l'ensemble des RFCs de l'architecture de RPKI
Sans entrer dans les détails, il existe peu de sécurité sur les échanges entre les routeurs permettant de suivre l'évolution des routes sur Internet (ou encore des chemins permettant de joindre un point d'un autre). Ces lacunes ont été évoqués lors de cas relativement récents de détournement de trafic : dans le climat actuel, cela représente donc d'importants problèmes potentiels. Cela a notamment conduit aux travaux de l'IETF.
Conduit par le groupe de travail SIDR, nous devons notamment à Stéphane Bortzmeyer une analyse exhaustive des multiples RFC qui établissent l'architecture technique de la solution. Ils sont listés à la fin de cet article.
Quel est l'objectif ?
L'objectif premier de cette solution est d'assurer que les routeurs qui annoncent des routes ont la légitimité pour le faire. Cette question n'a rien de simple et c'est la solution d'une infrastructure à clé publique pour le routage ou RPKI, Routing Public Key Infrastructure qui a été choisie.
En effet, en annonçant, par exemple, que j'ai la route la plus intéressante (la plus rapide, la moins consommatrice de ressources...) pour un site que je ne connais pas et héberge encore moins, j'ai de fortes chances, si bien évidemment, j'ai un routeur permettant d'émettre des annonces BGP, d'obtenir qu'une partie du trafic à sa destination passe par mes infrastructures.
Parfois, il s'agit d'une erreur - ex. : lorsque le Pakistan "coupe" Youtube" ou quand "tout" l'internet est annoncé par un seul AS - mais parfois, l'objectif peut-être d'étudier ou d'obtenir des informations sur certaines portions du trafic.
Quel sont les principes ?
Le principe de base est relativement simple : lorsqu'un organisme détiendra légitimement un bloc d'adresse IP, il sera également titulaire d'un certificat (de type x.509) permettant de signer des objets et autorisant ainsi certains AS à l'annoncer et donc, les routeurs en suivant à en vérifier la légitimité...
Cette architecture rappellera sans doute à certains celle de SSL, ce qui n'est pas tout à fait exact, mais le nouveau système emprunte certaines caractéristiques comme les certificats X.509.
Selon l'article de S. Bortzmeyer, on trouve 3 éléments principaux dans cette solution :
=> une infrastructure de clé, plaquée sur la logique actuelle d'attribution des blocs IP. L'IANA d'abord, suivi des RIR puis des attributeurs locaux (LIR) éventuels.
=> des objets numériques (signés par les certificats pour en attester la validité) qui expriment les autorisations de routage accordés ou non.
=> un mécanisme sécurisé de distribution (et de révocation)
Notons toutefois une distinction importante : cette première étape de la solution permet de valider l'origine de l'annonce. En bref, elle permet de certifier techniquement que celui qui annonce "détenir" une adresse IP (ou plutôt un bloc) en est bien le détenteur légitime. On valide donc l'origine.
Le chemin annoncé et pris par un paquet au départ d'une machine et à destination d'une autre est un problème qui sera traité plus tard : il est en effet bien plus compliqué car les chemins ne sont pas forcément stables et dépendent de relations entre opérateurs. La validation du chemin est donc encore à attendre.
3/ Quelques changements...
Bien que ne rentrant pas sciemment dans les détails techniques, quelques éléments sont à noter. Tout d'abord, il assiste à un renforcement de la pérennité de la structure de distribution d'adressage, structure très certainement contestable sur certains points : le cas de blocs entiers attribués à des structures privées et favorisées au détriment de pays et régions arrivés plus tard dans l'internet.
Cette structure apporte cependant ici une notion de pérennité et de constance et donc de sécurité. Le fait de pouvoir apporter une preuve technique, aux routeurs, de la légitimité de l'origine d'une annonce repose sur une chaine de confiance : IANA atteste des blocs attribués aux 5 RIRs qui eux-mêmes attestent avoir distribué les blocs à des LIRs ou à des FAI.
Cependant, auparavant, comme cette chaine n'avait pas de répercussion technique dans la validation, le processus de retrait d'un bloc à son détenteur précédent n'avait aucun effet pratique : désormais, en envoyant des informations de révocation, les annonces relatives à l'origine d'un bloc d'adresse ne seront plus valides et le détenteur en sera...dépossédé.
Cependant, pour le moment, IANA ne constitue pas la racine de certification : ce sont les RIRs qui sont chacun une racine de certification, ce qui tendrait à prouver que certains ne souhaitent pas que le pouvoir soit concentré à l'IANA. Vous pouvez lire quelques articles sur la modification de la structure de pouvoirs et opérationnelle de la gouvernance.
Enfin, cette solution nécessite cependant des changements au niveau des routeurs et des organisations offrant des services réseaux. Pour le moment, rien n'oblige un routeur à utiliser un système de vérification : il peut accepter les routes sans effectuer de contrôle...Cela pourrait varier mais pas pour le moment.
Conclusion :
Pour ceux qui persistent à croire qu'Internet est un espace absolument non-sécurisé, force est de constater la profonde évolution du milieu.
La fin d'IPv4 pousse à une adoption d'IPv6, la mise en place de DNSSEC est croissante et l'arrivée de RPKI représente, pour moi, une révolution du même acabit. Cette ensemble de solutions, issues de la gouvernance, apporte des fonctionnalités de sécurité importantes à un système qui en avait certainement besoin, notamment depuis que les attentes à son égard ont évoluées.
Il est à noter que sa naissance au sein de l'IETF est intéressante car elle est aussi une preuve de la capacité des mécanismes de la gouvernance à faire évoluer positivement ce système. Il faudra cependant demeurer attentif quant à son adoption et au développement de la seconde étape, plus compliquée mais déjà très attendue.
Source :
Une description globale du système et l'ensemble des RFCs de l'architecture de RPKI
Aucun commentaire:
Enregistrer un commentaire