Zusammenfassung

  • Ein passender PATH_RESPONSE zeigt, dass der Empfänger eines unvorhersehbaren PATH_CHALLENGE dessen acht Byte zurückgeben konnte.
  • Das beweist weder die Identität einer Person, eines Geräts, Kontos oder Anwendungsprinzipals noch Autorisierung, kryptografische Gegenstellenidentität, MTU oder künftige Pfadverfügbarkeit.
  • Ein belastbares Betriebsregister trennt Rücksendbarkeit von Authentisierung, Anwendungsergebnis und Aufbewahrungsregel.

Der typische Fehlentscheid entsteht, wenn ein Betreiber einen passenden PATH_RESPONSE sieht und ihn als dauerhafte Identitäts- oder Vertrauensentscheidung speichert. RFC 9000 gibt dem Ereignis eine engere Bedeutung. Die Pfadvalidierung prüft die Erreichbarkeit einer Gegenstelle über einen Netzwerkpfad. Sie wird bei der Verbindungs­migration verwendet und kann eine neue lokale Adresse vor der Migration sondieren. Sie ist aber kein Verfahren, um die Identität des Gegenübers festzustellen.

Der Endpoint sendet PATH_CHALLENGE über den Pfad, den er prüfen will. Die Daten müssen mindestens 64 Bit Entropie enthalten, also einen unvorhersehbaren Wert von acht Byte. Der Empfänger antwortet mit PATH_RESPONSE und kopiert die Daten unverändert. Die Antwort muss über den Pfad gesendet werden, auf dem die Herausforderung eingetroffen ist. Der Initiator akzeptiert dagegen eine passende Antwort, die über jeden Netzwerkpfad eintrifft. Diese Kombination ist entscheidend: Der Antwortende weist die Rückgabe über den Empfangspfad nach; der Initiator erzwingt keinen bestimmten Antwortpfad, weil daraus ein Migrationsangriff entstehen könnte.

Die Validierung ist erfolgreich, wenn ein empfangener PATH_RESPONSE Daten aus einem früheren PATH_CHALLENGE enthält. Ein ACK für das Paket mit dem Challenge reicht nicht, weil eine böswillige Gegenstelle diese Bestätigung fälschen kann. Mehrere Challenges dürfen zur Verlusttoleranz gesendet werden, sollten aber nicht in ein einziges Paket gelegt werden. Andere Pakete oder Frames auf dem Kandidatenpfad ersetzen die passende Antwort nicht.

Geprüft wird eine Bedingung von Adresse und Pfad zu einem bestimmten Zeitpunkt. Das Ergebnis ist nicht die Identität einer Person, eines Geräts, Kontos oder einer Anwendung. Es beweist auch keine kryptografische Gegenstellenidentität, keine Autorisierung, kein Geschäftsergebnis und keine künftige Verfügbarkeit. Diese Trennungen sind betriebliche Schlussfolgerungen aus der engen Erfolgskondition von RFC 9000. Kryptografische Authentisierung, Anwendungsidentität, Autorisierung, Ergebnis und Aufbewahrung müssen deshalb eigene Felder bleiben.

Pfadvalidierung ist außerdem nicht MTU-Validierung. Ein erfolgreicher Challenge in einem Datagramm unter 1200 Byte kann Adresse oder Pfad validieren, ohne die erforderliche MTU zu belegen. Dafür ist ein weiterer, erweiterter Challenge nötig. PATH_RESPONSE-Datagramme werden normalerweise auf mindestens 1200 Byte erweitert, dürfen aber das Anti-Amplifikationslimit nicht überschreiten. Das Register muss daher Adressvalidierung und Pfad-MTU-Validierung getrennt führen und Datagrammgröße sowie Anti-Amplifikationsstatus erfassen.

Eine fehlende Antwort bedeutet nicht sofortiges Scheitern. RFC 9000 empfiehlt einen Timer auf Basis des Dreifachen des größeren PTO von aktuellem und neuem Pfad und lässt mehrere PTO zu, damit ein einzelner verlorener Challenge oder eine verlorene Antwort nicht entscheidet. Die Validierung scheitert erst, wenn der Endpoint den Versuch aufgibt. Das Aufgeben eines Pfades beendet die Verbindung nicht zwingend, wenn ein anderer gültiger Pfad nutzbar bleibt. Ein fehlgeschlagener Probeversuch bedeutet, dass dieser Kandidatenpfad für die Verbindung nicht nutzbar ist.

Bei einer erkannten Adressänderung, einschließlich NAT-Rebinding, muss der Pfad validiert werden, sofern die Adresse nicht bereits validiert wurde. Das macht QUIC nicht zu einem NAT-Traversal-Verfahren; RFC 9000 liefert die dafür nötigen Synchronisationsmechanismen nicht. Bei der Migration können Kapazität und Zeitverhalten anders sein. QUIC setzt deshalb Congestion-Control- und RTT-Zustand zurück, statt Messwerte des alten Pfades als Zusicherung für den neuen zu behandeln.

Ein zweckmäßiges Register enthält eine verbindungsbezogene Pfadkennung und einen datenschutzschonenden Challenge-Digest, Challenge- und Antwortzeit, das geprüfte lokale und entfernte Adresstupel, Datagrammgröße, Matching-Ergebnis und Antwortpfad. Es trennt Gegenstellen-Adressvalidierung von MTU-Validierung, erfasst den Anti-Amplifikationsstatus vor und nach der Validierung, PTO-Eingaben, Aufgabegrund und Timerergebnis. NAT-Rebinding- oder Migrationstrigger, frühere Adressvalidierung und alternative nutzbare Pfade gehören ebenfalls in eigene Felder.

Datenschutzsichere Digests und begrenzte Aufbewahrung sind Betriebsempfehlungen, keine QUIC-Anforderungen.

Auch die fünf Abgrenzungen zu früheren Themen müssen erhalten bleiben. TR-039 behandelt das Anti-Amplifikationsbudget vor der Adressvalidierung. TR-033 behandelt DNS-Cookie-Nachweise für den Rückweg. TR-043 behandelt Retry-Integrität. TR-040 trennt Connection IDs von Identität. TR-061 behandelt NEW_TOKEN-Nachweise zur Adressvalidierung in späteren Verbindungen. PATH_RESPONSE ersetzt keines dieser Themen.