Résumé
- RFC 9797 décrit comment une adresse MAC aléatoire ou changeante réduit un vecteur de corrélation, sans garantir l’anonymat lorsque d’autres identifiants, comptes ou comportements restent stables.
- L’adresse MAC sert à la livraison sur un lien et peut indexer un état local. Elle ne prouve ni l’identité d’un appareil ou d’une personne, ni le droit d’hériter d’une décision antérieure.
- Un reçu local de continuité privée devrait relier, pour une durée limitée, l’époque d’adresse, le contexte de confiance, la preuve authentifiée, la politique, la transition d’état et le résultat. Il s’agit d’une proposition éditoriale de Daniel Kade, pas d’un champ IETF ou IEEE.
Un réseau peut réussir à protéger la vie privée et échouer à fournir le service dans la même seconde. L’appareil présente une nouvelle adresse MAC ; l’observateur occasionnel ne peut plus utiliser l’ancienne valeur pour relier deux passages ; pourtant le portail captif réclame une nouvelle inscription, la réservation DHCP ne suit pas et l’assistance ouvre une seconde fiche. La réussite et l’échec concernent des couches différentes.
RFC 9797, document informatif issu du groupe MADINAS, donne un vocabulaire pour ne pas les confondre. Il ne fixe pas une fréquence universelle de rotation. Il examine les conséquences des adresses MAC aléatoires et changeantes pour les fonctions qui avaient pris l’habitude d’une valeur persistante. Le problème n’est donc pas de choisir entre « toujours stable » et « toujours aléatoire », mais de savoir quelle continuité est nécessaire, qui la décide et quelle preuve la soutient.
Six objets doivent rester distincts : le nom utilisé pour acheminer une trame sur un lien ; la possibilité de relier des observations ; l’identité authentifiée d’un appareil ou d’une personne ; l’autorisation accordée par une politique ; l’état qu’un service doit conserver ; enfin le résultat constaté. Une adresse MAC peut participer au premier objet et faciliter le deuxième. Elle ne reçoit pas automatiquement les propriétés des quatre autres.
Un index commode ne devient pas une preuve
ARP, Neighbor Discovery, DHCP et les tables de commutation rendent l’adresse de liaison visible. Sa stabilité historique a encouragé les raccourcis. Une réservation d’adresse, une session de portail, une classe de qualité de service, une limite de débit, une note d’abus et un dossier de support ont pu être rangés sous la même clé.
Ce rangement peut rester utile si le système nomme exactement ce qu’il sait. « Cette adresse a été observée sur ce lien à cet instant » est un fait borné. « Il s’agit du même appareil » demande une chaîne supplémentaire. « Il s’agit du même utilisateur » demande une authentification adaptée. « Ce sujet a toujours droit au service » demande une politique actuelle, son contexte et sa date d’expiration.
La valeur peut changer avec une politique de confidentialité, une interface virtuelle, un remplacement matériel ou une configuration. Elle peut aussi être copiée. Un appareil peut en utiliser plusieurs ; plusieurs endpoints peuvent en reprendre une à des moments différents. La persistance crée de la corrélation, pas de l’authenticité.
La randomisation rend cette faiblesse plus visible, mais ne la crée pas. Si un système perd l’identité dès que l’index change, il n’avait jamais possédé cette identité dans l’index. Il avait seulement profité d’une coïncidence durable.
La rupture d’un lien n’efface pas tous les autres
Une adresse différente peut empêcher un observateur de réunir deux associations par égalité directe. Le gain augmente lorsque la valeur n’est pas réutilisée entre contextes et lorsqu’elle change avant de devenir un historique durable. C’est un bénéfice réel, précisément limité.
Il peut être annulé par un autre signal : compte connecté, certificat, jeton applicatif, nom d’hôte, option de protocole, identifiant IPv6 stable, signature radio, rythme du trafic ou simple continuité temporelle. RFC 7217 et RFC 8981 rappellent que la stabilité et la confidentialité des identifiants se jouent aussi au-dessus de la couche MAC. Changer une seule clé ne rend pas le reste du comportement anonyme.
L’analyse doit donc poser une question relative : qui cherche à relier quoi, dans quel périmètre, avec quels signaux ? Un réseau géré peut légitimement utiliser un certificat pour rétablir une politique professionnelle. Cela ne l’autorise pas à reconstruire un historique permanent de toutes les adresses observées. Un lieu public peut avoir besoin d’une session courte sans connaître l’identité civile. Un service d’abus peut conserver une preuve proportionnée sans transformer chaque passage en profil interréseaux.
À l’inverse, une adresse stable n’est pas une attestation. Elle peut rendre deux traces rapprochables tout en laissant l’auteur incertain. Confondre traçabilité et identité exagère la qualité de la preuve et minimise son coût pour la vie privée.
La confiance est une relation locale
RFC 9797 distingue plusieurs environnements de confiance parce qu’une même règle ne convient pas partout. Un terminal peut accepter davantage de continuité dans un réseau d’entreprise administré, moins dans un réseau choisi pour un usage temporaire et presque aucune pendant une simple exploration radio. Cette décision peut aussi varier entre réseaux déjà connus.
La confiance totale n’est pourtant pas un blanc-seing. Elle doit rester liée au service et au consentement qui l’ont justifiée. La confiance sélective oblige à préciser quelles informations sont révélées et pendant combien de temps. L’absence de confiance ne devrait pas conduire le réseau à collecter secrètement des signaux plus intrusifs pour reconstituer la même continuité.
L’unité saine de décision est l’époque d’adresse : une valeur, un contexte de réseau, un début, une fin et un but. Une jonction avec l’époque précédente doit être explicitement autorisée. Cette formulation protège aussi l’opérateur, car elle distingue une rotation attendue d’une usurpation ou d’un conflit réel.
Les services doivent savoir perdre puis reconstruire leur état
Lors d’un changement, plusieurs machines d’état peuvent diverger. Le serveur DHCP conserve un bail ancien et en crée un nouveau. Le contrôleur sans fil garde une station périmée. Le portail redemande une validation. La comptabilité ouvre une nouvelle session. La règle de qualité de service reste attachée à l’ancienne valeur. L’assistance conclut à deux équipements.
Chaque service doit décider si son état doit mourir, être recalculé ou être transféré. Une entrée de livraison locale peut disparaître avec l’époque. Une autorisation payante peut être rétablie depuis un compte authentifié. Un privilège sensible exige une nouvelle vérification. Une limite destinée à un utilisateur ne doit pas être contournée par une rotation, mais elle ne doit pas non plus être attribuée à un voisin parce qu’il reprend une adresse.
Les principes de résilience de RFC 3539 aident à distinguer une interruption d’identifiant de la perte d’autorité du service. DHCP, résolution d’adresse, authentification, autorisation et comptabilité n’ont ni les mêmes horloges ni les mêmes preuves. Un voyant unique « appareil connu » masque les désaccords qu’il faudrait précisément observer.
Le transfert d’état demande surtout une preuve positive indépendante de l’ancienne adresse. Un certificat d’appareil, un compte, une possession cryptographique ou une procédure locale peut convenir selon le risque. « La nouvelle session ressemble à l’ancienne » ne suffit pas pour transmettre un rôle d’administration ou une exception de sécurité.
Un reçu de continuité privée, borné et périssable
Le reçu de continuité privée proposé ici commence par l’époque : réseau, session, adresse observée, instant de début et de fin, cause connue du changement. Il note le contexte de confiance sans le généraliser à d’autres réseaux.
Il conserve ensuite la référence authentifiée, si elle existe, mais pas nécessairement le secret ni le certificat complet. Il nomme la source d’assurance, la version de politique, la décision, son périmètre et son expiration. S’il n’existe aucune identité vérifiée, cette absence reste explicite.
Le reçu décrit l’état détruit, reconstruit ou transféré, puis le résultat mesuré : accès obtenu, nouvelle authentification, échec du portail, duplication de session ou autre effet borné. Il peut signaler qu’un identifiant supérieur stable annule le bénéfice attendu de la rotation, sans recueillir une empreinte comportementale générale.
Enfin, le reçu expire avec le besoin opérationnel. Son accès reste limité aux responsables de la décision. Des statistiques agrégées peuvent mesurer les pannes de continuité ; les chaînes locales ne doivent pas alimenter un registre central de suivi.
Ce reçu n’est ni un format RFC, ni une exigence IEEE, ni un nouveau protocole. Il sert à empêcher deux verdicts faciles et faux : nouvelle MAC donc nouvelle personne ; même MAC donc même autorité.
Du texte normatif à la réalité observée
RFC 9797 n’a pas d’action IANA et ne démontre aucune adoption particulière. IEEE 802.11bh traite des services améliorés avec des adresses aléatoires ou changeantes dans la famille 802.11 ; l’existence de cet amendement ne prouve ni le comportement d’un produit ni la politique d’un opérateur.
Le standard rend les interactions descriptibles. Le logiciel du terminal exécute la rotation. Le réseau choisit la continuité qu’il demande. Le système d’identité fournit éventuellement une preuve indépendante. Le code réel transfère ou abandonne l’état. L’observation locale seule permet d’établir le résultat.
La doctrine de Heng Lu sépare utilement spécification, décision locale, adoption volontaire et code en fonctionnement. Appliquée ici, elle empêche de traiter une recommandation comme un fait de déploiement, une configuration comme un résultat ou une adresse comme une identité.
Le choix durable n’est pas entre vie privée et exploitation. Il consiste à conserver la plus petite continuité nécessaire à un service nommé, avec une preuve proportionnée, un responsable, un test de résultat et une fin.
Sources
- Fiche IETF Datatracker de la RFC 9797
- Heng Lu : Minimum Initial Specification, Localized Future Decision, Voluntary Adoption
- Heng Lu : On Why BTW Media Exists
- Heng Lu : The Policy Mirror
- IEEE 802.11bh-2025
- Fiche RFC Editor de la RFC 9797
- RFC 826 : protocole de résolution d’adresse
- RFC 2131 : DHCP
- RFC 3539 : profil de transport AAA
- RFC 4861 : découverte des voisins IPv6
- RFC 4862 : autoconfiguration IPv6 sans état
- RFC 7217 : identifiants d’interface sémantiquement opaques
- RFC 8981 : adresses IPv6 temporaires
- RFC 9797 : état des adresses MAC aléatoires et changeantes
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
