draft-ietf-opsawg-mud-06.txt   draft-ietf-opsawg-mud-07.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 16, 2017 Expires: January 4, 2018
D. Romascanu D. Romascanu
May 15, 2017 July 03, 2017
Manufacturer Usage Description Specification Manufacturer Usage Description Specification
draft-ietf-opsawg-mud-06 draft-ietf-opsawg-mud-07
Abstract Abstract
This memo specifies a component-based architecture for manufacturer This memo specifies a component-based architecture for manufacturer
usage descriptions (MUD). This includes two YANG modules, IPv4 and usage descriptions (MUD). This includes two YANG modules, IPv4 and
IPv6 DHCP options, an LLDP TLV, a URL suffix specification, an X.509 IPv6 DHCP options, an LLDP TLV, a URL suffix specification, an X.509
certificate extension and a means to sign and verify the certificate extension and a means to sign and verify the
descriptions. descriptions.
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 16, 2017. This Internet-Draft will expire on January 4, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 19 skipping to change at page 2, line 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. What MUD doesn't do . . . . . . . . . . . . . . . . . . . 4 1.1. What MUD doesn't do . . . . . . . . . . . . . . . . . . . 4
1.2. A Simple Example . . . . . . . . . . . . . . . . . . . . 4 1.2. A Simple Example . . . . . . . . . . . . . . . . . . . . 4
1.3. Determining Intended Use . . . . . . . . . . . . . . . . 5 1.3. Determining Intended Use . . . . . . . . . . . . . . . . 5
1.4. Finding A Policy: The MUD URL . . . . . . . . . . . . . . 5 1.4. Finding A Policy: The MUD URL . . . . . . . . . . . . . . 5
1.5. Types of Policies . . . . . . . . . . . . . . . . . . . . 6 1.5. Types of Policies . . . . . . . . . . . . . . . . . . . . 6
1.6. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 1.6. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
1.7. The Manufacturer Usage Description Architecture . . . . . 8 1.7. The Manufacturer Usage Description Architecture . . . . . 8
1.8. Order of operations . . . . . . . . . . . . . . . . . . . 9 1.8. Order of operations . . . . . . . . . . . . . . . . . . . 9
2. The MUD Model and Semantic Meaning . . . . . . . . . . . . . 9 2. The MUD Model and Semantic Meaning . . . . . . . . . . . . . 9
3. Element Definitions . . . . . . . . . . . . . . . . . . . . . 10 3. Element Definitions . . . . . . . . . . . . . . . . . . . . . 11
3.1. last-update . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. last-update . . . . . . . . . . . . . . . . . . . . . . . 11
3.2. cache-validity . . . . . . . . . . . . . . . . . . . . . 11 3.2. cache-validity . . . . . . . . . . . . . . . . . . . . . 11
3.3. masa-server . . . . . . . . . . . . . . . . . . . . . . . 11 3.3. masa-server . . . . . . . . . . . . . . . . . . . . . . . 12
3.4. is-supported . . . . . . . . . . . . . . . . . . . . . . 11 3.4. is-supported . . . . . . . . . . . . . . . . . . . . . . 12
3.5. systeminfo . . . . . . . . . . . . . . . . . . . . . . . 11 3.5. systeminfo . . . . . . . . . . . . . . . . . . . . . . . 12
3.6. extensions . . . . . . . . . . . . . . . . . . . . . . . 11 3.6. extensions . . . . . . . . . . . . . . . . . . . . . . . 12
3.7. packet-direction . . . . . . . . . . . . . . . . . . . . 11 3.7. packet-direction . . . . . . . . . . . . . . . . . . . . 12
3.8. manufacturer . . . . . . . . . . . . . . . . . . . . . . 12 3.8. manufacturer . . . . . . . . . . . . . . . . . . . . . . 12
3.9. same-manufacturer . . . . . . . . . . . . . . . . . . . . 12 3.9. same-manufacturer . . . . . . . . . . . . . . . . . . . . 13
3.10. model . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.10. model . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.11. local-networks . . . . . . . . . . . . . . . . . . . . . 12 3.11. local-networks . . . . . . . . . . . . . . . . . . . . . 13
3.12. controller . . . . . . . . . . . . . . . . . . . . . . . 12 3.12. controller . . . . . . . . . . . . . . . . . . . . . . . 13
3.13. my-controller . . . . . . . . . . . . . . . . . . . . . . 12 3.13. my-controller . . . . . . . . . . . . . . . . . . . . . . 13
3.14. direction-initiated . . . . . . . . . . . . . . . . . . . 13 3.14. direction-initiated . . . . . . . . . . . . . . . . . . . 13
4. Processing of the MUD file . . . . . . . . . . . . . . . . . 13 4. Processing of the MUD file . . . . . . . . . . . . . . . . . 14
5. What does a MUD URL look like? . . . . . . . . . . . . . . . 13 5. What does a MUD URL look like? . . . . . . . . . . . . . . . 14
6. The MUD YANG Model . . . . . . . . . . . . . . . . . . . . . 14 6. The MUD YANG Model . . . . . . . . . . . . . . . . . . . . . 15
7. The Domain Name Extension to the ACL Model . . . . . . . . . 17 7. The Domain Name Extension to the ACL Model . . . . . . . . . 20
7.1. source-dnsname . . . . . . . . . . . . . . . . . . . . . 18 7.1. source-dnsname . . . . . . . . . . . . . . . . . . . . . 21
7.2. destination-dnsname . . . . . . . . . . . . . . . . . . . 18 7.2. destination-dnsname . . . . . . . . . . . . . . . . . . . 21
7.3. The ietf-acldns Model . . . . . . . . . . . . . . . . . . 18 7.3. The ietf-acldns Model . . . . . . . . . . . . . . . . . . 21
8. MUD File Example . . . . . . . . . . . . . . . . . . . . . . 20 8. MUD File Example . . . . . . . . . . . . . . . . . . . . . . 22
9. The MUD URL DHCP Option . . . . . . . . . . . . . . . . . . . 21 9. The MUD URL DHCP Option . . . . . . . . . . . . . . . . . . . 24
9.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 22 9.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 25
9.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 22 9.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 25
9.3. Relay Requirements . . . . . . . . . . . . . . . . . . . 23 9.3. Relay Requirements . . . . . . . . . . . . . . . . . . . 26
10. The Manufacturer Usage Description (MUD) URL X.509 Extension 23 10. The Manufacturer Usage Description (MUD) URL X.509 Extension 26
11. The Manufacturer Usage Description LLDP extension . . . . . . 24 11. The Manufacturer Usage Description LLDP extension . . . . . . 27
12. Creating and Processing of Signed MUD Files . . . . . . . . . 26 12. Creating and Processing of Signed MUD Files . . . . . . . . . 29
12.1. Creating a MUD file signature . . . . . . . . . . . . . 26 12.1. Creating a MUD file signature . . . . . . . . . . . . . 29
12.2. Verifying a MUD file signature . . . . . . . . . . . . . 26 12.2. Verifying a MUD file signature . . . . . . . . . . . . . 29
13. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 27 13. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 30
14. Deployment Considerations . . . . . . . . . . . . . . . . . . 27 14. Deployment Considerations . . . . . . . . . . . . . . . . . . 30
15. Security Considerations . . . . . . . . . . . . . . . . . . . 28 15. Security Considerations . . . . . . . . . . . . . . . . . . . 31
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
16.1. YANG Module Registrations . . . . . . . . . . . . . . . 29 16.1. YANG Module Registrations . . . . . . . . . . . . . . . 32
16.2. DHCPv4 and DHCPv6 Options . . . . . . . . . . . . . . . 30 16.2. DHCPv4 and DHCPv6 Options . . . . . . . . . . . . . . . 33
16.3. PKIX Extensions . . . . . . . . . . . . . . . . . . . . 30 16.3. PKIX Extensions . . . . . . . . . . . . . . . . . . . . 33
16.4. Well Known URI Suffix . . . . . . . . . . . . . . . . . 30 16.4. Well Known URI Suffix . . . . . . . . . . . . . . . . . 33
16.5. MIME Media-type Registration for MUD files . . . . . . . 30 16.5. MIME Media-type Registration for MUD files . . . . . . . 33
16.6. LLDP IANA TLV Subtype Registry . . . . . . . . . . . . . 31 16.6. LLDP IANA TLV Subtype Registry . . . . . . . . . . . . . 34
16.7. The MUD Well Known Universal Resource Name (URNs) . . . 32 16.7. The MUD Well Known Universal Resource Name (URNs) . . . 35
17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
18.1. Normative References . . . . . . . . . . . . . . . . . . 32 18.1. Normative References . . . . . . . . . . . . . . . . . . 35
18.2. Informative References . . . . . . . . . . . . . . . . . 35 18.2. Informative References . . . . . . . . . . . . . . . . . 38
Appendix A. Changes from Earlier Versions . . . . . . . . . . . 36 Appendix A. Changes from Earlier Versions . . . . . . . . . . . 39
Appendix B. Default MUD elements . . . . . . . . . . . . . . . . 37 Appendix B. Default MUD elements . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
1. Introduction 1. Introduction
The Internet has largely been constructed on general purpose The Internet has largely been constructed on 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 buy the device. [RFC1984] presumed that an specified by those who buy 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 6, line 42 skipping to change at page 6, line 42
In this way anyone can print to the printer, but local access would In this way anyone can print to the printer, but local access would
be required for the management interface. be required for the management interface.
The files that are retrieved are intended to be closely aligned to The files that are retrieved are intended to be closely aligned to
existing network architectures so that they are easy to deploy. We existing network architectures so that they are easy to deploy. We
make use of YANG [RFC6020] because of the time and effort spent to make use of YANG [RFC6020] because of the time and effort spent to
develop accurate and adequate models for use by network devices. develop accurate and adequate models for use by network devices.
JSON is used as a serialization for compactness and readability, JSON is used as a serialization for compactness and readability,
relative to XML. relative to XML.
While the policy examples given here focus on access control, this is
not intended to be the sole focus. By structuring the model
described in this document with clear extension points, and by
leveraging YANG-based models, we provide the opportunity for new
policies to be introduced as required.
The YANG modules specified here are extensions of The YANG modules specified here are extensions of
[I-D.ietf-netmod-acl-model]. The extensions to this model allow for [I-D.ietf-netmod-acl-model]. The extensions to this model allow for
a manufacturer to express classes of systems that a manufacturer a manufacturer to express classes of systems that a manufacturer
would find necessary for the proper function of the device. Two would find necessary for the proper function of the device. Two
modules are specified. The first module specifies a means for domain modules are specified. The first module specifies a means for domain
names to be used in ACLs so that devices that have their controllers names to be used in ACLs so that devices that have their controllers
in the cloud may be appropriately authorized with domain names, where in the cloud may be appropriately authorized with domain names, where
the mapping of those names to addresses may rapidly change. the mapping of those names to addresses may rapidly change.
The other module abstracts away IP addresses into certain classes The other module abstracts away IP addresses into certain classes
skipping to change at page 10, line 4 skipping to change at page 10, line 10
A MUD file consists of JSON based on a YANG model. For purposes of A MUD file consists of JSON based on a YANG model. For purposes of
MUD, the elements that can be modified are access lists as augmented MUD, the elements that can be modified are access lists as augmented
by this model. The MUD file is limited to the serialization of a by this model. The MUD file is limited to the serialization of a
small number of YANG schema, including the models specified in the small number of YANG schema, including the models specified in the
following documents: following documents:
o [I-D.ietf-netmod-acl-model] o [I-D.ietf-netmod-acl-model]
o [RFC6991] o [RFC6991]
Publishers of MUD files MUST NOT include other elements except as Publishers of MUD files MUST NOT include other elements except as
described in Section 3.6, and MUST only contain information relevant described in Section 3.6, and MUST only contain information relevant
to the device being described. Devices parsing MUD files MUST cease to the device being described. Devices parsing MUD files MUST cease
processing if they find other elements. processing if they find other elements.
This module is structured into three parts. The first container ======= This module is structured into four parts:
holds information that is relevant to retrieval and validity of the
MUD file itself. The second container augments the access list to
indicate direction the ACL is to be applied. The final container
augments the matching container of the ACL model to add several
elements that are relevant to the MUD URL, or other otherwise
abstracted for use within a local environment.
Simplified graphical representation of the data models are used in o The first container, metainfo, holds information that is relevant
to retrieval and validity of the MUD file itself.
o The second container, device, describes the policies to be applied
to traffic to and from the device. The only policy currently
defined is a list of access control lists, but the from-device-
policy and to-device-policy containers serve as extension points
for subsequent augmentation.
o The third container augments the matching container of the ACL
model to add several elements that are relevant to the MUD URL, or
other otherwise abstracted for use within a local environment.
o The fourth container augments the tcp-acl container of the ACL
model to add the ability to match on the direction of initiation
of a TCP connection.
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
defined in [I-D.ietf-netmod-rfc6087bis]. defined in [I-D.ietf-netmod-rfc6087bis].
module: ietf-mud
+--rw metainfo +--rw metainfo
+--rw last-update? yang:date-and-time | +--rw last-update? yang:date-and-time
+--rw cache-validity? uint8 | +--rw cache-validity? uint8
+--rw masa-server? inet:uri | +--rw masa-server? inet:uri
+--rw is-supported? boolean | +--rw is-supported? boolean
+--rw systeminfo? inet:uri | +--rw systeminfo? inet:uri
+--rw extensions* string | +--rw extensions* string
augment /acl:access-lists/acl:acl: +--rw device
+--rw packet-direction? direction +--rw from-device-policy
augment /acl:access-lists/acl:acl/acl:access-list-entries/ | +--rw access-lists
acl:ace/acl:matches: | +--rw access-list* [acl-name acl-type]
+--rw manufacturer? inet:host | +--rw acl-name -> /acl:access-lists/acl/acl-name
+--rw same-manufacturer? empty | +--rw acl-type identityref
+--rw model? string +--rw to-device-policy
+--rw local-networks? empty +--rw access-lists
+--rw controller? inet:uri +--rw access-list* [acl-name acl-type]
+--rw my-controller? empty +--rw acl-name -> /acl:access-lists/acl/acl-name
+--rw acl-type identityref
augment /acl:access-lists/acl:acl/acl:access-list-entries \
/acl:ace/acl:matches:
+--rw mud-acl {mud-acl}?
+--rw manufacturer? inet:host
+--rw same-manufacturer? empty
+--rw model? string
+--rw local-networks? empty
+--rw controller? inet:uri
+--rw my-controller? empty
augment /acl:access-lists/acl:acl/acl:access-list-entries \
/acl:ace/acl:matches/acl:tcp-acl:
+--rw direction-initiated? direction +--rw direction-initiated? direction
3. Element Definitions 3. Element Definitions
The following elements are defined. The following elements are defined.
3.1. last-update 3.1. last-update
This is a date-and-time value of when the MUD file was generated. This is a date-and-time value of when the MUD file was generated.
This is akin to a version number. Its form is taken from [RFC6991] This is akin to a version number. Its form is taken from [RFC6991]
skipping to change at page 12, line 4 skipping to change at page 12, line 43
3.7. packet-direction 3.7. packet-direction
[I-D.ietf-netmod-acl-model] describes access-lists but does not [I-D.ietf-netmod-acl-model] describes access-lists but does not
attempt to indicate where they are applied as that is handled attempt to indicate where they are applied as that is handled
elsewhere in a configuration. However, in this case, a MUD file must elsewhere in a configuration. However, in this case, a MUD file must
be explicit in describing the communication pattern of a device, and be explicit in describing the communication pattern of a device, and
that includes indicating what is to be permitted or denied in either that includes indicating what is to be permitted or denied in either
direction of communication. This element takes a single value of direction of communication. This element takes a single value of
either "to-device" or "from-device", based on a typedef "direction". either "to-device" or "from-device", based on a typedef "direction".
This is applied specifically for TCP, and may be implemented either
via stateful or stateless approaches (e.g,. TCP flags)
3.8. manufacturer 3.8. manufacturer
This element consists of a hostname that would be matched against the This element consists of a hostname that would be matched against the
authority component of another device's MUD URL. authority component of another device's MUD URL.
3.9. same-manufacturer 3.9. same-manufacturer
This is an equivalent for when the manufacturer element is used to This is an equivalent for when the manufacturer element is used to
indicate the authority that is found in another device's MUD URL indicate the authority that is found in another device's MUD URL
skipping to change at page 12, line 49 skipping to change at page 13, line 44
one thing, it requires some understanding by the administrator as to one thing, it requires some understanding by the administrator as to
when it is appropriate. Classes that are standardized may make it when it is appropriate. Classes that are standardized may make it
possible to code in certain intelligence. Nonstandard classes may possible to code in certain intelligence. Nonstandard classes may
require substantially more care. Pre-registration in such classes by require substantially more care. Pre-registration in such classes by
controllers with the MUD server is encouraged. The mechanism to do controllers with the MUD server is encouraged. The mechanism to do
that is beyond the scope of this work. that is beyond the scope of this work.
3.13. my-controller 3.13. my-controller
This null-valued element establishes a class of controllers that are This null-valued element establishes a class of controllers that are
intended to control the device associated with the MUD file being intended to control the device associated with a given MUD-URL.
referenced.
3.14. direction-initiated 3.14. direction-initiated
When applied this matches packets when the flow was initiated in the When applied this matches packets when the flow was initiated in the
corresponding direction. [RFC6092] specifies IPv6 guidance best corresponding direction. [RFC6092] specifies IPv6 guidance best
practices. While that document is scoped specifically to IPv6, its practices. While that document is scoped specifically to IPv6, its
contents are applicable for IPv4 as well. When this flag is set, and contents are applicable for IPv4 as well. When this flag is set, and
the system has no reason to believe a flow has been initiated it MUST the system has no reason to believe a flow has been initiated it MUST
drop the packet. This match SHOULD be applied with specific drop the packet. This match SHOULD be applied with specific
transport parameters, such as protocol. transport parameters, such as protocol.
skipping to change at page 14, line 13 skipping to change at page 15, line 7
Specifically if it has been updated in the field, this is the place Specifically if it has been updated in the field, this is the place
where evidence of that update would appear. The field should be where evidence of that update would appear. The field should be
changed when the intended communication patterns of a device change. changed when the intended communication patterns of a device change.
While from a controller standpoint, only comparison and matching While from a controller standpoint, only comparison and matching
operations are safe, it is envisioned that updates will require some operations are safe, it is envisioned that updates will require some
administrative review. Processing of this URL occurs as specified in administrative review. Processing of this URL occurs as specified in
[RFC2818] and [RFC3986]. [RFC2818] and [RFC3986].
6. The MUD YANG Model 6. The MUD YANG Model
<CODE BEGINS>file "ietf-mud@2017-04-18.yang" <CODE BEGINS>file "ietf-mud@2017-07-03.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";
} }
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. This specific module IETF description of an access list. This specific module
focuses on additional filters that include local, model, focuses on additional filters that include local, model,
and same-manufacturer. and same-manufacturer.
Copyright (c) 2016,2017 IETF Trust and the persons Copyright (c) 2016,2017 IETF Trust and the persons
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 "2017-04-18" { revision "2017-07-03" {
description "Base version of MUD extensions to ACL model"; description
reference "RFC XXXX: Manufacturer Usage Description "More work on ACL usage.";
Specification"; reference "RFC XXXX: Manufacturer Usage Description
Specification";
}
revision "2017-06-29" {
description
"Take packet directionality out of ACL. " +
"Introduce device container.";
reference "RFC XXXX: Manufacturer Usage Description
Specification";
}
revision "2017-04-18" {
description "Base version of MUD extensions to ACL model";
reference "RFC XXXX: Manufacturer Usage Description
Specification";
}
typedef direction {
type enumeration {
enum to-device {
description "packets or flows destined to the target
device";
}
enum from-device {
description "packets or flows destined from
the target device";
}
}
description "Which way are we talking about?";
}
identity mud-acl {
base "acl:acl-base";
description
"ACL that contains MUD-specific access control list entries.";
}
feature mud-acl {
description
"MUD ACL augmentations supported.";
}
container metainfo {
description "Information about when support end(ed), and
when to refresh";
leaf last-update {
type yang:date-and-time;
description "This is intended to be when
the MUD file was generated.";
}
leaf cache-validity {
type uint8 {
range "1..168";
}
description "The information retrieved from the MUD server is
valid for these many hours, after which it should
be refreshed.";
}
leaf masa-server {
type inet:uri;
description "The URI of the MASA server that network
elements should forward requests to for this device.";
}
leaf is-supported {
type boolean;
description "The element is currently supported
by the manufacturer.";
}
leaf systeminfo {
type inet:uri;
description "A reference to a description of this device";
}
leaf-list extensions {
type string;
description "A list of extension names that are used in this MUD
file. Each name is registered with the IANA and
described in an RFC.";
} }
}
typedef direction { grouping ACCESS_LISTS {
type enumeration { description "A grouping for access lists in the context of device
enum to-device { policy.";
description "packets or flows destined to the target container access-lists {
device"; description "The access lists that should be applied to traffic
to or from the device.";
list access-list {
key "acl-name acl-type";
description "Each entry on this list refers to an ACL that
should be present in the overall access list
data model. Each ACL is identified by name and
type.";
leaf acl-name {
type leafref {
path "/acl:access-lists/acl:acl/acl:acl-name";
} }
enum from-device { description "The name of the ACL for this entry.";
description "packets or flows destined from }
the target device"; leaf acl-type {
} type identityref {
base acl:acl-base;
} }
description "Which way are we talking about?"; description "The type of the ACL for this entry.";
} }
}
}
}
container metainfo { container device {
description "A container allowing us to associate data with the
device type being described in the instance document";
description "Information about when support end(ed), and container from-device-policy {
when to refresh"; description "The policies that should be enforced on traffic
coming from the device. These policies are not
necessarily intended to be enforced at a single
point, but may be rendered by the controller to any
relevant enorcement points in the network or
elsewhere.";
uses ACCESS_LISTS;
}
leaf last-update { container to-device-policy {
type yang:date-and-time; description "The policies that should be enforced on traffic
description "This is intended to be when going to the device. These policies are not
the MUD file was generated."; necessarily intended to be enforced at a single
} point, but may be rendered by the controller to any
relevant enorcement points in the network or
elsewhere.";
uses ACCESS_LISTS;
leaf cache-validity { }
type uint8 {
range "1..168";
}
description "The information retrieved from the MUD server is
valid for these many hours, after which it should
be refreshed.";
}
leaf masa-server { }
type inet:uri;
description "The URI of the MASA server that network
elements should forward requests to for this device.";
}
leaf is-supported { augment "/acl:access-lists/acl:acl/" +
type boolean; "acl:access-list-entries/acl:ace/" +
description "The element is currently supported "acl:matches" {
by the manufacturer."; description "adding abstractions to avoid need of IP addresses";
}
leaf systeminfo {
type inet:uri;
description "A reference to a description of this device";
}
leaf-list extensions { container mud-acl {
type string; if-feature mud-acl;
description "A list of extension names that are used in this MUD must "../../../../acl-type = 'ietf-mud:mud-acl'";
file. Each name is registered with the IANA and
described in an RFC.";
}
}
augment "/acl:access-lists/acl:acl" { description
description "add inbound or outbound. Normally access lists "TODO; improve. MUD-specific matches.";
are applied in an inbound or outbound direction
separately from their definition. This is not
possible with MUD.";
leaf packet-direction
{
type direction;
description "inbound or outbound ACL.";
}
}
augment "/acl:access-lists/acl:acl/" + leaf manufacturer {
"acl:access-list-entries/acl:ace/" + type inet:host;
"acl:matches" { description "authority component of the manufacturer URI";
description "adding abstractions to avoid need of IP addresses"; }
leaf manufacturer { leaf same-manufacturer {
type inet:host; type empty;
description "authority component of the manufacturer URI"; description "expand to ACEs for each device
with the same origin";
}
} leaf model {
type string;
description "specific model (including version) for a
given manufacturer";
}
leaf same-manufacturer { leaf local-networks {
type empty; type empty;
description "expand to ACEs for each device description "this string is used to indicate networks
with the same origin"; considered local in a given environment.";
} }
leaf model { leaf controller {
type string; type inet:uri;
description "specific model (including version) for a description "expands to one or more controllers for a
given manufacturer"; given service that is codified by inet:uri.";
} }
leaf local-networks { leaf my-controller {
type empty; type empty;
description "this string is used to indicate networks description "This element indicates that the network should manage
considered local in a given environment."; a class of devices related to this MUD-URL that are
} intended to control this device.";
}
}
leaf controller { }
type inet:uri;
description "expands to one or more controllers for a
given service that is codified by inet:uri.";
}
leaf my-controller { augment "/acl:access-lists/acl:acl/" +
type empty; "acl:access-list-entries/acl:ace/" +
description "This element indicates that the network should manage "acl:matches/acl:tcp-acl" {
a class of devices related to this MUD-URL that are description "Adding domain names to matching";
intended to control this device."; leaf direction-initiated {
} type direction;
leaf direction-initiated { description "which direction a flow was initiated";
type direction; }
description "which direction a flow was initiated"; }
}
}
} }
<CODE ENDS> <CODE ENDS>
7. The Domain Name Extension to the ACL Model 7. The Domain Name Extension to the ACL Model
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" element. names may be referenced by augmenting the "matches" element.
Different implementations may deploy differing methods to maintain Different implementations may deploy differing methods to maintain
the mapping between IP address and domain name, if indeed any are the mapping between IP address and domain name, if indeed any are
needed. However, the intent is that resources that are referred to needed. However, the intent is that resources that are referred to
using a name should be authorized (or not) within an access list. using a name should be authorized (or not) within an access list.
skipping to change at page 18, line 9 skipping to change at page 20, line 34
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" element. names may be referenced by augmenting the "matches" element.
Different implementations may deploy differing methods to maintain Different implementations may deploy differing methods to maintain
the mapping between IP address and domain name, if indeed any are the mapping between IP address and domain name, if indeed any are
needed. However, the intent is that resources that are referred to needed. However, the intent is that resources that are referred to
using a name should be authorized (or not) within an access list. using a 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:
augment module: ietf-acldns
/acl:access-lists/acl:acl/acl:access-list-entries augment /acl:access-lists/acl:acl/acl:access-list-entries \
/acl:ace/acl:matches/acl:ace-type/acl:ace-ip: /acl:ace/acl:matches/acl:ipv4-acl:
+--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:access-list-entries \
/acl:ace/acl:matches/acl:ipv6-acl:
+--rw src-dnsname? inet:host
+--rw dst-dnsname? inet:host
The choice of this particular point in the access-list model is based The choice of these particular points in the access-list model is
on the assumption that we are in some way referring to IP-related based on the assumption that we are in some way referring to IP-
resources, as that is what the DNS returns. A domain name in our related resources, as that is what the DNS returns. A domain name in
context is defined in [RFC6991]. our context is defined in [RFC6991]. The augmentations are
replicated across IPv4 and IPv6 to allow MUD file autjors the ability
to control the IP version that the device may utilize.
The following elements are defined. The following elements are defined.
7.1. source-dnsname 7.1. source-dnsname
The argument corresponds to a domain name of a source as specified by The argument corresponds to a domain name of a source as specified by
inet:host. Depending on how the model is used, it may or may not be inet:host. Depending on how the model is used, it may or may not be
resolved, as required by the implementation and circumstances. resolved, as required by the implementation and circumstances.
7.2. destination-dnsname 7.2. destination-dnsname
skipping to change at page 19, line 23 skipping to change at page 22, line 5
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 "2017-07-03" {
description "Clone across IP ACL types.";
reference "RFC XXXX: Manufacturer Usage Description
Specification";
}
revision "2016-07-20" { revision "2016-07-20" {
description "Base version of dnsname extension of ACL model"; description "Base version of dnsname extension of ACL model";
reference "RFC XXXX: Manufacturer Usage Description reference "RFC XXXX: Manufacturer Usage Description
Specification"; Specification";
} }
augment "/acl:access-lists/acl:acl/" + grouping DNS_MATCHES {
"acl:access-list-entries/acl:ace/" + description "Domain names for matching.";
"acl:matches/acl:ace-type/acl:ace-ip" {
description "adding domain names to 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:access-lists/acl:acl/" +
"acl:access-list-entries/acl:ace/" +
"acl:matches/acl:ipv4-acl" {
description "Adding domain names to matching";
uses DNS_MATCHES;
}
augment "/acl:access-lists/acl:acl/" +
"acl:access-list-entries/acl:ace/" +
"acl:matches/acl:ipv6-acl" {
description "Adding domain names to matching";
uses DNS_MATCHES;
}
}
<CODE ENDS> <CODE ENDS>
8. MUD File Example 8. MUD File Example
This example contains two access lists that are intended to provide This example contains two access lists that are intended to provide
outbound access to a cloud service on TCP port 443. outbound access to a cloud service on TCP port 443.
TODO: this needs to be revised.
{ {
"ietf-mud:metainfo": { "ietf-mud:metainfo": {
"last-update": "2016-05-18T20:00:50Z", "last-update": "2016-05-18T20:00:50Z",
"cache-validity": 168 "cache-validity": 168
}, },
"ietf-access-control-list:access-lists": { "ietf-access-control-list:access-lists": {
"acl": [ { "acl": [ {
"acl-name": "inbound-stuff", "acl-name": "inbound-stuff",
"acl-type" : "ipv4-acl", "acl-type" : "ipv4-acl",
"ietf-mud:packet-direction" : "to-device", "ietf-mud:packet-direction" : "to-device",
skipping to change at page 32, line 25 skipping to change at page 35, line 25
The following entries should be added to the "urn:ietf:params:mud" The following entries should be added to the "urn:ietf:params:mud"
name space: name space:
"urn:ietf:params:mud:dns" refers to the service specified by "urn:ietf:params:mud:dns" refers to the service specified by
[RFC1123]. "urn:ietf:params:mud:ntp" refers to the service specified [RFC1123]. "urn:ietf:params:mud:ntp" refers to the service specified
by [RFC5905]. by [RFC5905].
17. Acknowledgments 17. Acknowledgments
The authors would like to thank Einar Nilsen-Nygaard, Bernie Volz, The authors would like to thank Einar Nilsen-Nygaard, who
Tom Gindin, Brian Weis, Sandeep Kumar, Thorsten Dahm, John Bashinski, singlehandedly updated the model to match the updated ACL model,
Steve Rich, Jim Bieda, and Dan Wing for their valuable advice and Bernie Volz, Tom Gindin, Brian Weis, Sandeep Kumar, Thorsten Dahm,
reviews. Russ Housley entirely rewrote Section 10 to be a complete John Bashinski, Steve Rich, Jim Bieda, and Dan Wing for their
module. Adrian Farrel provided the basis for privacy considerations valuable advice and reviews. Russ Housley entirely rewrote
text. Kent Watson provided a thorough review of the archictecture Section 10 to be a complete module. Adrian Farrel provided the basis
and the YANG model. The remaining errors in this work are entirely for privacy considerations text. Kent Watson provided a thorough
the responsibility of the author. review of the archictecture and the YANG model. The remaining errors
in this work are entirely the responsibility of the author.
18. References 18. References
18.1. Normative References 18.1. Normative References
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Behringer, M., Bjarnason, Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
S., and K. Watsen, "Bootstrapping Remote Secure Key S., and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-05 (work in progress), March 2017. keyinfra-06 (work in progress), May 2017.
[I-D.ietf-netmod-acl-model] [I-D.ietf-netmod-acl-model]
Bogdanovic, D., Koushik, K., Huang, L., and D. Blair, Bogdanovic, D., Jethanandani, M., Huang, L., Agarwal, S.,
"Network Access Control List (ACL) YANG Data Model", and D. Blair, "Network Access Control List (ACL) YANG Data
draft-ietf-netmod-acl-model-10 (work in progress), March Model", draft-ietf-netmod-acl-model-11 (work in progress),
2017. June 2017.
[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-12 Data Model Documents", draft-ietf-netmod-rfc6087bis-13
(work in progress), March 2017. (work in progress), June 2017.
[IEEE8021AB] [IEEE8021AB]
Institute for Electrical and Electronics Engineers, "IEEE Institute for Electrical and Electronics Engineers, "IEEE
Standard for Local and Metropolitan Area Networks-- Standard for Local and Metropolitan Area Networks--
Station and Media Access Control Connectivity Discovery", Station and Media Access Control Connectivity Discovery",
n.d.. n.d..
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123, Application and Support", STD 3, RFC 1123,
DOI 10.17487/RFC1123, October 1989, DOI 10.17487/RFC1123, October 1989,
skipping to change at page 36, line 19 skipping to change at page 39, line 19
[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,
<http://www.rfc-editor.org/info/rfc7488>. <http://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 -06 to -07:
o Update models to match new ACL model
o extract directionality from the ACL, introducing a new device
container.
Draft -05 to -06: Draft -05 to -06:
o Make clear that this is a component architecture (Polk and Watson) o Make clear that this is a component architecture (Polk and Watson)
o Add order of operations (Watson) o Add order of operations (Watson)
o Add extensions leaf-list (Pritikin) o Add extensions leaf-list (Pritikin)
o Remove previous-mud-file (Watson) o Remove previous-mud-file (Watson)
 End of changes. 60 change blocks. 
249 lines changed or deleted 397 lines changed or added

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