Zusammenfassung

  • Der individuelle HCGA-Entwurf bindet die Subnetzbits zwischen einem vom Betreiber kontrollierten Aggregat und der /64-Grenze an einen öffentlichen Schlüssel.
  • Bei einem /48-Aggregat sind das 16 Bits. Ein anderer Schlüssel kann sie in etwa 2^16 Versuchen treffen. Daher braucht jedes /64 eine exklusive Zulassung und eine Kontrolle der Paketquelle.

Ein Schloss mit zwei passenden Schlüsseln verlangt einen Pförtner. Genau diesen Pförtner braucht Hierarchical Cryptographically Generated Addresses. Der Entwurf soll Arbeitslasten oder Agenten in einem gemeinsam genutzten Netz ein aus ihrem Schlüssel berechnetes IPv6-/64 geben. Rechenbar wird die Verbindung zwischen Schlüssel und Adresse. Die Zuteilung selbst bleibt eine Entscheidung des Betreibers.

Nach RFC 3972 wird die untere Schnittstellenkennung einer IPv6-Adresse aus einem öffentlichen Schlüssel abgeleitet, während die Infrastruktur das /64-Präfix bereitstellt. HCGA würde auch die Subnetzbits oberhalb dieser Grenze aus dem Schlüssel und einem Präfix-Modifikator berechnen. Das Aggregat kontrolliert weiter der Netzbetreiber. Wer die Rechnung später prüfen will, braucht Schlüssel, Modifikatoren und Kollisionszähler aus der Erzeugung.

Die Sicherheitsanalyse benennt die Sollbruchstelle präzise. Unter /48 sind 16 Bits für die Wahl eines /64 übrig. Ein zweiter Schlüssel oder Modifikator kann diese Bits in ungefähr 2^16 Versuchen treffen. Das ist eine Kollision des Subnetzanteils. Weder der private Schlüssel noch die gesamten 128 Bits der IPv6-Adresse fallen dadurch mit 2^16 Versuchen; die Schnittstellenkennung hat eine eigene, wesentlich größere Hash-Grenze. Für die Frage, wer ein /64 erhalten hat, reicht das /64 allein dennoch nicht.

Der Entwurf überlässt einem umgebenden System die exklusive Zulassung: Es muss festhalten, welcher Schlüssel mit welchem Modifikator zu welchem /64 gehört, und konkurrierende Bewerber abweisen. Die Adresse eines Pakets beweist zudem nicht dessen Absender. Dafür braucht es entweder eine Signatur des zugehörigen privaten Schlüssels oder Netzregeln für Quelladressen. Außerhalb des lokalen Links gelingt die Prüfung nur, wenn die Erzeugungsparameter aufbewahrt und zugänglich sind.

Auch die Routing-Autorisierung trifft diese Einzelentscheidung nicht. Der Betreiber kündigt das Aggregat über BGP mit einer RPKI-ROA an; die einzelnen /64-Routen bleiben intern. Eine gültige ROA belegt die Berechtigung für die breite Ankündigung. Sie sagt nichts darüber, welcher Arbeitslast-Schlüssel innerhalb des Aggregats zugelassen wurde. Die Vergabeakte ist der engere Beleg.

Die stabile Vergabe hat einen Preis. Laut Entwurf bleibt das /64 erhalten, wenn die untere Schnittstellenkennung wechselt. Damit lassen sich Aktivitäten über solche Wechsel hinweg verbinden. Die temporären IPv6-Adressen aus RFC 8981 verfolgen ein anderes Datenschutz-Ziel. Zudem lässt die HCGA-Rechnung offen, ob ein Schlüssel durch Hardware oder nur Software geschützt ist. Die RATS-Architektur behandelt separate Attestierungsnachweise.

Im IETF-Datatracker steht der Entwurf vom 27. Oktober als individueller Standards-Track-Vorschlag auf „I-D Exists“. Ein aussagekräftiger Versuch erzeugt zwei Schlüssel mit demselben 16-Bit-Subnetzanteil unter einem Test-/48, weist den zweiten zurück und lässt einen externen Prüfer den ersten Schlüssel, die Parameter und den Nachweis der Paketquelle rekonstruieren. An dieser Beweiskette muss sich die Idee messen lassen.