idnits 2.17.1 draft-srich-opsawg-mud-net-lifecycle-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 : ---------------------------------------------------------------------------- ** 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 255: '...ly, the switches MUST remove any dynam...' RFC 2119 keyword, line 312: '...hen a valid MUD File MUST be retrieved...' RFC 2119 keyword, line 343: '...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 (12 March 2017) is 2602 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2882' is defined on line 390, 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: September 12, 2017 T. Dahm 6 Google 7 12 March 2017 9 MUD Lifecyle: A Network Operator's Perspective 10 draft-srich-opsawg-mud-net-lifecycle-00.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 September 12, 2017. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with 53 respect to this document. Code Components extracted from this 54 document must include Simplified BSD License text as described in 55 Section 4.e of the Trust Legal Provisions and are provided without 56 warranty as described in the Simplified BSD License. 58 1. MUD Introduction 60 Network architects and operators have the goal of designing and 61 operating networks so that they are reliable, secure, and operate 62 correctly. Making them do so requires that the network permit 63 traffic which is intended to be allowed on the network while 64 rejecting or blocking traffic which is not. Both goals are met 65 with a combination of policies and configurations which promote 66 efficient routing of packets for certain classes of traffic and 67 which rate limit or even block (possibly by black-holing) other 68 classes of unwanted or lower-priority traffic. 70 A common assumption is that devices on the inside of the network 71 can have relatively unrestricted access to other parts of the 72 network and to the local network segment. This is reasonable for 73 devices which themselves have certain configurations which will 74 naturally govern which network access they require. For example, 75 a printer will usually be configured to accept connections from 76 hosts which wish to print to it. The printer itself may not tend 77 to initiate outbound connections and thus does not require a 78 complex set of custom ACLs. If the printer needs external 79 connectivity, the usual scenario is to allow the printer to make 80 outbound connections while still preventing inbound connections 81 using a stateful firewall rule or similar. However, there are 82 often no rules preventing the printer from making arbitrary 83 connections within network delineated by the firewall. 85 Other devices such as general-purpose end-user hosts (PCs, Mac, 86 etc.) might need unrestricted access, at least in the outbound 87 direction, because, contrary to the printer example, end-user 88 hosts are generally expected to make outbound connections to an 89 unpredictable number of hosts. Even if outbound restrictions to 90 certain ports (such as 80, 443, 22, 25, etc.) are enforced, the 91 destination address may be unrestricted. As stated above, 92 restrictions from internal hosts to internal addresses may be even 93 more lax. 95 Enter into this situation IoT devices which may be introduced to 96 the network in the thousands and which may have unspecified or 97 unclear requirements for network access. For example, IoT light 98 bulbs may need to talk to DNS, NTP, LLDP, DHCP, and a controller 99 on the local network and nothing else. An IoT thermostat may need 100 to talk to DNS, NTP, LLDP, DHCP, and its cloud-based controller, 101 but nothing else. For both of these cases, while their specific 102 requirements vary, knowing each one's requirements would allow a 103 tight set of ACLs to be imposed, all the way to the port level, to 104 limit what connectivity is afforded to each individual instance. 106 Recent examples of IoT-based malware campaigns will not be 107 repeated here and the benefits of providing such security will no 108 doubt be obvious to network operators. What has not been 109 available before MUD is an ability to automatically retrieve 110 configuration policy and then automatically apply it for each 111 device. This document will describe the ``lifecycle'' of MUD from 112 the perspective of a network operator. The details of the 113 protocol and contents of the MUD file itself are described in 114 [LEAR2017], and familiarity with it is assumed for this document. 116 2. Terminology 118 This document will use some terms and abbreviations which will be 119 listed and described in this section. 121 MPD 122 "MUD-Protected Device" - While this is a possibly tedious use of a 123 three-letter acronym, repeated use of "MUD-protected device" or 124 similar is equally tedious 126 AAA Server 127 "Authentication, Authorization, and Accounting Server" - A network 128 service which processes AAA requests 130 ACL 131 "Access Control List" - In the context of this document, an ACL 132 will refer specifically to those which are specified in a MUD file 133 and which get applied at some point in the network to enforce the 134 security policy needed by a device. These ACLs may be configured 135 down the port into which the device the is plugged, and they may 136 be applied "dynamically" in the sense that they appear in response 137 to the MUD request as opposed to a static configuration. They 138 will not be dynamic in the sense that they change frequently. The 139 actual implementation by any particular vendor is left up to that 140 vendor and thus may differ from the examples given in this 141 document. 143 3. MUD Lifecycle Description for Network Operators 145 The totality of what network operators must do to build, operate, 146 and maintain networks will not be described in exhaustive detail 147 in this document. Instead, we will describe what additional or 148 different things are necessary or recommended when establishing 149 MUD support within the network. Some of the steps discussed will 150 presuppose that networking equipment vendors will have added MUD 151 support to their products. 153 The following high-level tasks are required to support the 154 automatic network configuration aspects of MUD devices on the 155 network: 157 1. Install and/or enable a MUD Policy Server 159 2. Configure network devices so that they will receive and enforce 160 ACLs generated by the MUD Policy Server 162 3. Test and verify functionality by confirming that MUD files are 163 retrieved and ACLs are applied to the appropriate ports and that 164 those ACLs are removed when the port goes down 166 The MUD Policy Server may support caching retrieved MUD files. If 167 it does, then the operator may choose to enable, tune, test, and 168 monitor this functionality as well. Details about caching MUD 169 files as well as each task above will be covered later in this 170 document. 172 The network equipment to which MPDs connect must be capable of 173 accepting and enabling dynamic ACLs which can preferrably be 174 scoped to a port. While it is conceivable that the ACLs be 175 combined and applied at a point in network that is multiple hops 176 away from the switch to which the MPD connects, the tightest 177 security controls are possible when enforcement can happen 178 directly on the port. This eliminates the possibility that a MPD 179 can talk to other devices on the same switch unless explicitly 180 permitted. The remainder of this document will only discuss the 181 case of using ACLs. 183 3.1. Installing and/or Enabling a MUD Controller 185 MUD Policy Servers can conceivably take on many forms, including 186 stand-alone appliances, software modules installed on a switch or 187 a router, a software package installed and integrated with a DHCP 188 server, etc. The key requirements for MUD Policy Servers are: 190 1. Able to "see" a MUD URI 192 2. Able to retrieve a MUD file 194 For a MUD Policy Server to ``see a MUD URI'', it must either be 195 able to see the DHCP or equivalent requests from MPDs directly or 196 it must be otherwise connected to the service which does get to 197 see these types of requests. For example the MUD Policy Server 198 could be implemented as a plugin to a RADIUS server which is 199 receiving requests from a switch which is handling DHCP requests 200 by generating corresponding RADIUS AAA requests. 202 For a MUD Policy Server to be able to retrieve a MUD file, it must 203 have network access permissive enough to retrieve files which are 204 served from arbitrary locations on the internet. 206 Finally, to have any useful effect, the MUD Policy Server must be 207 able to, having parsed a MUD file, generate ACLs which are to be 208 applied to the appropriate port of the appropriate network device 209 (i.e., a dynamic configuration must be generated and applied which 210 reflects the MUD policy). The specifics of how the generated ACLs 211 get back to the NAS and get applied to the proper port will depend 212 on the design of the network. 214 At the time of this document's preparation, MUD is still a new 215 protocol and is under development. Therefore, descriptions of how 216 it is integrated will be subject to adjustment according to the 217 progression of actual implementations. 219 3.2. Network Device Configuration 221 There are two distinct "network configuration" concepts involved 222 in the deployment of MUD: 224 1. Configuration of the network infrastructure such that the MUD 225 controller is "in the loop" and able to issue configurations for 226 devices as they appear on the network 228 2. The per-device dynamic configuration that is generated through the 229 behavior of MUD itself 231 This document discusses both concepts where applicable. To avoid 232 confusion, when a reference is made to "configuring a device" or 233 similar, we will be referring to setting up the network 234 infrastructure to include the MUD Policy Server into operations. 235 The actions of the MUD infrastructure and network infrastructure 236 to effect changes to network configurations persuant to MUD- 237 advised policies will be referred to as "applying device policy" 238 or (when it is more clear to do so) "applying the dynamic device 239 configuration". The key word in the latter is dynamic and may be 240 used when describing the specific steps being taken by the devices 241 to apply the policies. 243 As previously mentioned, the ideal point for the application of 244 MUD-based access restrictions is the port into which a device is 245 directly plugged since this results in the most finely-grained 246 application of access control and insures that devices are not 247 able to talk even to neighbors on the same shared media without 248 MUD authorization. For this to happen, the switches which connect 249 to MUD-enabled devices must be configured to allow ACLs to be 250 applied to each port. If the switch is stand-alone, then it will 251 have to be configured to allow something like RADIUS or similar so 252 that a controller device can send ACLs to the switch via an 253 authorization transaction once the MUD profile has been processed. 255 For MUD to work properly, the switches MUST remove any dynamic 256 configuration applied to a port when the connection on that port 257 is dropped (such as when the cable to the port is disconnected). 258 Once reconnected, a device will again issue a DHCP or similar 259 request and the MUD behavior will begin again. 261 As an example, if a Layer-2 switch is used which can process DHCP 262 requests by issuing RADIUS AAA requests to complete the port-level 263 authorization, MUD process can occur by: 265 1. The switch adds the MUD URI to the RADIUS request (see [WEIS2017]) 267 2. The RADIUS server passes the MUD URI to a MUD Controller 269 3. The returned MUD file is processed and the appropriate ACLs 270 generated 272 4. The ACLs are encoded into the RADIUS Authorization response and 273 returned to the switch 275 5. The switch receives the RADIUS Authorization, matches it to the 276 port being provisioned, and applies the ACLs 278 3.3. Testing and Verification 280 In addition to the normal activities of validating through 281 monitoring commands that ACLs have been applied as expected, the 282 following items are suggested: 284 o If one wants to understand what ACLs will be applied during a test 285 of a particular device, one can read the MUD file to understand 286 what access requirements it has and thus compare that with what 287 ACLs get applied during the operation of the MUD protocol 289 o The devices with MPDs attached to them should be checked to 290 confirm the application of the expected ACLs and they are scoped 291 to the appropriate ports 293 o An ideal test would be to connect a MUD-enabled test client which 294 will issue an appropriate network access negotiation via DHCP or 295 whatever is appropriate for the NAS in use so that a full MUD File 296 retrieval is triggered. The test client should then be used to 297 try to both confirm connectivity to its explicity provisioned 298 destination(s) while also verifying that it is not possible to 299 reach sites outside the stipulated ACLs. 301 o The MPD should be disconnected from the switch and the switch 302 checked to verify that the ACLs are removed (which may not occur 303 until another device is plugged into the same port) 305 3.4. Caching MUD Files 307 MUD Files may be cached by the MUD Controller. The MUD File 308 itself indicates the minimum time between re-retrievals of a MUD 309 File via the ``cache-validity'' attribute. When the MUD 310 Controller is asked for a MUD File, if the URIs match a cached MUD 311 File which is recent enough to be used, then that cached MUD File 312 should be used. If not, then a valid MUD File MUST be retrieved 313 by using the URI as a URL. 315 Note, however, that MUD files are very small. Additionally, MPDs 316 will likely be installed into networks and then left running for 317 long periods of time such that the number of MUD file requests 318 will likely be small. Given those considerations, the value in 319 caching MUD files, at least in the near term, is expected to be 320 low. 322 4. Security Considerations 324 The bulk of this document describes the use of MUD to increase the 325 security of a network. However, it is possible to compromise the 326 effectiveness of MUD by attacking its behavior directly. This 327 section discusses the known attacks and describes possible 328 mitigations (all from the network operator's perspective). This 329 section also attempts to clarify the limits to which MUD is 330 expected to perform in terms of increasing security. 332 The use of MUD is intended to increase the level of security in 333 the network relative to its current state. If the network has no 334 security protections in place, then MUD may improve the situation 335 by limiting access to MUD-enabled devices, but the network may 336 already be too permissively accessible to be secure. A common 337 comment about MUD is that a compromised MUD File can allow a MUD- 338 enabled device to access arbitrary parts of the network or to 339 allow arbitrary access to the device. If the network had had no 340 security to begin with, then the compromised MUD File will not 341 have reduce the security in any meaningful way. 343 To put this another way, any network SHOULD be properly designed 344 such that the minimum required access is granted to all parties 345 involved. If this is done, then a bad MUD File can only result in 346 too permissive access to and from a single device in the network. 348 Although MUD is still a new protocol, it is conceivable that an 349 "ecosystem" around it will grow that will enable a level of 350 security validation that is much more difficult without it. In 351 particular, the published MUD Files could be analyzed by third 352 parties to assess their contents and to make users aware of 353 anomalies. Additionally, deviations in successive versions of MUD 354 Files can be audited to detect surprising changes. 356 Another commonly-mentioned attack scenario is tampering with the 357 MUD URI during device bring-up to cause a different MUD File to be 358 fetched and applied in place of the correct, manufacturer-supplied 359 file. The ramifications of such an attack are no different than 360 that of a compromised MUD File. The mitigation against the attack 361 is insure the use of secure means of receiving and processing the 362 device's advertisement of the MUD URI. 364 One other intriguing attack scenario is the spurious introduction 365 of something akin to a "phantom" DHCP request with a MUD URI 366 intended to coax the network infrastructure into fetching and 367 acting on a MUD File, possibly without an actual device being 368 present (or the "device" actually being a rogue software element 369 running on a real device). In addition to mitigations already 370 mentioned, port-level security should be used whenever possible 371 with strict security policies to enable the detection of these 372 rogue DHCP or other advertisements. 374 5. IANA Considerations 376 This document has no actions for IANA. 378 6. Normative References 380 [LEAR2017] 381 Lear, E., "Manufacturer Usage Description Specification", draft- 382 ietf-opsawg-mud-03, January 05, 2017 384 [WEIS2017] 385 Weis, B., "RADIUS Extensions for Manufacturer Usage Description", 386 draft-weis-radext-mud-00, October 25, 2016 388 7. Informative References 390 [RFC2882] 391 Mitton, D., "Network Access Servers Requirements: Extended RADIUS 392 Practices", RFC2882, July 2000 394 Authors' Addresses 396 Steven Rich 397 Cisco Systems, Inc. 398 170 West Tasman Dr. 399 San Jose, CA 95134 401 Email: srich@cisco.com 403 Thorsten Dahm 404 Google Inc. 405 1600 Amphitheatre Parkway 406 Mountain View, CA 94043 408 Email: thorstendlux@google.com