Comment fonctionne l’infrastructure à clé publique des ressources

La vérification exige des preuves entretenues : certificats, autorisations et systèmes de publication doivent rester cohérents à mesure que les réseaux évoluent.

Vous déplacez un service vers un nouveau réseau. Ses serveurs sont opérationnels, ses adresses n’ont pas changé, et pourtant certains visiteurs ne peuvent plus y accéder. Une cause possible est étonnamment limitée : les enregistrements de routage d’Internet autorisent encore l’ancien réseau à annoncer ces adresses.

La RPKI transforme cette autorisation en information vérifiable par d’autres réseaux. Voici comment elle circule du détenteur d’adresses au routeur — et pourquoi Lu Heng estime que le fonctionnement de cette infrastructure ne doit jamais dépendre du maintien au pouvoir d’un seul administrateur. Pour une introduction plus courte, commencez par ce que protège la RPKI.

1. Établir qui peut autoriser les adresses

Un groupe d’adresses IP est appelé un préfixe. Un réseau qui annonce ce préfixe s’identifie par un numéro de système autonome, ou ASN. La RPKI, l’infrastructure à clé publique des ressources, utilise des certificats pour établir qui peut émettre des autorisations pour certaines plages d’adresses.

Ces certificats forment une chaîne qui remonte jusqu’à une racine de confiance. La hiérarchie suit l’attribution des ressources de numérotation d’Internet, comme le décrit le RFC 6480. Elle fournit des preuves concernant les ressources de ce système ; elle ne confère pas à une autorité de certification un mandat politique sur les personnes qui utilisent Internet.

2. Publier une autorisation signée

Le détenteur des adresses publie une autorisation d’origine de route, ou ROA. Son message est précis : cet ASN peut être à l’origine de ce préfixe. Être à l’origine signifie être le réseau au début de la route annoncée, et non chaque réseau qui transporte ensuite le trafic.

Une ROA peut également définir une longueur maximale de préfixe : la mesure dans laquelle la plage d’adresses peut être divisée en plages annoncées plus petites. Sans ce paramètre facultatif, elle n’autorise que la longueur de préfixe indiquée. Cela empêche que l’autorisation pour cette plage devienne silencieusement une autorisation pour toutes ses subdivisions possibles. Le RFC 9582 définit cet enregistrement signé.

3. Transformer les enregistrements publiés en données vérifiées

Les enregistrements signés sont rendus accessibles dans des dépôts de publication. Les logiciels de validation les collectent et vérifient la chaîne de certificats, les signatures, les dates d’expiration et les informations de révocation, ainsi que les manifestes qui décrivent les objets publiés. Un simple fichier lisible ne suffit pas : les preuves qui l’accompagnent doivent elles aussi être validées.

Le validateur produit des données d’autorisation exploitables, souvent appelées charges utiles ROA validées, ou VRP. Elles contiennent le préfixe, l’ASN d’origine autorisé et la longueur maximale. Les routeurs reçoivent ces résultats d’un cache de confiance par le protocole RPKI-to-Router décrit dans le RFC 8210. Ils ne demandent pas l’autorisation à un registre chaque fois qu’un visiteur ouvre une page.

4. Comparer la route à l’autorisation

BGP est le protocole par lequel les réseaux annoncent des routes. Un routeur récepteur compare le préfixe et l’ASN d’origine d’une route avec les données d’autorisation validées dont il dispose. C’est la validation de l’origine des routes, ou ROV.

Valide : une autorisation couvrante permet à la fois cette origine et cette longueur de préfixe. Invalide : des autorisations couvrantes existent, mais aucune n’autorise cette combinaison. Non trouvé : aucune autorisation ne couvre le préfixe. Il s’agit de résultats de comparaison, et non de verdicts sur les intentions de quelqu’un. L’opérateur décide comment les utiliser dans sa politique de routage. Voir le RFC 6811.

Revenons au déplacement du service. Si l’ancien ASN est toujours autorisé et le nouveau ne l’est pas, la nouvelle annonce peut être invalide. Les réseaux qui filtrent les routes invalides peuvent la rejeter. La solution consiste à coordonner le changement d’autorisation avec le déplacement, y compris pendant toute période où les deux réseaux ont besoin d’une autorisation — et non à supposer que des serveurs opérationnels garantissent l’accessibilité. Le RFC 7115 traite des précautions opérationnelles.

5. Faire fonctionner toute la chaîne

La validation de l’origine aide à rejeter les fausses affirmations d’origine. Elle ne vérifie pas chaque saut, ne chiffre pas le trafic et ne détecte pas toutes les fuites de routes. Une fuite peut conserver une origine autorisée. D’autres protections de routage restent nécessaires.

Les preuves doivent également être entretenues. Les certificats expirent ; les autorisations et les données de publication changent. La suppression d’une ROA ne provoque pas nécessairement une panne immédiate : le résultat final de la validation dépend des autres enregistrements disponibles, et la conséquence sur le routage dépend de la politique locale. Le RFC 8211 examine la manière dont les erreurs ou les actions préjudiciables des autorités de certification et des opérateurs de dépôts peuvent affecter le système.

La proposition de Lu Heng : préserver le service, remplacer l’administrateur

Dans la Note 70, Lu Heng conteste un raccourci courant : parce qu’un service de registre est essentiel, son opérateur actuel devrait être irremplaçable. Les réseaux ont besoin d’enregistrements exacts et d’une sécurité opérationnelle. Cela n’établit pas le droit permanent d’une institution à les contrôler.

L’alternative qu’il propose fait de la continuité une propriété du système : des enregistrements contrôlables indépendamment, une passation testée vers un successeur qualifié et un moyen de transférer l’administration sans contraindre les réseaux à changer leurs adresses. Il reconnaît explicitement que la RPKI ne peut pas être transférée par la simple copie d’un répertoire. Les clés, les certificats, la publication et la confiance doivent rester cohérents pendant toute la transition.

Il s’agit d’une exigence de conception qu’il défend, et non de l’affirmation que cette portabilité est déjà disponible partout. Elle répond aux deux aspects du problème : un remplacement imprudent pourrait perturber la vérification ; un gardien irremplaçable peut transformer cette dépendance en pouvoir. La fiabilité du service et la possibilité de remplacer son administrateur doivent être conçues ensemble.

Pourquoi construire cette capacité avant une crise ?

Lorsqu’un différend atteint la chaîne de certificats, il peut toucher des personnes très éloignées des parties en conflit. Les clients n’ont pas choisi le différend, mais ils peuvent en supporter le coût sous la forme d’une connectivité perturbée. Un processus de succession improvisé pendant une panne arrive déjà trop tard pour les protéger contre cette incertitude.

Lu Heng propose donc d’établir à l’avance la continuité et le droit de partir, tout en empêchant que les différends administratifs deviennent une arme contre des réseaux opérationnels. Suivez l’argument complet dans la Note 70 : protéger le registre, pas le gardien.