Résumé

  • La position de l’API et du dispositif de contrôle détermine les informations dont chacun dispose pour reconnaître un terminal. Une interface inchangée ne garantit pas une identification inchangée.
  • L’unicité d’un identifiant est bornée à un portail et à une période. Lorsqu’une adresse ou un point de raccordement change de terminal, les anciennes correspondances doivent être mises à jour ou invalidées.
  • Regrouper plusieurs adresses et maintenir une référence interne stable peut faciliter le service. Ces choix créent aussi des responsabilités de cohérence, de conservation et de confidentialité.

La migration qui ne semblait concerner que l’hébergement

Imaginons un exploitant qui déplace son service de portail vers une infrastructure mutualisée. L’adresse du service reste accessible, son certificat est valide et les réponses ont le même format. Le projet peut donc paraître terminé du point de vue de l’équipe applicative. Pourtant, le déplacement a pu modifier une information moins visible : ce que le service sait du terminal qui l’interroge.

Près du point d’accès, un équipement peut connaître le raccordement physique ou voir l’adresse utilisée avant une traduction. Plus loin, l’API peut recevoir une requête dont le contexte ne permet plus la même distinction. Elle ne perd pas nécessairement la connexion ; elle peut perdre la correspondance qui donnait un sens à cette connexion.

Ce scénario est hypothétique. Il ne décrit ni un prestataire ni une migration observée. Il permet de séparer deux questions souvent réunies dans un même procès-verbal : le service répond-il, et répond-il au sujet du bon terminal ?

L’architecture des portails captifs de la RFC 8952, publiée à titre informatif en novembre 2020, place l’identité de l’équipement au croisement des composants. Le système de provisionnement indique où interroger le portail. L’API renseigne sur l’état de captivité. L’interface destinée à l’utilisateur permet de satisfaire les conditions d’accès. Un dispositif distinct applique les restrictions au trafic.

Ces fonctions peuvent partager une infrastructure ou être séparées. Dans les deux cas, elles doivent reconnaître un même équipement lorsqu’elles échangent à son sujet. Le sujet commun ne résulte pas automatiquement du fait qu’elles appartiennent au même service.

Ce qu’une adresse permet de savoir dépend du trajet

L’adresse IP constitue un candidat naturel à l’identification. Mais elle doit être interprétée depuis la position du composant qui l’observe. Une traduction d’adresses peut placer plusieurs terminaux derrière une même adresse visible. La RFC 8952 envisage qu’une identification reste possible si les composants connaissent la correspondance des ports. Cette condition n’est pas un détail : l’adresse partagée, à elle seule, ne fournit pas cette connaissance.

La RFC 8908, qui définit l’API du portail, exige la cohérence des vues lorsque le système identifie le client par ses adresses IP : l’API et le dispositif de contrôle doivent pouvoir voir les mêmes adresses. Publiée sur la voie des normes en septembre 2020, elle ne transforme pas pour autant une adresse en identité universelle.

Déplacer l’API de l’autre côté d’une frontière de traduction peut donc modifier une hypothèse du service. Le format JSON n’a pas besoin de changer pour que le contexte d’identification change. Une validation limitée au code de réponse et à la disponibilité du nom d’hôte laisserait cette hypothèse hors champ.

Le même raisonnement vaut pour une interface physique. Elle distingue un équipement si un seul équipement y est attaché. Lorsque plusieurs terminaux partagent ce raccordement, le port ne suffit plus à les distinguer. En outre, le composant qui applique les règles doit connaître le port, directement ou grâce à un contexte transporté ; l’API rencontre un problème comparable.

La question d’architecture n’est donc pas « quel identifiant est le plus fort ? » dans l’absolu. C’est « quelle information reste distincte et accessible à tous les composants qui en ont besoin ? ». Un identifiant commode pour l’un peut être invisible ou ambigu pour l’autre.

L’unicité n’est pas une promesse de permanence

La RFC 8952 recommande de considérer ensemble quatre qualités : unicité, difficulté d’usurpation, visibilité pour l’API et visibilité pour le contrôle du trafic. Elle ne donne pas de note chiffrée qui permettrait de classer mécaniquement tous les candidats.

Surtout, l’unicité requise est définie parmi les équipements qui interagissent avec ce portail à cet instant. Le même identifiant peut être réutilisé plus tard pour un autre équipement. Deux portails indépendants peuvent également employer la même valeur.

Cette portée limitée est utile. Elle autorise des identifiants locaux et réutilisables sans imposer un numéro permanent à chaque appareil. Elle correspond à la nature temporaire de nombreux services d’accès.

Elle impose en revanche de gérer la fin de l’association. Lorsqu’un terminal quitte le réseau et que son adresse est attribuée à un autre, la réutilisation peut être parfaitement légitime. L’ancienne session ne devient pas celle du nouvel arrivant simplement parce que le numéro lui est désormais affecté.

La section consacrée aux adresses IP demande de supprimer ou de mettre à jour les correspondances quand l’association entre adresse et équipement change. Pour le raccordement physique, l’architecture demande à l’API comme au dispositif de contrôle d’invalider l’état relatif à l’équipement lorsque celui qui est raccordé change.

L’objet à maintenir n’est donc pas seulement une valeur. C’est une relation entre cette valeur, un équipement et une période de validité. Un système qui recycle correctement les adresses, mais oublie cette relation ailleurs, peut créer une attribution erronée sans produire de doublon simultané.

Le terminal et l’abonné ne sont pas donnés par le paquet

Un appareil peut utiliser plusieurs adresses IPv4 ou IPv6. La RFC 8952 permet de les traiter comme des instances distinctes ou de les regrouper dans une même vue de l’abonné. Ce choix ne découle pas du nombre d’appareils posés sur une table.

Regrouper peut faciliter une expérience cohérente : plusieurs chemins de trafic restent attachés au même service. Séparer peut préserver une granularité utile à l’implémentation. Dans les deux cas, les composants doivent appliquer une décision compatible.

Si l’API prolonge une session regroupée alors que le contrôle du trafic raisonne adresse par adresse, le service risque de donner des résultats différents selon le chemin utilisé. Il s’agit ici d’une conséquence possible d’un désaccord, pas d’un constat de dysfonctionnement propre à tous les réseaux double pile.

L’architecture mentionne aussi une identification possible par sous-réseau dans un environnement IPv6. Ce n’est pas une consigne consistant à assimiler tout préfixe /64 à un abonné. La pertinence de ce regroupement dépend du raccordement, de la topologie et de la prestation promise.

Une adresse MAC peut également servir d’identifiant sous réserve des mêmes critères. Le document n’en fait pas une méthode universelle. Rien n’autorise à déduire de son analyse qu’il faudrait désactiver des mécanismes de protection de la vie privée.

Enfin, reconnaître une instance d’équipement ne prouve pas l’identité de la personne qui l’utilise. Une correspondance suffisante pour appliquer une règle de trafic ne devient pas, par simple réemploi, une preuve d’attribution personnelle. Les processus de support ou de comptabilisation doivent conserver cette distinction.

Une URI peut survivre au contexte qui la rendait utile

Un portail peut identifier le demandeur à partir du contexte de sa requête et proposer une URI commune. Cette solution dépend du chemin attendu. Un terminal doté de plusieurs interfaces peut emprunter une autre connexion ; un DNS à réponses différenciées peut aussi modifier la destination selon l’origine de la requête.

La RFC 8952 distingue l’accès à l’API, qui peut dépendre du contexte, des URI fournies par celle-ci, qui devraient être propres à l’équipement et fonctionner sans dépendre de ce contexte. La RFC 8908 recommande de fournir une URI distincte par client lorsque l’API ne dispose pas autrement des informations nécessaires pour l’identifier. Une telle URI peut changer entre deux sessions d’un même terminal.

Cette recommandation n’est pas une invitation à mettre un identifiant brut et non authentifié dans tous les liens. La RFC 8952 souligne le risque d’usurpation ou de rejeu. Rendre une ressource identifiable hors de son contexte initial et autoriser correctement son utilisation sont deux travaux complémentaires.

Certaines fonctions peuvent d’ailleurs rester limitées au réseau captif. Si une interaction de paiement reste accessible depuis une autre connexion, le service peut devoir préciser qu’elle ne concerne pas la connexion actuellement utilisée. L’important est de garder le bon objet commercial, pas de promettre la portabilité de toutes les opérations.

Le certificat du serveur ne résout pas cette question. La RFC 8908 valide le serveur par rapport au nom fourni lors du provisionnement ; elle ne valide ni la sécurité du mécanisme de provisionnement ni la confiance de l’utilisateur dans le réseau. Si le certificat ne peut pas être validé, le client ne doit pas poursuivre les interactions avec l’API prévues par ce protocole.

La protection du canal est indispensable. Elle ne remet cependant pas en ordre une table interne qui associe la requête au mauvais terminal.

La continuité déplace parfois la sensibilité vers l’intérieur

Des identifiants anonymes et changeants peuvent limiter la reconnaissance à long terme. Mais, comme le rappelle la partie confidentialité de la RFC 8952, le système peut les relier à une valeur interne stable pour assurer la continuité du service.

Cette correspondance a une utilité réelle. Elle peut aider à comprendre pourquoi une session apparaît sous plusieurs adresses ou à maintenir le service pendant une transition prévue. Elle conserve aussi un pouvoir de corrélation que les changements visibles ne font pas disparaître.

Il serait trompeur d’opposer une technique « privée » à une technique « non privée » sans examiner cette couche interne. Le chiffrement protège les échanges ; il ne décide pas qui peut interroger l’historique, combien de temps les associations doivent être conservées ou quelles utilisations dépassent le besoin initial.

Le bon arbitrage n’est pas nécessairement de ne rien conserver. Une contestation d’attribution peut demander une trace bornée de la transition. Mais ce besoin ne justifie pas automatiquement une correspondance permanente entre toutes les apparitions d’un terminal.

Lu Heng examine le problème d’agence à travers l’écart entre le pouvoir de décider et les conséquences supportées. Cette grille aide ici à demander qui autorise le regroupement, la réutilisation et la conservation. Ses critiques propres à la gouvernance des registres ne constituent pas une accusation contre un exploitant de portail.

Son texte sur la raison d’être de BTW invite à décrire le fonctionnement plutôt qu’à promouvoir un acteur. Il faut donc reconnaître simultanément le bénéfice de la continuité et la sensibilité qu’elle peut créer.

L’accord entre les composants doit avoir une portée compréhensible et une fin maîtrisée. La vraie question après une migration n’est pas seulement de savoir si le portail répond encore. C’est de savoir quelle relation il utilise pour reconnaître le demandeur, et si cette relation est toujours justifiée.

Sources