1. Introduction (Introduzione)

Internet è stato in gran parte costruito per computer di uso generale, cioè dispositivi (Device) che possono essere usati per uno scopo specificato da chi possiede il dispositivo. In [RFC1984] si presumeva che un dispositivo (Device) terminale fosse il più capace di proteggere se stesso. Ciò aveva senso quando il dispositivo tipico era una workstation o un mainframe, e continua ad avere senso per i dispositivi (Device) di calcolo di uso generale oggi, inclusi laptop, smartphone e tablet.

[RFC7452] discute schemi di progettazione per, e pone domande su, smart object. Postuliamo allora un gruppo di oggetti che non sono specificamente destinati a essere usati per compiti di calcolo di uso generale. Questi dispositivi (Device), a cui questo memo si riferisce come Thing, hanno uno scopo specifico. Per definizione, quindi, tutti gli altri usi non sono previsti. Se un piccolo numero di pattern di comunicazione deriva da quel piccolo numero di usi, la combinazione di queste due affermazioni può essere riformulata come una Manufacturer Usage Description (MUD) che può essere applicata in vari punti all'interno di una rete. MUD affronta principalmente le minacce al dispositivo (Device) piuttosto che il dispositivo (Device) come minaccia. In alcune circostanze, tuttavia, MUD può offrire una certa protezione anche nel secondo caso, a seconda di come l'URL MUD (MUD URL) è comunicato e come dispositivi (Device) e le loro comunicazioni sono autenticati.

Usiamo la nozione di «produttore» in senso lato in questo contesto per riferirci all'entità o organizzazione che dichiarerà come un dispositivo (Device) è destinato a essere usato. Ad esempio, nel contesto di una lampadina, potrebbe effettivamente essere il produttore (Manufacturer) della lampadina. Nel contesto di un dispositivo (Device) più «smart» con uno stack Linux integrato, potrebbe essere un integratore di quel dispositivo (Device). I punti chiave sono che il dispositivo (Device) stesso si assume abbia uno scopo limitato, e che esista un'organizzazione nella catena di fornitura di quel dispositivo (Device) che si assumerà la responsabilità di informare la rete su quello scopo.

L'intento di MUD è fornire quanto segue:

Ridurre sostanzialmente la superficie di minaccia su un dispositivo (Device) alle sole comunicazioni previste dal produttore (Manufacturer).
Fornire un mezzo per scalare le politiche di rete al numero sempre crescente di tipi di dispositivi (Device) nella rete.
Fornire un mezzo per affrontare almeno alcune vulnerabilità in un modo più rapido del tempo che potrebbe richiedere l'aggiornamento dei sistemi. Ciò sarà particolarmente vero per i sistemi che non sono più supportati.
Mantenere al minimo il costo di implementazione di un tale sistema.
Fornire un mezzo di estensibilità affinché i produttori (Manufacturer) possano esprimere altre capacità o requisiti del dispositivo (Device).

MUD consiste in tre blocchi architetturali:

Un URL che può essere usato per localizzare una descrizione;
La descrizione stessa, incluso come viene interpretata; e
Un mezzo affinché i sistemi di gestione della rete locale recuperino la descrizione.

MUD è più efficace quando la rete è in grado di identificare in qualche modo gli endpoint remoti con cui le Thing parleranno.

In questa specifica descriviamo ciascuno di questi blocchi e come sono destinati a essere usati insieme. Tuttavia, possono anche essere usati separatamente, indipendentemente da questa specifica, da distribuzioni locali per i propri scopi.

1.1. What MUD Doesn't Do (Cosa MUD non fa)

MUD non è destinato ad affrontare l'autorizzazione di rete dei computer di uso generale, poiché i loro produttori (Manufacturer) non possono concepire un pattern di comunicazione specifico da descrivere. Inoltre, anche quei dispositivi (Device) che hanno un uso singolo o un piccolo numero di usi possono avere pattern di comunicazione molto ampi. MUD da solo non è per loro né.

Sebbene MUD possa fornire agli amministratori di rete una protezione aggiuntiva quando esistono vulnerabilità del dispositivo (Device), non sostituirà mai la necessità per i produttori (Manufacturer) di correggere le vulnerabilità.

Infine, non importa cosa il produttore (Manufacturer) specifichi in un file MUD, queste non sono direttive, ma suggerimenti. Come vengono istanziate localmente dipenderà da molti fattori e sarà in ultima analisi a carico dell'amministratore di rete locale, che deve decidere cosa è appropriato in date circostanze.

1.2. A Simple Example (Un esempio semplice)

Una lampadina è destinata a illuminare una stanza. Può essere controllata da remoto tramite la rete e può fare uso di un servizio di rendezvous (al quale potrebbe accedere un'applicazione su uno smartphone). Ciò che possiamo dire di quella lampadina, allora, è che tutto l'altro accesso di rete è indesiderato. Non contatterà un servizio di notizie, né parlerà con il frigorifero, e non ha bisogno di una stampante o di altri dispositivi (Device). Non ha amici sui social network. Pertanto, applicarle una lista di accesso che stabilisce che si connetterà solo al singolo servizio di rendezvous non ostacolerà lo svolgimento della sua funzione; allo stesso tempo, ciò permetterà alla rete di fornire alla lampadina e ad altri dispositivi (Device) un ulteriore livello di protezione.

1.3. Terminology (Terminologia)

MUD: Manufacturer Usage Description (descrizione di utilizzo del produttore).

File MUD (MUD file): un file contenente JSON basato su YANG che descrive una Thing e il comportamento di rete specifico suggerito associato.

Server di file MUD (MUD file server): un server web che ospita un file MUD.

MUD manager: il sistema che richiede e riceve il file MUD dal server MUD. Dopo aver elaborato un file MUD, può indirizzare modifiche agli elementi di rete pertinenti.

MUD controller: un sinonimo usato in passato per MUD manager.

URL MUD (MUD URL): un URL che può essere usato dal MUD manager per ricevere il file MUD.

Thing: il dispositivo (Device) che emette un URL MUD (MUD URL).

Produttore (Manufacturer): l'entità che configura la Thing affinché emetta l'URL MUD (MUD URL) e colui che asserisce una raccomandazione in un file MUD. Il produttore (Manufacturer) potrebbe non essere sempre l'entità che costruisce una Thing. Potrebbe, ad esempio, essere un integratore di sistemi, o persino un fornitore di componenti.

Le parole chiave «MUST», «MUST NOT», «REQUIRED», «SHALL», «SHALL NOT», «SHOULD», «SHOULD NOT», «RECOMMENDED», «NOT RECOMMENDED», «MAY» e «OPTIONAL» in questo documento devono essere interpretate come descritto in BCP 14 [RFC2119] [RFC8174] quando, e solo quando, compaiono in tutte maiuscole, come mostrato qui.

1.4. Determining Intended Use (Determinazione dell'uso previsto)

La nozione di uso previsto non è di per sé nuova. Gli amministratori di rete applicano ogni giorno liste di accesso per consentire solo tale uso. Questa nozione di whitelist è stata ben descritta da Chapman e Zwicky in [FW95]. I sistemi di profiling che usano euristiche per identificare tipi di sistemi esistono da anni.

Una Thing potrebbe altrettanto facilmente dire alla rete che tipo di accesso richiede senza entrare in che tipo di sistema è. Ciò sarebbe, in effetti, il contrario di [RFC7488]. Cercando una soluzione generale, tuttavia, assumiamo che un dispositivo (Device) implementerà la funzionalità necessaria per adempiere al suo scopo limitato. Questo è un vincolo economico di base. A meno che la rete non rifiutasse l'accesso a un tale dispositivo (Device), i suoi sviluppatori non avrebbero motivo di fornire alla rete alcuna informazione. Ad oggi, tale asserzione si è dimostrata vera.

1.5. Finding a Policy: The MUD URL (Trovare una politica: l'URL MUD)

Il nostro lavoro inizia con il dispositivo (Device) che emette un Universal Resource Locator (URL) [RFC3986]. Questo URL serve sia a classificare il tipo di dispositivo (Device) sia a fornire un mezzo per localizzare un file di politica.

Gli URL MUD (MUD URLs) DEVONO usare lo schema «https» [RFC7230].

In questo memo sono definiti tre mezzi per emettere l'URL MUD (MUD URL), come segue:

Un'opzione DHCP [RFC2131] [RFC8415] che il client DHCP usa per informare il server DHCP. Il server DHCP può intraprendere ulteriori azioni, come agire come MUD manager o inoltrare l'URL MUD (MUD URL) al MUD manager.
Un vincolo X.509. L'IEEE ha sviluppato IEEE 802.1AR [IEEE8021AR] per fornire un approccio basato su certificato per comunicare le caratteristiche del dispositivo (Device), che a sua volta si basa su [RFC5280]. L'estensione URL MUD (MUD URL) è non critica, come richiesto da IEEE 802.1AR. Vari mezzi possono essere usati per comunicare quel certificato, incluso il Tunnel Extensible Authentication Protocol (TEAP) [RFC7170].
Infine, è definito un frame Link Layer Discovery Protocol (LLDP) [IEEE8021AB].

È possibile che possano esistere altri mezzi affinché un URL MUD (MUD URL) sia appreso da una rete. Ad esempio, alcuni dispositivi (Device) possono già essere schierati o avere capacità molto limitate di comunicare un URL MUD (MUD URL), e tuttavia possono essere identificati tramite qualche mezzo, come un numero di serie o una chiave pubblica. In questi casi, i produttori (Manufacturer) possono essere in grado di mappare tali identificatori a particolari URL MUD (MUD URL) (o persino ai file stessi). Allo stesso modo, possono esistere meccanismi di risoluzione alternativi per situazioni in cui la connettività Internet è limitata o non esiste. Tali meccanismi non sono descritti in questo memo, ma sono possibili. Gli implementatori sono incoraggiati a consentire la flessibilità su come gli URL MUD (MUD URL) possono essere appresi.

1.6. Processing of the MUD URL (Elaborazione dell'URL MUD)

I MUD manager che sono in grado di farlo DOVREBBERO recuperare URL MUD (MUD URL) e file di firma come da [RFC7230], usando il metodo GET [RFC7231]. DEVONO convalidare il certificato usando le regole in [RFC2818], Sezione 3.1.

Le richieste per URL MUD (MUD URL) DOVREBBERO includere un campo di intestazione «Accept» ([RFC7231], Sezione 5.3.2) contenente «application/mud+json», un campo di intestazione «Accept-Language» ([RFC7231], Sezione 5.3.5) e un campo di intestazione «User-Agent» ([RFC7231], Sezione 5.5.3).

I MUD manager DOVREBBERO elaborare automaticamente i codici di stato di risposta 3xx.

Se un MUD manager non è in grado di recuperare un URL MUD (MUD URL), si PUÒ ricorrere ad altri mezzi per importare file MUD e file di firma associati. Finché la firma del file può essere validata, il file può essere usato. In tali ambienti, i controller DOVREBBERO avvisare gli amministratori quando sta per scadere la validità della cache affinché possano verificare la presenza di nuovi file.

Potrebbe non essere possibile per un MUD manager recuperare un file MUD in un dato momento. Se un MUD manager non riesce a recuperare un file MUD, DOVREBBE considerare quello esistente sicuro da usare, almeno per un tempo. Dopo un certo periodo, DOVREBBE registrare che non è stato in grado di recuperare il file. Possono esserci ottime ragioni per tali fallimenti, inclusa la possibilità che il MUD manager sia in un ambiente offline, la connessione Internet locale sia fallita o la connessione Internet remota sia fallita. È anche possibile che un attaccante stia tentando di interferire con la distribuzione di un dispositivo (Device). Come gestire tali circostanze è una decisione locale.

1.7. Types of Policies (Tipi di politiche)

Quando l'URL MUD (MUD URL) è risolto, il MUD manager recupera un file che descrive che tipo di comunicazioni un dispositivo (Device) è progettato per avere. Il produttore (Manufacturer) può specificare host specifici per servizi cloud o certe classi per l'accesso all'interno di una rete operativa. Un esempio di classe potrebbe essere «dispositivi (Device) di un tipo di produttore (Manufacturer) specificato», dove il tipo di produttore (Manufacturer) stesso è indicato semplicemente dal componente authority (ad esempio, il nome di dominio) dell'URL MUD (MUD URL). Un altro esempio potrebbe essere consentire o negare l'accesso locale. Come altre politiche, queste possono essere combinate. Ad esempio:

Consentire l'accesso a dispositivi (Device) dello stesso produttore (Manufacturer)
Consentire l'accesso da e verso controller tramite il Constrained Application Protocol (COAP) [RFC7252]
Consentire l'accesso a DNS/NTP locali
Negare tutto l'altro accesso

Una stampante potrebbe avere una descrizione che stabilisce:

Consentire l'accesso per la porta IPP o la porta LPD
Consentire l'accesso locale per la porta HTTP
Negare tutto l'altro accesso

In questo modo, chiunque può stampare sulla stampante, ma sarebbe richiesto l'accesso locale per l'interfaccia di gestione.

I file che vengono recuperati sono destinati ad essere strettamente allineati alle architetture di rete esistenti affinché siano facili da distribuire. Facciamo uso di YANG [RFC7950] perché fornisce modelli accurati e adeguati per l'uso da parte dei dispositivi (Device) di rete. JSON [RFC8259] è usato come formato di serializzazione per compattezza e leggibilità, rispetto a XML. Altri formati possono essere scelti con versioni successive di MUD.

Sebbene gli esempi di politica dati qui si concentrino sul controllo degli accessi, questo non è destinato a essere l'unico focus. Strutturando il modello descritto in questo documento con punti di estensione chiari, potrebbero essere incluse altre descrizioni. Una che spesso viene in mente è la qualità del servizio.

I moduli YANG specificati qui sono estensioni di [RFC8519]. Le estensioni a questo modello consentono a un produttore (Manufacturer) di esprimere classi di sistemi che un produttore (Manufacturer) ritiene necessarie per il corretto funzionamento del dispositivo (Device). Sono specificati due moduli. Il primo modulo specifica un mezzo affinché i nomi di dominio siano usati nelle Access Control List (ACL) affinché i dispositivi (Device) che hanno i loro controller nel cloud possano essere autorizzati appropriatamente con nomi di dominio, dove la mappatura di tali nomi agli indirizzi può cambiare rapidamente.

L'altro modulo astrae gli indirizzi IP in certe classi che sono istanziate in indirizzi IP effettivi tramite elaborazione locale. Tramite queste classi, i produttori (Manufacturer) possono specificare come il dispositivo (Device) è progettato per comunicare, affinché gli elementi di rete possano essere configurati da sistemi locali che hanno conoscenza topologica locale. Cioè, la distribuzione popola le classi che il produttore (Manufacturer) specifica. Le astrazioni sotto mappano a zero o più host, come segue:

Manufacturer: un dispositivo (Device) realizzato da un particolare produttore (Manufacturer), come identificato dal componente authority del suo URL MUD (MUD URL).

same-manufacturer: dispositivi (Device) che hanno lo stesso componente authority del loro URL MUD (MUD URL).

controller: dispositivi (Device) che l'amministratore di rete locale ammette alla classe particolare.

my-controller: dispositivi (Device) destinati a servire come controller per l'URL MUD (MUD URL) che la Thing ha emesso.

local: la classe di indirizzi IP che sono limitati entro qualche confine amministrativo. Per impostazione predefinita, si suggerisce che questa sia la sottorete locale.

Le classi «manufacturer» possono essere facilmente specificate dal produttore (Manufacturer), mentre le classi controller sono inizialmente concepite per essere specificate dall'amministratore.

Poiché i produttori (Manufacturer) non sanno chi userà i loro dispositivi (Device), è importante che la funzionalità referenziata nelle descrizioni di utilizzo sia relativamente ubiqua e matura. Per queste ragioni, la configurazione basata su YANG in un file MUD è limitata ai moduli specificati o referenziati in questo documento, o specificati in estensioni documentate.

1.8. The Manufacturer Usage Description Architecture (Architettura della descrizione di utilizzo del produttore)

Con questi componenti esposti, abbiamo ora la base per un'architettura. Ciò ci porta all'arte ASCII.

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

Figura 1: Architettura MUD

Nel diagramma sopra, lo switch o il router raccoglie URL MUD (MUD URL) e li inoltra al MUD manager (un sistema di gestione di rete) per l'elaborazione. Ciò avviene in modi diversi, a seconda di come l'URL è comunicato. Ad esempio, nel caso di DHCP, il server DHCP potrebbe ricevere l'URL e poi elaborarlo. Nel caso di IEEE 802.1X [IEEE8021X], lo switch porterebbe l'URL tramite un certificato al server di autenticazione tramite l'Extensible Authentication Protocol (EAP) su Radius [RFC3748], che poi lo elaborerebbe. Un metodo per farlo è TEAP, come descritto in [RFC7170]. L'estensione del certificato è descritta sotto.

Le informazioni restituite dal server di file MUD sono valide finché la Thing è connessa. Non c'è scadenza. Tuttavia, se il MUD manager ha rilevato che il file MUD per una Thing è cambiato, DOVREBBE aggiornare la politica prontamente, tenendo conto di qualunque flusso di approvazione richiesto in una distribuzione. In questo modo, nuove raccomandazioni dal produttore (Manufacturer) possono essere elaborate in modo tempestivo.

Le informazioni restituite dal server di file MUD (un server web) sono valide per la durata della connessione della Thing, o come specificato nella descrizione. Così, se la Thing è disconnessa, qualsiasi configurazione associata nello switch può essere rimossa. Allo stesso modo, di tanto in tanto la descrizione può essere aggiornata, in base a nuove capacità o pattern di comunicazione o vulnerabilità.

Il server web è tipicamente eseguito dal o per conto del produttore (Manufacturer). Il suo nome di dominio è quello dell'authority trovato nell'URL MUD (MUD URL). Per casi legacy in cui le Thing non possono emettere un URL, se lo switch è in grado di determinare l'URL appropriato, può fare da proxy. In un caso banale, può hardcodare un URL MUD (MUD URL) su una porta del switch o una mappa da qualche identificatore disponibile come un indirizzo L2 o hash del certificato a un URL MUD (MUD URL).

Il ruolo del MUD manager in questo ambiente è fare quanto segue:

ricevere URL MUD (MUD URL),
recuperare file MUD,
tradurre le astrazioni nei file MUD in configurazione specifica degli elementi di rete,
mantenere e aggiornare qualsiasi mappatura richiesta delle astrazioni, e
aggiornare gli elementi di rete con la configurazione appropriata.

Un MUD manager può essere un componente di un sistema Authentication, Authorization, and Accounting (AAA) o di un sistema di gestione di rete. La comunicazione all'interno di tali sistemi e da tali sistemi agli elementi di rete è al di fuori dell'ambito di questo memo.

1.9. Order of Operations (Ordine delle operazioni)

Come menzionato sopra, MUD contiene blocchi architetturali, quindi l'ordine delle operazioni può variare. Tuttavia, ecco un esempio chiaro previsto:

La Thing emette un URL.
Quell'URL è inoltrato a un MUD manager dallo switch più vicino (come ciò avviene dipende dal modo in cui l'URL MUD (MUD URL) è emesso).
Il MUD manager recupera il file MUD e la firma dal server di file MUD, assumendo che non abbia già copie. Dopo aver validato la firma, può testare l'URL contro un servizio di reputazione web o di dominio, e può testare qualsiasi host nel file contro tali servizi di reputazione, come ritiene opportuno.
Il MUD manager può interrogare l'amministratore per il permesso di aggiungere la Thing e la politica associata. Se la Thing è nota o il tipo di Thing è noto, può saltare questo passo.
Il MUD manager istanzia la configurazione locale basata sulle astrazioni definite in questo documento.
Il MUD manager configura lo switch più vicino alla Thing. Altri sistemi possono essere configurati pure.
Quando la Thing si disconnette, la politica è rimossa.