Résumé

  • Le RFC 9511 crée un point de rencontre minimal, notamment /.well-known/probing.txt, où l’émetteur d’une mesure peut annoncer son objectif, une échéance et un contact que le destinataire tentera ensuite de vérifier.
  • Le mécanisme ne délivre aucun sauf-conduit. L’attribution aide à enquêter, mais elle n’authentifie pas l’émetteur, ne démontre pas son intention et ne retire jamais au réseau destinataire le choix de filtrer ou d’escalader.

Le coût naît chez celui qui reçoit

Dans un laboratoire, une sonde peut être un instrument banal. À l’autre bout du réseau, elle ressemble d’abord à une activité non sollicitée. Un paquet ICMP, un SYN TCP ou une option IPv6 inhabituelle suffit à déclencher une alerte. Il faut alors retrouver la capture, examiner la cadence, résoudre l’adresse source, chercher un contact et décider si l’on observe une mesure, une reconnaissance hostile ou un logiciel mal configuré.

Cette dissymétrie est le point de départ du RFC 9511, publié en novembre 2023. Eric Vyncke, Benoît Donnet et Justin Iurman y décrivent des moyens simples d’identifier des sondes utilisées pour mesurer l’Internet public, y compris lorsque les destinataires ne collaborent pas à l’expérience. Le texte est informatif et issu de l’examen de l’IETF ; il ne crée ni obligation universelle ni droit à sonder.

Son ambition est volontairement restreinte. Il ne demande pas aux routeurs d’interroger un service central avant d’acheminer le trafic. Il n’ajoute pas de décision de confiance au plan de contrôle. Il donne à l’émetteur une façon de déclarer ce qu’il fait et au destinataire une piste pour vérifier cette déclaration.

Un rendez-vous prévisible, pas une autorité centrale

Le « Probe Description URI » peut mener vers un fichier, une adresse électronique ou un numéro de téléphone. Pour le fichier, le chemin retenu est /.well-known/probing.txt. Sa structure reprend plusieurs champs de security.txt, défini par le RFC 9116 : emplacement canonique, contact, date d’expiration et langues préférées. Le RFC 9511 y ajoute une brève description de la mesure.

Ces éléments répondent à des besoins concrets. L’expiration révèle qu’une déclaration ancienne ne doit pas survivre indéfiniment. Un contact de groupe permet de répartir le suivi sans publier les coordonnées privées d’une personne. Les langues préférées facilitent un échange qui traverse souvent les frontières. L’emplacement canonique aide à comparer une copie trouvée ailleurs avec la déclaration que l’organisation présente comme faisant foi.

Le registre des URI bien connus de l’IANA classe probing.txt comme suffixe permanent sous le contrôle de modification de l’IETF. Cette inscription normalise l’adresse du rendez-vous. Elle ne contrôle pas la véracité du fichier. Le consensus mondial porte sur une forme minimale ; l’interprétation et la décision restent locales.

Hors bande : préserver la mesure, accepter l’ambiguïté

La première méthode est hors bande. À partir de l’adresse source et, lorsqu’il existe, du DNS inverse, l’analyste construit l’emplacement où devrait se trouver le fichier de description. L’examen peut se faire après l’événement, à partir d’une capture. Aucun octet n’est ajouté au paquet, aucun nouveau comportement n’est imposé au réseau transportant la sonde.

C’est un avantage scientifique : l’étiquette ne modifie pas l’objet mesuré. Mais l’adresse source n’est pas toujours celle de l’organisation qui a commandé l’expérience. Elle peut être dynamique, traduite par un NAT ou appartenir à l’hébergeur d’un appareil tiers. RIPE Atlas illustre cette séparation : le RIPE NCC décrit un réseau mondial de sondes et d’ancres hébergées de manière distribuée. Le propriétaire de l’adresse, l’hôte de la sonde et l’auteur d’une mesure personnalisée peuvent occuper des rôles différents.

L’attribution hors bande est donc forte lorsqu’une série de faits concorde : DNS direct et inverse, plages publiées, fichier à jour, contact réactif. Elle devient fragile lorsque l’on transforme l’adresse en preuve automatique de responsabilité.

Dans le paquet : l’explication peut changer le résultat

La méthode en bande place l’URI dans le trafic lui-même : au début de la charge utile ICMP, UDP ou TCP, ou dans une option IPv6. Elle suit ainsi la sonde même lorsque le DNS inverse manque ou que l’émetteur ne maîtrise pas le serveur correspondant à l’adresse source.

Mais un paquet identifié n’est plus exactement le paquet que l’on voulait tester. Quelques octets supplémentaires peuvent franchir une limite de MTU. Un SYN TCP avec données n’est pas toujours traité comme un SYN ordinaire. Certaines piles abandonnent des options IPv6 qu’elles jugent atypiques. Le réseau peut également apprendre à réserver un traitement particulier aux sondes reconnaissables.

Le RFC déconseille pour cette raison une chaîne magique opaque. Un équipement de transit pourrait la détecter et favoriser, ralentir ou bloquer le paquet. La sonde mesurerait alors en partie le traitement accordé à son étiquette. La transparence destinée aux humains deviendrait un biais pour l’instrument.

Il n’existe pas de solution unique : l’attribution hors bande perturbe moins le trafic mais dépend de l’association entre une adresse et une déclaration ; l’attribution en bande colle au paquet mais peut en modifier le sort. Les combiner apporte une corroboration, non une identité cryptographique.

Attribuer n’est pas authentifier

La limite la plus importante du texte est explicite. Les informations trouvées ne doivent pas être crues aveuglément. Un acteur malveillant peut publier une description mensongère, placer l’URI d’un tiers dans ses paquets ou emprunter un contact légitime. L’attribution pourrait alors déplacer à tort l’enquête et les plaintes vers une organisation innocente.

Le RFC donne une règle d’exploitation nette : si le destinataire ne peut pas confirmer les informations, ou ne souhaite pas le faire, il doit traiter le flux comme s’il n’existait aucune attribution. La présence du fichier ne vaut pas présomption de bienveillance. Elle ne neutralise ni le filtrage, ni les limites de débit, ni la politique de réponse aux incidents.

Une authentification exigerait de lier plus fortement le paquet, l’infrastructure source, le responsable de la campagne et une identité reconnue par le destinataire. Une autorisation demanderait encore une décision distincte : cette identité a-t-elle le droit d’envoyer ce trafic vers cette cible, à ce moment et à cette cadence ? Le RFC 9511 s’arrête avant ces deux seuils.

Ce choix n’annule pas l’utilité du mécanisme. En exploitation, une preuve imparfaite mais vérifiable peut réduire une recherche sans limites. Une description datée, une plage cohérente et une boîte de groupe surveillée permettent de contacter rapidement le responsable, de classer un faux positif ou de bloquer plus précisément. Le gain est d’abord organisationnel : rapprocher une observation d’un interlocuteur responsable.

La déclaration publique du NCSC

Le RFC cite une pratique comparable du National Cyber Security Centre britannique. La notice publique du NCSC indique les adresses utilisées pour ses analyses de vulnérabilités, leur DNS direct et inverse, un en-tête HTTP d’identification, les précautions annoncées et une procédure de retrait.

Un opérateur peut donc croiser plusieurs éléments : origine observée, DNS, en-tête, page institutionnelle et contact. Aucune de ces pièces, prise isolément, n’est infaillible. Un en-tête se copie. Une page vieillit. Une adresse peut être usurpée dans certains contextes. La valeur vient de la concordance et de la capacité d’obtenir une réponse institutionnelle.

L’exemple révèle aussi le coût de la transparence pour l’émetteur. Publier ne suffit pas. Il faut maintenir les adresses, renouveler l’échéance, répondre aux plaintes, traiter les demandes d’exclusion et réagir si un tiers usurpe le nom. Une attribution responsable est un engagement opérationnel continu, non un fichier posé une fois pour toutes.

Eric Vyncke dans un travail collectif

Le profil IETF d’Eric Vyncke le présente comme directeur de la zone Internet et associe son activité aux normes, à IPv6, à la télémétrie et à la sécurité. Il répertorie sept RFC dont le RFC 9511. La liste actuelle de l’IESG confirme sa présence parmi les directeurs de la zone Internet.

Ces faits donnent un contexte, pas un titre de propriété. Le RFC 9511 a trois auteurs, s’appuie sur des mécanismes antérieurs et reflète une revue collective. L’IANA tient le registre ; les opérateurs de mesure publient les déclarations ; les administrateurs DNS créent les associations ; les réseaux destinataires décident de leur politique.

Un autre texte coécrit par Vyncke, le RFC 7404, étudiait l’emploi exclusif d’adresses IPv6 lien-local sur des liaisons d’infrastructure. Il exposait bénéfices et inconvénients sans recommandation universelle. Le trait commun n’est pas une solution imposée, mais une manière de borner le problème : rendre une option déployable, montrer ce qu’elle économise, préciser ce qu’elle fait perdre et restituer le choix à l’opérateur.

Une grammaire commune pour des décisions différentes

Le RFC 9511 peut rendre un paquet ambigu plus intelligible. Il ne peut pas prouver une intention, imposer une permission, garantir le passage d’une étiquette en bande ou empêcher l’usurpation. Ces limites définissent précisément le mécanisme : l’émetteur améliore la lisibilité de son acte ; le destinataire conserve l’autorité de le juger.

Dans un Internet composé d’administrations indépendantes, cette échelle de normalisation est réaliste. Il serait difficile qu’une institution unique déclare chaque sonde légitime pour tous les réseaux. Une petite convention peut néanmoins améliorer les décisions locales si elle est simple à publier, facile à inspecter et honnête sur ce qu’elle ne démontre pas.

Limites des preuves

Les sources publiques établissent le contenu et les auteurs du RFC, son statut, l’enregistrement IANA, les rôles institutionnels déclarés, la pratique publiée du NCSC et le fonctionnement documenté de RIPE Atlas. Elles ne mesurent ni le taux de déploiement de probing.txt, ni sa consultation réelle par les équipes, ni une réduction des incidents.

Elles ne permettent pas davantage d’attribuer à Eric Vyncke le contrôle d’une plateforme de mesure ou les choix d’un réseau destinataire. La personne sert ici de point d’entrée vers un raisonnement partagé, non de héros unique.

Sources