Comment fonctionne l’infrastructure à clés publiques des ressources
Du détenteur des adresses au routeur, comment fonctionne RPKI — et pourquoi Lu Heng veut préserver le service tout en permettant de remplacer son administrateur.
Un service change d’opérateur. Les serveurs fonctionnent, les adresses IP restent les mêmes, mais une partie des visiteurs n’y accède plus. Parmi les causes possibles : les autorisations de routage désignent encore l’ancien réseau.
RPKI sert à rendre ces autorisations vérifiables. Pour comprendre son fonctionnement, suivons une permission depuis le détenteur des adresses jusqu’au routeur qui la consulte. Ce parcours éclaire aussi une question posée par Lu Heng : comment préserver la sécurité du réseau sans rendre son administrateur impossible à remplacer ? Pour découvrir d’abord le principe général, lire notre introduction à RPKI.
À qui revient le droit d’autoriser une annonce ?
Sur Internet, les réseaux annoncent les groupes d’adresses IP qu’ils permettent d’atteindre. Un tel groupe s’appelle un préfixe. Chaque réseau dispose d’un numéro de système autonome, l’ASN, qui l’identifie dans les annonces de routage.
RPKI, pour Resource Public Key Infrastructure, repose sur des certificats. Ils établissent qui peut délivrer des autorisations pour une plage d’adresses. Leur chaîne remonte jusqu’à une racine de confiance et suit la hiérarchie d’attribution des ressources numériques. Le RFC 6480 (en anglais) décrit cette architecture. Ce rôle technique ne confère pas, à lui seul, un mandat politique sur les utilisateurs d’Internet.
Le détenteur publie une autorisation signée
Cette autorisation s’appelle une ROA, pour Route Origin Authorisation. Elle associe un préfixe à l’ASN autorisé à en être l’origine. Il s’agit du réseau dont part l’annonce, pas de tous les réseaux traversés ensuite par les données.
La ROA peut préciser jusqu’où le préfixe peut être découpé en plages plus petites dans les annonces. C’est sa longueur maximale. Sans cette option, seule la longueur du préfixe indiqué est autorisée. Autoriser une plage entière ne revient donc pas à autoriser toutes ses subdivisions possibles. Le format est défini dans le RFC 9582 (en anglais).
Un validateur contrôle les preuves
Les objets signés sont publiés dans des dépôts. Un logiciel de validation les récupère et contrôle les signatures, la chaîne de certificats, leur validité dans le temps et les informations de révocation. Il vérifie aussi les manifestes, qui décrivent les objets publiés. Pouvoir télécharger une autorisation ne suffit donc pas : les preuves qui la soutiennent doivent rester valables.
Le validateur en tire des données exploitables : le préfixe, l’ASN autorisé et la longueur maximale. On les appelle les VRP, pour Validated ROA Payloads. Les routeurs les reçoivent d’un cache de confiance, au moyen du protocole RPKI-to-Router décrit dans le RFC 8210 (en anglais). Aucun registre n’est interrogé à chaque fois qu’un internaute ouvre une page.
Le routeur compare ; l’opérateur choisit sa politique
BGP est le protocole utilisé par les réseaux pour échanger leurs annonces de routes. Le routeur qui reçoit une annonce compare son préfixe et son ASN d’origine aux autorisations validées. C’est la validation de l’origine des routes, ou ROV.
Valid : une autorisation couvrant le préfixe permet cette origine et cette longueur. Invalid : des autorisations couvrent le préfixe, mais aucune ne permet cette combinaison. NotFound : aucune ne couvre le préfixe. Ces résultats ne disent pas si quelqu’un a commis une erreur ou tenté une attaque. L’opérateur décide des règles à appliquer. Voir le RFC 6811 (en anglais).
Reprenons le changement d’opérateur. Si l’ancien ASN reste autorisé, mais pas le nouveau, l’annonce du nouveau réseau peut être classée Invalid. Les réseaux qui filtrent ces annonces risquent alors de la refuser. Il faut préparer le changement d’autorisation avec la migration, y compris la période où les deux réseaux pourraient en avoir besoin. Des serveurs en bon état ne suffisent pas à rendre un service accessible. Le RFC 7115 (en anglais) présente les précautions d’exploitation.
La sécurité dépend d’une chaîne qui reste opérationnelle
Ce contrôle aide à écarter les fausses déclarations d’origine. Il ne vérifie pas tout le trajet, ne chiffre pas les échanges et ne détecte pas toutes les fuites de routes : une route diffusée là où elle ne devrait pas l’être peut conserver une origine autorisée.
Les preuves, elles aussi, doivent être entretenues. Les certificats expirent, les autorisations évoluent. Retirer une ROA ne provoque pas forcément une panne immédiate : le résultat dépend des autres données disponibles, puis de la politique de chaque réseau. Le RFC 8211 (en anglais) analyse les effets possibles d’erreurs ou d’actions dommageables des autorités de certification et des opérateurs de dépôts.
Pour Lu Heng, un service indispensable doit pouvoir changer de mains
Dans sa Note 70, Lu Heng conteste l’idée qu’un organisme deviendrait irremplaçable parce qu’il assure une fonction essentielle. Les réseaux ont besoin de registres exacts et d’une sécurité qui fonctionne. Cela ne donne pas à une institution le droit de les contrôler indéfiniment.
Il propose d’organiser la continuité autrement : des enregistrements vérifiables de manière indépendante, une relève préparée et testée, et la possibilité de confier l’administration à un successeur qualifié sans changer les adresses des réseaux. Il souligne que, pour RPKI, copier des fichiers ne suffit pas. Les clés, les certificats, la publication et la confiance doivent rester cohérents pendant le passage de relais.
C’est une exigence qu’il défend pour l’avenir, pas une possibilité déjà offerte partout. Remplacer un opérateur sans préparation peut casser la vérification. Mais le rendre impossible à remplacer lui donne un moyen de pression. Il faut donc concevoir ensemble la fiabilité du service et la possibilité de quitter son administrateur.
Pourquoi ne pas attendre le prochain incident ?
Lorsqu’un conflit touche la chaîne de certification, ses conséquences peuvent dépasser les parties concernées. Des clients étrangers au litige risquent d’en subir les effets sur leur connexion. Improviser une relève en pleine panne ne les protège pas de cette incertitude.
Lu Heng veut que la continuité et la liberté de changer d’administrateur soient prévues en amont, pour qu’un différend administratif ne serve pas à mettre en péril des réseaux en activité. Lire son raisonnement complet dans la Note 70 : préserver le registre, sans rendre son gestionnaire irremplaçable (texte original en anglais).