Résumé

  • Dans une ROA, maxLength fixe la longueur maximale qu’un AS est autorisé à annoncer; il ne décrit pas les routes plus spécifiques réellement voulues.
  • Une autorisation trop étroite peut rendre invalide une désagrégation pourtant approuvée; une autorisation trop large peut rendre valide un préfixe jamais approuvé.
  • Un registre d’intention doit relier chaque préfixe à son AS, sa finalité, sa période d’activation, la modification de ROA, l’observation de propagation, le responsable du retrait et l’échéance du retour arrière.

Le plan d’urgence paraît simple. Un réseau annonce normalement 203.0.0.0/16 depuis l’AS 64496 et sa ROA couvre exactement ce /16. Pendant une attaque, l’équipe souhaite annoncer 203.0.113.0/24 afin de détourner un service vers un dispositif d’atténuation. La décision BGP est autorisée en interne, mais la modification RPKI n’a pas été préparée. Pour un réseau qui applique la validation d’origine, le /24 peut être Invalid: il dépasse la longueur permise.

Il serait facile d’élargir la ROA en indiquant le /16 avec maxLength 24. Le /24 d’urgence devient alors valide. Mais cette écriture autorise aussi l’AS désigné à être l’origine de chacun des 256 /24 contenus dans le /16. Le champ ne sait pas lesquels sont exploités, surveillés ou approuvés. La correction d’un oubli ponctuel crée ainsi une permission cryptographique durable et beaucoup plus vaste.

La définition de RFC 9582 ne prête pourtant pas à confusion. Une ROA exprime l’autorisation donnée à un AS d’originer les préfixes qui y figurent. L’élément facultatif maxLength fixe la longueur la plus spécifique autorisée. Sans lui, seule la longueur du préfixe inscrit est permise. Ni le motif commercial, ni la fenêtre de changement, ni le ticket d’incident, ni la date de retrait ne font partie de l’objet.

RFC 6811 délimite tout autant le résultat. La validation rapproche la route reçue des charges utiles ROA validées qui la couvrent, de son AS d’origine et de la longueur maximale autorisée. Elle produit un état d’origine. Elle ne certifie pas le chemin AS complet, la livraison des paquets, le bénéfice de l’ingénierie de trafic ou l’autorité humaine ayant demandé l’annonce.

L’autorisation minimale rend l’intention vérifiable

RFC 9319 recommande, chaque fois que possible, des ROA minimales: elles ne couvrent que les préfixes effectivement originés en BGP. Le texte recommande en général d’éviter maxLength, tout en décrivant des cas particuliers où son emploi peut se justifier. La nuance est essentielle. Il ne s’agit pas d’interdire une fonction du format, mais d’empêcher qu’une commodité remplace la liste réelle des origines voulues.

Imaginons qu’un opérateur annonce le /16 et quatre /24 précis pour ses entrées régionales. Quatre autorisations exactes exposent ce dessin. Un seul couple /16–24 autorise bien ces routes, mais il inclut aussi 252 autres /24 à cette longueur. Le système ne distingue plus le plan des espaces inutilisés. Comme la validation d’origine n’authentifie pas tout l’AS_PATH, une fausse route peut placer l’AS autorisé à l’extrémité d’un chemin fabriqué et viser un sous-préfixe non annoncé.

Les objets exacts imposent une discipline: avant une nouvelle origine, le détenteur des ressources, l’équipe routage, la sécurité et le prestataire éventuel doivent s’entendre sur le préfixe, l’AS et la durée. Cette coordination a un coût. Elle produit aussi la preuve qui manque à maxLength: qui a voulu cette origine, pour quel service et jusqu’à quand.

L’urgence exige un ordre d’exécution

L’atténuation DDoS montre pourquoi une règle absolue serait maladroite. Un fournisseur peut demander une route plus spécifique, un autre AS d’origine ou une route de rejet à destination. RFC 9319 examine ces exceptions. La bonne préparation consiste à connaître à l’avance les exigences exactes du fournisseur et à tester l’enchaînement entre autorisation et annonce.

L’équipe confirme d’abord le préfixe et l’AS. Elle crée ou remplace la ROA. Elle attend que des validateurs indépendants montrent la charge utile attendue. Elle annonce ensuite la route dans un périmètre maîtrisé, observe son état et sa propagation, puis élargit si le résultat est conforme. À la fin de l’événement, elle retire la route, en vérifie la disparition, puis retire l’autorisation temporaire selon le calendrier prévu.

Ces systèmes n’avancent pas sur une horloge unique. Publication RPKI, collecte des dépôts, validation, livraison aux routeurs et propagation BGP peuvent converger à des moments différents. Les RFC ne prouvent pas non plus la politique appliquée par chaque réseau. RFC 7115 traite donc l’introduction de la validation comme un changement d’exploitation: il faut observer, comprendre les exceptions locales et graduer les conséquences.

Sources