Résumé

  • Publié le 20 août, le projet individuel DOA relie par signature RPKI des préfixes, des longueurs, un AS d’origine, des relais facultatifs et des communautés BGP autorisées.
  • Le résultat DOA resterait distinct de ROV et ne commanderait aucune action par défaut ; le texte n’est pas adopté par l’IETF et conserve des sections de sécurité, d’exploitation et de transport inachevées.

Une route de blackholing est volontairement extrême : elle demande au réseau amont de jeter le trafic vers une destination afin que l’attaque n’atteigne pas le lien de la victime. Pour viser finement la destination, l’annonce est souvent plus spécifique que le préfixe ordinaire. C’est précisément ce qui peut la rendre Invalid lors de la validation d’origine RPKI si elle dépasse le maxLength autorisé par la ROA.

Le document draft-spaghetti-grow-rpki-doa-00, daté du 20 août, cherche à ne plus faire porter les deux fonctions par la même autorisation. Une Discard Origin Authorization serait un objet signé dans la RPKI. Le détenteur du bloc d’adresses y indiquerait l’AS d’origine habilité, les plages et longueurs de préfixe, les communautés Classic ou Large qui signalent le rejet et, le cas échéant, les AS pairs autorisés à relayer la demande.

Le statut du document fixe une limite essentielle. Le Datatracker le classe comme Internet-Draft individuel, sans approbation de l’IETF ni place formelle dans le processus de normalisation. Il reprend un texte publié en 2022 sous un nom visant SIDROPS et le redirige vers GROW. Cette destination éditoriale ne vaut pas adoption par le groupe de travail.

La révision ferme néanmoins une ambiguïté ancienne. Le texte de 2022 demandait encore si plusieurs communautés devaient être évaluées avec un « et » ou un « ou ». La version actuelle choisit le « ou » logique : une seule communauté listée et présente sur la route suffit pour cette partie du test. Si l’émetteur n’en fournit aucune, l’outil de signature peut utiliser par défaut la communauté BLACKHOLE bien connue de la RFC 7999.

La communauté n’est toutefois qu’un des contrôles. Pour obtenir l’état Matched, la route doit provenir de l’AS indiqué, respecter une longueur permise, être reçue directement de cet AS ou d’un peerAsID autorisé, et contenir au moins une communauté prévue. Les autres résultats seraient Unmatched lorsqu’un objet couvre le préfixe sans satisfaire ses contraintes, et NotFound lorsqu’aucun objet validé ne le couvre.

Ces états ne remplacent pas ROV. Le projet prévoit qu’une demande légitime puisse être DOA Matched tout en restant ROV Invalid, car les deux évaluations répondent à des questions différentes. Le traitement DOA pourrait intervenir tôt ; une route sans correspondance retomberait ensuite dans la politique ordinaire, y compris la validation d’origine. Surtout, une implémentation conforme ne devrait prendre aucune décision de routage par défaut à partir du seul état DOA ou ROV.

Cette règle maintient le contrôle chez l’opérateur. Une signature prouve l’existence d’une autorisation liée aux ressources ; elle ne prouve ni l’existence d’une attaque, ni l’intention réelle de l’annonceur, ni la sûreté de tout le chemin AS. Le réseau récepteur doit encore décider s’il installe la route de rejet, la journalise, la refuse ou demande une confirmation supplémentaire.

La propagation reste également bornée. La RFC 7999 déconseille en général d’exporter une route de blackholing au-delà de l’AS qui la reçoit. Le projet n’ouvre une exception que si l’AS local apparaît explicitement dans la liste facultative des pairs. Cela autorise un relais d’un saut ; cela ne crée pas une permission transitive illimitée.

L’intérêt structurel apparaît face à l’autre solution : élargir le maxLength d’une ROA pour rendre valide la route plus spécifique. Une telle modification étend aussi l’autorisation d’origine ordinaire. La RFC 9319 met en garde contre les longueurs maximales trop larges. DOA pourrait donc isoler l’urgence sans agrandir le périmètre de la ROA.

Mais le chemin de déploiement n’est pas défini. Le transport des charges DOA par RPKI-RTR est renvoyé à un autre document. Les sections consacrées à l’exploitation et à la sécurité ne sont pas encore rédigées. Les identifiants IANA ne sont pas attribués. Un outil de signature Python est cité, sans vérification indépendante ni preuve d’interopérabilité avec un validateur et un routeur.

La nouvelle publication rend ainsi le partage des responsabilités plus lisible, pas encore opérationnel. Le détenteur de ressources exprimerait une autorisation limitée ; l’infrastructure RPKI la distribuerait ; l’opérateur conserverait la décision. La valeur réelle dépendra de la révocation, de la fraîcheur des objets et de la cohérence des implémentations, autant que du format signé lui-même.

Sources