idnits 2.17.1 draft-ietf-opsawg-mud-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 19, 2016) is 2806 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-03 == Outdated reference: A later version (-21) exists of draft-ietf-netmod-acl-model-08 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE8021AB' ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 6092 ** Downref: Normative reference to an Informational RFC: RFC 7299 -- Obsolete informational reference (is this intentional?): RFC 7042 (Obsoleted by RFC 9542) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Lear 3 Internet-Draft R. Droms 4 Intended status: Standards Track Cisco Systems 5 Expires: February 20, 2017 D. Romascanu 6 Avaya 7 August 19, 2016 9 Manufacturer Usage Description Specification 10 draft-ietf-opsawg-mud-00 12 Abstract 14 This memo specifies the necessary components to implement 15 manufacturer usage descriptions (MUD). This includes two YANG 16 modules, IPv4 and IPv6 DHCP options, an LLDP TLV, a URL suffix 17 specification, an X.509 certificate extension and a means to sign and 18 verify the descriptions. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on February 20, 2017. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. A Simple Example . . . . . . . . . . . . . . . . . . . . 4 56 1.2. Determining Intended Use . . . . . . . . . . . . . . . . 4 57 1.3. Finding A Policy: The MUD URL . . . . . . . . . . . . . . 5 58 1.4. Types of Policies . . . . . . . . . . . . . . . . . . . . 5 59 1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 60 1.6. The Manufacturer Usage Description Architecture . . . . . 7 61 2. The MUD Model and Semantic Meaning . . . . . . . . . . . . . 8 62 3. Element Definitions . . . . . . . . . . . . . . . . . . . . . 8 63 3.1. last-update . . . . . . . . . . . . . . . . . . . . . . . 9 64 3.2. previous-mud-file . . . . . . . . . . . . . . . . . . . . 9 65 3.3. cache-validity . . . . . . . . . . . . . . . . . . . . . 9 66 3.4. masa-server . . . . . . . . . . . . . . . . . . . . . . . 9 67 3.5. is-supported . . . . . . . . . . . . . . . . . . . . . . 9 68 3.6. packet-direction . . . . . . . . . . . . . . . . . . . . 9 69 3.7. manufacturer . . . . . . . . . . . . . . . . . . . . . . 10 70 3.8. same-manufacturer . . . . . . . . . . . . . . . . . . . . 10 71 3.9. model . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 3.10. local-networks . . . . . . . . . . . . . . . . . . . . . 10 73 3.11. controller . . . . . . . . . . . . . . . . . . . . . . . 10 74 3.12. direction-initiated . . . . . . . . . . . . . . . . . . . 10 75 4. Processing of the MUD file . . . . . . . . . . . . . . . . . 11 76 5. What does a MUD URL look like? . . . . . . . . . . . . . . . 11 77 6. The MUD YANG Model . . . . . . . . . . . . . . . . . . . . . 11 78 7. The Domain Name Extension to the ACL Model . . . . . . . . . 15 79 7.1. source-dnsname . . . . . . . . . . . . . . . . . . . . . 15 80 7.2. destination-dnsname . . . . . . . . . . . . . . . . . . . 15 81 7.3. The ietf-acldns Model . . . . . . . . . . . . . . . . . . 16 82 8. MUD File Example . . . . . . . . . . . . . . . . . . . . . . 17 83 9. The MUD URL DHCP Option . . . . . . . . . . . . . . . . . . . 18 84 9.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 19 85 9.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 19 86 9.3. Relay Requirements . . . . . . . . . . . . . . . . . . . 20 87 10. The Manufacturer Usage Description (MUD) URL X.509 Extension 20 88 11. The Manufacturer Usage Description LLDP extension . . . . . . 21 89 12. Creating and Processing of Signed MUD Files . . . . . . . . . 22 90 12.1. Creating a MUD file signature . . . . . . . . . . . . . 22 91 12.2. Verifying a MUD file signature . . . . . . . . . . . . . 23 92 13. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 23 93 14. Security Considerations . . . . . . . . . . . . . . . . . . . 24 94 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 95 15.1. DHCPv4 and DHCPv6 Options . . . . . . . . . . . . . . . 25 96 15.2. PKIX Extensions . . . . . . . . . . . . . . . . . . . . 25 97 15.3. Well Known URI Suffix . . . . . . . . . . . . . . . . . 25 98 15.4. MIME Media-type Registration for MUD files . . . . . . . 25 99 15.5. LLDP IANA TLV Subtype Registry . . . . . . . . . . . . . 26 100 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 101 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 102 17.1. Normative References . . . . . . . . . . . . . . . . . . 27 103 17.2. Informative References . . . . . . . . . . . . . . . . . 28 104 Appendix A. Changes from Earlier Versions . . . . . . . . . . . 29 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 107 1. Introduction 109 The Internet has largely been constructed on general purpose 110 computers; those devices that may be used for a purpose that is 111 specified by those who buy the device. [RFC1984] presumed that an 112 end device would be most capable of protecting itself. This made 113 sense when the typical device was a workstation or a mainframe, and 114 it continues to make sense for general purpose computing devices 115 today, including laptops, smart phones, and tablets. 117 [RFC7452] discusses design patterns for, and poses questions about, 118 smart objects. Let us then posit a group of objects that are 119 specifically not general purpose computers. These devices therefore 120 have a purpose to their use. By definition, therefore, all other 121 purposes are NOT intended. The combination of these two statements 122 can be restated as a manufacturer usage description (MUD) that can be 123 applied at various points within a network. Although this memo may 124 seem to stress access requirements, usage intent also consists of 125 quality of service needs a device may have. 127 We use the notion of "manufacturer" loosely in this context, to 128 simply mean the entity or organization that will state how a device 129 is intended to be used. In the context of a lightbulb, this might 130 indeed be the lightbulb manufacturer. In the context of a smarter 131 device that has a built in Linux stack, it might be integrator of 132 that device. The key points are that the device itself is expected 133 to serve a limited purpose, and that there may exist an organization 134 in the supply chain of that device that will take responsibility for 135 informing the network about that purpose. 137 The converse statement holds that general computing systems will 138 benefit very little from MUD, as their manufacturers cannot envision 139 a specific communication pattern to describe. 141 The intent of MUD is to therefore solve for the following problems: 143 o Substantially reduce the threat surface on a device entering a 144 network to those communications intended by the manufacturer. 146 o Provide for a means to scale network policies to the ever- 147 increasing number types of devices in the network. 149 o Provide a means to address at least some vulnerabilities in a way 150 that is faster than it might take to update systems. This will be 151 particularly true for systems that are no longer supported by 152 their manufacturer. 154 o Keep the cost of implementation of such a system to the bare 155 minimum. 157 No matter how good a MUD-enabled network is, it will never replace 158 the need for manufacturers to patch vulnerabilities. It may, 159 however, provide network administrators with some additional 160 protection when those vulnerabilities exist. 162 1.1. A Simple Example 164 A light bulb is intended to light a room. It may be remotely 165 controlled through the network; and it may make use of a rendezvous 166 service of some form that an app on smart phone accesses. What we 167 can say about that light bulb, then, is that all other network access 168 is unwanted. It will not contact a news service, nor speak to the 169 refrigerator, and it has no need of a printer or other devices. It 170 has no Facebook friends. Therefore, an access list applied to it 171 that states that it will only connect to the single rendezvous 172 service will not impede the light bulb in performing its function, 173 while at the same time allowing the network to provide both it and 174 other devices an additional layer of protection. 176 1.2. Determining Intended Use 178 The notion of intended use is in itself not new. Network 179 administrators apply access lists every day to allow for only such 180 use. This notion of white listing was well described by Chapman and 181 Zwicky in [FW95]. Programmatically profiling systems have existed 182 for years as well. These systems make use of heuristics that take at 183 least some time to assert what a system is. 185 A system could just as easily tell the network what sort of 186 protection it requires without going into what sort of system it is. 187 This would, in effect, be the converse of [RFC7488]. In seeking a 188 general purpose solution, however, we assume that a device has so few 189 capabilities that it will implement the least necessary capabilities 190 to function properly. This is a basic economic constraint. Unless 191 the network would refuse access to such a device, its developers 192 would have no reason to implement such an approach. To date, such an 193 assertion has held true. 195 1.3. Finding A Policy: The MUD URL 197 Our work begins, therefore, with the device emitting a Universal 198 Resource Locator (URL) [RFC3986]. This URL may serves both to 199 classify the device type and to provide a means to locate a policy 200 file. 202 In this memo three means are defined to emit the MUD URL. One is a 203 DHCP option[RFC2131],[RFC3315] that the DHCP client uses to inform 204 the DHCP server. The DHCP server may take further actions, such as 205 retrieve the URL or otherwise pass it along to network management 206 system or controller. The other method defined is an X.509 207 constraint. The IEEE has developed [IEEE8021AR] that provides a 208 certificate-based approach to communicate device characteristics, 209 which itself relies on [RFC5280]. The MUD URL extension is non- 210 critical, as required by IEEE 802.1AR. Finally, an LLDP frame is 211 defined. 213 1.4. Types of Policies 215 When the MUD URL is resolved, the MUD controller retrieves a file 216 that describes what sort of communications a device is designed to 217 have. The manufacturer may specify either specific hosts for cloud 218 based services or certain classes for access within an operational 219 network. An example of a class might be "devices of a specified 220 manufacturer type", where the manufacturer type itself is indicated 221 simply by the authority of the MUD URL. Another example might to 222 allow or disallow local access. Just like other policies, these may 223 be combined. For example: 225 Allow access to host controller.example.com with QoS AF11 226 Allow access to devices of the same manufacturer 227 Allow access to and from controllers who need to speak COAP 228 Allow access to local DNS/DHCP 229 Deny all other access 231 To add a bit more depth that should not be a stretch of anyone's 232 imagination, one could also make use of port-based access lists. 233 Thus a printer might have a description that states: 235 Allow access for port IPP or port LPD 236 Allow local access for port HTTP 237 Deny all other access 239 In this way anyone can print to the printer, but local access would 240 be required for the management interface. 242 The files that are retrieved are intended to be closely aligned to 243 existing network architectures so that they are easy to deploy. We 244 make use of YANG [RFC6020] because of the time and effort spent to 245 develop accurate and adequate models for use by network devices. 246 JSON is used as a serialization for compactness and readability, 247 relative to XML. 249 The YANG modules specified here are extensions of 250 [I-D.ietf-netmod-acl-model]. The extensions to this model allow for 251 a manufacturer to express classes of systems that a manufacturer 252 would find necessary for the proper function of the device. Two 253 modules are specified. The first module specifies a means for domain 254 names to be used in ACLs so that devices that have their controllers 255 in the cloud may be appropriately authorized with domain names, where 256 the mapping of those names to addresses may rapidly change. 258 The second module abstracts away IP addresses into certain classes 259 that are instantiated into actual IP addresses through local 260 processing. Through these classes, manufacturers can specify how the 261 device is designed to communicate, so that network elements can be 262 configured by local systems that have local topological knowledge. 263 That is, the deployment populates the classes that the manufacturer 264 specifies. 266 Because manufacturers do not know who will be using their devices, it 267 is important for functionality referenced in usage descriptions to be 268 relatively ubiquitous, and therefore, mature. Therefore, only a a 269 limited subset YANG-based configuration of is permitted in a MUD 270 file. 272 1.5. Terminology 274 MUD: manufacturer usage description. 276 MUD file: a file containing YANG-based JSON that describes a 277 recommended behavior. 279 MUD file server: a web server that hosts a MUD file. 281 MUD controller: the system that requests and receives the MUD file 282 from the MUD server. After it has processed a MUD file it may 283 direct changes to relevant network elements. 285 MUD URL: a URL that can be used by the MUD controller to receive the 286 MUD file. 288 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 289 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 290 document are to be interpreted as described in [RFC2119]. 292 1.6. The Manufacturer Usage Description Architecture 294 With these components laid out we now have the basis for an 295 archicture. This leads us to ASCII art. 297 ......................................... 298 . ____________ . _____________ 299 . | | . | | 300 . | MUD |----->get URL->| MUD | 301 . | Controller | .(https) | File Server | 302 . End system network |____________|<--MUD file<--<|_____________| 303 . . . 304 . . . 305 . _______ _________ . 306 .| | (dhcp et al) | router | . 307 .| Thing |---->MUD URL-->| or | . 308 .|_______| | switch | . 309 . |_________| . 310 ......................................... 312 Figure 1: MUD Architecture 314 In the above diagram, the switch or router collects MUD URLs and 315 forwards them to the network management system for processing. This 316 happens in different ways, depending on how the URI is communicated. 317 For instance, in the case of DHCP, the DHCP server might receive the 318 URI and then process it. In the case of IEEE 802.1X, the switch 319 would tunnel the URI to the authentication server, who would then 320 process it. 322 The information returned by the web site is valid for the duration of 323 the device's connection, or as specified in the description. Thus if 324 the device is mobile, when it moves on, any configuration in the 325 switch is removed. Similarly, from time to time the description may 326 be refreshed, based on new capabilities or communication patterns or 327 vulnerabilities. 329 The web site is typically run by or on behalf of the manufacturer. 330 Its domain name is that of the authority found in the MUD URL. For 331 legacy cases where Things cannot emit a URL, if the switch is able to 332 determine the appropriate URI, it may proxy it, the trivial cases 333 being a map between some registered device or port and a URL. 335 2. The MUD Model and Semantic Meaning 337 A MUD file consists of JSON based on a YANG model. For purposes of 338 MUD, the elements that can be modified are access lists as augmented 339 by this model. The MUD file is limited to the serialization of a 340 small number of YANG schema, including the models specified in the 341 following documents: 343 o [I-D.ietf-netmod-acl-model] 345 o [RFC6991] 347 Publishers of MUD files MUST NOT include other elements except as 348 described in Section 13, and MUST only contain information relevant 349 to the device being described. Devices parsing MUD files MUST cease 350 processing if they find other elements. 352 This module is structured into three parts. The first container 353 holds information that is relevant to retrieval and validity of the 354 MUD file itself. The second container augments the access list to 355 indicate direction the ACL is to be applied. The final container 356 augments the matching container of the ACL model to add several 357 elements that are relevant to the MUD URL, or other otherwise 358 abstracted for use within a local environment. 360 module: ietf-mud 361 +--rw meta-information 362 +--rw last-update? yang:date-and-time 363 +--rw previous-mud-file? yang:uri 364 +--rw cache-validity? uint32 365 +--rw masa-server? inet:uri 366 +--rw is-supported? boolean 367 augment /acl:access-lists/acl:acl: 368 +--rw packet-direction? direction 369 augment /acl:access-lists/acl:acl 370 /acl:access-list-entries/acl:ace/acl:matches: 371 +--rw manufacturer? inet:host 372 +--rw same-manufacturer? empty 373 +--rw model? string 374 +--rw local-networks? empty 375 +--rw controller? inet:uri 376 +--rw direction-initiated? direction 378 3. Element Definitions 380 The following elements are defined. 382 3.1. last-update 384 This is a date-and-time value of the last time the MUD file was 385 updated. This is akin to a version number. Its form is taken from 386 [RFC6991] which, for those keeping score, turn was taken from 387 Section 5.6 of [RFC3339], which was taken from [ISO.8601.1988]. 389 3.2. previous-mud-file 391 This is a URL that should point to the previous MUD URL for auditing 392 purposes. Because it should not be necessary to resign a MUD file 393 when a new one is released, the archival location of a current MUD 394 file should be identified prior to its release. Note the signature 395 file MUST also be available. For example, if previous-mud-file is 396 set to "https://example.com/.mud/v1/xxx", the corresponding signature 397 would be found at "https://example.com/.mud/v1/xxx.p7s". 399 3.3. cache-validity 401 This uint32 is the period of time in hours that a network management 402 station MUST wait since its last retrieval before checking for an 403 update. It is RECOMMENDED that this value be no less than 24 and no 404 more than 1440 for any device that is supported. 406 3.4. masa-server 408 This optional element refers to the URL that should be used to 409 resolve the location any MASA service, as specified in 410 [I-D.ietf-anima-bootstrapping-keyinfra]. 412 3.5. is-supported 414 This boolean is an indication from the manufacturer to the network 415 administrator as to whether or not the device is supported. In this 416 context a device is said to be supported if the manufacturer might 417 issue an update to the device or if the manufacturer might update the 418 MUD file. 420 3.6. packet-direction 422 [I-D.ietf-netmod-acl-model] describes access-lists but does not 423 attempt to indicate where they are applied as that is handled 424 elsewhere in a configuration. However, in this case, a MUD file must 425 be explicit in describing the communcation pattern of a device, and 426 that includes indicating what is to be permitted or denied in either 427 direction of communication. This element takes a single value of 428 either "to-device" or "from-device", based on a typedef "direction". 430 3.7. manufacturer 432 This element consists of a hostname that would be matched against the 433 authority section of another device's MUD URL. 435 3.8. same-manufacturer 437 This is an equivalent for when the manufacturer element is used to 438 indicate the authority that is found in another device's MUD URL 439 matches that of the authority found in this device's MUD URL. 441 3.9. model 443 This string matches the one and only segment following the authority 444 section of the MUD URL. It refers to a model that is unique within 445 the context of the authority. It may also include product version 446 information. Thus how this field is constructed is entirely a local 447 matter for the manufacturer. 449 3.10. local-networks 451 This null-valued element expands to include local networks. Its 452 default expansion is that packets must not traverse toward a default 453 route that is received from the router. 455 3.11. controller 457 This URI specifies a value that a controller will register with the 458 network management station. The element then is expanded to the set 459 of hosts that are so registered. 461 In addition, some meta information is defined in order to determine 462 when a usage description should be refreshed. 464 3.12. direction-initiated 466 When applied this matches packets when the flow was initiated in the 467 corresponding direction. [RFC6092] provides guidance for IPv6 468 guidance best practices. While that document is scoped specifically 469 to IPv6, its contents are applicable for IPv4 as well. When this 470 flag is set, and the system has no reason to believe a flow has been 471 initiated it MUST drop the packet. This match SHOULD be applied with 472 specific transport parameters, such as protocol. 474 4. Processing of the MUD file 476 To keep things relatively simple in addition to whatever definitions 477 exist, we also apply two additional default behaviors: 479 o Anything not explicitly permitted is denied. 481 o Local DNS, DHCP, and NTP are, by default, permitted to and from 482 the device. 484 5. What does a MUD URL look like? 486 To begin with, MUD takes full advantage of both the https: scheme and 487 the use of .well-known. HTTPS is important in this case because a 488 man in the middle attack could otherwise harm the operation of a 489 class of devices. .well-known is used because we wish to add 490 additional structure to the URL. And so the URL appears as follows: 492 mud-url = "https://" authority "/.well-known/mud/" mud-rev 493 "/" model ( "?" extras ) 494 ; authority is from RFC3986 495 mud-rev = "v1" 496 model = segment ; from RFC3986 497 extras = query ; from RFC3986 499 mud-rev signifies the version of the manufacturer usage description 500 file. This memo specifies "v1" of that file. Later versions may 501 permit additional schemas or modify the format. 503 "model" represents a device model as the manufacturer wishes to 504 represent it. It could be a brand name or something more specific. 505 It also may provide a means to indicate what version the product is. 506 Specifically if it has been updated in the field, this is the place 507 where evidence of that update would appear. The field should be 508 changed when the intended communication patterns of a device change. 509 While from a controller standpoint, only comparison and matching 510 operations are safe, it is envisioned that updates will require some 511 administrative review. Processing of this URL occurs as specified in 512 [RFC2818] and [RFC3986]. 514 6. The MUD YANG Model 516 file "ietf-mud@2016-07-20.yang"; 518 module ietf-mud { 519 yang-version 1.1; 520 namespace "urn:ietf:params:xml:ns:yang:ietf-mud"; 521 prefix "ietf-mud"; 523 import ietf-access-control-list { 524 prefix "acl"; 525 } 527 import ietf-yang-types { 528 prefix "yang"; 529 } 531 import ietf-inet-types { 532 prefix "inet"; 533 } 535 organization 536 "IETF OPSAWG (Ops Area) Working Group"; 538 contact 539 "WG Web: http://tools.ietf.org/wg/opsawg/ 540 WG List: opsawg@ietf.org 541 WG Chair: Warren Kumari 542 warren@kumari.net 543 WG Chair: Zhou Tianran 544 zhoutianran@huawei.com 545 Editor: Eliot Lear 546 lear@cisco.com 547 Editor: Ralph Droms 548 rdroms@cisco.com 549 "; 551 description 552 "This YANG module defines a component that augments the 553 IETF description of an access list. This specific module 554 focuses on additional filters that include local, model, 555 and same-manufacturer. 557 Copyright (c) 2016 IETF Trust and the persons identified as 558 the document authors. All rights reserved. 559 Redistribution and use in source and binary forms, with or 560 without modification, is permitted pursuant to, and subject 561 to the license terms contained in, the Simplified BSD 562 License set forth in Section 4.c of the IETF Trust's Legal 563 Provisions Relating to IETF Documents 564 (http://trustee.ietf.org/license-info). 565 This version of this YANG module is part of RFC XXXX; see 566 the RFC itself for full legal notices."; 568 revision "2016-07-20" { 569 description "Base version of MUD extensions to ACL model"; 570 reference "RFC XXXX: Manufacturer Usage Description Specification"; 571 } 573 typedef direction { 574 type enumeration { 575 enum to-device { 576 description "packets or flows destined to the target device"; 577 } 578 enum from-device { 579 description "packets or flows destined from 580 the target device"; 581 } 582 } 583 description "Which way are we talking about?"; 584 } 586 container meta-information { 588 description "Information about when support end(ed), and 589 when to refresh"; 591 leaf last-update { 592 type yang:date-and-time; 593 description "This is intended to be the time and date that 594 the MUD file was generated."; 595 } 597 leaf previous-mud-file { 598 type inet:uri; 599 description "Use to find the previous MUD file location 600 for auditing purposes."; 601 } 603 leaf cache-validity { 604 type uint32; 605 description "The information retrieved from the MUD server is 606 valid for these many hours, after which it should 607 be refreshed."; 608 } 610 leaf masa-server { 611 type inet:uri; 612 description "The URI of the MASA server that network 613 elements should forward requests to for this device."; 614 } 616 leaf is-supported { 617 type boolean; 618 description "The element is currently supported 619 by the manufacturer."; 620 } 621 } 623 augment "/acl:access-lists/acl:acl" { 624 description "add inbound or outbound. Normally access lists 625 are applied in an inbound or outbound direction 626 separately from their definition. This is not 627 possible with MUD."; 628 leaf packet-direction 629 { 630 type direction; 631 description "inbound or outbound ACL."; 632 } 633 } 635 augment "/acl:access-lists/acl:acl/" + 636 "acl:access-list-entries/acl:ace/" + 637 "acl:matches" { 638 description "adding abstractions to avoid need of IP addresses"; 640 leaf manufacturer { 641 type inet:host; 642 description "authority component of the manufacturer URI"; 643 } 645 leaf same-manufacturer { 646 type empty; 647 description "expand to ACEs for each device 648 with the same origin"; 649 } 651 leaf model { 652 type string; 653 description "specific model (including version) for a 654 given manufacturer"; 655 } 657 leaf local-networks { 658 type empty; 659 description "this string is used to indicate networks 660 considered local in a given environment."; 661 } 662 leaf controller { 663 type inet:uri; 664 description "expands to one or more controllers for a 665 given service that is codified by inet:uri."; 666 } 667 leaf direction-initiated { 668 type direction; 669 description "which direction a flow was initiated"; 670 } 671 } 672 } 674 676 7. The Domain Name Extension to the ACL Model 678 This module specifies an extension to IETF-ACL model such that domain 679 names may be referenced by augmenting the "matches" element. 680 Different implementations may deploy differing methods to maintain 681 the mapping between IP address and domain name, if indeed any are 682 needed. However, the intent is that resources that are referred to 683 using a name should be authorized (or not) within an access list. 685 The structure of the change is as follows: 687 augment 688 /acl:access-lists/acl:acl/acl:access-list-entries 689 /acl:ace/acl:matches/acl:ace-type/acl:ace-ip: 690 +--rw src-dnsname? inet:host 691 +--rw dst-dnsname? inet:host 693 The choice of this particular point in the access-list model is based 694 on the assumption that we are in some way referring to IP-related 695 resources, as that is what the DNS returns. A domain name in our 696 context is defined in [RFC6991]. 698 The following elements are defined. 700 7.1. source-dnsname 702 The argument corresponds to a domain name of a source as specified by 703 inet:host. Depending on how the model is used, it may or may not be 704 resolved, as required by the implementation and circumstances. 706 7.2. destination-dnsname 708 The argument corresponds to a domain name of a destination as 709 specified by inet:host. Depending on how the model is used, it may 710 or may not be resolved, as required by the implementation and 711 circumstances. 713 7.3. The ietf-acldns Model 715 file "ietf-acldns@2007-07020.yang"; 717 module ietf-acldns { 718 yang-version 1.1; 719 namespace "urn:ietf:params:xml:ns:yang:ietf-acldns"; 720 prefix "ietf-acldns"; 722 import ietf-access-control-list { 723 prefix "acl"; 724 } 726 import ietf-inet-types { 727 prefix "inet"; 728 } 730 organization 731 "IETF OPSAWG (Ops Area) Working Group"; 733 contact 734 "WG Web: http://tools.ietf.org/wg/opsawg/ 735 WG List: opsawg@ietf.org 736 WG Chair: Warren Kumari 737 warren@kumari.net 738 WG Chair: Zhou Tianran 739 zhoutianran@huawei.com 740 Editor: Eliot Lear 741 lear@cisco.com 742 Editor: Ralph Droms 743 rdroms@cisco.com 744 "; 746 description 747 "This YANG module defines a component that augments the 748 IETF description of an access list to allow dns names 749 as matching criteria."; 751 revision "2016-07-20" { 752 description "Base version of dnsname extension of ACL model"; 753 reference "RFC XXXX: Manufacturer Usage Description Specification"; 754 } 756 augment "/acl:access-lists/acl:acl/" + 757 "acl:access-list-entries/acl:ace/" + 758 "acl:matches/acl:ace-type/acl:ace-ip" { 759 description "adding domain names to matching"; 760 leaf src-dnsname { 761 type inet:host; 762 description "domain name to be matched against"; 763 } 764 leaf dst-dnsname { 765 type inet:host; 766 description "domain name to be matched against"; 767 } 768 } 769 } 771 773 8. MUD File Example 775 This example contains two access lists that are intended to provide 776 outbound access to a cloud service on TCP port 443. 778 { 779 "ietf-mud:support-information": { 780 "last-update": "2016-05-18T20:00:50Z", 781 "cache-validity": 1440 782 }, 783 "ietf-access-control-list:access-lists": { 784 "acl": [ { 785 "acl-name": "inbound-stuff", 786 "acl-type" : "ipv4-acl", 787 "ietf-mud:direction" : "to-device", 788 "access-list-entries": { 789 "ace": [ 790 { 791 "rule-name": "access-cloud", 792 "matches": { 793 "ietf-acldns:src-dnsname": 794 "lighting-system.example.com", 795 "protocol" : 6, 796 "source-port-range" : { 797 "lower-port" : 443, 798 "upper-port" : 443 799 } 800 }, 801 "actions" : { 802 "permit" : [null] 803 } 804 } 805 ] 806 } 807 }, 808 { 809 "acl-name": "outbound-stuff", 810 "acl-type" : "ipv4-acl", 811 "ietf-mud:direction" : "from-device", 812 "access-list-entries": { 813 "ace": [ 814 { 815 "rule-name": "access-cloud", 816 "matches": { 817 "ietf-acldns:dst-dnsname": 818 "lighting-system.example.com", 819 "protocol" : 6, 820 "destination-port-range" : { 821 "lower-port" : 443, 822 "upper-port" : 443 823 } 824 }, 825 "actions" : { 826 "permit" : [null] 827 } 828 } 829 ] 830 } 831 } 832 ] 833 } 834 } 836 9. The MUD URL DHCP Option 838 The IPv4 MUD URL client option has the following format: 840 +------+-----+------------------------------ 841 | code | len | MUD URL 842 +------+-----+------------------------------ 844 Code OPTION_MUD_URL_V4 (TBD) is assigned by IANA. len is a single 845 octet that indicates the length of the URL in octets. MUD URL is a 846 URL. The length of a MUD URL does not exceed 255 bytes. 848 The IPv6 MUD URL client option has the following format: 850 0 1 2 3 851 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 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | OPTION_MUD_URL_V6 | option-length | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | MUD URL | 856 | ... | 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 OPTION_MUD_URL_V6 (TBD; assigned by IANA). 861 option-length contains the length of the URL in octets. The length 862 MUST NOT exceed 255 octets. 864 The intent of this option is to provide both a new device classifier 865 to the network as well as some recommended configuration to the 866 routers that implement policy. However, it is entirely the purview 867 of the network system as managed by the network administrator to 868 decide what to do with this information. The key function of this 869 option is simply to identify the type of device to the network in a 870 structured way such that the policy can be easily found with existing 871 toolsets. 873 9.1. Client Behavior 875 A DHCP client MAY emit either a DHCPv4 or DHCPv6 option or both. 876 These options singletons, as specified in [RFC7227]. Because clients 877 are intended to have at most one MUD URL associated with them, they 878 may emit at most one MUD URL option via DHCPv4 and one MUD URL option 879 via DHCPv6. In the case where both v4 and v6 DHCP options are 880 emitted, the same URL MUST be used. 882 Clients SHOULD log or otherwise report improper acknowledgments from 883 servers, but they MUST NOT modify their MUD URL configuration based 884 on a server's response. The server's response is only an 885 acknowledgment that the server has processed the option, and promises 886 no specific network behavior to the client. In particular, it may 887 not be possible for the server to retrieve the file associated with 888 the MUD URL, or the local network administration may not wish to use 889 the usage description. Neither of these situations should be 890 considered in any way exceptional. 892 9.2. Server Behavior 894 A DHCP server may ignore these options or take action based on 895 receipt of these options. For purposes of debugging, if a server 896 successfully parses the option and the URL, it MUST return the option 897 with the same URL as an acknowledgment. Even in this circumstance, 898 no specific network behavior is guaranteed. When a server consumes 899 this option, it will either forward the URL and relevant client 900 information to a network management system (such as the giaddr), or 901 it will retrieve the usage description by resolving the URL. 903 DHCP servers may implement MUD functionality themselves or they may 904 pass along appropriate information to a network management system or 905 controller. A DHCP server that does process the MUD URL MUST adhere 906 to the process specified in [RFC2818] and [RFC5280] to validate the 907 TLS certificate of the web server hosting the MUD file. Those 908 servers will retrieve the file, process it, create and install the 909 necessary configuration on the relevant network element. Servers 910 SHOULD monitor the gateway for state changes on a given interface. A 911 DHCP server that does not provide MUD functionality and has forwarded 912 a MUD URL to a network management system MUST notify the network 913 management of any corresponding change to the DHCP state of the 914 client (such as expiration or explicit release of a network address 915 lease). 917 9.3. Relay Requirements 919 There are no additional requirements for relays. 921 10. The Manufacturer Usage Description (MUD) URL X.509 Extension 923 [RFC7299] provides a procedure and means to specify extensions to 924 X.509 certificates. The MUD URL is a non-critical Certificate 925 extension that points to an on-line Manufacturer Usage Description 926 concerning the certificate subject. This extension contains a single 927 Uniform Resource Identifier (URI). Internationalized Resource 928 Identifiers must be represented as URI's in the way described in RFC 929 5280, section 7.4. 931 The choice of id-pe is based on guidance found in Section 4.2.2 of 932 [RFC5280]: 934 These extensions may be used to direct applications to on-line 935 information about the issuer or the subject. 937 The MUD URL is precisely that: online information about the 938 particular subject. 940 The new extension is identified as follows: 942 - The MUD URL extension id-pe-mud-url OBJECT IDENTIFER ::= { id-pe 943 TBD } 944 The extension returns a single value: 946 mudURLSyntax ::= IA5String - for use with MUD architecture. 948 The semantics of the URI are defined Section 5. 950 11. The Manufacturer Usage Description LLDP extension 952 The IEEE802.1AB Link Layer Discovery Protocol (LLDP) [IEEE8021AB] is 953 a one hop vendor-neutral link layer protocols used by end hosts 954 network devices for advertising their identity, capabilities, and 955 neighbors on an IEEE 802 local area network. Its Type-Length-Value 956 (TLV) design allows for 'vendor-specific' extensions to be defined. 957 IANA has a registered IEEE 802 organizationally unique identifier 958 (OUI) defined as documented in [RFC7042]. The MUD LLDP extension 959 uses a subtype defined in this document to carry the MUD URL. 961 The LLDP vendor specific frame has the following format: 963 +--------+--------+----------+---------+-------------- 964 |TLV Type| len | OUI |subtype | MUD URL 965 | =127 | |= 00 00 5E| = 1 | 966 |(7 bits)|(9 bits)|(3 octets)|(1 octet)|(1-256 octets) 967 +--------+--------+----------+---------+-------------- 969 where: 971 o TLV Type = 127 indicates a vendor-specific TLV 973 o len - indicates the TLV string length 975 o OUI = 00 00 5E is the organizationally unique identifier of IANA 977 o subtype = 1 (to be assigned by IANA for the MUD URL) 979 o MUD URL - the length MUST NOT exceed 256 octets (consistent with 980 the DHCP option defined in Section 9) 982 The intent of this extension is to provide both a new device 983 classifier to the network as well as some recommended configuration 984 to the routers that implement policy. However, it is entirely the 985 purview of the network system as managed by the network administrator 986 to decide what to do with this information. The key function of this 987 extension is simply to identify the type of device to the network in 988 a structured way such that the policy can be easily found with 989 existing toolsets. 991 Hosts, routers, or other network devices that implement this option 992 are intended to have at most one MUD URL associated with them, so 993 they may transmit at most one MUD URL value. 995 Hosts, routers, or other network devices that implement this option 996 may ignore these options or take action based on receipt of these 997 options. For example they may fill in information in the respective 998 extensions of the LLDP Management Information Base (LLDP MIB). LLDP 999 operates in a one-way direction. LLDPDUs are not exchanged as 1000 information requests by one device and response sent by another 1001 device. The other devices do not acknowledge LLDP information 1002 received from a device. No specific network behavior is guaranteed. 1003 When a device consumes this extension, it may either forward the URL 1004 and relevant remote device information to a network management 1005 system, or it will retrieve the usage description by resolving the 1006 URL. 1008 12. Creating and Processing of Signed MUD Files 1010 Because MUD files contain information that may be used to configure 1011 network access lists, they are sensitive. To insure that they have 1012 not been tampered with, it is important that they be signed. We make 1013 use of DER-encoded Cryptographic Message Syntax (CMS) [RFC5652] for 1014 this purpose. 1016 12.1. Creating a MUD file signature 1018 A MUD file MUST be signed using CMS as an opaque binary object. In 1019 order to make successful verification more likely, intermediate 1020 certificates SHOULD be included. If the device that is being 1021 described supports IEEE 802.1AR, its manufacturer certificate and the 1022 certificate in the MUD file MUST share a common trust anchor in order 1023 to insure that manufacturer of the device is also the provider of the 1024 MUD file. The signature is stored at the same location as the MUD 1025 URL but with the suffix of ".p7s". Signatures are transferred using 1026 content-type "Application/pkcs7-signature". 1028 For example: 1030 % openssl cms -sign -signer mancertfile -inkey mankey \ 1031 -in mudfile -binary -outform DER - \ 1032 -certfile intermediatecert -out mudfile.p7s 1034 Note: A MUD file may need to be resigned if the signature expires. 1036 12.2. Verifying a MUD file signature 1038 Prior to retrieving a MUD file the MUD controller SHOULD retrieve the 1039 MUD signature file using the MUD URL with a suffix of ".p7s". For 1040 example, if the MUD URL is "https://example.com/.well-known/v1/ 1041 modela", the MUD signature URL will be "https://example.com/.well- 1042 known/v1/modela.p7s". 1044 Upon retrieving a MUD file, a MUD controller MUST validate the 1045 signature of the file before continuing with further processing. A 1046 MUD controller SHOULD produce an error and it MUST cease all 1047 processing of that file if the signature cannot be validated. If the 1048 MUD controller has received the MUD URL via IEEE 802.1AR containing 1049 an IDevID (a manufacturer certificate), it MUST further confirm that 1050 the manufacturer certificate and that of the MUD file share a common 1051 trust anchor. 1053 For Example: 1055 % openssl cms -verify -in mudfile.p7s -inform DER -content mudfile 1057 Note the additional step of verifying the common trust root. 1059 13. Extensibility 1061 One of our design goals is to see that MUD files are able to be 1062 understood by as broad a cross-section of systems as is possible. 1063 Coupled with the fact that we have also chosen to leverage existing 1064 mechanisms, we are left with no ability to negotiate extensions and a 1065 limited desire for those extensions in any event. A such, a two-tier 1066 extensibility framework is employed, as follows: 1068 1. At a coarse grain, a protocol version is included in a MUD URL. 1069 This memo specifies MUD version 1. Any and all changes are 1070 entertained when this version is bumped. Transition approaches 1071 between versions would be a matter for discussion in future 1072 versions. 1074 2. At a finer grain, only extensions that would not incur additional 1075 risk to the device are permitted. Specifically, augmenting of 1076 the meta-information container is permitted with the 1077 understanding that such additions may be ignored. In addition, 1078 augmentation of the ACL model is permitted so long as it remains 1079 safe for a given ACE to be ignored by the MUD Controller or the 1080 network elements it configures. Most specifically, is is not 1081 permitted to include as an augmentation that modifies "deny" 1082 behavior without bumping the version. Furthermore, 1083 implementations that are not able to parse a component of the ACE 1084 array MUST ignore the entire array entry (e.g., not the entire 1085 array) and MAY ignore the entire MUD file. 1087 14. Security Considerations 1089 Based on the means a URL is procured, a device may be able to lie 1090 about what it is, thus gaining additional network access. There are 1091 several means to limit risk in this case. The most obvious is to 1092 only believe devices that make use of certificate-based 1093 authentication such as IEEE 802.1AR certificates. When those 1094 certificates are not present, devices claiming to be of a certain 1095 manufacturer SHOULD NOT be included in that manufacturer grouping 1096 without additional validation of some form. This will occur when it 1097 makes use of primitives such as "manufacturer" for the purpose of 1098 accessing devices of a particular type. 1100 Network management systems SHOULD NOT deploy a usage description for 1101 a device with the same MAC address that has indicated a change of 1102 authority without some additional validation (such as review of the 1103 class). New devices that present some form of unauthenticated MUD 1104 URL SHOULD be validated by some external means when they would be 1105 otherwise be given increased network access. 1107 It may be possible for a rogue manufacturer to inappropriately 1108 exercise the MUD file parser, in order to exploit a vulnerability. 1109 There are three recommended approaches to address this threat. The 1110 first is to validate the signature of the MUD file. The second is to 1111 have a system do a primary scan of the file to ensure that it is both 1112 parseable and believable at some level. MUD files will likely be 1113 relatively small, to start with. The number of ACEs used by any 1114 given device should be relatively small as well. Second, it may be 1115 useful to limit retrieval of MUD URLs to only those sites that are 1116 known to have decent web reputations. 1118 Use of a URL necessitates the use of domain names. If a domain name 1119 changes ownership, the new owner of that domain may be able to 1120 provide MUD files that MUD controllers would consider valid. There 1121 are a few approaches that can mitigate this attack. First, MUD file 1122 servers SHOULD cache certificates used by the MUD file server. When 1123 a new certificate is retrieved for whatever reason, the MUD 1124 controller should check to see if ownership of the domain has 1125 changed. A fair programmatic approximation of this is when the name 1126 servers for the domain have changed. If the actual MUD file has 1127 changed, the controller MAY check the WHOIS database to see if 1128 registration ownership of a domain has changed. If a change has 1129 occured, or if for some reason it is not possible to determine 1130 whether ownership has changed, further review may be warranted. 1131 Note, this remediation does not take into account the case of a 1132 device that was produced long ago and only recently fielded, or the 1133 case where a new MUD controller has been installed. 1135 15. IANA Considerations 1137 15.1. DHCPv4 and DHCPv6 Options 1139 IANA is requested to allocated the DHCPv4 and v6 options as specified 1140 in Section 9. 1142 15.2. PKIX Extensions 1144 The IANA is requested to assign a value for id-pe-mud-uri in the "SMI 1145 Security for PKIX Certificate Extension" Registry. Its use is 1146 specified in Section 10. 1148 15.3. Well Known URI Suffix 1150 The IANA is requested to register the URL suffix of "mud" as follows: 1152 o URI Suffix: "mud" o Specification documents: this document o 1153 Related information: n/a 1155 15.4. MIME Media-type Registration for MUD files 1157 The following media-type is defined for transfer of MUD file: 1159 o Type name: application 1160 o Subtype name: mud+json 1161 o Required parameters: n/a 1162 o Optional parameters: n/a 1163 o Encoding considerations: 8bit; application/mud+json values 1164 are represented as a JSON object; UTF-8 encoding SHOULD be 1165 employed. 1166 o Security considerations: See {{secon}} of this document. 1167 o Interoperability considerations: n/a 1168 o Published specification: this document 1169 o Applications that use this media type: MUD controllers as 1170 specified by this document. 1171 o Fragment identifier considerations: n/a 1172 o Additional information: 1174 Magic number(s): n/a 1175 File extension(s): n/a 1176 Macintosh file type code(s): n/a 1178 o Person & email address to contact for further information: 1179 Eliot Lear , Ralph Droms 1180 o Intended usage: COMMON 1181 o Restrictions on usage: none 1183 o Author: Eliot Lear , Ralph Droms 1184 o Change controller: IESG 1185 o Provisional registration? (standards tree only): No. 1187 15.5. LLDP IANA TLV Subtype Registry 1189 IANA is requested to create a new registry for IANA Link Layer 1190 Discovery Protocol (LLDP) TLV subtype values. The recommended policy 1191 for this registry is Expert Review. The maximum number of entries in 1192 the registry is 256. 1194 IANA is required to populate the initial registry with the value: 1196 LLDP subtype value = 1 1198 Description = the Manufacturer Usage Description (MUD) Uniform 1199 Resource Locator (URL) 1201 Reference = < this document > 1203 16. Acknowledgments 1205 The authors would like to thank Einar Nilsen-Nygaard, Bernie Volz, 1206 Tom Gindin, Brian Weis, Sandeep Kumar, Thorsten Dahm, John Bashinski, 1207 Steve Rich, Jim Bieda, and Dan Wing for their valuable advice and 1208 reviews. The remaining errors in this work are entirely the 1209 responsibility of the author. 1211 17. References 1213 17.1. Normative References 1215 [I-D.ietf-anima-bootstrapping-keyinfra] 1216 Pritikin, M., Richardson, M., Behringer, M., and S. 1217 Bjarnason, "Bootstrapping Remote Secure Key 1218 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 1219 keyinfra-03 (work in progress), June 2016. 1221 [I-D.ietf-netmod-acl-model] 1222 Bogdanovic, D., Koushik, K., Huang, L., and D. Blair, 1223 "Network Access Control List (ACL) YANG Data Model", 1224 draft-ietf-netmod-acl-model-08 (work in progress), July 1225 2016. 1227 [IEEE8021AB] 1228 Institute for Electrical and Electronics Engineers, "IEEE 1229 Standard for Local and Metropolitan Area Networks-- 1230 Station and Media Access Control Connectivity Discovery", 1231 n.d.. 1233 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1234 Requirement Levels", BCP 14, RFC 2119, 1235 DOI 10.17487/RFC2119, March 1997, 1236 . 1238 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1239 RFC 2131, DOI 10.17487/RFC2131, March 1997, 1240 . 1242 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1243 DOI 10.17487/RFC2818, May 2000, 1244 . 1246 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 1247 C., and M. Carney, "Dynamic Host Configuration Protocol 1248 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 1249 2003, . 1251 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1252 Resource Identifier (URI): Generic Syntax", STD 66, 1253 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1254 . 1256 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1257 Housley, R., and W. Polk, "Internet X.509 Public Key 1258 Infrastructure Certificate and Certificate Revocation List 1259 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1260 . 1262 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1263 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1264 . 1266 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1267 the Network Configuration Protocol (NETCONF)", RFC 6020, 1268 DOI 10.17487/RFC6020, October 2010, 1269 . 1271 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 1272 Capabilities in Customer Premises Equipment (CPE) for 1273 Providing Residential IPv6 Internet Service", RFC 6092, 1274 DOI 10.17487/RFC6092, January 2011, 1275 . 1277 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1278 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1279 . 1281 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 1282 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 1283 BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, 1284 . 1286 [RFC7299] Housley, R., "Object Identifier Registry for the PKIX 1287 Working Group", RFC 7299, DOI 10.17487/RFC7299, July 2014, 1288 . 1290 17.2. Informative References 1292 [FW95] Chapman, D. and E. Zwicky, "Building Internet Firewalls", 1293 January 1995. 1295 [IEEE8021AR] 1296 Institute for Electrical and Electronics Engineers, 1297 "Secure Device Identity", 1998. 1299 [ISO.8601.1988] 1300 International Organization for Standardization, "Data 1301 elements and interchange formats - Information interchange 1302 - Representation of dates and times", ISO Standard 8601, 1303 June 1988. 1305 [RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic 1306 Technology and the Internet", BCP 200, RFC 1984, 1307 DOI 10.17487/RFC1984, August 1996, 1308 . 1310 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1311 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 1312 . 1314 [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and 1315 IETF Protocol and Documentation Usage for IEEE 802 1316 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, 1317 October 2013, . 1319 [RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, 1320 "Architectural Considerations in Smart Object Networking", 1321 RFC 7452, DOI 10.17487/RFC7452, March 2015, 1322 . 1324 [RFC7488] Boucadair, M., Penno, R., Wing, D., Patil, P., and T. 1325 Reddy, "Port Control Protocol (PCP) Server Selection", 1326 RFC 7488, DOI 10.17487/RFC7488, March 2015, 1327 . 1329 Appendix A. Changes from Earlier Versions 1331 RFC Editor to remove this section prior to publication. 1333 Draft -03 to -04: * add LLDP extension. * add Dan Romascanu as co- 1334 author. 1336 Draft -02 to -03: * incorporate domain name model. * discuss 1337 extensibility. * leave placeholder for LLDP TLV. 1339 Draft -01 to -02: 1341 o XML->JSON 1343 o Remove device versioning information from URL 1345 o Add PKIX and DHCP options 1346 o Add Content-type information 1348 o Clean up IANA considerations to match registration templates 1350 o Ralph Droms carried over as author from DHCP option. 1352 o Signing information 1354 o Expanded Security Considerations 1356 o Add directionality for both packets and flows. 1358 o add previous-mud-file 1360 Draft -00 to -01: 1362 o Add MASA server element 1364 Authors' Addresses 1366 Eliot Lear 1367 Cisco Systems 1368 Richtistrasse 7 1369 Wallisellen CH-8304 1370 Switzerland 1372 Phone: +41 44 878 9200 1373 Email: lear@cisco.com 1375 Ralph Droms 1376 Cisco Systems 1377 55 Cambridge Parkway 1378 Cambridge 1057 1379 United States 1381 Phone: +1 617 621 1904 1382 Email: rdroms@cisco.com 1384 Dan Romascanu 1385 Avaya 1386 26, HaRokhmim Str., Bldg. D 1387 Holon 5885849 1388 Israel 1390 Phone: +972-3-645-8414 1391 Email: dromasca@avaya.com