Résumé
- Dans le RFC 7115, Randy Bush demande de vérifier les ROA de chaque sous-allocation annoncée par un autre AS avant de signer le bloc supérieur. Une annonce cliente oubliée peut alors recevoir l’état Invalid.
- L’effet se propage par les caches RPKI jusqu’aux routeurs, où la politique locale traite les états de validation. Bush recommande plusieurs caches, dont un local, et une synchronisation régulière.
Le grand bloc et ses locataires
Une bonne intention peut arriver dans le mauvais ordre. Le détenteur d’un vaste bloc IP décide de publier un ROA couvrant. Son client, qui annonce une sous-allocation depuis son propre AS, poursuit son activité. Puis le nouveau ROA se répand. Sur un routeur validant les origines, la petite annonce peut passer à Invalid. La décision a été prise à l’étage du propriétaire; le voyant s’allume chez le locataire.
Randy Bush formule la précaution dans le RFC 7115, texte de bonnes pratiques opérationnelles publié en janvier 2014. Avant de produire un ROA pour un super-bloc, l’opérateur doit s’assurer que les sous-allocations annoncées par d’autres AS, notamment ceux des clients, disposent des bons ROA. Les annonces sans cette couverture deviennent Invalid. Le document propose aussi une solution de transition : alimenter provisoirement les ROA à partir des données BGP observées pendant que les bénéficiaires enregistrent les leurs. L’inventaire précède la signature.
Le calcul est exposé dans le RFC 6811. Un routeur compare le préfixe annoncé et son AS d’origine aux données de ROA validées. Il obtient Valid, NotFound ou Invalid. Quand l’autorisation couvrante apparaît, une annonce plus spécifique peut entrer en conflit avec l’AS ou la longueur qu’elle permet. Chaque réseau décide ensuite dans sa politique de routage de l’usage de cet état. Là où la règle rejette Invalid, l’erreur de préparation prend un poids immédiat.
La donnée n’arrive pas au routeur par télépathie. Le RFC 6810, signé par Bush avec Rob Austein, définit le protocole entre cache validateur et routeur. Le RFC 7115 conseille à un routeur plusieurs caches, dont au moins un local. Lorsque les caches locaux alimentent les décisions de routage, ils devraient se synchroniser au moins toutes les quatre à six heures. Un réseau qui reçoit les données d’un cache en amont devrait les revérifier. La signature, sa diffusion et la décision locale forment une seule chaîne de responsabilité.
La biographie publiée par RIPE NCC situe Bush dans des décennies de travail sur la sécurité du routage, la RPKI et la validation d’origine. Son texte préfère les gestes vérifiables aux slogans : dresser la liste des sous-allocations, corriger les ROA, puis publier le parent. Sa photographie nominative chez RIPE NCC sert de référence au portrait de cet article; les deux baies de routeurs en arrière-plan sont imaginées.
Le détail qui mérite de rester sur le bureau n’a rien d’exotique : une liste de clients, de préfixes et d’AS annonciateurs. Une entrée manquante peut modifier l’étiquette qu’un routeur attribue à une annonce légitime. Bush traite cette liste comme un contrôle de production. Elle évite que l’opérateur célèbre la signature d’un grand bloc pendant que ses clients cherchent pourquoi le voyant a changé de couleur.
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance





