1. Introduction

1. Introduction

L'Internet a été largement construit pour des ordinateurs à usage général, ces appareils qui peuvent être utilisés à des fins spécifiées par leurs propriétaires. Dans [RFC1984], on présumait qu'un appareil terminal serait le plus capable de se protéger lui-même. Cela avait du sens lorsque l'appareil typique était une station de travail ou un ordinateur central, et cela continue d'avoir du sens pour les appareils informatiques à usage général d'aujourd'hui, y compris les ordinateurs portables, les smartphones et les tablettes.

[RFC7452] discute des modèles de conception pour et pose des questions sur les objets intelligents. Posons alors un groupe d'objets qui ne sont spécifiquement pas destinés à être utilisés pour des tâches informatiques à usage général. Ces appareils, que ce mémo appelle Things, ont un objectif spécifique. Par définition, par conséquent, toutes les autres utilisations ne sont pas prévues. Si un petit nombre de modèles de communication découle de ce petit nombre d'utilisations, la combinaison de ces deux déclarations peut être reformulée comme une description d'usage du fabricant (Manufacturer Usage Description, MUD) qui peut être appliquée à divers points au sein d'un réseau. MUD s'adresse principalement aux menaces pesant sur l'appareil plutôt qu'à l'appareil en tant que menace. Dans certaines circonstances, cependant, MUD peut offrir une certaine protection dans ce dernier cas, selon la façon dont l'URL MUD est communiquée et la façon dont les appareils et leurs communications sont authentifiés.

Nous utilisons la notion de "fabricant" de manière souple dans ce contexte pour faire référence à l'entité ou à l'organisation qui indiquera comment un appareil est destiné à être utilisé. Par exemple, dans le contexte d'une ampoule, il peut effectivement s'agir du fabricant d'ampoules. Dans le contexte d'un appareil plus intelligent doté d'une pile Linux intégrée, il pourrait s'agir d'un intégrateur de cet appareil. Les points clés sont que l'appareil lui-même est censé servir un objectif limité, et qu'il existe une organisation dans la chaîne d'approvisionnement de cet appareil qui prendra la responsabilité d'informer le réseau de cet objectif.

L'intention de MUD est de fournir ce qui suit:

• Réduire substantiellement la surface de menace sur un appareil à ces communications prévues par le fabricant.

• Fournir un moyen de faire évoluer les politiques réseau vers le nombre toujours croissant de types d'appareils sur le réseau.

• Fournir un moyen de remédier à au moins certaines vulnérabilités d'une manière plus rapide que le temps nécessaire pour mettre à jour les systèmes. Cela sera particulièrement vrai pour les systèmes qui ne sont plus pris en charge.

• Maintenir le coût de mise en œuvre d'un tel système au strict minimum.

• Fournir un moyen d'extensibilité aux fabricants pour exprimer d'autres capacités ou exigences de l'appareil.

MUD se compose de trois blocs de construction architecturaux:

• Une URL qui peut être utilisée pour localiser une description;

• La description elle-même, y compris comment elle est interprétée; et

• Un moyen pour les systèmes de gestion de réseau locaux de récupérer la description.

MUD est plus efficace lorsque le réseau est capable d'identifier d'une manière ou d'une autre les points d'extrémité distants avec lesquels les Things communiqueront.

Dans cette spécification, nous décrivons chacun de ces blocs de construction et comment ils sont destinés à être utilisés ensemble. Cependant, ils peuvent également être utilisés séparément, indépendamment de cette spécification, par des déploiements locaux pour leurs propres besoins.

1.1. What MUD Doesn't Do (Ce que MUD ne fait pas)

MUD n'est pas destiné à traiter l'autorisation réseau des ordinateurs à usage général, car leurs fabricants ne peuvent pas envisager un modèle de communication spécifique à décrire. De plus, même les appareils qui ont une seule ou un petit nombre d'utilisations peuvent avoir des modèles de communication très larges. MUD seul n'est pas pour eux non plus.

Bien que MUD puisse fournir aux administrateurs réseau une protection supplémentaire lorsque des vulnérabilités d'appareils existent, il ne remplacera jamais le besoin pour les fabricants de corriger les vulnérabilités.

Enfin, peu importe ce que le fabricant spécifie dans un fichier MUD, ce ne sont pas des directives, mais des suggestions. La façon dont elles sont instanciées localement dépendra de nombreux facteurs et sera finalement à la charge de l'administrateur réseau local, qui doit décider ce qui est approprié dans des circonstances données.

1.2. A Simple Example (Un exemple simple)

Une ampoule est destinée à éclairer une pièce. Elle peut être contrôlée à distance via le réseau et elle peut utiliser un service de rendez-vous (qui pourrait être accessible par une application sur un smartphone). Ce que nous pouvons dire de cette ampoule, alors, c'est que tout autre accès réseau est indésirable. Elle ne contactera pas un service d'actualités, ne parlera pas au réfrigérateur et n'a pas besoin d'une imprimante ou d'autres appareils. Elle n'a pas d'amis sur les réseaux sociaux. Par conséquent, lui appliquer une liste d'accès qui stipule qu'elle ne se connectera qu'au service de rendez-vous unique n'empêchera pas l'exécution de sa fonction; en même temps, cela permettra au réseau de fournir à l'ampoule et à d'autres appareils une couche de protection supplémentaire.

1.3. Terminology (Terminologie)

MUD: Description d'usage du fabricant (Manufacturer Usage Description).

MUD file (Fichier MUD): un fichier contenant du JSON basé sur YANG qui décrit un Thing et le comportement réseau spécifique suggéré associé.

MUD file server (Serveur de fichiers MUD): un serveur Web qui héberge un fichier MUD.

MUD manager (Gestionnaire MUD): le système qui demande et reçoit le fichier MUD du serveur MUD. Après avoir traité un fichier MUD, il peut diriger des modifications vers des éléments réseau pertinents.

MUD controller (Contrôleur MUD): un synonyme qui a été utilisé dans le passé pour le gestionnaire MUD.

MUD URL: une URL qui peut être utilisée par le gestionnaire MUD pour recevoir le fichier MUD.

Thing: l'appareil émettant une URL MUD.

Manufacturer (Fabricant): l'entité qui configure le Thing pour émettre l'URL MUD et celle qui affirme une recommandation dans un fichier MUD. Le fabricant peut ne pas toujours être l'entité qui construit un Thing. Il pourrait, par exemple, être un intégrateur de systèmes, ou même un fournisseur de composants.

Les mots-clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" et "OPTIONAL" dans ce document doivent être interprétés comme décrit dans BCP 14 [RFC2119] [RFC8174] lorsque, et seulement lorsque, ils apparaissent en majuscules, comme indiqué ici.

1.4. Determining Intended Use (Détermination de l'utilisation prévue)

La notion d'utilisation prévue n'est pas en soi nouvelle. Les administrateurs réseau appliquent des listes d'accès tous les jours pour permettre uniquement une telle utilisation. Cette notion de liste blanche a été bien décrite par Chapman et Zwicky dans [FW95]. Les systèmes de profilage qui utilisent l'heuristique pour identifier les types de systèmes existent également depuis des années.

Un Thing pourrait tout aussi facilement dire au réseau quel type d'accès il nécessite sans entrer dans quel type de système il est. Cela serait, en effet, l'inverse de [RFC7488]. Cependant, en cherchant une solution générale, nous supposons qu'un appareil implémentera la fonctionnalité nécessaire pour remplir son objectif limité. C'est une contrainte économique de base. À moins que le réseau ne refuse l'accès à un tel appareil, ses développeurs n'auraient aucune raison de fournir au réseau quelque information que ce soit. À ce jour, une telle affirmation s'est avérée vraie.

1.5. Finding a Policy: The MUD URL (Trouver une politique: l'URL MUD)

Notre travail commence par l'appareil émettant un localisateur de ressources universel (Universal Resource Locator, URL) [RFC3986]. Cette URL sert à la fois à classer le type d'appareil et à fournir un moyen de localiser un fichier de politique.

Les URL MUD DOIVENT utiliser le schéma "https" [RFC7230].

Dans ce mémo, trois moyens sont définis pour émettre l'URL MUD, comme suit:

• Une option DHCP [RFC2131] [RFC8415] que le client DHCP utilise pour informer le serveur DHCP. Le serveur DHCP peut entreprendre d'autres actions, telles qu'agir en tant que gestionnaire MUD ou transmettre l'URL MUD au gestionnaire MUD.

• Une contrainte X.509. L'IEEE a développé IEEE 802.1AR [IEEE8021AR] pour fournir une approche basée sur les certificats pour communiquer les caractéristiques de l'appareil, qui s'appuie elle-même sur [RFC5280]. L'extension d'URL MUD est non critique, comme requis par IEEE 802.1AR. Divers moyens peuvent être utilisés pour communiquer ce certificat, y compris le protocole d'authentification extensible par tunnel (Tunnel Extensible Authentication Protocol, TEAP) [RFC7170].

• Enfin, une trame de protocole de découverte de couche liaison (Link Layer Discovery Protocol, LLDP) est définie [IEEE8021AB].

Il est possible qu'il existe d'autres moyens pour qu'une URL MUD soit apprise par un réseau. Par exemple, certains appareils peuvent déjà être déployés ou avoir une capacité très limitée à communiquer une URL MUD, et pourtant ils peuvent être identifiés par certains moyens, tels qu'un numéro de série ou une clé publique. Dans ces cas, les fabricants peuvent être en mesure de mapper ces identifiants à des URL MUD particulières (ou même aux fichiers eux-mêmes). De même, il peut exister des mécanismes de résolution alternatifs disponibles pour les situations où la connectivité Internet est limitée ou n'existe pas. De tels mécanismes ne sont pas décrits dans ce mémo, mais ils sont possibles. Les implémenteurs sont encouragés à permettre la flexibilité de la façon dont les URL MUD peuvent être apprises.

1.6. Processing of the MUD URL (Traitement de l'URL MUD)

Les gestionnaires MUD qui sont capables de le faire DEVRAIENT récupérer les URL MUD et les fichiers de signature selon [RFC7230], en utilisant la méthode GET [RFC7231]. Ils DOIVENT valider le certificat en utilisant les règles de [RFC2818], section 3.1.

Les demandes d'URL MUD DEVRAIENT inclure un champ d'en-tête "Accept" ([RFC7231], section 5.3.2) contenant "application/mud+json", un champ d'en-tête "Accept-Language" ([RFC7231], section 5.3.5) et un champ d'en-tête "User-Agent" ([RFC7231], section 5.5.3).

Les gestionnaires MUD DEVRAIENT traiter automatiquement les codes d'état de réponse 3xx.

Si un gestionnaire MUD n'est pas en mesure de récupérer une URL MUD, d'autres moyens PEUVENT être utilisés pour importer des fichiers MUD et des fichiers de signature associés. Tant que la signature du fichier peut être validée, le fichier peut être utilisé. Dans de tels environnements, les contrôleurs DEVRAIENT avertir les administrateurs lorsque l'expiration de la validité du cache approche afin qu'ils puissent vérifier les nouveaux fichiers.

Il peut ne pas être possible pour un gestionnaire MUD de récupérer un fichier MUD à un moment donné. Si un gestionnaire MUD ne parvient pas à récupérer un fichier MUD, il DEVRAIT considérer celui existant comme sûr à utiliser, au moins pendant un certain temps. Après une certaine période, il DEVRAIT enregistrer qu'il n'a pas pu récupérer le fichier. Il peut y avoir de très bonnes raisons à de telles défaillances, y compris la possibilité que le gestionnaire MUD soit dans un environnement hors ligne, que la connexion Internet locale ait échoué ou que la connexion Internet distante ait échoué. Il est également possible qu'un attaquant tente d'interférer avec le déploiement d'un appareil. La façon de gérer de telles circonstances est une décision locale.

1.7. Types of Policies (Types de politiques)

Lorsque l'URL MUD est résolue, le gestionnaire MUD récupère un fichier qui décrit quel type de communications un appareil est conçu pour avoir. Le fabricant peut spécifier soit des hôtes spécifiques pour des services basés sur le cloud, soit certaines classes pour l'accès au sein d'un réseau opérationnel. Un exemple de classe pourrait être "appareils d'un type de fabricant spécifié", où le type de fabricant lui-même est indiqué simplement par le composant d'autorité (par exemple, le nom de domaine) de l'URL MUD. Un autre exemple pourrait être de permettre ou de refuser l'accès local. Tout comme d'autres politiques, celles-ci peuvent être combinées. Par exemple:

• Autoriser l'accès aux appareils du même fabricant

• Autoriser l'accès vers et depuis les contrôleurs via le protocole d'application contraint (Constrained Application Protocol, COAP) [RFC7252]

• Autoriser l'accès au DNS/NTP local

• Refuser tout autre accès

Une imprimante pourrait avoir une description qui stipule:

• Autoriser l'accès pour le port IPP ou le port LPD

• Autoriser l'accès local pour le port HTTP

• Refuser tout autre accès

De cette façon, n'importe qui peut imprimer sur l'imprimante, mais un accès local serait requis pour l'interface de gestion.

Les fichiers qui sont récupérés sont destinés à être étroitement alignés sur les architectures réseau existantes afin qu'ils soient faciles à déployer. Nous utilisons YANG [RFC7950] car il fournit des modèles précis et adéquats à utiliser par les appareils réseau. JSON [RFC8259] est utilisé comme format de sérialisation pour la compacité et la lisibilité, par rapport à XML. D'autres formats peuvent être choisis avec des versions ultérieures de MUD.

Bien que les exemples de politique donnés ici se concentrent sur le contrôle d'accès, ce n'est pas censé être le seul objectif. En structurant le modèle décrit dans ce document avec des points d'extension clairs, d'autres descriptions pourraient être incluses. Une qui vient souvent à l'esprit est la qualité de service.

Les modules YANG spécifiés ici sont des extensions de [RFC8519]. Les extensions à ce modèle permettent à un fabricant d'exprimer des classes de systèmes qu'un fabricant jugerait nécessaires au bon fonctionnement de l'appareil. Deux modules sont spécifiés. Le premier module spécifie un moyen pour les noms de domaine d'être utilisés dans les listes de contrôle d'accès (Access Control Lists, ACLs) afin que les appareils qui ont leurs contrôleurs dans le cloud puissent être correctement autorisés avec des noms de domaine, où le mappage de ces noms vers des adresses peut changer rapidement.

L'autre module abstrait les adresses IP en certaines classes qui sont instanciées en adresses IP réelles par le traitement local. Grâce à ces classes, les fabricants peuvent spécifier comment l'appareil est conçu pour communiquer, de sorte que les éléments réseau peuvent être configurés par des systèmes locaux qui ont une connaissance topologique locale. C'est-à-dire que le déploiement peuple les classes que le fabricant spécifie. Les abstractions ci-dessous correspondent à zéro ou plusieurs hôtes, comme suit:

Manufacturer (Fabricant): Un appareil fabriqué par un fabricant particulier, tel qu'identifié par le composant d'autorité de son URL MUD.

same-manufacturer (même fabricant): Appareils qui ont le même composant d'autorité de leur URL MUD.

controller (contrôleur): Appareils que l'administrateur réseau local admet dans la classe particulière.

my-controller (mon contrôleur): Appareils destinés à servir de contrôleurs pour l'URL MUD que le Thing a émise.

local: La classe d'adresses IP dont la portée est limitée à une certaine limite administrative. Par défaut, il est suggéré qu'il s'agisse du sous-réseau local.

Les classes de "fabricant" peuvent être facilement spécifiées par le fabricant, tandis que les classes de contrôleur sont initialement envisagées pour être spécifiées par l'administrateur.

Étant donné que les fabricants ne savent pas qui utilisera leurs appareils, il est important que la fonctionnalité référencée dans les descriptions d'utilisation soit relativement omniprésente et mature. Pour ces raisons, la configuration basée sur YANG dans un fichier MUD est limitée aux modules soit spécifiés soit référencés dans ce document, soit spécifiés dans des extensions documentées.

1.8. The Manufacturer Usage Description Architecture (Architecture de description d'usage du fabricant)

Avec ces composants disposés, nous avons maintenant la base d'une architecture. Cela nous amène à l'art ASCII.

.......................................
.                      ____________   .           _____________
.                     |            |  .          |             |
.                     |    MUD     |-->get URL-->|    MUD      |
.                     |  Manager   |  .(https)   | File Server |
.  End system network |____________|<-MUD file<-<|_____________|
.                             .       .
.                             .       .
. _______                 _________   .
.|       | (DHCP et al.) | router  |  .
.| Thing |---->MUD URL-->|   or    |  .
.|_______|               | switch  |  .
.                        |_________|  .
.......................................

Figure 1: Architecture MUD

Dans le diagramme ci-dessus, le commutateur ou le routeur collecte les URL MUD et les transmet au gestionnaire MUD (un système de gestion de réseau) pour traitement. Cela se produit de différentes manières, selon la façon dont l'URL est communiquée. Par exemple, dans le cas du DHCP, le serveur DHCP pourrait recevoir l'URL puis la traiter. Dans le cas d'IEEE 802.1X [IEEE8021X], le commutateur transporterait l'URL via un certificat vers le serveur d'authentification via le protocole d'authentification extensible (Extensible Authentication Protocol, EAP) sur Radius [RFC3748], qui le traiterait ensuite. Une méthode pour ce faire est TEAP, comme décrit dans [RFC7170]. L'extension de certificat est décrite ci-dessous.

Les informations renvoyées par le serveur de fichiers MUD sont valides tant que le Thing est connecté. Il n'y a pas d'expiration. Cependant, si le gestionnaire MUD a détecté que le fichier MUD d'un Thing a changé, il DEVRAIT mettre à jour la politique rapidement, en tenant compte du flux d'approbation requis dans un déploiement. De cette façon, les nouvelles recommandations du fabricant peuvent être traitées en temps opportun.

Les informations renvoyées par le serveur de fichiers MUD (un serveur Web) sont valides pour la durée de la connexion du Thing, ou comme spécifié dans la description. Ainsi, si le Thing est déconnecté, toute configuration associée dans le commutateur peut être supprimée. De même, de temps en temps, la description peut être actualisée, en fonction de nouvelles capacités ou de modèles de communication ou de vulnérabilités.

Le serveur Web est généralement exécuté par ou au nom du fabricant. Son nom de domaine est celui de l'autorité trouvée dans l'URL MUD. Pour les cas hérités où les Things ne peuvent pas émettre d'URL, si le commutateur est capable de déterminer l'URL appropriée, il peut la proxifier. Dans un cas trivial, il peut coder en dur une URL MUD sur un port de commutateur ou un mappage d'un identifiant disponible tel qu'une adresse L2 ou un hachage de certificat vers une URL MUD.

Le rôle du gestionnaire MUD dans cet environnement est de faire ce qui suit:

• recevoir les URL MUD,

• récupérer les fichiers MUD,

• traduire les abstractions dans les fichiers MUD en configuration d'élément réseau spécifique,

• maintenir et mettre à jour tous les mappages requis des abstractions, et

• mettre à jour les éléments réseau avec une configuration appropriée.

Un gestionnaire MUD peut être un composant d'un système d'authentification, d'autorisation et de comptabilité (Authentication, Authorization, and Accounting, AAA) ou d'un système de gestion de réseau. La communication au sein de ces systèmes et de ces systèmes vers les éléments réseau est hors de la portée de ce mémo.

1.9. Order of Operations (Ordre des opérations)

Comme mentionné ci-dessus, MUD contient des blocs de construction architecturaux, de sorte que l'ordre des opérations peut varier. Cependant, voici un exemple prévu clair:

1. Thing émet une URL.

2. Cette URL est transmise à un gestionnaire MUD par le commutateur le plus proche (comment cela se produit dépend de la façon dont l'URL MUD est émise).

3. Le gestionnaire MUD récupère le fichier MUD et la signature du serveur de fichiers MUD, en supposant qu'il n'en a pas déjà de copies. Après avoir validé la signature, il peut tester l'URL contre un service de réputation Web ou de domaine, et il peut tester tous les hôtes dans le fichier contre ces services de réputation, comme il le juge approprié.

4. Le gestionnaire MUD peut interroger l'administrateur pour obtenir la permission d'ajouter le Thing et la politique associée. Si le Thing est connu ou si le type de Thing est connu, il peut ignorer cette étape.

5. Le gestionnaire MUD instancie la configuration locale basée sur les abstractions définies dans ce document.

6. Le gestionnaire MUD configure le commutateur le plus proche du Thing. D'autres systèmes peuvent également être configurés.

7. Lorsque le Thing se déconnecte, la politique est supprimée.