Manufacturer Usage Description YANG Model
draft-lear-ietf-netmod-mud-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
---|---|---|---|
Author | Eliot Lear | ||
Last updated | 2016-01-22 | ||
Replaced by | draft-ietf-opsawg-mud, RFC 8520 | ||
RFC stream | (None) | ||
Formats | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | I-D Exists | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-lear-ietf-netmod-mud-00
Network Working Group E. Lear Internet-Draft Cisco Systems Intended status: Standards Track January 22, 2016 Expires: July 25, 2016 Manufacturer Usage Description YANG Model draft-lear-ietf-netmod-mud-00 Abstract This memo specifies a YANG model to be used to generate and parse manufacturer usage descriptions. These descriptions are retrieved by network management systems in order to instantiate policies associated with those devices. This memo also specifies a well known URI suffix to indicate that a file contains XML derived from this model. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 25, 2016. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Lear Expires July 25, 2016 [Page 1] Internet-Draft MUD YANG Model January 2016 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. The MUD Model and Semantic Meaning . . . . . . . . . . . . . 3 3. Element Definitions . . . . . . . . . . . . . . . . . . . . . 3 3.1. last-update . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. cache-validity . . . . . . . . . . . . . . . . . . . . . 3 3.3. is-supported . . . . . . . . . . . . . . . . . . . . . . 4 3.4. manufacturer . . . . . . . . . . . . . . . . . . . . . . 4 3.5. same-manufacturer . . . . . . . . . . . . . . . . . . . . 4 3.6. model . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.7. local-networks . . . . . . . . . . . . . . . . . . . . . 4 3.8. controller . . . . . . . . . . . . . . . . . . . . . . . 4 4. What does a MUD URI look like? . . . . . . . . . . . . . . . 5 5. The MUD YANG Model . . . . . . . . . . . . . . . . . . . . . 5 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction Manufacturer Usage Descriptions (MUDs) provide advice to end networks on how to treat specific classes of devices. The MUD architecture is explained in [I-D.lear-mud-framework]. The files that are retrieved are intended to be closely aligned to existing network architectures so that they are easy to deploy. We make use of YANG [RFC6020] and XML because many network vendors have focused their network management efforts through this interface. The YANG model specified here is an extension of [I-D.ietf-netmod-acl-model]. The extensions in this model allow for a manufacturer to express classes of systems that a manufacturer would find necessary for the proper function of the device. These classes are then instantiated into actual IP addresses through local processing. Because manufacturers do not know who will be using their devices, it is important for functionality referenced in usage descriptions to be relatively ubiquitous, and therefore, mature. Therefore, only a limited subset of NETCONF-like content is permitted. Lear Expires July 25, 2016 [Page 2] Internet-Draft MUD YANG Model January 2016 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]. 2. The MUD Model and Semantic Meaning A MUD file consists of XML based on a YANG model. For purposes of MUD, the elements that can be modified are access lists as augmented by this model. Publishers of MUD files MUST NOT include elements that are not stated in either this memo or by [I-D.ietf-netmod-acl-model]. This module is structured into four parts. The first container holds information that is relevant to retrieval and validity of the MUD file itself. The second container augments the matching container of the ACL model to add several elements that are relevant to the MUD URI, or other otherwise abstracted for use within a local environment. The third container augments actions to add quality of service treatment. Finally, an additional container provides for some meta-information relating to why a rule might be in place. module: ietf-mud +--rw support-information +--rw last-update? yang:date-and-time +--rw cache-validity? uint32 +--rw is-supported? boolean augment /acl:access-lists/acl:acl/acl:access-list-entries /acl:ace/acl:matches: +--rw manufacturer? inet:host +--rw same-manufacturer? boolean +--rw model? string +--rw local-networks? empty +--rw controller? inet:uri 3. Element Definitions The following elements are defined. 3.1. last-update This is a date-and-time value of the last time the XML file was updated. This is akin to a version number. 3.2. cache-validity This uint32 is the period of time in hours that a network management station MUST wait since its last retrieval before checking for an Lear Expires July 25, 2016 [Page 3] Internet-Draft MUD YANG Model January 2016 update. It is RECOMMENDED that this value be no less than 24 and no more than 144 for any device that is supported. 3.3. is-supported This boolean is an indication from the manufacturer to the network administrator as to whether or not the device is supported. In this context a device is said to be supported if the manufacturer might issue an update to the device or if the manufacturer might update the MUD file. 3.4. manufacturer This element consists of a hostname that would be matched against the authority section of another device's MUD URI. 3.5. same-manufacturer This is a boolean equivalent for when the manufacturer element is used to indicate the authority that is found in another device's MUD URI matches that of the authority found in this device's MUD URI. 3.6. model This string matches the one and only segment following the authority section of the MUD URI. It refers to a model that is unique within the context of the authority. It may also include product version information. Thus how this field is constructed is entirely a local matter for the manufacturer. 3.7. local-networks This null-valued element expands to include local networks. Its default expansion is that packets must not traverse toward a default route that is received from the router. 3.8. controller This URI specifies a value that a controller will register with the network management station. The element then is expanded to the set of hosts that are so registered. In addition, some meta information is defined in order to determine when a usage description should be refreshed. Finally, the class of a device may be specified, such that a generic policy for a given class may be applied. Lear Expires July 25, 2016 [Page 4] Internet-Draft MUD YANG Model January 2016 An example of an intended MUD policy for a lightbulb might be as follows: Allow access to controller "https://mfg.example.com/example-printers" Allow access to local DNS/DHCP Deny all other access 4. What does a MUD URI look like? 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 men in the middle could otherwise harm the operation of a class of devices. .well-known is used because we wish to add additional structure to the URI. And so the URI appears as follows: mud-uri = "https://" authority "/.well-known/mud/" mud-rev "/" model "/" dev-rev *( "?" extras ) ; authority is from RFC3986 mud-rev = "v1" model = segment ; from RFC3986 dev-rev = segment ; from RFC3986 extras = query ; from RFC3986 mud-rev signifies the version of the manufacturer usage description file. This memo specifies "v1" of that file. It should be pointout that later versions may not use XML at all. "model" represents a device model as the manufacturer wishes to represent it. It could be a brand name or something more specific. "dev-rev" provides a means to indicate what version the product is. Specifically if it has been updated in the field, this is the place where evidence of that update would appear. Once again, the field is opaque. From a controller standpoint, therefore, only comparison and matching operations are safe. Processing of this URI occurs as specified in [RFC2818] and [RFC3986]. 5. The MUD YANG Model <CODE BEGINS>file "ietf-mud.yang"; module ietf-mud { yang-version 1; namespace "urn:ietf:params:xml:ns:yang:ietf-mud"; prefix "ietf-mud"; import ietf-access-control-list { Lear Expires July 25, 2016 [Page 5] Internet-Draft MUD YANG Model January 2016 prefix "acl"; } import ietf-yang-types { prefix "yang"; } import ietf-inet-types { prefix "inet"; } organization "Cisco Systems, Inc."; contact "Eliot Lear lear@cisco.com "; description "This YANG module defines a component that augments the IETF description of an access list. This specific module focuses on additional filters that include local, model, and same-manufacturer. Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision "2015-12-15" { description "A policy container for manufacturer-driven policy"; reference "RFC XXXX"; } container support-information { description "Information about when support end(ed), and when to refresh"; Lear Expires July 25, 2016 [Page 6] Internet-Draft MUD YANG Model January 2016 leaf last-update { type yang:date-and-time; description "This is intended to be the time and date that the MUD file was generated."; } leaf cache-validity { type uint32; description "The information retrieved from the MUD server is valid for these many hours, after which it should be refreshed."; } leaf is-supported { type boolean; description "The element is currently supported by the manufacturer."; } } augment "/acl:access-lists/acl:acl/" + "acl:access-list-entries/acl:ace/" + "acl:matches" { description "adding manufacturer-driven policy"; leaf manufacturer { type inet:host; description "authority component of the manufacturer URI"; } leaf same-manufacturer { type boolean; description "expand to ACEs for each device with the same origin"; } leaf model { type string; description "specific model for a given manufacturer"; } Lear Expires July 25, 2016 [Page 7] Internet-Draft MUD YANG Model January 2016 leaf local-networks { type empty; description "this string is used to indicate networks considered local in a given environment."; } leaf controller { type inet:uri; description "expands to one or more controllers for a given service that is codified by inet:uri."; } } } <CODE ENDS> 6. Example The example below permits access to devices that are registered with the MUD system of type "http://mfg.example.com/printers". It denies all other access. <?xml version='1.0' encoding='UTF-8'?> <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <access-lists xmlns="urn:ietf:params:xml:ns:yang:ietf-access-control-list" xmlns:ietf-acl-dnsname="urn:ietf:params:xml:ns:yang:ietf-mud"> <acl> <access-list-entries> <ace> <matches> <controller> http://mfg.example.com/printers </controller> </matches> <actions> <permit /> </actions> <rule-name>rule1<rule-name/> </ace> </access-list-entries> <acl-name>sample-mud-acl<acl-name/> <acl-type>ipv4-acl<acl-type/> </acl> </access-lists> </data> Lear Expires July 25, 2016 [Page 8] Internet-Draft MUD YANG Model January 2016 7. Security Considerations Based on the means a URI is procurred, a device may be able to lie about what it is, thus gaining additional network access. This will occur when it makes use of primitives such as "manufacturer" for the purpose of accessing devices of a particular type. Depending on the sophistication of the attack it will be easier or harder to detect. Network management systems SHOULD NOT deploy a usage description for a a device with the same MAC address that has indicated a change of authority without some additional validation (such as review of the class). New devices that present some form of unauthenticated MUD URI SHOULD be validated by some external means when they would be otherwise be given increased network access. It may be possible for a rogue manufacturer to inappropriately exercise the MUD file parser, in order to exploit a vulnerability. There are two recommended approaches to address this threat. The first is to have a system do a primary scan of the file to ensure that it is both parseable and believable at some level. MUD files will likely be relatively small, to start with. The number of ACEs used by any given device should be relatively small as well. Second, it may be useful to limit retrieval of MUD URIs to only those sites that are known to have decent web reputations. 8. IANA Considerations This memo will make a request of IANA for the URI suffix of ".mud". Specification to follow. 9. Acknowledgments The author would like to thank Einar Nilsen-Nygaard for his valuable advice. The numerous remaining errors in this work are entirely the responsibility of the author. 10. References 10.1. Normative References [I-D.ietf-netmod-acl-model] Bogdanovic, D., Koushik, K., Huang, L., and D. Blair, "Network Access Control List (ACL) YANG Data Model", draft-ietf-netmod-acl-model-06 (work in progress), December 2015. Lear Expires July 25, 2016 [Page 9] Internet-Draft MUD YANG Model January 2016 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/ RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>. [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, <http://www.rfc-editor.org/info/rfc3986>. [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <http://www.rfc-editor.org/info/rfc6020>. 10.2. Informative References [I-D.lear-mud-framework] Lear, E., "Manufacturer Usage Description Framework", draft-lear-mud-framework-00 (work in progress), January 2016. Author's Address Eliot Lear Cisco Systems Richtistrasse 7 Wallisellen CH-8304 Switzerland Phone: +41 44 878 9200 Email: lear@cisco.com Lear Expires July 25, 2016 [Page 10]