Zusammenfassung

  • Der IESG eröffnete am 3. September 2026 den Last Call für Version 16 von Segment Routing IPv6 Security Considerations bis zum 17. September. Vorgesehen ist ein Informational RFC; das Draft ist weder gebilligt noch veröffentlicht.
  • Die SRH-Präsenz ist kein verlässlicher Zugangsfilter: SID-Verarbeitung kann ohne SRH stattfinden, während ein SRH-Paket nur durchlaufen kann. Die Vertrauensgrenze muss anhand von Adressen, Quellen und ausgeführten Kontrollen belegt werden.

Ein Trusted Domain ist nach Version 16 kein Gebäude und keine Firmenzugehörigkeit. Es ist ein logisches und betriebliches Konstrukt. Ein Host im selben physischen Netz bleibt außen, solange er nicht den Kontrollen unterliegt; zwei SR-Instanzen desselben Betreibers können gegenseitig externe Bereiche sein.

Darum greift die auffällige SRH als Klassifikator zu kurz. Eine IPv6-Zieladresse kann allein einen vollständigen Segmentpfad darstellen. Umgekehrt kann Routing Type 4 legitimen Transitverkehr kennzeichnen. Pauschales Sperren erzeugt Interoperabilitätsschäden, und Freigabe bei fehlendem Header übersieht SIDs.

Die eigentliche Kontrolle arbeitet zweistufig. Am Eingang wird jedes externe Paket verworfen, dessen Ziel zu den internen SIDs gehört. Jeder SID-Knoten verwirft zusätzlich ein Paket zur lokalen SID, wenn die Quelle nicht aus dem erlaubten Bereich stammt. Fällt eine Ebene aus, bleibt die andere. Fehlen beide, entsteht fail-open und eine zuvor interne Angriffsfläche kann von außen erreichbar werden.

RFC 9602 erleichtert diese Regeln mit einem dedizierten SID-Block. Er schützt nicht selbst und ist nicht zwingend. Verteilte eigene Präfixe erhöhen jedoch die Zahl der Regeln, Ausnahmen und möglichen Lecks. Lokale Flexibilität verschiebt Arbeit in Inventar und Prüfung.

Trusted Ingress Encapsulation gibt dem äußeren IPv6-Header und einem optionalen SRH einen kontrollierten Urheber. Dennoch ersetzt sie keinen Grenzfilter. Wer ein externes Paket falsch zulässt und danach kapselt, verwandelt den Fehler lediglich in internes Format.

Auch der HMAC-TLV ist begrenzt. Er schützt ausgewählte Felder mit einem Pre-Shared Key, bleibt optional und kann durch manuelle Schlüsselwiederverwendung geschwächt werden. Wiederholung ist während der Gültigkeit möglich; Segments Left gehört nicht zur Abdeckung. Ein gültiger HMAC ist weder Frische- noch Zugangsbeleg.

Middleboxes sehen während der Segmentverarbeitung wechselnde Ziele. Ohne SRv6-Verständnis können sie das aktive Segment für das Endziel halten oder Rückverkehr einer anderen Verbindung zuordnen. Alle Extension Header zu verwerfen würde Routing Type 4 im Domain brechen und Pakete ohne SRH zu einer SID weiterhin nicht erfassen.

Schließlich muss die Regel in Hardware passen. TCAM und ACL-Kapazität werden teils mit VLAN-, Routing- und MAC-Funktionen geteilt. Ein Controller kann eine korrekte Konfiguration akzeptieren, die das Gerät nicht vollständig laden kann. Erlaubt das System bei Ressourcenmangel, existiert die schriftliche Grenze ohne laufende Wirkung.

Die Heng-Lu-Perspektive trennt den Last Call, das Draft, die Soll-Konfiguration, den ASIC-Zustand, den beobachteten Paketweg und das Ergebnis. Kein früherer Datensatz darf die Autorität des folgenden übernehmen.

Quellen

  1. IESG Last Call
  2. SRv6-Sicherheitsentwurf Version 16
  3. Datatracker-Eintrag
  4. RFC 8402: Segment-Routing-Architektur
  5. RFC 8754: SRH
  6. RFC 8986: SRv6 Network Programming
  7. RFC 9602: dedizierter SID-Block
  8. RFC 9288: Filterung von IPv6 Extension Headers
  9. RFC 7872: Messung von Extension-Header-Verlust
  10. RFC 8200: IPv6
  11. RFC 9098: Sicherheit von IPv6 Extension Headers
  12. RFC 9099: betriebliche IPv6-Sicherheit
  13. RFC 9259: OAM im SRH
  14. RFC 4381: Trusted-Domain-Praxis
  15. RFC 3552: Security Considerations
  16. Heng Lu: Running-Code Primacy
  17. Heng Lu: Minimum Initial Specification
  18. Heng Lu: Reality Layers