idnits 2.17.1 draft-ietf-opsawg-mud-03.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 (January 05, 2017) is 2667 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: July 9, 2017 6 D. Romascanu 7 January 05, 2017 9 Manufacturer Usage Description Specification 10 draft-ietf-opsawg-mud-03 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 July 9, 2017. 37 Copyright Notice 39 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . 9 63 3.1. last-update . . . . . . . . . . . . . . . . . . . . . . . 9 64 3.2. previous-mud-file . . . . . . . . . . . . . . . . . . . . 9 65 3.3. cache-validity . . . . . . . . . . . . . . . . . . . . . 9 66 3.4. masa-server . . . . . . . . . . . . . . . . . . . . . . . 10 67 3.5. is-supported . . . . . . . . . . . . . . . . . . . . . . 10 68 3.6. systeminfo . . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . 11 74 3.12. controller . . . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . . . . 18 84 9. The MUD URL DHCP Option . . . . . . . . . . . . . . . . . . . 19 85 9.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 20 86 9.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 20 87 9.3. Relay Requirements . . . . . . . . . . . . . . . . . . . 21 88 10. The Manufacturer Usage Description (MUD) URL X.509 Extension 21 89 11. The Manufacturer Usage Description LLDP extension . . . . . . 22 90 12. Creating and Processing of Signed MUD Files . . . . . . . . . 24 91 12.1. Creating a MUD file signature . . . . . . . . . . . . . 24 92 12.2. Verifying a MUD file signature . . . . . . . . . . . . . 24 93 13. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 25 94 14. Security Considerations . . . . . . . . . . . . . . . . . . . 25 95 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 96 15.1. DHCPv4 and DHCPv6 Options . . . . . . . . . . . . . . . 27 97 15.2. PKIX Extensions . . . . . . . . . . . . . . . . . . . . 27 98 15.3. Well Known URI Suffix . . . . . . . . . . . . . . . . . 27 99 15.4. MIME Media-type Registration for MUD files . . . . . . . 27 100 15.5. LLDP IANA TLV Subtype Registry . . . . . . . . . . . . . 28 101 15.6. The MUD Well Known Universal Resource Name (URNs) . . . 29 102 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 103 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 104 17.1. Normative References . . . . . . . . . . . . . . . . . . 29 105 17.2. Informative References . . . . . . . . . . . . . . . . . 31 106 Appendix A. Changes from Earlier Versions . . . . . . . . . . . 33 107 Appendix B. Default MUD elements . . . . . . . . . . . . . . . . 33 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 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. Various means may be used to 214 communicate that certificate, including Tunnel Extensible 215 Authentication Protocol (TEAP) [RFC7170]. Finally, an LLDP frame is 216 defined. 218 1.4. Types of Policies 220 When the MUD URL is resolved, the MUD controller retrieves a file 221 that describes what sort of communications a device is designed to 222 have. The manufacturer may specify either specific hosts for cloud 223 based services or certain classes for access within an operational 224 network. An example of a class might be "devices of a specified 225 manufacturer type", where the manufacturer type itself is indicated 226 simply by the authority of the MUD URL. Another example might to 227 allow or disallow local access. Just like other policies, these may 228 be combined. For example: 230 Allow access to host controller.example.com with QoS AF11 231 Allow access to devices of the same manufacturer 232 Allow access to and from controllers who need to speak COAP 233 Allow access to local DNS/DHCP 234 Deny all other access 236 To add a bit more depth that should not be a stretch of anyone's 237 imagination, one could also make use of port-based access lists. 238 Thus a printer might have a description that states: 240 Allow access for port IPP or port LPD 241 Allow local access for port HTTP 242 Deny all other access 244 In this way anyone can print to the printer, but local access would 245 be required for the management interface. 247 The files that are retrieved are intended to be closely aligned to 248 existing network architectures so that they are easy to deploy. We 249 make use of YANG [RFC6020] because of the time and effort spent to 250 develop accurate and adequate models for use by network devices. 251 JSON is used as a serialization for compactness and readability, 252 relative to XML. 254 The YANG modules specified here are extensions of 255 [I-D.ietf-netmod-acl-model]. The extensions to this model allow for 256 a manufacturer to express classes of systems that a manufacturer 257 would find necessary for the proper function of the device. Two 258 modules are specified. The first module specifies a means for domain 259 names to be used in ACLs so that devices that have their controllers 260 in the cloud may be appropriately authorized with domain names, where 261 the mapping of those names to addresses may rapidly change. 263 The second module abstracts away IP addresses into certain classes 264 that are instantiated into actual IP addresses through local 265 processing. Through these classes, manufacturers can specify how the 266 device is designed to communicate, so that network elements can be 267 configured by local systems that have local topological knowledge. 268 That is, the deployment populates the classes that the manufacturer 269 specifies. 271 Because manufacturers do not know who will be using their devices, it 272 is important for functionality referenced in usage descriptions to be 273 relatively ubiquitous, and therefore, mature. Therefore, only a a 274 limited subset YANG-based configuration of is permitted in a MUD 275 file. 277 1.5. Terminology 279 MUD: manufacturer usage description. 281 MUD file: a file containing YANG-based JSON that describes a 282 recommended behavior. 284 MUD file server: a web server that hosts a MUD file. 286 MUD controller: the system that requests and receives the MUD file 287 from the MUD server. After it has processed a MUD file it may 288 direct changes to relevant network elements. 290 MUD URL: a URL that can be used by the MUD controller to receive the 291 MUD file. 293 Thing: the end device that emits a MUD URL. 295 Manufacturer: the entity that configures the Thing to emit the MUD 296 URL and the one who asserts a recommendation in a MUD file. The 297 manufacturer might not always be the entity that constructs a 298 device. It could, for instance, be a systems integrator, or even 299 a component provider. 301 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 302 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 303 document are to be interpreted as described in [RFC2119]. 305 1.6. The Manufacturer Usage Description Architecture 307 With these components laid out we now have the basis for an 308 archicture. This leads us to ASCII art. 310 ......................................... 311 . ____________ . _____________ 312 . | | . | | 313 . | MUD |----->get URL->| MUD | 314 . | Controller | .(https) | File Server | 315 . End system network |____________|<--MUD file<--<|_____________| 316 . . . 317 . . . 318 . _______ _________ . 319 .| | (dhcp et al) | router | . 320 .| Thing |---->MUD URL-->| or | . 321 .|_______| | switch | . 322 . |_________| . 323 ......................................... 325 Figure 1: MUD Architecture 327 In the above diagram, the switch or router collects MUD URLs and 328 forwards them to the network management system for processing. This 329 happens in different ways, depending on how the URI is communicated. 330 For instance, in the case of DHCP, the DHCP server might receive the 331 URI and then process it. In the case of IEEE 802.1X, the switch 332 would tunnel the URI via a certificate to the authentication server, 333 who would then process it. One method to do this is TEAP, described 334 in [RFC7170]. The certificate extension is described below. 336 The information returned by the web site is valid for the duration of 337 the device's connection, or as specified in the description. Thus if 338 the device is mobile, when it moves on, any configuration in the 339 switch is removed. Similarly, from time to time the description may 340 be refreshed, based on new capabilities or communication patterns or 341 vulnerabilities. 343 The web site is typically run by or on behalf of the manufacturer. 344 Its domain name is that of the authority found in the MUD URL. For 345 legacy cases where Things cannot emit a URL, if the switch is able to 346 determine the appropriate URI, it may proxy it, the trivial cases 347 being a map between some registered device or port and a URL. 349 2. The MUD Model and Semantic Meaning 351 A MUD file consists of JSON based on a YANG model. For purposes of 352 MUD, the elements that can be modified are access lists as augmented 353 by this model. The MUD file is limited to the serialization of a 354 small number of YANG schema, including the models specified in the 355 following documents: 357 o [I-D.ietf-netmod-acl-model] 359 o [RFC6991] 361 Publishers of MUD files MUST NOT include other elements except as 362 described in Section 13, and MUST only contain information relevant 363 to the device being described. Devices parsing MUD files MUST cease 364 processing if they find other elements. 366 This module is structured into three parts. The first container 367 holds information that is relevant to retrieval and validity of the 368 MUD file itself. The second container augments the access list to 369 indicate direction the ACL is to be applied. The final container 370 augments the matching container of the ACL model to add several 371 elements that are relevant to the MUD URL, or other otherwise 372 abstracted for use within a local environment. 374 module: ietf-mud 375 +--rw meta-info 376 +--rw last-update? yang:date-and-time 377 +--rw previous-mud-file? yang:uri 378 +--rw cache-validity? uint32 379 +--rw masa-server? inet:uri 380 +--rw is-supported? boolean 381 augment /acl:access-lists/acl:acl: 382 +--rw packet-direction? direction 383 augment /acl:access-lists/acl:acl 384 /acl:access-list-entries/acl:ace/acl:matches: 385 +--rw manufacturer? inet:host 386 +--rw same-manufacturer? empty 387 +--rw model? string 388 +--rw local-networks? empty 389 +--rw controller? inet:uri 390 +--rw direction-initiated? direction 392 3. Element Definitions 394 The following elements are defined. 396 3.1. last-update 398 This is a date-and-time value of the last time the MUD file was 399 updated. This is akin to a version number. Its form is taken from 400 [RFC6991] which, for those keeping score, turn was taken from 401 Section 5.6 of [RFC3339], which was taken from [ISO.8601.1988]. 403 3.2. previous-mud-file 405 This is a URL that should point to the previous MUD URL for auditing 406 purposes. Because it should not be necessary to resign a MUD file 407 when a new one is released, the archival location of a current MUD 408 file should be identified prior to its release. Note the signature 409 file MUST also be available. For example, if previous-mud-file is 410 set to "https://example.com/.mud/v1/xxx", the corresponding signature 411 would be found at "https://example.com/.mud/v1/xxx.p7s". 413 3.3. cache-validity 415 This uint32 is the period of time in hours that a network management 416 station MUST wait since its last retrieval before checking for an 417 update. It is RECOMMENDED that this value be no less than 24 and no 418 more than 1440 for any device that is supported. 420 3.4. masa-server 422 This optional element refers to the URL that should be used to 423 resolve the location any MASA service, as specified in 424 [I-D.ietf-anima-bootstrapping-keyinfra]. 426 3.5. is-supported 428 This boolean is an indication from the manufacturer to the network 429 administrator as to whether or not the device is supported. In this 430 context a device is said to be supported if the manufacturer might 431 issue an update to the device or if the manufacturer might update the 432 MUD file. 434 3.6. systeminfo 436 This string contains a description of the device that this MUD file 437 supports. Note that this is a hint, and not intended for consumption 438 by a computer. 440 3.7. packet-direction 442 [I-D.ietf-netmod-acl-model] describes access-lists but does not 443 attempt to indicate where they are applied as that is handled 444 elsewhere in a configuration. However, in this case, a MUD file must 445 be explicit in describing the communcation pattern of a device, and 446 that includes indicating what is to be permitted or denied in either 447 direction of communication. This element takes a single value of 448 either "to-device" or "from-device", based on a typedef "direction". 450 3.8. manufacturer 452 This element consists of a hostname that would be matched against the 453 authority section of another device's MUD URL. 455 3.9. same-manufacturer 457 This is an equivalent for when the manufacturer element is used to 458 indicate the authority that is found in another device's MUD URL 459 matches that of the authority found in this device's MUD URL. 461 3.10. model 463 This string matches the one and only segment following the authority 464 section of the MUD URL. It refers to a model that is unique within 465 the context of the authority. It may also include product version 466 information. Thus how this field is constructed is entirely a local 467 matter for the manufacturer. 469 3.11. local-networks 471 This null-valued element expands to include local networks. Its 472 default expansion is that packets must not traverse toward a default 473 route that is received from the router. 475 3.12. controller 477 This URI specifies a value that a controller will register with the 478 network management station. The element then is expanded to the set 479 of hosts that are so registered. This element may also be a URN. In 480 this case, the URN describes a well known service, such as DNS or 481 NTP. 483 In addition, some meta information is defined in order to determine 484 when a usage description should be refreshed. 486 3.13. direction-initiated 488 When applied this matches packets when the flow was initiated in the 489 corresponding direction. [RFC6092] provides guidance for IPv6 490 guidance best practices. While that document is scoped specifically 491 to IPv6, its contents are applicable for IPv4 as well. When this 492 flag is set, and the system has no reason to believe a flow has been 493 initiated it MUST drop the packet. This match SHOULD be applied with 494 specific transport parameters, such as protocol. 496 4. Processing of the MUD file 498 To keep things relatively simple in addition to whatever definitions 499 exist, we also apply two additional default behaviors: 501 o Anything not explicitly permitted is denied. 503 o Local DNS and NTP are, by default, permitted to and from the 504 device. 506 An explicit description of the defaults can be found in Appendix B. 508 5. What does a MUD URL look like? 510 To begin with, MUD takes full advantage of both the https: scheme and 511 the use of .well-known. HTTPS is important in this case because a 512 man in the middle attack could otherwise harm the operation of a 513 class of devices. .well-known is used because we wish to add 514 additional structure to the URL. And so the URL appears as follows: 516 mud-url = "https://" authority "/.well-known/mud/" mud-rev 517 "/" model ( "?" extras ) 518 ; authority is from RFC3986 519 mud-rev = "v1" 520 model = segment ; from RFC3986 521 extras = query ; from RFC3986 523 mud-rev signifies the version of the manufacturer usage description 524 file. This memo specifies "v1" of that file. Later versions may 525 permit additional schemas or modify the format. In order to provide 526 for the broadest compatibility for the various transmission 527 mechanisms, the length of the URL for v1 MUST NOT exceed 255 octets. 529 "model" represents a device model as the manufacturer wishes to 530 represent it. It could be a brand name or something more specific. 531 It also may provide a means to indicate what version the product is. 532 Specifically if it has been updated in the field, this is the place 533 where evidence of that update would appear. The field should be 534 changed when the intended communication patterns of a device change. 535 While from a controller standpoint, only comparison and matching 536 operations are safe, it is envisioned that updates will require some 537 administrative review. Processing of this URL occurs as specified in 538 [RFC2818] and [RFC3986]. 540 6. The MUD YANG Model 542 file "ietf-mud@2016-07-20.yang"; 544 module ietf-mud { 545 yang-version 1.1; 546 namespace "urn:ietf:params:xml:ns:yang:ietf-mud"; 547 prefix "ietf-mud"; 549 import ietf-access-control-list { 550 prefix "acl"; 551 } 553 import ietf-yang-types { 554 prefix "yang"; 555 } 557 import ietf-inet-types { 558 prefix "inet"; 559 } 561 organization 562 "IETF OPSAWG (Ops Area) Working Group"; 564 contact 565 "WG Web: http://tools.ietf.org/wg/opsawg/ 566 WG List: opsawg@ietf.org 567 WG Chair: Warren Kumari 568 warren@kumari.net 569 WG Chair: Zhou Tianran 570 zhoutianran@huawei.com 571 Editor: Eliot Lear 572 lear@cisco.com 573 Editor: Ralph Droms 574 rdroms@cisco.com 575 "; 577 description 578 "This YANG module defines a component that augments the 579 IETF description of an access list. This specific module 580 focuses on additional filters that include local, model, 581 and same-manufacturer. 583 Copyright (c) 2016 IETF Trust and the persons identified as 584 the document authors. All rights reserved. 585 Redistribution and use in source and binary forms, with or 586 without modification, is permitted pursuant to, and subject 587 to the license terms contained in, the Simplified BSD 588 License set forth in Section 4.c of the IETF Trust's Legal 589 Provisions Relating to IETF Documents 590 (http://trustee.ietf.org/license-info). 591 This version of this YANG module is part of RFC XXXX; see 592 the RFC itself for full legal notices."; 594 revision "2016-07-20" { 595 description "Base version of MUD extensions to ACL model"; 596 reference "RFC XXXX: Manufacturer Usage Description 597 Specification"; 598 } 600 typedef direction { 601 type enumeration { 602 enum to-device { 603 description "packets or flows destined to the target 604 device"; 605 } 606 enum from-device { 607 description "packets or flows destined from 608 the target device"; 609 } 610 } 611 description "Which way are we talking about?"; 613 } 615 container metainfo { 617 description "Information about when support end(ed), and 618 when to refresh"; 620 leaf last-update { 621 type yang:date-and-time; 622 description "This is intended to be the time and date that 623 the MUD file was generated."; 624 } 626 leaf previous-mud-file { 627 type inet:uri; 628 description "Use to find the previous MUD file location 629 for auditing purposes."; 630 } 632 leaf cache-validity { 633 type uint32; 634 description "The information retrieved from the MUD server is 635 valid for these many hours, after which it should 636 be refreshed."; 637 } 639 leaf masa-server { 640 type inet:uri; 641 description "The URI of the MASA server that network 642 elements should forward requests to for this device."; 643 } 645 leaf is-supported { 646 type boolean; 647 description "The element is currently supported 648 by the manufacturer."; 649 } 650 leaf systeminfo { 651 type string; 652 description "A non-normative name and description of the device 653 this file is used for."; 654 } 655 } 657 augment "/acl:access-lists/acl:acl" { 658 description "add inbound or outbound. Normally access lists 659 are applied in an inbound or outbound direction 660 separately from their definition. This is not 661 possible with MUD."; 662 leaf packet-direction 663 { 664 type direction; 665 description "inbound or outbound ACL."; 666 } 667 } 669 augment "/acl:access-lists/acl:acl/" + 670 "acl:access-list-entries/acl:ace/" + 671 "acl:matches" { 672 description "adding abstractions to avoid need of IP addresses"; 674 leaf manufacturer { 675 type inet:host; 676 description "authority component of the manufacturer URI"; 677 } 679 leaf same-manufacturer { 680 type empty; 681 description "expand to ACEs for each device 682 with the same origin"; 683 } 685 leaf model { 686 type string; 687 description "specific model (including version) for a 688 given manufacturer"; 689 } 691 leaf local-networks { 692 type empty; 693 description "this string is used to indicate networks 694 considered local in a given environment."; 695 } 696 leaf controller { 697 type inet:uri; 698 description "expands to one or more controllers for a 699 given service that is codified by inet:uri."; 700 } 701 leaf direction-initiated { 702 type direction; 703 description "which direction a flow was initiated"; 704 } 705 } 706 } 707 709 7. The Domain Name Extension to the ACL Model 711 This module specifies an extension to IETF-ACL model such that domain 712 names may be referenced by augmenting the "matches" element. 713 Different implementations may deploy differing methods to maintain 714 the mapping between IP address and domain name, if indeed any are 715 needed. However, the intent is that resources that are referred to 716 using a name should be authorized (or not) within an access list. 718 The structure of the change is as follows: 720 augment 721 /acl:access-lists/acl:acl/acl:access-list-entries 722 /acl:ace/acl:matches/acl:ace-type/acl:ace-ip: 723 +--rw src-dnsname? inet:host 724 +--rw dst-dnsname? inet:host 726 The choice of this particular point in the access-list model is based 727 on the assumption that we are in some way referring to IP-related 728 resources, as that is what the DNS returns. A domain name in our 729 context is defined in [RFC6991]. 731 The following elements are defined. 733 7.1. source-dnsname 735 The argument corresponds to a domain name of a source as specified by 736 inet:host. Depending on how the model is used, it may or may not be 737 resolved, as required by the implementation and circumstances. 739 7.2. destination-dnsname 741 The argument corresponds to a domain name of a destination as 742 specified by inet:host. Depending on how the model is used, it may 743 or may not be resolved, as required by the implementation and 744 circumstances. 746 7.3. The ietf-acldns Model 748 file "ietf-acldns@2016-07-20.yang"; 750 module ietf-acldns { 751 yang-version 1.1; 752 namespace "urn:ietf:params:xml:ns:yang:ietf-acldns"; 753 prefix "ietf-acldns"; 754 import ietf-access-control-list { 755 prefix "acl"; 756 } 758 import ietf-inet-types { 759 prefix "inet"; 760 } 762 organization 763 "IETF OPSAWG (Ops Area) Working Group"; 765 contact 766 "WG Web: http://tools.ietf.org/wg/opsawg/ 767 WG List: opsawg@ietf.org 768 WG Chair: Warren Kumari 769 warren@kumari.net 770 WG Chair: Zhou Tianran 771 zhoutianran@huawei.com 772 Editor: Eliot Lear 773 lear@cisco.com 774 Editor: Ralph Droms 775 rdroms@cisco.com 776 "; 778 description 779 "This YANG module defines a component that augments the 780 IETF description of an access list to allow dns names 781 as matching criteria."; 783 revision "2016-07-20" { 784 description "Base version of dnsname extension of ACL model"; 785 reference "RFC XXXX: Manufacturer Usage Description 786 Specification"; 787 } 789 augment "/acl:access-lists/acl:acl/" + 790 "acl:access-list-entries/acl:ace/" + 791 "acl:matches/acl:ace-type/acl:ace-ip" { 792 description "adding domain names to matching"; 794 leaf src-dnsname { 795 type inet:host; 796 description "domain name to be matched against"; 797 } 798 leaf dst-dnsname { 799 type inet:host; 800 description "domain name to be matched against"; 802 } 803 } 804 } 806 808 8. MUD File Example 810 This example contains two access lists that are intended to provide 811 outbound access to a cloud service on TCP port 443. 813 { 814 "ietf-mud:metainfo": { 815 "last-update": "2016-05-18T20:00:50Z", 816 "cache-validity": 1440 817 }, 818 "ietf-access-control-list:access-lists": { 819 "acl": [ { 820 "acl-name": "inbound-stuff", 821 "acl-type" : "ipv4-acl", 822 "ietf-mud:direction" : "to-device", 823 "access-list-entries": { 824 "ace": [ 825 { 826 "rule-name": "access-cloud", 827 "matches": { 828 "ietf-acldns:src-dnsname": 829 "lighting-system.example.com", 830 "protocol" : 6, 831 "source-port-range" : { 832 "lower-port" : 443, 833 "upper-port" : 443 834 } 835 }, 836 "actions" : { 837 "permit" : [null] 838 } 839 } 840 ] 841 } 842 }, 843 { 844 "acl-name": "outbound-stuff", 845 "acl-type" : "ipv4-acl", 846 "ietf-mud:direction" : "from-device", 847 "access-list-entries": { 848 "ace": [ 849 { 850 "rule-name": "access-cloud", 851 "matches": { 852 "ietf-acldns:dst-dnsname": 853 "lighting-system.example.com", 854 "protocol" : 6, 855 "destination-port-range" : { 856 "lower-port" : 443, 857 "upper-port" : 443 858 } 859 }, 860 "actions" : { 861 "permit" : [null] 862 } 863 } 864 ] 865 } 866 } 867 ] 868 } 869 } 871 9. The MUD URL DHCP Option 873 The IPv4 MUD URL client option has the following format: 875 +------+-----+------------------------------ 876 | code | len | MUD URL 877 +------+-----+------------------------------ 879 Code OPTION_MUD_URL_V4 (161) is assigned by IANA. len is a single 880 octet that indicates the length of the URL in octets. MUD URL is a 881 URL. MUD URLs MUST NOT exceed 255 octets. 883 The IPv6 MUD URL client option has the following format: 885 0 1 2 3 886 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 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | OPTION_MUD_URL_V6 | option-length | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | MUD URL | 891 | ... | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 OPTION_MUD_URL_V6 (112; assigned by IANA). 896 option-length contains the length of the URL in octets. 898 The intent of this option is to provide both a new device classifier 899 to the network as well as some recommended configuration to the 900 routers that implement policy. However, it is entirely the purview 901 of the network system as managed by the network administrator to 902 decide what to do with this information. The key function of this 903 option is simply to identify the type of device to the network in a 904 structured way such that the policy can be easily found with existing 905 toolsets. 907 9.1. Client Behavior 909 A DHCPv4 client MAY emit a DHCPv4 option and a DHCPv6 client MAY emit 910 DHCPv6 option. These options are singletons, as specified in 911 [RFC7227]. Because clients are intended to have at most one MUD URL 912 associated with them, they may emit at most one MUD URL option via 913 DHCPv4 and one MUD URL option via DHCPv6. In the case where both v4 914 and v6 DHCP options are emitted, the same URL MUST be used. 916 Clients SHOULD log or otherwise report improper acknowledgments from 917 servers, but they MUST NOT modify their MUD URL configuration based 918 on a server's response. The server's response is only an 919 acknowledgment that the server has processed the option, and promises 920 no specific network behavior to the client. In particular, it may 921 not be possible for the server to retrieve the file associated with 922 the MUD URL, or the local network administration may not wish to use 923 the usage description. Neither of these situations should be 924 considered in any way exceptional. 926 9.2. Server Behavior 928 A DHCP server may ignore these options or take action based on 929 receipt of these options. If a server successfully parses the option 930 and the URL, it MUST return the option with length field set to zero 931 and a corresponding null URL field as an acknowledgment. Even in 932 this circumstance, no specific network behavior is guaranteed. When 933 a server consumes this option, it will either forward the URL and 934 relevant client information to a network management system (such as 935 the giaddr), or it will retrieve the usage description by resolving 936 the URL. 938 DHCP servers may implement MUD functionality themselves or they may 939 pass along appropriate information to a network management system or 940 controller. A DHCP server that does process the MUD URL MUST adhere 941 to the process specified in [RFC2818] and [RFC5280] to validate the 942 TLS certificate of the web server hosting the MUD file. Those 943 servers will retrieve the file, process it, create and install the 944 necessary configuration on the relevant network element. Servers 945 SHOULD monitor the gateway for state changes on a given interface. A 946 DHCP server that does not provide MUD functionality and has forwarded 947 a MUD URL to a network management system MUST notify the network 948 management of any corresponding change to the DHCP state of the 949 client (such as expiration or explicit release of a network address 950 lease). 952 9.3. Relay Requirements 954 There are no additional requirements for relays. 956 10. The Manufacturer Usage Description (MUD) URL X.509 Extension 958 This section defines an X.509 non-critical certificate extension that 959 contains a single Uniform Resource Identifier (URI) that points to an 960 on-line Manufacturer Usage Description concerning the certificate 961 subject. URI must be represented as described in Section 7.4 of 962 [RFC5280]. 964 Any Internationalized Resource Identifiers (IRIs) MUST be mapped to 965 URIs as specified in Section 3.1 of [RFC3987] before they are placed 966 in the certificate extension. 968 The semantics of the URI are defined Section 5 of this document. 970 The choice of id-pe is based on guidance found in Section 4.2.2 of 971 [RFC5280]: 973 These extensions may be used to direct applications to on-line 974 information about the issuer or the subject. 976 The MUD URL is precisely that: online information about the 977 particular subject. 979 The new extension is identified as follows: 981 983 MUDURLExtnModule-2016 { iso(1) identified-organization(3) dod(6) 984 internet(1) security(5) mechanisms(5) pkix(7) 985 id-mod(0) id-mod-mudURLExtn2016(88) } 987 DEFINITIONS IMPLICIT TAGS ::= BEGIN 989 -- EXPORTS ALL -- 991 IMPORTS 992 EXTENSION 993 FROM PKIX-CommonTypes-2009 994 { iso(1) identified-organization(3) dod(6) internet(1) 995 security(5) mechanisms(5) pkix(7) id-mod(0) 996 id-mod-pkixCommon-02(57) } 998 id-pe 999 FROM PKIX1Explicit-2009 1000 { iso(1) identified-organization(3) dod(6) internet(1) 1001 security(5) mechanisms(5) pkix(7) id-mod(0) 1002 id-mod-pkix1-explicit-02(51) } ; 1003 MUDCertExtensions EXTENSION ::= { ext-MUDURL, ... } 1004 ext-MUDURL EXTENSION ::= { SYNTAX MUDURLSyntax 1005 IDENTIFIED BY id-pe-mud-url } 1007 id-pe-mud-url OBJECT IDENTIFIER ::= { id-pe 25 } 1009 MUDURLSyntax ::= IA5String 1011 END 1013 1015 11. The Manufacturer Usage Description LLDP extension 1017 The IEEE802.1AB Link Layer Discovery Protocol (LLDP) [IEEE8021AB] is 1018 a one hop vendor-neutral link layer protocols used by end hosts 1019 network devices for advertising their identity, capabilities, and 1020 neighbors on an IEEE 802 local area network. Its Type-Length-Value 1021 (TLV) design allows for 'vendor-specific' extensions to be defined. 1022 IANA has a registered IEEE 802 organizationally unique identifier 1023 (OUI) defined as documented in [RFC7042]. The MUD LLDP extension 1024 uses a subtype defined in this document to carry the MUD URL. 1026 The LLDP vendor specific frame has the following format: 1028 +--------+--------+----------+---------+-------------- 1029 |TLV Type| len | OUI |subtype | MUD URL 1030 | =127 | |= 00 00 5E| = 1 | 1031 |(7 bits)|(9 bits)|(3 octets)|(1 octet)|(1-255 octets) 1032 +--------+--------+----------+---------+-------------- 1034 where: 1036 o TLV Type = 127 indicates a vendor-specific TLV 1038 o len - indicates the TLV string length 1040 o OUI = 00 00 5E is the organizationally unique identifier of IANA 1042 o subtype = 1 (to be assigned by IANA for the MUD URL) 1044 o MUD URL - the length MUST NOT exceed 255 octets 1046 The intent of this extension is to provide both a new device 1047 classifier to the network as well as some recommended configuration 1048 to the routers that implement policy. However, it is entirely the 1049 purview of the network system as managed by the network administrator 1050 to decide what to do with this information. The key function of this 1051 extension is simply to identify the type of device to the network in 1052 a structured way such that the policy can be easily found with 1053 existing toolsets. 1055 Hosts, routers, or other network devices that implement this option 1056 are intended to have at most one MUD URL associated with them, so 1057 they may transmit at most one MUD URL value. 1059 Hosts, routers, or other network devices that implement this option 1060 may ignore these options or take action based on receipt of these 1061 options. For example they may fill in information in the respective 1062 extensions of the LLDP Management Information Base (LLDP MIB). LLDP 1063 operates in a one-way direction. LLDPDUs are not exchanged as 1064 information requests by one device and response sent by another 1065 device. The other devices do not acknowledge LLDP information 1066 received from a device. No specific network behavior is guaranteed. 1067 When a device consumes this extension, it may either forward the URL 1068 and relevant remote device information to a network management 1069 system, or it will retrieve the usage description by resolving the 1070 URL. 1072 12. Creating and Processing of Signed MUD Files 1074 Because MUD files contain information that may be used to configure 1075 network access lists, they are sensitive. To insure that they have 1076 not been tampered with, it is important that they be signed. We make 1077 use of DER-encoded Cryptographic Message Syntax (CMS) [RFC5652] for 1078 this purpose. 1080 12.1. Creating a MUD file signature 1082 A MUD file MUST be signed using CMS as an opaque binary object. In 1083 order to make successful verification more likely, intermediate 1084 certificates SHOULD be included. The signature is stored at the same 1085 location as the MUD URL but with the suffix of ".p7s". Signatures 1086 are transferred using content-type "Application/pkcs7-signature". 1088 For example: 1090 % openssl cms -sign -signer mancertfile -inkey mankey \ 1091 -in mudfile -binary -outform DER - \ 1092 -certfile intermediatecert -out mudfile.p7s 1094 Note: A MUD file may need to be resigned if the signature expires. 1096 12.2. Verifying a MUD file signature 1098 Prior to retrieving a MUD file the MUD controller SHOULD retrieve the 1099 MUD signature file using the MUD URL with a suffix of ".p7s". For 1100 example, if the MUD URL is "https://example.com/.well-known/v1/ 1101 modela", the MUD signature URL will be "https://example.com/.well- 1102 known/v1/modela.p7s". 1104 Upon retrieving a MUD file, a MUD controller MUST validate the 1105 signature of the file before continuing with further processing. A 1106 MUD controller SHOULD produce an error and it MUST cease all 1107 processing of that file if the signature cannot be validated. It is 1108 important that MUD controllers have some reason to trust the 1109 certificates they are seeing. Therefore, it is RECOMMENDED that new 1110 signers be validated either directly by an administrator or by a 1111 service that has some reason to believe that the signer is a good 1112 actor. 1114 For Example: 1116 % openssl cms -verify -in mudfile.p7s -inform DER -content mudfile 1118 Note the additional step of verifying the common trust root. 1120 13. Extensibility 1122 One of our design goals is to see that MUD files are able to be 1123 understood by as broad a cross-section of systems as is possible. 1124 Coupled with the fact that we have also chosen to leverage existing 1125 mechanisms, we are left with no ability to negotiate extensions and a 1126 limited desire for those extensions in any event. A such, a two-tier 1127 extensibility framework is employed, as follows: 1129 1. At a coarse grain, a protocol version is included in a MUD URL. 1130 This memo specifies MUD version 1. Any and all changes are 1131 entertained when this version is bumped. Transition approaches 1132 between versions would be a matter for discussion in future 1133 versions. 1135 2. At a finer grain, only extensions that would not incur additional 1136 risk to the device are permitted. Specifically, augmenting of 1137 the metainfo container is permitted with the understanding that 1138 such additions may be ignored. In addition, augmentation of the 1139 ACL model is permitted so long as it remains safe for a given ACE 1140 to be ignored by the MUD Controller or the network elements it 1141 configures. Most specifically, is is not permitted to include as 1142 an augmentation that modifies "deny" behavior without bumping the 1143 version. Furthermore, implementations that are not able to parse 1144 a component of the ACE array MUST ignore the entire array entry 1145 (e.g., not the entire array) and MAY ignore the entire MUD file. 1147 14. Security Considerations 1149 Based on the means a URL is procured, a device may be able to lie 1150 about what it is, thus gaining additional network access. There are 1151 several means to limit risk in this case. The most obvious is to 1152 only believe devices that make use of certificate-based 1153 authentication such as IEEE 802.1AR certificates. When those 1154 certificates are not present, devices claiming to be of a certain 1155 manufacturer SHOULD NOT be included in that manufacturer grouping 1156 without additional validation of some form. This will occur when it 1157 makes use of primitives such as "manufacturer" for the purpose of 1158 accessing devices of a particular type. 1160 Network management systems SHOULD NOT accept a usage description for 1161 a device with the same MAC address that has indicated a change of 1162 authority without some additional validation (such as review of the 1163 class). New devices that present some form of unauthenticated MUD 1164 URL SHOULD be validated by some external means when they would be 1165 otherwise be given increased network access. 1167 It may be possible for a rogue manufacturer to inappropriately 1168 exercise the MUD file parser, in order to exploit a vulnerability. 1169 There are three recommended approaches to address this threat. The 1170 first is to validate the signature of the MUD file. The second is to 1171 have a system do a primary scan of the file to ensure that it is both 1172 parseable and believable at some level. MUD files will likely be 1173 relatively small, to start with. The number of ACEs used by any 1174 given device should be relatively small as well. Second, it may be 1175 useful to limit retrieval of MUD URLs to only those sites that are 1176 known to have decent web reputations. 1178 Use of a URL necessitates the use of domain names. If a domain name 1179 changes ownership, the new owner of that domain may be able to 1180 provide MUD files that MUD controllers would consider valid. There 1181 are a few approaches that can mitigate this attack. First, MUD file 1182 servers SHOULD cache certificates used by the MUD file server. When 1183 a new certificate is retrieved for whatever reason, the MUD 1184 controller should check to see if ownership of the domain has 1185 changed. A fair programmatic approximation of this is when the name 1186 servers for the domain have changed. If the actual MUD file has 1187 changed, the controller MAY check the WHOIS database to see if 1188 registration ownership of a domain has changed. If a change has 1189 occured, or if for some reason it is not possible to determine 1190 whether ownership has changed, further review may be warranted. 1191 Note, this remediation does not take into account the case of a 1192 device that was produced long ago and only recently fielded, or the 1193 case where a new MUD controller has been installed. 1195 The release of a MUD URL by a device reveals what the device is, and 1196 provides an attacker with guidance on what vulnerabilities may be 1197 present. 1199 While the MUD URL itself is not intended to be unique to a specific 1200 device, the release of the URL may aid an observer in identifying 1201 individuals when combined with other information. This is a privacy 1202 consideration. 1204 In addressing both of these concerns, implementors should take into 1205 account what other information they are advertising through 1206 mechanisms such as mDNS[RFC6872], how a device might otherwise be 1207 identified, perhaps through how it behaves when it is connected to 1208 the network, whether a device is intended to be used by individuals 1209 or carry personal identifying information, and then apply appropriate 1210 data minimization techniques. One approach is to make use of TEAP 1211 [RFC7170] as the means to share information with authorized 1212 components in the network. Network devices may also assist in 1213 limiting access to the MUD-URL through the use of mechanisms such as 1214 DHCPv6-Shield [RFC7610]. 1216 15. IANA Considerations 1218 15.1. DHCPv4 and DHCPv6 Options 1220 The IANA has allocated option 161 in the Dynamic Host Configuration 1221 Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters registry 1222 for the MUD DHCPv4 option. 1224 IANA is requested to allocated the DHCPv4 and v6 options as specified 1225 in Section 9. 1227 15.2. PKIX Extensions 1229 IANA is kindly requested to make the following assignments for: 1231 o The MUDURLExtnModule-2016 ASN.1 module in the "SMI Security for 1232 PKIX Module Identifier" registry (1.3.6.1.5.5.7.0). 1234 o id-pe-mud-url object identifier from the "SMI Security for PKIX 1235 Certificate Extension" registry (1.3.6.1.5.5.7.1). 1237 The use fo these values is specified in Section 10. 1239 15.3. Well Known URI Suffix 1241 The IANA has allocated the URL suffix of "mud" as follows: 1243 o URI Suffix: "mud" o Specification documents: this document o 1244 Related information: n/a 1246 15.4. MIME Media-type Registration for MUD files 1248 The following media-type is defined for transfer of MUD file: 1250 o Type name: application 1251 o Subtype name: mud+json 1252 o Required parameters: n/a 1253 o Optional parameters: n/a 1254 o Encoding considerations: 8bit; application/mud+json values 1255 are represented as a JSON object; UTF-8 encoding SHOULD be 1256 employed. 1257 o Security considerations: See {{secon}} of this document. 1258 o Interoperability considerations: n/a 1259 o Published specification: this document 1260 o Applications that use this media type: MUD controllers as 1261 specified by this document. 1262 o Fragment identifier considerations: n/a 1263 o Additional information: 1265 Magic number(s): n/a 1266 File extension(s): n/a 1267 Macintosh file type code(s): n/a 1269 o Person & email address to contact for further information: 1270 Eliot Lear , Ralph Droms 1271 o Intended usage: COMMON 1272 o Restrictions on usage: none 1273 o Author: 1274 Eliot Lear 1275 Ralph Droms 1276 o Change controller: IESG 1277 o Provisional registration? (standards tree only): No. 1279 15.5. LLDP IANA TLV Subtype Registry 1281 IANA is requested to create a new registry for IANA Link Layer 1282 Discovery Protocol (LLDP) TLV subtype values. The recommended policy 1283 for this registry is Expert Review. The maximum number of entries in 1284 the registry is 256. 1286 IANA is required to populate the initial registry with the value: 1288 LLDP subtype value = 1 (All the other 255 values should be initially 1289 marked as 'Unassigned'.) 1291 Description = the Manufacturer Usage Description (MUD) Uniform 1292 Resource Locator (URL) 1294 Reference = < this document > 1296 15.6. The MUD Well Known Universal Resource Name (URNs) 1298 The following parameter registry is requested to be added in 1299 accordance with [RFC3553] 1301 Registry name: "urn:ietf:params:mud" is requested. 1302 Specification: this document 1303 Repository: this document 1304 Index value: Encoded identically to a TCP/UDP port service 1305 name, as specified in Section 5.1 of [RFC6335] 1307 The following entries should be added to the "urn:ietf:params:mud" 1308 name space: 1310 "urn:ietf:params:mud:dns" refers to the service specified by 1311 [RFC1123]. "urn:ietf:params:mud:ntp" refers to the service specified 1312 by [RFC5905]. 1314 16. Acknowledgments 1316 The authors would like to thank Einar Nilsen-Nygaard, Bernie Volz, 1317 Tom Gindin, Brian Weis, Sandeep Kumar, Thorsten Dahm, John Bashinski, 1318 Steve Rich, Jim Bieda, and Dan Wing for their valuable advice and 1319 reviews. Russ Housley entirely rewrote Section 10 to be a complete 1320 module. Adrian Farrel provided the basis for privacy considerations 1321 text. The remaining errors in this work are entirely the 1322 responsibility of the author. 1324 17. References 1326 17.1. Normative References 1328 [I-D.ietf-anima-bootstrapping-keyinfra] 1329 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 1330 S., and K. Watsen, "Bootstrapping Remote Secure Key 1331 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 1332 keyinfra-04 (work in progress), October 2016. 1334 [I-D.ietf-netmod-acl-model] 1335 Bogdanovic, D., Koushik, K., Huang, L., and D. Blair, 1336 "Network Access Control List (ACL) YANG Data Model", 1337 draft-ietf-netmod-acl-model-09 (work in progress), October 1338 2016. 1340 [IEEE8021AB] 1341 Institute for Electrical and Electronics Engineers, "IEEE 1342 Standard for Local and Metropolitan Area Networks-- 1343 Station and Media Access Control Connectivity Discovery", 1344 n.d.. 1346 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 1347 Application and Support", STD 3, RFC 1123, 1348 DOI 10.17487/RFC1123, October 1989, 1349 . 1351 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1352 Requirement Levels", BCP 14, RFC 2119, 1353 DOI 10.17487/RFC2119, March 1997, 1354 . 1356 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1357 RFC 2131, DOI 10.17487/RFC2131, March 1997, 1358 . 1360 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1361 DOI 10.17487/RFC2818, May 2000, 1362 . 1364 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 1365 C., and M. Carney, "Dynamic Host Configuration Protocol 1366 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 1367 2003, . 1369 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1370 Resource Identifier (URI): Generic Syntax", STD 66, 1371 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1372 . 1374 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 1375 Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, 1376 January 2005, . 1378 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1379 Housley, R., and W. Polk, "Internet X.509 Public Key 1380 Infrastructure Certificate and Certificate Revocation List 1381 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1382 . 1384 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1385 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1386 . 1388 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1389 "Network Time Protocol Version 4: Protocol and Algorithms 1390 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1391 . 1393 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1394 the Network Configuration Protocol (NETCONF)", RFC 6020, 1395 DOI 10.17487/RFC6020, October 2010, 1396 . 1398 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 1399 Capabilities in Customer Premises Equipment (CPE) for 1400 Providing Residential IPv6 Internet Service", RFC 6092, 1401 DOI 10.17487/RFC6092, January 2011, 1402 . 1404 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 1405 Cheshire, "Internet Assigned Numbers Authority (IANA) 1406 Procedures for the Management of the Service Name and 1407 Transport Protocol Port Number Registry", BCP 165, 1408 RFC 6335, DOI 10.17487/RFC6335, August 2011, 1409 . 1411 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1412 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1413 . 1415 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 1416 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 1417 BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, 1418 . 1420 [RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: 1421 Protecting against Rogue DHCPv6 Servers", BCP 199, 1422 RFC 7610, DOI 10.17487/RFC7610, August 2015, 1423 . 1425 17.2. Informative References 1427 [FW95] Chapman, D. and E. Zwicky, "Building Internet Firewalls", 1428 January 1995. 1430 [IEEE8021AR] 1431 Institute for Electrical and Electronics Engineers, 1432 "Secure Device Identity", 1998. 1434 [ISO.8601.1988] 1435 International Organization for Standardization, "Data 1436 elements and interchange formats - Information interchange 1437 - Representation of dates and times", ISO Standard 8601, 1438 June 1988. 1440 [RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic 1441 Technology and the Internet", BCP 200, RFC 1984, 1442 DOI 10.17487/RFC1984, August 1996, 1443 . 1445 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1446 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 1447 . 1449 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 1450 IETF URN Sub-namespace for Registered Protocol 1451 Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 1452 2003, . 1454 [RFC6872] Gurbani, V., Ed., Burger, E., Ed., Anjali, T., Abdelnur, 1455 H., and O. Festor, "The Common Log Format (CLF) for the 1456 Session Initiation Protocol (SIP): Framework and 1457 Information Model", RFC 6872, DOI 10.17487/RFC6872, 1458 February 2013, . 1460 [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and 1461 IETF Protocol and Documentation Usage for IEEE 802 1462 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, 1463 October 2013, . 1465 [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 1466 "Tunnel Extensible Authentication Protocol (TEAP) Version 1467 1", RFC 7170, DOI 10.17487/RFC7170, May 2014, 1468 . 1470 [RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, 1471 "Architectural Considerations in Smart Object Networking", 1472 RFC 7452, DOI 10.17487/RFC7452, March 2015, 1473 . 1475 [RFC7488] Boucadair, M., Penno, R., Wing, D., Patil, P., and T. 1476 Reddy, "Port Control Protocol (PCP) Server Selection", 1477 RFC 7488, DOI 10.17487/RFC7488, March 2015, 1478 . 1480 Appendix A. Changes from Earlier Versions 1482 RFC Editor to remove this section prior to publication. 1484 Draft -02 to -03: * Additional IANA updates * Format correction in 1485 YANG. * Add reference to TEAP. 1487 Draft -01 to -02: * Update IANA considerations * Accept Russ Housley 1488 rewrite of X.509 text * Include privacy considerations text * Redo 1489 the URL limit. Still 255 bytes, but now stated in the URL 1490 definition. * Change URI registration to be under urn:ietf:params 1492 Draft -00 to -01: * Fix cert trust text. * change supportInformation 1493 to meta-info * Add an informaitonal element in. * add urn registry 1494 and create first entry * add default elements 1496 Appendix B. Default MUD elements 1498 What follows is a MUD file that permits DNS traffic to a controller 1499 that is registered with the URN "urn:ietf:params:mud:dns" and traffic 1500 NTP to a controller that is registered "urn:ietf:params:mud:ntp". 1501 This is considered the default behavior and the ACEs are in effect 1502 appended to whatever other ACEs. To block DNS or NTP one repeats the 1503 matching statement but replace "permit" with deny. Because ACEs are 1504 processed in the order they are received, the defaults would not be 1505 reached. A MUD controller might further decide to optimize to simply 1506 not include the defaults when they are overriden. 1508 A complete MUD entry is included below. 1510 { 1511 "ietf-mud:meta-info": { 1512 "lastUpdate": "2016-09-27T15:10:24+02:00", 1513 "cacheValidity": 1440 1514 }, 1515 "ietf-acl:access-lists": { 1516 "ietf-acl:access-list": [ 1517 { 1518 "acl-name": "mud-53134-v4in", 1519 "acl-type": "ipv4-acl", 1520 "ietf-mud:packet-direction": "to-device", 1521 "access-list-entries": { 1522 "ace": [ 1523 { 1524 "rule-name": "entout0-in", 1525 "matches": { 1526 "ietf-mud:controller": "urn:ietf:params:mud:dns", 1527 "protocol": 17, 1528 "source-port-range": { 1529 "lower-port": 53, 1530 "upper-port": 53 1531 } 1532 }, 1533 "actions": { 1534 "permit": [ 1535 null 1536 ] 1537 } 1538 }, 1539 { 1540 "rule-name": "entout1-in", 1541 "matches": { 1542 "ietf-mud:controller": "urn:ietf:params:mud:dns", 1543 "protocol": 6, 1544 "source-port-range": { 1545 "lower-port": 53, 1546 "upper-port": 53 1547 } 1548 }, 1549 "actions": { 1550 "permit": [ 1551 null 1552 ] 1553 } 1554 }, 1555 { 1556 "rule-name": "entout2-in", 1557 "matches": { 1558 "ietf-mud:controller": "urn:ietf:params:mud:ntp", 1559 "protocol": 17, 1560 "source-port-range": { 1561 "lower-port": 123, 1562 "upper-port": 123 1563 } 1564 }, 1565 "actions": { 1566 "permit": [ 1567 null 1568 ] 1569 } 1570 } 1571 ] 1572 } 1573 }, 1574 { 1575 "acl-name": "mud-53134-v4out", 1576 "acl-type": "ipv4-acl", 1577 "ietf-mud:packet-direction": "from-device", 1578 "access-list-entries": { 1579 "ace": [ 1580 { 1581 "rule-name": "entout0-in", 1582 "matches": { 1583 "ietf-mud:controller": "urn:ietf:params:mud:dns", 1584 "protocol": 17, 1585 "source-port-range": { 1586 "lower-port": 53, 1587 "upper-port": 53 1588 } 1589 }, 1590 "actions": { 1591 "permit": [ 1592 null 1593 ] 1594 } 1595 }, 1596 { 1597 "rule-name": "entout1-in", 1598 "matches": { 1599 "ietf-mud:controller": "urn:ietf:params:mud:dns", 1600 "protocol": 6, 1601 "source-port-range": { 1602 "lower-port": 53, 1603 "upper-port": 53 1604 } 1605 }, 1606 "actions": { 1607 "permit": [ 1608 null 1609 ] 1610 } 1611 }, 1612 { 1613 "rule-name": "entout2-in", 1614 "matches": { 1615 "ietf-mud:controller": "urn:ietf:params:mud:ntp", 1616 "protocol": 17, 1617 "source-port-range": { 1618 "lower-port": 123, 1619 "upper-port": 123 1620 } 1621 }, 1622 "actions": { 1623 "permit": [ 1624 null 1625 ] 1626 } 1627 } 1628 ] 1629 } 1630 }, 1631 { 1632 "acl-name": "mud-53134-v6in", 1633 "acl-type": "ipv6-acl", 1634 "ietf-mud:packet-direction": "to-device", 1635 "access-list-entries": { 1636 "ace": [ 1637 { 1638 "rule-name": "entout0-in", 1639 "matches": { 1640 "ietf-mud:controller": "urn:ietf:params:mud:dns", 1641 "protocol": 17, 1642 "source-port-range": { 1643 "lower-port": 53, 1644 "upper-port": 53 1645 } 1646 }, 1647 "actions": { 1648 "permit": [ 1649 null 1650 ] 1651 } 1652 }, 1653 { 1654 "rule-name": "entout1-in", 1655 "matches": { 1656 "ietf-mud:controller": "urn:params:mud:dns", 1657 "protocol": 6, 1658 "source-port-range": { 1659 "lower-port": 53, 1660 "upper-port": 53 1661 } 1662 }, 1663 "actions": { 1664 "permit": [ 1665 null 1666 ] 1667 } 1668 }, 1669 { 1670 "rule-name": "entout2-in", 1671 "matches": { 1672 "ietf-mud:controller": "urn:ietf:params:mud:ntp", 1673 "protocol": 17, 1674 "source-port-range": { 1675 "lower-port": 123, 1676 "upper-port": 123 1677 } 1678 }, 1679 "actions": { 1680 "permit": [ 1681 null 1682 ] 1683 } 1684 } 1685 ] 1686 } 1687 }, 1688 { 1689 "acl-name": "mud-53134-v6out", 1690 "acl-type": "ipv6-acl", 1691 "ietf-mud:packet-direction": "from-device", 1692 "access-list-entries": { 1693 "ace": [ 1694 { 1695 "rule-name": "entout0-in", 1696 "matches": { 1697 "ietf-mud:controller": "urn:ietf:params:mud:dns", 1698 "protocol": 17, 1699 "source-port-range": { 1700 "lower-port": 53, 1701 "upper-port": 53 1702 } 1703 }, 1704 "actions": { 1705 "permit": [ 1706 null 1707 ] 1708 } 1709 }, 1710 { 1711 "rule-name": "entout1-in", 1712 "matches": { 1713 "ietf-mud:controller": "urn:ietf:params:mud:dns", 1714 "protocol": 6, 1715 "source-port-range": { 1716 "lower-port": 53, 1717 "upper-port": 53 1718 } 1719 }, 1720 "actions": { 1721 "permit": [ 1722 null 1723 ] 1724 } 1725 }, 1726 { 1727 "rule-name": "entout2-in", 1728 "matches": { 1729 "ietf-mud:controller": "urn:ietf:params:mud:ntp", 1730 "protocol": 17, 1731 "source-port-range": { 1732 "lower-port": 123, 1733 "upper-port": 123 1734 } 1735 }, 1736 "actions": { 1737 "permit": [ 1738 null 1739 ] 1740 } 1741 } 1742 ] 1743 } 1744 } 1745 ] 1746 } 1747 } 1749 Authors' Addresses 1751 Eliot Lear 1752 Cisco Systems 1753 Richtistrasse 7 1754 Wallisellen CH-8304 1755 Switzerland 1757 Phone: +41 44 878 9200 1758 Email: lear@cisco.com 1760 Ralph Droms 1762 Phone: +1 978 376 3731 1763 Email: rdroms@gmail.com 1764 Dan Romascanu 1766 Email: dromasca@gmail.com