Pourquoi les opérateurs réseau ont besoin d’une autorisation d’origine de route (ROA)
Un ROA indique quel réseau peut être à l’origine d’une route. Découvrez comment le préparer, vérifier son effet et changer de réseau sans confondre enregistrement signé et acheminement garanti.
Une autorisation d’origine relie un bloc d’adresses à un réseau autorisé à l’annoncer. Elle ne garantit pas l’ensemble du trajet.
Vos adresses n’ont pas changé, mais vous souhaitez qu’un autre réseau les annonce. La nouvelle connexion est prête. Le reste d’Internet acceptera-t-il la route ? L’autorisation d’origine de route, ou ROA, est l’un des enregistrements dont il faut vérifier l’exactitude avant ce changement.
Elle permet au titulaire d’adresses d’indiquer quel système autonome peut être à l’origine de routes pour un préfixe, c’est-à-dire un bloc d’adresses IP. Cette déclaration fournit aux autres réseaux un élément à vérifier. Elle n’annonce pas la route, ne transporte pas de paquets et ne garantit pas que tous les fournisseurs l’accepteront.
Partir de l’annonce que vous comptez émettre
Un système autonome est un réseau doté de sa propre politique de routage et identifié par un ASN. L’ASN d’origine est celui qui figure comme point de départ de la route annoncée. Le système autonome d’origine n’est pas nécessairement exploité par l’organisation enregistrée comme titulaire des adresses.
Avant de publier une autorisation, identifiez le préfixe, l’ASN d’origine prévu et les éventuels préfixes plus spécifiques que vous comptez effectivement annoncer. Le format ROA défini dans la RFC 9582 associe un ASN à des préfixes et à leurs longueurs maximales autorisées. Un préfixe plus long décrit un bloc d’adresses plus petit.
Par exemple, autoriser un /24 donné n’est pas la même chose qu’autoriser tous les blocs plus petits qu’il contient. Une valeur maxLength inutilement large accorde davantage de latitude que ne l’exige l’annonce actuelle. La RFC 9319 explique pourquoi les opérateurs doivent veiller à la précision de cette autorisation.
Publier et vérifier sont deux tâches distinctes
Un titulaire publie des éléments d’autorisation signés au moyen de son dispositif RPKI. Le logiciel de validation d’un réseau qui reçoit les annonces vérifie ces éléments et produit un ensemble d’enregistrements validés. Ses routeurs peuvent s’appuyer sur ces enregistrements pour comparer les origines des routes reçues. L’opérateur configure la manière dont le résultat influe sur le routage.
Une origine correspondante et une longueur de préfixe autorisée donnent l’état Valid. Lorsque des autorisations couvrent le préfixe mais qu’aucune ne permet à la fois l’origine et la longueur de préfixe annoncées, le résultat est Invalid. L’absence d’autorisation couvrant le préfixe donne l’état NotFound. Ces trois états permettent de distinguer un enregistrement manquant d’un enregistrement contradictoire. Un ROA présent dans un dépôt ne bloque pas, à lui seul, une fausse annonce partout.
Effectuer le changement dans le bon ordre
Si un bloc d’adresses doit passer à une autre origine, préparez l’autorisation nécessaire avant de vous appuyer sur la nouvelle annonce. Lorsque les deux origines sont délibérément utilisées pendant une transition, les autorisations doivent refléter ce plan. Observez les données qui parviennent aux validateurs et aux réseaux recevant les annonces, puis confirmez les routes effectives et la joignabilité. Retirez les autorisations obsolètes lorsqu’elles ne sont plus nécessaires.
Il n’existe pas d’instant universel auquel tous les routeurs voient un nouvel enregistrement. La publication RPKI, la validation et les mises à jour des routeurs suivent leurs propres délais ; réduire un TTL DNS ne permet pas de les contrôler. La RFC 7115 traite des différences de fonctionnement entre les caches et des décalages de mise à jour.
Testez les origines et les longueurs de préfixe erronées dans un laboratoire isolé. En production, surveillez les routes prévues, les données de validation, l’état des sessions et les politiques appliquées par vos fournisseurs. Des validateurs redondants aident à faire face aux défaillances individuelles, mais leurs sources de données, leurs logiciels et leurs configurations peuvent encore présenter des dépendances communes.
Conserver les autres vérifications
La validation d’origine n’authentifie pas l’intégralité du chemin AS, n’arrête pas toutes les fuites de routes et ne chiffre pas le trafic des utilisateurs. Les filtres de préfixes, les relations de routage et les autres contrôles d’exploitation restent importants. Si une route ne fonctionne pas, examinez précisément la discordance et la politique du réseau qui la reçoit ; supprimer toute validation ou supposer que chaque route Invalid est une attaque ne constitue pas un diagnostic sérieux.
La sécurité doit servir les personnes qui exploitent le réseau
Dans la Note 28, Lu Heng soutient que la tenue des enregistrements essentiels ne doit pas devenir un moyen de sanction discrétionnaire. Une autorisation signée utile est une assertion technique ; elle ne donne pas un mandat illimité à l’institution qui tient les enregistrements associés.
Dans la Note 64, il plaide pour des règles communes vérifiables localement, des données de coordination portables et la liberté des participants de choisir les changements futurs qu’ils adopteront. Pour les opérateurs réseau, l’enjeu est la continuité : savoir de quels enregistrements dépend leur service, qui peut les modifier et comment des éléments probants exacts pourraient rester utilisables en cas de défaillance d’un coordinateur.
Poursuivez avec les raisons pour lesquelles un préfixe IPv4 change d’ASN d’origine afin de distinguer un changement de routage d’un changement de titulaire.