1. Introduction (Einführung)

Das Internet wurde größtenteils für Allzweckcomputer konstruiert, also Geräte, die für einen Zweck verwendet werden können, der von den Eigentümern des Geräts festgelegt wird. In [RFC1984] wurde angenommen, dass ein Endgerät am besten in der Lage ist, sich selbst zu schützen. Dies war sinnvoll, als das typische Gerät eine Workstation oder ein Mainframe war, und es ist auch heute noch für Allzweck-Computing-Geräte sinnvoll, einschließlich Laptops, Smartphones und Tablets.

[RFC7452] diskutiert Entwurfsmuster für intelligente Objekte und stellt Fragen dazu. Lassen Sie uns dann eine Gruppe von Objekten postulieren, die ausdrücklich nicht für Allzweck-Computing-Aufgaben verwendet werden sollen. Diese Geräte, die dieses Memo als Things bezeichnet, haben einen spezifischen Zweck. Daher sind definitionsgemäß alle anderen Verwendungen nicht beabsichtigt. Wenn eine kleine Anzahl von Kommunikationsmustern aus dieser kleinen Anzahl von Verwendungen folgt, kann die Kombination dieser beiden Aussagen als Manufacturer Usage Description (MUD) neu formuliert werden, die an verschiedenen Punkten innerhalb eines Netzwerks angewendet werden kann. MUD befasst sich in erster Linie mit Bedrohungen für das Gerät und nicht mit dem Gerät als Bedrohung. In einigen Fällen kann MUD jedoch auch im letzteren Fall einen gewissen Schutz bieten, abhängig davon, wie die MUD-URL kommuniziert wird und wie Geräte und ihre Kommunikation authentifiziert werden.

Wir verwenden den Begriff "Hersteller" in diesem Kontext locker, um die Entität oder Organisation zu bezeichnen, die angibt, wie ein Gerät verwendet werden soll. Im Kontext einer Glühbirne könnte dies tatsächlich der Glühbirnenhersteller sein. Im Kontext eines intelligenteren Geräts mit einem integrierten Linux-Stack könnte es ein Integrator dieses Geräts sein. Die wichtigsten Punkte sind, dass das Gerät selbst einem begrenzten Zweck dient und dass in der Lieferkette dieses Geräts eine Organisation existiert, die die Verantwortung dafür übernimmt, das Netzwerk über diesen Zweck zu informieren.

Die Absicht von MUD besteht darin, Folgendes bereitzustellen:

Die Angriffsfläche eines Geräts erheblich auf die vom Hersteller beabsichtigten Kommunikationen zu reduzieren.
Ein Mittel zur Skalierung von Netzwerkrichtlinien auf die ständig wachsende Anzahl von Gerätetypen im Netzwerk bereitzustellen.
Ein Mittel bereitzustellen, um zumindest einige Schwachstellen auf eine Weise zu beheben, die schneller ist als die Zeit, die zum Aktualisieren von Systemen erforderlich sein könnte. Dies gilt insbesondere für Systeme, die nicht mehr unterstützt werden.
Die Implementierungskosten eines solchen Systems auf ein absolutes Minimum zu beschränken.
Ein Mittel zur Erweiterbarkeit für Hersteller bereitzustellen, um andere Gerätefähigkeiten oder -anforderungen auszudrücken.

MUD besteht aus drei architektonischen Bausteinen:

Eine URL, die zum Auffinden einer Beschreibung verwendet werden kann;
Die Beschreibung selbst, einschließlich ihrer Interpretation; und
Ein Mittel für lokale Netzwerkverwaltungssysteme zum Abrufen der Beschreibung.

MUD ist am effektivsten, wenn das Netzwerk in der Lage ist, die entfernten Endpunkte, mit denen Things kommunizieren, auf irgendeine Weise zu identifizieren.

In dieser Spezifikation beschreiben wir jeden dieser Bausteine und wie sie zusammen verwendet werden sollen. Sie können jedoch auch unabhängig von dieser Spezifikation separat von lokalen Bereitstellungen für ihre eigenen Zwecke verwendet werden.

1.1. What MUD Doesn't Do (Was MUD nicht tut)

MUD ist nicht dazu gedacht, die Netzwerkautorisierung von Allzweckcomputern zu adressieren, da ihre Hersteller kein spezifisches Kommunikationsmuster vorstellen können, das beschrieben werden könnte. Darüber hinaus können selbst solche Geräte, die einen einzelnen oder eine geringe Anzahl von Verwendungen haben, sehr breite Kommunikationsmuster aufweisen. MUD allein ist auch nicht für sie geeignet.

Obwohl MUD Netzwerkadministratoren einen gewissen zusätzlichen Schutz bieten kann, wenn Geräteschwachstellen bestehen, wird es niemals die Notwendigkeit für Hersteller ersetzen, Schwachstellen zu patchen.

Schließlich, egal was der Hersteller in einer MUD-Datei spezifiziert, dies sind keine Direktiven, sondern Vorschläge. Wie sie lokal instanziiert werden, hängt von vielen Faktoren ab und liegt letztendlich beim lokalen Netzwerkadministrator, der entscheiden muss, was unter bestimmten Umständen angemessen ist.

1.2. A Simple Example (Ein einfaches Beispiel)

Eine Glühbirne ist dazu bestimmt, einen Raum zu beleuchten. Sie kann über das Netzwerk ferngesteuert werden und kann einen Rendezvous-Dienst nutzen (auf den über eine Anwendung auf einem Smartphone zugegriffen werden kann). Was wir über diese Glühbirne sagen können, ist, dass jeder andere Netzwerkzugriff unerwünscht ist. Sie wird keinen Nachrichtendienst kontaktieren, nicht mit dem Kühlschrank sprechen, und sie benötigt weder einen Drucker noch andere Geräte. Sie hat keine Freunde in sozialen Netzwerken. Daher wird die Anwendung einer Zugriffsliste auf sie, die besagt, dass sie nur eine Verbindung zum einzelnen Rendezvous-Dienst herstellt, ihre Funktion nicht beeinträchtigen; gleichzeitig ermöglicht dies dem Netzwerk, der Glühbirne und anderen Geräten eine zusätzliche Schutzschicht zu bieten.

1.3. Terminology (Terminologie)

MUD: Manufacturer Usage Description (Herstellerverwendungsbeschreibung).

MUD file (MUD-Datei): Eine Datei, die YANG-basiertes JSON enthält, das ein Thing und zugehöriges vorgeschlagenes spezifisches Netzwerkverhalten beschreibt.

MUD file server (MUD-Dateiserver): Ein Webserver, der eine MUD-Datei hostet.

MUD manager (MUD-Manager): Das System, das die MUD-Datei vom MUD-Server anfordert und empfängt. Nachdem es eine MUD-Datei verarbeitet hat, kann es Änderungen an relevanten Netzwerkelementen veranlassen.

MUD controller (MUD-Controller): Ein Synonym, das in der Vergangenheit für MUD-Manager verwendet wurde.

MUD URL: Eine URL, die vom MUD-Manager verwendet werden kann, um die MUD-Datei zu empfangen.

Thing: Das Gerät, das eine MUD-URL aussendet.

Manufacturer (Hersteller): Die Entität, die das Thing so konfiguriert, dass es die MUD-URL aussendet, und diejenige, die eine Empfehlung in einer MUD-Datei vorschlägt. Der Hersteller ist möglicherweise nicht immer die Entität, die ein Thing konstruiert. Es könnte beispielsweise ein Systemintegrator oder sogar ein Komponentenanbieter sein.

Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind wie in BCP 14 [RFC2119] [RFC8174] beschrieben zu interpretieren, wenn und nur wenn sie in Großbuchstaben erscheinen, wie hier gezeigt.

1.4. Determining Intended Use (Bestimmung der beabsichtigten Verwendung)

Der Begriff der beabsichtigten Verwendung ist an sich nicht neu. Netzwerkadministratoren wenden täglich Zugriffslisten an, um nur eine solche Verwendung zu ermöglichen. Dieser Begriff der Whitelist wurde von Chapman und Zwicky in [FW95] gut beschrieben. Profilierungssysteme, die Heuristiken verwenden, um Systemtypen zu identifizieren, existieren ebenfalls seit Jahren.

Ein Thing könnte dem Netzwerk ebenso leicht mitteilen, welche Art von Zugriff es benötigt, ohne darauf einzugehen, welche Art von System es ist. Dies wäre im Effekt das Gegenteil von [RFC7488]. Bei der Suche nach einer allgemeinen Lösung gehen wir jedoch davon aus, dass ein Gerät Funktionen implementiert, die zur Erfüllung seines begrenzten Zwecks erforderlich sind. Dies ist eine grundlegende wirtschaftliche Einschränkung. Sofern das Netzwerk den Zugriff auf ein solches Gerät nicht verweigert, hätten seine Entwickler keinen Grund, dem Netzwerk Informationen bereitzustellen. Bis heute hat sich diese Behauptung als wahr erwiesen.

1.5. Finding a Policy: The MUD URL (Finden einer Richtlinie: Die MUD-URL)

Unsere Arbeit beginnt damit, dass das Gerät einen Universal Resource Locator (URL) [RFC3986] aussendet. Diese URL dient sowohl zur Klassifizierung des Gerätetyps als auch zur Bereitstellung eines Mittels zum Auffinden einer Richtliniendatei.

MUD-URLs MÜSSEN das "https"-Schema [RFC7230] verwenden.

In diesem Memo sind drei Mittel definiert, um die MUD-URL auszusenden, wie folgt:

Eine DHCP-Option [RFC2131] [RFC8415], die der DHCP-Client verwendet, um den DHCP-Server zu informieren. Der DHCP-Server kann weitere Maßnahmen ergreifen, z. B. als MUD-Manager fungieren oder die MUD-URL an den MUD-Manager weitergeben.
Eine X.509-Einschränkung. Die IEEE hat IEEE 802.1AR [IEEE8021AR] entwickelt, um einen zertifikatbasierten Ansatz zur Kommunikation von Geräteeigenschaften bereitzustellen, der selbst auf [RFC5280] basiert. Die MUD-URL-Erweiterung ist nicht kritisch, wie von IEEE 802.1AR gefordert. Verschiedene Mittel können verwendet werden, um dieses Zertifikat zu kommunizieren, einschließlich des Tunnel Extensible Authentication Protocol (TEAP) [RFC7170].
Schließlich ist ein Link Layer Discovery Protocol (LLDP) Frame definiert [IEEE8021AB].

Es ist möglich, dass es andere Mittel gibt, mit denen eine MUD-URL von einem Netzwerk erlernt werden kann. Beispielsweise können einige Geräte bereits im Feld sein oder eine sehr begrenzte Fähigkeit haben, eine MUD-URL zu kommunizieren, und dennoch können sie durch einige Mittel identifiziert werden, wie z. B. eine Seriennummer oder einen öffentlichen Schlüssel. In diesen Fällen können Hersteller möglicherweise diese Kennungen bestimmten MUD-URLs (oder sogar den Dateien selbst) zuordnen. Ebenso können alternative Auflösungsmechanismen für Situationen verfügbar sein, in denen die Internetverbindung begrenzt ist oder nicht existiert. Solche Mechanismen werden in diesem Memo nicht beschrieben, aber sie sind möglich. Implementierer werden ermutigt, Flexibilität bei der Erlernbarkeit von MUD-URLs zu ermöglichen.

1.6. Processing of the MUD URL (Verarbeitung der MUD-URL)

MUD-Manager, die dazu in der Lage sind, SOLLTEN MUD-URLs und Signaturdateien gemäß [RFC7230] unter Verwendung der GET-Methode [RFC7231] abrufen. Sie MÜSSEN das Zertifikat unter Verwendung der Regeln in [RFC2818], Abschnitt 3.1, validieren.

Anfragen für MUD-URLs SOLLTEN ein "Accept"-Header-Feld ([RFC7231], Abschnitt 5.3.2) mit "application/mud+json", ein "Accept-Language"-Header-Feld ([RFC7231], Abschnitt 5.3.5) und ein "User-Agent"-Header-Feld ([RFC7231], Abschnitt 5.5.3) enthalten.

MUD-Manager SOLLTEN 3xx-Antwortstatuscodes automatisch verarbeiten.

Wenn ein MUD-Manager keine MUD-URL abrufen kann, KÖNNEN andere Mittel verwendet werden, um MUD-Dateien und zugehörige Signaturdateien zu importieren. Solange die Signatur der Datei validiert werden kann, kann die Datei verwendet werden. In solchen Umgebungen SOLLTEN Controller Administratoren warnen, wenn der Ablauf der Cache-Gültigkeit naht, damit sie nach neuen Dateien suchen können.

Es kann sein, dass ein MUD-Manager zu einem bestimmten Zeitpunkt keine MUD-Datei abrufen kann. Sollte ein MUD-Manager eine MUD-Datei nicht abrufen können, SOLLTE er die vorhandene zumindest für eine Zeit als sicher betrachten. Nach einiger Zeit SOLLTE er protokollieren, dass er die Datei nicht abrufen konnte. Es kann sehr gute Gründe für solche Fehler geben, einschließlich der Möglichkeit, dass sich der MUD-Manager in einer Offline-Umgebung befindet, die lokale Internetverbindung ausgefallen ist oder die entfernte Internetverbindung ausgefallen ist. Es ist auch möglich, dass ein Angreifer versucht, die Bereitstellung eines Geräts zu stören. Wie mit solchen Umständen umzugehen ist, ist eine lokale Entscheidung.

1.7. Types of Policies (Arten von Richtlinien)

Wenn die MUD-URL aufgelöst wird, ruft der MUD-Manager eine Datei ab, die beschreibt, welche Art von Kommunikation ein Gerät haben soll. Der Hersteller kann entweder bestimmte Hosts für cloudbasierte Dienste oder bestimmte Klassen für den Zugriff innerhalb eines Betriebsnetzwerks angeben. Ein Beispiel für eine Klasse könnte "Geräte eines bestimmten Herstellertyps" sein, wobei der Herstellertyp selbst einfach durch die Autoritätskomponente (z. B. den Domänennamen) der MUD-URL angegeben wird. Ein weiteres Beispiel könnte sein, lokalen Zugriff zuzulassen oder zu verweigern. Genau wie andere Richtlinien können diese kombiniert werden. Zum Beispiel:

Zugriff auf Geräte desselben Herstellers zulassen
Zugriff auf und von Controllern über das Constrained Application Protocol (COAP) [RFC7252] zulassen
Zugriff auf lokales DNS/NTP zulassen
Alle anderen Zugriffe verweigern

Ein Drucker könnte eine Beschreibung haben, die besagt:

Zugriff für Port IPP oder Port LPD zulassen
Lokalen Zugriff für Port HTTP zulassen
Alle anderen Zugriffe verweigern

Auf diese Weise kann jeder auf dem Drucker drucken, aber für die Verwaltungsschnittstelle wäre lokaler Zugriff erforderlich.

Die abgerufenen Dateien sollen eng mit bestehenden Netzwerkarchitekturen abgestimmt sein, damit sie einfach bereitzustellen sind. Wir verwenden YANG [RFC7950], weil es genaue und angemessene Modelle für die Verwendung durch Netzwerkgeräte bereitstellt. JSON [RFC8259] wird als Serialisierungsformat für Kompaktheit und Lesbarkeit im Vergleich zu XML verwendet. Andere Formate können mit späteren Versionen von MUD gewählt werden.

Während sich die hier gegebenen Richtlinienbeispiele auf Zugriffskontrolle konzentrieren, ist dies nicht der einzige Fokus. Durch die Strukturierung des in diesem Dokument beschriebenen Modells mit klaren Erweiterungspunkten könnten andere Beschreibungen enthalten sein. Eine, die häufig in den Sinn kommt, ist Quality of Service.

Die hier spezifizierten YANG-Module sind Erweiterungen von [RFC8519]. Die Erweiterungen dieses Modells ermöglichen es einem Hersteller, Klassen von Systemen auszudrücken, die ein Hersteller für die ordnungsgemäße Funktion des Geräts als notwendig erachtet. Zwei Module sind spezifiziert. Das erste Modul spezifiziert ein Mittel, mit dem Domänennamen in Access Control Lists (ACLs) verwendet werden können, damit Geräte, die ihre Controller in der Cloud haben, mit Domänennamen angemessen autorisiert werden können, wobei die Zuordnung dieser Namen zu Adressen sich schnell ändern kann.

Das andere Modul abstrahiert IP-Adressen in bestimmte Klassen, die durch lokale Verarbeitung in tatsächliche IP-Adressen instanziiert werden. Durch diese Klassen können Hersteller angeben, wie das Gerät kommunizieren soll, sodass Netzwerkelemente von lokalen Systemen konfiguriert werden können, die über lokales topologisches Wissen verfügen. Das heißt, die Bereitstellung füllt die vom Hersteller spezifizierten Klassen auf. Die folgenden Abstraktionen werden wie folgt auf null oder mehr Hosts abgebildet:

Manufacturer (Hersteller): Ein von einem bestimmten Hersteller hergestelltes Gerät, identifiziert durch die Autoritätskomponente seiner MUD-URL.

same-manufacturer (gleicher Hersteller): Geräte, die dieselbe Autoritätskomponente ihrer MUD-URL haben.

controller (Controller): Geräte, die der lokale Netzwerkadministrator zur bestimmten Klasse zulässt.

my-controller (mein Controller): Geräte, die als Controller für die vom Thing ausgesendete MUD-URL dienen sollen.

local (lokal): Die Klasse von IP-Adressen, die innerhalb einer administrativen Grenze gültig sind. Standardmäßig wird vorgeschlagen, dass dies das lokale Subnetz ist.

Die "Hersteller"-Klassen können vom Hersteller leicht spezifiziert werden, während Controller-Klassen ursprünglich vom Administrator spezifiziert werden sollten.

Da Hersteller nicht wissen, wer ihre Geräte verwenden wird, ist es wichtig, dass die in Verwendungsbeschreibungen referenzierte Funktionalität relativ allgegenwärtig und ausgereift ist. Aus diesen Gründen ist die YANG-basierte Konfiguration in einer MUD-Datei auf die Module beschränkt, die entweder in diesem Dokument spezifiziert oder referenziert sind oder in dokumentierten Erweiterungen spezifiziert sind.

1.8. The Manufacturer Usage Description Architecture (Die Manufacturer Usage Description Architektur)

Mit diesen Komponenten haben wir nun die Grundlage für eine Architektur. Dies führt uns zu ASCII-Kunst.

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

Abbildung 1: MUD-Architektur

Im obigen Diagramm sammelt der Switch oder Router MUD-URLs und leitet sie zur Verarbeitung an den MUD-Manager (ein Netzwerkverwaltungssystem) weiter. Dies geschieht auf unterschiedliche Weise, abhängig davon, wie die URL kommuniziert wird. Im Fall von DHCP könnte beispielsweise der DHCP-Server die URL empfangen und dann verarbeiten. Im Fall von IEEE 802.1X [IEEE8021X] würde der Switch die URL über ein Zertifikat über das Extensible Authentication Protocol (EAP) über Radius [RFC3748] zum Authentifizierungsserver übertragen, der sie dann verarbeiten würde. Eine Methode hierfür ist TEAP, wie in [RFC7170] beschrieben. Die Zertifikatserweiterung wird unten beschrieben.

Die vom MUD-Dateiserver zurückgegebenen Informationen sind gültig, solange das Thing verbunden ist. Es gibt kein Ablaufdatum. Wenn der MUD-Manager jedoch festgestellt hat, dass sich die MUD-Datei für ein Thing geändert hat, SOLLTE er die Richtlinie zeitnah aktualisieren, unter Berücksichtigung des in einer Bereitstellung erforderlichen Genehmigungsablaufs. Auf diese Weise können neue Empfehlungen des Herstellers zeitnah verarbeitet werden.

Die vom MUD-Dateiserver (einem Webserver) zurückgegebenen Informationen sind für die Dauer der Verbindung des Things oder wie in der Beschreibung angegeben gültig. Wenn das Thing also getrennt wird, kann jede zugehörige Konfiguration im Switch entfernt werden. Ebenso kann die Beschreibung von Zeit zu Zeit aktualisiert werden, basierend auf neuen Fähigkeiten oder Kommunikationsmustern oder Schwachstellen.

Der Webserver wird typischerweise vom oder im Auftrag des Herstellers betrieben. Sein Domänenname ist der der in der MUD-URL gefundenen Autorität. Für Legacy-Fälle, in denen Things keine URL aussenden können, kann der Switch diese proxyen, wenn er in der Lage ist, die entsprechende URL zu bestimmen. In einem trivialen Fall könnte er eine MUD-URL auf einem Switch-Port fest codieren oder eine Zuordnung von einem verfügbaren Identifikator wie einer L2-Adresse oder einem Zertifikat-Hash zu einer MUD-URL.

Die Rolle des MUD-Managers in dieser Umgebung besteht darin, Folgendes zu tun:

MUD-URLs empfangen,
MUD-Dateien abrufen,
Abstraktionen in den MUD-Dateien in spezifische Netzwerkelementkonfiguration übersetzen,
erforderliche Zuordnungen der Abstraktionen pflegen und aktualisieren, und
Netzwerkelemente mit entsprechender Konfiguration aktualisieren.

Ein MUD-Manager kann eine Komponente eines Authentication, Authorization, and Accounting (AAA) Systems oder eines Netzwerkverwaltungssystems sein. Die Kommunikation innerhalb dieser Systeme und von diesen Systemen zu Netzwerkelementen liegt außerhalb des Umfangs dieses Memos.

1.9. Order of Operations (Reihenfolge der Operationen)

Wie oben erwähnt, enthält MUD architektonische Bausteine, sodass die Reihenfolge der Operationen variieren kann. Hier ist jedoch ein klares beabsichtigtes Beispiel:

Thing sendet eine URL aus.
Diese URL wird vom nächsten Switch an einen MUD-Manager weitergeleitet (wie dies geschieht, hängt von der Art und Weise ab, wie die MUD-URL ausgesendet wird).
Der MUD-Manager ruft die MUD-Datei und Signatur vom MUD-Dateiserver ab, vorausgesetzt, er hat noch keine Kopien. Nach der Validierung der Signatur kann er die URL gegen einen Web- oder Domain-Reputationsdienst testen, und er kann alle Hosts innerhalb der Datei gegen diese Reputationsdienste testen, wie er es für angemessen hält.
Der MUD-Manager kann den Administrator um Erlaubnis zum Hinzufügen des Things und der zugehörigen Richtlinie bitten. Wenn das Thing bekannt ist oder der Thing-Typ bekannt ist, kann er diesen Schritt überspringen.
Der MUD-Manager instanziiert die lokale Konfiguration basierend auf den in diesem Dokument definierten Abstraktionen.
Der MUD-Manager konfiguriert den Switch, der dem Thing am nächsten ist. Andere Systeme können ebenfalls konfiguriert werden.
Wenn das Thing die Verbindung trennt, wird die Richtlinie entfernt.