1. Introduction (Einführung)

1. Introduction (Einführung)

Eine BGP-Route verknüpft ein Adresspräfix mit einer Menge von autonomen Systemen (AS), die den Interdomänen-Pfad identifizieren, den das Präfix in Form von BGP-Ankündigungen durchlaufen hat. Diese Menge wird als AS_PATH-Attribut in BGP [RFC4271] dargestellt und beginnt mit dem AS, das das Präfix ursprünglich angekündigt hat. Um bekannte Bedrohungen gegen BGP, einschließlich falscher Präfix-Ankündigungen und Man-in-the-Middle-Angriffen, zu reduzieren, ist eine der Sicherheitsanforderungen die Fähigkeit, das ursprüngliche AS von BGP-Routen zu validieren. Genauer gesagt muss validiert werden, dass die AS-Nummer, die behauptet, ein Adresspräfix zu sein (wie vom AS_PATH-Attribut der BGP-Route abgeleitet), tatsächlich vom Präfixinhaber dazu autorisiert ist. Dieses Dokument beschreibt einen einfachen Validierungsmechanismus, um diese Anforderung teilweise zu erfüllen.

Die Resource Public Key Infrastructure (RPKI, Ressourcen-Public-Key-Infrastruktur) beschreibt einen Ansatz zum Aufbau einer formal verifizierbaren Datenbank von IP-Adressen und AS-Nummern als Ressourcen. Die Gesamtarchitektur von RPKI, wie in [RFC6480] definiert, besteht aus drei Hauptkomponenten:

• einer Public-Key-Infrastruktur (PKI) mit den erforderlichen Zertifikatsobjekten,

• digital signierten Routing-Objekten, und

• einem verteilten Repository-System zur Speicherung der Objekte, das auch periodisches Abrufen unterstützt.

Das RPKI-System basiert auf Ressourcenzertifikaten, die Erweiterungen zu X.509 definieren, um IP-Adressen und AS-Identifikatoren darzustellen [RFC3779], daher der Name RPKI. Route Origin Authorizations (ROA, Routenursprungsautorisierungen) [RFC6482] sind separate digital signierte Objekte, die Zuordnungen zwischen AS und IP-Adressblöcken definieren. Schließlich wird das Repository-System auf verteilte Weise über die IANA, die Regional Internet Registry (RIR)-Hierarchie und ISPs betrieben.

Um vom RPKI-System zu profitieren, wird erwartet, dass vertrauende Parteien auf AS- oder Organisationsebene eine lokale Kopie der signierten Objektsammlung erhalten, die Signaturen verifizieren und sie verarbeiten. Der Cache muss auch regelmäßig aktualisiert werden. Der genaue Zugriffsmechanismus zum Abrufen des lokalen Caches liegt außerhalb des Umfangs dieses Dokuments.

Einzelne BGP-Sprecher können die im lokalen Cache enthaltenen verarbeiteten Daten verwenden, um BGP-Ankündigungen zu validieren. Die Protokolldetails zum Abrufen der verarbeiteten Daten vom lokalen Cache zu den BGP-Sprechern liegen außerhalb des Umfangs dieses Dokuments (siehe [RFC6810] für einen solchen Mechanismus). Dieses Dokument schlägt eine Methode vor, mit der ein BGP-Sprecher die verarbeiteten Daten verwenden kann, um jedem Präfix in einer empfangenen BGP-UPDATE-Nachricht einen "Validierungsstatus" zuzuweisen.

Beachten Sie, dass die vollständige Pfadbeglaubigung gegen das AS_PATH-Attribut einer Route außerhalb des Umfangs dieses Dokuments liegt.

Wie beim DNS präsentiert das globale RPKI nur eine lose konsistente Ansicht, abhängig von Timing, Aktualisierung, Abruf usw. Daher kann ein Cache oder Router unterschiedliche Daten über ein bestimmtes Präfix haben als ein anderer Cache oder Router. Es gibt keine "Lösung" dafür; es ist die Natur verteilter Daten mit verteilten Caches.

Obwohl RPKI den Kontext für dieses Dokument bereitstellt, ist es ebenso möglich, jede andere Datenbank zu verwenden, die Präfixe ihren autorisierten Ursprungs-AS zuordnen kann. Jede unterschiedliche Datenbank hat ihre eigenen besonderen betrieblichen und Sicherheitsmerkmale; solche Merkmale liegen außerhalb des Umfangs dieses Dokuments.