idnits 2.17.1 draft-ietf-opsawg-mud-07.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 479 has weird spacing: '...cl-type ide...' == Line 484 has weird spacing: '...cl-type ide...' -- The document date (July 03, 2017) is 2460 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-06 == 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 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 2 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: January 4, 2018 6 D. Romascanu 7 July 03, 2017 9 Manufacturer Usage Description Specification 10 draft-ietf-opsawg-mud-07 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 January 4, 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 . . . . . . . . . . . . . 9 64 3. Element Definitions . . . . . . . . . . . . . . . . . . . . . 11 65 3.1. last-update . . . . . . . . . . . . . . . . . . . . . . . 11 66 3.2. cache-validity . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . 12 72 3.8. manufacturer . . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . . . 13 78 3.14. direction-initiated . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . 20 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 . . . . . . . . . . . . . . . . . . . . . . 22 87 9. The MUD URL DHCP Option . . . . . . . . . . . . . . . . . . . 24 88 9.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 25 89 9.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 25 90 9.3. Relay Requirements . . . . . . . . . . . . . . . . . . . 26 91 10. The Manufacturer Usage Description (MUD) URL X.509 Extension 26 92 11. The Manufacturer Usage Description LLDP extension . . . . . . 27 93 12. Creating and Processing of Signed MUD Files . . . . . . . . . 29 94 12.1. Creating a MUD file signature . . . . . . . . . . . . . 29 95 12.2. Verifying a MUD file signature . . . . . . . . . . . . . 29 96 13. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 30 97 14. Deployment Considerations . . . . . . . . . . . . . . . . . . 30 98 15. Security Considerations . . . . . . . . . . . . . . . . . . . 31 99 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 100 16.1. YANG Module Registrations . . . . . . . . . . . . . . . 32 101 16.2. DHCPv4 and DHCPv6 Options . . . . . . . . . . . . . . . 33 102 16.3. PKIX Extensions . . . . . . . . . . . . . . . . . . . . 33 103 16.4. Well Known URI Suffix . . . . . . . . . . . . . . . . . 33 104 16.5. MIME Media-type Registration for MUD files . . . . . . . 33 105 16.6. LLDP IANA TLV Subtype Registry . . . . . . . . . . . . . 34 106 16.7. The MUD Well Known Universal Resource Name (URNs) . . . 35 107 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 108 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 109 18.1. Normative References . . . . . . . . . . . . . . . . . . 35 110 18.2. Informative References . . . . . . . . . . . . . . . . . 38 111 Appendix A. Changes from Earlier Versions . . . . . . . . . . . 39 112 Appendix B. Default MUD elements . . . . . . . . . . . . . . . . 40 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 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 General computing systems will benefit very little from MUD, as their 174 manufacturers cannot envision a specific communication pattern to 175 describe. In addition, even those devices that have a single or 176 small number of uses might have very broad communication patterns. 177 MUD 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 may serves both to 221 classify the device type and to provide a means to locate a policy 222 file. 224 In this memo three means are defined to emit the MUD URL. One is a 225 DHCP option[RFC2131],[RFC3315] that the DHCP client uses to inform 226 the DHCP server. The DHCP server may take further actions, such as 227 retrieve the URL or otherwise pass it along to network management 228 system or controller. The other method defined is an X.509 229 constraint. The IEEE has developed [IEEE8021AR] that provides a 230 certificate-based approach to communicate device characteristics, 231 which itself relies on [RFC5280]. The MUD URL extension is non- 232 critical, as required by IEEE 802.1AR. Various means may be used to 233 communicate that certificate, including Tunnel Extensible 234 Authentication Protocol (TEAP) [RFC7170]. Finally, a Link Layer 235 Discovery Protocol (LLDP) frame is defined [IEEE8021AB]. 237 It is possible that there may be other means for a MUD URL to be 238 learned by a network. For instance, if a device has a serial number, 239 it may be possible for the MUD controller to perform a lookup of the 240 device, if it has some knowledge as to who the device manufacturer 241 is, and what its MUD file server is. Such mechanisms are not 242 described in this memo, but are possible. 244 1.5. Types of Policies 246 When the MUD URL is resolved, the MUD controller retrieves a file 247 that describes what sort of communications a device is designed to 248 have. The manufacturer may specify either specific hosts for cloud 249 based services or certain classes for access within an operational 250 network. An example of a class might be "devices of a specified 251 manufacturer type", where the manufacturer type itself is indicated 252 simply by the authority component (e.g, the domain name) of the MUD 253 URL. Another example might to allow or disallow local access. Just 254 like other policies, these may be combined. For example: 256 Allow access to devices of the same manufacturer 257 Allow access to and from controllers who need to speak COAP 258 Allow access to local DNS/DHCP 259 Deny all other access 261 To add a bit more depth that should not be a stretch of anyone's 262 imagination, one could also make use of port-based access lists. 263 Thus a printer might have a description that states: 265 Allow access for port IPP or port LPD 266 Allow local access for port HTTP 267 Deny all other access 269 In this way anyone can print to the printer, but local access would 270 be required for the management interface. 272 The files that are retrieved are intended to be closely aligned to 273 existing network architectures so that they are easy to deploy. We 274 make use of YANG [RFC6020] because of the time and effort spent to 275 develop accurate and adequate models for use by network devices. 276 JSON is used as a serialization for compactness and readability, 277 relative to XML. 279 While the policy examples given here focus on access control, this is 280 not intended to be the sole focus. By structuring the model 281 described in this document with clear extension points, and by 282 leveraging YANG-based models, we provide the opportunity for new 283 policies to be introduced as required. 285 The YANG modules specified here are extensions of 286 [I-D.ietf-netmod-acl-model]. The extensions to this model allow for 287 a manufacturer to express classes of systems that a manufacturer 288 would find necessary for the proper function of the device. Two 289 modules are specified. The first module specifies a means for domain 290 names to be used in ACLs so that devices that have their controllers 291 in the cloud may be appropriately authorized with domain names, where 292 the mapping of those names to addresses may rapidly change. 294 The other module abstracts away IP addresses into certain classes 295 that are instantiated into actual IP addresses through local 296 processing. Through these classes, manufacturers can specify how the 297 device is designed to communicate, so that network elements can be 298 configured by local systems that have local topological knowledge. 299 That is, the deployment populates the classes that the manufacturer 300 specifies. The abstractions are as follows: 302 Manufacturer: A device made by a particular manufacturer, as 303 identified by the authority component of its MUD-URL 305 same-manufacturer: Devices that have the same authority component of 306 their MUD-URL. 308 Controller: A device that the local network administrator admits to 309 the particular class. 311 my-controller: A class associated with the MUD-URL of a device that 312 the administrator admits. 314 The "manufacturer" classes can be easily specified by the 315 manufacturer, whereas controller classes are initially envisioned to 316 be specified by the administrator. 318 Because manufacturers do not know who will be using their devices, it 319 is important for functionality referenced in usage descriptions to be 320 relatively ubiquitous, and therefore, mature. Therefore, only a a 321 limited subset YANG-based configuration of is permitted in a MUD 322 file. 324 1.6. Terminology 326 MUD: manufacturer usage description. 328 MUD file: a file containing YANG-based JSON that describes a 329 recommended behavior. 331 MUD file server: a web server that hosts a MUD file. 333 MUD controller: the system that requests and receives the MUD file 334 from the MUD server. After it has processed a MUD file it may 335 direct changes to relevant network elements. 337 MUD URL: a URL that can be used by the MUD controller to receive the 338 MUD file. 340 Thing: the end device that emits a MUD URL. 342 Manufacturer: the entity that configures the Thing to emit the MUD 343 URL and the one who asserts a recommendation in a MUD file. The 344 manufacturer might not always be the entity that constructs a 345 device. It could, for instance, be a systems integrator, or even 346 a component provider. 348 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 349 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 350 document are to be interpreted as described in [RFC2119]. 352 1.7. The Manufacturer Usage Description Architecture 354 With these components laid out we now have the basis for an 355 archicture. This leads us to ASCII art. 357 ......................................... 358 . ____________ . _____________ 359 . | | . | | 360 . | MUD |----->get URL->| MUD | 361 . | Controller | .(https) | File Server | 362 . End system network |____________|<--MUD file<--<|_____________| 363 . . . 364 . . . 365 . _______ _________ . 366 .| | (dhcp et al) | router | . 367 .| Thing |---->MUD URL-->| or | . 368 .|_______| | switch | . 369 . |_________| . 370 ......................................... 372 Figure 1: MUD Architecture 374 In the above diagram, the switch or router collects MUD URLs and 375 forwards them to the network management system for processing. This 376 happens in different ways, depending on how the URI is communicated. 377 For instance, in the case of DHCP, the DHCP server might receive the 378 URI and then process it. In the case of IEEE 802.1X, the switch 379 would carry the URI via a certificate to the authentication server 380 via EAP over Radius[RFC3748], which would then process it. One 381 method to do this is TEAP, described in [RFC7170]. The certificate 382 extension is described below. 384 The information returned by the web site is valid for the duration of 385 the device's connection, or as specified in the description. Thus if 386 the device is mobile, when it moves on, any configuration in the 387 switch is removed. Similarly, from time to time the description may 388 be refreshed, based on new capabilities or communication patterns or 389 vulnerabilities. 391 The web site is typically run by or on behalf of the manufacturer. 392 Its domain name is that of the authority found in the MUD URL. For 393 legacy cases where Things cannot emit a URL, if the switch is able to 394 determine the appropriate URI, it may proxy it, the trivial cases 395 being a map between some registered device or port and a URL. 397 1.8. Order of operations 399 As mentioned above, MUD contains architectural building blocks, and 400 so order of operation may vary. However, here is one clear intended 401 example: 403 1. Device emits URL. 405 2. That URL is forwarded to a MUD controller by the nearest switch 406 (how this happens depends on the way in which the MUD URL is 407 emitted). 409 3. The MUD controller retrieves the MUD file from the MUD file 410 server, assuming it doesn't already have a copy. It may test the 411 URL against a reputation service, and it may test any hosts 412 within the file against reputation services, as it deems fit. 414 4. The MUD controller may query the administrator for permission to 415 add the device and associated policy. If the device is known or 416 the device type is known, it may skip this step. 418 5. The MUD controller instantiates local configuration based on the 419 abstractions defined in this document. 421 6. The MUD controller configures the switch nearest the device. 422 Other systems may be configured as well. 424 7. When the device disconnects, policy is removed. 426 2. The MUD Model and Semantic Meaning 428 A MUD file consists of JSON based on a YANG model. For purposes of 429 MUD, the elements that can be modified are access lists as augmented 430 by this model. The MUD file is limited to the serialization of a 431 small number of YANG schema, including the models specified in the 432 following documents: 434 o [I-D.ietf-netmod-acl-model] 436 o [RFC6991] 438 Publishers of MUD files MUST NOT include other elements except as 439 described in Section 3.6, and MUST only contain information relevant 440 to the device being described. Devices parsing MUD files MUST cease 441 processing if they find other elements. 443 ======= This module is structured into four parts: 445 o The first container, metainfo, holds information that is relevant 446 to retrieval and validity of the MUD file itself. 448 o The second container, device, describes the policies to be applied 449 to traffic to and from the device. The only policy currently 450 defined is a list of access control lists, but the from-device- 451 policy and to-device-policy containers serve as extension points 452 for subsequent augmentation. 454 o The third container augments the matching container of the ACL 455 model to add several elements that are relevant to the MUD URL, or 456 other otherwise abstracted for use within a local environment. 458 o The fourth container augments the tcp-acl container of the ACL 459 model to add the ability to match on the direction of initiation 460 of a TCP connection. 462 A simplified graphical representation of the data models is used in 463 this document. The meaning of the symbols in these diagrams is 464 defined in [I-D.ietf-netmod-rfc6087bis]. 466 module: ietf-mud 467 +--rw metainfo 468 | +--rw last-update? yang:date-and-time 469 | +--rw cache-validity? uint8 470 | +--rw masa-server? inet:uri 471 | +--rw is-supported? boolean 472 | +--rw systeminfo? inet:uri 473 | +--rw extensions* string 474 +--rw device 475 +--rw from-device-policy 476 | +--rw access-lists 477 | +--rw access-list* [acl-name acl-type] 478 | +--rw acl-name -> /acl:access-lists/acl/acl-name 479 | +--rw acl-type identityref 480 +--rw to-device-policy 481 +--rw access-lists 482 +--rw access-list* [acl-name acl-type] 483 +--rw acl-name -> /acl:access-lists/acl/acl-name 484 +--rw acl-type identityref 485 augment /acl:access-lists/acl:acl/acl:access-list-entries \ 486 /acl:ace/acl:matches: 487 +--rw mud-acl {mud-acl}? 488 +--rw manufacturer? inet:host 489 +--rw same-manufacturer? empty 490 +--rw model? string 491 +--rw local-networks? empty 492 +--rw controller? inet:uri 493 +--rw my-controller? empty 494 augment /acl:access-lists/acl:acl/acl:access-list-entries \ 495 /acl:ace/acl:matches/acl:tcp-acl: 496 +--rw direction-initiated? direction 498 3. Element Definitions 500 The following elements are defined. 502 3.1. last-update 504 This is a date-and-time value of when the MUD file was generated. 505 This is akin to a version number. Its form is taken from [RFC6991] 506 which, for those keeping score, turn was taken from Section 5.6 of 507 [RFC3339], which was taken from [ISO.8601.1988]. 509 3.2. cache-validity 511 This uint8 is the period of time in hours that a network management 512 station MUST wait since its last retrieval before checking for an 513 update. It is RECOMMENDED that this value be no less than 24 and 514 MUST NOT be more than 168 for any device that is supported. 516 3.3. masa-server 518 This optional element refers to the URL that should be used to 519 resolve the location any MASA service, as specified in 520 [I-D.ietf-anima-bootstrapping-keyinfra]. 522 3.4. is-supported 524 This boolean is an indication from the manufacturer to the network 525 administrator as to whether or not the device is supported. In this 526 context a device is said to be supported if the manufacturer might 527 issue an update to the device or if the manufacturer might update the 528 MUD file. 530 3.5. systeminfo 532 This is a URL that points to a description of the device to be 533 connected. The intent is for administrators to be able to read about 534 what the device is the first time the MUD-URL is used. 536 3.6. extensions 538 This optional leaf-list names MUD extensions that are used in the MUD 539 file. Note that NO MUD extensions may be used in a MUD file prior to 540 the extensions being declared. Implementations MUST ignore any 541 elements in this file that they do not understand. 543 3.7. packet-direction 545 [I-D.ietf-netmod-acl-model] describes access-lists but does not 546 attempt to indicate where they are applied as that is handled 547 elsewhere in a configuration. However, in this case, a MUD file must 548 be explicit in describing the communication pattern of a device, and 549 that includes indicating what is to be permitted or denied in either 550 direction of communication. This element takes a single value of 551 either "to-device" or "from-device", based on a typedef "direction". 552 This is applied specifically for TCP, and may be implemented either 553 via stateful or stateless approaches (e.g,. TCP flags) 555 3.8. manufacturer 557 This element consists of a hostname that would be matched against the 558 authority component of another device's MUD URL. 560 3.9. same-manufacturer 562 This is an equivalent for when the manufacturer element is used to 563 indicate the authority that is found in another device's MUD URL 564 matches that of the authority found in this device's MUD URL. 566 3.10. model 568 This string matches the one and only segment following the authority 569 component of the MUD URL. It refers to a model that is unique within 570 the context of the authority. It may also include product version 571 information. Thus how this field is constructed is entirely a local 572 matter for the manufacturer. 574 3.11. local-networks 576 This null-valued element expands to include local networks. Its 577 default expansion is that packets must not traverse toward a default 578 route that is received from the router. However, administrators may 579 expand the expression as is appropriate in their deployments. 581 3.12. controller 583 This URI specifies a value that a controller will register with the 584 mud controller. The element then is expanded to the set of hosts 585 that are so registered. This element may also be a URN. In this 586 case, the URN describes a well known service, such as DNS or NTP. 588 Great care should be used when invoking the controller class. For 589 one thing, it requires some understanding by the administrator as to 590 when it is appropriate. Classes that are standardized may make it 591 possible to code in certain intelligence. Nonstandard classes may 592 require substantially more care. Pre-registration in such classes by 593 controllers with the MUD server is encouraged. The mechanism to do 594 that is beyond the scope of this work. 596 3.13. my-controller 598 This null-valued element establishes a class of controllers that are 599 intended to control the device associated with a given MUD-URL. 601 3.14. direction-initiated 603 When applied this matches packets when the flow was initiated in the 604 corresponding direction. [RFC6092] specifies IPv6 guidance best 605 practices. While that document is scoped specifically to IPv6, its 606 contents are applicable for IPv4 as well. When this flag is set, and 607 the system has no reason to believe a flow has been initiated it MUST 608 drop the packet. This match SHOULD be applied with specific 609 transport parameters, such as protocol. 611 4. Processing of the MUD file 613 To keep things relatively simple in addition to whatever definitions 614 exist, we also apply two additional default behaviors: 616 o Anything not explicitly permitted is denied. 618 o Local DNS and NTP are, by default, permitted to and from the 619 device. 621 An explicit description of the defaults can be found in Appendix B. 623 5. What does a MUD URL look like? 625 To begin with, MUD takes full advantage of both the https: scheme and 626 the use of .well-known. HTTPS is important in this case because a 627 man in the middle attack could otherwise harm the operation of a 628 class of devices. .well-known is used because we wish to add 629 additional structure to the URL. And so the URL appears as follows: 631 mud-url = "https://" authority "/.well-known/mud/" mud-rev 632 "/" model ( "?" extras ) 633 ; authority is from RFC3986 634 mud-rev = "v1" 635 model = segment ; from RFC3986 636 extras = query ; from RFC3986 638 mud-rev signifies the version of the manufacturer usage description 639 file. This memo specifies "v1" of that file. Later versions may 640 permit additional schemas or modify the format. In order to provide 641 for the broadest compatibility for the various transmission 642 mechanisms, the length of the URL for v1 MUST NOT exceed 255 octets. 644 "model" represents a device model as the manufacturer wishes to 645 represent it. It could be a brand name or something more specific. 646 It also may provide a means to indicate what version the product is. 647 Specifically if it has been updated in the field, this is the place 648 where evidence of that update would appear. The field should be 649 changed when the intended communication patterns of a device change. 650 While from a controller standpoint, only comparison and matching 651 operations are safe, it is envisioned that updates will require some 652 administrative review. Processing of this URL occurs as specified in 653 [RFC2818] and [RFC3986]. 655 6. The MUD YANG Model 657 file "ietf-mud@2017-07-03.yang" 658 module ietf-mud { 659 yang-version 1.1; 660 namespace "urn:ietf:params:xml:ns:yang:ietf-mud"; 661 prefix "ietf-mud"; 663 import ietf-access-control-list { 664 prefix "acl"; 665 } 667 import ietf-yang-types { 668 prefix "yang"; 669 } 671 import ietf-inet-types { 672 prefix "inet"; 673 } 675 organization 676 "IETF OPSAWG (Ops Area) Working Group"; 678 contact 679 "WG Web: http://tools.ietf.org/wg/opsawg/ 680 WG List: opsawg@ietf.org 681 Author: Eliot Lear 682 lear@cisco.com 683 Author: Ralph Droms 684 rdroms@gmail.com 685 Author: Dan Romascanu 686 dromasca@gmail.com 688 "; 690 description 691 "This YANG module defines a component that augments the 692 IETF description of an access list. This specific module 693 focuses on additional filters that include local, model, 694 and same-manufacturer. 696 Copyright (c) 2016,2017 IETF Trust and the persons 697 identified as the document authors. All rights reserved. 698 Redistribution and use in source and binary forms, with or 699 without modification, is permitted pursuant to, and subject 700 to the license terms contained in, the Simplified BSD 701 License set forth in Section 4.c of the IETF Trust's Legal 702 Provisions Relating to IETF Documents 703 (http://trustee.ietf.org/license-info). 704 This version of this YANG module is part of RFC XXXX; see 705 the RFC itself for full legal notices."; 707 revision "2017-07-03" { 708 description 709 "More work on ACL usage."; 710 reference "RFC XXXX: Manufacturer Usage Description 711 Specification"; 712 } 714 revision "2017-06-29" { 715 description 716 "Take packet directionality out of ACL. " + 717 "Introduce device container."; 718 reference "RFC XXXX: Manufacturer Usage Description 719 Specification"; 720 } 722 revision "2017-04-18" { 723 description "Base version of MUD extensions to ACL model"; 724 reference "RFC XXXX: Manufacturer Usage Description 725 Specification"; 726 } 728 typedef direction { 729 type enumeration { 730 enum to-device { 731 description "packets or flows destined to the target 732 device"; 733 } 734 enum from-device { 735 description "packets or flows destined from 736 the target device"; 737 } 738 } 739 description "Which way are we talking about?"; 740 } 742 identity mud-acl { 743 base "acl:acl-base"; 744 description 745 "ACL that contains MUD-specific access control list entries."; 746 } 748 feature mud-acl { 749 description 750 "MUD ACL augmentations supported."; 752 } 754 container metainfo { 756 description "Information about when support end(ed), and 757 when to refresh"; 759 leaf last-update { 760 type yang:date-and-time; 761 description "This is intended to be when 762 the MUD file was generated."; 763 } 765 leaf cache-validity { 766 type uint8 { 767 range "1..168"; 768 } 769 description "The information retrieved from the MUD server is 770 valid for these many hours, after which it should 771 be refreshed."; 772 } 774 leaf masa-server { 775 type inet:uri; 776 description "The URI of the MASA server that network 777 elements should forward requests to for this device."; 778 } 780 leaf is-supported { 781 type boolean; 782 description "The element is currently supported 783 by the manufacturer."; 784 } 785 leaf systeminfo { 786 type inet:uri; 787 description "A reference to a description of this device"; 788 } 790 leaf-list extensions { 791 type string; 792 description "A list of extension names that are used in this MUD 793 file. Each name is registered with the IANA and 794 described in an RFC."; 795 } 796 } 798 grouping ACCESS_LISTS { 799 description "A grouping for access lists in the context of device 800 policy."; 801 container access-lists { 802 description "The access lists that should be applied to traffic 803 to or from the device."; 804 list access-list { 805 key "acl-name acl-type"; 806 description "Each entry on this list refers to an ACL that 807 should be present in the overall access list 808 data model. Each ACL is identified by name and 809 type."; 810 leaf acl-name { 811 type leafref { 812 path "/acl:access-lists/acl:acl/acl:acl-name"; 813 } 814 description "The name of the ACL for this entry."; 815 } 816 leaf acl-type { 817 type identityref { 818 base acl:acl-base; 819 } 820 description "The type of the ACL for this entry."; 821 } 822 } 823 } 824 } 826 container device { 827 description "A container allowing us to associate data with the 828 device type being described in the instance document"; 830 container from-device-policy { 831 description "The policies that should be enforced on traffic 832 coming from the device. These policies are not 833 necessarily intended to be enforced at a single 834 point, but may be rendered by the controller to any 835 relevant enorcement points in the network or 836 elsewhere."; 837 uses ACCESS_LISTS; 838 } 840 container to-device-policy { 841 description "The policies that should be enforced on traffic 842 going to the device. These policies are not 843 necessarily intended to be enforced at a single 844 point, but may be rendered by the controller to any 845 relevant enorcement points in the network or 846 elsewhere."; 847 uses ACCESS_LISTS; 849 } 851 } 853 augment "/acl:access-lists/acl:acl/" + 854 "acl:access-list-entries/acl:ace/" + 855 "acl:matches" { 856 description "adding abstractions to avoid need of IP addresses"; 858 container mud-acl { 859 if-feature mud-acl; 860 must "../../../../acl-type = 'ietf-mud:mud-acl'"; 862 description 863 "TODO; improve. MUD-specific matches."; 865 leaf manufacturer { 866 type inet:host; 867 description "authority component of the manufacturer URI"; 868 } 870 leaf same-manufacturer { 871 type empty; 872 description "expand to ACEs for each device 873 with the same origin"; 874 } 876 leaf model { 877 type string; 878 description "specific model (including version) for a 879 given manufacturer"; 880 } 882 leaf local-networks { 883 type empty; 884 description "this string is used to indicate networks 885 considered local in a given environment."; 886 } 888 leaf controller { 889 type inet:uri; 890 description "expands to one or more controllers for a 891 given service that is codified by inet:uri."; 892 } 894 leaf my-controller { 895 type empty; 896 description "This element indicates that the network should manage 897 a class of devices related to this MUD-URL that are 898 intended to control this device."; 899 } 900 } 902 } 904 augment "/acl:access-lists/acl:acl/" + 905 "acl:access-list-entries/acl:ace/" + 906 "acl:matches/acl:tcp-acl" { 907 description "Adding domain names to matching"; 908 leaf direction-initiated { 909 type direction; 910 description "which direction a flow was initiated"; 911 } 912 } 913 } 914 916 7. The Domain Name Extension to the ACL Model 918 This module specifies an extension to IETF-ACL model such that domain 919 names may be referenced by augmenting the "matches" element. 920 Different implementations may deploy differing methods to maintain 921 the mapping between IP address and domain name, if indeed any are 922 needed. However, the intent is that resources that are referred to 923 using a name should be authorized (or not) within an access list. 925 The structure of the change is as follows: 927 module: ietf-acldns 928 augment /acl:access-lists/acl:acl/acl:access-list-entries \ 929 /acl:ace/acl:matches/acl:ipv4-acl: 930 +--rw src-dnsname? inet:host 931 +--rw dst-dnsname? inet:host 932 augment /acl:access-lists/acl:acl/acl:access-list-entries \ 933 /acl:ace/acl:matches/acl:ipv6-acl: 934 +--rw src-dnsname? inet:host 935 +--rw dst-dnsname? inet:host 937 The choice of these particular points in the access-list model is 938 based on the assumption that we are in some way referring to IP- 939 related resources, as that is what the DNS returns. A domain name in 940 our context is defined in [RFC6991]. The augmentations are 941 replicated across IPv4 and IPv6 to allow MUD file autjors the ability 942 to control the IP version that the device may utilize. 944 The following elements are defined. 946 7.1. source-dnsname 948 The argument corresponds to a domain name of a source as specified by 949 inet:host. Depending on how the model is used, it may or may not be 950 resolved, as required by the implementation and circumstances. 952 7.2. destination-dnsname 954 The argument corresponds to a domain name of a destination as 955 specified by inet:host. Depending on how the model is used, it may 956 or may not be resolved, as required by the implementation and 957 circumstances. 959 7.3. The ietf-acldns Model 961 file "ietf-acldns@2016-07-20.yang" 962 module ietf-acldns { 963 yang-version 1.1; 964 namespace "urn:ietf:params:xml:ns:yang:ietf-acldns"; 965 prefix "ietf-acldns"; 967 import ietf-access-control-list { 968 prefix "acl"; 969 } 971 import ietf-inet-types { 972 prefix "inet"; 973 } 975 organization 976 "IETF OPSAWG (Ops Area) Working Group"; 978 contact 979 "WG Web: http://tools.ietf.org/wg/opsawg/ 980 WG List: opsawg@ietf.org 981 Author: Eliot Lear 982 lear@cisco.com 983 Author: Ralph Droms 984 rdroms@gmail.com 985 Author: Dan Romascanu 986 dromasca@gmail.com 987 "; 989 description 990 "This YANG module defines a component that augments the 991 IETF description of an access list to allow dns names 992 as matching criteria."; 994 revision "2017-07-03" { 995 description "Clone across IP ACL types."; 996 reference "RFC XXXX: Manufacturer Usage Description 997 Specification"; 998 } 1000 revision "2016-07-20" { 1001 description "Base version of dnsname extension of ACL model"; 1002 reference "RFC XXXX: Manufacturer Usage Description 1003 Specification"; 1004 } 1006 grouping DNS_MATCHES { 1007 description "Domain names for matching."; 1009 leaf src-dnsname { 1010 type inet:host; 1011 description "domain name to be matched against"; 1012 } 1013 leaf dst-dnsname { 1014 type inet:host; 1015 description "domain name to be matched against"; 1016 } 1017 } 1019 augment "/acl:access-lists/acl:acl/" + 1020 "acl:access-list-entries/acl:ace/" + 1021 "acl:matches/acl:ipv4-acl" { 1022 description "Adding domain names to matching"; 1023 uses DNS_MATCHES; 1024 } 1026 augment "/acl:access-lists/acl:acl/" + 1027 "acl:access-list-entries/acl:ace/" + 1028 "acl:matches/acl:ipv6-acl" { 1029 description "Adding domain names to matching"; 1030 uses DNS_MATCHES; 1031 } 1032 } 1033 1035 8. MUD File Example 1037 This example contains two access lists that are intended to provide 1038 outbound access to a cloud service on TCP port 443. 1040 TODO: this needs to be revised. 1042 { 1043 "ietf-mud:metainfo": { 1044 "last-update": "2016-05-18T20:00:50Z", 1045 "cache-validity": 168 1046 }, 1047 "ietf-access-control-list:access-lists": { 1048 "acl": [ { 1049 "acl-name": "inbound-stuff", 1050 "acl-type" : "ipv4-acl", 1051 "ietf-mud:packet-direction" : "to-device", 1052 "access-list-entries": { 1053 "ace": [ 1054 { 1055 "rule-name": "access-cloud", 1056 "matches": { 1057 "ietf-acldns:src-dnsname": 1058 "lighting-system.example.com", 1059 "protocol" : 6, 1060 "source-port-range" : { 1061 "lower-port" : 443, 1062 "upper-port" : 443 1063 } 1064 }, 1065 "actions" : { 1066 "permit" : [null] 1067 } 1068 } 1069 ] 1070 } 1071 }, 1072 { 1073 "acl-name": "outbound-stuff", 1074 "acl-type" : "ipv4-acl", 1075 "ietf-mud:packet-direction" : "from-device", 1076 "access-list-entries": { 1077 "ace": [ 1078 { 1079 "rule-name": "access-cloud", 1080 "matches": { 1081 "ietf-acldns:dst-dnsname": 1082 "lighting-system.example.com", 1083 "protocol" : 6, 1084 "destination-port-range" : { 1085 "lower-port" : 443, 1086 "upper-port" : 443 1087 } 1088 }, 1089 "actions" : { 1090 "permit" : [null] 1091 } 1092 } 1093 ] 1094 } 1095 } 1096 ] 1097 } 1098 } 1100 9. The MUD URL DHCP Option 1102 The IPv4 MUD URL client option has the following format: 1104 +------+-----+------------------------------ 1105 | code | len | MUD URL 1106 +------+-----+------------------------------ 1108 Code OPTION_MUD_URL_V4 (161) is assigned by IANA. len is a single 1109 octet that indicates the length of the URL in octets. MUD URL is a 1110 URL. MUD URLs MUST NOT exceed 255 octets. 1112 The IPv6 MUD URL client option has the following format: 1114 0 1 2 3 1115 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 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 | OPTION_MUD_URL_V6 | option-length | 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | MUD URL | 1120 | ... | 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 OPTION_MUD_URL_V6 (112; assigned by IANA). 1125 option-length contains the length of the URL in octets. 1127 The intent of this option is to provide both a new device classifier 1128 to the network as well as some recommended configuration to the 1129 routers that implement policy. However, it is entirely the purview 1130 of the network system as managed by the network administrator to 1131 decide what to do with this information. The key function of this 1132 option is simply to identify the type of device to the network in a 1133 structured way such that the policy can be easily found with existing 1134 toolsets. 1136 9.1. Client Behavior 1138 A DHCPv4 client MAY emit a DHCPv4 option and a DHCPv6 client MAY emit 1139 DHCPv6 option. These options are singletons, as specified in 1140 [RFC7227]. Because clients are intended to have at most one MUD URL 1141 associated with them, they may emit at most one MUD URL option via 1142 DHCPv4 and one MUD URL option via DHCPv6. In the case where both v4 1143 and v6 DHCP options are emitted, the same URL MUST be used. 1145 Clients SHOULD log or otherwise report improper acknowledgments from 1146 servers, but they MUST NOT modify their MUD URL configuration based 1147 on a server's response. The server's response is only an 1148 acknowledgment that the server has processed the option, and promises 1149 no specific network behavior to the client. In particular, it may 1150 not be possible for the server to retrieve the file associated with 1151 the MUD URL, or the local network administration may not wish to use 1152 the usage description. Neither of these situations should be 1153 considered in any way exceptional. 1155 9.2. Server Behavior 1157 A DHCP server may ignore these options or take action based on 1158 receipt of these options. If a server successfully parses the option 1159 and the URL, it MUST return the option with length field set to zero 1160 and a corresponding null URL field as an acknowledgment. Even in 1161 this circumstance, no specific network behavior is guaranteed. When 1162 a server consumes this option, it will either forward the URL and 1163 relevant client information to a network management system (such as 1164 the giaddr), or it will retrieve the usage description by resolving 1165 the URL. 1167 DHCP servers may implement MUD functionality themselves or they may 1168 pass along appropriate information to a network management system or 1169 MUD controller. A DHCP server that does process the MUD URL MUST 1170 adhere to the process specified in [RFC2818] and [RFC5280] to 1171 validate the TLS certificate of the web server hosting the MUD file. 1172 Those servers will retrieve the file, process it, create and install 1173 the necessary configuration on the relevant network element. Servers 1174 SHOULD monitor the gateway for state changes on a given interface. A 1175 DHCP server that does not provide MUD functionality and has forwarded 1176 a MUD URL to a MUD controller MUST notify the MUD controller of any 1177 corresponding change to the DHCP state of the client (such as 1178 expiration or explicit release of a network address lease). 1180 9.3. Relay Requirements 1182 There are no additional requirements for relays. 1184 10. The Manufacturer Usage Description (MUD) URL X.509 Extension 1186 This section defines an X.509 non-critical certificate extension that 1187 contains a single Uniform Resource Identifier (URI) that points to an 1188 on-line Manufacturer Usage Description concerning the certificate 1189 subject. URI must be represented as described in Section 7.4 of 1190 [RFC5280]. 1192 Any Internationalized Resource Identifiers (IRIs) MUST be mapped to 1193 URIs as specified in Section 3.1 of [RFC3987] before they are placed 1194 in the certificate extension. 1196 The semantics of the URI are defined Section 5 of this document. 1198 The choice of id-pe is based on guidance found in Section 4.2.2 of 1199 [RFC5280]: 1201 These extensions may be used to direct applications to on-line 1202 information about the issuer or the subject. 1204 The MUD URL is precisely that: online information about the 1205 particular subject. 1207 The new extension is identified as follows: 1209 1211 MUDURLExtnModule-2016 { iso(1) identified-organization(3) dod(6) 1212 internet(1) security(5) mechanisms(5) pkix(7) 1213 id-mod(0) id-mod-mudURLExtn2016(88) } 1215 DEFINITIONS IMPLICIT TAGS ::= BEGIN 1217 -- EXPORTS ALL -- 1219 IMPORTS 1220 EXTENSION 1221 FROM PKIX-CommonTypes-2009 1222 { iso(1) identified-organization(3) dod(6) internet(1) 1223 security(5) mechanisms(5) pkix(7) id-mod(0) 1224 id-mod-pkixCommon-02(57) } 1226 id-pe 1227 FROM PKIX1Explicit-2009 1228 { iso(1) identified-organization(3) dod(6) internet(1) 1229 security(5) mechanisms(5) pkix(7) id-mod(0) 1230 id-mod-pkix1-explicit-02(51) } ; 1231 MUDCertExtensions EXTENSION ::= { ext-MUDURL, ... } 1232 ext-MUDURL EXTENSION ::= { SYNTAX MUDURLSyntax 1233 IDENTIFIED BY id-pe-mud-url } 1235 id-pe-mud-url OBJECT IDENTIFIER ::= { id-pe 25 } 1237 MUDURLSyntax ::= IA5String 1239 END 1241 1243 While this extension can appear in either an 802.AR manufacturer 1244 certificate (IDevID) or deployment certificate (LDevID), of course it 1245 is not guaranteed in either, nor is it guaranteed to be carried over. 1246 It is RECOMMENDED that MUD controller implementations maintain a 1247 table that maps a device to its MUD-URL. 1249 11. The Manufacturer Usage Description LLDP extension 1251 The IEEE802.1AB Link Layer Discovery Protocol (LLDP) is a one hop 1252 vendor-neutral link layer protocols used by end hosts network devices 1253 for advertising their identity, capabilities, and neighbors on an 1254 IEEE 802 local area network. Its Type-Length-Value (TLV) design 1255 allows for 'vendor-specific' extensions to be defined. IANA has a 1256 registered IEEE 802 organizationally unique identifier (OUI) defined 1257 as documented in [RFC7042]. The MUD LLDP extension uses a subtype 1258 defined in this document to carry the MUD URL. 1260 The LLDP vendor specific frame has the following format: 1262 +--------+--------+----------+---------+-------------- 1263 |TLV Type| len | OUI |subtype | MUD URL 1264 | =127 | |= 00 00 5E| = 1 | 1265 |(7 bits)|(9 bits)|(3 octets)|(1 octet)|(1-255 octets) 1266 +--------+--------+----------+---------+-------------- 1268 where: 1270 o TLV Type = 127 indicates a vendor-specific TLV 1272 o len - indicates the TLV string length 1274 o OUI = 00 00 5E is the organizationally unique identifier of IANA 1276 o subtype = 1 (to be assigned by IANA for the MUD URL) 1278 o MUD URL - the length MUST NOT exceed 255 octets 1280 The intent of this extension is to provide both a new device 1281 classifier to the network as well as some recommended configuration 1282 to the routers that implement policy. However, it is entirely the 1283 purview of the network system as managed by the network administrator 1284 to decide what to do with this information. The key function of this 1285 extension is simply to identify the type of device to the network in 1286 a structured way such that the policy can be easily found with 1287 existing toolsets. 1289 Hosts, routers, or other network devices that implement this option 1290 are intended to have at most one MUD URL associated with them, so 1291 they may transmit at most one MUD URL value. 1293 Hosts, routers, or other network devices that implement this option 1294 may ignore these options or take action based on receipt of these 1295 options. For example they may fill in information in the respective 1296 extensions of the LLDP Management Information Base (LLDP MIB). LLDP 1297 operates in a one-way direction. LLDPDUs are not exchanged as 1298 information requests by one device and response sent by another 1299 device. The other devices do not acknowledge LLDP information 1300 received from a device. No specific network behavior is guaranteed. 1301 When a device consumes this extension, it may either forward the URL 1302 and relevant remote device information to a MUD controller, or it 1303 will retrieve the usage description by resolving the URL. 1305 12. Creating and Processing of Signed MUD Files 1307 Because MUD files contain information that may be used to configure 1308 network access lists, they are sensitive. To insure that they have 1309 not been tampered with, it is important that they be signed. We make 1310 use of DER-encoded Cryptographic Message Syntax (CMS) [RFC5652] for 1311 this purpose. 1313 12.1. Creating a MUD file signature 1315 A MUD file MUST be signed using CMS as an opaque binary object. In 1316 order to make successful verification more likely, intermediate 1317 certificates SHOULD be included. The signature is stored at the same 1318 location as the MUD URL but with the suffix of ".p7s". Signatures 1319 are transferred using content-type "Application/pkcs7-signature". 1321 For example: 1323 % openssl cms -sign -signer mancertfile -inkey mankey \ 1324 -in mudfile -binary -outform DER - \ 1325 -certfile intermediatecert -out mudfile.p7s 1327 Note: A MUD file may need to be re-signed if the signature expires. 1329 12.2. Verifying a MUD file signature 1331 Prior to retrieving a MUD file the MUD controller SHOULD retrieve the 1332 MUD signature file using the MUD URL with a suffix of ".p7s". For 1333 example, if the MUD URL is "https://example.com/.well-known/v1/ 1334 modela", the MUD signature URL will be "https://example.com/.well- 1335 known/v1/modela.p7s". 1337 Upon retrieving a MUD file, a MUD controller MUST validate the 1338 signature of the file before continuing with further processing. A 1339 MUD controller SHOULD produce an error and it MUST cease all 1340 processing of that file if the signature cannot be validated. It is 1341 important that MUD controllers have some reason to trust the 1342 certificates they are seeing. Therefore, it is RECOMMENDED that new 1343 signers be validated either directly by an administrator or by a 1344 service that has some reason to believe that the signer is a good 1345 actor. 1347 For Example: 1349 % openssl cms -verify -in mudfile.p7s -inform DER -content mudfile 1351 Note the additional step of verifying the common trust root. 1353 13. Extensibility 1355 One of our design goals is to see that MUD files are able to be 1356 understood by as broad a cross-section of systems as is possible. 1357 Coupled with the fact that we have also chosen to leverage existing 1358 mechanisms, we are left with no ability to negotiate extensions and a 1359 limited desire for those extensions in any event. A such, a two-tier 1360 extensibility framework is employed, as follows: 1362 1. At a coarse grain, a protocol version is included in a MUD URL. 1363 This memo specifies MUD version 1. Any and all changes are 1364 entertained when this version is bumped. Transition approaches 1365 between versions would be a matter for discussion in future 1366 versions. 1368 2. At a finer grain, only extensions that would not incur additional 1369 risk to the device are permitted. Specifically, augmenting of 1370 the metainfo container is permitted with the understanding that 1371 such additions may be ignored. In addition, augmentation of the 1372 ACL model is permitted so long as it remains safe for a given ACE 1373 to be ignored by the MUD Controller or the network elements it 1374 configures. Most specifically, is is not permitted to include as 1375 an augmentation that modifies "deny" behavior without bumping the 1376 version. Furthermore, implementations that are not able to parse 1377 a component of the ACE array MUST ignore the entire array entry 1378 (e.g., not the entire array) and MAY ignore the entire MUD file. 1380 14. Deployment Considerations 1382 Because MUD consists of a number of architectural building blocks, it 1383 is possible to assemble different deployment scenarios. One key 1384 aspect is where to place policy enforcement. In order to protect the 1385 device from other devices within a local deployment, policy can be 1386 enforced on the nearest switch or access point. In order to limit 1387 unwanted traffic within a network, it may also be advisable to 1388 enforce policy as close to the Internet as possible. In some 1389 circumstances, policy enforcement may not be available at the closest 1390 hop. At that point, the risk of so-called east-west infection is 1391 increased to the number of devices that are able to communicate 1392 without protection. 1394 A caution about some of the classes: admission of a device into the 1395 "manufacturer" and "same-manufacturer" class may have impact on 1396 access of other devices. Put another way, the admission may grow the 1397 access-list on switches connected to other devices, depending on how 1398 access is managed. Therefore, care should be given on managing that 1399 access-list growth. Alternative methods such as additional 1400 segmentation can be used to keep that growth within reason. 1402 15. Security Considerations 1404 Based on how a MUD-URL is emitted, a device may be able to lie about 1405 what it is, thus gaining additional network access. There are 1406 several means to limit risk in this case. The most obvious is to 1407 only believe devices that make use of certificate-based 1408 authentication such as IEEE 802.1AR certificates. When those 1409 certificates are not present, devices claiming to be of a certain 1410 manufacturer SHOULD NOT be included in that manufacturer grouping 1411 without additional validation of some form. This will occur when it 1412 makes use of primitives such as "manufacturer" for the purpose of 1413 accessing devices of a particular type. Similarly, network 1414 management systems may be able to fingerprint the device. In such 1415 cases, the MUD-URL can act as a classifier that can be proven or 1416 disproven. Fingerprinting may have other advantages as well: when 1417 802.1AR certificates are used, because they themselves cannot change, 1418 fingerprinting offers the opportunity to add artificats to the MUD- 1419 URL. The meaning of such artifacts is left as future work. 1421 Network management systems SHOULD NOT accept a usage description for 1422 a device with the same MAC address that has indicated a change of 1423 authority without some additional validation (such as review of the 1424 class). New devices that present some form of unauthenticated MUD 1425 URL SHOULD be validated by some external means when they would be 1426 otherwise be given increased network access. 1428 It may be possible for a rogue manufacturer to inappropriately 1429 exercise the MUD file parser, in order to exploit a vulnerability. 1430 There are three recommended approaches to address this threat. The 1431 first is to validate the signature of the MUD file. The second is to 1432 have a system do a primary scan of the file to ensure that it is both 1433 parseable and believable at some level. MUD files will likely be 1434 relatively small, to start with. The number of ACEs used by any 1435 given device should be relatively small as well. It may also be 1436 useful to limit retrieval of MUD URLs to only those sites that are 1437 known to have decent web reputations. 1439 Use of a URL necessitates the use of domain names. If a domain name 1440 changes ownership, the new owner of that domain may be able to 1441 provide MUD files that MUD controllers would consider valid. There 1442 are a few approaches that can mitigate this attack. First, MUD 1443 controllers SHOULD cache certificates used by the MUD file server. 1444 When a new certificate is retrieved for whatever reason, the MUD 1445 controller should check to see if ownership of the domain has 1446 changed. A fair programmatic approximation of this is when the name 1447 servers for the domain have changed. If the actual MUD file has 1448 changed, the controller MAY check the WHOIS database to see if 1449 registration ownership of a domain has changed. If a change has 1450 occured, or if for some reason it is not possible to determine 1451 whether ownership has changed, further review may be warranted. 1452 Note, this remediation does not take into account the case of a 1453 device that was produced long ago and only recently fielded, or the 1454 case where a new MUD controller has been installed. 1456 The release of a MUD URL by a device reveals what the device is, and 1457 provides an attacker with guidance on what vulnerabilities may be 1458 present. 1460 While the MUD URL itself is not intended to be unique to a specific 1461 device, the release of the URL may aid an observer in identifying 1462 individuals when combined with other information. This is a privacy 1463 consideration. 1465 In addressing both of these concerns, implementors should take into 1466 account what other information they are advertising through 1467 mechanisms such as mDNS[RFC6872], how a device might otherwise be 1468 identified, perhaps through how it behaves when it is connected to 1469 the network, whether a device is intended to be used by individuals 1470 or carry personal identifying information, and then apply appropriate 1471 data minimization techniques. One approach is to make use of TEAP 1472 [RFC7170] as the means to share information with authorized 1473 components in the network. Network devices may also assist in 1474 limiting access to the MUD-URL through the use of mechanisms such as 1475 DHCPv6-Shield [RFC7610]. 1477 Please note that the security considerations mentioned in Section 4.7 1478 of [I-D.ietf-netmod-rfc6087bis] are not applicable in this case 1479 because the YANG serialization is not intended to be accessed via 1480 NETCONF. However, for those who try to instantiate this model in a 1481 device via NETCONF, all objects in each model in this draft exhibit 1482 similar security characteristics as [I-D.ietf-netmod-acl-model]. The 1483 basic purpose of MUD is to configure access, and so by its very 1484 nature can be disruptive if used by unauthorized parties. 1486 16. IANA Considerations 1488 16.1. YANG Module Registrations 1490 The following YANG modules are requested to be registred in the "IANA 1491 Module Names" registry: 1493 The ietf-mud module: 1495 o Name: ietf-mud 1497 o XML Namespace: urn:ietf:params:xml:ns:yang:ietf-mud 1498 o Prefix: ief-mud 1500 o Reference: This memo 1502 The ietf-acldns module: 1504 o Name: ietf-acldns 1506 o XML Namespace: urn:ietf:params:xml:ns:yang:ietf-acldns 1508 o Prefix: ietf-acldns 1510 o Reference: This memo 1512 16.2. DHCPv4 and DHCPv6 Options 1514 The IANA has allocated option 161 in the Dynamic Host Configuration 1515 Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters registry 1516 for the MUD DHCPv4 option. 1518 IANA is requested to allocated the DHCPv4 and v6 options as specified 1519 in Section 9. 1521 16.3. PKIX Extensions 1523 IANA is kindly requested to make the following assignments for: 1525 o The MUDURLExtnModule-2016 ASN.1 module in the "SMI Security for 1526 PKIX Module Identifier" registry (1.3.6.1.5.5.7.0). 1528 o id-pe-mud-url object identifier from the "SMI Security for PKIX 1529 Certificate Extension" registry (1.3.6.1.5.5.7.1). 1531 The use fo these values is specified in Section 10. 1533 16.4. Well Known URI Suffix 1535 The IANA has allocated the URL suffix of "mud" as follows: 1537 o URI Suffix: "mud" o Specification documents: this document o 1538 Related information: n/a 1540 16.5. MIME Media-type Registration for MUD files 1542 The following media-type is defined for transfer of MUD file: 1544 o Type name: application 1545 o Subtype name: mud+json 1546 o Required parameters: n/a 1547 o Optional parameters: n/a 1548 o Encoding considerations: 8bit; application/mud+json values 1549 are represented as a JSON object; UTF-8 encoding SHOULD be 1550 employed. 1551 o Security considerations: See {{secon}} of this document. 1552 o Interoperability considerations: n/a 1553 o Published specification: this document 1554 o Applications that use this media type: MUD controllers as 1555 specified by this document. 1556 o Fragment identifier considerations: n/a 1557 o Additional information: 1559 Magic number(s): n/a 1560 File extension(s): n/a 1561 Macintosh file type code(s): n/a 1563 o Person & email address to contact for further information: 1564 Eliot Lear , Ralph Droms 1565 o Intended usage: COMMON 1566 o Restrictions on usage: none 1567 o Author: 1568 Eliot Lear 1569 Ralph Droms 1570 o Change controller: IESG 1571 o Provisional registration? (standards tree only): No. 1573 16.6. LLDP IANA TLV Subtype Registry 1575 IANA is requested to create a new registry for IANA Link Layer 1576 Discovery Protocol (LLDP) TLV subtype values. The recommended policy 1577 for this registry is Expert Review. The maximum number of entries in 1578 the registry is 256. 1580 IANA is required to populate the initial registry with the value: 1582 LLDP subtype value = 1 (All the other 255 values should be initially 1583 marked as 'Unassigned'.) 1585 Description = the Manufacturer Usage Description (MUD) Uniform 1586 Resource Locator (URL) 1588 Reference = < this document > 1590 16.7. The MUD Well Known Universal Resource Name (URNs) 1592 The following parameter registry is requested to be added in 1593 accordance with [RFC3553] 1595 Registry name: "urn:ietf:params:mud" is requested. 1596 Specification: this document 1597 Repository: this document 1598 Index value: Encoded identically to a TCP/UDP port service 1599 name, as specified in Section 5.1 of [RFC6335] 1601 The following entries should be added to the "urn:ietf:params:mud" 1602 name space: 1604 "urn:ietf:params:mud:dns" refers to the service specified by 1605 [RFC1123]. "urn:ietf:params:mud:ntp" refers to the service specified 1606 by [RFC5905]. 1608 17. Acknowledgments 1610 The authors would like to thank Einar Nilsen-Nygaard, who 1611 singlehandedly updated the model to match the updated ACL model, 1612 Bernie Volz, Tom Gindin, Brian Weis, Sandeep Kumar, Thorsten Dahm, 1613 John Bashinski, Steve Rich, Jim Bieda, and Dan Wing for their 1614 valuable advice and reviews. Russ Housley entirely rewrote 1615 Section 10 to be a complete module. Adrian Farrel provided the basis 1616 for privacy considerations text. Kent Watson provided a thorough 1617 review of the archictecture and the YANG model. The remaining errors 1618 in this work are entirely the responsibility of the author. 1620 18. References 1622 18.1. Normative References 1624 [I-D.ietf-anima-bootstrapping-keyinfra] 1625 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 1626 S., and K. Watsen, "Bootstrapping Remote Secure Key 1627 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 1628 keyinfra-06 (work in progress), May 2017. 1630 [I-D.ietf-netmod-acl-model] 1631 Bogdanovic, D., Jethanandani, M., Huang, L., Agarwal, S., 1632 and D. Blair, "Network Access Control List (ACL) YANG Data 1633 Model", draft-ietf-netmod-acl-model-11 (work in progress), 1634 June 2017. 1636 [I-D.ietf-netmod-rfc6087bis] 1637 Bierman, A., "Guidelines for Authors and Reviewers of YANG 1638 Data Model Documents", draft-ietf-netmod-rfc6087bis-13 1639 (work in progress), June 2017. 1641 [IEEE8021AB] 1642 Institute for Electrical and Electronics Engineers, "IEEE 1643 Standard for Local and Metropolitan Area Networks-- 1644 Station and Media Access Control Connectivity Discovery", 1645 n.d.. 1647 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 1648 Application and Support", STD 3, RFC 1123, 1649 DOI 10.17487/RFC1123, October 1989, 1650 . 1652 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1653 Requirement Levels", BCP 14, RFC 2119, 1654 DOI 10.17487/RFC2119, March 1997, 1655 . 1657 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1658 RFC 2131, DOI 10.17487/RFC2131, March 1997, 1659 . 1661 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1662 DOI 10.17487/RFC2818, May 2000, 1663 . 1665 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 1666 C., and M. Carney, "Dynamic Host Configuration Protocol 1667 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 1668 2003, . 1670 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1671 Levkowetz, Ed., "Extensible Authentication Protocol 1672 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 1673 . 1675 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1676 Resource Identifier (URI): Generic Syntax", STD 66, 1677 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1678 . 1680 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 1681 Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, 1682 January 2005, . 1684 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1685 Housley, R., and W. Polk, "Internet X.509 Public Key 1686 Infrastructure Certificate and Certificate Revocation List 1687 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1688 . 1690 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1691 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1692 . 1694 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1695 "Network Time Protocol Version 4: Protocol and Algorithms 1696 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1697 . 1699 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1700 the Network Configuration Protocol (NETCONF)", RFC 6020, 1701 DOI 10.17487/RFC6020, October 2010, 1702 . 1704 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 1705 Capabilities in Customer Premises Equipment (CPE) for 1706 Providing Residential IPv6 Internet Service", RFC 6092, 1707 DOI 10.17487/RFC6092, January 2011, 1708 . 1710 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 1711 Cheshire, "Internet Assigned Numbers Authority (IANA) 1712 Procedures for the Management of the Service Name and 1713 Transport Protocol Port Number Registry", BCP 165, 1714 RFC 6335, DOI 10.17487/RFC6335, August 2011, 1715 . 1717 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1718 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1719 . 1721 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 1722 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 1723 BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, 1724 . 1726 [RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: 1727 Protecting against Rogue DHCPv6 Servers", BCP 199, 1728 RFC 7610, DOI 10.17487/RFC7610, August 2015, 1729 . 1731 18.2. Informative References 1733 [FW95] Chapman, D. and E. Zwicky, "Building Internet Firewalls", 1734 January 1995. 1736 [IEEE8021AR] 1737 Institute for Electrical and Electronics Engineers, 1738 "Secure Device Identity", 1998. 1740 [ISO.8601.1988] 1741 International Organization for Standardization, "Data 1742 elements and interchange formats - Information interchange 1743 - Representation of dates and times", ISO Standard 8601, 1744 June 1988. 1746 [RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic 1747 Technology and the Internet", BCP 200, RFC 1984, 1748 DOI 10.17487/RFC1984, August 1996, 1749 . 1751 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1752 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 1753 . 1755 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 1756 IETF URN Sub-namespace for Registered Protocol 1757 Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 1758 2003, . 1760 [RFC6872] Gurbani, V., Ed., Burger, E., Ed., Anjali, T., Abdelnur, 1761 H., and O. Festor, "The Common Log Format (CLF) for the 1762 Session Initiation Protocol (SIP): Framework and 1763 Information Model", RFC 6872, DOI 10.17487/RFC6872, 1764 February 2013, . 1766 [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and 1767 IETF Protocol and Documentation Usage for IEEE 802 1768 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, 1769 October 2013, . 1771 [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 1772 "Tunnel Extensible Authentication Protocol (TEAP) Version 1773 1", RFC 7170, DOI 10.17487/RFC7170, May 2014, 1774 . 1776 [RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, 1777 "Architectural Considerations in Smart Object Networking", 1778 RFC 7452, DOI 10.17487/RFC7452, March 2015, 1779 . 1781 [RFC7488] Boucadair, M., Penno, R., Wing, D., Patil, P., and T. 1782 Reddy, "Port Control Protocol (PCP) Server Selection", 1783 RFC 7488, DOI 10.17487/RFC7488, March 2015, 1784 . 1786 Appendix A. Changes from Earlier Versions 1788 RFC Editor to remove this section prior to publication. 1790 Draft -06 to -07: 1792 o Update models to match new ACL model 1794 o extract directionality from the ACL, introducing a new device 1795 container. 1797 Draft -05 to -06: 1799 o Make clear that this is a component architecture (Polk and Watson) 1801 o Add order of operations (Watson) 1803 o Add extensions leaf-list (Pritikin) 1805 o Remove previous-mud-file (Watson) 1807 o Modify text in last-update (Watson) 1809 o Clarify local networks (Weis, Watson) 1811 o Fix contact info (Watson) 1813 o Terminology clarification (Weis) 1815 o Advice on how to handle LDevIDs (Watson) 1817 o Add deployment considerations (Watson) 1819 o Add some additional text about fingerprinting (Watson) 1821 o Appropriate references to 6087bis (Watson) 1823 o Change systeminfo to a URL to be referenced (Lear) 1824 Draft -04 to -05: * syntax error correction 1826 Draft -03 to -04: * Re-add my-controller 1828 Draft -02 to -03: * Additional IANA updates * Format correction in 1829 YANG. * Add reference to TEAP. 1831 Draft -01 to -02: * Update IANA considerations * Accept Russ Housley 1832 rewrite of X.509 text * Include privacy considerations text * Redo 1833 the URL limit. Still 255 bytes, but now stated in the URL 1834 definition. * Change URI registration to be under urn:ietf:params 1836 Draft -00 to -01: * Fix cert trust text. * change supportInformation 1837 to meta-info * Add an informaitonal element in. * add urn registry 1838 and create first entry * add default elements 1840 Appendix B. Default MUD elements 1842 What follows is a MUD file that permits DNS traffic to a controller 1843 that is registered with the URN "urn:ietf:params:mud:dns" and traffic 1844 NTP to a controller that is registered "urn:ietf:params:mud:ntp". 1845 This is considered the default behavior and the ACEs are in effect 1846 appended to whatever other ACEs. To block DNS or NTP one repeats the 1847 matching statement but replace "permit" with deny. Because ACEs are 1848 processed in the order they are received, the defaults would not be 1849 reached. A MUD controller might further decide to optimize to simply 1850 not include the defaults when they are overriden. 1852 A complete MUD entry is included below. 1854 { 1855 "ietf-mud:metainfo": { 1856 "last-update": "2016-09-27T15:10:24+02:00", 1857 "cache-validity": 168 1858 }, 1859 "acl:access-lists": { 1860 "access-list": [ 1861 { 1862 "acl-name": "mud-53134-v4in", 1863 "acl-type": "ipv4-acl", 1864 "ietf-mud:packet-direction": "to-device", 1865 "access-list-entries": { 1866 "ace": [ 1867 { 1868 "rule-name": "entout0-in", 1869 "matches": { 1870 "ietf-mud:controller": "urn:ietf:params:mud:dns", 1871 "protocol": 17, 1872 "source-port-range": { 1873 "lower-port": 53, 1874 "upper-port": 53 1875 } 1876 }, 1877 "actions": { 1878 "permit": [ 1879 null 1880 ] 1881 } 1882 }, 1883 { 1884 "rule-name": "entout1-in", 1885 "matches": { 1886 "ietf-mud:controller": "urn:ietf:params:mud:dns", 1887 "protocol": 6, 1888 "source-port-range": { 1889 "lower-port": 53, 1890 "upper-port": 53 1891 } 1892 }, 1893 "actions": { 1894 "permit": [ 1895 null 1896 ] 1897 } 1898 }, 1899 { 1900 "rule-name": "entout2-in", 1901 "matches": { 1902 "ietf-mud:controller": "urn:ietf:params:mud:ntp", 1903 "protocol": 17, 1904 "source-port-range": { 1905 "lower-port": 123, 1906 "upper-port": 123 1907 } 1908 }, 1909 "actions": { 1910 "permit": [ 1911 null 1912 ] 1913 } 1914 } 1915 ] 1916 } 1917 }, 1918 { 1919 "acl-name": "mud-53134-v4out", 1920 "acl-type": "ipv4-acl", 1921 "ietf-mud:packet-direction": "from-device", 1922 "access-list-entries": { 1923 "ace": [ 1924 { 1925 "rule-name": "entout0-in", 1926 "matches": { 1927 "ietf-mud:controller": "urn:ietf:params:mud:dns", 1928 "protocol": 17, 1929 "source-port-range": { 1930 "lower-port": 53, 1931 "upper-port": 53 1932 } 1933 }, 1934 "actions": { 1935 "permit": [ 1936 null 1937 ] 1938 } 1939 }, 1940 { 1941 "rule-name": "entout1-in", 1942 "matches": { 1943 "ietf-mud:controller": "urn:ietf:params:mud:dns", 1944 "protocol": 6, 1945 "source-port-range": { 1946 "lower-port": 53, 1947 "upper-port": 53 1948 } 1949 }, 1950 "actions": { 1951 "permit": [ 1952 null 1953 ] 1954 } 1955 }, 1956 { 1957 "rule-name": "entout2-in", 1958 "matches": { 1959 "ietf-mud:controller": "urn:ietf:params:mud:ntp", 1960 "protocol": 17, 1961 "source-port-range": { 1962 "lower-port": 123, 1963 "upper-port": 123 1964 } 1965 }, 1966 "actions": { 1967 "permit": [ 1968 null 1969 ] 1970 } 1971 } 1972 ] 1973 } 1974 }, 1975 { 1976 "acl-name": "mud-53134-v6in", 1977 "acl-type": "ipv6-acl", 1978 "ietf-mud:packet-direction": "to-device", 1979 "access-list-entries": { 1980 "ace": [ 1981 { 1982 "rule-name": "entout0-in", 1983 "matches": { 1984 "ietf-mud:controller": "urn:ietf:params:mud:dns", 1985 "protocol": 17, 1986 "source-port-range": { 1987 "lower-port": 53, 1988 "upper-port": 53 1989 } 1990 }, 1991 "actions": { 1992 "permit": [ 1993 null 1994 ] 1995 } 1996 }, 1997 { 1998 "rule-name": "entout1-in", 1999 "matches": { 2000 "ietf-mud:controller": "urn:params:mud:dns", 2001 "protocol": 6, 2002 "source-port-range": { 2003 "lower-port": 53, 2004 "upper-port": 53 2005 } 2006 }, 2007 "actions": { 2008 "permit": [ 2009 null 2010 ] 2011 } 2012 }, 2013 { 2014 "rule-name": "entout2-in", 2015 "matches": { 2016 "ietf-mud:controller": "urn:ietf:params:mud:ntp", 2017 "protocol": 17, 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-53134-v6out", 2034 "acl-type": "ipv6-acl", 2035 "ietf-mud:packet-direction": "from-device", 2036 "access-list-entries": { 2037 "ace": [ 2038 { 2039 "rule-name": "entout0-in", 2040 "matches": { 2041 "ietf-mud:controller": "urn:ietf:params:mud:dns", 2042 "protocol": 17, 2043 "source-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": "entout1-in", 2056 "matches": { 2057 "ietf-mud:controller": "urn:ietf:params:mud:dns", 2058 "protocol": 6, 2059 "source-port-range": { 2060 "lower-port": 53, 2061 "upper-port": 53 2062 } 2063 }, 2064 "actions": { 2065 "permit": [ 2066 null 2067 ] 2068 } 2069 }, 2070 { 2071 "rule-name": "entout2-in", 2072 "matches": { 2073 "ietf-mud:controller": "urn:ietf:params:mud:ntp", 2074 "protocol": 17, 2075 "source-port-range": { 2076 "lower-port": 123, 2077 "upper-port": 123 2078 } 2079 }, 2080 "actions": { 2081 "permit": [ 2082 null 2083 ] 2084 } 2085 } 2086 ] 2087 } 2088 } 2089 ] 2090 } 2091 } 2093 Authors' Addresses 2095 Eliot Lear 2096 Cisco Systems 2097 Richtistrasse 7 2098 Wallisellen CH-8304 2099 Switzerland 2101 Phone: +41 44 878 9200 2102 Email: lear@cisco.com 2104 Ralph Droms 2106 Phone: +1 978 376 3731 2107 Email: rdroms@gmail.com 2108 Dan Romascanu 2110 Phone: +972 54 5555347 2111 Email: dromasca@gmail.com