Résumé

  • La version 05, datée du 1er octobre, du projet de groupe SAVNET distingue les informations fournies par l'opérateur de celles acquises dans le système de routage. Pour des préfixes BYOIP ou obtenus auprès d'un autre fournisseur, elle demande à l'opérateur de faire identifier le préfixe par le client et de recueillir la preuve de son droit à l'utiliser comme source, même sans route configurée ou annoncée.
  • Il s'agit toujours d'un Internet-Draft destiné à être informatif. Le texte ne définit ni certificat universel, ni nouveau protocole entre AS, ni obligation de bloquer immédiatement les paquets. Son apport est de préciser comment l'autorisation rejoint les règles appliquées sur les interfaces d'accès.

Le filtre est posé sur une interface, mais la vérité dont il dépend peut être répartie entre plusieurs dossiers. Une fiche client décrit l'attachement, un registre d'adresses décrit une attribution, le routage décrit la joignabilité et une autorisation distincte peut couvrir un préfixe qui ne sert qu'à émettre. Si l'on réduit ces pièces à une route présente ou absente, un réseau multiraccordé risque de voir un trafic légitime rejeté; à l'inverse, la présence d'une route ne devrait pas devenir un permis automatique d'usurper une source.

Le projet de juin expliquait déjà que le routage ne représente pas toujours complètement l'espace des sources autorisées, notamment en cas d'asymétrie ou de préfixe caché. La nouvelle version ne doit donc pas être présentée comme la découverte de cette limite. Elle distingue désormais plus nettement deux voies d'alimentation de l'agent SAV : le provisionnement par l'opérateur, qui peut réutiliser les dossiers de clientèle et d'allocation, et l'acquisition d'informations par le système de routage. Ces voies peuvent se compléter.

Une autorisation absente du routage doit cependant être apportée par le provisionnement.

La précision sur le BYOIP révèle l'enjeu de responsabilité. Pour des préfixes que le client apporte ou qu'un autre fournisseur lui a attribués, l'opérateur de l'AS doit demander leur déclaration et un élément établissant le droit de les utiliser comme sources. Le projet ne transforme pas pour autant un ROA, une inscription de registre ou une route BGP en preuve universelle. Il ne choisit aucun format probatoire unique. C'est l'opérateur qui doit relier les éléments acceptés au client, aux interfaces et aux règles installées.

L'exemple de la version 05 met en scène un client C raccordé par i1 et i2. P1 et P2 sont visibles dans les informations de routage pertinentes; H, lui, est un préfixe caché, utilisable seulement comme source. Dans l'hypothèse exposée, les trois préfixes sont autorisés sur les deux interfaces. Pour H, l'agent SAV a besoin d'un enregistrement explicite, accompagné de la déclaration du client et d'une preuve de son autorisation. Les deux méthodes de collecte décrites aboutissent à la même liste d'autorisation; l'une réutilise les dossiers opérationnels, l'autre combine routage et provisionnement.

C'est un modèle illustratif, pas un bilan d'exploitation.

Le texte recommande des règles de type liste d'autorisation, mais avertit aussi que des données incomplètes peuvent bloquer des paquets licites. L'action prise contre un paquet jugé invalide relève de la politique locale et du stade de déploiement; surveillance, journalisation ou autres traitements prudents peuvent précéder un rejet strict. Le projet reste au stade « I-D Exists » dans Datatracker et ne décrit pas une nouvelle infrastructure centralisée d'autorisation. La décision contrôlable est locale : qui a fourni le préfixe, sur quelles attaches est-il permis et quelle modification a effectivement atteint le filtre?

Sources