Le rôle de RPKI dans le renforcement de la sécurité du routage mondial
RPKI peut aider les réseaux à rejeter les origines de routes non autorisées. Suivez les éléments partagés, les décisions locales et les dépendances opérationnelles qui déterminent son effet réel.
Chaque réseau vérifie les éléments partagés. Leur effet dépend des données reçues et des politiques appliquées.
Une erreur de routage dans un réseau peut affecter des personnes très éloignées. Lorsqu’une origine incorrecte se propage, un site web opérationnel peut devenir inaccessible ou du trafic peut être dirigé vers une destination non prévue. RPKI donne aux réseaux qui reçoivent une annonce un moyen d’en vérifier un aspect avant de s’y fier.
Son intérêt tient à une chaîne d’actions : un titulaire publie une autorisation exploitable, un logiciel la vérifie et un opérateur applique une politique de routage. Comprendre cette chaîne permet de saisir à la fois la protection apportée et les points où elle peut échouer.
Que vérifie-t-on ?
Les réseaux échangent des informations de joignabilité au moyen de BGP. Un préfixe est un bloc d’adresses IP ; un ASN identifie un système autonome. Une autorisation d’origine de route, ou ROA, indique quel ASN le titulaire autorise à être à l’origine de routes pour des préfixes spécifiés.
Un logiciel de validation vérifie les enregistrements signés et les certificats, puis fournit des données d’autorisation validées. Un routeur compare l’origine d’une route et la longueur de son préfixe à ces données. L’opérateur décide de la suite à donner au résultat. Cette répartition distingue la publication des enregistrements, la validation des éléments probants et les décisions de routage.
Trois résultats aux significations différentes
- Valid : au moins une autorisation couvrant le préfixe permet l’origine et la longueur de préfixe annoncées.
- Invalid : des données d’autorisation couvrant le préfixe existent, mais aucune entrée ne permet cette combinaison.
- NotFound : les données utilisées ne contiennent aucune autorisation couvrant la route.
Ces règles proviennent de la RFC 6811. En particulier, l’absence de ROA couvrant le préfixe n’équivaut pas à une route Invalid. De même, l’état Valid ne signifie pas que l’ensemble du chemin annoncé a été authentifié.
Où la protection agit-elle ?
Si un réseau qui reçoit des annonces rejette celles qui sont Invalid, une origine en contradiction avec les autorisations peut y être arrêtée au lieu d’être propagée au-delà par ce réseau. L’effet dépend des autorisations, des données disponibles et de la politique effectivement déployée. Publier davantage de ROA et amener davantage de réseaux à utiliser la validation d’origine sont deux formes d’adoption liées, mais distinctes.
La RFC 8481 explicite le rôle de l’opérateur : attribuer un état de validation est une opération distincte de la décision prise en fonction de cet état. Il n’existe pas d’interrupteur mondial unique qui ferait appliquer simultanément la même politique à tous les réseaux.
Une route ayant fait l’objet d’une fuite peut conserver une origine autorisée. Un chemin falsifié peut également préserver cette valeur d’origine. La validation d’origine laisse donc subsister des risques importants pour le routage ; les opérateurs ont toujours besoin d’autres contrôles et d’une visibilité sur la propagation des routes.
Le système de preuves exige lui aussi de l’attention
Une autorisation désignant le mauvais ASN ou excluant une longueur de préfixe prévue peut entraîner le classement d’une annonce de route légitime comme Invalid. Des problèmes de dépôt, de certificat ou de validateur peuvent également modifier les données disponibles pour les routeurs. La diversité des caches et des moments de mise à jour signifie que les réseaux n’ont pas nécessairement la même vue au même instant.
La préparation pratique comprend des autorisations précises, des changements de routage testés, des validateurs surveillés et une procédure documentée en cas de données périmées ou manquantes. Un second validateur n’est utile que dans la mesure où il réduit les défaillances auxquelles vous cherchez à résister. Il n’élimine pas toutes les dépendances communes. La RFC 7115 traite de l’exploitation ; la RFC 8211 examine les actions préjudiciables au sein du système de publication et de certification RPKI.
La protection ne doit pas devenir une dépendance permanente
C’est aussi une question de conception institutionnelle. Un organisme qui contrôle des éléments de preuve essentiels peut affecter des réseaux qu’il n’exploite pas et qu’il ne représente pas politiquement. Dans la Note 28, Lu Heng soutient que la fonction de registre doit rester une activité administrative exacte, plutôt que devenir un moyen de coercition.
Sa Note 64 fixe une ambition de conception plus exigeante : les règles communes devraient être minimales et vérifiables localement, les enregistrements devraient être portables et les changements futurs devraient dépendre de leur adoption volontaire par les participants. La sécurité et la capacité à remplacer un coordinateur défaillant doivent être conçues ensemble.
L’urgence est concrète. Une fois que les utilisateurs ont perdu l’accès, découvrir qui contrôle un enregistrement nécessaire devient une urgence. Retracez ces dépendances tant que les réseaux fonctionnent. Poursuivez ensuite avec la manière dont une modification d’enregistrement peut entraîner le rejet d’une route.