Zusammenfassung

  • Der OPSAWG-UCL-Entwurf in Revision 15 beschreibt sowohl gruppenfähige PEPs als auch einen Controller, der eine Gruppen-ID dynamisch in IP-/Transportfelder wie ein Fünf-Tupel übersetzt und gewöhnliche ACLs verteilt.
  • Die stabile Kennung entkoppelt die Absicht von flüchtigen Adressen, beseitigt aber die Übersetzung nicht. Migration, Adresswechsel und unvollständige Verteilung können eine korrekte Gruppenentscheidung in eine veraltete Paketregel verwandeln.

Die Anwendung hieß vor und nach der Migration gleich. Ihre Gruppe hieß vor und nach der Migration gleich. Im Orchestrator war der Umzug abgeschlossen. Nur eine Firewall filterte noch die alte Quelladresse und den alten Transportendpunkt.

Der Controller hatte die Gruppen-ID in ein Fünf-Tupel expandiert und daraus eine konventionelle ACL gebaut. Diese Regel war korrekt, als sie erzeugt wurde. Während der Verteilung zog die Anwendung auf einen anderen Host. Zwei PEPs erhielten die neue Projektion, einer bestätigte noch die vorherige.

Eine Prüfung der Geschäftsabsicht fand keinen Fehler. Die Richtlinie erlaubte der richtigen Gruppe den richtigen Dienst. Eine Prüfung der ACL-Syntax fand ebenfalls keinen Fehler. Der Fehler lebte in der zeitlichen Beziehung zwischen Identität, Abbildung, Verteilung und Paket.

Revision 15 von A YANG Data Model and RADIUS Extension for Policy-Based Network Access Control nimmt genau dieses Betriebsproblem ernst. Das Dokument erweitert das ACL-YANG-Modell aus RFC 8519 um Endpoint-Gruppen, Quell- und Zielgruppenabgleich sowie wirksame Zeitpläne. Für nutzerzentrierte Szenarien definiert es außerdem das RADIUS-Attribut User-Access-Group-ID.

Im Datatracker ist der Entwurf ein aktives OPSAWG-Arbeitsgruppendokument mit Zielstatus Proposed Standard. Er wurde beim IESG eingereicht und befindet sich in der RFC-Editor-Warteschlange, im finalen Review. Die IANA-Prüfung ist mit erforderlichen Aktionen abgeschlossen. Revision 15 trägt das Datum 2. April 2026 und läuft am 4. Oktober aus. Sie hat noch keine RFC-Nummer. Prozessreife ist kein Nachweis einer bestimmten Implementierung.

Stabilität wird erkauft, nicht geschenkt

IP-Adressen sind als dauerhafte Identität problematisch. Mobile Nutzer wechseln Netze. Temporäre IPv6-Adressen rotieren. NAPT verändert die sichtbaren Koordinaten. Virtuelle Maschinen und Container wandern. Eine Anwendung kann mehrere Instanzen auf mehreren Geräten besitzen.

Eine Gruppenkennung erlaubt es, die Richtlinie oberhalb dieser Bewegung auszudrücken. Das ist wertvoll: Die Aussage „Mitglieder der Betriebsgruppe dürfen den Verwaltungsdienst nutzen“ muss nicht bei jedem Adresswechsel neu erfunden werden.

Doch jeder PEP benötigt am Ende ein prüfbares Prädikat. Er muss entweder die Gruppe selbst erkennen oder eine Regel über Paketfelder erhalten. Der Entwurf beschreibt beide Wege.

Im administrativen Modell hält ein SDN-Controller die dynamische Zuordnung von Endpoint Group ID zu IP-/Transportfeldern und programmiert PEPs mit gewöhnlichen ACLs. Die PEPs brauchen dann keine besondere Gruppenlogik. Im Gerätemodell ordnet der PEP eingehende Pakete selbst einer Quell- oder Zielgruppe zu und wendet gruppenbezogene ACLs an.

Der erste Weg verschiebt Komplexität in Aktualisierung und Verteilung. Der zweite verschiebt sie in Klassifikation, Hardware, Software und möglicherweise die Weiterleitungsleistung. Der Entwurf erklärt ausdrücklich, dass Implementierungen diesen betrieblichen Tausch bewerten müssen; die Bewertung liegt außerhalb seines Umfangs.

Eine Abbildung braucht eine Gültigkeitsbedingung

Die Übersetzung Gruppe -> Fünf-Tupel darf nicht als zeitlose Stammdatenzeile behandelt werden. Sie ist eine Momentaufnahme mit Quelle, Version und Gültigkeitsbereich. Ein Nutzer kann sich neu verbinden, eine Adresse kann rotieren, ein Port kann durch NAPT anders erscheinen, eine Anwendung kann migrieren.

Ein belastbarer Datensatz nennt die Gruppenentscheidung, die Inventar- oder Sitzungsquelle, die resultierenden Felder, den Zeitpunkt der Berechnung, den Auslöser für Erneuerung und die PEPs, für die die Projektion bestimmt ist. Ohne diese Angaben kann eine alte Regel weiterhin erfolgreich kompiliert und installiert werden.

Die Lücke wird größer, wenn Aktualisierungen unabhängig eintreffen. Ein Controller kann zuerst die neue Anwendungslokation sehen, danach die neue AAA-Sitzung und erst später eine veraltete Inventarnachricht. „Neuester Wert“ ist kein ausreichender Konfliktalgorithmus, wenn Quellen unterschiedliche Ereigniszeiten besitzen.

Die Abbildung sollte deshalb eine kausale oder zumindest versionierte Beziehung zur Identitätsentscheidung und zum Migrationsereignis tragen. Ein nachträglich eintreffendes altes Ereignis darf die Projektion nicht zurückdrehen, ohne den Konflikt sichtbar zu machen.

Der Abschnitt zur Mapping Consistency fordert eine geeignete Einrichtung und besondere Sorgfalt, wenn verschiedene Mechanismen wie RADIUS unterstützt werden. Diese Sorgfalt muss in maschinenprüfbare Übergaben übersetzt werden: akzeptierte Entscheidungsversion, Mapping-Version, ACL-Version und PEP-Aktivierung.

Auch eine native Gruppen-PEP braucht Übersetzung

Das Gerätemodell scheint das Fünf-Tupel-Problem zu vermeiden. Der PEP versteht Gruppen und kann Pakete direkt klassifizieren. Dennoch bleibt eine Semantikgrenze.

Der Entwurf sagt, dass das im Paket verwendete Tag nicht exakt der Group-ID-Zeichenkette entsprechen muss. Wie die Zeichenkette auf ein Tag oder ein Headerfeld in einem Kapselungsszenario abgebildet wird, ist außerhalb des Umfangs. RFC 9638 wird als Beispiel für GBP genannt, nicht als universelle Kodierung.

Ein Paketmitschnitt mit Wert 37 beweist daher keine Gruppe, solange die damals aktive Tabelle fehlt. Ein Konfigurationsobjekt mit Gruppenname beweist nicht, dass der Datenpfad das beobachtete Tag gleich interpretierte. Die native Lösung verlagert die Abbildung näher an den PEP; sie schafft sie nicht ab.

Manche Geräte besitzen außerdem keine eingebaute Fähigkeit für gruppenbasierte Matches. Hardware- oder Software-Upgrades können erforderlich sein. Ein Controller muss die PEP-Fähigkeit kennen und dokumentieren, ob er eine native Gruppenregel oder eine expandierte konventionelle ACL geliefert hat.

Diese Modi können in einem Netz gleichzeitig vorkommen. Dann gelten verschiedene Aktualisierungs- und Fehlerflächen unter derselben Geschäftsrichtlinie. Ein pauschaler Status policy installed verdeckt genau diese Heterogenität.

RADIUS entscheidet nicht über den gesamten Pfad

User-Access-Group-ID darf in Access-Accept vorkommen. Nach erfolgreicher Authentisierung wird die zugehörige Zugriffskontrolle verwendet. In Access-Request darf das Attribut nur als Hinweis oder Präferenz erscheinen; der Server muss sie nicht erfüllen.

Eine Ereignisplattform muss den Pakettyp erhalten. Sonst kann ein vom Client gewünschter Gruppenwert wie eine vom Server erteilte Berechtigung aussehen. Geschützter Transport ändert diese Semantik nicht.

Mehrere Attributinstanzen in Access-Accept bedeuten, dass ein Nutzer mehreren Gruppen angehört. Diese Aussage liefert noch keine universelle Konfliktregel. Wenn eine Gruppen-ACE erlaubt und eine andere verweigert, sind Reihenfolge, Priorität, Zeitplan und Implementierungsverhalten Teil des Ergebnisses.

Das Attribut darf auch in CoA-Request vorkommen. Eine laufende Sitzung kann somit eine neue Gruppenzuweisung erhalten. Für einen wandernden Nutzer treffen zwei Veränderungsströme zusammen: Berechtigung und Paketkoordinaten. Der Controller darf sie nicht unter derselben „aktuellen“ Version zusammenfügen, wenn ihre Ursprünge nicht zusammenpassen.

In Accounting-Request kann der NAS bestätigen, dass er das Attribut empfangen hat und die Richtlinie durchsetzt. Diese Aussage ist ein wertvoller lokaler Beleg. Sie sagt nicht, welche Fünf-Tupel-Regel eine entfernte Firewall installiert hat oder ob der Dienst nach der Migration erreichbar war.

Mehrere PEPs bedeuten mehrere Abschlusspunkte

Der Entwurf erlaubt ausdrücklich mehrere Policy Enforcement Points. Ein Fluss kann durch NAS, Segmentierungs-Gateway, Firewall und Dienstrand laufen. Jeder Punkt hat eigene Fähigkeiten, Transaktionswarteschlangen und Ausfallzustände.

Der Controller sollte den erwarteten PEP-Satz für jede Richtlinie versionieren. Fehlt ein neu eingeführtes Gateway im Inventar, wird keine fehlgeschlagene Verteilung gemeldet; das Gerät war aus Sicht des Systems nie Ziel. Vollständigkeit beginnt deshalb bei der Zielermittlung.

Für jeden PEP sind getrennte Stufen nötig: gesendet, validiert, installiert, aktiviert und zurückgelesen. Ein HTTP-Erfolg des Controllers kann den ersten Übergang belegen. Eine Commit-ID oder Geräteantwort belegt mehr. Ein Readback-Hash bindet den lokalen Zustand. Paketzähler und Testverkehr belegen anschließend Verhalten.

Der Zustand des Netzes ist ein Vektor, keine boolesche Variable. „Zwei PEPs auf Mapping 82, einer auf Mapping 81, einer unbekannt“ ist eine ehrliche und handlungsfähige Aussage. enforced=true ist es nicht.

Die Fehlerstrategie muss zur Wirkung passen. Ein Entzug kann bei Teilkonvergenz eine Sperre verlangen. Eine Änderung für einen lebenswichtigen Dienst kann die letzte bekannte Richtlinie bewahren, bis alle Ziele bereit sind. Beide Entscheidungen sind legitim, wenn sie vorher festgelegt und im Beleg kenntlich gemacht werden.

Zeitpläne verschärfen die Versionsfrage

Das UCL-Modul kann einer ACE einen wirksamen Zeitplan geben: Zeitraum oder Wiederholung nach RFC 9922. Ohne Zeitplan gilt die ACE sofort und dauerhaft.

Eine Mapping-Version kann also auf die richtige Gruppe und die richtige Adresse zeigen, während die relevante ACE an diesem PEP noch nicht aktiv ist. Umgekehrt kann eine alte Projektion während eines gültigen Zeitfensters weiterlaufen. Mapping- und Zeitplanversion müssen gemeinsam ausgewertet werden.

Zeitzone, Ausnahmedaten, Uhrquelle und Aktivierungszeit gehören in den Beleg. Gleicher gespeicherter Text ist keine Garantie gleicher zeitlicher Auswertung. Der Entwurf weist zudem darauf hin, dass unbefugtes Schreiben des Zeitplans Verfügbarkeit schädigen und unbefugtes Lesen Angriffsfenster offenlegen kann.

Transparenz braucht daher Zugriffsstufen. Interne Prüfer benötigen die exakten Regeln. Öffentliche Nachweise können Integrität und Prüfung bestätigen, ohne betriebliche Zeitfenster preiszugeben.

Formale Qualität ist keine Migrationsmessung

Der Datatracker verzeichnet für die YANG-Validierung der Revision 15 null Fehler und null Warnungen. Das ist ein klarer Beleg für die geprüfte Form. Es misst nicht, wie schnell eine VM-Migration in ACLs erscheint oder ob zwei Hersteller denselben Gruppen-Tag verstehen.

Der Vergleich von Revision 14 und 15 zeigt vor allem redaktionelle Änderungen: Datum, Ablauf, Formulierungen, die Auflösung von NVO3 und die Referenz auf RFC 9907. Es kommen keine Interoperabilitäts- oder Produktionsmessungen hinzu.

Auch sichere Managementprotokolle lösen nur einen Teil. NETCONF oder RESTCONF müssen sicheren Transport und gegenseitige Authentisierung verwenden; NACM kann Zugriffe begrenzen. Dadurch wird eine unbefugte Änderung schwieriger. Eine befugte, aber veraltete Zuordnung bleibt möglich.

Dasselbe gilt für RADIUS-Sicherheit. Eine vertrauenswürdige Client-Server-Beziehung sowie IPsec oder TLS schützen den Austausch. Aktuelle RADEXT-Arbeiten zu unsicheren Praktiken und RadSec sind wichtig. Kein Transportprotokoll verteilt jedoch automatisch die richtige nachgelagerte ACL.

Ein minimaler Migrationsbeleg

Der Beleg beginnt mit Subjekt, Sitzung, Gruppenzuweisung und Autorität. Hinweise aus Access-Request bleiben von akzeptierten Werten getrennt; mehrere Gruppen bleiben vollständig erhalten.

Dann folgt die Abbildung: Quellsystem, Mapping-Version, Paketfelder oder Tag, Gültigkeit, Ereigniszeit und Migrationsauslöser. Danach die ACL: Revision, Aktion, Reihenfolge, Konfliktregel und wirksamer Zeitplan.

Der erwartete PEP-Satz, die Fähigkeiten und der gewählte Modus werden festgehalten. Pro PEP folgen Validierung, Installation, Aktivierung und Readback. Schließlich dokumentieren Pfad- und Paketbeobachtungen sowie ein Diensttest die tatsächliche Wirkung.

Heng Lus Minimum Initial Specification zielt nicht auf eine allumfassende globale Architektur. Sie legt die kleinste gemeinsame Übergabe fest, die lokale Entscheidungen prüfbar hält. Hier ist das die Bindung zwischen stabiler Gruppenabsicht und flüchtiger Paketprojektion.

Die Realitätsebenen machen den Kategorienfehler sichtbar. Gruppenname und Mapping sind symbolische beziehungsweise kontrollierende Aussagen. Die Geräte-ACL ist ausführbarer Zustand. Das Paket und die Dienstantwort sind beobachtete Wirklichkeit. Ein Erfolg auf einer Ebene kann die nächste nicht vertreten.

Running-Code Primacy fordert Migrationstests statt Folien: Adresse rotieren, VM verschieben, Controller zwischen Berechnung und Quittung neu starten, einen PEP abtrennen, CoA gleichzeitig auslösen und ein Zeitfenster überschreiten. Ein sicheres System zeigt partielle Konvergenz, statt sie durch einen stabilen Namen zu verdecken.

Im Ausgangsfall war die Gruppe niemals weitergezogen. Die Anwendung war es. Gerade deshalb brauchte die stabile Kennung einen versionierten Beleg ihrer aktuellen Projektion. Abstraktion schützt vor ständig wechselnder Konfiguration nur, wenn sie die Bewegung beobachtet, die sie verbergen soll.

Sources