idnits 2.17.1 draft-ietf-opsawg-mud-08.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 == Line 506 has weird spacing: '...cl-type ide...' == Line 511 has weird spacing: '...cl-type ide...' -- The document date (August 09, 2017) is 2451 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-07 == Outdated reference: A later version (-21) exists of draft-ietf-netmod-acl-model-11 == Outdated reference: A later version (-20) exists of draft-ietf-netmod-rfc6087bis-13 -- 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 (~~), 6 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: February 10, 2018 6 D. Romascanu 7 August 09, 2017 9 Manufacturer Usage Description Specification 10 draft-ietf-opsawg-mud-08 12 Abstract 14 This memo specifies a component-based architecture for manufacturer 15 usage descriptions (MUD). This includes two YANG modules, IPv4 and 16 IPv6 DHCP options, an LLDP TLV, a URL suffix specification, an X.509 17 certificate extension and a means to sign and verify the 18 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 February 10, 2018. 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. What MUD doesn't do . . . . . . . . . . . . . . . . . . . 4 56 1.2. A Simple Example . . . . . . . . . . . . . . . . . . . . 4 57 1.3. Determining Intended Use . . . . . . . . . . . . . . . . 5 58 1.4. Finding A Policy: The MUD URL . . . . . . . . . . . . . . 5 59 1.5. Types of Policies . . . . . . . . . . . . . . . . . . . . 6 60 1.6. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 61 1.7. The Manufacturer Usage Description Architecture . . . . . 8 62 1.8. Order of operations . . . . . . . . . . . . . . . . . . . 9 63 2. The MUD Model and Semantic Meaning . . . . . . . . . . . . . 10 64 3. Element Definitions . . . . . . . . . . . . . . . . . . . . . 12 65 3.1. last-update . . . . . . . . . . . . . . . . . . . . . . . 12 66 3.2. cache-validity . . . . . . . . . . . . . . . . . . . . . 12 67 3.3. masa-server . . . . . . . . . . . . . . . . . . . . . . . 12 68 3.4. is-supported . . . . . . . . . . . . . . . . . . . . . . 12 69 3.5. systeminfo . . . . . . . . . . . . . . . . . . . . . . . 12 70 3.6. extensions . . . . . . . . . . . . . . . . . . . . . . . 12 71 3.7. packet-direction . . . . . . . . . . . . . . . . . . . . 13 72 3.8. manufacturer . . . . . . . . . . . . . . . . . . . . . . 13 73 3.9. same-manufacturer . . . . . . . . . . . . . . . . . . . . 13 74 3.10. model . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 3.11. local-networks . . . . . . . . . . . . . . . . . . . . . 13 76 3.12. controller . . . . . . . . . . . . . . . . . . . . . . . 13 77 3.13. my-controller . . . . . . . . . . . . . . . . . . . . . . 14 78 3.14. direction-initiated . . . . . . . . . . . . . . . . . . . 14 79 4. Processing of the MUD file . . . . . . . . . . . . . . . . . 14 80 5. What does a MUD URL look like? . . . . . . . . . . . . . . . 14 81 6. The MUD YANG Model . . . . . . . . . . . . . . . . . . . . . 15 82 7. The Domain Name Extension to the ACL Model . . . . . . . . . 21 83 7.1. source-dnsname . . . . . . . . . . . . . . . . . . . . . 21 84 7.2. destination-dnsname . . . . . . . . . . . . . . . . . . . 21 85 7.3. The ietf-acldns Model . . . . . . . . . . . . . . . . . . 21 86 8. MUD File Example . . . . . . . . . . . . . . . . . . . . . . 23 87 9. The MUD URL DHCP Option . . . . . . . . . . . . . . . . . . . 25 88 9.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 26 89 9.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 26 90 9.3. Relay Requirements . . . . . . . . . . . . . . . . . . . 27 91 10. The Manufacturer Usage Description (MUD) URL X.509 Extension 27 92 11. The Manufacturer Usage Description LLDP extension . . . . . . 28 93 12. Creating and Processing of Signed MUD Files . . . . . . . . . 30 94 12.1. Creating a MUD file signature . . . . . . . . . . . . . 30 95 12.2. Verifying a MUD file signature . . . . . . . . . . . . . 30 96 13. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 31 97 14. Deployment Considerations . . . . . . . . . . . . . . . . . . 31 98 15. Security Considerations . . . . . . . . . . . . . . . . . . . 32 99 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 100 16.1. YANG Module Registrations . . . . . . . . . . . . . . . 33 101 16.2. DHCPv4 and DHCPv6 Options . . . . . . . . . . . . . . . 34 102 16.3. PKIX Extensions . . . . . . . . . . . . . . . . . . . . 34 103 16.4. Well Known URI Suffix . . . . . . . . . . . . . . . . . 34 104 16.5. MIME Media-type Registration for MUD files . . . . . . . 34 105 16.6. LLDP IANA TLV Subtype Registry . . . . . . . . . . . . . 35 106 16.7. The MUD Well Known Universal Resource Name (URNs) . . . 36 107 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 108 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 109 18.1. Normative References . . . . . . . . . . . . . . . . . . 36 110 18.2. Informative References . . . . . . . . . . . . . . . . . 39 111 Appendix A. Changes from Earlier Versions . . . . . . . . . . . 40 112 Appendix B. Default MUD elements . . . . . . . . . . . . . . . . 41 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 115 1. Introduction 117 The Internet has largely been constructed on general purpose 118 computers; those devices that may be used for a purpose that is 119 specified by those who buy the device. [RFC1984] presumed that an 120 end device would be most capable of protecting itself. This made 121 sense when the typical device was a workstation or a mainframe, and 122 it continues to make sense for general purpose computing devices 123 today, including laptops, smart phones, and tablets. 125 [RFC7452] discusses design patterns for, and poses questions about, 126 smart objects. Let us then posit a group of objects that are 127 specifically NOT general purpose computers. These devices therefore 128 have a purpose to their use. By definition, therefore, all other 129 purposes are NOT intended. The combination of these two statements 130 can be restated as a manufacturer usage description (MUD) that can be 131 applied at various points within a network. Although this memo may 132 seem to stress access requirements, usage intent also consists of 133 quality of service needs a device may have. 135 We use the notion of "manufacturer" loosely in this context, to 136 simply mean the entity or organization that will state how a device 137 is intended to be used. In the context of a lightbulb, this might 138 indeed be the lightbulb manufacturer. In the context of a smarter 139 device that has a built in Linux stack, it might be integrator of 140 that device. The key points are that the device itself is expected 141 to serve a limited purpose, and that there may exist an organization 142 in the supply chain of that device that will take responsibility for 143 informing the network about that purpose. 145 The intent of MUD is to therefore solve for the following problems: 147 o Substantially reduce the threat surface on a device entering a 148 network to those communications intended by the manufacturer. 150 o Provide for a means to scale network policies to the ever- 151 increasing number types of devices in the network. 153 o Provide a means to address at least some vulnerabilities in a way 154 that is faster than it might take to update systems. This will be 155 particularly true for systems that are no longer supported by 156 their manufacturer. 158 o Keep the cost of implementation of such a system to the bare 159 minimum. 161 MUD therefore consists of three architectural building blocks: - A 162 classifier that a device emits that can be used to locate a 163 description; - The description itself, including how it is 164 interpreted, and; - A means to retrieve the description. 166 In this specification we specify each of these building blocks and 167 how they are intended to be used together. However, they may also be 168 used separately, independent of this specification by enterprise 169 networks for their own purposes. 171 1.1. What MUD doesn't do 173 MUD is not intended to address network authorization of general 174 computing, as their manufacturers cannot envision a specific 175 communication pattern to describe. In addition, even those devices 176 that have a single or small number of uses might have very broad 177 communication patterns. MUD on its own is not for them either. 179 No matter how good a MUD-enabled network is, it will never replace 180 the need for manufacturers to patch vulnerabilities. It may, 181 however, provide network administrators with some additional 182 protection when those vulnerabilities exist. 184 1.2. A Simple Example 186 A light bulb is intended to light a room. It may be remotely 187 controlled through the network; and it may make use of a rendezvous 188 service of some form that an app on smart phone accesses. What we 189 can say about that light bulb, then, is that all other network access 190 is unwanted. It will not contact a news service, nor speak to the 191 refrigerator, and it has no need of a printer or other devices. It 192 has no Facebook friends. Therefore, an access list applied to it 193 that states that it will only connect to the single rendezvous 194 service will not impede the light bulb in performing its function, 195 while at the same time allowing the network to provide both it and 196 other devices an additional layer of protection. 198 1.3. Determining Intended Use 200 The notion of intended use is in itself not new. Network 201 administrators apply access lists every day to allow for only such 202 use. This notion of white listing was well described by Chapman and 203 Zwicky in [FW95]. Programmatically profiling systems have existed 204 for years as well. These systems make use of heuristics that take at 205 least some time to assert what a system is. 207 A system could just as easily tell the network what sort of 208 protection it requires without going into what sort of system it is. 209 This would, in effect, be the converse of [RFC7488]. In seeking a 210 general purpose solution, however, we assume that a device has so few 211 capabilities that it will implement the least necessary capabilities 212 to function properly. This is a basic economic constraint. Unless 213 the network would refuse access to such a device, its developers 214 would have no reason to implement such an approach. To date, such an 215 assertion has held true. 217 1.4. Finding A Policy: The MUD URL 219 Our work begins, therefore, with the device emitting a Universal 220 Resource Locator (URL) [RFC3986]. This URL serves both to classify 221 the device type and to provide a means to locate a policy file. 223 In this memo three means are defined to emit the MUD URL. One is a 224 DHCP option[RFC2131],[RFC3315] that the DHCP client uses to inform 225 the DHCP server. The DHCP server may take further actions, such as 226 retrieve the URL or otherwise pass it along to network management 227 system or controller. The other method defined is an X.509 228 constraint. The IEEE has developed [IEEE8021AR] that provides a 229 certificate-based approach to communicate device characteristics, 230 which itself relies on [RFC5280]. The MUD URL extension is non- 231 critical, as required by IEEE 802.1AR. Various means may be used to 232 communicate that certificate, including Tunnel Extensible 233 Authentication Protocol (TEAP) [RFC7170]. Finally, a Link Layer 234 Discovery Protocol (LLDP) frame is defined [IEEE8021AB]. 236 It is possible that there may be other means for a MUD URL to be 237 learned by a network. For instance, if a device has a serial number, 238 it may be possible for the MUD controller to perform a lookup of the 239 device, if it has some knowledge as to who the device manufacturer 240 is, and what its MUD file server is. Such mechanisms are not 241 described in this memo, but are possible. 243 1.5. Types of Policies 245 When the MUD URL is resolved, the MUD controller retrieves a file 246 that describes what sort of communications a device is designed to 247 have. The manufacturer may specify either specific hosts for cloud 248 based services or certain classes for access within an operational 249 network. An example of a class might be "devices of a specified 250 manufacturer type", where the manufacturer type itself is indicated 251 simply by the authority component (e.g, the domain name) of the MUD 252 URL. Another example might to allow or disallow local access. Just 253 like other policies, these may be combined. For example: 255 Allow access to devices of the same manufacturer 256 Allow access to and from controllers who need to speak COAP 257 Allow access to local DNS/DHCP 258 Deny all other access 260 To add a bit more depth that should not be a stretch of anyone's 261 imagination, one could also make use of port-based access lists. 262 Thus a printer might have a description that states: 264 Allow access for port IPP or port LPD 265 Allow local access for port HTTP 266 Deny all other access 268 In this way anyone can print to the printer, but local access would 269 be required for the management interface. 271 The files that are retrieved are intended to be closely aligned to 272 existing network architectures so that they are easy to deploy. We 273 make use of YANG [RFC6020] because of the time and effort spent to 274 develop accurate and adequate models for use by network devices. 275 JSON is used as a serialization for compactness and readability, 276 relative to XML. 278 While the policy examples given here focus on access control, this is 279 not intended to be the sole focus. By structuring the model 280 described in this document with clear extension points, and by 281 leveraging YANG-based models, we provide the opportunity for new 282 policies to be introduced as required. 284 The YANG modules specified here are extensions of 285 [I-D.ietf-netmod-acl-model]. The extensions to this model allow for 286 a manufacturer to express classes of systems that a manufacturer 287 would find necessary for the proper function of the device. Two 288 modules are specified. The first module specifies a means for domain 289 names to be used in ACLs so that devices that have their controllers 290 in the cloud may be appropriately authorized with domain names, where 291 the mapping of those names to addresses may rapidly change. 293 The other module abstracts away IP addresses into certain classes 294 that are instantiated into actual IP addresses through local 295 processing. Through these classes, manufacturers can specify how the 296 device is designed to communicate, so that network elements can be 297 configured by local systems that have local topological knowledge. 298 That is, the deployment populates the classes that the manufacturer 299 specifies. The abstractions are as follows: 301 Manufacturer: A device made by a particular manufacturer, as 302 identified by the authority component of its MUD-URL 304 same-manufacturer: Devices that have the same authority component of 305 their MUD-URL. 307 Controller: A device that the local network administrator admits to 308 the particular class. 310 my-controller: A class associated with the MUD-URL of a device that 311 the administrator admits. 313 The "manufacturer" classes can be easily specified by the 314 manufacturer, whereas controller classes are initially envisioned to 315 be specified by the administrator. 317 Because manufacturers do not know who will be using their devices, it 318 is important for functionality referenced in usage descriptions to be 319 relatively ubiquitous, and therefore, mature. Therefore, only a a 320 limited subset YANG-based configuration of is permitted in a MUD 321 file. 323 1.6. Terminology 325 MUD: manufacturer usage description. 327 MUD file: a file containing YANG-based JSON that describes a 328 recommended behavior. 330 MUD file server: a web server that hosts a MUD file. 332 MUD controller: the system that requests and receives the MUD file 333 from the MUD server. After it has processed a MUD file it may 334 direct changes to relevant network elements. 336 MUD URL: a URL that can be used by the MUD controller to receive the 337 MUD file. 339 Thing: the end device that emits a MUD URL. 341 Manufacturer: the entity that configures the Thing to emit the MUD 342 URL and the one who asserts a recommendation in a MUD file. The 343 manufacturer might not always be the entity that constructs a 344 device. It could, for instance, be a systems integrator, or even 345 a component provider. 347 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 348 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 349 document are to be interpreted as described in [RFC2119]. 351 1.7. The Manufacturer Usage Description Architecture 353 With these components laid out we now have the basis for an 354 archicture. This leads us to ASCII art. 356 ......................................... 357 . ____________ . _____________ 358 . | | . | | 359 . | MUD |----->get URL->| MUD | 360 . | Controller | .(https) | File Server | 361 . End system network |____________|<--MUD file<--<|_____________| 362 . . . 363 . . . 364 . _______ _________ . 365 .| | (dhcp et al) | router | . 366 .| Thing |---->MUD URL-->| or | . 367 .|_______| | switch | . 368 . |_________| . 369 ......................................... 371 Figure 1: MUD Architecture 373 In the above diagram, the switch or router collects MUD URLs and 374 forwards them to the network management system for processing. This 375 happens in different ways, depending on how the URI is communicated. 376 For instance, in the case of DHCP, the DHCP server might receive the 377 URI and then process it. In the case of IEEE 802.1X, the switch 378 would carry the URI via a certificate to the authentication server 379 via EAP over Radius[RFC3748], which would then process it. One 380 method to do this is TEAP, described in [RFC7170]. The certificate 381 extension is described below. 383 The information returned by the web site is valid for the duration of 384 the device's connection, or as specified in the description. Thus if 385 the device is mobile, when it moves on, any configuration in the 386 switch is removed. Similarly, from time to time the description may 387 be refreshed, based on new capabilities or communication patterns or 388 vulnerabilities. 390 The web site is typically run by or on behalf of the manufacturer. 391 Its domain name is that of the authority found in the MUD URL. For 392 legacy cases where Things cannot emit a URL, if the switch is able to 393 determine the appropriate URI, it may proxy it, the trivial cases 394 being a map between some registered device or port and a URL. 396 The role of the MUD controller in this environment is to do the 397 following: 399 o receive MUD URLs, 401 o retrieve MUD files, 403 o translate abstractions in the MUD files to specific device 404 configuration, 406 o maintain and update any required mappings of the abstractions, and 408 o update network elements with appropriate configuration. 410 A MUD controller may be a component of a AAA or network management 411 system. Communication within those systems and from those systems to 412 network elements is beyond the scope of this memo. 414 1.8. Order of operations 416 As mentioned above, MUD contains architectural building blocks, and 417 so order of operation may vary. However, here is one clear intended 418 example: 420 1. Device emits URL. 422 2. That URL is forwarded to a MUD controller by the nearest switch 423 (how this happens depends on the way in which the MUD URL is 424 emitted). 426 3. The MUD controller retrieves the MUD file from the MUD file 427 server, assuming it doesn't already have a copy. It may test the 428 URL against a reputation service, and it may test any hosts 429 within the file against reputation services, as it deems fit. 431 4. The MUD controller may query the administrator for permission to 432 add the device and associated policy. If the device is known or 433 the device type is known, it may skip this step. 435 5. The MUD controller instantiates local configuration based on the 436 abstractions defined in this document. 438 6. The MUD controller configures the switch nearest the device. 439 Other systems may be configured as well. 441 7. When the device disconnects, policy is removed. 443 2. The MUD Model and Semantic Meaning 445 A MUD file consists of JSON based on a YANG model. For purposes of 446 MUD, the elements that can be modified are access lists as augmented 447 by this model. The MUD file is limited to the serialization of a 448 small number of YANG schema, including the models specified in the 449 following documents: 451 o [I-D.ietf-netmod-acl-model] 453 o [RFC6991] 455 The ACL model makes use of features for different forms of ACLs. For 456 purposes of MUD, any feature not related to addresses MAY be 457 included. Any feature related to addresses MUST NOT be included. 458 The reason for these statements is so that the broadest number of 459 implementations will understand the the MUD file without need for 460 negotiation. Furthermore, it is important to rely on appropriate 461 abstractions stated in this memo. It is the job of the MUD 462 controller to translate those abstractions to appropriate 463 configuration for each network element. 465 Publishers of MUD files MUST NOT include other elements except as 466 described in Section 3.6, and MUST only contain information relevant 467 to the device being described. Devices parsing MUD files MUST cease 468 processing if they find other elements. 470 ======= This module is structured into four parts: 472 o The first container, metainfo, holds information that is relevant 473 to retrieval and validity of the MUD file itself. 475 o The second container, device, describes the policies to be applied 476 to traffic to and from the device. The only policy currently 477 defined is a list of access control lists, but the from-device- 478 policy and to-device-policy containers serve as extension points 479 for subsequent augmentation. 481 o The third container augments the matching container of the ACL 482 model to add several elements that are relevant to the MUD URL, or 483 other otherwise abstracted for use within a local environment. 485 o The fourth container augments the tcp-acl container of the ACL 486 model to add the ability to match on the direction of initiation 487 of a TCP connection. 489 A simplified graphical representation of the data models is used in 490 this document. The meaning of the symbols in these diagrams is 491 defined in [I-D.ietf-netmod-rfc6087bis]. 493 module: ietf-mud 494 +--rw metainfo 495 | +--rw last-update? yang:date-and-time 496 | +--rw cache-validity? uint8 497 | +--rw masa-server? inet:uri 498 | +--rw is-supported? boolean 499 | +--rw systeminfo? inet:uri 500 | +--rw extensions* string 501 +--rw device 502 +--rw from-device-policy 503 | +--rw access-lists 504 | +--rw access-list* [acl-name acl-type] 505 | +--rw acl-name -> /acl:access-lists/acl/acl-name 506 | +--rw acl-type identityref 507 +--rw to-device-policy 508 +--rw access-lists 509 +--rw access-list* [acl-name acl-type] 510 +--rw acl-name -> /acl:access-lists/acl/acl-name 511 +--rw acl-type identityref 512 augment /acl:access-lists/acl:acl/acl:access-list-entries \ 513 /acl:ace/acl:matches: 514 +--rw mud-acl {mud-acl}? 515 +--rw manufacturer? inet:host 516 +--rw same-manufacturer? empty 517 +--rw model? string 518 +--rw local-networks? empty 519 +--rw controller? inet:uri 520 +--rw my-controller? empty 521 augment /acl:access-lists/acl:acl/acl:access-list-entries \ 522 /acl:ace/acl:matches/acl:tcp-acl: 523 +--rw direction-initiated? direction 525 3. Element Definitions 527 The following elements are defined. 529 3.1. last-update 531 This is a date-and-time value of when the MUD file was generated. 532 This is akin to a version number. Its form is taken from [RFC6991] 533 which, for those keeping score, turn was taken from Section 5.6 of 534 [RFC3339], which was taken from [ISO.8601.1988]. 536 3.2. cache-validity 538 This uint8 is the period of time in hours that a network management 539 station MUST wait since its last retrieval before checking for an 540 update. It is RECOMMENDED that this value be no less than 24 and 541 MUST NOT be more than 168 for any device that is supported. 543 3.3. masa-server 545 This optional element refers to the URL that should be used to 546 resolve the location any MASA service, as specified in 547 [I-D.ietf-anima-bootstrapping-keyinfra]. 549 3.4. is-supported 551 This boolean is an indication from the manufacturer to the network 552 administrator as to whether or not the device is supported. In this 553 context a device is said to be supported if the manufacturer might 554 issue an update to the device or if the manufacturer might update the 555 MUD file. 557 3.5. systeminfo 559 This is a URL that points to a description of the device to be 560 connected. The intent is for administrators to be able to read about 561 what the device is the first time the MUD-URL is used. 563 3.6. extensions 565 This optional leaf-list names MUD extensions that are used in the MUD 566 file. Note that NO MUD extensions may be used in a MUD file prior to 567 the extensions being declared. Implementations MUST ignore any 568 elements in this file that they do not understand. 570 3.7. packet-direction 572 [I-D.ietf-netmod-acl-model] describes access-lists but does not 573 attempt to indicate where they are applied as that is handled 574 elsewhere in a configuration. However, in this case, a MUD file must 575 be explicit in describing the communication pattern of a device, and 576 that includes indicating what is to be permitted or denied in either 577 direction of communication. This element takes a single value of 578 either "to-device" or "from-device", based on a typedef "direction". 579 This is applied specifically for TCP, and may be implemented either 580 via stateful or stateless approaches (e.g,. TCP flags) 582 3.8. manufacturer 584 This element consists of a hostname that would be matched against the 585 authority component of another device's MUD URL. In its simplest 586 form "manufacturer" and "same-manufacturer" may be implemented as 587 access-lists. In more complex forms, additional network capabilities 588 may be used. 590 3.9. same-manufacturer 592 This is an equivalent for when the manufacturer element is used to 593 indicate the authority that is found in another device's MUD URL 594 matches that of the authority found in this device's MUD URL. 596 3.10. model 598 This string matches the entire MUD URL, thus covering the model that 599 is unique within the context of the authority. It may also include 600 product version information. Thus how this field is constructed is 601 entirely a local matter for the manufacturer. 603 3.11. local-networks 605 This null-valued element expands to include local networks. Its 606 default expansion is that packets must not traverse toward a default 607 route that is received from the router. However, administrators may 608 expand the expression as is appropriate in their deployments. 610 3.12. controller 612 This URI specifies a value that a controller will register with the 613 mud controller. The element then is expanded to the set of hosts 614 that are so registered. This element may also be a URN. In this 615 case, the URN describes a well known service, such as DNS or NTP. 617 Great care should be used when invoking the controller class. For 618 one thing, it requires some understanding by the administrator as to 619 when it is appropriate. Classes that are standardized may make it 620 possible to code in certain intelligence. Nonstandard classes may 621 require substantially more care. Pre-registration in such classes by 622 controllers with the MUD server is encouraged. The mechanism to do 623 that is beyond the scope of this work. 625 3.13. my-controller 627 This null-valued element establishes a class of controllers that are 628 intended to control the device associated with a given MUD-URL. 630 3.14. direction-initiated 632 When applied this matches packets when the flow was initiated in the 633 corresponding direction. [RFC6092] specifies IPv6 guidance best 634 practices. While that document is scoped specifically to IPv6, its 635 contents are applicable for IPv4 as well. When this flag is set, and 636 the system has no reason to believe a flow has been initiated it MUST 637 drop the packet. This element may be implemented in its simplest 638 form by looking at naked SYN bits, but may also be implemented 639 through more stateful mechanisms. 641 4. Processing of the MUD file 643 To keep things relatively simple in addition to whatever definitions 644 exist, we also apply two additional default behaviors: 646 o Anything not explicitly permitted is denied. 648 o Local DNS and NTP are, by default, permitted to and from the 649 device. 651 An explicit description of the defaults can be found in Appendix B. 653 5. What does a MUD URL look like? 655 To begin with, MUD takes full advantage of both the https: scheme and 656 the use of .well-known. HTTPS is important in this case because a 657 man in the middle attack could otherwise harm the operation of a 658 class of devices. .well-known is used because we wish to add 659 additional structure to the URL. And so the URL appears as follows: 661 mud-url = "https://" authority "/.well-known/mud/" mud-rev 662 "/" model ( "?" extras ) 663 ; authority is from RFC3986 664 mud-rev = "v1" 665 model = segment ; from RFC3986 666 extras = query ; from RFC3986 668 mud-rev signifies the version of the manufacturer usage description 669 file. This memo specifies "v1" of that file. Later versions may 670 permit additional schemas or modify the format. In order to provide 671 for the broadest compatibility for the various transmission 672 mechanisms, the length of the URL for v1 MUST NOT exceed 255 octets. 674 "model" represents a device model as the manufacturer wishes to 675 represent it. It could be a brand name or something more specific. 676 It also may provide a means to indicate what version the product is. 677 Specifically if it has been updated in the field, this is the place 678 where evidence of that update would appear. The field should be 679 changed when the intended communication patterns of a device change. 680 While from a controller standpoint, only comparison and matching 681 operations are safe, it is envisioned that updates will require some 682 administrative review. Processing of this URL occurs as specified in 683 [RFC2818] and [RFC3986]. 685 6. The MUD YANG Model 687 file "ietf-mud@2017-07-03.yang" 688 module ietf-mud { 689 yang-version 1.1; 690 namespace "urn:ietf:params:xml:ns:yang:ietf-mud"; 691 prefix "ietf-mud"; 693 import ietf-access-control-list { 694 prefix "acl"; 695 } 697 import ietf-yang-types { 698 prefix "yang"; 699 } 701 import ietf-inet-types { 702 prefix "inet"; 703 } 705 organization 706 "IETF OPSAWG (Ops Area) Working Group"; 708 contact 709 "WG Web: http://tools.ietf.org/wg/opsawg/ 710 WG List: opsawg@ietf.org 711 Author: Eliot Lear 712 lear@cisco.com 713 Author: Ralph Droms 714 rdroms@gmail.com 715 Author: Dan Romascanu 716 dromasca@gmail.com 718 "; 720 description 721 "This YANG module defines a component that augments the 722 IETF description of an access list. This specific module 723 focuses on additional filters that include local, model, 724 and same-manufacturer. 726 Copyright (c) 2016,2017 IETF Trust and the persons 727 identified as the document authors. All rights reserved. 728 Redistribution and use in source and binary forms, with or 729 without modification, is permitted pursuant to, and subject 730 to the license terms contained in, the Simplified BSD 731 License set forth in Section 4.c of the IETF Trust's Legal 732 Provisions Relating to IETF Documents 733 (http://trustee.ietf.org/license-info). 734 This version of this YANG module is part of RFC XXXX; see 735 the RFC itself for full legal notices."; 737 revision "2017-07-03" { 738 description 739 "More work on ACL usage."; 740 reference "RFC XXXX: Manufacturer Usage Description 741 Specification"; 742 } 744 revision "2017-06-29" { 745 description 746 "Take packet directionality out of ACL. " + 747 "Introduce device container."; 748 reference "RFC XXXX: Manufacturer Usage Description 749 Specification"; 750 } 752 revision "2017-04-18" { 753 description "Base version of MUD extensions to ACL model"; 754 reference "RFC XXXX: Manufacturer Usage Description 755 Specification"; 757 } 759 typedef direction { 760 type enumeration { 761 enum to-device { 762 description "packets or flows destined to the target 763 device"; 764 } 765 enum from-device { 766 description "packets or flows destined from 767 the target device"; 768 } 769 } 770 description "Which way are we talking about?"; 771 } 773 identity mud-acl { 774 base "acl:acl-base"; 775 description 776 "ACL that contains MUD-specific access control list entries."; 777 } 779 feature mud-acl { 780 description 781 "MUD ACL augmentations supported."; 782 } 784 container metainfo { 786 description "Information about when support end(ed), and 787 when to refresh"; 789 leaf last-update { 790 type yang:date-and-time; 791 description "This is intended to be when 792 the MUD file was generated."; 793 } 795 leaf cache-validity { 796 type uint8 { 797 range "1..168"; 798 } 799 description "The information retrieved from the MUD server is 800 valid for these many hours, after which it should 801 be refreshed."; 802 } 804 leaf masa-server { 805 type inet:uri; 806 description "The URI of the MASA server that network 807 elements should forward requests to for this device."; 808 } 810 leaf is-supported { 811 type boolean; 812 description "The element is currently supported 813 by the manufacturer."; 814 } 815 leaf systeminfo { 816 type inet:uri; 817 description "A reference to a description of this device"; 818 } 820 leaf-list extensions { 821 type string; 822 description "A list of extension names that are used in this MUD 823 file. Each name is registered with the IANA and 824 described in an RFC."; 825 } 826 } 828 grouping access_lists { 829 description "A grouping for access lists in the context of device 830 policy."; 831 container access-lists { 832 description "The access lists that should be applied to traffic 833 to or from the device."; 834 list access-list { 835 key "acl-name acl-type"; 836 description "Each entry on this list refers to an ACL that 837 should be present in the overall access list 838 data model. Each ACL is identified by name and 839 type."; 840 leaf acl-name { 841 type leafref { 842 path "/acl:access-lists/acl:acl/acl:acl-name"; 843 } 844 description "The name of the ACL for this entry."; 845 } 846 leaf acl-type { 847 type identityref { 848 base acl:acl-base; 849 } 850 description "The type of the ACL for this entry."; 851 } 852 } 854 } 855 } 857 container device { 858 description "A container allowing us to associate data with the 859 device type being described in the instance document"; 861 container from-device-policy { 862 description "The policies that should be enforced on traffic 863 coming from the device. These policies are not 864 necessarily intended to be enforced at a single 865 point, but may be rendered by the controller to any 866 relevant enorcement points in the network or 867 elsewhere."; 868 uses access_lists; 869 } 871 container to-device-policy { 872 description "The policies that should be enforced on traffic 873 going to the device. These policies are not 874 necessarily intended to be enforced at a single 875 point, but may be rendered by the controller to any 876 relevant enorcement points in the network or 877 elsewhere."; 878 uses access_lists; 879 } 881 } 883 augment "/acl:access-lists/acl:acl/" + 884 "acl:access-list-entries/acl:ace/" + 885 "acl:matches" { 886 description "adding abstractions to avoid need of IP addresses"; 888 container mud-acl { 889 if-feature mud-acl; 890 must "../../../../acl:acl-type = 'ietf-mud:mud-acl'"; 892 description 893 "TODO; improve. MUD-specific matches."; 895 leaf manufacturer { 896 type inet:host; 897 description "authority component of the manufacturer URI"; 898 } 900 leaf same-manufacturer { 901 type empty; 902 description "expand to ACEs for each device 903 with the same origin"; 904 } 906 leaf model { 907 type string; 908 description "specific model (including version) for a 909 given manufacturer"; 910 } 912 leaf local-networks { 913 type empty; 914 description "this string is used to indicate networks 915 considered local in a given environment."; 916 } 918 leaf controller { 919 type inet:uri; 920 description "expands to one or more controllers for a 921 given service that is codified by inet:uri."; 922 } 924 leaf my-controller { 925 type empty; 926 description "The network should manage 927 a class of devices related to this MUD-URL that are 928 intended to control this device."; 929 } 930 } 932 } 934 augment "/acl:access-lists/acl:acl/" + 935 "acl:access-list-entries/acl:ace/" + 936 "acl:matches/acl:tcp-acl" { 937 description "Adding domain names to matching"; 938 leaf direction-initiated { 939 type direction; 940 description "which direction a flow was initiated"; 941 } 942 } 943 } 944 946 7. The Domain Name Extension to the ACL Model 948 This module specifies an extension to IETF-ACL model such that domain 949 names may be referenced by augmenting the "matches" element. 950 Different implementations may deploy differing methods to maintain 951 the mapping between IP address and domain name, if indeed any are 952 needed. However, the intent is that resources that are referred to 953 using a name should be authorized (or not) within an access list. 955 The structure of the change is as follows: 957 module: ietf-acldns 958 augment /acl:access-lists/acl:acl/acl:access-list-entries \ 959 /acl:ace/acl:matches/acl:ipv4-acl: 960 +--rw src-dnsname? inet:host 961 +--rw dst-dnsname? inet:host 962 augment /acl:access-lists/acl:acl/acl:access-list-entries \ 963 /acl:ace/acl:matches/acl:ipv6-acl: 964 +--rw src-dnsname? inet:host 965 +--rw dst-dnsname? inet:host 967 The choice of these particular points in the access-list model is 968 based on the assumption that we are in some way referring to IP- 969 related resources, as that is what the DNS returns. A domain name in 970 our context is defined in [RFC6991]. The augmentations are 971 replicated across IPv4 and IPv6 to allow MUD file autjors the ability 972 to control the IP version that the device may utilize. 974 The following elements are defined. 976 7.1. source-dnsname 978 The argument corresponds to a domain name of a source as specified by 979 inet:host. Depending on how the model is used, it may or may not be 980 resolved, as required by the implementation and circumstances. 982 7.2. destination-dnsname 984 The argument corresponds to a domain name of a destination as 985 specified by inet:host. Depending on how the model is used, it may 986 or may not be resolved, as required by the implementation and 987 circumstances. 989 7.3. The ietf-acldns Model 991 file "ietf-acldns@2016-07-20.yang" 992 module ietf-acldns { 993 yang-version 1.1; 994 namespace "urn:ietf:params:xml:ns:yang:ietf-acldns"; 995 prefix "ietf-acldns"; 997 import ietf-access-control-list { 998 prefix "acl"; 999 } 1001 import ietf-inet-types { 1002 prefix "inet"; 1003 } 1005 organization 1006 "IETF OPSAWG (Ops Area) Working Group"; 1008 contact 1009 "WG Web: http://tools.ietf.org/wg/opsawg/ 1010 WG List: opsawg@ietf.org 1011 Author: Eliot Lear 1012 lear@cisco.com 1013 Author: Ralph Droms 1014 rdroms@gmail.com 1015 Author: Dan Romascanu 1016 dromasca@gmail.com 1017 "; 1019 description 1020 "This YANG module defines a component that augments the 1021 IETF description of an access list to allow dns names 1022 as matching criteria."; 1024 revision "2017-07-03" { 1025 description "Clone across IP ACL types."; 1026 reference "RFC XXXX: Manufacturer Usage Description 1027 Specification"; 1028 } 1030 revision "2016-07-20" { 1031 description "Base version of dnsname extension of ACL model"; 1032 reference "RFC XXXX: Manufacturer Usage Description 1033 Specification"; 1034 } 1036 grouping DNS_MATCHES { 1037 description "Domain names for matching."; 1039 leaf src-dnsname { 1040 type inet:host; 1041 description "domain name to be matched against"; 1043 } 1044 leaf dst-dnsname { 1045 type inet:host; 1046 description "domain name to be matched against"; 1047 } 1048 } 1050 augment "/acl:access-lists/acl:acl/" + 1051 "acl:access-list-entries/acl:ace/" + 1052 "acl:matches/acl:ipv4-acl" { 1053 description "Adding domain names to matching"; 1054 uses DNS_MATCHES; 1055 } 1057 augment "/acl:access-lists/acl:acl/" + 1058 "acl:access-list-entries/acl:ace/" + 1059 "acl:matches/acl:ipv6-acl" { 1060 description "Adding domain names to matching"; 1061 uses DNS_MATCHES; 1062 } 1063 } 1064 1066 8. MUD File Example 1068 This example contains two access lists that are intended to provide 1069 outbound access to a cloud service on TCP port 443. 1071 { 1072 "ietf-mud:metainfo": { 1073 "lastUpdate": "2017-08-06T18:55:07+02:00", 1074 "systeminfo": "https://example.com/productinfo/LightingSystem3000", 1075 "cacheValidity": 168 1076 }, 1077 "ietf-mud:device": { 1078 "from-device-policy": { 1079 "access-lists": { 1080 "access-list": [ 1081 { 1082 "acl-name": "mud-66805-v6out", 1083 "acl-type": "ietf-access-control-list:ipv6-acl" 1084 } 1085 ] 1086 } 1087 }, 1088 "to-device-policy": { 1089 "access-lists": { 1090 "access-list": [ 1091 { 1092 "acl-name": "mud-66805-v6in", 1093 "acl-type": "ietf-access-control-list:ipv6-acl" 1094 } 1095 ] 1096 } 1097 } 1098 }, 1099 "ietf-access-control-list:access-lists": { 1100 "acl": [ 1101 { 1102 "acl-name": "mud-66805-v6in", 1103 "acl-type": "ipv6-acl", 1104 "access-list-entries": { 1105 "ace": [ 1106 { 1107 "rule-name": "cl0-in", 1108 "matches": { 1109 "ipv6-acl": { 1110 "ietf-acldns:src-dnsname": "lighting-system.example.com" 1111 }, 1112 "source-port-range": { 1113 "lower-port": 443, 1114 "upper-port": 443 1115 }, 1116 "tcp-acl": { 1117 "ietf-mud:direction-initiated": "from-device" 1118 } 1119 }, 1120 "actions": { 1121 "permit": [ 1122 null 1123 ] 1124 } 1125 } 1126 ] 1127 } 1128 }, 1129 { 1130 "acl-name": "mud-66805-v6out", 1131 "acl-type": "ipv6-acl", 1132 "access-list-entries": { 1133 "ace": [ 1134 { 1135 "rule-name": "cl0-out", 1136 "matches": { 1137 "ipv6-acl": { 1138 "ietf-acldns:dst-dnsname": "lighting-system.example.com" 1139 }, 1140 "destination-port-range": { 1141 "lower-port": 443, 1142 "upper-port": 443 1143 }, 1144 "tcp-acl": { 1145 "ietf-mud:direction-initiated": "from-device" 1146 } 1147 }, 1148 "actions": { 1149 "permit": [ 1150 null 1151 ] 1152 } 1153 } 1154 ] 1155 } 1156 } 1157 ] 1158 } 1159 } 1161 In this example, two policies are declared, one from the device and 1162 the other to the device. Each policy names an access list that 1163 applies to the device, and one that applies from. Within each access 1164 list, access is permitted to packets flowing to or from the device 1165 that can be mapped to the domain name of lighting-system.example.com. 1166 For each access list, the enforcement point should expect that the 1167 thing initiated the connection. 1169 9. The MUD URL DHCP Option 1171 The IPv4 MUD URL client option has the following format: 1173 +------+-----+------------------------------ 1174 | code | len | MUD URL 1175 +------+-----+------------------------------ 1177 Code OPTION_MUD_URL_V4 (161) is assigned by IANA. len is a single 1178 octet that indicates the length of the URL in octets. MUD URL is a 1179 URL. MUD URLs MUST NOT exceed 255 octets. 1181 The IPv6 MUD URL client option has the following format: 1183 0 1 2 3 1184 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 1185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1186 | OPTION_MUD_URL_V6 | option-length | 1187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 | MUD URL | 1189 | ... | 1190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 OPTION_MUD_URL_V6 (112; assigned by IANA). 1194 option-length contains the length of the URL in octets. 1196 The intent of this option is to provide both a new device classifier 1197 to the network as well as some recommended configuration to the 1198 routers that implement policy. However, it is entirely the purview 1199 of the network system as managed by the network administrator to 1200 decide what to do with this information. The key function of this 1201 option is simply to identify the type of device to the network in a 1202 structured way such that the policy can be easily found with existing 1203 toolsets. 1205 9.1. Client Behavior 1207 A DHCPv4 client MAY emit a DHCPv4 option and a DHCPv6 client MAY emit 1208 DHCPv6 option. These options are singletons, as specified in 1209 [RFC7227]. Because clients are intended to have at most one MUD URL 1210 associated with them, they may emit at most one MUD URL option via 1211 DHCPv4 and one MUD URL option via DHCPv6. In the case where both v4 1212 and v6 DHCP options are emitted, the same URL MUST be used. 1214 Clients SHOULD log or otherwise report improper acknowledgments from 1215 servers, but they MUST NOT modify their MUD URL configuration based 1216 on a server's response. The server's response is only an 1217 acknowledgment that the server has processed the option, and promises 1218 no specific network behavior to the client. In particular, it may 1219 not be possible for the server to retrieve the file associated with 1220 the MUD URL, or the local network administration may not wish to use 1221 the usage description. Neither of these situations should be 1222 considered in any way exceptional. 1224 9.2. Server Behavior 1226 A DHCP server may ignore these options or take action based on 1227 receipt of these options. If a server successfully parses the option 1228 and the URL, it MUST return the option with length field set to zero 1229 and a corresponding null URL field as an acknowledgment. Even in 1230 this circumstance, no specific network behavior is guaranteed. When 1231 a server consumes this option, it will either forward the URL and 1232 relevant client information to a network management system (such as 1233 the giaddr), or it will retrieve the usage description by resolving 1234 the URL. 1236 DHCP servers may implement MUD functionality themselves or they may 1237 pass along appropriate information to a network management system or 1238 MUD controller. A DHCP server that does process the MUD URL MUST 1239 adhere to the process specified in [RFC2818] and [RFC5280] to 1240 validate the TLS certificate of the web server hosting the MUD file. 1241 Those servers will retrieve the file, process it, create and install 1242 the necessary configuration on the relevant network element. Servers 1243 SHOULD monitor the gateway for state changes on a given interface. A 1244 DHCP server that does not provide MUD functionality and has forwarded 1245 a MUD URL to a MUD controller MUST notify the MUD controller of any 1246 corresponding change to the DHCP state of the client (such as 1247 expiration or explicit release of a network address lease). 1249 9.3. Relay Requirements 1251 There are no additional requirements for relays. 1253 10. The Manufacturer Usage Description (MUD) URL X.509 Extension 1255 This section defines an X.509 non-critical certificate extension that 1256 contains a single Uniform Resource Identifier (URI) that points to an 1257 on-line Manufacturer Usage Description concerning the certificate 1258 subject. URI must be represented as described in Section 7.4 of 1259 [RFC5280]. 1261 Any Internationalized Resource Identifiers (IRIs) MUST be mapped to 1262 URIs as specified in Section 3.1 of [RFC3987] before they are placed 1263 in the certificate extension. 1265 The semantics of the URI are defined Section 5 of this document. 1267 The choice of id-pe is based on guidance found in Section 4.2.2 of 1268 [RFC5280]: 1270 These extensions may be used to direct applications to on-line 1271 information about the issuer or the subject. 1273 The MUD URL is precisely that: online information about the 1274 particular subject. 1276 The new extension is identified as follows: 1278 1280 MUDURLExtnModule-2016 { iso(1) identified-organization(3) dod(6) 1281 internet(1) security(5) mechanisms(5) pkix(7) 1282 id-mod(0) id-mod-mudURLExtn2016(88) } 1284 DEFINITIONS IMPLICIT TAGS ::= BEGIN 1286 -- EXPORTS ALL -- 1288 IMPORTS 1289 EXTENSION 1290 FROM PKIX-CommonTypes-2009 1291 { iso(1) identified-organization(3) dod(6) internet(1) 1292 security(5) mechanisms(5) pkix(7) id-mod(0) 1293 id-mod-pkixCommon-02(57) } 1295 id-pe 1296 FROM PKIX1Explicit-2009 1297 { iso(1) identified-organization(3) dod(6) internet(1) 1298 security(5) mechanisms(5) pkix(7) id-mod(0) 1299 id-mod-pkix1-explicit-02(51) } ; 1300 MUDCertExtensions EXTENSION ::= { ext-MUDURL, ... } 1301 ext-MUDURL EXTENSION ::= { SYNTAX MUDURLSyntax 1302 IDENTIFIED BY id-pe-mud-url } 1304 id-pe-mud-url OBJECT IDENTIFIER ::= { id-pe 25 } 1306 MUDURLSyntax ::= IA5String 1308 END 1310 1312 While this extension can appear in either an 802.AR manufacturer 1313 certificate (IDevID) or deployment certificate (LDevID), of course it 1314 is not guaranteed in either, nor is it guaranteed to be carried over. 1315 It is RECOMMENDED that MUD controller implementations maintain a 1316 table that maps a device to its MUD-URL. 1318 11. The Manufacturer Usage Description LLDP extension 1320 The IEEE802.1AB Link Layer Discovery Protocol (LLDP) is a one hop 1321 vendor-neutral link layer protocols used by end hosts network devices 1322 for advertising their identity, capabilities, and neighbors on an 1323 IEEE 802 local area network. Its Type-Length-Value (TLV) design 1324 allows for 'vendor-specific' extensions to be defined. IANA has a 1325 registered IEEE 802 organizationally unique identifier (OUI) defined 1326 as documented in [RFC7042]. The MUD LLDP extension uses a subtype 1327 defined in this document to carry the MUD URL. 1329 The LLDP vendor specific frame has the following format: 1331 +--------+--------+----------+---------+-------------- 1332 |TLV Type| len | OUI |subtype | MUD URL 1333 | =127 | |= 00 00 5E| = 1 | 1334 |(7 bits)|(9 bits)|(3 octets)|(1 octet)|(1-255 octets) 1335 +--------+--------+----------+---------+-------------- 1337 where: 1339 o TLV Type = 127 indicates a vendor-specific TLV 1341 o len - indicates the TLV string length 1343 o OUI = 00 00 5E is the organizationally unique identifier of IANA 1345 o subtype = 1 (to be assigned by IANA for the MUD URL) 1347 o MUD URL - the length MUST NOT exceed 255 octets 1349 The intent of this extension is to provide both a new device 1350 classifier to the network as well as some recommended configuration 1351 to the routers that implement policy. However, it is entirely the 1352 purview of the network system as managed by the network administrator 1353 to decide what to do with this information. The key function of this 1354 extension is simply to identify the type of device to the network in 1355 a structured way such that the policy can be easily found with 1356 existing toolsets. 1358 Hosts, routers, or other network devices that implement this option 1359 are intended to have at most one MUD URL associated with them, so 1360 they may transmit at most one MUD URL value. 1362 Hosts, routers, or other network devices that implement this option 1363 may ignore these options or take action based on receipt of these 1364 options. For example they may fill in information in the respective 1365 extensions of the LLDP Management Information Base (LLDP MIB). LLDP 1366 operates in a one-way direction. LLDPDUs are not exchanged as 1367 information requests by one device and response sent by another 1368 device. The other devices do not acknowledge LLDP information 1369 received from a device. No specific network behavior is guaranteed. 1370 When a device consumes this extension, it may either forward the URL 1371 and relevant remote device information to a MUD controller, or it 1372 will retrieve the usage description by resolving the URL. 1374 12. Creating and Processing of Signed MUD Files 1376 Because MUD files contain information that may be used to configure 1377 network access lists, they are sensitive. To insure that they have 1378 not been tampered with, it is important that they be signed. We make 1379 use of DER-encoded Cryptographic Message Syntax (CMS) [RFC5652] for 1380 this purpose. 1382 12.1. Creating a MUD file signature 1384 A MUD file MUST be signed using CMS as an opaque binary object. In 1385 order to make successful verification more likely, intermediate 1386 certificates SHOULD be included. The signature is stored at the same 1387 location as the MUD URL but with the suffix of ".p7s". Signatures 1388 are transferred using content-type "Application/pkcs7-signature". 1390 For example: 1392 % openssl cms -sign -signer mancertfile -inkey mankey \ 1393 -in mudfile -binary -outform DER - \ 1394 -certfile intermediatecert -out mudfile.p7s 1396 Note: A MUD file may need to be re-signed if the signature expires. 1398 12.2. Verifying a MUD file signature 1400 Prior to retrieving a MUD file the MUD controller SHOULD retrieve the 1401 MUD signature file using the MUD URL with a suffix of ".p7s". For 1402 example, if the MUD URL is "https://example.com/.well-known/v1/ 1403 modela", the MUD signature URL will be "https://example.com/.well- 1404 known/v1/modela.p7s". 1406 Upon retrieving a MUD file, a MUD controller MUST validate the 1407 signature of the file before continuing with further processing. A 1408 MUD controller SHOULD produce an error and it MUST cease all 1409 processing of that file if the signature cannot be validated. It is 1410 important that MUD controllers have some reason to trust the 1411 certificates they are seeing. Therefore, it is RECOMMENDED that new 1412 signers be validated either directly by an administrator or by a 1413 service that has some reason to believe that the signer is a good 1414 actor. 1416 For Example: 1418 % openssl cms -verify -in mudfile.p7s -inform DER -content mudfile 1420 Note the additional step of verifying the common trust root. 1422 13. Extensibility 1424 One of our design goals is to see that MUD files are able to be 1425 understood by as broad a cross-section of systems as is possible. 1426 Coupled with the fact that we have also chosen to leverage existing 1427 mechanisms, we are left with no ability to negotiate extensions and a 1428 limited desire for those extensions in any event. A such, a two-tier 1429 extensibility framework is employed, as follows: 1431 1. At a coarse grain, a protocol version is included in a MUD URL. 1432 This memo specifies MUD version 1. Any and all changes are 1433 entertained when this version is bumped. Transition approaches 1434 between versions would be a matter for discussion in future 1435 versions. 1437 2. At a finer grain, only extensions that would not incur additional 1438 risk to the device are permitted. Specifically, augmenting of 1439 the metainfo container is permitted with the understanding that 1440 such additions may be ignored. In addition, augmentation of the 1441 ACL model is permitted so long as it remains safe for a given ACE 1442 to be ignored by the MUD Controller or the network elements it 1443 configures. Most specifically, one MUST NOT augment behavior of 1444 the acl "deny" action. Furthermore, implementations that are not 1445 able to parse a component of the ACE array MUST ignore the entire 1446 array entry (e.g., not the entire array) and MAY ignore the 1447 entire MUD file or otherwise prompt the administrator. 1449 14. Deployment Considerations 1451 Because MUD consists of a number of architectural building blocks, it 1452 is possible to assemble different deployment scenarios. One key 1453 aspect is where to place policy enforcement. In order to protect the 1454 device from other devices within a local deployment, policy can be 1455 enforced on the nearest switch or access point. In order to limit 1456 unwanted traffic within a network, it may also be advisable to 1457 enforce policy as close to the Internet as possible. In some 1458 circumstances, policy enforcement may not be available at the closest 1459 hop. At that point, the risk of so-called east-west infection is 1460 increased to the number of devices that are able to communicate 1461 without protection. 1463 A caution about some of the classes: admission of a device into the 1464 "manufacturer" and "same-manufacturer" class may have impact on 1465 access of other devices. Put another way, the admission may grow the 1466 access-list on switches connected to other devices, depending on how 1467 access is managed. Therefore, care should be given on managing that 1468 access-list growth. Alternative methods such as additional 1469 segmentation can be used to keep that growth within reason. 1471 15. Security Considerations 1473 Based on how a MUD-URL is emitted, a device may be able to lie about 1474 what it is, thus gaining additional network access. There are 1475 several means to limit risk in this case. The most obvious is to 1476 only believe devices that make use of certificate-based 1477 authentication such as IEEE 802.1AR certificates. When those 1478 certificates are not present, devices claiming to be of a certain 1479 manufacturer SHOULD NOT be included in that manufacturer grouping 1480 without additional validation of some form. This will occur when it 1481 makes use of primitives such as "manufacturer" for the purpose of 1482 accessing devices of a particular type. Similarly, network 1483 management systems may be able to fingerprint the device. In such 1484 cases, the MUD-URL can act as a classifier that can be proven or 1485 disproven. Fingerprinting may have other advantages as well: when 1486 802.1AR certificates are used, because they themselves cannot change, 1487 fingerprinting offers the opportunity to add artificats to the MUD- 1488 URL. The meaning of such artifacts is left as future work. 1490 Network management systems SHOULD NOT accept a usage description for 1491 a device with the same MAC address that has indicated a change of 1492 authority without some additional validation (such as review of the 1493 class). New devices that present some form of unauthenticated MUD 1494 URL SHOULD be validated by some external means when they would be 1495 otherwise be given increased network access. 1497 It may be possible for a rogue manufacturer to inappropriately 1498 exercise the MUD file parser, in order to exploit a vulnerability. 1499 There are three recommended approaches to address this threat. The 1500 first is to validate the signature of the MUD file. The second is to 1501 have a system do a primary scan of the file to ensure that it is both 1502 parseable and believable at some level. MUD files will likely be 1503 relatively small, to start with. The number of ACEs used by any 1504 given device should be relatively small as well. It may also be 1505 useful to limit retrieval of MUD URLs to only those sites that are 1506 known to have decent web reputations. 1508 Use of a URL necessitates the use of domain names. If a domain name 1509 changes ownership, the new owner of that domain may be able to 1510 provide MUD files that MUD controllers would consider valid. There 1511 are a few approaches that can mitigate this attack. First, MUD 1512 controllers SHOULD cache certificates used by the MUD file server. 1513 When a new certificate is retrieved for whatever reason, the MUD 1514 controller should check to see if ownership of the domain has 1515 changed. A fair programmatic approximation of this is when the name 1516 servers for the domain have changed. If the actual MUD file has 1517 changed, the controller MAY check the WHOIS database to see if 1518 registration ownership of a domain has changed. If a change has 1519 occured, or if for some reason it is not possible to determine 1520 whether ownership has changed, further review may be warranted. 1521 Note, this remediation does not take into account the case of a 1522 device that was produced long ago and only recently fielded, or the 1523 case where a new MUD controller has been installed. 1525 The release of a MUD URL by a device reveals what the device is, and 1526 provides an attacker with guidance on what vulnerabilities may be 1527 present. 1529 While the MUD URL itself is not intended to be unique to a specific 1530 device, the release of the URL may aid an observer in identifying 1531 individuals when combined with other information. This is a privacy 1532 consideration. 1534 In addressing both of these concerns, implementors should take into 1535 account what other information they are advertising through 1536 mechanisms such as mDNS[RFC6872], how a device might otherwise be 1537 identified, perhaps through how it behaves when it is connected to 1538 the network, whether a device is intended to be used by individuals 1539 or carry personal identifying information, and then apply appropriate 1540 data minimization techniques. One approach is to make use of TEAP 1541 [RFC7170] as the means to share information with authorized 1542 components in the network. Network devices may also assist in 1543 limiting access to the MUD-URL through the use of mechanisms such as 1544 DHCPv6-Shield [RFC7610]. 1546 Please note that the security considerations mentioned in Section 4.7 1547 of [I-D.ietf-netmod-rfc6087bis] are not applicable in this case 1548 because the YANG serialization is not intended to be accessed via 1549 NETCONF. However, for those who try to instantiate this model in a 1550 device via NETCONF, all objects in each model in this draft exhibit 1551 similar security characteristics as [I-D.ietf-netmod-acl-model]. The 1552 basic purpose of MUD is to configure access, and so by its very 1553 nature can be disruptive if used by unauthorized parties. 1555 16. IANA Considerations 1557 16.1. YANG Module Registrations 1559 The following YANG modules are requested to be registred in the "IANA 1560 Module Names" registry: 1562 The ietf-mud module: 1564 o Name: ietf-mud 1566 o XML Namespace: urn:ietf:params:xml:ns:yang:ietf-mud 1567 o Prefix: ief-mud 1569 o Reference: This memo 1571 The ietf-acldns module: 1573 o Name: ietf-acldns 1575 o XML Namespace: urn:ietf:params:xml:ns:yang:ietf-acldns 1577 o Prefix: ietf-acldns 1579 o Reference: This memo 1581 16.2. DHCPv4 and DHCPv6 Options 1583 The IANA has allocated option 161 in the Dynamic Host Configuration 1584 Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters registry 1585 for the MUD DHCPv4 option. 1587 IANA is requested to allocated the DHCPv4 and v6 options as specified 1588 in Section 9. 1590 16.3. PKIX Extensions 1592 IANA is kindly requested to make the following assignments for: 1594 o The MUDURLExtnModule-2016 ASN.1 module in the "SMI Security for 1595 PKIX Module Identifier" registry (1.3.6.1.5.5.7.0). 1597 o id-pe-mud-url object identifier from the "SMI Security for PKIX 1598 Certificate Extension" registry (1.3.6.1.5.5.7.1). 1600 The use fo these values is specified in Section 10. 1602 16.4. Well Known URI Suffix 1604 The IANA has allocated the URL suffix of "mud" as follows: 1606 o URI Suffix: "mud" o Specification documents: this document o 1607 Related information: n/a 1609 16.5. MIME Media-type Registration for MUD files 1611 The following media-type is defined for transfer of MUD file: 1613 o Type name: application 1614 o Subtype name: mud+json 1615 o Required parameters: n/a 1616 o Optional parameters: n/a 1617 o Encoding considerations: 8bit; application/mud+json values 1618 are represented as a JSON object; UTF-8 encoding SHOULD be 1619 employed. 1620 o Security considerations: See {{secon}} of this document. 1621 o Interoperability considerations: n/a 1622 o Published specification: this document 1623 o Applications that use this media type: MUD controllers as 1624 specified by this document. 1625 o Fragment identifier considerations: n/a 1626 o Additional information: 1628 Magic number(s): n/a 1629 File extension(s): n/a 1630 Macintosh file type code(s): n/a 1632 o Person & email address to contact for further information: 1633 Eliot Lear , Ralph Droms 1634 o Intended usage: COMMON 1635 o Restrictions on usage: none 1636 o Author: 1637 Eliot Lear 1638 Ralph Droms 1639 o Change controller: IESG 1640 o Provisional registration? (standards tree only): No. 1642 16.6. LLDP IANA TLV Subtype Registry 1644 IANA is requested to create a new registry for IANA Link Layer 1645 Discovery Protocol (LLDP) TLV subtype values. The recommended policy 1646 for this registry is Expert Review. The maximum number of entries in 1647 the registry is 256. 1649 IANA is required to populate the initial registry with the value: 1651 LLDP subtype value = 1 (All the other 255 values should be initially 1652 marked as 'Unassigned'.) 1654 Description = the Manufacturer Usage Description (MUD) Uniform 1655 Resource Locator (URL) 1657 Reference = < this document > 1659 16.7. The MUD Well Known Universal Resource Name (URNs) 1661 The following parameter registry is requested to be added in 1662 accordance with [RFC3553] 1664 Registry name: "urn:ietf:params:mud" is requested. 1665 Specification: this document 1666 Repository: this document 1667 Index value: Encoded identically to a TCP/UDP port service 1668 name, as specified in Section 5.1 of [RFC6335] 1670 The following entries should be added to the "urn:ietf:params:mud" 1671 name space: 1673 "urn:ietf:params:mud:dns" refers to the service specified by 1674 [RFC1123]. "urn:ietf:params:mud:ntp" refers to the service specified 1675 by [RFC5905]. 1677 17. Acknowledgments 1679 The authors would like to thank Einar Nilsen-Nygaard, who 1680 singlehandedly updated the model to match the updated ACL model, 1681 Bernie Volz, Tom Gindin, Brian Weis, Sandeep Kumar, Thorsten Dahm, 1682 John Bashinski, Steve Rich, Jim Bieda, and Dan Wing for their 1683 valuable advice and reviews. Russ Housley entirely rewrote 1684 Section 10 to be a complete module. Adrian Farrel provided the basis 1685 for privacy considerations text. Kent Watson provided a thorough 1686 review of the archictecture and the YANG model. The remaining errors 1687 in this work are entirely the responsibility of the author. 1689 18. References 1691 18.1. Normative References 1693 [I-D.ietf-anima-bootstrapping-keyinfra] 1694 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 1695 S., and K. Watsen, "Bootstrapping Remote Secure Key 1696 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 1697 keyinfra-07 (work in progress), July 2017. 1699 [I-D.ietf-netmod-acl-model] 1700 Bogdanovic, D., Jethanandani, M., Huang, L., Agarwal, S., 1701 and D. Blair, "Network Access Control List (ACL) YANG Data 1702 Model", draft-ietf-netmod-acl-model-11 (work in progress), 1703 June 2017. 1705 [I-D.ietf-netmod-rfc6087bis] 1706 Bierman, A., "Guidelines for Authors and Reviewers of YANG 1707 Data Model Documents", draft-ietf-netmod-rfc6087bis-13 1708 (work in progress), June 2017. 1710 [IEEE8021AB] 1711 Institute for Electrical and Electronics Engineers, "IEEE 1712 Standard for Local and Metropolitan Area Networks-- 1713 Station and Media Access Control Connectivity Discovery", 1714 n.d.. 1716 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 1717 Application and Support", STD 3, RFC 1123, 1718 DOI 10.17487/RFC1123, October 1989, 1719 . 1721 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1722 Requirement Levels", BCP 14, RFC 2119, 1723 DOI 10.17487/RFC2119, March 1997, 1724 . 1726 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1727 RFC 2131, DOI 10.17487/RFC2131, March 1997, 1728 . 1730 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1731 DOI 10.17487/RFC2818, May 2000, 1732 . 1734 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 1735 C., and M. Carney, "Dynamic Host Configuration Protocol 1736 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 1737 2003, . 1739 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1740 Levkowetz, Ed., "Extensible Authentication Protocol 1741 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 1742 . 1744 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1745 Resource Identifier (URI): Generic Syntax", STD 66, 1746 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1747 . 1749 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 1750 Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, 1751 January 2005, . 1753 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1754 Housley, R., and W. Polk, "Internet X.509 Public Key 1755 Infrastructure Certificate and Certificate Revocation List 1756 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1757 . 1759 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1760 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1761 . 1763 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1764 "Network Time Protocol Version 4: Protocol and Algorithms 1765 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1766 . 1768 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1769 the Network Configuration Protocol (NETCONF)", RFC 6020, 1770 DOI 10.17487/RFC6020, October 2010, 1771 . 1773 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 1774 Capabilities in Customer Premises Equipment (CPE) for 1775 Providing Residential IPv6 Internet Service", RFC 6092, 1776 DOI 10.17487/RFC6092, January 2011, 1777 . 1779 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 1780 Cheshire, "Internet Assigned Numbers Authority (IANA) 1781 Procedures for the Management of the Service Name and 1782 Transport Protocol Port Number Registry", BCP 165, 1783 RFC 6335, DOI 10.17487/RFC6335, August 2011, 1784 . 1786 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1787 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1788 . 1790 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 1791 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 1792 BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, 1793 . 1795 [RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: 1796 Protecting against Rogue DHCPv6 Servers", BCP 199, 1797 RFC 7610, DOI 10.17487/RFC7610, August 2015, 1798 . 1800 18.2. Informative References 1802 [FW95] Chapman, D. and E. Zwicky, "Building Internet Firewalls", 1803 January 1995. 1805 [IEEE8021AR] 1806 Institute for Electrical and Electronics Engineers, 1807 "Secure Device Identity", 1998. 1809 [ISO.8601.1988] 1810 International Organization for Standardization, "Data 1811 elements and interchange formats - Information interchange 1812 - Representation of dates and times", ISO Standard 8601, 1813 June 1988. 1815 [RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic 1816 Technology and the Internet", BCP 200, RFC 1984, 1817 DOI 10.17487/RFC1984, August 1996, 1818 . 1820 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1821 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 1822 . 1824 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 1825 IETF URN Sub-namespace for Registered Protocol 1826 Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 1827 2003, . 1829 [RFC6872] Gurbani, V., Ed., Burger, E., Ed., Anjali, T., Abdelnur, 1830 H., and O. Festor, "The Common Log Format (CLF) for the 1831 Session Initiation Protocol (SIP): Framework and 1832 Information Model", RFC 6872, DOI 10.17487/RFC6872, 1833 February 2013, . 1835 [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and 1836 IETF Protocol and Documentation Usage for IEEE 802 1837 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, 1838 October 2013, . 1840 [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 1841 "Tunnel Extensible Authentication Protocol (TEAP) Version 1842 1", RFC 7170, DOI 10.17487/RFC7170, May 2014, 1843 . 1845 [RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, 1846 "Architectural Considerations in Smart Object Networking", 1847 RFC 7452, DOI 10.17487/RFC7452, March 2015, 1848 . 1850 [RFC7488] Boucadair, M., Penno, R., Wing, D., Patil, P., and T. 1851 Reddy, "Port Control Protocol (PCP) Server Selection", 1852 RFC 7488, DOI 10.17487/RFC7488, March 2015, 1853 . 1855 Appendix A. Changes from Earlier Versions 1857 RFC Editor to remove this section prior to publication. 1859 Draft -06 to -07: 1861 o Examples updated. 1863 o Additional clarification for direction-initiated. 1865 o Additional implementation guidance given. 1867 Draft -06 to -07: 1869 o Update models to match new ACL model 1871 o extract directionality from the ACL, introducing a new device 1872 container. 1874 Draft -05 to -06: 1876 o Make clear that this is a component architecture (Polk and Watson) 1878 o Add order of operations (Watson) 1880 o Add extensions leaf-list (Pritikin) 1882 o Remove previous-mud-file (Watson) 1884 o Modify text in last-update (Watson) 1886 o Clarify local networks (Weis, Watson) 1888 o Fix contact info (Watson) 1890 o Terminology clarification (Weis) 1892 o Advice on how to handle LDevIDs (Watson) 1893 o Add deployment considerations (Watson) 1895 o Add some additional text about fingerprinting (Watson) 1897 o Appropriate references to 6087bis (Watson) 1899 o Change systeminfo to a URL to be referenced (Lear) 1901 Draft -04 to -05: * syntax error correction 1903 Draft -03 to -04: * Re-add my-controller 1905 Draft -02 to -03: * Additional IANA updates * Format correction in 1906 YANG. * Add reference to TEAP. 1908 Draft -01 to -02: * Update IANA considerations * Accept Russ Housley 1909 rewrite of X.509 text * Include privacy considerations text * Redo 1910 the URL limit. Still 255 bytes, but now stated in the URL 1911 definition. * Change URI registration to be under urn:ietf:params 1913 Draft -00 to -01: * Fix cert trust text. * change supportInformation 1914 to meta-info * Add an informaitonal element in. * add urn registry 1915 and create first entry * add default elements 1917 Appendix B. Default MUD elements 1919 What follows is a MUD file that permits DNS traffic to a controller 1920 that is registered with the URN "urn:ietf:params:mud:dns" and traffic 1921 NTP to a controller that is registered "urn:ietf:params:mud:ntp". 1922 This is considered the default behavior and the ACEs are in effect 1923 appended to whatever other ACEs. To block DNS or NTP one repeats the 1924 matching statement but replace "permit" with deny. Because ACEs are 1925 processed in the order they are received, the defaults would not be 1926 reached. A MUD controller might further decide to optimize to simply 1927 not include the defaults when they are overriden. 1929 A complete MUD entry is included below. 1931 { 1932 "ietf-mud:metainfo": { 1933 "lastUpdate": "2017-08-06T19:12:24+02:00", 1934 "systeminfo": "https://www.ietf.org/mudcontrollerdefaults", 1935 "cacheValidity": 168 1936 }, 1937 "ietf-mud:device": { 1938 "from-device-policy": { 1939 "access-lists": { 1940 "access-list": [ 1941 { 1942 "acl-name": "mud-39988-v4out", 1943 "acl-type": "ietf-access-control-list:ipv4-acl" 1944 }, 1945 { 1946 "acl-name": "mud-39988-v6out", 1947 "acl-type": "ietf-access-control-list:ipv6-acl" 1948 } 1949 ] 1950 } 1951 }, 1952 "to-device-policy": { 1953 "access-lists": { 1954 "access-list": [ 1955 { 1956 "acl-name": "mud-39988-v4in", 1957 "acl-type": "ietf-access-control-list:ipv4-acl" 1958 }, 1959 { 1960 "acl-name": "mud-39988-v6in", 1961 "acl-type": "ietf-access-control-list:ipv6-acl" 1962 } 1963 ] 1964 } 1965 } 1966 }, 1967 "ietf-access-control-list:access-lists": { 1968 "acl": [ 1969 { 1970 "acl-name": "mud-39988-v4in", 1971 "acl-type": "ipv4-acl", 1972 "access-list-entries": { 1973 "ace": [ 1974 { 1975 "rule-name": "ent0-in", 1976 "matches": { 1977 "ietf-mud:mud-acl"{ 1978 "controller": "urn:ietf:params:mud:dns" 1979 }, 1980 "source-port-range": { 1981 "lower-port": 53, 1982 "upper-port": 53 1983 } 1984 }, 1985 "actions": { 1986 "permit": [ 1987 null 1988 ] 1990 } 1991 }, 1992 { 1993 "rule-name": "ent1-in", 1994 "matches": { 1995 "ietf-mud:mud-acl"{ 1996 "controller": "urn:ietf:params:mud:dns" 1997 }, 1998 "source-port-range": { 1999 "lower-port": 53, 2000 "upper-port": 53 2001 }, 2002 "tcp-acl": { 2003 "ietf-mud:direction-initiated": "from-device" 2004 } 2005 }, 2006 "actions": { 2007 "permit": [ 2008 null 2009 ] 2010 } 2011 }, 2012 { 2013 "rule-name": "ent2-in", 2014 "matches": { 2015 "ietf-mud:mud-acl"{ 2016 "controller": "urn:ietf:params:mud:ntp" 2017 }, 2018 "source-port-range": { 2019 "lower-port": 123, 2020 "upper-port": 123 2021 } 2022 }, 2023 "actions": { 2024 "permit": [ 2025 null 2026 ] 2027 } 2028 } 2029 ] 2030 } 2031 }, 2032 { 2033 "acl-name": "mud-39988-v4out", 2034 "acl-type": "ipv4-acl", 2035 "access-list-entries": { 2036 "ace": [ 2037 { 2038 "rule-name": "ent0-out", 2039 "matches": { 2040 "ietf-mud:mud-acl"{ 2041 "controller": "urn:ietf:params:mud:dns" 2042 }, 2043 "destination-port-range": { 2044 "lower-port": 53, 2045 "upper-port": 53 2046 } 2047 }, 2048 "actions": { 2049 "permit": [ 2050 null 2051 ] 2052 } 2053 }, 2054 { 2055 "rule-name": "ent1-out", 2056 "matches": { 2057 "ietf-mud:mud-acl"{ 2058 "controller": "urn:ietf:params:mud:dns" 2059 }, 2060 "destination-port-range": { 2061 "lower-port": 53, 2062 "upper-port": 53 2063 }, 2064 "tcp-acl": { 2065 "ietf-mud:direction-initiated": "from-device" 2066 } 2067 }, 2068 "actions": { 2069 "permit": [ 2070 null 2071 ] 2072 } 2073 }, 2074 { 2075 "rule-name": "ent2-out", 2076 "matches": { 2077 "ietf-mud:mud-acl"{ 2078 "controller": "urn:ietf:params:mud:ntp" 2079 }, 2080 "destination-port-range": { 2081 "lower-port": 123, 2082 "upper-port": 123 2083 } 2084 }, 2085 "actions": { 2086 "permit": [ 2087 null 2088 ] 2089 } 2090 } 2091 ] 2092 } 2093 }, 2094 { 2095 "acl-name": "mud-39988-v6in", 2096 "acl-type": "ipv6-acl", 2097 "access-list-entries": { 2098 "ace": [ 2099 { 2100 "rule-name": "ent0-in", 2101 "matches": { 2102 "ietf-mud:mud-acl"{ 2103 "controller": "urn:ietf:params:mud:dns" 2104 }, 2105 "source-port-range": { 2106 "lower-port": 53, 2107 "upper-port": 53 2108 } 2109 }, 2110 "actions": { 2111 "permit": [ 2112 null 2113 ] 2114 } 2115 }, 2116 { 2117 "rule-name": "ent1-in", 2118 "matches": { 2119 "ietf-mud:mud-acl"{ 2120 "controller": "urn:ietf:params:mud:dns" 2121 }, 2122 "source-port-range": { 2123 "lower-port": 53, 2124 "upper-port": 53 2125 }, 2126 "tcp-acl": { 2127 "ietf-mud:direction-initiated": "from-device" 2128 } 2129 }, 2130 "actions": { 2131 "permit": [ 2132 null 2133 ] 2135 } 2136 }, 2137 { 2138 "rule-name": "ent2-in", 2139 "matches": { 2140 "ietf-mud:mud-acl"{ 2141 "controller": "urn:ietf:params:mud:ntp" 2142 }, 2143 "source-port-range": { 2144 "lower-port": 123, 2145 "upper-port": 123 2146 } 2147 }, 2148 "actions": { 2149 "permit": [ 2150 null 2151 ] 2152 } 2153 } 2154 ] 2155 } 2156 }, 2157 { 2158 "acl-name": "mud-39988-v6out", 2159 "acl-type": "ipv6-acl", 2160 "access-list-entries": { 2161 "ace": [ 2162 { 2163 "rule-name": "ent0-out", 2164 "matches": { 2165 "ietf-mud:mud-acl"{ 2166 "controller": "urn:ietf:params:mud:dns" 2167 }, 2168 "destination-port-range": { 2169 "lower-port": 53, 2170 "upper-port": 53 2171 } 2172 }, 2173 "actions": { 2174 "permit": [ 2175 null 2176 ] 2177 } 2178 }, 2179 { 2180 "rule-name": "ent1-out", 2181 "matches": { 2182 "ietf-mud:mud-acl"{ 2183 "controller": "urn:ietf:params:mud:dns" 2184 }, 2185 "destination-port-range": { 2186 "lower-port": 53, 2187 "upper-port": 53 2188 }, 2189 "tcp-acl": { 2190 "ietf-mud:direction-initiated": "from-device" 2191 } 2192 }, 2193 "actions": { 2194 "permit": [ 2195 null 2196 ] 2197 } 2198 }, 2199 { 2200 "rule-name": "ent2-out", 2201 "matches": { 2202 "ietf-mud:mud-acl"{ 2203 "controller": "urn:ietf:params:mud:ntp" 2204 }, 2205 "destination-port-range": { 2206 "lower-port": 123, 2207 "upper-port": 123 2208 } 2209 }, 2210 "actions": { 2211 "permit": [ 2212 null 2213 ] 2214 } 2215 } 2216 ] 2217 } 2218 } 2219 ] 2220 } 2221 } 2223 Authors' Addresses 2224 Eliot Lear 2225 Cisco Systems 2226 Richtistrasse 7 2227 Wallisellen CH-8304 2228 Switzerland 2230 Phone: +41 44 878 9200 2231 Email: lear@cisco.com 2233 Ralph Droms 2235 Phone: +1 978 376 3731 2236 Email: rdroms@gmail.com 2238 Dan Romascanu 2240 Phone: +972 54 5555347 2241 Email: dromasca@gmail.com