Résumé

  • La RFC 1613 imposait une connexion TCP distincte à chaque circuit virtuel X.25. Le Logical Channel Number inclus dans XOT était arbitraire et ne séparait pas deux appels de même numéro arrivés par des flux différents.
  • La couche XOT devait fournir l’identité du flux au moteur X.25 ; à la sortie, celui-ci inscrivait le LCN propre à l’interface locale. L’identité opérationnelle résidait dans la correspondance, non dans un champ portable.
  • Les paramètres explicites de débit, les paquets de portée locale et le montage particulier des PVC montrent la même frontière entre règle commune et décision locale vérifiable.

Quand deux numéros justes deviennent une mauvaise clé

Dans l’exemple de la RFC, A et B ouvrent chacun une session XOT vers C. Les deux appels portent le même LCN. Si C indexe son état par ce seul nombre, deux valeurs parfaitement licites dans leurs interfaces d’origine se heurtent dans un espace artificiellement global.

RFC 1613, cisco Systems X.25 over TCP (XOT), formule le risque et la réponse. Sa notice RFC Editor la date de mai 1994 et la classe Informational ; elle ne définit aucun Internet Standard. Elle prouve l’existence d’une méthode documentée, pas son déploiement général.

Chaque circuit virtuel devait utiliser sa propre connexion TCP. Sur XOT, le LCN n’avait pas de signification déterminante et pouvait être arbitraire. Le moteur X.25 de C devait apprendre que les deux paquets provenaient d’interfaces logiques différentes. La couche XOT lui transmettait donc l’identité du flux.

La portée, et non la taille du nombre, était le problème. Un identifiant local reste intelligible grâce à l’interface et à l’état qui l’interprètent.

Une connexion complète la clé sans devenir une identité

TCP était établi avant le circuit X.25. La RFC exigeait le port TCP 1998 et interdisait d’envoyer des données XOT dans le SYN. Le registre IANA des services et ports affiche aujourd’hui x25-svc-port sur 1998 pour TCP et UDP. Cette ligne coordonne un numéro ; elle ne constate ni écoute, ni propriétaire, ni conformité. La RFC 1613 décrit TCP.

Le flux séparait les circuits portant le même LCN, mais il n’authentifiait pas un client et ne prouvait ni autorisation ni résultat applicatif. Il apportait un contexte technique.

Le TCP de la RFC 793 livre un flux ordonné d’octets, pas les limites des paquets X.25. XOT ajoutait quatre octets : Version sur 16 bits et Length sur 16 bits. La version devait valoir zéro ; une version inconnue ou une longueur illégale fermait TCP.

Cette trame n’est pas la thèse nouvelle. La RFC 1006 avait déjà restitué des enregistrements TPDU au-dessus de TCP avec un autre en-tête de quatre octets, sujet déjà traité par BTW. Ici, même un paquet parfaitement délimité peut rejoindre le mauvais circuit si son contexte flux/interface est perdu.

Le numéro change à la sortie

Lorsqu’un paquet reçu de TCP partait sur une interface X.25 locale, l’implémentation devait inscrire le LCN utilisé par cette interface. La continuité du circuit supportait donc un changement de nombre.

Une preuve exploitable relie la connexion TCP, l’interface XOT logique, le LCN entrant, l’interface sortante et son LCN. Conserver seulement le champ intérieur produit une ambiguïté précise ; conserver seulement les extrémités TCP efface l’allocation locale.

La primauté du code en fonctionnement donne ici une règle de lecture concrète. Le texte fixe l’interopérabilité minimale. Configuration, transitions d’état et observations de paquets prouvent l’instance locale. Leur résultat ne doit pas être gonflé en identité sociale ou en succès de service.

Les valeurs par défaut ne traversent pas le réseau

Un réseau X.25 pouvait disposer de tailles de paquet et de fenêtre par défaut. Entre sites divers reliés par TCP/IP, la RFC jugeait ce défaut commun impraticable : chaque Call devait donc annoncer Packet Size et Window Size. Accepter un Call incomplet restait une décision locale, mais le Call Confirm devait alors rendre les valeurs effectives explicites.

Le contrôle de flux pouvait être bout en bout ou local. La variante locale pouvait fragmenter ou regrouper les données et entretenir des numéros de séquence distincts. Une jonction modulo 128/modulo 8 devait traduire l’état, réduire une fenêtre trop grande ou refuser l’appel. Un RNR dans un sens ne permettait pas de supposer l’arrêt des DATA dans l’autre.

La fiabilité de TCP ne répondait donc pas aux questions de fenêtre, de préparation du récepteur, de traduction ou d’achèvement métier.

Ce qui traverse, et ce qui s’arrête

Interrupt et Reset conservaient une portée bout en bout. Restart, DTE Reject, Diagnostic et Registration n’avaient qu’une portée d’interface locale : ils ne devaient pas traverser XOT et étaient rejetés silencieusement s’ils arrivaient de TCP.

Les PVC rendaient la frontière encore plus visible. Un PVC X.25 était normalement provisionné sans Call/Clear. XOT avait besoin d’un échange non standard après l’établissement TCP, avec noms d’interfaces, LCN locaux et valeurs de flux. Le répondant pouvait distinguer interface absente ou arrêtée, PVC inexistant, configuration ou débit incompatibles. Un succès de statut zéro était suivi d’un Reset local ; fermer TCP rompait le PVC. Deux connexions créées par une collision de montage ne devaient jamais transporter le trafic en parallèle.

Ces statuts décrivent une machine d’état, pas la personne, le contrat ou l’utilité du trafic.

Limite de preuve

La section sécurité de la RFC 1613 dit seulement que les questions de sécurité ne sont pas abordées. Ce silence ne constitue pas une assurance. Aucune source n’établit authentification, chiffrement, autorisation ou protection contre une mauvaise association.

Aucune implémentation, version Cisco, session réelle ou capture n’a été testée. Le registre IANA ne prouve pas un service actif. Les sources ne mesurent ni déploiement actuel, ni part de marché, ni incident, ni résultat applicatif, ni filiation directe avec un overlay moderne.

La conclusion certaine est plus étroite : un champ peut être valide sans posséder la portée nécessaire pour identifier l’objet opérationnel. RFC 1613 conserva le flux et l’interface que le nombre ne pouvait contenir.

Sources