RFC 8520
Manufacturer Usage Description Specification
18. References
18.1. Normative References
[IEEE8021AB] IEEE, "IEEE Standard for Local and Metropolitan Area Networks-- Station and Media Access Control Connectivity Discovery", IEEE 802.1AB. [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, <https://www.rfc-editor.org/info/rfc1123>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <https://www.rfc-editor.org/info/rfc2131>. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <https://www.rfc-editor.org/info/rfc2818>. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, <https://www.rfc-editor.org/info/rfc3748>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>. [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, January 2005, <https://www.rfc-editor.org/info/rfc3987>. [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>. [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>. [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>. [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10.17487/RFC5912, June 2010, <https://www.rfc-editor.org/info/rfc5912>. [RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)", RFC 6268, DOI 10.17487/RFC6268, July 2011, <https://www.rfc-editor.org/info/rfc6268>. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <https://www.rfc-editor.org/info/rfc6335>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>. [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014, <https://www.rfc-editor.org/info/rfc7120>. [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and S. Krishnan, "Guidelines for Creating New DHCPv6 Options", BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, <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: Protecting against Rogue DHCPv6 Servers", BCP 199, RFC 7610, DOI 10.17487/RFC7610, August 2015, <https://www.rfc-editor.org/info/rfc7610>. [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>. [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, August 2016, <https://www.rfc-editor.org/info/rfc7951>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>. [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.
[RFC8348] Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A YANG Data Model for Hardware Management", RFC 8348, DOI 10.17487/RFC8348, March 2018, <https://www.rfc-editor.org/info/rfc8348>. [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>. [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, "YANG Data Model for Network Access Control Lists (ACLs)", RFC 8519, DOI 10.17487/RFC8519, March 2019, <https://www.rfc-editor.org/info/rfc8519>.18.2. Informative References
[FW95] Chapman, D. and E. Zwicky, "Building Internet Firewalls", First Edition, November 1995. [IEEE80211i] IEEE, "IEEE Standard for information technology- Telecommunications and information exchange between systems-Local and metropolitan area networks-Specific requirements-Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications: Amendment 6: Medium Access Control (MAC) Security Enhancements", IEEE 802.11i. [IEEE8021AE] IEEE, "IEEE Standard for Local and metropolitan area networks-Media Access Control (MAC) Security", IEEE 802.1AE. [IEEE8021AR] IEEE, "IEEE Standard for Local and metropolitan area networks - Secure Device Identity", IEEE 802.1AR. [IEEE8021X] IEEE, "IEEE Standard for Local and metropolitan area networks--Port-Based Network Access Control", IEEE 802.1X. [RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic Technology and the Internet", BCP 200, RFC 1984, DOI 10.17487/RFC1984, August 1996, <https://www.rfc-editor.org/info/rfc1984>.
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 2003, <https://www.rfc-editor.org/info/rfc3553>. [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, DOI 10.17487/RFC6092, January 2011, <https://www.rfc-editor.org/info/rfc6092>. [RFC6872] Gurbani, V., Ed., Burger, E., Ed., Anjali, T., Abdelnur, H., and O. Festor, "The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Information Model", RFC 6872, DOI 10.17487/RFC6872, February 2013, <https://www.rfc-editor.org/info/rfc6872>. [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, October 2013, <https://www.rfc-editor.org/info/rfc7042>. [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, "Tunnel Extensible Authentication Protocol (TEAP) Version 1", RFC 7170, DOI 10.17487/RFC7170, May 2014, <https://www.rfc-editor.org/info/rfc7170>. [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>. [RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, "Architectural Considerations in Smart Object Networking", RFC 7452, DOI 10.17487/RFC7452, March 2015, <https://www.rfc-editor.org/info/rfc7452>. [RFC7488] Boucadair, M., Penno, R., Wing, D., Patil, P., and T. Reddy, "Port Control Protocol (PCP) Server Selection", RFC 7488, DOI 10.17487/RFC7488, March 2015, <https://www.rfc-editor.org/info/rfc7488>. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, <https://www.rfc-editor.org/info/rfc8343>. [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of Documents Containing YANG Data Models", BCP 216, RFC 8407, DOI 10.17487/RFC8407, October 2018, <https://www.rfc-editor.org/info/rfc8407>.
Appendix A. Default MUD Nodes
What follows is the portion of a MUD file that permits DNS traffic to a controller that is registered with the URN "urn:ietf:params:mud:dns" and traffic NTP to a controller that is registered with "urn:ietf:params:mud:ntp". This is considered the default behavior, and the ACEs are in effect appended to whatever other "ace" entries that a MUD file contains. To block DNS or NTP, one repeats the matching statement but replaces the "forwarding" action "accept" with "drop". Because ACEs are processed in the order they are received, the defaults would not be reached. A MUD manager might further decide to optimize to simply not include the defaults when they are overridden. Four "acl" list entries that implement default MUD nodes are listed below. Two are for IPv4 and two are for IPv6 (one in each direction for both versions of IP). Note that neither the access list name nor the ace name need be retained or used in any way by local implementations; they are simply there for the sake of completeness. "ietf-access-control-list:acls": { "acl": [ { "name": "mud-59776-v4to", "type": "ipv4-acl-type", "aces": { "ace": [ { "name": "ent0-todev", "matches": { "ietf-mud:mud": { "controller": "urn:ietf:params:mud:dns" }, "ipv4": { "protocol": 17 }, "udp": { "source-port": { "operator": "eq", "port": 53 } } }, "actions": { "forwarding": "accept" } }, {
"name": "ent1-todev",
"matches": {
"ietf-mud:mud": {
"controller": "urn:ietf:params:mud:ntp"
},
"ipv4": {
"protocol": 17
},
"udp": {
"source-port": {
"operator": "eq",
"port": 123
}
}
},
"actions": {
"forwarding": "accept"
}
}
]
}
},
{
"name": "mud-59776-v4fr",
"type": "ipv4-acl-type",
"aces": {
"ace": [
{
"name": "ent0-frdev",
"matches": {
"ietf-mud:mud": {
"controller": "urn:ietf:params:mud:dns"
},
"ipv4": {
"protocol": 17
},
"udp": {
"destination-port": {
"operator": "eq",
"port": 53
}
}
},
"actions": {
"forwarding": "accept"
}
},
{
"name": "ent1-frdev",
"matches": {
"ietf-mud:mud": {
"controller": "urn:ietf:params:mud:ntp"
},
"ipv4": {
"protocol": 17
},
"udp": {
"destination-port": {
"operator": "eq",
"port": 123
}
}
},
"actions": {
"forwarding": "accept"
}
}
]
}
},
{
"name": "mud-59776-v6to",
"type": "ipv6-acl-type",
"aces": {
"ace": [
{
"name": "ent0-todev",
"matches": {
"ietf-mud:mud": {
"controller": "urn:ietf:params:mud:dns"
},
"ipv6": {
"protocol": 17
},
"udp": {
"source-port": {
"operator": "eq",
"port": 53
}
}
},
"actions": {
"forwarding": "accept"
}
},
{
"name": "ent1-todev",
"matches": {
"ietf-mud:mud": {
"controller": "urn:ietf:params:mud:ntp"
},
"ipv6": {
"protocol": 17
},
"udp": {
"source-port": {
"operator": "eq",
"port": 123
}
}
},
"actions": {
"forwarding": "accept"
}
}
]
}
},
{
"name": "mud-59776-v6fr",
"type": "ipv6-acl-type",
"aces": {
"ace": [
{
"name": "ent0-frdev",
"matches": {
"ietf-mud:mud": {
"controller": "urn:ietf:params:mud:dns"
},
"ipv6": {
"protocol": 17
},
"udp": {
"destination-port": {
"operator": "eq",
"port": 53
}
}
},
"actions": {
"forwarding": "accept"
}
},
{
"name": "ent1-frdev",
"matches": {
"ietf-mud:mud": {
"controller": "urn:ietf:params:mud:ntp"
},
"ipv6": {
"protocol": 17
},
"udp": {
"destination-port": {
"operator": "eq",
"port": 123
}
}
},
"actions": {
"forwarding": "accept"
}
}
]
}
}
]
}
Appendix B. A Sample Extension: DETNET-indicator
In this sample extension, we augment the core MUD model to indicate
whether the device implements DETNET. If a device claims not to use
DETNET, but then later attempts to do so, a notification or exception
might be generated. Note that this example is intended only for
illustrative purposes.
Extension Name: "Example-Extension" (to be used in the extensions list)
Standard: RFC 8520 (but do not register the example)
This extension augments the MUD model to include a single node, using
the following sample module that has the following tree structure:
module: ietf-mud-detext-example
augment /ietf-mud:mud:
+--rw is-detnet-required? boolean
The model is defined as follows:
<CODE BEGINS>file "ietf-mud-detext-example@2019-01-28.yang"
module ietf-mud-detext-example {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-mud-detext-example";
prefix ietf-mud-detext-example;
import ietf-mud {
prefix ietf-mud;
}
organization
"IETF OPSAWG (Operations and Management Area Working Group)";
contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: opsawg@ietf.org
Author: Eliot Lear
lear@cisco.com
Author: Ralph Droms
rdroms@gmail.com
Author: Dan Romascanu
dromasca@gmail.com
";
description
"Sample extension to a MUD module to indicate a need
for DETNET support.";
revision 2019-01-28 {
description
"Initial revision.";
reference
"RFC 8520: Manufacturer Usage Description
Specification";
}
augment "/ietf-mud:mud" {
description
"This adds a simple extension for a manufacturer
to indicate whether DETNET is required by a
device.";
leaf is-detnet-required {
type boolean;
description
"This value will equal 'true' if a device requires
DETNET to properly function.";
}
}
}
<CODE ENDS>
Using the previous example, we now show how the extension would be
expressed:
{
"ietf-mud:mud": {
"mud-version": 1,
"mud-url": "https://lighting.example.com/lightbulb2000",
"last-update": "2019-01-28T11:20:51+01:00",
"cache-validity": 48,
"extensions": [
"ietf-mud-detext-example"
],
"ietf-mud-detext-example:is-detnet-required": "false",
"is-supported": true,
"systeminfo": "The BMS Example Light Bulb",
"from-device-policy": {
"access-lists": {
"access-list": [
{
"name": "mud-76100-v6fr"
}
]
}
},
"to-device-policy": {
"access-lists": {
"access-list": [
{
"name": "mud-76100-v6to"
}
]
}
}
},
"ietf-access-control-list:acls": {
"acl": [
{
"name": "mud-76100-v6to",
"type": "ipv6-acl-type",
"aces": {
"ace": [
{
"name": "cl0-todev",
"matches": {
"ipv6": {
"ietf-acldns:src-dnsname": "test.example.com",
"protocol": 6
},
"tcp": {
"ietf-mud:direction-initiated": "from-device",
"source-port": {
"operator": "eq",
"port": 443
}
}
},
"actions": {
"forwarding": "accept"
}
}
]
}
},
{
"name": "mud-76100-v6fr",
"type": "ipv6-acl-type",
"aces": {
"ace": [
{
"name": "cl0-frdev",
"matches": {
"ipv6": {
"ietf-acldns:dst-dnsname": "test.example.com",
"protocol": 6
},
"tcp": {
"ietf-mud:direction-initiated": "from-device",
"destination-port": {
"operator": "eq",
"port": 443
}
}
},
"actions": {
"forwarding": "accept"
}
}
]
}
}
]
}
}
Acknowledgments
The authors would like to thank Einar Nilsen-Nygaard, who
singlehandedly updated the model to match the updated ACL model,
Bernie Volz, Tom Gindin, Brian Weis, Sandeep Kumar, Thorsten Dahm,
John Bashinski, Steve Rich, Jim Bieda, Dan Wing, Joe Clarke, Henk
Birkholz, Adam Montville, Jim Schaad, and Robert Sparks for their
valuable advice and reviews. Russ Housley entirely rewrote
Section 11 to be a complete module. Adrian Farrel provided the basis
for the privacy considerations text. Kent Watsen provided a thorough
review of the architecture and the YANG model. The remaining errors
in this work are entirely the responsibility of the authors.
Authors' Addresses
Eliot Lear
Cisco Systems
Richtistrasse 7
Wallisellen CH-8304
Switzerland
Phone: +41 44 878 9200
Email: lear@cisco.com
Ralph Droms
Google
355 Main St., 5th Floor
Cambridge, MA 02142
United States of America
Phone: +1 978 376 3731
Email: rdroms@gmail.com
Dan Romascanu
Phone: +972 54 5555347
Email: dromasca@gmail.com