Zusammenfassung

  • RFC 9853 ergänzt DTLS 1.2 und 1.3 um eine authentisierte und verschlüsselte Rückwegbarkeitsprüfung. Eine an die Herausforderung gebundene Antwort kann die Aktualisierung der CID-Adresse rechtfertigen; ein Timeout lässt die alte Bindung bestehen.
  • Das Ergebnis ist enger als Identität, Autorisierung oder eine vollendete Migration. Ein belastbarer Beleg trennt Auslöser, Bedrohungsmodell, Prüfbudget, Antwortbindung, Kontextverschiebung, Anwendungsannahme, Beobachtung und Rückfallziel.

Der erste Record von Adresse B ist gültig. Seine CID wählt einen Sicherheitskontext, der entstand, als der Peer Adresse A nutzte; Epoche und Sequenznummer passen; die authentisierte Entschlüsselung gelingt. Dennoch ist nicht entschieden, ob die nächste Anwendungsantwort an B gehen darf.

Eine Connection ID befreit die DTLS-Assoziation von der dauerhaften Bindung an ein UDP-Tupel. Das hilft mobilen, beschränkten und durch NAT angebundenen Geräten. Zugleich entsteht eine Umleitungsfläche. Eine Kopie eines echten Records kann auf einem schnelleren Weg zuerst eintreffen; eine manipulierte Quelladresse kann große Antworten zu einem Opfer lenken.

RFC 9146 verlangte vor einem Adresswechsel bereits drei Dinge: kryptografische Verifikation, einen nach Epoche und Sequenz neueren Record und eine Strategie, die Empfangs- und Verarbeitungsfähigkeit der neuen Adresse zeigt. Die konkrete Strategie blieb offen.

RFC 9853, seit März 2026 IETF Standards Track, schließt diese Lücke für DTLS 1.2 und 1.3 und aktualisiert RFC 9146 sowie RFC 9147. Der Return Routability Check, RRC, prüft den Kandidatenpfad, bevor die lokale Zuordnung von CID zu Adresse geändert wird.

Die Reihenfolge darf nicht verschwimmen. CID findet Zustand, der Record Layer prüft Zugehörigkeit, RRC prüft einen Pfad, danach entscheidet der Empfänger über seine Bindung. Kein Schritt erbt stillschweigend die Bedeutung des nächsten.

Vorher ausgehandelt

RRC wird mit der leeren Erweiterung rrc, Wert 61, ausgehandelt. Ein Client muss zugleich connection_id anbieten; der Server bestätigt in ServerHello. Ohne erfolgreichen beidseitigen Austausch darf RRC nicht eingesetzt werden.

Auch danach kann eine Anwendung einen eigenen Mechanismus nutzen. RFC 9175 gibt CoAP mit Echo eine ressourcen-, methoden- und regelabhängige Frische- oder Erreichbarkeitsprüfung. Transportreichweite und Anwendungsbereitschaft bleiben verschiedene Fragen.

Content Type 27, return_routability_check, trägt path_challenge, path_response und path_drop. Jede Nachricht enthält ein acht Oktett langes Cookie mit 64 Bit Entropie und wird mit dem aktiven DTLS-Kontext authentisiert und verschlüsselt.

Das Cookie ist weder Identität noch Besitznachweis oder Erlaubnis. Es ordnet die Antwort einer konkreten Herausforderung zu. Ein Protokoll, das nur „RRC bestanden“ speichert, verliert Verbindung, Versuch, Zielpfad, Beginn und Ablauf der Aussage.

Erst das Budget, dann der Beweis

Bei erkannter Adressänderung stoppt der Empfänger gepufferte Anwendungssendungen oder begrenzt sämtlichen Ausgang zur ungeprüften Adresse auf das Anti-Amplification-Limit: das Dreifache der von dort empfangenen, nicht verworfenen Daten.

Das ist kein Durchsatzwert, sondern ein Risikodeckel. Eine kleine Nachricht mit gefälschter Quelle darf keine große Antwort freigeben. Stattdessen geht eine kleine geschützte Herausforderung hinaus. Ein Opfer ohne DTLS-Zustand kann sie nicht entschlüsseln und keine passende Antwort erzeugen; die Bindung bleibt unverändert.

Beim einfachen Verfahren sendet der Initiator ein unvorhersagbares Cookie in path_challenge an die neue Adresse und startet T. Der Peer prüft es und spiegelt den Wert in path_response. Erst die passende Antwort erlaubt das Update. Läuft T ab, erfolgt keines.

Verlust erlaubt zusätzliche Herausforderungen, aber keine unbegrenzte Folge. Sie sollten in getrennten Transportpaketen liegen, getaktet werden und jeweils Zufall enthalten. Ohne Anwendungsvorgabe gilt ein Versuch pro RTT bis zum Limit als Orientierung. Der Antwortende sendet pro gültiger Herausforderung genau eine unverzügliche Antwort an deren Quelladresse. Die PMTU des Rückwegs wird damit nicht ermittelt.

Auch T gehört zur Beweisgrundlage. Bei extern bekanntem RTT des aktiven Pfads werden drei RTT empfohlen, sonst eine Sekunde; Profile dürfen abweichen. Ein Timeout beweist kein dauerhaftes Verschwinden, sondern fehlende Evidenz innerhalb des gewählten Fensters.

Der alte Pfad als Gegenprobe

Das einfache Verfahren reduziert Verstärkung. Ein Off-Path-Angreifer kann jedoch echte Records beobachten und Kopien über eine schnellere Strecke vorauseilen lassen. Der Gewinner sieht wie eine Migration aus. Eine Prüfung nur des neuen Weges könnte den Angreifer auf den Pfad bringen.

Das erweiterte Verfahren fragt deshalb zuerst die alte Adresse. path_response auf dem weiterhin bevorzugten Pfad erhält die Bindung. path_drop sagt, dass der alte Weg lebt, aber nicht mehr bevorzugt wird; anschließend wird B einfach geprüft. Schweigt der alte Weg bis zum Timeout, folgt ebenfalls die Prüfung des neuen — keine automatische Migration.

Schweigen, ausdrückliche Aufgabe und bestätigte Präferenz bleiben getrennt. Vollständig ist die Abwehr nicht. Ein dauerhaft schnellerer Angreiferweg kann von einer echten Routingverbesserung ununterscheidbar sein. Kürzliches Altpfad-Verkehrsaufkommen und Duplikate können lokale Heuristiken speisen, erweitern aber die Cookie-Aussage nicht.

Auch verschachtelte Rebindings sind nicht abgedeckt. Ändert sich die Adresse während einer Prüfung erneut, wird eine unpassende Antwort verworfen, der Versuch läuft ab, die Bindung bleibt und spätere Daten starten neu. Ohne Versuchsidentität lässt sich nicht erklären, welcher Kandidat tatsächlich geprüft wurde.

Rückweg ist keine Identität

Ein erfolgreicher RRC zeigt: Eine Partei mit dem aktiven DTLS-Kontext erhielt auf dem getesteten Pfad eine geschützte Herausforderung und gab die gebundene Antwort rechtzeitig zurück. Nicht gezeigt werden rechtlicher Adressbesitz, menschliche oder Geräteidentität, Änderungsbefugnis, Ort, Dauer oder ein unbeobachteter Pfad.

Die Anwendung muss ebenfalls separat entscheiden. Eine CoAP-Operation kann zusätzliche Frische verlangen; ein Auftrag kann abgelaufen, nicht mehr idempotent oder nach geänderter Autorisierung unzulässig sein. Das Wiederaufnehmen von Bytes ist Transportkontinuität. Der Erhalt ihrer Bedeutung ist Anwendungskontinuität.

Lu Hengs Lehre von minimaler Anfangsspezifikation, lokaler Zukunftsentscheidung und freiwilliger Einführung hält die gemeinsame Schicht bei deterministischen Sicherheits- und Interoperabilitätsfakten. Bedrohungsmodell, Anwendungsalternative, Zeitpunkt und Wirkung bleiben bei den Teilnehmern, die den Code betreiben. Der Policy Mirror zeigt die eigentliche Entscheidungsfläche: das lokale Umschreiben der Adresse und die Freigabe von Anwendungsausgang.

Was eine grüne Anzeige verdeckt

RFC 9853 empfiehlt, Fehlschläge, mehrere Antworten auf dieselbe Herausforderung und häufige Prüfungen zu erfassen. Sie können Rückwegstörungen oder Spoofing, ein Off-Path-Rennen beziehungsweise instabile Konnektivität anzeigen.

DTLS 1.3 verbirgt den Record-Typ vor Beobachtern auf dem Pfad. Bei DTLS 1.2 ist ein nicht in tls12_cid verpackter RRC-Typ sichtbar und durch Middleboxes filterbar; CID in beide Richtungen begrenzt das. DTLS 1.3 kann zudem neue CIDs für neue Pfade anfordern. DTLS 1.2 kann das während der Sitzung nicht und eignet sich bei relevantem Multihoming-Korrelationsrisiko nicht.

Ein On-Path-Angreifer kann weiterhin schaden oder Prüfungen zum echten Peer weiterleiten. Das IANA-Register koordiniert Typ 27, Erweiterung 61 und drei Nachrichtencodes. Es bescheinigt weder Implementierung noch Identität, Befugnis oder Dienstabschluss.

Quellen und Grenzen

Grundlage sind RFC 9853 mit Status und Errata, RFC 9146, RFC 9147, RFC 9175, RFC 9000, das IANA-Register und RFC 8126. Sie definieren Protokoll- und Registrierungsverträge, nicht Verbreitung, Anbieterdefaults, Leistung, Vorfälle oder Betreiberregeln.

Das separate Errata-Verzeichnis für RFC 9853 bewahrt die zum Recherchezeitpunkt geprüfte Korrekturhistorie.