Qu’est-ce que RPKI ? Guide du débutant sur la sécurité du routage

Un site peut fonctionner normalement et devenir pourtant inaccessible. Le problème se trouve parfois loin de ses serveurs : un autre réseau a annoncé un mauvais chemin pour le rejoindre. Le trafic part alors vers une destination incapable de l’acheminer, voire vers quelqu’un qui cherche à l’intercepter.

RPKI, pour Resource Public Key Infrastructure, aide à vérifier une affirmation précise : ce réseau est-il autorisé à annoncer ces adresses IP ? Pour comprendre son intérêt, il faut aussi regarder de quoi dépend cette vérification. Qui tient les registres, et quel pouvoir cela lui donne-t-il ?

Quand un réseau annonce un chemin

Internet relie des réseaux exploités par des organisations différentes. Avec BGP, le protocole de routage entre réseaux, chacun annonce comment joindre des ensembles d’adresses IP, appelés préfixes. Un numéro de système autonome, ou ASN, identifie chaque réseau de routage administré de manière autonome.

Imaginez un transporteur qui affirme : « Je peux livrer dans ce quartier. » Ses partenaires ont besoin de vérifier cette affirmation. Sur Internet, une annonce erronée peut venir d’une faute de frappe ou d’un détournement volontaire. L’annonce BGP ne prouve pas, à elle seule, que le réseau présenté comme son origine a l’autorisation de la faire.

Un certificat, une autorisation, puis une vérification

RPKI fournit un cadre de certification pour les ressources de numérotation d’Internet. Le détenteur d’adresses peut publier une autorisation signée, appelée ROA, qui indique quel ASN peut annoncer un préfixe. Elle peut aussi préciser jusqu’à quel niveau ce préfixe peut être découpé dans les annonces. Le RFC 9582 définit ce mécanisme (en anglais).

Publier ses autorisations et vérifier les annonces reçues sont deux tâches distinctes. Un logiciel de validation contrôle les certificats et les documents signés, puis fournit les autorisations vérifiées aux routeurs. Ceux-ci les comparent aux annonces BGP. L’opérateur décide ensuite de la politique de routage à appliquer. C’est la validation de l’origine des routes, ou ROV. Le guide du RIPE NCC (en anglais) détaille ce fonctionnement.

Pour reprendre l’exemple du transporteur, on vérifie qui est autorisé à desservir le quartier. On ne garantit pas pour autant le bon déroulement de chaque livraison.

Trois résultats possibles

Valid : au moins une autorisation vérifiée couvre le préfixe annoncé et permet cet ASN d’origine ainsi que cette longueur de préfixe. Invalid : des autorisations couvrent le préfixe, mais aucune ne permet cette combinaison. NotFound : aucune autorisation ne couvre le préfixe dans les données de validation.

NotFound ne signifie donc pas qu’une attaque a été détectée. Invalid ne permet pas non plus de distinguer, à lui seul, une attaque d’une erreur de configuration. Ces trois résultats décrivent une comparaison, selon les règles du RFC 6811 (en anglais).

Une protection utile, avec un périmètre précis

La validation de l’origine aide à écarter les annonces dont l’origine n’est pas autorisée. Elle ne vérifie pas chaque réseau traversé, ne chiffre pas la connexion du visiteur et ne garantit pas la disponibilité d’un site. Une route peut être propagée à tort tout en conservant une origine autorisée. Le filtrage et la surveillance restent donc nécessaires.

Pour un opérateur, la première étape consiste à comparer ses autorisations à ce qu’il annonce réellement : quels préfixes, depuis quels ASN ? Il faut ensuite maintenir ces données et les validateurs. Activer une option sur un routeur ne suffit pas. Le RFC 7115 (en anglais) présente les enjeux d’exploitation.

Celui qui tient les preuves détient aussi un pouvoir

La hiérarchie de confiance RPKI couramment utilisée suit l’attribution des ressources, avec les registres Internet régionaux à sa racine. La vérification dépend donc aussi des organismes qui émettent les certificats et publient les données. La solidité des calculs cryptographiques ne règle pas cette dépendance.

Modifier ou retirer des données peut changer le résultat d’une validation. Cela ne coupe pas automatiquement un réseau de tout Internet : les autres autorisations disponibles et les politiques des opérateurs comptent aussi. Le RFC 8211 (en anglais) étudie les effets d’actions défavorables ou d’erreurs des autorités de certification et des gestionnaires de dépôts.

La position de Lu Heng : sécuriser sans donner les pleins pouvoirs

Dans sa Note 28, consacrée aux limites du rôle des registres (texte original en anglais), Lu Heng défend une distinction nette : tenir un annuaire d’adresses ne donne pas le droit de punir ses utilisateurs. Il ne remet pas en cause l’exactitude des registres, mais l’autorité que leurs administrateurs revendiquent. Un petit groupe qui se constitue lui-même ne reçoit pas, de ce seul fait, un mandat sur des réseaux répartis entre plusieurs continents.

Sa Note 64 propose une autre direction. Les règles communes doivent se limiter à ce qu’exigent l’unicité des identifiants et la sécurité. Les participants doivent pouvoir vérifier les preuves eux-mêmes et conserver des données utilisables ailleurs. Changer de prestataire ne devrait pas obliger un réseau à abandonner son identité. Les évolutions futures doivent convaincre les participants de les adopter, sans dépendre d’un pouvoir administratif permanent.

C’est une proposition pour reconstruire la coordination, pas l’annonce d’un système RPKI de remplacement déjà utilisé partout. Elle doit assurer la compatibilité des registres et la fiabilité des vérifications. L’exigence est double : se protéger des fausses annonces, mais aussi d’une autorité qui n’a de comptes à rendre à personne sur les preuves qui servent à les juger.

Pourquoi s’en préoccuper avant la panne

Les clients d’un réseau comptent chaque jour sur les mêmes adresses. Si une dépendance n’apparaît qu’au moment où ses données changent ou disparaissent, elle devient immédiatement un problème de continuité de service. C’est le point de départ de Lu Heng : prévoir dès la conception la vérification indépendante, la continuité et la possibilité de partir, avant qu’un différend ne les rende indispensables.

Pour passer du constat à la proposition, poursuivez avec la Note 64 de Lu Heng sur les règles communes minimales et le libre choix des participants (texte original en anglais).