Zusammenfassung

  • Sind alle anwendbaren RSVP Security Associations abgelaufen, empfiehlt der Entwurf eine Meldung an das Management und eine unbegrenzte Weiterbehandlung der letzten Association, bis sie verlängert, gelöscht oder ersetzt wird.
  • Die Ausnahme erklärt alte Kryptografie nicht für risikolos. Sie verhindert den Rückfall in unauthentisiertes RSVP und soll zugleich vermeiden, dass der Kalender laufende Reservierungen und damit womöglich das Netz stört.
  • Der Schlüsselwechsel ist erst belegt, wenn der Nachfolger im richtigen Geltungsbereich aktiv ist, die Überlappung ausreicht, die Uhren verlässlich sind und jeder Empfänger den Handshake abgeschlossen hat.

Der Schlüssel ist abgelaufen, doch der nächste RSVP-Datensatz passiert die Prüfung. Das ist im aktuellen Entwurf kein versehentlicher Fail-open. Es ist die vorgesehene Reaktion auf einen Übergang, der nicht rechtzeitig fertig geworden ist.

RSVP Cryptographic Authentication Version 2, Revision 02, erschien am 27. September 2026 und befindet sich im Working Group Last Call der IETF-Arbeitsgruppe TEAS. Das Dokument bleibt ein Internet-Draft mit dem Ziel Proposed Standard. Es ist weder RFC noch Nachweis einer Implementierung. Bei erfolgreichem Abschluss würde es RFC 2747 und RFC 3097 ablösen.

Der einschlägige Abschnitt heißt „Pathological Case“. Sämtliche Associations für den RSVP-Austausch sind abgelaufen. Auf unauthentisierte Kommunikation zurückzufallen, ist unzulässig. Bestehende Reservierungen zu unterbrechen, könnte jedoch einen größeren Netzfehler verursachen. Deshalb soll das System den Ablauf der letzten Association melden und sie zugleich wie unbegrenzt gültig behandeln, bis das Management ihre Laufzeit verlängert, sie löscht oder eine neue einrichtet.

Die Regel stand bereits in Revision 01. Revision 02 hat sie nicht neu eingeführt. Aktuell ist vielmehr, dass ein Text mit diesem Kompromiss die jetzige Prüfphase erreicht hat: Das Ablaufdatum erzwingt nicht den Zustandswechsel, sondern markiert eine fehlgeschlagene Übergabe an einen Nachfolger.

RSVP signalisiert Ressourcenreservierungen. Die Grundlage liefert RFC 2205, die Traffic-Engineering-Erweiterung RFC 3209. Der neue Entwurf authentisiert Nachrichten hop-by-hop mit einem INTEGRITY-Objekt. Sender und Empfänger sind hier die benachbarten RSVP-Systeme des jeweiligen Hops, nicht zwingend die Anwendungsendpunkte.

Das Objekt enthält eine 48-Bit-Key-Identifier, eine 64-Bit-Sequenznummer und Authentisierungsdaten. Der Empfänger wählt anhand von Key Identifier und Absenderadresse die konkrete Association. Darin liegen außerdem kryptografische Transformation, Schlüssel, Interfaces oder Peers sowie Start und Ende. Associations gelten je Richtung.

Damit ist eine begrenzte Aussage möglich: Der Nachbar mit dem konfigurierten Schlüssel erzeugte eine Nachricht an einer als frisch akzeptierten Sequenzposition. RSVP wird dadurch nicht vertraulich. Ebenso wenig beweist die Signatur Berechtigung, Admission Control, Datenweiterleitung oder erbrachte Dienstqualität. Nachrichtenechtheit und Netzwirklichkeit bleiben verschiedene Ebenen.

Nach Neustarts entsteht eine Replay-Frage. Die Sequenznummer muss während der gesamten Schlüssellebensdauer eindeutig und monoton steigen. Verliert ein Empfänger seinen aktuellen Stand, kann alte Kommunikation neu wirken. Daher muss jede Implementierung den Integrity Handshake beherrschen und sollte ihn standardmäßig aktivieren. Der Empfänger sendet ein unvorhersehbares Cookie; der Sender gibt es zusammen mit der aktuellen Sequenz in einer geschützten Antwort zurück.

Jede Sitzung benötigt entweder diesen Handshake oder dauerhaft gespeicherte Sequenzstände. RFC 4086 und RFC 8937 stützen die Zufälligkeit des Cookies. Sie liefern aber keinen Betriebsnachweis darüber, welcher Empfänger den Austausch abgeschlossen hat.

Auch Rotation ist kein einzelner Zeitpunkt. Mindestens zwei Associations müssen parallel möglich sein. Die neue beginnt vor dem Ende der alten; die Überlappung soll mindestens doppelt so lang sein wie die Unsicherheit zwischen den Uhren. Fünf Minuten reichen laut Entwurf oft aus. Jeder Empfänger muss auf dem Nachfolger handshaken.

„Neuer Schlüssel eingetragen“ genügt folglich nicht. Der Nachfolger muss denselben Kommunikationsbereich treffen, nach verlässlicher Zeit aktiv sein, vom Sender genutzt, vom Empfänger ausgewählt und mit einem sicheren Sequenzanfang versehen werden. Fehlt einer dieser Belege, hat das Inventar zwei Schlüssel, das laufende System aber keinen abgeschlossenen Wechsel.

Die Zeitquelle wird selbst Teil des Sicherheitsmodells. Der Entwurf verlangt hinreichend synchrone Uhren und empfiehlt eine authentisierte Zeitverteilung. RFC 5905 beschreibt NTPv4. Eine NTP-Konfiguration beweist jedoch weder die tatsächliche Abweichung noch die Gesundheit der Quelle.

Existiert ein gültiger Ersatz, ist die Behandlung des alten Schlüssels streng. Ein Paket unter der abgelaufenen Association muss noch vor der kryptografischen Berechnung verworfen werden. Ein rate-limitiertes Sicherheitsprotokoll wird empfohlen. Der Peer darf den alten Pfad nicht weiter wählen, sobald der neue wirklich funktioniert.

Ohne gültigen Ersatz kehrt sich das Ergebnis um: Die abgelaufene Association wird zur Prüfung genutzt, als wäre sie noch gültig. Das ist eine Fail-operational-Entscheidung. Das letzte bekannte authentisierte Verhältnis bleibt erhalten, statt auf ungeschützte Nachrichten oder einen automatischen Reservierungsabbruch umzuschalten.

Kontinuität hat allerdings einen blinden Fleck: Das Netz sieht gesund aus. Reparatur verliert Priorität, eine Meldung bleibt ohne Besitzer, der Ausnahmezustand wird Alltag. „Unbegrenzt“ enthält keine zweite automatische Frist. Nur eine Managementhandlung beendet ihn.

Schlüsselmanagement selbst liegt außerhalb des Entwurfs. Manuelle Verteilung muss unterstützt werden; unbegrenzte manuelle Laufzeiten sind möglich, aber nicht empfohlen. Ein IANA-Register soll die kryptografischen Transformationen beweglich halten. Die historische HMAC-MD5-Kompatibilität bleibt im Format sichtbar, während RFC 6151 die Grenzen erklärt. Algorithmusagilität verteilt keinen neuen geheimen Schlüssel an die richtigen Nachbarn.

Der kleinste brauchbare Betriebsnachweis verfolgt deshalb den Übergang: Key Identifier und Absenderadresse, Peer- und Interfacebereich, Transformation, Beginn und Ende, Nachfolger, Überlappungsfenster, Uhrabweichung, erwartete Empfänger, deren Handshake-Status, erstes nach Ablauf akzeptiertes Paket, Zustellung und Quittierung des Alarms sowie die Handlung, die den Ausnahmezustand beendete. Das Geheimnis gehört nicht ins Protokoll; die Zustandsherkunft sehr wohl.

Heng Lus Primat des laufenden Codes ordnet die Ebenen: Der Zeitstempel ist ein Symbol, die Paketverarbeitung der tatsächliche Zustand. Die minimale Anfangsspezifikation lässt dem gemeinsamen Protokoll eine enge Rolle und der lokalen Organisation ihre Entscheidung. Die Realitätsebenen verhindern, dass „abgelaufen“ mit tatsächlich beendetem Vertrauen verwechselt wird.

Beim Ablauf des letzten Schlüssels hält RSVP den authentisierten Pfad offen, löst Alarm aus und wartet. Die technische Ausnahme ist damit zugleich eine sichtbare Frage der Verantwortung.

Quellen