draft-ietf-opsawg-mud-13.txt   draft-ietf-opsawg-mud-14.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: April 27, 2018 Expires: July 28, 2018
D. Romascanu D. Romascanu
October 24, 2017 January 24, 2018
Manufacturer Usage Description Specification Manufacturer Usage Description Specification
draft-ietf-opsawg-mud-13 draft-ietf-opsawg-mud-14
Abstract Abstract
This memo specifies a component-based architecture for manufacturer This memo specifies a component-based architecture for manufacturer
usage descriptions (MUD). The goal of MUD is to provide a means for usage descriptions (MUD). The goal of MUD is to provide a means for
Things to signal to the network what sort of access and network Things to signal to the network what sort of access and network
functionality they require to properly function. The initial focus functionality they require to properly function. The initial focus
is on access control. Later work can delve into other aspects. is on access control. Later work can delve into other aspects.
This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, an This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, an
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and a means to sign and verify the descriptions. and a means to sign and verify the descriptions.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 27, 2018. This Internet-Draft will expire on July 28, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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. What MUD doesn't do . . . . . . . . . . . . . . . . . . . 4 1.1. What MUD Doesn't Do . . . . . . . . . . . . . . . . . . . 4
1.2. A Simple Example . . . . . . . . . . . . . . . . . . . . 5 1.2. A Simple Example . . . . . . . . . . . . . . . . . . . . 5
1.3. Determining Intended Use . . . . . . . . . . . . . . . . 5 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Finding A Policy: The MUD URL . . . . . . . . . . . . . . 5 1.4. Determining Intended Use . . . . . . . . . . . . . . . . 6
1.5. Types of Policies . . . . . . . . . . . . . . . . . . . . 6 1.5. Finding A Policy: The MUD URL . . . . . . . . . . . . . . 6
1.6. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 1.6. Processing of the MUD URL . . . . . . . . . . . . . . . . 7
1.7. The Manufacturer Usage Description Architecture . . . . . 9 1.7. Types of Policies . . . . . . . . . . . . . . . . . . . . 7
1.8. Order of operations . . . . . . . . . . . . . . . . . . . 10 1.8. The Manufacturer Usage Description Architecture . . . . . 9
1.9. Order of operations . . . . . . . . . . . . . . . . . . . 11
2. The MUD Model and Semantic Meaning . . . . . . . . . . . . . 11 2. The MUD Model and Semantic Meaning . . . . . . . . . . . . . 11
2.1. The IETF-MUD YANG Module . . . . . . . . . . . . . . . . 11 2.1. The IETF-MUD YANG Module . . . . . . . . . . . . . . . . 12
3. Data Node Definitions . . . . . . . . . . . . . . . . . . . . 13 3. Data Node Definitions . . . . . . . . . . . . . . . . . . . . 14
3.1. to-device-policy and from-device-policy containers . . . 13 3.1. mud-version . . . . . . . . . . . . . . . . . . . . . . . 14
3.2. last-update . . . . . . . . . . . . . . . . . . . . . . . 14 3.2. to-device-policy and from-device-policy containers . . . 14
3.3. cache-validity . . . . . . . . . . . . . . . . . . . . . 14 3.3. last-update . . . . . . . . . . . . . . . . . . . . . . . 14
3.4. is-supported . . . . . . . . . . . . . . . . . . . . . . 14 3.4. cache-validity . . . . . . . . . . . . . . . . . . . . . 14
3.5. systeminfo . . . . . . . . . . . . . . . . . . . . . . . 14 3.5. is-supported . . . . . . . . . . . . . . . . . . . . . . 14
3.6. extensions . . . . . . . . . . . . . . . . . . . . . . . 14 3.6. systeminfo . . . . . . . . . . . . . . . . . . . . . . . 15
3.7. manufacturer . . . . . . . . . . . . . . . . . . . . . . 15 3.7. extensions . . . . . . . . . . . . . . . . . . . . . . . 15
3.8. same-manufacturer . . . . . . . . . . . . . . . . . . . . 15 3.8. manufacturer . . . . . . . . . . . . . . . . . . . . . . 15
3.9. model . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.9. same-manufacturer . . . . . . . . . . . . . . . . . . . . 15
3.10. local-networks . . . . . . . . . . . . . . . . . . . . . 15 3.10. model . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.11. controller . . . . . . . . . . . . . . . . . . . . . . . 15 3.11. local-networks . . . . . . . . . . . . . . . . . . . . . 16
3.12. my-controller . . . . . . . . . . . . . . . . . . . . . . 16 3.12. controller . . . . . . . . . . . . . . . . . . . . . . . 16
3.13. direction-initiated . . . . . . . . . . . . . . . . . . . 16 3.13. my-controller . . . . . . . . . . . . . . . . . . . . . . 16
4. Processing of the MUD file . . . . . . . . . . . . . . . . . 16 3.14. direction-initiated . . . . . . . . . . . . . . . . . . . 16
4. Processing of the MUD file . . . . . . . . . . . . . . . . . 17
5. What does a MUD URL look like? . . . . . . . . . . . . . . . 17 5. What does a MUD URL look like? . . . . . . . . . . . . . . . 17
6. The MUD YANG Model . . . . . . . . . . . . . . . . . . . . . 17 6. The MUD YANG Model . . . . . . . . . . . . . . . . . . . . . 18
7. The Domain Name Extension to the ACL Model . . . . . . . . . 23 7. The Domain Name Extension to the ACL Model . . . . . . . . . 23
7.1. source-dnsname . . . . . . . . . . . . . . . . . . . . . 24 7.1. src-dnsname . . . . . . . . . . . . . . . . . . . . . . . 24
7.2. destination-dnsname . . . . . . . . . . . . . . . . . . . 24 7.2. destination-dnsname . . . . . . . . . . . . . . . . . . . 24
7.3. The ietf-acldns Model . . . . . . . . . . . . . . . . . . 24 7.3. The ietf-acldns Model . . . . . . . . . . . . . . . . . . 24
8. MUD File Example . . . . . . . . . . . . . . . . . . . . . . 25 8. MUD File Example . . . . . . . . . . . . . . . . . . . . . . 26
9. The MUD URL DHCP Option . . . . . . . . . . . . . . . . . . . 28 9. The MUD URL DHCP Option . . . . . . . . . . . . . . . . . . . 28
9.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 28 9.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 29
9.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 29 9.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 29
9.3. Relay Requirements . . . . . . . . . . . . . . . . . . . 29 9.3. Relay Requirements . . . . . . . . . . . . . . . . . . . 30
10. The Manufacturer Usage Description (MUD) URL X.509 Extension 29
10. The Manufacturer Usage Description (MUD) URL X.509 Extension 30
11. The Manufacturer Usage Description LLDP extension . . . . . . 31 11. The Manufacturer Usage Description LLDP extension . . . . . . 31
12. Creating and Processing of Signed MUD Files . . . . . . . . . 33 12. Creating and Processing of Signed MUD Files . . . . . . . . . 33
12.1. Creating a MUD file signature . . . . . . . . . . . . . 33 12.1. Creating a MUD file signature . . . . . . . . . . . . . 33
12.2. Verifying a MUD file signature . . . . . . . . . . . . . 33 12.2. Verifying a MUD file signature . . . . . . . . . . . . . 33
13. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 34 13. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 34
14. Deployment Considerations . . . . . . . . . . . . . . . . . . 34 14. Deployment Considerations . . . . . . . . . . . . . . . . . . 34
15. Security Considerations . . . . . . . . . . . . . . . . . . . 35 15. Security Considerations . . . . . . . . . . . . . . . . . . . 35
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
16.1. YANG Module Registrations . . . . . . . . . . . . . . . 37 16.1. YANG Module Registrations . . . . . . . . . . . . . . . 37
16.2. DHCPv4 and DHCPv6 Options . . . . . . . . . . . . . . . 38 16.2. DHCPv4 and DHCPv6 Options . . . . . . . . . . . . . . . 38
16.3. PKIX Extensions . . . . . . . . . . . . . . . . . . . . 38 16.3. PKIX Extensions . . . . . . . . . . . . . . . . . . . . 38
16.4. Well Known URI Suffix . . . . . . . . . . . . . . . . . 38 16.4. Well Known URI Suffix . . . . . . . . . . . . . . . . . 38
16.5. MIME Media-type Registration for MUD files . . . . . . . 38 16.5. MIME Media-type Registration for MUD files . . . . . . . 38
16.6. LLDP IANA TLV Subtype Registry . . . . . . . . . . . . . 39 16.6. LLDP IANA TLV Subtype Registry . . . . . . . . . . . . . 39
16.7. The MUD Well Known Universal Resource Name (URNs) . . . 40 16.7. The MUD Well Known Universal Resource Name (URNs) . . . 40
16.8. Extensions Registry . . . . . . . . . . . . . . . . . . 40 16.8. Extensions Registry . . . . . . . . . . . . . . . . . . 40
17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
18.1. Normative References . . . . . . . . . . . . . . . . . . 41 18.1. Normative References . . . . . . . . . . . . . . . . . . 41
18.2. Informative References . . . . . . . . . . . . . . . . . 43 18.2. Informative References . . . . . . . . . . . . . . . . . 43
Appendix A. Changes from Earlier Versions . . . . . . . . . . . 44 Appendix A. Changes from Earlier Versions . . . . . . . . . . . 45
Appendix B. Default MUD nodes . . . . . . . . . . . . . . . . . 47 Appendix B. Default MUD nodes . . . . . . . . . . . . . . . . . 48
Appendix C. A Sample Extension: DETNET-indicator . . . . . . . . 51 Appendix C. A Sample Extension: DETNET-indicator . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55
1. Introduction 1. Introduction
The Internet has largely been constructed on general purpose The Internet has largely been constructed for general purpose
computers, those devices that may be used for a purpose that is computers, those devices that may be used for a purpose that is
specified by those who buy the device. [RFC1984] presumed that an specified by those who own the device. [RFC1984] presumed that an
end device would be most capable of protecting itself. This made end device would be most capable of protecting itself. This made
sense when the typical device was a workstation or a mainframe, and sense when the typical device was a workstation or a mainframe, and
it continues to make sense for general purpose computing devices it continues to make sense for general purpose computing devices
today, including laptops, smart phones, and tablets. today, including laptops, smart phones, and tablets.
[RFC7452] discusses design patterns for, and poses questions about, [RFC7452] discusses design patterns for, and poses questions about,
smart objects. Let us then posit a group of objects that are smart objects. Let us then posit a group of objects that are
specifically NOT general purpose computers. These devices have a specifically not general purpose computers. These devices, which
specific purpose. By definition, therefore, all other uses are NOT this memo refers to as Things, have a specific purpose. By
intended. The combination of these two statements can be restated as definition, therefore, all other uses are not intended. The
a manufacturer usage description (MUD) that can be applied at various combination of these two statements can be restated as a manufacturer
points within a network. Although this memo may seem to stress usage description (MUD) that can be applied at various points within
access requirements, usage intent also consists of quality of service a network.
needs a device may have.
We use the notion of "manufacturer" loosely in this context to refer We use the notion of "manufacturer" loosely in this context to refer
to the entity or organization that will state how a device is to the entity or organization that will state how a device is
intended to be used. In the context of a lightbulb, this might intended to be used. For example, in the context of a lightbulb,
indeed be the lightbulb manufacturer. In the context of a smarter this might indeed be the lightbulb manufacturer. In the context of a
device that has a built in Linux stack, it might be an integrator of smarter device that has a built in Linux stack, it might be an
that device. The key points are that the device itself is expected integrator of that device. The key points are that the device itself
to serve a limited purpose, and that there may exist an organization is assumed to serve a limited purpose, and that there may exist an
in the supply chain of that device that will take responsibility for organization in the supply chain of that device that will take
informing the network about that purpose. responsibility for informing the network about that purpose.
The intent of MUD is to solve for the following problems: The intent of MUD is to provide the following:
o Substantially reduce the threat surface on a device entering a o Substantially reduce the threat surface on a device entering a
network to those communications intended by the manufacturer. network to those communications intended by the manufacturer.
o Provide for a means to scale network policies to the ever- o Provide a means to scale network policies to the ever-increasing
increasing number types of devices in the network. number of types of devices in the network.
o Provide a means to address at least some vulnerabilities in a way o Provide a means to address at least some vulnerabilities in a way
that is faster than it might take to update systems. This will be that is faster than the time it might take to update systems.
particularly true for systems that are no longer supported by This will be particularly true for systems that are no longer
their manufacturer. supported by their manufacturer.
o Keep the cost of implementation of such a system to the bare o Keep the cost of implementation of such a system to the bare
minimum. minimum.
o Provide a means of extensibility for manufacturers to express o Provide a means of extensibility for manufacturers to express
other device capabilities or requirements. other device capabilities or requirements.
MUD consists of three architectural building blocks: MUD consists of three architectural building blocks:
o A classifier that a device emits that can be used to locate a o A URL that is can be used to locate a description;
description;
o The description itself, including how it is interpreted, and; o The description itself, including how it is interpreted, and;
o A means for local network management systems to retrieve the o A means for local network management systems to retrieve the
description. description.
In this specification we describe each of these building blocks and In this specification we describe 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 local used separately, independent of this specification, by local
deployments for their own purposes. deployments for their own purposes.
1.1. What MUD doesn't do 1.1. What MUD Doesn't Do
MUD is not intended to address network authorization of general MUD is not intended to address network authorization of general
purpose computers, as their manufacturers cannot envision a specific purpose computers, as their manufacturers cannot envision a specific
communication pattern to describe. In addition, even those devices communication pattern to describe. In addition, even those devices
that have a single or small number of uses might have very broad that have a single or small number of uses might have very broad
communication patterns. MUD on its own 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 Although MUD can provide network administrators with some additional
the need for manufacturers to patch vulnerabilities. It may, protection when device vulnerabilities exist, it will never replace
however, provide network administrators with some additional the need for manufacturers to patch vulnerabilities.
protection when those vulnerabilities exist.
Finally, no matter what the manufacturer specifies in a MUD file, Finally, no matter what the manufacturer specifies in a MUD file,
these are not directives, but suggestions. How they are instantiated these are not directives, but suggestions. How they are instantiated
locally will depend on many factors and will be ultimately up to the locally will depend on many factors and will be ultimately up to the
local network administrator, who must decide what is appropriate in a local network administrator, who must decide what is appropriate in a
given circumstances. given circumstances.
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
service of some form that an app on smart phone accesses. What we service of some form that an application on a smart phone. What we
can say about that light bulb, then, is that all other network access can say about that light bulb, then, is that all other network access
is unwanted. It will not contact a news service, nor speak to the is unwanted. It will not contact a news service, nor speak to the
refrigerator, and it has no need of a printer or other devices. It refrigerator, and it has no need of a printer or other devices. It
has no social networking friends. Therefore, an access list applied has no social networking friends. Therefore, an access list applied
to it that states that it will only connect to the single rendezvous to it that states that it will only connect to the single rendezvous
service will not impede the light bulb in performing its function, service will not impede the light bulb in performing its function,
while at the same time allowing the network to provide both it and while at the same time allowing the network to provide both it and
other devices an additional layer of protection. other devices an additional layer of protection.
1.3. Determining Intended Use 1.3. Terminology
MUD: manufacturer usage description.
MUD file: a file containing YANG-based JSON that describes a Thing
and associated suggested specific network behavior.
MUD file server: a web server that hosts a MUD file.
MUD controller: the system that requests and receives the MUD file
from the MUD server. After it has processed a MUD file, it may
direct changes to relevant network elements.
MUD URL: a URL that can be used by the MUD controller to receive the
MUD file.
Thing: the device emitting a MUD URL.
Manufacturer: the entity that configures the Thing to emit the MUD
URL and the one who asserts a recommendation in a MUD file. The
manufacturer might not always be the entity that constructs a
Thing. It could, for instance, be a systems integrator, or even a
component provider.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.4. Determining Intended Use
The notion of intended use is in itself not new. Network The notion of intended use is in itself not new. Network
administrators apply access lists every day to allow for only such administrators apply access lists every day to allow for only such
use. This notion of white listing was well described by Chapman and use. This notion of white listing was well described by Chapman and
Zwicky in [FW95]. Profiling systems that make use of heuristics to Zwicky in [FW95]. Profiling systems that make use of heuristics to
identify types of systems have existed for years as well. identify types of systems have existed for years as well.
A Thing could just as easily tell the network what sort of access it A Thing could just as easily tell the network what sort of access it
requires without going into what sort of system it is. This would, requires without going into what sort of system it is. This would,
in effect, be the converse of [RFC7488]. In seeking a general in effect, be the converse of [RFC7488]. In seeking a general
purpose solution, however, we assume that a device has so few 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 provide the network any information. To would have no reason to provide the network any information. To
date, such an assertion has held true. date, such an assertion has held true.
1.4. Finding A Policy: The MUD URL 1.5. Finding A Policy: The MUD URL
Our work begins with the device emitting a Universal Resource Locator Our work begins with the device emitting a Universal Resource Locator
(URL) [RFC3986]. This URL serves both to classify the device type (URL) [RFC3986]. This URL serves both to classify the device type
and to provide a means to locate a policy file. and to provide a means to locate a policy 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, as follows:
DHCP option[RFC2131],[RFC3315] that the DHCP client uses to inform
the DHCP server. The DHCP server may take further actions, such as o A DHCP option[RFC2131],[RFC3315] that the DHCP client uses to
retrieve the URL or otherwise pass it along to network management inform the DHCP server. The DHCP server may take further actions,
system or controller. The second method defined is an X.509 such as retrieve the URL or otherwise pass it along to network
constraint. The IEEE has developed [IEEE8021AR] that provides a management system or controller.
certificate-based approach to communicate device characteristics,
which itself relies on [RFC5280]. The MUD URL extension is non- o An X.509 constraint. The IEEE has developed [IEEE8021AR] that
critical, as required by IEEE 802.1AR. Various means may be used to provides a certificate-based approach to communicate device
communicate that certificate, including Tunnel Extensible characteristics, which itself relies on [RFC5280]. The MUD URL
Authentication Protocol (TEAP) [RFC7170]. Finally, a Link Layer extension is non-critical, as required by IEEE 802.1AR. Various
Discovery Protocol (LLDP) frame is defined [IEEE8021AB]. means may be used to communicate that certificate, including
Tunnel Extensible Authentication Protocol (TEAP) [RFC7170].
o Finally, a Link Layer Discovery Protocol (LLDP) frame is defined
[IEEE8021AB].
It is possible that there may be other means for a MUD URL to be It is possible that there may be other means for a MUD URL to be
learned by a network. For instance, some devices may already be learned by a network. For instance, some devices may already be
fielded or have very limited ability to communicate a MUD URL, and fielded or have very limited ability to communicate a MUD URL, and
yet can be identified through some means, such as a serial number or yet can be identified through some means, such as a serial number or
a public key. In these cases, manufacturers may be able to map those a public key. In these cases, manufacturers may be able to map those
identifiers to particular MUD URLs (or even the files themselves). identifiers to particular MUD URLs (or even the files themselves).
Similarly, there may be alternative resolution mechanisms available Similarly, there may be alternative resolution mechanisms available
for situations where Internet connectivity is limited or does not for situations where Internet connectivity is limited or does not
exist. Such mechanisms are not described in this memo, but are exist. Such mechanisms are not described in this memo, but are
possible. Implementors should allow for this sort of flexibility of possible. Implementors should allow for this sort of flexibility of
how MUD URLs may be learned. how MUD URLs may be learned.
1.5. Types of Policies 1.6. Processing of the MUD URL
MUD URLs MUST use the HTTPS scheme [RFC7230].
MUD controllers that are able to do so SHOULD retrieve MUD URLs and
signature files as per [RFC7230], using the GET method [RFC7231].
They MUST validate the certificate using the rules in [RFC2618],
Section 3.1.
Requests for MUD URLs SHOULD include an "Accept" header ([RFC7231],
Section 5.3.2) containing "application/mud+json", an "Accept-
Language" header ([RFC7231], Section 5.3.5), and a "User-Agent"
header ([RFC7231], Section 5.5.3).
MUD controllers SHOULD automatically process 3xx response status
codes.
If a MUD controller is not able to fetch a MUD URL, other means MAY
be used to import MUD files and associated signature files. So long
as the signature of the file can be validated, the file can be used.
In such environments, controllers SHOULD warn administrators when
cache-validity expiry is approaching so that they may check for new
files.
1.7. Types of Policies
When the MUD URL is resolved, the MUD controller retrieves a file When the MUD URL is resolved, the MUD controller retrieves a file
that describes what sort of communications a device is designed to that describes what sort of communications a device is designed to
have. The manufacturer may specify either specific hosts for cloud have. The manufacturer may specify either specific hosts for cloud
based services or certain classes for access within an operational based services or certain classes for access within an operational
network. An example of a class might be "devices of a specified network. An example of a class might be "devices of a specified
manufacturer type", where the manufacturer type itself is indicated manufacturer type", where the manufacturer type itself is indicated
simply by the authority component (e.g, the domain name) of the MUD simply by the authority component (e.g, the domain name) of the MUD
URL. Another example might be to allow or disallow local access. URL. Another example might be to allow or disallow local access.
Just like other policies, these may be combined. For example: Just like other policies, these may be combined. For example:
skipping to change at page 8, line 5 skipping to change at page 9, line 13
That is, the deployment populates the classes that the manufacturer That is, the deployment populates the classes that the manufacturer
specifies. The abstractions below map to zero or more hosts, as specifies. The abstractions below map to zero or more hosts, as
follows: follows:
Manufacturer: A device made by a particular manufacturer, as Manufacturer: A device made by a particular manufacturer, as
identified by the authority component of its MUD URL identified by the authority component of its MUD URL
same-manufacturer: Devices that have the same authority component of same-manufacturer: Devices that have the same authority component of
their MUD URL. their MUD URL.
Controller: Devices that the local network administrator admits to controller: Devices that the local network administrator admits to
the particular class. the particular class.
my-controller: Devices associated with the MUD URL of a device that my-controller: Devices associated with the MUD URL of a device that
the administrator admits. the administrator admits.
local: The class of IP addresses that are scoped within some local: The class of IP addresses that are scoped within some
administrative boundary. By default it is suggested that this be administrative boundary. By default it is suggested that this be
the local subnet. the local subnet.
The "manufacturer" classes can be easily specified by the The "manufacturer" classes can be easily specified by the
manufacturer, whereas controller classes are initially envisioned to manufacturer, whereas controller classes are initially envisioned to
be specified by the administrator. be specified by the administrator.
Because manufacturers do not know who will be using their devices, it Because manufacturers do not know who will be using their devices, it
is important for functionality referenced in usage descriptions to be is important for functionality referenced in usage descriptions to be
relatively ubiquitous and mature. For these reasons only a limited relatively ubiquitous and mature. For these reasons only a limited
subset YANG-based configuration of is permitted in a MUD file. subset YANG-based configuration is permitted in a MUD file.
1.6. Terminology
MUD: manufacturer usage description.
MUD file: a file containing YANG-based JSON that describes a Thing
and associated suggested specific network behavior.
MUD file server: a web server that hosts a MUD file.
MUD controller: the system that requests and receives the MUD file
from the MUD server. After it has processed a MUD file, it may
direct changes to relevant network elements.
MUD URL: a URL that can be used by the MUD controller to receive the
MUD file.
Thing: the device emitting a MUD URL.
Manufacturer: the entity that configures the Thing to emit the MUD
URL and the one who asserts a recommendation in a MUD file. The
manufacturer might not always be the entity that constructs a
Thing. It could, for instance, be a systems integrator, or even a
component provider.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.7. The Manufacturer Usage Description Architecture 1.8. The Manufacturer Usage Description Architecture
With these components laid out we now have the basis for an With these components laid out we now have the basis for an
architecture. This leads us to ASCII art. architecture. This leads us to ASCII art.
....................................... .......................................
. ____________ . _____________ . ____________ . _____________
. | | . | | . | | . | |
. | MUD |-->get URL-->| MUD | . | MUD |-->get URL-->| MUD |
. | Controller | .(https) | File Server | . | Controller | .(https) | File Server |
. End system network |____________|<-MUD file<-<|_____________| . End system network |____________|<-MUD file<-<|_____________|
skipping to change at page 9, line 28 skipping to change at page 10, line 23
. _______ _________ . . _______ _________ .
.| | (dhcp et al) | router | . .| | (dhcp et al) | router | .
.| Thing |---->MUD URL-->| or | . .| Thing |---->MUD URL-->| or | .
.|_______| | switch | . .|_______| | switch | .
. |_________| . . |_________| .
....................................... .......................................
Figure 1: MUD Architecture Figure 1: MUD Architecture
In the above diagram, the switch or router collects MUD URLs and In the above diagram, the switch or router collects MUD URLs and
forwards them to the network management system for processing. This forwards them to the MUD controller (a network management system) for
happens in different ways, depending on how the URL is communicated. processing. This happens in different ways, depending on how the URL
For instance, in the case of DHCP, the DHCP server might receive the is communicated. For instance, in the case of DHCP, the DHCP server
URL and then process it. In the case of IEEE 802.1X, the switch might receive the URL and then process it. In the case of IEEE
would carry the URL via a certificate to the authentication server 802.1X, the switch would carry the URL via a certificate to the
via EAP over Radius[RFC3748], which would then process it. One authentication server via EAP over Radius[RFC3748], which would then
method to do this is TEAP, described in [RFC7170]. The certificate process it. One method to do this is TEAP, described in [RFC7170].
extension is described below. The certificate extension is described below.
The information returned by the web site is valid for the duration of The information returned by the MUD file server (a web server) is
the Thing's connection, or as specified in the description. Thus if valid for the duration of the Thing's connection, or as specified in
the Thing is disconnected, any associated configuration in the switch the description. Thus if the Thing is disconnected, any associated
can be removed. Similarly, from time to time the description may be configuration in the switch can be removed. Similarly, from time to
refreshed, based on new capabilities or communication patterns or time the description may be refreshed, based on new capabilities or
vulnerabilities. communication patterns or 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 URL, it may proxy it, the trivial cases determine the appropriate URL, it may proxy it, the trivial cases
being a hardcoded MUD-URL on a switch port, or a mapping from some being a hardcoded MUD-URL on a switch port, or a mapping from some
available identifier such as an L2 address or certificate hash to a available identifier such as an L2 address or certificate hash to a
MUD-URL. MUD-URL.
The role of the MUD controller in this environment is to do the The role of the MUD controller in this environment is to do the
following: following:
o receive MUD URLs, o receive MUD URLs,
o retrieve MUD files, o fetch MUD files,
o translate abstractions in the MUD files to specific network o translate abstractions in the MUD files to specific network
element configuration, element configuration,
o maintain and update any required mappings of the abstractions, and o maintain and update any required mappings of the abstractions, and
o update network elements with appropriate configuration. o update network elements with appropriate configuration.
A MUD controller may be a component of a AAA or network management A MUD controller may be a component of a AAA or network management
system. Communication within those systems and from those systems to system. Communication within those systems and from those systems to
network elements is beyond the scope of this memo. network elements is beyond the scope of this memo.
1.8. Order of operations 1.9. 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. Thing emits URL. 1. Thing 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
emitted). emitted).
skipping to change at page 11, line 29 skipping to change at page 12, line 22
further on. further on.
To provide the widest possible deployment, publishers of MUD files To provide the widest possible deployment, publishers of MUD files
SHOULD make use of the abstractions in this memo and avoid the use of SHOULD make use of the abstractions in this memo and avoid the use of
IP addresses. A MUD controller SHOULD NOT automatically implement IP addresses. A MUD controller SHOULD NOT automatically implement
any MUD file that contains IP addresses, especially those that might any MUD file that contains IP addresses, especially those that might
have local significance. The addressing of one side of an access have local significance. The addressing of one side of an access
list is implicit, based on whether it is applied as to-device-policy list is implicit, based on whether it is applied as to-device-policy
or from-device-policy. or from-device-policy.
With the exceptions of "acl-name", "acl-type", "rule-name", and TCP With the exceptions of "name", "acl-type", "rule-name", and TCP and
and UDP source and destination port information, publishers of MUD UDP source and destination port information, publishers of MUD files
files SHOULD limit the use of ACL model leaf nodes expressed to those SHOULD limit the use of ACL model leaf nodes expressed to those found
found in this specification. Absent any extensions, MUD files are in this specification. Absent any extensions, MUD files are assumed
assumed to implement only the following ACL model features: to implement only the following ACL model features:
o any-acl, mud-acl, icmp-acl, ipv6-acl, tcp-acl, any-acl, udp-acl, o match-on-ipv4, match-on-ipv6, match-on-tcp, match-on-udp, match-
ipv4-acl, and ipv6-acl on-icmp
Furthermore, only"accept" or "drop" actions SHOULD be included. A Furthermore, only "accept" or "drop" actions SHOULD be included. A
MUD controller MAY choose to interpret "reject" as "drop". A MUD MUD controller MAY choose to interpret "reject" as "drop". A MUD
controller SHOULD ignore all other actions. controller SHOULD ignore all other actions.
In fact, MUD controllers MAY ignore any particular component of a In fact, MUD controllers MAY ignore any particular component of a
description or MAY ignore the description in its entirety, and SHOULD description or MAY ignore the description in its entirety, and SHOULD
carefully inspect all MUD descriptions. Publishers of MUD files MUST carefully inspect all MUD descriptions. Publishers of MUD files MUST
NOT include other nodes except as described in Section 3.6. See that NOT include other nodes except as described in Section 3.7. See that
section for more information. section for more information.
2.1. The IETF-MUD YANG Module 2.1. The IETF-MUD YANG Module
This module is structured into three parts: This module is structured into three parts:
o The first container "mud" holds information that is relevant to o The first container "mud" holds information that is relevant to
retrieval and validity of the MUD file itself, as well as policy retrieval and validity of the MUD file itself, as well as policy
intended to and from the Thing. intended to and from the Thing.
skipping to change at page 12, line 28 skipping to change at page 13, line 20
an "access-lists" container. Extensions may add additional root an "access-lists" container. Extensions may add additional root
objects as required. As a reminder, when parsing access-lists, objects as required. As a reminder, when parsing access-lists,
elements within a "match" block are logically ANDed. In general, a elements within a "match" block are logically ANDed. In general, a
single abstraction in a match statement should be used. For single abstraction in a match statement should be used. For
instance, it makes little sense to match both "my-controller" and instance, it makes little sense to match both "my-controller" and
"controller" with an argument, since they are highly unlikely to be "controller" with an argument, since they are highly unlikely to be
the same value. the same value.
A simplified graphical representation of the data models is used in A simplified graphical representation of the data models is used in
this document. The meaning of the symbols in these diagrams is this document. The meaning of the symbols in these diagrams is
explained in [I-D.ietf-netmod-rfc6087bis]. explained in [I-D.ietf-netmod-yang-tree-diagrams].
module: ietf-mud module: ietf-mud
+--rw mud! +--rw mud!
+--rw mud-version uint8
+--rw mud-url inet:uri +--rw mud-url inet:uri
+--rw last-update yang:date-and-time +--rw last-update yang:date-and-time
+--rw cache-validity? uint8 +--rw cache-validity? uint8
+--rw is-supported boolean +--rw is-supported boolean
+--rw systeminfo? inet:uri +--rw systeminfo? inet:uri
+--rw extensions* string +--rw extensions* string
+--rw from-device-policy +--rw from-device-policy
| +--rw access-lists | +--rw access-lists
| +--rw access-list* [acl-name acl-type] | +--rw access-list* [name]
| +--rw acl-name -> /acl:access-lists/acl/acl-name | +--rw name -> /acl:access-lists/acl/name
| +--rw acl-type identityref
+--rw to-device-policy +--rw to-device-policy
+--rw access-lists +--rw access-lists
+--rw access-list* [acl-name acl-type] +--rw access-list* [name]
+--rw acl-name -> /acl:access-lists/acl/acl-name +--rw name -> /acl:access-lists/acl/name
+--rw acl-type identityref augment /acl:access-lists/acl:acl/acl:aces/acl:ace/acl:matches:
augment /acl:access-lists/acl:acl/acl:aces/ +--rw mud
acl:ace/acl:matches:
+--rw mud-acl
+--rw manufacturer? inet:host +--rw manufacturer? inet:host
+--rw same-manufacturer? empty +--rw same-manufacturer? empty
+--rw model? inet:uri +--rw model? inet:uri
+--rw local-networks? empty +--rw local-networks? empty
+--rw controller? inet:uri +--rw controller? inet:uri
+--rw my-controller? empty +--rw my-controller? empty
augment /acl:access-lists/acl:acl/acl:aces/ augment /acl:access-lists/acl:acl/acl:aces/acl:ace/acl:matches
acl:ace/acl:matches/acl:tcp-acl: /acl:l4/acl:tcp:
+--rw direction-initiated? direction +--rw direction-initiated? direction
3. Data Node Definitions 3. Data Node Definitions
Note that in this section, when we use the term "match" we are Note that in this section, when we use the term "match" we are
referring to the ACL model "matches" node, and thus returns positive referring to the ACL model "matches" node.
such that an action should be applied.
The following nodes are defined. The following nodes are defined.
3.1. to-device-policy and from-device-policy containers 3.1. mud-version
[I-D.ietf-netmod-acl-model] describes access-lists but does not This node specifies the integer version of the MUD specification.
attempt to indicate where they are applied as that is handled This memo specifies version 1.
elsewhere in a configuration. However, in this case, a MUD file must
be explicit in describing the communication pattern of a Thing, and
that includes indicating what is to be permitted or denied in either
direction of communication. Hence each of these containers indicate
the appropriate direction of a flow in association with a particular
Thing. They contain references to specific access-lists.
3.2. last-update 3.2. to-device-policy and from-device-policy containers
[I-D.ietf-netmod-acl-model] describes access-lists. In the case of
MUD, a MUD file must be explicit in describing the communication
pattern of a Thing, and that includes indicating what is to be
permitted or denied in either direction of communication. Hence each
of these containers indicates the appropriate direction of a flow in
association with a particular Thing. They contain references to
specific access-lists.
3.3. 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]
which, for those keeping score, in turn was taken from Section 5.6 of which, for those keeping score, in turn was taken from Section 5.6 of
[RFC3339], which was taken from [ISO.8601.1988]. [RFC3339], which was taken from [ISO.8601.1988].
3.3. cache-validity 3.4. cache-validity
This uint8 is the period of time in hours that a network management This uint8 is the period of time in hours that a network management
station MUST wait since its last retrieval before checking for an station MUST wait since its last retrieval before checking for an
update. It is RECOMMENDED that this value be no less than 24 and update. It is RECOMMENDED that this value be no less than 24 and
MUST NOT be more than 168 for any Thing that is supported. This MUST NOT be more than 168 for any Thing that is supported. This
period SHOULD be no shorter than any period determined through HTTP period SHOULD be no shorter than any period determined through HTTP
caching directives (e.g., "cache-control" or "Expires"). N.B., caching directives (e.g., "cache-control" or "Expires"). N.B.,
expiring of this timer does not require the MUD controller to discard expiring of this timer does not require the MUD controller to discard
the MUD file, nor terminate access to a Thing. See Section 15 for the MUD file, nor terminate access to a Thing. See Section 15 for
more information. more information.
3.4. is-supported 3.5. is-supported
This boolean is an indication from the manufacturer to the network This boolean is an indication from the manufacturer to the network
administrator as to whether or not the Thing is supported. In this administrator as to whether or not the Thing is supported. In this
context a Thing is said to NOT be supported if the manufacturer context a Thing is said to not be supported if the manufacturer
intends never to issue an update to the Thing or never update the MUD intends never to issue an update to the Thing or never update the MUD
file. A MUD controller MAY still periodically check for updates. file. A MUD controller MAY still periodically check for updates.
3.5. systeminfo 3.6. systeminfo
This is a URL that points to a description of the Thing to be This is a URL that points to a description of the Thing to be
connected. The intent is for administrators to be able to see a connected. The intent is for administrators to be able to see a
localized name associated with the Thing. The referenced URL SHOULD localized name associated with the Thing. The referenced URL SHOULD
be a localized display string, and MAY be in either HTML or a raw be a localized display string, and MAY be in either HTML or a raw
UTF-8 text file. It SHOULD NOT exceed 60 characters worth of display UTF-8 text file. It SHOULD NOT exceed 60 characters worth of display
space (that is- what the administrator actually sees), but it MAY space (that is- what the administrator actually sees), but it MAY
contain links to other documents (presumably product documentation). contain links to other documents (presumably product documentation).
3.6. extensions 3.7. extensions
This optional leaf-list names MUD extensions that are used in the MUD This optional leaf-list names MUD extensions that are used in the MUD
file. Note that NO MUD extensions may be used in a MUD file prior to file. Note that NO MUD extensions may be used in a MUD file without
the extensions being declared. Implementations MUST ignore any node the extensions being declared. Implementations MUST ignore any node
in this file that they do not understand. in this file that they do not understand.
Note that extensions can either extend the MUD file as described in Note that extensions can either extend the MUD file as described in
the previous paragraph, or they might reference other work. An the previous paragraph, or they might reference other work. An
extension example can be found in Appendix C. extension example can be found in Appendix C.
3.7. manufacturer 3.8. manufacturer
This node consists of a hostname that would be matched against the This node consists of a hostname that would be matched against the
authority component of another Thing's MUD URL. In its simplest form authority component of another Thing's MUD URL. In its simplest form
"manufacturer" and "same-manufacturer" may be implemented as access- "manufacturer" and "same-manufacturer" may be implemented as access-
lists. In more complex forms, additional network capabilities may be lists. In more complex forms, additional network capabilities may be
used. For example, if one saw the line "manufacturer" : used. For example, if one saw the line "manufacturer" :
"flobbidy.example.com", then all Things that registered with a MUD "flobbidy.example.com", then all Things that registered with a MUD
URL that contained flobbity.example.com in its authority section URL that contained flobbity.example.com in its authority section
would match. would match.
3.8. same-manufacturer 3.9. same-manufacturer
This is an equivalent for when the manufacturer element is used to This null-valued node is an equivalent for when the manufacturer
indicate the authority that is found in another Thing's MUD URL element is used to indicate the authority that is found in another
matches that of the authority found in this Thing's MUD URL. For Thing's MUD URL matches that of the authority found in this Thing's
example, if the Thing's MUD URL were https://b1.example.com/.well- MUD URL. For example, if the Thing's MUD URL were
known/mud/v1/ThingV1, then all devices that had MUD URL with an https://b1.example.com/.well-known/mud/ThingV1, then all devices that
authority section of b1.example.com would match. had MUD URL with an authority section of b1.example.com would match.
3.9. model 3.10. model
This string matches the entire MUD URL, thus covering the model that This string matches the entire MUD URL, thus covering the model that
is unique within the context of the authority. It may contain not is unique within the context of the authority. It may contain not
only model information, but versioning information as well, and any only model information, but versioning information as well, and any
other information that the manufacturer wishes to add. The intended other information that the manufacturer wishes to add. The intended
use is for devices of this precise class to match, to permit or deny use is for devices of this precise class to match, to permit or deny
communication between one another. communication between one another.
3.10. local-networks 3.11. local-networks
This null-valued node expands to include local networks. Its default This null-valued node expands to include local networks. Its default
expansion is that packets must not traverse toward a default route expansion is that packets must not traverse toward a default route
that is received from the router. However, administrators may expand that is received from the router. However, administrators may expand
the expression as is appropriate in their deployments. the expression as is appropriate in their deployments.
3.11. 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
mud controller. The node then is expanded to the set of hosts that MUD controller. The node then is expanded to the set of hosts that
are so registered. This node may also be a URN. In this case, the are so registered. This node may also be a URN. In this case, the
URN describes a well known service, such as DNS or NTP. URN describes a well known service, such as DNS or NTP.
Great care should be used when invoking the controller class. For Great care should be used when invoking the controller class. For
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 easily name devices that support standard functions. For possible to easily name devices that support standard functions. For
instance, the MUD controller could have some knowledge of which DNS instance, the MUD controller could have some knowledge of which DNS
servers should be used for any particular group of Things. Non- servers should be used for any particular group of Things. Non-
standard classes will likely require some sort of administrator standard classes will likely require some sort of administrator
skipping to change at page 16, line 23 skipping to change at page 16, line 39
the MUD server is encouraged. The mechanism to do that is beyond the the MUD server is encouraged. The mechanism to do that is beyond the
scope of this work. scope of this work.
Controller URIs MAY take the form of a URL (e.g. "http[s]://"). Controller URIs MAY take the form of a URL (e.g. "http[s]://").
However, MUD controllers MUST NOT resolve and retrieve such files, However, MUD controllers MUST NOT resolve and retrieve such files,
and it is RECOMMENDED that there be no such file at this time, as and it is RECOMMENDED that there be no such file at this time, as
their form and function may be defined at a point in the future. For their form and function may be defined at a point in the future. For
now, URLs should serve simply as class names and be populated by the now, URLs should serve simply as class names and be populated by the
local deployment administrator. local deployment administrator.
3.12. my-controller 3.13. my-controller
This null-valued node signals to the MUD controller to use whatever This null-valued node signals to the MUD controller to use whatever
mapping it has for this MUD URL to a particular group of hosts. This mapping it has for this MUD URL to a particular group of hosts. This
may require prompting the administrator for class members. Future may require prompting the administrator for class members. Future
work should seek to automate membership management. work should seek to automate membership management.
3.13. 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 node may be implemented in its simplest form drop the packet. This node may be implemented in its simplest form
by looking at naked SYN bits, but may also be implemented through by looking at naked SYN bits, but may also be implemented through
more stateful mechanisms. more stateful mechanisms.
skipping to change at page 17, line 16 skipping to change at page 17, line 32
To begin with, MUD takes full advantage of both the https: scheme and To begin with, MUD takes full advantage of both the https: scheme and
the use of .well-known. HTTPS is important in this case because a the use of .well-known. HTTPS is important in this case because a
man in the middle attack could otherwise harm the operation of a man in the middle attack could otherwise harm the operation of a
class of Things. .well-known is used because we wish to add class of Things. .well-known is used because we wish to add
additional structure to the URL, and want to leave open for future additional structure to the URL, and want to leave open for future
versions both the means by which the URL is processed and the format versions both the means by which the URL is processed and the format
of the MUD file retrieved (there have already been some discussions of the MUD file retrieved (there have already been some discussions
along these lines). The URL appears as follows: along these lines). The URL appears as follows:
mud-url = "https://" authority "/.well-known/mud/" mud-rev mud-url = "https://" authority "/.well-known/mud/"
"/" modelinfo ( "?" extras ) "/" modelinfo ( "?" extras )
; authority is from RFC3986 ; authority is from RFC3986
mud-rev = "v1"
modelinfo = segment ; from RFC3986 modelinfo = segment ; from RFC3986
extras = query ; from RFC3986 extras = query ; from RFC3986
mud-rev signifies the version of the manufacturer usage description
file. This memo specifies "v1" of that file. Later versions may
permit additional schemas or modify the format. In order to provide
for the broadest compatibility for the various transmission
mechanisms, the length of the URL for v1 MUST NOT exceed 255 octets.
Taken together with the mud-url, "modelinfo" represents a Thing model Taken together with the mud-url, "modelinfo" represents a Thing model
as the manufacturer wishes to represent it. It could be a brand name as the manufacturer wishes to represent it. It could be a brand name
or something more specific. It also may provide a means to indicate or something more specific. It also may provide a means to indicate
what version the product is. Specifically if it has been updated in what version the product is. Specifically if it has been updated in
the field, this is the place where evidence of that update would the field, this is the place where evidence of that update would
appear. The field should be changed when the intended communication appear. The field should be changed when the intended communication
patterns of a Thing change. While from a controller standpoint, only patterns of a Thing change. While from a controller standpoint, only
comparison and matching operations are safe, it is envisioned that comparison and matching operations are safe, it is envisioned that
updates will require some administrative review. Processing of this updates will require some administrative review.
URL occurs as specified in [RFC2818] and [RFC3986].
"extras" is intended for use by the MUD controller to provide "extras" is intended for use by the MUD controller to provide
additional information such as posture about the Thing to the MUD additional information such as posture about the Thing to the MUD
file server. This field MUST NOT be configured on the Thing itself file server. This field MUST NOT be configured on the Thing itself
by a manufacturer - that is what "modelinfo" is for. It is left as by a manufacturer - that is what "modelinfo" is for. It is left as
future work to define the full semantics of this field. future work to define the full semantics of this field.
6. The MUD YANG Model 6. The MUD YANG Model
<CODE BEGINS>file "ietf-mud@2017-10-07.yang" <CODE BEGINS>file "ietf-mud@2018-01-24.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;
skipping to change at page 18, line 50 skipping to change at page 19, line 11
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-10-07 { revision 2018-01-24 {
description description
"Initial proposed standard."; "Initial proposed standard.";
reference reference
"RFC XXXX: Manufacturer Usage Description "RFC XXXX: Manufacturer Usage Description
Specification"; Specification";
} }
typedef direction { typedef direction {
type enumeration { type enumeration {
enum "to-device" { enum "to-device" {
skipping to change at page 19, line 39 skipping to change at page 19, line 48
description description
"MUD related information, as specified "MUD related information, as specified
by RFC-XXXX [RFC Editor to fill in]."; by RFC-XXXX [RFC Editor to fill in].";
uses mud-grouping; uses mud-grouping;
} }
grouping mud-grouping { grouping mud-grouping {
description description
"Information about when support end(ed), and "Information about when support end(ed), and
when to refresh"; when to refresh";
leaf mud-version {
type uint8;
mandatory true;
description "This is the version of the MUD
specification. This memo specifies version 1.";
}
leaf mud-url { leaf mud-url {
type inet:uri; type inet:uri;
mandatory true; mandatory true;
description description
"This is the MUD URL associated with the entry found "This is the MUD URL associated with the entry found
in a MUD file."; in a MUD file.";
} }
leaf last-update { leaf last-update {
type yang:date-and-time; type yang:date-and-time;
mandatory true; mandatory true;
skipping to change at page 21, line 28 skipping to change at page 21, line 46
grouping access-lists { grouping access-lists {
description description
"A grouping for access lists in the context of device "A grouping for access lists in the context of device
policy."; policy.";
container access-lists { container access-lists {
description description
"The access lists that should be applied to traffic "The access lists that should be applied to traffic
to or from the device."; to or from the device.";
list access-list { list access-list {
key "acl-name acl-type"; key "name";
description description
"Each entry on this list refers to an ACL that "Each entry on this list refers to an ACL that
should be present in the overall access list should be present in the overall access list
data model. Each ACL is identified by name and data model. Each ACL is identified by name and
type."; type.";
leaf acl-name { leaf name {
type leafref { type leafref {
path "/acl:access-lists/acl:acl/acl:acl-name"; path "/acl:access-lists/acl:acl/acl:name";
} }
description description
"The name of the ACL for this entry."; "The name of the ACL for this entry.";
} }
leaf acl-type {
type identityref {
base acl:acl-base;
}
description
"The type of the ACL for this entry. The name is
scoped ONLY to the MUD file, and may not be unique
in any other circumstance.";
}
} }
} }
} }
augment "/acl:access-lists/acl:acl/acl:aces/acl:ace/acl:matches" { augment "/acl:access-lists/acl:acl/acl:aces/acl:ace/acl:matches" {
description description
"adding abstractions to avoid need of IP addresses"; "adding abstractions to avoid need of IP addresses";
container mud-acl { container mud {
description description
"MUD-specific matches."; "MUD-specific matches.";
leaf manufacturer { leaf manufacturer {
type inet:host; type inet:host;
description description
"A domain that is intended to match the authority "A domain that is intended to match the authority
section of the MUD URL. This node is used to specify section of the MUD URL. This node is used to specify
one or more manufacturers a device should one or more manufacturers a device should
be authorized to access."; be authorized to access.";
} }
skipping to change at page 23, line 9 skipping to change at page 23, line 18
leaf my-controller { leaf my-controller {
type empty; type empty;
description description
"This node matches one or more network elements that "This node matches one or more network elements that
have been configured to be the controller for this have been configured to be the controller for this
Thing, based on its MUD URL."; Thing, based on its MUD URL.";
} }
} }
} }
augment "/acl:access-lists/acl:acl/acl:aces/" + augment "/acl:access-lists/acl:acl/acl:aces/" +
"acl:ace/acl:matches/acl:tcp-acl" { "acl:ace/acl:matches/acl:l4/acl:tcp" {
description description
"Adding domain names to matching"; "Adding domain names to matching";
leaf direction-initiated { leaf direction-initiated {
type direction; type direction;
description description
"This node matches based on which direction a "This node matches based on which direction a
connection was initiated. The means by which that connection was initiated. The means by which that
is determined is discussed in this document."; is determined is discussed in this document.";
} }
} }
skipping to change at page 23, line 36 skipping to change at page 24, line 6
This module specifies an extension to IETF-ACL model such that domain This module specifies an extension to IETF-ACL model such that domain
names may be referenced by augmenting the "matches" node. Different names may be referenced by augmenting the "matches" node. Different
implementations may deploy differing methods to maintain the mapping implementations may deploy differing methods to maintain the mapping
between IP address and domain name, if indeed any are needed. between IP address and domain name, if indeed any are needed.
However, the intent is that resources that are referred to using a However, the intent is that resources that are referred to using a
name should be authorized (or not) within an access list. name should be authorized (or not) within an access list.
The structure of the change is as follows: The structure of the change is as follows:
module: ietf-acldns module: ietf-acldns
augment /acl:access-lists/acl:acl/acl:aces/acl:ace/ augment /acl:access-lists/acl:acl/acl:aces/acl:ace/acl:matches
acl:matches/acl:ipv4-acl: /acl:l3/acl:ipv4:
+--rw src-dnsname? inet:host +--rw src-dnsname? inet:host
+--rw dst-dnsname? inet:host +--rw dst-dnsname? inet:host
augment /acl:access-lists/acl:acl/acl:aces/acl:ace/ augment /acl:access-lists/acl:acl/acl:aces/acl:ace/acl:matches
acl:matches/acl:ipv6-acl: /acl:l3/acl:ipv6:
+--rw src-dnsname? inet:host +--rw src-dnsname? inet:host
+--rw dst-dnsname? inet:host +--rw dst-dnsname? inet:host
The choice of these particular points in the access-list model is The choice of these particular points in the access-list model is
based on the assumption that we are in some way referring to IP- based on the assumption that we are in some way referring to IP-
related resources, as that is what the DNS returns. A domain name in related resources, as that is what the DNS returns. A domain name in
our context is defined in [RFC6991]. The augmentations are our context is defined in [RFC6991]. The augmentations are
replicated across IPv4 and IPv6 to allow MUD file authors the ability replicated across IPv4 and IPv6 to allow MUD file authors the ability
to control the IP version that the Thing may utilize. to control the IP version that the Thing may utilize.
The following node are defined. The following node are defined.
7.1. source-dnsname 7.1. src-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. A number of means may be used to resolve hosts. What is inet:host. A number of means may be used to resolve hosts. What is
important is that such resolutions be consistent with ACLs required important is that such resolutions be consistent with ACLs required
by Things to properly operate. by Things to properly operate.
7.2. destination-dnsname 7.2. destination-dnsname
The argument corresponds to a domain name of a destination as The argument corresponds to a domain name of a destination as
specified by inet:host See the previous section relating to specified by inet:host See the previous section relating to
resolution. resolution.
Note when using either of these with a MUD file, because access is
associated with a particular Thing, MUD files MUST not contain either
a src-dnsname in an ACL associated with from-device-policy or a dst-
dnsname associated with to-device-policy.
7.3. The ietf-acldns Model 7.3. The ietf-acldns Model
<CODE BEGINS>file "ietf-acldns@2017-10-07.yang" <CODE BEGINS>file "ietf-acldns@2018-01-24.yang"
module ietf-acldns { module ietf-acldns {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-acldns"; namespace "urn:ietf:params:xml:ns:yang:ietf-acldns";
prefix "ietf-acldns"; prefix "ietf-acldns";
import ietf-access-control-list { import ietf-access-control-list {
prefix "acl"; prefix "acl";
} }
import ietf-inet-types { import ietf-inet-types {
prefix "inet"; prefix "inet";
} }
organization organization
"IETF OPSAWG (Ops Area) Working Group"; "IETF OPSAWG (Ops Area) Working Group";
contact contact
skipping to change at page 25, line 10 skipping to change at page 25, line 30
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-10-07" { revision "2018-01-24" {
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";
} }
grouping dns-matches { grouping dns-matches {
description "Domain names for matching."; description "Domain names for matching.";
leaf src-dnsname { leaf src-dnsname {
type inet:host; type inet:host;
description "domain name to be matched against"; description "domain name to be matched against";
} }
leaf dst-dnsname { leaf dst-dnsname {
type inet:host; type inet:host;
description "domain name to be matched against"; description "domain name to be matched against";
} }
} }
augment "/acl:access-lists/acl:acl/acl:aces/acl:ace/" + augment "/acl:access-lists/acl:acl/acl:aces/acl:ace/" +
"acl:matches/acl:ipv4-acl" { "acl:matches/acl:l3/acl:ipv4" {
description "Adding domain names to matching"; description "Adding domain names to matching";
uses dns-matches; uses dns-matches;
} }
augment "/acl:access-lists/acl:acl/" + augment "/acl:access-lists/acl:acl/" +
"acl:aces/acl:ace/" + "acl:aces/acl:ace/" +
"acl:matches/acl:ipv6-acl" { "acl:matches/acl:l3/acl:ipv6" {
description "Adding domain names to matching"; description "Adding domain names to matching";
uses dns-matches; uses dns-matches;
} }
} }
<CODE ENDS> <CODE ENDS>
8. MUD File Example 8. MUD File Example
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.
{ {
"ietf-mud:mud": { "ietf-mud:mud": {
"mud-url": "mud-version": 1,
"https://bms.example.com/.well-known/mud/v1/lightbulb2000", "mud-url": "https://bms.example.com/.well-known/mud/lightbulb2000",
"last-update": "2017-10-07T12:16:24+02:00", "last-update": "2018-01-23T13:33:52+01:00",
"cache-validity": 48, "cache-validity": 48,
"is-supported": true, "is-supported": true,
"systeminfo": "systeminfo": "The BMS Example Lightbulb",
"https://bms.example.com/descriptions/lightbulb2000", "from-device-policy": {
"from-device-policy": { "access-lists": {
"access-lists": { "access-list": [
"access-list": [ {
{ "name": "mud-45782-v6fr"
"acl-name": "mud-14377-v6fr", }
"acl-type": "ietf-access-control-list:ipv6-acl" ]
}
]
}
},
"to-device-policy": {
"access-lists": {
"access-list": [
{
"acl-name": "mud-14377-v6to",
"acl-type": "ietf-access-control-list:ipv6-acl"
}
]
}
} }
}, },
"ietf-access-control-list:access-lists": { "to-device-policy": {
"acl": [ "access-lists": {
{ "access-list": [
"acl-name": "mud-14377-v6to", {
"acl-type": "ipv6-acl", "name": "mud-45782-v6to"
"access-list-entries": { }
"ace": [ ]
{ }
"rule-name": "cl0-todev", }
"matches": { },
"ipv6-acl": { "ietf-access-control-list:access-lists": {
"ietf-acldns:src-dnsname": "acl": [
"service.bms.example.com", {
"protocol": 6, "name": "mud-45782-v6to",
"source-port-range": { "acl-type": "ipv6-acl-type",
"lower-port": 443, "access-list-entries": {
"upper-port": 443 "ace": [
} {
}, "rule-name": "cl0-todev",
"tcp-acl": { "matches": {
"ietf-mud:direction-initiated": "from-device" "ipv6-acl": {
"ietf-acldns:src-dnsname": "service.bms.example.com",
"protocol": 6,
"source-port-range-or-operator": {
"operator": "eq",
"port": 443
} }
}, },
"actions": { "tcp": {
"forwarding": "accept" "ietf-mud:direction-initiated": "from-device"
} }
},
"actions": {
"forwarding": "accept"
} }
] }
} ]
}, }
{ },
"acl-name": "mud-14377-v6fr", {
"acl-type": "ipv6-acl", "name": "mud-45782-v6fr",
"access-list-entries": { "acl-type": "ipv6-acl-type",
"ace": [ "access-list-entries": {
{ "ace": [
"rule-name": "cl0-frdev", {
"matches": { "rule-name": "cl0-frdev",
"ipv6-acl": { "matches": {
"ietf-acldns:dst-dnsname": "ipv6-acl": {
"service.bms.example.com", "ietf-acldns:dst-dnsname": "service.bms.example.com",
"protocol": 6, "protocol": 6,
"destination-port-range": { "destination-port-range-or-operator": {
"lower-port": 443, "operator": "eq",
"upper-port": 443 "port": 443
}
},
"tcp-acl": {
"ietf-mud:direction-initiated": "from-device"
} }
}, },
"actions": { "tcp": {
"forwarding": "accept" "ietf-mud:direction-initiated": "from-device"
} }
},
"actions": {
"forwarding": "accept"
} }
] }
} ]
} }
] }
} ]
} }
}
In this example, two policies are declared, one from the Thing and In this example, two policies are declared, one from the Thing and
the other to the Thing. Each policy names an access list that the other to the Thing. Each policy names an access list that
applies to the Thing, and one that applies from. Within each access applies to the Thing, and one that applies from. Within each access
list, access is permitted to packets flowing to or from the Thing list, access is permitted to packets flowing to or from the Thing
that can be mapped to the domain name of "service.bms.example.com". that can be mapped to the domain name of "service.bms.example.com".
For each access list, the enforcement point should expect that the For each access list, the enforcement point should expect that the
Thing initiated the connection. Thing initiated the connection.
9. The MUD URL DHCP Option 9. The MUD URL DHCP Option
skipping to change at page 33, line 35 skipping to change at page 33, line 35
% openssl cms -sign -signer mancertfile -inkey mankey \ % openssl cms -sign -signer mancertfile -inkey mankey \
-in mudfile -binary -outform DER - \ -in mudfile -binary -outform DER - \
-certfile intermediatecert -out mudfile.p7s -certfile intermediatecert -out mudfile.p7s
Note: A MUD file may need to be re-signed if the signature expires. Note: A MUD file may need to be re-signed if the signature expires.
12.2. Verifying a MUD file signature 12.2. Verifying a MUD file signature
Prior to retrieving a MUD file the MUD controller SHOULD retrieve the Prior to retrieving a MUD file the MUD controller SHOULD retrieve the
MUD signature file using the MUD URL with a suffix of ".p7s". For MUD signature file using the MUD URL with a suffix of ".p7s". For
example, if the MUD URL is "https://example.com/.well-known/v1/ example, if the MUD URL is "https://example.com/.well-known/modela",
modela", the MUD signature URL will be "https://example.com/.well- the MUD signature URL will be "https://example.com/.well-known/
known/v1/modela.p7s". modela.p7s".
Upon retrieving a MUD file, a MUD controller MUST validate the Upon retrieving a MUD file, a MUD controller MUST validate the
signature of the file before continuing with further processing. A signature of the file before continuing with further processing. A
MUD controller MUST cease processing of that file it cannot validate MUD controller MUST cease processing of that file it cannot validate
the chain of trust to a known trust anchor until an administrator has the chain of trust to a known trust anchor until an administrator has
given approval. given approval.
The purpose of the signature on the file is to assign accountability The purpose of the signature on the file is to assign accountability
to an entity, whose reputation can be used to guide administrators on to an entity, whose reputation can be used to guide administrators on
whether or not to accept a given MUD file. It is already common whether or not to accept a given MUD file. It is already common
skipping to change at page 38, line 9 skipping to change at page 38, line 9
o XML Namespace: urn:ietf:params:xml:ns:yang:ietf-acldns o XML Namespace: urn:ietf:params:xml:ns:yang:ietf-acldns
o Prefix: ietf-acldns o Prefix: ietf-acldns
o Reference: This memo o Reference: This memo
16.2. DHCPv4 and DHCPv6 Options 16.2. DHCPv4 and DHCPv6 Options
The IANA has allocated option 161 in the Dynamic Host Configuration The IANA has allocated option 161 in the Dynamic Host Configuration
Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters registry Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters registry
for the MUD DHCPv4 option. for the MUD DHCPv4 option, and option 112 for DHCPv6, as described in
Section 9.
IANA is requested to allocated the DHCPv4 and v6 options as specified
in Section 9.
16.3. PKIX Extensions 16.3. PKIX Extensions
IANA is kindly requested to make the following assignments for: IANA is kindly requested to make the following assignments for:
o The MUDURLExtnModule-2016 ASN.1 module in the "SMI Security for o The MUDURLExtnModule-2016 ASN.1 module in the "SMI Security for
PKIX Module Identifier" registry (1.3.6.1.5.5.7.0). PKIX Module Identifier" registry (1.3.6.1.5.5.7.0).
o id-pe-mud-url object identifier from the "SMI Security for PKIX o id-pe-mud-url object identifier from the "SMI Security for PKIX
Certificate Extension" registry (1.3.6.1.5.5.7.1). Certificate Extension" registry (1.3.6.1.5.5.7.1).
skipping to change at page 41, line 12 skipping to change at page 41, line 12
architecture and the YANG model. The remaining errors in this work architecture and the YANG model. The remaining errors in this work
are entirely the responsibility of the authors. are entirely the responsibility of the authors.
18. References 18. References
18.1. Normative References 18.1. Normative References
[I-D.ietf-netmod-acl-model] [I-D.ietf-netmod-acl-model]
Jethanandani, M., Huang, L., Agarwal, S., and D. Blair, Jethanandani, M., Huang, L., Agarwal, S., and D. Blair,
"Network Access Control List (ACL) YANG Data Model", "Network Access Control List (ACL) YANG Data Model",
draft-ietf-netmod-acl-model-14 (work in progress), October draft-ietf-netmod-acl-model-15 (work in progress), January
2017. 2018.
[I-D.ietf-netmod-yang-tree-diagrams]
Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft-
ietf-netmod-yang-tree-diagrams-05 (work in progress),
January 2018.
[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, <https://www.rfc- DOI 10.17487/RFC1123, October 1989,
editor.org/info/rfc1123>. <https://www.rfc-editor.org/info/rfc1123>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997, RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/info/rfc2131>. <https://www.rfc-editor.org/info/rfc2131>.
[RFC2618] Aboba, B. and G. Zorn, "RADIUS Authentication Client MIB",
RFC 2618, DOI 10.17487/RFC2618, June 1999,
<https://www.rfc-editor.org/info/rfc2618>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000, <https://www.rfc- DOI 10.17487/RFC2818, May 2000,
editor.org/info/rfc2818>. <https://www.rfc-editor.org/info/rfc2818>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <https://www.rfc-editor.org/info/rfc3315>. 2003, <https://www.rfc-editor.org/info/rfc3315>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<https://www.rfc-editor.org/info/rfc3748>. <https://www.rfc-editor.org/info/rfc3748>.
skipping to change at page 42, line 44 skipping to change at page 43, line 5
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
2014, <https://www.rfc-editor.org/info/rfc7120>. 2014, <https://www.rfc-editor.org/info/rfc7120>.
[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and
S. Krishnan, "Guidelines for Creating New DHCPv6 Options", S. Krishnan, "Guidelines for Creating New DHCPv6 Options",
BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014,
<https://www.rfc-editor.org/info/rfc7227>. <https://www.rfc-editor.org/info/rfc7227>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>.
[RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: [RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield:
Protecting against Rogue DHCPv6 Servers", BCP 199, Protecting against Rogue DHCPv6 Servers", BCP 199,
RFC 7610, DOI 10.17487/RFC7610, August 2015, RFC 7610, DOI 10.17487/RFC7610, August 2015,
<https://www.rfc-editor.org/info/rfc7610>. <https://www.rfc-editor.org/info/rfc7610>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
RFC 7951, DOI 10.17487/RFC7951, August 2016, RFC 7951, DOI 10.17487/RFC7951, August 2016,
<https://www.rfc-editor.org/info/rfc7951>. <https://www.rfc-editor.org/info/rfc7951>.
18.2. Informative References 18.2. Informative References
[FW95] Chapman, D. and E. Zwicky, "Building Internet Firewalls", [FW95] Chapman, D. and E. Zwicky, "Building Internet Firewalls",
January 1995. January 1995.
[I-D.ietf-netmod-rfc6087bis] [I-D.ietf-netmod-rfc6087bis]
Bierman, A., "Guidelines for Authors and Reviewers of YANG Bierman, A., "Guidelines for Authors and Reviewers of YANG
Data Model Documents", draft-ietf-netmod-rfc6087bis-14 Data Model Documents", draft-ietf-netmod-rfc6087bis-16
(work in progress), September 2017. (work in progress), January 2018.
[IEEE8021AR] [IEEE8021AR]
Institute for Electrical and Electronics Engineers, Institute for Electrical and Electronics Engineers,
"Secure Device Identity", 1998. "Secure Device Identity", 1998.
[ISO.8601.1988] [ISO.8601.1988]
International Organization for Standardization, "Data International Organization for Standardization, "Data
elements and interchange formats - Information interchange elements and interchange formats - Information interchange
- Representation of dates and times", ISO Standard 8601, - Representation of dates and times", ISO Standard 8601,
June 1988. June 1988.
[RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic [RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic
Technology and the Internet", BCP 200, RFC 1984, Technology and the Internet", BCP 200, RFC 1984,
DOI 10.17487/RFC1984, August 1996, <https://www.rfc- DOI 10.17487/RFC1984, August 1996,
editor.org/info/rfc1984>. <https://www.rfc-editor.org/info/rfc1984>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>. <https://www.rfc-editor.org/info/rfc3339>.
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
IETF URN Sub-namespace for Registered Protocol IETF URN Sub-namespace for Registered Protocol
Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June
2003, <https://www.rfc-editor.org/info/rfc3553>. 2003, <https://www.rfc-editor.org/info/rfc3553>.
[RFC6092] Woodyatt, J., Ed., "Recommended Simple Security [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security
Capabilities in Customer Premises Equipment (CPE) for Capabilities in Customer Premises Equipment (CPE) for
Providing Residential IPv6 Internet Service", RFC 6092, Providing Residential IPv6 Internet Service", RFC 6092,
DOI 10.17487/RFC6092, January 2011, <https://www.rfc- DOI 10.17487/RFC6092, January 2011,
editor.org/info/rfc6092>. <https://www.rfc-editor.org/info/rfc6092>.
[RFC6872] Gurbani, V., Ed., Burger, E., Ed., Anjali, T., Abdelnur, [RFC6872] Gurbani, V., Ed., Burger, E., Ed., Anjali, T., Abdelnur,
H., and O. Festor, "The Common Log Format (CLF) for the H., and O. Festor, "The Common Log Format (CLF) for the
Session Initiation Protocol (SIP): Framework and Session Initiation Protocol (SIP): Framework and
Information Model", RFC 6872, DOI 10.17487/RFC6872, Information Model", RFC 6872, DOI 10.17487/RFC6872,
February 2013, <https://www.rfc-editor.org/info/rfc6872>. February 2013, <https://www.rfc-editor.org/info/rfc6872>.
[RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and
IETF Protocol and Documentation Usage for IEEE 802 IETF Protocol and Documentation Usage for IEEE 802
Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042,
October 2013, <https://www.rfc-editor.org/info/rfc7042>. October 2013, <https://www.rfc-editor.org/info/rfc7042>.
[RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna,
"Tunnel Extensible Authentication Protocol (TEAP) Version "Tunnel Extensible Authentication Protocol (TEAP) Version
1", RFC 7170, DOI 10.17487/RFC7170, May 2014, 1", RFC 7170, DOI 10.17487/RFC7170, May 2014,
<https://www.rfc-editor.org/info/rfc7170>. <https://www.rfc-editor.org/info/rfc7170>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, <https://www.rfc- DOI 10.17487/RFC7252, June 2014,
editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, [RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson,
"Architectural Considerations in Smart Object Networking", "Architectural Considerations in Smart Object Networking",
RFC 7452, DOI 10.17487/RFC7452, March 2015, RFC 7452, DOI 10.17487/RFC7452, March 2015,
<https://www.rfc-editor.org/info/rfc7452>. <https://www.rfc-editor.org/info/rfc7452>.
[RFC7488] Boucadair, M., Penno, R., Wing, D., Patil, P., and T. [RFC7488] Boucadair, M., Penno, R., Wing, D., Patil, P., and T.
Reddy, "Port Control Protocol (PCP) Server Selection", Reddy, "Port Control Protocol (PCP) Server Selection",
RFC 7488, DOI 10.17487/RFC7488, March 2015, RFC 7488, DOI 10.17487/RFC7488, March 2015,
<https://www.rfc-editor.org/info/rfc7488>. <https://www.rfc-editor.org/info/rfc7488>.
Appendix A. Changes from Earlier Versions Appendix A. Changes from Earlier Versions
RFC Editor to remove this section prior to publication. RFC Editor to remove this section prior to publication.
Draft -13 to -14:
o Final WGLC comments and review comments
o Move version from MUD-URL to Model
o Have MUD-URL in model
o Update based on update to draft-ietf-netmod-acl-model
o Point to tree diagram draft instead of 6087bis.
Draft -12 to -13:
o Additional WGLC comments
Draft -10 to -12: Draft -10 to -12:
These are based on WGLC comments: These are based on WGLC comments:
o Correct examples based on ACL model changes. o Correct examples based on ACL model changes.
o Change ordering nodes. o Change ordering nodes.
o Additional explanatory text around systeminfo. o Additional explanatory text around systeminfo.
skipping to change at page 47, line 46 skipping to change at page 48, line 29
the matching statement but replaces the "forwarding" action "accept" the matching statement but replaces the "forwarding" action "accept"
with "drop". Because ACEs are processed in the order they are with "drop". Because ACEs are processed in the order they are
received, the defaults would not be reached. A MUD controller might received, the defaults would not be reached. A MUD controller might
further decide to optimize to simply not include the defaults when further decide to optimize to simply not include the defaults when
they are overriden. they are overriden.
Four of "acl" liste entries that implement default MUD nodes is Four of "acl" liste entries that implement default MUD nodes is
listed below. Two are for IPv4 and two are for IPv6 (one in each listed below. Two are for IPv4 and two are for IPv6 (one in each
direction for both versions of IP). direction for both versions of IP).
"ietf-access-control-list:access-lists": { "ietf-access-control-list:access-lists": {
"acl": [ "acl": [
{ {
"acl-name": "mud-v4-default-to-device", "name": "mud-63142-v4to",
"acl-type": "ipv4-acl", "acl-type": "ipv4-acl-type",
"aces": { "aces": {
"ace": [ "ace": [
{ {
"rule-name": "ent0-todev", "rule-name": "ent0-todev",
"matches": { "matches": {
"ietf-mud:mud-acl": { "ietf-mud:mud-acl": {
"controller": "urn:ietf:params:mud:dns" "controller": "urn:ietf:params:mud:dns"
}, },
"ipv4-acl": { "ipv4": {
"protocol": 17, "protocol": 17,
"source-port-range": { "source-port-range-or-operator": {
"lower-port": 53, "operator": "eq",
"upper-port": 53 "port": 53
} }
} }
}, },
"actions": { "actions": {
"forwarding": "accept" "forwarding": "accept"
} }
}, },
{ {
"rule-name": "ent1-todev", "rule-name": "ent1-todev",
"matches": { "matches": {
"ietf-mud:mud-acl": { "ietf-mud:mud-acl": {
"controller": "urn:ietf:params:mud:ntp" "controller": "urn:ietf:params:mud:ntp"
}, },
"ipv4-acl": { "ipv4": {
"protocol": 17, "protocol": 17,
"source-port-range": { "source-port-range-or-operator": {
"lower-port": 123, "operator": "eq",
"upper-port": 123 "port": 123
} }
} }
}, },
"actions": { "actions": {
"forwarding": "accept" "forwarding": "accept"
} }
} }
] ]
} }
}, },
{ {
"acl-name": "mud-v4-default-from-device", "name": "mud-63142-v4fr",
"acl-type": "ipv4-acl", "acl-type": "ipv4-acl-type",
"aces": { "aces": {
"ace": [ "ace": [
{ {
"rule-name": "ent0-frdev", "rule-name": "ent0-frdev",
"matches": { "matches": {
"ietf-mud:mud-acl": { "ietf-mud:mud-acl": {
"controller": "urn:ietf:params:mud:dns" "controller": "urn:ietf:params:mud:dns"
}, },
"ipv4-acl": { "ipv4": {
"protocol": 17, "protocol": 17,
"destination-port-range": { "destination-port-range-or-operator": {
"lower-port": 53, "operator": "eq",
"upper-port": 53 "port": 53
} }
} }
}, },
"actions": { "actions": {
"forwarding": "accept" "forwarding": "accept"
} }
}, },
{ {
"rule-name": "ent1-frdev", "rule-name": "ent1-frdev",
"matches": { "matches": {
"ietf-mud:mud-acl": { "ietf-mud:mud-acl": {
"controller": "urn:ietf:params:mud:ntp" "controller": "urn:ietf:params:mud:ntp"
}, },
"ipv4-acl": { "ipv4": {
"protocol": 17, "protocol": 17,
"destination-port-range": { "destination-port-range-or-operator": {
"lower-port": 123, "operator": "eq",
"upper-port": 123 "port": 123
} }
} }
}, },
"actions": { "actions": {
"forwarding": "accept" "forwarding": "accept"
} }
} }
] ]
} }
}, },
{ {
"acl-name": "mud-v6-default-to-device", "name": "mud-63142-v6to",
"acl-type": "ipv6-acl", "acl-type": "ipv6-acl-type",
"access-list-entries": { "access-list-entries": {
"ace": [ "ace": [
{ {
"rule-name": "ent0-todev", "rule-name": "ent0-todev",
"matches": { "matches": {
"ietf-mud:mud-acl": { "ietf-mud:mud-acl": {
"controller": "urn:ietf:params:mud:dns" "controller": "urn:ietf:params:mud:dns"
}, },
"ipv6-acl": { "ipv6": {
"protocol": 17, "protocol": 17,
"source-port-range": { "source-port-range-or-operator": {
"lower-port": 53, "operator": "eq",
"upper-port": 53 "port": 53
} }
} }
}, },
"actions": { "actions": {
"forwarding": "accept" "forwarding": "accept"
} }
}, },
{ {
"rule-name": "ent1-todev", "rule-name": "ent1-todev",
"matches": { "matches": {
"ietf-mud:mud-acl": { "ietf-mud:mud-acl": {
"controller": "urn:ietf:params:mud:ntp" "controller": "urn:ietf:params:mud:ntp"
}, },
"ipv6-acl": { "ipv6": {
"protocol": 17, "protocol": 17,
"source-port-range": { "source-port-range-or-operator": {
"lower-port": 123, "operator": "eq",
"upper-port": 123 "port": 123
} }
} }
}, },
"actions": { "actions": {
"forwarding": "accept" "forwarding": "accept"
} }
} }
] ]
} }
}, },
{ {
"acl-name": "mud-v6-default-from-device", "name": "mud-63142-v6fr",
"acl-type": "ipv6-acl", "acl-type": "ipv6-acl-type",
"access-list-entries": { "access-list-entries": {
"ace": [ "ace": [
{ {
"rule-name": "ent0-frdev", "rule-name": "ent0-frdev",
"matches": { "matches": {
"ietf-mud:mud-acl": { "ietf-mud:mud-acl": {
"controller": "urn:ietf:params:mud:dns" "controller": "urn:ietf:params:mud:dns"
}, },
"ipv6-acl": { "ipv6": {
"protocol": 17, "protocol": 17,
"destination-port-range": { "destination-port-range-or-operator": {
"lower-port": 53, "operator": "eq",
"upper-port": 53 "port": 53
} }
} }
}, },
"actions": { "actions": {
"forwarding": "accept" "forwarding": "accept"
} }
}, },
{ {
"rule-name": "ent1-frdev", "rule-name": "ent1-frdev",
"matches": { "matches": {
"ietf-mud:mud-acl": { "ietf-mud:mud-acl": {
"controller": "urn:ietf:params:mud:ntp" "controller": "urn:ietf:params:mud:ntp"
}, },
"ipv6-acl": { "ipv6": {
"protocol": 17, "protocol": 17,
"destination-port-range": { "destination-port-range-or-operator": {
"lower-port": 123, "operator": "eq",
"upper-port": 123 "port": 123
} }
} }
}, },
"actions": { "actions": {
"forwarding": "accept" "forwarding": "accept"
} }
} }
] ]
} }
} }
skipping to change at page 52, line 11 skipping to change at page 52, line 37
This extension augments the MUD model to include a single node, using This extension augments the MUD model to include a single node, using
the following sample module that has the following tree structure: the following sample module that has the following tree structure:
module: ietf-mud-detext-example module: ietf-mud-detext-example
augment /ietf-mud:mud: augment /ietf-mud:mud:
+--rw is-detnet-required? boolean +--rw is-detnet-required? boolean
The model is defined as follows: The model is defined as follows:
<CODE BEGINS>file "ietf-mud-detext-example@2016-09-07.yang" <CODE BEGINS>file "ietf-mud-detext-example@2018-01-24.yang"
module ietf-mud-detext-example { module ietf-mud-detext-example {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-mud-detext-example"; namespace "urn:ietf:params:xml:ns:yang:ietf-mud-detext-example";
prefix ietf-mud-detext-example; prefix ietf-mud-detext-example;
import ietf-mud { import ietf-mud {
prefix ietf-mud; prefix ietf-mud;
} }
organization organization
skipping to change at page 52, line 38 skipping to change at page 53, line 20
Author: Ralph Droms Author: Ralph Droms
rdroms@gmail.com rdroms@gmail.com
Author: Dan Romascanu Author: Dan Romascanu
dromasca@gmail.com dromasca@gmail.com
"; ";
description description
"Sample extension to a MUD module to indicate a need "Sample extension to a MUD module to indicate a need
for DETNET support."; for DETNET support.";
revision 2017-09-05 { revision 2018-01-24 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: Manufacturer Usage Description "RFC XXXX: Manufacturer Usage Description
Specification"; Specification";
} }
augment "/ietf-mud:mud" { augment "/ietf-mud:mud" {
description description
"This adds a simple extension for a manufacturer "This adds a simple extension for a manufacturer
skipping to change at page 53, line 17 skipping to change at page 53, line 47
detnet to properly function"; detnet to properly function";
} }
} }
} }
<CODE ENDS> <CODE ENDS>
Using the previous example, we now show how the extension would be Using the previous example, we now show how the extension would be
expressed: expressed:
{ {
{
"ietf-mud:mud": { "ietf-mud:mud": {
"mud-url": "https://bms.example.com/.well-known/mud/v1/lightbulb", "mud-version": 1,
"last-update": "2017-09-20T15:49:18+02:00", "mud-url": "https://bms.example.com/.well-known/mud/lightbulb2000",
"last-update": "2018-01-23T13:33:52+01:00",
"cache-validity": 48, "cache-validity": 48,
"is-supported": true, "is-supported": true,
"systeminfo": "https://bms.example.com/descriptions/lightbulb", "systeminfo": "The BMS Example Lightbulb",
"extensions": [ "extensions": [
"ietf-mud-detext-example" "ietf-mud-detext-example"
], ],
"ietf-mud-detext-example:is-detnet-required": "false", "ietf-mud-detext-example:is-detnet-required": "false",
"from-device-policy": { "from-device-policy": {
"access-lists": { "access-lists": {
"access-list": [ "access-list": [
{ {
"acl-name": "mud-54684-v6fr", "name": "mud-45782-v6fr"
"acl-type": "ietf-access-control-list:ipv6-acl"
} }
] ]
} }
}, },
"to-device-policy": { "to-device-policy": {
"access-lists": { "access-lists": {
"access-list": [ "access-list": [
{ {
"acl-name": "mud-54684-v6to", "name": "mud-45782-v6to"
"acl-type": "ietf-access-control-list:ipv6-acl"
} }
] ]
} }
} }
}, },
"ietf-access-control-list:access-lists": { "ietf-access-control-list:access-lists": {
"acl": [ "acl": [
{ {
"acl-name": "mud-54684-v6to", "name": "mud-45782-v6to",
"acl-type": "ipv6-acl", "acl-type": "ipv6-acl-type",
"access-list-entries": { "access-list-entries": {
"ace": [ "ace": [
{ {
"rule-name": "cl0-todev", "rule-name": "cl0-todev",
"matches": { "matches": {
"ipv6-acl": { "ipv6-acl": {
"ietf-acldns:src-dnsname": "service.bms.example.com", "ietf-acldns:src-dnsname": "service.bms.example.com",
"protocol": 6, "protocol": 6,
"source-port-range": { "source-port-range-or-operator": {
"lower-port": 443, "operator": "eq",
"upper-port": 443 "port": 443
} }
}, },
"tcp-acl": { "tcp": {
"ietf-mud:direction-initiated": "from-device" "ietf-mud:direction-initiated": "from-device"
} }
}, },
"actions": { "actions": {
"forwarding": "accept" "forwarding": "accept"
} }
} }
] ]
} }
}, },
{ {
"acl-name": "mud-54684-v6fr", "name": "mud-45782-v6fr",
"acl-type": "ipv6-acl", "acl-type": "ipv6-acl-type",
"access-list-entries": { "access-list-entries": {
"ace": [ "ace": [
{ {
"rule-name": "cl0-frdev", "rule-name": "cl0-frdev",
"matches": { "matches": {
"ipv6-acl": { "ipv6-acl": {
"ietf-acldns:dst-dnsname": "service.bms.example.com", "ietf-acldns:dst-dnsname": "service.bms.example.com",
"protocol": 6, "protocol": 6,
"destination-port-range": { "destination-port-range-or-operator": {
"lower-port": 443, "operator": "eq",
"upper-port": 443 "port": 443
} }
}, },
"tcp-acl": { "tcp": {
"ietf-mud:direction-initiated": "from-device" "ietf-mud:direction-initiated": "from-device"
} }
}, },
"actions": { "actions": {
"forwarding": "accept" "forwarding": "accept"
} }
} }
] ]
} }
} }
] ]
} }
} }
Authors' Addresses Authors' Addresses
Eliot Lear Eliot Lear
Cisco Systems Cisco Systems
Richtistrasse 7 Richtistrasse 7
Wallisellen CH-8304 Wallisellen CH-8304
Switzerland Switzerland
Phone: +41 44 878 9200 Phone: +41 44 878 9200
Email: lear@cisco.com Email: lear@cisco.com
Ralph Droms Ralph Droms
 End of changes. 149 change blocks. 
387 lines changed or deleted 441 lines changed or added

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