idnits 2.17.1 draft-lear-mud-framework-00.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 date (January 21, 2016) is 2990 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-01 -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Lear 3 Internet-Draft Cisco Systems 4 Intended status: Informational January 21, 2016 5 Expires: July 24, 2016 7 Manufacturer Usage Description Framework 8 draft-lear-mud-framework-00 10 Abstract 12 A key presumption of the Internet architecture has been that devices 13 are general purpose computers. By constraining the set of devices 14 that connect to the Internet to non-general purpose devices, we can 15 introduce a set of network capabilities that provides an additional 16 layer of protection to those devices. One such capability is the 17 Manufacturer Usage Description (MUD). This work builds on many 18 existing network capabilities so as to be easily deployable by all 19 involved. The focus of this work is primarily, but not exclusively, 20 in the realm of security; and again primarily, but not exclusively, 21 relating to smart objects. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on July 24, 2016. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. A Simple Example . . . . . . . . . . . . . . . . . . . . 3 59 1.2. Determining Intended Use . . . . . . . . . . . . . . . . 4 60 1.3. Types of Policies . . . . . . . . . . . . . . . . . . . . 5 61 2. The Manufacturer Usage Description Architecture . . . . . . . 6 62 2.1. What does a MUD URI look like? . . . . . . . . . . . . . 7 63 2.2. Communicating to the Manufacturer . . . . . . . . . . . . 7 64 2.3. Using YANG-based XML . . . . . . . . . . . . . . . . . . 7 65 2.4. Instantiating Policy . . . . . . . . . . . . . . . . . . 8 66 2.5. When Configuration Can't Change . . . . . . . . . . . . . 8 67 3. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 9 68 3.1. Relationship to ANIMA . . . . . . . . . . . . . . . . . . 9 69 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 71 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 72 7. Informative References . . . . . . . . . . . . . . . . . . . 10 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Introduction 77 The Internet has largely been constructed on general purpose 78 computers; those devices that may be used for a purpose that is 79 specified by those who buy the device. [RFC1984] presumed that an 80 end device would be most capable of protecting itself. This made 81 sense when the typical device was a workstation or a mainframe, and 82 it continues to make sense for general purpose computing devices 83 today, including laptops, smart phones, and tablets. 85 [RFC7452] discusses design patterns for, and poses questions about, 86 smart objects. Let us then posit a group of objects that are 87 specifically not general purpose computers. These devices therefore 88 have a purpose to their use. By definition, therefore, all other 89 purposes are NOT intended. The combination of these two statements 90 can be restated as a manufacturer usage description (MUD) that can be 91 applied at various points within a network. Although this memo may 92 seem to stress access requirements, usage intent also consists of 93 quality of service needs a device may have. 95 We use the notion of "manufacturer" loosely in this context, to 96 simply mean the entity or organization that will state how a device 97 is intended to be used. In the context of a lightbulb, this might 98 indeed be the lightbulb manufacturer. In the context of a smarter 99 device that has a built in Linux stack, it might be integrator of 100 that device. The key points are that the device itself is expected 101 to serve a limited purpose, and that there may exist an organization 102 in the supply chain of that device that will take responsibility for 103 informing the network about that purpose. 105 The converse statement holds that general computing systems will 106 benefit very little from MUD, as their manufacturers cannot envision 107 a specific communication pattern to describe. 109 The intent of MUD is to therefore solve for the following problems: 111 o Substantially reduce the threat surface on a device entering a 112 network to those communications intended by the manufacturer. 114 o Provide for a means to scale network policies to the ever- 115 increasing number types of devices in the network. 117 o Provide a means to address at least some vulnerabilities in a way 118 that is faster than it might take to update systems. This will be 119 particularly true for systems that are no longer supported by 120 their manufacturer. 122 o Keep the cost of implementation of such a system to the bare 123 minimum. 125 No matter how good a MUD-enabled network is, it will never replace 126 the need for manufacturers to patch vulnerabilities. It may, 127 however, provide network administrators with some additional 128 protection when those vulnerabilities exist. 130 1.1. A Simple Example 132 A light bulb is intended to light a room. It may be remotely 133 controlled through the network; and it may make use of a rendezvous 134 service of some form that an app on smart phone accesses. What we 135 can say about that light bulb, then, is that all other network access 136 is unwanted. It will not contact a news service, nor speak to the 137 refrigerator, and it has no need of a printer or other devices. It 138 has no Facebook friends. Therefore, an access list applied to it 139 that states that it will only connect to the single rendezvous 140 service will not impede the light bulb in performing its function, 141 while at the same time allowing the network to provide both it and 142 other devices an additional layer of protection. 144 1.2. Determining Intended Use 146 The notion of intended use is in itself not new. Network 147 administrators apply access lists every day to allow for only such 148 use. This notion of white listing was well described by Chapman and 149 Zwicky in [FW95]. Programmatically profiling systems have existed 150 for years as well. These systems make use of heuristics that take at 151 least some time to assert what a system is. 153 A system could just as easily tell the network what sort of 154 protection it requires without going into what sort of system it is. 155 This would, in effect, be the converse of [RFC7488]. In seeking a 156 general purpose solution, however, we assume that a device has so few 157 capabilities that it will implement the least necessary capabilities 158 to function properly. This is a basic economic constraint. Unless 159 the network would refuse access to such a device, its developers 160 would have no reason to implement such an approach. To date, such an 161 assertion has held true. 163 If the network does not apply heuristics and a device is not capable 164 of articulating what it needs from the network, perhaps there is a 165 third approach that builds on capabilities already in both. There 166 are four such potential capabilities for the network to determine 167 what sort of client it has: 169 1. For those devices that are meant to operate in a secure 170 environment [IEEE8021X] and [IEEE8021AR] provides a means for 171 certificate-based device identification. 173 2. In the absense of DHCP in IPv6 (e.g., stateless address 174 selection), [IEEE8021AB] can be used to learn the same 175 information. 177 3. In the IP network context, every device needs an IP address. 178 [RFC2131] specifies the dynamic host configuraiton protocol, 179 necessary for all IPv4 and IPv6 implementations. Client use of a 180 DHCP option would inform the network of what the device thinks it 181 is, and provide a pointer to additional policy information. 183 4. Finally, for equipment that does not emit any information, it is 184 possible for the access switch to proxy the information into the 185 system. 187 With these capabilities, a device may impart some piece of 188 information to the network. In the immortal words of David John 189 Wheeler, "All problems in computer science can be solved by another 190 level of indirection, except of course for the problem of too many 191 indirections." Our means of providing this level of indirection is a 192 Universal Resource Identifier (URI) [RFC3986] that references a file 193 put in place by someone who knows something about the device - the 194 manufacturer. As we will later discuss, we can later relax whether 195 it is indeed the manufacturer who is specifying the URI. 197 With a simple resolution of a URI, a file is retrieved. We are now 198 to the point in the discussion where we have to decide how the 199 manufacturer expresses intent. We have already stated that Things 200 themselves have limited capabilities. Let us also assume that we in 201 the networking business wish to stand on the shoulders of giants and 202 also not reinvent the wheel. While such a wheel is not _perfectly_ 203 rounded for our purposes, YANG models [RFC6020] and their derivative 204 XML provide sufficient richness for the manufacturer to clearly state 205 at least simple intent. They are thus our starting point. 207 1.3. Types of Policies 209 Once we know how to determine intended use and who can determine it, 210 there is still the question of what that sort of policies can in fact 211 be intended. At least initially, we envision that as a beginning 212 host-level access policies. The manufacturer may specify either 213 specific hosts or certain classes. An example of a class might be 214 "devices of a specified manufacturer type", where the manufacturer 215 type itself is indicated simply by the authority of the MUD-URI. 216 Another example might to allow or disallow local access. Just like 217 other policies, these may be combined. For example: 219 Allow access to host controller.example.com with QoS AF11 220 Allow access to devices of the same manufacturer 221 Allow access to and from controllers who need to speak COAP 222 Allow access to local DNS/DHCP 223 Deny all other access 225 To add a bit more depth that should not be a stretch of anyone's 226 imagination, one could also make use of port-based access lists. 227 Thus a printer might have a description that states: 229 Allow access for port IPP or port LPD 230 Allow local access for port HTTP 231 Deny all other access 233 In this way anyone can print to the printer, but local access would 234 be required for the management interface. 236 Other non-access policies may be possible as well. For instance, 237 suppose a manufacturer is able to make use of an authentication 238 infrastructure. That could be specified in the usage description 239 such that the details could be filled in by the controller. In 240 addition, QoS policies are sufficiently mature and ubiquitous as to 241 be valuable in this context as well. And so for instance, for voice/ 242 video services: 244 Set QoS AF13 to SIP-GW.EXAMPLE.COM 246 The converse highlights a design consideration: policies that are 247 articulated by the manufacturer must be ubiquitously understood, or 248 they may not be applied. That is- applying half a policy is not 249 safe. 251 2. The Manufacturer Usage Description Architecture 253 With these components laid out we now have the basis for an 254 archicture. This leads us to ASCII art. 256 ......................................... 257 . ____________ . __________ 258 . | Network | . | | 259 . | Management |----->get URI->| MFG | 260 . | System | . | Web Site | 261 . End system network |____________|<--MUD file<--<|__________| 262 . . . 263 . . . 264 . _______ _________ . 265 .| | | router | . 266 .| Thing |---->MUD URI-->| or | . 267 .|_______| | switch | . 268 . |_________| . 269 ......................................... 271 Figure 1: MUD Architecture 273 In the above diagram, the switch or router collects MUD URIs and 274 forwards them to the network management system for processing. This 275 happens in different ways, depending on how the URI is communicated. 276 For instance, in the case of DHCP, the DHCP server might receive the 277 URI and then process it. In the case of IEEE 802.1X, the switch 278 would tunnel the URI to the authentication server, who would then 279 process it. 281 The information returned by the web site is valid for the duration of 282 the device's connection, or as specified in the description. Thus if 283 the device is mobile, when it moves on, any configuration in the 284 switch is removed. Similarly, from time to time the description may 285 be refreshed, based on new capabilities or communication patterns or 286 vulnerabilities. 288 The web site is run by or on behalf of the manufacturer. Its domain 289 name is that of the authority found in the MUD URI. For legacy cases 290 where Things cannot emit a URI, if the switch is able to determine 291 the appropriate URI, it may proxy it, the trivial cases being a map 292 between some registered device or port and a URI. 294 2.1. What does a MUD URI look like? 296 To begin with, MUD takes full advantage of both the https: scheme and 297 the use of .well-known. HTTPS is important in this case because men 298 in the middle could otherwise harm the operation of a class of 299 devices. .well-known is used because we wish to add additional 300 structure to the URI. And so the URI is specified in draft-lear- 301 netmod-mud-pre0. It looks like this: 303 https://manufacturer.example.com/.well-known/mud/v1/model/version#extra 305 "model" represents a device model as the manufacturer wishes to 306 represent it. It could be a brand name or something more specific. 307 "version" provides a means to indicate what version the product is. 308 Specifically if it has been updated in the field, this is the place 309 where evidence of that update would appear. Once again, the field is 310 opaque. From a controller standpoint, therefore, only comparison and 311 matching operations are safe. 313 2.2. Communicating to the Manufacturer 315 We assume that the the manufacturer has at its disposal a web service 316 running atop port 443 with standard HTTPS semantics, and that its 317 capabilities are at par with today's web servers. We further assume 318 that this web server has no semantic understanding itself of MUD. 319 This poses us a particular challenge: either we are to cast in stone 320 the model that is put in place, or we must find a mechanism by which 321 the switch or its controller can choose an appropriate set of 322 capabilities. 324 2.3. Using YANG-based XML 326 Because NETCONF is well distributed within network infrastructure and 327 YANG has become the accepted way to generate schema for NETCONF, 328 these we attempt to adapt the protocol and the modeling language, 329 respectively. At some point in the near future, it will likely be 330 the case that XML gives way to JSON[RFC7159]. YANG can be used for 331 either, and so it seems even more appropriate to make good use of it. 332 This work makes use of XML because of the breadth of toolsets 333 available, and not for any love of angle brackets. That is subject 334 to change. 336 The descriptions specified in MUD files should be based on relatively 337 ubiquitous network capabilities. Access lists are such an example, 338 and QoS policies follow closely behind. For security purposes, these 339 policies must only apply to the device that is connecting, and should 340 not modify other parts of a network element's configuration. The key 341 scaling properties here are as follows: 343 o A manufacturer should only have to maintain and distributer one 344 file per device model. 346 o A network management system need not retrieve that same file when 347 the same model appears in multiple places in its network. 349 o Updates should occur at periods specified by the manufacturer to 350 manage load. 352 2.4. Instantiating Policy 354 The network management system receiving the MUD file must convert it 355 into an access list that a network element understands, and apply it 356 to an appropriate interface, limiting its applicability only to the 357 device in question. In some cases, the policies will be abstract. 358 For example, "local" would be translated to the set of networks that 359 are within the same administrative domain. It is the network 360 management system's responsibility to see that the configuration is 361 removed when the device detaches, and that the configuration is 362 consistent with other policies that might apply to that device. 363 Importantly, network management systems should always defer to the 364 network administrator's wishes. As such, a conflicting policy should 365 not be deployed, but rather logged. 367 Human interaction may be required in some cases. In the home, one 368 could imagine description simply being instantiated, whereas in the 369 enterprise, someone may need to review the description before it is 370 applied. 372 It is distinctly possible that a highly advanced enterprise would 373 ignore any manufacturer recommendations altogether but still use the 374 URI received from devices as a classifier. 376 2.5. When Configuration Can't Change 378 In some environments it may not be possible for policy reasons to 379 make changes to network elements to instantiate usage descriptions as 380 a means of enforcement. These very same descriptions may be used as 381 a means to audit activity of a device to determine whether or not it 382 is acting in accordance with the the manufacturer's intent. 384 3. Related Work 386 3.1. Relationship to ANIMA 388 [I-D.ietf-anima-bootstrapping-keyinfra] specifies a means by which a 389 device is configured with appropriate credentials for a given 390 network. This work specifies a means to configure the network rather 391 than the device. In fact, one key assumption of MUD is that it will 392 be extremely painful to make any end system changes. 394 4. Security Considerations 396 The three mentioned means for a device to emit a MUD URI each have 397 their own security properties, and will be discussed in separate 398 drafts. A risk they share in common, however, is that the URI could 399 point to to a site that contains malware. To avoid such problems, 400 several countermeasures are suggested: 402 o All XML should be well formed and validated against appropriate 403 schema. 405 o Only XML whose capability name spaces are known should be 406 processed at all. 408 o Any names within the XML (such as access-list or ACE names) should 409 be replaced with local instances, so as to avoid overwriting 410 existing configuration. 412 o Controllers are encouraged to validate the reputation of the 413 authority of the web site. 415 By emitting a URI the device may identify itself to an interloper. 416 As it happens, most devices can be relatively easily fingerprinted 417 based on their communications patterns. However, if this is of 418 concern, devices should emit the URI to network controllers over 419 secure channels. 421 Use of certain operations, such as SameManufacturer scale less well 422 than others. Frequent connects and disconnects could cause 423 configuration storms. To address this risk, as the number of changes 424 increase, modifications to devices other than the one connecting 425 should decrease or simply be scheduled. In as much as this is an 426 attack, it can also be mitigated through device authorization 427 mechanisms such as 802.1X. 429 5. IANA Considerations 431 The IANA is requested to enjoy a coffee or tea, as there is nothing 432 in this document that otherwise requires their attention. 434 6. Acknowledgments 436 The author thanks Bernie Volz, Eric Vyncke, and Cullen Jennings for 437 their helpful suggestions. 439 7. Informative References 441 [FW95] Chapman, D. and E. Zwicky, "Building Internet Firewalls", 442 January 1995. 444 [I-D.ietf-anima-bootstrapping-keyinfra] 445 Pritikin, M., Richardson, M., Behringer, M., and S. 446 Bjarnason, "Bootstrapping Key Infrastructures", draft- 447 ietf-anima-bootstrapping-keyinfra-01 (work in progress), 448 October 2015. 450 [IEEE8021AB] 451 Institute for Electrical and Electronics Engineers, "Link 452 Layer Discovery Protocol", 2005. 454 [IEEE8021AR] 455 Institute for Electrical and Electronics Engineers, 456 "Secure Device Identity", 1998. 458 [IEEE8021X] 459 Institute for Electrical and Electronics Engineers, "Port 460 Based Network Access Control", 1998. 462 [RFC1984] IAB and , "IAB and IESG Statement on Cryptographic 463 Technology and the Internet", BCP 200, RFC 1984, DOI 464 10.17487/RFC1984, August 1996, 465 . 467 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 468 2131, DOI 10.17487/RFC2131, March 1997, 469 . 471 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 472 Resource Identifier (URI): Generic Syntax", STD 66, RFC 473 3986, DOI 10.17487/RFC3986, January 2005, 474 . 476 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 477 the Network Configuration Protocol (NETCONF)", RFC 6020, 478 DOI 10.17487/RFC6020, October 2010, 479 . 481 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 482 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 483 2014, . 485 [RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, 486 "Architectural Considerations in Smart Object Networking", 487 RFC 7452, DOI 10.17487/RFC7452, March 2015, 488 . 490 [RFC7488] Boucadair, M., Penno, R., Wing, D., Patil, P., and T. 491 Reddy, "Port Control Protocol (PCP) Server Selection", RFC 492 7488, DOI 10.17487/RFC7488, March 2015, 493 . 495 Author's Address 497 Eliot Lear 498 Cisco Systems 499 Richtistrasse 7 500 Wallisellen CH-8304 501 Switzerland 503 Phone: +41 44 878 9200 504 Email: lear@cisco.com