--- 1/draft-ietf-netconf-server-model-02.txt 2014-09-22 17:14:37.641969965 -0700 +++ 2/draft-ietf-netconf-server-model-03.txt 2014-09-22 17:14:37.689971088 -0700 @@ -1,19 +1,19 @@ NETCONF Working Group K. Watsen Internet-Draft Juniper Networks Intended status: Standards Track J. Schoenwaelder -Expires: March 20, 2015 Jacobs University Bremen - September 16, 2014 +Expires: March 26, 2015 Jacobs University Bremen + September 22, 2014 NETCONF Server Configuration Model - draft-ietf-netconf-server-model-02 + draft-ietf-netconf-server-model-03 Abstract This draft defines a NETCONF server configuration data model. This data model enables configuration of the NETCONF service itself, including which transports it supports, what ports they listen on, whether they support device-initiated connections, and associated parameters. Status of This Memo @@ -24,21 +24,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on March 20, 2015. + This Internet-Draft will expire on March 26, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -54,21 +54,21 @@ 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Support all NETCONF Transports . . . . . . . . . . . . . 3 2.2. Align Transport-Specific Configurations . . . . . . . . . 3 2.3. Support both Listening for Connections and Call Home . . 4 2.4. For Call Home Connections . . . . . . . . . . . . . . . . 4 2.4.1. Support More than One Application . . . . . . . . . . 4 2.4.2. Support Applications Having More than One Server . . 4 2.4.3. Support a Reconnection Strategy . . . . . . . . . . . 4 - 2.4.4. Support both Persistent and Periodic Connections . . 5 + 2.4.4. Support both Persistent and Periodic Connections . . 4 2.4.5. Reconnection Strategy for Periodic Connections . . . 5 2.4.6. Keep-Alives for Persistent Connections . . . . . . . 5 2.4.7. Customizations for Periodic Connections . . . . . . . 5 3. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 8 4. Keep-Alives for SSH and TLS . . . . . . . . . . . . . . . . . 21 4.1. SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.2. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 @@ -77,20 +77,21 @@ 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 9.1. Normative References . . . . . . . . . . . . . . . . . . 24 9.2. Informative References . . . . . . . . . . . . . . . . . 25 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 26 A.1. SSH Transport Configuration . . . . . . . . . . . . . . . 26 A.2. TLS Transport Configuration . . . . . . . . . . . . . . . 26 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 27 B.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 28 B.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 28 + B.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 28 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 28 1. Introduction This draft defines a NETCONF [RFC6241] server configuration data model. This data model enables configuration of the NETCONF service itself, including which transports are supported, what ports does the server listen on, whether call-home is supported, and associated parameters. @@ -119,42 +120,40 @@ 2. Objectives The primary purpose of the YANG module defined herein is to enable the configuration of the NETCONF service on the device. This scope includes the following objectives: 2.1. Support all NETCONF Transports The YANG module should support all current NETCONF transports, namely - NETCONF over SSH [RFC6242] and NETCONF over TLS - [I-D.ietf-netconf-rfc5539bis], and be extensible to support future - transports as necessary. + NETCONF over SSH [RFC6242] and NETCONF over TLS [rfc5539bis], and be + extensible to support future transports as necessary. Since implementations may not support all transports, the module should use YANG "feature" statements so that implementations can accurately advertise which transports are supported. 2.2. Align Transport-Specific Configurations While each transport is unique in its protocol and may have some distinct configurations, there remains a significant overlap between them. Thus the YANG module should use "grouping" statements so that the common aspects can be configured similarly. 2.3. Support both Listening for Connections and Call Home NETCONF has always supported the server opening a port to listen for client connections. More recently the NETCONF working group defined - support for call-home ([I-D.ietf-netconf-rfc5539bis] and - [draft-ieft-netconf-reverse-ssh]). The module should configure both - listening for connections and call-home. + support for call-home ([draft-ietf-netconf-call-home]). The module + should configure both listening for connections and call-home. Since implementations may not support both listening for connections and call home, YANG "feature" statements should be used so that implementation can accurately advertise the connection types it supports. 2.4. For Call Home Connections The following objectives only pertain to call home connections. @@ -232,65 +231,79 @@ to send a notification message, there's a high probability that it will send another shortly thereafter. Likewise, the application may have a sequence of pending messages to send. Thus, it should be possible for a device to hold a connection open until some amount of time of no data being transmitted as transpired. 3. Data Model 3.1. Overview - To enable transports to configure listening on one or more ports in a - common way, the following subtree is defined. This subtree defines - SSH and TLS specific containers, each of which refines the default - listening port appropriately. Further, each of these transport - specific containers use a feature statement, enabling NETCONF servers - to accurately advertise what they support. + The following subtree illustrates how this YANG module enables + configuration for listening for remote connections, as described in + [RFC6242] and [rfc5539bis]. Feature statements are used to limit + both if listening is supported at all as well as for which + transports. If listening for connections is supported, then the + model enables configuring a list of listening endpoints, each + configured with a user-specified name (the key field), the transport + to use (i.e. SSH, TLS), and the IP address and port to listen on. + The port field is optional, defaulting to the transport-specific port + when not configured. module: ietf-netconf-server +--rw netconf-server +--rw listen* [name] +--rw name string +--rw (transport) +--:(ssh) {ssh-listen}? | +--rw ssh | +--rw address inet:host | +--rw port? inet:port-number +--:(tls) {tls-listen}? +--rw tls +--rw address inet:host +--rw port? inet:port-number - To enable transports to configure initiating connections to remote - applications in a common way, the following subtree is defined. This - subtree configures a list of appliacations, each with some transport- - specific configuration augmented in. Each of the transport specific - containers use a feature statement, enabling NETCONF servers to - accurately advertise what they support. + The following subtree illustrates how this YANG module enables + configuration for call home, as described in + [draft-ietf-netconf-call-home]. Feature statements are used to limit + both if call-home is supported at all as well as for which + transports, if it is. If call-home is supported, then the model + supports configuring a list of applications to connect to. Each + application is configured with a user-specified name (the key field), + the transport to be used (i.e. SSH, TLS), and a list of remote + endpoints, each having a name, an IP address, and an optional port. + Additionally, the configuration for each remote application indicates + the connection-type (persistent vs. periodic) and associated + parameters, as well as the reconnection strategy to use. module: ietf-netconf-server +--rw netconf-server - +--rw call-home - +--rw network-managers - +--rw network-manager* [name] + +--rw call-home* [name] +--rw name string - +--rw description? string - +--rw endpoints - | +--rw endpoint* [address] - | +--rw address inet:host - | +--rw port? inet:port-number - +--rw transport - | +--rw ssh {ssh-call-home}? - | | +--rw host-keys + +--rw (transport) + | +--:(ssh) {ssh-call-home}? + | | +--rw ssh + | | +--rw endpoints + | | | +--rw endpoint* [name] + | | | +--rw name string + | | | +--rw address inet:host + | | | +--rw port? inet:port-number | | +--rw host-key* [name] | | +--rw name string - | +--rw tls! {tls-call-home}? + | +--:(tls) {tls-call-home}? + | +--rw tls + | +--rw endpoints + | +--rw endpoint* [name] + | +--rw name string + | +--rw address inet:host + | +--rw port? inet:port-number +--rw connection-type | +--rw (connection-type)? | +--:(persistent-connection) | | +--rw persistent | | +--rw keep-alives | | +--rw interval-secs? uint8 | | +--rw count-max? uint8 | +--:(periodic-connection) | +--rw periodic | +--rw timeout-mins? uint8 @@ -562,21 +575,21 @@ refine endpoints/endpoint/port { default 9999; // pending IANA assignment } } list host-key { key name; min-elements 1; ordered-by user; description "User-ordered list of host-keys the SSH server - should advertize."; + should advertise."; leaf name { type string; mandatory true; description "The name of a host key the device should advertise during the SSH key exchange."; } } } } @@ -1058,70 +1071,65 @@ Lhotka, Radek Krejci, Tom Petch, and Phil Shafer. Juergen Schoenwaelder and was partly funded by Flamingo, a Network of Excellence project (ICT-318488) supported by the European Commission under its Seventh Framework Programme. 9. References 9.1. Normative References - [I-D.ietf-netconf-rfc5539bis] - Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the - NETCONF Protocol over Transport Layer Security (TLS)", - draft-ietf-netconf-rfc5539bis-04 (work in progress), - October 2013. - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. - [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for - the Network Configuration Protocol (NETCONF)", RFC 6020, + [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the + Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. - [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., - and A. Bierman, Ed., "NETCONF Configuration Protocol", RFC + [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. + Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, June 2011. [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, February 2012. [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", RFC 6536, March 2012. [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, July 2013. - [draft-ieft-netconf-reverse-ssh] - Watsen, K., "NETCONF over SSH Call Home", draft-ieft- - netconf-reverse-ssh-00 (work in progress), May 2014. + [draft-ietf-netconf-call-home] + Watsen, K., "NETCONF Call Home", draft-ieft-netconf-call- + home-00 (work in progress), 2014. [draft-ietf-netmod-snmp-cfg] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for SNMP Configuration", draft-ietf-netmod-snmp-cfg-03 (work in progress), November 2013. - [draft-ietf-netmod-system-mgmt] - Bierman, A., "A YANG Data Model for System Management", - draft-ieft-netmod-system-mgmt-16 (work in progress), May - 2014. + [rfc5539bis] + Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the + NETCONF Protocol over Transport Layer Security (TLS)", + draft-ietf-netconf-rfc5539bis-04 (work in progress), + October 2013. 9.2. Informative References [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. Appendix A. Examples A.1. SSH Transport Configuration @@ -1225,20 +1233,24 @@ o removed the "one-to-many" construct o removed "address" as a key field o removed "network-manager" terminology o moved open issues to github issues o brought TLS client auth back into model +B.3. 02 to 03 + + o fixed tree diagrams and surrounding text + Appendix C. Open Issues Please see: https://github.com/netconf-wg/server-model/issues. Authors' Addresses Kent Watsen Juniper Networks EMail: kwatsen@juniper.net