Zusammenfassung

  • RFC 5204 setzt den RVS nur an den Anfang: Er sucht den registrierten HIT und leitet I1 weiter; R1, I2 und R2 laufen direkt zwischen den Peers.
  • FROM und RVS_HMAC sichern die Umschreibung im Registrierungskontext, nicht die aktuelle Präsenz des Hosts oder eine abgeschlossene Ende-zu-Ende-Authentisierung.
  • DNS-Epoche, Registrierungsstand, Transformation, Peer-Empfang, Rückweg, Base Exchange, geschützter Datenverkehr und Anwendungsergebnis brauchen getrennte Belege.

Eine konsistente Tabelle kann veraltet sein

Ein konstruiertes Beispiel: Ein mobiles Gerät registriert Adresse A, wechselt danach zu B, und das Update ist noch unterwegs. Die Lifetime von A läuft weiter. Der RVS empfängt I1, findet den HIT, wählt A, fügt FROM und RVS_HMAC hinzu und sendet. Jeder lokale Test ist erfolgreich; der Host sieht das Paket nie.

RFC 5204, ein später durch RFC 8004 abgelöstes Experimental RFC, verspricht eine bessere Chance für den Erstkontakt mit mobilen und multihomed HIP-Knoten. Der Client registriert HIT und aktuelle IP-Adresse. Ein Initiator entdeckt den RVS etwa per DNS und schickt I1 dorthin. Bei passender Registrierung leitet der Server weiter, sonst verwirft er.

„Aktuell“ bezeichnet dabei den vom RVS akzeptierten Datenstand. Es ist keine frische Messung am Endgerät.

Nach I1 muss der direkte Weg tragen

I1 nimmt den Umweg. Der Responder sendet R1 direkt an den Initiator; I2 und R2 sind ebenfalls direkt. Der RVS ist weder dauerhafter Tunnel noch vollständiger Zeuge des HIP-Zustands.

Deshalb sind RVS erreichbar, Locator ausgewählt, I1 gesendet, I1 empfangen, R1 zurückgekehrt, I2/R2 abgeschlossen, Schutz aktiv und Anwendung erfolgreich acht verschiedene Aussagen. Ein grüner Relay-Zähler beantwortet nur einen Teil davon.

Auch die Nutzung eines eigenen RVS durch den Initiator für NAT- oder Firewall-Traversal liegt außerhalb des Dokuments. Eine Implementierung darf mehr leisten, muss dafür aber einen eigenen Vertrag zeigen.

FROM belegt eine Umschreibung

Egress-Filter können den RVS zwingen, die Source-IP von I1 durch seine eigene Adresse zu ersetzen. Dann muss er die ursprüngliche Adresse in FROM ablegen und mit RVS_HMAC schützen. Der Schlüssel stammt aus der Rendezvous-Registrierung. Weitere RVS hängen Werte an, statt vorhandene zu überschreiben.

Damit kann der Client prüfen, dass ein Inhaber des Registrierungsschlüssels die Transformation geschützt hat. Das ist keine Signatur der Host Identity des Initiators, keine vollständige Pfadmessung und keine Empfangsbestätigung. Eine geordnete FROM-Liste ist eine dokumentierte Relay-Kette, kein kryptografischer Traceroute.

Die präzise Anzeige lautet daher: Integrität der RVS-Client-Umschreibung unter Registrierung X bestätigt. „Quelle bestätigt“ wäre zu groß.

Zwei Integritätsräume

I1 enthält noch nicht die Ende-zu-Ende-HMACs und Signaturen des späteren HIP Base Exchange. Darum darf der RVS Header ändern, Parameter ergänzen und Checksummen neu berechnen. Die Endpunkte authentisieren sich danach.

Die Registrierungsintegrität beantwortet, welcher Intermediär die Weiterleitung geschützt hat. Der Base Exchange beantwortet, welche Hosts den kryptografischen Kontext hergestellt haben. Nutzdaten und Anwendungserfolg bleiben wiederum spätere Ebenen.

RFC 5204 behandelt Redirect-, Amplification-, Reflection- und HIP-Angriffe. Gerade weil der RVS Identität in ein Traffic-Ziel übersetzt, muss seine Entscheidung überprüfbar und ihr Geltungsbereich begrenzt bleiben.

VIA_RVS ist Diagnosekontext

Der Responder ergänzt VIA_RVS in R1, wenn I1 über einen RVS kam. Hauptzweck ist die Diagnose von Problemen beim Aufbau. Der Parameter sagt nicht, dass der Initiator R1 erhalten oder validiert hat, und er bildet nicht jeden Netzsprung ab.

R1 erzeugt, R1 gesendet, R1 empfangen, R1 validiert, I2 gesendet und R2 empfangen dürfen in einem Monitoring-System nicht zu einem einzigen Status verschmelzen.

DNS und Registrierung altern unabhängig

Der DNS-Eintrag hat TTL, Cache, Vertrauensbasis und Auflösungszeit. Die RVS-Registrierung hat ID, Lifetime, Renewal und letzte Aktualisierung. Ein frischer RR kann zu einem Server ohne Eintrag führen; eine gültige Registrierung kann auf einen alten Locator zeigen; ein richtiger Locator kann durch Routing oder Policy unbrauchbar sein.

Ein belastbarer Receipt speichert RR, HIT, Registrierungs-Epoche, I1-Fingerprint, Lookup-Entscheidung, Header vor und nach der Umschreibung, FROM, HMAC-Kontext und Sendebeobachtung. Peer-Empfang, direktes R1, I2/R2, Schutz und Anwendungsergebnis kommen als unabhängige Evidenz hinzu.

Obsolet ist kein Deployment-Befund

RFC 8004 ersetzte RFC 5204; RFC 7401, 8003, 8005 und 8046 aktualisierten benachbarte HIP-Bausteine. Ein Inventar muss die tatsächlich implementierte Generation benennen. Aus dem Alter einer Referenz folgen aber weder laufende Version noch konkrete Schwachstelle oder Migration.

„HIP Rendezvous unterstützt“ reicht nicht. Version, Algorithmen, Registration Types, Parameterregeln, Policy und beobachtetes Verhalten machen die Aussage prüfbar.

Sources