zurück zum Artikel

Die FCC untersucht die "Unsicherheit" des Routing-Systems. Bereitet das alte Routing-Protokoll BGP Sorgen? Praktiker versichern: BGP werde alles überleben.

Vier Tage nach Beginn des Krieges in der Ukraine veröffentlichte die US-Behörde Federal Communications Commission (FCC) ein Konsultationspapier. Die Inhalte waren: Versäumnisse von Entwicklern und Unternehmen, die Frage möglicher staatlicher Interventionen sowie der Führungsrolle der USA und generell die Schwächen des zum Routing eingesetzten Border Gateway Protocol (BGP). Würde eine Mandatierung lange eingeführter Sicherheitsfeatures Sinn ergeben? Ein Blick zurück in die Geschichte von RPKI und BGPsec und ein paar Ideen für "next steps".

BGP wird überleben

Im Licht der Eskalation des russischen Vorgehens in der Ukraine habe die Kommission die Kommunikationsbranche aufgefordert, sich gegen Cyberangriffe zu wappnen [1], schrieb die FCC am 28. Februar. Mit der Anhörung wolle man jetzt in Erfahrung bringen, wie schlimm es um das BGP steht und was die Kommission durch Regulierung oder anderweitig tun könnte, um die Löcher zu stopfen beziehungsweise "BGP-Hijacking zu verhindern oder sicheres Routing voranzubringen."

Der Forscher Steve Bellovin von der Columbia University konnte einen Riesenseufzer nicht zurückhalten und twitterte: "Wie lange hat die Network Security Community davor schon gewarnt?" Seit es das BGP gibt, schallte es ihm aus dem Netz entgegen, und auch der Hinweis auf eine Senatsanhörung von L0PHT Heavy Industries aus dem Jahr 1998 [2] fehlte nicht. Das legendäre Hackerkollektiv erklärte damals den erstaunten Senatoren, dass es innerhalb einer halben Stunde das Internet lahmlegen könnte.

"Missing Link"

Was fehlt: In der rapiden Technikwelt häufig die Zeit, die vielen News und Hintergründe neu zu sortieren. Am Wochenende wollen wir sie uns nehmen, die Seitenwege abseits des Aktuellen verfolgen, andere Blickwinkel probieren und Zwischentöne hörbar machen.

• Mehr zum Feuilleton "Missing Link" [3]

Routen-Leaks und andere Gemeinheiten

Bellovin hatte 1989 in einem Paper etliche Schwachstellen im BGP-Vorläufer EGP (Exterior Gateway Protocol) hingewiesen. Im selben Jahr wurde BGP als RFC 1105 standardisiert. Das Protokoll spezifiziert den Austausch von Informationen zwischen Routern, auf deren Basis sie die beste Route für die zwischen ihren Netzen – den Autonomen Systemen (AS) – übermittelten Datenpakete identifizieren können. In Routing-Tabellen halten die Border-Router die besten Pfade fest.

Von Anfang an wiesen Experten wie Bellovin darauf hin, dass Verkehr im Netz leicht umgeleitet werden konnte, sodass Angreifer den Datenverkehr sehen, verändern oder einfach verschwinden lassen könnten. Beim sogenannten Präfix-Hijacking gibt ein Angreifer die Präfixe seiner Opfer als eigene aus. Beispielsweise kann das angreifende Netz spezifischere Adressen aus dem Netz des Opfers ankündigen oder behaupten, eine Abkürzung zu bestimmten IP-Adressblöcken zu bieten.

Noch häufiger als gezielte Angriffe sind schlichte Fehler, durch die falsche Routen im Netz propagiert werden. Das vielleicht bekannteste Beispiel dafür ist die Umleitung von YouTube-Verkehr zur Pakistan Telecom [4].

Zahlreiche neue Fälle von Routen-Leaks und Präfix-Hijacking hat das Bundesamt für Sicherheit in der Informationstechnik (BSI) in seiner zweiten Internet-Backbone-Studie [5] dargestellt. Die Leaks treffen, wie die Übersicht zeigt, große Tier-1- und Contentplattformen oder IXPs (Internet Exchange Points) gleichermaßen. Bei den acht dokumentieren Fällen großer Routen-Hijacking-Vorfälle gibt es drei mit russischer Beteiligung.

Zweimal Zeitenwende: Erst 9/11, dann Ukrainekrieg

Als Zeitenwende gilt der Ukrainekrieg – und der Anhörungstext der FCC legt nahe, dass es eine solche auch für das Thema Routing-Sicherheit geben könnte. Beobachter in den USA und auch in Deutschland schütteln den Kopf, warnen gar vor Kurzschlussreaktionen, wie der APNIC-Chefwissenschaftler Geoff Huston in seiner vor wenigen Tagen veröffentlichten Stellungnahme. Er ermutige die FCC, schreibt Huston unmissverständlich, den aktuellen Rufen nach sofortigen Lösungen zu widerstehen und anzuerkennen, dass Routing Security ein komplexes Thema ist, das Zeit und Anstrengungen erfordert.

Huston gehörte zum Kreis derer, die vor knapp 20 Jahren an den Standards zur Verbesserung der Sicherheit im Routing-System mitgearbeitet haben. Er war unter anderem Vorsitzender der Secure Inter-Domain Routing (SIDR), die die kryptographische Absicherung des Routing-Systems in zwei Basis Standard Suits für die Routing-Security goss, Routing PKI und BGPsec.

Die Arbeiten waren Ergebnis einer anderen Zeitenwende vor 21 Jahren, sagte Rüdiger Volk im Interview über die Internet-Grundlagen [6]. Nachdem Anschlag vom 11. September "haben US-Behörden im großen Stil die Arbeiten an der kryptographischen Absicherung des Routing System gesponsort", erinnert er sich.

Erste Arbeiten hatten Vertreter des Unternehmens Bolt Beranek and Newmann (BBN) bereits vor der Jahrtausendwende in Angriff genommen. Am Rande eines Treffens der North American Network Operator Group (NANOG) 2002 in Eugene habe BBN Entwickler Steve Kent einer Handvoll von Operatoren eine erste Implementierung von dem "zum Spielen" gegeben, was in den Folgejahren zu BGPsec und RPKI wurde. Er habe sich damals im Raum umgesehen, sagt Volk. "Es waren außer mir keine Europäer mit von der Partie."

Reine US-Angelegenheit

Auch das Sponsoring für die Entwicklung der einschlägigen Standards war eine reine US-Angelegenheit. Geld für Secure Routing kam etwa vom neu geschaffenen Department of Homeland Security, das sich zusammen mit dem National Institutes of Standard and Technology (NIST) des Themas Routing Security [7] annahm.

Die Finanzierung aus US-Töpfen erlaubte einer Gruppe von Security-Experten, Router-Herstellern, Netzbetreibern und Wissenschaftlern, die Standardisierung in der Internet Engineering Task Force rasch voranzutreiben. Aber der warme Regen durch die Finanzierung der Entwicklungs- und auch Implementierungsarbeit durch die US-Behörden hatte auch Nachteile, schreibt der Australier Huston jetzt rückblickend an die FCC. "Viele der inhärenten Schwächen im Design der aktuellen BGP Sicherheitsmechanismen sind auf den aggressiven Finanzierungsplan des Department of Homeland zurückzuführen, das Mitte des ersten Jahrzehnts der 2000er die Entwicklung von BGPsec förderte", schreibt Huston.

Randy Bush, kurze Zeit bei AT&T für das Thema zuständig, davor einer der Gründer von Verio (heute NTT/Verio) und heute Netzbetreiber und Entwickler für die Internet Initiative Japan, Japans ersten kommerziellen ISP, bestätigt diese Beobachtung. Es waren, erinnert sich der Autor vieler RFCs zu Routing-Security [8], andere Lösungen denkbar bei der Absicherung. Statt der Public Key Infrastruktur-Lösung X509 wäre auch ein weniger hierarchisches, dezentrales Web of Trust-Modell in Frage gekommen. Doch drückten Vertreter von BBN aufs Tempo und bezeichneten die Web of Trust-Lösung als noch zu Forschungs-intensiv. Er ist sich fast sicher, dass hier auch die Interessen von Geheimdienstseite eine Rolle gespielt haben.

Zentrale Root-Instanz? Danke, nein

Noch etwas hätte Bush – und viele andere [9] – ursprünglich gerne gesehen: eine klar hierarchische Struktur der Wurzelzertifikate, praktisch analog zur DNSSEC-Hierarchie, die bis hinauf zur Root reicht und durch diese Zusammenführung das Validieren einfacher macht. Doch diese Variante fanden einige Netzadministratoren und auch den RIRs nicht so gut, wären sie damit doch abhängig geworden von dieser zentralen Wurzelinstanz. Die logische Stelle dafür wäre die Internet Assigned Numbers Authority (IANA) gewesen, denn von ihr werden große IP-Adressblöcke an die RIRs nach unten gereicht.

Zu groß war da gerade in Europa die Sorge, dass durch mögliche legalistische oder juristische Interventionen in den USA Zertifikate für ungültig erklärt werden könnten. Schon die Gefahr von Eingriffen niederländischer Strafverfolger und Gerichte bekam das RIPE NCC, der operative Arm des RIPE, vor einigen Jahren zu spüren. Wird wirklich überall signiert und validiert, kann sich das Ungültigmachen eines Zertifikats dramatisch für den betroffenen Operator auswirken. Plötzlich wären Sanktionen gegen russische Provider – wenn auch in unvollständiger Form – doch denkbar.

RPKI ist einsatzbereit

Bush war ab 2000 in die Vorarbeiten für RPKI und BGPsec involviert, die beiden Programme, mit denen das ungesicherte, alte BGP nachgerüstet werden soll, und sorgte mit dafür, dass auch Routerhersteller und Operator mit von der Partie waren. In monatlichen Treffen wurden die beiden Standardideen entwickelt und ab 2005 in der IETF in RFCs übernommen.

Resource Public Key Infrastructure (RPKI) ist das Rückgrat für die schrittweise Absicherung von AS-Nummern und Routing-Präfixen. Im ersten Schritt wurde die Infrastruktur genutzt, um Route Origin Authorisations (ROA) zu erstellen, also mit klassischer PKI-Kryptografie zu hinterlegen, für welche IP-Präfixe ein Autonomous System, ein Netz, verantwortlich ist. Damit sollen in erster Linie die häufig vorkommenden Fehler beim Announcement von Routen verhindert werden. Begrenzt hilft diese Maßnahme auch gegen solche "Hijacking-Aktionen", die nicht als böswillige Aktionen geplant sind. Versehentliche Routen-Leaks lassen sich durch die Validierung von ROAs gut in den Griff bekommen, bestätigt Bush. Er spricht von RPKI als einem "Uuups-Feature".

Der Vergleich zweier "versehentlicher" Angriffe auf Twitter illustriert die Schutzwirkung. Noch im Februar 2021 hatte Twitter keine ROAs hinterlegt, daher sorgte eine Zensuraktion der Militärregierung von Myanmar für einen längeren Ausfall des Dienstes. "Als die russische RTCom vor ein paar Wochen die IP-Adressen von Twitter aus ihrem Netzwerk ankündigte, kam das nicht weit im Netz. Die Validierung von Routen funktioniert", sagt Bush.

Die versehentlichen Routen-Leaks

"Langsam, aber sicher verbreitet sich RPKI", ist Bushs Antwort auf die aus seiner Sicht leicht alarmistisch wirkende Notiz der FCC. Tatsächlich hat es immerhin ein Jahrzehnt seit Verabschiedung des ersten von mittlerweile 40 RFCs zur Signierung und Validierung von Adressraum-Inhaberschaft [10] gedauert.

Aber für 2020 notiert der niederländische Routing System Experte Job Snijders den globalen Start von RPKI Origin Validierung bei Telia, NTT, LINX, Telstra, HK-IX, GTT, Cogent, Amazon und vielen anderen. Auch das BSI konstatiert in seiner Studie: "Mit zunehmender Verbreitung der Resource Public Key Infrastructure (RPKI), durch die die Gültigkeit von Routen-Updates kryptografisch verifiziert werden kann, wird sich dem Problem von Route Leaks perspektivisch besser begegnen lassen."

Im Vergleich der regionalen Adressverwalter, bei denen die Zertifikate hinterlegt werden, präsentiert sich die RIPE Region – das sind Europa und der Nahe Osten – mit fast hundert Prozent signierten Adressbereiche [11] ziemlich gut. Die Zahlen des NIST-Monitoring-Dienstes verraten aber auch, dass weltweit erst rund 63 Prozent der Präfixe signiert sind. Wie zäh der Fortschritt bleibt, wird auch dadurch illustriert, dass auch die Implementierungen der Großen in Deutschland wie der DTAG, für die Volk bis zu seiner Pensionierung RPKI umgesetzt hat, alles andere als perfekt sind. Ein Testtool von Cloudflare [12] legt jedenfalls nahe, dass man bei der Validierung von Routen noch großzügig über als invalide gemeldete hinwegsieht.

Nächster Schritt Pfadvalidierung

Ist man bei RPKI und der Signierung und Validierung von Präfixen und darauf aufbauenden Filterung von Routen vorangekommen, ist der zweite Satz an Standards, das BGPsec-Protokoll, Zukunftsmusik. Fünf Jahre später in die Standardisierung gebracht, ist BGPsec seit 2017 in RFC8204 spezifiziert [13]. Es sichert die Routing-Informationen auf dem Weg durch das Netz ab.

Statt allein die Authentizität des Ursprungs einer Routenankündigung zu prüfen, soll so sichergestellt werden, dass entlang des Pfades keine Manipulationen passieren. Erst damit lassen sich letztlich bösartige Präfix-Entführungen verhindern, zumindest, wie die Perfektionisten Bush und Volk sagen, einigermaßen.

Doch BGPsec ist auf aktueller Router-Hardware noch nicht zu bewerkstelligen und fordert den Netzbetreibern einen erheblichen Mehraufwand für die vielen Schlüssel ab, die für jeden Hop notwendig sind. Seit seiner Spezifikation habe das an sich nützliche Protokoll "keine relevante Verbreitung erfahren", teilt die BSI-Sprecherin mit und fügt an: "Es ist weiterhin von einer zögerlichen Adaption auszugehen. Daher begrüßt das BSI die Abfrage der FCC, um Hemmnisse für den Einsatz von BGPsec zu identifizieren."

Kommt BGPsec 2026?

Snijders, der vor kurzem zum CDN-Anbieter Fastly gewechselt hat, ist optimistisch und dabei, eine Machbarkeitsstudie für den Einsatz der Pfadvalidierung auf die Beine zu stellen. Aktuell sei er erst einmal dabei, Interessierte zusammenzutrommeln. Die Gruppe soll dann erkunden, welche Veränderungen es an aktueller Router-Hardware noch braucht, welche Softwareprojekte noch zu finanzieren sind, was das kosten soll und wo etwaige Geldgeber gefunden werden können.

"Ich halte 2026 für machbar!" schreibt er auf eine Anfrage. Die Roadmap für die Machbarkeitsstudie sieht vor, dass man sich noch zwei Jahre gibt, um die für Feldtests notwendigen Bausteine zu schaffen. Nach einem Jahr Erprobung und Monitoring hätte man dann immer noch ein Jahr bis zum möglichen kommerziellen Ausrollen.

"Natürlich bin ich ein Optimist", schreibt Snijders, "wenn man auf einen hohen Berg klettern will, braucht man positives Denken!" Mit dem Zieldatum 2026 wolle die kleine Gruppe, die sich bislang zusammengefunden habe, zum Ausdruck bringen, dass es durchaus noch ein paar Jahre dauere, aber dass man das Ganze durchaus noch zu "Lebzeiten" abschließen könne.

Dass sich etwas bewegt, beobachtet auch Thomas King, Chief Technology Officer des DE-CIX, eines der international größten Internet-Knoten. "BGPsec-Implementierungen kommen jetzt gerade in den Betriebssystemen der Router an, sodass man sie auch nutzen kann", sagt er. Das zeigten die Featurelisten und Roadmaps der Routerhersteller. Bei den ganz großen Routern sei überdies auch heute schon Hardware integriert, die die notwendigen Cryptooperationen übernehmen könne. Für normale Router gilt dies aber noch nicht und Updates mit Cryptoprozessoren für fünf Jahre alter Router seien nicht wahrscheinlich.

Wie bei RPKI werde der Umstieg auf entsprechend ausgerüstete Router und das Einpreisen des Aufwandes, der für das Ausrollen und Aktualisieren von Schlüsseln notwendig sei, ganz ein Problem für mittlere und kleinere Betreiber. Setzen die großen Provider die Sicherheitsmaßnahmen um, sei man aber schon ein Stück weiter, schätzt er. Kleinere Netze verlassen sich in vielen Fällen ohnehin auf ihren Upstream-Provider. Anders als bei RPKI leidet die Pfadabsicherung freilich dann, wenn auf dem Weg liegende Systeme nicht mitmachen.

Geschäftsmodelle statt weiterer Bausteine

King ist überzeugt, dass die Zukunft des sicheren Routing nicht an der Technik scheitern wird. Natürlich könne man viele Dinge noch schöner, noch runder, noch schneller machen. Eine aktuelle Idee, die etwa Bush sehr befürwortet, ist eine Umstellung der Felder in der BGPsec-Signatur, um das Protokoll um den Faktor fünf zu beschleunigen [14]. Auch an einem Mechanismus zur Autorisierung des AS-Betreibers und an Ideen zum RPKI-Transport wird noch gearbeitet.

Woran es für die Umsetzung der neuen Mechanismen aber noch mehr fehlt, meint King, sei das Geschäftsmodell. RPKI rechne sich inzwischen ganz offensichtlich, zumindest für die großen Provider. "Die vielen Leaks, die wir praktisch täglich sehen, waren einfach nicht mehr tragbar." An dieser Stelle müsse man auch damit rechnen, dass Regulierer irgendwann sagen: "Der Sicherheitsgurt ist da, jetzt würden wir ihn auch gerne sehen", schätzt er.

Anders als für RPKI fällt die Kosten-Nutzen-Rechnung derzeit dagegen nicht nur für BGPsec aus, sondern bei Ideen, die auch die IP-Datenverkehre durch die Netze per Source Address Validation absichern wollen. Eine ganze Phalanx neuer Vorschläge chinesischer Hersteller und Universitäten legten diese Mitte März bei der IETF auf den Tisch. Dabei gibt es bereits eine ganze Reihe von RFCs aus den Arbeiten, der ebenfalls chinesisch dominierten SAVI-Arbeitsgruppe.

Die Vorschläge sehen zwar nicht schlecht aus, meint King, doch schlage gerade bei der Source Validation die Frage nach dem Geschäftsmodell voll zu. "Die Ressourcen aller Infrastrukturprovider sind begrenzt", sagt er, "ich muss mich also fragen, wofür setze ich sie ein." Mit der Source Address Validation mache man in erster Linie die Netze der anderen sicherer. "Mache ich das, um Dein Netz sicherer zu machen oder versuche ich mir einen Wettbewerbsvorteil zu verschaffen, damit es mich morgen als Provider noch gibt?", laute die Frage.

Das von der ISOC in Leben gerufene Projekt MANRS ist ein Versuch, den Providern, die RPKI und auch klassisches Egress-Filtering aus ihren Netzen einsetzen und damit verhindern, dass bösartiger oder falsch betitelter Verkehr ihre Netze verlässt, etwas auf die Haben-Seite zu schreiben. Wer sich an die Regeln der "Mutually Agreed Norms for Routing Security" hält, erhält das Prädikat "MANRS"-kompatibel [15]. Es geben Kunden, die etwa beim DE-CIX fragen, ob man das erfülle.

Allerdings ist schon der Einsatz von RPKI rein optional. Stattdessen könne auch auf der Basis der von den RIRs betriebenen, allerdings nicht fälschungssicheren Internet Routing Registry gefiltert werden. Das Instrument setzt auf Freiwilligkeit bei der Einführung der aufwändigeren Maßnahme.

Lange Wunschlisten – und bitte international agieren

Wird das angesichts der FCC Frage zu ihren Interventionsmöglichkeiten so bleiben? Etwa 40 Antworten hat die Behörde erhalten und die Einigkeit in einem Punkt ist groß. Eine Mandatierung von RPKI oder gar BGPsec macht insbesondere als rein nationale Maßnahme wenig Sinn, warnen die meisten.

Ein weiterer Punkt, in dem es große Überschneidungen gibt, ist die Aufforderung an die FCC, vor etwaigen regulatorischen Schritten eine klare Taxonomie der vorhandenen Technologien zu erstellen. Ein solcher Überblick über die verschiedenen Tools, ihrer Effekte und ihrer Beschränkungen fehle generell, sagt Volk. Auch hierzulande könnte man so etwas gut gebrauchen, findet er.

Eine Idee des Router-Herstellers Juniper lautet, die FCC solle sich um die internationale Vernetzung von für die Routing-Sicherheit zuständigen Organisationen und Behörden kümmern. "Hier könnte die FCC eine Führungsrolle übernehmen", wirbt Juniper, denn da gebe es ein Vakuum.

Snijders empfiehlt mit Blick auf Europa, dass die EU Geld und Expertise bereitstellt, um der Internet-Community dabei zu helfen, durch BSD-lizenzierte Software-Tools für mehr Sicherheit zu sorgen. "Die Absicherung des Routing-Systems ist eine gesellschaftliche Aufgabe." Auch bei der Aufklärung könnte die öffentliche Hand helfen und vielleicht einfach mal ein IETF-Meeting oder Gruppen sponsern, die quelloffene Standards wie RPKI und BGP-4, die aktuelle Version von BGP, implementieren.

Vielleicht doch ein neues, sicheres Routing-Protokoll?

Eine Alternative zum alten BGP offerieren Forscher von der ETH in Zürich der FCC. Professor Adrian Perrig, der das BGP-freie Routing Konzept "Scalability, Control and Isolation on Next Generation Networks" entwickelt hat, listet alle Schwierigkeiten mit BGP und BGPsec auf und nennt das noch nicht sehr weit verbreitete SCION die Lösung für alle Probleme. Geroutet wird bei SCION in den sogenannten Isolation Domains, zwischen diesen wird über eine Art Edge-Router die Verbindung zwischen den Inseln hergestellt. Für kleinere Gruppen wie die bisherigen Anwender, die Schweizer Banken, vielleicht keine schlechte Sache, urteilten kürzlich Teilnehmer der IETF, wo Perrig das Konzept in der Routing-Arbeitsgruppe vorstellte. Die Werbung damit, dass SCION durch die Isolation Domains kleinen Gruppen oder eben auch Ländern die Hoheit über Zertifikatserteilung und -entzug verschafft, könnte allerdings auch den Weg in souveräne, nationale Internet-Inseln weisen, sagt BGP-Experte Volk.

Eine Komplettmigration weg von BGP zu einem Nicht-BGP-gerouteten Internet ist ziemlich unwahrscheinlich, urteilt Bush. "Wer meint, das ginge, hat die Migration von IPv4 auf IPv6 vergessen." Solche Migrationen würden, gerade bei einem so großen Schritt, auch dadurch erschwert, dass sie praktisch dem Tausch von Maschinen einer 747 im Flug gleichen, meint Bush. Das sei schon heikel. BGP, da ist er sicher, wird überleben.

[Update 20.04.2022 16:20]:

Im Artikel wird nicht deutlich, dass RPKI die Infrastruktur für beides, Route Origin Validation (ROV) und BGPSec, ist. Die in den RPKI-Datenbanken der fünf Regional Internet Registries hinterlegten Route Origin Autorizations (ROAs) können im Rahmen der ROV automatisch von den Routern geprüft werden. Damit wird sichergestellt, dass nur der Inhaber der entsprechenden Präfixe und IP-Adressen diese seinen Routing-Partnern announciert. Die ROV ist es auch, die Randy Bush das "upps-Feature" nennt. Bush teilte außerdem mit, dass die Arbeiten der ersten Designgruppe bis ins Jahr 1999 zurückreichen. Die aktuellen Ideen für eine Umstrukturierung des BGPSec Headers [16] stammen von Ignas Bagdonas.

(tiw [17])

URL dieses Artikels:
https://www.heise.de/-6702206

Links in diesem Artikel:
[1] https://docs.fcc.gov/public/attachments/FCC-22-18A1.pdf
[2] https://www.youtube.com/watch?v=VVJldn_MmMY
[3] https://www.heise.de/thema/Missing-Link
[4] https://www.heise.de/news/Routing-Kleinkrieg-Ursache-fuer-YouTube-Ausfall-205345.html
[5] https://www.bsi.bund.de/DE/Service-Navi/Publikationen/Studien/ZwiBACK/zwiback-studie.html
[6] https://www.heise.de/hintergrund/Missing-Link-Abschied-vom-Herrn-der-Routen-dem-Internetpionier-der-Telekom-4980616.html
[7] https://www.nist.gov/programs-projects/robust-inter-domain-routing
[8] https://datatracker.ietf.org/person/randy@psg.com
[9] https://www.iab.org/documents/correspondence-reports-documents/2018-2/iab-statement-on-the-rpki/
[10] https://blog.apnic.net/2021/03/15/which-rpki-related-rfcs-should-you-read/
[11] https://rpki-monitor.antd.nist.gov/
[12] https://isbgpsafeyet.com/
[13] https://datatracker.ietf.org/doc/html/rfc8205
[14] https://datatracker.ietf.org/meeting/113/materials/slides-113-sidrops-sidrops-bgpsec-scalability-00
[15] https://www.manrs.org/
[16] https://datatracker.ietf.org/meeting/113/materials/slides-113-sidrops-sidrops-bgpsec-scalability-00
[17] mailto:tiw@heise.de

Copyright © 2022 Heise Medien