RPKI für ISPs: Implementierung und Risiken, die man einplanen muss

RPKI für ISPs ist heute eines der wirksamsten Mittel, um Route Hijacks und Route Leaks im globalen Routing-Ökosystem zu reduzieren. Gleichzeitig ist RPKI kein „Schalter“, den man umlegt, sondern eine Kombination aus Kryptoinfrastruktur, Datenversorgung (ROAs, VRPs), Validierungslogik und operativen Entscheidungen in BGP-Policies. Wer RPKI implementiert, muss daher zwei Ziele gleichzeitig erreichen: Erstens die Routing-Sicherheit messbar erhöhen (Invalids erkennen und behandeln), und zweitens neue Risiken kontrollieren, die durch RPKI selbst entstehen können (Fehlkonfigurationen bei Kunden, Validator-Ausfälle, Dateninkonsistenzen, False Positives und unerwartete Traffic-Shifts). Besonders im ISP-Betrieb ist die Konsequenz hoch: Ein falsch behandeltes „Invalid“ kann legitimen Traffic blackholen, ein zu aggressives Rollout kann eskalierende Kundentickets auslösen, und ein unzureichendes Monitoring kann dazu führen, dass man RPKI zwar betreibt, aber im Incident nicht versteht, was gerade passiert. Dieser Leitfaden erklärt praxisnah, wie RPKI für ISPs implementiert wird, welche Architekturvarianten sich bewährt haben, welche Policy-Optionen (Drop vs. Depräferenz) realistisch sind und welche Risiken Sie von Anfang an einplanen müssen, damit RPKI nicht selbst zur Outage-Ursache wird.

Was RPKI im Routing wirklich absichert

RPKI (Resource Public Key Infrastructure) verbindet Internetressourcen (IP-Präfixe und ASNs) mit kryptografisch signierten Aussagen. Im operativen Kern geht es bei Routing-Security meist um ROAs (Route Origin Authorizations): Eine ROA sagt aus, welches AS (Origin-AS) ein bestimmtes Präfix announcen darf und bis zu welcher Prefix-Länge (maxLength). Aus diesen ROAs werden im Validierungsprozess VRPs (Validated ROA Payloads) abgeleitet. Router vergleichen dann eine BGP-Route (Präfix + Origin-AS + Prefix-Länge) gegen die VRPs und klassifizieren sie typischerweise als Valid, Invalid oder NotFound.

• Valid: Origin-AS und Prefix-Länge passen zu einer vorhandenen ROA.
• Invalid: Es existiert eine ROA, aber die Route widerspricht ihr (falsches Origin-AS oder Prefix-Länge > maxLength).
• NotFound: Für dieses Präfix existiert keine ROA (noch) – das ist kein Beweis für „böse“, sondern fehlende Signierung.

Normativer Einstieg: RFC 6480 (RPKI Architecture), RFC 6482 (ROAs) und für Route Origin Validation im Router RFC 6811. Für die Kommunikation zwischen Router und Validator ist RFC 8210 (RPKI-to-Router, RTR Protocol) relevant.

Warum ISPs RPKI einführen sollten

Der ISP-Nutzen von RPKI ist operativ greifbar: Sie reduzieren das Risiko, dass falsch originierte Routen in Ihr Netz gelangen (Hijack) oder dass Leaks über Kunden/Peers zu unerwünschten Pfaden führen. RPKI verhindert nicht jede Routing-Störung, aber es macht eine wichtige Klasse von Fehlern deutlich schwerer – vorausgesetzt, Sie implementieren es konsequent und überwachen es.

• Schutz vor Origin Hijacks: Wenn ein fremdes AS Ihr Präfix als Origin annonciert, kann RPKI das als Invalid markieren.
• Leak-Dämpfung: Manche Leaks zeigen sich als Invalids, wenn Kunden versehentlich fremde Prefixe mit falschem Origin weiterreichen.
• Bessere Incident-Triage: RPKI-States liefern zusätzliche Evidenz: „Warum wird diese Route nicht akzeptiert?“

Als praktischer Rahmen für Routing-Security und Umsetzungsdisziplin eignet sich MANRS (Mutually Agreed Norms for Routing Security), insbesondere in Kombination mit RPKI.

Architektur: Wie RPKI technisch im ISP-Betrieb umgesetzt wird

Eine robuste Implementierung besteht meist aus drei Komponenten: (1) ROA-Management (bei Ihnen und Ihren Kunden), (2) Validator-Services, die VRPs erzeugen, und (3) Router-Policies, die RPKI-States in Routing-Entscheidungen übersetzen.

Komponente 1: ROA-Management und Governance

ROAs werden typischerweise über die jeweiligen RIR-Portale oder über delegierte Zertifikate verwaltet. Für viele europäische ISPs ist das RIR-Portal von RIPE NCC eine zentrale Anlaufstelle; praxisnahe Dokumentation findet sich im Bereich RIPE NCC RPKI. Operativ ist entscheidend, dass ROA-Änderungen Prozesse haben:

• Änderungsmanagement: ROA-Updates wie Changes behandeln (Review, Zeitfenster, Rollback-Plan).
• Customer Enablement: klare Anleitung, wie Kunden ROAs setzen sollen (Origin-AS, Prefix, maxLength).
• Audit: regelmäßiger Abgleich: „Welche Kundenprefixe sind NotFound? Welche sind potenziell invalid-gefährdet?“

Komponente 2: Validatoren und VRP-Versorgung

Validatoren laden RPKI-Repositories, validieren kryptografisch und erzeugen daraus VRPs, die via RTR an Router verteilt werden. Operativ zählt vor allem: Verfügbarkeit, Konsistenz und Observability.

• Redundanz: mindestens zwei Validatoren (unabhängig), idealerweise in getrennten Fault Domains.
• Geordnete Updates: kontrollierte Update-Zyklen, damit ein Repository-Problem nicht sofort global Routing beeinflusst.
• State-Telemetrie: Anzahl VRPs, Last Successful Fetch, Serial/Session-Status RTR.

Komponente 3: Router-Integration und Policy

Router erhalten VRPs via RTR, klassifizieren eingehende BGP-Routen und setzen dann Policy-Aktionen um. Hier entsteht der größte operative Hebel – und das größte Risiko.

• Ingress-Policy: wie behandeln Sie Valid/Invalid/NotFound auf Sessions (Customer/Peer/Transit)?
• Attributsteuerung: setzen Sie LocalPref, Communities oder spezielle RPKI-Tags basierend auf State?
• Visibility: können NOC-Teams pro Session/Prefix den RPKI-State schnell sehen?

Implementierung in Stufen: Rollout-Plan, der Outages vermeidet

Die größte Gefahr bei RPKI-Rollouts ist ein „Big Bang“. RPKI verändert nicht die Data Plane, aber die Route-Auswahl – und damit kann es sehr schnell Traffic verschieben oder abschneiden. Ein stufenweiser Rollout ist für ISPs fast immer die sichere Wahl.

Stufe 1: Observe-only (Tagging ohne Enforcement)

• Ziel: VRP-Versorgung stabilisieren und Invalids sichtbar machen, ohne Traffic zu beeinflussen.
• Umsetzung: RPKI-State als Tag/Community/Local Label markieren; Monitoring und Dashboards bauen.
• Erfolgskriterium: stabile VRP-Zahlen, stabile RTR-Sessions, nachvollziehbare Invalid-Listen.

Stufe 2: Depräferenz statt Drop (soft enforcement)

• Ziel: Invalids weniger attraktiv machen, ohne harte Blackholes zu riskieren.
• Umsetzung: Invalid bekommt niedrigere LocalPref oder wird aus bestimmten Policies ausgeschlossen, aber nicht zwingend verworfen.
• Erfolgskriterium: sichtbare Reduktion von „Invalid als Best Path“, ohne Kundenimpact.

Stufe 3: Drop von Invalids (hard enforcement) – rollenbasiert

Wenn Sie Invalids droppen, muss die Rolle der Session berücksichtigt werden. Customer-Sessions können strenger sein als Transit, weil das Risiko eines Customer-Leaks oft höher ist und weil Kundenprefixe idealerweise ROA-abgedeckt werden.

• Customer: Drop Invalid häufig sinnvoll, wenn Customer-ROAs sauber gepflegt sind.
• Peer/Transit: Drop Invalid ist ebenfalls verbreitet, aber nur mit gutem Monitoring und klarer Kommunikation, um False Positives schnell zu beheben.

Enforcement-Logik als Policy-Regel (MathML)

$\mathrm{Accept}\Leftarrow \mathrm{RPKI}\_\mathrm{state}=\mathrm{Valid}\vee \mathrm{RPKI}\_\mathrm{state}=\mathrm{NotFound}$
$\mathrm{Drop}\Leftarrow \mathrm{RPKI}\_\mathrm{state}=\mathrm{Invalid}\wedge \mathrm{EnforcementEnabled}$

Die wichtigsten Risiken, die ISPs einplanen müssen

RPKI erhöht Sicherheit, aber verschiebt auch Verantwortung. Die häufigsten operativen Risiken sind bekannt und gut planbar – wenn man sie früh berücksichtigt.

Risiko 1: False Positives durch falsche oder fehlende ROAs

Das häufigste praktische Problem ist nicht „RPKI ist falsch“, sondern „ROA ist falsch“. Beispiele:

• Falsches Origin-AS: Prefix wird legitimerweise aus AS X annonciert, ROA erlaubt nur AS Y → Invalid.
• maxLength zu klein: Kunden deaggregieren für DDoS-Mitigation oder Traffic Engineering, aber ROA erlaubt nur das Aggregat → mehr spezifische Prefixe werden Invalid.
• Multi-Homing/Migration: Origin-AS ändert sich im Rahmen eines Providerwechsels, ROA wurde nicht aktualisiert → temporäres Blackhole-Risiko.

Operative Mitigation: Kundenprozesse, ROA-Change-Runbooks und ein „Invalid Hotline“-Workflow, der schnell ROA-Fixes triggert.

Risiko 2: Validator-Ausfall oder stale VRP-Daten

Wenn Router keine aktuellen VRPs bekommen, kann das zu Fehlklassifikationen oder zu „NotFound/Unknown“-Zuständen führen. Je nach Implementierung kann ein Validator-Ausfall auch dazu führen, dass ein Router in einen Fail-Open- oder Fail-Closed-Modus gerät (policyabhängig). Das muss bewusst entschieden und getestet sein.

• Fail-Open: bei VRP-Ausfall weiter akzeptieren (geringerer Schutz, aber weniger Outage-Risiko).
• Fail-Closed: bei VRP-Ausfall restriktiv (höherer Schutz, aber Risiko von Trafficverlust).

Best Practice: redundante Validatoren und Monitoring, das VRP-Count-Drops und RTR-Session-Probleme sofort alarmiert.

Risiko 3: Unerwartete Traffic-Shifts und Congestion

Wenn Invalids gedroppt werden, können Best Paths wechseln. Das kann Traffic plötzlich auf andere Transits/Peers lenken und Congestion erzeugen – selbst wenn das Routing „korrekter“ wird. Deshalb sollte RPKI-Enforcement immer mit Traffic- und Capacity-Monitoring gekoppelt sein.

• Symptom: Prefix wird über anderen Upstream gewählt, Latenz und Auslastung verschieben sich.
• Mitigation: staged rollout, Beobachtungsfenster, Notfall-Override (temporär depräferieren statt droppen).

Risiko 4: Kundenkommunikation und Support-Last

RPKI ist für viele Kunden neu. Wenn Sie Invalids droppen, müssen Sie Kunden befähigen, ROAs korrekt zu setzen. Ohne klare Kommunikation eskalieren Tickets als „Provider blockt unsere Routen“. Praktische Maßnahmen:

• Customer Guide: ROA-Howto, typische Fehler, maxLength-Strategie, Migrations-Checkliste.
• Self-Service Checks: Kunden sollen ihren eigenen RPKI-Status prüfen können (Portal/Tooling).
• Support-Runbook: NOC-Standardfragen: „Ist es Invalid? Welche ROA? Welche maxLength?“

Risiko 5: Teilabdeckung und „NotFound“-Realität

In der Realität ist nicht jedes Präfix mit einer ROA abgedeckt. NotFound ist daher normal. Wenn Sie NotFound wie Invalid behandeln, riskieren Sie großflächige Reachability-Probleme. Deshalb ist die gängige Praxis: NotFound akzeptieren, aber sichtbar machen – und schrittweise Abdeckung erhöhen.

Monitoring: Welche Kennzahlen für RPKI im ISP-Betrieb Pflicht sind

Damit RPKI nicht zur Black Box wird, brauchen Sie Metriken, die sowohl technische Gesundheit als auch Policy-Effekt zeigen.

Validator- und RTR-Health

• VRP Count: Anzahl VRPs im Zeitverlauf (plötzliche Drops sind Alarm).
• Last Fetch/Sync: wann wurden Repositories zuletzt erfolgreich geladen.
• RTR Sessions: up/down, reconnect rate, serial changes.

Routing-Policy-Health

• Invalid Rate pro Neighbor: Anteil Invalids je Session (Customer/Peer/Transit) – starke Spikes sind Leak- oder ROA-Fehlerindikatoren.
• Dropped Invalid Prefixes: absolute Zahl und Trend (inkl. Top-N Beispiele).
• NotFound Coverage: Anteil NotFound (Monitoring für Abdeckungsprogramme).

Invalid-Anteil als Monitoring-KPI (MathML)

$\mathrm{InvalidShare}=\frac{P\_\mathrm{invalid}}{P\_\mathrm{total}}$

Traffic-Impact

• Traffic Shifts: Auslastung an Transits/Peers nach RPKI-Änderungen.
• Latency/Loss Probes: synthetische Messungen zu Referenzzielen, um unerwartete Pfadwechsel sichtbar zu machen.
• Congestion Indikatoren: Queue Drops, ECN/Markings (falls genutzt), Mikroburst-Telemetrie.

Policy-Design: Wie ISPs RPKI in BGP-Policies einbetten

RPKI ist am wirkungsvollsten, wenn es in ein rollenbasiertes Policy-Design eingebettet ist. Rollen helfen, konsistente Defaults zu definieren und Fehler zu vermeiden. Das ist besonders im Kontext von Route Leaks relevant; rollenbasierte Ansätze werden in RFC 9234 beschrieben.

• Customer: strenge Filter + RPKI Invalid Drop, wenn ROA-Abdeckung hoch ist.
• Peer: häufig Invalid Drop, NotFound akzeptieren; bei Supportfällen klare Eskalationswege.
• Transit: Invalid Drop üblich, aber besonders gutes Monitoring nötig, weil Traffic-Shifts groß sein können.

Runbook: Was tun, wenn RPKI plötzlich Kundenimpact erzeugt?

Ein realistisches Risiko ist der „RPKI-induced Outage“: Ein legitimes Präfix wird plötzlich Invalid (falsche ROA, maxLength, Origin-Wechsel), und Enforcement dropt es. Dafür braucht es ein schnelles, kontrolliertes Incident-Runbook.

Schritt: Klassifikation

• Ist die Route Invalid? oder NotFound/Valid?
• Welche Dimension? Origin mismatch oder maxLength?
• Scope: betrifft es einen Kunden, mehrere Kunden oder einen Upstream/Peer?

Schritt: Mitigation

• Temporärer Override: kontrolliertes „depräferieren statt droppen“ für genau dieses Präfix/Session, wenn businesskritisch.
• ROA-Fix beschleunigen: Owner bestimmen, ROA aktualisieren, propagation abwarten und verifizieren.
• Beweis sammeln: VRP/ROA-Daten, Zeitpunkt der Änderung, BGP-Updates, Before/After.

Schritt: Post-Validation

• Route State: Invalid wird Valid oder NotFound (je nach Ziel), und Route ist wieder akzeptiert.
• Traffic stabil: keine unerwarteten Shifts, keine Congestion-Spitzen.
• Guardrail Update: Monitoring/Alerts anpassen, damit der Fehler früher sichtbar wird.

Praktische Empfehlungen für sichere RPKI-Einführung

• Staged Rollout: observe-only → soft enforcement → hard enforcement.
• Redundante Validatoren: mindestens zwei, getrennte Fault Domains, klare Alarmierung auf VRP-Count und RTR-Health.
• Customer Enablement: ROA-Guides, maxLength-Strategien, Migrations-Checklisten, Support-Workflows.
• Policy-Templates: rollenbasiert (Customer/Peer/Transit), mit Change-Validation und Audit.
• Evidence Packs: standardisierte Daten für RPKI-Fälle (State, VRP, ROA, Prefix, Origin, Zeitfenster).

Outbound-Ressourcen

• RFC 6480 (RPKI Architecture)
• RFC 6482 (Route Origin Authorizations)
• RFC 6811 (BGP Prefix Origin Validation)
• RFC 8210 (RPKI-to-Router Protocol, RTR)
• RFC 9234 (BGP Roles: Route Leak Prevention and Detection)
• RIPE NCC RPKI (Praxisdokumentation und Betriebsinformationen)
• MANRS (Operational Best Practices für Routing-Sicherheit)

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.