draft-ietf-opsawg-mud-18.txt   draft-ietf-opsawg-mud-19.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: September 3, 2018 Expires: October 5, 2018 Google
D. Romascanu D. Romascanu
March 02, 2018 April 03, 2018
Manufacturer Usage Description Specification Manufacturer Usage Description Specification
draft-ietf-opsawg-mud-18 draft-ietf-opsawg-mud-19
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
LLDP TLV, a URL suffix specification, an X.509 certificate extension LLDP TLV, a URL, an X.509 certificate extension and a means to sign
and a means to sign and verify the descriptions. and verify the descriptions.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 September 3, 2018. This Internet-Draft will expire on October 5, 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 32 skipping to change at page 2, line 32
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 . . . . . . . . . . . . . . . . 13 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 . . . 15 3.2. to-device-policy and from-device-policy containers . . . 15
3.3. last-update . . . . . . . . . . . . . . . . . . . . . . . 15 3.3. last-update . . . . . . . . . . . . . . . . . . . . . . . 15
3.4. cache-validity . . . . . . . . . . . . . . . . . . . . . 15 3.4. cache-validity . . . . . . . . . . . . . . . . . . . . . 15
3.5. is-supported . . . . . . . . . . . . . . . . . . . . . . 15 3.5. is-supported . . . . . . . . . . . . . . . . . . . . . . 15
3.6. systeminfo . . . . . . . . . . . . . . . . . . . . . . . 15 3.6. systeminfo . . . . . . . . . . . . . . . . . . . . . . . 15
3.7. mfg-name, hardware-rev, software-rev, model-name 3.7. mfg-name, software-rev, model-name firmware-rev . . . . . 16
firmware-rev . . . . . . . . . . . . . . . . . . . . . . 16
3.8. extensions . . . . . . . . . . . . . . . . . . . . . . . 16 3.8. extensions . . . . . . . . . . . . . . . . . . . . . . . 16
3.9. manufacturer . . . . . . . . . . . . . . . . . . . . . . 16 3.9. manufacturer . . . . . . . . . . . . . . . . . . . . . . 16
3.10. same-manufacturer . . . . . . . . . . . . . . . . . . . . 16 3.10. same-manufacturer . . . . . . . . . . . . . . . . . . . . 16
3.11. model . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.11. model . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.12. local-networks . . . . . . . . . . . . . . . . . . . . . 17 3.12. local-networks . . . . . . . . . . . . . . . . . . . . . 17
3.13. controller . . . . . . . . . . . . . . . . . . . . . . . 17 3.13. controller . . . . . . . . . . . . . . . . . . . . . . . 17
3.14. my-controller . . . . . . . . . . . . . . . . . . . . . . 17 3.14. my-controller . . . . . . . . . . . . . . . . . . . . . . 17
3.15. direction-initiated . . . . . . . . . . . . . . . . . . . 17 3.15. direction-initiated . . . . . . . . . . . . . . . . . . . 17
4. Processing of the MUD file . . . . . . . . . . . . . . . . . 18 4. Processing of the MUD file . . . . . . . . . . . . . . . . . 18
5. What does a MUD URL look like? . . . . . . . . . . . . . . . 18 5. What does a MUD URL look like? . . . . . . . . . . . . . . . 18
6. The MUD YANG Model . . . . . . . . . . . . . . . . . . . . . 19 6. The MUD YANG Model . . . . . . . . . . . . . . . . . . . . . 18
7. The Domain Name Extension to the ACL Model . . . . . . . . . 25 7. The Domain Name Extension to the ACL Model . . . . . . . . . 25
7.1. src-dnsname . . . . . . . . . . . . . . . . . . . . . . . 26 7.1. src-dnsname . . . . . . . . . . . . . . . . . . . . . . . 25
7.2. dst-dnsname . . . . . . . . . . . . . . . . . . . . . . . 26 7.2. dst-dnsname . . . . . . . . . . . . . . . . . . . . . . . 25
7.3. The ietf-acldns Model . . . . . . . . . . . . . . . . . . 26 7.3. The ietf-acldns Model . . . . . . . . . . . . . . . . . . 26
8. MUD File Example . . . . . . . . . . . . . . . . . . . . . . 27 8. MUD File Example . . . . . . . . . . . . . . . . . . . . . . 27
9. The MUD URL DHCP Option . . . . . . . . . . . . . . . . . . . 30 9. The MUD URL DHCP Option . . . . . . . . . . . . . . . . . . . 29
9.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 30 9.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 30
9.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 31 9.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 31
9.3. Relay Requirements . . . . . . . . . . . . . . . . . . . 31 9.3. Relay Requirements . . . . . . . . . . . . . . . . . . . 31
10. The Manufacturer Usage Description (MUD) URL X.509 Extension 31 10. The Manufacturer Usage Description (MUD) URL X.509 Extension 31
11. The Manufacturer Usage Description LLDP extension . . . . . . 33 11. The Manufacturer Usage Description LLDP extension . . . . . . 33
12. Creating and Processing of Signed MUD Files . . . . . . . . . 35 12. Creating and Processing of Signed MUD Files . . . . . . . . . 34
12.1. Creating a MUD file signature . . . . . . . . . . . . . 35 12.1. Creating a MUD file signature . . . . . . . . . . . . . 34
12.2. Verifying a MUD file signature . . . . . . . . . . . . . 35 12.2. Verifying a MUD file signature . . . . . . . . . . . . . 34
13. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 36 13. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 35
14. Deployment Considerations . . . . . . . . . . . . . . . . . . 36 14. Deployment Considerations . . . . . . . . . . . . . . . . . . 35
15. Security Considerations . . . . . . . . . . . . . . . . . . . 37 15. Security Considerations . . . . . . . . . . . . . . . . . . . 36
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
16.1. YANG Module Registrations . . . . . . . . . . . . . . . 39 16.1. YANG Module Registrations . . . . . . . . . . . . . . . 38
16.2. DHCPv4 and DHCPv6 Options . . . . . . . . . . . . . . . 40 16.2. DHCPv4 and DHCPv6 Options . . . . . . . . . . . . . . . 39
16.3. PKIX Extensions . . . . . . . . . . . . . . . . . . . . 40 16.3. PKIX Extensions . . . . . . . . . . . . . . . . . . . . 39
16.4. MIME Media-type Registration for MUD files . . . . . . . 40 16.4. MIME Media-type Registration for MUD files . . . . . . . 39
16.5. LLDP IANA TLV Subtype Registry . . . . . . . . . . . . . 41 16.5. LLDP IANA TLV Subtype Registry . . . . . . . . . . . . . 40
16.6. The MUD Well Known Universal Resource Name (URNs) . . . 42 16.6. The MUD Well Known Universal Resource Name (URNs) . . . 41
16.7. Extensions Registry . . . . . . . . . . . . . . . . . . 42 16.7. Extensions Registry . . . . . . . . . . . . . . . . . . 41
17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
18.1. Normative References . . . . . . . . . . . . . . . . . . 43 18.1. Normative References . . . . . . . . . . . . . . . . . . 42
18.2. Informative References . . . . . . . . . . . . . . . . . 45 18.2. Informative References . . . . . . . . . . . . . . . . . 44
Appendix A. Changes from Earlier Versions . . . . . . . . . . . 47 Appendix A. Changes from Earlier Versions . . . . . . . . . . . 46
Appendix B. Default MUD nodes . . . . . . . . . . . . . . . . . 50 Appendix B. Default MUD nodes . . . . . . . . . . . . . . . . . 50
Appendix C. A Sample Extension: DETNET-indicator . . . . . . . . 55 Appendix C. A Sample Extension: DETNET-indicator . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58
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
skipping to change at page 13, line 22 skipping to change at page 13, line 22
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 "access-lists" container. Extensions may add additional root an "acls" container. Extensions may add additional root objects as
objects as required. As a reminder, when parsing access-lists, required. As a reminder, when parsing access-lists, elements within
elements within a "match" block are logically ANDed. In general, a a "match" block are logically ANDed. In general, a single
single abstraction in a match statement should be used. For abstraction in a match statement should be used. For instance, it
instance, it makes little sense to match both "my-controller" and makes little sense to match both "my-controller" and "controller"
"controller" with an argument, since they are highly unlikely to be with an argument, since they are highly unlikely to be the same
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 [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 mud-signature? inet:uri +--rw mud-signature? inet:uri
+--rw cache-validity? uint8 +--rw cache-validity? uint8
+--rw is-supported boolean +--rw is-supported boolean
+--rw systeminfo? inet:uri +--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 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: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
+--rw my-controller? empty +--rw my-controller? empty
augment /acl:access-lists/acl:acl/acl:aces/acl:ace augment /acl:access-lists/acl:acl/acl:aces/acl:ace
/acl:matches/acl:l4/acl:tcp/acl:tcp: /acl:matches/acl:l4/acl:tcp/acl:tcp:
+--rw direction-initiated? direction +--rw direction-initiated? direction
skipping to change at page 16, line 5 skipping to change at page 16, line 5
intends never to issue an update to the Thing or never update the MUD intends never to issue an update to the Thing or never update the MUD
file. A MUD controller MAY still periodically check for updates. file. A MUD controller MAY still periodically check for updates.
3.6. systeminfo 3.6. systeminfo
This is a textual UTF-8 description of the Thing to be connected. This is a textual UTF-8 description of the Thing to be connected.
The intent is for administrators to be able to see a localized name The intent is for administrators to be able to see a localized name
associated with the Thing. It SHOULD NOT exceed 60 characters worth associated with the Thing. It SHOULD NOT exceed 60 characters worth
of display space (that is- what the administrator actually sees). of display space (that is- what the administrator actually sees).
3.7. mfg-name, hardware-rev, software-rev, model-name firmware-rev 3.7. mfg-name, software-rev, model-name firmware-rev
These optional fields are filled in as specified by These optional fields are filled in as specified by
[I-D.ietf-netmod-entity]. Note that firmware-rev and software-rev [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 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 the MUD-URL cannot be. This would be the case, for instance, with
MUR-URLs that are contained in 802.1AR certificates. MUR-URLs that are contained in 802.1AR certificates.
3.8. extensions 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
skipping to change at page 18, line 26 skipping to change at page 18, line 26
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 These are applied AFTER all other explicit rules. Thus, a default
behavior can be changed with a "drop" action. behavior can be changed with a "drop" action.
5. What does a MUD URL look like? 5. What does a MUD URL look like?
MUD URLs are required to use the HTTPS scheme, in order to establish MUD URLs are required to use the HTTPS scheme, in order to establish
the MUD file server's identity and assure integrity of the MUD file. the MUD file server's identity and assure integrity of the MUD file.
Any "https://" URL without a query component can be a MUD URL. For Any "https://" URL can be a MUD URL. For example:
example:
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
======= The MUD URL identifies a Thing with a specificity according The MUD URL identifies a Thing with a specificity according to the
to the manufacturer's wishes. It could include a brand name, model manufacturer's wishes. It could include a brand name, model number,
number, or something more specific. It also could provide a means to or something more specific. It also could provide a means to
indicate what version the product is. indicate what version the product is.
Specifically, if the intended communication patterns of a Thing Specifically, if the intended communication patterns of a Thing
change, as compared to other things, the MUD URL should change. For change, as compared to other things, the MUD URL should change. For
example, if a new model of light bulb is released that requires example, if a new model of light bulb is released that requires
access to different network services, it would have a separate MUD access to different network services, it would have a separate MUD
URL from those that do not. URL from those that do not.
The query string of the MUD URL is reserved for potential future use;
MUD URLs MUST NOT contain queries when sent to the controller. MUD
file servers MUST ignore query parameters that they do not
understand.
Note that if the MUD URL contains a fragment identifier (e.g.,
"#foo"), that information will not be sent to the MUD file server in
the HTTP request. However, it will still be considered a separate
MUD URL by the controller.
6. The MUD YANG Model 6. The MUD YANG Model
<CODE BEGINS>file "ietf-mud@2018-03-01.yang" <CODE BEGINS>file "ietf-mud@2018-03-01.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;
skipping to change at page 21, line 50 skipping to change at page 21, line 39
need not discard MUD files beyond this period."; need not discard MUD files beyond this period.";
} }
leaf is-supported { leaf is-supported {
type boolean; type boolean;
mandatory true; mandatory true;
description description
"This boolean indicates whether or not the Thing is "This boolean indicates whether or not the Thing is
currently supported by the manufacturer."; currently supported by the manufacturer.";
} }
leaf systeminfo { leaf systeminfo {
type inet:uri; type string;
description description
"A URL to a description of this Thing. This "A UTF-8 description of this Thing. This
should be a brief localized description. The should be a brief description that may be
reference text should be no more than octets. displayed to the user to determine whether
systeminfo may be displayed to the user to to allow the Thing on the
determine whether 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 "Manufacturer name, as described in
the ietf-hardware yang module."; 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;
skipping to change at page 23, line 41 skipping to change at page 23, line 28
to or from the device."; to or from the device.";
list access-list { list access-list {
key "name"; key "name";
description description
"Each entry on this list refers to an ACL that "Each entry on this list refers to an ACL that
should be present in the overall access list should be present in the overall access list
data model. Each ACL is identified by name and data model. Each ACL is identified by name and
type."; type.";
leaf name { leaf name {
type leafref { type leafref {
path "/acl:access-lists/acl:acl/acl:name"; path "/acl:acls/acl:acl/acl:name";
} }
description description
"The name of the ACL for this entry."; "The name of the ACL for this entry.";
} }
} }
} }
} }
augment "/acl:access-lists/acl:acl/acl:aces/acl:ace/acl:matches" { augment "/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches" {
description description
"adding abstractions to avoid need of IP addresses"; "adding abstractions to avoid need of IP addresses";
container mud { container mud {
description description
"MUD-specific matches."; "MUD-specific matches.";
leaf manufacturer { leaf manufacturer {
type inet:host; type inet:host;
description description
"A domain that is intended to match the authority "A domain that is intended to match the authority
section of the MUD URL. This node is used to specify section of the MUD URL. This node is used to specify
one or more manufacturers a device should one or more manufacturers a device should
be authorized to access."; be authorized to access.";
skipping to change at page 25, line 4 skipping to change at page 24, line 39
URN."; URN.";
} }
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:access-lists/acl:acl/acl:aces/" + augment "/acl:acls/acl:acl/acl:aces/" +
"acl:ace/acl:matches/acl:l4/acl:tcp/acl:tcp" { "acl:ace/acl:matches/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 27, line 29 skipping to change at page 27, line 14
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: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" {
description "Adding domain names to matching"; description "Adding domain names to matching";
uses dns-matches; uses dns-matches;
} }
augment "/acl:access-lists/acl:acl/" + augment "/acl:acls/acl:acl/" +
"acl:aces/acl:ace/" + "acl:aces/acl:ace/" +
"acl:matches/acl:l3/acl:ipv6/acl:ipv6" { "acl:matches/acl:l3/acl:ipv6/acl:ipv6" {
description "Adding domain names to matching"; description "Adding domain names to matching";
uses dns-matches; uses dns-matches;
} }
} }
<CODE ENDS> <CODE ENDS>
8. MUD File Example 8. MUD File Example
skipping to change at page 30, line 10 skipping to change at page 29, line 39
list, access is permitted to packets flowing to or from the Thing list, access is permitted to packets flowing to or from the Thing
that can be mapped to the domain name of "service.bms.example.com". that can be mapped to the domain name of "service.bms.example.com".
For each access list, the enforcement point should expect that the For each access list, the enforcement point should expect that the
Thing initiated the connection. Thing initiated the connection.
9. The MUD URL DHCP Option 9. The MUD URL DHCP Option
The IPv4 MUD URL client option has the following format: The IPv4 MUD URL client option has the following format:
+------+-----+------------------------------ +------+-----+------------------------------
| code | len | MUD URL | code | len | MUDstring
+------+-----+------------------------------ +------+-----+------------------------------
Code OPTION_MUD_URL_V4 (161) is assigned by IANA. len is a single Code OPTION_MUD_URL_V4 (161) is assigned by IANA. len is a single
octet that indicates the length of the URL in octets. MUD URL is a octet that indicates the length of MUD string in octets. The MUD
URL. MUD URLs MUST NOT exceed 255 octets. string is defined as follows:
MUDstring = mudurl [ " " reserved ]
mudurl = URI; a URL [RFC3986] that uses the "https" schema [RFC7230]
reserved = 1*( CHAR ) ; from [RFC5234]
The entire option MUST NOT exceed 255 octets. If a space follows the
MUD URL, a reserved string that will be defined in future
specifications follows. MUD controllers that do not understand this
field MUST ignore it.
The IPv6 MUD URL client option has the following format: The IPv6 MUD URL client option has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_MUD_URL_V6 | option-length | | OPTION_MUD_URL_V6 | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUD URL | | MUDstring |
| ... | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OPTION_MUD_URL_V6 (112; assigned by IANA). OPTION_MUD_URL_V6 (112; assigned by IANA).
option-length contains the length of the URL in octets. option-length contains the length of the MUDstring, as defined above,
in octets.
The intent of this option is to provide both a new Thing classifier The intent of this option is to provide both a new Thing classifier
to the network as well as some recommended configuration to the to the network as well as some recommended configuration to the
routers that implement policy. However, it is entirely the purview routers that implement policy. However, it is entirely the purview
of the network system as managed by the network administrator to of the network system as managed by the network administrator to
decide what to do with this information. The key function of this decide what to do with this information. The key function of this
option is simply to identify the type of Thing to the network in a option is simply to identify the type of Thing to the network in a
structured way such that the policy can be easily found with existing structured way such that the policy can be easily found with existing
toolsets. toolsets.
skipping to change at page 43, line 12 skipping to change at page 42, line 12
architecture and the YANG model. The remaining errors in this work architecture and the YANG model. The remaining errors in this work
are entirely the responsibility of the authors. are entirely the responsibility of the authors.
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-16 (work in progress), draft-ietf-netmod-acl-model-18 (work in progress), March
February 2018. 2018.
[I-D.ietf-netmod-entity] [I-D.ietf-netmod-entity]
Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A
YANG Data Model for Hardware Management", draft-ietf- YANG Data Model for Hardware Management", draft-ietf-
netmod-entity-08 (work in progress), January 2018. 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-06 (work in progress), ietf-netmod-yang-tree-diagrams-06 (work in progress),
February 2018. February 2018.
skipping to change at page 44, line 24 skipping to change at page 43, line 24
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987,
January 2005, <https://www.rfc-editor.org/info/rfc3987>. January 2005, <https://www.rfc-editor.org/info/rfc3987>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>. <https://www.rfc-editor.org/info/rfc5652>.
skipping to change at page 45, line 40 skipping to change at page 44, line 48
RFC 7951, DOI 10.17487/RFC7951, August 2016, RFC 7951, DOI 10.17487/RFC7951, August 2016,
<https://www.rfc-editor.org/info/rfc7951>. <https://www.rfc-editor.org/info/rfc7951>.
18.2. Informative References 18.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-18 Data Model Documents", draft-ietf-netmod-rfc6087bis-20
(work in progress), February 2018. (work in progress), March 2018.
[IEEE8021AR] [IEEE8021AR]
Institute for Electrical and Electronics Engineers, Institute for Electrical and Electronics Engineers,
"Secure Device Identity", 1998. "Secure Device Identity", 1998.
[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.
skipping to change at page 47, line 19 skipping to change at page 46, line 28
[RFC7488] Boucadair, M., Penno, R., Wing, D., Patil, P., and T. [RFC7488] Boucadair, M., Penno, R., Wing, D., Patil, P., and T.
Reddy, "Port Control Protocol (PCP) Server Selection", Reddy, "Port Control Protocol (PCP) Server Selection",
RFC 7488, DOI 10.17487/RFC7488, March 2015, RFC 7488, DOI 10.17487/RFC7488, March 2015,
<https://www.rfc-editor.org/info/rfc7488>. <https://www.rfc-editor.org/info/rfc7488>.
Appendix A. Changes from Earlier Versions Appendix A. Changes from Earlier Versions
RFC Editor to remove this section prior to publication. RFC Editor to remove this section prior to publication.
Draft -19: * Edits after discussion with apps area to address
reserved field for the future. * Correct systeminfo to be utf8. *
Remove "hardware-rev" from list.
Draft -18: * Correct an error in the augment statement * Changes to Draft -18: * Correct an error in the augment statement * Changes to
the ACL model re ports. the ACL model re ports.
Draft -17: Draft -17:
o One editorial. o One editorial.
Draft -16 Draft -16
o add mud-signature element based on review comments o add mud-signature element based on review comments
skipping to change at page 58, line 47 skipping to change at page 58, line 17
Eliot Lear Eliot Lear
Cisco Systems Cisco Systems
Richtistrasse 7 Richtistrasse 7
Wallisellen CH-8304 Wallisellen CH-8304
Switzerland Switzerland
Phone: +41 44 878 9200 Phone: +41 44 878 9200
Email: lear@cisco.com Email: lear@cisco.com
Ralph Droms Ralph Droms
Google
355 Main St., 5th Floor
Cambridge
Phone: +1 978 376 3731 Phone: +1 978 376 3731
Email: rdroms@gmail.com Email: rdroms@gmail.com
Dan Romascanu Dan Romascanu
Phone: +972 54 5555347 Phone: +972 54 5555347
Email: dromasca@gmail.com Email: dromasca@gmail.com
 End of changes. 38 change blocks. 
80 lines changed or deleted 89 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/