Zusammenfassung

  • MP_ADDADDR ist authentifizierter Soft State. Die Ankündigung darf verworfen werden und beweist weder globale Erreichbarkeit noch Eigentum oder Gutartigkeit der angekündigten Adresse.
  • Nach einem mit MP_KEY erfolgreich aufgebauten ersten Subflow verwendet MP_JOIN die Verbindungskennung, eine innerhalb der Verbindung eindeutige Address ID und eine frische 32-Bit-Nonce, um den Beitritt an die ursprüngliche Verbindung zu binden.
  • MP_HMAC verwendet HMAC-SHA256, auf die links stehenden 160 Bit gekürzt. Für jede geschützte Option ist ein unmittelbar folgendes eigenes MP_HMAC erforderlich. Ein ungültiges MP_JOIN schließt den versuchten Subflow; ein ungültiges MP_ADDADDR oder MP_REMOVEADDR wird stillschweigend ignoriert.

Die eigentliche Zulassungsgrenze

RFC 9897 erweitert DCCP so, dass eine Verbindung mehrere DCCP-Subflows über unterschiedliche Pfade aufbauen und verwenden kann. Die erste Verbindung erhält ihre Kontinuität über MP_KEY und die daraus bekannte Connection ID. Wenn die Gegenstelle anschließend MP_ADDADDR sendet, ist das zunächst nur eine Mitteilung über eine mögliche Adresse. Das empfangende System kann diese Soft-State-Information verwerfen. Broadcast- und Multicast-Adressen sind zu ignorieren. Scheitert eine Adresse/Port-Kombination, sollte die Implementierung nicht fortlaufend neue Verbindungsversuche daraus ableiten, sofern die Ankündigung nicht erneuert wird.

Der entscheidende Schritt ist MP_JOIN. Die Nachricht enthält die Connection ID der Gegenstelle, eine vom Sender erzeugte Address ID und eine frische 32-Bit-Nonce. Die Address ID muss die Quelladresse des Senders innerhalb dieser Verbindung eindeutig abbilden. Sie bleibt erhalten, solange sie noch von einem der Endpunkte verwendet wird, und ermöglicht die Zuordnung eines MP_JOIN zu MP_ADDADDR, auch wenn ein Middlebox-Gerät Adressen umschreibt. Die Nonce ist für die einmalige Verwendung vorgesehen; geeignete Zufallswerte unterstützen den Schutz gegen Replay.

Der Austausch bindet die beitretende Seite an die ursprüngliche Verbindung und prüft die Erreichbarkeit an der angekündigten Adresse. Er macht aus einer authentifizierten Behauptung aber keine universelle Aussage über den Pfad.

Die Authentisierung der Optionen folgt HMAC nach RFC 2104 mit SHA-256 aus RFC 6234; übertragen werden die links stehenden 160 Bit des HMAC-SHA256-Ergebnisses. Ein MP_HMAC muss unmittelbar auf die jeweils geschützte Option folgen. Ein HMAC irgendwo in der Nachricht oder ein HMAC für eine andere Option reicht nicht. Bei einem ungültigen MP_ADDADDR oder MP_REMOVEADDR wird die Option stillschweigend ignoriert. Ein ungültiges MP_JOIN hat eine andere Konsequenz: Der versuchte Subflow wird geschlossen. Diese unterschiedliche Fehlerbehandlung gehört in Tests und Betriebsauswertung.

MP-DCCP liefert damit keine vollständige kryptografische Sicherheit. MP_HMAC ist weder Ende-zu-Ende-Verschlüsselung noch eine vollständige Authentisierung der Anwendungsdaten. Selbst ein gültiger HMAC beweist nicht, dass die Adresse harmlos, im globalen Netz erreichbar oder tatsächlich Eigentum der Gegenstelle ist. RFC 9897 weist außerdem auf das Risiko hin, dass ein Angreifer über angekündigte private Adressen unerwünschten Handshake-Verkehr zu anderen Hosts lenkt. Sender- und Empfänger-Heuristiken können den Denial-of-Service-Effekt reduzieren; eine einheitliche Heuristik schreibt die Spezifikation jedoch nicht vor.

RFC 9897 ist eine IETF-Spezifikation im Standards-Track. Der Quellensatz liefert keine Aussagen zu gemessener Verbreitung, Leistungsgewinnen oder Vorfallraten. Ebenso gibt es keinen universellen Scheduler, keine vorgeschriebene gekoppelte Congestion-Control, kein festgelegtes Retry-Budget, keinen Telemetrie-Schwellenwert und keine verbindliche Regel zum Zurückweisen verdächtiger Adressen. Scheduling, gekoppelte Überlaststeuerung und Reordering für den allgemeinen Internetbetrieb liegen ausdrücklich außerhalb des Umfangs.

Key Type 0 ist für Interoperabilitätstests erforderlich, überträgt Schlüsselmaterial aber im Klartext; bei höheren Schutzanforderungen müssen Betreiber Key Type und Ende-zu-Ende-Schutz selbst entscheiden, etwa IPsec oder DTLS.

Konkrete Prüf-Fixtures

  1. Baue den ersten Subflow mit MP_KEY auf, sende danach ein gültiges MP_ADDADDR und prüfe, dass der Zustand nur „angekündigt“ lautet, nicht „für Verkehr freigegeben“.
  2. Teste eine Address ID, die zwei Quelladressen zugeordnet wird, sowie eine durch ein Middlebox-Gerät umgeschriebene Adresse. Die Zuordnung zu MP_ADDADDR und die Nicht-Wiederverwendung während aktiver Nutzung müssen sichtbar bleiben.
  3. Wiederhole eine 32-Bit-Nonce und sende anschließend eine neue; prüfe Einmalverwendung und die Behandlung von Replay, ohne einen nicht spezifizierten Timer zu unterstellen.
  4. Setze den MP_HMAC absichtlich nicht direkt hinter MP_JOIN, MP_ADDADDR oder MP_REMOVEADDR. Prüfe danach separat ungültiges MP_JOIN sowie ungültige Add-/Remove-Optionen: einmal Subflow-Schließung, einmal stilles Ignorieren.
  5. Verwende private, Broadcast- und Multicast-Adressen und dokumentiere lokale Schutzheuristiken, ohne sie als RFC-MUSS oder als universelle Ablehnungsregel auszugeben.

Betreiber-Entscheidungspfad

Erstens: Kontinuität von MP_KEY und Connection ID prüfen. Zweitens: Address-ID-Eindeutigkeit, Lebenszyklus und Zuordnung zur angekündigten Quelle prüfen. Drittens: frische, einmalige Nonce und HMAC-SHA256 mit 160-Bit-Trunkierung sowie die unmittelbare Option-HMAC-Nachbarschaft validieren. Viertens: erst nach vollständig abgeschlossenem MP_JOIN und bestätigter bidirektionaler Erreichbarkeit Verkehr zulassen. Bei MP_ADDADDR oder MP_REMOVEADDR einen HMAC-Fehler als stilles Ignorieren behandeln; bei MP_JOIN den versuchten Subflow schließen. Die Empfehlung, eine Beobachtungskette aus „angekündigt“, „Join läuft“, „bestätigt“ und „verworfen“ zu führen, Retry-Budgets zu definieren und verdächtige Adressen heuristisch zu gewichten, ist Analyse von Theo March, kein RFC-Mandat. Auch konkrete Metrikschwellen und Zeitwerte bleiben lokale Entscheidungen.

Quellen