Zusammenfassung

  • Mit BGP-Rollen können benachbarte Netze ihre Erwartungen als Provider, Customer, Peer oder Route Server vor dem Routenaustausch vergleichen; eine bestätigte Unvereinbarkeit kann die eBGP-Sitzung verhindern.
  • OTC trägt eine Weitergabegrenze mit der Route, authentifiziert aber weder den Geschäftsvertrag noch ersetzt es explizite Import- und Export-Policies oder beschreibt komplexe, präfixabhängige Beziehungen.

Analyse

Ein Route Leak setzt keinen falschen Ursprung voraus. RFC 7908 definiert ihn als Weitergabe einer gelernten BGP-Ankündigung über ihren beabsichtigten Geltungsbereich hinaus. Eine Route kann zum richtigen Ziel führen und dennoch von einem Provider zu einem anderen oder von einem Peer zu einem Provider in eine unzulässige Richtung gelangen. Der Fehler liegt in der Kette der Übergaben.

Lange beruhte diese Kette vor allem auf lokaler Konfiguration. Ein Betreiber stufte den Nachbarn als Customer, Provider oder Peer ein, baute Filter um diese Annahme und hoffte, dass die Gegenseite dieselbe Beziehung beschrieb. Die Sitzung musste beide Darstellungen nicht vergleichen. Tippfehler, fehlende Filter oder fehlerhafte Automatisierung konnten aus einem lokalen Fehler eine anderswo akzeptierte Route machen.

RFC 9234 fügt vor dem Routenaustausch eine kleine, aber folgenreiche Prüfung ein. Eine BGP-OPEN-Nachricht kann die Role Capability tragen. Die normalen Rollen sind Provider, Customer, Route Server, Route Server Client und Peer. Wenn beide Seiten Rollen senden, muss das Paar passen: Provider zu Customer, Route Server zu Route Server Client und Peer zu Peer. Andernfalls wird die Verbindung mit Role Mismatch abgelehnt.

Das ist eine Konsistenzprüfung des Protokolls, kein kaufmännisches Orakel. Ein Router liest weder Transitvertrag noch Rechnung noch Verkehrszusage. Beide Netze können passende, aber sachlich falsche Rollen konfigurieren. Eine Beziehung kann außerdem je Präfix, Dienst oder Region variieren. RFC 9234 nennt sie dann komplex und verbietet eine einzelne Rolle auf dieser Sitzung. Lässt sie sich nicht in normale Sitzungen trennen, bleibt eine präfixbezogene Policy erforderlich.

Der zweite Mechanismus wirkt in UPDATEs. Only to Customer, kurz OTC, ist ein optionales transitives Path Attribute mit Typcode 35. Sein Vier-Oktett-Wert enthält eine ASN. Wurde eine Route zu einem Customer, Peer oder Route Server Client gesendet, kennzeichnet OTC, dass sie anschließend nur noch zu Customers weitergegeben werden darf.

Eine Route mit OTC, die von einem Customer oder Route Server Client eintrifft, gilt als Leak und wird unzulässig. Ein definierter Widerspruch beim Empfang von einem Peer hat dieselbe Folge. Beim Export darf eine Route mit OTC nicht zu Providern, Peers oder Route Servern gesendet werden. Das Signal kann also einen lokalen Leak verhindern und einen Leak mehrere Hops später erkennen.

Auch Teildeployment hilft. Kommt eine Route von Provider, Peer oder Route Server ohne OTC, kann ein kompatibler Empfänger das Attribut hinzufügen. Der RFC beschreibt das als Vorteil für frühe Anwender. OTC ist jedoch nicht kryptografisch geschützt: Ein AS auf dem Pfad kann es entfernen, und eine falsche Markierung kann legitime Reichweite beschneiden.

Die Abwärtskompatibilität verlangt eine weitere Entscheidung. Sendet nur ein Nachbar eine Rolle, wird die Sitzung normalerweise mit der lokal konfigurierten Rolle fortgesetzt. Im Strict Mode kann ein stummer Nachbar abgewiesen werden. RFC 9234 warnt davor, dies zum Standard zu machen, weil nach einem Software-Update eine eBGP-Sitzung nicht mehr zustande kommen könnte.

RFC 8212 bleibt das Fundament: Ohne explizite Policy sollten eBGP-Routen weder importiert noch exportiert werden. Rollen und OTC validieren keinen Ursprung, machen keine zu großzügige Policy sicher und ersetzen keine Präfix- oder Pfadfilter. IANA bestätigt nur die Wire-Codes — Attribut 35 und Untercode 11 —, nicht das Deployment in einem benannten Netz oder Release.

Quellen