idnits 2.17.1 draft-kwatsen-netconf-server-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 258 has weird spacing: '...address ine...' == Line 277 has weird spacing: '...address ine...' == Line 314 has weird spacing: '...address ine...' == Line 323 has weird spacing: '...address ine...' == Line 342 has weird spacing: '...rw name str...' == (3 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 14, 2014) is 3724 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) ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) == Outdated reference: A later version (-08) exists of draft-ietf-netmod-snmp-cfg-03 == Outdated reference: A later version (-10) exists of draft-ietf-netconf-rfc5539bis-04 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF Working Group K. Watsen 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track J. Schoenwaelder 5 Expires: August 18, 2014 Jacobs University Bremen 6 February 14, 2014 8 A YANG Data Model for NETCONF Server Configuration 9 draft-kwatsen-netconf-server-01 11 Abstract 13 This draft defines a NETCONF server configuration data model. This 14 data model enables configuration of the NETCONF service itself, 15 including which transports it supports, what ports they listen on, 16 whether they support device-initiated connections, and associated 17 parameters. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 18, 2014. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Support all NETCONF Transports . . . . . . . . . . . . . 3 58 2.2. Align Transport-Specific Configurations . . . . . . . . . 4 59 2.3. Support Transport-Independent Configuration . . . . . . . 4 60 2.4. Support both Inbound and Outbound Connections . . . . . . 4 61 2.5. For Device-Initiated Outbound Connections . . . . . . . . 4 62 2.5.1. Support More than One Application . . . . . . . . . . 4 63 2.5.2. Support Applications Having More than One Server . . 4 64 2.5.3. Support a Reconnection Strategy . . . . . . . . . . . 5 65 2.5.4. Support both Persistent and Periodic Connections . . 5 66 2.5.5. Keep-Alives for Persistent Connections . . . . . . . 5 67 2.5.6. Customizations for Periodic Connections . . . . . . . 5 68 3. Data Model Overview . . . . . . . . . . . . . . . . . . . . . 6 69 3.1. The "listen" Grouping . . . . . . . . . . . . . . . . . . 6 70 3.2. The "call-home" Grouping . . . . . . . . . . . . . . . . 6 71 3.3. The SSH Subtree . . . . . . . . . . . . . . . . . . . . . 7 72 3.4. The TLS Subtree . . . . . . . . . . . . . . . . . . . . . 8 73 4. NETCONF Server YANG Module . . . . . . . . . . . . . . . . . 9 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 22 79 8.2. Informative References . . . . . . . . . . . . . . . . . 22 80 Appendix A. Example: SSH . . . . . . . . . . . . . . . . . . . . 22 81 Appendix B. Example: TLS . . . . . . . . . . . . . . . . . . . . 23 82 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 25 83 C.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 25 84 Appendix D. Open Issues . . . . . . . . . . . . . . . . . . . . 25 86 1. Introduction 87 This draft defines a NETCONF [RFC6241] server configuration data 88 model. This data model enables configuration of the NETCONF service 89 itself, including which transports it supports, what ports they 90 listen on, whether they support device-initiated connections, and 91 associated parameters. 93 1.1. Terminology 95 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC 2119 [RFC2119]. 99 1.2. Tree Diagrams 101 A simplified graphical representation of the data model is used in 102 this document. The meaning of the symbols in these diagrams is as 103 follows: 105 o Brackets "[" and "]" enclose list keys. 107 o Abbreviations before data node names: "rw" means configuration 108 (read-write) and "ro" state data (read-only). 110 o Symbols after data node names: "?" means an optional node, "!" 111 means a presence container, and "*" denotes a list and leaf-list. 113 o Parentheses enclose choice and case nodes, and case nodes are also 114 marked with a colon (":"). 116 2. Objectives 118 The primary purpose of this YANG module is to enable the 119 configuration of the NETCONF service on the device. This scope 120 includes both transport-independent and transport-specific 121 configuration parameters. 123 2.1. Support all NETCONF Transports 125 The YANG module should support all current NETCONF transports, namely 126 NETCONF over SSH [RFC6242] and NETCONF over TLS 127 [I-D.ietf-netconf-rfc5539bis], and be extensible to support future 128 transports as necessary. 130 Since implementations may not support all transports, the module 131 should use YANG "feature" statements so that each implementation can 132 advertise which transports it actually supports. 134 2.2. Align Transport-Specific Configurations 136 While each transport is unique in its protocol and may have some 137 distinct configurations, there remains a significant overlap between 138 them. Thus the YANG module should use "grouping" statements so that 139 the common aspects can be configured similarly. 141 2.3. Support Transport-Independent Configuration 143 Since some NETCONF server configurations may be independent of any 144 transport, the module should define a location for these transport- 145 independent values to be configured. 147 2.4. Support both Inbound and Outbound Connections 149 Historically, NETCONF only supported the device opening a port to 150 listen for inbound client connections. However, the NETCONF working 151 group is actively defining support for devices to initiate outbound 152 connections (e.g., "call home"). Thus, the module should enable the 153 configuration of both inbound and outbound connections. 155 Since implementations may not support both inbound and outbound 156 connections, the module should use YANG "feature" statements so that 157 each implementation can advertise the type of connections it actually 158 supports. 160 2.5. For Device-Initiated Outbound Connections 162 The following objectives only pertain to support for device-initiated 163 outbound connections. 165 2.5.1. Support More than One Application 167 A device may be managed by more than one northbound applications. 168 For instance, a deployment may have one application for provisioning 169 and another for fault monitoring. Therefore, when it is desired for 170 a device to initiate management connections, it should be able to do 171 so for more than one application. 173 2.5.2. Support Applications Having More than One Server 175 An application managing a device may implement a high-availability 176 strategy employing a multiplicity of active and/or passive servers. 177 Therefore, when it is desired for a device to initiate connections to 178 the application, it should be able to connect to any of the 179 applications servers. 181 2.5.3. Support a Reconnection Strategy 183 Assuming an application has more than one server, then it becomes 184 necessary to understand how a device should reconnect to the 185 application should it lose its connection to one of the application's 186 servers. Of primary interest is if the device should start with 187 first server defined in a user-ordered list of servers or with the 188 last server it was connected to. Secondary settings might specify 189 the frequency of attempts and number of attempts per server. 190 Therefore, a reconnection strategy should be configurable. 192 Note that the reconnection strategy should apply to both persistent 193 and periodic connections. How it applies to periodic connections 194 becomes clear when considering that a periodic "connection" is a 195 logical connection to a single server. That is, the periods of 196 unconnectedness are intentional as opposed to due to external 197 reasons. A periodic "connection" should always reconnect to the same 198 server until it is no longer able to, at which time the reconnection 199 strategy guides the device how to get connected to another server. 201 2.5.4. Support both Persistent and Periodic Connections 203 Applications may vary greatly on how frequently they need to interact 204 with a device, how responsive interactions with devices need to be, 205 and how many simultaneous connections they can support. Some 206 applications may need a persistent connection to devices to optimize 207 real-time interactions, while others are satisfied with periodic 208 interactions and reduced resources required. Therefore, when it is 209 necessary for devices to initiate connections, the type of connection 210 desired should be configured. 212 2.5.5. Keep-Alives for Persistent Connections 214 If a persistent connection is desired, it is the responsibility of 215 the connection-initiator to actively test the connection for 216 aliveness. However, there is a balance between the frequency of the 217 tests and the networking overhead they generate. The appropriate 218 balance can only be determined by the application, based on its 219 interaction requirements. Therefore, for persistent connections, 220 keep-alive settings should be configurable on a per-application 221 basis. 223 2.5.6. Customizations for Periodic Connections 225 If a periodic connection is desired, it is necessary for the device 226 to know how often it should connect. This delay essentially 227 determines how long the application might have to wait to send data 228 to the device. Note, this setting does not constrain how often the 229 device must wait to send data to the application, as the device 230 should immediately connect to the application whenever it has data to 231 send to it. 233 A common communication pattern is that one data transmission is many 234 times closely followed by another. For instance, if the device needs 235 to send a notification message, there's a high probability that it 236 will send another shortly thereafter. Likewise, the application may 237 have a sequence of pending messages to send. Thus, it should be 238 possible for a device to hold a connection open until some amount of 239 time of no data being transmitted as transpired. 241 3. Data Model Overview 243 3.1. The "listen" Grouping 245 To enable transports to configure listening on one or more ports in a 246 common way, this grouping is defined. Being a grouping enables each 247 transport-specific data-model to augment it as needed (e.g., to 248 specify a default for the "port" values), as well as enable 249 implementations to advertise support for listening for inbound 250 connections using a YANG feature. 252 +--rw listen 253 +--rw (one-or-many)? 254 +--:(one-port) 255 | +--rw port? inet:port-number 256 +--:(many-ports) 257 +--rw interface* [address] 258 +--rw address inet:ip-address 259 +--rw port? inet:port-number 261 3.2. The "call-home" Grouping 263 To enable transports to configure initiating connections to remote 264 applications in a common way, this grouping is defined. Being a 265 grouping enables each transport-specific data-model to augment it as 266 needed (e.g., to specify a default port value, lists of algorithms to 267 advertise, etc.), as well as enable implementations to advertise 268 support for listening for inbound connections using a YANG feature. 270 +--rw call-home 271 +--rw applications 272 +--rw application* [name] 273 +--rw name string 274 +--rw description? string 275 +--rw servers 276 | +--rw server* [address] 277 | +--rw address inet:host 278 | +--rw port? inet:port-number 279 +--rw connection-type 280 | +--rw (connection-type)? 281 | +--:(persistent-connection) 282 | | +--rw persistent 283 | | +--rw keep-alives 284 | | +--rw interval-secs? uint8 285 | | +--rw count-max? uint8 286 | +--:(periodic-connection) 287 | +--rw periodic 288 | +--rw timeout-mins? uint8 289 | +--rw linger-secs? uint8 290 +--rw reconnect-strategy 291 +--rw start-with? enumeration 292 +--rw interval-secs? uint8 293 +--rw count-max? uint8 295 3.3. The SSH Subtree 297 The SSH subtree uses both the "listen" and "call-home" groupings 298 mentioned above. Support for the SSH transport is advertised by the 299 "ssh" feature, while listening for clients and calling home are 300 advertised by the "inbound-ssh" and "outbound-ssh" features 301 respectively. The SSH subtree augments the "call-home" grouping by 302 adding a "host-keys" container. Also, though not visible in the tree 303 output below, this subtree refines all the port values with a 304 suitable default (i.e., 830). 306 +--rw netconf 307 +--rw ssh {ssh}? 308 +--rw listen {inbound-ssh}? 309 | +--rw (one-or-many)? 310 | +--:(one-port) 311 | | +--rw port? inet:port-number 312 | +--:(many-ports) 313 | +--rw interface* [address] 314 | +--rw address inet:ip-address 315 | +--rw port? inet:port-number 316 +--rw call-home {outbound-ssh}? 317 +--rw applications 318 +--rw application* [name] 319 +--rw name string 320 +--rw description? string 321 +--rw servers 322 | +--rw server* [address] 323 | +--rw address inet:host 324 | +--rw port? inet:port-number 325 +--rw connection-type 326 | +--rw (connection-type)? 327 | +--:(persistent-connection) 328 | | +--rw persistent 329 | | +--rw keep-alives 330 | | +--rw interval-secs? uint8 331 | | +--rw count-max? uint8 332 | +--:(periodic-connection) 333 | +--rw periodic 334 | +--rw timeout-mins? uint8 335 | +--rw linger-secs? uint8 336 +--rw reconnect-strategy 337 | +--rw start-with? enumeration 338 | +--rw interval-secs? uint8 339 | +--rw count-max? uint8 340 +--rw host-keys 341 +--rw host-key* [name] 342 +--rw name string 344 3.4. The TLS Subtree 346 The TLS subtree uses both the "listen" and "call-home" groupings 347 mentioned above, while also defining containers for certificate and 348 pre-shared key mappings. Support for the TLS transport is advertised 349 by the "tls" feature, while listening for clients and calling home 350 are advertised by the "inbound-tls" and "outbound-tls" features 351 respectively. Also, though not visible in the tree output below, 352 this submodule refines all the port values with a suitable defaults 353 (e.g., 6513). 355 +--rw netconf 356 +--rw tls {tls}? 357 +--rw listen {inbound-tls}? 358 | +--rw (one-or-many)? 359 | +--:(one-port) 360 | | +--rw port? inet:port-number 361 | +--:(many-ports) 362 | +--rw interface* [address] 363 | +--rw address inet:ip-address 364 | +--rw port? inet:port-number 365 +--rw call-home {outbound-tls}? 366 | +--rw applications 367 | +--rw application* [name] 368 | +--rw name string 369 | +--rw description? string 370 | +--rw servers 371 | | +--rw server* [address] 372 | | +--rw address inet:host 373 | | +--rw port? inet:port-number 374 | +--rw connection-type 375 | | +--rw (connection-type)? 376 | | +--:(persistent-connection) 377 | | | +--rw persistent 378 | | | +--rw keep-alives 379 | | | +--rw interval-secs? uint8 380 | | | +--rw count-max? uint8 381 | | +--:(periodic-connection) 382 | | +--rw periodic 383 | | +--rw timeout-mins? uint8 384 | | +--rw linger-secs? uint8 385 | +--rw reconnect-strategy 386 | +--rw start-with? enumeration 387 | +--rw interval-secs? uint8 388 | +--rw count-max? uint8 389 +--rw cert-maps {tls-map-certificates}? 390 | +--rw cert-to-name* [id] 391 | +--rw id uint32 392 | +--rw fingerprint x509c2n:tls-fingerprint 393 | +--rw map-type identityref 394 | +--rw name string 395 +--rw psk-maps {tls-map-pre-shared-keys}? 396 +--rw psk-map* [psk-identity] 397 +--rw psk-identity string 398 +--rw user-name nacm:user-name-type 399 +--rw not-valid-before? yang:date-and-time 400 +--rw not-valid-after? yang:date-and-time 401 +--rw key yang:hex-string 403 4. NETCONF Server YANG Module 405 This YANG module imports YANG extensions from [RFC6536], and imports 406 YANG types from [RFC6991] and a YANG grouping from 407 [I-D.ietf-netmod-snmp-cfg]. 409 module ietf-netconf-server { 411 namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-server"; 412 prefix "ncserver"; 414 import ietf-yang-types { 415 prefix yang; // RFC 6991 416 } 417 import ietf-inet-types { 418 prefix inet; // RFC 6991 419 } 420 import ietf-x509-cert-to-name { 421 prefix x509c2n; // I-D.ietf-netconf-rfc5539bis 422 } 423 import ietf-netconf-acm { 424 prefix nacm; // RFC 6536 425 } 427 organization 428 "IETF NETCONF (Network Configuration) Working Group"; 430 contact 431 "WG Web: 432 WG List: 434 WG Chair: Mehmet Ersue 435 437 WG Chair: Bert Wijnen 438 440 Editor: Juergen Schoenwaelder 441 443 Kent Watsen 444 "; 446 description 447 "This module contains a collection of YANG definitions for 448 configuring NETCONF servers. 450 Copyright (c) 2014 IETF Trust and the persons identified as 451 authors of the code. All rights reserved. 453 Redistribution and use in source and binary forms, with or 454 without modification, is permitted pursuant to, and subject 455 to the license terms contained in, the Simplified BSD 456 License set forth in Section 4.c of the IETF Trust's 457 Legal Provisions Relating to IETF Documents 458 (http://trustee.ietf.org/license-info). 460 This version of this YANG module is part of RFC XXXX; see 461 the RFC itself for full legal notices."; 462 // RFC Ed.: replace XXXX with actual RFC number and 463 // remove this note 465 // RFC Ed.: please update the date to the date of publication 467 revision "2014-01-24" { 468 description 469 "Initial version"; 470 reference 471 "RFC XXXX: A YANG Data Model for NETCONF Server Configuration"; 472 } 474 /* 475 * Features 476 */ 478 feature ssh { 479 description 480 "A server implements this feature if it supports NETCONF 481 over Secure Shell (SSH)."; 482 reference 483 "RFC 6242: Using the NETCONF Protocol over Secure Shell (SSH)"; 484 } 486 feature inbound-ssh { 487 description 488 "The inbound-ssh feature indicates that the server can 489 open a port to listen for incoming client connections."; 490 } 492 feature outbound-ssh { 493 description 494 "The outbound-ssh feature indicates that the server can 495 connect to a client."; 496 reference 497 "RFC XXXX: Reverse Secure Shell (Reverse SSH)"; 498 } 500 feature tls { 501 description 502 "A server implements this feature if it supports NETCONF 503 over Transport Layer Security (TLS)."; 504 reference 505 "RFC XXXX: NETCONF over Transport Layer Security (TLS)"; 506 } 508 feature inbound-tls { 509 description 510 "The inbound-tls feature indicates that the server can 511 open a port to listen for incoming client connections."; 512 } 514 feature outbound-tls { 515 description 516 "The outbound-tls feature indicates that the server can 517 connect to a client."; 518 } 520 feature tls-map-certificates { 521 description 522 "The tls-map-certificates feature indicates that the 523 server implements mapping X.509 certificates to NETCONF 524 usernames."; 525 } 527 feature tls-map-pre-shared-keys { 528 description 529 "The tls-map-pre-shared-keys feature indicates that the 530 server implements mapping TLS pre-shared keys to NETCONF 531 usernames."; 532 } 534 /* 535 * Groupings 536 */ 538 grouping listen-config { 539 description 540 "Provides a choice of configuring one of more ports 541 to listen for incoming client connections."; 543 choice one-or-many { 544 default one-port; 545 case one-port { 546 leaf port { 547 type inet:port-number; 548 description 549 "The port number the server listens on on all 550 interfaces."; 551 } 552 } 554 case many-ports { 555 list interface { 556 key "address"; 557 leaf address { 558 type inet:ip-address; 559 mandatory true; 560 description 561 "The local IP address of the interface to listen 562 on."; 563 } 564 leaf port { 565 type inet:port-number; 566 description 567 "The local port number on this interface the 568 server listens on."; 569 } 570 } 571 } 572 } 573 } 575 grouping call-home-config { 577 container applications { 578 description 579 "A list of applications the device iniates connections 580 to. The configuration for each application specifies 581 its details, including its servers, the type of 582 connection to maintain, and the reconnection strategy 583 to use."; 585 list application { 586 key name; 587 // min-elements 1; // this forces ?! 588 leaf name { 589 type string { 590 length 1..64; // XXX why these limits? 591 } 592 mandatory true; 593 description 594 "An arbitrary name for the application the device 595 is connecting to."; 596 } 597 leaf description { 598 type string; 599 description 600 "An optional description for the application."; 601 } 602 container servers { 603 description 604 "An ordered listing of the application's servers 605 that the device should attempt connecting to."; 606 list server { 607 key address; 608 min-elements 1; 609 ordered-by user; 610 leaf address { 611 type inet:host; 612 mandatory true; 613 description 614 "The address or domain-name of the server."; 615 } 616 leaf port { 617 type inet:port-number; 618 description 619 "The IP port for this server. The device will use 620 the IANA-assigned well-known port if not specified."; 621 } 622 } 623 } 624 container connection-type { 625 description 626 "Indicates the application's preference for how the 627 device's connection is maintained."; 628 choice connection-type { 629 default persistent-connection; 631 case persistent-connection { 632 container persistent { 633 description 634 "Maintain a persistent connection to the 635 application. If the connection goes down, 636 immediately start trying to reconnect to it, 637 using the reconnection strategy. 639 This connection type minimizes any 640 application-to-server data-transfer delay, 641 albeit at the expense of holding resources 642 longer."; 643 container keep-alives { 644 leaf interval-secs { 645 type uint8; 646 units seconds; 647 default 15; 648 description 649 "Sets a timeout interval in seconds after which 650 if no data has been received from the 651 application, a message will be sent to request 652 a response from the application. A value of 653 '0' indicates that no keep-alive messages 654 should be sent."; 655 } 656 leaf count-max { 657 type uint8; 658 default 3; 659 description 660 "Sets the number of keep-alive messages that may 661 be sent without receiving any data from the 662 application before assuming the application is 663 no longer alive. If this threshold is reached, 664 the transport-level connection will be 665 disconnected (thus triggering the reconnection 666 strategy). The interval timer is reset after 667 each transmission, thus an unresponsive 668 application will be disconnected after 669 approximately count-max * interval-secs 670 seconds."; 671 } 672 } 673 } 674 } 676 case periodic-connection { 677 container periodic { 678 description 679 "Periodically connect to application, using the 680 reconnection strategy, so it can flush any pending 681 data it may be holding. This connection type 682 minimizes resources held open, albeit at the 683 expense of longer application-to-server 684 data-transfer delay. Note that for 685 server-to-application data, the data should be 686 sent immediately, connecting to application first 687 if not already."; 688 leaf timeout-mins { 689 type uint8; 690 units minutes; 691 default 5; 692 description 693 "The maximum amount of unconnected time the 694 device will wait until establishing a 695 connection to the application again. The 696 device may establish a connection before this 697 time if it has data it needs to send to the 698 application. Note: this value differs from 699 the reconnection strategy's interval-secs 700 value."; 701 } 702 leaf linger-secs { 703 type uint8; 704 units seconds; 705 default 30; 706 description 707 "The amount of time the device should wait after 708 last receiving data from or sending data to the 709 application before closing its connection to it. 710 This is an optimization to prevent unnecessary 711 connections."; 712 } 713 } 714 } 715 } 716 } 718 // XXX 719 // Should we have something smarter as the reconnect 720 // strategy, e.g. an exponential backoff? 722 container reconnect-strategy { 723 description 724 "The reconnection strategy guides how a device reconnects 725 to an application, after losing a connection to it, even 726 if due to a reboot. The device starts with the specified 727 server, tries to connect to it count-max times, waiting 728 interval-secs between each connection attempt, before 729 trying the next server in the list (round robin)."; 730 leaf start-with { 731 type enumeration { 732 enum first-listed { value 1; } 733 enum last-connected { value 2; } 734 } 735 default first-listed; 736 description 737 "Specifies which of the application's servers the 738 device should start with when trying to connect to 739 the application. In the case of newly configured 740 application, the first server listed shall be 741 considered last-connected."; 742 } 743 leaf interval-secs { 744 type uint8; 745 units seconds; 746 default 5; 747 description 748 "Specifies the time delay between connection attempts 749 to the same server. Note: this value differs from the 750 periodic-connection's timeout-mins value."; 751 } 752 leaf count-max { 753 type uint8; 754 default 3; 755 description 756 "Specifies the number times the device tries to 757 connect to a specific server before moving on to 758 the next server in the list (round robin)."; 759 } 760 } 761 } 762 } 763 } 765 grouping ssh-config { 766 description 767 "Provides a reusable grouping for all the ssh config. This 768 is done primarily to enable external modules to reference 769 this definition in a "uses" statement."; 771 container listen { 772 if-feature inbound-ssh; 773 description 774 "Provides the configuration of the NETCONF server to 775 open one or more ports to listen for incoming client 776 connections."; 777 uses listen-config { 778 refine one-or-many/one-port/port { 779 default 830; 780 } 781 refine one-or-many/many-ports/interface/port { 782 default 830; 783 } 784 } 785 } 787 container call-home { 788 if-feature outbound-ssh; 789 description 790 "Provides the configuration of the NETCONF call-home 791 clients to connect to, the overall call-home policy, 792 and the reconnect strategy."; 793 uses call-home-config { 794 augment applications/application { 795 container host-keys { 796 description 797 "An ordered listing of the SSH host keys the 798 device should advertise to the application."; 799 list host-key { 800 key name; 801 min-elements 1; 802 ordered-by user; 803 leaf name { 804 type string { 805 length 1..64; // XXX why this limit? 806 } 807 mandatory true; 808 description 809 "The name of a host key the device should 810 advertise during the SSH key exchange."; 811 } 812 } 813 } 814 } 815 } 816 } 817 } 819 grouping tls-config { 820 description 821 "Provides a reusable grouping for all the tls config. This 822 is done primarily to enable external modules to reference 823 this definition in a "uses" statement."; 825 container listen { 826 if-feature inbound-tls; 827 description 828 "Provides the configuration of the NETCONF server to 829 open one or more ports to listen for incoming client 830 connections."; 831 uses listen-config { 832 refine one-or-many/one-port/port { 833 default 6513; 834 } 835 refine one-or-many/many-ports/interface/port { 836 default 6513; 837 } 838 } 839 } 841 container call-home { 842 if-feature outbound-tls; 843 description 844 "Provides the configuration of the NETCONF call-home 845 clients to connect to, the overall call-home policy, 846 and the reconnect strategy."; 847 uses call-home-config; 848 } 850 /* 851 * Objects for deriving NETCONF usernames from X.509 852 * certificates. 853 */ 855 container cert-maps { 856 if-feature tls-map-certificates; 857 uses x509c2n:cert-to-name; 858 description 859 "The cert-maps container is used by a NETCONF server to 860 map the NETCONF client's presented X.509 certificate to 861 a NETCONF username. 863 If no matching and valid cert-to-name list entry can be 864 found, then the NETCONF server MUST close the connection, 865 and MUST NOT accept NETCONF messages over it."; 866 } 868 /* 869 * Objects for deriving NETCONF usernames from TLS 870 * pre-shared keys. 871 */ 873 container psk-maps { 874 if-feature tls-map-pre-shared-keys; 875 description 876 "During the TLS Handshake, the client indicates which 877 key to use by including a PSK identity in the TLS 878 ClientKeyExchange message. On the server side, this 879 PSK identity is used to look up an entry in the psk-map 880 list. If such an entry is found, and the pre-shared keys 881 match, then the client is authenticated. The server uses 882 the value from the user-name leaf in the psk-map list as 883 the NETCONF username. If the server cannot find an entry 884 in the psk-map list, or if the pre-shared keys do not 885 match, then the server terminates the connection."; 886 reference 887 "RFC 4279: Pre-Shared Key Ciphersuites for Transport Layer 888 Security (TLS)"; 890 list psk-map { 891 key psk-identity; 893 leaf psk-identity { 894 type string; 895 description 896 "The PSK identity encoded as a UTF-8 string. For 897 details how certain common PSK identity formats can 898 be encoded in UTF-8, see section 5.1. of RFC 4279."; 899 reference 900 "RFC 4279: Pre-Shared Key Ciphersuites for Transport 901 Layer Security (TLS)"; 902 } 903 leaf user-name { 904 type nacm:user-name-type; 905 mandatory true; 906 description 907 "The NETCONF username associated with this PSK 908 identity."; 909 } 910 leaf not-valid-before { 911 type yang:date-and-time; 912 description 913 "This PSK identity is not valid before the given date 914 and time."; 915 } 916 leaf not-valid-after { 917 type yang:date-and-time; 918 description 919 "This PSK identity is not valid after the given date 920 and time."; 921 } 922 leaf key { 923 type yang:hex-string; 924 mandatory true; 925 nacm:default-deny-all; 926 description 927 "The key associated with the PSK identity"; 928 reference 929 "RFC 4279: Pre-Shared Key Ciphersuites for Transport 930 Layer Security (TLS)"; 931 } 932 } 933 } 934 } 936 /* 937 * Configuration data nodes 938 */ 940 container netconf { 941 description 942 "Top-level container for NETCONF server related 943 configuration objects."; 945 container ssh { 946 if-feature ssh; 947 uses ssh-config; 948 } 950 container tls { 951 if-feature tls; 952 uses tls-config; 953 } 955 } 956 } 958 5. Security Considerations 960 This document defines a YANG modules to configure NETCONF's SSH and 961 TLS transports. Please see the Security Considerations section in 962 those RFCs for transport-specific issues. 964 6. IANA Considerations 966 This document registers one URIs in the IETF XML registry [RFC2119]. 967 Following the format in [RFC3688], the following registration is 968 requested to be made. 970 URI: urn:ietf:params:xml:ns:yang:ietf-netconf-server 971 Registrant Contact: The NETCONF WG of the IETF. 972 XML: N/A, the requested URI is an XML namespace. 974 This document registers one YANG module in the YANG Module Names 975 registry [RFC6020]. 977 name: ietf-netconf-server 978 namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-server 979 prefix: ncserver 980 reference: RFC XXXX 982 7. Acknowledgements 984 Juergen Schoenwaelder and was partly funded by Flamingo, a Network of 985 Excellence project (ICT-318488) supported by the European Commission 986 under its Seventh Framework Programme. 988 8. References 989 8.1. Normative References 991 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 992 Requirement Levels ", BCP 14, RFC 2119, March 1997. 994 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 995 the Network Configuration Protocol (NETCONF) ", RFC 6020, 996 October 2010. 998 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 999 Protocol (NETCONF) Access Control Model ", RFC 6536, March 1000 2012. 1002 [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, 1003 July 2013. 1005 [I-D.ietf-netmod-snmp-cfg] 1006 Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for 1007 SNMP Configuration", draft-ietf-netmod-snmp-cfg-03 (work 1008 in progress), November 2013. 1010 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1011 and A. Bierman, Ed., "NETCONF Configuration Protocol", RFC 1012 6241, June 2011. 1014 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1015 Shell (SSH)", RFC 6242, June 2011. 1017 [I-D.ietf-netconf-rfc5539bis] 1018 Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 1019 NETCONF Protocol over Transport Layer Security (TLS) ", 1020 draft-ietf-netconf-rfc5539bis-04 (work in progress), 1021 October 2013. 1023 8.2. Informative References 1025 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1026 January 2004. 1028 Appendix A. Example: SSH 1030 1031 1033 1034 831 1035 1036 1037 1038 1039 config-mgr 1040 1041 This entry requests the device to periodically 1042 connect to the Configuration Manager application 1043 1044 1045 1046
config-mgr1.example.com
1047 1048 1049
config-mgr2.example.com
1050 1051 1052 1053 1054 5 1055 10 1056 1057 1058 1059 last-connected 1060 10 1061 3 1062 1063 1064 1065 ssh_host_key_cert 1066 1067 1068 ssh_host_key_cert2 1069 1070 1071 1072 1073 1075 1076 1078 Appendix B. Example: TLS 1080 1081 1083 1084 1085
192.0.2.1
1086 6514 1087 1088 1090 1091 1092 1093 log-monitor 1094 1095 This entry requests the device to maintain a 1096 persistent connect to the Log Monitor application 1097 1098 1099 1100
log-monitor1.example.com
1101 1102 1103
log-monitor2.example.com
1104 1105 1106 1107 1108 1109 5 1110 3 1111 1112 1113 1114 1115 first-listed 1116 10 1117 4 1118 1119 1120 1121 1123 1124 1126 1127 1 1128 11:0A:05:11:00 1129 x509c2n:san-any 1130 1131 1133 1134 2 1135 11:0A:05:11:00 1136 x509c2n:specified 1137 Joe Cool 1138 1139 1141 1142 1143 a8gc8]klh59 1144 admin 1145 2013-01-01T00:00:00Z 1146 2014-01-01T00:00:00Z 1147 1148 1150 1151 1153 Appendix C. Change Log 1155 C.1. 00 to 01 1157 o Restructured YANG module slightly, to provide groupings useful to 1158 the ZeroTouch draft. 1160 Appendix D. Open Issues 1162 o NETCONF implementations typically have config parameters such as 1163 session timeouts or hello timeouts. Shall they be included in 1164 this model? 1166 o Do we need knobs to enable/disable call-home without the need to 1167 remove all the call-home client configuration? 1169 o Do we need something equivalent to the host-keys in the TLS 1170 configuration subtree? 1172 Authors' Addresses 1174 Kent Watsen 1175 Juniper Networks 1177 EMail: kwatsen@juniper.net 1178 Juergen Schoenwaelder 1179 Jacobs University Bremen 1181 EMail: j.schoenwaelder@jacobs-university.de