Zusammenfassung

  • Die schreibgeschützten Blätter in Revision 01 bilden eine hierarchische Obergrenze für SCHC-Änderungen, enthalten aber keine Identität des aufrufenden Benutzers, Geräts oder der Sitzung.
  • Eine Änderung darf nur durch die Schnittmenge aus Akteursberechtigung und vollständiger SCHC-Rechtekette wirksam werden; hinzu kommen alter Versionsstand, Validierung, Peer-Aktivierung und Rückweg.

Ein Konfigurationsauftrag sieht auf den ersten Blick sauber aus. Die Management-Sitzung ist authentifiziert, die Gruppe besitzt Schreibrechte und das betroffene Feld meldet change-tv. Der Workflow hat damit zwei positive Prüfungen und setzt die neue Target Value.

Doch die Prüfungen belegen Verschiedenes. Die Gruppenregel erlaubt dieser Sitzung eine Management-Operation. Das SCHC-Blatt beschreibt, welche Art von Änderung das Field Descriptor grundsätzlich verträgt. Offen bleibt, ob genau dieser Akteur genau diesen Context und RuleID jetzt ändern darf, ob der gelesene Ausgangszustand noch gilt und ob der Kommunikationspartner dieselbe Bedeutung aktivieren wird.

Das Beispiel ist rekonstruiert und keine dokumentierte Störung. Es macht die Governance-Frage hinter draft-ietf-schc-access-control-01 sichtbar: Aus der Änderbarkeit eines Objekts folgt noch kein Mandat für einen Akteur.

Die weggelassenen Bits leben im Context

SCHC spart Übertragung, weil beide Enden einen gemeinsamen Context besitzen. Nach RFC 8724 verweist der RuleID auf eine Regel, deren Field Descriptors unter anderem Target Value, Matching Operator und Compression/Decompression Action enthalten. Bekanntes muss nicht in jedem Paket erneut erscheinen.

Damit wird Übereinstimmung zur Betriebsbedingung. Wenn die Enden denselben RuleID unterschiedlich lesen, kann das verkürzte Paket den Streit nicht selbst lösen. RFC 9363 nennt die Folgen: Eine manipulierte Anwendungs-IPv6-Adresse kann Kommunikation blockieren oder Abhören ermöglichen. Die Identität des Anfragenden soll geprüft werden, und ein Gerät darf nur seine eigenen Regeln verändern.

Revision 01 versucht, die Objektgrenze feiner zu beschreiben. Ein allgemeines Recht zum Schreiben des YANG-Baums reicht nicht, wenn bei einer Uri-Path-Entry die Target Value verändert werden darf, der Anwendungspräfix in derselben Regel aber geschützt bleiben muss.

Drei Grenzen statt eines Schreibbits

ac-modify-set-of-rules unterscheidet keine Änderung, die Änderung vorhandener Elemente sowie Hinzufügen und Entfernen. ac-modify-compression-rule begrenzt die Field Descriptions einer Kompressionsregel. ac-modify-field soll schließlich zwischen unveränderlich, Änderung nur der Target Value und Änderung von TV, MO und CDA unterscheiden.

Diese Ebenen sind keine unabhängigen Ja/Nein-Schalter. Das Kompressionsregel-Blatt wird nur wirksam, wenn sein Elternblatt Änderungen zulässt. Das Feld-Blatt benötigt die Freigabe beider Eltern. Ein großzügiges Kind hebt ein restriktives Elternteil nicht auf. Fehlt ein Blatt, gilt die Information laut Entwurf als nicht änderbar.

Die Blätter sind config false. Der entfernte Bearbeiter kann sie nicht selbst setzen und dadurch im selben Vorgang seine Erlaubnis erzeugen. Sie sind berichteter Zustand. Aber auch berichteter Zustand braucht einen Adressaten: Die Blätter nennen weder Benutzer noch Gruppe, Credential, Sitzung, Eigentümer oder Delegation. Sie begrenzen die Mutation, nicht den Kreis der Berechtigten.

NACM liefert den Akteur, SCHC die Objektsemantik

Der Entwurf grenzt sich nicht von NACM ab. Er erklärt vielmehr, dass NACM Benutzer und Gruppen zu Aktionen ermächtigt, seine gewöhnliche Granularität jedoch nicht in das SCHC-Regelmodell passt. RFC 8341 bindet einen authentifizierten Benutzernamen und Gruppen an die Sitzung, prüft Protokolloperationen und Datenknoten und antwortet bei Ablehnung mit access-denied. Für eine Nachricht bleibt der zu Beginn wirksame Regelsatz stabil.

Die Systeme beantworten daher zwei notwendige Fragen. NACM oder ein gleichwertiger Mechanismus entscheidet, ob der Principal diese Anfrage ausführen darf. Die SCHC-Hierarchie entscheidet, ob dieses Element diese Veränderungsart zulässt. Die Freigabe ist eine UND-Verknüpfung.

NETCONF verlangt authentifizierte Verbindungen und kann, sofern die Fähigkeiten angeboten werden, Validierung, Candidate Datastore, Locks und rollback-on-error bereitstellen. RESTCONF kennt keine vom Client gesteuerten expliziten Locks, bietet aber ETags und If-Match, um veraltete Schreibversuche abzuweisen. CORECONF überträgt YANG kompakt über CoAP und verpflichtet den Server, unautorisierte Lese- und Schreibzugriffe zu verhindern.

Diese Werkzeuge lösen unterschiedliche Teile. NACM-CRUDX allein weiß nicht, warum eine TV veränderlich und der benachbarte Präfix geschützt ist. change-tv allein weiß nicht, welcher authentifizierte Principal handeln darf. Wer nur eine Seite prüft, macht entweder eine breite Administratorrolle zur Ausnahme von der Feldgrenze oder eine Feldberechtigung zum Inhaberticket.

Transaktion und Protokollwechsel sind zwei Ereignisse

Auch nach korrekter Autorisierung kann ein zweiter Writer den Ausgangszustand ändern. RESTCONF kann mit ETag und If-Match erkennen, dass die gelesene Fassung veraltet ist. NETCONF kann einen Datastore sperren oder eine Candidate-Konfiguration validieren. Der konkrete Schutz hängt von beworbenen Fähigkeiten und Implementierung ab.

Noch wichtiger: Ein erfolgreicher Schreibvorgang bedeutet nicht, dass der SCHC-Peer bereits denselben Context verwendet. HTTP 204 oder <ok/> quittiert eine Management-Transaktion. Für den Protokollwechsel braucht es zusätzlich die neue Rule-Revision, einen definierten Aktivierungszeitpunkt, die betroffenen Peers, Kompatibilitätsbelege und einen getesteten Rücksprung.

Revision 01 definiert nicht, wer die schreibgeschützten Blätter bereitstellt, wie sie abgeleitet und widerrufen werden oder wie ein Principal mit einem bestimmten Context verknüpft wird. Auch gleichzeitige Writer, Mehrfeld-Atomizität, Aktivierung, Audit und Wiederherstellung sind nicht festgelegt.

Diese Funktionen können außerhalb des Entwurfs existieren. Sie dürfen aber nicht unsichtbar vorausgesetzt werden. Der SCHC-Architekturentwurf vom Juli 2026 verlangt Authentifizierung und Autorisierung der Manager, Protokollierung von Context-Änderungen und Wiederherstellung eines bekannten guten Zustands; zugleich bezeichnet er Lifecycle und Management als noch auszuarbeiten.

Unfertiger Text ist selbst ein Risikosignal

Die untersuchte Revision wurde am 29. September 2026 aktualisiert. Sie ist ein aktiver Working-Group Internet-Draft mit Standards-Track-Kopf, kein RFC. Im Abschnitt Terminology steht ToDo; Security Considerations und IANA Considerations bestehen aus TBD. Das YANG-Modul trägt eine Revision von 2023 und eine fremde Beschreibung zu compound-ack und RFC YYYY. Feldrecht-Enums sind mit Reserved slot number beschrieben.

Solche Spuren widerlegen nicht das Modell. Sie zeigen, dass Namen, Semantik und Sicherheitskomposition noch nicht als stabiler Produktvertrag behandelt werden dürfen. Keine der eingefrorenen Quellen belegt breite Produktion, Interoperabilität, Leistung oder einen benannten Vorfall.

Wer jetzt implementiert, sollte Revision und Annahmen explizit speichern. Eine spätere Änderung des Entwurfs darf nicht unbemerkt die Bedeutung eines bereits automatisierten Blatts verändern.

Ein prüfbarer Änderungsbeleg

Für jede folgenreiche Mutation gehören mindestens in den Nachweis:

  1. authentifizierter Principal, Gruppen, Sitzung und Transportschutz;
  2. Operation, Context, Set of Rules und RuleID;
  3. vorherige Revision oder ETag sowie exakte Vorher-/Nachherwerte;
  4. sämtliche SCHC-Blätter einschließlich der Eltern;
  5. die verwendete NACM- oder gleichwertige Policy-Revision;
  6. Validierung, Konfliktprüfung und Transaktionsergebnis;
  7. Aktivierungszeit und Kompatibilität je Peer;
  8. beobachtete Wirkung, Verantwortlicher und getesteter Rollback-Punkt.

Schmale Autorität bedeutet hier nicht, möglichst viele Änderungen zu verbieten. Sie bedeutet, dass keine Schicht mehr behauptet, als sie belegen kann. Identitätsverwaltung bestätigt den Akteur, SCHC begrenzt das Objekt, die Transaktion schützt den Übergang und der Betreiber verantwortet die Aktivierung.

Sources