Zusammenfassung

  • RFC 5206 und RFC 8046 schützen die Locator-Mitteilung, setzen eine neu gelernte Adresse aber grundsätzlich auf UNVERIFIED. Erst Nonce-Antwort oder geeigneter geschützter Empfang liefert Erreichbarkeitsevidenz.
  • Credit-Based Authorization erlaubt begrenzte Bytes während der Prüfung. Sie verhindert Verstärkung, bestätigt aber weder Adresse noch SA, Pfad oder Anwendung.

Der Sprecher ist bekannt, der Weg nicht

HIP bindet Transportbeziehungen an Host Identities statt an wechselnde IP-Adressen. Ein mobiles Gerät kann den Anschluss wechseln, ohne als neuer kryptografischer Partner zu erscheinen. Aus dieser Stabilität folgt keine stabile Route.

HMAC und Signatur sagen, welcher Peer Locator, Lebensdauer und Präferenz gemeldet hat. Sie schützen die Nachricht vor unbemerkter Änderung. Zwischen Signatur und Netzrealität liegen jedoch Interface, Routing, NAT, Firewall und Empfangszustand.

Die Zustände UNVERIFIED, ACTIVE und DEPRECATED machen die Grenze messbar. Wer UNVERIFIED aus einem Dashboard entfernt, ersetzt eine genaue Zustandsmaschine durch symbolische Gewissheit.

Die Challenge muss den behaupteten Ort erreichen

Typischerweise enthält ein UPDATE an die neue Adresse einen zufälligen Nonce im ECHO_REQUEST. Die passende Antwort zeigt Empfang und Reaktion dort. Ein anderes Verfahren ist zulässig, wenn es denselben Sachverhalt belegt.

Auch geschützte Daten auf einer neu angekündigten SA können implizit genügen. Dann ist das eingetroffene Paket der Beleg. Die frühere Liste war nur die Ankündigung.

SA-Erstellung, Locator-Verifikation, erster ESP-Nutzverkehr und Anwendungskontinuität benötigen getrennte Zeiten. Eine lokale SA kann bereitstehen, obwohl nie etwas zurückkommt. Ein HIP-Reply kann passieren, während ESP später blockiert wird.

Präferenz ist Policy

Das P-Bit beschreibt den Wunsch des Peers. Ist der neue bevorzugte Locator noch UNVERIFIED, soll ein vorhandener ACTIVE-Pfad während der Prüfung weiterlaufen. Aktivierung folgt auf den Nachweis.

Die Locator Lifetime hält einen Datensatz gültig; sie garantiert nicht die Leitung. Route, Funk, NAT oder Policy können vorher wechseln. Nach Inaktivität darf auch ACTIVE wieder UNVERIFIED werden.

Die enge R1-Ausnahme gehört in ihren Base-Exchange-Kontext. Sie ist kein allgemeines Argument, jede signierte Adresse ungeprüft zu aktivieren.

CBA führt ein Unsicherheitskonto

Eine vollständige Prüfung kostet einen Round Trip. CBA erlaubt in der Zwischenzeit Verkehr in Höhe kürzlich empfangener Bytes. Senden verbraucht Credit, Zeit lässt ihn altern.

Damit wird Redirection nicht unmöglich. Die Spezifikation verhindert Verstärkung und macht den Angriff nicht attraktiver als direkte Flutung. Ein sauberer Datensatz heißt unter CBA gesendet und nennt Guthaben, Herkunft, Aging, Verbrauch und späteres Ergebnis.

Kehrt der Nonce nie zurück, bleibt der Verkehr eine begrenzte Entscheidung unter Unsicherheit. Er ist kein nachträglicher Erfolgsbeweis.

Die beweisbare Ereigniskette

Zu speichern sind Association, UPDATE-Fingerprint, Locator Set, Lifetime, Präferenz, Adressprüfung, Anfangsstatus, Fallback, Nonce, Wiederholungen, Antwort oder geschütztes Paket, Statuswechsel, Pfadauswahl, SA, erste Nutzlast, Anwendung, Ablauf und Löschung.

So lassen sich Signaturerfolg mit Challengefehler, Challengeerfolg mit ESP-Fehler und ESP-Erfolg mit Anwendungsfehler kombinieren, ohne Widerspruch zu behaupten. Jede Komponente bleibt bei ihrer Evidenz.

Version ist eine Betriebsfrage

RFC 5206 erschien 2008 Experimental und ist obsolet. RFC 8046 ersetzte sie 2017 auf dem Standards Track, benannte LOCATOR in LOCATOR_SET um und verlagerte Multihoming in RFC 8047. Die getrennte Reachability-Prüfung blieb.

Ein moderner RFC-Verweis beweist kein Upgrade. Parser, State Machine, Timer, CBA-Werte und Paketverhalten müssen aus Running Code stammen.

Führung sollte vier Zusagen trennen: authentisierte Ankündigung, verifizierter Locator, aktiver geschützter Pfad, kontinuierliche Anwendung. Die Signatur verantwortet den Sprecher; die Rückkehr verantwortet den Weg.

Quellen

  1. RFC 5206 Informationen
  2. RFC 5206 HTML
  3. RFC 5206 Text
  4. Datatracker RFC 5206
  5. RFC 5206 Verlauf
  6. RFC 5206 Referenzen
  7. RFC 5206 Errata
  8. RFC 8046 Informationen
  9. RFC 8046 HTML
  10. RFC 8046 Text
  11. Datatracker RFC 8046
  12. RFC 8046 Verlauf
  13. RFC 8046 Referenzen
  14. RFC 8046 Errata
  15. RFC 7401 — HIP v2
  16. RFC 7402 — HIP ESP
  17. RFC 8047 — HIP Multihoming
  18. RFC 6973 — Datenschutz
  19. RFC 4423 — HIP-Architektur
  20. Heng Lu — Realitätsebenen
  21. Heng Lu — minimale Anfangsspezifikation
  22. Heng Lu — Vorrang laufenden Codes