Zusammenfassung

  • RFC 8805 beschreibt grobe, vom Netzbetreiber veröffentlichte Standortdaten je Präfix, die ein Verbraucher als Hinweis behandeln kann.
  • RFC 9632 bindet eine signierte Datei an die Autorität über den abgedeckten Adressraum, nicht an die physische Wahrheit des Standorts.
  • Ein belastbarer Abschluss verbindet die signierte Revision mit Abruf, Aktivierung, Überlappungsentscheidung und beobachtetem Ergebnis.

Die Signatur stimmt, die Karte bleibt falsch

Ein Betreiber verlagert ein Präfix in eine andere Stadt, aktualisiert den Geofeed und fügt den optionalen RPKI-Authenticator hinzu. Die Prüfung besteht. Tage später zeigt ein Videokatalog, eine Betrugsprüfung oder die CDN-Auswahl noch die alte Stadt.

Die Signatur ist nicht nutzlos. RFC 9632 prüft, ob der Signierende für die abgedeckten Ressourcen autorisiert ist und ob die kanonischen Dateibytes übereinstimmen. HTTPS schützt den Abrufendpunkt, doch WebPKI authentifiziert keine Zuweisung von IP-Adressraum.

RFC 8805 definiert eine einfache CSV-Zuordnung von Präfix, Land, Region und Stadt. Die Ortsangabe ist bewusst grob. Verbraucher dürfen sie als Hinweis behandeln, andere Quellen bevorzugen und sollen Autorität und Genauigkeit getrennt prüfen. Kryptografie beobachtet nicht, wo Router, Nutzer oder Dienste tatsächlich stehen.

RFC 9632 ermöglicht die Entdeckung über das Attribut geofeed: eines RPSL-Objekts inetnum:. Abrufzeit, Longest-Match-Entscheidung, Zusammenführung weiterer Daten und Aktivierung einer Revision bleiben beim Verbraucher. Cache-Alter und Datensatzversion sind deshalb operative Belege.

Die Untersuchung verfolgt ein Präfix über Feed-Hash, Signatur und Zertifikatsabdeckung, Entdeckungsobjekt, Abrufzeit, Parser, Überlappung, Verbraucherversion, aktivierten Ort und externe Messungen. „Signatur gültig“ schließt nur die Authentifizierung.

Quellen