Zusammenfassung

  • RFC 2351 legte zwei verschiedenartige Luftverkehrsströme auf TCP/IP: Type A durfte verloren gehen und nach ausbleibender Antwort wiederholt werden; Type B verlangte Schutz, mehrere Empfänger und vier Prioritäten.
  • Eine TCP-Verbindung und eine bestätigte MATIP-Sitzung belegten passende Transportparameter. Sie belegten weder Reservierung noch Ticket, sichere Wiederholung oder den Übergang der Verantwortung für eine konkrete Nachricht.

1998 konnten in einem Luftfahrtbüro zwei technische Generationen nebeneinander stehen. TCP/IP-Stacks waren preiswert, Intranets verbreitet. Zugleich arbeiteten tausende Stellen weiter mit P1024B- oder P1024C-Terminals und zentralen Anwendungen, deren Protokolle bis in die sechziger Jahre zurückreichten.

RFC 2351 setzte an dieser zeitlichen Lücke an. MATIP, Mapping of Airline Traffic over Internet Protocol, standardisierte die Schicht zwischen TCP und der Luftfahrtanwendung. Nicht die Fachanwendung wurde ersetzt, sondern das inkompatible Geflecht proprietärer Gateways. Gerade deshalb musste die Spezifikation unterschiedliche Bedeutungen von Ausfall bewahren.

Type A machte Schweigen zu einer Wiederholungsentscheidung

Type A umfasste die interaktive Verbindung eines Büros oder Reisebüros mit einem zentralen Reservierungs- und Ticketrechner. Der Verkehr war zeitkritisch und hoch priorisiert, aber nur begrenzt geschützt. Er durfte verworfen werden. Bei einer durch Datenverlust ausbleibenden Antwort konnte der Benutzer die Anfrage wiederholen.

Das ist kein allgemeines Versprechen von Idempotenz. Eine Verfügbarkeitsabfrage kann anders auf Wiederholung reagieren als ein Verkauf. RFC 2351 definierte weder eine universelle Transaktionskennung noch ein Dublettenregister oder einen Abgleich für alle Anwendungen. Nur die Fachanwendung konnte entscheiden, ob der zweite Aufruf Ersatz, Doppelung oder neuer Auftrag war.

MATIP erhielt die Auswahlmerkmale, um dorthin zu gelangen. Beim Sitzungsaufbau wurden Untertyp, Zeichencodierung, Darstellung, Header und Multiplexing vereinbart. H1, H2, A1 und A2 konnten eine Terminalgruppe unabhängig von der IP-Adresse kennzeichnen; zwischen Hosts war eine Flow ID möglich. Diese Werte wählten einen Protokollkontext. Sie bewiesen weder eine Person noch ihre Buchungsbefugnis oder die Änderung im zentralen System.

Type B trug eine andere Pflicht

Type B war Nachrichtenverkehr. Echtzeit war weniger wichtig als hoher Schutz, Mehrfachadressierung und vier Prioritätsstufen. BATAP lag als Application-to-Application-Protokoll oberhalb von MATIP und sollte Type-B-Verkehr absichern.

Die Type-B-Eröffnung führte PROTEC als Kennung des Ende-zu-Ende-Protokolls zur Übertragung der Nachrichtenverantwortung. Passten die Mechanismen nicht zusammen, konnte Open Confirm die Sitzung ablehnen. Sender und Empfänger ließen sich über HLDs oder über das IP-Adresspaar bestimmen.

Gleiche Mechanismen sind noch kein Übergabebeleg. Ein übereinstimmendes PROTEC zeigt, dass beide Seiten dasselbe Verfahren verstehen. Es zeigt nicht, dass BATAP eine bestimmte Nachricht angenommen, jeder Adressat sie erhalten oder die Verantwortung tatsächlich übernommen hat. Dafür brauchte es die Bestätigung und den Zustand der Anwendung.

Ports trennten Verkehr, nicht Geschäftsergebnis

TCP-Port 350 war Type A, Port 351 Type B zugeordnet. Jeder Parametersatz benötigte eine eigene Verbindung und Sitzung. Session Open erklärte die Eigenschaften, Open Confirm nahm an oder lehnte ab, Session Close beendete MATIP. Eine eigene Keep-alive-Funktion gab es nicht; Timeouts folgten TCP.

Die Lebenszyklen überlappten, waren aber nicht identisch. Ohne TCP konnte MATIP nicht bestehen; das Schließen von MATIP musste TCP jedoch nicht beenden. Eine lebende TCP-Verbindung war damit kein Nachweis einer nutzbaren Luftfahrtsitzung. Eine angenommene MATIP-Sitzung war kein Nachweis abgeschlossener Facharbeit.

RFC 793 versprach für TCP einen zuverlässigen, geordneten Bytestrom zwischen Prozessen. RFC 1122 legte Anforderungen an die Kommunikationsschichten eines Hosts fest. Sitzbestand, Ticketnummer und Type-B-Verantwortung lagen außerhalb dieses Blickfelds.

Die Beweiskette muss daher länger bleiben: Netzpfad, TCP-Aufbau, MATIP Session Open, Open Confirm, zugelassene ASCU-, Flow-ID- oder HLD-Auswahl, Datenlieferung, Anwendungsbestätigung, Verantwortungsübergang, fachlicher Commit und Abgleich von Wiederholungen. Wer Stufen zusammenzieht, macht ein Transportsignal zur Geschäftsquittung.

Der Sicherheitshinweis markierte den Preis der Brücke

RFC 2351 erlaubte statische ASCU-Konfiguration oder Benutzerkennung und Passwort, Firewall-Kontrolle auf IP- oder Anwendungsebene sowie optional IPsec ESP und AH. Der RFC Editor weist heute darauf hin, dass statische Kennungen und offenbar unverschlüsselte Passwörter keinen soliden Schutz bieten und belastbares IPsec freiwillig blieb.

Damit wird MATIP nicht bedeutungslos, sondern begrenzt. Die Brücke löste Migration und Interoperabilität; aus einer alten Endpunktkennung konnte sie keine kryptografische Autorisierung erzeugen. RFC 4301 beschrieb später IPsec-Richtlinien und Security Associations. Auch deren Vorhandensein beweist erst zusammen mit Betriebsdaten, dass ein bestimmter Austausch geschützt war.

Die historische Leistung von RFC 2351 liegt somit in der Trennlinie: Gemeinsamer Transport war möglich, ohne Schweigen, Quittung und Abschluss auf eine einzige Definition zu reduzieren.

Quellen