idnits 2.17.1 draft-richardson-shg-mud-quarantined-access-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 36 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 02, 2020) is 1268 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) == Missing Reference: 'THIS DOCUMENT' is mentioned on line 171, but not defined == Unused Reference: 'RFC8520' is defined on line 182, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 opsawg Working Group (if adopted) M. Richardson 3 Internet-Draft Sandelman Software Works 4 Intended status: Standards Track M. Ranganathan 5 Expires: May 6, 2021 NIST 6 November 02, 2020 8 Manufacturer Usage Description for quarantined access to firmware 9 draft-richardson-shg-mud-quarantined-access-02 11 Abstract 13 The Manufacturer Usage Description is a tool to describe the limited 14 access that a single function device such as an Internet of Things 15 device might need. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on May 6, 2021. 34 Copyright Notice 36 Copyright (c) 2020 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 53 3. MUD file extensions . . . . . . . . . . . . . . . . . . . . . 2 54 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 2 55 3.2. YANG FILE . . . . . . . . . . . . . . . . . . . . . . . . 2 56 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 57 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 4 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 59 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 60 8. Normative References . . . . . . . . . . . . . . . . . . . . 4 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 63 1. Introduction 65 The document details an extension to the Manufacturer Usage 66 Description (MUD) mechanism to be able to mark one or more ACLs as 67 being enabled even though the device has been quaranteed. 69 2. Requirements Language 71 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 72 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 73 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 74 [RFC2119] and indicate requirement levels for compliant STuPiD 75 implementations. 77 3. MUD file extensions 79 3.1. Tree Diagram 81 module: cira-shg-mud augment /m:mud: +-rw quaranteed-device-policy 82 +-rw enabled-ace-names* [ace-name] +-rw ace-name -> 83 /acl:acls/acl/aces/ace/name 85 3.2. YANG FILE 87 file "ietf-mud-quarantine@2019-12-27.yang" 88 module ietf-mud-quarantine { 89 yang-version 1.1; 91 namespace 92 "urn:ietf:params:xml:ns:yang:ietf-mud-quarantine"; 93 prefix "q"; 95 import ietf-mud { 96 prefix m; 97 description "This module defines an extension to MUD to mark entries as being needed during quarantine"; 98 reference "RFC YYYY: MUD YANG"; 99 } 101 organization "IETF OPSAWG Working group."; 103 contact 104 "WG Web: 105 WG List: opsawg@ietf.org 106 Author: Michael Richardson 107 109 Author: M. Ranganathan 110 "; 112 description 113 "This module extends the RFC8520 MUD format to two 114 facilities: definition of an Access Control List appropriate 115 to enable device upgrade only, and provide for a history of 116 modifications by third-parties to the MUD file"; 118 revision "2019-12-27" { 119 description 120 "Initial version"; 121 reference 122 "RFC XXXX: MUD profile with quarantined access"; 123 } 125 augment "/m:mud" { 126 description 127 "Adds leaf nodes for marking ACLs that should be enabled during quarantine"; 129 container quaranteed-device-policy { 130 description 131 "The policies that should be enforced on traffic 132 coming from the device when it is under quarantine. 133 These policies are usually a subset of operational policies 134 and are intended to permit firmware updates only. 135 They are intended to keep the device safe (and the network safe 136 from the device) when the device is suspected of being 137 out-of-date, but still considered sufficiently intact to be 138 able to do a firmware update"; 139 list enabled-ace-names { 140 key ace-name; 141 leaf ace-name { 142 type leafref { 143 path "/acl:acls/acl:acl/acl:aces/acl:ace/acl:name"; 144 } 146 } 147 } 148 } 149 } 150 } 152 154 4. Security Considerations 156 TBD 158 5. Privacy Considerations 160 TBD 162 6. IANA Considerations 164 The following YANG modules need to be registered in the "YANG Module 165 Names" registry: 167 Name: ietf-mud 168 URN: urn:ietf:params:xml:ns:yang:ietf-mud 169 Prefix: ietf-mud 170 Registrant contact: The IESG 171 Reference: [THIS DOCUMENT] 173 7. Acknowledgements 175 8. Normative References 177 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 178 Requirement Levels", BCP 14, RFC 2119, 179 DOI 10.17487/RFC2119, March 1997, 180 . 182 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 183 Description Specification", RFC 8520, 184 DOI 10.17487/RFC8520, March 2019, 185 . 187 Authors' Addresses 189 Michael Richardson 190 Sandelman Software Works 192 Email: mcr+ietf@sandelman.ca 193 M. Ranganathan 194 NIST 196 Email: mranga@gmail.com