RPKI Route Origin Validation in OcNOS: ROV am Peering-Edge konfigurieren

Route Origin Validation ist die kostengünstigste Kontrolle, die ein Betreiber am Internet-Edge hinzufügen kann, und sie ist von optional zu erwartet geworden. Dieser Leitfaden zeigt, wie sie in OcNOS funktioniert und wie sie auf einem Peering-Router konfiguriert wird, mit Befehlen, die auf OcNOS-SP verifiziert wurden.

Was ist RPKI Route Origin Validation?

Die Resource Public Key Infrastructure (RPKI) bindet ein IP-Präfix an das Netzwerk, das zu seiner Ankündigung berechtigt ist, in einem kryptografisch signierten Datensatz namens Route Origin Authorization (ROA). Route Origin Validation (ROV) ist die Aktion, die ein Router ausführt, wenn er eine eingehende BGP-Route mit diesen ROAs vergleicht und sie als valid, invalid oder not-found markiert. Eine Route ist valid, wenn Origin-AS und Präfixlänge einer ROA entsprechen, invalid, wenn eine ROA existiert, aber Origin oder Länge falsch sind, und not-found, wenn keine ROA das Präfix abdeckt. ROV stoppt den häufigsten Routing-Unfall und -Angriff in einem Schritt: ein Netzwerk, das ein Präfix ankündigt, das ihm nicht gehört, und so den Verkehr anderer Betreiber in die falsche Richtung lenkt.

Warum RPKI jetzt wichtig ist

Route Origin Validation ist kein Nice-to-have mehr. Große Transit-Provider weisen RPKI-invalid-Routen standardmäßig zurück, nationale Regulierungsbehörden verweisen in ihren Vorgaben auf Routing-Sicherheit, und die MANRS-Aktionen behandeln Origin Validation und Präfixfilterung als Grundvoraussetzung für ein ernstzunehmendes Netzwerk. Für einen Betreiber, der die vollständige Internet-BGP-Tabelle am Peering-Edge führt, beseitigt ROV mit sehr geringem Aufwand eine ganze Klasse von Fehlorigin. Zudem sind Sie sofort geschützt, denn Sie profitieren von jeder bereits existierenden ROA, ohne auf den Rest des Internets zu warten.

Wie OcNOS Routen validiert

OcNOS führt die RPKI-Datenbank nicht auf dem Router. Es verbindet sich mit einem externen RPKI-Validator, auch RPKI-to-Router (RTR) Cache genannt, der ROAs von den Trust Anchors abruft und kryptografisch prüft und dem Router einen sauberen Satz validierter Präfix-zu-Origin-Datensätze übergibt. OcNOS hält diese validierte Tabelle im Speicher, aktualisiert sie per Timer und markiert Routen, sobald es sie empfängt. Sie können den Router zur Redundanz auf mehr als einen Validator verweisen. Jeder Validator, der das RTR-Protokoll spricht, funktioniert, darunter Routinator, rpki-client mit StayRTR und Krill-Deployments von NLnet Labs.

So konfigurieren Sie RPKI Route Origin Validation in OcNOS

Die Konfiguration besteht aus drei Teilen: den Router mit einem Validator verbinden, die validierte Tabelle füllen lassen und eine Policy anwenden, die auf das Ergebnis reagiert. OcNOS ist transaktional, daher wird jede Stufe angewendet mit commit.

1. Den Router mit RPKI-Validatoren verbinden

Verweisen Sie den Router innerhalb der BGP-Instanz auf einen oder zwei RTR-Caches. Die Adresse allein ist ein vollständiger Befehl, und port ist optional und ist bei TCP standardmäßig 3323.

configure terminal
router bgp 64500
 bgp rpki server 10.0.0.10 port 3323
 bgp rpki server 10.0.0.11 port 3323
 commit

2. Den Validierungsstatus abgleichen und invalid-Routen verwerfen

Verwenden Sie eine route-map, um auf den RPKI-Status zu reagieren. Diese weist invalid-Routen ab und lässt alles andere zu, sodass valid- und not-found-Routen akzeptiert und invalid-Routen verworfen werden.

route-map RPKI-EDGE-IN deny 10
 match rpki invalid
!
route-map RPKI-EDGE-IN permit 20
 commit

3. Die Policy eingehend auf der Peering-Sitzung anwenden

Binden Sie die route-map an den eBGP-Peer in der Address Family, die sie schützen soll. Wiederholen Sie dies unter address-family ipv6 unicast für IPv6.

router bgp 64500
 address-family ipv4 unicast
  neighbor 203.0.113.1 route-map RPKI-EDGE-IN in
  exit
 commit

Wie überprüfe ich, ob die RPKI-Validierung funktioniert?

Bestätigen Sie, dass die Validator-Sitzung aktiv ist, dass die validierte Tabelle Einträge enthält und dass Routen markiert werden. OcNOS bietet dafür drei Befehle.

OcNOS# show bgp rpki server
OcNOS# show bgp rpki table
OcNOS# show bgp rpki

show bgp rpki server meldet jeden Validator und ob dessen Sitzung aufgebaut ist, show bgp rpki table listet die validierten Präfix-zu-Origin-Datensätze auf, die der Router heruntergeladen hat, und show bgp rpki fasst den RPKI-Status zusammen. Sobald die Sitzung aufgebaut ist und die Tabelle Einträge enthält, tragen Routen, die die Validierung nicht bestehen, den invalid-Status und werden von der route-map am Edge verworfen.

RPKI am Peering-Edge

Origin validation is one layer of a secure peering edge, not the whole of it. On a complete open peering router, RPKI invalid-route rejection sits alongside prefix filtering aligned with MANRS, BGP FlowSpec for DDoS mitigation, and remote-triggered black-holing, so the router enforces routing hygiene and attack response from the same place it carries the full table. See how the roles fit together on the offener IP-Core- und Peering-Router.