Host Identity Protocol RFC 7401: Lehren für IPvX-Adressen

Das Host Identity Protocol RFC 7401 ist für uns als veröffentlichtes IETF-Beispiel eines Protokolls nützlich, das bei IP-Adressen die Rolle des Identifiers von der Rolle des Lokators trennt und zwischen zustimmenden Hosts einen gemeinsamen Zustand auf IP-Ebene herstellt.² HIP verwendet öffentliche Schlüssel-Identifier aus dem Host-Identity-Namensraum zur gegenseitigen Authentifizierung der Teilnehmer und basiert auf einem Diffie-Hellman-Austausch.² Für den Entwurf von IPvX-Adressen ist das kein fertiger Bauplan, sondern eine Sammlung architektonischer Fragen, die in den IETF-Dokumenten zu HIP bereits ausdrücklich formuliert wurden.¹

Warum die Trennung von Identifier und Lokator wichtig ist

RFC 7401 beschreibt HIP als Alternative zur doppelten Verwendung von IP-Adressen: IP-Adressen können sowohl als locators, also Routing-Marken, als auch als identifiers, also Identifier von Hosts oder Endpunkten, dienen.³ In HIP werden öffentliche kryptografische Schlüssel aus einem public/private key-Paar als Host-Identifier verwendet, und Protokolle höherer Ebenen werden an diese Identifier gebunden statt an eine IP-Adresse.³

RFC 9063 formuliert dasselbe Problem breiter: Das Internet hat zwei wichtige globale Namensräume — IP-Adressen und DNS-Namen — und beide Namensräume sind semantisch überladen worden, weil man versucht hat, mit ihnen zu viel zu leisten.¹ In der HIP-Architektur wird der Host-Identity-Namensraum zwischen IP- und DNS-Namensräumen eingefügt, und die entsprechende Protokollschicht liegt zwischen internetworking und transport layers.¹

Für IPvX ziehen wir daraus eine vorsichtige Lehre: Adressierung über Schlüssel sollte kryptografische Identität, die Darstellung dieser Identität in Paketen und den aktuellen Zustellpfad nicht automatisch vermischen.³ Das ist genau unsere Entwurfsinterpretation von HIP und keine Anforderung von RFC 7401 an IPvX.³

Schlüssel, Identität und kompaktes Tag sind unterschiedliche Entitäten

RFC 9063 unterscheidet zwischen Host Identity und Host Identifier: Identity bezieht sich auf die abstrakte Entität, die identifiziert wird, während Identifier das konkrete Bitmuster ist, das im Identifikationsprozess verwendet wird.¹ Im zentralen Fall der HIP-Architektur ist der Host Identifier der öffentliche Schlüssel eines asymmetrischen Schlüsselpaars.¹

HIP definiert außerdem den Host Identity Tag, kurz HIT, als einen 128-Bit-Wert, der durch kryptografisches Hashing des Host Identifier erzeugt wird, ergänzt um Bits, die den verwendeten Hash angeben.¹ In der Terminologie von RFC 9063 ist der Host Identity Hash der kryptografische Hash, der bei der Erzeugung eines HIT aus einem Host Identifier verwendet wird.¹ Das Dokument definiert außerdem den Local Scope Identifier als einen 32-Bit-Wert, der eine Host Identity in einem lokalen Geltungsbereich bezeichnet.¹

Diese Definitionen geben uns für IPvX eine nützliche begriffliche Disziplin: „Schlüssel“, „abstrakte Identität“, „kompaktes Tag“ und „lokaler Bereichs-Identifier“ sind in HIP nicht ein und derselbe Begriff.¹ Wir können diese Disziplin bei der Beschreibung von IPvX-Adressen nutzen, dürfen sie aber nicht als direkte Vorgabe von RFC 9063 für IPvX ausgeben.¹

Auch die Geschichte des HIT zeigt, dass sich das Format einer kompakten Darstellung weiterentwickeln kann.⁶ In RFC 4423 wurde der HIT als 128-Bit-Wert beschrieben, der durch Hashing des Host Identifier erzeugt wird.⁶ In RFC 9063 umfasst die Definition des HIT bereits Bits, die den verwendeten Hash angeben.¹ Das beweist nicht, wie das Format einer IPvX-Adresse aussehen sollte, zeigt aber, dass in HIP der algorithmische Kontext eines kompakten Tags Teil der architektonischen Beschreibung geworden ist.¹

Base Exchange als Modell für den Zustandsaufbau

RFC 7401 definiert das base HIP protocol, oder base exchange, das zwischen Hosts verwendet wird, um vor der Kommunikation einen IP-layer communications context herzustellen, der HIP association genannt wird.³ Im Inhaltsverzeichnis von RFC 7401 werden die Einrichtung einer HIP Association, der HIP Puzzle Mechanism, der Puzzle-Austausch, authentifiziertes Diffie-Hellman mit Aushandlung der DH-Gruppe, Schutz vor Wiederholungen, der Abbruch des base exchange, die Unterbrechung des base exchange, downgrade protection und opportunistic mode gesondert aufgeführt.²

Die Spezifikation RFC 7401 listet außerdem die Steuerpakete I1, R1, I2, R2, UPDATE, NOTIFY, CLOSE und CLOSE_ACK auf.² Dasselbe Dokument enthält Abschnitte zur Aktualisierung der HIP association, zur Fehlerbehandlung, zur HIP state machine, zur Verarbeitung von UPDATE mit SEQ und ACK, zur Verarbeitung von CLOSE und CLOSE_ACK sowie zu handling state loss.²

Für IPvX ist diese Themenliste als Checkliste für den Verbindungsentwurf nützlich, aber nicht als Beleg dafür, dass IPvX die state machine von HIP wiederholen muss.² Wir können unseren eigenen Entwurf auf dieselben Klassen von Fragen prüfen: wie eine Assoziation erzeugt wird, wie Parameter ausgehandelt werden, wie Fehler erkannt werden, wie Zustand aktualisiert wird und wie die Verbindung geschlossen wird.² Dabei sollte eine Aussage über einen „billigen Start“ nicht allein aus RFC 7401 abgeleitet werden; die Quelle bestätigt ausdrücklich das Vorhandensein eines puzzle mechanism und von Schutzabschnitten, formuliert aber keine universelle Anforderung an jedes Protokoll zur schlüsselbasierten Adressierung.²

Nutzlastsicherheit und Assoziationen sind getrennte Ebenen

RFC 7401 sagt, dass HIP designed to be resistant to denial-of-service and man-in-the-middle attacks.² Das Dokument weist außerdem darauf hin, dass HIP bei Verwendung mit einem geeigneten Sicherheitsprotokoll, zum Beispiel ESP, integrity protection und optional encryption für Protokolle höherer Ebenen wie TCP und UDP bereitstellt.²

RFC 9063 präzisiert die architektonische Rolle: Bei der Verwendung von HIP wird die Nutzlast zwischen HIP-Hosts üblicherweise, aber nicht zwingend, durch Encapsulating Security Payload geschützt, und Host Identities werden genutzt, um die erforderlichen ESP Security Associations aufzubauen und Hosts zu authentifizieren.¹ Das ist eine wichtige Grenze für IPvX: Schlüsselbasierte Adressierung kann Teil der Authentifizierung sein, aber der Schutz der Nutzlast, die Parameter der security association und der Lebenszyklus solcher Assoziationen müssen separat beschrieben werden.¹

Die HIP-Dokumente zeigen außerdem, dass kryptografische Flexibilität Gegenstand ausdrücklicher Anpassungen war.² RFC 7401 gibt an, dass das Dokument Anmerkungen der IESG aufgreift, insbesondere zu crypto agility, und Lehren aus Implementierungen von RFC 5201 enthält.² RFC 9063 sagt ebenfalls, dass er concerns raised by the IESG, particularly crypto agility berücksichtigt.¹ Für IPvX ist das keine fertige Regel zu konkreten Hashes oder Schlüsseltypen, aber ein starker Grund, den algorithmischen Kontext von Adressen und das Verfahren zur Weiterentwicklung von Formaten ausdrücklich zu dokumentieren.¹

Rendezvous, Mobilität und Adressänderungen

Eine der zentralen Eigenschaften von HIP in RFC 7401 ist die Aufrechterhaltung der Kommunikationskontinuität bei Änderungen von IP-Adressen durch die Trennung der Rollen von identifier und locator.² RFC 9063 beschreibt die HIP-Schicht als Unterstützung für end-host mobility, multihoming und NAT traversal.¹

In der Terminologie von RFC 9063 ist der Rendezvous Mechanism ein Mechanismus zum Auffinden mobiler Hosts anhand ihres HIT.¹ In RFC 4423 wurde rendezvous mechanism ebenfalls als Mechanismus definiert, der zum Auffinden mobiler Hosts anhand des Host Identity Tag verwendet wird.⁶

Für IPvX ergibt sich daraus eine vorsichtige Formulierung der Lehre: Ein stabiler schlüsselbasierter Identifier beschreibt für sich genommen nicht, wo sich der Empfänger aktuell befindet.¹ Wenn ein Protokoll die Identität bei Änderungen des Zustellpfads erhalten will, braucht es eine separate Möglichkeit, den Identifier mit dem aktuellen Lokator oder der aktuellen Route zu verknüpfen; HIP nennt diese Aufgabenklasse rendezvous mechanism.¹

Wichtig ist, diese Schlussfolgerung nicht zu überdehnen.² RFC 7401 bestätigt das Vorhandensein von UPDATE-, SEQ- und ACK-Prozeduren zur Verarbeitung von Aktualisierungen der HIP association, doch daraus folgt keine automatische Skalierungsregel für IPvX.² Wir können HIP als Beispiel dafür nutzen, dass Änderungen des Assoziationszustands in eigene Prozeduren ausgelagert sind; die Parameter für Fehlertoleranz und Skalierung von IPvX müssen jedoch in eigenen reproduzierbaren Experimenten geprüft werden.²

Zertifikate: Erweiterbarkeit ohne Überlastung des ersten Pakets

RFC 8002 aktualisiert RFC 7401 und definiert den CERT parameter als Container für digitale Zertifikate in HIP-Steuerpaketen.⁵ Dasselbe Dokument betont, dass der CERT parameter nicht die Semantik der Zertifikate festlegt; konkrete Nutzungsszenarien müssen vielmehr durch die Dokumente definiert werden, die diesen Parameter verwenden.⁵

Das ist ein gutes Beispiel für die Trennung von Mechanismus und Vertrauenspolitik.⁵ Das Basisprotokoll kann die Übertragung von Zertifikaten, die Gruppierung zusammengehöriger CERT parameters und die Fehlersignalisierung bei fehlgeschlagener Prüfung beschreiben, ohne alle szenariospezifischen Entscheidungen in ein universelles Format einzubauen.⁵

RFC 8002 enthält auch eine negative Lehre: Die Verwendung von CERT im ersten Initiator packet I1 wird nicht empfohlen, weil dies die Verarbeitungszeit von I1 erhöhen und bei processing storms of I1s zu einem Problem werden kann.⁵ Für IPvX können wir das als Entwurfshypothese formulieren: Nachweise, Zertifikate und Attestierungen sollten nicht automatisch in das früheste und am stärksten massenhaft auftretende Paket des Handshake gelegt werden.⁵ Das ist genau eine Schlussfolgerung für unseren Entwurf und keine zitierte Anforderung von RFC 8002 an IPvX.⁵

RFC 8002 beschreibt außerdem Varianten, bei denen Verweise statt der Zertifikate selbst übertragen werden: Hash and URL, LDAP URL und Distinguished Name können HIP control packets verkleinern, verlangen vom Empfänger aber, die URL aufzulösen, das Zertifikat abzurufen oder den lokalen Cache zu prüfen.⁸ Deshalb muss beim Entwurf eines IPvX-handshake der Kompromiss zwischen einer selbstgenügsamen Nachricht und der Abhängigkeit vom externen Abruf von Vertrauensdaten separat berücksichtigt werden.⁸

Reifegrad und Grenzen dokumentieren

RFC 4423 war ein Informationsdokument und beschrieb sich ausdrücklich als Momentaufnahme der Überlegungen zur HIP-Architektur im Herbst 2003.⁶ In RFC 4423 heißt es außerdem, dass sich die Architektur verändert haben könnte und dass das Dokument einen stabilen Punkt in der Entwicklung des Verständnisses darstellt.⁶ Dieses Beispiel ist für ein Forschungsprotokoll wichtig: Der Status des Dokuments und der Reifegrad der Architektur müssen für den Leser sichtbar sein.⁶

RFC 9063 ersetzte RFC 4423 und blieb ein Dokument der Kategorie Informational, während RFC 7401 ein Standards-Track-Dokument mit dem Status Proposed Standard ist.⁴ Das zeigt, dass architektonische Beschreibung und Basisspezifikation eines Protokolls im IETF-Prozess unterschiedliche Status haben können.⁴

Security Considerations in RFC 9063 umfassen flooding attacks, die Verwendung von identities in access control lists, weaker types of identifiers und trust on first use.¹ Die Anhänge von RFC 9063 umfassen außerdem design considerations, benefits, drawbacks, deployment and adoption considerations, deployment analysis, infrastructure applications und management of identities in a commercial product.⁴ Für unsere RFC-Projekte zu IPvX stützt das die Praxis, Paketformat, Einschränkungen, betriebliche Annahmen und bekannte Kompromisse ausdrücklich voneinander zu trennen.⁴

Die Historie von RFC 7401 im Datatracker verzeichnet die Veröffentlichung des RFC am 9. April 2015 und die Aktualisierung der IANA-Register am 10. April 2015.⁷ Dieselbe Historie zeigt spätere Synchronisierungen von RFC-Editor-Metadaten, darunter Änderungen am abstract im Jahr 2018, das Hinzufügen des Tags Verified Errata im Jahr 2020 und Metadatenaktualisierungen im Jahr 2026.⁷ Das beweist nicht das Vorhandensein aller späteren aktualisierenden RFCs, zeigt aber, dass der öffentliche Eintrag zum Dokument nach der Veröffentlichung weiter gepflegt wird.⁷

Was wir in IPvX übernehmen

Die erste Lehre: Bei der Beschreibung von IPvX-Adressen über Schlüssel ist es sinnvoll, ausdrücklich zwischen abstrakter Identität, öffentlichem Schlüssel als Identifier, kompakter gehashter Darstellung und aktuellem Lokator zu unterscheiden, weil HIP zwischen Host Identity, Host Identifier, HIT und locator role IP address unterscheidet.¹³

Die zweite Lehre: Der Verbindungsaufbau sollte als Lebenszyklus eines Zustands und nicht als einzelner Schlüsselaustausch entworfen werden, weil RFC 7401 HIP association, base exchange, state machine, UPDATE, NOTIFY, CLOSE, CLOSE_ACK und handling state loss beschreibt.²

Die dritte Lehre: Rendezvous sollte als eigenständige Aufgabe der control plane betrachtet werden, weil RFC 9063 einen Mechanismus zum Auffinden mobiler Hosts anhand des HIT definiert und die HIP-Architektur mit Mobilität, multihoming und NAT traversal verknüpft.¹

Die vierte Lehre: Zertifikate und zusätzliche Nachweise sollten von der grundlegenden Semantik der Adresse getrennt werden, weil RFC 8002 den CERT parameter als Container festlegt und die szenariospezifische Semantik den Dokumenten überlässt, die diesen Parameter verwenden.⁵

Die fünfte Lehre: Einschränkungen, negative Ergebnisse und die Entscheidungshistorie sollten Teil unserer Entwürfe sein, weil die HIP-Dokumente Reifestatus, security considerations, drawbacks und deployment considerations ausdrücklich ausweisen.⁴⁶

Das Fazit für uns ist vorsichtig: HIP definiert IPvX nicht und nimmt uns nicht die Pflicht ab, Routing, Ausfälle und Skalierung in eigenen reproduzierbaren Experimenten zu prüfen.² Aber HIP liefert eine veröffentlichte Sprache, um über schlüsselbasierte Adressen, Sicherheitsassoziationen, Rendezvous, Mobilität und die Grenzen zwischen Architektur, Spezifikation und betrieblichen Einschränkungen zu sprechen.¹²

Quellen

1. RFC 9063: Host Identity Protocol Architecture, rfc-editor.org, 01.07.2021
2. RFC 7401: Host Identity Protocol Version 2 (HIPv2), datatracker.ietf.org
3. RFC 7401: Host Identity Protocol Version 2 (HIPv2), datatracker.ietf.org
4. RFC 9063: Host Identity Protocol Architecture, datatracker.ietf.org
5. RFC 8002: Host Identity Protocol Certificates, datatracker.ietf.org
6. RFC 4423: Host Identity Protocol (HIP) Architecture, datatracker.ietf.org
7. History for rfc7401, datatracker.ietf.org
8. RFC 8002: Host Identity Protocol Certificates | RFC Editor, rfc-editor.org