Bildquelle: extern
RPKI im Unternehmensnetz: Warum Internet-Routing 2026 nicht mehr nur Sache des Providers ist
Viele IT-Organisationen behandeln Internet-Routing noch immer als Randthema der Carrier oder des Rechenzentrumsbetriebs. Solange Leitungen stehen und der Transitvertrag läuft, scheint die Verantwortung sauber ausgelagert. Genau diese Sicht wird 2026 für einen Teil der Unternehmen zu kurz. Denn wer eigene IP-Präfixe nutzt, mit mehreren Providern arbeitet, DDoS-Schutzdienste einschaltet, Colocation betreibt oder Cloud-Exits über eigene Routing-Policies steuert, hängt operativ längst mit in der Verantwortung.
RPKI, also die Resource Public Key Infrastructure, setzt genau dort an. ARIN beschreibt sie als kryptografisch verifizierbare Methode, mit der Ressourceninhaber festlegen können, welche Autonomous Systems ihre Präfixe originieren dürfen. RIPE NCC macht es operativ noch greifbarer: Über Route Origin Authorizations, kurz ROAs, lässt sich festhalten, welches AS einen bestimmten Prefix ankündigen darf. Router oder Validierungssoftware können diese Angaben dann gegen reale BGP-Ankündigungen prüfen und Zustände wie valid, not found oder invalid ableiten.
Für klassische Mittelständler mit einem einzigen Internetzugang ohne eigene Ressourcen bleibt das Thema oft indirekt. Für größere Unternehmen, öffentliche Einrichtungen, Forschungsnetze, Plattformbetreiber und Organisationen mit Multi-Provider-Anbindung ist es dagegen ein handfestes Betriebs- und Risikothema. Worauf es praktisch ankommt, zeigen fünf Punkte.
1. Zuerst klären, ob das eigene Haus überhaupt Routing-Verantwortung trägt
Der wichtigste erste Schritt ist kein Tool, sondern ein sauberes Lagebild. Viele Organisationen wissen erstaunlich ungenau, ob sie eigene Provider-Independent-Adressräume, eigene ASNs oder historisch gewachsene Ankündigungswege über Dienstleister im Einsatz haben. Spätestens bei Colocation, MPLS-Altverträgen, regionalen Rechenzentren, SD-WAN-Hubs, Internet-Breakouts oder DDoS-Mitigation-Providern wird diese Unschärfe riskant.
Praktisch sollte jede IT-Leitung deshalb vier Dinge zusammentragen: welche Präfixe der Organisation gehören, welche ASNs beteiligt sind, welche Provider oder Scrubbing-Dienste Ankündigungen im Namen der Organisation machen dürfen und wo es aktive oder geplante Multi-Homing-Szenarien gibt. Genau diese Transparenz entscheidet darüber, ob RPKI ein Muss, ein Soll oder vorerst nur Beobachtungsthema ist.
Der Vorteil dieser Inventur ist größer als nur RPKI. Sie räumt oft auch veraltete Carrier-Abhängigkeiten, unklare Eigentümerschaften und still mitlaufende Sonderwege auf, die in Incidents später sonst teuer werden.
2. Legitime Ankündigungen müssen als ROAs sauber hinterlegt werden, nicht nur „ungefähr passend“
Wenn die Organisation eigene Ressourcen oder delegierte Verantwortung trägt, folgt der eigentliche Kernschritt: legitime Route-Origin-Ankündigungen müssen sauber autorisiert werden. RIPE NCC beschreibt ROAs als signierte Objekte, die festlegen, welches Origin-AS einen oder mehrere Präfixe announcen darf. Der operative Fehler besteht häufig nicht im Nichtstun, sondern im halbrichtigen Eintrag. Ein Präfix ist erfasst, aber nicht alle berechtigten Origin-ASNs. Oder ein DDoS-Dienstleister wird im Vertrag genannt, aber nie im ROA-Modell berücksichtigt.
Gerade in Multi-Provider-Umgebungen braucht deshalb jedes legitime Ursprungs-AS für das betreffende Präfix einen nachvollziehbaren Eintrag. Wer heute mehrere Upstreams, einen externen Mitigation-Provider und zusätzlich einen temporären Migrationspfad über einen zweiten Standort nutzt, sollte genau diese Realität im RPKI-Modell abbilden. Sonst produziert die Organisation ihre eigenen „invalid“-Zustände.
Wichtig ist auch die Zuständigkeit. ROAs gehören nicht in die lose Verantwortung eines einzelnen Netzwerkingenieurs, sondern in ein dokumentiertes Betriebsmodell mit Owner, Vier-Augen-Prinzip und Änderungsnachweis. Denn faktisch beeinflussen sie, welche Routing-Ankündigungen im Internet als legitim gelten.
3. Das maxLength-Feld darf nicht bequem gesetzt werden, nur weil es kurzfristig flexibler wirkt
Ein besonders häufiger Fehlgriff ist die großzügige Nutzung von maxLength. Auf den ersten Blick wirkt das attraktiv, weil damit auch spezifischere Präfixe autorisiert werden können. Das IETF-Best-Current-Practice RFC 9319 warnt hier aber sehr klar: Der leichtfertige Einsatz von maxLength vergrößert die Angriffsfläche für forged-origin sub-prefix hijacks. Die Empfehlung lautet deshalb, wann immer möglich minimale ROAs zu verwenden, die nur tatsächlich angekündigte Präfixe autorisieren.
Für die Praxis heißt das: Standardmäßig sollte ein ROA möglichst exakt zur real angekündigten Route passen. Größere Flexibilität ist nur dann sinnvoll, wenn ein konkreter, dokumentierter Betriebsfall existiert, etwa eine geplante DDoS-Abwehr mit spezifischeren Präfixen oder eine klar vorbereitete De-Aggregation im Störungsfall. Auch dann gehört die Entscheidung in ein geprüftes Design und nicht in eine spontane Admin-Abkürzung.
Gerade dieser Punkt ist für Change und Security wichtig. Eine zu weit gefasste Autorisierung bleibt im Alltag oft unsichtbar, bis sie im Fehlerfall oder Missbrauchsszenario plötzlich relevant wird. Präzision schlägt hier Bequemlichkeit.
4. Route Origin Validation gehört in Edge und Provider-Steuerung, nicht nur ins Architekturpapier
ROAs allein schützen noch nicht. Erst wenn Netze Route Origin Validation, also ROV, tatsächlich nutzen, entsteht betrieblicher Schutzwert. RIPE NCC beschreibt die drei Grundzustände sehr klar: valid, not found und invalid. Für Organisationen mit eigener Routing-Infrastruktur oder starkem Einfluss auf Provider-Policies ist deshalb die nächste Frage entscheidend: Wo wird validiert, mit welcher Policy und wie wird ein Übergang getestet?
Ein häufiger Reifegradpfad ist sinnvoll. Zuerst sollten Unternehmen Sichtbarkeit schaffen, also ROV-Zustände protokollieren und auf Auffälligkeiten überwachen. Danach können Regeln wie bevorzugte Behandlung valider Routen oder Alarmierung bei ungültigen Announcements folgen. Harte Verwerfungsregeln für invalid sind fachlich oft richtig, sollten aber nur nach Test und mit sauberem Fallback eingeführt werden, damit eigene Altlasten oder Providerfehler nicht produktive Erreichbarkeit beschädigen.
Die NYSERNet-Fallstudie bei MANRS zeigt genau diesen praktischen Punkt: Die eigentliche Einführung von RPKI bringt oft alten Staub im Netz ans Licht, also vergessene Sonderrouten, historisch gewachsene Konfigurationen und unklare Zuständigkeiten. Das ist kein Argument gegen Validierung, sondern ein gutes Signal, dass technische Schulden sichtbar werden.
5. RPKI muss an Change, Incident und Provider-Management angebunden sein
Der größte Fehler wäre, RPKI als einmaliges Netzwerkprojekt abzuhaken. In Wahrheit gehört es in mehrere Betriebsprozesse. Jede neue Carrier-Anbindung, jeder Wechsel eines DDoS-Anbieters, jede Rechenzentrumsmigration und jede Änderung an einem Origin-AS kann ROAs und Validierungspfade berühren. Ohne Prozessankopplung bleiben die Einträge schnell veraltet.
Mindestens drei Verbindungen sollten 2026 fest etabliert sein. Erstens muss jeder relevante Netzwerk-Change prüfen, ob ROAs angepasst werden müssen. Zweitens sollten Incident- und Major-Incident-Runbooks einen Blick auf ROV-Zustände enthalten, wenn es um unerklärliche externe Erreichbarkeitsprobleme geht. Drittens braucht das Provider-Management vertragliche Klarheit dazu, welche ASNs ein Dienstleister nutzen darf und wie Routing-Änderungen angekündigt werden.
Hinzu kommt ein eher strategischer Punkt: Das NRO-RPKI-Programm arbeitet seit 2024 daran, Transparenz, Robustheit und eine konsistentere Nutzererfahrung über die RIRs hinweg zu verbessern. Das zeigt, dass RPKI kein exotisches Nischenthema mehr ist, sondern ein Feld, in dem Standards, Oberflächen und Best Practices sichtbar reifen. Wer heute beginnt, schafft also nicht nur mehr Sicherheit, sondern auch mehr Anschlussfähigkeit an einen stabileren globalen Betriebsstandard.
Fazit
RPKI ist 2026 nicht für jedes Unternehmen ein Sofortprojekt. Aber für Organisationen mit eigenen Präfixen, eigenem ASN, Multi-Provider-Internet, DDoS-Schutzdiensten oder anspruchsvollen Cloud- und Rechenzentrumsanbindungen ist es längst mehr als eine Sache des Carriers. Entscheidend sind ein ehrliches Inventar, präzise ROAs, vorsichtiger Umgang mit maxLength, ein gestufter ROV-Rollout und die feste Einbindung in Change-, Incident- und Provider-Prozesse.
Wer diese Punkte sauber angeht, verbessert nicht nur Routing-Sicherheit. Er gewinnt auch etwas, das im Betrieb oft genauso wertvoll ist: Klarheit darüber, wer im Ernstfall tatsächlich die Kontrolle über die eigenen Internet-Wege hat.
