idnits 2.17.1 draft-srich-opsawg-mud-net-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 : ---------------------------------------------------------------------------- ** 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 396: '...ly, the switches MUST remove any dynam...' RFC 2119 keyword, line 455: '...hen a valid MUD File MUST be retrieved...' RFC 2119 keyword, line 486: '...way, any network SHOULD be properly de...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (27 September 2017) is 2400 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2882' is defined on line 535, but no explicit reference was found in the text == Outdated reference: A later version (-25) exists of draft-ietf-opsawg-mud-03 Summary: 1 error (**), 0 flaws (~~), 3 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: March 27, 2017 T. Dahm 6 Google 7 27 September 2017 9 MUD Lifecyle: A Network Operator's Perspective 10 draft-srich-opsawg-mud-net-lifecycle-01.txt 12 Abstract 14 This memo describes the lifecycle of MUD as seen from the 15 perspective of a network operator. It is informational and 16 intended to help provide perspective around the operation of a 17 network which connects MUD-supporting devices and uses MUD- 18 supporting network infrastructure. All phases of network 19 operation that involves or affects MUD will be described. 20 Considerations specific to device manufacturers will be described 21 elsewhere. Considerations relevant to network equipment 22 manufacturers and networking software authors will be described 23 where appropriate where MUD behavior is affected. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current 33 Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six 36 months and may be updated, replaced, or obsoleted by other 37 documents at any time. It is inappropriate to use Internet-Drafts 38 as reference material or to cite them other than as "work in 39 progress." 41 This Internet-Draft will expire on March 27, 2017. 43 Draft MUD Lifecyle: Network Operator 27 September 2017 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with 55 respect to this document. Code Components extracted from this 56 document must include Simplified BSD License text as described in 57 Section 4.e of the Trust Legal Provisions and are provided without 58 warranty as described in the Simplified BSD License. 60 1. MUD Introduction 62 Network architects and operators have the goal of designing and 63 operating networks so that they are reliable, secure, and operate 64 correctly. Making them do so requires that the network permit 65 traffic which is intended to be allowed on the network while 66 rejecting or blocking traffic which is not. Both goals are met 67 with a combination of policies and configurations which promote 68 efficient routing of packets for certain classes of traffic and 69 which rate limit or even block (possibly by black-holing) other 70 classes of unwanted or lower-priority traffic. 72 A common assumption is that devices on the inside of the network 73 can have relatively unrestricted access to other parts of the 74 network and to the local network segment. This is reasonable for 75 devices which themselves have certain configurations which will 76 naturally govern which network access they require. For example, 77 a printer will usually be configured to accept connections from 78 hosts which wish to print to it. The printer itself may not tend 79 to initiate outbound connections and thus does not require a 80 complex set of custom ACLs. If the printer needs external 81 connectivity, the usual scenario is to allow the printer to make 82 outbound connections while still preventing inbound connections 83 using a stateful firewall rule or similar. However, there are 84 often no rules preventing the printer from making arbitrary 85 connections within network delineated by the firewall. 87 Other devices such as general-purpose end-user hosts (PCs, Mac, 88 etc.) might need unrestricted access, at least in the outbound 89 direction, because, contrary to the printer example, end-user 90 hosts are generally expected to make outbound connections to an 91 unpredictable number of hosts. Even if outbound restrictions to 93 Draft MUD Lifecyle: Network Operator 27 September 2017 95 certain ports (such as 80, 443, 22, 25, etc.) are enforced, the 96 destination address may be unrestricted. As stated above, 97 restrictions from internal hosts to internal addresses may be even 98 more lax. 100 Enter into this situation IoT devices which may be introduced to 101 the network in the thousands and which may have unspecified or 102 unclear requirements for network access. For example, IoT light 103 bulbs may need to talk to DNS, NTP, LLDP, DHCP, and a controller 104 on the local network and nothing else. An IoT thermostat may need 105 to talk to DNS, NTP, LLDP, DHCP, and its cloud-based controller, 106 but nothing else. For both of these cases, while their specific 107 requirements vary, knowing each one's requirements would allow a 108 tight set of ACLs to be imposed, all the way to the port level, to 109 limit what connectivity is afforded to each individual instance. 111 Recent examples of IoT-based malware campaigns will not be 112 repeated here and the benefits of providing such security will no 113 doubt be obvious to network operators. What has not been 114 available before MUD is an ability to automatically retrieve 115 configuration policy and then automatically apply it for each 116 device. This document will describe the ``lifecycle'' of MUD from 117 the perspective of a network operator. The details of the 118 protocol and contents of the MUD file itself are described in 119 [LEAR2017], and familiarity with it is assumed for this document. 121 2. Terminology 123 This document will use some terms and abbreviations which will be 124 listed and described in this section. 126 MPD 127 "MUD-Protected Device" - While this is a possibly tedious use of a 128 three-letter acronym, repeated use of "MUD-protected device" or 129 similar is equally tedious 131 AAA Server 132 "Authentication, Authorization, and Accounting Server" - A network 133 service which processes AAA requests 135 ACL 136 "Access Control List" - In the context of this document, an ACL 137 will refer specifically to those which are specified in a MUD file 138 and which get applied at some point in the network to enforce the 139 security policy needed by a device. These ACLs may be configured 140 down the port into which the device the is plugged, and they may 141 be applied "dynamically" in the sense that they appear in response 143 Draft MUD Lifecyle: Network Operator 27 September 2017 145 to the MUD request as opposed to a static configuration. They 146 will not be dynamic in the sense that they change frequently. The 147 actual implementation by any particular vendor is left up to that 148 vendor and thus may differ from the examples given in this 149 document. 151 3. MUD Lifecycle Description for Network Operators 153 The totality of what network operators must do to build, operate, 154 and maintain networks will not be described in exhaustive detail 155 in this document. Instead, we will describe what additional or 156 different things are necessary or recommended when establishing 157 MUD support within the network. Some of the steps discussed will 158 presuppose that networking equipment vendors will have added MUD 159 support to their products. 161 The following high-level tasks are required to support the 162 automatic network configuration aspects of MUD devices on the 163 network: 165 1. Network Segmentation Considerations and Design 167 2. Install and/or enable a MUD Policy Server 169 3. Configure network devices so that they will receive and enforce 170 ACLs generated by the MUD Policy Server 172 4. Test and verify functionality by confirming that MUD files are 173 retrieved and ACLs are applied to the appropriate ports and that 174 those ACLs are removed when the port goes down 176 The MUD Policy Server may support caching retrieved MUD files. If 177 it does, then the operator may choose to enable, tune, test, and 178 monitor this functionality as well. Details about caching MUD 179 files as well as each task above will be covered later in this 180 document. 182 The network equipment to which MPDs connect must be capable of 183 accepting and enabling dynamic ACLs which can preferrably be 184 scoped to a port. While it is conceivable that the ACLs be 185 combined and applied at a point in network that is multiple hops 186 away from the switch to which the MPD connects, the tightest 187 security controls are possible when enforcement can happen 188 directly on the port. This eliminates the possibility that a MPD 189 can talk to other devices on the same switch unless explicitly 190 permitted. The remainder of this document will only discuss the 191 case of using ACLs. 193 Draft MUD Lifecyle: Network Operator 27 September 2017 195 3.1. Network Segmentation Considerations and Design 197 A well-designed network is one which includes the use of 198 segmentation which keeps different parts of the network isolated 199 from each other to the optimimum degree. For example, groups of 200 machines which need to communicate frequently and at high speed 201 most likely should be on the same LAN. Different groups of 202 machines which rarely communicate together can be separated into 203 different routed networks, and depending upon security 204 requirements, may even be guarded by ACLs or other mechanisms. 206 Different network segments may be designed with different 207 expectations of security. Inner-bastion networks may contain 208 sensitive systems which are isolated from all but the most trusted 209 systems. Segments which allow guest users or devices which are 210 less trusted may be relegated to segments which have also been 211 protected with ACLs, but the focus can be on limiting what the 212 devices in the segment can access rather than worrying about what 213 external devices can access inside the segment itself. 215 The goal of MUD is to enable the near-automatic management of 216 device segmentation for the class of devices which have MUD 217 support. To be maximally effective, though, the network designer 218 should take advantage of pre-defining segments into which MUD- 219 capable devices can be grouped by function and by required access. 220 An optimal middle ground (for a large network with many types of 221 MUD-enabled devices) would comprise some device-class-specific 222 segments, some vendor-specific segments, the essential set of 223 network segments (required regardless of MUD for the normal 224 operation), and perhaps a ``default network'' into which untrusted 225 devices are placed which get no internal network access and 226 severely limited internet access. 228 Ideally, with full MUD support in devices deployed in a network, 229 there would be no need for the so-called ``default network'' 230 segment (except perhaps as a ``guest'' network) since MUD profiles 231 would result in a properly-segmented and protected devices. Until 232 MUD is ubiquitously supported, though, it is wise to consider the 233 option. 235 To make these ideas more clear, an example network will be 236 described (at a high level) with various segments defined. The 237 use of each segment by MUD will then be described. These are 238 segments within a larger network which will not be described to 239 avoid cluttering the diagram. 241 Draft MUD Lifecyle: Network Operator 27 September 2017 243 +-------------+---------------------+-----+ 244 |Segment Name | Segment Description | MUD | 245 +-------------+---------------------+-----+ 246 |SecDB | Recorders, IDs | N | 247 +-------------+---------------------+-----+ 248 |Readers | Badge Scanners | Y | 249 +-------------+---------------------+-----+ 250 |Cameras | Security Cameras | Y | 251 +-------------+---------------------+-----+ 252 |Other | Other IoT devices | Y | 253 +-------------+---------------------+-----+ 254 |NetMgmt | Network Management | N | 255 +-------------+---------------------+-----+ 257 There are five segments. Two of them will have no MUD-enabled 258 devices in them, whereas the other three will. Of those three, 259 one is a non-classed MUD network (i.e., one in which MUD-enabled 260 devices which do not belong to specifically-configured classes 261 will be placed). The connectivity of the network looks like: 263 +--------------------+ 264 | Network Management |-----------| 265 +--------------------+ | 266 | v 267 | +--------------+ 268 | | SecDB | 269 | +---------+ | +----------+ | 270 +->| Readers |---------------->|Controller| | 271 | +---------+ | +----^-----+ | 272 | +------|-------+ 273 | +---------+ | 274 +---->| Cameras |-------------------+ 275 | +---------+ 276 | 277 | +-------+ 278 +------>| Other | 279 +-------+ 281 The SecDB segment will contain senstive systems as well as a 282 controller to which some of the other devices will need to 283 communicate. The Readers will be a segment in which all 284 badge/card readers will be grouped. The Cameras segment will 285 contain all of the security cameras. Finally, all other MUD- 286 enabled devices will be placed in the Other segment. Devices 287 placed into any of these segments as a result of MUD will still 288 have applicable ACLs applied. In addition, any static access 289 control restrictions given to each segment will be enforced per 290 the network designers' intentions. 292 Draft MUD Lifecyle: Network Operator 27 September 2017 294 How do the cameras get into the Cameras segment, and how do the 295 card readers get into the Readers segment? The specifics will 296 depend on the MUD Controller implemenation and the network devices 297 used, but the gist is that the network administrator defines 298 policies which map a MUD file's ``manufacturer'' and ``model'' to 299 the appropriate network segment assignment policy. If no specific 300 mapping is available for a device, then the MUD-enabled device 301 will be placed into a default segment per the operation of the MUD 302 Controller in use. 304 Another consideration is what to do with devices which have no MUD 305 profile at all. This was the case for all device before MUD was 306 defined and may continue to be the case for certain classes of 307 devices. The solution again lies with the definition of network 308 policies. It is up to the network designer to choose which 309 segment or segments devices which have no MUD support are placed 310 by default. Theoretically, the placement could be influenced by 311 the MAC address, the port into which the device is plugged, etc. 313 The bottom line is that MUD is not responsible for fully 314 describing the network configuration policy. It is very helpful 315 to automatically limit the access that MUD-enabled devices are 316 afforded to only what they need, but the network operator must 317 insure that the network design is complete. 319 3.2. Installing and/or Enabling a MUD Controller 321 MUD Policy Servers can conceivably take on many forms, including 322 stand-alone appliances, software modules installed on a switch or 323 a router, a software package installed and integrated with a DHCP 324 server, etc. The key requirements for MUD Policy Servers are: 326 1. Able to "see" a MUD URI 328 2. Able to retrieve a MUD file 330 For a MUD Policy Server to ``see a MUD URI'', it must either be 331 able to see the DHCP or equivalent requests from MPDs directly or 332 it must be otherwise connected to the service which does get to 333 see these types of requests. For example the MUD Policy Server 334 could be implemented as a plugin to a RADIUS server which is 335 receiving requests from a switch which is handling DHCP requests 336 by generating corresponding RADIUS AAA requests. 338 For a MUD Policy Server to be able to retrieve a MUD file, it must 339 have network access permissive enough to retrieve files which are 340 served from arbitrary locations on the internet. 342 Draft MUD Lifecyle: Network Operator 27 September 2017 344 Finally, to have any useful effect, the MUD Policy Server must be 345 able to, having parsed a MUD file, generate ACLs which are to be 346 applied to the appropriate port of the appropriate network device 347 (i.e., a dynamic configuration must be generated and applied which 348 reflects the MUD policy). The specifics of how the generated ACLs 349 get back to the NAS and get applied to the proper port will depend 350 on the design of the network. 352 At the time of this document's preparation, MUD is still a new 353 protocol and is under development. Therefore, descriptions of how 354 it is integrated will be subject to adjustment according to the 355 progression of actual implementations. 357 3.3. Network Device Configuration 359 There are two distinct "network configuration" concepts involved 360 in the deployment of MUD: 362 1. Configuration of the network infrastructure such that the MUD 363 controller is "in the loop" and able to issue configurations for 364 devices as they appear on the network 366 2. The per-device dynamic configuration that is generated through the 367 behavior of MUD itself 369 This document discusses both concepts where applicable. To avoid 370 confusion, when a reference is made to "configuring a device" or 371 similar, we will be referring to setting up the network 372 infrastructure to include the MUD Policy Server into operations. 373 The actions of the MUD infrastructure and network infrastructure 374 to effect changes to network configurations persuant to MUD- 375 advised policies will be referred to as "applying device policy" 376 or (when it is more clear to do so) "applying the dynamic device 377 configuration". The key word in the latter is dynamic and may be 378 used when describing the specific steps being taken by the devices 379 to apply the policies. 381 As previously mentioned, the ideal point for the application of 382 MUD-based access restrictions is the port into which a device is 383 directly plugged since this results in the most finely-grained 384 application of access control and insures that devices are not 385 able to talk even to neighbors on the same shared media without 386 MUD authorization. For this to happen, the switches which connect 387 to MUD-enabled devices must be configured to allow ACLs to be 388 applied to each port. If the switch is stand-alone, then it will 389 have to be configured to allow something like RADIUS or similar so 390 that a controller device can send ACLs to the switch via an 392 Draft MUD Lifecyle: Network Operator 27 September 2017 394 authorization transaction once the MUD profile has been processed. 396 For MUD to work properly, the switches MUST remove any dynamic 397 configuration applied to a port when the connection on that port 398 is dropped (such as when the cable to the port is disconnected). 399 Once reconnected, a device will again issue a DHCP or similar 400 request and the MUD behavior will begin again. 402 As an example, if a Layer-2 switch is used which can process DHCP 403 requests by issuing RADIUS AAA requests to complete the port-level 404 authorization, MUD process can occur by: 406 1. The switch adds the MUD URI to the RADIUS request (see [WEIS2017]) 408 2. The RADIUS server passes the MUD URI to a MUD Controller 410 3. The returned MUD file is processed and the appropriate ACLs 411 generated 413 4. The ACLs are encoded into the RADIUS Authorization response and 414 returned to the switch 416 5. The switch receives the RADIUS Authorization, matches it to the 417 port being provisioned, and applies the ACLs 419 3.4. Testing and Verification 421 In addition to the normal activities of validating through 422 monitoring commands that ACLs have been applied as expected, the 423 following items are suggested: 425 o If one wants to understand what ACLs will be applied during a test 426 of a particular device, one can read the MUD file to understand 427 what access requirements it has and thus compare that with what 428 ACLs get applied during the operation of the MUD protocol 430 o The devices with MPDs attached to them should be checked to 431 confirm the application of the expected ACLs and they are scoped 432 to the appropriate ports 434 o An ideal test would be to connect a MUD-enabled test client which 435 will issue an appropriate network access negotiation via DHCP or 436 whatever is appropriate for the NAS in use so that a full MUD File 437 retrieval is triggered. The test client should then be used to 438 try to both confirm connectivity to its explicity provisioned 439 destination(s) while also verifying that it is not possible to 440 reach sites outside the stipulated ACLs. 442 Draft MUD Lifecyle: Network Operator 27 September 2017 444 o The MPD should be disconnected from the switch and the switch 445 checked to verify that the ACLs are removed (which may not occur 446 until another device is plugged into the same port) 448 3.5. Caching MUD Files 450 MUD Files may be cached by the MUD Controller. The MUD File 451 itself indicates the minimum time between re-retrievals of a MUD 452 File via the ``cache-validity'' attribute. When the MUD 453 Controller is asked for a MUD File, if the URIs match a cached MUD 454 File which is recent enough to be used, then that cached MUD File 455 should be used. If not, then a valid MUD File MUST be retrieved 456 by using the URI as a URL. 458 Note, however, that MUD files are very small. Additionally, MPDs 459 will likely be installed into networks and then left running for 460 long periods of time such that the number of MUD file requests 461 will likely be small. Given those considerations, the value in 462 caching MUD files, at least in the near term, is expected to be 463 low. 465 4. Security Considerations 467 The bulk of this document describes the use of MUD to increase the 468 security of a network. However, it is possible to compromise the 469 effectiveness of MUD by attacking its behavior directly. This 470 section discusses the known attacks and describes possible 471 mitigations (all from the network operator's perspective). This 472 section also attempts to clarify the limits to which MUD is 473 expected to perform in terms of increasing security. 475 The use of MUD is intended to increase the level of security in 476 the network relative to its current state. If the network has no 477 security protections in place, then MUD may improve the situation 478 by limiting access to MUD-enabled devices, but the network may 479 already be too permissively accessible to be secure. A common 480 comment about MUD is that a compromised MUD File can allow a MUD- 481 enabled device to access arbitrary parts of the network or to 482 allow arbitrary access to the device. If the network had had no 483 security to begin with, then the compromised MUD File will not 484 have reduce the security in any meaningful way. 486 To put this another way, any network SHOULD be properly designed 487 such that the minimum required access is granted to all parties 488 involved. If this is done, then a bad MUD File can only result in 489 too permissive access to and from a single device in the network. 491 Draft MUD Lifecyle: Network Operator 27 September 2017 493 Although MUD is still a new protocol, it is conceivable that an 494 "ecosystem" around it will grow that will enable a level of 495 security validation that is much more difficult without it. In 496 particular, the published MUD Files could be analyzed by third 497 parties to assess their contents and to make users aware of 498 anomalies. Additionally, deviations in successive versions of MUD 499 Files can be audited to detect surprising changes. 501 Another commonly-mentioned attack scenario is tampering with the 502 MUD URI during device bring-up to cause a different MUD File to be 503 fetched and applied in place of the correct, manufacturer-supplied 504 file. The ramifications of such an attack are no different than 505 that of a compromised MUD File. The mitigation against the attack 506 is insure the use of secure means of receiving and processing the 507 device's advertisement of the MUD URI. 509 One other intriguing attack scenario is the spurious introduction 510 of something akin to a "phantom" DHCP request with a MUD URI 511 intended to coax the network infrastructure into fetching and 512 acting on a MUD File, possibly without an actual device being 513 present (or the "device" actually being a rogue software element 514 running on a real device). In addition to mitigations already 515 mentioned, port-level security should be used whenever possible 516 with strict security policies to enable the detection of these 517 rogue DHCP or other advertisements. 519 5. IANA Considerations 521 This document has no actions for IANA. 523 6. Normative References 525 [LEAR2017] 526 Lear, E., "Manufacturer Usage Description Specification", draft- 527 ietf-opsawg-mud-03, January 05, 2017 529 [WEIS2017] 530 Weis, B., "RADIUS Extensions for Manufacturer Usage Description", 531 draft-weis-radext-mud-00, October 25, 2016 533 7. Informative References 535 [RFC2882] 536 Mitton, D., "Network Access Servers Requirements: Extended RADIUS 538 Draft MUD Lifecyle: Network Operator 27 September 2017 540 Practices", RFC2882, July 2000 542 Authors' Addresses 544 Steven Rich 545 Cisco Systems, Inc. 546 170 West Tasman Dr. 547 San Jose, CA 95134 549 Email: srich@cisco.com 551 Thorsten Dahm 552 Google Inc. 553 1600 Amphitheatre Parkway 554 Mountain View, CA 94043 556 Email: thorstendlux@google.com