Résumé

  • Le troisième article de la série IRR Landscape de RIPE Labs s’appuie sur des mesures de trafic à AMS-IX et DE-CIX pour examiner ce que RPKI peut remplacer.
  • Sa conclusion sépare deux classes : les objets ROUTE(6) de tiers peuvent largement disparaître dans les scénarios étudiés; les AS-SET de tiers restent nécessaires à la génération de filtres BGP.
  • Il ne s’agit ni d’une instruction générale de supprimer l’IRR ni d’une preuve qu’une ROA décrit un cône client. ASPA est présenté comme un relais possible, pas comme un mécanisme déjà largement déployé.

Le même sigle cache deux fonctions

Parler de « l’IRR » au singulier peut masquer la question décisive : quelle donnée est consommée, et pour quel contrôle ? Un objet ROUTE ou ROUTE6 relie un préfixe à une origine. Un AS-SET aide à retrouver un ensemble de systèmes autonomes et à construire, dans certains outils, une vision du cône client. Les deux peuvent participer à une chaîne de filtrage; ils ne prouvent pas la même chose.

Le nouvel article de RIPE Labs met cette différence à l’épreuve avec des mesures de trafic d’AMS-IX et DE-CIX. Il compare la configuration de production à des scénarios qui réduisent certaines classes de données IRR tierces et introduisent de l’information dérivée de RPKI. La conclusion est volontairement inégale : les ROUTE(6) tiers peuvent largement être abandonnés, tandis que les AS-SET tiers restent essentiels à la génération de filtres BGP.

Le terme « largement » n’est pas une permission sans limite. L’article n’annonce pas qu’un opérateur précis a changé son filtrage, ni qu’un registre a imposé une nouvelle règle. Il explique que les ROA peuvent remplacer les objets ROUTE/ROUTE6 lorsque la couverture existe. La condition empêche de transformer un résultat d’étude en déclaration sur tous les réseaux.

Une autorisation d’origine n’est pas une carte de relations

La persistance des AS-SET est la moitié du résultat. Un cône client ne se réduit pas à l’autorisation d’un ASN à annoncer un préfixe. Il organise un ensemble relationnel utilisé dans la construction de filtres. L’étude voit dans ASPA le successeur possible de cette fonction, tout en précisant que la standardisation et le déploiement ne sont pas encore suffisamment larges.

La formule exacte n’est donc pas « RPKI remplace l’IRR ». Elle est plus utile : une classe d’objets peut changer de rôle dans un contexte testé sans que l’autre perde le sien. Une ROA ne prouve ni la politique bilatérale, ni la joignabilité, ni le trafic, ni l’intégralité d’un cône. Inversement, conserver un AS-SET ne démontre pas que chaque objet ROUTE(6) tiers reste nécessaire.

Rendre visible le retrait partiel

Un opérateur qui évalue un retrait de données tierces gagnerait à publier un relevé court mais précis : classe d’objet et classe de source touchées; fonction de routage; condition de couverture RPKI et de données IRR faisant autorité; scénario; période d’évaluation; limites; périmètre constaté; déclencheur de retour en arrière; corrections éventuelles.

Le relevé devrait aussi dire ce qui demeure. Si les AS-SET tiers restent requis pour le cône client, un récit sur le seul retrait de ROUTE(6) peut devenir trompeur. L’information dérivée de RPKI peut être une composante d’essai, sans devenir la preuve d’une politique relationnelle non testée.

Cette proposition n’est pas une obligation de RIPE NCC, d’AMS-IX ou de DE-CIX. Elle préserve seulement la frontière mise en évidence par l’étude : le retrait d’une preuve de préfixe-origine n’est pas le retrait d’une preuve de relation.

Portée des sources

RIPE Labs établit le cadre étudié et cette conclusion différenciée pour les ROUTE(6) et les AS-SET tiers. La source n’établit ni déploiement en direct, ni incident, ni état de filtre d’un réseau nommé, ni disponibilité généralisée d’ASPA.

Sources