Zusammenfassung

  • RFC 1613 verlangte eine eigene TCP-Verbindung für jeden virtuellen X.25-Kanal. Die Logical Channel Number in XOT war beliebig und konnte gleich nummerierte Anrufe auf verschiedenen Streams nicht unterscheiden.
  • XOT musste die Stream-Identität an die X.25-Engine geben; am Ausgang wurde die LCN der lokalen Schnittstelle eingesetzt. Die operative Identität lag in der Abbildung, nicht in einem portablen Feld.
  • Explizite Flussparameter, lokal bleibende Kontrollpakete und das gesonderte PVC-Setup trennten gemeinsame Interoperabilität von lokaler Entscheidung.

Zwei richtige Nummern ergeben einen falschen Schlüssel

Im Beispiel rufen A und B über verschiedene XOT-Sitzungen C an und benutzen dieselbe LCN. Sucht C nur nach dieser Zahl, kollidieren zwei lokal zulässige Werte in einem erfundenen globalen Namensraum.

RFC 1613, cisco Systems X.25 over TCP (XOT), beschreibt genau dieses Risiko. Der RFC-Editor-Eintrag datiert das Dokument auf Mai 1994 und stuft es als Informational ein, nicht als Internet Standard. Belegt ist eine veröffentlichte Methode, keine allgemeine Einführung.

Jeder Virtual Circuit brauchte eine eigene TCP-Verbindung. Die LCN im XOT-Paket hatte keine eigenständige Bedeutung. Cs X.25-Engine musste erfahren, dass die gleich nummerierten Pakete über verschiedene logische XOT-Schnittstellen eingingen; XOT reichte daher die Stream-Identifikation weiter.

Der Stream ergänzte den Geltungsbereich

TCP entstand vor dem X.25-Kanal. RFC 1613 nannte TCP-Port 1998 und verbot XOT-Daten im SYN. Das heutige IANA-Register führt x25-svc-port auf 1998 für TCP und UDP. Ein Registereintrag beweist weder offenen Dienst noch Betreiber oder Konformität; das RFC-Verfahren benutzt TCP.

Eine Verbindung pro VC trennt gleiche LCNs, authentifiziert aber keinen Teilnehmer und belegt kein Anwendungsergebnis.

Das historische TCP in RFC 793 liefert einen geordneten Oktettstrom, keine X.25-Paketgrenzen. XOT ergänzte vier Oktette: je 16 Bit Version und Length. Version musste null sein; unbekannte Version oder illegale Länge schlossen TCP.

Dieses Framing ist nur Voraussetzung. RFC 1006 hatte mit einem anderen Vier-Oktett-Header bereits TPDU-Grenzen über TCP hergestellt; BTW hat diese Geschichte veröffentlicht. Bei XOT kann selbst ein korrekt begrenztes Paket dem falschen Circuit zugeordnet werden, wenn Stream und Schnittstelle fehlen.

Am Ausgang wechselte die Nummer

Beim Übergang zu einer lokalen X.25-Schnittstelle musste die Implementierung deren LCN einsetzen. Der Circuit konnte also fortbestehen, obwohl die Zahl wechselte.

Ein belastbarer Beleg verbindet TCP-Connection, logische XOT-Schnittstelle, eingehende LCN sowie ausgehende Schnittstelle und LCN. Nur die Nummer ist mehrdeutig; nur TCP-Endpunkte verbergen die lokale Zuweisung. Running-Code Primacy hält die Aussage prüfbar: Das RFC liefert die Minimalregel, laufende Konfiguration, Zustandswechsel und Pakete belegen die konkrete Abbildung.

Defaults und Kontrolle blieben lokal

Packet Size und Window Size mussten in jedem Call explizit stehen, weil verschiedene Standorte keinen gemeinsamen X.25-Netzstandardwert voraussetzen konnten. Einen unvollständigen Call anzunehmen war lokal; Call Confirm musste dann die tatsächlich verwendeten Werte nennen.

Flow Control konnte end-to-end oder lokal sein. Lokal durften DATA fragmentiert oder zusammengeführt und Sequenzen getrennt geführt werden. Modulo 128/8 erforderte Übersetzung und gegebenenfalls kleinere Fenster oder Ablehnung. RNR in einer Richtung stoppte nicht automatisch DATA in der anderen. TCP-Zuverlässigkeit bewies damit weder Fensterkompatibilität noch Empfangsbereitschaft oder Abschluss.

Interrupt und Reset behielten End-to-End-Bedeutung. Restart, DTE Reject, Diagnostic und Registration waren lokal und durften XOT nicht queren.

PVCs bestanden sonst durch Provisionierung ohne Call/Clear. XOT brauchte ein nicht standardisiertes Setup mit Schnittstellennamen, lokalen LCNs und Flow-Werten. Statuswerte trennten fehlende/down Schnittstelle, unbekannten PVC und Konfigurations- oder Flow-Mismatch. Erfolg null führte zu lokalen Resets; TCP-Schluss brach den PVC. Zwei durch Setup-Kollision entstandene TCP-Verbindungen durften nie parallel Daten tragen.

Evidenzgrenze

Der Security-Abschnitt sagt nur, Sicherheitsfragen würden nicht behandelt. Schweigen ist keine Zusicherung. Keine Quelle belegt Authentifizierung, Verschlüsselung, Autorisierung oder Schutz vor Fehlbindung.

Getestet wurden weder Implementierung, Cisco-Release, Betreiber noch Mitschnitt. IANA belegt keinen aktiven Dienst. Gegenwärtige Verbreitung, Vorfälle, Anwendungserfolg und direkte moderne Abstammung bleiben unbelegt.

Die tragfähige Folgerung ist klein: Ein gültiges Feld kann zu wenig Geltungsbereich besitzen, um das operative Objekt zu identifizieren. RFC 1613 bewahrte im Stream und in der Schnittstelle die Grenze, die nicht in die Zahl passte.

Quellen