Résumé

  • ATMP permettait à un client PPP ou SLIP d’employer une adresse de son réseau d’origine tandis qu’un NAS distant et un agent mère assuraient le tunnel à son insu.
  • Un enregistrement, une épreuve à secret partagé inspirée de CHAP, un identifiant local au couple d’agents et GRE fabriquaient l’apparence opérationnelle d’un raccordement local, pour IP comme pour IPX.
  • L’adresse, la réponse positive ou la clé GRE attestaient un état borné du protocole, pas le lieu physique, l’identité humaine, l’autorisation applicative, la livraison ou un consensus de l’IETF.

Le domicile était une décision de routage

En 1997, un usager pouvait appeler un serveur d’accès éloigné et néanmoins présenter une adresse issue de son réseau d’origine. La ligne téléphonique aboutissait ailleurs ; le routage racontait qu’il était chez lui.

C’est la tension essentielle du protocole ATMP décrit par le RFC 2107. Le poste ne se déplaçait pas. Un agent étranger intégré au NAS enregistrait le client auprès d’un agent mère placé sur le réseau d’origine. Les deux équipements transportaient ensuite les paquets dans un tunnel, de sorte que le reste du réseau puisse agir comme si le client était local.

Le client n’exécutait pas ATMP. Un logiciel PPP ou SLIP ordinaire suffisait. La mécanique appartenait au NAS et à l’agent mère ; les autres systèmes n’avaient pas à savoir que l’accès était distant. La simplicité à la périphérie fut obtenue en concentrant le jugement de routage à la frontière.

L’adresse d’origine pouvait venir du client, dépendre d’un identifiant d’usager ou être prélevée dans un pool. Le RFC laisse explicitement hors de son périmètre la méthode d’attribution et la décision du NAS d’activer ATMP. Le protocole savait transporter l’adresse choisie. Il ne savait pas démontrer que le choix était encore autorisé ni qu’il décrivait la bonne personne.

L’enregistrement construisait le rattachement

La liaison de mobilité ATMP associait une adresse d’origine, l’adresse IP de l’agent étranger et un identifiant de tunnel. Ce triplet n’était pas une déclaration géographique ; c’était une instruction de routage compacte.

Lorsqu’un client réclamait le service, l’agent étranger obtenait par configuration l’adresse de l’agent mère et un secret partagé. Il envoyait une demande d’enregistrement toutes les deux secondes ; après dix tentatives sans défi en retour, il consignait l’échec et déconnectait le client.

L’agent mère envoyait un authentifiant aléatoire. L’agent étranger lui concaténait le secret, calculait un condensat MD5 et le retournait. L’agent mère refaisait le calcul. Une égalité permettait d’accepter l’enregistrement ; un désaccord ou le manque de ressources produisait un résultat non nul.

Cette épreuve authentifiait une relation configurée entre deux agents. Elle n’identifiait pas l’être humain devant le modem, n’accordait pas une action applicative et ne chiffrait pas les données. La formule « semblable à CHAP » décrivait une construction, non une extension de son pouvoir probant.

L’identifiant transformait l’état en chemin

Après acceptation, l’agent mère attribuait un identifiant unique seulement au sein du couple agent étranger–agent mère. Il créait un bloc de contrôle reliant cet identifiant aux informations de routage ; l’agent étranger conservait la même valeur avec la session du client.

Les données circulaient alors dans GRE. L’identifiant occupait le champ Key. L’agent mère l’utilisait pour retrouver le contexte de routage ; l’agent étranger pour démultiplexer vers un client actif. Une valeur inconnue déclenchait une notification d’erreur puis la suppression silencieuse du paquet.

Le transfert d’autorité apparaît nettement : le client produisait le trafic, mais les agents décidaient du contexte d’origine, du nom local de l’état et de la persistance du rattachement. La stabilité de l’adresse provenait de blocs de contrôle qui absorbaient le changement d’accès physique.

IPX révélait le coût supplémentaire. La gestion du tunnel restait fondée sur IP. Chaque agent mère devait choisir un numéro de réseau IPX propre à l’entreprise, distinct de ses LAN ; les clients partageaient ce numéro tout en gardant des adresses de nœud uniques. La portabilité d’une couche exigeait donc une coordination nouvelle dans une autre.

La suppression faisait partie de la vérité

La présence virtuelle n’existait que tant que les deux côtés accordaient leur cycle de vie. La demande de désenregistrement était répétée toutes les deux secondes. Une réponse valide supprimait la liaison chez l’agent mère puis libérait l’identifiant chez l’agent étranger. Après dix échecs, celui-ci consignait l’erreur et coupait tout de même le client.

Un client pouvait donc avoir disparu localement alors que la suppression distante n’était pas confirmée. Après une réinitialisation, un identifiant pouvait être connu d’un côté et invalide de l’autre. La vérité opérationnelle n’était jamais un champ isolé : c’était l’alignement de deux blocs de contrôle, de l’historique des reprises, du raccordement courant et du traitement effectif des paquets.

Un protocole privé, une leçon publique

La note de l’IESG ne laisse aucune ambiguïté : le RFC 2107 documentait un protocole privé, étranger à un groupe de travail de l’IETF et sans statut de norme. Le Datatracker actuel le classe « Legacy » et sans position formelle dans le processus de normalisation.

Cet avertissement accroît sa valeur historique. Il conserve le moment où une architecture propriétaire, avant L2TP, rendait la localisation réseau portable en centralisant l’état entre l’accès et le domicile. Mobile IP couvrait une mobilité plus large ; L2F puis L2TP séparaient l’accès commuté de la terminaison PPP ; GRE fournissait l’enveloppe. ATMP assemblait un sous-ensemble particulier pour une famille de produits. La publication enregistrait ce choix, elle ne le transformait pas en consensus.

Sources