idnits 2.17.1 draft-srich-opsawg-mud-manu-lifecycle-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 : ---------------------------------------------------------------------------- ** There are 18 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 504: '...imate MUD File. A manufacturer SHOULD...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (27 March 2017) is 2586 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Manufacturer' is mentioned on line 227, but not defined == Missing Reference: 'Customer' is mentioned on line 227, but not defined == Unused Reference: 'WEIS2017' is defined on line 524, but no explicit reference was found in the text == Unused Reference: 'RFC2882' is defined on line 542, but no explicit reference was found in the text == Outdated reference: A later version (-25) exists of draft-ietf-opsawg-mud-03 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Operations and Management Area Work Group S. Rich 3 Internet-Draft Cisco Systems 4 Intended status: Informational 5 Expires: September 27, 2017 T. Dahm 6 Google 7 27 March 2017 9 MUD Lifecyle: A Manufacturer's Perspective 10 draft-srich-opsawg-mud-manu-lifecycle-01.txt 12 Abstract 14 Manufacturer Usage Descriptions, or MUDs, allow a manufacturer to 15 cheaply and simply describe to the network the accesses required 16 by an IoT device without adding any extra cost or software to the 17 devices themselves. By doing so, the network infrastructure 18 devices can apply access policies automatically which increase the 19 overall security of the entire network, not just for the IoT 20 devices themselves. This document describes the lifecycle of 21 Manufacturer Usage Descriptions (MUDs) by describing detailed MUD 22 scenarios from the perspective of device manufacturers. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current 32 Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six 35 months and may be updated, replaced, or obsoleted by other 36 documents at any time. It is inappropriate to use Internet-Drafts 37 as reference material or to cite them other than as "work in 38 progress." 40 This Internet-Draft will expire on September 27, 2017. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with 52 respect to this document. Code Components extracted from this 53 document must include Simplified BSD License text as described in 54 Section 4.e of the Trust Legal Provisions and are provided without 55 warranty as described in the Simplified BSD License. 57 1. Introduction 59 The addition of IoT devices to a network expands the attack 60 surface of that network. Even if a device does not have 61 exploitable vulnerabilities (in the sense of an attacker injecting 62 and running malware on it), it may be susceptible to denial-of- 63 service (DoS) attacks and thus could have its functionality 64 impaired by attackers. Recent events have shown just how real, 65 and not just theoretical, such attacks can be. 67 A detailed summary of the current state of understanding of the 68 Mirai botnet's use of IoT devices can be found in [MIRAI]. It is 69 estimated that around 100,000 IoT devices generated more than a 70 terabit per second of DDoS traffic. 72 Also consider the Sony Cameras IP Security article [SONYCAMS] 73 which describes a vulnerability in many camera models which could 74 be exploited to launch attacks like those seen in the massive DDoS 75 attack on DynDNS in [DynDNS]. As both of these incidents show, 76 more network-accessible devices which can connect to arbitrary 77 external addresses can, if those devices permit too much access or 78 if they have vulnerabilities which allow arbitrary code execution, 79 be used by attackers to amplify attacks and to do so by using 80 origin addresses spanning broad ranges of networks. 82 Concerns about the negative possibilities of attacks related to 83 IoT devices is also discussed in [MITTECH] that also discusses 84 some of the regulatory and government angles in play. In a recent 85 move described in [USGSUIT], the U.S. Federal Government has taken 86 the step of suing D-Link, accusing it of ``poor security 87 practices'' for some of its IoT devices. 89 MUD provides a light-weight model of achieving very effective 90 baseline security for IoT devices by simply allowing a network to 91 automatically configure the required network access for IoT 92 devices so that they can perform their intended functions without 93 granting them gratuitous, unrestricted network privilege. 95 2. MUD High-level Introduction 97 Manufacturer Usage Descriptions (MUDs) provide advice to end 98 networks on how to treat specific classes of devices. The MUD 99 architecture is explained in [LEAR2017], but we will describe it 100 briefly here and also discuss details where necessary to 101 understand this document. At its most basic, MUD is a system by 102 which the IoT device itself tells the network exactly how to 103 retrieve its network access requirements (in a ``MUD File'', which 104 is the term used in the MUD specification to refer to the file 105 which contains the description of an IoT device's network access 106 requirements), and network infrastructure can fetch and act upon 107 this information. The MUD File itself is a static text file which 108 the network infrastructure element responsible for it can retrieve 109 from the manufacturer or from whomever the manufacturer delegates 110 the responsibility to. The MUD file may be cached, so when 111 served, the MUD file should be returned with a ``max-age'' value 112 which lets the requestor know how long it can cache it. 114 To add MUD support to an IoT device is a very minimal change: add 115 the URL for the MUD File as the ``MUD URI'' to whatever dynamic 116 network registration protocol which is currently being used by the 117 device (e.g. DHCP, etc.). It is so simple that the device 118 manufacturer can statically compile the URI into the firmware of 119 the device. The essential point is that MUD does not force a 120 large behavioral change on the IoT device itself, and the serving 121 up of the MUD file during the lifetime of the devices is similarly 122 relatively low-impact. The bulk of the complexity of MUD is 123 concentrated within the network elements which perform operations 124 to retrieve the MUD files, possibly cache them, and then configure 125 the network in response, but even there, the network elements 126 effected mostly already perform all of these actions, albeit not 127 automatically in most cases. 129 For this description, one can consider three general classes of 130 actors in the MUD ecosystem: 132 o Device manufacturers 134 o Networking equipment manufacturers 135 o Network operators 137 Note that end users are not mentioned here, as their involvement 138 in MUD is minimal at best (and likely only present in the simplest 139 of deployments). Note also that ``Device manufacturers'' are 140 described with the assumption that they will both include MUD URIs 141 within their devices as well as service MUD URL requests (via a 142 cloud service or via their own web infrastructures). It is 143 possible that a manufacturer will delegate the MUD URL retrieval 144 function to a third party. The question of who actually services 145 network requests for the MUD URL is an administrative one and does 146 not affect the MUD architecture. It does give device manufactures 147 more flexibility, though, in managing their investment into the 148 MUD ecosystem. 150 This document will describe the MUD ``lifecycle'' from the 151 standpoint of manufacturers, but it is also intended to be 152 informative to persons interested in standardization, 153 installation, or other areas where MUD may be in play. Where 154 appropriate, suggestions of best practices will be given if there 155 are no specific hard requirements. 157 3. Terminology 159 Before going into descriptions how MUD works, we will list terms 160 used within the MUD ecosystem: 162 MUD 163 Manufacturer Usage Description 165 MUD file 166 a file containing YANG-based JSON that describes a recommended 167 behavior 169 MUD file server 170 an HTTPS server that hosts a MUD file 172 MUD controller 173 the system that requests and receives the MUD file from the MUD 174 server. After it has processed a MUD file it may direct changes 175 to relevant network elements 177 URL 178 Universal Resource Locator 180 URI 181 Universal Resource Identifier. The difference between a ``URI'' 182 and a ``URL'' is that a URI is intended to be used as an 183 identifier in a general sense, whereas a URL is a specific use 184 case of a URI that is used to access something at a particular 185 network location 187 MUD URI 188 a URI that an IoT device carries and which will be issued during 189 operations such as DHCP requests which can be used as a URL to 190 retrieve a MUD file 192 MUD URL 193 the MUD URI being used as a URL 195 IEEE 802.1AR 196 A IEEE specification for a certification-based approach for 197 communicating device characteristics 199 YANG 200 A data modeling language for the definition of data sent over the 201 NETCONF network configuration protocol [RFC6020] 203 NETCONF 204 Network Configuration Protocol [RFC6241] 206 JSON 207 Javascript Object Notation, a human- as well as machine-readable 208 file format containing textual representations of ``objects'' such 209 as strings of characters, numbers, boolean values, and lists and 210 dictionaries of such objects and collections of objects 212 Many of these terms are in common usage with the IETF or other 213 network standards bodies and are thus used for consistency. More 214 information about terms like ``URL'', ``URI'', ``YANG'', and 215 ``NETCONF'' can be found in the standards and references published 216 by the IETF and others. The value in distinguishing ``URI'' and 217 ``URL'' will hopefully become more apparent when MUD file caching 218 is discussed (during which time, already-retrieved MUD files will 219 be used if the URI lookup returns a match). The actual text of a 220 ``MUD URI'' and a ``MUD URL'' will generally be identical; the 221 distinction lies in the use of it by various elements (IoT 222 devices, network devices, and web services). 224 4. MUD Operation 226 +--------------------------+ +------------------------------------------+ 227 | [Manufacturer] | | [Customer] | 228 | ------- | | | 229 | +----->( ) 6 | | +------------+ 7 +----------------+ | 230 | | |-------|<--------| MUD |---->| Network Policy | | 231 | | 2:MUD| |-------->| Controller | | Management | | 232 | | File ( ) | | +------------+ +----------------+ | 233 | | ------- | | ^ | | 234 | | | | 5:MUD | | 8 | 235 | (1:Create Device) | | URI | v | 236 | | | | +-------------+ | 237 | | | | | (Switch) | | 238 +---------|----------------+ | +-------------+ | 239 v | | | | | | | 240 +-------------------+ 3:Buy | 4:Deploy | | | | | | 241 | Distribution ---------->| X X X X X ... | 242 | Channels | | | 243 +-------------------+ +------------------------------------------+ 245 6: MUD URI used as URL to request MUD File 246 7: MUD Controller informs network policy engine about ACLs 247 8: Network policy applied as close to IoT device as possible 249 Figure 1: MUD-related network information flow 251 A full description of MUD is given in [LEAR2017]. In short, when 252 a device such as an IP-enabled lightbulb is connected to the 253 network and given power, that device will perform some action to 254 acquire a network identity, including an IP address, such as by 255 making a DHCP request. If that request has a MUD URI in it, 256 equipment in the network (not necessarily the DHCP server) can use 257 that URI to retrieve the device's MUD file from the MUD file 258 server. Some other networking component (the switch to which the 259 bulb in connected, for example) can then act on the contents of 260 the retrieved MUD file and apply the appropriate configurations to 261 allow the device to function normally while restricting where it 262 can connect. 264 A MUD file's contents will mostly contain descriptions of which 265 protocols are required by the device and over what port or ports. 267 From the perspective of a manufacturer, the essential elements to 268 note are the following: 270 1. On the device itself, the only change required to add MUD 271 compliance/functionality is to add a field populated with a URI to 272 whatever network access protocol is already being used (i.e., 273 DHCP, IPv6 AD, etc.). This will be a static text string which 274 will probably remain constant throughout the life of the product 275 and which is identical for every instance of a product run (i.e., 276 there is no per-serial-number version of the MUD URI) 278 2. The MUD file which is to be returned via an HTTPS server can be a 279 static file and can be reused for devices which have the same 280 network access requirements. The service which returns the MUD 281 file will not be responsible for any security policy enforcement, 282 as that is the job of the network which contains the devices 283 themselves 285 3. MUD files are fairly short (on the order of tens of lines of text) 286 and are thus trivial to serve either directly and are amenable to 287 caching 289 4. The act of retrieving the MUD file and of acting on it is entirely 290 up to the network infrastructure and not a responsibility of the 291 IoT devices themselves. MUD does not impose any behavioral 292 requirements on the IoT devices themselves other than that they 293 must send the MUD URI during network access configuration, as 294 mentioned earlier 296 How does MUD work in practice? Figure 1 shows a representation of 297 the high-level MUD information flow. This document deals almost 298 exclusively with elements in the upper left of that figure. 299 Specifically, it describes what a manufacturer should do to put a 300 MUD file into a device and what is required for a manufacturer (or 301 a designee of the manufacturer) to answer requests for MUD files 302 from network operators whose networks provide connectivity for 303 such devices. 305 5. Device Manufacturer Considerations 307 The device manufacturers have the most insight into what resources 308 the devices will need once they are installed in a network. They 309 are thus best-suited to author the network profiles which will be 310 required by the devices that they make for correct operation. 311 Conversely, each manufacturer cannot know what each network's 312 other requirements happen to be. As a result, the manufactures 313 should provide configuration requirements for their devices which 314 network operators can apply in a way best suited for their 315 networks. The network operator can optimize operations through 316 caching, LAN segregation, etc., and can use the MUD information to 317 further secure the network. 319 If a manufacturer makes many devices which have similar network 320 access requirements, that manufacturer may want to leverage common 321 profiles. They should do so only when the profiles are truly 322 close enough to be treated as the same. 324 Device manufacturers have three responsibilities under MUD: 326 o They must author a MUD profile which describes a device's 327 requirements for network access 329 o They must encode a MUD URI into the device such that when the 330 device performs DHCP or similar 332 o The MUD File must be hosted on a publicly-available web server 334 Since the MUD profiles can be static files, there is very little 335 overhead required to serve these profiles. Due to their static 336 nature, they are inherently cacheable. 338 Similarly, since the URI can be essentially static (the actual 339 device configurations are easily updatable since they are 340 contained in the MUD file, not the URI), the manufacturer can 341 assign a name space and begin encoding the URIs into the devices 342 relatively early in the manufacturing process, including before 343 the MUD specification is finalized. An important point is that 344 manufacturers should adopt and follow a nomenclature that insures 345 that they can sufficiently distinguish classes or families of 346 devices with different requirements and assign them different 347 URIs. From a security standpoint, it is better to have several 348 URIs with more granular security profiles than it is to have a 349 very few URIs with "catch-all" (and thus more open) security 350 profiles. This ensures that a customer using a single family of 351 devices will have the most closed network configuration possible. 353 If the device manufacturer decides to update the profile, then it 354 may do so at any time, independently of updates to the firmware on 355 the devices themselves. If it is expected that a profile may 356 change frequently (say, for a new class of devices which aren't 357 fully understood yet), then the MUD profile for said device should 358 be served with a fairly short max-age (as compared to a device 359 with a well-established network access profile). 361 6. High-level MUD Lifecycle 363 The following lifecycle description is described considering a 364 single device. As additional devices are added to a portfolio, 365 the same steps are taken for each one where necessary. Each step 366 can be isolated or coordinated with other device instances where 367 convenient. There is little coupling inherent in the way that the 368 various phases of MUD deployment operates to impose strict 369 requirements in this area. 371 1. Based on a device's function, a MUD profile is either: 373 o Chosen from a library of existing profiles for similar devices 375 o Written anew to describe this device's network requirements 377 2. If the profile is pre-existing, the a choice is made if this 378 device will receive a new URI or if it should be classed as 379 identical to existing devices and use the same URI 381 3. The chosen URI is assigned to the device so that when the device 382 performs network initialization, the URI is included in the 383 request (i.e., DHCP, ANIMA, etc.) 385 4. In parallel or in advance (but prior to first customer shipment), 386 the device manufacturer should allocate in an appropriate 387 namespace and place the MUD profiles for when the URI is used as a 388 URL. 390 5. The MUD profile should be made available to customers until such a 391 time that the device is unsupported. While it is outside the 392 scope of this document, The manufacturer should support MUD 393 profile retrieval for each device for at least as long as the 394 manufacturer supports the devices themselves. 396 6. If the profile is found to contain an error, the manufacturer 397 should update the profile. Devices which are already deployed 398 will continue to use the original URI (unless a firmware updates 399 changes it), so the original profile should be corrected 401 7. If a device manufacturer chooses to update a MUD-enabled device's 402 firmware, the manufacturer may update the MUD URI to a new one. 403 The manufacturer should change the URI if the network access 404 requirements of the new firmware are sufficiently different from 405 those of the original firmware version. 407 7. MUD URI 409 The MUD URI is a very visible and important part of MUD that is 410 best done correctly from the start, for once it is embedded in an 411 IoT device, changing it for the fielded devices will be, at best, 412 inconvenient. Choosing a scheme for organizing the ``name space'' 413 for the portion of the URI which is controlled by the device 414 manufacturer may have knock-on effects such as the URL GET request 415 routing behavior that must be supported during MUD file retrieval. 417 The format of the URI is: 419 https://authority/.well-known/mud/mud-rev/model 421 where ``mud-rev'' is currently the literal string ``v1'', and may 422 be suffixed with `` ?extras ''. Referencing [RFC3986], the 423 authority element is described by the ``authority'' type, the 424 model element by the ``segment'' type, and extras by the ``query'' 425 type. This gives considerable flexibility to manufacturers to 426 structure their various namespaces to handle a huge variety of 427 device types. However, this document will restrict itself to 428 describing a very simple URI encoding scheme. 430 In the following, we will use ``example.com'' as the authority 431 element. By far, the simplest method of assigning MUD URIs to 432 devices is to assign each distinct model number a URI of the form 434 https://example.com/.well-known/mud/v1/model 436 where the ``model'' element is literally the model number of the 437 device. If a manufacturer has a model number collision problem 438 (possibly because of acquisitions of other companies, for 439 example), a simple scheme of a prefix or a suffix, set off with a 440 hyphen or similar, will suffice to disambiguate them. Since the 441 MUD files are relatively small, there is likely little value in 442 conjuring schemes to save disk space with complicated naming 443 conventions or structure. 445 8. MUD File Serving: Operations, Lifetypes, and Transfer 447 The previous section discussed how one might design the URI 448 namespace for MUD files. Another very important consideration is 449 the total lifecycle of the serving of MUD files via the internet 450 for an appropriate length of time and what to do if one wants to 451 transfer the responsibility of serving MUD files to some other 452 entity. This section will describe several scenarios and suggest 453 options for the transfer of responsibility of MUD files to other 454 providers. There is no single set policy for these various 455 activities, and organizations are free to decide how and when 456 these transfers occur. There are technical considerations that 457 must be dealt with, but this is not unlike outsourcing subsections 458 of one's web site to payment partners or other specialists if so 459 desired. 461 The single largest factor in thinking about serving MUD files 462 throughout their lifetimes is the relative ``permanence'' of the 463 URI itself (since, for some types of devices, at least, the 464 buried-in URI will be essentially indelible). Even if a device 465 has a more fungible MUD URI (say, because it is easily and 466 frequently updated), it is still wise to consider the case when a 467 device's MUD URI cannot be easily updated since this represents 468 the most problematic case. Networks containing the MUD-enabled 469 devices will make network requests to retrieve the MUD files. The 470 MUD URIs are, quite literally, the URLs of the MUD files. There, 471 network infrastructure devices from potentially anywhere on the 472 internet will try to retrieve these MUD files. The volume of 473 requests will be simple to handle (given that MUD files are static 474 and small and that MUD servers in the network will be able to 475 cache them and avoid redundant retrievals). 477 A very simple and direct way to manage MUD files and make the 478 possible future delegation of MUD file serving to a $3^{rd}$-party 479 is to assign a URI DNS ``namespace'' for your company's MUD files. 480 For example, using the fictional company ``Acme Lightbulb and 481 Sensor'' and its web presence at ``https://acmels.com'', the DNS 482 namespace for MUD files could be 483 mud.acmels.com 484 which can serve as the authority section of the MUD URI. If Acme 485 wants to serve the MUD files themselves, then they can provision 486 an HTTPS service that serves that address and return the requested 487 MUD files, or they can create a CNAME to point to the actual 488 entity who will answer the requests. 490 9. Security Considerations 492 The bulk of this document describes the use of MUD to increase the 493 security of a network. However, it is possible to compromise the 494 effectiveness of MUD by attacking its behavior directly. This 495 section discusses the known attacks and describes possible 496 mitigations (all from the manufacturer's perspective). This 497 section also attempts to clarify the limits to which MUD is 498 expected to perform in terms of increasing security. 500 The first and most obvious attack scenario is that a malicious or 501 compromised device can issue a MUD URI which allows that device to 502 communicate too permissively, either by having the URI refer to an 503 unintended file or by simply putting too permissive a set of rules 504 in the otherwise-legitimate MUD File. A manufacturer SHOULD 505 employ secure development best practices to take reasonable steps 506 to insure that their devices behave correctly at least up to the 507 point that they are shipped and that their web services follow all 508 BCPs. 510 Other attacks are not manufacturer-specific and will not be 511 covered in this document. They will instead be discussed in TBD 512 which focuses on the network operator's perspective of MUD. 514 10. IANA Considerations 516 This document has no actions for IANA. 518 11. Normative References 520 [LEAR2017] 521 Lear, E., "Manufacturer Usage Description Specification", draft- 522 ietf-opsawg-mud-03, January 05, 2017 524 [WEIS2017] 525 Weis, B., "RADIUS Extensions for Manufacturer Usage Description", 526 draft-weis-radext-mud-00, October 25, 2016 528 [RFC6020] 529 Bjorklund, M., "YANG - A Data Modeling Language for the Network 530 Configuration Protocol (NETCONF)", IETF RFC 6020, 2010 532 [RFC6241] 533 Enns, R., Bjorklund, M., Schoenwaelder, J. and Bierman, A., 534 "Network Configuration Protocol (NETCONF)", IETF RFC 6241, 2011 536 [RFC3986] 537 Berners-Less, T., Fielding, R., Masinter, L., "Uniform Resource 538 Identifier (URI): Generic Syntax", IETF RFC 3986, 2005 540 12. Informative References 542 [RFC2882] 543 Mitton, D., "Network Access Servers Requirements: Extended RADIUS 544 Practices", RFC2882, July 2000 546 [MIRAI] 547 https://www.flashpoint-intel.com/action-analysis-mirai-botnet- 548 attacks-dyn/ 550 [SONYCAMS] 551 http://www.pcworld.com/article/3147311/security/backdoor-accounts- 552 found-in-80-sony-ip-security-camera-models.html 554 [DynDNS] 555 http://www.pcworld.com/article/3134056/hacking/an-iot-botnet-is- 556 partly-behind-fridays-massive-ddos-attack.html 558 [MITTECH] 559 https://www.technologyreview.com/s/603015/security-experts-warn- 560 congress-that-the-internet-of-things-could-kill-people/ 562 [USGSUIT] 563 https://www.cnet.com/news/d-link-lawsuit-ftc-security-hackers/ 565 Authors' Addresses 567 Steven Rich 568 Cisco Systems, Inc. 569 170 West Tasman Dr. 570 San Jose, CA 95134 572 Email: srich@cisco.com 574 Thorsten Dahm 575 Google Inc. 576 1600 Amphitheatre Parkway 577 Mountain View, CA 94043 579 Email: thorstendlux@google.com