Zusammenfassung

  • Beherrscht PCEPS mehrere TLS-Versionen, muss es die neueste bevorzugen. Unterstützt es TLS 1.3 oder später, darf es keine Early Data verwenden.
  • Die belastbare Kette reicht von unterstützten und ausgehandelten Versionen über ausgeschaltetes 0-RTT, Handshake und Peer-Prüfung bis zu PCEP-Annahme, autorisiertem Zustandswechsel und beobachteter Netzwirkung.

Die Messung versprach eine schnellere Sitzung. Ein vorhandenes Resumption-Ticket, TLS 1.3 und die erste PCEP-Nachricht im ersten Flight sollten einen Round Trip sparen. Doch das eingesparte Warten war genau die Zeit, in der die neue Sitzung ihre gewöhnliche Authentisierung abschließt. RFC 9916 behandelt diese Lücke nicht als kleine Implementierungsfrage, sondern als Verbotsgrenze.

RFC 9916 erschien im Juli 2026 auf dem IETF Standards Track und aktualisiert die PCEPS-Spezifikation RFC 8253. Sie verlangt die Präferenz für die neueste TLS-Version und untersagt Early Data, sobald TLS 1.3 oder eine spätere Version unterstützt wird. Verbindungsaufbau, Framing, Schließen, Zertifikatsprüfung, Peer-Identität und Fehlerbehandlung bleiben unverändert.

TLS 1.3 und 0-RTT sind keine Einheit. TLS 1.3 funktioniert ohne Early Data. Die Option setzt einen geeigneten Pre-Shared Key voraus, den die Peers extern oder aus einem früheren Handshake besitzen. Dann kann der Client Anwendungsdaten zusammen mit seinem ersten Flight senden, bevor der neue Handshake vollständig ist.

Der aktuelle TLS-1.3-Standard RFC 9846 nennt den Beweistausch ausdrücklich: Early Data ist nicht vorwärtsgeheim und nicht gegen Replay zwischen Verbindungen geschützt. Zudem darf ein Anwendungsprotokoll 0-RTT nur mit einem Profil nutzen, das sichere Interaktionen und Fallback behandelt. RFC 9325 rät ohne eine solche ausdrückliche Spezifikation vom Einsatz ab.

HTTP hat eine eigene Antwort gebaut. RFC 8470 definiert den Early-Data-Header und 425 Too Early, damit ein Origin Replay-Risiko ablehnen und eine Wiederholung verlangen kann. PCEPS übernimmt weder den Statuscode noch eine fallweise Freigabe. RFC 9916 schließt Early Data für PCEP vollständig aus.

Die Reihenfolge in RFC 8253 macht den Zweck sichtbar: TCP herstellen, StartTLS in beide Richtungen austauschen, TLS aushandeln und etablieren, danach PCEP beginnen. Selbst Open kommt erst später. Das Basisprotokoll RFC 5440 transportiert Pfadberechnungsanforderungen und -antworten zwischen PCC und PCE oder zwischen PCEs.

Stateful PCE vergrößert die mögliche Wirkung. RFC 8231 führt LSP-Zustandssynchronisierung, Delegation und PCE-gesteuerte Reihenfolge von Berechnungen ein. RFC 8281 erlaubt PCE-initiierte Einrichtung, Pflege und Entfernung von LSPs. RFC 8283 ordnet PCEP zentral gesteuerten Netzen zu, in denen Software Forwarding-Komponenten programmiert.

Nicht jede Nachricht verändert Forwarding. Aber daraus folgt keine Unschädlichkeit eines Duplikats. Identische Early Data kann in einer weiteren Verbindung angenommen werden. Erfolgreiche Entschlüsselung belegt nur die passende frühe Schlüsselableitung. Sie belegt weder einmalige Verarbeitung noch einen beendeten normalen Handshake noch eine aktuell gültige Delegation.

Request-ID, SRP-Objekt, LSP-ID und symbolischer Pfadname helfen bei der Korrelation. Automatische Idempotenz schaffen sie nicht. Zur Bewertung einer zweiten Nachricht braucht die Anwendung vorhandenen Zustand, erwartete Sequenz, delegierten Umfang, Wiederholungsregel und bereits angewandtes Ergebnis. Das ist PCEP-Semantik, keine TLS-Entscheidung.

Ein Audit sollte deshalb die Stationen einzeln speichern: Versionen beider Peers, ausgehandelte Version, Angebot und Annahme von Early Data, Handshake-Abschluss, Zertifikat und Peer-Namen, erste akzeptierte PCEP-Nachricht, Identifikatoren, Delegation, angeforderte Transition, Antwort und beobachteten Netzstatus. Das Sammelfeld „sicher“ ist zu grob, um einen späteren Vorfall zu erklären.

Auch die Störungsklasse bleibt sauber. Ein unerwarteter Fallback betrifft die Versionspolitik. Anwendungsbytes vor dem Handshake verletzen das Profil. Eine fehlgeschlagene Identitätsprüfung bleibt trotz Verschlüsselung ein Authentisierungsfehler. Doppelte Anwendung gehört zur PCEP-Zustandslogik. Ein bestätigter Wechsel ohne Forwarding-Wirkung verlangt Beobachtung am PCC und Gerät.

Heng Lus Minimum Initial Specification begrenzt den gemeinsamen Kern auf deterministische, lokal prüfbare Regeln. Running-Code Primacy gewichtet ausgeführten Handshake und Zustand stärker als ein Versionsetikett. Reality Layers verhindert, dass „TLS 1.3“ eine nicht beobachtete Netzhandlung beansprucht. Das sind offengelegte redaktionelle Prinzipien, keine zusätzlichen IETF-Regeln.

RFC 9916 verlangt keine Abkehr von moderner Kryptografie und keine Geringschätzung von Latenz. Sie ordnet beides. Neueste Version zuerst, Early Data aus, Handshake abschließen, Peer prüfen, PCEP autorisieren, Netz beobachten. Eine Steuerungsnachricht darf warten, wenn dadurch später beweisbar bleibt, wer sie wann und wie oft ausgeführt hat.

Quellen