Résumé

  • draft-sriram-savnet-intrasav-solution-00 construit des listes d’autorisation par interface à partir des usages de routage et de source déclarés, y compris un préfixe BYOIP qui n’est jamais annoncé.
  • L’absence d’admission et de blocage erronés suppose une configuration complète. La révision 00 ne définit pas encore le reçu prouvant que la bonne génération gouverne réellement le bon port.

Le gestionnaire de configuration affiche deux ensembles impeccables. Sur la première interface, le client peut utiliser {p, q}. Sur la seconde, il peut annoncer r et émettre également depuis s, sans jamais annoncer s. La liste {r, s} décrit donc exactement ce que la seconde interface devrait accepter.

Puis le client déplace son service. Une partie du réseau reçoit la nouvelle génération ; un routeur redémarré conserve l’ancienne ; le tableau de bord, lui, continue de montrer le calcul central. La liste n’est pas fausse. Elle n’est simplement pas encore devenue une réalité unique dans le plan de données.

C’est le point de décision ouvert par IntraSAV - A Solution for Intra-Domain Source Address Validation. La révision 00 a été déposée le 1er octobre 2026. C’est un Internet-Draft individuel en I-D Exists, destiné au statut Best Current Practice. Il ne s’agit ni d’une adoption par SAVNET, ni d’un RFC, ni d’une implémentation ou d’un déploiement mesuré. S’il était approuvé, il mettrait à jour les BCP 38 et 84 ; aujourd’hui, il ne les modifie pas.

L’itinéraire n’est pas une autorisation de source

Les mécanismes antérieurs cherchent souvent la réponse dans la table de transfert. Le mode uRPF strict vérifie que le chemin de retour vers une adresse source utilise l’interface d’arrivée. Une route asymétrique ou un site multihomé peut alors faire rejeter un paquet parfaitement légitime. Le mode lâche accepte la présence d’une route, mais abandonne la direction et laisse davantage de sources usurpées passer. Une ACL peut être précise, tant qu’un opérateur la maintient au rythme de chaque changement.

Le problème est conceptuel avant d’être technique. Une FIB répond à une question de joignabilité. Elle ne dit pas nécessairement qu’un client est autorisé à employer une adresse comme source. Dans un montage Direct Server Return, un serveur périphérique peut envoyer une réponse avec l’adresse anycast du service sans annoncer ce préfixe. L’absence de route locale ne rend pas cet usage illégitime.

IntraSAV demande donc une déclaration explicite. Le client BYOIP indique les préfixes qu’il utilisera pour le routage, comme sources, ou pour les deux, et l’interface concernée. L’AS local ajoute les mêmes informations pour ses propres préfixes. Un Configuration Manager, éventuellement doté d’un SAV Agent, assemble ces faits puis calcule une liste distincte pour chaque interface de routeur Customer Edge.

Dans la figure du brouillon, le premier client route p et q. Le second route r, mais utilise aussi s uniquement comme source. Le mécanisme saisit précisément le fait que la FIB ne peut pas deviner : s appartient à l’interface 2 même s’il n’apparaît jamais dans une annonce.

Le ROA et la configuration locale ne parlent pas au même public

Le texte recommande aux propriétaires de créer des ROA autorisant l’AS local comme origine. Il précise en même temps que la configuration locale prévaut, pour le routage et la validation locale, sur l’information du ROA. L’opérateur doit comparer les deux et avertir le client en cas d’incohérence, car des AS distants utiliseront le ROA dans leur propre calcul inter-domaine.

Cette hiérarchie est sensée si l’on garde les deux usages séparés. La configuration locale affirme que tel client peut utiliser tel préfixe sur telle interface. Le ROA rend visible une autorisation d’origine à d’autres réseaux. Une concordance réduit le risque de divergence ; elle ne démontre pas que le client était habilité à soumettre le changement, que le port lui appartient encore ou que la règle est active dans le matériel.

Le gestionnaire doit authentifier les clients, mais la révision 00 ne définit ni protocole d’inscription, ni portée de mandat, ni révocation, ni identifiant de transaction. Une première spécification peut laisser ces choix aux opérateurs. En revanche, une exploitation qui prétend expliquer un blocage a besoin d’un reçu liant client, préfixe, interface, mode d’usage et génération.

« Complet » porte toute la garantie

Le brouillon affirme que, tant que le Configuration Manager possède une information complète, IntraSAV garantit zéro blocage erroné et zéro admission erronée. Dans le modèle, la proposition est presque définitionnelle : tous les préfixes autorisés figurent dans la liste, et tout ce qui n’y figure pas est refusé.

La difficulté opérationnelle tient au mot « complète ». Aucun test indépendant ne l’établit. La révision ne donne ni numéro de génération, ni heure d’effet, ni inventaire attendu des équipements, ni remplacement atomique, ni accusé de livraison ou procédure de retour arrière. Elle ne dit pas ce qui se passe lorsque le client ajoute, retire ou déplace un préfixe pendant la propagation des règles.

Le contrôleur peut donc avoir raison tandis que le réseau diverge. Une interface exécute la génération 18, une autre la 17. Une règle existe dans le logiciel du routeur mais pas dans l’ASIC. L’ancien port garde une autorisation après le déménagement du client. Une suppression ferme une ouverture d’usurpation sur un équipement et coupe un basculement légitime sur un autre.

Ce ne sont pas des réfutations du calcul proposé. Ce sont les pièces que le code en fonctionnement devra produire. Le « zéro » ne devient une observation qu’avec un dénominateur : population autorisée des couples préfixe-interface, génération effectivement engagée sur tous les points attendus, paquets de test étiquetés comme légitimes ou usurpés, et compteurs distinguant les quatre résultats possibles.

L’union à la frontière perd la liaison au client

Une section marquée explicitement « To be Discussed » envisage de placer à l’ASBR une liste agrégée {p, q, r, s}. L’opérateur pourrait ainsi filtrer à un équipement plus facile à mettre à niveau que tous les CE, si sa connaissance de la topologie garantit que les sources attendues appartiennent toutes à l’AS local.

Le document reconnaît que cette idée dépasse probablement la portée du problème, sauf lorsque l’ASBR dessert directement des hôtes ou un client sans AS. La prudence est justifiée. L’union peut montrer que s est autorisé quelque part dans le domaine ; elle ne prouve plus que s doit arriver précisément sur l’interface du second client. Défense agrégée et liaison par client fournissent deux garanties différentes.

Il en va de même pour le déploiement incrémental. Compter les interfaces équipées montre une couverture de configuration. Pour mesurer le bénéfice, il faut encore identifier les chemins d’attaque fermés, les flux légitimes exposés et les bords non couverts qui deviennent un contournement.

Ajouter une génération entre l’intention et le paquet

Une exploitation défendable sépare dix reçus : authentification du client ; mandat sur le préfixe et l’interface ; acceptation d’une configuration versionnée ; comparaison avec le ROA ; calcul de la liste ; livraison au routeur et au port visés ; engagement atomique ou rejet ; compteurs de correspondance et de rejet ; tests étiquetés ; résultat de sécurité et de service observé.

La doctrine de spécification minimale de Heng Lu n’oblige pas tous les réseaux à partager un même contrôleur. Elle permet un format commun étroit et des décisions locales. La primauté du code en fonctionnement impose ensuite une trace à la frontière d’exécution. Un opérateur peut garder son Configuration Manager privé tout en produisant un condensat de configuration, une génération par interface et un accusé d’engagement vérifiable.

L’apport essentiel d’IntraSAV est d’arrêter de confondre route et autorisation de source. L’étape suivante consiste à préserver cette vérité explicite jusqu’au paquet. Une liste exacte dans le contrôleur ouvre la chaîne de preuve ; elle ne la ferme pas.

Sources