Résumé

  • Le résultat positif de RFC 5210 concerne un AS doté des trois niveaux SAVA : réseau d’accès, intra-AS et inter-AS. Retirer cette condition revient à changer le sens de l’expérience.
  • Chaque niveau dépend d’un état mutable : association adresse-port, règle préfixe-interface ou étiquette temporaire entre AS. Un verdict sans époque ne décrit pas le paquet suivant.
  • Une adresse légitime peut transporter une attaque légitime au regard du filtrage anti-usurpation. La validation de source ne prouve ni l’intégrité de la machine ni l’identité humaine.

Le moment où le vert cesse de vouloir dire ce que l’on croit

À 09 h 00, un paquet IPv6 quitte un poste relié au port 17. L’adresse correspond à l’association connue par le commutateur. Le routeur d’entrée accepte le préfixe sur l’interface prévue. À l’autre extrémité, une étiquette temporaire entre membres d’une alliance SAVA est reconnue. Trois contrôles, trois résultats positifs.

À 09 h 12, le poste bascule vers une autre liaison. La table de préfixes évolue et une rotation d’étiquette commence. Certains équipements ont reçu le nouvel état, d’autres pas encore ; les deux étiquettes restent momentanément admises pour éviter une coupure. À 09 h 15, le tableau de bord n’affiche pourtant qu’une formule : source authentifiée.

Le constat de 09 h 00 reste valable. C’est l’étiquette durable qui ment par omission. Elle efface le paquet concerné, les barrières réellement franchies, la version des règles et l’intervalle de transition. Puis elle fait un second saut : d’une adresse admise, elle infère un émetteur identifié.

Cette scène est construite. Elle ne décrit aucune entreprise, aucun produit ni incident réel. Elle sert à conserver la bonne unité de vérité : RFC 5210 mesure une validation sur un chemin expérimental, pas une essence attachée pour toujours à une adresse.

Une expérience précise, pas une promesse universelle

Publié en juin 2008 avec le statut Experimental, RFC 5210 relate un prototype de Source Address Validation Architecture. Le dispositif a été installé dans douze AS universitaires raccordés à CNGI-CERNET2. Six sites disposaient des trois éléments nécessaires pour être qualifiés de complets.

Dans cette configuration complète, les paquets ne possédant pas une adresse source authentifiée n’étaient pas acheminés. Les essais couvraient des situations ordinaires, des changements dynamiques et des tentatives d’usurpation : ajout ou retrait d’étiquette, nouvelle participation à l’alliance, ajout ou suppression d’espace d’adresses et trafic forgé.

Le document ne se présente pas comme une norme Internet achevée. Ses auteurs parlent d’un apport aux travaux futurs et exposent les limites techniques, économiques et opérationnelles du prototype. Respecter ce statut n’enlève rien au résultat. Au contraire, cela évite de lui attribuer une portée qu’il n’a jamais revendiquée.

La proposition centrale est celle de plusieurs barrières. Une seule méthode ne sera vraisemblablement jamais déployée partout ; plusieurs contrôles indépendants peuvent couvrir une partie des trous et augmenter la confiance. « Augmenter » n’est pas « universaliser ». Une zone non observée reste une zone non observée.

La barrière d’accès connaît une liaison, pas une personne

Dans une première variante, le prototype crée dynamiquement une association entre adresse IP, adresse MAC et port de commutateur. Le trafic qui ne respecte pas le couple adresse-port est rejeté. Dans une seconde, l’authentification d’accès fournit une clé de session utilisée pour protéger les paquets jusqu’au dispositif de validation.

Le résultat décrit une cohérence entre une allocation et un point d’attachement. Il ne dit pas quel utilisateur tient le clavier, quel processus a émis le paquet ni si la machine a été compromise. Même la protection cryptographique de la liaison ne transforme pas automatiquement un hôte en principal humain.

Le RFC avertit d’ailleurs que l’approche d’association testée ne suffirait pas telle quelle en production. Déplacement d’un poste, double connexion, basculement, mobilité et accès sans fil modifient les hypothèses. Une association sans durée et sans mécanisme de changement devient rapidement un souvenir présenté comme un fait actuel.

L’intra-AS raisonne sur un préfixe et une topologie

Au niveau intra-AS, le prototype reprend les principes du filtrage d’entrée de RFC 2827 et RFC 3704. La question n’est plus « ce poste possède-t-il cette adresse ? », mais « ce préfixe source est-il plausible sur cette interface selon la connaissance du routage ? ».

Le mode strict, le chemin faisable et les vérifications plus lâches n’ont pas la même sémantique. L’asymétrie et le multihoming rendent un test strict susceptible de rejeter du trafic légitime ; un mode plus permissif réduit cette erreur au prix d’une preuve plus faible. Le choix est une décision locale de topologie, non un label absolu.

Une réception correcte à ce niveau autorise donc une phrase limitée : le préfixe était compatible avec la règle et la vue de routage datées. Elle n’autorise pas à remonter jusqu’à l’équipement, au compte ou à l’auteur.

L’inter-AS ajoute une dépendance collective

Entre AS voisins, le prototype associe une interface entrante à un ensemble de blocs sources valides. Un moteur produit des règles en langage d’AS, un service projette les AS vers les préfixes IPv6, puis les moteurs de validation appliquent ces règles.

Entre membres non voisins, l’expérience utilise une alliance et des étiquettes temporaires. Le routeur de sortie ajoute une valeur en fonction de l’AS destinataire ; le routeur d’entrée la vérifie et la retire. La liste des membres, les informations de propriété des préfixes, les valeurs et leur renouvellement deviennent des dépendances d’exécution.

L’alliance devait pouvoir évoluer dynamiquement, mais la confiance initiale du banc d’essai a été confirmée hors ligne. Cette précision empêche de décrire l’expérience comme un système mondial d’établissement autonome de confiance. Elle révèle aussi la question de gouvernance : qui admet un membre, qui corrige une cartographie, qui assume une mise à jour perdue ?

La règle d’aujourd’hui peut arriver demain

RFC 5210 signale que le mécanisme fondé sur les relations entre AS peut suivre trop lentement la dynamique des routes et produire des faux positifs. CNGI-CERNET2 était relativement stable durant l’expérience. Cette stabilité fait partie du contexte du résultat.

L’étiquette a elle aussi une époque. Les anciennes valeurs ne doivent pas rester valides indéfiniment. Durant les essais, l’ancienne et la nouvelle valeur se chevauchaient cinq secondes. Ce chevauchement évite des pertes, mais ouvre un intervalle où « valeur courante » ne suffit pas à décrire la règle.

Une preuve exploitable doit donc conserver la vue de routage, la cartographie AS-préfixe, la version générée, l’accusé de distribution, l’installation sur l’interface, l’époque d’étiquette et la fin du chevauchement. Sans ces éléments, valide=true est incapable de répondre à la question la plus simple : valide selon quoi ?

La traçabilité progresse sans devenir identité

L’un des bénéfices attendus est une traçabilité plus fiable. Si plusieurs barrières éliminent l’usurpation, l’adresse et le chemin restants deviennent de meilleurs indices. Mais un indice plus solide ne change pas de catégorie.

RFC 7039 le rappelle avec netteté : il est séduisant d’imaginer que les associations de validation permettent d’identifier la personne, voire le système final, à l’origine d’un datagramme. Elles fournissent des éléments circonstanciels, pas une résolution complète de l’attribution.

Un serveur multi-utilisateur, un relais, un proxy, une plateforme applicative ou une machine compromise peuvent tous utiliser une adresse correctement associée. Il faut des preuves distinctes pour relier le réseau à l’appareil, l’appareil à la charge de travail, la charge au compte et le compte à une personne. L’intention demeure encore une autre question.

Cette discipline protège aussi la vie privée. Les journaux d’association peuvent aider une enquête, mais ils révèlent les lieux et périodes d’activité. Leur conservation et leur consultation exigent une finalité, une durée et une procédure de contestation. Une apparence d’attribution ne doit jamais devenir une sanction automatique.

Le botnet passe avec sa propre adresse

Le plafond de la technique figure dans RFC 5210 lui-même. De nombreuses attaques par déni de service utilisent les adresses légitimes de machines enrôlées dans un botnet. Même une validation universelle des sources ne les empêcherait pas.

La technique réduit l’usurpation ; elle n’atteste ni la santé du terminal, ni l’autorisation de l’application, ni l’intention, ni la légitimité du volume. Une machine compromise peut réussir les trois barrières précisément parce qu’elle emploie l’adresse qui lui a été attribuée.

Dire « adresse admise » conserve cette limite. Dire « trafic authentifié » la fait disparaître. L’équipe de sécurité risque alors de relâcher le contrôle comportemental, la limitation de débit ou l’analyse du terminal au motif que la source est « sûre ».

La configuration ne prouve pas l’effet dans le plan de données

L’étiquette légère de l’expérience était une valeur aléatoire partagée, non une identité cryptographique par paquet. Le RFC mentionne la vulnérabilité à un adversaire placé sur le chemin et le coût d’une construction cryptographique plus forte. Il relate également une chute de débit lorsque des options IPv6 hop-by-hop étaient traitées lentement par certains routeurs du montage.

La présence d’une règle dans un contrôleur prouve une intention. L’accusé d’installation prouve que l’équipement a accepté une configuration. Seuls les compteurs, les paquets d’essai corrélés et les observations au bon point montrent que le plan de données a exécuté la règle. Chaque étape mérite son propre reçu.

Le reçu minimal d’une affirmation honnête

Il faut enregistrer le paquet ou le flux, l’heure et le point d’observation, puis les barrières attendues. À l’accès : origine de l’allocation, adresse, liaison, port, création, expiration et traitement des déplacements. À l’entrée de l’AS : mode de validation, interface, vue de routage, règle et heure de génération.

Pour l’inter-AS : relation administrative, cartographie, version de règle, distribution et empreinte installée. Pour l’alliance : membres, pairs, époque d’étiquette, intervalle de chevauchement et expiration. Enfin : versions logicielles et matérielles, chemins lents, compteurs, rejets et provenance des tests.

Le reçu doit nommer la première barrière absente ou obsolète. Puis il doit s’arrêter. S’il existe une preuve indépendante reliant l’adresse à un appareil, un compte ou une personne, on la relie comme un autre objet. Sinon la conclusion correcte est : adresse et chemin admis ; acteur inconnu.

Sources