draft-ietf-opsawg-mud-03.txt   draft-ietf-opsawg-mud-04.txt 
Network Working Group E. Lear Network Working Group E. Lear
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track R. Droms Intended status: Standards Track R. Droms
Expires: July 9, 2017 Expires: August 27, 2017
D. Romascanu D. Romascanu
January 05, 2017 February 23, 2017
Manufacturer Usage Description Specification Manufacturer Usage Description Specification
draft-ietf-opsawg-mud-03 draft-ietf-opsawg-mud-04
Abstract Abstract
This memo specifies the necessary components to implement This memo specifies the necessary components to implement
manufacturer usage descriptions (MUD). This includes two YANG manufacturer usage descriptions (MUD). This includes two YANG
modules, IPv4 and IPv6 DHCP options, an LLDP TLV, a URL suffix modules, IPv4 and IPv6 DHCP options, an LLDP TLV, a URL suffix
specification, an X.509 certificate extension and a means to sign and specification, an X.509 certificate extension and a means to sign and
verify the descriptions. verify the 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 July 9, 2017. This Internet-Draft will expire on August 27, 2017.
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 14 skipping to change at page 2, line 14
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. A Simple Example . . . . . . . . . . . . . . . . . . . . 4 1.1. A Simple Example . . . . . . . . . . . . . . . . . . . . 4
1.2. Determining Intended Use . . . . . . . . . . . . . . . . 4 1.2. Determining Intended Use . . . . . . . . . . . . . . . . 4
1.3. Finding A Policy: The MUD URL . . . . . . . . . . . . . . 5 1.3. Finding A Policy: The MUD URL . . . . . . . . . . . . . . 5
1.4. Types of Policies . . . . . . . . . . . . . . . . . . . . 5 1.4. Types of Policies . . . . . . . . . . . . . . . . . . . . 5
1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
1.6. The Manufacturer Usage Description Architecture . . . . . 7 1.6. The Manufacturer Usage Description Architecture . . . . . 7
2. The MUD Model and Semantic Meaning . . . . . . . . . . . . . 8 2. The MUD Model and Semantic Meaning . . . . . . . . . . . . . 8
3. Element Definitions . . . . . . . . . . . . . . . . . . . . . 9 3. Element Definitions . . . . . . . . . . . . . . . . . . . . . 9
3.1. last-update . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. last-update . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. previous-mud-file . . . . . . . . . . . . . . . . . . . . 9 3.2. previous-mud-file . . . . . . . . . . . . . . . . . . . . 10
3.3. cache-validity . . . . . . . . . . . . . . . . . . . . . 9 3.3. cache-validity . . . . . . . . . . . . . . . . . . . . . 10
3.4. masa-server . . . . . . . . . . . . . . . . . . . . . . . 10 3.4. masa-server . . . . . . . . . . . . . . . . . . . . . . . 10
3.5. is-supported . . . . . . . . . . . . . . . . . . . . . . 10 3.5. is-supported . . . . . . . . . . . . . . . . . . . . . . 10
3.6. systeminfo . . . . . . . . . . . . . . . . . . . . . . . 10 3.6. systeminfo . . . . . . . . . . . . . . . . . . . . . . . 10
3.7. packet-direction . . . . . . . . . . . . . . . . . . . . 10 3.7. packet-direction . . . . . . . . . . . . . . . . . . . . 10
3.8. manufacturer . . . . . . . . . . . . . . . . . . . . . . 10 3.8. manufacturer . . . . . . . . . . . . . . . . . . . . . . 11
3.9. same-manufacturer . . . . . . . . . . . . . . . . . . . . 10 3.9. same-manufacturer . . . . . . . . . . . . . . . . . . . . 11
3.10. model . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.10. model . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.11. local-networks . . . . . . . . . . . . . . . . . . . . . 11 3.11. local-networks . . . . . . . . . . . . . . . . . . . . . 11
3.12. controller . . . . . . . . . . . . . . . . . . . . . . . 11 3.12. controller . . . . . . . . . . . . . . . . . . . . . . . 11
3.13. direction-initiated . . . . . . . . . . . . . . . . . . . 11 3.13. my-controller . . . . . . . . . . . . . . . . . . . . . . 11
4. Processing of the MUD file . . . . . . . . . . . . . . . . . 11 3.14. direction-initiated . . . . . . . . . . . . . . . . . . . 12
5. What does a MUD URL look like? . . . . . . . . . . . . . . . 11 4. Processing of the MUD file . . . . . . . . . . . . . . . . . 12
6. The MUD YANG Model . . . . . . . . . . . . . . . . . . . . . 12 5. What does a MUD URL look like? . . . . . . . . . . . . . . . 12
6. The MUD YANG Model . . . . . . . . . . . . . . . . . . . . . 13
7. The Domain Name Extension to the ACL Model . . . . . . . . . 16 7. The Domain Name Extension to the ACL Model . . . . . . . . . 16
7.1. source-dnsname . . . . . . . . . . . . . . . . . . . . . 16 7.1. source-dnsname . . . . . . . . . . . . . . . . . . . . . 17
7.2. destination-dnsname . . . . . . . . . . . . . . . . . . . 16 7.2. destination-dnsname . . . . . . . . . . . . . . . . . . . 17
7.3. The ietf-acldns Model . . . . . . . . . . . . . . . . . . 16 7.3. The ietf-acldns Model . . . . . . . . . . . . . . . . . . 17
8. MUD File Example . . . . . . . . . . . . . . . . . . . . . . 18 8. MUD File Example . . . . . . . . . . . . . . . . . . . . . . 19
9. The MUD URL DHCP Option . . . . . . . . . . . . . . . . . . . 19 9. The MUD URL DHCP Option . . . . . . . . . . . . . . . . . . . 20
9.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 20 9.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 21
9.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 20 9.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 21
9.3. Relay Requirements . . . . . . . . . . . . . . . . . . . 21 9.3. Relay Requirements . . . . . . . . . . . . . . . . . . . 22
10. The Manufacturer Usage Description (MUD) URL X.509 Extension 21 10. The Manufacturer Usage Description (MUD) URL X.509 Extension 22
11. The Manufacturer Usage Description LLDP extension . . . . . . 22 11. The Manufacturer Usage Description LLDP extension . . . . . . 23
12. Creating and Processing of Signed MUD Files . . . . . . . . . 24 12. Creating and Processing of Signed MUD Files . . . . . . . . . 25
12.1. Creating a MUD file signature . . . . . . . . . . . . . 24 12.1. Creating a MUD file signature . . . . . . . . . . . . . 25
12.2. Verifying a MUD file signature . . . . . . . . . . . . . 24 12.2. Verifying a MUD file signature . . . . . . . . . . . . . 25
13. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 25 13. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 26
14. Security Considerations . . . . . . . . . . . . . . . . . . . 25 14. Security Considerations . . . . . . . . . . . . . . . . . . . 26
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
15.1. DHCPv4 and DHCPv6 Options . . . . . . . . . . . . . . . 27 15.1. DHCPv4 and DHCPv6 Options . . . . . . . . . . . . . . . 28
15.2. PKIX Extensions . . . . . . . . . . . . . . . . . . . . 27 15.2. PKIX Extensions . . . . . . . . . . . . . . . . . . . . 28
15.3. Well Known URI Suffix . . . . . . . . . . . . . . . . . 27 15.3. Well Known URI Suffix . . . . . . . . . . . . . . . . . 28
15.4. MIME Media-type Registration for MUD files . . . . . . . 27 15.4. MIME Media-type Registration for MUD files . . . . . . . 28
15.5. LLDP IANA TLV Subtype Registry . . . . . . . . . . . . . 28 15.5. LLDP IANA TLV Subtype Registry . . . . . . . . . . . . . 29
15.6. The MUD Well Known Universal Resource Name (URNs) . . . 29 15.6. The MUD Well Known Universal Resource Name (URNs) . . . 30
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
17.1. Normative References . . . . . . . . . . . . . . . . . . 29 17.1. Normative References . . . . . . . . . . . . . . . . . . 30
17.2. Informative References . . . . . . . . . . . . . . . . . 31 17.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Changes from Earlier Versions . . . . . . . . . . . 33 Appendix A. Changes from Earlier Versions . . . . . . . . . . . 34
Appendix B. Default MUD elements . . . . . . . . . . . . . . . . 33 Appendix B. Default MUD elements . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
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 28 skipping to change at page 6, line 28
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 second module abstracts away IP addresses into certain classes The other module abstracts away IP addresses into certain classes
that are instantiated into actual IP addresses through local that are instantiated into actual IP addresses through local
processing. Through these classes, manufacturers can specify how the processing. Through these classes, manufacturers can specify how the
device is designed to communicate, so that network elements can be device is designed to communicate, so that network elements can be
configured by local systems that have local topological knowledge. configured by local systems that have local topological knowledge.
That is, the deployment populates the classes that the manufacturer That is, the deployment populates the classes that the manufacturer
specifies. specifies. The abstractions are as follows:
Manufacturer: A device made by a particular manufacturer, as
identified by the authority component of its MUD-URL
my-manufacturer: Devices that have the same authority section of
their MUD-URL.
Controller: A device that the local network administrator admits to
the particular class.
my-controller: A class associated with the MUD-URL of a device that
the administrator admits.
The "manufacturer" classes can be easily specified by the
manufacturer, whereas controller classes are initially envisioned to
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
is important for functionality referenced in usage descriptions to be is important for functionality referenced in usage descriptions to be
relatively ubiquitous, and therefore, mature. Therefore, only a a relatively ubiquitous, and therefore, mature. Therefore, only a a
limited subset YANG-based configuration of is permitted in a MUD limited subset YANG-based configuration of is permitted in a MUD
file. file.
1.5. Terminology 1.5. Terminology
MUD: manufacturer usage description. MUD: manufacturer usage description.
skipping to change at page 9, line 21 skipping to change at page 9, line 35
+--rw is-supported? boolean +--rw is-supported? boolean
augment /acl:access-lists/acl:acl: augment /acl:access-lists/acl:acl:
+--rw packet-direction? direction +--rw packet-direction? direction
augment /acl:access-lists/acl:acl augment /acl:access-lists/acl:acl
/acl:access-list-entries/acl:ace/acl:matches: /acl:access-list-entries/acl:ace/acl:matches:
+--rw manufacturer? inet:host +--rw manufacturer? inet:host
+--rw same-manufacturer? empty +--rw same-manufacturer? empty
+--rw model? string +--rw model? string
+--rw local-networks? empty +--rw local-networks? empty
+--rw controller? inet:uri +--rw controller? inet:uri
+--rw my-controller? empty
+--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 the last time the MUD file was This is a date-and-time value of the last time the MUD file was
updated. This is akin to a version number. Its form is taken from updated. This is akin to a version number. Its form is taken from
skipping to change at page 11, line 19 skipping to change at page 11, line 38
route that is received from the router. route that is received from the router.
3.12. controller 3.12. 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
network management station. The element then is expanded to the set network management station. The element then is expanded to the set
of hosts that are so registered. This element may also be a URN. In of hosts that are so registered. This element may also be a URN. In
this case, the URN describes a well known service, such as DNS or this case, the URN describes a well known service, such as DNS or
NTP. NTP.
In addition, some meta information is defined in order to determine Great care should be used when invoking the controller class. For
when a usage description should be refreshed. one thing, it requires some understanding by the administrator as to
when it is appropriate. For standard classes, it may be possible to
code in certain intelligence. Nonstandard classes may require
substantially more care. Pre-registration in such classes by
controllers with the MUD server is encouraged. The mechanism to do
that is beyond the scope of this work.
3.13. direction-initiated 3.13. my-controller
This null-valued element establishes a class of controllers that are
intended to control the device associated with the MUD file being
referenced.
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] provides guidance for IPv6 corresponding direction. [RFC6092] specifies IPv6 guidance best
guidance best practices. While that document is scoped specifically practices. While that document is scoped specifically to IPv6, its
to IPv6, its contents are applicable for IPv4 as well. When this contents are applicable for IPv4 as well. When this flag is set, and
flag is set, and the system has no reason to believe a flow has been the system has no reason to believe a flow has been initiated it MUST
initiated it MUST drop the packet. This match SHOULD be applied with drop the packet. This match SHOULD be applied with specific
specific transport parameters, such as protocol. transport parameters, such as protocol.
4. Processing of the MUD file 4. Processing of the MUD file
To keep things relatively simple in addition to whatever definitions To keep things relatively simple in addition to whatever definitions
exist, we also apply two additional default behaviors: exist, we also apply two additional default behaviors:
o Anything not explicitly permitted is denied. o Anything not explicitly permitted is denied.
o Local DNS and NTP are, by default, permitted to and from the o Local DNS and NTP are, by default, permitted to and from the
device. device.
skipping to change at page 12, line 31 skipping to change at page 13, line 13
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@2016-07-20.yang"; <CODE BEGINS>file "ietf-mud@2016-07-20.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
WG Chair: Warren Kumari WG Chair: Warren Kumari
warren@kumari.net warren@kumari.net
WG Chair: Zhou Tianran WG Chair: Zhou Tianran
zhoutianran@huawei.com zhoutianran@huawei.com
Editor: Eliot Lear Editor: Eliot Lear
lear@cisco.com lear@cisco.com
Editor: Ralph Droms Editor: Ralph Droms
rdroms@cisco.com rdroms@cisco.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 IETF Trust and the persons identified as Copyright (c) 2016 IETF Trust and the persons identified as
the document authors. All rights reserved. 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 "2016-07-20" { revision "2016-07-20" {
description "Base version of MUD extensions to ACL model"; description "Base version of MUD extensions to ACL model";
reference "RFC XXXX: Manufacturer Usage Description reference "RFC XXXX: Manufacturer Usage Description
Specification"; Specification";
} }
typedef direction { typedef direction {
type enumeration { type enumeration {
enum to-device { enum to-device {
description "packets or flows destined to the target description "packets or flows destined to the target
device"; device";
} }
enum from-device { enum from-device {
description "packets or flows destined from description "packets or flows destined from
the target device"; the target device";
} }
} }
description "Which way are we talking about?"; description "Which way are we talking about?";
}
} container metainfo {
container metainfo { description "Information about when support end(ed), and
when to refresh";
description "Information about when support end(ed), and leaf last-update {
when to refresh"; type yang:date-and-time;
description "This is intended to be the time and date that
the MUD file was generated.";
}
leaf last-update { leaf previous-mud-file {
type yang:date-and-time; type inet:uri;
description "This is intended to be the time and date that description "Use to find the previous MUD file location
the MUD file was generated."; for auditing purposes.";
}
leaf previous-mud-file { }
type inet:uri;
description "Use to find the previous MUD file location
for auditing purposes.";
}
leaf cache-validity { leaf cache-validity {
type uint32; type uint32;
description "The information retrieved from the MUD server is description "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."; be refreshed.";
} }
leaf masa-server { leaf masa-server {
type inet:uri; type inet:uri;
description "The URI of the MASA server that network description "The URI of the MASA server that network
elements should forward requests to for this device."; elements should forward requests to for this device.";
} }
leaf is-supported { leaf is-supported {
type boolean; type boolean;
description "The element is currently supported description "The element is currently supported
by the manufacturer."; by the manufacturer.";
} }
leaf systeminfo { leaf systeminfo {
type string; type string;
description "A non-normative name and description of the device description "A non-normative name and description of the device
this file is used for."; this file is used for.";
} }
} }
augment "/acl:access-lists/acl:acl" { augment "/acl:access-lists/acl:acl" {
description "add inbound or outbound. Normally access lists description "add inbound or outbound. Normally access lists
are applied in an inbound or outbound direction are applied in an inbound or outbound direction
separately from their definition. This is not separately from their definition. This is not
possible with MUD."; possible with MUD.";
leaf packet-direction leaf packet-direction
{ {
type direction; type direction;
description "inbound or outbound ACL."; description "inbound or outbound ACL.";
} }
} }
augment "/acl:access-lists/acl:acl/" + augment "/acl:access-lists/acl:acl/" +
"acl:access-list-entries/acl:ace/" + "acl:access-list-entries/acl:ace/" +
"acl:matches" { "acl:matches" {
description "adding abstractions to avoid need of IP addresses"; description "adding abstractions to avoid need of IP addresses";
leaf manufacturer { leaf manufacturer {
type inet:host; type inet:host;
description "authority component of the manufacturer URI"; description "authority component of the manufacturer URI";
}
leaf same-manufacturer { }
type empty;
description "expand to ACEs for each device
with the same origin";
}
leaf model { leaf same-manufacturer {
type string; type empty;
description "specific model (including version) for a description "expand to ACEs for each device
given manufacturer"; with the same origin";
} }
leaf local-networks { leaf model {
type empty; type string;
description "this string is used to indicate networks description "specific model (including version) for a
considered local in a given environment."; given manufacturer";
} }
leaf controller {
type inet:uri; leaf local-networks {
description "expands to one or more controllers for a type empty;
given service that is codified by inet:uri."; description "this string is used to indicate networks
} considered local in a given environment.";
leaf direction-initiated { }
type direction;
description "which direction a flow was initiated"; leaf controller {
} type inet:uri;
} description "expands to one or more controllers for a
} given service that is codified by inet:uri.";
<CODE ENDS> }
leaf my-controller {
type empty;
description "This element indicates that the network should manage
a class of devices related to this MUD-URL that are
intended to control this device.";
}
leaf direction-initiated {
type direction;
description "which direction a flow was initiated";
}
}
}
<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.
 End of changes. 40 change blocks. 
196 lines changed or deleted 235 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/