Summary

  • Der IOTOPS-Entwurf vom 1. November 2026 beschreibt eine kontrollierte Nachfolge für Manufacturer-Usage-Description-URLs. Revision 03 ist ein aktiver Working-Group-Entwurf, noch kein RFC.
  • Bei einem Wechsel des Hostnamens kann eine signierte Datei am alten Ort eine neue kanonische URL benennen. Ein HTTP-301-Redirect auf einen anderen Host soll laut Entwurf vom MUD-Controller grundsätzlich nicht als Abkürzung akzeptiert werden.
  • Ein Erwerber braucht Belege für Firmwarestand, gemeldete URL, akzeptierte Datei, Signaturprüfung und tatsächlich installierte Firewallregel. Eigentum am Hersteller ersetzt keinen dieser Schritte.

Auf einer Übernahmeliste sieht ein alter Webserver wie ein Kostenposten aus. Für tausende Geräte kann er weiterhin die Eingangstür zur Netzwerkberechtigung sein. RFC 8520 lässt ein Gerät eine MUD-URL melden. Ein Controller holt dort die Herstellerdatei und übersetzt die beschriebenen Verbindungen in lokale Zugriffsregeln. Die Adresse kann im Gerät weiterleben, wenn Firma, Domain und Hostingvertrag längst gewechselt haben.

Der neue IOTOPS-Entwurf erläutert das mit einem erfundenen Toaster und einem möglichen Firmenkauf. Er meldet keinen realen Vorfall. Sein technischer Konflikt ist trotzdem konkret. Wird eine MUD-Datei am selben Ort für neue Firmware erweitert, erhalten alte Geräte möglicherweise zusätzliche Verbindungen, obwohl ihnen die neuen Schutzmechanismen fehlen. Wird eine Verbindung gestrichen, erscheint normales Verhalten ungepatchter Geräte als Regelverstoß. Eine eigene URL je Firmwaregeneration kann diese Zustände auseinanderhalten.

Gültige Unterschrift, falsches Gerät

Geräte können ihre MUD-URL über DHCP oder LLDP bekanntgeben. Eine Firmwareaktualisierung darf sie ändern; gezielte Schadsoftware könnte dasselbe tun. Ein Hersteller unterschreibt oft Dateien für mehrere Produkte. Prüft der Controller nur den Hersteller als Signierer, kann ein kompromittiertes Gerät auf die gültig signierte Datei eines anderen Produkts mit weiteren Rechten zeigen. Die Unterschrift ist echt. Die Zuordnung ist falsch.

Deshalb setzt der Entwurf eine für dieses Gerät akzeptierte Root-MUD-Datei an den Anfang. Ein kleiner URL-Wechsel behält die Basis-URI und die vorherigen Pfadsegmente bei und ersetzt lediglich das letzte Segment. Die neue Datei braucht eine gleichwertige End-Entity-Identität unter derselben vertrauenswürdigen Zertifizierungsstelle und mit demselben Subjektnamen. RFC 3986 liefert die URI-Syntax für die Grenze. Der Controller soll frühere URLs speichern und eine Rückkehr dorthin als möglichen Rollback prüfen. Die Regel setzt voraus, dass der Controller signierte MUD-Dateien tatsächlich verifiziert; RFC 8520 verlangt diese Konfiguration nicht von jeder Installation.

Der Umzug beginnt an der alten Adresse

Ein anderer Hostname passt nicht in einen bloßen Wechsel des letzten Pfadteils. Dafür lässt der Entwurf eine auf dem alten Pfad akzeptierte, signierte Datei in ihrem MUD-URL-Attribut eine neue kanonische Adresse angeben. Sobald der Controller diese Datei akzeptiert, beginnen weitere Änderungen an der neuen Adresse. Die alte Datei unterschreibt gewissermaßen ihre Nachfolgerin. Eine 301-Antwort des Webservers zeigt nur einen Weg; bei geändertem Hostnamen soll der Controller ihr nach dem Entwurf SHOULD NOT folgen.

Der Käufer muss den alten Ort daher lange genug betreiben, damit installierte Controller die Brücke abrufen können. Cache-Einträge machen den Termin unsicher. Wenn ein Controller die alte Datei nicht erneut lädt, sieht er den neuen Verweis nicht. Für diesen Teil verweist der Entwurf auf HTTP-Validierung und Caching, wie in RFC 9111 beschrieben. Lässt sich das Auffrischen der alten Datei nicht steuern, skizziert er eine Zwischenadresse im erlaubten Pfad und zwei Firmwareaktualisierungen bis zum endgültigen Ziel. Diese zwei Schritte lösen einen bestimmten Cachefall; sie sind kein allgemeiner Zwang für jede Übernahme.

Auch eine neue Zertifizierungsstelle bekommt nicht automatisch den Schlüsselbund. Im Beispiel des Entwurfs kann eine Zertifikatskette die CA wechseln und den Subjektnamen der unterschreibenden Identität bewahren. Ein Wechsel dieses Subjektnamens ist damit ausdrücklich nicht abgedeckt. Der Erwerber besitzt vielleicht die neue Domain; der Controller prüft noch die Kontinuität zur bisherigen Identität.

Die fehlende Zahl in einer echten Transaktion ist keine Marktprognose. Es ist eine Bestandsliste: Firmware pro Geräteklasse, ausgesandte URL, akzeptierte Signatur und Datei, letzter Abruf und installierte Regel. Der Entwurf nennt keine Zahl betroffener Geräte. Mit dieser Liste lässt sich feststellen, welche Klassen noch am alten Host hängen und wann dessen Abschaltung tatsächlich vertretbar ist.

Der alte Server ist also nicht bloß technischer Schutt im Kaufvertrag. Er hält den ersten Beleg einer Berechtigungskette. Wer ihn vor der nachgewiesenen Übergabe abschaltet, reißt die Kette an dem Punkt durch, den die Geräte noch kennen.

IOTOPS-Entwurf · RFC 8520 · RFC 3986 · RFC 9111