Zusammenfassung

  • Die HIP-Architektur von Robert Moskowitz und Pekka Nikander aus dem Jahr 2006 nutzt eine Public-Key-Identität als Namen des Endpunkts und lässt die IP-Adresse als Locator für die Zustellung bestehen.
  • Nutzen beide Hosts HIP, kann diese Trennung eine Assoziation nach einem Adresswechsel erhalten. Sie überträgt weder eine Adressregistrierung noch aktualisiert sie automatisch alle Anwendungsregeln.

Ein Laptop verlässt ein Netz, verbindet sich anderswo und bekommt eine neue IP-Adresse. Der Paketweg hat sich geändert, der Kommunikationspartner nicht. Lange mussten Protokolle eine einzige Zahl für zwei Dinge verwenden: den topologischen Ort und den Namen des Endpunkts. Robert Moskowitz und Pekka Nikander machten diese Doppelrolle in RFC 4423 zum Ausgangspunkt ihrer Architektur.

Das Host Identity Protocol legt zwischen Internet- und Transportschicht einen eigenen Identitätsraum an. Ein Host Identifier ist darin ein öffentlicher Schlüssel; die Host Identity, für die er steht, ist die abstrakte Identität. Der Host Identity Tag (HIT) liefert eine kompakte 128-Bit-Darstellung. Die IP-Adresse bleibt notwendig, denn Router brauchen sie, um Pakete weiterzuleiten. Sie muss aber nicht mehr allein bestimmen, welchem Host eine Transportassoziation zugeordnet ist.

Diese andere Bindung ist der Kern des Entwurfs. RFC 4423 beschreibt Transportassoziationen, die an Host Identities gebunden sind. Ändert sich die Adresse wegen Mobilität, eines neuen Netzzugangs oder einer Umnummerierung, kann ein HIP-fähiger Partner den Locator aktualisieren und die identitätsgebundene Assoziation erhalten. Ein Host kann außerdem über mehrere Schnittstellen erreichbar sein. Ein Teil der Kontinuität wandert damit von einer festen Adresse zu einem kryptografischen Zustand, den die teilnehmenden Endpunkte gemeinsam verwalten.

Die RFC-Geschichte grenzt Moskowitz’ Beitrag genauer ein. RFC 4423 erschien im Mai 2006 als Informational. Die Autoren bezeichnen sie selbst als Momentaufnahme ihres Denkens im Herbst 2003 und weisen darauf hin, dass sich die Architektur weiterentwickelt haben kann. Sie definiert ausdrücklich keinen Internet-Standard. Die spätere RFC 7401, herausgegeben von Moskowitz und weiteren Autoren, legt HIP Version 2 als Standards-Track-Protokoll fest. Sie beschreibt, wie zustimmende Hosts einen gemeinsamen Zustand auf IP-Ebene aufbauen und sich in einem kryptografischen Austausch aus vier Paketen authentifizieren. 2021 aktualisierte die RFC 9063 von Moskowitz und Miika Komu die Architektur, löste RFC 4423 ab und nahm Erfahrungen aus Implementierungen von RFC 7401 sowie Fragen der kryptografischen Agilität und des Vertrauens beim ersten Kontakt auf.

Diese Folge belegt die Weiterentwicklung eines technischen Ansatzes, aber nicht das Ende der Adressabhängigkeit im Internet. HIP erhält die Assoziation, die seine beiden Endpunkte verwalten. Eine Firewall kann weiterhin nur eine bestimmte Quell-IP erlauben. Ein DNS-Eintrag kann auf einen alten Locator zeigen. Der Gegenhost unterstützt vielleicht kein HIP. Eine Anwendung kann eine Adresse in ihrer Konfiguration speichern oder als Reputationssignal auswerten. Dass eine Assoziation den Wechsel übersteht, ändert keinen dieser Zustände automatisch.

Note 68 von Heng Lu liefert eine andere, wirtschaftliche Perspektive: Eine Adresse kann zum Unternehmensgedächtnis werden, wenn Kunden, Partner und Sicherheitsteams ihre Erwartungen daran knüpfen. Das erklärt weder HIP noch belegt es einen konkreten Einsatz. Es hilft aber, zwei Formen von Kontinuität auseinanderzuhalten. HIP trennt die Host-Identität im Protokollaustausch vom Locator für das Routing; es schreibt die externen Beziehungen nicht um, die sich um eine Adresse gebildet haben.

Moskowitz’ Beitrag lässt sich daher als Grenzziehung in der Architektur lesen: „Mein Weg durchs Netz kann sich ändern; meine authentisierte Endpunktidentität ist ein anderer Zustand.“ Diese Grenze ist gerade deshalb nützlich, weil sie klar umrissen ist. HIP kann bei Mobilität und Multihoming die Abhängigkeit von festen Adressen senken. DNS, Routing, Ressourcenverwaltung, Anwendungsrichtlinien und Kundenkontinuität bleiben jedoch Aufgaben eigener Systeme.

Quellen