idnits 2.17.1 draft-ietf-opsawg-mud-02.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 (November 30, 2016) is 2702 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-04 == Outdated reference: A later version (-21) exists of draft-ietf-netmod-acl-model-09 -- 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 -- Obsolete informational reference (is this intentional?): RFC 7042 (Obsoleted by RFC 9542) Summary: 3 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: June 3, 2017 6 D. Romascanu 7 November 30, 2016 9 Manufacturer Usage Description Specification 10 draft-ietf-opsawg-mud-02 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 June 3, 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 . . . . . . 22 90 12. Creating and Processing of Signed MUD Files . . . . . . . . . 23 91 12.1. Creating a MUD file signature . . . . . . . . . . . . . 23 92 12.2. Verifying a MUD file signature . . . . . . . . . . . . . 23 93 13. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 24 94 14. Security Considerations . . . . . . . . . . . . . . . . . . . 24 95 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 96 15.1. DHCPv4 and DHCPv6 Options . . . . . . . . . . . . . . . 26 97 15.2. PKIX Extensions . . . . . . . . . . . . . . . . . . . . 26 98 15.3. Well Known URI Suffix . . . . . . . . . . . . . . . . . 26 99 15.4. MIME Media-type Registration for MUD files . . . . . . . 26 100 15.5. LLDP IANA TLV Subtype Registry . . . . . . . . . . . . . 27 101 15.6. The MUD Well Known Universal Resource Name (URNs) . . . 28 102 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 103 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 104 17.1. Normative References . . . . . . . . . . . . . . . . . . 28 105 17.2. Informative References . . . . . . . . . . . . . . . . . 30 106 Appendix A. Changes from Earlier Versions . . . . . . . . . . . 31 107 Appendix B. Default MUD elements . . . . . . . . . . . . . . . . 32 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 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. In order to provide 515 for the broadest compatibility for the various transmission 516 mechanisms, the length of the URL for v1 MUST NOT exceed 255 octets. 518 "model" represents a device model as the manufacturer wishes to 519 represent it. It could be a brand name or something more specific. 520 It also may provide a means to indicate what version the product is. 521 Specifically if it has been updated in the field, this is the place 522 where evidence of that update would appear. The field should be 523 changed when the intended communication patterns of a device change. 524 While from a controller standpoint, only comparison and matching 525 operations are safe, it is envisioned that updates will require some 526 administrative review. Processing of this URL occurs as specified in 527 [RFC2818] and [RFC3986]. 529 6. The MUD YANG Model 531 file "ietf-mud@2016-07-20.yang"; 533 module ietf-mud { 534 yang-version 1.1; 535 namespace "urn:ietf:params:xml:ns:yang:ietf-mud"; 536 prefix "ietf-mud"; 538 import ietf-access-control-list { 539 prefix "acl"; 540 } 542 import ietf-yang-types { 543 prefix "yang"; 544 } 546 import ietf-inet-types { 547 prefix "inet"; 548 } 550 organization 551 "IETF OPSAWG (Ops Area) Working Group"; 553 contact 554 "WG Web: http://tools.ietf.org/wg/opsawg/ 555 WG List: opsawg@ietf.org 556 WG Chair: Warren Kumari 557 warren@kumari.net 558 WG Chair: Zhou Tianran 559 zhoutianran@huawei.com 560 Editor: Eliot Lear 561 lear@cisco.com 562 Editor: Ralph Droms 563 rdroms@cisco.com 564 "; 566 description 567 "This YANG module defines a component that augments the 568 IETF description of an access list. This specific module 569 focuses on additional filters that include local, model, 570 and same-manufacturer. 572 Copyright (c) 2016 IETF Trust and the persons identified as 573 the document authors. All rights reserved. 574 Redistribution and use in source and binary forms, with or 575 without modification, is permitted pursuant to, and subject 576 to the license terms contained in, the Simplified BSD 577 License set forth in Section 4.c of the IETF Trust's Legal 578 Provisions Relating to IETF Documents 579 (http://trustee.ietf.org/license-info). 580 This version of this YANG module is part of RFC XXXX; see 581 the RFC itself for full legal notices."; 583 revision "2016-07-20" { 584 description "Base version of MUD extensions to ACL model"; 585 reference "RFC XXXX: Manufacturer Usage Description Specification"; 586 } 588 typedef direction { 589 type enumeration { 590 enum to-device { 591 description "packets or flows destined to the target device"; 592 } 593 enum from-device { 594 description "packets or flows destined from 595 the target device"; 596 } 597 } 598 description "Which way are we talking about?"; 599 } 601 container metainfo { 603 description "Information about when support end(ed), and 604 when to refresh"; 606 leaf last-update { 607 type yang:date-and-time; 608 description "This is intended to be the time and date that 609 the MUD file was generated."; 610 } 612 leaf previous-mud-file { 613 type inet:uri; 614 description "Use to find the previous MUD file location 615 for auditing purposes."; 616 } 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 } 663 leaf same-manufacturer { 664 type empty; 665 description "expand to ACEs for each device 666 with the same origin"; 667 } 669 leaf model { 670 type string; 671 description "specific model (including version) for a 672 given manufacturer"; 673 } 675 leaf local-networks { 676 type empty; 677 description "this string is used to indicate networks 678 considered local in a given environment."; 679 } 680 leaf controller { 681 type inet:uri; 682 description "expands to one or more controllers for a 683 given service that is codified by inet:uri."; 684 } 685 leaf direction-initiated { 686 type direction; 687 description "which direction a flow was initiated"; 688 } 689 } 690 } 692 694 7. The Domain Name Extension to the ACL Model 696 This module specifies an extension to IETF-ACL model such that domain 697 names may be referenced by augmenting the "matches" element. 698 Different implementations may deploy differing methods to maintain 699 the mapping between IP address and domain name, if indeed any are 700 needed. However, the intent is that resources that are referred to 701 using a name should be authorized (or not) within an access list. 703 The structure of the change is as follows: 705 augment 706 /acl:access-lists/acl:acl/acl:access-list-entries 707 /acl:ace/acl:matches/acl:ace-type/acl:ace-ip: 708 +--rw src-dnsname? inet:host 709 +--rw dst-dnsname? inet:host 711 The choice of this particular point in the access-list model is based 712 on the assumption that we are in some way referring to IP-related 713 resources, as that is what the DNS returns. A domain name in our 714 context is defined in [RFC6991]. 716 The following elements are defined. 718 7.1. source-dnsname 720 The argument corresponds to a domain name of a source as specified by 721 inet:host. Depending on how the model is used, it may or may not be 722 resolved, as required by the implementation and circumstances. 724 7.2. destination-dnsname 726 The argument corresponds to a domain name of a destination as 727 specified by inet:host. Depending on how the model is used, it may 728 or may not be resolved, as required by the implementation and 729 circumstances. 731 7.3. The ietf-acldns Model 733 file "ietf-acldns@2007-07020.yang"; 735 module ietf-acldns { 736 yang-version 1.1; 737 namespace "urn:ietf:params:xml:ns:yang:ietf-acldns"; 738 prefix "ietf-acldns"; 740 import ietf-access-control-list { 741 prefix "acl"; 742 } 744 import ietf-inet-types { 745 prefix "inet"; 746 } 748 organization 749 "IETF OPSAWG (Ops Area) Working Group"; 751 contact 752 "WG Web: http://tools.ietf.org/wg/opsawg/ 753 WG List: opsawg@ietf.org 754 WG Chair: Warren Kumari 755 warren@kumari.net 756 WG Chair: Zhou Tianran 757 zhoutianran@huawei.com 758 Editor: Eliot Lear 759 lear@cisco.com 760 Editor: Ralph Droms 761 rdroms@cisco.com 762 "; 764 description 765 "This YANG module defines a component that augments the 766 IETF description of an access list to allow dns names 767 as matching criteria."; 769 revision "2016-07-20" { 770 description "Base version of dnsname extension of ACL model"; 771 reference "RFC XXXX: Manufacturer Usage Description Specification"; 772 } 774 augment "/acl:access-lists/acl:acl/" + 775 "acl:access-list-entries/acl:ace/" + 776 "acl:matches/acl:ace-type/acl:ace-ip" { 777 description "adding domain names to matching"; 779 leaf src-dnsname { 780 type inet:host; 781 description "domain name to be matched against"; 782 } 783 leaf dst-dnsname { 784 type inet:host; 785 description "domain name to be matched against"; 786 } 787 } 788 } 790 792 8. MUD File Example 794 This example contains two access lists that are intended to provide 795 outbound access to a cloud service on TCP port 443. 797 { 798 "ietf-mud:metainfo": { 799 "last-update": "2016-05-18T20:00:50Z", 800 "cache-validity": 1440 801 }, 802 "ietf-access-control-list:access-lists": { 803 "acl": [ { 804 "acl-name": "inbound-stuff", 805 "acl-type" : "ipv4-acl", 806 "ietf-mud:direction" : "to-device", 807 "access-list-entries": { 808 "ace": [ 809 { 810 "rule-name": "access-cloud", 811 "matches": { 812 "ietf-acldns:src-dnsname": 813 "lighting-system.example.com", 814 "protocol" : 6, 815 "source-port-range" : { 816 "lower-port" : 443, 817 "upper-port" : 443 818 } 819 }, 820 "actions" : { 821 "permit" : [null] 822 } 823 } 824 ] 825 } 826 }, 827 { 828 "acl-name": "outbound-stuff", 829 "acl-type" : "ipv4-acl", 830 "ietf-mud:direction" : "from-device", 831 "access-list-entries": { 832 "ace": [ 833 { 834 "rule-name": "access-cloud", 835 "matches": { 836 "ietf-acldns:dst-dnsname": 837 "lighting-system.example.com", 838 "protocol" : 6, 839 "destination-port-range" : { 840 "lower-port" : 443, 841 "upper-port" : 443 842 } 843 }, 844 "actions" : { 845 "permit" : [null] 846 } 847 } 848 ] 849 } 850 } 851 ] 852 } 853 } 855 9. The MUD URL DHCP Option 857 The IPv4 MUD URL client option has the following format: 859 +------+-----+------------------------------ 860 | code | len | MUD URL 861 +------+-----+------------------------------ 863 Code OPTION_MUD_URL_V4 (161) is assigned by IANA. len is a single 864 octet that indicates the length of the URL in octets. MUD URL is a 865 URL. MUD URLs MUST NOT exceed 255 octets. 867 The IPv6 MUD URL client option has the following format: 869 0 1 2 3 870 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 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | OPTION_MUD_URL_V6 | option-length | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | MUD URL | 875 | ... | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 OPTION_MUD_URL_V6 (TBD; assigned by IANA). 880 option-length contains the length of the URL in octets. 882 The intent of this option is to provide both a new device classifier 883 to the network as well as some recommended configuration to the 884 routers that implement policy. However, it is entirely the purview 885 of the network system as managed by the network administrator to 886 decide what to do with this information. The key function of this 887 option is simply to identify the type of device to the network in a 888 structured way such that the policy can be easily found with existing 889 toolsets. 891 9.1. Client Behavior 893 A DHCPv4 client MAY emit a DHCPv4 option and a DHCPv6 client MAY emit 894 DHCPv6 option. These options are singletons, as specified in 895 [RFC7227]. Because clients are intended to have at most one MUD URL 896 associated with them, they may emit at most one MUD URL option via 897 DHCPv4 and one MUD URL option via DHCPv6. In the case where both v4 898 and v6 DHCP options are emitted, the same URL MUST be used. 900 Clients SHOULD log or otherwise report improper acknowledgments from 901 servers, but they MUST NOT modify their MUD URL configuration based 902 on a server's response. The server's response is only an 903 acknowledgment that the server has processed the option, and promises 904 no specific network behavior to the client. In particular, it may 905 not be possible for the server to retrieve the file associated with 906 the MUD URL, or the local network administration may not wish to use 907 the usage description. Neither of these situations should be 908 considered in any way exceptional. 910 9.2. Server Behavior 912 A DHCP server may ignore these options or take action based on 913 receipt of these options. If a server successfully parses the option 914 and the URL, it MUST return the option with length field set to zero 915 and a corresponding null URL field as an acknowledgment. Even in 916 this circumstance, no specific network behavior is guaranteed. When 917 a server consumes this option, it will either forward the URL and 918 relevant client information to a network management system (such as 919 the giaddr), or it will retrieve the usage description by resolving 920 the URL. 922 DHCP servers may implement MUD functionality themselves or they may 923 pass along appropriate information to a network management system or 924 controller. A DHCP server that does process the MUD URL MUST adhere 925 to the process specified in [RFC2818] and [RFC5280] to validate the 926 TLS certificate of the web server hosting the MUD file. Those 927 servers will retrieve the file, process it, create and install the 928 necessary configuration on the relevant network element. Servers 929 SHOULD monitor the gateway for state changes on a given interface. A 930 DHCP server that does not provide MUD functionality and has forwarded 931 a MUD URL to a network management system MUST notify the network 932 management of any corresponding change to the DHCP state of the 933 client (such as expiration or explicit release of a network address 934 lease). 936 9.3. Relay Requirements 938 There are no additional requirements for relays. 940 10. The Manufacturer Usage Description (MUD) URL X.509 Extension 942 This section defines an X.509 non-critical certificate extension that 943 contains a single Uniform Resource Identifier (URI) that points to an 944 on-line Manufacturer Usage Description concerning the certificate 945 subject. URI must be represented as described in Section 7.4 of 946 [RFC5280]. 948 Any Internationalized Resource Identifiers (IRIs) MUST be mapped to 949 URIs as specified in Section 3.1 of [RFC3987] before they are placed 950 in the certificate extension. 952 The semantics of the URI are defined Section 5 of this document. 954 The choice of id-pe is based on guidance found in Section 4.2.2 of 955 [RFC5280]: 957 These extensions may be used to direct applications to on-line 958 information about the issuer or the subject. 960 The MUD URL is precisely that: online information about the 961 particular subject. 963 The new extension is identified as follows: 965 MUDURLExtnModule-2016 { iso(1) identified-organization(3) dod(6) 966 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 967 id-mod-mudURLExtn2016(TBD1) } 969 DEFINITIONS IMPLICIT TAGS ::= BEGIN 971 -- EXPORTS ALL -- 973 IMPORTS 974 EXTENSION 975 FROM PKIX-CommonTypes-2009 976 { iso(1) identified-organization(3) dod(6) internet(1) 977 security(5) mechanisms(5) pkix(7) id-mod(0) 978 id-mod-pkixCommon-02(57) } 980 id-pe 981 FROM PKIX1Explicit-2009 982 { iso(1) identified-organization(3) dod(6) internet(1) 983 security(5) mechanisms(5) pkix(7) id-mod(0) 984 id-mod-pkix1-explicit-02(51) } ; 985 MUDCertExtensions EXTENSION ::= { ext-MUDURL, ... } 986 ext-MUDURL EXTENSION ::= { SYNTAX MUDURLSyntax 987 IDENTIFIED BY id-pe-mud-url } 989 id-pe-mud-url OBJECT IDENTIFIER ::= { id-pe TBD2 } 991 MUDURLSyntax ::= IA5String 993 END 995 11. The Manufacturer Usage Description LLDP extension 997 The IEEE802.1AB Link Layer Discovery Protocol (LLDP) [IEEE8021AB] is 998 a one hop vendor-neutral link layer protocols used by end hosts 999 network devices for advertising their identity, capabilities, and 1000 neighbors on an IEEE 802 local area network. Its Type-Length-Value 1001 (TLV) design allows for 'vendor-specific' extensions to be defined. 1002 IANA has a registered IEEE 802 organizationally unique identifier 1003 (OUI) defined as documented in [RFC7042]. The MUD LLDP extension 1004 uses a subtype defined in this document to carry the MUD URL. 1006 The LLDP vendor specific frame has the following format: 1008 +--------+--------+----------+---------+-------------- 1009 |TLV Type| len | OUI |subtype | MUD URL 1010 | =127 | |= 00 00 5E| = 1 | 1011 |(7 bits)|(9 bits)|(3 octets)|(1 octet)|(1-255 octets) 1012 +--------+--------+----------+---------+-------------- 1014 where: 1016 o TLV Type = 127 indicates a vendor-specific TLV 1018 o len - indicates the TLV string length 1020 o OUI = 00 00 5E is the organizationally unique identifier of IANA 1022 o subtype = 1 (to be assigned by IANA for the MUD URL) 1024 o MUD URL - the length MUST NOT exceed 255 octets 1026 The intent of this extension is to provide both a new device 1027 classifier to the network as well as some recommended configuration 1028 to the routers that implement policy. However, it is entirely the 1029 purview of the network system as managed by the network administrator 1030 to decide what to do with this information. The key function of this 1031 extension is simply to identify the type of device to the network in 1032 a structured way such that the policy can be easily found with 1033 existing toolsets. 1035 Hosts, routers, or other network devices that implement this option 1036 are intended to have at most one MUD URL associated with them, so 1037 they may transmit at most one MUD URL value. 1039 Hosts, routers, or other network devices that implement this option 1040 may ignore these options or take action based on receipt of these 1041 options. For example they may fill in information in the respective 1042 extensions of the LLDP Management Information Base (LLDP MIB). LLDP 1043 operates in a one-way direction. LLDPDUs are not exchanged as 1044 information requests by one device and response sent by another 1045 device. The other devices do not acknowledge LLDP information 1046 received from a device. No specific network behavior is guaranteed. 1047 When a device consumes this extension, it may either forward the URL 1048 and relevant remote device information to a network management 1049 system, or it will retrieve the usage description by resolving the 1050 URL. 1052 12. Creating and Processing of Signed MUD Files 1054 Because MUD files contain information that may be used to configure 1055 network access lists, they are sensitive. To insure that they have 1056 not been tampered with, it is important that they be signed. We make 1057 use of DER-encoded Cryptographic Message Syntax (CMS) [RFC5652] for 1058 this purpose. 1060 12.1. Creating a MUD file signature 1062 A MUD file MUST be signed using CMS as an opaque binary object. In 1063 order to make successful verification more likely, intermediate 1064 certificates SHOULD be included. The signature is stored at the same 1065 location as the MUD URL but with the suffix of ".p7s". Signatures 1066 are transferred using content-type "Application/pkcs7-signature". 1068 For example: 1070 % openssl cms -sign -signer mancertfile -inkey mankey \ 1071 -in mudfile -binary -outform DER - \ 1072 -certfile intermediatecert -out mudfile.p7s 1074 Note: A MUD file may need to be resigned if the signature expires. 1076 12.2. Verifying a MUD file signature 1078 Prior to retrieving a MUD file the MUD controller SHOULD retrieve the 1079 MUD signature file using the MUD URL with a suffix of ".p7s". For 1080 example, if the MUD URL is "https://example.com/.well-known/v1/ 1081 modela", the MUD signature URL will be "https://example.com/.well- 1082 known/v1/modela.p7s". 1084 Upon retrieving a MUD file, a MUD controller MUST validate the 1085 signature of the file before continuing with further processing. A 1086 MUD controller SHOULD produce an error and it MUST cease all 1087 processing of that file if the signature cannot be validated. It is 1088 important that MUD controllers have some reason to trust the 1089 certificates they are seeing. Therefore, it is RECOMMENDED that new 1090 signers be validated either directly by an administrator or by a 1091 service that has some reason to believe that the signer is a good 1092 actor. 1094 For Example: 1096 % openssl cms -verify -in mudfile.p7s -inform DER -content mudfile 1098 Note the additional step of verifying the common trust root. 1100 13. Extensibility 1102 One of our design goals is to see that MUD files are able to be 1103 understood by as broad a cross-section of systems as is possible. 1104 Coupled with the fact that we have also chosen to leverage existing 1105 mechanisms, we are left with no ability to negotiate extensions and a 1106 limited desire for those extensions in any event. A such, a two-tier 1107 extensibility framework is employed, as follows: 1109 1. At a coarse grain, a protocol version is included in a MUD URL. 1110 This memo specifies MUD version 1. Any and all changes are 1111 entertained when this version is bumped. Transition approaches 1112 between versions would be a matter for discussion in future 1113 versions. 1115 2. At a finer grain, only extensions that would not incur additional 1116 risk to the device are permitted. Specifically, augmenting of 1117 the metainfo container is permitted with the understanding that 1118 such additions may be ignored. In addition, augmentation of the 1119 ACL model is permitted so long as it remains safe for a given ACE 1120 to be ignored by the MUD Controller or the network elements it 1121 configures. Most specifically, is is not permitted to include as 1122 an augmentation that modifies "deny" behavior without bumping the 1123 version. Furthermore, implementations that are not able to parse 1124 a component of the ACE array MUST ignore the entire array entry 1125 (e.g., not the entire array) and MAY ignore the entire MUD file. 1127 14. Security Considerations 1129 Based on the means a URL is procured, a device may be able to lie 1130 about what it is, thus gaining additional network access. There are 1131 several means to limit risk in this case. The most obvious is to 1132 only believe devices that make use of certificate-based 1133 authentication such as IEEE 802.1AR certificates. When those 1134 certificates are not present, devices claiming to be of a certain 1135 manufacturer SHOULD NOT be included in that manufacturer grouping 1136 without additional validation of some form. This will occur when it 1137 makes use of primitives such as "manufacturer" for the purpose of 1138 accessing devices of a particular type. 1140 Network management systems SHOULD NOT accept a usage description for 1141 a device with the same MAC address that has indicated a change of 1142 authority without some additional validation (such as review of the 1143 class). New devices that present some form of unauthenticated MUD 1144 URL SHOULD be validated by some external means when they would be 1145 otherwise be given increased network access. 1147 It may be possible for a rogue manufacturer to inappropriately 1148 exercise the MUD file parser, in order to exploit a vulnerability. 1149 There are three recommended approaches to address this threat. The 1150 first is to validate the signature of the MUD file. The second is to 1151 have a system do a primary scan of the file to ensure that it is both 1152 parseable and believable at some level. MUD files will likely be 1153 relatively small, to start with. The number of ACEs used by any 1154 given device should be relatively small as well. Second, it may be 1155 useful to limit retrieval of MUD URLs to only those sites that are 1156 known to have decent web reputations. 1158 Use of a URL necessitates the use of domain names. If a domain name 1159 changes ownership, the new owner of that domain may be able to 1160 provide MUD files that MUD controllers would consider valid. There 1161 are a few approaches that can mitigate this attack. First, MUD file 1162 servers SHOULD cache certificates used by the MUD file server. When 1163 a new certificate is retrieved for whatever reason, the MUD 1164 controller should check to see if ownership of the domain has 1165 changed. A fair programmatic approximation of this is when the name 1166 servers for the domain have changed. If the actual MUD file has 1167 changed, the controller MAY check the WHOIS database to see if 1168 registration ownership of a domain has changed. If a change has 1169 occured, or if for some reason it is not possible to determine 1170 whether ownership has changed, further review may be warranted. 1171 Note, this remediation does not take into account the case of a 1172 device that was produced long ago and only recently fielded, or the 1173 case where a new MUD controller has been installed. 1175 The release of a MUD URL by a device reveals what the device is, and 1176 provides an attacker with guidance on what vulnerabilities may be 1177 present. This is a security consideration. 1179 While the MUD URL itself is not intended to be unique to a specific 1180 device, the release of the URL may aid an observer in identifying 1181 individuals when combined with other information. This is a privacy 1182 consideration. 1184 In addressing both of these concerns, implementors should take into 1185 account what other information they are advertising through 1186 mechanisms such as mDNS[RFC6872], how a device might otherwise be 1187 identified, perhaps through how it behaves when it is connected to 1188 the network, whether a device is intended to be used by individuals 1189 or carry personal identifying information, and then apply appropriate 1190 data minimization techniques. One approach is to make use of EAP-TLS 1191 (cited above) as the means to share information with the network. 1192 Network devices may also assist in limiting access to the MUD-URL 1193 through the use of mechanisms such as DHCPv6-Shield [RFC7610]. 1195 15. IANA Considerations 1197 15.1. DHCPv4 and DHCPv6 Options 1199 The IANA has allocated option 161 in the Dynamic Host Configuration 1200 Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters registry 1201 for the MUD DHCPv4 option. 1203 IANA is requested to allocated the DHCPv4 and v6 options as specified 1204 in Section 9. 1206 15.2. PKIX Extensions 1208 IANA is kindly requested to make the following assignments for: 1210 o The MUDURLExtnModule-2016 ASN.1 module in the "SMI Security for 1211 PKIX Module Identifier" registry (1.3.6.1.5.5.7.0). 1213 o id-pe-mud-url object identifier from the "SMI Security for PKIX 1214 Certificate Extension" registry (1.3.6.1.5.5.7.1). 1216 The use fo these values is specified in Section 10. 1218 15.3. Well Known URI Suffix 1220 The IANA has allocated the URL suffix of "mud" as follows: 1222 o URI Suffix: "mud" o Specification documents: this document o 1223 Related information: n/a 1225 15.4. MIME Media-type Registration for MUD files 1227 The following media-type is defined for transfer of MUD file: 1229 o Type name: application 1230 o Subtype name: mud+json 1231 o Required parameters: n/a 1232 o Optional parameters: n/a 1233 o Encoding considerations: 8bit; application/mud+json values 1234 are represented as a JSON object; UTF-8 encoding SHOULD be 1235 employed. 1236 o Security considerations: See {{secon}} of this document. 1237 o Interoperability considerations: n/a 1238 o Published specification: this document 1239 o Applications that use this media type: MUD controllers as 1240 specified by this document. 1241 o Fragment identifier considerations: n/a 1242 o Additional information: 1244 Magic number(s): n/a 1245 File extension(s): n/a 1246 Macintosh file type code(s): n/a 1248 o Person & email address to contact for further information: 1249 Eliot Lear , Ralph Droms 1250 o Intended usage: COMMON 1251 o Restrictions on usage: none 1253 o Author: Eliot Lear , Ralph Droms 1254 o Change controller: IESG 1255 o Provisional registration? (standards tree only): No. 1257 15.5. LLDP IANA TLV Subtype Registry 1259 IANA is requested to create a new registry for IANA Link Layer 1260 Discovery Protocol (LLDP) TLV subtype values. The recommended policy 1261 for this registry is Expert Review. The maximum number of entries in 1262 the registry is 256. 1264 IANA is required to populate the initial registry with the value: 1266 LLDP subtype value = 1 (All the other 255 values should be initially 1267 marked as 'Unassigned'.) 1269 Description = the Manufacturer Usage Description (MUD) Uniform 1270 Resource Locator (URL) 1272 Reference = < this document > 1274 15.6. The MUD Well Known Universal Resource Name (URNs) 1276 The following parameter registry is requested to be added in 1277 accordance with [RFC3553] 1279 Registry name: "urn:ietf:params:mud" is requested. 1280 Specification: this document 1281 Repository: this document 1282 Index value: Encoded identically to a TCP/UDP port service name, as 1283 specified in Section 5.1 of [RFC6335] 1285 The following entries should be added to the "urn:ietf:params:mud" 1286 name space: 1288 "urn:ietf:params:mud:dns" refers to the service specified by 1289 [RFC1123]. "urn:ietf:params:mud:ntp" refers to the service specified 1290 by [RFC5905]. 1292 16. Acknowledgments 1294 The authors would like to thank Einar Nilsen-Nygaard, Bernie Volz, 1295 Tom Gindin, Brian Weis, Sandeep Kumar, Thorsten Dahm, John Bashinski, 1296 Steve Rich, Jim Bieda, and Dan Wing for their valuable advice and 1297 reviews. Russ Housley entirely rewrote Section 10 to be a complete 1298 module. Adrian Farrel provided the basis for privacy considerations 1299 text. The remaining errors in this work are entirely the 1300 responsibility of the author. 1302 17. References 1304 17.1. Normative References 1306 [I-D.ietf-anima-bootstrapping-keyinfra] 1307 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 1308 S., and K. Watsen, "Bootstrapping Remote Secure Key 1309 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 1310 keyinfra-04 (work in progress), October 2016. 1312 [I-D.ietf-netmod-acl-model] 1313 Bogdanovic, D., Koushik, K., Huang, L., and D. Blair, 1314 "Network Access Control List (ACL) YANG Data Model", 1315 draft-ietf-netmod-acl-model-09 (work in progress), October 1316 2016. 1318 [IEEE8021AB] 1319 Institute for Electrical and Electronics Engineers, "IEEE 1320 Standard for Local and Metropolitan Area Networks-- 1321 Station and Media Access Control Connectivity Discovery", 1322 n.d.. 1324 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 1325 Application and Support", STD 3, RFC 1123, 1326 DOI 10.17487/RFC1123, October 1989, 1327 . 1329 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1330 Requirement Levels", BCP 14, RFC 2119, 1331 DOI 10.17487/RFC2119, March 1997, 1332 . 1334 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1335 RFC 2131, DOI 10.17487/RFC2131, March 1997, 1336 . 1338 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1339 DOI 10.17487/RFC2818, May 2000, 1340 . 1342 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 1343 C., and M. Carney, "Dynamic Host Configuration Protocol 1344 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 1345 2003, . 1347 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1348 Resource Identifier (URI): Generic Syntax", STD 66, 1349 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1350 . 1352 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 1353 Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, 1354 January 2005, . 1356 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1357 Housley, R., and W. Polk, "Internet X.509 Public Key 1358 Infrastructure Certificate and Certificate Revocation List 1359 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1360 . 1362 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1363 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1364 . 1366 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1367 "Network Time Protocol Version 4: Protocol and Algorithms 1368 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1369 . 1371 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1372 the Network Configuration Protocol (NETCONF)", RFC 6020, 1373 DOI 10.17487/RFC6020, October 2010, 1374 . 1376 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 1377 Capabilities in Customer Premises Equipment (CPE) for 1378 Providing Residential IPv6 Internet Service", RFC 6092, 1379 DOI 10.17487/RFC6092, January 2011, 1380 . 1382 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 1383 Cheshire, "Internet Assigned Numbers Authority (IANA) 1384 Procedures for the Management of the Service Name and 1385 Transport Protocol Port Number Registry", BCP 165, 1386 RFC 6335, DOI 10.17487/RFC6335, August 2011, 1387 . 1389 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1390 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1391 . 1393 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 1394 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 1395 BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, 1396 . 1398 [RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: 1399 Protecting against Rogue DHCPv6 Servers", BCP 199, 1400 RFC 7610, DOI 10.17487/RFC7610, August 2015, 1401 . 1403 17.2. Informative References 1405 [FW95] Chapman, D. and E. Zwicky, "Building Internet Firewalls", 1406 January 1995. 1408 [IEEE8021AR] 1409 Institute for Electrical and Electronics Engineers, 1410 "Secure Device Identity", 1998. 1412 [ISO.8601.1988] 1413 International Organization for Standardization, "Data 1414 elements and interchange formats - Information interchange 1415 - Representation of dates and times", ISO Standard 8601, 1416 June 1988. 1418 [RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic 1419 Technology and the Internet", BCP 200, RFC 1984, 1420 DOI 10.17487/RFC1984, August 1996, 1421 . 1423 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1424 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 1425 . 1427 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 1428 IETF URN Sub-namespace for Registered Protocol 1429 Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 1430 2003, . 1432 [RFC6872] Gurbani, V., Ed., Burger, E., Ed., Anjali, T., Abdelnur, 1433 H., and O. Festor, "The Common Log Format (CLF) for the 1434 Session Initiation Protocol (SIP): Framework and 1435 Information Model", RFC 6872, DOI 10.17487/RFC6872, 1436 February 2013, . 1438 [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and 1439 IETF Protocol and Documentation Usage for IEEE 802 1440 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, 1441 October 2013, . 1443 [RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, 1444 "Architectural Considerations in Smart Object Networking", 1445 RFC 7452, DOI 10.17487/RFC7452, March 2015, 1446 . 1448 [RFC7488] Boucadair, M., Penno, R., Wing, D., Patil, P., and T. 1449 Reddy, "Port Control Protocol (PCP) Server Selection", 1450 RFC 7488, DOI 10.17487/RFC7488, March 2015, 1451 . 1453 Appendix A. Changes from Earlier Versions 1455 RFC Editor to remove this section prior to publication. 1457 Draft -01 to -02: * Update IANA considerations * Accept Russ Housley 1458 rewrite of X.509 text * Include privacy considerations text * Redo 1459 the URL limit. Still 255 bytes, but now stated in the URL 1460 definition. * Change URI registration to be under urn:ietf:params 1462 Draft -00 to -01: * Fix cert trust text. * change supportInformation 1463 to meta-info * Add an informaitonal element in. * add urn registry 1464 and create first entry * add default elements 1466 Appendix B. Default MUD elements 1468 What follows is a MUD file that permits DNS traffic to a controller 1469 that is registered with the URN "urn:ietf:params:mud:dns" and traffic 1470 NTP to a controller that is registered "urn:ietf:params:mud:ntp". 1471 This is considered the default behavior and the ACEs are in effect 1472 appended to whatever other ACEs. To block DNS or NTP one repeats the 1473 matching statement but replace "permit" with deny. Because ACEs are 1474 processed in the order they are received, the defaults would not be 1475 reached. A MUD controller might further decide to optimize to simply 1476 not include the defaults when they are overriden. 1478 A complete MUD entry is included below. 1480 { 1481 "ietf-mud:meta-info": { 1482 "lastUpdate": "2016-09-27T15:10:24+02:00", 1483 "cacheValidity": 1440 1484 }, 1485 "ietf-acl:access-lists": { 1486 "ietf-acl:access-list": [ 1487 { 1488 "acl-name": "mud-53134-v4in", 1489 "acl-type": "ipv4-acl", 1490 "ietf-mud:packet-direction": "to-device", 1491 "access-list-entries": { 1492 "ace": [ 1493 { 1494 "rule-name": "entout0-in", 1495 "matches": { 1496 "ietf-mud:controller": "urn:ietf:params:mud:dns", 1497 "protocol": 17, 1498 "source-port-range": { 1499 "lower-port": 53, 1500 "upper-port": 53 1501 } 1502 }, 1503 "actions": { 1504 "permit": [ 1505 null 1506 ] 1508 } 1509 }, 1510 { 1511 "rule-name": "entout1-in", 1512 "matches": { 1513 "ietf-mud:controller": "urn:ietf:params:mud:dns", 1514 "protocol": 6, 1515 "source-port-range": { 1516 "lower-port": 53, 1517 "upper-port": 53 1518 } 1519 }, 1520 "actions": { 1521 "permit": [ 1522 null 1523 ] 1524 } 1525 }, 1526 { 1527 "rule-name": "entout2-in", 1528 "matches": { 1529 "ietf-mud:controller": "urn:ietf:params:mud:ntp", 1530 "protocol": 17, 1531 "source-port-range": { 1532 "lower-port": 123, 1533 "upper-port": 123 1534 } 1535 }, 1536 "actions": { 1537 "permit": [ 1538 null 1539 ] 1540 } 1541 } 1542 ] 1543 } 1544 }, 1545 { 1546 "acl-name": "mud-53134-v4out", 1547 "acl-type": "ipv4-acl", 1548 "ietf-mud:packet-direction": "from-device", 1549 "access-list-entries": { 1550 "ace": [ 1551 { 1552 "rule-name": "entout0-in", 1553 "matches": { 1554 "ietf-mud:controller": "urn:ietf:params:mud:dns", 1555 "protocol": 17, 1556 "source-port-range": { 1557 "lower-port": 53, 1558 "upper-port": 53 1559 } 1560 }, 1561 "actions": { 1562 "permit": [ 1563 null 1564 ] 1565 } 1566 }, 1567 { 1568 "rule-name": "entout1-in", 1569 "matches": { 1570 "ietf-mud:controller": "urn:ietf:params:mud:dns", 1571 "protocol": 6, 1572 "source-port-range": { 1573 "lower-port": 53, 1574 "upper-port": 53 1575 } 1576 }, 1577 "actions": { 1578 "permit": [ 1579 null 1580 ] 1581 } 1582 }, 1583 { 1584 "rule-name": "entout2-in", 1585 "matches": { 1586 "ietf-mud:controller": "urn:ietf:params:mud:ntp", 1587 "protocol": 17, 1588 "source-port-range": { 1589 "lower-port": 123, 1590 "upper-port": 123 1591 } 1592 }, 1593 "actions": { 1594 "permit": [ 1595 null 1596 ] 1597 } 1598 } 1599 ] 1600 } 1601 }, 1602 { 1603 "acl-name": "mud-53134-v6in", 1604 "acl-type": "ipv6-acl", 1605 "ietf-mud:packet-direction": "to-device", 1606 "access-list-entries": { 1607 "ace": [ 1608 { 1609 "rule-name": "entout0-in", 1610 "matches": { 1611 "ietf-mud:controller": "urn:ietf:params:mud:dns", 1612 "protocol": 17, 1613 "source-port-range": { 1614 "lower-port": 53, 1615 "upper-port": 53 1616 } 1617 }, 1618 "actions": { 1619 "permit": [ 1620 null 1621 ] 1622 } 1623 }, 1624 { 1625 "rule-name": "entout1-in", 1626 "matches": { 1627 "ietf-mud:controller": "urn:params:mud:dns", 1628 "protocol": 6, 1629 "source-port-range": { 1630 "lower-port": 53, 1631 "upper-port": 53 1632 } 1633 }, 1634 "actions": { 1635 "permit": [ 1636 null 1637 ] 1638 } 1639 }, 1640 { 1641 "rule-name": "entout2-in", 1642 "matches": { 1643 "ietf-mud:controller": "urn:ietf:params:mud:ntp", 1644 "protocol": 17, 1645 "source-port-range": { 1646 "lower-port": 123, 1647 "upper-port": 123 1648 } 1649 }, 1650 "actions": { 1651 "permit": [ 1652 null 1653 ] 1654 } 1655 } 1656 ] 1657 } 1658 }, 1659 { 1660 "acl-name": "mud-53134-v6out", 1661 "acl-type": "ipv6-acl", 1662 "ietf-mud:packet-direction": "from-device", 1663 "access-list-entries": { 1664 "ace": [ 1665 { 1666 "rule-name": "entout0-in", 1667 "matches": { 1668 "ietf-mud:controller": "urn:ietf:params:mud:dns", 1669 "protocol": 17, 1670 "source-port-range": { 1671 "lower-port": 53, 1672 "upper-port": 53 1673 } 1674 }, 1675 "actions": { 1676 "permit": [ 1677 null 1678 ] 1679 } 1680 }, 1681 { 1682 "rule-name": "entout1-in", 1683 "matches": { 1684 "ietf-mud:controller": "urn:ietf:params:mud:dns", 1685 "protocol": 6, 1686 "source-port-range": { 1687 "lower-port": 53, 1688 "upper-port": 53 1689 } 1690 }, 1691 "actions": { 1692 "permit": [ 1693 null 1694 ] 1695 } 1696 }, 1697 { 1698 "rule-name": "entout2-in", 1699 "matches": { 1700 "ietf-mud:controller": "urn:ietf:params:mud:ntp", 1701 "protocol": 17, 1702 "source-port-range": { 1703 "lower-port": 123, 1704 "upper-port": 123 1705 } 1706 }, 1707 "actions": { 1708 "permit": [ 1709 null 1710 ] 1711 } 1712 } 1713 ] 1714 } 1715 } 1716 ] 1717 } 1718 } 1720 Authors' Addresses 1722 Eliot Lear 1723 Cisco Systems 1724 Richtistrasse 7 1725 Wallisellen CH-8304 1726 Switzerland 1728 Phone: +41 44 878 9200 1729 Email: lear@cisco.com 1731 Ralph Droms 1733 Phone: +1 978 376 3731 1734 Email: rdroms@gmail.com 1736 Dan Romascanu 1738 Email: dromasca@gmail.com