Zusammenfassung

  • UDP ASSOCIATE entstand auf einer TCP-Verbindung nach der Methodenaushandlung und endete mit genau dieser Verbindung. Der Stream bestimmte die Lebensdauer des Kontexts, nicht den Transport oder die Zuverlässigkeit der UDP-Nutzdaten.
  • Gebundener Relay-Endpunkt, erwartete Client-IP, Ziel im einzelnen Datagramm, Schutzmethode und Fragmentzustand blieben getrennte Aussagen. Keine war allein Benutzeridentität oder Zustellbeleg.

Laufender Verkehr durfte keinen Zustand erben

Ein Relay empfängt weiterhin UDP, obwohl sein TCP-Steuerkanal gerade geschlossen wurde. Das kann nach einem Prozessabbruch, einem NAT-Wechsel, einem mobilen Pfadwechsel oder einem Proxy-Neustart geschehen. Das nächste Datagramm ist syntaktisch korrekt und nennt ein erlaubtes Ziel. Technisch wäre Weiterleitung noch möglich.

RFC 1928 aus dem März 1996 entzog ihr dennoch die Grundlage: Eine UDP-Assoziation endet, wenn die TCP-Verbindung endet, auf der UDP ASSOCIATE eingetroffen ist. Ankommende Bytes beweisen Aktivität, aber nicht den Fortbestand der früher ausgewerteten Sicherheits- und Policyentscheidung.

UDP lief dabei nicht durch TCP. Jedes Datagramm behielt seine eigene Verlust-, Duplikations- und Reihenfolgeunsicherheit. TCP trug Methodenauswahl und Erzeugungsantrag; sein Ende war ein beobachtbarer Aufräumpunkt für einen Zustand, den UDP selbst nicht schließen konnte.

Diese Arbeitsteilung war absichtlich schmal. Ein verbindungsloser Dienst erhielt einen überprüfbaren Anfang und ein Ende, ohne dass der Standard ihm Streamgarantien zuschrieb.

Die Anfrage konnte ihre künftige Quelle noch nicht kennen

Der Client bot zunächst Authentisierungsmethoden über TCP an. Der Server wählte eine, beide führten deren Subnegotiation aus, und erst danach folgte CONNECT, BIND oder UDP ASSOCIATE.

Die UDP-Anfrage konnte Adresse und Port nennen, von denen der Client voraussichtlich senden würde. Der Server durfte den Zugriff damit beschränken. Waren die Werte noch unbekannt, musste der Client eine Nulladresse und Port null verwenden.

Null bedeutete nicht „jede Quelle“. Es bedeutete, dass die Anfrage keine konkrete Quelle belegen konnte. Der Server musste aus Verbindung, Beobachtung und lokaler Konfiguration eine wirksame Bindung bilden.

Die Erfolgsantwort lieferte BND.ADDR und BND.PORT. Dorthin musste der Client seine SOCKS-UDP-Umschläge senden. Bei einem Multihoming-Server konnte diese Adresse von der TCP-Adresse abweichen. Sie bezeichnete den Relay-Eingang, nicht den entfernten Dienst.

Mindestens drei Adresspaare gehörten deshalb ins Protokollbuch: TCP-Steuerziel, zurückgegebener UDP-Relayendpunkt und das im Datagramm deklarierte Remoteziel. Ein einziges Feld „Proxy-Adresse“ verschleiert, welche Reichweite oder Policy tatsächlich versagte.

Das Ziel stand in jedem Umschlag neu

Der SOCKS-UDP-Header enthielt Reserved, FRAG, Adresstyp, Zieladresse, Zielport und Daten. Ein Client konnte innerhalb derselben Assoziation verschiedene Ziele ansprechen. Das Relay wertete die Absicht pro Datagramm aus.

Antwortete ein entfernter Host, verpackte das Relay dessen Datagramm in derselben Grammatik. So erfuhr der Client, welche Quelladresse und welchen Port das Relay beobachtet hatte. Das war eine Korrelationsaussage, keine kryptographische Identität.

Das Relay konnte Annahme, Policyentscheidung und Ausgangssendung bezeugen. Es konnte nicht allein feststellen, ob der Pfad zustellte, die Anwendung verarbeitete oder eine Geschäftswirkung eintrat. Auch eine Rückantwort war ein neuer Bericht, kein universeller Genau-einmal-Nachweis.

Nach TCP-Ende konnte BND.ADDR im Clientcache verbleiben. Ein korrekt formatierter Umschlag an den alten Endpunkt stellte die verlorene Assoziation nicht wieder her. Adresswissen war keine dauerhafte Berechtigung.

Quellbindung war eine Netzgrenze, keine Person

RFC 1928 verlangte, dass das UDP-Relay die erwartete Client-IP vom SOCKS-Server erhält und Datagramme anderer Quell-IPs still verwirft. Ein fremder Host sollte einen bestehenden Kontext nicht einfach mitbenutzen.

Mehr bewies die Regel nicht. Eine IP kann viele Geräte hinter NAT, mehrere Prozesse und wechselnde mobile Identitäten vertreten. Der Vergleich sagte, welche Netzquelle am Relay sichtbar war. Er sagte nicht, wer den TCP-Kanal eröffnet hatte oder ob das Ziel die Operation autorisierte.

Die Authentisierung lag in der ausgehandelten Methode. RFC 1929 definierte Benutzername und Passwort, übertrug beide aber innerhalb der Subnegotiation im Klartext und warnte vor sniffbaren Umgebungen. RFC 1961 definierte GSS-API mit Authentisierung sowie aushandelbarer Nachrichtenintegrität und optionaler Vertraulichkeit.

„SOCKS5“ war folglich kein einheitliches Sicherheitsniveau. Ein belastbarer Beleg nennt ausgewählte Methode, Ergebnis, Schutzstufe und geschützte Nachrichten. Weder Versionsnummer noch Source-IP-Test dürfen fehlende Eigenschaften ergänzen.

FRAG führte nur widerrufliche Kurzzeitgeschichte

Im SOCKS-Umschlag bedeutete FRAG=0 ein eigenständiges Datagramm. Werte eins bis 127 beschrieben Fragmentpositionen; das höchste Bit markierte das Ende. Das war keine IP-Fragmentierung, sondern eine Relay-interne Grammatik.

Reassembly blieb optional. Eine Implementierung ohne Unterstützung musste jedes nichtnull FRAG verwerfen. Eine unterstützende Seite führte Queue und Timer. Ablauf ließ alle Fragmente fallen; ebenso setzte ein neu eintreffender Wert unterhalb der bisher höchsten Nummer die Queue zurück. Der Timer durfte nicht kürzer als fünf Sekunden sein, und die Spezifikation empfahl, Fragmentierung möglichst zu vermeiden.

ACKs oder Retransmissionspflichten entstanden dadurch nicht. Die Queue rekonstruierte lokal oder gab auf. Selbst ein vollständiger Datensatz bewies nur, dass der nächste Verarbeitungsschritt möglich war.

Betrieblich müssen deshalb Source-Mismatch, nicht unterstütztes FRAG, Sequenzrücklauf, Timerablauf, Policyverweigerung und Verlust hinter dem Relay getrennte Ursachen bleiben. Ein Sammelzähler „UDP fehlgeschlagen“ entzieht dem richtigen Team die Diagnose.

Das TCP-Ende verhinderte eine verwaiste Befugnis

Eine reine Leerlauffrist räumt Ressourcen auf, kann aber Schweigen nicht erklären. Eine Verlängerung durch laufende Datagramme hat das Gegenproblem: Wer den Endpunkt kennt, könnte den Kontext ohne erneute Authentisierung am Leben halten.

Die Steuerverbindung war ein stärkeres, wenn auch begrenztes Signal. Der Server konnte Methodenstatus, Policy und UDP-Eintrag an eine lebende Unterhaltung binden. Mit deren Ende wählte der Standard Widerruf statt Vermutung. Weitere Nutzung verlangte einen neuen Antrag.

Das kostete Verfügbarkeit. Ein kurzer TCP-Fehler konnte gesunden UDP-Verkehr stoppen; Mobilität machte Steuerung und Source-Bindung gleichzeitig alt; ein offener Socket verbrauchte Ressourcen. Dafür blieb die Grenze testbar und durch Neuaufbau reversibel. Ein verwaistes Relay, das sich durch schlecht zurechenbare Pakete selbst verlängert, wäre bequemer und institutionell gefährlicher gewesen.

Auch die IPv6/IPv4-Brücke blieb Anwendungsschicht

Das Informational-Dokument RFC 3089 beschrieb 2001 ein SOCKS-basiertes IPv6/IPv4-Gateway. Es terminierte Kommunikation beider Adressfamilien auf der Anwendungsschicht und konnte Namensauflösung an einen Dual-Stack-Knoten delegieren, wenn eine alte Anwendung keine IPv6-Adresse speichern konnte.

Die Brücke erbte CONNECT, BIND und UDP ASSOCIATE. Sie wurde deshalb nicht zum transparenten IP-Router. Angefragter Name, DNS-Ergebnis, Steuerassoziation und weitergegebene Daten blieben unterscheidbare Gegenstände.

Die historische Leistung lag in einem kleinen gemeinsamen Vertrag. Der Client konnte begrenzte Arbeit erbitten. Das Relay durfte lokal entscheiden. Kein Feld musste zur zentralen Wahrheit über den gesamten Pfad aufgeblasen werden.

Quellen