Zusammenfassung

  • draft-ietf-spring-srv6-security-16 versteht die Vertrauensdomäne als logische und betriebliche Konstruktion, in der die Grenzfilter-Annahme aus RFC 8402 tatsächlich gilt, nicht als physischen Ort.
  • Mehrere SR-Instanzen können derselben administrativen Einheit gehören und dennoch getrennt bleiben. Gemeinsamer Eigentümer, Standort oder Markenname beweisen keine gemeinsame Berechtigung.
  • Falsch geänderte Regeln oder Hardwaregrenzen können die Grenze offen ausfallen lassen. Nur nach einem SRH zu filtern reicht ebenfalls nicht aus.
  • Ein Grenzmanifest mit Durchsetzungsbeleg sollte Mitglieder, Bereiche, Schlüssel, geplante und installierte Regeln, Kapazität und Negativtests verbinden. Das ist Daniel Kades Vorschlag, keine IETF-Vorgabe.

Der Eigentümer wechselte, die Autorität nicht

Zwei SRv6-Umgebungen wurden unabhängig aufgebaut. Jede hat eigene SID-Planung, Controller, Schlüssel, Betriebsteams und Übergangsregeln. Nach dem Zusammenschluss entsteht ein einheitliches Organigramm. Eine Verbindung zwischen den Netzen wird nun als intern bezeichnet und soll weniger streng behandelt werden.

Doch ein Vertrag ermächtigt keinen Knoten des ersten Netzes automatisch, in der zweiten Umgebung Pfade vorzugeben. Er gleicht weder Adresspläne noch Filterkapazität an. Wird die Grenze entfernt, kann aus organisatorischer Vereinfachung eine technische Ausweitung von Befugnissen werden, für die es keinen gesonderten Beschluss gibt.

Revision 16 der Segment Routing IPv6 Security Considerations trennt diese Ebenen. Sie übernimmt aus RFC 8402 die Annahme, dass Segment Routing standardmäßig in einer Vertrauensdomäne betrieben und Verkehr an deren Grenzen gefiltert wird. Zugleich erklärt sie diese Domäne zur logischen und betrieblichen, nicht physischen Konstruktion. Rechner im selben physischen Netz gehören erst dazu, wenn sie ausdrücklich ihren Kontrollen unterstellt wurden.

Der Entwurf nennt außerdem mehrere SR-Instanzen unter derselben administrativen Einheit, die logisch oder betrieblich verschieden bleiben. Eine Quelle in einer anderen Vertrauensdomäne gilt für das Bedrohungsmodell als extern. Ein Firmenname ist damit kein Sicherheitsmerkmal.

Last Call ist kein Gütesiegel

Die IESG eröffnete am 3. September 2026 den Last Call zu Revision 16; Kommentare sind bis 17. September erbeten. Am Recherche-Stichtag 9. September führte der Datatracker das Dokument als aktiven SPRING-Internet-Draft mit beabsichtigtem Informational-Status. Ein Telechat-Termin fehlte, und der WG-Status verlangte wegen eines im WGLC erhobenen Punktes eine weitere Überarbeitung.

Der 17. September ist folglich kein vorweggenommenes Genehmigungsdatum. Revision 16 ist kein RFC und bescheinigt keinem Netz eine sichere Umsetzung. Der Text erklärt selbst, dass er weder ein neues Sicherheitsprotokoll noch eine Erweiterung definiert.

RFC 8402 macht die Tragweite der Annahme sichtbar: Ein Knoten, der eine Segmentliste oder einen SRH hinzufügt, gilt als dazu berechtigt. Mitgliedschaft verleiht also praktische Macht über Weiterleitung und Verarbeitung. Wird „intern“ aufgrund einer Übernahme neu definiert, erweitert sich diese Macht möglicherweise ohne einen technischen Nachweis.

Vertrauen besteht aus Deklaration, Regel und Ergebnis

Der Entwurf warnt vor der betrieblichen Schwierigkeit. Korrekte Filter müssen an sämtlichen Grenzen erhalten bleiben. Eine versehentliche Löschung oder Anpassung kann eingehenden oder ausgehenden Verkehr durchsickern lassen. Manche Plattformen verfügen nicht über die nötige Tabellengröße, Ausdruckskomplexität oder Protokollunterstützung.

Dann entsteht ein Fail-open-Zustand. Handlungen, die nur einem internen Angreifer zugeschrieben wurden, können von außen möglich werden, sobald ein beteiligtes System die grenzbildende Regel nicht mehr durchsetzt.

Drei Nachweise dürfen nicht zusammenfallen. Die deklarierte Mitgliedschaft nennt Knoten, Quellen, Controller und Rollen. Die beabsichtigte Durchsetzung beschreibt Ein- und Ausgänge, SID- und Quellbereiche, Kapselung und Ausnahmen. Die beobachtete Durchsetzung zeigt installierte Regeln, freie Kapazität, Zähler und Tests.

Ein angenommener Konfigurationsauftrag beweist nur einen Teil. Er zeigt nicht, ob alle Geräte die Regel übernommen haben, ob Tabellen voll waren, ob sie einen Neustart überstand und ob ein externer Test tatsächlich verworfen wurde.

Gerade bei der Integration unterscheiden sich die Voraussetzungen. Eine Umgebung nutzt einen gut filterbaren SID-Bereich, die andere eine komplexere Zuteilung. Eine kapselt am Eingang, die andere vertraut anderen Kontrollen. ACL- oder TCAM-Platz kann auf einer Plattform knapp sein und mit VLAN- oder Routingfunktionen konkurrieren. Gemeinsames Eigentum schafft keine zusätzliche Hardwarekapazität.

Das Vorhandensein eines SRH ist kein Grenzausweis

Ein Filter allein nach SRH klingt eindeutig, hat aber zwei Grenzen. SID-Verarbeitung kann ohne SRH stattfinden. Zugleich kann ein Paket mit SRH eine Domäne lediglich durchqueren. Das Merkmal kann daher relevante Pakete übersehen und legitimen Transit stören.

Entscheidend ist die Beziehung zwischen Quelle, Ziel und Bereichen. Am Eingang wird externer Verkehr zu einem internen SID verworfen. Ein SRv6-fähiger Knoten verwirft außerdem Pakete zu einem lokal instanziierten SID, wenn die Quelle außerhalb der Domäne liegt. Versagen beide Ebenen, öffnet sich die Grenze.

Dafür braucht der Betreiber erkennbare Infrastrukturbereiche. RFC 9602 stellt einen eigenen SRv6-SID-Präfix bereit. Revision 16 weist darauf hin, dass andere Adressentscheidungen Filter komplexer machen und das Risiko von Routenlecks oder Bedienfehlern erhöhen können. Maßgeblich ist die reale Adressierung, nicht die neue Konzernbezeichnung.

Kapselung am Eingang kann einen neuen äußeren IPv6-Header und SRH erzeugen. Interne Entscheidungen hängen dann nicht von Feldern ab, die eine nicht vertrauenswürdige Quelle geliefert hat. Kapselung ergänzt jedoch den Grenzfilter und ersetzt ihn nicht.

Zwei Schlüsseldomänen auf einem Knoten

RFC 8754 definiert einen optionalen HMAC-TLV. Revision 16 warnt, dass manuelle Verwaltung vorab geteilter Schlüssel zu Wiederverwendung verleiten kann. Derselbe Schlüssel soll nicht für verschiedene Vertrauensdomänen genutzt werden — auch dann nicht, wenn beide auf demselben Knoten existieren.

Damit wird die physische Maschine ausdrücklich vom Vertrauensumfang getrennt. Ein Gehäuse kann zwei Instanzen mit verschiedenen Autoritäten tragen.

Auch eine erfolgreiche HMAC-Prüfung hat begrenzte Aussagekraft. Ein kompromittierter berechtigter Knoten mit Schlüssel bleibt ein interner Angreifer. Ein interner Akteur ohne Schlüssel kann während dessen Gültigkeit zuvor erfasste SRH- und HMAC-Werte wiederholen. Kryptografie schützt bestimmte Felder; sie entscheidet nicht allein, wer welchen Pfad anordnen darf.

Ein konzernweit geteilter Schlüssel kann deshalb eine falsche Einheit erzeugen. Alles lässt sich prüfen, obwohl die zugrunde liegende Berechtigung nie beschlossen wurde. Eine spätere Trennung wird zugleich schwieriger.

Die tatsächliche Grenze belegbar machen

Sinnvoll ist ein versioniertes Vertrauensdomänen-Grenzmanifest mit einem Durchsetzungsbeleg nach jeder Änderung. Es verändert SRv6 nicht, sondern hält die Fakten auseinander, die sonst im Wort „intern“ verschwinden.

Das Manifest nennt Domänen-ID, zugelassene Knoten und Rollen, Ein- und Ausgänge, SID- und Quellbereiche, Controller-Befugnisse, Kapselungspunkte und Schlüsseldomänen-IDs, nie die Schlüssel selbst. Jeder Übergang zu einer anderen Domäne erhält Verantwortlichen, Zweck und Ablaufdatum.

Der Beleg verbindet genehmigte Absicht und Ergebnis: von jedem Gerät gemeldete Regeln, verfügbare Kapazität, Zähler, ein Negativtest von außen, ein erlaubter Test von innen und Ausnahmen. Änderungen an Topologie, Software, Hardware, Präfix, Rolle oder Schlüssel machen den früheren Beleg veraltet.

Das ist keine Behauptung absoluter Sicherheit. Es ist eine prüfbare Aussage: Diese Domänenrevision wurde zu diesem Zeitpunkt an diesen Grenzen, auf diesen Geräten und für diese Bereiche getestet; diese Einschränkungen bleiben offen.

The Policy Mirror fragt, wo Regeln tatsächlich wirksam werden. Hier verteilen sie sich auf Mitgliedschaft, Adressen, Filter, Kapselung und Schlüssel. Running-Code Primacy verlangt den gemeinsamen Ausführungsnachweis. Reality, Not Advocacy begrenzt die Aussage: Der Entwurf beschuldigt keinen Betreiber und löst kein domänenübergreifendes SRv6. Er zeigt jedoch, warum gemeinsames Eigentum kein gemeinsames Vertrauen erzeugt.

Quellen