Summary

  • Le projet IOTOPS du 1er novembre 2026 décrit comment un contrôleur pourrait accepter une nouvelle URL Manufacturer Usage Description sans prendre n'importe quel fichier signé par le fabricant. Sa révision 03 reste un Internet-Draft de groupe de travail.
  • Lorsqu'un hébergement change, l'ancien fichier signé peut annoncer une nouvelle URL canonique. Le texte demande au contrôleur de refuser en principe une redirection HTTP 301 qui change de nom d'hôte.
  • Le dossier de reprise doit relier firmware, URL annoncée, signature acceptée, cache et règle de pare-feu réellement installée. Un acte de vente ne met pas à jour ce dossier à la place des appareils.

Une entreprise peut vendre sa gamme d'objets connectés en une journée. Les appareils, eux, continuent de réciter une adresse enregistrée dans leur logiciel. Le RFC 8520 prévoit qu'un appareil transmette une URL MUD; un contrôleur y récupère la description de ses communications attendues et en tire une politique d'accès locale. L'URL est courte. Sa durée de vie peut dépasser celle de la société qui l'héberge.

Le nouveau projet IOTOPS part d'un problème très matériel. Une mise à jour du firmware modifie les besoins de connexion. Réécrire le fichier MUD à la même adresse peut alors autoriser les nouveaux ports pour des appareils qui utilisent encore un vieux logiciel vulnérable. À l'inverse, retirer une autorisation peut faire passer leur trafic normal pour une anomalie. Séparer les versions par URL donne un moyen d'éviter que tous les appareils reçoivent la même politique par simple rafraîchissement du fichier.

La signature du fabricant ne choisit pas le bon produit

Une URL transmise par DHCP ou LLDP peut évoluer avec le firmware. Elle peut aussi être changée par un logiciel malveillant suffisamment ciblé. Si le contrôleur accepte tout fichier portant une signature du fabricant, l'appareil compromis peut lui désigner le fichier d'un autre modèle, signé authentiquement mais doté d'accès plus larges. Le projet propose donc un fichier MUD racine accepté pour l'appareil, puis une succession limitée à partir de cette racine. Le premier choix de confiance appartient au déploiement local: le RFC 8520 permet la vérification des signatures sans l'imposer à tous les contrôleurs.

Le petit déplacement conserve la base de l'URI et les segments du chemin; seul le dernier segment change. Le nouveau fichier doit venir d'une identité de signature équivalente, sous la même autorité de certification reconnue et avec le même nom de sujet. La grammaire de cette comparaison vient du RFC 3986. Le contrôleur devrait aussi mémoriser les URL déjà utilisées. Le retour à une ancienne adresse pourrait rétablir une autorisation retirée lors d'une version précédente.

La grande migration exige un pont dans l'ancien fichier

Le changement de domaine fonctionne autrement. Une fois un nouveau fichier admis au moyen de la petite transition, son attribut MUD-URL peut déclarer une URL canonique entièrement différente. Les transitions suivantes partent de cette nouvelle adresse. Ce contenu signé constitue le passage d'autorité. Une réponse 301 du serveur ne produit pas le même effet: le projet dit qu'un contrôleur SHOULD NOT accepter une redirection qui change de nom d'hôte.

Le repreneur doit donc maintenir l'ancien hébergement pendant que les contrôleurs récupèrent le fichier de passage. Le cache complique le calendrier. Pour que le changement soit découvert, l'ancien fichier doit pouvoir être rafraîchi; le projet renvoie notamment aux mécanismes HTTP exposés dans le RFC 9111. Si cette maîtrise du cache manque, ses auteurs décrivent un détour par une URL intermédiaire acceptable et deux mises à jour du firmware. C'est une solution à ce cas de cache, pas un nombre universel de mises à jour.

La signature ne se transmet pas non plus avec le mobilier. Le texte illustre un changement d'autorité de certification au moyen d'une chaîne de certificats qui garde le nom de sujet du signataire. Il ne fournit pas, par ce mécanisme, un changement de ce nom. Le nouveau propriétaire peut contrôler une nouvelle société et un nouveau serveur; le contrôleur, lui, continue de vérifier l'identité liée à la racine acceptée.

Le projet ne chiffre ni déploiements ni acquisitions concernées. Le fait qui changerait une décision de fermeture est observable chez chaque cohorte: version de firmware, URL émise, fichier signé accepté, heure de rafraîchissement et politique installée. Sans ce relevé, fermer l'ancien hôte revient à supprimer le premier maillon d'une chaîne dont on ignore combien d'appareils dépendent encore.

Une URL historique n'est pas un simple actif de communication. Elle reste un guichet par lequel l'appareil demande une autorisation réseau. L'acquéreur peut rebaptiser la société; il ne peut pas rebaptiser la confiance déjà enregistrée dans les contrôleurs par communiqué de presse.

Projet IOTOPS · RFC 8520 · RFC 3986 · RFC 9111