Zusammenfassung

  • RFC 5202 lässt ESP_INFO beim Rekey absichtlich lesbar, damit SPI-abhängige Zwischen­systeme ihre Zuordnung aktualisieren können. RFC 7402 übernimmt diese Grenze in die Standards-Track-Fassung.
  • HMAC und Signatur belegen Integrität und Herkunft. Sie belegen weder Metadatengeheimnis noch Installation, Umschaltung, Löschung oder Anwendungserfolg.

Der Prüfpunkt vor dem Ciphertext

ESP zeigt die Trennlinie bereits im Paketformat. Security Parameters Index und Sequence Number stehen vor der verschlüsselten Nutzlast. RFC 4303 schützt ihre Integrität, verschlüsselt sie aber nicht. Der Empfänger benötigt den SPI, um die passende eingehende Security Association zu finden.

HIP verdichtet mit dem SPI zusätzlich ein HIT-Paar. Zwischen­systeme dürfen ihn etwa für Adressabbildung verwenden. Seine Bedeutung ist jedoch zeit- und zielgebunden: Nur Zieladresse plus SPI identifizieren den empfangenden HIT-Kontext zu einem bestimmten Zeitpunkt. Derselbe Zahlenwert kann an anderen Hosts oder später anders verwendet werden.

Damit ist der SPI weder dauerhaftes Identitätsmerkmal noch Schlüssel. Er ist aber ein verwertbarer Betriebskoordinate. Diese mittlere Aussage ist präziser als „öffentlich“ oder „anonym“.

Warum das UPDATE nicht verdeckt wird

Beim Rekey enthält ESP_INFO alten SPI, neuen SPI und KEYMAT-Index. Das initiale UPDATE führt zusätzlich SEQ, optional Diffie–Hellman, HMAC und HIP-Signatur. Die Antwort bringt eigene Parameter und ACK mit.

RFC 5202 begründet die Offenheit ausdrücklich: Zwischen­systeme, die den SPI nutzen, müssen HIP-Pakete mit Rekey-Information untersuchen. Das Paket wird zu ihrem Nutzen signiert. Weil sie die neuen SPI-Werte benötigen können, darf der Inhalt nicht verschlüsselt sein. RFC 7402 behält den Wortlaut im Nachfolger bei.

Die Signatur macht den sichtbaren Übergang belastbarer. Sie verbirgt ihn nicht. Ein authorisierter Prüfer kann feststellen, dass eine Zuordnung aus dem erwarteten HIP-Kontext stammt. Genau diese Verlässlichkeit macht das Metadatum operativ nützlich.

Eine Konsole darf deshalb Signature gültig nicht in Metadaten privat übersetzen. Ebenso wenig darf sie aus dem gelesenen UPDATE eine aktive neue SA oder erfolgreichen Datenverkehr ableiten.

Eine begrenzte Korrelationsfläche

HIP-Header liefern Sender- und Empfänger-HIT, ESP_INFO den Wechsel alt zu neu, IP-Header Locator und ein Sensor die Zeit. Ein HIP-bewusster Firewall- oder NAT-Knoten mit Association-Kontext kann daraus planmäßig Soft State pflegen. RFC 9063 beschreibt diese passive On-Path-Beobachtung.

RFC 6973 nennt die Schlussfolgerung aus Anwesenheit, Richtung, Zeitpunkt, Größe, Zusammensetzung oder Häufigkeit eines verschlüsselten Flusses Traffic Analysis. Ein sichtbarer Rekey ist ein strukturiertes Ereignis in dieser Fläche.

Die Grenze bleibt wichtig. Der SPI benennt keinen Menschen und enthüllt keine Nutzlast. Globale oder langfristige Identifizierung folgt daraus nicht. Wie viel verknüpft werden kann, hängt von zusätzlichem Wissen, Sensoren und Aufbewahrung ab.

Zufall ist kein Löschverfahren

Die HIP-Spezifikationen empfehlen zufällige SPI-Auswahl, einen anderen Wert für jeden neuen Austausch mit demselben Peer und einen zwingenden Wechsel beim Rekey. Das hilft gegen Wiederverwendung und Replay.

Eine bereits gespeicherte Beziehung alt → neu bleibt davon unberührt. Der Soft-State-Timer eines Gateways kann kurz sein, während SIEM, Flow-Speicher, Tickets und Backups viel länger leben. Auch die in RFC 9063 empfohlene Rotation unveröffentlichter Host Identities löscht diese Kopien nicht.

Die Organisation braucht drei getrennte Lebenszyklen: SPI, HIT und Beobachtungsdatensatz. Erst wenn alle drei inventarisiert sind, lässt sich eine Datenschutzbehauptung prüfen.

Vom Mapping zur Löschquittung

Für jeden ESP_INFO-Konsumenten sind Zweck, gelesene Felder, Installationsregel, berechtigte Rollen, Exportziele, Ablauf und Löschbeweis zu dokumentieren. Der Ereignisbeleg enthält Beobachtungspunkt, Richtung, Locator, geschützte HIT-Referenz, beide SPIs, SEQ/ACK, Verifikationsergebnis, Algorithmus, Regelversion und Timeout.

Endpoint-Belege folgen separat: neue SA angelegt, erstes authentisiertes Paket am neuen SPI, letztes Paket am alten, alter Zustand entfernt. Ein Middlebox-Mapping ist kein Cutover-Beweis.

Auch Löschung ist mehrstufig. Das Verschwinden aus der Live-Tabelle reicht nicht, wenn Packet Capture, abgeleitete Flows, Support-Anhang oder externer Prozessor fortbestehen. Jede deklarierte Kopie braucht ihr eigenes Ende.

Der korrekte Dokumentstatus

RFC 5202 erschien 2008 als Experimental und ist überholt. Ein gehaltenes Erratum korrigiert lediglich „transport“ zu „transform“ bei Parametern. RFC 7402 ersetzte sie 2015 für HIPv2 im Standards Track.

Die fortbestehende Sichtbarkeitsklausel macht die Aussage aktuell. RFC 6538 und RFC 9063 zeigen zudem, dass Identitätsschutz und Middlebox-Teilnahme unterschiedliche Entwurfsziele sind. Gute Governance nennt den Trade-off, statt beide in einem Sicherheitswort zu verstecken.

Entscheidungsebene

Verträge und Dashboards müssen mindestens fünf Zustände ausweisen: Payload vertraulich, Kontrolle authentisch, Metadatum sichtbar, neue SA wirksam, Aufbewahrung beendet. Jeder Zustand verweist auf einen eigenen Nachweis.

Die gemeinsame Spezifikation darf nur die Offenlegung verlangen, die Interoperabilität tatsächlich braucht. Sekundäranalyse, Sensor-Joins und Langzeitspeicherung bleiben lokale Entscheidungen mit benanntem Verantwortlichen. Running Code zeigt die tatsächliche Sichtbarkeit; Audit begrenzt ihre Macht.

Quellen

  1. RFC 5202 HTML
  2. RFC 5202 Text
  3. RFC-5202-Informationsseite
  4. IETF Datatracker: RFC 5202
  5. RFC-5202-Historie
  6. RFC-5202-Referenzen
  7. RFC-5202-Errata
  8. RFC 7402 HTML
  9. RFC 7402 Text
  10. RFC-7402-Informationsseite
  11. IETF Datatracker: RFC 7402
  12. RFC-7402-Historie
  13. RFC-7402-Referenzen
  14. RFC-7402-Errata
  15. RFC 4303 — ESP
  16. RFC 4301 — IPsec-Architektur
  17. RFC 9063 — HIP-Architektur
  18. RFC 6538 — HIP-Experimentbericht
  19. RFC 6973 — Datenschutzbetrachtungen
  20. Heng Lu — Realitätsebenen und symbolische Macht
  21. Heng Lu — minimale Anfangsspezifikation
  22. Heng Lu — Primat des laufenden Codes