draft-ietf-opsawg-mud-14.txt   draft-ietf-opsawg-mud-15.txt 
Network Working Group E. Lear Network Working Group E. Lear
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track R. Droms Intended status: Standards Track R. Droms
Expires: July 28, 2018 Expires: July 29, 2018
D. Romascanu D. Romascanu
January 24, 2018 January 25, 2018
Manufacturer Usage Description Specification Manufacturer Usage Description Specification
draft-ietf-opsawg-mud-14 draft-ietf-opsawg-mud-15
Abstract Abstract
This memo specifies a component-based architecture for manufacturer This memo specifies a component-based architecture for manufacturer
usage descriptions (MUD). The goal of MUD is to provide a means for usage descriptions (MUD). The goal of MUD is to provide a means for
Things to signal to the network what sort of access and network Things to signal to the network what sort of access and network
functionality they require to properly function. The initial focus functionality they require to properly function. The initial focus
is on access control. Later work can delve into other aspects. is on access control. Later work can delve into other aspects.
This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, an This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, an
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 28, 2018. This Internet-Draft will expire on July 29, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 24 skipping to change at page 2, line 24
1.1. What MUD Doesn't Do . . . . . . . . . . . . . . . . . . . 4 1.1. What MUD Doesn't Do . . . . . . . . . . . . . . . . . . . 4
1.2. A Simple Example . . . . . . . . . . . . . . . . . . . . 5 1.2. A Simple Example . . . . . . . . . . . . . . . . . . . . 5
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Determining Intended Use . . . . . . . . . . . . . . . . 6 1.4. Determining Intended Use . . . . . . . . . . . . . . . . 6
1.5. Finding A Policy: The MUD URL . . . . . . . . . . . . . . 6 1.5. Finding A Policy: The MUD URL . . . . . . . . . . . . . . 6
1.6. Processing of the MUD URL . . . . . . . . . . . . . . . . 7 1.6. Processing of the MUD URL . . . . . . . . . . . . . . . . 7
1.7. Types of Policies . . . . . . . . . . . . . . . . . . . . 7 1.7. Types of Policies . . . . . . . . . . . . . . . . . . . . 7
1.8. The Manufacturer Usage Description Architecture . . . . . 9 1.8. The Manufacturer Usage Description Architecture . . . . . 9
1.9. Order of operations . . . . . . . . . . . . . . . . . . . 11 1.9. Order of operations . . . . . . . . . . . . . . . . . . . 11
2. The MUD Model and Semantic Meaning . . . . . . . . . . . . . 11 2. The MUD Model and Semantic Meaning . . . . . . . . . . . . . 11
2.1. The IETF-MUD YANG Module . . . . . . . . . . . . . . . . 12 2.1. The IETF-MUD YANG Module . . . . . . . . . . . . . . . . 13
3. Data Node Definitions . . . . . . . . . . . . . . . . . . . . 14 3. Data Node Definitions . . . . . . . . . . . . . . . . . . . . 14
3.1. mud-version . . . . . . . . . . . . . . . . . . . . . . . 14 3.1. mud-version . . . . . . . . . . . . . . . . . . . . . . . 14
3.2. to-device-policy and from-device-policy containers . . . 14 3.2. to-device-policy and from-device-policy containers . . . 15
3.3. last-update . . . . . . . . . . . . . . . . . . . . . . . 14 3.3. last-update . . . . . . . . . . . . . . . . . . . . . . . 15
3.4. cache-validity . . . . . . . . . . . . . . . . . . . . . 14 3.4. cache-validity . . . . . . . . . . . . . . . . . . . . . 15
3.5. is-supported . . . . . . . . . . . . . . . . . . . . . . 14 3.5. is-supported . . . . . . . . . . . . . . . . . . . . . . 15
3.6. systeminfo . . . . . . . . . . . . . . . . . . . . . . . 15 3.6. systeminfo . . . . . . . . . . . . . . . . . . . . . . . 15
3.7. extensions . . . . . . . . . . . . . . . . . . . . . . . 15 3.7. mfg-name, hardware-rev, software-rev, model-name
3.8. manufacturer . . . . . . . . . . . . . . . . . . . . . . 15 firmware-rev . . . . . . . . . . . . . . . . . . . . . . 16
3.9. same-manufacturer . . . . . . . . . . . . . . . . . . . . 15 3.8. extensions . . . . . . . . . . . . . . . . . . . . . . . 16
3.10. model . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.9. manufacturer . . . . . . . . . . . . . . . . . . . . . . 16
3.11. local-networks . . . . . . . . . . . . . . . . . . . . . 16 3.10. same-manufacturer . . . . . . . . . . . . . . . . . . . . 16
3.12. controller . . . . . . . . . . . . . . . . . . . . . . . 16 3.11. model . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.13. my-controller . . . . . . . . . . . . . . . . . . . . . . 16 3.12. local-networks . . . . . . . . . . . . . . . . . . . . . 17
3.14. direction-initiated . . . . . . . . . . . . . . . . . . . 16 3.13. controller . . . . . . . . . . . . . . . . . . . . . . . 17
4. Processing of the MUD file . . . . . . . . . . . . . . . . . 17 3.14. my-controller . . . . . . . . . . . . . . . . . . . . . . 17
5. What does a MUD URL look like? . . . . . . . . . . . . . . . 17 3.15. direction-initiated . . . . . . . . . . . . . . . . . . . 17
6. The MUD YANG Model . . . . . . . . . . . . . . . . . . . . . 18 4. Processing of the MUD file . . . . . . . . . . . . . . . . . 18
7. The Domain Name Extension to the ACL Model . . . . . . . . . 23 5. What does a MUD URL look like? . . . . . . . . . . . . . . . 18
7.1. src-dnsname . . . . . . . . . . . . . . . . . . . . . . . 24 6. The MUD YANG Model . . . . . . . . . . . . . . . . . . . . . 19
7.2. destination-dnsname . . . . . . . . . . . . . . . . . . . 24 7. The Domain Name Extension to the ACL Model . . . . . . . . . 25
7.3. The ietf-acldns Model . . . . . . . . . . . . . . . . . . 24 7.1. src-dnsname . . . . . . . . . . . . . . . . . . . . . . . 25
8. MUD File Example . . . . . . . . . . . . . . . . . . . . . . 26 7.2. dst-dnsname . . . . . . . . . . . . . . . . . . . . . . . 26
9. The MUD URL DHCP Option . . . . . . . . . . . . . . . . . . . 28 7.3. The ietf-acldns Model . . . . . . . . . . . . . . . . . . 26
9.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 29 8. MUD File Example . . . . . . . . . . . . . . . . . . . . . . 27
9.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 29 9. The MUD URL DHCP Option . . . . . . . . . . . . . . . . . . . 30
9.3. Relay Requirements . . . . . . . . . . . . . . . . . . . 30 9.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 30
9.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 31
10. The Manufacturer Usage Description (MUD) URL X.509 Extension 30 9.3. Relay Requirements . . . . . . . . . . . . . . . . . . . 31
11. The Manufacturer Usage Description LLDP extension . . . . . . 31 10. The Manufacturer Usage Description (MUD) URL X.509 Extension 31
12. Creating and Processing of Signed MUD Files . . . . . . . . . 33 11. The Manufacturer Usage Description LLDP extension . . . . . . 33
12.1. Creating a MUD file signature . . . . . . . . . . . . . 33 12. Creating and Processing of Signed MUD Files . . . . . . . . . 35
12.2. Verifying a MUD file signature . . . . . . . . . . . . . 33 12.1. Creating a MUD file signature . . . . . . . . . . . . . 35
13. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 34 12.2. Verifying a MUD file signature . . . . . . . . . . . . . 35
14. Deployment Considerations . . . . . . . . . . . . . . . . . . 34 13. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 36
15. Security Considerations . . . . . . . . . . . . . . . . . . . 35 14. Deployment Considerations . . . . . . . . . . . . . . . . . . 36
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 15. Security Considerations . . . . . . . . . . . . . . . . . . . 37
16.1. YANG Module Registrations . . . . . . . . . . . . . . . 37 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
16.2. DHCPv4 and DHCPv6 Options . . . . . . . . . . . . . . . 38 16.1. YANG Module Registrations . . . . . . . . . . . . . . . 39
16.3. PKIX Extensions . . . . . . . . . . . . . . . . . . . . 38 16.2. DHCPv4 and DHCPv6 Options . . . . . . . . . . . . . . . 40
16.4. Well Known URI Suffix . . . . . . . . . . . . . . . . . 38 16.3. PKIX Extensions . . . . . . . . . . . . . . . . . . . . 40
16.5. MIME Media-type Registration for MUD files . . . . . . . 38 16.4. Well Known URI Suffix . . . . . . . . . . . . . . . . . 40
16.6. LLDP IANA TLV Subtype Registry . . . . . . . . . . . . . 39 16.5. MIME Media-type Registration for MUD files . . . . . . . 40
16.7. The MUD Well Known Universal Resource Name (URNs) . . . 40 16.6. LLDP IANA TLV Subtype Registry . . . . . . . . . . . . . 41
16.8. Extensions Registry . . . . . . . . . . . . . . . . . . 40 16.7. The MUD Well Known Universal Resource Name (URNs) . . . 42
17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 16.8. Extensions Registry . . . . . . . . . . . . . . . . . . 42
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42
18.1. Normative References . . . . . . . . . . . . . . . . . . 41 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
18.2. Informative References . . . . . . . . . . . . . . . . . 43 18.1. Normative References . . . . . . . . . . . . . . . . . . 43
Appendix A. Changes from Earlier Versions . . . . . . . . . . . 45 18.2. Informative References . . . . . . . . . . . . . . . . . 45
Appendix B. Default MUD nodes . . . . . . . . . . . . . . . . . 48 Appendix A. Changes from Earlier Versions . . . . . . . . . . . 47
Appendix C. A Sample Extension: DETNET-indicator . . . . . . . . 52 Appendix B. Default MUD nodes . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 Appendix C. A Sample Extension: DETNET-indicator . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59
1. Introduction 1. Introduction
The Internet has largely been constructed for general purpose The Internet has largely been constructed for general purpose
computers, those devices that may be used for a purpose that is computers, those devices that may be used for a purpose that is
specified by those who own the device. [RFC1984] presumed that an specified by those who own the device. [RFC1984] presumed that an
end device would be most capable of protecting itself. This made end device would be most capable of protecting itself. This made
sense when the typical device was a workstation or a mainframe, and sense when the typical device was a workstation or a mainframe, and
it continues to make sense for general purpose computing devices it continues to make sense for general purpose computing devices
today, including laptops, smart phones, and tablets. today, including laptops, smart phones, and tablets.
skipping to change at page 12, line 22 skipping to change at page 12, line 22
further on. further on.
To provide the widest possible deployment, publishers of MUD files To provide the widest possible deployment, publishers of MUD files
SHOULD make use of the abstractions in this memo and avoid the use of SHOULD make use of the abstractions in this memo and avoid the use of
IP addresses. A MUD controller SHOULD NOT automatically implement IP addresses. A MUD controller SHOULD NOT automatically implement
any MUD file that contains IP addresses, especially those that might any MUD file that contains IP addresses, especially those that might
have local significance. The addressing of one side of an access have local significance. The addressing of one side of an access
list is implicit, based on whether it is applied as to-device-policy list is implicit, based on whether it is applied as to-device-policy
or from-device-policy. or from-device-policy.
With the exceptions of "name", "acl-type", "rule-name", and TCP and With the exceptions of "name" of the ACL, "type", "name" of the ACE,
UDP source and destination port information, publishers of MUD files and TCP and UDP source and destination port information, publishers
SHOULD limit the use of ACL model leaf nodes expressed to those found of MUD files SHOULD limit the use of ACL model leaf nodes expressed
in this specification. Absent any extensions, MUD files are assumed to those found in this specification. Absent any extensions, MUD
to implement only the following ACL model features: files are assumed to implement only the following ACL model features:
o match-on-ipv4, match-on-ipv6, match-on-tcp, match-on-udp, match- o match-on-ipv4, match-on-ipv6, match-on-tcp, match-on-udp, match-
on-icmp on-icmp
Furthermore, only "accept" or "drop" actions SHOULD be included. A Furthermore, only "accept" or "drop" actions SHOULD be included. A
MUD controller MAY choose to interpret "reject" as "drop". A MUD MUD controller MAY choose to interpret "reject" as "drop". A MUD
controller SHOULD ignore all other actions. controller SHOULD ignore all other actions. This is because
manufacturers do not have sufficient context within a local
deployment to know whether reject is appropriate. That is a decision
that should be left to a network administrator.
Given that MUD does not deal with interfaces, the support of the
"ietf-interfaces" module [RFC7223] is not required. Specifically,
the support of interface-related features and branches (e.g.,
interface-attachment and interface-stats) of the ACL YANG module is
not required.
In fact, MUD controllers MAY ignore any particular component of a In fact, MUD controllers MAY ignore any particular component of a
description or MAY ignore the description in its entirety, and SHOULD description or MAY ignore the description in its entirety, and SHOULD
carefully inspect all MUD descriptions. Publishers of MUD files MUST carefully inspect all MUD descriptions. Publishers of MUD files MUST
NOT include other nodes except as described in Section 3.7. See that NOT include other nodes except as described in Section 3.8. See that
section for more information. section for more information.
2.1. The IETF-MUD YANG Module 2.1. The IETF-MUD YANG Module
This module is structured into three parts: This module is structured into three parts:
o The first container "mud" holds information that is relevant to o The first container "mud" holds information that is relevant to
retrieval and validity of the MUD file itself, as well as policy retrieval and validity of the MUD file itself, as well as policy
intended to and from the Thing. intended to and from the Thing.
skipping to change at page 13, line 30 skipping to change at page 14, line 13
explained in [I-D.ietf-netmod-yang-tree-diagrams]. explained in [I-D.ietf-netmod-yang-tree-diagrams].
module: ietf-mud module: ietf-mud
+--rw mud! +--rw mud!
+--rw mud-version uint8 +--rw mud-version uint8
+--rw mud-url inet:uri +--rw mud-url inet:uri
+--rw last-update yang:date-and-time +--rw last-update yang:date-and-time
+--rw cache-validity? uint8 +--rw cache-validity? uint8
+--rw is-supported boolean +--rw is-supported boolean
+--rw systeminfo? inet:uri +--rw systeminfo? inet:uri
+--rw mfg-name? string
+--rw model-name? string
+--rw firmware-rev? string
+--rw software-rev? string
+--rw extensions* string +--rw extensions* string
+--rw from-device-policy +--rw from-device-policy
| +--rw access-lists | +--rw access-lists
| +--rw access-list* [name] | +--rw access-list* [name]
| +--rw name -> /acl:access-lists/acl/name | +--rw name -> /acl:access-lists/acl/name
+--rw to-device-policy +--rw to-device-policy
+--rw access-lists +--rw access-lists
+--rw access-list* [name] +--rw access-list* [name]
+--rw name -> /acl:access-lists/acl/name +--rw name -> /acl:access-lists/acl/name
augment /acl:access-lists/acl:acl/acl:aces/acl:ace/acl:matches: augment /acl:access-lists/acl:acl/acl:aces/acl:ace/acl:matches:
+--rw mud +--rw mud
+--rw manufacturer? inet:host +--rw manufacturer? inet:host
+--rw same-manufacturer? empty +--rw same-manufacturer? empty
+--rw model? inet:uri +--rw model? inet:uri
+--rw local-networks? empty +--rw local-networks? empty
+--rw controller? inet:uri +--rw controller? inet:uri
+--rw my-controller? empty +--rw my-controller? empty
augment /acl:access-lists/acl:acl/acl:aces/acl:ace/acl:matches augment /acl:access-lists/acl:acl/acl:aces/acl:ace
/acl:l4/acl:tcp: /acl:matches/acl:l4/acl:tcp:
+--rw direction-initiated? direction +--rw direction-initiated? direction
3. Data Node Definitions 3. Data Node Definitions
Note that in this section, when we use the term "match" we are Note that in this section, when we use the term "match" we are
referring to the ACL model "matches" node. referring to the ACL model "matches" node.
The following nodes are defined. The following nodes are defined.
3.1. mud-version 3.1. mud-version
skipping to change at page 15, line 15 skipping to change at page 16, line 5
3.6. systeminfo 3.6. systeminfo
This is a URL that points to a description of the Thing to be This is a URL that points to a description of the Thing to be
connected. The intent is for administrators to be able to see a connected. The intent is for administrators to be able to see a
localized name associated with the Thing. The referenced URL SHOULD localized name associated with the Thing. The referenced URL SHOULD
be a localized display string, and MAY be in either HTML or a raw be a localized display string, and MAY be in either HTML or a raw
UTF-8 text file. It SHOULD NOT exceed 60 characters worth of display UTF-8 text file. It SHOULD NOT exceed 60 characters worth of display
space (that is- what the administrator actually sees), but it MAY space (that is- what the administrator actually sees), but it MAY
contain links to other documents (presumably product documentation). contain links to other documents (presumably product documentation).
3.7. extensions 3.7. mfg-name, hardware-rev, software-rev, model-name firmware-rev
These optional fields are filled in as specified by
[I-D.ietf-netmod-entity]. Note that firmware-rev and software-rev
MUST NOT be populated in a MUD file if the device can be upgraded but
the MUD-URL cannot be. This would be the case, for instance, with
MUR-URLs that are contained in 802.1AR certificates.
3.8. extensions
This optional leaf-list names MUD extensions that are used in the MUD This optional leaf-list names MUD extensions that are used in the MUD
file. Note that NO MUD extensions may be used in a MUD file without file. Note that NO MUD extensions may be used in a MUD file without
the extensions being declared. Implementations MUST ignore any node the extensions being declared. Implementations MUST ignore any node
in this file that they do not understand. in this file that they do not understand.
Note that extensions can either extend the MUD file as described in Note that extensions can either extend the MUD file as described in
the previous paragraph, or they might reference other work. An the previous paragraph, or they might reference other work. An
extension example can be found in Appendix C. extension example can be found in Appendix C.
3.8. manufacturer 3.9. manufacturer
This node consists of a hostname that would be matched against the This node consists of a hostname that would be matched against the
authority component of another Thing's MUD URL. In its simplest form authority component of another Thing's MUD URL. In its simplest form
"manufacturer" and "same-manufacturer" may be implemented as access- "manufacturer" and "same-manufacturer" may be implemented as access-
lists. In more complex forms, additional network capabilities may be lists. In more complex forms, additional network capabilities may be
used. For example, if one saw the line "manufacturer" : used. For example, if one saw the line "manufacturer" :
"flobbidy.example.com", then all Things that registered with a MUD "flobbidy.example.com", then all Things that registered with a MUD
URL that contained flobbity.example.com in its authority section URL that contained flobbity.example.com in its authority section
would match. would match.
3.9. same-manufacturer 3.10. same-manufacturer
This null-valued node is an equivalent for when the manufacturer This null-valued node is an equivalent for when the manufacturer
element is used to indicate the authority that is found in another element is used to indicate the authority that is found in another
Thing's MUD URL matches that of the authority found in this Thing's Thing's MUD URL matches that of the authority found in this Thing's
MUD URL. For example, if the Thing's MUD URL were MUD URL. For example, if the Thing's MUD URL were
https://b1.example.com/.well-known/mud/ThingV1, then all devices that https://b1.example.com/.well-known/mud/ThingV1, then all devices that
had MUD URL with an authority section of b1.example.com would match. had MUD URL with an authority section of b1.example.com would match.
3.10. model 3.11. model
This string matches the entire MUD URL, thus covering the model that This string matches the entire MUD URL, thus covering the model that
is unique within the context of the authority. It may contain not is unique within the context of the authority. It may contain not
only model information, but versioning information as well, and any only model information, but versioning information as well, and any
other information that the manufacturer wishes to add. The intended other information that the manufacturer wishes to add. The intended
use is for devices of this precise class to match, to permit or deny use is for devices of this precise class to match, to permit or deny
communication between one another. communication between one another.
3.11. local-networks 3.12. local-networks
This null-valued node expands to include local networks. Its default This null-valued node expands to include local networks. Its default
expansion is that packets must not traverse toward a default route expansion is that packets must not traverse toward a default route
that is received from the router. However, administrators may expand that is received from the router. However, administrators may expand
the expression as is appropriate in their deployments. the expression as is appropriate in their deployments.
3.12. controller 3.13. controller
This URI specifies a value that a controller will register with the This URI specifies a value that a controller will register with the
MUD controller. The node then is expanded to the set of hosts that MUD controller. The node then is expanded to the set of hosts that
are so registered. This node may also be a URN. In this case, the are so registered. This node may also be a URN. In this case, the
URN describes a well known service, such as DNS or NTP. URN describes a well known service, such as DNS or NTP.
Great care should be used when invoking the controller class. For Great care should be used when invoking the controller class. For
one thing, it requires some understanding by the administrator as to one thing, it requires some understanding by the administrator as to
when it is appropriate. Classes that are standardized may make it when it is appropriate. Classes that are standardized may make it
possible to easily name devices that support standard functions. For possible to easily name devices that support standard functions. For
skipping to change at page 16, line 36 skipping to change at page 17, line 34
servers should be used for any particular group of Things. Non- servers should be used for any particular group of Things. Non-
standard classes will likely require some sort of administrator standard classes will likely require some sort of administrator
interaction. Pre-registration in such classes by controllers with interaction. Pre-registration in such classes by controllers with
the MUD server is encouraged. The mechanism to do that is beyond the the MUD server is encouraged. The mechanism to do that is beyond the
scope of this work. scope of this work.
Controller URIs MAY take the form of a URL (e.g. "http[s]://"). Controller URIs MAY take the form of a URL (e.g. "http[s]://").
However, MUD controllers MUST NOT resolve and retrieve such files, However, MUD controllers MUST NOT resolve and retrieve such files,
and it is RECOMMENDED that there be no such file at this time, as and it is RECOMMENDED that there be no such file at this time, as
their form and function may be defined at a point in the future. For their form and function may be defined at a point in the future. For
now, URLs should serve simply as class names and be populated by the now, URLs should serve simply as class names and may be populated by
local deployment administrator. the local deployment administrator.
3.13. my-controller 3.14. my-controller
This null-valued node signals to the MUD controller to use whatever This null-valued node signals to the MUD controller to use whatever
mapping it has for this MUD URL to a particular group of hosts. This mapping it has for this MUD URL to a particular group of hosts. This
may require prompting the administrator for class members. Future may require prompting the administrator for class members. Future
work should seek to automate membership management. work should seek to automate membership management.
3.14. direction-initiated 3.15. direction-initiated
When applied this matches packets when the flow was initiated in the When applied this matches packets when the flow was initiated in the
corresponding direction. [RFC6092] specifies IPv6 guidance best corresponding direction. [RFC6092] specifies IPv6 guidance best
practices. While that document is scoped specifically to IPv6, its practices. While that document is scoped specifically to IPv6, its
contents are applicable for IPv4 as well. When this flag is set, and contents are applicable for IPv4 as well. When this flag is set, and
the system has no reason to believe a flow has been initiated it MUST the system has no reason to believe a flow has been initiated it MUST
drop the packet. This node may be implemented in its simplest form drop the packet. This node may be implemented in its simplest form
by looking at naked SYN bits, but may also be implemented through by looking at naked SYN bits, but may also be implemented through
more stateful mechanisms. more stateful mechanisms.
skipping to change at page 17, line 20 skipping to change at page 18, line 18
To keep things relatively simple in addition to whatever definitions To keep things relatively simple in addition to whatever definitions
exist, we also apply two additional default behaviors: exist, we also apply two additional default behaviors:
o Anything not explicitly permitted is denied. o Anything not explicitly permitted is denied.
o Local DNS and NTP are, by default, permitted to and from the o Local DNS and NTP are, by default, permitted to and from the
Thing. Thing.
An explicit description of the defaults can be found in Appendix B. An explicit description of the defaults can be found in Appendix B.
These are applied AFTER all other explicit rules. Thus, a default
behavior can be changed with a "drop" action.
5. What does a MUD URL look like? 5. What does a MUD URL look like?
To begin with, MUD takes full advantage of both the https: scheme and To begin with, MUD takes full advantage of both the https: scheme and
the use of .well-known. HTTPS is important in this case because a the use of .well-known. HTTPS is important in this case because a
man in the middle attack could otherwise harm the operation of a man in the middle attack could otherwise harm the operation of a
class of Things. .well-known is used because we wish to add class of Things. .well-known is used because we wish to add
additional structure to the URL, and want to leave open for future additional structure to the URL, and want to leave open for future
versions both the means by which the URL is processed and the format versions both the means by which the URL is processed and the format
of the MUD file retrieved (there have already been some discussions of the MUD file retrieved (there have already been some discussions
skipping to change at page 21, line 6 skipping to change at page 22, line 6
type inet:uri; type inet:uri;
description description
"A URL to a description of this Thing. This "A URL to a description of this Thing. This
should be a brief localized description. The should be a brief localized description. The
reference text should be no more than octets. reference text should be no more than octets.
systeminfo may be displayed to the user to systeminfo may be displayed to the user to
determine whether to allow the Thing on the determine whether to allow the Thing on the
network."; network.";
} }
leaf mfg-name {
type string;
description "Manufacturer name, as described in
the ietf-hardware yang module.";
}
leaf model-name {
type string;
description "Model name, as described in the
ietf-hardware yang module.";
}
leaf firmware-rev {
type string;
description "firmware-rev, as described in the
ietf-hardware yang module. Note this field MUST
NOT be included when the device can be updated
but the MUD-URL cannot.";
}
leaf software-rev {
type string;
description "software-rev, as described in the
ietf-hardware yang module. Note this field MUST
NOT be included when the device can be updated
but the MUD-URL cannot.";
}
leaf-list extensions { leaf-list extensions {
type string { type string {
length "1..40"; length "1..40";
} }
description description
"A list of extension names that are used in this MUD "A list of extension names that are used in this MUD
file. Each name is registered with the IANA and file. Each name is registered with the IANA and
described in an RFC."; described in an RFC.";
} }
container from-device-policy { container from-device-policy {
skipping to change at page 24, line 31 skipping to change at page 26, line 5
The following node are defined. The following node are defined.
7.1. src-dnsname 7.1. src-dnsname
The argument corresponds to a domain name of a source as specified by The argument corresponds to a domain name of a source as specified by
inet:host. A number of means may be used to resolve hosts. What is inet:host. A number of means may be used to resolve hosts. What is
important is that such resolutions be consistent with ACLs required important is that such resolutions be consistent with ACLs required
by Things to properly operate. by Things to properly operate.
7.2. destination-dnsname 7.2. dst-dnsname
The argument corresponds to a domain name of a destination as The argument corresponds to a domain name of a destination as
specified by inet:host See the previous section relating to specified by inet:host See the previous section relating to
resolution. resolution.
Note when using either of these with a MUD file, because access is Note when using either of these with a MUD file, because access is
associated with a particular Thing, MUD files MUST not contain either associated with a particular Thing, MUD files MUST not contain either
a src-dnsname in an ACL associated with from-device-policy or a dst- a src-dnsname in an ACL associated with from-device-policy or a dst-
dnsname associated with to-device-policy. dnsname associated with to-device-policy.
skipping to change at page 26, line 25 skipping to change at page 27, line 45
8. MUD File Example 8. MUD File Example
This example contains two access lists that are intended to provide This example contains two access lists that are intended to provide
outbound access to a cloud service on TCP port 443. outbound access to a cloud service on TCP port 443.
{ {
"ietf-mud:mud": { "ietf-mud:mud": {
"mud-version": 1, "mud-version": 1,
"mud-url": "https://bms.example.com/.well-known/mud/lightbulb2000", "mud-url": "https://bms.example.com/.well-known/mud/lightbulb2000",
"last-update": "2018-01-23T13:33:52+01:00", "last-update": "2018-01-24T16:08:58+01:00",
"cache-validity": 48, "cache-validity": 48,
"is-supported": true, "is-supported": true,
"systeminfo": "The BMS Example Lightbulb", "systeminfo": "The BMS Example Lightbulb",
"from-device-policy": { "from-device-policy": {
"access-lists": { "access-lists": {
"access-list": [ "access-list": [
{ {
"name": "mud-45782-v6fr" "name": "mud-61898-v6fr"
} }
] ]
} }
}, },
"to-device-policy": { "to-device-policy": {
"access-lists": { "access-lists": {
"access-list": [ "access-list": [
{ {
"name": "mud-45782-v6to" "name": "mud-61898-v6to"
} }
] ]
} }
} }
}, },
"ietf-access-control-list:access-lists": { "ietf-access-control-list:access-lists": {
"acl": [ "acl": [
{ {
"name": "mud-45782-v6to", "name": "mud-61898-v6to",
"acl-type": "ipv6-acl-type", "type": "ipv6-acl-type",
"access-list-entries": { "aces": {
"ace": [ "ace": [
{ {
"rule-name": "cl0-todev", "name": "cl0-todev",
"matches": { "matches": {
"ipv6-acl": { "l3": {
"ietf-acldns:src-dnsname": "service.bms.example.com", "ipv6": {
"protocol": 6, "ietf-acldns:src-dnsname": "service.bms.example.com",
"source-port-range-or-operator": { "protocol": 6
"operator": "eq",
"port": 443
} }
}, },
"tcp": { "l4": {
"ietf-mud:direction-initiated": "from-device" "tcp": {
"ietf-mud:direction-initiated": "from-device",
"source-port-range-or-operator": {
"operator": "eq",
"port": 443
}
}
} }
}, },
"actions": { "actions": {
"forwarding": "accept" "forwarding": "accept"
} }
} }
] ]
} }
}, },
{ {
"name": "mud-45782-v6fr", "name": "mud-61898-v6fr",
"acl-type": "ipv6-acl-type", "type": "ipv6-acl-type",
"access-list-entries": { "aces": {
"ace": [ "ace": [
{ {
"rule-name": "cl0-frdev", "name": "cl0-frdev",
"matches": { "matches": {
"ipv6-acl": { "l3": {
"ietf-acldns:dst-dnsname": "service.bms.example.com", "ipv6": {
"protocol": 6, "ietf-acldns:dst-dnsname": "service.bms.example.com",
"destination-port-range-or-operator": { "protocol": 6
"operator": "eq",
"port": 443
} }
}, },
"tcp": { "l4": {
"ietf-mud:direction-initiated": "from-device" "tcp": {
"ietf-mud:direction-initiated": "from-device",
"destination-port-range-or-operator": {
"operator": "eq",
"port": 443
}
}
} }
}, },
"actions": { "actions": {
"forwarding": "accept" "forwarding": "accept"
} }
} }
] ]
} }
} }
] ]
} }
} }
In this example, two policies are declared, one from the Thing and In this example, two policies are declared, one from the Thing and
skipping to change at page 41, line 15 skipping to change at page 43, line 15
18. References 18. References
18.1. Normative References 18.1. Normative References
[I-D.ietf-netmod-acl-model] [I-D.ietf-netmod-acl-model]
Jethanandani, M., Huang, L., Agarwal, S., and D. Blair, Jethanandani, M., Huang, L., Agarwal, S., and D. Blair,
"Network Access Control List (ACL) YANG Data Model", "Network Access Control List (ACL) YANG Data Model",
draft-ietf-netmod-acl-model-15 (work in progress), January draft-ietf-netmod-acl-model-15 (work in progress), January
2018. 2018.
[I-D.ietf-netmod-entity]
Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A
YANG Data Model for Hardware Management", draft-ietf-
netmod-entity-08 (work in progress), January 2018.
[I-D.ietf-netmod-yang-tree-diagrams] [I-D.ietf-netmod-yang-tree-diagrams]
Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft-
ietf-netmod-yang-tree-diagrams-05 (work in progress), ietf-netmod-yang-tree-diagrams-05 (work in progress),
January 2018. January 2018.
[IEEE8021AB] [IEEE8021AB]
Institute for Electrical and Electronics Engineers, "IEEE Institute for Electrical and Electronics Engineers, "IEEE
Standard for Local and Metropolitan Area Networks-- Standard for Local and Metropolitan Area Networks--
Station and Media Access Control Connectivity Discovery", Station and Media Access Control Connectivity Discovery",
n.d.. n.d..
skipping to change at page 44, line 36 skipping to change at page 46, line 41
[RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and
IETF Protocol and Documentation Usage for IEEE 802 IETF Protocol and Documentation Usage for IEEE 802
Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042,
October 2013, <https://www.rfc-editor.org/info/rfc7042>. October 2013, <https://www.rfc-editor.org/info/rfc7042>.
[RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna,
"Tunnel Extensible Authentication Protocol (TEAP) Version "Tunnel Extensible Authentication Protocol (TEAP) Version
1", RFC 7170, DOI 10.17487/RFC7170, May 2014, 1", RFC 7170, DOI 10.17487/RFC7170, May 2014,
<https://www.rfc-editor.org/info/rfc7170>. <https://www.rfc-editor.org/info/rfc7170>.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
<https://www.rfc-editor.org/info/rfc7223>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, [RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson,
"Architectural Considerations in Smart Object Networking", "Architectural Considerations in Smart Object Networking",
RFC 7452, DOI 10.17487/RFC7452, March 2015, RFC 7452, DOI 10.17487/RFC7452, March 2015,
<https://www.rfc-editor.org/info/rfc7452>. <https://www.rfc-editor.org/info/rfc7452>.
skipping to change at page 48, line 25 skipping to change at page 50, line 34
"urn:ietf:params:mud:dns" and traffic NTP to a controller that is "urn:ietf:params:mud:dns" and traffic NTP to a controller that is
registered "urn:ietf:params:mud:ntp". This is considered the default registered "urn:ietf:params:mud:ntp". This is considered the default
behavior and the ACEs are in effect appended to whatever other "ace" behavior and the ACEs are in effect appended to whatever other "ace"
entries that a MUD file contains. To block DNS or NTP one repeats entries that a MUD file contains. To block DNS or NTP one repeats
the matching statement but replaces the "forwarding" action "accept" the matching statement but replaces the "forwarding" action "accept"
with "drop". Because ACEs are processed in the order they are with "drop". Because ACEs are processed in the order they are
received, the defaults would not be reached. A MUD controller might received, the defaults would not be reached. A MUD controller might
further decide to optimize to simply not include the defaults when further decide to optimize to simply not include the defaults when
they are overriden. they are overriden.
Four of "acl" liste entries that implement default MUD nodes is Four "acl" list entries that implement default MUD nodes are listed
listed below. Two are for IPv4 and two are for IPv6 (one in each below. Two are for IPv4 and two are for IPv6 (one in each direction
direction for both versions of IP). for both versions of IP). Note that neither access-list name nor ace
name need be retained or used in any way by local implementations,
but are simply there for completeness' sake.
"ietf-access-control-list:access-lists": { "ietf-access-control-list:access-lists": {
"acl": [ "acl": [
{ {
"name": "mud-63142-v4to", "name": "mud-76295-v4to",
"acl-type": "ipv4-acl-type", "type": "ipv4-acl-type",
"aces": { "aces": {
"ace": [ "ace": [
{ {
"rule-name": "ent0-todev", "name": "ent0-todev",
"matches": { "matches": {
"ietf-mud:mud-acl": { "ietf-mud:mud": {
"controller": "urn:ietf:params:mud:dns" "controller": "urn:ietf:params:mud:dns"
}, },
"ipv4": { "l3": {
"protocol": 17, "ipv4": {
"source-port-range-or-operator": { "protocol": 17
"operator": "eq", }
"port": 53 },
"l4": {
"udp": {
"source-port-range-or-operator": {
"operator": "eq",
"port": 53
}
} }
} }
}, },
"actions": { "actions": {
"forwarding": "accept" "forwarding": "accept"
} }
}, },
{ {
"rule-name": "ent1-todev", "name": "ent1-todev",
"matches": { "matches": {
"ietf-mud:mud-acl": { "ietf-mud:mud": {
"controller": "urn:ietf:params:mud:ntp" "controller": "urn:ietf:params:mud:ntp"
}, },
"ipv4": { "l3": {
"protocol": 17, "ipv4": {
"source-port-range-or-operator": { "protocol": 17
"operator": "eq", }
"port": 123 },
"l4": {
"udp": {
"source-port-range-or-operator": {
"operator": "eq",
"port": 123
}
} }
} }
}, },
"actions": { "actions": {
"forwarding": "accept" "forwarding": "accept"
} }
} }
] ]
} }
}, },
{ {
"name": "mud-63142-v4fr", "name": "mud-76295-v4fr",
"acl-type": "ipv4-acl-type", "type": "ipv4-acl-type",
"aces": { "aces": {
"ace": [ "ace": [
{ {
"rule-name": "ent0-frdev", "name": "ent0-frdev",
"matches": { "matches": {
"ietf-mud:mud-acl": { "ietf-mud:mud": {
"controller": "urn:ietf:params:mud:dns" "controller": "urn:ietf:params:mud:dns"
}, },
"ipv4": { "l3": {
"protocol": 17, "ipv4": {
"destination-port-range-or-operator": { "protocol": 17
"operator": "eq", }
"port": 53 },
"l4": {
"udp": {
"destination-port-range-or-operator": {
"operator": "eq",
"port": 53
}
} }
} }
}, },
"actions": { "actions": {
"forwarding": "accept" "forwarding": "accept"
} }
}, },
{ {
"rule-name": "ent1-frdev", "name": "ent1-frdev",
"matches": { "matches": {
"ietf-mud:mud-acl": { "ietf-mud:mud": {
"controller": "urn:ietf:params:mud:ntp" "controller": "urn:ietf:params:mud:ntp"
}, },
"ipv4": { "l3": {
"protocol": 17, "ipv4": {
"destination-port-range-or-operator": { "protocol": 17
"operator": "eq", }
"port": 123 },
"l4": {
"udp": {
"destination-port-range-or-operator": {
"operator": "eq",
"port": 123
}
} }
} }
}, },
"actions": { "actions": {
"forwarding": "accept" "forwarding": "accept"
} }
} }
] ]
} }
}, },
{ {
"name": "mud-63142-v6to", "name": "mud-76295-v6to",
"acl-type": "ipv6-acl-type", "type": "ipv6-acl-type",
"access-list-entries": { "aces": {
"ace": [ "ace": [
{ {
"rule-name": "ent0-todev", "name": "ent0-todev",
"matches": { "matches": {
"ietf-mud:mud-acl": { "ietf-mud:mud": {
"controller": "urn:ietf:params:mud:dns" "controller": "urn:ietf:params:mud:dns"
}, },
"ipv6": { "l3": {
"protocol": 17, "ipv6": {
"source-port-range-or-operator": { "protocol": 17
"operator": "eq", }
"port": 53 },
"l4": {
"udp": {
"source-port-range-or-operator": {
"operator": "eq",
"port": 53
}
} }
} }
}, },
"actions": { "actions": {
"forwarding": "accept" "forwarding": "accept"
} }
}, },
{ {
"rule-name": "ent1-todev", "name": "ent1-todev",
"matches": { "matches": {
"ietf-mud:mud-acl": { "ietf-mud:mud": {
"controller": "urn:ietf:params:mud:ntp" "controller": "urn:ietf:params:mud:ntp"
}, },
"ipv6": { "l3": {
"protocol": 17, "ipv6": {
"source-port-range-or-operator": { "protocol": 17
"operator": "eq", }
"port": 123 },
"l4": {
"udp": {
"source-port-range-or-operator": {
"operator": "eq",
"port": 123
}
} }
} }
}, },
"actions": { "actions": {
"forwarding": "accept" "forwarding": "accept"
} }
} }
] ]
} }
}, },
{ {
"name": "mud-63142-v6fr", "name": "mud-76295-v6fr",
"acl-type": "ipv6-acl-type", "type": "ipv6-acl-type",
"access-list-entries": { "aces": {
"ace": [ "ace": [
{ {
"rule-name": "ent0-frdev", "name": "ent0-frdev",
"matches": { "matches": {
"ietf-mud:mud-acl": { "ietf-mud:mud": {
"controller": "urn:ietf:params:mud:dns" "controller": "urn:ietf:params:mud:dns"
}, },
"ipv6": { "l3": {
"protocol": 17, "ipv6": {
"destination-port-range-or-operator": { "protocol": 17
"operator": "eq", }
"port": 53 },
"l4": {
"udp": {
"destination-port-range-or-operator": {
"operator": "eq",
"port": 53
}
} }
} }
}, },
"actions": { "actions": {
"forwarding": "accept" "forwarding": "accept"
} }
}, },
{ {
"rule-name": "ent1-frdev", "name": "ent1-frdev",
"matches": { "matches": {
"ietf-mud:mud-acl": { "ietf-mud:mud": {
"controller": "urn:ietf:params:mud:ntp" "controller": "urn:ietf:params:mud:ntp"
}, },
"ipv6": { "l3": {
"protocol": 17, "ipv6": {
"destination-port-range-or-operator": { "protocol": 17
"operator": "eq", }
"port": 123 },
"l4": {
"udp": {
"destination-port-range-or-operator": {
"operator": "eq",
"port": 123
}
} }
} }
}, },
"actions": { "actions": {
"forwarding": "accept" "forwarding": "accept"
} }
} }
] ]
} }
} }
skipping to change at page 53, line 42 skipping to change at page 57, line 4
device."; device.";
leaf is-detnet-required { leaf is-detnet-required {
type boolean; type boolean;
description description
"This value will equal true if a device requires "This value will equal true if a device requires
detnet to properly function"; detnet to properly function";
} }
} }
} }
<CODE ENDS> <CODE ENDS>
Using the previous example, we now show how the extension would be Using the previous example, we now show how the extension would be
expressed: expressed:
{ {
{
"ietf-mud:mud": { "ietf-mud:mud": {
"mud-version": 1, "mud-version": 1,
"mud-url": "https://bms.example.com/.well-known/mud/lightbulb2000", "mud-url": "https://bms.example.com/.well-known/mud/lightbulb2000",
"last-update": "2018-01-23T13:33:52+01:00", "last-update": "2018-01-23T13:33:52+01:00",
"cache-validity": 48, "cache-validity": 48,
"is-supported": true, "is-supported": true,
"systeminfo": "The BMS Example Lightbulb", "systeminfo": "The BMS Example Lightbulb",
"extensions": [ "extensions": [
"ietf-mud-detext-example" "ietf-mud-detext-example"
], ],
skipping to change at page 54, line 34 skipping to change at page 57, line 42
"name": "mud-45782-v6to" "name": "mud-45782-v6to"
} }
] ]
} }
} }
}, },
"ietf-access-control-list:access-lists": { "ietf-access-control-list:access-lists": {
"acl": [ "acl": [
{ {
"name": "mud-45782-v6to", "name": "mud-45782-v6to",
"acl-type": "ipv6-acl-type", "type": "ipv6-acl-type",
"access-list-entries": { "aces": {
"ace": [ "ace": [
{ {
"rule-name": "cl0-todev", "rule-name": "cl0-todev",
"matches": { "matches": {
"ipv6-acl": { "ipv6-acl": {
"ietf-acldns:src-dnsname": "service.bms.example.com", "ietf-acldns:src-dnsname": "service.bms.example.com",
"protocol": 6, "protocol": 6,
"source-port-range-or-operator": { "source-port-range-or-operator": {
"operator": "eq", "operator": "eq",
"port": 443 "port": 443
skipping to change at page 55, line 14 skipping to change at page 58, line 22
"actions": { "actions": {
"forwarding": "accept" "forwarding": "accept"
} }
} }
] ]
} }
}, },
{ {
"name": "mud-45782-v6fr", "name": "mud-45782-v6fr",
"acl-type": "ipv6-acl-type", "acl-type": "ipv6-acl-type",
"access-list-entries": { "aces": {
"ace": [ "ace": [
{ {
"rule-name": "cl0-frdev", "rule-name": "cl0-frdev",
"matches": { "matches": {
"ipv6-acl": { "ipv6-acl": {
"ietf-acldns:dst-dnsname": "service.bms.example.com", "ietf-acldns:dst-dnsname": "service.bms.example.com",
"protocol": 6, "protocol": 6,
"destination-port-range-or-operator": { "destination-port-range-or-operator": {
"operator": "eq", "operator": "eq",
"port": 443 "port": 443
} }
}, },
"tcp": { "tcp": {
"ietf-mud:direction-initiated": "from-device" "ietf-mud:direction-initiated": "from-device"
} }
}, },
 End of changes. 77 change blocks. 
181 lines changed or deleted 299 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/