Résumé

  • Le projet individuel draft-geng-sidrops-bgp-drip-00 décrit quatre mécanismes reliant détection locale, retour vers un RP, ROA marqué à risque et signal BGP entre routeurs.
  • Un ROA peut rester cryptographiquement valide tout en recevant un jugement opérationnel défavorable : l’autorisation d’origine et la confiance momentanée sont deux faits différents.
  • Avant toute adoption, il faut attribuer séparément l’observation, l’association, le transport, la politique locale, l’effet sur Local_Pref, l’expiration et le retour arrière.

La sécurité du routage souffre d’un problème réel. Une validation d’origine peut conclure qu’une annonce précise est invalide, tandis que d’autres routes du même AS d’origine, du même voisin ou d’un chemin comparable restent acceptables. Si l’anomalie révèle une compromission plus large, agir uniquement sur l’annonce initiale peut sembler trop étroit.

La version 00 de DRIP propose d’élargir la réaction. Le routeur pourrait associer l’annonce suspecte à d’autres chemins et réduire leur préférence locale. Il pourrait envoyer au relying party RPKI un message comportant le préfixe, l’origine ou le pair suspect, un identifiant de ROA et un code de motif. Le RP pourrait enrichir sa base de risque, puis distribuer un ROA accompagné de métadonnées de risque. Enfin, un attribut ou une communauté BGP pourrait transmettre ce jugement à un autre routeur.

Le mot important n’est pas « dynamique ». C’est « autorité ».

Chaque étape change la nature du fait. Le routeur observe une annonce. Une règle d’association en déduit que d’autres routes sont liées. Le RP transforme le rapport en état de risque. Un protocole transporte cet état. Le routeur destinataire décide d’en tirer une baisse de préférence. Si ces étapes sont condensées en une seule étiquette, le lecteur ne sait plus où se situe l’erreur éventuelle ni qui porte la décision.

Un ROA valide peut porter un avertissement défavorable

Le projet affirme explicitement qu’un enregistrement ROA marqué à risque peut conserver une signature cryptographique valide. Ce n’est pas une contradiction. Le ROA répond à une question d’autorisation d’origine. Le marquage répond à une question différente : des renseignements opérationnels suggèrent-ils un danger actuel ?

Le danger apparaît lorsque l’interface ou l’automatisation présente ces deux réponses comme un seul verdict. Une origine autorisée ne devient pas cryptographiquement invalide parce qu’un détecteur a observé un comportement suspect. Inversement, la validité du ROA ne garantit ni l’absence de fuite, ni l’intégrité du routeur d’origine, ni la qualité du chemin.

La trace d’audit doit donc conserver les deux plans. Elle doit montrer l’état ROV, le fait observé, le motif du risque, la confiance, l’auteur de l’évaluation et la politique qui a converti cette évaluation en action. Sans cette séparation, un jugement révocable acquiert l’apparence d’une propriété durable de l’objet RPKI.

L’association détermine qui paie

DRIP mentionne trois rapprochements : même AS d’origine, même voisin ou pair immédiat, ou motif similaire dans l’AS_PATH. Ces indices peuvent servir à enquêter. Ils ne prouvent pas une responsabilité commune.

Un AS peut annoncer les préfixes de clients indépendants. Un pair transporte des routes de nombreuses organisations. Un motif de chemin peut résulter de la topologie ordinaire. La détection initiale peut être exacte tandis que le groupe associé est excessif. À partir du moment où ce groupe reçoit une préférence inférieure, l’erreur analytique devient un impact de production.

Le projet recommande un plancher de Local_Pref et distingue le déclassement du filtrage dur. C’est utile, mais insuffisant. Une route moins préférée peut déplacer du trafic vers un chemin saturé, coûteux ou moins bien surveillé. En l’absence d’alternative viable, un déclassement « doux » peut produire une indisponibilité réelle. Le reçu opérationnel doit enregistrer les chemins alternatifs visibles, la variation exacte de préférence, les services touchés et la joignabilité mesurée après l’action.

Protéger le transport ne valide pas le jugement

Le texte reconnaît l’injection de faux risques comme vecteur de déni de service. Il demande une protection de la session RTR, recommande de filtrer la communauté aux frontières eBGP sauf accord bilatéral et impose un plancher de préférence pour éviter le blackholing total.

Ces protections défendent le canal et limitent la portée. Elles ne répondent pas à la question de fond. Une session TLS ou SSH peut transporter sans altération un jugement erroné. L’identité de l’émetteur ne démontre pas que son détecteur était correctement étalonné. Un accord bilatéral n’indique pas à lui seul comment la confiance est auditée, expirée ou révoquée.

Il manque encore une discipline pour l’habilitation des détecteurs, les preuves brutes, la fraîcheur, la répétition d’un signal, la contestation et le retrait. Une conception exploitable devrait permettre de remonter de chaque étiquette à l’observation originale et de retirer automatiquement l’effet lorsque le délai ou la confiance n’est plus valable.

Une proposition, pas un standard ni un déploiement

Le Datatracker ne liste que la version 00. Il la classe comme Internet-Draft individuel actif, sans stream RFC, sans statut RFC visé et sans soutien formel de l’IETF. Cette précision interdit de transformer les verbes normatifs du document en preuve d’un consensus.

La prudence vaut aussi pour les valeurs de protocole. Le projet propose les PDU RTR 0x0B et 0x0C et montre la version 2 dans son schéma. Le registre IANA courant attribue déjà le type 11 (0x0B) à ASPA pour la version 2 ; le type 12 reste non attribué. Le sous-type de la communauté opaque transitive BGP est encore « à déterminer », et aucun enregistrement IANA ne porte le nom proposé.

Ce constat n’est pas un rejet. Il montre que l’encodage et l’interopérabilité doivent encore être résolus. Aucun opérateur ne devrait traiter ces valeurs comme une allocation ou une capacité disponible chez les fournisseurs.

Le jugement final doit rester local

La doctrine de Lu Heng pose une frontière utile : un registre décrit la réalité, il ne la crée pas ; une alerte peut être une preuve sans devenir un mandat. Dans DRIP, le détecteur peut produire une observation, le RP peut enregistrer un risque et BGP peut transporter une métadonnée. L’autorité de modifier le trafic appartient néanmoins au réseau qui supporte les conséquences.

Cette propriété locale exige un dossier complet : identité et mandat du détecteur, observation horodatée, méthode de validation, règle d’association, confiance, protection du signal, portée de propagation, politique d’import, delta de préférence, alternatives, durée de vie, retrait, dérogation, rollback et mesure indépendante du service. Une étiquette sans ce dossier accélère la réaction en sacrifiant l’explication.

Le projet DRIP révèle correctement que l’autorisation cryptographique n’épuise pas le risque opérationnel. Sa réussite dépendra d’une autre séparation : coordonner une alerte sans centraliser le droit de décider. Le réseau receveur doit pouvoir expliquer, contester et annuler chaque conséquence.

Sources