Résumé

  • RFC 2351 a normalisé le passage de deux familles de trafic aérien sur TCP/IP : le Type A, interactif et retentable après un silence, et le Type B, protégé, priorisé et destiné à plusieurs adresses.
  • L’ouverture d’une connexion TCP puis l’acceptation d’une session MATIP attestent une compatibilité de transport. Elles ne prouvent ni la réservation d’un siège, ni l’émission d’un billet, ni l’innocuité d’un doublon, ni le transfert effectif de responsabilité d’un message.

À la fin des années 1990, le coût du réseau baissait plus vite que celui du remplacement des applications. Des milliers de bureaux de compagnies aériennes utilisaient encore des terminaux P1024B ou P1024C et des systèmes centraux conçus bien avant l’OSI et SNA. Les piles TCP/IP devenaient courantes et bon marché, mais le métier restait logé dans des protocoles propriétaires.

RFC 2351 n’a pas tenté de réécrire ce métier. MATIP, pour Mapping of Airline Traffic over Internet Protocol, a défini une couche entre TCP et l’application aérienne. C’est précisément cette modestie qui rend le texte intéressant : le transport devient commun, tandis que les règles d’échec restent attachées au service qui peut réellement les comprendre.

Le Type A traitait le silence comme une invitation à réessayer

Le Type A couvrait les échanges interactifs entre un bureau, une agence de voyages ou un poste terminal et l’ordinateur central de réservation ou de billetterie. Le trafic était prioritaire et en temps réel, mais faiblement protégé. Le RFC précise qu’il pouvait être abandonné et qu’en l’absence de réponse après une perte, l’utilisateur pouvait répéter la demande.

Cette possibilité n’est pas une garantie générale d’idempotence. Consulter une disponibilité une seconde fois n’a pas le même effet que répéter une vente. Le texte ne définit ni identifiant transactionnel universel, ni journal de dédoublonnage, ni procédure de rapprochement pour toutes les applications. Il décrit seulement le comportement prévu face au silence.

MATIP conservait les identités utiles à cette pratique. Une session Type A négociait le sous-type, le codage, la présentation, l’en-tête et le multiplexage. Les octets H1, H2, A1 et A2 permettaient au système central de reconnaître un groupe terminal indépendamment de l’adresse IP. Un Flow ID pouvait distinguer les flux entre hôtes. Ces valeurs sélectionnaient un contexte de protocole ; elles ne démontraient pas l’identité juridique de l’auteur ni la décision prise par le système de réservation.

Le Type B transportait une obligation différente

Le Type B était de la messagerie. Il n’exigeait pas une réponse immédiate, mais devait supporter une protection élevée, plusieurs destinataires et quatre niveaux de priorité. RFC 2351 plaçait BATAP, le protocole applicatif de transfert entre applications Type B, au-dessus de MATIP.

Lors de l’ouverture, le champ PROTEC indiquait le mécanisme de transfert de responsabilité de bout en bout. Si les deux extrémités n’annonçaient pas un mécanisme compatible, la confirmation pouvait refuser la session. Des HLD pouvaient désigner l’émetteur et le destinataire ; à défaut, la paire d’adresses IP pouvait servir à identifier les systèmes.

Il faut résister à un raccourci : l’accord sur PROTEC établit que les deux côtés savent employer le même mécanisme. Il ne constitue pas le reçu de transfert pour un message donné. Les données doivent encore être acceptées par BATAP ou le service convenu, recevoir l’acquittement prévu et être rapprochées de l’état applicatif.

Les ports séparaient les flux, pas les preuves

Les ports TCP 350 et 351 distinguaient respectivement Type A et Type B. Chaque ensemble de paramètres exigeait sa propre connexion et sa propre session. Session Open annonçait les caractéristiques ; Open Confirm acceptait ou refusait ; Session Close terminait la couche MATIP. Aucun keep-alive MATIP n’était défini : l’expiration dépendait de TCP.

Les cycles de vie étaient liés sans être identiques. Une session MATIP ne pouvait rester active si TCP tombait, mais fermer MATIP n’obligeait pas à fermer TCP. Une connexion TCP ouverte n’attestait donc pas que la session aérienne était utilisable. Une session MATIP acceptée n’attestait pas davantage que le traitement métier était terminé.

TCP, tel que le définissait RFC 793, fournit un flux d’octets ordonné et fiable entre processus. RFC 1122 impose aux hôtes les exigences de cette couche de communication. Aucun des deux ne peut voir l’inventaire de sièges, l’émission d’un numéro de billet ou la prise en charge d’un message Type B.

La chaîne de preuve devrait rester explicite : chemin réseau, établissement TCP, ouverture MATIP, confirmation, autorisation de l’ASCU ou du HLD, livraison des données, acquittement applicatif, transfert de responsabilité, écriture de l’état métier, puis rapprochement visible par l’utilisateur. Faire disparaître un maillon revient à attribuer au transport une connaissance qu’il n’a pas.

L’avertissement de sécurité révélait la limite du compromis

RFC 2351 autorisait une configuration statique de l’ASCU ou un couple identifiant-mot de passe. Le filtrage pouvait intervenir au niveau IP ou applicatif. IPsec ESP ou AH restait facultatif. Le RFC Editor accompagne aujourd’hui le texte d’un avertissement : les identifiants statiques et les mots de passe apparemment en clair sont faibles, tandis que la protection robuste par IPsec n’était qu’une option.

Cette critique ne rend pas MATIP inutile. Elle indique ce que la couche ne pouvait pas faire. Un pont de migration peut réduire les coûts et rendre les passerelles interopérables ; il ne peut pas convertir une ancienne étiquette de terminal en autorisation cryptographique. L’architecture IPsec de RFC 4301 ajoute politiques et associations de sécurité, mais leur simple possibilité ne prouve pas qu’un échange précis a été protégé comme prévu.

L’apport historique de RFC 2351 tient donc à une séparation. L’Internet pouvait devenir le transport commun sans obliger une requête de réservation et un message opérationnel à partager la même notion de réussite. La couche basse déplaçait les octets. Les couches supérieures gardaient la charge de définir le silence, l’acquittement et l’achèvement.

Sources