idnits 2.17.1 draft-ietf-opsawg-mud-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 29, 2016) is 2765 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-03 == Outdated reference: A later version (-21) exists of draft-ietf-netmod-acl-model-08 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE8021AB' ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 6092 ** Downref: Normative reference to an Informational RFC: RFC 7299 -- Obsolete informational reference (is this intentional?): RFC 7042 (Obsoleted by RFC 9542) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 3 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: Standards Track R. Droms 5 Expires: April 2, 2017 6 D. Romascanu 7 September 29, 2016 9 Manufacturer Usage Description Specification 10 draft-ietf-opsawg-mud-01 12 Abstract 14 This memo specifies the necessary components to implement 15 manufacturer usage descriptions (MUD). This includes two YANG 16 modules, IPv4 and IPv6 DHCP options, an LLDP TLV, a URL suffix 17 specification, an X.509 certificate extension and a means to sign and 18 verify the descriptions. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 2, 2017. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. A Simple Example . . . . . . . . . . . . . . . . . . . . 4 56 1.2. Determining Intended Use . . . . . . . . . . . . . . . . 4 57 1.3. Finding A Policy: The MUD URL . . . . . . . . . . . . . . 5 58 1.4. Types of Policies . . . . . . . . . . . . . . . . . . . . 5 59 1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 60 1.6. The Manufacturer Usage Description Architecture . . . . . 7 61 2. The MUD Model and Semantic Meaning . . . . . . . . . . . . . 8 62 3. Element Definitions . . . . . . . . . . . . . . . . . . . . . 8 63 3.1. last-update . . . . . . . . . . . . . . . . . . . . . . . 9 64 3.2. previous-mud-file . . . . . . . . . . . . . . . . . . . . 9 65 3.3. cache-validity . . . . . . . . . . . . . . . . . . . . . 9 66 3.4. masa-server . . . . . . . . . . . . . . . . . . . . . . . 9 67 3.5. is-supported . . . . . . . . . . . . . . . . . . . . . . 9 68 3.6. systeminfo . . . . . . . . . . . . . . . . . . . . . . . 9 69 3.7. packet-direction . . . . . . . . . . . . . . . . . . . . 10 70 3.8. manufacturer . . . . . . . . . . . . . . . . . . . . . . 10 71 3.9. same-manufacturer . . . . . . . . . . . . . . . . . . . . 10 72 3.10. model . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 3.11. local-networks . . . . . . . . . . . . . . . . . . . . . 10 74 3.12. controller . . . . . . . . . . . . . . . . . . . . . . . 10 75 3.13. direction-initiated . . . . . . . . . . . . . . . . . . . 11 76 4. Processing of the MUD file . . . . . . . . . . . . . . . . . 11 77 5. What does a MUD URL look like? . . . . . . . . . . . . . . . 11 78 6. The MUD YANG Model . . . . . . . . . . . . . . . . . . . . . 12 79 7. The Domain Name Extension to the ACL Model . . . . . . . . . 15 80 7.1. source-dnsname . . . . . . . . . . . . . . . . . . . . . 16 81 7.2. destination-dnsname . . . . . . . . . . . . . . . . . . . 16 82 7.3. The ietf-acldns Model . . . . . . . . . . . . . . . . . . 16 83 8. MUD File Example . . . . . . . . . . . . . . . . . . . . . . 17 84 9. The MUD URL DHCP Option . . . . . . . . . . . . . . . . . . . 19 85 9.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 19 86 9.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 20 87 9.3. Relay Requirements . . . . . . . . . . . . . . . . . . . 20 88 10. The Manufacturer Usage Description (MUD) URL X.509 Extension 20 89 11. The Manufacturer Usage Description LLDP extension . . . . . . 21 90 12. Creating and Processing of Signed MUD Files . . . . . . . . . 22 91 12.1. Creating a MUD file signature . . . . . . . . . . . . . 22 92 12.2. Verifying a MUD file signature . . . . . . . . . . . . . 23 93 13. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 23 94 14. Security Considerations . . . . . . . . . . . . . . . . . . . 24 95 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 96 15.1. DHCPv4 and DHCPv6 Options . . . . . . . . . . . . . . . 25 97 15.2. PKIX Extensions . . . . . . . . . . . . . . . . . . . . 25 98 15.3. Well Known URI Suffix . . . . . . . . . . . . . . . . . 25 99 15.4. MIME Media-type Registration for MUD files . . . . . . . 25 100 15.5. LLDP IANA TLV Subtype Registry . . . . . . . . . . . . . 26 101 15.6. The MUD Well Known Universal Resource Name (URNs) . . . 27 102 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 103 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 104 17.1. Normative References . . . . . . . . . . . . . . . . . . 27 105 17.2. Informative References . . . . . . . . . . . . . . . . . 29 106 Appendix A. Changes from Earlier Versions . . . . . . . . . . . 30 107 Appendix B. Default MUD elements . . . . . . . . . . . . . . . . 30 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 110 1. Introduction 112 The Internet has largely been constructed on general purpose 113 computers; those devices that may be used for a purpose that is 114 specified by those who buy the device. [RFC1984] presumed that an 115 end device would be most capable of protecting itself. This made 116 sense when the typical device was a workstation or a mainframe, and 117 it continues to make sense for general purpose computing devices 118 today, including laptops, smart phones, and tablets. 120 [RFC7452] discusses design patterns for, and poses questions about, 121 smart objects. Let us then posit a group of objects that are 122 specifically not general purpose computers. These devices therefore 123 have a purpose to their use. By definition, therefore, all other 124 purposes are NOT intended. The combination of these two statements 125 can be restated as a manufacturer usage description (MUD) that can be 126 applied at various points within a network. Although this memo may 127 seem to stress access requirements, usage intent also consists of 128 quality of service needs a device may have. 130 We use the notion of "manufacturer" loosely in this context, to 131 simply mean the entity or organization that will state how a device 132 is intended to be used. In the context of a lightbulb, this might 133 indeed be the lightbulb manufacturer. In the context of a smarter 134 device that has a built in Linux stack, it might be integrator of 135 that device. The key points are that the device itself is expected 136 to serve a limited purpose, and that there may exist an organization 137 in the supply chain of that device that will take responsibility for 138 informing the network about that purpose. 140 The converse statement holds that general computing systems will 141 benefit very little from MUD, as their manufacturers cannot envision 142 a specific communication pattern to describe. 144 The intent of MUD is to therefore solve for the following problems: 146 o Substantially reduce the threat surface on a device entering a 147 network to those communications intended by the manufacturer. 149 o Provide for a means to scale network policies to the ever- 150 increasing number types of devices in the network. 152 o Provide a means to address at least some vulnerabilities in a way 153 that is faster than it might take to update systems. This will be 154 particularly true for systems that are no longer supported by 155 their manufacturer. 157 o Keep the cost of implementation of such a system to the bare 158 minimum. 160 No matter how good a MUD-enabled network is, it will never replace 161 the need for manufacturers to patch vulnerabilities. It may, 162 however, provide network administrators with some additional 163 protection when those vulnerabilities exist. 165 1.1. A Simple Example 167 A light bulb is intended to light a room. It may be remotely 168 controlled through the network; and it may make use of a rendezvous 169 service of some form that an app on smart phone accesses. What we 170 can say about that light bulb, then, is that all other network access 171 is unwanted. It will not contact a news service, nor speak to the 172 refrigerator, and it has no need of a printer or other devices. It 173 has no Facebook friends. Therefore, an access list applied to it 174 that states that it will only connect to the single rendezvous 175 service will not impede the light bulb in performing its function, 176 while at the same time allowing the network to provide both it and 177 other devices an additional layer of protection. 179 1.2. Determining Intended Use 181 The notion of intended use is in itself not new. Network 182 administrators apply access lists every day to allow for only such 183 use. This notion of white listing was well described by Chapman and 184 Zwicky in [FW95]. Programmatically profiling systems have existed 185 for years as well. These systems make use of heuristics that take at 186 least some time to assert what a system is. 188 A system could just as easily tell the network what sort of 189 protection it requires without going into what sort of system it is. 190 This would, in effect, be the converse of [RFC7488]. In seeking a 191 general purpose solution, however, we assume that a device has so few 192 capabilities that it will implement the least necessary capabilities 193 to function properly. This is a basic economic constraint. Unless 194 the network would refuse access to such a device, its developers 195 would have no reason to implement such an approach. To date, such an 196 assertion has held true. 198 1.3. Finding A Policy: The MUD URL 200 Our work begins, therefore, with the device emitting a Universal 201 Resource Locator (URL) [RFC3986]. This URL may serves both to 202 classify the device type and to provide a means to locate a policy 203 file. 205 In this memo three means are defined to emit the MUD URL. One is a 206 DHCP option[RFC2131],[RFC3315] that the DHCP client uses to inform 207 the DHCP server. The DHCP server may take further actions, such as 208 retrieve the URL or otherwise pass it along to network management 209 system or controller. The other method defined is an X.509 210 constraint. The IEEE has developed [IEEE8021AR] that provides a 211 certificate-based approach to communicate device characteristics, 212 which itself relies on [RFC5280]. The MUD URL extension is non- 213 critical, as required by IEEE 802.1AR. Finally, an LLDP frame is 214 defined. 216 1.4. Types of Policies 218 When the MUD URL is resolved, the MUD controller retrieves a file 219 that describes what sort of communications a device is designed to 220 have. The manufacturer may specify either specific hosts for cloud 221 based services or certain classes for access within an operational 222 network. An example of a class might be "devices of a specified 223 manufacturer type", where the manufacturer type itself is indicated 224 simply by the authority of the MUD URL. Another example might to 225 allow or disallow local access. Just like other policies, these may 226 be combined. For example: 228 Allow access to host controller.example.com with QoS AF11 229 Allow access to devices of the same manufacturer 230 Allow access to and from controllers who need to speak COAP 231 Allow access to local DNS/DHCP 232 Deny all other access 234 To add a bit more depth that should not be a stretch of anyone's 235 imagination, one could also make use of port-based access lists. 236 Thus a printer might have a description that states: 238 Allow access for port IPP or port LPD 239 Allow local access for port HTTP 240 Deny all other access 242 In this way anyone can print to the printer, but local access would 243 be required for the management interface. 245 The files that are retrieved are intended to be closely aligned to 246 existing network architectures so that they are easy to deploy. We 247 make use of YANG [RFC6020] because of the time and effort spent to 248 develop accurate and adequate models for use by network devices. 249 JSON is used as a serialization for compactness and readability, 250 relative to XML. 252 The YANG modules specified here are extensions of 253 [I-D.ietf-netmod-acl-model]. The extensions to this model allow for 254 a manufacturer to express classes of systems that a manufacturer 255 would find necessary for the proper function of the device. Two 256 modules are specified. The first module specifies a means for domain 257 names to be used in ACLs so that devices that have their controllers 258 in the cloud may be appropriately authorized with domain names, where 259 the mapping of those names to addresses may rapidly change. 261 The second module abstracts away IP addresses into certain classes 262 that are instantiated into actual IP addresses through local 263 processing. Through these classes, manufacturers can specify how the 264 device is designed to communicate, so that network elements can be 265 configured by local systems that have local topological knowledge. 266 That is, the deployment populates the classes that the manufacturer 267 specifies. 269 Because manufacturers do not know who will be using their devices, it 270 is important for functionality referenced in usage descriptions to be 271 relatively ubiquitous, and therefore, mature. Therefore, only a a 272 limited subset YANG-based configuration of is permitted in a MUD 273 file. 275 1.5. Terminology 277 MUD: manufacturer usage description. 279 MUD file: a file containing YANG-based JSON that describes a 280 recommended behavior. 282 MUD file server: a web server that hosts a MUD file. 284 MUD controller: the system that requests and receives the MUD file 285 from the MUD server. After it has processed a MUD file it may 286 direct changes to relevant network elements. 288 MUD URL: a URL that can be used by the MUD controller to receive the 289 MUD file. 291 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 292 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 293 document are to be interpreted as described in [RFC2119]. 295 1.6. The Manufacturer Usage Description Architecture 297 With these components laid out we now have the basis for an 298 archicture. This leads us to ASCII art. 300 ......................................... 301 . ____________ . _____________ 302 . | | . | | 303 . | MUD |----->get URL->| MUD | 304 . | Controller | .(https) | File Server | 305 . End system network |____________|<--MUD file<--<|_____________| 306 . . . 307 . . . 308 . _______ _________ . 309 .| | (dhcp et al) | router | . 310 .| Thing |---->MUD URL-->| or | . 311 .|_______| | switch | . 312 . |_________| . 313 ......................................... 315 Figure 1: MUD Architecture 317 In the above diagram, the switch or router collects MUD URLs and 318 forwards them to the network management system for processing. This 319 happens in different ways, depending on how the URI is communicated. 320 For instance, in the case of DHCP, the DHCP server might receive the 321 URI and then process it. In the case of IEEE 802.1X, the switch 322 would tunnel the URI to the authentication server, who would then 323 process it. 325 The information returned by the web site is valid for the duration of 326 the device's connection, or as specified in the description. Thus if 327 the device is mobile, when it moves on, any configuration in the 328 switch is removed. Similarly, from time to time the description may 329 be refreshed, based on new capabilities or communication patterns or 330 vulnerabilities. 332 The web site is typically run by or on behalf of the manufacturer. 333 Its domain name is that of the authority found in the MUD URL. For 334 legacy cases where Things cannot emit a URL, if the switch is able to 335 determine the appropriate URI, it may proxy it, the trivial cases 336 being a map between some registered device or port and a URL. 338 2. The MUD Model and Semantic Meaning 340 A MUD file consists of JSON based on a YANG model. For purposes of 341 MUD, the elements that can be modified are access lists as augmented 342 by this model. The MUD file is limited to the serialization of a 343 small number of YANG schema, including the models specified in the 344 following documents: 346 o [I-D.ietf-netmod-acl-model] 348 o [RFC6991] 350 Publishers of MUD files MUST NOT include other elements except as 351 described in Section 13, and MUST only contain information relevant 352 to the device being described. Devices parsing MUD files MUST cease 353 processing if they find other elements. 355 This module is structured into three parts. The first container 356 holds information that is relevant to retrieval and validity of the 357 MUD file itself. The second container augments the access list to 358 indicate direction the ACL is to be applied. The final container 359 augments the matching container of the ACL model to add several 360 elements that are relevant to the MUD URL, or other otherwise 361 abstracted for use within a local environment. 363 module: ietf-mud 364 +--rw meta-info 365 +--rw last-update? yang:date-and-time 366 +--rw previous-mud-file? yang:uri 367 +--rw cache-validity? uint32 368 +--rw masa-server? inet:uri 369 +--rw is-supported? boolean 370 augment /acl:access-lists/acl:acl: 371 +--rw packet-direction? direction 372 augment /acl:access-lists/acl:acl 373 /acl:access-list-entries/acl:ace/acl:matches: 374 +--rw manufacturer? inet:host 375 +--rw same-manufacturer? empty 376 +--rw model? string 377 +--rw local-networks? empty 378 +--rw controller? inet:uri 379 +--rw direction-initiated? direction 381 3. Element Definitions 383 The following elements are defined. 385 3.1. last-update 387 This is a date-and-time value of the last time the MUD file was 388 updated. This is akin to a version number. Its form is taken from 389 [RFC6991] which, for those keeping score, turn was taken from 390 Section 5.6 of [RFC3339], which was taken from [ISO.8601.1988]. 392 3.2. previous-mud-file 394 This is a URL that should point to the previous MUD URL for auditing 395 purposes. Because it should not be necessary to resign a MUD file 396 when a new one is released, the archival location of a current MUD 397 file should be identified prior to its release. Note the signature 398 file MUST also be available. For example, if previous-mud-file is 399 set to "https://example.com/.mud/v1/xxx", the corresponding signature 400 would be found at "https://example.com/.mud/v1/xxx.p7s". 402 3.3. cache-validity 404 This uint32 is the period of time in hours that a network management 405 station MUST wait since its last retrieval before checking for an 406 update. It is RECOMMENDED that this value be no less than 24 and no 407 more than 1440 for any device that is supported. 409 3.4. masa-server 411 This optional element refers to the URL that should be used to 412 resolve the location any MASA service, as specified in 413 [I-D.ietf-anima-bootstrapping-keyinfra]. 415 3.5. is-supported 417 This boolean is an indication from the manufacturer to the network 418 administrator as to whether or not the device is supported. In this 419 context a device is said to be supported if the manufacturer might 420 issue an update to the device or if the manufacturer might update the 421 MUD file. 423 3.6. systeminfo 425 This string contains a description of the device that this MUD file 426 supports. Note that this is a hint, and not intended for consumption 427 by a computer. 429 3.7. packet-direction 431 [I-D.ietf-netmod-acl-model] describes access-lists but does not 432 attempt to indicate where they are applied as that is handled 433 elsewhere in a configuration. However, in this case, a MUD file must 434 be explicit in describing the communcation pattern of a device, and 435 that includes indicating what is to be permitted or denied in either 436 direction of communication. This element takes a single value of 437 either "to-device" or "from-device", based on a typedef "direction". 439 3.8. manufacturer 441 This element consists of a hostname that would be matched against the 442 authority section of another device's MUD URL. 444 3.9. same-manufacturer 446 This is an equivalent for when the manufacturer element is used to 447 indicate the authority that is found in another device's MUD URL 448 matches that of the authority found in this device's MUD URL. 450 3.10. model 452 This string matches the one and only segment following the authority 453 section of the MUD URL. It refers to a model that is unique within 454 the context of the authority. It may also include product version 455 information. Thus how this field is constructed is entirely a local 456 matter for the manufacturer. 458 3.11. local-networks 460 This null-valued element expands to include local networks. Its 461 default expansion is that packets must not traverse toward a default 462 route that is received from the router. 464 3.12. controller 466 This URI specifies a value that a controller will register with the 467 network management station. The element then is expanded to the set 468 of hosts that are so registered. This element may also be a URN. In 469 this case, the URN describes a well known service, such as DNS or 470 NTP. 472 In addition, some meta information is defined in order to determine 473 when a usage description should be refreshed. 475 3.13. direction-initiated 477 When applied this matches packets when the flow was initiated in the 478 corresponding direction. [RFC6092] provides guidance for IPv6 479 guidance best practices. While that document is scoped specifically 480 to IPv6, its contents are applicable for IPv4 as well. When this 481 flag is set, and the system has no reason to believe a flow has been 482 initiated it MUST drop the packet. This match SHOULD be applied with 483 specific transport parameters, such as protocol. 485 4. Processing of the MUD file 487 To keep things relatively simple in addition to whatever definitions 488 exist, we also apply two additional default behaviors: 490 o Anything not explicitly permitted is denied. 492 o Local DNS and NTP are, by default, permitted to and from the 493 device. 495 An explicit description of the defaults can be found in Appendix B. 497 5. What does a MUD URL look like? 499 To begin with, MUD takes full advantage of both the https: scheme and 500 the use of .well-known. HTTPS is important in this case because a 501 man in the middle attack could otherwise harm the operation of a 502 class of devices. .well-known is used because we wish to add 503 additional structure to the URL. And so the URL appears as follows: 505 mud-url = "https://" authority "/.well-known/mud/" mud-rev 506 "/" model ( "?" extras ) 507 ; authority is from RFC3986 508 mud-rev = "v1" 509 model = segment ; from RFC3986 510 extras = query ; from RFC3986 512 mud-rev signifies the version of the manufacturer usage description 513 file. This memo specifies "v1" of that file. Later versions may 514 permit additional schemas or modify the format. 516 "model" represents a device model as the manufacturer wishes to 517 represent it. It could be a brand name or something more specific. 518 It also may provide a means to indicate what version the product is. 519 Specifically if it has been updated in the field, this is the place 520 where evidence of that update would appear. The field should be 521 changed when the intended communication patterns of a device change. 523 While from a controller standpoint, only comparison and matching 524 operations are safe, it is envisioned that updates will require some 525 administrative review. Processing of this URL occurs as specified in 526 [RFC2818] and [RFC3986]. 528 6. The MUD YANG Model 530 file "ietf-mud@2016-07-20.yang"; 532 module ietf-mud { 533 yang-version 1.1; 534 namespace "urn:ietf:params:xml:ns:yang:ietf-mud"; 535 prefix "ietf-mud"; 537 import ietf-access-control-list { 538 prefix "acl"; 539 } 541 import ietf-yang-types { 542 prefix "yang"; 543 } 545 import ietf-inet-types { 546 prefix "inet"; 547 } 549 organization 550 "IETF OPSAWG (Ops Area) Working Group"; 552 contact 553 "WG Web: http://tools.ietf.org/wg/opsawg/ 554 WG List: opsawg@ietf.org 555 WG Chair: Warren Kumari 556 warren@kumari.net 557 WG Chair: Zhou Tianran 558 zhoutianran@huawei.com 559 Editor: Eliot Lear 560 lear@cisco.com 561 Editor: Ralph Droms 562 rdroms@cisco.com 563 "; 565 description 566 "This YANG module defines a component that augments the 567 IETF description of an access list. This specific module 568 focuses on additional filters that include local, model, 569 and same-manufacturer. 571 Copyright (c) 2016 IETF Trust and the persons identified as 572 the document authors. All rights reserved. 573 Redistribution and use in source and binary forms, with or 574 without modification, is permitted pursuant to, and subject 575 to the license terms contained in, the Simplified BSD 576 License set forth in Section 4.c of the IETF Trust's Legal 577 Provisions Relating to IETF Documents 578 (http://trustee.ietf.org/license-info). 579 This version of this YANG module is part of RFC XXXX; see 580 the RFC itself for full legal notices."; 582 revision "2016-07-20" { 583 description "Base version of MUD extensions to ACL model"; 584 reference "RFC XXXX: Manufacturer Usage Description Specification"; 585 } 587 typedef direction { 588 type enumeration { 589 enum to-device { 590 description "packets or flows destined to the target device"; 591 } 592 enum from-device { 593 description "packets or flows destined from 594 the target device"; 595 } 596 } 597 description "Which way are we talking about?"; 598 } 600 container metainfo { 602 description "Information about when support end(ed), and 603 when to refresh"; 605 leaf last-update { 606 type yang:date-and-time; 607 description "This is intended to be the time and date that 608 the MUD file was generated."; 609 } 611 leaf previous-mud-file { 612 type inet:uri; 613 description "Use to find the previous MUD file location 614 for auditing purposes."; 615 } 617 leaf cache-validity { 618 type uint32; 619 description "The information retrieved from the MUD server is 620 valid for these many hours, after which it should 621 be refreshed."; 622 } 624 leaf masa-server { 625 type inet:uri; 626 description "The URI of the MASA server that network 627 elements should forward requests to for this device."; 628 } 630 leaf is-supported { 631 type boolean; 632 description "The element is currently supported 633 by the manufacturer."; 634 } 635 leaf systeminfo { 636 type string; 637 description "A non-normative name and description of the device 638 this file is used for."; 639 } 640 } 642 augment "/acl:access-lists/acl:acl" { 643 description "add inbound or outbound. Normally access lists 644 are applied in an inbound or outbound direction 645 separately from their definition. This is not 646 possible with MUD."; 647 leaf packet-direction 648 { 649 type direction; 650 description "inbound or outbound ACL."; 651 } 652 } 654 augment "/acl:access-lists/acl:acl/" + 655 "acl:access-list-entries/acl:ace/" + 656 "acl:matches" { 657 description "adding abstractions to avoid need of IP addresses"; 659 leaf manufacturer { 660 type inet:host; 661 description "authority component of the manufacturer URI"; 662 } 664 leaf same-manufacturer { 665 type empty; 666 description "expand to ACEs for each device 667 with the same origin"; 668 } 670 leaf model { 671 type string; 672 description "specific model (including version) for a 673 given manufacturer"; 674 } 676 leaf local-networks { 677 type empty; 678 description "this string is used to indicate networks 679 considered local in a given environment."; 680 } 681 leaf controller { 682 type inet:uri; 683 description "expands to one or more controllers for a 684 given service that is codified by inet:uri."; 685 } 686 leaf direction-initiated { 687 type direction; 688 description "which direction a flow was initiated"; 689 } 690 } 691 } 693 695 7. The Domain Name Extension to the ACL Model 697 This module specifies an extension to IETF-ACL model such that domain 698 names may be referenced by augmenting the "matches" element. 699 Different implementations may deploy differing methods to maintain 700 the mapping between IP address and domain name, if indeed any are 701 needed. However, the intent is that resources that are referred to 702 using a name should be authorized (or not) within an access list. 704 The structure of the change is as follows: 706 augment 707 /acl:access-lists/acl:acl/acl:access-list-entries 708 /acl:ace/acl:matches/acl:ace-type/acl:ace-ip: 709 +--rw src-dnsname? inet:host 710 +--rw dst-dnsname? inet:host 712 The choice of this particular point in the access-list model is based 713 on the assumption that we are in some way referring to IP-related 714 resources, as that is what the DNS returns. A domain name in our 715 context is defined in [RFC6991]. 717 The following elements are defined. 719 7.1. source-dnsname 721 The argument corresponds to a domain name of a source as specified by 722 inet:host. Depending on how the model is used, it may or may not be 723 resolved, as required by the implementation and circumstances. 725 7.2. destination-dnsname 727 The argument corresponds to a domain name of a destination as 728 specified by inet:host. Depending on how the model is used, it may 729 or may not be resolved, as required by the implementation and 730 circumstances. 732 7.3. The ietf-acldns Model 734 file "ietf-acldns@2007-07020.yang"; 736 module ietf-acldns { 737 yang-version 1.1; 738 namespace "urn:ietf:params:xml:ns:yang:ietf-acldns"; 739 prefix "ietf-acldns"; 741 import ietf-access-control-list { 742 prefix "acl"; 743 } 745 import ietf-inet-types { 746 prefix "inet"; 747 } 749 organization 750 "IETF OPSAWG (Ops Area) Working Group"; 752 contact 753 "WG Web: http://tools.ietf.org/wg/opsawg/ 754 WG List: opsawg@ietf.org 755 WG Chair: Warren Kumari 756 warren@kumari.net 757 WG Chair: Zhou Tianran 758 zhoutianran@huawei.com 759 Editor: Eliot Lear 760 lear@cisco.com 761 Editor: Ralph Droms 762 rdroms@cisco.com 763 "; 765 description 766 "This YANG module defines a component that augments the 767 IETF description of an access list to allow dns names 768 as matching criteria."; 770 revision "2016-07-20" { 771 description "Base version of dnsname extension of ACL model"; 772 reference "RFC XXXX: Manufacturer Usage Description Specification"; 773 } 775 augment "/acl:access-lists/acl:acl/" + 776 "acl:access-list-entries/acl:ace/" + 777 "acl:matches/acl:ace-type/acl:ace-ip" { 778 description "adding domain names to matching"; 780 leaf src-dnsname { 781 type inet:host; 782 description "domain name to be matched against"; 783 } 784 leaf dst-dnsname { 785 type inet:host; 786 description "domain name to be matched against"; 787 } 788 } 789 } 791 793 8. MUD File Example 795 This example contains two access lists that are intended to provide 796 outbound access to a cloud service on TCP port 443. 798 { 799 "ietf-mud:metainfo": { 800 "last-update": "2016-05-18T20:00:50Z", 801 "cache-validity": 1440 802 }, 803 "ietf-access-control-list:access-lists": { 804 "acl": [ { 805 "acl-name": "inbound-stuff", 806 "acl-type" : "ipv4-acl", 807 "ietf-mud:direction" : "to-device", 808 "access-list-entries": { 809 "ace": [ 810 { 811 "rule-name": "access-cloud", 812 "matches": { 813 "ietf-acldns:src-dnsname": 814 "lighting-system.example.com", 815 "protocol" : 6, 816 "source-port-range" : { 817 "lower-port" : 443, 818 "upper-port" : 443 819 } 820 }, 821 "actions" : { 822 "permit" : [null] 823 } 824 } 825 ] 826 } 827 }, 828 { 829 "acl-name": "outbound-stuff", 830 "acl-type" : "ipv4-acl", 831 "ietf-mud:direction" : "from-device", 832 "access-list-entries": { 833 "ace": [ 834 { 835 "rule-name": "access-cloud", 836 "matches": { 837 "ietf-acldns:dst-dnsname": 838 "lighting-system.example.com", 839 "protocol" : 6, 840 "destination-port-range" : { 841 "lower-port" : 443, 842 "upper-port" : 443 843 } 844 }, 845 "actions" : { 846 "permit" : [null] 847 } 848 } 849 ] 850 } 851 } 852 ] 853 } 854 } 856 9. The MUD URL DHCP Option 858 The IPv4 MUD URL client option has the following format: 860 +------+-----+------------------------------ 861 | code | len | MUD URL 862 +------+-----+------------------------------ 864 Code OPTION_MUD_URL_V4 (TBD) is assigned by IANA. len is a single 865 octet that indicates the length of the URL in octets. MUD URL is a 866 URL. The length of a MUD URL does not exceed 255 bytes. 868 The IPv6 MUD URL client option has the following format: 870 0 1 2 3 871 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | OPTION_MUD_URL_V6 | option-length | 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | MUD URL | 876 | ... | 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 OPTION_MUD_URL_V6 (TBD; assigned by IANA). 881 option-length contains the length of the URL in octets. The length 882 MUST NOT exceed 255 octets. 884 The intent of this option is to provide both a new device classifier 885 to the network as well as some recommended configuration to the 886 routers that implement policy. However, it is entirely the purview 887 of the network system as managed by the network administrator to 888 decide what to do with this information. The key function of this 889 option is simply to identify the type of device to the network in a 890 structured way such that the policy can be easily found with existing 891 toolsets. 893 9.1. Client Behavior 895 A DHCP client MAY emit either a DHCPv4 or DHCPv6 option or both. 896 These options singletons, as specified in [RFC7227]. Because clients 897 are intended to have at most one MUD URL associated with them, they 898 may emit at most one MUD URL option via DHCPv4 and one MUD URL option 899 via DHCPv6. In the case where both v4 and v6 DHCP options are 900 emitted, the same URL MUST be used. 902 Clients SHOULD log or otherwise report improper acknowledgments from 903 servers, but they MUST NOT modify their MUD URL configuration based 904 on a server's response. The server's response is only an 905 acknowledgment that the server has processed the option, and promises 906 no specific network behavior to the client. In particular, it may 907 not be possible for the server to retrieve the file associated with 908 the MUD URL, or the local network administration may not wish to use 909 the usage description. Neither of these situations should be 910 considered in any way exceptional. 912 9.2. Server Behavior 914 A DHCP server may ignore these options or take action based on 915 receipt of these options. For purposes of debugging, if a server 916 successfully parses the option and the URL, it MUST return the option 917 with the same URL as an acknowledgment. Even in this circumstance, 918 no specific network behavior is guaranteed. When a server consumes 919 this option, it will either forward the URL and relevant client 920 information to a network management system (such as the giaddr), or 921 it will retrieve the usage description by resolving the URL. 923 DHCP servers may implement MUD functionality themselves or they may 924 pass along appropriate information to a network management system or 925 controller. A DHCP server that does process the MUD URL MUST adhere 926 to the process specified in [RFC2818] and [RFC5280] to validate the 927 TLS certificate of the web server hosting the MUD file. Those 928 servers will retrieve the file, process it, create and install the 929 necessary configuration on the relevant network element. Servers 930 SHOULD monitor the gateway for state changes on a given interface. A 931 DHCP server that does not provide MUD functionality and has forwarded 932 a MUD URL to a network management system MUST notify the network 933 management of any corresponding change to the DHCP state of the 934 client (such as expiration or explicit release of a network address 935 lease). 937 9.3. Relay Requirements 939 There are no additional requirements for relays. 941 10. The Manufacturer Usage Description (MUD) URL X.509 Extension 943 [RFC7299] provides a procedure and means to specify extensions to 944 X.509 certificates. The MUD URL is a non-critical Certificate 945 extension that points to an on-line Manufacturer Usage Description 946 concerning the certificate subject. This extension contains a single 947 Uniform Resource Identifier (URI). Internationalized Resource 948 Identifiers must be represented as URI's in the way described in RFC 949 5280, section 7.4. 951 The choice of id-pe is based on guidance found in Section 4.2.2 of 952 [RFC5280]: 954 These extensions may be used to direct applications to on-line 955 information about the issuer or the subject. 957 The MUD URL is precisely that: online information about the 958 particular subject. 960 The new extension is identified as follows: 962 - The MUD URL extension id-pe-mud-url OBJECT IDENTIFER ::= { id-pe 963 TBD } 965 The extension returns a single value: 967 mudURLSyntax ::= IA5String - for use with MUD architecture. 969 The semantics of the URI are defined Section 5. 971 11. The Manufacturer Usage Description LLDP extension 973 The IEEE802.1AB Link Layer Discovery Protocol (LLDP) [IEEE8021AB] is 974 a one hop vendor-neutral link layer protocols used by end hosts 975 network devices for advertising their identity, capabilities, and 976 neighbors on an IEEE 802 local area network. Its Type-Length-Value 977 (TLV) design allows for 'vendor-specific' extensions to be defined. 978 IANA has a registered IEEE 802 organizationally unique identifier 979 (OUI) defined as documented in [RFC7042]. The MUD LLDP extension 980 uses a subtype defined in this document to carry the MUD URL. 982 The LLDP vendor specific frame has the following format: 984 +--------+--------+----------+---------+-------------- 985 |TLV Type| len | OUI |subtype | MUD URL 986 | =127 | |= 00 00 5E| = 1 | 987 |(7 bits)|(9 bits)|(3 octets)|(1 octet)|(1-256 octets) 988 +--------+--------+----------+---------+-------------- 990 where: 992 o TLV Type = 127 indicates a vendor-specific TLV 994 o len - indicates the TLV string length 996 o OUI = 00 00 5E is the organizationally unique identifier of IANA 997 o subtype = 1 (to be assigned by IANA for the MUD URL) 999 o MUD URL - the length MUST NOT exceed 256 octets (consistent with 1000 the DHCP option defined in Section 9) 1002 The intent of this extension is to provide both a new device 1003 classifier to the network as well as some recommended configuration 1004 to the routers that implement policy. However, it is entirely the 1005 purview of the network system as managed by the network administrator 1006 to decide what to do with this information. The key function of this 1007 extension is simply to identify the type of device to the network in 1008 a structured way such that the policy can be easily found with 1009 existing toolsets. 1011 Hosts, routers, or other network devices that implement this option 1012 are intended to have at most one MUD URL associated with them, so 1013 they may transmit at most one MUD URL value. 1015 Hosts, routers, or other network devices that implement this option 1016 may ignore these options or take action based on receipt of these 1017 options. For example they may fill in information in the respective 1018 extensions of the LLDP Management Information Base (LLDP MIB). LLDP 1019 operates in a one-way direction. LLDPDUs are not exchanged as 1020 information requests by one device and response sent by another 1021 device. The other devices do not acknowledge LLDP information 1022 received from a device. No specific network behavior is guaranteed. 1023 When a device consumes this extension, it may either forward the URL 1024 and relevant remote device information to a network management 1025 system, or it will retrieve the usage description by resolving the 1026 URL. 1028 12. Creating and Processing of Signed MUD Files 1030 Because MUD files contain information that may be used to configure 1031 network access lists, they are sensitive. To insure that they have 1032 not been tampered with, it is important that they be signed. We make 1033 use of DER-encoded Cryptographic Message Syntax (CMS) [RFC5652] for 1034 this purpose. 1036 12.1. Creating a MUD file signature 1038 A MUD file MUST be signed using CMS as an opaque binary object. In 1039 order to make successful verification more likely, intermediate 1040 certificates SHOULD be included. The signature is stored at the same 1041 location as the MUD URL but with the suffix of ".p7s". Signatures 1042 are transferred using content-type "Application/pkcs7-signature". 1044 For example: 1046 % openssl cms -sign -signer mancertfile -inkey mankey \ 1047 -in mudfile -binary -outform DER - \ 1048 -certfile intermediatecert -out mudfile.p7s 1050 Note: A MUD file may need to be resigned if the signature expires. 1052 12.2. Verifying a MUD file signature 1054 Prior to retrieving a MUD file the MUD controller SHOULD retrieve the 1055 MUD signature file using the MUD URL with a suffix of ".p7s". For 1056 example, if the MUD URL is "https://example.com/.well-known/v1/ 1057 modela", the MUD signature URL will be "https://example.com/.well- 1058 known/v1/modela.p7s". 1060 Upon retrieving a MUD file, a MUD controller MUST validate the 1061 signature of the file before continuing with further processing. A 1062 MUD controller SHOULD produce an error and it MUST cease all 1063 processing of that file if the signature cannot be validated. It is 1064 important that MUD controllers have some reason to trust the 1065 certificates they are seeing. Therefore, it is RECOMMENDED that new 1066 signers be validated either directly by an administrator or by a 1067 service that has some reason to believe that the signer is a good 1068 actor. 1070 For Example: 1072 % openssl cms -verify -in mudfile.p7s -inform DER -content mudfile 1074 Note the additional step of verifying the common trust root. 1076 13. Extensibility 1078 One of our design goals is to see that MUD files are able to be 1079 understood by as broad a cross-section of systems as is possible. 1080 Coupled with the fact that we have also chosen to leverage existing 1081 mechanisms, we are left with no ability to negotiate extensions and a 1082 limited desire for those extensions in any event. A such, a two-tier 1083 extensibility framework is employed, as follows: 1085 1. At a coarse grain, a protocol version is included in a MUD URL. 1086 This memo specifies MUD version 1. Any and all changes are 1087 entertained when this version is bumped. Transition approaches 1088 between versions would be a matter for discussion in future 1089 versions. 1091 2. At a finer grain, only extensions that would not incur additional 1092 risk to the device are permitted. Specifically, augmenting of 1093 the meta-info container is permitted with the understanding that 1094 such additions may be ignored. In addition, augmentation of the 1095 ACL model is permitted so long as it remains safe for a given ACE 1096 to be ignored by the MUD Controller or the network elements it 1097 configures. Most specifically, is is not permitted to include as 1098 an augmentation that modifies "deny" behavior without bumping the 1099 version. Furthermore, implementations that are not able to parse 1100 a component of the ACE array MUST ignore the entire array entry 1101 (e.g., not the entire array) and MAY ignore the entire MUD file. 1103 14. Security Considerations 1105 Based on the means a URL is procured, a device may be able to lie 1106 about what it is, thus gaining additional network access. There are 1107 several means to limit risk in this case. The most obvious is to 1108 only believe devices that make use of certificate-based 1109 authentication such as IEEE 802.1AR certificates. When those 1110 certificates are not present, devices claiming to be of a certain 1111 manufacturer SHOULD NOT be included in that manufacturer grouping 1112 without additional validation of some form. This will occur when it 1113 makes use of primitives such as "manufacturer" for the purpose of 1114 accessing devices of a particular type. 1116 Network management systems SHOULD NOT deploy a usage description for 1117 a device with the same MAC address that has indicated a change of 1118 authority without some additional validation (such as review of the 1119 class). New devices that present some form of unauthenticated MUD 1120 URL SHOULD be validated by some external means when they would be 1121 otherwise be given increased network access. 1123 It may be possible for a rogue manufacturer to inappropriately 1124 exercise the MUD file parser, in order to exploit a vulnerability. 1125 There are three recommended approaches to address this threat. The 1126 first is to validate the signature of the MUD file. The second is to 1127 have a system do a primary scan of the file to ensure that it is both 1128 parseable and believable at some level. MUD files will likely be 1129 relatively small, to start with. The number of ACEs used by any 1130 given device should be relatively small as well. Second, it may be 1131 useful to limit retrieval of MUD URLs to only those sites that are 1132 known to have decent web reputations. 1134 Use of a URL necessitates the use of domain names. If a domain name 1135 changes ownership, the new owner of that domain may be able to 1136 provide MUD files that MUD controllers would consider valid. There 1137 are a few approaches that can mitigate this attack. First, MUD file 1138 servers SHOULD cache certificates used by the MUD file server. When 1139 a new certificate is retrieved for whatever reason, the MUD 1140 controller should check to see if ownership of the domain has 1141 changed. A fair programmatic approximation of this is when the name 1142 servers for the domain have changed. If the actual MUD file has 1143 changed, the controller MAY check the WHOIS database to see if 1144 registration ownership of a domain has changed. If a change has 1145 occured, or if for some reason it is not possible to determine 1146 whether ownership has changed, further review may be warranted. 1147 Note, this remediation does not take into account the case of a 1148 device that was produced long ago and only recently fielded, or the 1149 case where a new MUD controller has been installed. 1151 15. IANA Considerations 1153 15.1. DHCPv4 and DHCPv6 Options 1155 IANA is requested to allocated the DHCPv4 and v6 options as specified 1156 in Section 9. 1158 15.2. PKIX Extensions 1160 The IANA is requested to assign a value for id-pe-mud-uri in the "SMI 1161 Security for PKIX Certificate Extension" Registry. Its use is 1162 specified in Section 10. 1164 15.3. Well Known URI Suffix 1166 The IANA is requested to register the URL suffix of "mud" as follows: 1168 o URI Suffix: "mud" o Specification documents: this document o 1169 Related information: n/a 1171 15.4. MIME Media-type Registration for MUD files 1173 The following media-type is defined for transfer of MUD file: 1175 o Type name: application 1176 o Subtype name: mud+json 1177 o Required parameters: n/a 1178 o Optional parameters: n/a 1179 o Encoding considerations: 8bit; application/mud+json values 1180 are represented as a JSON object; UTF-8 encoding SHOULD be 1181 employed. 1182 o Security considerations: See {{secon}} of this document. 1183 o Interoperability considerations: n/a 1184 o Published specification: this document 1185 o Applications that use this media type: MUD controllers as 1186 specified by this document. 1187 o Fragment identifier considerations: n/a 1188 o Additional information: 1190 Magic number(s): n/a 1191 File extension(s): n/a 1192 Macintosh file type code(s): n/a 1194 o Person & email address to contact for further information: 1195 Eliot Lear , Ralph Droms 1196 o Intended usage: COMMON 1197 o Restrictions on usage: none 1199 o Author: Eliot Lear , Ralph Droms 1200 o Change controller: IESG 1201 o Provisional registration? (standards tree only): No. 1203 15.5. LLDP IANA TLV Subtype Registry 1205 IANA is requested to create a new registry for IANA Link Layer 1206 Discovery Protocol (LLDP) TLV subtype values. The recommended policy 1207 for this registry is Expert Review. The maximum number of entries in 1208 the registry is 256. 1210 IANA is required to populate the initial registry with the value: 1212 LLDP subtype value = 1 1214 Description = the Manufacturer Usage Description (MUD) Uniform 1215 Resource Locator (URL) 1217 Reference = < this document > 1219 15.6. The MUD Well Known Universal Resource Name (URNs) 1221 Namespace ID: "urn:mud" is requested. Registration Information: 1222 registration version number: 1 registration date: 2016-09-27 1224 Declared registrant of the namespace: The Internet Engineering Task 1225 Force Ops Area WG Designated contact person: opsawg@ietf.org 1226 Declaration of syntactic structure: Entries should follow the syntax 1227 of a TCP/UDP port service name as found in Section 5.1 of [RFC6335]. 1228 Relevant ancillary documentation: this document. Identifier 1229 uniqueness considerations: see below Identifier persistence 1230 considerations: no resolution mechanism is anticipated. Process of 1231 identifier assignment: IANA is requested to maintain a table of 1232 entries that are updated with the policy of "standards action". 1233 Process for identifier resolution: n/a Rules for Lexical Equivalence: 1234 exact ASCII match Conformance with URN Syntax: no special 1235 considerations. Validation mechanism: a syntax grammar Scope: These 1236 identifiers are intended solely for use as a means to indicate 1237 standard MUD controllers. 1239 The following entries should be added to the "ietf:mud" name space: 1241 "ietf:mud:dns" refers to the service specified by [RFC1123]. 1242 "ietf:mud:ntp" refers to the service specified by [RFC5905]. 1244 16. Acknowledgments 1246 The authors would like to thank Einar Nilsen-Nygaard, Bernie Volz, 1247 Tom Gindin, Brian Weis, Sandeep Kumar, Thorsten Dahm, John Bashinski, 1248 Steve Rich, Jim Bieda, and Dan Wing for their valuable advice and 1249 reviews. The remaining errors in this work are entirely the 1250 responsibility of the author. 1252 17. References 1254 17.1. Normative References 1256 [I-D.ietf-anima-bootstrapping-keyinfra] 1257 Pritikin, M., Richardson, M., Behringer, M., and S. 1258 Bjarnason, "Bootstrapping Remote Secure Key 1259 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 1260 keyinfra-03 (work in progress), June 2016. 1262 [I-D.ietf-netmod-acl-model] 1263 Bogdanovic, D., Koushik, K., Huang, L., and D. Blair, 1264 "Network Access Control List (ACL) YANG Data Model", 1265 draft-ietf-netmod-acl-model-08 (work in progress), July 1266 2016. 1268 [IEEE8021AB] 1269 Institute for Electrical and Electronics Engineers, "IEEE 1270 Standard for Local and Metropolitan Area Networks-- 1271 Station and Media Access Control Connectivity Discovery", 1272 n.d.. 1274 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 1275 Application and Support", STD 3, RFC 1123, 1276 DOI 10.17487/RFC1123, October 1989, 1277 . 1279 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1280 Requirement Levels", BCP 14, RFC 2119, 1281 DOI 10.17487/RFC2119, March 1997, 1282 . 1284 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1285 RFC 2131, DOI 10.17487/RFC2131, March 1997, 1286 . 1288 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1289 DOI 10.17487/RFC2818, May 2000, 1290 . 1292 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 1293 C., and M. Carney, "Dynamic Host Configuration Protocol 1294 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 1295 2003, . 1297 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1298 Resource Identifier (URI): Generic Syntax", STD 66, 1299 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1300 . 1302 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1303 Housley, R., and W. Polk, "Internet X.509 Public Key 1304 Infrastructure Certificate and Certificate Revocation List 1305 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1306 . 1308 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1309 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1310 . 1312 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1313 "Network Time Protocol Version 4: Protocol and Algorithms 1314 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1315 . 1317 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1318 the Network Configuration Protocol (NETCONF)", RFC 6020, 1319 DOI 10.17487/RFC6020, October 2010, 1320 . 1322 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 1323 Capabilities in Customer Premises Equipment (CPE) for 1324 Providing Residential IPv6 Internet Service", RFC 6092, 1325 DOI 10.17487/RFC6092, January 2011, 1326 . 1328 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 1329 Cheshire, "Internet Assigned Numbers Authority (IANA) 1330 Procedures for the Management of the Service Name and 1331 Transport Protocol Port Number Registry", BCP 165, 1332 RFC 6335, DOI 10.17487/RFC6335, August 2011, 1333 . 1335 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1336 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1337 . 1339 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 1340 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 1341 BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, 1342 . 1344 [RFC7299] Housley, R., "Object Identifier Registry for the PKIX 1345 Working Group", RFC 7299, DOI 10.17487/RFC7299, July 2014, 1346 . 1348 17.2. Informative References 1350 [FW95] Chapman, D. and E. Zwicky, "Building Internet Firewalls", 1351 January 1995. 1353 [IEEE8021AR] 1354 Institute for Electrical and Electronics Engineers, 1355 "Secure Device Identity", 1998. 1357 [ISO.8601.1988] 1358 International Organization for Standardization, "Data 1359 elements and interchange formats - Information interchange 1360 - Representation of dates and times", ISO Standard 8601, 1361 June 1988. 1363 [RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic 1364 Technology and the Internet", BCP 200, RFC 1984, 1365 DOI 10.17487/RFC1984, August 1996, 1366 . 1368 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1369 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 1370 . 1372 [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and 1373 IETF Protocol and Documentation Usage for IEEE 802 1374 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, 1375 October 2013, . 1377 [RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, 1378 "Architectural Considerations in Smart Object Networking", 1379 RFC 7452, DOI 10.17487/RFC7452, March 2015, 1380 . 1382 [RFC7488] Boucadair, M., Penno, R., Wing, D., Patil, P., and T. 1383 Reddy, "Port Control Protocol (PCP) Server Selection", 1384 RFC 7488, DOI 10.17487/RFC7488, March 2015, 1385 . 1387 Appendix A. Changes from Earlier Versions 1389 RFC Editor to remove this section prior to publication. 1391 Draft -00 to -01: * Fix cert trust text. * change supportInformation 1392 to meta-info * Add an informaitonal element in. * add urn registry 1393 and create first entry * add default elements 1395 Appendix B. Default MUD elements 1397 What follows is a MUD file that permits DNS traffic to a controller 1398 that is registered with the URN "urn:mud:dns" and traffic NTP to a 1399 controller that is registered "urn:mud:ntp". This is considered the 1400 default behavior and the ACEs are in effect appended to whatever 1401 other ACEs. To block DNS or NTP one repeats the matching statement 1402 but replace "permit" with deny. Because ACEs are processed in the 1403 order they are received, the defaults would not be reached. A MUD 1404 controller might further decide to optimize to simply not include the 1405 defaults when they are overriden. 1407 A complete MUD entry is included below. 1409 { 1410 "ietf-mud:meta-info": { 1411 "lastUpdate": "2016-09-27T15:10:24+02:00", 1412 "cacheValidity": 1440 1413 }, 1414 "ietf-acl:access-lists": { 1415 "ietf-acl:access-list": [ 1416 { 1417 "acl-name": "mud-53134-v4in", 1418 "acl-type": "ipv4-acl", 1419 "ietf-mud:packet-direction": "to-device", 1420 "access-list-entries": { 1421 "ace": [ 1422 { 1423 "rule-name": "entout0-in", 1424 "matches": { 1425 "ietf-mud:controller": "urn:mud:dns", 1426 "protocol": 17, 1427 "source-port-range": { 1428 "lower-port": 53, 1429 "upper-port": 53 1430 } 1431 }, 1432 "actions": { 1433 "permit": [ 1434 null 1435 ] 1436 } 1437 }, 1438 { 1439 "rule-name": "entout1-in", 1440 "matches": { 1441 "ietf-mud:controller": "urn:mud:dns", 1442 "protocol": 6, 1443 "source-port-range": { 1444 "lower-port": 53, 1445 "upper-port": 53 1446 } 1447 }, 1448 "actions": { 1449 "permit": [ 1450 null 1451 ] 1452 } 1453 }, 1454 { 1455 "rule-name": "entout2-in", 1456 "matches": { 1457 "ietf-mud:controller": "urn:mud:ntp", 1458 "protocol": 17, 1459 "source-port-range": { 1460 "lower-port": 123, 1461 "upper-port": 123 1462 } 1463 }, 1464 "actions": { 1465 "permit": [ 1466 null 1467 ] 1468 } 1469 } 1470 ] 1471 } 1472 }, 1473 { 1474 "acl-name": "mud-53134-v4out", 1475 "acl-type": "ipv4-acl", 1476 "ietf-mud:packet-direction": "from-device", 1477 "access-list-entries": { 1478 "ace": [ 1479 { 1480 "rule-name": "entout0-in", 1481 "matches": { 1482 "ietf-mud:controller": "urn:mud:dns", 1483 "protocol": 17, 1484 "source-port-range": { 1485 "lower-port": 53, 1486 "upper-port": 53 1487 } 1488 }, 1489 "actions": { 1490 "permit": [ 1491 null 1492 ] 1493 } 1494 }, 1495 { 1496 "rule-name": "entout1-in", 1497 "matches": { 1498 "ietf-mud:controller": "urn:mud:dns", 1499 "protocol": 6, 1500 "source-port-range": { 1501 "lower-port": 53, 1502 "upper-port": 53 1503 } 1504 }, 1505 "actions": { 1506 "permit": [ 1507 null 1508 ] 1509 } 1510 }, 1511 { 1512 "rule-name": "entout2-in", 1513 "matches": { 1514 "ietf-mud:controller": "urn:mud:ntp", 1515 "protocol": 17, 1516 "source-port-range": { 1517 "lower-port": 123, 1518 "upper-port": 123 1519 } 1520 }, 1521 "actions": { 1522 "permit": [ 1523 null 1524 ] 1525 } 1526 } 1527 ] 1528 } 1529 }, 1530 { 1531 "acl-name": "mud-53134-v6in", 1532 "acl-type": "ipv6-acl", 1533 "ietf-mud:packet-direction": "to-device", 1534 "access-list-entries": { 1535 "ace": [ 1536 { 1537 "rule-name": "entout0-in", 1538 "matches": { 1539 "ietf-mud:controller": "urn:mud:dns", 1540 "protocol": 17, 1541 "source-port-range": { 1542 "lower-port": 53, 1543 "upper-port": 53 1544 } 1545 }, 1546 "actions": { 1547 "permit": [ 1548 null 1549 ] 1550 } 1551 }, 1552 { 1553 "rule-name": "entout1-in", 1554 "matches": { 1555 "ietf-mud:controller": "urn:mud:dns", 1556 "protocol": 6, 1557 "source-port-range": { 1558 "lower-port": 53, 1559 "upper-port": 53 1560 } 1561 }, 1562 "actions": { 1563 "permit": [ 1564 null 1565 ] 1566 } 1567 }, 1568 { 1569 "rule-name": "entout2-in", 1570 "matches": { 1571 "ietf-mud:controller": "urn:mud:ntp", 1572 "protocol": 17, 1573 "source-port-range": { 1574 "lower-port": 123, 1575 "upper-port": 123 1576 } 1577 }, 1578 "actions": { 1579 "permit": [ 1580 null 1581 ] 1582 } 1583 } 1584 ] 1585 } 1586 }, 1587 { 1588 "acl-name": "mud-53134-v6out", 1589 "acl-type": "ipv6-acl", 1590 "ietf-mud:packet-direction": "from-device", 1591 "access-list-entries": { 1592 "ace": [ 1593 { 1594 "rule-name": "entout0-in", 1595 "matches": { 1596 "ietf-mud:controller": "urn:mud:dns", 1597 "protocol": 17, 1598 "source-port-range": { 1599 "lower-port": 53, 1600 "upper-port": 53 1601 } 1602 }, 1603 "actions": { 1604 "permit": [ 1605 null 1606 ] 1607 } 1608 }, 1609 { 1610 "rule-name": "entout1-in", 1611 "matches": { 1612 "ietf-mud:controller": "urn:mud:dns", 1613 "protocol": 6, 1614 "source-port-range": { 1615 "lower-port": 53, 1616 "upper-port": 53 1617 } 1618 }, 1619 "actions": { 1620 "permit": [ 1621 null 1622 ] 1623 } 1624 }, 1625 { 1626 "rule-name": "entout2-in", 1627 "matches": { 1628 "ietf-mud:controller": "urn:mud:ntp", 1629 "protocol": 17, 1630 "source-port-range": { 1631 "lower-port": 123, 1632 "upper-port": 123 1633 } 1634 }, 1635 "actions": { 1636 "permit": [ 1637 null 1638 ] 1639 } 1640 } 1641 ] 1642 } 1643 } 1644 ] 1645 } 1646 } 1648 Authors' Addresses 1650 Eliot Lear 1651 Cisco Systems 1652 Richtistrasse 7 1653 Wallisellen CH-8304 1654 Switzerland 1656 Phone: +41 44 878 9200 1657 Email: lear@cisco.com 1659 Ralph Droms 1661 Phone: +1 978 376 3731 1662 Email: rdroms@gmail.com 1664 Dan Romascanu 1666 Email: dromasca@gmail.com