Qu’est-ce que le RPKI ? Guide de la sécurité du routage pour débutants

Vérifier qui peut annoncer une route revient à vérifier l’autorisation d’un transporteur à desservir un quartier. Cela ne garantit pas chaque étape du trajet.

Un site web peut fonctionner parfaitement et devenir malgré tout inaccessible. Quelque part entre son réseau et ses visiteurs, un autre réseau peut annoncer la mauvaise route. Le trafic se dirige alors vers un endroit qui ne peut pas l’acheminer — ou vers quelqu’un qui tente de l’intercepter.

Le RPKI, abréviation de Resource Public Key Infrastructure, aide les réseaux à vérifier une affirmation importante : ce réseau est-il autorisé à annoncer ces adresses IP ? Comprendre cette vérification révèle aussi une question plus profonde. Qui contrôle les registres dont dépend cette vérification ?

Commencer par l’affirmation d’un réseau

Internet est un réseau de réseaux. Le BGP, Border Gateway Protocol, leur permet d’échanger des annonces indiquant comment atteindre des groupes d’adresses IP. Un tel groupe s’appelle un préfixe. Chaque réseau de routage exploité indépendamment est identifié par un numéro de système autonome, ou ASN.

Imaginez une entreprise de livraison annonçant : « Nous pouvons livrer dans ce quartier. » Les autres entreprises ont besoin d’un moyen de vérifier cette affirmation. En routage, une annonce incorrecte peut résulter d’une faute de frappe ou d’un détournement délibéré. Les annonces BGP ne prouvent pas à elles seules que le réseau désigné comme origine de la route est autorisé à l’annoncer.

Les rôles respectifs du RPKI, des ROA et de la validation

Le RPKI fournit un cadre de certificats pour les ressources de numérotation Internet. Un détenteur d’adresses peut publier une autorisation d’origine de route signée, ou ROA. Celle-ci identifie l’ASN autorisé à annoncer un préfixe donné et, lorsque cela est précisé, jusqu’à quel point cette plage d’adresses peut être subdivisée dans les annonces. La définition technique figure dans la RFC 9582.

Publier une ROA et vérifier les routes entrantes sont deux tâches distinctes. Les logiciels de validation vérifient les certificats et les enregistrements signés, puis transmettent les données d’autorisation vérifiées aux routeurs. Les routeurs comparent les annonces de routes à ces données ; les opérateurs choisissent la politique de routage à appliquer. Cette comparaison s’appelle la validation de l’origine des routes, ou ROV. Le guide opérateur du RIPE NCC explique cette division du travail.

Dans l’exemple de la livraison, une partie publie qui peut desservir le quartier ; d’autres vérifient cette autorisation. Un certificat constitue une preuve au sein de ce système. Il ne prouve pas que chaque livraison ultérieure sera sûre.

Trois résultats, pas un simple oui ou non

Valid : au moins une autorisation vérifiée couvre le préfixe annoncé et autorise à la fois l’ASN d’origine indiqué et la longueur du préfixe. Invalid : des autorisations couvrantes existent, mais aucune n’autorise cette combinaison. NotFound : aucune autorisation couvrante ne figure dans les données de validation.

NotFound ne signifie pas qu’un attaquant a été détecté. Invalid n’explique pas à lui seul si la cause est une attaque ou une erreur de configuration. Ces états décrivent la comparaison, telle qu’elle est définie dans la RFC 6811.

Ce que cette protection peut — et ne peut pas — vous dire

La validation de l’origine peut aider les réseaux à rejeter les origines non autorisées. Elle n’authentifie pas tous les réseaux situés le long d’une route, ne chiffre pas la connexion d’un visiteur et ne garantit pas qu’un site web restera disponible. Une fuite de route peut conserver une origine autorisée et passer cette vérification. Le filtrage et la surveillance ont encore leur rôle à jouer ; le RPKI n’est qu’un élément de la sécurité du routage.

Pour les opérateurs, une préparation utile commence par leurs annonces réelles : quels préfixes ils annoncent, par quels ASN et si les autorisations publiées correspondent. Maintenir ces enregistrements et les validateurs en fonctionnement compte autant que l’activation d’un paramètre sur un routeur. La RFC 7115 traite des considérations opérationnelles.

Les registres eux-mêmes constituent un point de pouvoir

La hiérarchie de confiance RPKI couramment utilisée suit l’attribution des ressources, les registres Internet régionaux se trouvant à ses racines. La vérification dépend donc de plus que de mathématiques solides : elle dépend aussi des autorités de certification et des systèmes de publication qui fournissent les registres.

Modifier ou retirer des registres peut modifier les résultats de validation. Il ne s’agit pas automatiquement d’une coupure d’Internet à l’échelle mondiale : l’effet dépend des autres autorisations disponibles et des politiques de routage des opérateurs. La RFC 8211 examine les actions préjudiciables et les erreurs des autorités de certification et des gestionnaires de dépôts. Un mécanisme de sécurité peut réduire un risque tout en créant des dépendances qui méritent d’être examinées.

L’argument de Lu Heng : protéger le réseau et limiter le gardien

Dans la Note 28, Pourquoi les registres ne doivent jamais devenir des agents coercitifs, Lu Heng trace une limite nette : tenir le carnet d’adresses ne doit pas se transformer en pouvoir de punir ses utilisateurs. Son objection porte sur l’autorité revendiquée par les administrateurs, et non sur la nécessité de disposer de registres exacts. Un petit groupe auto-désigné n’acquiert pas un mandat sur des réseaux répartis entre plusieurs continents simplement parce qu’il exploite le service de coordination dont ils dépendent.

La Note 64 développe son alternative : les règles partagées devraient couvrir le minimum nécessaire à l’unicité et à la sécurité, avec des preuves que les participants peuvent vérifier eux-mêmes. Les registres et les preuves devraient être portables ; les opérateurs devraient pouvoir remplacer un prestataire sans renoncer à leur identité réseau. Les modifications futures devraient être adoptées en raison de leur utilité, plutôt que par le contrôle administratif permanent.

Il s’agit d’une orientation pour reconstruire la coordination, et non de l’affirmation qu’un système RPKI alternatif est déjà déployé partout. Il doit encore préserver des enregistrements compatibles et une vérification fiable. La difficulté est d’obtenir les deux : une protection contre les fausses affirmations et une protection contre une autorité qui ne rend de comptes à personne sur les preuves.

Pourquoi cette question compte avant une panne

Les clients d’un réseau dépendent chaque jour de ses adresses familières. S’il ne découvre une dépendance qu’au moment où ses registres sont modifiés ou disparaissent, le rétablissement est déjà un problème de service en cours. L’argument de Lu Heng en faveur du changement commence ici : intégrer au système la continuité, la vérification indépendante et la possibilité de partir avant qu’un litige ne les rende nécessaires.

Pour suivre cet argument, de la critique à la conception, lisez la Note 64 de Lu Heng sur les règles partagées minimales, les décisions locales et l’adoption volontaire.