idnits 2.17.1 draft-ietf-netmod-factory-default-15.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 (April 25, 2020) is 1434 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'RFC 8525' is mentioned on line 212, but not defined == Missing Reference: 'RFC8573' is mentioned on line 483, but not defined == Unused Reference: 'RFC8525' is defined on line 409, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-anima-bootstrapping-keyinfra' is defined on line 416, but no explicit reference was found in the text == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-41 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETMOD Working Group Q. Wu 3 Internet-Draft Huawei 4 Intended status: Standards Track B. Lengyel 5 Expires: October 27, 2020 Ericsson Hungary 6 Y. Niu 7 Huawei 8 April 25, 2020 10 A YANG Data Model for Factory Default Settings 11 draft-ietf-netmod-factory-default-15 13 Abstract 15 This document defines a YANG data model with the "factory-reset" RPC 16 to allow clients to reset a server back to its factory default 17 condition. It also defines an optional "factory-default" datastore 18 to allow clients to read the factory default configuration for the 19 device. 21 The YANG data model in this document conforms to the Network 22 Management Datastore Architecture (NMDA) defined in RFC 8342. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on October 27, 2020. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Factory-Reset RPC . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Factory-Default Datastore . . . . . . . . . . . . . . . . . . 4 62 4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 66 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 69 9.2. Informative References . . . . . . . . . . . . . . . . . 9 70 Appendix A. Changes between revisions . . . . . . . . . . . . . 10 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 73 1. Introduction 75 This document defines a YANG data model and associated mechanism to 76 reset a server to its factory default content. This mechanism may be 77 used, e.g., when the existing configuration has major errors so re- 78 starting the configuration process from scratch is the best option. 80 A "factory-reset" RPC is defined within the YANG data model. When 81 resetting a device, all previous configuration settings will be lost 82 and replaced by the factory default content. 84 In addition, an optional "factory-default" read-only datastore is 85 defined within the YANG data model, that contains the data to replace 86 the contents of implemented read-write conventional configuration 87 datastores at reset. This datastore can also be used in the operation. 90 The YANG data model in this document conforms to the Network 91 Management Datastore Architecture defined in [RFC8342]. 93 1.1. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 97 "OPTIONAL" in this document are to be interpreted as described in BCP 98 14 [RFC2119] [RFC8174] when, and only when, they appear in all 99 capitals, as shown here. 101 The following terms are defined in [RFC8342] [RFC7950] and are not 102 redefined here: 104 o server 106 o startup configuration datastore 108 o candidate configuration datastore 110 o running configuration datastore 112 o intended configuration datastore 114 o operational state datastore 116 o conventional configuration datastore 118 o datastore schema 120 o RPC operation 122 The following terms are defined in this document as follows: 124 o factory-default datastore: A read-only configuration datastore 125 holding a pre-set initial configuration that is used to initialize 126 the configuration of a server. This datastore is referred to as 127 "". 129 2. Factory-Reset RPC 131 A new "factory-reset" remote procedure call (RPC) is introduced. 132 Upon receiving the RPC: 134 o All supported conventional read-write configuration datastores 135 (i.e. , , and ) are reset to the 136 contents of . 138 o Read-only datastores receive their content from other datastores 139 (e.g., gets its content from ). 141 o All data in any dynamic configuration datastores MUST be 142 discarded. 144 o The contents of the datastore MUST reflect the 145 operational state of the device after applying the factory default 146 configuration. 148 In addition, the "factory-reset" RPC MUST restore non-volatile 149 storage to factory condition. Depending on the system, this may 150 entail deleting dynamically generated files, such as those containing 151 keys (e.g., /etc/ssl/private), certificates (e.g., /etc/ssl), logs 152 (e.g., /var/log), and temporary files (e.g., /tmp/*). Any other 153 cryptographic keys that are part of the factory-installed image will 154 be retained (such as an IDevID certificate) [I-D.ietf-anima- 155 bootstrapping-keyinfra]. When this process includes security- 156 sensitive data such as cryptographic keys or passwords, it is 157 RECOMMENDED to perform the deletion in a manner as thorough as 158 possible (e.g., overwriting the physical storage medium with zeros 159 and/or random bits for repurpose or end of life (EoL) disposal) to 160 reduce the risk of the sensitive material being recoverable. The 161 "factory-reset" RPC MAY also be used to trigger some other resetting 162 tasks such as restarting the node or some of the software processes. 164 Note that operators should be aware that since all read-write 165 datastores are immediately reset to factory default, the device may 166 become unreachable as a host on the network. It is important to 167 understand how a given vendor's device will behave after the RPC is 168 executed. Implementors SHOULD reboot the device and get it properly 169 configured or otherwise restart processes needed to bootstrap it. 171 3. Factory-Default Datastore 173 Following the guidelines for defining Datastores in the appendix A of 174 [RFC8342], this document introduces a new optional datastore resource 175 named "factory-default" that represents a pre-set initial 176 configuration that can be used to initialize the configuration of a 177 server. A device MAY implement the "factory-reset" RPC without 178 implementing the "factory-default" datastore, which would only 179 eliminate the ability to programmatically determine the factory 180 default configuration. 182 o Name: "factory-default" 184 o YANG modules: The factory default datastore schema MUST either be 185 the same as the conventional configuration datastores, or a subset 186 of the datastore schema for the conventional configuration 187 datastores. 189 o YANG nodes: all "config true" data nodes 191 o Management operations: The content of the datastore is set by the 192 server in an implementation dependent manner. The content can not 193 be changed by management operations via NETCONF, RESTCONF, the CLI 194 etc. unless specialized, dedicated operations are provided. The 195 datastore can be read using the standard NETCONF/RESTCONF protocol 196 operations. The "factory-reset" operation copies the factory 197 default content to and, if present, and/or 198 and then the content of these datastores is propagated 199 automatically to any other read only datastores, e.g., 200 and . 202 o Origin: This document does not define a new origin identity as it 203 does not interact with the datastore. 205 o Protocols: RESTCONF, NETCONF and other management protocol. 207 o Defining YANG module: "ietf-factory-default". 209 The contents of are defined by the device vendor 210 and MUST persist across device restarts. If supported, the factory- 211 default datastore MUST be included in the list of datastores in YANG 212 library [RFC 8525]. 214 4. YANG Module 216 This module uses the "datastore" identity [RFC8342], and the 217 "default-deny-all" extension statement from [RFC8341]. 219 file "ietf-factory-default@2019-11-27.yang" 220 module ietf-factory-default { 221 yang-version 1.1; 222 namespace "urn:ietf:params:xml:ns:yang:ietf-factory-default"; 223 prefix fd; 225 import ietf-datastores { 226 prefix ds; 227 reference 228 "RFC 8342: Network Management Datastore Architecture (NMDA)"; 229 } 230 import ietf-netconf-acm { 231 prefix nacm; 232 reference 233 "RFC8341: Network Configuration Access Control Model"; 234 } 236 organization 237 "IETF NETMOD (Network Modeling) Working Group"; 238 contact 239 "WG Web: 240 WG List: 242 Editor: Qin Wu 243 244 Editor: Balazs Lengyel 245 246 Editor: Ye Niu 247 "; 248 description 249 "This module provides functionality to reset a server to its 250 factory default configuration and, when supported, to discover 251 the factory default configuration contents independent of 252 resetting the server. 254 Copyright (c) 2020 IETF Trust and the persons identified as 255 authors of the code. All rights reserved. 257 Redistribution and use in source and binary forms, with or 258 without modification, is permitted pursuant to, and subject 259 to the license terms contained in, the Simplified BSD License 260 set forth in Section 4.c of the IETF Trust's Legal Provisions 261 Relating to IETF Documents 262 (http://trustee.ietf.org/license-info). 264 This version of this YANG module is part of RFC XXXX; 265 see the RFC itself for full legal notices."; 266 // RFC Ed.: update the date below with the date of RFC publication 267 // and remove this note. 268 // RFC Ed.: replace XXXX with actual RFC number and remove this 269 // note. 270 revision 2019-11-27 { 271 description 272 "Initial revision."; 273 reference 274 "RFC XXXX: Factory default Setting"; 275 } 277 feature factory-default-datastore { 278 description 279 "Indicates that the factory default configuration is 280 available as a datastore."; 281 } 283 rpc factory-reset { 284 nacm:default-deny-all; 285 description 286 "The server resets all datastores to their factory 287 default content and any non-volatile storage back to 288 factory condition, deleting all dynamically generated 289 files, including those containing keys, certificates, 290 logs, and other temporary files. 292 Depending on the factory default configuration, after 293 being reset, the device may become unreachable on the 294 network."; 295 } 297 identity factory-default { 298 if-feature "factory-default-datastore"; 299 base ds:datastore; 300 description 301 "This read-only datastore contains the factory default 302 configuration for the device that will be used to replace 303 the contents of the read-write conventional configuration 304 datastores during a 'factory-reset' RPC operation."; 305 } 306 } 307 309 5. IANA Considerations 311 This document registers one URI in the IETF XML Registry [RFC3688]. 312 The following registration has been made: 314 URI: urn:ietf:params:xml:ns:yang:ietf-factory-default 315 Registrant Contact: The IESG. 316 XML: N/A, the requested URI is an XML namespace. 318 This document registers one YANG module in the YANG Module Names 319 Registry [RFC6020]. The following registration has been made: 321 name: ietf-factory-default 322 namespace: urn:ietf:params:xml:ns:yang:ietf-factory-default 323 prefix: fd 324 RFC: xxxx 326 6. Security Considerations 328 The YANG module defined in this document extends the base operations 329 for NETCONF [RFC6241] and RESTCONF [RFC8040]. The lowest NETCONF 330 layer is the secure transport layer, and the mandatory-to-implement 331 secure transport is Secure Shell (SSH) [RFC6242]. The lowest 332 RESTCONF layer is HTTPS, and the mandatory-to-implement secure 333 transport is TLS [RFC8446]. 335 Access to the "factory-reset" RPC operation and factory default 336 values of all configuration data nodes within "factory-default" 337 datastore is considered sensitive and therefore has been restricted 338 using the "default-deny-all" access control defined in [RFC8341]. 340 The "factory-reset" RPC can prevent any further management of the 341 device when the server is reset back to its factory default 342 condition,e.g., the session and client config are included in the 343 factory default contents or treated as dynamic files on the 344 nonvoliatile storage and overwritten by the the "factory-reset" RPC. 346 The operational disruption caused by setting the config to factory 347 default contents or lacking appropriate security control on factory 348 default configuration varies greatly depending on the implementation 349 and current config. 351 The non-volatile storage is expected to be wiped clean and reset back 352 to the factory default state, but there is no guarantee that the data 353 is wiped according to any particular data cleansing standard, and the 354 owner of the device MUST NOT rely on any sensitive data (e.g., 355 private keys) being forensically unrecoverable from the device's non- 356 volatile storage after a factory-reset RPC has been invoked. 358 7. Acknowledgements 360 Thanks to Juergen Schoenwaelder, Ladislav Lhotka, Alex Campbell, Joe 361 Clarke, Robert Wilton, Kent Watsen, Joel Jaeggli, Lou Berger, Andy 362 Bierman, Susan Hares, Benjamin Kaduk, Stephen Kent, Stewart Bryant, 363 Eric Vyncke, Murray Kucherawy, Roman Danyliw, Tony Przygienda, John 364 Heasley for reviewing this draft and providing important input to 365 this document. 367 8. Contributors 369 Rohit R Ranade 370 Huawei 371 Email: rohitrranade@huawei.com 373 9. References 375 9.1. Normative References 377 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 378 Requirement Levels", BCP 14, RFC 2119, 379 DOI 10.17487/RFC2119, March 1997, 380 . 382 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 383 DOI 10.17487/RFC3688, January 2004, 384 . 386 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 387 the Network Configuration Protocol (NETCONF)", RFC 6020, 388 DOI 10.17487/RFC6020, October 2010, 389 . 391 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 392 RFC 7950, DOI 10.17487/RFC7950, August 2016, 393 . 395 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 396 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 397 May 2017, . 399 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 400 Access Control Model", STD 91, RFC 8341, 401 DOI 10.17487/RFC8341, March 2018, 402 . 404 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 405 and R. Wilton, "Network Management Datastore Architecture 406 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 407 . 409 [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 410 and R. Wilton, "YANG Library", RFC 8525, 411 DOI 10.17487/RFC8525, March 2019, 412 . 414 9.2. Informative References 416 [I-D.ietf-anima-bootstrapping-keyinfra] 417 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 418 and K. Watsen, "Bootstrapping Remote Secure Key 419 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 420 keyinfra-41 (work in progress), April 2020. 422 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 423 and A. Bierman, Ed., "Network Configuration Protocol 424 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 425 . 427 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 428 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 429 . 431 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 432 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 433 . 435 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 436 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 437 . 439 Appendix A. Changes between revisions 441 Editorial Note (To be removed by RFC Editor) 443 v14 -15 445 o Address comments raised in IESG review. 447 v13 - 14 449 o Address additional issues raised during AD review. 451 v12 - 13 453 o Address issues raised during AD review. 455 v11 - 12 457 o Fix IDnits and reference issues from Shepherd review. 459 v10 - 11 461 o Incorporate additional Shepherd review's comments. 463 v09 - 10 465 o Incorporate Shepherd review's comments. 467 v08 - 09 468 o Provide some guideline for operators and implementor who implement 469 factory defaut method. 471 v07 - 08 473 o Provide clarification and recommendation on the relationship 474 between factory-reset RPC and reboot. 476 o Nits fixed based on YANG Doctor Review. 478 v06 - 07 480 o Remove Factory default content specification; 482 o Remove reference to YANG instance data file format and zero touch 483 provision [RFC8573]; 485 o Remove copy-config operation extension on factory-default 486 datastore 488 v05 - 06 490 o Additional text to enhance security section. 492 o Add nacm:default-deny-all on "factory-reset" RPC. 494 o A few clarification on Factory default content specification. 496 v03 - 04 498 o Additional text to clarify factory-reset RPC usage. 500 v02 - 03 502 o Update security consideration section. 504 v01 - v02 506 o Address security issue in the security consideration section. 508 o Remove an extension to the NETCONF operation which 509 allows it to operate on the factory-default datastore. 511 o Add an extension to the NETCONF operation which 512 allows it to operate on the factory-default datastore. 514 v00 - v01 515 o Change YANG server into server defined in NMDA architecture based 516 on discussion. 518 o Allow reset the content of all read-write configuraton datastores 519 to its factory default content except . 521 o Add clarification text on factory-reset protocol operation 522 behavior. 524 v03 - v00 526 o Change draft name from draft-wu to draft-ietf-netmod-factory- 527 default-00 without content changes. 529 v02 - v03 531 o Change reset-datastore RPC into factory-reset RPC to allow reset 532 the whole device with factory default content. 534 o Remove target datastore parameter from factory-reset RPC. 536 o Other editorial changes. 538 v01 - v02 540 o Add copy-config based on Rob's comment. 542 o Reference Update. 544 v03 - v00 - v01 546 o Changed name from draft-wu-netconf-restconf-factory-restore to 547 draft-wu-netmod-factory-default 549 o Removed copy-config ; reset-datastore is enough 551 v02 - v03 553 o Restructured 555 o Made new datastore optional 557 o Removed Netconf capability 559 o Listed Open issues 561 v01 - v02 562 o - 564 v00 - v01 566 o - 568 Authors' Addresses 570 Qin Wu 571 Huawei 572 101 Software Avenue, Yuhua District 573 Nanjing, Jiangsu 210012 574 China 576 Email: bill.wu@huawei.com 578 Balazs Lengyel 579 Ericsson Hungary 580 Magyar Tudosok korutja 11 581 1117 Budapest 582 Hungary 584 Phone: +36-70-330-7909 585 Email: balazs.lengyel@ericsson.com 587 Ye Niu 588 Huawei 590 Email: niuye@huawei.com