idnits 2.17.1 draft-lear-ietf-dhc-mud-option-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (February 29, 2016) is 2978 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-04) exists of draft-lear-ietf-netmod-mud-00 ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-21) exists of draft-ietf-dhc-sedhcpv6-10 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC E. Lear 3 Internet-Draft R. Droms 4 Intended status: Standards Track Cisco Systems 5 Expires: September 1, 2016 February 29, 2016 7 Manufacturer Usage Description URI and DHCP Option 8 draft-lear-ietf-dhc-mud-option-01 10 Abstract 12 The ability of smart objects to protect themselves will vary. A good 13 source of information about a device's capabilities is the 14 manufacturer. This document specifies a means by which devices can 15 communicate a URI that the network can use to retrieve simple 16 network-relevant information. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 1, 2016. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. The MUD URI DHCP Option . . . . . . . . . . . . . . . . . . . 3 54 3. How the Option Is Processed . . . . . . . . . . . . . . . . . 3 55 3.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 3 56 3.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 4 57 3.3. Relay Requirements . . . . . . . . . . . . . . . . . . . 4 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 63 7.2. Informative References . . . . . . . . . . . . . . . . . 6 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 A Manufacturer Usage Description (mud) refers to a YANG-based XML 69 file that is intended for use by a management station or controller, 70 but is very close to directly parsable by a NETCONF-enabled 71 device.[RFC6020],[RFC6241]. The basic concept is that a device will 72 emit a uniform resource identifier (URI) [RFC3986] that is associated 73 with that file, and the network may do various things with that 74 knowledge, including apply access lists or quality of service 75 policies. A complete overview of MUD can be found in 76 [I-D.lear-mud-framework]. 78 In this memo a single means is defined to emit the MUD URI, which is 79 a DHCP option[RFC2131],[RFC3315] that the DHCP client uses to inform 80 the DHCP server. The DHCP server may take further actions, such as 81 retrieve the URI or otherwise pass it along to network management 82 system or controller. 84 The format of the mud URI is specified in [I-D.lear-ietf-netmod-mud]. 86 An example would be as follows: 88 https://www.vendor.example.com/.well-known/mud/v1/BudsLight/m2000 90 Figure 1: URI example 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 2. The MUD URI DHCP Option 98 The IPv4 MUD URI client option has the following format: 100 +------+-----+------------------------------ 101 | code | len | MUD URI 102 +------+-----+------------------------------ 104 Code OPTION_MUD_URI_V4 (TBD) is assigned by IANA. len is a single 105 octet that indicates the length of the URI in octets. MUD URI is a 106 URI. The length of a MUD URI does not exceed 255 bytes. 108 The IPv6 MUD URI client option has the following format: 110 0 1 2 3 111 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | OPTION_MUD_URI_V6 | option-length | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | MUD URI | 116 | ... | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 OPTION_MUD_URI_V6 (TBD; assigned by IANA). 121 option-length contains the length of the URI in octets. The length 122 MUST NOT exceed 255 octets. 124 The MUD URI is a URI. 126 3. How the Option Is Processed 128 The intent of this option is to provide both a new classifier to the 129 network as well as some recommended configuration to the routers that 130 implement policy. However, it is entirely the purview of the network 131 system as managed by the network administrator to decide what to do 132 with this information. The key function of this option is simply to 133 identify the type of device to the network in a structured way such 134 that the policy can be easily found with existing toolsets. 136 3.1. Client Behavior 138 A client MAY emit a DHCP v4 or DHCPv6 option or both. This is a 139 singleton option, as specified in [RFC7227]. Because clients are 140 intended to have at most one MUD URI associated with them, they may 141 emit at most one MUD URI option via DHCPv4 and one MUD URI option via 142 DHCPv6. In the case where both v4 and v6 DHCP options are emitted, 143 the same URI MUST be used. 145 Clients SHOULD log or otherwise report improper acknowledgments from 146 servers, but they MUST NOT modify their MUD URI configuration based 147 on a server's response. The server's response is only an 148 acknowledgment that the server has processed the option, and promises 149 no specific network behavior to the client. In particular, it may 150 not be possible for the server to retrieve the file associated with 151 the MUD URI, or the local network administration may not wish to use 152 the usage description. Neither of these situations should be 153 considered in any way exceptional. 155 3.2. Server Behavior 157 DHCP servers MAY ignore or process the option. For purposes of 158 debugging, if a server successfully parses the option and the URI, it 159 MUST return the option with the same URI as an acknowledgment. Even 160 in this circumstance, no specific network behavior is guaranteed. 161 When a server consumes this option, it will either forward the URI 162 and relevant client information to a network management system (such 163 as the giaddr), or it will retrieve the usage description by 164 resolving the URI. 166 DHCP servers may implement MUD functionality themselves or they may 167 pass along appropriate information to a network management system or 168 controller. The server that does process the MUD URI MUST adhere to 169 the process specified in [RFC2818] and [RFC5280] to validate the TLS 170 certificate of the web server hosting the MUD file. Those servers 171 will retrieve the file, process it, create and install the necessary 172 configuration on the relevant gateway. Servers SHOULD monitor the 173 gateway for state changes on a given interface. DHCP servers that 174 are NOT providing MUD functionality themselves will forward to the 175 network management system(s) that are any RELEASEs they receive for 176 any DHCPREQUESTs that they previously processed, so that the network 177 management systems may then retire any lingering state. 179 3.3. Relay Requirements 181 There are no additional requirements for relays. 183 4. Security Considerations 185 Emission of a MUD URI will provide an interloper with knowledge about 186 a device. However, an interloper may gain most of this same 187 information through classical fingerprinting techniques. That is, 188 device behavior patterns are generally easy to determine. In 189 environments where this would be a concern, use of devices with this 190 option is NOT RECOMMENDED. Instead other more secure means should be 191 considered. 193 It may be possible for a man in the middle to modify the DHCP request 194 so that a different URI is queried. To address this threat, 195 controllers SHOULD NOT query a site based on the authority component 196 of the MUD URI when it has noted that the authority section has 197 changed. For example, if the MAC address is the same and the 198 authority portion of the URI is different from the last query, 199 something probably has gone wrong. Such a situation SHOULD be logged 200 and reported. As of this writing, one of the authors is aware of 201 ongoing work to address DHCP message integrity 202 protection[I-D.ietf-dhc-sedhcpv6]. 204 A malicious device could emit a URI to malware. Servers or other 205 network management systems should only process valid MUD URIs, and 206 MUST apply strict validation rules to the content that is returned, 207 making use of the Accept: header, and rejecting any content that does 208 not have an acceptable type. In addition, servers MAY ignore URIs to 209 unknown manufacturers. In order to prevent modification of content 210 in flight, all communication to web sites MUST make use of TLS, and 211 all certificates MUST be validated. 213 5. IANA Considerations 215 IANA is requested to allocated the DHCPv4 and v6 options as specified 216 in Section 2. 218 6. Acknowledgments 220 The authors thank Bernie Volz for his helpful suggestions. 222 7. References 224 7.1. Normative References 226 [I-D.lear-ietf-netmod-mud] 227 Lear, E., "Manufacturer Usage Description YANG Model", 228 draft-lear-ietf-netmod-mud-00 (work in progress), January 229 2016. 231 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 232 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 233 RFC2119, March 1997, 234 . 236 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 237 2131, DOI 10.17487/RFC2131, March 1997, 238 . 240 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/ 241 RFC2818, May 2000, 242 . 244 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 245 C., and M. Carney, "Dynamic Host Configuration Protocol 246 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 247 2003, . 249 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 250 Resource Identifier (URI): Generic Syntax", STD 66, RFC 251 3986, DOI 10.17487/RFC3986, January 2005, 252 . 254 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 255 Housley, R., and W. Polk, "Internet X.509 Public Key 256 Infrastructure Certificate and Certificate Revocation List 257 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 258 . 260 7.2. Informative References 262 [I-D.ietf-dhc-sedhcpv6] 263 Jiang, S., Li, L., Cui, Y., Jinmei, T., Lemon, T., and D. 264 Zhang, "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-10 (work 265 in progress), December 2015. 267 [I-D.lear-mud-framework] 268 Lear, E., "Manufacturer Usage Description Framework", 269 draft-lear-mud-framework-00 (work in progress), January 270 2016. 272 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 273 the Network Configuration Protocol (NETCONF)", RFC 6020, 274 DOI 10.17487/RFC6020, October 2010, 275 . 277 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 278 and A. Bierman, Ed., "Network Configuration Protocol 279 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 280 . 282 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 283 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 284 BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, 285 . 287 Authors' Addresses 289 Eliot Lear 290 Cisco Systems 291 Richtistrasse 7 292 Wallisellen CH-8304 293 Switzerland 295 Phone: +41 44 878 9200 296 Email: lear@cisco.com 298 Ralph Droms 299 Cisco Systems 300 55 Cambridge Parkway 301 Cambridge 1057 302 United States 304 Phone: +1 617 621 1904 305 Email: rdroms@cisco.com