draft-ietf-opsawg-mud-07.txt   draft-ietf-opsawg-mud-08.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: January 4, 2018 Expires: February 10, 2018
D. Romascanu D. Romascanu
July 03, 2017 August 09, 2017
Manufacturer Usage Description Specification Manufacturer Usage Description Specification
draft-ietf-opsawg-mud-07 draft-ietf-opsawg-mud-08
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 January 4, 2018. This Internet-Draft will expire on February 10, 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 18 skipping to change at page 2, line 18
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 . . . . . . . . . . . . . 10
3. Element Definitions . . . . . . . . . . . . . . . . . . . . . 11 3. Element Definitions . . . . . . . . . . . . . . . . . . . . . 12
3.1. last-update . . . . . . . . . . . . . . . . . . . . . . . 11 3.1. last-update . . . . . . . . . . . . . . . . . . . . . . . 12
3.2. cache-validity . . . . . . . . . . . . . . . . . . . . . 11 3.2. cache-validity . . . . . . . . . . . . . . . . . . . . . 12
3.3. masa-server . . . . . . . . . . . . . . . . . . . . . . . 12 3.3. masa-server . . . . . . . . . . . . . . . . . . . . . . . 12
3.4. is-supported . . . . . . . . . . . . . . . . . . . . . . 12 3.4. is-supported . . . . . . . . . . . . . . . . . . . . . . 12
3.5. systeminfo . . . . . . . . . . . . . . . . . . . . . . . 12 3.5. systeminfo . . . . . . . . . . . . . . . . . . . . . . . 12
3.6. extensions . . . . . . . . . . . . . . . . . . . . . . . 12 3.6. extensions . . . . . . . . . . . . . . . . . . . . . . . 12
3.7. packet-direction . . . . . . . . . . . . . . . . . . . . 12 3.7. packet-direction . . . . . . . . . . . . . . . . . . . . 13
3.8. manufacturer . . . . . . . . . . . . . . . . . . . . . . 12 3.8. manufacturer . . . . . . . . . . . . . . . . . . . . . . 13
3.9. same-manufacturer . . . . . . . . . . . . . . . . . . . . 13 3.9. same-manufacturer . . . . . . . . . . . . . . . . . . . . 13
3.10. model . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.10. model . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.11. local-networks . . . . . . . . . . . . . . . . . . . . . 13 3.11. local-networks . . . . . . . . . . . . . . . . . . . . . 13
3.12. controller . . . . . . . . . . . . . . . . . . . . . . . 13 3.12. controller . . . . . . . . . . . . . . . . . . . . . . . 13
3.13. my-controller . . . . . . . . . . . . . . . . . . . . . . 13 3.13. my-controller . . . . . . . . . . . . . . . . . . . . . . 14
3.14. direction-initiated . . . . . . . . . . . . . . . . . . . 13 3.14. direction-initiated . . . . . . . . . . . . . . . . . . . 14
4. Processing of the MUD file . . . . . . . . . . . . . . . . . 14 4. Processing of the MUD file . . . . . . . . . . . . . . . . . 14
5. What does a MUD URL look like? . . . . . . . . . . . . . . . 14 5. What does a MUD URL look like? . . . . . . . . . . . . . . . 14
6. The MUD YANG Model . . . . . . . . . . . . . . . . . . . . . 15 6. The MUD YANG Model . . . . . . . . . . . . . . . . . . . . . 15
7. The Domain Name Extension to the ACL Model . . . . . . . . . 20 7. The Domain Name Extension to the ACL Model . . . . . . . . . 21
7.1. source-dnsname . . . . . . . . . . . . . . . . . . . . . 21 7.1. source-dnsname . . . . . . . . . . . . . . . . . . . . . 21
7.2. destination-dnsname . . . . . . . . . . . . . . . . . . . 21 7.2. destination-dnsname . . . . . . . . . . . . . . . . . . . 21
7.3. The ietf-acldns Model . . . . . . . . . . . . . . . . . . 21 7.3. The ietf-acldns Model . . . . . . . . . . . . . . . . . . 21
8. MUD File Example . . . . . . . . . . . . . . . . . . . . . . 22 8. MUD File Example . . . . . . . . . . . . . . . . . . . . . . 23
9. The MUD URL DHCP Option . . . . . . . . . . . . . . . . . . . 24 9. The MUD URL DHCP Option . . . . . . . . . . . . . . . . . . . 25
9.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 25 9.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 26
9.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 25 9.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 26
9.3. Relay Requirements . . . . . . . . . . . . . . . . . . . 26 9.3. Relay Requirements . . . . . . . . . . . . . . . . . . . 27
10. The Manufacturer Usage Description (MUD) URL X.509 Extension 26 10. The Manufacturer Usage Description (MUD) URL X.509 Extension 27
11. The Manufacturer Usage Description LLDP extension . . . . . . 27 11. The Manufacturer Usage Description LLDP extension . . . . . . 28
12. Creating and Processing of Signed MUD Files . . . . . . . . . 29 12. Creating and Processing of Signed MUD Files . . . . . . . . . 30
12.1. Creating a MUD file signature . . . . . . . . . . . . . 29 12.1. Creating a MUD file signature . . . . . . . . . . . . . 30
12.2. Verifying a MUD file signature . . . . . . . . . . . . . 29 12.2. Verifying a MUD file signature . . . . . . . . . . . . . 30
13. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 30 13. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 31
14. Deployment Considerations . . . . . . . . . . . . . . . . . . 30 14. Deployment Considerations . . . . . . . . . . . . . . . . . . 31
15. Security Considerations . . . . . . . . . . . . . . . . . . . 31 15. Security Considerations . . . . . . . . . . . . . . . . . . . 32
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
16.1. YANG Module Registrations . . . . . . . . . . . . . . . 32 16.1. YANG Module Registrations . . . . . . . . . . . . . . . 33
16.2. DHCPv4 and DHCPv6 Options . . . . . . . . . . . . . . . 33 16.2. DHCPv4 and DHCPv6 Options . . . . . . . . . . . . . . . 34
16.3. PKIX Extensions . . . . . . . . . . . . . . . . . . . . 33 16.3. PKIX Extensions . . . . . . . . . . . . . . . . . . . . 34
16.4. Well Known URI Suffix . . . . . . . . . . . . . . . . . 33 16.4. Well Known URI Suffix . . . . . . . . . . . . . . . . . 34
16.5. MIME Media-type Registration for MUD files . . . . . . . 33 16.5. MIME Media-type Registration for MUD files . . . . . . . 34
16.6. LLDP IANA TLV Subtype Registry . . . . . . . . . . . . . 34 16.6. LLDP IANA TLV Subtype Registry . . . . . . . . . . . . . 35
16.7. The MUD Well Known Universal Resource Name (URNs) . . . 35 16.7. The MUD Well Known Universal Resource Name (URNs) . . . 36
17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
18.1. Normative References . . . . . . . . . . . . . . . . . . 35 18.1. Normative References . . . . . . . . . . . . . . . . . . 36
18.2. Informative References . . . . . . . . . . . . . . . . . 38 18.2. Informative References . . . . . . . . . . . . . . . . . 39
Appendix A. Changes from Earlier Versions . . . . . . . . . . . 39 Appendix A. Changes from Earlier Versions . . . . . . . . . . . 40
Appendix B. Default MUD elements . . . . . . . . . . . . . . . . 40 Appendix B. Default MUD elements . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
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 4, line 33 skipping to change at page 4, line 33
description; - The description itself, including how it is description; - The description itself, including how it is
interpreted, and; - A means to retrieve the description. interpreted, and; - A means to retrieve the description.
In this specification we specify each of these building blocks and In this specification we specify each of these building blocks and
how they are intended to be used together. However, they may also be how they are intended to be used together. However, they may also be
used separately, independent of this specification by enterprise used separately, independent of this specification by enterprise
networks for their own purposes. networks for their own purposes.
1.1. What MUD doesn't do 1.1. What MUD doesn't do
General computing systems will benefit very little from MUD, as their MUD is not intended to address network authorization of general
manufacturers cannot envision a specific communication pattern to computing, as their manufacturers cannot envision a specific
describe. In addition, even those devices that have a single or communication pattern to describe. In addition, even those devices
small number of uses might have very broad communication patterns. that have a single or small number of uses might have very broad
MUD is not for them either. communication patterns. MUD on its own is not for them either.
No matter how good a MUD-enabled network is, it will never replace No matter how good a MUD-enabled network is, it will never replace
the need for manufacturers to patch vulnerabilities. It may, the need for manufacturers to patch vulnerabilities. It may,
however, provide network administrators with some additional however, provide network administrators with some additional
protection when those vulnerabilities exist. protection when those vulnerabilities exist.
1.2. A Simple Example 1.2. A Simple Example
A light bulb is intended to light a room. It may be remotely A light bulb is intended to light a room. It may be remotely
controlled through the network; and it may make use of a rendezvous controlled through the network; and it may make use of a rendezvous
skipping to change at page 5, line 31 skipping to change at page 5, line 31
general purpose solution, however, we assume that a device has so few general purpose solution, however, we assume that a device has so few
capabilities that it will implement the least necessary capabilities capabilities that it will implement the least necessary capabilities
to function properly. This is a basic economic constraint. Unless to function properly. This is a basic economic constraint. Unless
the network would refuse access to such a device, its developers the network would refuse access to such a device, its developers
would have no reason to implement such an approach. To date, such an would have no reason to implement such an approach. To date, such an
assertion has held true. assertion has held true.
1.4. Finding A Policy: The MUD URL 1.4. Finding A Policy: The MUD URL
Our work begins, therefore, with the device emitting a Universal Our work begins, therefore, with the device emitting a Universal
Resource Locator (URL) [RFC3986]. This URL may serves both to Resource Locator (URL) [RFC3986]. This URL serves both to classify
classify the device type and to provide a means to locate a policy the device type and to provide a means to locate a policy file.
file.
In this memo three means are defined to emit the MUD URL. One is a In this memo three means are defined to emit the MUD URL. One is a
DHCP option[RFC2131],[RFC3315] that the DHCP client uses to inform DHCP option[RFC2131],[RFC3315] that the DHCP client uses to inform
the DHCP server. The DHCP server may take further actions, such as the DHCP server. The DHCP server may take further actions, such as
retrieve the URL or otherwise pass it along to network management retrieve the URL or otherwise pass it along to network management
system or controller. The other method defined is an X.509 system or controller. The other method defined is an X.509
constraint. The IEEE has developed [IEEE8021AR] that provides a constraint. The IEEE has developed [IEEE8021AR] that provides a
certificate-based approach to communicate device characteristics, certificate-based approach to communicate device characteristics,
which itself relies on [RFC5280]. The MUD URL extension is non- which itself relies on [RFC5280]. The MUD URL extension is non-
critical, as required by IEEE 802.1AR. Various means may be used to critical, as required by IEEE 802.1AR. Various means may be used to
skipping to change at page 9, line 18 skipping to change at page 9, line 18
switch is removed. Similarly, from time to time the description may switch is removed. Similarly, from time to time the description may
be refreshed, based on new capabilities or communication patterns or be refreshed, based on new capabilities or communication patterns or
vulnerabilities. vulnerabilities.
The web site is typically run by or on behalf of the manufacturer. The web site is typically run by or on behalf of the manufacturer.
Its domain name is that of the authority found in the MUD URL. For Its domain name is that of the authority found in the MUD URL. For
legacy cases where Things cannot emit a URL, if the switch is able to legacy cases where Things cannot emit a URL, if the switch is able to
determine the appropriate URI, it may proxy it, the trivial cases determine the appropriate URI, it may proxy it, the trivial cases
being a map between some registered device or port and a URL. being a map between some registered device or port and a URL.
The role of the MUD controller in this environment is to do the
following:
o receive MUD URLs,
o retrieve MUD files,
o translate abstractions in the MUD files to specific device
configuration,
o maintain and update any required mappings of the abstractions, and
o update network elements with appropriate configuration.
A MUD controller may be a component of a AAA or network management
system. Communication within those systems and from those systems to
network elements is beyond the scope of this memo.
1.8. Order of operations 1.8. Order of operations
As mentioned above, MUD contains architectural building blocks, and As mentioned above, MUD contains architectural building blocks, and
so order of operation may vary. However, here is one clear intended so order of operation may vary. However, here is one clear intended
example: example:
1. Device emits URL. 1. Device emits URL.
2. That URL is forwarded to a MUD controller by the nearest switch 2. That URL is forwarded to a MUD controller by the nearest switch
(how this happens depends on the way in which the MUD URL is (how this happens depends on the way in which the MUD URL is
skipping to change at page 10, line 11 skipping to change at page 10, line 29
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]
The ACL model makes use of features for different forms of ACLs. For
purposes of MUD, any feature not related to addresses MAY be
included. Any feature related to addresses MUST NOT be included.
The reason for these statements is so that the broadest number of
implementations will understand the the MUD file without need for
negotiation. Furthermore, it is important to rely on appropriate
abstractions stated in this memo. It is the job of the MUD
controller to translate those abstractions to appropriate
configuration for each network element.
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 four parts: ======= This module is structured into four parts:
o The first container, metainfo, holds information that is relevant o The first container, metainfo, holds information that is relevant
to retrieval and validity of the MUD file itself. to retrieval and validity of the MUD file itself.
skipping to change at page 12, line 49 skipping to change at page 13, line 20
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 This is applied specifically for TCP, and may be implemented either
via stateful or stateless approaches (e.g,. TCP flags) 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. In its simplest
form "manufacturer" and "same-manufacturer" may be implemented as
access-lists. In more complex forms, additional network capabilities
may be used.
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
matches that of the authority found in this device's MUD URL. matches that of the authority found in this device's MUD URL.
3.10. model 3.10. model
This string matches the one and only segment following the authority This string matches the entire MUD URL, thus covering the model that
component of the MUD URL. It refers to a model that is unique within is unique within the context of the authority. It may also include
the context of the authority. It may also include product version product version information. Thus how this field is constructed is
information. Thus how this field is constructed is entirely a local entirely a local matter for the manufacturer.
matter for the manufacturer.
3.11. local-networks 3.11. local-networks
This null-valued element expands to include local networks. Its This null-valued element expands to include local networks. Its
default expansion is that packets must not traverse toward a default default expansion is that packets must not traverse toward a default
route that is received from the router. However, administrators may route that is received from the router. However, administrators may
expand the expression as is appropriate in their deployments. expand the expression as is appropriate in their deployments.
3.12. controller 3.12. controller
skipping to change at page 14, line 4 skipping to change at page 14, line 25
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 a given MUD-URL. intended to control the device associated with a given MUD-URL.
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 element may be implemented in its simplest
transport parameters, such as protocol. form by looking at naked SYN bits, but may also be implemented
through more stateful mechanisms.
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 15, line 7 skipping to change at page 15, line 31
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-07-03.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-07-03" { revision "2017-07-03" {
description description
"More work on ACL usage."; "More work on ACL usage.";
reference "RFC XXXX: Manufacturer Usage Description reference "RFC XXXX: Manufacturer Usage Description
Specification"; Specification";
} }
revision "2017-06-29" { revision "2017-06-29" {
description description
"Take packet directionality out of ACL. " + "Take packet directionality out of ACL. " +
"Introduce device container."; "Introduce device container.";
reference "RFC XXXX: Manufacturer Usage Description reference "RFC XXXX: Manufacturer Usage Description
Specification"; Specification";
} }
revision "2017-04-18" { revision "2017-04-18" {
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 { }
type enumeration {
enum to-device { typedef direction {
description "packets or flows destined to the target type enumeration {
device"; enum to-device {
} description "packets or flows destined to the target
enum from-device { device";
description "packets or flows destined from
the target device";
} }
} enum from-device {
description "Which way are we talking about?"; description "packets or flows destined from
} the target device";
}
}
description "Which way are we talking about?";
}
identity mud-acl { identity mud-acl {
base "acl:acl-base"; base "acl:acl-base";
description description
"ACL that contains MUD-specific access control list entries."; "ACL that contains MUD-specific access control list entries.";
} }
feature mud-acl { feature mud-acl {
description description
"MUD ACL augmentations supported."; "MUD ACL augmentations supported.";
}
} 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 when
the MUD file was generated.";
}
leaf last-update { leaf cache-validity {
type yang:date-and-time; type uint8 {
description "This is intended to be when range "1..168";
the MUD file was generated."; }
} description "The information retrieved from the MUD server is
valid for these many hours, after which it should
be refreshed.";
}
leaf cache-validity { leaf masa-server {
type uint8 { type inet:uri;
range "1..168"; description "The URI of the MASA server that network
elements should forward requests to for this device.";
} }
description "The information retrieved from the MUD server is
valid for these many hours, after which it should
be refreshed.";
}
leaf masa-server { leaf is-supported {
type inet:uri; type boolean;
description "The URI of the MASA server that network description "The element is currently supported
elements should forward requests to for this device."; by the manufacturer.";
} }
leaf systeminfo {
type inet:uri;
description "A reference to a description of this device";
}
leaf is-supported { leaf-list extensions {
type boolean; type string;
description "The element is currently supported description "A list of extension names that are used in this MUD
by the manufacturer."; file. Each name is registered with the IANA and
} described in an RFC.";
leaf systeminfo { }
type inet:uri;
description "A reference to a description of this device";
} }
leaf-list extensions { grouping access_lists {
type string; description "A grouping for access lists in the context of device
description "A list of extension names that are used in this MUD policy.";
file. Each name is registered with the IANA and container access-lists {
described in an RFC."; description "The access lists that should be applied to traffic
} to or from the device.";
} list access-list {
key "acl-name acl-type";
grouping ACCESS_LISTS { description "Each entry on this list refers to an ACL that
description "A grouping for access lists in the context of device should be present in the overall access list
policy."; data model. Each ACL is identified by name and
container access-lists { type.";
description "The access lists that should be applied to traffic leaf acl-name {
to or from the device."; type leafref {
list access-list { path "/acl:access-lists/acl:acl/acl:acl-name";
key "acl-name acl-type"; }
description "Each entry on this list refers to an ACL that description "The name of the ACL for this entry.";
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";
} }
description "The name of the ACL for this entry."; leaf acl-type {
} type identityref {
leaf acl-type { base acl:acl-base;
type identityref { }
base acl:acl-base; description "The type of the ACL for this entry.";
} }
description "The type of the ACL for this entry.";
} }
} }
} }
}
container device { container device {
description "A container allowing us to associate data with the description "A container allowing us to associate data with the
device type being described in the instance document"; device type being described in the instance document";
container from-device-policy { container from-device-policy {
description "The policies that should be enforced on traffic description "The policies that should be enforced on traffic
coming from the device. These policies are not coming from the device. These policies are not
necessarily intended to be enforced at a single necessarily intended to be enforced at a single
point, but may be rendered by the controller to any point, but may be rendered by the controller to any
relevant enorcement points in the network or relevant enorcement points in the network or
elsewhere."; elsewhere.";
uses ACCESS_LISTS; uses access_lists;
} }
container to-device-policy { container to-device-policy {
description "The policies that should be enforced on traffic description "The policies that should be enforced on traffic
going to the device. These policies are not going to the device. These policies are not
necessarily intended to be enforced at a single necessarily intended to be enforced at a single
point, but may be rendered by the controller to any point, but may be rendered by the controller to any
relevant enorcement points in the network or relevant enorcement points in the network or
elsewhere."; elsewhere.";
uses ACCESS_LISTS; uses access_lists;
}
} }
} augment "/acl:access-lists/acl:acl/" +
"acl:access-list-entries/acl:ace/" +
"acl:matches" {
description "adding abstractions to avoid need of IP addresses";
augment "/acl:access-lists/acl:acl/" + container mud-acl {
"acl:access-list-entries/acl:ace/" + if-feature mud-acl;
"acl:matches" { must "../../../../acl:acl-type = 'ietf-mud:mud-acl'";
description "adding abstractions to avoid need of IP addresses";
container mud-acl { description
if-feature mud-acl; "TODO; improve. MUD-specific matches.";
must "../../../../acl-type = 'ietf-mud:mud-acl'";
description leaf manufacturer {
"TODO; improve. MUD-specific matches."; type inet:host;
description "authority component of the manufacturer URI";
}
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 same-manufacturer { leaf model {
type empty; type string;
description "expand to ACEs for each device description "specific model (including version) for a
with the same origin"; given manufacturer";
} }
leaf model { leaf local-networks {
type string; type empty;
description "specific model (including version) for a description "this string is used to indicate networks
given manufacturer"; considered local in a given environment.";
} }
leaf local-networks { leaf controller {
type empty; type inet:uri;
description "this string is used to indicate networks description "expands to one or more controllers for a
considered local in a given environment."; given service that is codified by inet:uri.";
} }
leaf controller { leaf my-controller {
type inet:uri; type empty;
description "expands to one or more controllers for a description "The network should manage
given service that is codified by inet:uri."; a class of devices related to this MUD-URL that are
intended to control this device.";
}
} }
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.";
}
} }
} augment "/acl:access-lists/acl:acl/" +
"acl:access-list-entries/acl:ace/" +
augment "/acl:access-lists/acl:acl/" + "acl:matches/acl:tcp-acl" {
"acl:access-list-entries/acl:ace/" + description "Adding domain names to matching";
"acl:matches/acl:tcp-acl" { leaf direction-initiated {
description "Adding domain names to matching"; 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 22, line 51 skipping to change at page 23, line 33
uses DNS_MATCHES; 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": {
{ "lastUpdate": "2017-08-06T18:55:07+02:00",
"ietf-mud:metainfo": { "systeminfo": "https://example.com/productinfo/LightingSystem3000",
"last-update": "2016-05-18T20:00:50Z", "cacheValidity": 168
"cache-validity": 168 },
}, "ietf-mud:device": {
"ietf-access-control-list:access-lists": { "from-device-policy": {
"acl": [ { "access-lists": {
"acl-name": "inbound-stuff", "access-list": [
"acl-type" : "ipv4-acl", {
"ietf-mud:packet-direction" : "to-device", "acl-name": "mud-66805-v6out",
"access-list-entries": { "acl-type": "ietf-access-control-list:ipv6-acl"
"ace": [ }
{ ]
"rule-name": "access-cloud", }
"matches": { },
"ietf-acldns:src-dnsname": "to-device-policy": {
"lighting-system.example.com", "access-lists": {
"protocol" : 6, "access-list": [
"source-port-range" : { {
"lower-port" : 443, "acl-name": "mud-66805-v6in",
"upper-port" : 443 "acl-type": "ietf-access-control-list:ipv6-acl"
} }
}, ]
"actions" : { }
"permit" : [null] }
} },
} "ietf-access-control-list:access-lists": {
] "acl": [
{
"acl-name": "mud-66805-v6in",
"acl-type": "ipv6-acl",
"access-list-entries": {
"ace": [
{
"rule-name": "cl0-in",
"matches": {
"ipv6-acl": {
"ietf-acldns:src-dnsname": "lighting-system.example.com"
},
"source-port-range": {
"lower-port": 443,
"upper-port": 443
},
"tcp-acl": {
"ietf-mud:direction-initiated": "from-device"
}
},
"actions": {
"permit": [
null
]
} }
}, }
]
}
},
{
"acl-name": "mud-66805-v6out",
"acl-type": "ipv6-acl",
"access-list-entries": {
"ace": [
{ {
"acl-name": "outbound-stuff", "rule-name": "cl0-out",
"acl-type" : "ipv4-acl", "matches": {
"ietf-mud:packet-direction" : "from-device", "ipv6-acl": {
"access-list-entries": { "ietf-acldns:dst-dnsname": "lighting-system.example.com"
"ace": [ },
{ "destination-port-range": {
"rule-name": "access-cloud", "lower-port": 443,
"matches": { "upper-port": 443
"ietf-acldns:dst-dnsname": },
"lighting-system.example.com", "tcp-acl": {
"protocol" : 6, "ietf-mud:direction-initiated": "from-device"
"destination-port-range" : { }
"lower-port" : 443, },
"upper-port" : 443 "actions": {
} "permit": [
}, null
"actions" : { ]
"permit" : [null]
}
}
]
} }
} }
] ]
} }
} }
]
}
}
In this example, two policies are declared, one from the device and
the other to the device. Each policy names an access list that
applies to the device, and one that applies from. Within each access
list, access is permitted to packets flowing to or from the device
that can be mapped to the domain name of lighting-system.example.com.
For each access list, the enforcement point should expect that the
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 | MUD URL
+------+-----+------------------------------ +------+-----+------------------------------
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
skipping to change at page 30, line 26 skipping to change at page 31, line 26
entertained when this version is bumped. Transition approaches entertained when this version is bumped. Transition approaches
between versions would be a matter for discussion in future between versions would be a matter for discussion in future
versions. versions.
2. At a finer grain, only extensions that would not incur additional 2. At a finer grain, only extensions that would not incur additional
risk to the device are permitted. Specifically, augmenting of risk to the device are permitted. Specifically, augmenting of
the metainfo container is permitted with the understanding that the metainfo container is permitted with the understanding that
such additions may be ignored. In addition, augmentation of the such additions may be ignored. In addition, augmentation of the
ACL model is permitted so long as it remains safe for a given ACE ACL model is permitted so long as it remains safe for a given ACE
to be ignored by the MUD Controller or the network elements it to be ignored by the MUD Controller or the network elements it
configures. Most specifically, is is not permitted to include as configures. Most specifically, one MUST NOT augment behavior of
an augmentation that modifies "deny" behavior without bumping the the acl "deny" action. Furthermore, implementations that are not
version. Furthermore, implementations that are not able to parse able to parse a component of the ACE array MUST ignore the entire
a component of the ACE array MUST ignore the entire array entry array entry (e.g., not the entire array) and MAY ignore the
(e.g., not the entire array) and MAY ignore the entire MUD file. entire MUD file or otherwise prompt the administrator.
14. Deployment Considerations 14. Deployment Considerations
Because MUD consists of a number of architectural building blocks, it Because MUD consists of a number of architectural building blocks, it
is possible to assemble different deployment scenarios. One key is possible to assemble different deployment scenarios. One key
aspect is where to place policy enforcement. In order to protect the aspect is where to place policy enforcement. In order to protect the
device from other devices within a local deployment, policy can be device from other devices within a local deployment, policy can be
enforced on the nearest switch or access point. In order to limit enforced on the nearest switch or access point. In order to limit
unwanted traffic within a network, it may also be advisable to unwanted traffic within a network, it may also be advisable to
enforce policy as close to the Internet as possible. In some enforce policy as close to the Internet as possible. In some
skipping to change at page 35, line 43 skipping to change at page 36, line 43
in this work are entirely the responsibility of the author. 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-06 (work in progress), May 2017. keyinfra-07 (work in progress), July 2017.
[I-D.ietf-netmod-acl-model] [I-D.ietf-netmod-acl-model]
Bogdanovic, D., Jethanandani, M., Huang, L., Agarwal, S., Bogdanovic, D., Jethanandani, M., Huang, L., Agarwal, S.,
and D. Blair, "Network Access Control List (ACL) YANG Data and D. Blair, "Network Access Control List (ACL) YANG Data
Model", draft-ietf-netmod-acl-model-11 (work in progress), Model", draft-ietf-netmod-acl-model-11 (work in progress),
June 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-13 Data Model Documents", draft-ietf-netmod-rfc6087bis-13
skipping to change at page 39, line 21 skipping to change at page 40, line 21
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: Draft -06 to -07:
o Examples updated.
o Additional clarification for direction-initiated.
o Additional implementation guidance given.
Draft -06 to -07:
o Update models to match new ACL model o Update models to match new ACL model
o extract directionality from the ACL, introducing a new device o extract directionality from the ACL, introducing a new device
container. 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)
skipping to change at page 40, line 36 skipping to change at page 41, line 44
appended to whatever other ACEs. To block DNS or NTP one repeats the appended to whatever other ACEs. To block DNS or NTP one repeats the
matching statement but replace "permit" with deny. Because ACEs are matching statement but replace "permit" with deny. Because ACEs are
processed in the order they are received, the defaults would not be processed in the order they are received, the defaults would not be
reached. A MUD controller might further decide to optimize to simply reached. A MUD controller might further decide to optimize to simply
not include the defaults when they are overriden. not include the defaults when they are overriden.
A complete MUD entry is included below. A complete MUD entry is included below.
{ {
"ietf-mud:metainfo": { "ietf-mud:metainfo": {
"last-update": "2016-09-27T15:10:24+02:00", "lastUpdate": "2017-08-06T19:12:24+02:00",
"cache-validity": 168 "systeminfo": "https://www.ietf.org/mudcontrollerdefaults",
"cacheValidity": 168
}, },
"acl:access-lists": { "ietf-mud:device": {
"access-list": [ "from-device-policy": {
"access-lists": {
"access-list": [
{
"acl-name": "mud-39988-v4out",
"acl-type": "ietf-access-control-list:ipv4-acl"
},
{
"acl-name": "mud-39988-v6out",
"acl-type": "ietf-access-control-list:ipv6-acl"
}
]
}
},
"to-device-policy": {
"access-lists": {
"access-list": [
{
"acl-name": "mud-39988-v4in",
"acl-type": "ietf-access-control-list:ipv4-acl"
},
{
"acl-name": "mud-39988-v6in",
"acl-type": "ietf-access-control-list:ipv6-acl"
}
]
}
}
},
"ietf-access-control-list:access-lists": {
"acl": [
{ {
"acl-name": "mud-53134-v4in", "acl-name": "mud-39988-v4in",
"acl-type": "ipv4-acl", "acl-type": "ipv4-acl",
"ietf-mud:packet-direction": "to-device",
"access-list-entries": { "access-list-entries": {
"ace": [ "ace": [
{ {
"rule-name": "entout0-in", "rule-name": "ent0-in",
"matches": { "matches": {
"ietf-mud:controller": "urn:ietf:params:mud:dns", "ietf-mud:mud-acl"{
"protocol": 17, "controller": "urn:ietf:params:mud:dns"
},
"source-port-range": { "source-port-range": {
"lower-port": 53, "lower-port": 53,
"upper-port": 53 "upper-port": 53
} }
}, },
"actions": { "actions": {
"permit": [ "permit": [
null null
] ]
} }
}, },
{ {
"rule-name": "entout1-in", "rule-name": "ent1-in",
"matches": { "matches": {
"ietf-mud:controller": "urn:ietf:params:mud:dns", "ietf-mud:mud-acl"{
"protocol": 6, "controller": "urn:ietf:params:mud:dns"
},
"source-port-range": { "source-port-range": {
"lower-port": 53, "lower-port": 53,
"upper-port": 53 "upper-port": 53
},
"tcp-acl": {
"ietf-mud:direction-initiated": "from-device"
} }
}, },
"actions": { "actions": {
"permit": [ "permit": [
null null
] ]
} }
}, },
{ {
"rule-name": "entout2-in", "rule-name": "ent2-in",
"matches": { "matches": {
"ietf-mud:controller": "urn:ietf:params:mud:ntp", "ietf-mud:mud-acl"{
"protocol": 17, "controller": "urn:ietf:params:mud:ntp"
},
"source-port-range": { "source-port-range": {
"lower-port": 123, "lower-port": 123,
"upper-port": 123 "upper-port": 123
} }
}, },
"actions": { "actions": {
"permit": [ "permit": [
null null
] ]
} }
} }
] ]
} }
}, },
{ {
"acl-name": "mud-53134-v4out", "acl-name": "mud-39988-v4out",
"acl-type": "ipv4-acl", "acl-type": "ipv4-acl",
"ietf-mud:packet-direction": "from-device",
"access-list-entries": { "access-list-entries": {
"ace": [ "ace": [
{ {
"rule-name": "entout0-in", "rule-name": "ent0-out",
"matches": { "matches": {
"ietf-mud:controller": "urn:ietf:params:mud:dns", "ietf-mud:mud-acl"{
"protocol": 17, "controller": "urn:ietf:params:mud:dns"
"source-port-range": { },
"destination-port-range": {
"lower-port": 53, "lower-port": 53,
"upper-port": 53 "upper-port": 53
} }
}, },
"actions": { "actions": {
"permit": [ "permit": [
null null
] ]
} }
}, },
{ {
"rule-name": "entout1-in", "rule-name": "ent1-out",
"matches": { "matches": {
"ietf-mud:controller": "urn:ietf:params:mud:dns", "ietf-mud:mud-acl"{
"protocol": 6, "controller": "urn:ietf:params:mud:dns"
"source-port-range": { },
"destination-port-range": {
"lower-port": 53, "lower-port": 53,
"upper-port": 53 "upper-port": 53
},
"tcp-acl": {
"ietf-mud:direction-initiated": "from-device"
} }
}, },
"actions": { "actions": {
"permit": [ "permit": [
null null
] ]
} }
}, },
{ {
"rule-name": "entout2-in", "rule-name": "ent2-out",
"matches": { "matches": {
"ietf-mud:controller": "urn:ietf:params:mud:ntp", "ietf-mud:mud-acl"{
"protocol": 17, "controller": "urn:ietf:params:mud:ntp"
"source-port-range": { },
"destination-port-range": {
"lower-port": 123, "lower-port": 123,
"upper-port": 123 "upper-port": 123
} }
}, },
"actions": { "actions": {
"permit": [ "permit": [
null null
] ]
} }
} }
] ]
} }
}, },
{ {
"acl-name": "mud-53134-v6in", "acl-name": "mud-39988-v6in",
"acl-type": "ipv6-acl", "acl-type": "ipv6-acl",
"ietf-mud:packet-direction": "to-device",
"access-list-entries": { "access-list-entries": {
"ace": [ "ace": [
{ {
"rule-name": "entout0-in", "rule-name": "ent0-in",
"matches": { "matches": {
"ietf-mud:controller": "urn:ietf:params:mud:dns", "ietf-mud:mud-acl"{
"protocol": 17, "controller": "urn:ietf:params:mud:dns"
},
"source-port-range": { "source-port-range": {
"lower-port": 53, "lower-port": 53,
"upper-port": 53 "upper-port": 53
} }
}, },
"actions": { "actions": {
"permit": [ "permit": [
null null
] ]
} }
}, },
{ {
"rule-name": "entout1-in", "rule-name": "ent1-in",
"matches": { "matches": {
"ietf-mud:controller": "urn:params:mud:dns", "ietf-mud:mud-acl"{
"protocol": 6, "controller": "urn:ietf:params:mud:dns"
},
"source-port-range": { "source-port-range": {
"lower-port": 53, "lower-port": 53,
"upper-port": 53 "upper-port": 53
},
"tcp-acl": {
"ietf-mud:direction-initiated": "from-device"
} }
}, },
"actions": { "actions": {
"permit": [ "permit": [
null null
] ]
} }
}, },
{ {
"rule-name": "entout2-in", "rule-name": "ent2-in",
"matches": { "matches": {
"ietf-mud:controller": "urn:ietf:params:mud:ntp", "ietf-mud:mud-acl"{
"protocol": 17, "controller": "urn:ietf:params:mud:ntp"
},
"source-port-range": { "source-port-range": {
"lower-port": 123, "lower-port": 123,
"upper-port": 123 "upper-port": 123
} }
}, },
"actions": { "actions": {
"permit": [ "permit": [
null null
] ]
} }
} }
] ]
} }
}, },
{ {
"acl-name": "mud-53134-v6out", "acl-name": "mud-39988-v6out",
"acl-type": "ipv6-acl", "acl-type": "ipv6-acl",
"ietf-mud:packet-direction": "from-device",
"access-list-entries": { "access-list-entries": {
"ace": [ "ace": [
{ {
"rule-name": "entout0-in", "rule-name": "ent0-out",
"matches": { "matches": {
"ietf-mud:controller": "urn:ietf:params:mud:dns", "ietf-mud:mud-acl"{
"protocol": 17, "controller": "urn:ietf:params:mud:dns"
"source-port-range": { },
"destination-port-range": {
"lower-port": 53, "lower-port": 53,
"upper-port": 53 "upper-port": 53
} }
}, },
"actions": { "actions": {
"permit": [ "permit": [
null null
] ]
} }
}, },
{ {
"rule-name": "entout1-in", "rule-name": "ent1-out",
"matches": { "matches": {
"ietf-mud:controller": "urn:ietf:params:mud:dns", "ietf-mud:mud-acl"{
"protocol": 6, "controller": "urn:ietf:params:mud:dns"
"source-port-range": { },
"destination-port-range": {
"lower-port": 53, "lower-port": 53,
"upper-port": 53 "upper-port": 53
},
"tcp-acl": {
"ietf-mud:direction-initiated": "from-device"
} }
}, },
"actions": { "actions": {
"permit": [ "permit": [
null null
] ]
} }
}, },
{ {
"rule-name": "entout2-in", "rule-name": "ent2-out",
"matches": { "matches": {
"ietf-mud:controller": "urn:ietf:params:mud:ntp", "ietf-mud:mud-acl"{
"protocol": 17, "controller": "urn:ietf:params:mud:ntp"
"source-port-range": { },
"destination-port-range": {
"lower-port": 123, "lower-port": 123,
"upper-port": 123 "upper-port": 123
} }
}, },
"actions": { "actions": {
"permit": [ "permit": [
null null
] ]
} }
} }
 End of changes. 107 change blocks. 
381 lines changed or deleted 510 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/