draft-ietf-opsawg-mud-21.txt   draft-ietf-opsawg-mud-22.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: November 18, 2018 Google Expires: November 26, 2018 Google
D. Romascanu D. Romascanu
May 17, 2018 May 25, 2018
Manufacturer Usage Description Specification Manufacturer Usage Description Specification
draft-ietf-opsawg-mud-21 draft-ietf-opsawg-mud-22
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
end devices to signal to the network what sort of access and network end devices 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 November 18, 2018. This Internet-Draft will expire on November 26, 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 3, line 16 skipping to change at page 3, line 16
10.2. Server Behavior . . . . . . . . . . . . . . . . . . . . 31 10.2. Server Behavior . . . . . . . . . . . . . . . . . . . . 31
10.3. Relay Requirements . . . . . . . . . . . . . . . . . . . 32 10.3. Relay Requirements . . . . . . . . . . . . . . . . . . . 32
11. The Manufacturer Usage Description (MUD) URL X.509 Extension 32 11. The Manufacturer Usage Description (MUD) URL X.509 Extension 32
12. The Manufacturer Usage Description LLDP extension . . . . . . 34 12. The Manufacturer Usage Description LLDP extension . . . . . . 34
13. Creating and Processing of Signed MUD Files . . . . . . . . . 36 13. Creating and Processing of Signed MUD Files . . . . . . . . . 36
13.1. Creating a MUD file signature . . . . . . . . . . . . . 36 13.1. Creating a MUD file signature . . . . . . . . . . . . . 36
13.2. Verifying a MUD file signature . . . . . . . . . . . . . 36 13.2. Verifying a MUD file signature . . . . . . . . . . . . . 36
14. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 37 14. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 37
15. Deployment Considerations . . . . . . . . . . . . . . . . . . 37 15. Deployment Considerations . . . . . . . . . . . . . . . . . . 37
16. Security Considerations . . . . . . . . . . . . . . . . . . . 38 16. Security Considerations . . . . . . . . . . . . . . . . . . . 38
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
17.1. YANG Module Registrations . . . . . . . . . . . . . . . 40 17.1. YANG Module Registrations . . . . . . . . . . . . . . . 41
17.2. DHCPv4 and DHCPv6 Options . . . . . . . . . . . . . . . 41 17.2. DHCPv4 and DHCPv6 Options . . . . . . . . . . . . . . . 41
17.3. PKIX Extensions . . . . . . . . . . . . . . . . . . . . 41 17.3. PKIX Extensions . . . . . . . . . . . . . . . . . . . . 41
17.4. MIME Media-type Registration for MUD files . . . . . . . 42 17.4. MIME Media-type Registration for MUD files . . . . . . . 42
17.5. LLDP IANA TLV Subtype Registry . . . . . . . . . . . . . 42 17.5. LLDP IANA TLV Subtype Registry . . . . . . . . . . . . . 43
17.6. The MUD Well Known Universal Resource Name (URNs) . . . 43 17.6. The MUD Well Known Universal Resource Name (URNs) . . . 43
17.7. Extensions Registry . . . . . . . . . . . . . . . . . . 43 17.7. Extensions Registry . . . . . . . . . . . . . . . . . . 43
18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43 18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
19.1. Normative References . . . . . . . . . . . . . . . . . . 44 19.1. Normative References . . . . . . . . . . . . . . . . . . 44
19.2. Informative References . . . . . . . . . . . . . . . . . 47 19.2. Informative References . . . . . . . . . . . . . . . . . 47
Appendix A. Changes from Earlier Versions . . . . . . . . . . . 48 Appendix A. Changes from Earlier Versions . . . . . . . . . . . 49
Appendix B. Default MUD nodes . . . . . . . . . . . . . . . . . 52 Appendix B. Default MUD nodes . . . . . . . . . . . . . . . . . 53
Appendix C. A Sample Extension: DETNET-indicator . . . . . . . . 57 Appendix C. A Sample Extension: DETNET-indicator . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61
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 9, line 41 skipping to change at page 9, line 41
Manufacturer: A device made by a particular manufacturer, as Manufacturer: A device made by a particular manufacturer, as
identified by the authority component of its MUD URL identified by the authority component of its MUD URL
same-manufacturer: Devices that have the same authority component of same-manufacturer: Devices that have the same authority component of
their MUD URL. their MUD URL.
controller: Devices that the local network administrator admits to controller: Devices that the local network administrator admits to
the particular class. the particular class.
my-controller: Devices intended to serve as controllers for the MUD- my-controller: Devices intended to serve as controllers for the MUD-
URL that the thing emitted. URL that the Thing emitted.
local: The class of IP addresses that are scoped within some local: The class of IP addresses that are scoped within some
administrative boundary. By default it is suggested that this be administrative boundary. By default it is suggested that this be
the local subnet. the local subnet.
The "manufacturer" classes can be easily specified by the The "manufacturer" classes can be easily specified by the
manufacturer, whereas controller classes are initially envisioned to manufacturer, whereas controller classes are initially envisioned to
be specified by the administrator. be specified by the administrator.
Because manufacturers do not know who will be using their devices, it Because manufacturers do not know who will be using their devices, it
skipping to change at page 10, line 39 skipping to change at page 10, line 39
. |_________| . . |_________| .
....................................... .......................................
Figure 1: MUD Architecture Figure 1: MUD Architecture
In the above diagram, the switch or router collects MUD URLs and In the above diagram, the switch or router collects MUD URLs and
forwards them to the MUD manager (a network management system) for forwards them to the MUD manager (a network management system) for
processing. This happens in different ways, depending on how the URL processing. This happens in different ways, depending on how the URL
is communicated. For instance, in the case of DHCP, the DHCP server is communicated. For instance, in the case of DHCP, the DHCP server
might receive the URL and then process it. In the case of IEEE might receive the URL and then process it. In the case of IEEE
802.1X, the switch would carry the URL via a certificate to the 802.1X [IEEE8021X], the switch would carry the URL via a certificate
authentication server via EAP over Radius[RFC3748], which would then to the authentication server via EAP over Radius[RFC3748], which
process it. One method to do this is TEAP, described in [RFC7170]. would then process it. One method to do this is TEAP, described in
The certificate extension is described below. [RFC7170]. The certificate extension is described below.
The information returned by the MUD file server is valid for as long The information returned by the MUD file server is valid for as long
as the Thing is connected. There is no expiry. However, if the MUD as the Thing is connected. There is no expiry. However, if the MUD
manager has detected that the MUD file for a Thing has changed, it manager has detected that the MUD file for a Thing has changed, it
SHOULD update the policy expeditiously, taking into account whatever SHOULD update the policy expeditiously, taking into account whatever
approval flow is required in a deployment. In this way, new approval flow is required in a deployment. In this way, new
recommendations from the manufacturer can be processed in a timely recommendations from the manufacturer can be processed in a timely
fashion. fashion.
The information returned by the MUD file server (a web server) is The information returned by the MUD file server (a web server) is
skipping to change at page 13, line 24 skipping to change at page 13, line 24
In fact, MUD managers MAY ignore any particular component of a In fact, MUD managers 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.9. See that NOT include other nodes except as described in Section 3.9. 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 component "mud" holds information that is relevant to o The first component, the "mud" container, holds information that
retrieval and validity of the MUD file itself, as well as policy is relevant to retrieval and validity of the MUD file itself, as
intended to and from the Thing. well as policy intended to and from the Thing.
o The second component augments the matching container of the ACL o The second component augments the matching container of the ACL
model to add several nodes that are relevant to the MUD URL, or model to add several nodes that are relevant to the MUD URL, or
otherwise abstracted for use within a local environment. otherwise abstracted for use within a local environment.
o The third component augments the tcp-acl container of the ACL o The third component augments the tcp-acl container of the ACL
model to add the ability to match on the direction of initiation model to add the ability to match on the direction of initiation
of a TCP connection. of a TCP connection.
A valid MUD file will contain two root objects, a "mud" container and A valid MUD file will contain two root objects, a "mud" container and
an "acls" container. Extensions may add additional root objects as an "acls" container. Extensions may add additional root objects as
required. As a reminder, when parsing access-lists, elements within required. As a reminder, when parsing acls, elements within a
a "match" block are logically ANDed. In general, a single "match" block are logically ANDed. In general, a single abstraction
abstraction in a match statement should be used. For instance, it in a match statement should be used. For instance, it makes little
makes little sense to match both "my-controller" and "controller" sense to match both "my-controller" and "controller" with an
with an argument, since they are highly unlikely to be the same argument, since they are highly unlikely to be the same value.
value.
A simplified graphical representation of the data models is used in A simplified graphical representation of the data models is used in
this document. The meaning of the symbols in these diagrams is this document. The meaning of the symbols in these diagrams is
explained in [RFC8340]. explained in [RFC8340].
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
skipping to change at page 14, line 21 skipping to change at page 14, line 21
+--rw cache-validity? uint8 +--rw cache-validity? uint8
+--rw is-supported boolean +--rw is-supported boolean
+--rw systeminfo? string +--rw systeminfo? string
+--rw mfg-name? string +--rw mfg-name? string
+--rw model-name? string +--rw model-name? string
+--rw firmware-rev? string +--rw firmware-rev? string
+--rw software-rev? string +--rw software-rev? string
+--rw documentation? inet:uri +--rw documentation? inet:uri
+--rw extensions* string +--rw extensions* string
+--rw from-device-policy +--rw from-device-policy
| +--rw access-lists | +--rw acls
| +--rw access-list* [name] | +--rw access-list* [name]
| +--rw name -> /acl:acls/acl/name | +--rw name -> /acl:acls/acl/name
+--rw to-device-policy +--rw to-device-policy
+--rw access-lists +--rw acls
+--rw access-list* [name] +--rw access-list* [name]
+--rw name -> /acl:acls/acl/name +--rw name -> /acl:acls/acl/name
augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches: augment /acl:acls/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
skipping to change at page 17, line 36 skipping to change at page 17, line 36
4.6. controller 4.6. 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 manager. The node then is expanded to the set of hosts that are MUD manager. 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 URN so registered. This node may also be a URN. In this case, the URN
describes a well known service, such as DNS or NTP, that has been describes a well known service, such as DNS or NTP, that has been
standardized. Both of those URNs may be found in Section 17.6. standardized. Both of those URNs may be found in Section 17.6.
When "my-controller" is used, it is possible that the administrator When "my-controller" is used, it is possible that the administrator
will be prompted to populate that class for each every model. Use of will be prompted to populate that class for each and every model.
"controller" with a named class allows the user to populate that Use of "controller" with a named class allows the user to populate
class only once for many different models that a manufacturer may that class only once for many different models that a manufacturer
produce. may produce.
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 managers MUST NOT resolve and retrieve such files, and However, MUD managers MUST NOT resolve and retrieve such files, and
it is RECOMMENDED that there be no such file at this time, as their 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 now, form and function may be defined at a point in the future. For now,
URLs should serve simply as class names and may be populated by the URLs should serve simply as class names and may be populated by the
local deployment administrator. local deployment administrator.
Great care should be taken by MUD managers when invoking the Great care should be taken by MUD managers when invoking the
controller class in the form of URLs. For one thing, it requires controller class in the form of URLs. For one thing, it requires
skipping to change at page 18, line 16 skipping to change at page 18, line 16
4.7. my-controller 4.7. my-controller
This null-valued node signals to the MUD manager to use whatever This null-valued node signals to the MUD manager 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.
4.8. direction-initiated 4.8. direction-initiated
This MUST only applied to TCP. this matches the direction in which a This MUST only be applied to TCP. This matches the direction in
TCP connection is initiated. When direction initiated is "from- which a TCP connection is initiated. When direction initiated is
device", packets that are transmitted in the direction of a thing "from-device", packets that are transmitted in the direction of a
MUST be dropped unless the thing has first initiated a TCP thing MUST be dropped unless the thing has first initiated a TCP
connection. By way of example, this node may be implemented in its connection. By way of example, this node may be implemented in its
simplest form by looking at naked SYN bits, but may also be simplest form by looking at naked SYN bits, but may also be
implemented through more stateful mechanisms. implemented through more stateful mechanisms.
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. contents are applicable for IPv4 as well.
5. Processing of the MUD file 5. Processing of the MUD file
skipping to change at page 19, line 14 skipping to change at page 19, line 14
https://things.example.org/product_abc123/v5 https://things.example.org/product_abc123/v5
https://www.example.net/mudfiles/temperature_sensor/ https://www.example.net/mudfiles/temperature_sensor/
https://example.com/lightbulbs/colour/v1 https://example.com/lightbulbs/colour/v1
A manufacturer may construct a MUD URL in any way, so long as it A manufacturer may construct a MUD URL in any way, so long as it
makes use of the "https" schema. makes use of the "https" schema.
7. The MUD YANG Model 7. The MUD YANG Model
<CODE BEGINS>file "ietf-mud@2018-04-12.yang" <CODE BEGINS>file "ietf-mud@2018-05-22.yang"
module ietf-mud { module ietf-mud {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-mud"; namespace "urn:ietf:params:xml:ns:yang:ietf-mud";
prefix ietf-mud; prefix ietf-mud;
import ietf-access-control-list { import ietf-access-control-list {
prefix acl; prefix acl;
} }
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
} }
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
} }
skipping to change at page 20, line 14 skipping to change at page 20, line 16
identified as the document authors. All rights reserved. identified as the document authors. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's Legal License set forth in Section 4.c of the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2018-04-12 { revision 2018-05-22 {
description description
"Initial proposed standard."; "Initial proposed standard.";
reference reference
"RFC XXXX: Manufacturer Usage Description "RFC XXXX: Manufacturer Usage Description
Specification"; Specification";
} }
typedef direction { typedef direction {
type enumeration { type enumeration {
enum "to-device" { enum to-device {
description description
"packets or flows destined to the target "packets or flows destined to the target
Thing"; Thing";
} }
enum "from-device" { enum from-device {
description description
"packets or flows destined from "packets or flows destined from
the target Thing"; the target Thing";
} }
} }
description description
"Which way are we talking about?"; "Which way are we talking about?";
} }
container mud { container mud {
skipping to change at page 21, line 8 skipping to change at page 21, line 8
} }
grouping mud-grouping { grouping mud-grouping {
description description
"Information about when support end(ed), and "Information about when support end(ed), and
when to refresh"; when to refresh";
leaf mud-version { leaf mud-version {
type uint8; type uint8;
mandatory true; mandatory true;
description "This is the version of the MUD description
"This is the version of the MUD
specification. This memo specifies version 1."; specification. This memo specifies version 1.";
} }
leaf mud-url { leaf mud-url {
type inet:uri; type inet:uri;
mandatory true; mandatory true;
description description
"This is the MUD URL associated with the entry found "This is the MUD URL associated with the entry found
in a MUD file."; in a MUD file.";
} }
leaf last-update { leaf last-update {
type yang:date-and-time; type yang:date-and-time;
mandatory true; mandatory true;
skipping to change at page 21, line 27 skipping to change at page 21, line 27
in a MUD file."; in a MUD file.";
} }
leaf last-update { leaf last-update {
type yang:date-and-time; type yang:date-and-time;
mandatory true; mandatory true;
description description
"This is intended to be when the current MUD file "This is intended to be when the current MUD file
was generated. MUD Managers SHOULD NOT check was generated. MUD Managers SHOULD NOT check
for updates between this time plus cache validity"; for updates between this time plus cache validity";
} }
leaf mud-signature { leaf mud-signature {
type inet:uri; type inet:uri;
description "A URI that resolves to a signature as description
described in this specification."; "A URI that resolves to a signature as
described in this specification.";
} }
leaf cache-validity { leaf cache-validity {
type uint8 { type uint8 {
range "1..168"; range "1..168";
} }
units "hours"; units "hours";
default "48"; default "48";
description description
"The information retrieved from the MUD server is "The information retrieved from the MUD server is
valid for these many hours, after which it should valid for these many hours, after which it should
be refreshed. N.B. MUD manager implementations be refreshed. N.B. MUD manager implementations
skipping to change at page 22, line 13 skipping to change at page 22, line 12
} }
leaf systeminfo { leaf systeminfo {
type string; type string;
description description
"A UTF-8 description of this Thing. This "A UTF-8 description of this Thing. This
should be a brief description that may be should be a brief description that may be
displayed to the user to determine whether displayed to the user to determine whether
to allow the Thing on the to allow the Thing on the
network."; network.";
} }
leaf mfg-name { leaf mfg-name {
type string; type string;
description "Manufacturer name, as described in description
the ietf-hardware YANG module."; "Manufacturer name, as described in
the ietf-hardware YANG module.";
} }
leaf model-name { leaf model-name {
type string; type string;
description "Model name, as described in the description
"Model name, as described in the
ietf-hardware YANG module."; ietf-hardware YANG module.";
} }
leaf firmware-rev { leaf firmware-rev {
type string; type string;
description "firmware-rev, as described in the description
"firmware-rev, as described in the
ietf-hardware YANG module. Note this field MUST ietf-hardware YANG module. Note this field MUST
NOT be included when the device can be updated NOT be included when the device can be updated
but the MUD-URL cannot."; but the MUD-URL cannot.";
} }
leaf software-rev { leaf software-rev {
type string; type string;
description "software-rev, as described in the description
"software-rev, as described in the
ietf-hardware YANG module. Note this field MUST ietf-hardware YANG module. Note this field MUST
NOT be included when the device can be updated NOT be included when the device can be updated
but the MUD-URL cannot."; but the MUD-URL cannot.";
} }
leaf documentation { leaf documentation {
type inet:uri; type inet:uri;
description "This URL points to documentation that description
"This URL points to documentation that
relates to this device and any classes that it uses relates to this device and any classes that it uses
in its MUD file. A caution: MUD managers need in its MUD file. A caution: MUD managers need
not resolve this URL on their own, but rather simply not resolve this URL on their own, but rather simply
provide it to the administrator. Parsing HTML is provide it to the administrator. Parsing HTML is
not an intended function of a MUD manager."; not an intended function of a MUD manager.";
} }
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 {
description description
"The policies that should be enforced on traffic "The policies that should be enforced on traffic
coming from the device. These policies are not coming from the device. These policies are not
skipping to change at page 25, line 16 skipping to change at page 25, line 15
} }
leaf my-controller { leaf my-controller {
type empty; type empty;
description description
"This node matches one or more network elements that "This node matches one or more network elements that
have been configured to be the controller for this have been configured to be the controller for this
Thing, based on its MUD URL."; Thing, based on its MUD URL.";
} }
} }
} }
augment "/acl:acls/acl:acl/acl:aces/" + augment "/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches" +
"acl:ace/acl:matches/acl:l4/acl:tcp/acl:tcp" { "/acl:l4/acl:tcp/acl:tcp" {
description description
"add direction-initiated"; "add direction-initiated";
leaf direction-initiated { leaf direction-initiated {
type direction; type direction;
description description
"This node matches based on which direction a "This node matches based on which direction a
connection was initiated. The means by which that connection was initiated. The means by which that
is determined is discussed in this document."; is determined is discussed in this document.";
} }
} }
skipping to change at page 26, line 6 skipping to change at page 25, line 42
This module specifies an extension to IETF-ACL model such that domain This module specifies an extension to IETF-ACL model such that domain
names may be referenced by augmenting the "matches" node. Different names may be referenced by augmenting the "matches" node. Different
implementations may deploy differing methods to maintain the mapping implementations may deploy differing methods to maintain the mapping
between IP address and domain name, if indeed any are needed. between IP address and domain name, if indeed any are needed.
However, the intent is that resources that are referred to using a However, the intent is that resources that are referred to using a
name should be authorized (or not) within an access list. name should be authorized (or not) within an access list.
The structure of the change is as follows: The structure of the change is as follows:
module: ietf-acldns module: ietf-acldns
augment /acl:access-lists/acl:acl/acl:aces/acl:ace/ augment /acl:acls/acl:acl/acl:aces/acl:ace/
acl:matches/acl:l3/acl:ipv4/acl:ipv4: acl:matches/acl:l3/acl:ipv4/acl:ipv4:
+--rw src-dnsname? inet:host +--rw src-dnsname? inet:host
+--rw dst-dnsname? inet:host +--rw dst-dnsname? inet:host
augment /acl:access-lists/acl:acl/acl:aces/acl:ace/ augment /acl:acls/acl:acl/acl:aces/acl:ace/
acl:matches/acl:l3/acl:ipv6/acl:ipv6: acl:matches/acl:l3/acl:ipv6/acl:ipv6:
+--rw src-dnsname? inet:host +--rw src-dnsname? inet:host
+--rw dst-dnsname? inet:host +--rw dst-dnsname? inet:host
The choice of these particular points in the access-list model is The choice of these particular points in the access-list model is
based on the assumption that we are in some way referring to IP- based on the assumption that we are in some way referring to IP-
related resources, as that is what the DNS returns. A domain name in related resources, as that is what the DNS returns. A domain name in
our context is defined in [RFC6991]. The augmentations are our context is defined in [RFC6991]. The augmentations are
replicated across IPv4 and IPv6 to allow MUD file authors the ability replicated across IPv4 and IPv6 to allow MUD file authors the ability
to control the IP version that the Thing may utilize. to control the IP version that the Thing may utilize.
skipping to change at page 26, line 44 skipping to change at page 26, line 34
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.
8.3. The ietf-acldns Model 8.3. The ietf-acldns Model
<CODE BEGINS>file "ietf-acldns@2018-04-12.yang" <CODE BEGINS>file "ietf-acldns@2018-05-22.yang"
module ietf-acldns { module ietf-acldns {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-acldns"; namespace "urn:ietf:params:xml:ns:yang:ietf-acldns";
prefix "ietf-acldns"; prefix ietf-acldns;
import ietf-access-control-list { import ietf-access-control-list {
prefix "acl"; prefix acl;
} }
import ietf-inet-types { import ietf-inet-types {
prefix "inet"; prefix inet;
} }
organization organization
"IETF OPSAWG (Ops Area) Working Group"; "IETF OPSAWG (Ops Area) Working Group";
contact contact
"WG Web: http://tools.ietf.org/wg/opsawg/ "WG Web: http://tools.ietf.org/wg/opsawg/
WG List: opsawg@ietf.org WG List: opsawg@ietf.org
Author: Eliot Lear Author: Eliot Lear
lear@cisco.com lear@cisco.com
Author: Ralph Droms Author: Ralph Droms
rdroms@gmail.com rdroms@gmail.com
Author: Dan Romascanu Author: Dan Romascanu
dromasca@gmail.com dromasca@gmail.com
"; ";
description description
"This YANG module defines a component that augments the "This YANG module defines a component that augments the
IETF description of an access list to allow DNS names IETF description of an access list to allow DNS names
as matching criteria."; as matching criteria.";
revision 2018-04-12 { revision 2018-05-22 {
description "Base version of dnsname extension of ACL model"; description
reference "RFC XXXX: Manufacturer Usage Description "Base version of dnsname extension of ACL model";
Specification"; reference
"RFC XXXX: Manufacturer Usage Description
Specification";
} }
grouping dns-matches { grouping dns-matches {
description "Domain names for matching."; description
"Domain names for matching.";
leaf src-dnsname { leaf src-dnsname {
type inet:host; type inet:host;
description "domain name to be matched against"; description
"domain name to be matched against";
} }
leaf dst-dnsname { leaf dst-dnsname {
type inet:host; type inet:host;
description "domain name to be matched against"; description
"domain name to be matched against";
} }
} }
augment "/acl:acls/acl:acl/acl:aces/acl:ace/" + augment "/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches" +
"acl:matches/acl:l3/acl:ipv4/acl:ipv4" { "/acl:l3/acl:ipv4/acl:ipv4" {
description "Adding domain names to matching"; description
"Adding domain names to matching";
uses dns-matches; uses dns-matches;
} }
augment "/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches" +
augment "/acl:acls/acl:acl/" + "/acl:l3/acl:ipv6/acl:ipv6" {
"acl:aces/acl:ace/" + description
"acl:matches/acl:l3/acl:ipv6/acl:ipv6" { "Adding domain names to matching";
description "Adding domain names to matching";
uses dns-matches; uses dns-matches;
} }
} }
<CODE ENDS> <CODE ENDS>
9. MUD File Example 9. 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.
skipping to change at page 28, line 48 skipping to change at page 28, line 37
"to-device-policy": { "to-device-policy": {
"access-lists": { "access-lists": {
"access-list": [ "access-list": [
{ {
"name": "mud-76100-v6to" "name": "mud-76100-v6to"
} }
] ]
} }
} }
}, },
"ietf-access-control-list:access-lists": { "ietf-access-control-list:acls": {
"acl": [ "acl": [
{ {
"name": "mud-76100-v6to", "name": "mud-76100-v6to",
"type": "ipv6-acl-type", "type": "ipv6-acl-type",
"aces": { "aces": {
"ace": [ "ace": [
{ {
"name": "cl0-todev", "name": "cl0-todev",
"matches": { "matches": {
"ipv6": { "ipv6": {
skipping to change at page 33, line 23 skipping to change at page 33, line 5
found on the server is valid for a given device, independent of any found on the server is valid for a given device, independent of any
other factors. There are several security considerations below in other factors. There are several security considerations below in
Section 16. Section 16.
A new content-type id-ct-mud is also defined. While signatures are A new content-type id-ct-mud is also defined. While signatures are
detached today, should a MUD file be transmitted as part of a CMS detached today, should a MUD file be transmitted as part of a CMS
message, this content-type SHOULD be used. message, this content-type SHOULD be used.
The new extension is identified as follows: The new extension is identified as follows:
<CODE BEGINS> <CODE BEGINS>
MUDURLExtnModule-2016 { iso(1) identified-organization(3) dod(6) MUDURLExtnModule-2016 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-mod-mudURLExtn2016(88) } id-mod(0) id-mod-mudURLExtn2016(88) }
DEFINITIONS IMPLICIT TAGS ::= BEGIN
DEFINITIONS IMPLICIT TAGS ::= BEGIN -- EXPORTS ALL --
-- EXPORTS ALL --
IMPORTS IMPORTS
-- RFC 5912 -- RFC 5912
EXTENSION EXTENSION
FROM PKIX-CommonTypes-2009 FROM PKIX-CommonTypes-2009
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57) } id-mod-pkixCommon-02(57) }
-- RFC 5912 -- RFC 5912
id-ct id-ct
FROM PKIXCRMF-2009 FROM PKIXCRMF-2009
{iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-crmf2005-02(55) } id-mod-crmf2005-02(55) }
-- RFC 5911 -- RFC 6268
CONTENT-TYPE CONTENT-TYPE
FROM CryptographicMessageSyntax-2009 FROM CryptographicMessageSyntax-2010
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs-9(9) smime(16) modules(0) id-mod-cms-2004-02(41)} pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) }
-- RFC 5912 -- RFC 5912
id-pe, Name id-pe, Name
FROM PKIX1Explicit-2009 FROM PKIX1Explicit-2009
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-explicit-02(51) }; id-mod-pkix1-explicit-02(51) } ;
MUDCertExtensions EXTENSION ::= { ext-MUDURL, ... } --
ext-MUDURL EXTENSION ::= { SYNTAX MUDURLSyntax -- Certificate Extensions
IDENTIFIED BY id-pe-mud-url } --
id-pe-mud-url OBJECT IDENTIFIER ::= { id-pe 25 }
MUDURLSyntax ::= IA5String
ext-MUDsigner EXTENSION ::= { SYNTAX MUDsignerSyntax MUDCertExtensions EXTENSION ::=
IDENTIFIED by id-pe-mudsigner } { ext-MUDURL | ext-MUDsigner, ... }
id-pe-mudsigner OBJECT IDENTIFIER ::= { id-pe TBD }
MUDsignerSyntax ::= Name
id-ct-mudtype OBJECT IDENTIFER ::= { id-ct TBD } ext-MUDURL EXTENSION ::=
{ SYNTAX MUDURLSyntax IDENTIFIED BY id-pe-mud-url }
-- OCTET STRING contains data that in the form id-pe-mud-url OBJECT IDENTIFIER ::= { id-pe 25 }
-- "Application/mud+json" or the JSON described MUDURLSyntax ::= IA5String
-- in this document.
ct-mud CONTENT-TYPE ::= { OCTET STRING
IDENTIFIED BY id-ct-mudtype }
END ext-MUDsigner EXTENSION ::=
{ SYNTAX MUDsignerSyntax IDENTIFIED BY id-pe-mudsigner }
<CODE ENDS> id-pe-mudsigner OBJECT IDENTIFIER ::= { id-pe TBD }
MUDsignerSyntax ::= Name
--
-- CMS Content Types
--
MUDContentTypes CONTENT-TYPE ::=
{ ct-mud, ... }
ct-mud CONTENT-TYPE ::=
{ -- directly include the content
IDENTIFIED BY id-ct-mudtype }
-- The binary data that is in the form
-- 'application/mud+json" is directly encoded as the
-- signed data. No additional ASN.1 encoding is added.
id-ct-mudtype OBJECT IDENTIFIER ::= { id-ct TBD }
END
<CODE ENDS>
While this extension can appear in either an 802.AR manufacturer While this extension can appear in either an 802.AR manufacturer
certificate (IDevID) or deployment certificate (LDevID), of course it certificate (IDevID) or deployment certificate (LDevID), of course it
is not guaranteed in either, nor is it guaranteed to be carried over. is not guaranteed in either, nor is it guaranteed to be carried over.
It is RECOMMENDED that MUD manager implementations maintain a table It is RECOMMENDED that MUD manager implementations maintain a table
that maps a Thing to its MUD URL based on IDevIDs. that maps a Thing to its MUD URL based on IDevIDs.
12. The Manufacturer Usage Description LLDP extension 12. The Manufacturer Usage Description LLDP extension
The IEEE802.1AB Link Layer Discovery Protocol (LLDP) is a one hop The IEEE802.1AB Link Layer Discovery Protocol (LLDP) is a one hop
skipping to change at page 36, line 8 skipping to change at page 36, line 8
The other Things do not acknowledge LLDP information received from a The other Things do not acknowledge LLDP information received from a
Thing. No specific network behavior is guaranteed. When a Thing Thing. No specific network behavior is guaranteed. When a Thing
consumes this extension, it may either forward the URL and relevant consumes this extension, it may either forward the URL and relevant
remote Thing information to a MUD manager, or it will retrieve the remote Thing information to a MUD manager, or it will retrieve the
usage description by resolving the URL in accordance with normal HTTP usage description by resolving the URL in accordance with normal HTTP
semantics. semantics.
13. Creating and Processing of Signed MUD Files 13. Creating and Processing of Signed MUD Files
Because MUD files contain information that may be used to configure Because MUD files contain information that may be used to configure
network access lists, they are sensitive. To insure that they have network access lists, they are sensitive. To ensure that they have
not been tampered with, it is important that they be signed. We make not been tampered with, it is important that they be signed. We make
use of DER-encoded Cryptographic Message Syntax (CMS) [RFC5652] for use of DER-encoded Cryptographic Message Syntax (CMS) [RFC5652] for
this purpose. this purpose.
13.1. Creating a MUD file signature 13.1. Creating a MUD file signature
A MUD file MUST be signed using CMS as an opaque binary object. In A MUD file MUST be signed using CMS as an opaque binary object. In
order to make successful verification more likely, intermediate order to make successful verification more likely, intermediate
certificates SHOULD be included. The signature is stored at the certificates SHOULD be included. The signature is stored at the
location specified in the MUD file. Signatures are transferred using location specified in the MUD file. Signatures are transferred using
skipping to change at page 36, line 33 skipping to change at page 36, line 33
% openssl cms -sign -signer mancertfile -inkey mankey \ % openssl cms -sign -signer mancertfile -inkey mankey \
-in mudfile -binary -outform DER -binary \ -in mudfile -binary -outform DER -binary \
-certfile intermediatecert -out mudfile.p7s -certfile intermediatecert -out mudfile.p7s
Note: A MUD file may need to be re-signed if the signature expires. Note: A MUD file may need to be re-signed if the signature expires.
13.2. Verifying a MUD file signature 13.2. Verifying a MUD file signature
Prior to processing the rest of a MUD file the MUD manager MUST Prior to processing the rest of a MUD file the MUD manager MUST
retrieve the MUD signature file by retrieving the value of "mud- retrieve the MUD signature file by retrieving the value of "mud-
signature" and validating the signature across the MUD file. A MUD signature" and validating the signature across the MUD file. The Key
manager MUST cease processing of that file it cannot validate the Usage Extension in the MUD file signature MUST have the bit
chain of trust to a known trust anchor until an administrator has digitalSignature(0) set. A MUD manager MUST cease processing of that
given approval. file it cannot validate the chain of trust to a known trust anchor or
if it cannot validate the id-pe-mudsigner field until an
administrator has given approval.
The purpose of the signature on the file is to assign accountability The purpose of the signature on the file is to assign accountability
to an entity, whose reputation can be used to guide administrators on to an entity, whose reputation can be used to guide administrators on
whether or not to accept a given MUD file. It is already common whether or not to accept a given MUD file. It is already common
place to check web reputation on the location of a server on which a place to check web reputation on the location of a server on which a
file resides. While it is likely that the manufacturer will be the file resides. While it is likely that the manufacturer will be the
signer of the file, this is not strictly necessary, and may not be signer of the file, this is not strictly necessary, and may not be
desirable. For one thing, in some environments, integrators may desirable. For one thing, in some environments, integrators may
install their own certificates. For another, what is more important install their own certificates. For another, what is more important
is the accountability of the recommendation, and not just the is the accountability of the recommendation, and not just the
relationship between the Thing and the file. relationship between the Thing and the file.
It is expected that the Key Usage extension would contain "Digital
Signature" and that the extended key usage would include either "code
signing" or "email protection". What is important is simply that the
verification step match the purpose of the signing certificate to its
use, and that the MUD manager and network administrator have approved
the trust relationship of the signer.
An example: An example:
% openssl cms -verify -in mudfile.p7s -inform DER -content mudfile % openssl cms -verify -in mudfile.p7s -inform DER -content mudfile
Note the additional step of verifying the common trust root. Note the additional step of verifying the common trust root.
14. Extensibility 14. Extensibility
One of our design goals is to see that MUD files are able to be One of our design goals is to see that MUD files are able to be
understood by as broad a cross-section of systems as is possible. understood by as broad a cross-section of systems as is possible.
skipping to change at page 38, line 16 skipping to change at page 38, line 10
"manufacturer" and "same-manufacturer" class may have impact on "manufacturer" and "same-manufacturer" class may have impact on
access of other Things. Put another way, the admission may grow the access of other Things. Put another way, the admission may grow the
access-list on switches connected to other Things, depending on how access-list on switches connected to other Things, depending on how
access is managed. Some care should be given on managing that access is managed. Some care should be given on managing that
access-list growth. Alternative methods such as additional network access-list growth. Alternative methods such as additional network
segmentation can be used to keep that growth within reason. segmentation can be used to keep that growth within reason.
Because as of this writing MUD is a new concept, one can expect a Because as of this writing MUD is a new concept, one can expect a
great many devices to not have implemented it. It remains a local great many devices to not have implemented it. It remains a local
deployment decision as to whether a device that is first connected deployment decision as to whether a device that is first connected
should be alloewed broad or limited access. Furthermore, as should be allowed broad or limited access. Furthermore, as mentioned
mentioned in the introduction, a deployment may choose to ignore a in the introduction, a deployment may choose to ignore a MUD policy
MUD policy in its entirety, but simply taken into account the MUD URL in its entirety, but simply taken into account the MUD URL as a
as a classifier to be used as part of a local policy decision. classifier to be used as part of a local policy decision.
Finally, please see directly below regarding device lifetimes and use Finally, please see directly below regarding device lifetimes and use
of domain names. of domain names.
16. Security Considerations 16. Security Considerations
Based on how a MUD URL is emitted, a Thing may be able to lie about Based on how a MUD URL is emitted, a Thing may be able to lie about
what it is, thus gaining additional network access. This happens what it is, thus gaining additional network access. This happens
when a device emits a MUD URL using DHCP or LLDP, and is either when a device emits a MUD URL using DHCP or LLDP, and is either
inappropriately admitted to a class such as "same-manufacturer" or inappropriately admitted to a class such as "same-manufacturer" or
given access to a device such as "my-controller", where such access given access to a device such as "my-controller", where such access
would otherwise be disallowed. Whether that is the case will depend would otherwise be disallowed. Whether that is the case will depend
on the deployment. Implementations SHOULD be configurable to on the deployment. Implementations SHOULD be configurable to
disallow additive access for devices using MUD-URLs that not emitted disallow additive access for devices using MUD-URLs that not emitted
in a secure fashion such as in a certificate. When insecure methods in a secure fashion such as in a certificate. Similarly,
are used by the MUD Manager, the classes SHOULD NOT contain devices implementations SHOULD NOT grant elevated permissions (beyond those
that use both insecure and secure methods, in order to prevent of devices presenting no MUD policy) to devices which do not strongly
privilege escalation attacks, and MUST NOT contain devices with the bind their identity to their L2/L3 transmissions. When insecure
same MUD-URL that is derived from both strong and weak authentication methods are used by the MUD Manager, the classes SHOULD NOT contain
methods. devices that use both insecure and secure methods, in order to
prevent privilege escalation attacks, and MUST NOT contain devices
with the same MUD-URL that are derived from both strong and weak
authentication methods.
Devices may forge source (L2/L3) information. Deployments should
apply appropriate protections to bind communications to the
authentication that has taken place. For 802.1X authentication, IEEE
802.1AE (MACsec) [IEEE8021AE] is one means by which this may happen.
A similar approach can be used with 802.11i (WPA2) [IEEE80211i].
Other means are available with other lower layer technologies.
Implementations using session-oriented access that is not
cryptographically bound should take care to remove state when any
form of break in the session is detected.
A rogue CA may sign a certificate that contains the same subject name A rogue CA may sign a certificate that contains the same subject name
as is listed in the MUDsigner field in the manufacturer certificate, as is listed in the MUDsigner field in the manufacturer certificate,
thus seemingly permitting a substitute MUD file for a device. There thus seemingly permitting a substitute MUD file for a device. There
are two mitigations available: first, if the signer changes, this may are two mitigations available: first, if the signer changes, this may
be flagged as an exception by the MUD manager. If the MUD file also be flagged as an exception by the MUD manager. If the MUD file also
changes, the MUD manager SHOULD seek administrator approval (it changes, the MUD manager SHOULD seek administrator approval (it
should do this in any case). In all circumstances, the MUD manager should do this in any case). In all circumstances, the MUD manager
MUST maintain a cache of trusted CAs for this purpose. When such a MUST maintain a cache of trusted CAs for this purpose. When such a
rogue is discovered, it SHOULD be removed. rogue is discovered, it SHOULD be removed.
skipping to change at page 39, line 14 skipping to change at page 39, line 21
When certificates are not present, Things claiming to be of a certain When certificates are not present, Things claiming to be of a certain
manufacturer SHOULD NOT be included in that manufacturer grouping manufacturer SHOULD NOT be included in that manufacturer grouping
without additional validation of some form. This will be relevant without additional validation of some form. This will be relevant
when it makes use of primitives such as "manufacturer" for the when it makes use of primitives such as "manufacturer" for the
purpose of accessing Things of a particular type. Similarly, network purpose of accessing Things of a particular type. Similarly, network
management systems may be able to fingerprint the Thing. In such management systems may be able to fingerprint the Thing. In such
cases, the MUD URL can act as a classifier that can be proven or cases, the MUD URL can act as a classifier that can be proven or
disproven. Fingerprinting may have other advantages as well: when disproven. Fingerprinting may have other advantages as well: when
802.1AR certificates are used, because they themselves cannot change, 802.1AR certificates are used, because they themselves cannot change,
fingerprinting offers the opportunity to add artifacts to the MUD URL fingerprinting offers the opportunity to add artifacts to the MUD
in the form of the reserved field discussed in Section 10. The string in the form of the reserved field discussed in Section 10.
meaning of such artifacts is left as future work. The meaning of such artifacts is left as future work.
MUD managers SHOULD NOT accept a usage description for a Thing with MUD managers SHOULD NOT accept a usage description for a Thing with
the same MAC address that has indicated a change of the URL authority the same MAC address that has indicated a change of the URL authority
without some additional validation (such as review by a network without some additional validation (such as review by a network
administrator). New Things that present some form of unauthenticated administrator). New Things that present some form of unauthenticated
MUD URL SHOULD be validated by some external means when they would be MUD URL SHOULD be validated by some external means when they would be
be given increased network access. be given increased network access.
It may be possible for a rogue manufacturer to inappropriately It may be possible for a rogue manufacturer to inappropriately
exercise the MUD file parser, in order to exploit a vulnerability. exercise the MUD file parser, in order to exploit a vulnerability.
skipping to change at page 39, line 47 skipping to change at page 40, line 6
Use of a URL necessitates the use of domain names. If a domain name Use of a URL necessitates the use of domain names. If a domain name
changes ownership, the new owner of that domain may be able to changes ownership, the new owner of that domain may be able to
provide MUD files that MUD managers would consider valid. There are provide MUD files that MUD managers would consider valid. There are
a few approaches that can mitigate this attack. First, MUD managers a few approaches that can mitigate this attack. First, MUD managers
SHOULD cache certificates used by the MUD file server. When a new SHOULD cache certificates used by the MUD file server. When a new
certificate is retrieved for whatever reason, the MUD manager should certificate is retrieved for whatever reason, the MUD manager should
check to see if ownership of the domain has changed. A fair check to see if ownership of the domain has changed. A fair
programmatic approximation of this is when the name servers for the programmatic approximation of this is when the name servers for the
domain have changed. If the actual MUD file has changed, the MUD domain have changed. If the actual MUD file has changed, the MUD
manager MAY check the WHOIS database to see if registration ownership manager MAY check the WHOIS database to see if registration ownership
of a domain has changed. If a change has occured, or if for some of a domain has changed. If a change has occurred, or if for some
reason it is not possible to determine whether ownership has changed, reason it is not possible to determine whether ownership has changed,
further review may be warranted. Note, this remediation does not further review may be warranted. Note, this remediation does not
take into account the case of a Thing that was produced long ago and take into account the case of a Thing that was produced long ago and
only recently fielded, or the case where a new MUD manager has been only recently fielded, or the case where a new MUD manager has been
installed. installed.
The release of a MUD URL by a Thing reveals what the Thing is, and The release of a MUD URL by a Thing reveals what the Thing is, and
provides an attacker with guidance on what vulnerabilities may be provides an attacker with guidance on what vulnerabilities may be
present. present.
skipping to change at page 40, line 49 skipping to change at page 41, line 13
by unauthorized parties. by unauthorized parties.
17. IANA Considerations 17. IANA Considerations
[ There was originally a registry entry for .well-known suffixes. [ There was originally a registry entry for .well-known suffixes.
This has been removed from the draft and may be marked as deprecated This has been removed from the draft and may be marked as deprecated
in the registry. RFC Editor: please remove this comment. ] in the registry. RFC Editor: please remove this comment. ]
17.1. YANG Module Registrations 17.1. YANG Module Registrations
The following YANG modules are requested to be registred in the "IANA The following YANG modules are requested to be registered in the
Module Names" registry: "IANA Module Names" registry:
The ietf-mud module: The ietf-mud module:
o Name: ietf-mud o Name: ietf-mud
o URN: urn:ietf:params:xml:ns:yang:ietf-mud o URN: urn:ietf:params:xml:ns:yang:ietf-mud
o Prefix: ietf-mud o Prefix: ietf-mud
o Registrant conact: The IESG o Registrant conact: The IESG
skipping to change at page 47, line 29 skipping to change at page 47, line 33
19.2. Informative References 19.2. Informative References
[FW95] Chapman, D. and E. Zwicky, "Building Internet Firewalls", [FW95] Chapman, D. and E. Zwicky, "Building Internet Firewalls",
January 1995. January 1995.
[I-D.ietf-netmod-rfc6087bis] [I-D.ietf-netmod-rfc6087bis]
Bierman, A., "Guidelines for Authors and Reviewers of YANG Bierman, A., "Guidelines for Authors and Reviewers of YANG
Data Model Documents", draft-ietf-netmod-rfc6087bis-20 Data Model Documents", draft-ietf-netmod-rfc6087bis-20
(work in progress), March 2018. (work in progress), March 2018.
[IEEE80211i]
Institute for Electrical and Electronics Engineers, "IEEE
Standard for information technology-Telecommunications and
information exchange between systems-Local and
metropolitan area networks-Specific requirements-Part 11-
Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) specifications- Amendment 6- Medium Access
Control (MAC) Security Enhancements", 2004.
[IEEE8021AE]
Institute for Electrical and Electronics Engineers, "IEEE
Standard for Local and Metropolitan Area Networks- Media
Access Control (MAC) Security", 2006.
[IEEE8021AR] [IEEE8021AR]
Institute for Electrical and Electronics Engineers, Institute for Electrical and Electronics Engineers,
"Secure Device Identity", 1998. "Secure Device Identity", 1998.
[IEEE8021X]
Institute for Electrical and Electronics Engineers, "IEEE
Standard for Local and metropolitan area networks--Port-
Based Network Access Control", 2010.
[ISO.8601.1988] [ISO.8601.1988]
International Organization for Standardization, "Data International Organization for Standardization, "Data
elements and interchange formats - Information interchange elements and interchange formats - Information interchange
- Representation of dates and times", ISO Standard 8601, - Representation of dates and times", ISO Standard 8601,
June 1988. June 1988.
[RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic [RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic
Technology and the Internet", BCP 200, RFC 1984, Technology and the Internet", BCP 200, RFC 1984,
DOI 10.17487/RFC1984, August 1996, DOI 10.17487/RFC1984, August 1996,
<https://www.rfc-editor.org/info/rfc1984>. <https://www.rfc-editor.org/info/rfc1984>.
skipping to change at page 52, line 36 skipping to change at page 53, line 17
What follows is the portion of a MUD file that permits DNS traffic to What follows is the portion of a MUD file that permits DNS traffic to
a controller that is registered with the URN a controller that is registered with the URN
"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 manager might received, the defaults would not be reached. A MUD manager 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 overridden.
Four "acl" list entries that implement default MUD nodes are listed Four "acl" list entries that implement default MUD nodes are listed
below. Two are for IPv4 and two are for IPv6 (one in each direction below. Two are for IPv4 and two are for IPv6 (one in each direction
for both versions of IP). Note that neither access-list name nor ace 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, name need be retained or used in any way by local implementations,
but are simply there for completeness' sake. but are simply there for completeness' sake.
"ietf-access-control-list:access-lists": { "ietf-access-control-list:acls": {
"acl": [ "acl": [
{ {
"name": "mud-59776-v4to", "name": "mud-59776-v4to",
"type": "ipv4-acl-type", "type": "ipv4-acl-type",
"aces": { "aces": {
"ace": [ "ace": [
{ {
"name": "ent0-todev", "name": "ent0-todev",
"matches": { "matches": {
"ietf-mud:mud": { "ietf-mud:mud": {
skipping to change at page 57, line 25 skipping to change at page 58, line 5
This extension augments the MUD model to include a single node, using This extension augments the MUD model to include a single node, using
the following sample module that has the following tree structure: the following sample module that has the following tree structure:
module: ietf-mud-detext-example module: ietf-mud-detext-example
augment /ietf-mud:mud: augment /ietf-mud:mud:
+--rw is-detnet-required? boolean +--rw is-detnet-required? boolean
The model is defined as follows: The model is defined as follows:
<CODE BEGINS>file "ietf-mud-detext-example@2018-04-12.yang" <CODE BEGINS>file "ietf-mud-detext-example@2018-05-22.yang"
module ietf-mud-detext-example { module ietf-mud-detext-example {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-mud-detext-example"; namespace "urn:ietf:params:xml:ns:yang:ietf-mud-detext-example";
prefix ietf-mud-detext-example; prefix ietf-mud-detext-example;
import ietf-mud { import ietf-mud {
prefix ietf-mud; prefix ietf-mud;
} }
organization organization
skipping to change at page 58, line 5 skipping to change at page 58, line 32
Author: Ralph Droms Author: Ralph Droms
rdroms@gmail.com rdroms@gmail.com
Author: Dan Romascanu Author: Dan Romascanu
dromasca@gmail.com dromasca@gmail.com
"; ";
description description
"Sample extension to a MUD module to indicate a need "Sample extension to a MUD module to indicate a need
for DETNET support."; for DETNET support.";
revision 2018-04-12 { revision 2018-05-22 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: Manufacturer Usage Description "RFC XXXX: Manufacturer Usage Description
Specification"; Specification";
} }
augment "/ietf-mud:mud" { augment "/ietf-mud:mud" {
description description
"This adds a simple extension for a manufacturer "This adds a simple extension for a manufacturer
skipping to change at page 59, line 13 skipping to change at page 59, line 40
"to-device-policy": { "to-device-policy": {
"access-lists": { "access-lists": {
"access-list": [ "access-list": [
{ {
"name": "mud-76100-v6to" "name": "mud-76100-v6to"
} }
] ]
} }
} }
}, },
"ietf-access-control-list:access-lists": { "ietf-access-control-list:acls": {
"acl": [ "acl": [
{ {
"name": "mud-76100-v6to", "name": "mud-76100-v6to",
"type": "ipv6-acl-type", "type": "ipv6-acl-type",
"aces": { "aces": {
"ace": [ "ace": [
{ {
"name": "cl0-todev", "name": "cl0-todev",
"matches": { "matches": {
"ipv6": { "ipv6": {
 End of changes. 86 change blocks. 
169 lines changed or deleted 208 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/