Zusammenfassung

  • Ein MP_JOIN-SYN enthält das Token des Empfängers, damit dieser den richtigen MPTCP-Zustand findet. Nonces, HMACs und die lokale Annahmepolitik entscheiden getrennt über den neuen Subflow.
  • Weder das Token noch ein erfolgreicher HMAC sind ein Nachweis von Adressbesitz, Nutzeridentität, Anwendungsberechtigung oder Geschäftserfolg.

MPTCP soll für die Anwendung wie TCP aussehen: ein zuverlässiger geordneter Bytestrom. RFC 6182 legt daneben die andere Wirklichkeit offen: Im Netz bestehen mehrere TCP-Subflows mit eigenen Fünf-Tupeln. Mehrere Adressen sind ein praktischer Hinweis auf mögliche Pfade, aber kein Beweis für voneinander getrennte Leitungen. Die Architektur muss zudem mit gewöhnlichem TCP, Middleboxes und konkurrierenden Einpfad-Flows an einem gemeinsamen Engpass leben.

Die erste Verbindung trägt MP_CAPABLE in SYN, SYN/ACK und ACK. Nach RFC 8684 handeln die Endpunkte damit MPTCP für diese Verbindung aus und tauschen Schlüsselmaterial für spätere Subflow-Authentisierung aus. Bleibt der notwendige Austausch aus, etwa weil ein Peer oder eine Middlebox die Option nicht mitträgt, fällt die Sitzung auf normales TCP zurück. Eine beobachtete Option ist weder eine Verpflichtung des nächsten Pfads noch eine Aussage über Person, Berechtigung oder IP-Anspruch.

Auch die Dokumentgeschichte ist begrenzt auszulegen. RFC 6824 war 2013 ein Experimental-Protokoll für Erprobung und Bewertung. RFC 8041 hielt 2017 damals gesammelte Betriebs- und Implementierungserfahrungen fest. RFC 8684 ersetzte v0 2020 als Standards-Track-Spezifikation und nennt Deployment-Erfahrung als Hauptgrund für Klarstellungen und Änderungen. Das belegt eine lernende Spezifikation, nicht heutige Verbreitung, Produktvorgaben oder garantierte Leistung.

Der kompakte Suchschlüssel

Ein späterer MP_JOIN-SYN führt das Token des Empfängers, eine neue Zufallszahl des Senders und eine Address ID mit. Bei der v1-Auswahl mit SHA-256 sind es die obersten 32 Bits des SHA-256-Hashs des ursprünglichen Empfängerschlüssels. Der Empfänger benutzt es, um den lokalen MPTCP-Verbindungszustand zu finden, dem der neue SYN beitreten möchte.

Das Token ist ein Demultiplexing-Index, kein Berechtigungsschein. Beim SYN gibt es noch kein bekanntes Fünf-Tupel dieses neuen Subflows. Nach seiner Einrichtung demultiplexen TCP-Pakete wieder über das Fünf-Tupel. Das Token ist also kein dauerhafter Name auf jedem Paket und ersetzt keine TCP-Validierung.

Die Address ID hat einen anderen Zweck. Sie lässt eine Senderadresse zuordnen und entfernen, selbst wenn NAT den am anderen Ende sichtbaren IP-Header verändert hat. Daraus folgt weder Eigentum an der Adresse noch eine Erlaubnis, sie außerhalb dieses Verbindungszusammenhangs zu verwenden.

Der Host behält die Zulassungsentscheidung

Zur Suche kommt der HMAC-Nachweis. Der Empfänger antwortet mit eigenem Nonce und gekürztem HMAC, der Initiator mit seinem HMAC. Schlüssel aus MP_CAPABLE und beide neuen Zufallswerte binden die Prüfung an diesen konkreten Beitrittsversuch.

Bei korrekten HMACs bestätigt RFC 8684 nur, dass beide Hosts dieselben MPTCP-Peers wie zu Beginn sind und sich über die zugehörige Verbindung einig sind. Das ist Transportkontinuität, keine Anmeldung eines Menschen, keine Unternehmensvollmacht und keine Autorisierung einer nachfolgenden Anwendungstransaktion.

Vor allem bleibt lokale Ablehnung möglich: unbekanntes Token führt zu RST; bekanntes Token mit lokal verbotener Subflow-Zulassung ebenfalls; fehlender oder falscher HMAC schließt den Subflow. Ein Lookup zwingt den Zustandseigner nicht, weitere Ressourcen an ihn zu binden.

Eine Spur kann damit Initialaushandlung, Token-Suche, korrekte HMACs und einen eingerichteten Subflow belegen. Sie belegt nicht, dass eine Anwendung Daten annahm, dauerhaft speicherte oder einen Auftrag vollzog. Der Bytestrom bleibt zusammenhängend; seine Bedeutung bleibt außerhalb der Transportzuständigkeit.

Quellen und Beweisgrenzen

Die Quellen stützen Architektur, dokumentierte Revision und spezifiziertes Verhalten. Sie stützen keine aktuelle Nutzungsquote, reale Pfadtrennung, konkretes NAT-Verhalten, Produktkonformität, menschliche Identität oder Anwendungsabschluss.