Zusammenfassung

  • Kotikalapudi Sriram ist als Mitautor von RFC 6472 und RFC 9774 sowie als Mitherausgeber von RFC 8205 ausgewiesen. Gemeinsam dokumentieren diese RFCs eine Entwicklung von der senderseitigen Empfehlung gegen AS_SET und AS_CONFED_SET zur verbindlichen Unterdrückung und zum Treat-as-withdraw-Verhalten, ergänzt durch einen BGPsec-Entwurf, der Pfadautorisierung an ausgehandelte Fähigkeiten, eindeutige AS-Nummern, RPKI-Routerzertifikate und aktuelle Validierungsdaten bindet.
  • Die Standards schaffen präzisere und überprüfbarere Zustände, garantieren aber weder Einführung noch fehlerfreie Implementierung, Datenpfadtreue oder ein bestimmtes Routingergebnis. Gültigkeit hängt vom aktuellen RPKI-Zustand ab, Teilbereitstellung begrenzt die kryptografische Aussage, lokale Policy bestimmt die Routenauswahl, und der beobachtete Netzbetrieb bleibt die entscheidende Realitätsebene.

Analyse

Ein belegter Beitrag zu kollaborativen Standards

Die personengebundene Grundlage dieser Analyse ist eng und überprüfbar. RFC 6472, im Dezember 2011 als Best Current Practice 172 veröffentlicht, nennt Warren Kumari und K. Sriram als Mitautoren. RFC 8205, im September 2017 auf dem Standards Track veröffentlicht, nennt Matt Lepinski und K. Sriram als Mitherausgeber der BGPsec-Protokollspezifikation. RFC 9774, im Mai 2025 auf dem Standards Track veröffentlicht, führt Sriram zusammen mit Warren Kumari, Lilia Hannachi und Jeffrey Haas im Autorenkreis.

Diese Rollen erlauben es, Srirams öffentlich dokumentierten Anteil an einer Entwicklung von Routingregeln zu betrachten. Sie erlauben nicht, ihm die RFCs, BGPsec, RPKI oder die Entscheidungen realer Netze allein zuzuschreiben. Ein RFC ist Ergebnis eines IETF-Prozesses mit mehreren Autoren oder Herausgebern, Arbeitsgruppenbeiträgen, öffentlicher Prüfung und IETF-Konsens. Die normativen Anforderungen gehören dem veröffentlichten Dokument. Implementierungen gehören ihren Entwicklern, Konfigurationen ihren Betreibern und beobachtete Resultate den jeweiligen Netzen.

Die drei Quellen sind auch keine allgemeine Biografie. Sie belegen weder eine heutige Beschäftigung noch persönliche Einsätze in bestimmten Netzen, Kundenergebnisse, Störfälle oder gemessene Sicherheitsgewinne. Der belastbare Gegenstand ist technischer: Sriram ist an Dokumenten beteiligt, die ungeordnete AS-Pfadangaben, kryptografisch geschützte Pfadinformationen und deren operative Grenzen genauer fassen. Gerade diese Begrenzung macht die Personenzuordnung seriös. Sie würdigt dokumentierte Mitarbeit, ohne kollektive Standardisierung in eine Erfindergeschichte umzuschreiben.

Warum ungeordnete AS-Mengen die Aussage eines Pfads verwischen

AS_SET und AS_CONFED_SET entstehen im Zusammenhang mit Routenaggregation. Ein Router fasst mehrere spezifischere Routen zu einer weniger spezifischen Route zusammen. Ein AS_SET kann dabei die autonomen Systeme enthalten, welche die beitragenden Routen durchlaufen haben, allerdings als ungeordnete Menge. AS_CONFED_SET erfüllt eine ähnliche Funktion für Mitglieds-AS innerhalb einer Konföderation. Die Menge bewahrt damit einen Teil der Beteiligungsinformation, verliert aber die Reihenfolge, die für eine eindeutige Pfadinterpretation wesentlich sein kann.

RFC 6472 beschreibt die daraus entstehende Unschärfe. Wenn mehrere Routen zu einem Aggregat werden, ist nicht mehr ohne Weiteres klar, was es bedeutet, dieses Aggregat zu originieren. Für Sicherheitsmechanismen, die IP-Präfixe und AS-Nummern in Zertifikaten oder Autorisierungsobjekten miteinander verbinden, ist das kein rein ästhetisches Problem. Eine mehrdeutige Herkunft kann verhindern, dass ein Ursprung für das aggregierte Präfix eindeutig authentifiziert wird. Auch für Traffic Engineering geht Information verloren, weil die genauen Pfade der beitragenden Präfixe nicht erhalten bleiben.

Das Dokument führt historische Routingdaten als Grundlage für die Feststellung an, dass AS_SET-Aggregation im öffentlichen Internet selten und häufig fehlerhaft verwendet worden sei. Diese Aussage ist eine im RFC dokumentierte Auswertung, keine in diesem Artikel neu erhobene Messung. Die daraus gezogene Standardisierungslogik ist dennoch klar: Wenn ein selten genutzter Mechanismus zusätzliche Protokollkomplexität erzeugt, seine praktische Tabellenersparnis gering ist und er neue Sicherheitsverfahren behindert, steigt der Rechtfertigungsdruck für seine weitere Verwendung.

Der relevante Maßstab ist nicht, ob ein Feld formal existiert, sondern ob sein Nutzen die Mehrdeutigkeit und den laufenden Implementierungsaufwand trägt.

RFC 6472 setzt 2011 zunächst eine senderseitige Grenze

RFC 6472 wählt bewusst den Weg einer Empfehlung. Betreiber sollen keine neuen Ankündigungen mit AS_SET oder AS_CONFED_SET erzeugen. Bereits angekündigte Routen sollen zurückgezogen und die beitragenden spezifischeren Präfixe ohne AS_SET erneut angekündigt werden. Das bedeutet, eine zuvor mit solchen Mengen vorgenommene Aggregation rückgängig zu machen. Zugleich warnt das Dokument, dass ein Betreiber vor jeder Änderung die vollständigen Auswirkungen verstehen muss. Die Empfehlung ist daher keine Aufforderung zu einer unvorbereiteten Massenänderung.

Wichtig ist die damalige Geltungsgrenze. Der Schwerpunkt liegt auf dem Sender. RFC 6472 beobachtet zwar, dass Sicherheitsverfahren oder künftige Implementierungen Routen mit AS_SET möglicherweise als nicht verwendbar behandeln und dass Betreiber solche Routen filtern könnten. Es schreibt für den Empfang aber noch kein allgemeines Verhalten vor. Diese Trennung verhindert, eine Best Current Practice aus dem Jahr 2011 nachträglich als vollständige Sende- und Empfangsspezifikation zu lesen.

Auch die Sicherheitsbegründung bleibt präzise. Das Dokument erwartet, dass spätere Arbeiten selten ausgeübte Komplexität und zugehörigen Code entfernen könnten. Weniger kaum genutzter Code kann die Angriffsfläche verkleinern und RPKI-basierte Systeme vereinfachen. Das ist eine Entwurfsrichtung, kein Nachweis, dass jede Implementierung den Code tatsächlich entfernt hat oder dass ein Netz dadurch bereits sicherer wurde. Eine Empfehlung verändert zunächst den normativen Bezugspunkt. Erst Implementierung, Konfiguration und beobachtetes Verhalten zeigen, ob sich der gewünschte Zustand im Betrieb durchsetzt.

BGPsec bindet Pfadautorisierung an explizite Ressourcen

RFC 8205 behandelt eine zweite, eigenständige Oberfläche. BGPsec definiert ein Verfahren, mit dem ein Empfänger kryptografische Sicherheit darüber erhalten kann, dass jedes im Pfad aufgeführte autonome System die Weitergabe einer Route an das jeweils folgende AS ausdrücklich autorisiert hat. Das geschieht über das optionale, nicht transitive Attribut BGPsec_PATH. Dieses enthält einen Secure_Path und Signaturblöcke. In einer BGPsec-UPDATE ersetzt es AS_PATH; beide Attribute dürfen nicht gleichzeitig enthalten sein.

Die Aussage entsteht nicht allein durch eine Signatur. BGPsec stützt sich auf die Resource Public Key Infrastructure. RPKI-Zertifikate bescheinigen die Zuordnung von AS-Nummern und IP-Adressressourcen. Ein BGPsec-Sprecher, der signierte Updates an externe Nachbarn senden will, benötigt einen privaten Schlüssel zu einem gültigen RPKI-Routerzertifikat, dessen AS-Ressource zur eigenen AS-Nummer passt. Für die Validierung empfangener BGPsec-Updates ist ein eigenes solches Zertifikat dagegen nicht zwingend. Der Validator braucht die gültigen Zuordnungen aus AS-Nummer, öffentlichem Schlüssel und Subject Key Identifier.

Damit wird die Registerfunktion konkret. AS-Nummern und Präfixe sind nicht bloße Etiketten, sondern Ressourcen, deren eindeutige Zuordnung, aktuelle Zertifikatslage und sicherer Metadatentransport die Protokollaussage erst ermöglichen. Ein Router kann eine mathematisch korrekte Signatur nur sinnvoll einordnen, wenn der zugehörige Schlüssel und die AS-Bindung in seiner aktuellen RPKI-Sicht gültig sind. Die RPKI führt jedoch nicht selbst die Routingentscheidung aus. Sie liefert überprüfbare Datensätze, auf deren Grundlage laufender Code eine Validierung vornimmt und lokale Policy anschließend handeln kann.

Aushandlung macht Unterstützung zu einem gerichteten Vertrag

BGPsec-Unterstützung wird nicht aus einem Produktnamen oder einer globalen Aktivierungsbehauptung abgeleitet. RFC 8205 definiert eine BGP-Fähigkeit, die Richtung, Version und Address Family Identifier trägt. Ein Sprecher kann mitteilen, dass er BGPsec-Updates für eine bestimmte Adressfamilie senden oder empfangen kann. Für beide Richtungen sind zwei entsprechende Fähigkeitsangaben nötig. IPv4 und IPv6 werden ebenfalls getrennt angekündigt. Unterstützung ist damit eine konkrete Eigenschaft einer Sitzung und einer Adressfamilie, nicht ein pauschales Merkmal des gesamten Netzes.

Eine BGPsec_PATH-Nachricht darf nur gesendet werden, wenn der Sender seine Sendefähigkeit und der Empfänger die passende Empfangsfähigkeit für dieselbe Version und Adressfamilie angekündigt haben. Zusätzlich muss für dieselbe Adressfamilie die Multiprotocol-Erweiterung ausgehandelt sein. Wer BGPsec ankündigt, muss auch die Fähigkeit für 4-Byte-AS-Nummern ankündigen. Fehlt eine dieser Voraussetzungen, gilt BGPsec als nicht erfolgreich ausgehandelt, und Updates mit BGPsec_PATH dürfen in dieser Sitzung nicht gesendet werden.

Das Scheitern der Aushandlung bedeutet nicht automatisch, dass die BGP-Sitzung ausfällt. Die Partner können weiterhin unsignierte traditionelle Updates austauschen. RFC 8205 empfiehlt, den Fehlschlag zu protokollieren, und verlangt, dass eine Implementierung den Aufbau einer Sitzung verhindern kann, wenn sie ausdrücklich auf ausschließliche BGPsec-Nutzung konfiguriert wurde. Hier liegt eine wichtige operative Wahl: Kompatibilität kann Konnektivität erhalten, aber die erwartete Pfadautorisierung verlieren. Strikte Konfiguration kann die Sicherheitsanforderung bewahren, aber die Sitzung verhindern.

Der Standard macht diese Alternative sichtbar; er entscheidet sie nicht für jeden Betreiber.

Signaturen schützen einen genau begrenzten Weitergabeschritt

Die Konstruktion des BGPsec_PATH zeigt, wie fein die Aussage gebunden ist. Die Signatur schützt unter anderem das Präfix, die Pfadsegmente und das Ziel-AS des nächsten Nachbarn. Deshalb muss ein Sprecher für jedes eindeutige Peer-AS eine eigene BGPsec-UPDATE erzeugen. Eine solche UPDATE darf zudem nur eine Route zu einem Präfix ankündigen. Mehrere Präfixe brauchen getrennte Nachrichten. Diese Regeln verhindern, dass eine für einen bestimmten Empfänger und ein bestimmtes Präfix erzeugte Autorisierung unbemerkt auf einen anderen Kontext übertragen wird.

Beim Weiterleiten an einen externen BGPsec-Nachbarn fügt der Sprecher sein Secure_Path-Segment und eine passende Signatur hinzu. Die AS-Nummer in diesem Segment muss zu der AS-Nummer im RPKI-Routerzertifikat passen, mit dessen öffentlichem Schlüssel die Signatur geprüft wird. BGPsec macht damit eine Kette gerichteter Weitergabeentscheidungen überprüfbar. Jeder Schritt sagt sinngemäß, dass ein Sprecher die empfangene Routenankündigung mit den angegebenen Merkmalen an das bezeichnete nächste AS weitergeben wollte.

Diese Signatur ist jedoch keine Bestätigung, dass alle früheren Signaturen gültig sind. RFC 8205 hält ausdrücklich fest, dass das Signieren einer ausgehenden Nachricht nicht die Validität der gesamten empfangenen Kette attestiert. Ein Sprecher kann je nach lokaler Policy sogar eine als nicht gültig bewertete Route auswählen und mit dem vorhandenen Status weitergeben. Das Beibehalten der Signaturinformationen ermöglicht nachgelagerten Systemen eine eigene Bewertung aus ihrer Sicht. Die Beweiskette soll Zustand erhalten, nicht durch die Entscheidung eines Zwischenknotens künstlich bereinigt werden.

Routenursprung und Pfad sind zwei verschiedene Prüfungen

BGPsec ist als Ergänzung zur Ursprungsvalidierung angelegt. Eine Route Origin Authorization verbindet ein Präfix mit einem AS, das es originieren darf. RFC 8205 empfiehlt, eine signierte BGPsec-Route für ein Präfix nur dann zu originieren, wenn eine gültige ROA das eigene AS dazu autorisiert. BGPsec_PATH schützt anschließend die autorisierten Weitergabeschritte entlang der AS-Folge. Die Frage „Darf dieses AS das Präfix originieren?“ und die Frage „Hat jedes AS diese Ankündigung an den nächsten Pfadteilnehmer weitergegeben?“ bleiben also getrennt, auch wenn sie zusammen eine stärkere Aussage ergeben.

Diese Trennung ist für den Betrieb entscheidend. Ein gültiger Ursprung macht noch keinen gültigen kryptografischen Pfad. Ein korrekt validierter BGPsec_PATH ersetzt nicht die Prüfung des Ursprungs. Und selbst die Kombination beider Ergebnisse entscheidet die Route nicht automatisch. RFC 8205 erwartet, dass der Validierungsstatus in die BGP-Pfadauswahl einfließen kann, überlässt die Behandlung aber der lokalen Policy. Betreiber können den Status pro Sitzung unterschiedlich gewichten. Damit bleibt der Kontrollpunkt dort, wo auch andere Routingziele, Risikogrenzen und Verfügbarkeitsanforderungen zusammenlaufen.

Der Standard verspricht außerdem nicht, dass Datenpakete dem im BGPsec_PATH ausgewiesenen Pfad folgen. Die kryptografische Garantie betrifft den Weg der BGP-UPDATE durch die angegebenen autonomen Systeme. Datenebenen, Tunnel, interne Weiterleitung, Abweichungen nach der Pfadauswahl oder andere operative Zustände werden dadurch nicht automatisch bewiesen. Diese Grenze schützt vor einer verbreiteten Fehlinterpretation: Kontrollpfadautorisierung ist wertvoll, aber sie ist keine Ende-zu-Ende-Messung der tatsächlichen Paketweiterleitung.

Validität ist ein Ergebnis der aktuellen RPKI-Sicht

Ein BGPsec-Validator prüft zunächst Syntax und Protokollbedingungen, bevor er teure kryptografische Prüfungen ausführt. Unter anderem müssen Anzahl und Zuordnung von Secure_Path- und Signatursegmenten stimmen, das zuletzt hinzugefügte AS zum externen Nachbarn passen, AS_PATH darf nicht zusätzlich vorhanden sein, Konföderationskennzeichen müssen zum Kontext passen, und eine unerwartete Verwendung von pCount gleich null ist ein Fehler. Bei syntaktischen oder protokollbezogenen Fehlern verlangt RFC 8205 Treat-as-withdraw.

Für die Signaturprüfung sucht der Validator in gültigen RPKI-Routerzertifikatsdaten nach der passenden Kombination aus AS-Nummer, öffentlichem Schlüssel und Subject Key Identifier. Fehlt diese Verbindung, kann der betreffende Signaturblock nicht als gültig bewertet werden. Entscheidend ist das Wort „gültig“ im zeitlichen Sinn. Zertifikate können ablaufen oder widerrufen werden; Caches können unterschiedliche Aktualitätsstände haben. Ändert sich der RPKI-Zustand, müssen betroffene gespeicherte Updates neu validiert werden. Ändert sich dadurch deren Status, kann lokale Policy eine erneute Best-Path-Auswahl erforderlich machen.

Validität ist deshalb kein dauerhaftes Etikett, das einmal auf eine Route geklebt wird. Sie ist das reproduzierbare Ergebnis aus Nachricht, Algorithmus, Zertifikatsdaten und Zeitpunkt. Zwei AS können vorübergehend unterschiedliche Ergebnisse sehen, wenn ihre RPKI-Sichten nicht denselben Stand haben. RFC 8205 bewahrt aus diesem Grund auch nicht gültige Signaturinformationen, anstatt sie vorschnell zu entfernen. Ein nachgelagerter Validator soll seine eigene, möglicherweise aktuellere Sicht anwenden können. Genauigkeit verlangt nicht nur korrekte Einträge, sondern auch nachvollziehbare Aktualisierung und erneute Auswertung.

Die erneute Validierung verbindet damit Registeränderung und Routingzustand, ohne beide gleichzusetzen. Wird ein Zertifikat ungültig oder steht eine zuvor fehlende Schlüsselbindung zur Verfügung, ändert sich zunächst das Ergebnis der kryptografischen Prüfung. Erst die lokale Policy bestimmt, ob daraus eine neue Pfadauswahl folgt. Für eine spätere Rekonstruktion müssen daher mindestens die empfangene Nachricht, der damals verwendete Zertifikatsstand, das Validierungsergebnis und die nachfolgende Policyentscheidung unterscheidbar bleiben.

Sonst lässt sich ein Wechsel der Route fälschlich dem Protokoll zuschreiben, obwohl die auslösende Änderung in den Sicherheitsmetadaten oder in der lokalen Behandlung lag.

Umgekehrt darf das Aufbewahren einer nicht gültig bewerteten Signaturkette nicht als Anerkennung dieser Kette gelesen werden. Es erhält den prüfbaren Eingabestatus für einen nachgelagerten Teilnehmer, dessen Datenstand oder unterstützte Algorithmussuite abweichen kann. Diese Form der Zustandserhaltung ist operativ wertvoll, gerade weil sie kein zentrales Urteil erzwingt. Jeder Validator wendet die definierten Prüfschritte auf seine aktuelle, gültige Sicht an, und jede Routenauswahl bleibt als lokale Entscheidung kenntlich.

Die gemeinsame Spezifikation schafft vergleichbare Prüfbedingungen; sie beseitigt weder Zeitunterschiede zwischen Caches noch die Verantwortung der Betreiber für ihre Policy.

Laufzeitlast darf den Validierungszustand nicht unsichtbar machen

Unter außergewöhnlicher Last darf eine Implementierung die Validierung eingehender BGPsec-Updates vorübergehend aufschieben. Die Behandlung solcher Nachrichten bleibt lokale Policy. RFC 8205 verlangt jedoch eine operative Sichtbarkeit des Aufschubs und des Zustands der betroffenen Nachrichten. Damit wird ein wichtiger Unterschied festgehalten: „noch nicht validiert“ ist nicht dasselbe wie „gültig“ oder „nicht gültig“. Wenn ein System diese Zustände zusammenfasst, verliert der Betreiber die Grundlage für eine belastbare Entscheidung.

Auch die Reihenfolge der Prüfungen ist eine Betriebsentscheidung mit Sicherheitswirkung. Billigere Syntax- und Strukturprüfungen sollten vor aufwendigen Signaturprüfungen erfolgen. Bei langen, offensichtlich ungültigen Signaturketten soll die Verifikation früh abbrechen können. Ein System kann außerdem vermeiden, kryptografische Arbeit für eine Route zu leisten, die aus anderen Gründen ohnehin nicht als bester Pfad infrage kommt. Solche Optimierungen verändern nicht die geforderte sichtbare Ein- und Ausgabe des Validierungsverfahrens.

Sie zeigen vielmehr, dass Sicherheitsmechanismen selbst Ressourcen verbrauchen und gegen Überlastungsangriffe entworfen werden müssen.

Ein belastbarer Betrieb braucht daher mehr als einen Zähler „BGPsec aktiv“. Er braucht die Anzahl ausgehandelter Sitzungen je Adressfamilie, fehlgeschlagene Aushandlungen, aufgeschobene Validierungen, Alter und Synchronisationsstatus der RPKI-Daten, Veränderungen von Validierungszuständen und die lokale Behandlung dieser Zustände. Erst diese Aufzeichnungen verbinden die Spezifikation mit dem Verhalten des laufenden Systems. Ohne sie bleibt ein Konfigurationsversprechen von der tatsächlichen Kontrollwirkung getrennt.

Teilbereitstellung begrenzt die Reichweite der Aussage

RFC 8205 beschreibt BGPsec als schrittweise einführbares Verfahren. Anfangs können zusammenhängende Gruppen von AS signierte Pfade austauschen. Innerhalb einer solchen zusammenhängenden Region besteht die kryptografische Pfadaussage. Trifft die Route auf ein AS ohne BGPsec-Unterstützung, wird sie für diesen Übergang in eine traditionelle unsignierte BGP-UPDATE umgewandelt. Die bis dahin vorhandene Aussage reicht nicht über die Unterbrechung hinaus.

Diese Grenze verhindert zwei Übertreibungen. Eine einzelne aktivierte Sitzung macht nicht den gesamten Internetpfad kryptografisch geschützt. Umgekehrt ist der Schutz innerhalb eines zusammenhängenden unterstützenden Abschnitts nicht wertlos, nur weil ein späterer Abschnitt unsigniert bleibt. Die richtige Beschreibung muss angeben, welcher Teil der Kette validierbar ist, wo die Signaturen enden und welche Policy danach gilt. Ein binäres Etikett für ein ganzes Präfix würde diese Topologie der Gewissheit verdecken.

Auch Algorithmuswechsel erfordern parallele Zustände. RFC 8205 erlaubt während einer Übergangszeit mehrere Signaturblöcke für unterschiedliche Algorithmussuiten. Ein Update kann als gültig gelten, wenn mindestens ein unterstützter Block gültig ist. Das Entfernen eines aus lokaler Sicht nicht gültigen Blocks könnte jedoch nachgelagerten Systemen wichtige Information nehmen oder eine nicht gültige Nachricht in deren Sicht zu einer bloß unsignierten Nachricht machen. Kontinuität entsteht hier durch Erhalt unterscheidbarer Zustände, nicht durch kosmetische Vereinfachung.

pCount und Konföderationen zeigen die Grenzen lokaler Ausnahmekenntnis

Im Secure_Path beschreibt pCount üblicherweise die Pfadlänge, die ein Segment repräsentiert. Ein transparenter Route Server kann pCount gleich null verwenden, um am Kontrollpfad teilzunehmen, ohne als Transit-AS die sichtbare Pfadlänge zu erhöhen. Auch Konföderationen und AS-Migrationen kennen begrenzte Anwendungsfälle. Diese Ausnahme muss jedoch konfiguriert und gegenüber dem direkten Nachbarn erwartet werden. Kommt pCount gleich null von einem Peer, für den es nicht vorgesehen ist, muss die Nachricht als fehlerhaft gelten.

Die Prüfung hat eine Reichweitengrenze. Ein Empfänger kann nicht selbst sicher feststellen, ob ein mehrere Hops entfernter Teilnehmer pCount gleich null legitim gesetzt hat. Die Signatur bewahrt den angegebenen Zustand, liefert aber nicht automatisch die organisatorische Berechtigung für jede entfernte Ausnahme. Der Standard begrenzt das Risiko durch Nachbarschaftskonfiguration und Fehlerbehandlung. Er ersetzt kein vollständiges Wissen über alle Rollen in einem weit entfernten Netz.

Dasselbe Muster gilt für Konföderationen und private AS-Nummern. Die globale RPKI kann private AS-Nummern nicht in derselben Weise abbilden. Lokale RPKI-Sichten oder besondere Übergangsverfahren können erforderlich sein. Sobald eine Nachricht die Grenze einer Konföderation verlässt, werden interne Segmente entsprechend den Regeln entfernt. Das ist kein Defekt der Registerlogik, sondern eine definierte Zuständigkeitsgrenze: Globale Aussagen benötigen global gültige Ressourcenbindungen; lokale Identitäten brauchen lokal kontrollierte Ergänzungen und eine saubere Exportgrenze.

RFC 9774 macht aus der Empfehlung ein Standardverhalten

Mit RFC 9774 wird die 2011 formulierte Richtung 2025 normativ verschärft. Das Dokument obsoletiert RFC 6472 und aktualisiert die grundlegenden BGP- und Konföderationsspezifikationen. Sofern ein Betreiber nicht ausdrücklich etwas anderes konfiguriert, etwa für eine Übergangsphase, dürfen BGP-Sprecher keine Updates mit AS_SET oder AS_CONFED_SET ankündigen. Beim Empfang solcher Segmente in AS_PATH oder AS4_PATH müssen sie Treat-as-withdraw anwenden.

Der Unterschied ist praktisch bedeutsam. Eine senderseitige Empfehlung wird zu einem symmetrischen Standardverhalten für Erzeugung und Empfang. Zugleich bleibt eine enge, ausdrückliche Übergangsausnahme bestehen. Der Standard behauptet daher nicht, dass alte Zustände mit seinem Veröffentlichungsdatum augenblicklich verschwunden seien. Er setzt einen Default, gegen den eine Abweichung bewusst konfiguriert werden muss. Betreiber können Übergänge planen, müssen aber die Ausnahme als Ausnahme behandeln und deren Dauer, Reichweite und Rücknahme kontrollieren.

Treat-as-withdraw begrenzt die Wirkung einer fehlerhaften oder nicht mehr zulässigen Route, ohne notwendigerweise die gesamte BGP-Sitzung zurückzusetzen. Es kann dennoch Reichweite verändern, wenn ein bisher genutzter Pfad zurückgezogen behandelt wird. Vor einer Aktivierung braucht ein Betreiber deshalb ein Inventar eingehender und ausgehender AS_SET-Verwendung, eine Sicht auf betroffene Präfixe und Nachbarn sowie eine vorbereitete Alternative für Aggregation und Ursprung. Normative Klarheit beseitigt nicht die Notwendigkeit, die operative Änderung zu messen.

Die Empfangsregel ist dabei nicht nur ein Filterhinweis, sondern eine Zustandsänderung im Routingprozess. Eine eingegangene Ankündigung mit einem der abgekündigten Segmenttypen darf unter dem Standardverhalten nicht wie eine weiterhin brauchbare Route behandelt werden. Für die Fehlersuche muss deshalb erkennbar bleiben, dass die Route empfangen, wegen ihres Pfadaufbaus als zurückgezogen behandelt und nicht aus einem unabhängigen Grund verworfen wurde. Nur diese Trennung erlaubt es, die Auswirkung der neuen Regel von einer fehlenden Sitzung, einem anderen Filter oder einer geänderten Ursprungsvalidierung zu unterscheiden.

Auch die ausdrückliche Abweichung vom Default braucht eine enge Lesart. Sie ändert nicht die technische Mehrdeutigkeit eines AS_SET und macht eine solche Route nicht zu einer BGPsec-Route. Sie verschiebt lediglich die Behandlung während eines kontrollierten Übergangs. Deshalb sollte eine Ausnahme nicht als allgemeiner Kompatibilitätsmodus verstanden werden, sondern an den konkreten Nachbarn, die beobachteten Präfixe und einen bekannten Rückkehrpunkt gebunden sein. Der RFC liefert die Möglichkeit der Konfiguration; ob ihr Umfang noch der tatsächlichen Übergangslage entspricht, bleibt eine Betreiberprüfung.

Konsistente kurze Aggregation verlagert die Verantwortung

RFC 9774 entfernt nicht jede Form der Aggregation. Es beschreibt eine kurze Aggregation ohne AS_SET und verlangt für einen konsistenten Ursprung, den AS_PATH nach der am weitesten rechts liegenden Instanz des gewünschten Ursprungs-AS abzuschneiden. Für das Aggregat ist eine passende ROA mit diesem gewünschten Ursprung nötig. Wenn gegenüber dem sonst erwarteten Aggregationsergebnis Information entfernt wird, soll ATOMIC_AGGREGATE die Veränderung kennzeichnen. AGGREGATOR und ATOMIC_AGGREGATE bleiben damit Teil der Aufzeichnung, während die ungeordnete AS-Menge verschwindet.

Die Verantwortung wird nicht aufgehoben, sondern anders verteilt. Der Betreiber muss einen eindeutigen Ursprung wählen, die ROA dazu pflegen und die Aggregationslogik so konfigurieren, dass der Ursprung stabil bleibt. Ohne diese Disziplin kann eine kurze Aggregation je nach verfügbaren beitragenden Routen einen wechselnden scheinbaren Ursprung erzeugen. Dann wären mehrere mögliche ROAs nötig oder die Route könnte in der Ursprungsvalidierung scheitern. Eindeutigkeit ist also nicht allein das Ergebnis des Verbots eines Feldtyps; sie entsteht aus konsistenter Konfiguration und passenden Ressourcenaufzeichnungen.

Das Dokument erinnert zudem daran, Aggregatrouten nicht an beitragende AS zurückzusenden und stattdessen geeignete spezifischere Präfixe anzukündigen. Bei weniger spezifischen und spezifischeren Routen können sonst Weiterleitungsschleifen entstehen. Implementierungen, die aggregieren, müssen Pakete verwerfen, die zwar zum Aggregat, aber zu keiner vorhandenen spezifischeren Route passen. Diese Regeln zeigen die Datenebenenfolge einer Kontrollpfadentscheidung. Ein sauberer AS_PATH verhindert nicht allein jede Schleife; Aggregation, Filterung und Weiterleitungsverhalten müssen zusammenpassen.

Damit entsteht für eine kurze Aggregation eine zusammenhängende Prüfkette. Zuerst muss feststehen, welche spezifischeren Routen in das Aggregat eingehen und welches AS als konsistenter Ursprung erscheinen soll. Danach müssen das Abschneiden des AS_PATH und die zu diesem Ursprung passende ROA denselben Zustand ausdrücken. Schließlich sind Exportgrenzen und das Verhalten für Verkehr zu prüfen, der nur vom weniger spezifischen Aggregat erfasst wird. Jede Stufe beantwortet eine andere Frage; keine einzelne Stufe ersetzt die übrigen.

Gerade an dieser Stelle wird der Unterschied zwischen einer eindeutigen Aufzeichnung und einer garantierten Wirkung sichtbar. Eine passende ROA dokumentiert die zulässige Herkunft, während die Aggregationskonfiguration den tatsächlich angekündigten Pfad erzeugt. ATOMIC_AGGREGATE kennzeichnet einen Informationsverlust, stellt aber die entfernte Information nicht wieder her. Die Weiterleitungsregel verhindert schließlich nicht durch Metadaten, sondern durch laufendes Verhalten, dass Pakete ohne passende spezifischere Route unkontrolliert zirkulieren.

Ein Betreiber muss diese drei Ebenen gemeinsam beobachten, obwohl sie in unterschiedlichen Datensätzen und Komponenten erscheinen.

Die drei RFCs bilden eine Entwicklung, keine Erfolgsmessung

Zusammengelesen zeigen die Dokumente eine nachvollziehbare Standardsentwicklung. RFC 6472 identifiziert die Mehrdeutigkeit ungeordneter AS-Mengen und empfiehlt Betreibern, sie nicht neu zu erzeugen. RFC 8205 entwirft eine Pfadautorisierung, die geordnete AS-Schritte, Zielnachbarn, RPKI-Ressourcenbindung und aktuelle Schlüssel benötigt und AS_SET nicht in BGPsec_PATH überführt. RFC 9774 hebt die frühere Empfehlung auf ein verbindliches Defaultverhalten, definiert die Empfangsreaktion und beschreibt eine konsistente Aggregationsalternative.

Diese Linie belegt weder eine flächendeckende Umsetzung noch einen bestimmten Rückgang von Hijacks, Störungen oder Angriffsfläche. Die Quellen liefern in diesem Zusammenhang keine aktuelle Messung der weltweiten AS_SET-Nutzung, keine Bestandsaufnahme aktiver BGPsec-Sitzungen und keine Leistungsdaten realer Router. Sie sagen auch nicht, dass Sriram persönlich eine bestimmte Implementierung, Bereitstellung oder Routingentscheidung kontrolliert habe. Solche Behauptungen würden zusätzliche, unabhängige Belege verlangen.

Der belastbare Schluss ist enger und für Betreiber nützlicher. Routing-Sicherheit wird stärker, wenn ein Zustand eindeutig benannt, an korrekte Nummernressourcen gebunden, zwischen Nachbarn explizit ausgehandelt, bei Änderungen neu bewertet und mit einer begrenzten Fehlerreaktion versehen wird. Doch die Aufzeichnung bleibt eine Aufzeichnung. Ob eine Route tatsächlich verwendet wird, ob ein Cache aktuell ist, ob Code den Standard korrekt umsetzt und wohin Pakete fließen, entscheidet sich in der laufenden Realität.