Zusammenfassung

  • Revision 30 des IDR-Arbeitsgruppendokuments verlangt Authentifizierung, Integrität und Vertraulichkeit für die BGP-Sitzung und eine zentrale Prüfung der Ursprungsberechtigung.
  • IPsec-Aushandlung, Replay-Behandlung, SA-Aufbau und der beobachtete Tunnelbetrieb bleiben außerhalb von BGP; ein angenommenes UPDATE ist deshalb nur ein Glied der Beweiskette.

Ein grüner Status, mehrere unbekannte Entscheidungen

Automatisierung verdichtet viele Ereignisse gern zu einer Farbe. Ist die BGP-Sitzung oben und wurde das UPDATE akzeptiert, erscheint der Vorgang abgeschlossen. Doch das Grün kann lediglich bedeuten, dass der Parser zufrieden war. Es sagt nicht, ob eine Policy dem Sender das konkrete Attribut erlaubte, ob der Empfänger eine kompatible kryptografische Auswahl fand oder ob später überhaupt Verkehr über den Tunnel lief.

draft-ietf-idr-sdwan-edge-discovery-30 liefert eine gute Grundlage, diese Ebenen auseinanderzuhalten. Die Revision vom 1. September 2026 ist ein aktiver Internet-Draft der IDR-Arbeitsgruppe mit dem angestrebten Status Proposed Standard. Er beschreibt die Verteilung von Informationen zur Entdeckung von SD-WAN-Edges und Underlay-Tunneln mittels BGP in einer kontrollierten Umgebung unter gemeinsamer administrativer Hoheit. Als laufender Entwurf belegt er weder eine Implementierung noch eine Verbreitung oder einen Produktfehler.

Revision 30 verlangt, dass die betroffenen BGP-Sitzungen Peer-Authentifizierung, Integrität und Vertraulichkeit bereitstellen. Das konkrete Verfahren bleibt der Bereitstellung überlassen. Zusätzlich erhält der Route Reflector beziehungsweise Controller eine zentrale Policy- und Autorisierungsfunktion: Bevor er Informationen zu einem SD-WAN Hybrid Tunnel reflektiert, muss er prüfen, ob der BGP-Speaker sie originieren darf.

Gleichzeitig grenzt der Text BGP von IPsec ab. BGP transportiert Parameter, handelt sie aber nicht aus, prüft ihre Nutzbarkeit nicht und baut keine Security Association auf. Gerade diese Begrenzung macht den Governance-Bedarf sichtbar.

Authentizität ist noch keine Zuständigkeit

Eine Peer-Authentifizierung ordnet die Sitzung einem bekannten Gegenüber zu. Integrität schützt vor unbemerkter Veränderung, Vertraulichkeit vor unbefugter Einsicht. Keine dieser Eigenschaften erteilt dem Peer pauschal das Recht, beliebige Node IDs, Endpunkte, SD-WAN Colors oder Tunnelparameter zu behaupten.

Identität und Zuständigkeit sind verschiedene Angaben. Eine Berechtigung braucht eine Policy, die Gegenstand, Umfang und Zeit bindet. Deshalb sollte die Entscheidung des Controllers später rekonstruierbar sein: Policy-Version, zutreffende Regel, autorisierter Ursprung, Geltungsbereich und Entscheidungszeitpunkt gehören zusammen.

Die gemeinsame administrative Hoheit ersetzt diesen Nachweis nicht. Auch eine Organisation verteilt Kompetenzen, richtet Ausnahmen ein und widerruft Rechte. Ohne präzise Delegation wird aus einem legitimen Teilnehmer unbemerkt ein Sprecher mit unbegrenzter Aussagebefugnis.

Ein korrektes UPDATE kann ohne Tunnel enden

Der Empfänger kann ein wohlgeformtes, autorisiertes UPDATE erhalten und trotzdem keinen Tunnel zulassen. Ein kryptografisches Verfahren kann fehlen, ein Endpunkt kann lokal unzulässig sein, die SD-WAN Color kann nicht zur Absicht passen oder die lokale Policy kann eine andere SA wählen. Der Entwurf sagt ausdrücklich: Wenn die angekündigten IPsec-Parameter nicht verwendbar sind, ist die BGP-Ankündigung deshalb nicht automatisch fehlerhaft.

Das ist saubere Schichtung. Für die Nachweisführung bedeutet es, dass zwei Wahrheiten gleichzeitig bestehen können: „BGP-Ankündigung gültig“ und „lokale IPsec-Zulassung abgelehnt“. Wer nur die erste speichert, verliert die Ursache. Wer die zweite als BGP-Fehler bezeichnet, weist sie der falschen Verantwortung zu.

Auch der Rekey-Zähler bleibt für BGP undurchsichtig. Er beeinflusst weder die Routenwahl noch beweist er Aktualität oder erkennt Replays. Erzeugung, Speicherung und Vergleich von Nonces sowie die Reaktion auf Wiederholungen liegen außerhalb von BGP. Ein universelles Frische-Symbol aus diesem Wert abzuleiten, würde eine nicht vorhandene Zusicherung erzeugen.

Fünf Nachweise statt eines Häkchens

Der Transportnachweis hält authentifizierten Peer, geschützte Sitzung, Verfahren und Empfangszeit fest. Er belegt die Zustellung über diese Sitzung, nicht jede inhaltliche Befugnis.

Der Ursprungsnachweis zeigt, mit welcher Controller- oder Reflector-Policy dieser Speaker genau diese SD-WAN-Information in diesem Umfang originieren durfte. Eine bloße Ja-Nein-Antwort reicht nach einer Policy-Änderung kaum zur Rekonstruktion.

Der Ankündigungsnachweis umfasst Syntax und Konsistenz von NLRI und TLVs. Bekannte Node ID, erreichbare und autorisierte Endpunkte sowie passende SD-WAN Color gehören zu den beschriebenen operativen Prüfungen. Ein positives Ergebnis macht die Information verarbeitbar, aber noch keinen Tunnel.

Der lokale Zulassungsnachweis erfasst IPsec-Kompatibilität, angewandte lokale Regel, gewählte SA oder Aktion und einen Ablehnungsgrund. Mehrere Empfänger können auf dieselbe Ankündigung unterschiedlich reagieren, ohne dass einer von ihnen das BGP-Ergebnis umdeuten muss.

Der Ausführungs- und Ergebnisnachweis dokumentiert SA-Aufbau, Tunnelzustand und den tatsächlich beobachteten Datenverkehr. Erst er verbindet die verteilte Absicht mit einem laufenden Dienst.

Wer diese fünf Nachweise zusammenfasst, kann später eine zu breite Autorisierung, ein ungültiges Attribut, eine legitime Inkompatibilität, eine gescheiterte Aushandlung und einen ungenutzten Tunnel nicht mehr unterscheiden.

Ein lokaler Zulassungs- und Ausführungsbeleg

Die Verknüpfung erfordert keine neue BGP-Nachricht. Der Betreiber kann pro Tunnelentscheidung einen lokalen Beleg erzeugen, der vorhandene Ereignisse verbindet: Sitzungspartner und empfangender Knoten; Version, Regel und Umfang der zentralen Policy; autorisierter Ursprung; Fingerabdruck der angekündigten Attribute; Syntax- und Konsistenzresultate; lokale IPsec-Entscheidung; ausgewählte SA oder Aktion; Erfolg oder Fehler des Aufbaus; Datenpfadgesundheit; verantwortlicher Owner; Ablauf, Widerruf und Ablösung.

Der Beleg soll keine Schlüssel oder sensiblen kryptografischen Werte kopieren. Unveränderliche Policy-Referenzen, Hashes und knappe Entscheidungscodes genügen, wenn Kennungen und Zeitbezug stimmen. Er ist kein globales Wahrheitsregister, sondern ein Beweismittel innerhalb der Verantwortung des Betreibers.

Dieser Vorschlag ist eine redaktionelle Governance-Empfehlung. Er ist keine Forderung von IETF, IDR, BGP oder dem Entwurf. Sein Ziel ist weder ein zweites Routingprotokoll noch die Überladung von BGP, sondern eine belastbare Kausalität über Systemgrenzen hinweg.

Autorisierung macht den Reflector zum Machtpunkt

Sobald ein Route Reflector über Ursprungsrechte entscheidet, ist er mehr als ein effizienter Verteiler. Eine präzise Regel stoppt eine unzulässige Behauptung vor der Verbreitung. Eine veraltete oder zu breite Regel vervielfacht einen Fehler ebenso effizient.

Revision 30 nennt eine Kompromittierung des Controllers ausdrücklich als außerhalb ihres Umfangs. Das ist kein Argument gegen zentrale Autorisierung, wohl aber gegen den Schluss „Der Controller hat reflektiert, also ist alles bewiesen“. Jede Ausübung dieser Autorität sollte an eine unveränderlich referenzierte Policy gebunden sein. Notfallausnahmen brauchen ein Ablaufdatum; Rechte sollten klein zugeschnitten sein; ein Widerruf muss zu allen abhängigen Tunneln führen.

Ein Beleg verhindert keine Kompromittierung. Er macht aber sichtbar, welche Regel wo wirkte, und begrenzt die Wiederherstellung auf identifizierbare Entscheidungen.

Ablehnungen sind wertvolle Evidenz

Erfolgreiche Tunnel hinterlassen Pakete und Liveness-Werte. Ablehnungen verschwinden oft in kurzlebigen Logs. Dabei kann eine Häufung autorisierter, aber inkompatibler Vorschläge auf auseinanderlaufende Kryptopolicies hinweisen. Wiederholte Ursprungsablehnungen können eine fehlerhafte Rollout-Reihenfolge zeigen. Aufgebaute SAs ohne erwarteten Verkehr legen offen, dass Kontroll- und Dienstebene auseinanderfallen.

Jeder Fehler sollte seine Schicht behalten. Ein TLV-Parsingfehler ist kein IPsec-Vorfall. Lokale Inkompatibilität beweist kein Fehlverhalten des Senders. Ein Datenpfadausfall widerlegt nicht nachträglich die Peer-Authentifizierung. Präzise Klassen führen zum zuständigen Team und zeigen, wo Automation Unklarheiten nur überdeckt.

Den Entwurf nicht größer machen als er ist

Gegenüber Revision 29 schärft Revision 30 die verpflichtende Sitzungssicherung, den gemeinsamen Administrationsrahmen, zentrale Autorisierung, die Trennung von BGP und IPsec, Replay-Verantwortung außerhalb von BGP, lokale Policy sowie Ausschlüsse wie Controller-Kompromittierung, Forward Secrecy, großflächiges Rekeying und alternative Mechanismen. Das sind wichtige Grenzmarkierungen, keine Aussage über reale Einführung oder universelle Überlegenheit.

Die dauerhafte Regel lautet: Eine Sicherheitseigenschaft belegt nur, was ihre Schicht tatsächlich herstellt. Ein authentifiziertes BGP-UPDATE ist ein starker Nachweis dafür, dass ein bekannter Peer Information über eine geschützte Sitzung geliefert hat. Zum Zulassungsnachweis wird es erst zusammen mit Ursprungsautorisierung, Ankündigungsprüfung, lokaler IPsec-Entscheidung und beobachtetem Ergebnis. Die sichere Zustellung eines Antrags ist nicht seine Genehmigung.

Quellen