Zusammenfassung

  • AS-Nummer 0 ist eine reservierte Nicht-Identität. Sie darf weder im Peer-AS eines OPEN noch in AS_PATH, AS4_PATH, AGGREGATOR oder AS4_AGGREGATOR vorkommen; ORIGIN-Wert 0 ist dagegen die gültige BGP-Codierung für IGP.
  • RFC 7607 bindet die Reaktion an den Ort: Ein Peer, der AS 0 beansprucht, wird abgewiesen; ein AS_PATH mit Null führt für die betroffenen Routen zu treat-as-withdraw; ein fehlerhaftes Aggregator- oder Übergangsattribut wird verworfen, während die übrige UPDATE-Verarbeitung fortgesetzt wird.

Eine Automatisierung setzt während einer Migration eine noch unbekannte AS-Nummer auf 0. Danach sieht der Betrieb drei verschiedene Symptome: Eine Nachbarschaft scheitert mit Bad Peer AS. Auf einer zweiten bleibt die Session bestehen, aber Routen verschwinden. Auf einer dritten bleibt der Präfix erhalten, während AGGREGATOR aus der Darstellung fällt.

Wer diese Beobachtungen unter „AS0-Fehler“ zusammenfasst, hat den entscheidenden Teil der Evidenz entfernt. RFC 7607 verbietet denselben ASN-Wert in fünf BGP-Feldern, weist ihm aber je nach Protokollobjekt unterschiedliche Folgen zu. Beschädigt sein kann die versuchte Identität einer Session, die Glaubwürdigkeit einer in einem UPDATE getragenen Route oder nur ein Attribut.

Operative Autorität besteht nicht darin, immer die Session zu beenden. Sie besteht darin, genau das Objekt abzulehnen, dessen Semantik nicht mehr haltbar ist, und den restlichen gültigen Zustand zu schützen.

Eine reservierte Nicht-Identität

Das aktuelle IANA-Register der AS-Nummern führt 0 als Reserved mit Verweis auf RFC 7607. Das Register der AS-Nummern für besondere Zwecke trennt davon AS_TRANS 23456, Dokumentationsbereiche, private Bereiche und die reservierten letzten Nummern.

Diese Werte sind nicht austauschbar. AS_TRANS trägt eine definierte Funktion beim Übergang zu vier Oktetten. Private ASNs können innerhalb eines kontrollierten Bereichs verwendet werden. AS 0 bedeutet weder „unbekannt“ noch „anonym“ noch „später ausfüllen“.

Gerade Datenmodelle erzeugen den Fehler leicht: eine Spalte duldet kein null, ein leerer String wird als Integer konvertiert, eine Vorlage braucht einen Default. Damit wird aus fehlender Information eine unzulässige Netzidentität.

Eine Konfigurationsprüfung sollte den Fehler vor dem Router stoppen. Juniper dokumentiert im Rahmen seiner Unterstützung für 4-Byte-ASNs, dass die Verwendung beschränkter Nummern einschließlich 0 beim Commit scheitert. Das ist produktspezifische Prävention, kein Nachweis für sämtliche eingehenden Nachrichten. Parser und Fehlerbehandlung bleiben notwendig.

OPEN: Die Nachbarschaft entsteht nicht

RFC 4271 definiert das Feld My Autonomous System im OPEN. Trifft dort null als Peer-AS ein, verlangt RFC 7607 den Abbruch der Verbindung und eine NOTIFICATION OPEN Message Error / Bad Peer AS. Ein Router darf auch nicht selbst eine Verbindung unter AS 0 eröffnen.

Die Fehlerdomäne ist der Verbindungsversuch. Es gibt noch keine Established-Session, deren gültige Routen man bewahren könnte. Für die Untersuchung gehören das empfangene OPEN, die gesendete NOTIFICATION, Richtung, Endpunkte, Zeit, Wiederholungen und die erzeugende Konfiguration zusammen.

Eine gelockerte Peer-AS-Prüfung schafft keine legitime Ausnahme. Niemand ist Inhaber von AS 0. Wenn eine Übernahme zwei reale ASNs vorübergehend parallel benötigt, muss die local-as-Logik mit realen Werten und einer geprüften Wirkung auf OPEN und AS_PATH arbeiten.

AS_PATH: Die Route wird als zurückgezogen behandelt

Enthält AS_PATH die AS-Nummer 0, erklärt RFC 7607 das UPDATE für malformed und verweist auf RFC 7606. Ein fehlerhaftes AS_PATH wird als treat-as-withdraw behandelt. Alle im UPDATE enthaltenen Routen gelten als zurückgezogen und verlassen Adj-RIB-In.

Die Session kann bestehen bleiben. So reißt ein einzelnes fehlerhaftes Path-Attribut nicht sämtliche anderen gültigen Präfixe des Peers mit. Die Begrenzung ist kein Nachgeben gegenüber AS 0, sondern Schutz der laufenden Funktion bei gleichzeitiger Ablehnung der unglaubwürdigen Reachability.

Der Empfänger darf die Null nicht aus dem Pfad schneiden oder durch eine vermutete ASN ersetzen. AS_PATH ist angekündigte Provenienz und dient Loop-Erkennung und Auswahl. Eine lokale Korrektur würde eine Behauptung erzeugen, die der Nachbar nie gesendet hat. Erst ein neues, sauberes UPDATE des Schreibers kann die Route zurückbringen.

Ein Grenzfilter ergänzt diese Logik. Die FRRouting-BGP-Dokumentation zeigt in einem Bogon-Beispiel ein Match _0_ für AS_PATH. Das schafft Tiefenverteidigung und Zähler, deckt aber weder OPEN noch andere Attribute ab.

AGGREGATOR: Das Attribut fällt weg

AGGREGATOR nennt AS und Speaker, die ein Aggregat erzeugten. AS 0 ist dort ebenfalls verboten. RFC 7606 ordnet einem malformed AGGREGATOR jedoch attribute discard zu: Das Attribut wird verworfen, das UPDATE weiterverarbeitet.

Die Route kann die übrigen Prüfungen bestehen. Darum ist „Jedes UPDATE mit AS 0 muss zurückgezogen werden“ falsch. Die verbleibende Route entschuldigt aber weder Informationsverlust noch den fehlerhaften Sender. Feld, Aktion und Quelle müssen protokolliert und repariert werden.

RFC 6793 definiert AS4_PATH und AS4_AGGREGATOR für die Vier-Oktett-Transition. RFC 7607 macht AS 0 in beiden Attributen malformed und übergibt die Behandlung an RFC 6793. Im zutreffenden Kontext wird das Attribut verworfen, der Fehler lokal protokolliert und die Verarbeitung fortgesetzt.

Ohne die ausgetauschten OPENs fehlt der Capability-Kontext. Zwischen zwei NEW-Speakern dürfen AS4_PATH und AS4_AGGREGATOR überhaupt nicht übertragen werden. Ihr Auftauchen kann bereits unabhängig vom Nullwert ein Fehler sein. UPDATE und Capability-Verhandlung gehören deshalb in denselben Evidenzsatz.

Der gültige ORIGIN-Wert 0

RFC 4271 codiert im ORIGIN-Attribut IGP als 0, EGP als 1 und INCOMPLETE als 2. ORIGIN 0 ist gültig und keine Aussage, der originierende AS sei AS 0.

Eine Telemetrie, die nur nach Zahlen oder einem generischen Feld origin sucht, kann ORIGIN-Code, aus AS_PATH abgeleitete Origin-ASN, Default-Route und Metrik vermischen. Rauschen führt zu Ausnahmen und stummgeschalteten Regeln; darunter verschwindet schließlich der echte Verstoß.

Ein belastbarer Regressionstest enthält ein gültiges ORIGIN-0-UPDATE und je einen ASN-0-Fall in den fünf verbotenen Positionen. Das System muss den gültigen Fall akzeptieren, die anderen nach Feld benennen und die jeweilige Aktion sichtbar machen. Sämtliche Nullbytes abzulehnen wäre keine strenge, sondern eine semantiklose Implementierung.

Zu speichern sind PDU oder verlustfreie Darstellung, Nachrichtentyp, Attribute Type Code, Richtung, Peer, AFI/SAFI, Capabilities, Version und Zeit. Eine Oberfläche darf „AS0 erkannt“ anzeigen, solange sie den Weg zum ursprünglichen Feld nicht abschneidet.

AS-0-ROA: Ein anderer Autoritätspfad

RFC 6482 definiert eine ROA als signiertes Objekt aus asID und Präfixautorisierungen. RFC 6483 beschreibt AS 0 als Erklärung des Ressourceninhabers, dass ein Präfix und seine spezifischeren Präfixe nicht zum Routing verwendet werden sollen.

Das Objekt erlaubt keine Route mit Origin AS 0. RFC 6907 stellt fest, dass keine gültige BGP-Route origin ASN 0 haben und daher keine Route eine AS-0-ROA matchen kann. Eine Ankündigung eines realen ASN kann Invalid werden, wenn eine Abdeckung existiert und keine Kandidaten-ROA ihren tatsächlichen Ursprung und die Länge autorisiert.

Eine wichtige Grenze bleibt: AS-0-ROA und ROAs für routbare ASNs können koexistieren. Matcht eine davon Präfix, maxLength und tatsächlichen Ursprung, ist die Route Valid. Die AS-0-ROA überstimmt keine passende positive Autorisierung.

Auch die Zeitlinien unterscheiden sich. OPEN und UPDATE laufen in der BGP-Session. Eine ROA läuft über Publikation, Zertifikatsvalidierung, Sammlung und Relying-Party-Cache. Eine BGP-Korrektur und eine RPKI-Korrektur konvergieren nicht zwangsläufig gleichzeitig. Beide Beweisspuren müssen getrennt bleiben.

Vom Eingang bis zum Ausgang

RFC 7854 definiert BMP für UPDATEs, Peer-Zustand und pre-/post-policy Adj-RIB-In. Pre-policy zeigt, was ankam; post-policy, was lokal überlebte. Nur gemeinsam trennen sie Senderfehler von erfolgreicher Eindämmung.

RFC 9069 ergänzt Loc-RIB-Monitoring. Es zeigt die vom Decision Process gewählten Routen, aber weder FIB noch Paketlieferung. Für einen behaupteten Dienstausfall braucht es Data-Plane-Evidenz.

RFC 8671 ergänzt pre-/post-policy Adj-RIB-Out. Damit lässt sich das Verbot der Weitergabe an benannten Ausgangsgrenzen prüfen. Ein Collector beweist keine weltweite Abwesenheit, aber ein definierter Peer-Umfang ist auditierbar.

RFC 7454 liefert die allgemeine Disziplin für Ein-, Aus- und AS-Path-Filter. RFC 7607 liefert die feldspezifische Entscheidung. Der Fall muss Originalnachricht, Capability-Kontext, Aktion, RIB-Differenzen, Auswahl, nötigenfalls FIB, Ausgänge, Generatorfehler und korrigierte Nachricht verbinden.

Quellen