Résumé

  • Pour LACNIC, un ROA est un objet signé reliant des préfixes à l’AS autorisé à les annoncer ; le service RPKI hébergé permet aux membres de l’utiliser sans exploiter leur propre autorité de certification.
  • Analyse BTW : le contrôle devient opérationnel lorsque les ROA restent cohérents avec BGP, que leurs effets sont vérifiés et que la validation d’origine est déployée avec observation et redondance.

Sources : FAQ RPKI de LACNIC, bonnes pratiques RPKI, quinze ans de RPKI et FAQ RPKI et IRR.

Une attestation d’origine volontairement limitée

LACNIC présente RPKI comme une infrastructure à clé publique qui fournit aux opérateurs du matériel cryptographique pour vérifier le droit d’un client à utiliser certaines ressources Internet. Une autorisation d’origine de route associe un ou plusieurs préfixes IP au système autonome admis à les annoncer dans BGP.

Cette preuve est précise, mais elle ne certifie pas toute la route. La FAQ de LACNIC indique que RPKI ne remplace pas un registre de routage Internet, car un IRR conserve notamment l’enregistrement de politiques par ASN. Le bilan publié en 2026 distingue également la validation de l’origine, objectif initial du système, de la validation d’autres éléments du chemin.

Le mode hébergé abaisse un seuil technique

LACNIC propose des modes RPKI hébergé et délégué. Avec le service hébergé, un membre peut effectuer les opérations RPKI sans maintenir sa propre autorité de certification. Cette simplification ne décide toutefois ni des préfixes que ses ROA doivent couvrir, ni des AS d’origine qui doivent y figurer.

Analyse BTW : cette frontière sépare l’autorisation adossée au registre de l’exécution par le réseau. LACNIC peut exploiter l’infrastructure de certification et publier des recommandations ; le détenteur des ressources reste responsable de l’exactitude des ROA, tandis que chaque opérateur choisit l’effet des données validées sur son routage.

La qualité dépend de la discipline de changement

Les bonnes pratiques de LACNIC recommandent de faire correspondre les ROA aux préfixes réellement annoncés dans BGP, sans étendre inutilement leur portée. Elles mettent en garde contre un maxLength trop permissif, invitent à vérifier qu’une modification n’a pas rendu de routes invalides et conseillent plusieurs validateurs pour la redondance.

Pour un premier déploiement de la validation d’origine, le parcours proposé est progressif : observer les états de validité, marquer les annonces ou ajuster les préférences, puis rejeter les annonces invalides lorsque la configuration est suffisamment maîtrisée.

La logique opérationnelle apparaît dans cette séquence. RPKI fournit un moyen structuré de distinguer une origine autorisée d’une origine non autorisée, mais sa valeur dépend d’une maintenance régulière, de changements observables et d’un mécanisme de retour arrière. Une autorisation ancienne ou trop large peut affaiblir le contrôle même lorsque sa signature est valide.

Ce que les sources ne démontrent pas

Les documents cités ne prouvent ni une couverture ROA complète chez tous les membres de LACNIC, ni le rejet des routes invalides par tous les réseaux. Ils ne disent pas non plus qu’une origine valide rend une route joignable ou sûre de bout en bout. Leur conclusion est plus étroite : LACNIC fournit une infrastructure et des pratiques pour prouver et vérifier l’autorité d’origine.