draft-ietf-netconf-server-model-06.txt   draft-ietf-netconf-server-model-07.txt 
NETCONF Working Group K. Watsen NETCONF Working Group K. Watsen
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Standards Track J. Schoenwaelder Intended status: Standards Track J. Schoenwaelder
Expires: August 6, 2015 Jacobs University Bremen Expires: January 7, 2016 Jacobs University Bremen
February 2, 2015 July 6, 2015
NETCONF Server and RESTCONF Server Configuration Models NETCONF Server and RESTCONF Server Configuration Models
draft-ietf-netconf-server-model-06 draft-ietf-netconf-server-model-07
Abstract Abstract
This draft defines a NETCONF server configuration data model and a This draft defines a NETCONF server configuration data model and a
RESTCONF server configuration data model. These data models enable RESTCONF server configuration data model. These data models enable
configuration of the NETCONF and RESTCONF services themselves, configuration of the NETCONF and RESTCONF services themselves,
including which transports are supported, what ports the servers including which transports are supported, what ports the servers
listens on, whether call-home is supported, and associated listen on, call-home parameters, client authentication, and other
parameters. related configuration parameters.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
This draft contains many placeholder values that need to be replaced This draft contains many placeholder values that need to be replaced
with finalized values at the time of publication. This note with finalized values at the time of publication. This note
summarizes all of the substitutions that are needed. Please note summarizes all of the substitutions that are needed. Please note
that no other RFC Editor instructions are specified anywhere else in that no other RFC Editor instructions are specified anywhere else in
this document. this document.
This document contains references to other drafts in progress, both This document contains references to other drafts in progress, both
in the Normative References section, as well as in body text in the Normative References section, as well as in body text
throughout. Please update the following references to reflect their throughout. Please update the following references to reflect their
final RFC assignments: final RFC assignments:
o draft-ietf-netconf-rfc5539bis
o draft-ietf-netconf-restconf o draft-ietf-netconf-restconf
o draft-ietf-netconf-call-home o draft-ietf-netconf-call-home
Artwork in this document contains shorthand references to drafts in Artwork in this document contains shorthand references to drafts in
progress. Please apply the following replacements: progress. Please apply the following replacements:
o "VVVV" --> the assigned RFC value for this draft o "VVVV" --> the assigned RFC value for this draft
o "WWWW" --> the assigned RFC value for draft-ietf-netconf-
rfc5539bis
o "XXXX" --> the assigned RFC value for draft-ietf-netconf-restconf o "XXXX" --> the assigned RFC value for draft-ietf-netconf-restconf
o "YYYY" --> the assigned RFC value for draft-ietf-netconf-call-home o "YYYY" --> the assigned RFC value for draft-ietf-netconf-call-home
o "ZZZZ" --> the assigned RFC value for draft-thomson-httpbis-cant o "ZZZZ" --> the assigned RFC value for draft-thomson-httpbis-cant
Artwork in this document contains placeholder values for ports Artwork in this document contains placeholder values for ports
pending IANA assignment from "draft-ietf-netconf-call-home". Please pending IANA assignment from "draft-ietf-netconf-call-home". Please
apply the following replacements: apply the following replacements:
o "7777" --> the assigned port value for "netconf-ch-ssh" o "7777" --> the assigned port value for "netconf-ch-ssh"
o "8888" --> the assigned port value for "netconf-ch-tls" o "8888" --> the assigned port value for "netconf-ch-tls"
o "9999" --> the assigned port value for "restconf-ch-tls" o "9999" --> the assigned port value for "restconf-ch-tls"
skipping to change at page 2, line 21 skipping to change at page 2, line 17
o "7777" --> the assigned port value for "netconf-ch-ssh" o "7777" --> the assigned port value for "netconf-ch-ssh"
o "8888" --> the assigned port value for "netconf-ch-tls" o "8888" --> the assigned port value for "netconf-ch-tls"
o "9999" --> the assigned port value for "restconf-ch-tls" o "9999" --> the assigned port value for "restconf-ch-tls"
Artwork in this document contains placeholder values for the date of Artwork in this document contains placeholder values for the date of
publication of this draft. Please apply the following replacement: publication of this draft. Please apply the following replacement:
o "2015-02-02" --> the publication date of this draft o "2015-07-06" --> the publication date of this draft
The following two Appendix sections are to be removed prior to The following two Appendix sections are to be removed prior to
publication: publication:
o Appendix B. Change Log o Appendix B. Change Log
o Appendix C. Open Issues o Appendix C. Open Issues
Status of This Memo Status of This Memo
skipping to change at page 2, line 45 skipping to change at page 2, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 6, 2015. This Internet-Draft will expire on January 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 5
2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Support all NETCONF and RESTCONF transports . . . . . . . 5 2.1. Support all NETCONF and RESTCONF transports . . . . . . . 5
2.2. Enable each transport to select which keys to use . . . . 5 2.2. Enable each transport to select which keys to use . . . . 5
2.3. Support authenticating NETCONF/RESTCONF clients 2.3. Support authenticating NETCONF/RESTCONF clients
certificates . . . . . . . . . . . . . . . . . . . . . . 5 certificates . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Support mapping authenticated NETCONF/RESTCONF client 2.4. Support mapping authenticated NETCONF/RESTCONF client
certificates to usernames . . . . . . . . . . . . . . . . 6 certificates to usernames . . . . . . . . . . . . . . . . 6
2.5. Support both Listening for connections and Call Home . . 6 2.5. Support both listening for connections and call home . . 6
2.6. For Call Home connections . . . . . . . . . . . . . . . . 6 2.6. For Call Home connections . . . . . . . . . . . . . . . . 6
2.6.1. Support more than one northbound application . . . . 6 2.6.1. Support more than one NETCONF/RESTCONF client . . . . 6
2.6.2. Support applications having more than one server . . 6 2.6.2. Support NETCONF/RESTCONF clients having more than one
2.6.3. Support a reconnection strategy . . . . . . . . . . . 6 endpoint . . . . . . . . . . . . . . . . . . . . . . 6
2.6.3. Support a reconnection strategy . . . . . . . . . . . 7
2.6.4. Support both persistent and periodic connections . . 7 2.6.4. Support both persistent and periodic connections . . 7
2.6.5. Reconnection strategy for periodic connections . . . 7 2.6.5. Reconnection strategy for periodic connections . . . 7
2.6.6. Keep-alives for persistent connections . . . . . . . 7 2.6.6. Keep-alives for persistent connections . . . . . . . 7
2.6.7. Customizations for periodic connections . . . . . . . 7 2.6.7. Customizations for periodic connections . . . . . . . 8
3. The NETCONF Server Configuration Model . . . . . . . . . . . 8 3. The NETCONF Server Model . . . . . . . . . . . . . . . . . . 8
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 8
3.1.1. The "session-options" subtree . . . . . . . . . . . . 8 3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 9
3.1.2. The "listen" subtree . . . . . . . . . . . . . . . . 8 3.2.1. Configuring SSH Transport . . . . . . . . . . . . . . 10
3.1.3. The "call-home" subtree . . . . . . . . . . . . . . . 9 3.2.2. Configuring TLS Transport . . . . . . . . . . . . . . 11
3.1.4. The "ssh" subtree . . . . . . . . . . . . . . . . . . 11 3.3. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.5. The "tls" subtree . . . . . . . . . . . . . . . . . . 11 4. The RESTCONF Server Model . . . . . . . . . . . . . . . . . . 26
3.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 26
4. The RESTCONF Server Configuration Model . . . . . . . . . . . 25 4.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 27
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 25 4.2.1. Configuring TLS Transport . . . . . . . . . . . . . . 27
4.1.1. The "listen" subtree . . . . . . . . . . . . . . . . 25 4.3. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 28
4.1.2. The "call-home" subtree . . . . . . . . . . . . . . . 26 5. Security Considerations . . . . . . . . . . . . . . . . . . . 37
4.1.3. The "client-cert-auth" subtree . . . . . . . . . . . 28 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
4.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 28 7. Other Considerations . . . . . . . . . . . . . . . . . . . . 39
5. Implementation strategy for keep-alives . . . . . . . . . . . 39 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
5.1. Keep-alives for SSH . . . . . . . . . . . . . . . . . . . 39 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2. Keep-alives for TLS . . . . . . . . . . . . . . . . . . . 40 9.1. Normative References . . . . . . . . . . . . . . . . . . 39
9.2. Informative References . . . . . . . . . . . . . . . . . 40
6. Security Considerations . . . . . . . . . . . . . . . . . . . 40 Appendix A. Alternative solution addressing Issue #49 . . . . . 41
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 A.1. The Keychain Model . . . . . . . . . . . . . . . . . . . 41
8. Other Considerations . . . . . . . . . . . . . . . . . . . . 41 A.1.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 41
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42 A.1.2. Example Usage . . . . . . . . . . . . . . . . . . . . 42
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 A.1.3. YANG Model . . . . . . . . . . . . . . . . . . . . . 45
10.1. Normative References . . . . . . . . . . . . . . . . . . 42 A.2. The SSH Server Model . . . . . . . . . . . . . . . . . . 52
10.2. Informative References . . . . . . . . . . . . . . . . . 43 A.2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 52
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 44 A.2.2. Example Usage . . . . . . . . . . . . . . . . . . . . 53
A.1. NETCONF Configuration using SSH Transport . . . . . . . . 44 A.2.3. YANG Model . . . . . . . . . . . . . . . . . . . . . 53
A.2. NETCONF Configuration using TLS Transport . . . . . . . . 45 A.3. The TLS Server Model . . . . . . . . . . . . . . . . . . 56
A.3. RESTCONF Configuration using TLS Transport . . . . . . . 47 A.3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 56
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 47 A.3.2. Example Usage . . . . . . . . . . . . . . . . . . . . 57
B.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 47 A.3.3. YANG Model . . . . . . . . . . . . . . . . . . . . . 57
B.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 48 A.4. The NETCONF Server Model . . . . . . . . . . . . . . . . 60
B.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 48 A.4.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 60
B.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 48 A.4.2. Example Usage . . . . . . . . . . . . . . . . . . . . 62
B.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 48 A.4.3. YANG Model . . . . . . . . . . . . . . . . . . . . . 64
B.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 49 A.5. The RESTCONF Server Model . . . . . . . . . . . . . . . . 75
Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 49 A.5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 75
A.5.2. Example Usage . . . . . . . . . . . . . . . . . . . . 76
A.5.3. YANG Model . . . . . . . . . . . . . . . . . . . . . 76
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 84
B.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 84
B.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 84
B.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 84
B.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 84
B.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 85
B.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 85
B.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 86
Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 87
1. Introduction 1. Introduction
This draft defines a NETCONF [RFC6241] server configuration data This draft defines a NETCONF [RFC6241] server configuration data
model and a RESTCONF [draft-ietf-netconf-restconf] server model and a RESTCONF [draft-ietf-netconf-restconf] server
configuration data model. These data models enable configuration of configuration data model. These data models enable configuration of
the NETCONF and RESTCONF services themselves, including which the NETCONF and RESTCONF services themselves, including which
transports are supported, what ports the servers listens on, whether transports are supported, what ports the servers listen on, call-home
call-home is supported, and associated parameters. parameters, client authentication, and other related configuration
parameters.
1.1. Terminology 1.1. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Tree Diagrams 1.2. Tree Diagrams
A simplified graphical representation of the data models is used in A simplified graphical representation of the data models is used in
skipping to change at page 5, line 24 skipping to change at page 5, line 38
2. Objectives 2. Objectives
The primary purpose of the YANG modules defined herein is to enable The primary purpose of the YANG modules defined herein is to enable
the configuration of the NETCONF and RESTCONF services on a network the configuration of the NETCONF and RESTCONF services on a network
element. This scope includes the following objectives: element. This scope includes the following objectives:
2.1. Support all NETCONF and RESTCONF transports 2.1. Support all NETCONF and RESTCONF transports
The YANG module should support all current NETCONF and RESTCONF The YANG module should support all current NETCONF and RESTCONF
transports, namely NETCONF over SSH [RFC6242], NETCONF over TLS transports, namely NETCONF over SSH [RFC6242], NETCONF over TLS
[draft-ietf-netconf-rfc5539bis], and RESTCONF over TLS [RFC7589], and RESTCONF over TLS [draft-ietf-netconf-restconf], and
[draft-ietf-netconf-restconf], and to be extensible to support future to be extensible to support future transports as necessary.
transports as necessary.
Because implementations may not support all transports, the module Because implementations may not support all transports, the module
should use YANG "feature" statements so that implementations can should use YANG "feature" statements so that implementations can
accurately advertise which transports are supported. accurately advertise which transports are supported.
2.2. Enable each transport to select which keys to use 2.2. Enable each transport to select which keys to use
Servers may have a multiplicity of host-keys or server-certificates Servers may have a multiplicity of host-keys or server-certificates
from which subsets may be selected for specific uses. For instance, from which subsets may be selected for specific uses. For instance,
a NETCONF server may want to use one set of SSH host-keys when a NETCONF server may want to use one set of SSH host-keys when
skipping to change at page 6, line 8 skipping to change at page 6, line 17
When a certificate is used to authenticate a NETCONF or RESTCONF When a certificate is used to authenticate a NETCONF or RESTCONF
client, there is a need to configure the server to know how to client, there is a need to configure the server to know how to
authenticate the certificates. The server should be able to authenticate the certificates. The server should be able to
authenticate the client's certificate either by using path-validation authenticate the client's certificate either by using path-validation
to a configured trust anchor or by matching the client-certificate to to a configured trust anchor or by matching the client-certificate to
one previously configured. one previously configured.
2.4. Support mapping authenticated NETCONF/RESTCONF client certificates 2.4. Support mapping authenticated NETCONF/RESTCONF client certificates
to usernames to usernames
When a client certifcate is used for TLS transport-level When a client certificate is used for TLS client authentication, the
authentication, the NETCONF/RESTCONF server must be able to derive a NETCONF/RESTCONF server must be able to derive a username from the
username from the authenticated certifcate. Thus the modules defined authenticated certificate. Thus the modules defined herein should
herein should enable this mapping to be configured. enable this mapping to be configured.
2.5. Support both Listening for connections and Call Home 2.5. Support both listening for connections and call home
The NETCONF and RESTCONF protocols were originally defined as having The NETCONF and RESTCONF protocols were originally defined as having
the server opening a port to listen for client connections. More the server opening a port to listen for client connections. More
recently the NETCONF working group defined support for call-home recently the NETCONF working group defined support for call-home
([draft-ietf-netconf-call-home]), enabling the server to initiate the ([draft-ietf-netconf-call-home]), enabling the server to initiate the
connection to the client, for both the NETCONF and RESTCONF connection to the client, for both the NETCONF and RESTCONF
protocols. Thus the modules defined herein should enable protocols. Thus the modules defined herein should enable
configuration for both listening for connections and calling home. configuration for both listening for connections and calling home.
Because implementations may not support both listening for Because implementations may not support both listening for
connections and calling home, YANG "feature" statements should be connections and calling home, YANG "feature" statements should be
used so that implementation can accurately advertise the connection used so that implementation can accurately advertise the connection
types it supports. types it supports.
2.6. For Call Home connections 2.6. For Call Home connections
The following objectives only pertain to call home connections. The following objectives only pertain to call home connections.
2.6.1. Support more than one northbound application 2.6.1. Support more than one NETCONF/RESTCONF client
A device may be managed by more than one northbound application. For A NETCONF/RESTCONF server may be managed by more than one NETCONF/
instance, a deployment may have one application for provisioning and RESTCONF client. For instance, a deployment may have one client for
another for fault monitoring. Therefore, when it is desired for a provisioning and another for fault monitoring. Therefore, when it is
device to initiate call home connections, it should be able to do so desired for a server to initiate call home connections, it should be
to more than one application. able to do so to more than one client.
2.6.2. Support applications having more than one server 2.6.2. Support NETCONF/RESTCONF clients having more than one endpoint
An application managing a device may implement a high-availability An NETCONF/RESTCONF client managing a NETCONF/RESTCONF server may
strategy employing a multiplicity of active and/or passive servers. implement a high-availability strategy employing a multiplicity of
Therefore, when it is desired for a device to initiate call home active and/or passive endpoint. Therefore, when it is desired for a
connections, it should be able to connect to any of the application's server to initiate call home connections, it should be able to
servers. connect to any of the client's endpoints.
2.6.3. Support a reconnection strategy 2.6.3. Support a reconnection strategy
Assuming an application has more than one server, then it becomes Assuming a NETCONF/RESTCONF client has more than one endpoint, then
necessary to configure how a device should reconnect to the it becomes necessary to configure how a NETCONF/RESTCONF server
application should it lose its connection to the application's should reconnect to the client should it lose its connection to one
servers. Of primary interest is if the device should start with the client's endpoints. For instance, the NETCONF/RESTCONF server
first server defined in a user-ordered list of servers or with the may start with first endpoint defined in a user-ordered list of
last server it was connected to. Secondary settings might specify endpoints or with thei last endpoints it was connected to.
the frequency of attempts and number of attempts per server.
Therefore, a reconnection strategy should be configurable.
2.6.4. Support both persistent and periodic connections 2.6.4. Support both persistent and periodic connections
Applications may vary greatly on how frequently they need to interact NETCONF/RESTCONF clients may vary greatly on how frequently they need
with a device, how responsive interactions with devices need to be, to interact with a NETCONF/RESTCONF server, how responsive
and how many simultaneous connections they can support. Some interactions need to be, and how many simultaneous connections they
applications may need a persistent connection to devices to optimize can support. Some clients may need a persistent connection to
real-time interactions, while others prefer periodic interactions in servers to optimize real-time interactions, while others prefer
order to minimize resource requirements. Therefore, when it is periodic interactions in order to minimize resource requirements.
necessary for devices to initiate connections, the type of connection Therefore, when it is necessary for server to initiate connections,
desired should be configurable. it should be configurable if the connection is persistent or
periodic.
2.6.5. Reconnection strategy for periodic connections 2.6.5. Reconnection strategy for periodic connections
The reconnection strategy should apply to both persistent and The reconnection strategy should apply to both persistent and
periodic connections. How it applies to periodic connections becomes periodic connections. How it applies to periodic connections becomes
clear when considering that a periodic "connection" is a logical clear when considering that a periodic "connection" is a logical
connection to a single server. That is, the periods of connection to a single server. That is, the periods of
unconnectedness are intentional as opposed to due to external unconnectedness are intentional as opposed to due to external
reasons. A periodic "connection" should always reconnect to the same reasons. A periodic "connection" should always reconnect to the same
server until it is no longer able to, at which time the reconnection server until it is no longer able to, at which time the reconnection
strategy guides how to connect to another server. strategy guides how to connect to another server.
2.6.6. Keep-alives for persistent connections 2.6.6. Keep-alives for persistent connections
If a persistent connection is desired, it is the responsibility of If a persistent connection is desired, it is the responsibility of
the connection initiator to actively test the "aliveness" of the the connection initiator to actively test the "aliveness" of the
connection. The connection initiator must immediately work to connection. The connection initiator must immediately work to
reestablish a persistent connection as soon as the connection is reestablish a persistent connection as soon as the connection is
lost. How often the connection should be tested is driven by lost. How often the connection should be tested is driven by
application requirements, and therefore keep-alive settings should be NETCONF/RESTCONF client requirements, and therefore keep-alive
configurable on a per-application basis. settings should be configurable on a per-client basis.
2.6.7. Customizations for periodic connections 2.6.7. Customizations for periodic connections
If a periodic connection is desired, it is necessary for the device If a periodic connection is desired, it is necessary for the NETCONF/
to know how often it should connect. This delay essentially RESTCONF server to know how often it should connect. This frequency
determines how long the application might have to wait to send data determines the maximum amount of time a NETCONF/RESTCONF client may
to the device. This setting does not constrain how often the device have to wait to send data to a server. A server may connect to a
must wait to send data to the application, as the device should client before this interval expires if desired (e.g., to send data to
immediately connect to the application whenever it has data to send a client).
to it.
A common communication pattern is that one data transmission is many
times closely followed by another. For instance, if the device needs
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. The NETCONF Server Configuration Model
3.1. Overview 3. The NETCONF Server Model
3.1.1. The "session-options" subtree 3.1. Tree Diagram
module: ietf-netconf-server module: ietf-netconf-server
+--rw netconf-server +--rw netconf-server
+--rw session-options +--rw session-options
+--rw hello-timeout? uint32 | +--rw hello-timeout? uint16
+--rw idle-timeout? uint32 +--rw listen {(ssh-listen or tls-listen)}?
| +--rw max-sessions? uint16
The above subtree illustrates how the ietf-netconf-server YANG module | +--rw idle-timeout? uint16
enables configuration of NETCONF session options, independent of any | +--rw endpoint* [name]
transport or connection strategy. Please see the YANG module | +--rw name string
(Section 3.2) for a complete description of these configuration | +--rw (transport)
knobs. | +--:(ssh) {ssh-listen}?
| | +--rw ssh
3.1.2. The "listen" subtree | | +--rw address? inet:ip-address
module: ietf-netconf-server | | +--rw port? inet:port-number
+--rw netconf-server | | +--rw host-keys
+--rw listen {listen}? | | +--rw host-key* string
+--rw max-sessions? uint16 | +--:(tls) {tls-listen}?
+--rw endpoint* [name] | +--rw tls
+--rw name string | +--rw address? inet:ip-address
+--rw (transport) | +--rw port? inet:port-number
| +--:(ssh) {ssh}? | +--rw certificates
| | +--rw ssh | +--rw certificate* string
| | +--rw address? inet:ip-address +--rw call-home {(ssh-call-home or tls-call-home)}?
| | +--rw port? inet:port-number | +--rw netconf-client* [name]
| | +--rw host-keys | +--rw name string
| | +--rw host-key* string | +--rw (transport)
| +--:(tls) {tls}? | | +--:(ssh) {ssh-call-home}?
| +--rw tls | | | +--rw ssh
| +--rw address? inet:ip-address | | | +--rw endpoints
| +--rw port? inet:port-number | | | | +--rw endpoint* [name]
| +--rw certificates | | | | +--rw name string
| +--rw certificate* string | | | | +--rw address inet:host
+--rw keep-alives | | | | +--rw port? inet:port-number
+--rw interval-secs? uint8 | | | +--rw host-keys
+--rw count-max? uint8 | | | +--rw host-key* string
| | +--:(tls) {tls-call-home}?
The above subtree illustrates how the ietf-netconf-server YANG module | | +--rw tls
enables configuration for listening for remote connections, as | | +--rw endpoints
described in [RFC6242]. Feature statements are used to limit both if | | | +--rw endpoint* [name]
listening is supported at all as well as for which transports. If | | | +--rw name string
listening for connections is supported, then the model enables | | | +--rw address inet:host
configuring a list of listening endpoints, each configured with a | | | +--rw port? inet:port-number
user-specified name (the key field), the transport to use (i.e. SSH, | | +--rw certificates
TLS), and the IP address and port to listen on. The port field is | | +--rw certificate* string
optional, defaulting to the transport-specific port when not | +--rw connection-type
configured. Please see the YANG module (Section 3.2) for a complete | | +--rw (connection-type)?
description of these configuration knobs. | | +--:(persistent-connection)
| | | +--rw persistent!
3.1.3. The "call-home" subtree | | | +--rw idle-timeout? uint32
module: ietf-netconf-server | | | +--rw keep-alives
+--rw netconf-server | | | +--rw max-wait? uint16
+--rw call-home {call-home}? | | | +--rw max-attempts? uint8
+--rw application* [name] | | +--:(periodic-connection)
+--rw name string | | +--rw periodic!
+--rw (transport) | | +--rw idle-timeout? uint16
| +--:(ssh) {ssh}? | | +--rw reconnect_timeout? uint16
| | +--rw ssh | +--rw reconnect-strategy
| | +--rw endpoints | +--rw start-with? enumeration
| | | +--rw endpoint* [name] | +--rw max-attempts? uint8
| | | +--rw name string +--rw ssh {(ssh-listen or ssh-call-home)}?
| | | +--rw address inet:host | +--rw x509 {ssh-x509-certs}?
| | | +--rw port? inet:port-number | +--rw trusted-ca-certs
| | +--rw host-keys | | +--rw trusted-ca-cert* binary
| | +--rw host-key* string | +--rw trusted-client-certs
| +--:(tls) {tls}? | +--rw trusted-client-cert* binary
| +--rw tls +--rw tls {(tls-listen or tls-call-home)}?
| +--rw endpoints
| | +--rw endpoint* [name]
| | +--rw name string
| | +--rw address inet:host
| | +--rw port? inet:port-number
| +--rw certificates
| +--rw certificate* string
+--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
| +--rw linger-secs? uint8
+--rw reconnect-strategy
+--rw start-with? enumeration
+--rw interval-secs? uint8
+--rw count-max? uint8
The above subtree illustrates how the ietf-netconf-server 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. Please see
the YANG module (Section 3.2) for a complete description of these
configuration knobs.
3.1.4. The "ssh" subtree
module: ietf-netconf-server
+--rw netconf-server
+--rw ssh {ssh}?
+--rw x509 {ssh-x509-certs}?
+--rw trusted-ca-certs
| +--rw trusted-ca-cert* binary
+--rw trusted-client-certs
+--rw trusted-client-cert* binary
The above subtree illustrates how the ietf-netconf-server YANG module
enables some SSH configuration independent of if the NETCONF server
is listening or calling home. Specifically, when RFC 6187 is
supported, this data model provides an ability to configure how
client-certificates are authenticated. Please see the YANG module
(Section 3.2) for a complete description of these configuration
knobs.
3.1.5. The "tls" subtree
module: ietf-netconf-server
+--rw netconf-server
+--rw tls {tls}?
+--rw client-auth +--rw client-auth
+--rw trusted-ca-certs +--rw trusted-ca-certs
| +--rw trusted-ca-cert* binary | +--rw trusted-ca-cert* binary
+--rw trusted-client-certs +--rw trusted-client-certs
| +--rw trusted-client-cert* binary | +--rw trusted-client-cert* binary
+--rw cert-maps +--rw cert-maps
+--rw cert-to-name* [id] +--rw cert-to-name* [id]
+--rw id uint32 +--rw id uint32
+--rw fingerprint x509c2n:tls-fingerprint +--rw fingerprint x509c2n:tls-fingerprint
+--rw map-type identityref +--rw map-type identityref
+--rw name string +--rw name string
The above subtree illustrates how the ietf-netconf-server YANG module 3.2. Example Usage
enables TLS configuration independent of if the NETCONF server is 3.2.1. Configuring SSH Transport
listening or calling home. Specifically, this data-model provides 1)
an ability to configure how client-certificates are authenticated and
2) how authenticated client-certificates are mapped to NETCONF user
names. Please see the YANG module (Section 3.2) for a complete
description of these configuration knobs.
3.2. YANG Module The following example illustrates the <get> response from a NETCONF
server that only supports SSH, both listening for incoming
connections as well as calling home to a single NETCONF/RESTCONF
client having two endpoints.
<netconf-server xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-server">
<listen>
<endpoint>
<name>netconf/ssh</name>
<ssh>
<address>11.22.33.44</address>
<host-keys>
<host-key>my-rsa-key</host-key>
<host-key>my-dss-key</host-key>
</host-keys>
</ssh>
</endpoint>
</listen>
<call-home>
<netconf-client>
<name>config-mgr</name>
<ssh>
<endpoints>
<endpoint>
<name>east-data-center</name>
<address>11.22.33.44</address>
</endpoint>
<endpoint>
<name>west-data-center</name>
<address>55.66.77.88</address>
</endpoint>
</endpoints>
<host-keys>
<host-key>my-call-home-x509-key</host-key>
</host-keys>
</ssh>
</netconf-client>
</call-home>
<ssh>
<x509>
<trusted-ca-certs>
<trusted-ca-cert>
QW4gRWFzdGVyIGVnZywgZm9yIHRob3NlIHdobyBtaWdodCBsb29rICA6KQo=
</trusted-ca-cert>
</trusted-ca-certs>
<trusted-client-certs>
<trusted-client-cert>
SSBhbSB0aGUgZWdnIG1hbiwgdGhleSBhcmUgdGhlIGVnZyBtZW4uCg==
</trusted-client-cert>
<trusted-client-cert>
SSBhbSB0aGUgd2FscnVzLCBnb28gZ29vIGcnam9vYi4K
</trusted-client-cert>
</trusted-client-certs>
</x509>
</ssh>
</netconf-server>
3.2.2. Configuring TLS Transport
The following example illustrates the <get> response from a NETCONF
server that only supports TLS, both listening for incoming
connections as well as calling home to a single NETCONF/RESTCONF
client having two endpoints. Please note also the configurations for
authenticating client certificates and mappings authenticated
certificates to NETCONF user names.
<netconf-server xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-server"
xmlns:x509c2n="urn:ietf:params:xml:ns:yang:ietf-x509-cert-to-name">
<listen>
<endpoint>
<name>netconf/tls</name>
<tls>
<address>11.22.33.44</address>
<certificates>
<certificate>fw1.east.example.com</certificate>
</certificates>
</tls>
</endpoint>
</listen>
<call-home>
<netconf-client>
<name>config-mgr</name>
<tls>
<endpoints>
<endpoint>
<name>east-data-center</name>
<address>22.33.44.55</address>
</endpoint>
<endpoint>
<name>west-data-center</name>
<address>33.44.55.66</address>
</endpoint>
</endpoints>
<certificates>
<certificate>IDevID Certificate</certificate>
</certificates>
</tls>
</netconf-client>
</call-home>
<tls>
<client-auth>
<trusted-ca-certs>
<trusted-ca-cert>
WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM
lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk
zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot
NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd
VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER
V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF
NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC
Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN
WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW
QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ
MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ
25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2
RJSUJQFRStS0Cg==
</trusted-ca-cert>
</trusted-ca-certs>
<trusted-client-certs>
<trusted-client-cert>
QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ
MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ
25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2
RV0JCU2t2MXI2SFNHeUFUVkpwSmYyOWtXbUU0NEo5akJrQmdOVkhTTUVY
VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER
UxNQWtHQTFVRUJoTUNWVk14RURBT0JnTlZCQW9UQjJWNApZVzF3YkdVeE
V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF
NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC
Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN
WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW
xWVE1SQXdEZ1lEVlFRSwpFd2RsZUdGdGNHeGxNUk13RVFZRFZRUURFd3B
EVWt3Z1NYTnpkV1Z5TUEwR0NTcUdTSWIzRFFFQkJRVUFBNEdCCkFFc3BK
WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM
TQzcjFZSjk0M1FQLzV5eGUKN2QxMkxCV0dxUjUrbEl5N01YL21ka2M4al
zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot
LS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
</trusted-client-cert>
<trusted-client-cert>
VlEVlFRREV3Vm9ZWEJ3ZVRDQm56QU5CZ2txaGtpRzl3MEJBUUVGQUFPQm
pRQXdnWWtDCmdZRUE1RzRFSWZsS1p2bDlXTW44eUhyM2hObUFRaUhVUzV
rRUpPQy9hSFA3eGJXQW1ra054ZStUa2hrZnBsL3UKbVhsTjhSZUd1ODhG
NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd
VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER
V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF
NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC
Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN
WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW
xWVE1SQXdEZ1lEVlFRSwpFd2RsZUdGdGNHeGxNUk13RVFZRFZRUURFd3B
EVWt3Z1NYTnpkV1Z5TUEwR0NTcUdTSWIzRFFFQkJRVUFBNEdCCkFFc3BK
WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM
lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk
zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot
QWtUOCBDRVUUZJ0RUF==
</trusted-client-cert>
</trusted-client-certs>
<cert-maps>
<cert-to-name>
<id>1</id>
<fingerprint>11:0A:05:11:00</fingerprint>
<map-type>x509c2n:san-any</map-type>
</cert-to-name>
<cert-to-name>
<id>2</id>
<fingerprint>B3:4F:A1:8C:54</fingerprint>
<map-type>x509c2n:specified</map-type>
<name>scooby-doo</name>
</cert-to-name>
</cert-maps>
</client-auth>
</tls>
</netconf-server>
3.3. YANG Model
This YANG module imports YANG types from [RFC6991] and [RFC7407]. This YANG module imports YANG types from [RFC6991] and [RFC7407].
<CODE BEGINS> file "ietf-netconf-server@2015-02-02.yang" <CODE BEGINS> file "ietf-netconf-server@2015-07-06.yang"
module ietf-netconf-server { module ietf-netconf-server {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-server"; namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-server";
prefix "ncserver"; prefix "ncserver";
import ietf-netconf-acm { import ietf-netconf-acm {
prefix nacm; // RFC 6536 prefix nacm; // RFC 6536
revision-date 2012-02-22;
} }
import ietf-inet-types { // RFC 6991 import ietf-inet-types { // RFC 6991
prefix inet; prefix inet;
revision-date 2013-07-15;
} }
import ietf-x509-cert-to-name { // RFC 7407 import ietf-x509-cert-to-name { // RFC 7407
prefix x509c2n; prefix x509c2n;
revision-date 2014-12-10;
} }
organization organization
"IETF NETCONF (Network Configuration) Working Group"; "IETF NETCONF (Network Configuration) Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/netconf/> "WG Web: <http://tools.ietf.org/wg/netconf/>
WG List: <mailto:netconf@ietf.org> WG List: <mailto:netconf@ietf.org>
WG Chair: Mehmet Ersue WG Chair: Mehmet Ersue
skipping to change at page 13, line 18 skipping to change at page 14, line 43
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC VVVV; see This version of this YANG module is part of RFC VVVV; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision "2015-02-02" { revision "2015-07-06" {
description description
"Initial version"; "Initial version";
reference reference
"RFC VVVV: NETCONF Server and RESTCONF Server Configuration Models"; "RFC VVVV: NETCONF Server and RESTCONF Server Configuration
Models";
} }
// Features // Features
feature ssh { feature ssh-listen {
description description
"The ssh feature indicates that the server supports the "The ssh-listen feature indicates that the NETCONF server
SSH transport protocol."; supports opening a port to accept NETCONF over SSH
client connections.";
reference reference
"RFC 6242: Using the NETCONF Protocol over Secure Shell (SSH)"; "RFC 6242: Using the NETCONF Protocol over Secure Shell (SSH)";
} }
feature tls { feature ssh-call-home {
description description
"The tls feature indicates that the server supports the "The ssh-call-home feature indicates that the NETCONF
TLS transport protocol."; server supports initiating a NETCONF over SSH call
home connection to NETCONF clients.";
reference reference
"RFC 5539: NETCONF over Transport Layer Security (TLS)"; "RFC YYYY: NETCONF Call Home and RESTCONF Call Home";
} }
feature listen { feature tls-listen {
description description
"The listen feature indicates that the server supports "The tls-listen feature indicates that the NETCONF server
opening a port to listen for incoming client connections."; supports opening a port to accept NETCONF over TLS
client connections.";
reference reference
"RFC 6242: Using the NETCONF Protocol over Secure Shell (SSH) "RFC 5539: Using the NETCONF Protocol over Transport
RFC 5539: NETCONF over Transport Layer Security (TLS)"; Layer Security (TLS) with Mutual X.509
Authentication";
} }
feature call-home {
feature tls-call-home {
description description
"The call-home feature indicates that the server supports "The tls-call-home feature indicates that the NETCONF
connecting to the client"; server supports initiating a NETCONF over TLS call
home connection to NETCONF clients.";
reference reference
"RFC YYYY: NETCONF Call Home and RESTCONF Call Home"; "RFC YYYY: NETCONF Call Home and RESTCONF Call Home";
} }
feature ssh-x509-certs { feature ssh-x509-certs {
description description
"The ssh-x509-certs feature indicates that the NETCONF server "The ssh-x509-certs feature indicates that the NETCONF server
supports RFC 6187"; supports RFC 6187";
reference reference
"RFC 6187: X.509v3 Certificates for Secure Shell Authentication"; "RFC 6187: X.509v3 Certificates for Secure Shell Authentication";
skipping to change at page 14, line 19 skipping to change at page 16, line 4
"RFC YYYY: NETCONF Call Home and RESTCONF Call Home"; "RFC YYYY: NETCONF Call Home and RESTCONF Call Home";
} }
feature ssh-x509-certs { feature ssh-x509-certs {
description description
"The ssh-x509-certs feature indicates that the NETCONF server "The ssh-x509-certs feature indicates that the NETCONF server
supports RFC 6187"; supports RFC 6187";
reference reference
"RFC 6187: X.509v3 Certificates for Secure Shell Authentication"; "RFC 6187: X.509v3 Certificates for Secure Shell Authentication";
} }
// top-level container (groupings below) // top-level container (groupings below)
container netconf-server { container netconf-server {
description description
"Top-level container for NETCONF server configuration."; "Top-level container for NETCONF server configuration.";
uses session-options-container; container session-options { // SHOULD WE REMOVE THIS ALTOGETHER?
uses listen-container;
uses call-home-container;
uses ssh-container;
uses tls-container;
}
grouping session-options-container {
description
"This grouping is used only to help improve readability
of the YANG module.";
container session-options {
description description
"NETCONF session options, independent of transport "NETCONF session options, independent of transport
or connection strategy."; or connection strategy.";
leaf hello-timeout { leaf hello-timeout {
type uint32 { type uint16;
range "0 | 10 .. 3600";
}
units "seconds";
default '600';
description
"Specifies the number of seconds that a session may exist
before the hello PDU is received. A session will be
dropped if no hello PDU is received before this number
of seconds elapses.
If this parameter is set to zero, then the server will
wait forever for a hello message, and not drop any
sessions stuck in 'hello-wait' state.
Setting this parameter to zero may permit denial of
service attacks, since only a limited number of
concurrent sessions may be supported by the server.";
}
leaf idle-timeout {
type uint32 {
range "0 | 10 .. 360000";
}
units "seconds"; units "seconds";
default '3600'; default 600;
description description
"Specifies the number of seconds that a NETCONF session may "Specifies the maximum number of seconds that a SSH/TLS
remain idle without issuing any RPC requests. A session connection may wait for a hello message to be received.
will be dropped if it is idle for an interval longer than A connection will be dropped if no hello message is
this number of seconds. If this parameter is set to zero, received before this number of seconds elapses. If set
then the server will never drop a session because it is to zero, then the server will wait forever for a hello
idle. Sessions that have a notification subscription message.";
active are never dropped.
This mechanism is independent of keep-alives, as it regards
activity occurring at the NETCONF protocol layer, whereas
the keep-alive mechanism regards transport-level activity.";
} }
} }
}
grouping listen-container {
description
"This grouping is used only to help improve readability
of the YANG module.";
container listen { container listen {
description description
"Configures listen behavior"; "Configures listen behavior";
if-feature listen; if-feature "(ssh-listen or tls-listen)";
leaf max-sessions { leaf max-sessions {
type uint16 { type uint16;
range "0 .. 1024"; default 0;
}
default '0';
description description
"Specifies the maximum number of concurrent sessions "Specifies the maximum number of concurrent sessions
that can be active at one time. The value 0 indicates that can be active at one time. The value 0 indicates
that no artificial session limit should be used."; that no artificial session limit should be used.";
}
leaf idle-timeout {
type uint16;
units "seconds";
default 3600; // one hour
description
"Specifies the maximum number of seconds that a NETCONF
session may remain idle. A NETCONF session will be dropped
if it is idle for an interval longer than this number of
seconds. If set to zero, then the server will never drop
a session because it is idle. Sessions that have a
notification subscription active are never dropped.";
} }
list endpoint { list endpoint {
key name; key name;
description description
"List of endpoints to listen for NETCONF connections on."; "List of endpoints to listen for NETCONF connections on.";
leaf name { leaf name {
type string; type string;
description description
"An arbitrary name for the NETCONF listen endpoint."; "An arbitrary name for the NETCONF listen endpoint.";
} }
choice transport { choice transport {
mandatory true; mandatory true;
description description
"Selects between SSH and TLS transports."; "Selects between available transports.";
case ssh { case ssh {
if-feature ssh; if-feature ssh-listen;
container ssh { container ssh {
description description
"SSH-specific listening configuration for inbound "SSH-specific listening configuration for inbound
connections."; connections.";
uses address-and-port-grouping { uses address-and-port-grouping {
refine port { refine port {
default 830; default 830;
} }
} }
uses host-keys-container; uses host-keys-grouping;
} }
} }
case tls { case tls {
if-feature tls; if-feature tls-listen;
container tls { container tls {
description description
"TLS-specific listening configuration for inbound "TLS-specific listening configuration for inbound
connections."; connections.";
uses address-and-port-grouping { uses address-and-port-grouping {
refine port { refine port {
default 6513; default 6513;
} }
} }
uses certificates-container; uses certificates-grouping;
} }
} }
} }
uses keep-alives-container {
refine keep-alives/interval-secs {
default 0; // disabled by default for listen connections
}
}
} }
} }
}
grouping call-home-container {
description
"This grouping is used only to help improve readability
of the YANG module.";
container call-home { container call-home {
if-feature call-home; if-feature "(ssh-call-home or tls-call-home)";
description description
"Configures call-home behavior"; "Configures call-home behavior";
list application {
list netconf-client {
key name; key name;
description description
"List of NETCONF clients the NETCONF server is to initiate "List of NETCONF clients the NETCONF server is to initiate
call-home connections to."; call-home connections to.";
leaf name { leaf name {
type string; type string;
description description
"An arbitrary name for the remote NETCONF client."; "An arbitrary name for the remote NETCONF client.";
} }
choice transport { choice transport {
mandatory true; mandatory true;
description description
"Selects between available transports."; "Selects between available transports.";
case ssh { case ssh {
if-feature ssh; if-feature ssh-call-home;
container ssh { container ssh {
description description
"Specifies SSH-specific call-home transport "Specifies SSH-specific call-home transport
configuration."; configuration.";
uses endpoints-container { uses endpoints-container {
refine endpoints/endpoint/port { refine endpoints/endpoint/port {
default 7777; default 7777;
} }
} }
uses host-keys-container; uses host-keys-grouping;
} }
} }
case tls { case tls {
if-feature tls; if-feature tls-call-home;
container tls { container tls {
description description
"Specifies TLS-specific call-home transport "Specifies TLS-specific call-home transport
configuration."; configuration.";
uses endpoints-container { uses endpoints-container {
refine endpoints/endpoint/port { refine endpoints/endpoint/port {
default 8888; default 8888;
} }
} }
uses certificates-container; uses certificates-grouping;
} }
} }
} }
container connection-type { container connection-type {
description description
"Indicates the kind of connection to use."; "Indicates the kind of connection to use.";
choice connection-type { choice connection-type {
default persistent-connection;
description description
"Selects between persistent and periodic connections."; "Selects between available connection types.";
case persistent-connection { case persistent-connection {
container persistent { container persistent {
presence true;
description description
"Maintain a persistent connection to the NETCONF "Maintain a persistent connection to the NETCONF
client. If the connection goes down, immediately client. If the connection goes down, immediately
start trying to reconnect to it, using the start trying to reconnect to it, using the
reconnection strategy. reconnection strategy.
This connection type minimizes any NETCONF client This connection type minimizes any NETCONF client
to NETCONF server data-transfer delay, albeit at to NETCONF server data-transfer delay, albeit at
the expense of holding resources longer."; the expense of holding resources longer.";
uses keep-alives-container { leaf idle-timeout {
refine keep-alives/interval-secs { type uint32;
default 15; // 15 seconds for call-home sessions units "seconds";
default 86400; // one day;
description
"Specifies the maximum number of seconds that a
a NETCONF session may remain idle. A NETCONF
session will be dropped if it is idle for an
interval longer than this number of seconds.
If set to zero, then the server will never drop
a session because it is idle. Sessions that
have a notification subscription active are
never dropped.";
}
container keep-alives {
description
"Configures the keep-alive policy, to proactively
test the aliveness of the SSH/TLS client. An
unresponsive SSH/TLS client will be dropped after
approximately (max-attempts * max-wait) seconds.";
reference
"RFC YYYY: NETCONF Call Home and RESTCONF Call Home,
Section 3.1, item S6";
leaf max-wait {
type uint16 {
range "1..max";
}
units seconds;
default 30;
description
"Sets the amount of time in seconds after which
if no data has been received from the SSH/TLS
client, a SSH/TLS-level message will be sent
to test the aliveness of the SSH/TLS client.";
}
leaf max-attempts {
type uint8;
default 3;
description
"Sets the number of sequential keep-alive messages
that can fail to obtain a response from the SSH/TLS
client before assuming the SSH/TLS client is no
longer alive.";
} }
} }
} }
} }
case periodic-connection { case periodic-connection {
container periodic { container periodic {
presence true;
description description
"Periodically connect to NETCONF client, using the "Periodically connect to the NETCONF client, so that
reconnection strategy, so the NETCONF client can the NETCONF client may deliver messages pending for
deliver pending messages to the NETCONF server. the NETCONF server. The NETCONF client is expected
to close the connection when it is ready to release
For messages the NETCONF server wants to send to it, thus starting the NETCONF server's timer until
to the NETCONF client, the NETCONF server should next connection.";
proactively connect to the NETCONF client, if leaf idle-timeout {
not already, to send the messages immediately."; type uint16;
leaf timeout-mins { units "seconds";
type uint8; default 300; // five minutes
units minutes;
default 5;
description description
"The maximum amount of unconnected time the NETCONF "Specifies the maximum number of seconds that a
server will wait until establishing a connection to a NETCONF session may remain idle. A NETCONF
the NETCONF client again. The NETCONF server MAY session will be dropped if it is idle for an
establish a connection before this time if it has interval longer than this number of seconds.
data it needs to send to the NETCONF client. Note: If set to zero, then the server will never drop
this value differs from the reconnection strategy's a session because it is idle. Sessions that
interval-secs value."; have a notification subscription active are
never dropped.";
} }
leaf linger-secs { leaf reconnect_timeout {
type uint8; type uint16 {
units seconds; range "1..max";
default 30; }
units minutes;
default 60;
description description
"The amount of time the NETCONF server should wait "The maximum amount of unconnected time the NETCONF
after last receiving data from or sending data to server will wait before establishing a connection
the NETCONF client's endpoint before closing its to the NETCONF client. The NETCONF server may
connection to it. This is an optimization to initiate a connection before this time if desired
prevent unnecessary connections."; (e.g., to deliver a notification).";
} }
} }
} }
} }
} }
container reconnect-strategy { container reconnect-strategy {
description description
"The reconnection strategy guides how a NETCONF server "The reconnection strategy guides how a NETCONF server
reconnects to an NETCONF client, after losing a connection reconnects to an NETCONF client, after losing a connection
to it, even if due to a reboot. The NETCONF server starts to it, even if due to a reboot. The NETCONF server starts
with the specified endpoint and tries to connect to it with the specified endpoint and tries to connect to it
count-max times, waiting interval-secs between each max-attempts times before trying the next endpoint in the
connection attempt, before trying the next endpoint in list (round robin).";
the list (round robin).";
leaf start-with { leaf start-with {
type enumeration { type enumeration {
enum first-listed { enum first-listed {
description description
"Indicates that reconnections should start with "Indicates that reconnections should start with
the first endpoint listed."; the first endpoint listed.";
} }
enum last-connected { enum last-connected {
description description
"Indicates that reconnections should start with "Indicates that reconnections should start with
the endpoint last connected to. NETCONF servers the endpoint last connected to. If no previous
SHOULD support this flag across reboots."; connection has ever been established, then the
first endpoint configured is used. NETCONF
servers SHOULD be able to remember the last
endpoint connected to across reboots.";
} }
} }
default first-listed; default first-listed;
description description
"Specifies which of the NETCONF client's endpoints the "Specifies which of the NETCONF client's endpoints the
NETCONF server should start with when trying to connect NETCONF server should start with when trying to connect
to the NETCONF client. If no previous connection has to the NETCONF client.";
ever been established, last-connected defaults to
the first endpoint listed.";
}
leaf interval-secs {
type uint8;
units seconds;
default 5;
description
"Specifies the time delay between connection attempts
to the same endpoint. Note: this value differs from
the periodic-connection's timeout-mins value.";
} }
leaf count-max { leaf max-attempts {
type uint8; type uint8 {
range "1..max";
}
default 3; default 3;
description description
"Specifies the number times the NETCONF server tries to "Specifies the number times the NETCONF server tries to
connect to a specific endpoint before moving on to the connect to a specific endpoint before moving on to the
next endpoint in the list (round robin)."; next endpoint in the list (round robin).";
} }
} }
} }
} }
}
grouping ssh-container {
description
"This grouping is used only to help improve readability
of the YANG module.";
container ssh { container ssh {
description description
"Configures SSH properties not specific to the listen "Configures SSH properties not specific to the listen
or call-home use-cases"; or call-home use-cases";
if-feature ssh; if-feature "(ssh-listen or ssh-call-home)";
container x509 { container x509 {
if-feature ssh-x509-certs; if-feature ssh-x509-certs;
uses trusted-certs-grouping; uses trusted-certs-grouping;
} }
} }
}
grouping tls-container {
description
"This grouping is used only to help improve readability
of the YANG module.";
container tls { container tls {
description description
"Configures TLS properties for authenticating clients."; "Configures TLS properties for authenticating clients.";
if-feature tls; if-feature "(tls-listen or tls-call-home)";
container client-auth { container client-auth {
description description
"Container for TLS client authentication configuration."; "Container for TLS client authentication configuration.";
uses trusted-certs-grouping; uses trusted-certs-grouping;
container cert-maps { container cert-maps {
uses x509c2n:cert-to-name; uses x509c2n:cert-to-name;
description description
"The cert-maps container is used by a NETCONF server to "The cert-maps container is used by a NETCONF server to
map the NETCONF client's presented X.509 certificate to a map the NETCONF client's presented X.509 certificate to a
NETCONF username. If no matching and valid cert-to-name NETCONF username. If no matching and valid cert-to-name
list entry can be found, then the NETCONF server MUST list entry can be found, then the NETCONF server MUST
close the connection, and MUST NOT accept NETCONF close the connection, and MUST NOT accept NETCONF
messages over it."; messages over it.";
reference
"RFC WWWW: NETCONF over TLS, Section 7";
} }
} }
} }
} }
grouping trusted-certs-grouping { grouping trusted-certs-grouping {
description description
"This grouping is used by both the ssh and tls containers."; "This grouping is used by both the ssh and tls containers.";
container trusted-ca-certs { container trusted-ca-certs {
description description
"A list of Certificate Authority (CA) certificates that "A list of Certificate Authority (CA) certificates that
a NETCONF server can use to authenticate NETCONF client a NETCONF server can use to authenticate NETCONF client
certificates. A client's certificate is authenticated certificates.";
if there is a chain of trust to a configured trusted CA reference
certificate. The client certificate MAY be accompanied "RFC WWWW: NETCONF over TLS, Sections 5 and 7.
with additional certificates forming a chain of trust. RFC 4253: The Secure Shell (SSH) Transport Layer Protocol,
The client's certificate is authenticated if there is Section 8, #3.
path-validation from any of the certificates it presents RFC 6187: X.509v3 Certificates for Secure Shell
to a configured trust anchor."; Authentication.";
leaf-list trusted-ca-cert { leaf-list trusted-ca-cert {
type binary; type binary;
ordered-by system;
nacm:default-deny-write; nacm:default-deny-write;
description description
"The binary certificate structure as specified by RFC "The binary certificate structure as specified by RFC
5246, Section 7.4.6, i.e.,: opaque ASN.1Cert<1..2^24>; 5246, Section 7.4.6, i.e.,: opaque ASN.1Cert<1..2^24>;
"; ";
reference reference
"RFC 5246: The Transport Layer Security (TLS) "RFC 5246: The Transport Layer Security (TLS)
Protocol Version 1.2"; Protocol Version 1.2";
} }
} }
container trusted-client-certs { container trusted-client-certs {
description description
"A list of client certificates that a NETCONF server can "A list of client certificates that a NETCONF server can
use to authenticate a NETCONF client's certificate. A use to authenticate a NETCONF client's certificate. A
client's certificate is authenticated if it is an exact client's certificate is authenticated if it is an exact
skipping to change at page 22, line 15 skipping to change at page 23, line 24
reference reference
"RFC 5246: The Transport Layer Security (TLS) "RFC 5246: The Transport Layer Security (TLS)
Protocol Version 1.2"; Protocol Version 1.2";
} }
} }
container trusted-client-certs { container trusted-client-certs {
description description
"A list of client certificates that a NETCONF server can "A list of client certificates that a NETCONF server can
use to authenticate a NETCONF client's certificate. A use to authenticate a NETCONF client's certificate. A
client's certificate is authenticated if it is an exact client's certificate is authenticated if it is an exact
match to a configured trusted client certificates."; match to a configured trusted client certificate.";
leaf-list trusted-client-cert { leaf-list trusted-client-cert {
type binary; type binary;
ordered-by system;
nacm:default-deny-write; nacm:default-deny-write;
description description
"The binary certificate structure, as "The binary certificate structure, as
specified by RFC 5246, Section 7.4.6, i.e.,: specified by RFC 5246, Section 7.4.6, i.e.,:
opaque ASN.1Cert<1..2^24>; opaque ASN.1Cert<1..2^24>;
"; ";
reference reference
"RFC 5246: The Transport Layer Security (TLS) "RFC 5246: The Transport Layer Security (TLS)
Protocol Version 1.2"; Protocol Version 1.2";
} }
} }
} }
grouping host-keys-container { grouping host-keys-grouping {
description description
"This grouping is used by both the listen and "This grouping is used by both the listen and
call-home containers"; call-home containers";
container host-keys { container host-keys {
description description
"Parent container for the list of host-keys."; "Parent container for the list of host-keys.";
leaf-list host-key { leaf-list host-key {
type string; type string;
min-elements 1; min-elements 1;
ordered-by user; ordered-by user;
skipping to change at page 23, line 12 skipping to change at page 24, line 21
on the system. How valid values are discovered is on the system. How valid values are discovered is
outside the scope of this module, but they are outside the scope of this module, but they are
envisioned to be the keys for a list of host-keys envisioned to be the keys for a list of host-keys
provided by another YANG module"; provided by another YANG module";
reference reference
"RFC 4253: The SSH Transport Layer Protocol, Section 7"; "RFC 4253: The SSH Transport Layer Protocol, Section 7";
} }
} }
} }
grouping certificates-container { grouping certificates-grouping {
description description
"This grouping is used by both the listen and "This grouping is used by both the listen and
call-home containers"; call-home containers";
container certificates { container certificates {
description description
"Parent container for the list of certificates."; "Parent container for the list of certificates.";
leaf-list certificate { leaf-list certificate {
type string; type string;
min-elements 1; min-elements 1;
description description
skipping to change at page 23, line 38 skipping to change at page 24, line 47
to be the keys for a list of certificates provided to be the keys for a list of certificates provided
by another YANG module"; by another YANG module";
reference reference
"RFC 5246: The TLS Protocol, Section 7.4.2"; "RFC 5246: The TLS Protocol, Section 7.4.2";
} }
} }
} }
grouping address-and-port-grouping { grouping address-and-port-grouping {
description description
"This grouping is usd by both the ssh and tls containers "This grouping is used by both the ssh and tls containers
for listen configuration."; for listen configuration.";
leaf address { leaf address {
type inet:ip-address; type inet:ip-address;
description description
"The IP address of the interface to listen on."; "The IP address of the interface to listen on. The NETCONF
server will listen on all interfaces if no value is
specified.";
} }
leaf port { leaf port {
type inet:port-number; type inet:port-number;
description description
"The local port number on this interface the NETCONF server "The local port number on this interface the NETCONF server
listens on."; listens on. The NETCONF server will use the IANA-assigned
well-known port if no value is specified.";
} }
} }
grouping endpoints-container { grouping endpoints-container {
description description
"This grouping is used by both the ssh and tls containers "This grouping is used by both the ssh and tls containers
for call-home configurations."; for call-home configurations.";
container endpoints { container endpoints {
description description
"Container for the list of endpoints."; "Container for the list of endpoints.";
list endpoint { list endpoint {
key name; key name;
min-elements 1; min-elements 1;
skipping to change at page 24, line 21 skipping to change at page 25, line 34
list endpoint { list endpoint {
key name; key name;
min-elements 1; min-elements 1;
ordered-by user; ordered-by user;
description description
"User-ordered list of endpoints for this NETCONF client. "User-ordered list of endpoints for this NETCONF client.
Defining more than one enables high-availability."; Defining more than one enables high-availability.";
leaf name { leaf name {
type string; type string;
description description
"An arbitrary name for the endpoint to connect to."; "An arbitrary name for this endpoint.";
} }
leaf address { leaf address {
type inet:host; type inet:host;
mandatory true; mandatory true;
description description
"The hostname or IP address or hostname of the endpoint. "The IP address or hostname of the endpoint. If a
If a hostname is provided and DNS resolves to more than hostname is configured and the DNS resolution results
one IP address, the NETCONF server SHOULD try all of in more than one IP address, the NETCONF server
the ones it can based on how its networking stack is will process the IP addresses as if they had been
configured (e.g. v4, v6, dual-stack)."; explicitly configured in place of the hostname.";
} }
leaf port { leaf port {
type inet:port-number; type inet:port-number;
description description
"The IP port for this endpoint. The NETCONF server will "The IP port for this endpoint. The NETCONF server will
use the IANA-assigned well-known port if not specified."; use the IANA-assigned well-known port if no value is
specified.";
} }
} }
} }
} }
grouping keep-alives-container {
description
"This grouping is use by both listen and call-home configurations.";
container keep-alives {
description
"Configures the keep-alive policy, to proactively test the
aliveness of the NETCONF client.";
reference
"RFC VVVV: NETCONF Server and RESTCONF Server Configuration
Models, Section 4";
leaf interval-secs {
type uint8;
units seconds;
description
"Sets a timeout interval in seconds after which if no data
has been received from the NETCONF client, a message will
be sent to request a response from the NETCONF client. A
value of '0' indicates that no keep-alive messages should
be sent.";
}
leaf count-max {
type uint8;
default 3;
description
"Sets the number of keep-alive messages that may be sent
without receiving any data from the NETCONF client before
assuming the NETCONF client is no longer alive. If this
threshold is reached, the transport-level connection will
be disconnected, which will trigger the reconnection
strategy). The interval timer is reset after each
transmission, thus an unresponsive NETCONF client will
be dropped after approximately (count-max * interval-secs)
seconds.";
}
}
}
} }
<CODE ENDS> <CODE ENDS>
4. The RESTCONF Server Configuration Model 4. The RESTCONF Server Model
4.1. Overview
4.1.1. The "listen" subtree
module: ietf-restconf-server
+--rw restconf-server
+--rw listen {listen}?
+--rw max-sessions? uint16
+--rw endpoint* [name]
+--rw name string
+--rw (transport)
| +--:(tls)
| +--rw tls
| +--rw address? inet:ip-address
| +--rw port? inet:port-number
| +--rw certificates
| +--rw certificate* string
+--rw keep-alives
+--rw interval-secs? uint8
+--rw count-max? uint8
The above subtree illustrates how the ietf-restconf-server YANG
module enables configuration for listening for remote connections, as
described in [draft-ietf-netconf-restconf]. 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. TLS), and the IP address and port to listen on. The
port field is optional, defaulting to the transport-specific port
when not configured. Please see the YANG module (Section 4.2) for a
complete description of these configuration knobs.
4.1.2. The "call-home" subtree
module: ietf-restconf-server
+--rw restconf-server
+--rw call-home {call-home}?
+--rw application* [name]
+--rw name string
+--rw (transport)
| +--:(tls) {tls}?
| +--rw tls
| +--rw endpoints
| | +--rw endpoint* [name]
| | +--rw name string
| | +--rw address inet:host
| | +--rw port? inet:port-number
| +--rw certificates
| +--rw certificate* string
+--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
| +--rw linger-secs? uint8
+--rw reconnect-strategy
+--rw start-with? enumeration
+--rw interval-secs? uint8
+--rw count-max? uint8
The above subtree illustrates how the ietf-restconf-server 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. 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. Please see
the YANG module (Section 4.2) for a complete description of these
configuration knobs.
4.1.3. The "client-cert-auth" subtree 4.1. Tree Diagram
module: ietf-restconf-server module: ietf-restconf-server
+--rw restconf-server +--rw restconf-server
+--rw listen {tls-listen}?
| +--rw max-sessions? uint16
| +--rw endpoint* [name]
| +--rw name string
| +--rw (transport)
| +--:(tls)
| +--rw tls
| +--rw address? inet:ip-address
| +--rw port? inet:port-number
| +--rw certificates
| +--rw certificate* string
+--rw call-home {tls-call-home}?
| +--rw restconf-client* [name]
| +--rw name string
| +--rw (transport)
| | +--:(tls)
| | +--rw tls
| | +--rw endpoints
| | | +--rw endpoint* [name]
| | | +--rw name string
| | | +--rw address inet:host
| | | +--rw port? inet:port-number
| | +--rw certificates
| | +--rw certificate* string
| +--rw connection-type
| | +--rw (connection-type)?
| | +--:(persistent-connection)
| | | +--rw persistent!
| | | +--rw keep-alives
| | | +--rw max-wait? uint16
| | | +--rw max-attempts? uint8
| | +--:(periodic-connection)
| | +--rw periodic!
| | +--rw reconnect-timeout? uint16
| +--rw reconnect-strategy
| +--rw start-with? enumeration
| +--rw max-attempts? uint8
+--rw client-cert-auth {client-cert-auth}? +--rw client-cert-auth {client-cert-auth}?
+--rw trusted-ca-certs +--rw trusted-ca-certs
| +--rw trusted-ca-cert* binary | +--rw trusted-ca-cert* binary
+--rw trusted-client-certs +--rw trusted-client-certs
| +--rw trusted-client-cert* binary | +--rw trusted-client-cert* binary
+--rw cert-maps +--rw cert-maps
+--rw cert-to-name* [id] +--rw cert-to-name* [id]
+--rw id uint32 +--rw id uint32
+--rw fingerprint x509c2n:tls-fingerprint +--rw fingerprint x509c2n:tls-fingerprint
+--rw map-type identityref +--rw map-type identityref
+--rw name string +--rw name string
The above subtree illustrates how the ietf-restconf-server YANG 4.2. Example Usage
module enables configuration of client-certificate authentication.
Specifically, this data-model provides 1) an ability to configure how
client-certificates are authenticated and 2) how authenticated
client-certificates are mapped to RESTCONF user names. Please see
the YANG module (Section 4.2) for a complete description of these
configuration knobs.
4.2. YANG Module 4.2.1. Configuring TLS Transport
The following example illustrates the <get> response from a RESTCONF
server that only supports TLS, both listening for incoming
connections as well as calling home to a single RESTCONF client
having two endpoints.
<restconf-server xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf-server">
<listen>
<endpoint>
<name>primary-restconf-endpoint</name>
<tls>
<address>11.22.33.44</address>
<certificates>
<certificate>fw1.east.example.com</certificate>
</certificates>
</tls>
</endpoint>
</listen>
<call-home>
<restconf-client>
<name>config-mgr</name>
<tls>
<endpoints>
<endpoint>
<name>east-data-center</name>
<address>11.22.33.44</address>
</endpoint>
<endpoint>
<name>west-data-center</name>
<address>55.66.77.88</address>
</endpoint>
</endpoints>
<certificates>
<certificate>fw1.east.example.com</certificate>
</certificates>
</tls>
</restconf-client>
</call-home>
</restconf-server>
4.3. YANG Model
This YANG module imports YANG types from [RFC6991] and [RFC7407]. This YANG module imports YANG types from [RFC6991] and [RFC7407].
<CODE BEGINS> file "ietf-restconf-server@2015-02-02.yang" <CODE BEGINS> file "ietf-restconf-server@2015-07-06.yang"
module ietf-restconf-server { module ietf-restconf-server {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-restconf-server"; namespace "urn:ietf:params:xml:ns:yang:ietf-restconf-server";
prefix "rcserver"; prefix "rcserver";
import ietf-netconf-acm { import ietf-netconf-acm {
prefix nacm; // RFC 6536 prefix nacm; // RFC 6536
revision-date 2012-02-22;
} }
import ietf-inet-types { // RFC 6991 import ietf-inet-types { // RFC 6991
prefix inet; prefix inet;
revision-date 2013-07-15;
} }
import ietf-x509-cert-to-name { // RFC 7407 import ietf-x509-cert-to-name { // RFC 7407
prefix x509c2n; prefix x509c2n;
revision-date 2014-12-10;
} }
organization organization
"IETF NETCONF (Network Configuration) Working Group"; "IETF NETCONF (Network Configuration) Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/netconf/> "WG Web: <http://tools.ietf.org/wg/netconf/>
WG List: <mailto:netconf@ietf.org> WG List: <mailto:netconf@ietf.org>
WG Chair: Mehmet Ersue WG Chair: Mehmet Ersue
<mailto:mehmet.ersue@nsn.com> <mailto:mehmet.ersue@nsn.com>
skipping to change at page 29, line 37 skipping to change at page 29, line 46
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC VVVV; see This version of this YANG module is part of RFC VVVV; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision "2015-02-02" { revision "2015-07-06" {
description description
"Initial version"; "Initial version";
reference reference
"RFC VVVV: NETCONF Server and RESTCONF Server Configuration Models"; "RFC VVVV: NETCONF Server and RESTCONF Server Configuration
Models";
} }
// Features // Features
feature tls { feature tls-listen {
description
"The tls feature indicates that the server supports RESTCONF
over the TLS transport protocol.";
reference
"RFC XXXX: RESTCONF Protocol";
}
feature listen {
description description
"The listen feature indicates that the server supports "The listen feature indicates that the RESTCONF server
opening a port to listen for incoming client connections."; supports opening a port to listen for incoming RESTCONF
client connections.";
reference reference
"RFC XXXX: RESTCONF Protocol"; "RFC XXXX: RESTCONF Protocol";
} }
feature call-home { feature tls-call-home {
description description
"The call-home feature indicates that the server supports "The call-home feature indicates that the RESTCONF server
connecting to the client."; supports initiating connections to RESTCONF clients.";
reference reference
"RFC YYYY: NETCONF Call Home and RESTCONF Call Home"; "RFC YYYY: NETCONF Call Home and RESTCONF Call Home";
} }
feature client-cert-auth { feature client-cert-auth {
description description
"The client-cert-auth feature indicatres that the server "The client-cert-auth feature indicates that the RESTCONF
supports the ClientCertificate authentication scheme."; server supports the ClientCertificate authentication scheme.";
reference reference
"RFC ZZZZ: Client Authentication over New TLS Connection"; "RFC ZZZZ: Client Authentication over New TLS Connection";
} }
// top-level container (groupings below) // top-level container (groupings below)
container restconf-server { container restconf-server {
description description
"Top-level container for RESTCONF server configuration."; "Top-level container for RESTCONF server configuration.";
uses listen-container;
uses call-home-container;
uses client-cert-auth-container;
}
grouping listen-container {
description
"This grouping is used only to help improve readability
of the YANG module.";
container listen { container listen {
description description
"Configures listen behavior"; "Configures listen behavior";
if-feature listen; if-feature tls-listen;
leaf max-sessions { leaf max-sessions {
type uint16 { type uint16;
range "0 .. 1024"; default 0; // should this be 'max'?
}
default '0';
description description
"Specifies the maximum number of concurrent sessions "Specifies the maximum number of concurrent sessions
that can be active at one time. The value 0 indicates that can be active at one time. The value 0 indicates
that no artificial session limit should be used."; that no artificial session limit should be used.";
} }
list endpoint { list endpoint {
key name; key name;
description description
"List of endpoints to listen for RESTCONF connections on."; "List of endpoints to listen for RESTCONF connections on.";
leaf name { leaf name {
type string; type string;
description description
"An arbitrary name for the RESTCONF listen endpoint."; "An arbitrary name for the RESTCONF listen endpoint.";
} }
skipping to change at page 31, line 32 skipping to change at page 31, line 24
} }
choice transport { choice transport {
mandatory true; mandatory true;
description description
"Selects between available transports."; "Selects between available transports.";
case tls { case tls {
container tls { container tls {
description description
"TLS-specific listening configuration for inbound "TLS-specific listening configuration for inbound
connections."; connections.";
uses address-and-port-grouping { leaf address {
refine port { type inet:ip-address;
default 443; description
} "The IP address of the interface to listen on. The
RESTCONF server will listen on all interfaces if
no value is specified.";
} }
uses certificates-container; leaf port {
type inet:port-number;
default 443;
description
"The port number the RESTCONF server will listen on.";
}
uses certificates-grouping;
} }
} }
} }
uses keep-alives-container {
refine keep-alives/interval-secs {
default 0; // disabled by default for listen connections
}
}
} }
} }
}
grouping call-home-container {
description
"This grouping is used only to help improve readability
of the YANG module.";
container call-home { container call-home {
if-feature call-home; if-feature tls-call-home;
description description
"Configures call-home behavior"; "Configures call-home behavior";
list application { list restconf-client {
key name; key name;
description description
"List of RESTCONF clients the RESTCONF server is to initiate "List of RESTCONF clients the RESTCONF server is to
call-home connections to."; initiate call-home connections to.";
leaf name { leaf name {
type string; type string;
description description
"An arbitrary name for the remote RESTCONF client."; "An arbitrary name for the remote RESTCONF client.";
} }
choice transport { choice transport {
mandatory true; mandatory true;
description description
"Selects between TLS and any future transports augmented in."; "Selects between TLS and any transports augmented in.";
case tls { case tls {
if-feature tls;
container tls { container tls {
description description
"Specifies TLS-specific call-home transport "Specifies TLS-specific call-home transport
configuration."; configuration.";
uses endpoints-container { container endpoints {
refine endpoints/endpoint/port { description
default 9999; "Container for the list of endpoints.";
list endpoint {
key name;
min-elements 1;
ordered-by user;
description
"User-ordered list of endpoints for this RESTCONF
client. More than one enables high-availability.";
leaf name {
type string;
description
"An arbitrary name for this endpoint.";
}
leaf address {
type inet:host;
mandatory true;
description
"The IP address or hostname of the endpoint. If
a hostname is configured and the DNS resolution
results in more than one IP address, the RESTCONF
server will process the IP addresses as if they
had been explicitly configured in place of the
hostname.";
}
leaf port {
type inet:port-number;
default 9999;
description
"The IP port for this endpoint. The RESTCONF
server will use the IANA-assigned well-known
port if no value is specified.";
}
} }
} }
uses certificates-container; uses certificates-grouping;
} }
} }
} }
container connection-type { container connection-type {
description description
"Indicates the RESTCONF client's preference for how the "Indicates the RESTCONF client's preference for how the
RESTCONF server's connection is maintained."; RESTCONF server's connection is maintained.";
choice connection-type { choice connection-type {
default persistent-connection;
description description
"Selects between persistent and periodic connections."; "Selects between available connection types.";
case persistent-connection { case persistent-connection {
container persistent { container persistent {
presence true;
description description
"Maintain a persistent connection to the RESTCONF "Maintain a persistent connection to the RESTCONF
client. If the connection goes down, immediately client. If the connection goes down, immediately
start trying to reconnect to it, using the start trying to reconnect to it, using the
reconnection strategy. reconnection strategy.
This connection type minimizes any RESTCONF client This connection type minimizes any RESTCONF client
to RESTCONF server data-transfer delay, albeit at to RESTCONF server data-transfer delay, albeit at
the expense of holding resources longer."; the expense of holding resources longer.";
uses keep-alives-container {
refine keep-alives/interval-secs { container keep-alives {
default 15; // 15 seconds for call-home sessions description
"Configures the keep-alive policy, to proactively
test the aliveness of the TLS client. An
unresponsive TLS client will be dropped after
approximately (max-attempts * max-wait) seconds.";
reference
"RFC YYYY: NETCONF Call Home and RESTCONF Call Home,
Section 3.1, item S6";
leaf max-wait {
type uint16 {
range "1..max";
}
units seconds;
default 30;
description
"Sets the amount of time in seconds after which
if no data has been received from the TLS
client, a TLS-level message will be sent to
test the aliveness of the TLS client.";
}
leaf max-attempts {
type uint8;
default 3;
description
"Sets the number of sequential keep-alive messages
that can fail to obtain a response from the TLS
client before assuming the TLS client is no
longer alive.";
} }
} }
} }
} }
case periodic-connection { case periodic-connection {
container periodic { container periodic {
presence true;
description description
"Periodically connect to RESTCONF client, using the "Periodically connect to the RESTCONF client, so that
reconnection strategy, so the RESTCONF client can the RESTCONF client may deliver messages pending for
deliver pending messages to the RESTCONF server. the RESTCONF server. The RESTCONF client is expected
to close the connection when it is ready to release
For messages the RESTCONF server wants to send to it, thus starting the RESTCONF server's timer until
to the RESTCONF client, the RESTCONF server should next connection.";
proactively connect to the RESTCONF client, if leaf reconnect-timeout {
not already, to send the messages immediately."; type uint16 {
leaf timeout-mins { range "1..max";
type uint8; }
units minutes; units minutes;
default 5; default 60;
description description
"The maximum amount of unconnected time the RESTCONF "The maximum amount of unconnected time the RESTCONF
server will wait until establishing a connection to server will wait before re-establishing a connection
the RESTCONF client again. The RESTCONF server MAY to the RESTCONF client. The RESTCONF server may
establish a connection before this time if it has initiate a connection before this time if desired
data it needs to send to the RESTCONF client. Note: (e.g., to deliver a notification).";
this value differs from the reconnection strategy's
interval-secs value.";
}
leaf linger-secs {
type uint8;
units seconds;
default 30;
description
"The amount of time the RESTCONF server should wait
after last receiving data from or sending data to
the RESTCONF client's endpoint before closing its
connection to it. This is an optimization to
prevent unnecessary connections.";
} }
} }
} }
} }
} }
container reconnect-strategy { container reconnect-strategy {
description description
"The reconnection strategy guides how a RESTCONF server "The reconnection strategy guides how a RESTCONF server
reconnects to an RESTCONF client, after losing a connection reconnects to an RESTCONF client, after losing a connection
to it, even if due to a reboot. The RESTCONF server starts to it, even if due to a reboot. The RESTCONF server starts
with the specified endpoint and tries to connect to it with the specified endpoint and tries to connect to it
skipping to change at page 34, line 15 skipping to change at page 34, line 48
} }
} }
} }
} }
container reconnect-strategy { container reconnect-strategy {
description description
"The reconnection strategy guides how a RESTCONF server "The reconnection strategy guides how a RESTCONF server
reconnects to an RESTCONF client, after losing a connection reconnects to an RESTCONF client, after losing a connection
to it, even if due to a reboot. The RESTCONF server starts to it, even if due to a reboot. The RESTCONF server starts
with the specified endpoint and tries to connect to it with the specified endpoint and tries to connect to it
count-max times, waiting interval-secs between each max-attempts times before trying the next endpoint in the
connection attempt, before trying the next endpoint in list (round robin).";
the list (round robin).";
leaf start-with { leaf start-with {
type enumeration { type enumeration {
enum first-listed { enum first-listed {
description description
"Indicates that reconnections should start with "Indicates that reconnections should start with
the first endpoint listed."; the first endpoint listed.";
} }
enum last-connected { enum last-connected {
description description
"Indicates that reconnections should start with "Indicates that reconnections should start with
the endpoint last connected to. RESTCONF servers the endpoint last connected to. If no previous
SHOULD support this flag across reboots."; connection has ever been established, then the
first endpoint configured is used. RESTCONF
servers SHOULD be able to remember the last
endpoint connected to across reboots.";
} }
} }
default first-listed; default first-listed;
description description
"Specifies which of the RESTCONF client's endpoints the "Specifies which of the RESTCONF client's endpoints the
RESTCONF server should start with when trying to connect RESTCONF server should start with when trying to connect
to the RESTCONF client. If no previous connection has to the RESTCONF client.";
ever been established, last-connected defaults to
the first endpoint listed.";
}
leaf interval-secs {
type uint8;
units seconds;
default 5;
description
"Specifies the time delay between connection attempts
to the same endpoint. Note: this value differs from
the periodic-connection's timeout-mins value.";
} }
leaf count-max { leaf max-attempts {
type uint8; type uint8 {
range "1..max";
}
default 3; default 3;
description description
"Specifies the number times the RESTCONF server tries to "Specifies the number times the RESTCONF server tries to
connect to a specific endpoint before moving on to the connect to a specific endpoint before moving on to the
next endpoint in the list (round robin)."; next endpoint in the list (round robin).";
} }
} }
} }
} }
}
grouping client-cert-auth-container {
description
"This grouping is used only to help improve readability
of the YANG module.";
container client-cert-auth { container client-cert-auth {
if-feature client-cert-auth; if-feature client-cert-auth;
description description
"Container for TLS client certificate authentication "Container for TLS client certificate authentication
configuration."; configuration.";
container trusted-ca-certs { container trusted-ca-certs {
description description
"A list of Certificate Authority (CA) certificates that "A list of Certificate Authority (CA) certificates that
a NETCONF server can use to authenticate NETCONF client a RESTCONF server can use to authenticate RESTCONF client
certificates. A client's certificate is authenticated certificates.";
if there is a chain of trust to a configured trusted CA reference
certificate. The client certificate MAY be accompanied "RFC XXXX: RESTCONF Protocol, Sections 2.3 and 2.5.";
with additional certificates forming a chain of trust.
The client's certificate is authenticated if there is
path-validation from any of the certificates it presents
to a configured trust anchor.";
leaf-list trusted-ca-cert { leaf-list trusted-ca-cert {
type binary; type binary;
ordered-by system;
nacm:default-deny-write; nacm:default-deny-write;
description description
"The binary certificate structure as specified by RFC "The binary certificate structure as specified by RFC
5246, Section 7.4.6, i.e.,: opaque ASN.1Cert<1..2^24>; 5246, Section 7.4.6, i.e.,: opaque ASN.1Cert<1..2^24>;
"; ";
reference reference
"RFC 5246: The Transport Layer Security (TLS) "RFC 5246: The Transport Layer Security (TLS)
Protocol Version 1.2"; Protocol Version 1.2";
} }
} }
container trusted-client-certs { container trusted-client-certs {
description description
"A list of client certificates that a NETCONF server can "A list of client certificates that a RESTCONF server can
use to authenticate a NETCONF client's certificate. A use to authenticate a RESTCONF client's certificate. A
client's certificate is authenticated if it is an exact client's certificate is authenticated if it is an exact
match to a configured trusted client certificates."; match to a configured trusted client certificate.";
leaf-list trusted-client-cert { leaf-list trusted-client-cert {
type binary; type binary;
ordered-by system;
nacm:default-deny-write; nacm:default-deny-write;
description description
"The binary certificate structure, as "The binary certificate structure, as specified by RFC
specified by RFC 5246, Section 7.4.6, i.e.,: 5246, Section 7.4.6, i.e.,: opaque ASN.1Cert<1..2^24>;
opaque ASN.1Cert<1..2^24>;
"; ";
reference reference
"RFC 5246: The Transport Layer Security (TLS) "RFC 5246: The Transport Layer Security (TLS)
Protocol Version 1.2"; Protocol Version 1.2";
} }
} }
container cert-maps { container cert-maps {
uses x509c2n:cert-to-name; uses x509c2n:cert-to-name;
description description
"The cert-maps container is used by a NETCONF server to "The cert-maps container is used by a RESTCONF server to
map the NETCONF client's presented X.509 certificate to a map the RESTCONF client's presented X.509 certificate to a
NETCONF username. If no matching and valid cert-to-name RESTCONF username. If no matching and valid cert-to-name
list entry can be found, then the NETCONF server MUST list entry can be found, then the RESTCONF server MUST
close the connection, and MUST NOT accept NETCONF close the connection, and MUST NOT accept RESTCONF
messages over it."; messages over it.";
reference
"RFC XXXX: RESTCONF Protocol, Section 2.5";
} }
} }
} }
grouping certificates-container { grouping certificates-grouping {
description description
"This grouping is used by both the listen and "This grouping is used by both the listen and
call-home containers"; call-home containers";
container certificates { container certificates {
description description
"Parent container for the list of certificates."; "Parent container for the list of certificates.";
leaf-list certificate { leaf-list certificate {
type string; type string;
min-elements 1; min-elements 1;
description description
skipping to change at page 37, line 12 skipping to change at page 37, line 25
configured on the system. How valid values are discovered configured on the system. How valid values are discovered
is outside the scope of this module, but they are envisioned is outside the scope of this module, but they are envisioned
to be the keys for a list of certificates provided to be the keys for a list of certificates provided
by another YANG module"; by another YANG module";
reference reference
"RFC 5246: The TLS Protocol, Section 7.4.2"; "RFC 5246: The TLS Protocol, Section 7.4.2";
} }
} }
} }
grouping address-and-port-grouping {
description
"This grouping is usd by both the ssh and tls containers
for listen configuration.";
leaf address {
type inet:ip-address;
description
"The IP address of the interface to listen on.";
}
leaf port {
type inet:port-number;
description
"The local port number on this interface the RESTCONF server
listens on.";
}
}
grouping endpoints-container {
description
"This grouping is used by both the ssh and tls containers
for call-home configurations.";
container endpoints {
description
"Container for the list of endpoints.";
list endpoint {
key name;
min-elements 1;
ordered-by user;
description
"User-ordered list of endpoints for this RESTCONF client.
Defining more than one enables high-availability.";
leaf name {
type string;
description
"An arbitrary name for the endpoint to connect to.";
}
leaf address {
type inet:host;
mandatory true;
description
"The hostname or IP address or hostname of the endpoint.
If a hostname is provided and DNS resolves to more than
one IP address, the RESTCONF server SHOULD try all of
the ones it can based on how its networking stack is
configured (e.g. v4, v6, dual-stack).";
}
leaf port {
type inet:port-number;
description
"The IP port for this endpoint. The RESTCONF server will
use the IANA-assigned well-known port if not specified.";
}
}
}
}
grouping keep-alives-container {
description
"This grouping is use by both listen and call-home configurations.";
container keep-alives {
description
"Configures the keep-alive policy, to proactively test the
aliveness of the RESTCONF client.";
reference
"RFC VVVV: NETCONF Server and RESTCONF Server Configuration
Models, Section 4";
leaf interval-secs {
type uint8;
units seconds;
description
"Sets a timeout interval in seconds after which if no data
has been received from the RESTCONF client, a message will
be sent to request a response from the RESTCONF client. A
value of '0' indicates that no keep-alive messages should
be sent.";
}
leaf count-max {
type uint8;
default 3;
description
"Sets the number of keep-alive messages that may be sent
without receiving any data from the RESTCONF client before
assuming the RESTCONF client is no longer alive. If this
threshold is reached, the transport-level connection will
be disconnected, which will trigger the reconnection
strategy). The interval timer is reset after each
transmission, thus an unresponsive RESTCONF client will
be dropped after approximately (count-max * interval-secs)
seconds.";
}
}
}
} }
<CODE ENDS> <CODE ENDS>
5. Implementation strategy for keep-alives 5. Security Considerations
One of the objectives listed above, Keep-alives for persistent
connections Section 2.6.6, indicates a need for a "keep-alive"
mechanism. This section specifies how the keep-alive mechanism is to
be implemented for both the SSH and TLS transports.
Both SSH and TLS have the ability to support keep-alives securely.
Using the strategies listed below, the keep-alive messages are sent
inside the encrypted tunnel and thus immune to attack.
5.1. Keep-alives for SSH
The SSH keep-alive solution that is expected to be used is ubiquitous
in practice, though never being explicitly defined in an RFC. The
strategy used is to purposely send a malformed request message with a
flag set to ensure a response. More specifically, per section 4 of
[RFC4253], either SSH peer can send a SSH_MSG_GLOBAL_REQUEST message
with "want reply" set to '1' and that, if there is an error, will get
back a SSH_MSG_REQUEST_FAILURE response. Similarly, section 5 of
[RFC4253] says that either SSH peer can send a
SSH_MSG_CHANNEL_REQUEST message with "want reply" set to '1' and
that, if there is an error, will get back a SSH_MSG_CHANNEL_FAILURE
response.
To ensure that the request will fail, current implementations of this
keep-alive strategy (e.g. OpenSSH's `sshd` server) send an invalid
"request name" or "request type", respectively. Abiding to the
extensibility guidelines specified in Section 6 of [RFC4251], these
implementations use the "name@domain". For instance, when configured
to send keep-alives, OpenSSH sends the string
"keepalive@openssh.com". In order to remain compatible with existing
implementations, this draft does not require a specific "request
name" or "request type" string be used, implementations are free to
pick values of their choosing.
5.2. Keep-alives for TLS
The TLS keep-alive solution that is expected to be used is defined in
[RFC6520]. This solution allows both peers to advertise if they can
receive heartbeat request messages from its peer. For standard TLS
connections, devices SHOULD advertise "peer_allowed_to_send", as per
[RFC6520]. This advertisement is not a "MUST" in order to
grandfather existing NETCONF/RESTCONF over TLS implementations. For
NETCONF Call Home or RESTCONF Call Home, the network management
system MUST advertise "peer_allowed_to_send" per [RFC6520]. This is
a "MUST" so as to ensure devices can depend on it always being there
for call home connections, which is when keep-alives are needed the
most.
6. Security Considerations
The YANG modules defined in this memo are designed to be accessed via
the NETCONF protocol [RFC6241]. Authorization for access to specific
portions of conceptual data and operations within this module is
provided by the NETCONF access control model (NACM) [RFC6536].
There are a number of data nodes defined in the "ietf-netconf-server" There are a number of data nodes defined in the "ietf-netconf-server"
YANG module which are readable and/or writable that may be considered YANG module which are readable and/or writable that may be considered
sensitive or vulnerable in some network environments. Write and read sensitive or vulnerable in some network environments. Write and read
operations to these data nodes can have a negative effect on network operations to these data nodes can have a negative effect on network
operations. It is thus important to control write and read access to operations. It is thus important to control write and read access to
these data nodes. Below are the data nodes and their sensitivity/ these data nodes. Below are the data nodes and their sensitivity/
vulnerability. vulnerability.
netconf-server/tls/client-auth/trusted-ca-certs: netconf-server/tls/client-auth/trusted-ca-certs:
skipping to change at page 41, line 14 skipping to change at page 38, line 21
certificates. Write access to this node is protected using an certificates. Write access to this node is protected using an
nacm:default-deny-write statement. nacm:default-deny-write statement.
restconf-server/tls/client-auth/trusted-client-certs: restconf-server/tls/client-auth/trusted-client-certs:
o This container contains certificates that a RESTCONF server is to o This container contains certificates that a RESTCONF server is to
trust directly when authenticating X.509-based client trust directly when authenticating X.509-based client
certificates. Write access to this node is protected using an certificates. Write access to this node is protected using an
nacm:default-deny-write statement. nacm:default-deny-write statement.
7. IANA Considerations 6. IANA Considerations
This document registers two URIs in the IETF XML registry [RFC2119]. This document registers two URIs in the IETF XML registry [RFC2119].
Following the format in [RFC3688], the following registrations are Following the format in [RFC3688], the following registrations are
requested: requested:
URI: urn:ietf:params:xml:ns:yang:ietf-netconf-server URI: urn:ietf:params:xml:ns:yang:ietf-netconf-server
Registrant Contact: The NETCONF WG of the IETF. Registrant Contact: The NETCONF WG of the IETF.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-restconf-server URI: urn:ietf:params:xml:ns:yang:ietf-restconf-server
skipping to change at page 41, line 42 skipping to change at page 39, line 5
name: ietf-netconf-server name: ietf-netconf-server
namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-server namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-server
prefix: ncserver prefix: ncserver
reference: RFC VVVV reference: RFC VVVV
name: ietf-restconf-server name: ietf-restconf-server
namespace: urn:ietf:params:xml:ns:yang:ietf-restconf-server namespace: urn:ietf:params:xml:ns:yang:ietf-restconf-server
prefix: rcserver prefix: rcserver
reference: RFC VVVV reference: RFC VVVV
8. Other Considerations 7. Other Considerations
The YANG modules define herein do not themselves support virtual The YANG modules define herein do not themselves support virtual
routing and forwarding (VRF). It is expected that external modules routing and forwarding (VRF). It is expected that external modules
will augment in VRF designations when needed. will augment in VRF designations when needed.
9. Acknowledgements 8. Acknowledgements
The authors would like to thank for following for lively discussions The authors would like to thank for following for lively discussions
on list and in the halls (ordered by last name): Andy Bierman, Martin on list and in the halls (ordered by last name): Andy Bierman, Martin
Bjorklund, Benoit Claise, Mehmet Ersue, David Lamparter, Alan Luchuk, Bjorklund, Benoit Claise, Mehmet Ersue, David Lamparter, Alan Luchuk,
Ladislav Lhotka, Radek Krejci, Tom Petch, Phil Shafer, and Bert Ladislav Lhotka, Radek Krejci, Tom Petch, Phil Shafer, and Bert
Wijnen. Wijnen.
Juergen Schoenwaelder and was partly funded by Flamingo, a Network of Juergen Schoenwaelder and was partly funded by Flamingo, a Network of
Excellence project (ICT-318488) supported by the European Commission Excellence project (ICT-318488) supported by the European Commission
under its Seventh Framework Programme. under its Seventh Framework Programme.
10. References 9. References
10.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. 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) [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, January 2006. Transport Layer Protocol", RFC 4253, January 2006.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020, Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010. October 2010.
[RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure
Shell Authentication", RFC 6187, March 2011. Shell Authentication", RFC 6187, March 2011.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", RFC Bierman, "Network Configuration Protocol (NETCONF)", RFC
6241, June 2011. 6241, June 2011.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, June 2011. 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 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536, March Protocol (NETCONF) Access Control Model", RFC 6536, March
2012. 2012.
[RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991,
July 2013. July 2013.
[RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for [RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for
SNMP Configuration", RFC 7407, December 2014. SNMP Configuration", RFC 7407, December 2014.
[RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the
NETCONF Protocol over Transport Layer Security (TLS) with
Mutual X.509 Authentication", RFC 7589, June 2015.
[draft-ietf-netconf-call-home] [draft-ietf-netconf-call-home]
Watsen, K., "NETCONF Call Home and RESTCONF Call Home", Watsen, K., "NETCONF Call Home and RESTCONF Call Home",
draft-ieft-netconf-call-home-02 (work in progress), 2014. draft-ieft-netconf-call-home-02 (work in progress), 2014.
[draft-ietf-netconf-restconf] [draft-ietf-netconf-restconf]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", draft-ieft-netconf-restconf-04 (work in Protocol", draft-ieft-netconf-restconf-04 (work in
progress), 2014. progress), 2014.
[draft-ietf-netconf-rfc5539bis] 9.2. Informative References
Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the
NETCONF Protocol over Transport Layer Security (TLS)",
draft-ietf-netconf-rfc5539bis-06 (work in progress), 2014.
10.2. Informative References
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
Appendix A. Examples Appendix A. Alternative solution addressing Issue #49
A.1. NETCONF Configuration using SSH Transport Option #4 for Issue #49 proposed to define configuration for a
keychain and on-going discussion proposed to create reusable
groupings for SSH/TLS servers (referencing keys and certificates held
in the keychain) that the NETCONF/RESTCONF servers would uses. This
relationship is illustrated by the diagram below.
The following example illustrates the <get> response from a NETCONF +-------------+
server that only supports SSH, both listening for incoming |ietf-keychain|
connections as well as calling home to a single application having +-------------+
two endpoints. ^ ^
| |
<leafref> | | <leafref>
+------------+ +------------+
| |
+---------------+ +------------------+
|ietf-ssh-server| | ietf-tls-server |
+---------------+ +------------------+
^ ^ ^
| <uses> | |
| <augments> | |
| +--------------------+ | <augments>
| | |
+-------------------+ +--------------------+
|ietf-netconf-server| |ietf-restconf-server|
+-------------------+ +--------------------+
The following sections each of the five YANG modules above.
A.1. The Keychain Model
A.1.1. Tree Diagram
module: ietf-keychain
+--rw keychain
+--rw private-keys
| +--rw private-key* [name]
| +--rw name string
| +--ro algorithm? enumeration
| +--ro key-length? uint32
| +--ro public-key? string
| +--rw certificates
| +--rw certificate* [name]
| +--rw name string
| +--rw chain? binary
+--rw trusted-certificates* [name]
+--rw name string
+--rw trusted-certificate* [name]
+--rw name string
+--rw certificate? binary
rpcs:
+---x generate-certificate-signing-request
| +---w input
| | +---w private-key? -> /keychain/private-keys/private-key/name
| | +---w subject binary
| | +---w attributes? binary
| +--ro output
| +--ro certificate-signing-request binary
+---x generate-private-key
+---w input
+---w name string
+---w algorithm enumeration
+---w key-length uint32
A.1.2. Example Usage
<keychain xmlns="urn:ietf:params:xml:ns:yang:ietf-keychain">
<!-- private keys and associated certificates -->
<private-keys>
<private-key>
<name>TPM key</name>
<algorithm>rsa</algorithm>
<key-length>2048</key-length>
<public-key>
cztvaWRoc2RmZ2tqaHNkZmdramRzZnZzZGtmam5idnNvO2RmanZvO3NkZ
mJpdmhzZGZpbHVidjtvc2lkZmhidml1bHNkYmZ2aXNiZGZpYmhzZG87Zm
JvO3NkZ25iO29pLmR6Zgo=
</public-key>
<certificates>
<certificate>
<name>IDevID Certificate</name>
<chain>
LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNrekNDQWZ5Z
0F3SUJBZ0lKQUpRT2t3bGpNK2pjTUEwR0NTcUdTSWIzRFFFQkJRVU
FNRFF4Q3pBSkJnTlYKQkFZVEFsVlRNUkF3RGdZRFZRUUtFd2RsZUd
GdGNHeGxNUk13RVFZRFZRUURFd3BEVWt3Z1NYTnpkV1Z5TUI0WApE
diR1V4RXpBUkJnTlZCQU1UQ2tOU1RDQkpjM04xWlhJd2daOHdEUVl
KS29aSWh2Y04KQVFFQkJRQURnWTBBTUlHSkFvR0JBTXVvZmFPNEV3
El1QWMrQ1RsTkNmc0d6cEw1Um5ydXZsOFRIcUJTdGZQY3N0Zk1KT1
FaNzlnNlNWVldsMldzaHE1bUViCkJNNitGNzdjbTAvU25FcFE0TnV
bXBDT2YKQWdNQkFBR2pnYXd3Z2Frd0hRWURWUjBPQkJZRUZKY1o2W
URiR0lPNDB4ajlPb3JtREdsRUNCVTFNR1FHQTFVZApJd1JkTUZ1QU
ZKY1o2WURiR0lPNDB4ajlPb3JtREdsRUNCVTFvVGlrTmpBME1Rc3d
mMKTUE0R0ExVWREd0VCL3dRRUF3SUNCREFTQmdOVkhSTUJBZjhFQ0
RBR0FRSC9BZ0VBTUEwR0NTcUdTSWIzRFFFQgpCUVVBQTRHQkFMMmx
rWmFGNWcyaGR6MVNhZnZPbnBneHA4eG00SHRhbStadHpLazFlS3Bx
TXp4YXJCbFpDSHlLCklVbC9GVzRtV1RQS1VDeEtFTE40NEY2Zmk2d
c4d0tSSElkYW1WL0pGTmlQS0VXSTF4K1I1aDZmazcrQzQ1QXg1RWV
SWHgzZjdVM2xZTgotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
</chain>
</certificate>
</certificates>
</private-key>
</private-keys>
<!-- trusted netconf/restconf client certificates -->
<trusted-certificates>
<name>Trusted certificates for netconf/restconf client</name>
<trusted-certificate>
<name>George Jetson</name>
<certificate>
QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ
MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ
25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2
RV0JCU2t2MXI2SFNHeUFUVkpwSmYyOWtXbUU0NEo5akJrQmdOVkhTTUVY
VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER
UxNQWtHQTFVRUJoTUNWVk14RURBT0JnTlZCQW9UQjJWNApZVzF3YkdVeE
V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF
NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC
Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN
WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW
xWVE1SQXdEZ1lEVlFRSwpFd2RsZUdGdGNHeGxNUk13RVFZRFZRUURFd3B
EVWt3Z1NYTnpkV1Z5TUEwR0NTcUdTSWIzRFFFQkJRVUFBNEdCCkFFc3BK
WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM
TQzcjFZSjk0M1FQLzV5eGUKN2QxMkxCV0dxUjUrbEl5N01YL21ka2M4al
zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot
LS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
</certificate>
</trusted-certificate>
<trusted-certificate>
<name>Fred Flinstone</name>
<certificate>
VlEVlFRREV3Vm9ZWEJ3ZVRDQm56QU5CZ2txaGtpRzl3MEJBUUVGQUFPQm
pRQXdnWWtDCmdZRUE1RzRFSWZsS1p2bDlXTW44eUhyM2hObUFRaUhVUzV
rRUpPQy9hSFA3eGJXQW1ra054ZStUa2hrZnBsL3UKbVhsTjhSZUd1ODhG
NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd
VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER
V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF
NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC
Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN
WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW
xWVE1SQXdEZ1lEVlFRSwpFd2RsZUdGdGNHeGxNUk13RVFZRFZRUURFd3B
EVWt3Z1NYTnpkV1Z5TUEwR0NTcUdTSWIzRFFFQkJRVUFBNEdCCkFFc3BK
WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM
lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk
zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot
QWtUOCBDRVUUZJ0RUF==
</certificate>
</trusted-certificate>
</trusted-certificates>
<!-- trust anchors for netconf/restconf clients -->
<trusted-certificates>
<name>Trust anchors for netconf/restconf clients</name>
<trusted-certificate>
<name>Example.com</name>
<certificate>
WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM
lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk
zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot
NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd
VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER
V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF
NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC
Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN
WpiMjB2WlhoaGJYQnNaUzVqY215aU9LUTJNRFF4Q3pBSkJnTlZCQVlUQW
QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ
MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ
25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2
RJSUJQFRStS0Cg==
</certificate>
</trusted-certificate>
</trusted-certificates>
<!-- trust anchors for random HTTPS servers on Internet -->
<trusted-certificates>
<name>Trust anchors for random HTTPS servers</name>
<trusted-certificate>
<name>Example.com</name>
<certificate>
NGcEk3UE90cnNFVjRwTUNBd0VBQWFPQ0FSSXdnZ0VPCk1CMEdBMVVkRGd
VEJiZ0JTWEdlbUEKMnhpRHVOTVkvVHFLNWd4cFJBZ1ZOYUU0cERZd05ER
V6QVJCZ05WQkFNVENrTlNUQ0JKYzNOMVpYS0NDUUNVRHBNSll6UG8zREF
Z05WSFI4RVlqQmdNRjZnSXFBZ2hoNW9kSFJ3T2k4dlpYaGgKYlhCc1pTN
QmdOVkJBWVRBbFZUTVJBd0RnWURWUVFLRXdkbAplR0Z0Y0d4bE1RNHdEQ
MkF6a3hqUDlVQWtHR0dvS1U1eUc1SVR0Wm0vK3B0R2FieXVDMjBRd2kvZ
NQmdOVkhSTUJBZjhFCkFqQUFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQnBC
WmdsK2gyTTg3QmtGMjhWbW1CdFFVaWc3OEgrRkYyRTFwdSt4ZVRJbVFFM
lLQllsdWpOcjFTMnRLR05EMUc2OVJpK2FWNGw2NTdZNCtadVJMZgpRYjk
zSFNwSDdwVXBCYnA4dmtNanFtZjJma3RqZHBxeFppUUtTbndWZTF2Zwot
25PZnpZNEhONApXY0pTaUpZK2xtYWs3RTRORUZXZS9RdGp4NUlXZmdvN2
WpiMjB2WlhoaGJYQnNaUzVqY215aU9L=
</certificate>
</trusted-certificate>
</trusted-certificates>
</keychain>
A.1.3. YANG Model
<CODE BEGINS> file "ietf-keychain@2015-07-06.yang"
module ietf-keychain {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-keychain";
prefix "kc";
organization
"IETF NETCONF (Network Configuration) Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/netconf/>
WG List: <mailto:netconf@ietf.org>
WG Chair: Mehmet Ersue
<mailto:mehmet.ersue@nsn.com>
WG Chair: Mahesh Jethanandani
<mailto:mjethanandani@gmail.com>
Editor: Kent Watsen
<mailto:kwatsen@juniper.net>";
description
"This module defines a keychain to centralize management of
security credentials.
Copyright (c) 2014 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC VVVV; see
the RFC itself for full legal notices.";
revision "2015-07-06" {
description
"Initial version";
reference
"RFC VVVV: NETCONF Server and RESTCONF Server Configuration
Models";
}
container keychain {
description
"A list of private-keys and their associated certificates, as
well as lists of trusted certificates for client certificate
authentication. RPCs are provided to generate a new private
key and to generate a certificate signing requests.";
container private-keys {
description
"A list of private key maintained by the keychain.";
list private-key {
key name;
description
"A private key.";
leaf name {
type string;
description
"An arbitrary name for the private key.";
}
leaf algorithm {
type enumeration {
enum rsa { description "TBD"; }
enum dsa { description "TBD"; }
enum secp192r1 { description "TBD"; }
enum sect163k1 { description "TBD"; }
enum sect163r2 { description "TBD"; }
enum secp224r1 { description "TBD"; }
enum sect233k1 { description "TBD"; }
enum sect233r1 { description "TBD"; }
enum secp256r1 { description "TBD"; }
enum sect283k1 { description "TBD"; }
enum sect283r1 { description "TBD"; }
enum secp384r1 { description "TBD"; }
enum sect409k1 { description "TBD"; }
enum sect409r1 { description "TBD"; }
enum secp521r1 { description "TBD"; }
enum sect571k1 { description "TBD"; }
enum sect571r1 { description "TBD"; }
}
config false;
description
"The algorithm used by the private key.";
}
leaf key-length {
type uint32;
config false;
description
"The key-length used by the private key.";
}
leaf public-key {
type string;
config false;
description
"The public-key matching the private key.";
}
container certificates {
list certificate {
key name;
description
"A certificate for this public key.";
leaf name {
type string;
description
"An arbitrary name for the certificate.";
}
leaf chain {
type binary;
description
"The certificate itself, as well as an ordered
sequence of intermediate certificates leading
to a trust anchor, as specified by RFC 5246,
Section 7.4.2.";
reference
"RFC 5246: The Transport Layer Security (TLS)
Protocol Version 1.2";
}
}
description
"A list of certificates for this public key.";
}
action generate-certificate-signing-request {
description
"Generates a certificate signing request structure for
the associated private key using the passed subject
and attribute values.";
input {
leaf subject {
type binary;
mandatory true;
description
"The 'subject' field in the CertificationRequestInfo
defined in RFC 2986, Section 4.1.";
reference
"RFC 2986: PKCS #10: Certification Request Syntax
Specification Version 1.7";
}
leaf attributes {
type binary;
description
"The 'attributes' field in the CertificationRequestInfo
defined in RFC 2986, Section 4.1.";
reference
"RFC 2986: PKCS #10: Certification Request Syntax
Specification Version 1.7";
}
}
output {
leaf certificate-signing-request {
type binary;
mandatory true;
description
"The CertificationRequestInfo structure as specified
by RFC 2986, Section 4.1.";
reference
"RFC 2986: PKCS #10: Certification Request Syntax
Specification Version 1.7";
}
}
}
}
action generate-private-key {
description
"Generates a private key using the specified algorithm and
key length.";
input {
leaf name {
type string;
mandatory true;
description
"The name this private-key should have when listed in
/keychain/private-keys/private-key. As such, the
passed value must not match any existing 'name' value.";
}
leaf algorithm {
type enumeration {
enum rsa { description "TBD"; }
enum dsa { description "TBD"; }
enum secp192r1 { description "TBD"; }
enum sect163k1 { description "TBD"; }
enum sect163r2 { description "TBD"; }
enum secp224r1 { description "TBD"; }
enum sect233k1 { description "TBD"; }
enum sect233r1 { description "TBD"; }
enum secp256r1 { description "TBD"; }
enum sect283k1 { description "TBD"; }
enum sect283r1 { description "TBD"; }
enum secp384r1 { description "TBD"; }
enum sect409k1 { description "TBD"; }
enum sect409r1 { description "TBD"; }
enum secp521r1 { description "TBD"; }
enum sect571k1 { description "TBD"; }
enum sect571r1 { description "TBD"; }
}
mandatory true;
description
"The algorithm to be used.";
}
leaf key-length {
type uint32;
mandatory true;
description
"The key length to be used.";
}
}
}
}
list trusted-certificates {
key name;
description
"A list of lists of trusted certificates.";
leaf name {
type string;
description
"An arbitrary name for this list of trusted certificates.";
}
list trusted-certificate {
key name;
description
"A list of trusted certificates for a specific use.";
leaf name {
type string;
description
"An arbitrary name for this trusted certificate.";
}
leaf certificate {
type binary;
description
"The binary certificate structure as specified by RFC
5246, Section 7.4.6, i.e.,: opaque ASN.1Cert<1..2^24>;
";
reference
"RFC 5246: The Transport Layer Security (TLS)
Protocol Version 1.2";
}
}
}
}
rpc generate-certificate-signing-request {
description
"Generates a certificate signing request structure for
the specified private key using the passed subject
and attribute values.";
input {
leaf private-key {
type leafref {
path "/keychain/private-keys/private-key/name";
}
description
"The private key to generate the certificate signing
request for.";
}
leaf subject {
type binary;
mandatory true;
description
"The 'subject' field in the CertificationRequestInfo
defined in RFC 2986, Section 4.1.";
reference
"RFC 2986: PKCS #10: Certification Request Syntax
Specification Version 1.7";
}
leaf attributes {
type binary;
description
"The 'attributes' field in the CertificationRequestInfo
defined in RFC 2986, Section 4.1.";
reference
"RFC 2986: PKCS #10: Certification Request Syntax
Specification Version 1.7";
}
}
output {
leaf certificate-signing-request {
type binary;
mandatory true;
description
"The CertificationRequestInfo structure as specified
by RFC 2986, Section 4.1.";
reference
"RFC 2986: PKCS #10: Certification Request Syntax
Specification Version 1.7";
}
}
}
rpc generate-private-key {
description
"Generates a private key using the specified algorithm and
key length.";
input {
leaf name {
type string;
mandatory true;
description
"The name this private-key should have when listed in
/keychain/private-keys/private-key. As such, the
passed value must not match any existing 'name' value.";
}
leaf algorithm {
type enumeration {
enum rsa { description "TBD"; }
enum dsa { description "TBD"; }
enum secp192r1 { description "TBD"; }
enum sect163k1 { description "TBD"; }
enum sect163r2 { description "TBD"; }
enum secp224r1 { description "TBD"; }
enum sect233k1 { description "TBD"; }
enum sect233r1 { description "TBD"; }
enum secp256r1 { description "TBD"; }
enum sect283k1 { description "TBD"; }
enum sect283r1 { description "TBD"; }
enum secp384r1 { description "TBD"; }
enum sect409k1 { description "TBD"; }
enum sect409r1 { description "TBD"; }
enum secp521r1 { description "TBD"; }
enum sect571k1 { description "TBD"; }
enum sect571r1 { description "TBD"; }
}
mandatory true;
description
"The algorithm to be used.";
}
leaf key-length {
type uint32;
mandatory true;
description
"The key length to be used.";
}
}
}
}
<CODE ENDS>
A.2. The SSH Server Model
A.2.1. Tree Diagram
The following tree diagram is faked, as a module having only a
grouping in it has no tree diagram. However, for illustrative
purposes, a container has been added as nothing more than a "uses"
statement of the grouping.
module: ietf-ssh-server
+--rw fake-ssh-server
+--rw host-keys
| +--rw host-key* [name]
| +--rw name string
| +--rw (type)?
| +--:(public-key)
| | +--rw public-key? -> /kc:keychain/private-keys/private-key/name
| +--:(certificate)
| +--rw certificate? -> /kc:keychain/private-keys/private-key/certificates/certificate/name {ssh-x509-certs}?
+--rw client-cert-auth {ssh-x509-certs}?
+--rw trusted-ca-certs? -> /kc:keychain/trusted-certificates/name
+--rw trusted-client-certs? -> /kc:keychain/trusted-certificates/name
A.2.2. Example Usage
<fake-ssh-server xmlns="urn:ietf:params:xml:ns:yang:ietf-ssh-server">
<host-keys>
<host-key>
<name>IDevID</name>
<certificate>
IDevID Certificate
</certificate>
</host-key>
</host-keys>
</certificates>
<client-cert-auth>
<trusted-ca-certs>
Trusted certificates for netconf/restconf clients
</trusted-ca-certs>
<trusted-client-certs>
Trust anchors for netconf/restconf clients
</trusted-client-certs>
</client-cert-auth>
</fake-ssh-server>
A.2.3. YANG Model
<CODE BEGINS> file "ietf-ssh-server@2015-07-06.yang"
module ietf-ssh-server {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-ssh-server";
prefix "ts";
import ietf-keychain {
prefix kc; // RFC VVVV
}
organization
"IETF NETCONF (Network Configuration) Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/netconf/>
WG List: <mailto:netconf@ietf.org>
WG Chair: Mehmet Ersue
<mailto:mehmet.ersue@nsn.com>
WG Chair: Mahesh Jethanandani
<mailto:mjethanandani@gmail.com>
Editor: Kent Watsen
<mailto:kwatsen@juniper.net>";
description
"This module defines a reusable grouping for a SSH server that
can be used as a basis for specific SSH server instances.
Copyright (c) 2014 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC VVVV; see
the RFC itself for full legal notices.";
revision "2015-07-06" {
description
"Initial version";
reference
"RFC VVVV: NETCONF Server and RESTCONF Server Configuration
Models";
}
// features
feature ssh-x509-certs {
description
"The ssh-x509-certs feature indicates that the NETCONF server
supports RFC 6187";
reference
"RFC 6187: X.509v3 Certificates for Secure Shell Authentication";
}
// grouping
grouping ssh-server-grouping {
description
"A reusable grouping for a SSH server that can be used as a
basis for specific SSH server instances.";
container host-keys {
description
"The list of host-keys the SSH server will present when
establishing a SSH connection.";
list host-key {
key name;
min-elements 1;
ordered-by user;
description
"An ordered list of hostkeys the SSH server advertises
when sending its ??? message.";
reference
"RFC ????: ...";
leaf name {
type string;
mandatory true;
description
"An arbitrary name for this host-key";
}
choice type {
leaf public-key {
type leafref {
path "/kc:keychain/kc:private-keys/kc:private-key/kc:name";
}
description
"The name of a private-key in the keychain.";
}
leaf certificate {
if-feature ssh-x509-certs;
type leafref {
path "/kc:keychain/kc:private-keys/kc:private-key/kc:certificates/kc:certificate/kc:name";
}
description
"The name of a certificate in the keychain.";
}
}
}
}
container client-cert-auth {
if-feature ssh-x509-certs;
description
"A reference to a list of trusted certificate authority (CA)
certificates and a reference to a list of trusted client
certificates.";
leaf trusted-ca-certs {
type leafref {
path "/kc:keychain/kc:trusted-certificates/kc:name";
}
description
"A reference to a list of certificate authority (CA)
certificates used by the SSH server to authenticate
SSH client certificates.";
}
leaf trusted-client-certs {
type leafref {
path "/kc:keychain/kc:trusted-certificates/kc:name";
}
description
"A reference to a list of client certificates used by
the SSH server to authenticate SSH client certificates.
A clients certificate is authenticated if it is an
exact match to a configured trusted client certificate.";
}
}
}
}
<CODE ENDS>
A.3. The TLS Server Model
A.3.1. Tree Diagram
The following tree diagram is faked, as a module having only a
grouping in it has no tree diagram. However, for illustrative
purposes, a container has been added as nothing more than a "uses"
statement of the grouping.
module: ietf-tls-server
+--rw fake-tls-server
+--rw certificates
| +--rw certificate* [name]
| +--rw name -> /kc:keychain/private-keys/private-key/certificates/certificate/name
+--rw client-auth
+--rw trusted-ca-certs? -> /kc:keychain/trusted-certificates/name
+--rw trusted-client-certs? -> /kc:keychain/trusted-certificates/name
A.3.2. Example Usage
<fake-tls-server xmlns="urn:ietf:params:xml:ns:yang:ietf-tls-server">
</certificates>
<certificate>
IDevID Certificate
</certificate>
</certificates>
<client-auth>
<trusted-ca-certs>
Trusted certificates for netconf/restconf clients
</trusted-ca-certs>
<trusted-client-certs>
Trust anchors for netconf/restconf clients
</trusted-client-certs>
</client-auth>
</fake-tls-server>
A.3.3. YANG Model
<CODE BEGINS> file "ietf-tls-server@2015-07-06.yang"
module ietf-tls-server {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-tls-server";
prefix "ts";
import ietf-keychain {
prefix kc; // RFC VVVV
}
organization
"IETF NETCONF (Network Configuration) Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/netconf/>
WG List: <mailto:netconf@ietf.org>
WG Chair: Mehmet Ersue
<mailto:mehmet.ersue@nsn.com>
WG Chair: Mahesh Jethanandani
<mailto:mjethanandani@gmail.com>
Editor: Kent Watsen
<mailto:kwatsen@juniper.net>";
description
"This module defines a reusable grouping for a TLS server that
can be used as a basis for specific TLS server instances.
Copyright (c) 2014 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC VVVV; see
the RFC itself for full legal notices.";
revision "2015-07-06" {
description
"Initial version";
reference
"RFC VVVV: NETCONF Server and RESTCONF Server Configuration
Models";
}
grouping tls-server-grouping {
description
"A reusable grouping for a TLS server that can be used as a
basis for specific TLS server instances.";
container certificates {
description
"The list of certificates the TLS server will present when
establishing a TLS connection.";
list certificate {
key name;
min-elements 1;
description
"An unordered list of certificates the TLS server can pick
from when sending its Server Certificate message.";
reference
"RFC 5246: The TLS Protocol, Section 7.4.2";
leaf name {
type leafref {
path "/kc:keychain/kc:private-keys/kc:private-key/kc:certificates/kc:certificate/kc:name";
}
description
"The name of the certificate in the keychain.";
}
}
}
container client-auth {
description
"A reference to a list of trusted certificate authority (CA)
certificates and a reference to a list of trusted client
certificates.";
leaf trusted-ca-certs {
type leafref {
path "/kc:keychain/kc:trusted-certificates/kc:name";
}
description
"A reference to a list of certificate authority (CA)
certificates used by the TLS server to authenticate
TLS client certificates.";
}
leaf trusted-client-certs {
type leafref {
path "/kc:keychain/kc:trusted-certificates/kc:name";
}
description
"A reference to a list of client certificates used by
the TLS server to authenticate TLS client certificates.
A clients certificate is authenticated if it is an
exact match to a configured trusted client certificate.";
}
}
}
}
<CODE ENDS>
A.4. The NETCONF Server Model
A.4.1. Tree Diagram
module: ietf-netconf-server-new
+--rw netconf-server
+--rw session-options
| +--rw hello-timeout? uint16
+--rw listen {(ssh-listen or tls-listen)}?
| +--rw max-sessions? uint16
| +--rw idle-timeout? uint16
| +--rw endpoint* [name]
| +--rw name string
| +--rw (transport)
| +--:(ssh) {ssh-listen}?
| | +--rw ssh
| | +--rw address? inet:ip-address
| | +--rw port? inet:port-number
| | +--rw host-keys
| | | +--rw host-key* [name]
| | | +--rw name string
| | | +--rw (type)?
| | | +--:(public-key)
| | | | +--rw public-key? -> /kc:keychain/private-keys/private-key/name
| | | +--:(certificate)
| | | +--rw certificate? -> /kc:keychain/private-keys/private-key/certificates/certificate/name {ssh-x509-certs}?
| | +--rw client-cert-auth {ssh-x509-certs}?
| | +--rw trusted-ca-certs? -> /kc:keychain/trusted-certificates/name
| | +--rw trusted-client-certs? -> /kc:keychain/trusted-certificates/name
| +--:(tls) {tls-listen}?
| +--rw tls
| +--rw address? inet:ip-address
| +--rw port? inet:port-number
| +--rw certificates
| | +--rw certificate* [name]
| | +--rw name -> /kc:keychain/private-keys/private-key/certificates/certificate/name
| +--rw client-auth
| +--rw trusted-ca-certs? -> /kc:keychain/trusted-certificates/name
| +--rw trusted-client-certs? -> /kc:keychain/trusted-certificates/name
| +--rw cert-maps
| +--rw cert-to-name* [id]
| +--rw id uint32
| +--rw fingerprint x509c2n:tls-fingerprint
| +--rw map-type identityref
| +--rw name string
+--rw call-home {(ssh-call-home or tls-call-home)}?
+--rw netconf-client* [name]
+--rw name string
+--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-keys
| | | +--rw host-key* [name]
| | | +--rw name string
| | | +--rw (type)?
| | | +--:(public-key)
| | | | +--rw public-key? -> /kc:keychain/private-keys/private-key/name
| | | +--:(certificate)
| | | +--rw certificate? -> /kc:keychain/private-keys/private-key/certificates/certificate/name {ssh-x509-certs}?
| | +--rw client-cert-auth {ssh-x509-certs}?
| | +--rw trusted-ca-certs? -> /kc:keychain/trusted-certificates/name
| | +--rw trusted-client-certs? -> /kc:keychain/trusted-certificates/name
| +--:(tls) {tls-call-home}?
| +--rw tls
| +--rw endpoints
| | +--rw endpoint* [name]
| | +--rw name string
| | +--rw address inet:host
| | +--rw port? inet:port-number
| +--rw certificates
| | +--rw certificate* [name]
| | +--rw name -> /kc:keychain/private-keys/private-key/certificates/certificate/name
| +--rw client-auth
| +--rw trusted-ca-certs? -> /kc:keychain/trusted-certificates/name
| +--rw trusted-client-certs? -> /kc:keychain/trusted-certificates/name
| +--rw cert-maps
| +--rw cert-to-name* [id]
| +--rw id uint32
| +--rw fingerprint x509c2n:tls-fingerprint
| +--rw map-type identityref
| +--rw name string
+--rw connection-type
| +--rw (connection-type)?
| +--:(persistent-connection)
| | +--rw persistent!
| | +--rw idle-timeout? uint32
| | +--rw keep-alives
| | +--rw max-wait? uint16
| | +--rw max-attempts? uint8
| +--:(periodic-connection)
| +--rw periodic!
| +--rw idle-timeout? uint16
| +--rw reconnect_timeout? uint16
+--rw reconnect-strategy
+--rw start-with? enumeration
+--rw max-attempts? uint8
A.4.2. Example Usage
Configuring an SSH Server
<netconf-server xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-server"> <netconf-server xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-server">
<session-options>
<hello-timeout>600</hello-timeout>
<idle-timeout>3600</idle-timeout>
</session-options>
<listen> <listen>
<endpoint> <endpoint>
<name>foo bar</name> <name>netconf/ssh</name>
<ssh> <ssh>
<address>11.22.33.44</address> <address>11.22.33.44</address>
<host-keys> <host-keys>
<host-key>my-rsa-key</host-key> <host-key>
<host-key>my-dss-key</host-key> <public-key>my-rsa-key</public-key>
</host-key>
<host-key>
<certificate>TPM key</certificate>
</host-key>
</host-keys> </host-keys>
<client-cert-auth>
<trusted-ca-certs>
Trusted netconf/restconf client certificates
</trusted-ca-certs>
<trusted-client-certs>
Trust anchors for netconf/restconf clients
</trusted-client-certs>
</client-cert-auth>
</ssh> </ssh>
</endpoint> </endpoint>
</listen> </listen>
<call-home> <call-home>
<application> <netconf-client>
<name>config-mgr</name> <name>config-mgr</name>
<ssh> <ssh>
<endpoints> <endpoints>
<endpoint> <endpoint>
<name>east-data-center</name> <name>east-data-center</name>
<address>11.22.33.44</address> <address>11.22.33.44</address>
</endpoint> </endpoint>
<endpoint> <endpoint>
<name>west-data-center</name> <name>west-data-center</name>
<address>55.66.77.88</address> <address>55.66.77.88</address>
</endpoint> </endpoint>
</endpoints> </endpoints>
<host-keys> <host-keys>
<host-key>my-call-home-x509-key</host-key> <host-key>
<certificate>TPM key</certificate>
</host-key>
</host-keys> </host-keys>
<client-cert-auth>
<trusted-ca-certs>
Trusted netconf/restconf client certificates
</trusted-ca-certs>
<trusted-client-certs>
Trust anchors for netconf/restconf clients
</trusted-client-certs>
</client-cert-auth>
</ssh> </ssh>
</application> </netconf-client>
</call-home> </call-home>
<ssh>
<x509>
<trusted-ca-certs>
<trusted-ca-cert>
QW4gRWFzdGVyIGVnZywgZm9yIHRob3NlIHdobyBtaWdodCBsb29rICA6KQo=
</trusted-ca-cert>
</trusted-ca-certs>
<trusted-client-certs>
<trusted-client-cert>
SSBhbSB0aGUgZWdnIG1hbiwgdGhleSBhcmUgdGhlIGVnZyBtZW4uCg==
</trusted-client-cert>
<trusted-client-cert>
SSBhbSB0aGUgd2FscnVzLCBnb28gZ29vIGcnam9vYi4K
</trusted-client-cert>
</trusted-client-certs>
</x509>
</ssh>
</netconf-server> </netconf-server>
A.2. NETCONF Configuration using TLS Transport Configuring a TLS Server
The following example illustrates the <get> response from a NETCONF
server that only supports TLS, both listening for incoming
connections as well as calling home to a single application having
two endpoints. Please note also the configurations for
authenticating client certificates and mappings authenticated
certificates to NETCONF user names.
<netconf-server xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-server"> <netconf-server xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-server"
<session-options> xmlns:x509c2n="urn:ietf:params:xml:ns:yang:ietf-x509-cert-to-name">
<hello-timeout>600</hello-timeout>
<idle-timeout>3600</idle-timeout>
</session-options>
<listen> <listen>
<endpoint> <endpoint>
<name>primary-netconf-endpoint</name> <name>netconf/tls</name>
<tls> <tls>
<address>11.22.33.44</address> <address>11.22.33.44</address>
<certificates> <certificates>
<certificate>fw1.east.example.com</certificate> <certificate>IDevID Certificate</certificate>
</certificates> </certificates>
<client-auth>
<trusted-ca-certs>
Trusted netconf/restconf client certificates
</trusted-ca-certs>
<trusted-client-certs>
Trust anchors for netconf/restconf clients
</trusted-client-certs>
<cert-maps>
<cert-to-name>
<id>1</id>
<fingerprint>11:0A:05:11:00</fingerprint>
<map-type>x509c2n:san-any</map-type>
</cert-to-name>
<cert-to-name>
<id>2</id>
<fingerprint>B3:4F:A1:8C:54</fingerprint>
<map-type>x509c2n:specified</map-type>
<name>scooby-doo</name>
</cert-to-name>
</cert-maps>
</client-auth>
</tls> </tls>
</endpoint> </endpoint>
</listen> </listen>
<call-home> <call-home>
<application> <netconf-client>
<name>config-mgr</name> <name>config-mgr</name>
<tls> <tls>
<endpoints> <endpoints>
<endpoint> <endpoint>
<name>east-data-center</name> <name>east-data-center</name>
<address>11.22.33.44</address> <address>22.33.44.55</address>
</endpoint> </endpoint>
<endpoint> <endpoint>
<name>west-data-center</name> <name>west-data-center</name>
<address>55.66.77.88</address> <address>33.44.55.66</address>
</endpoint> </endpoint>
</endpoints> </endpoints>
<certificates> <certificates>
<certificate>fw1.east.example.com</certificate> <certificate>IDevID Certificate</certificate>
</certificates> </certificates>
</tls> </tls>
</application> </netconf-client>
</call-home> </call-home>
<tls>
<client-auth>
<trusted-ca-certs>
<trusted-ca-cert>
QW4gRWFzdGVyIGVnZywgZm9yIHRob3NlIHdobyBtaWdodCBsb29rICA6KQo=
</trusted-ca-cert>
</trusted-ca-certs>
<trusted-client-certs>
<trusted-client-cert>
SSBhbSB0aGUgZWdnIG1hbiwgdGhleSBhcmUgdGhlIGVnZyBtZW4uCg==
</trusted-client-cert>
<trusted-client-cert>
SSBhbSB0aGUgd2FscnVzLCBnb28gZ29vIGcnam9vYi4K
</trusted-client-cert>
</trusted-client-certs>
<cert-maps>
<cert-to-name>
<id>1</id>
<fingerprint>11:0A:05:11:00</fingerprint>
<map-type>x509c2n:san-any</map-type>
</cert-to-name>
<cert-to-name>
<id>2</id>
<fingerprint>11:0A:05:11:00</fingerprint>
<map-type>x509c2n:specified</map-type>
<name>Joe Cool</name>
</cert-to-name>
</cert-maps>
</client-auth>
</tls>
</netconf-server> </netconf-server>
A.3. RESTCONF Configuration using TLS Transport
The following example illustrates the <get> response from a RESTCONF A.4.3. YANG Model
server that only supports TLS, both listening for incoming
connections as well as calling home to a single application having
two endpoints.
<restconf-server xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf-server"> This YANG module imports YANG types from [RFC6991] and [RFC7407].
<listen>
<endpoint> <CODE BEGINS> file "ietf-netconf-server-new@2015-07-06.yang"
<name>primary-restconf-endpoint</name>
<tls> module ietf-netconf-server-new {
<address>11.22.33.44</address> yang-version 1.1;
<certificates>
<certificate>fw1.east.example.com</certificate> namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-server-new";
</certificates> prefix "ncserver";
</tls>
</endpoint> import ietf-inet-types { // RFC 6991
</listen> prefix inet;
<call-home> }
<application> import ietf-x509-cert-to-name { // RFC 7407
<name>config-mgr</name> prefix x509c2n;
<tls> }
<endpoints> import ietf-ssh-server { // RFC VVVV
<endpoint> prefix ss;
<name>east-data-center</name> }
<address>11.22.33.44</address> import ietf-tls-server { // RFC VVVV
</endpoint> prefix ts;
<endpoint> }
<name>west-data-center</name>
<address>55.66.77.88</address> organization
</endpoint> "IETF NETCONF (Network Configuration) Working Group";
</endpoints>
<certificates> contact
<certificate>fw1.east.example.com</certificate> "WG Web: <http://tools.ietf.org/wg/netconf/>
</certificates> WG List: <mailto:netconf@ietf.org>
</tls>
</application> WG Chair: Mehmet Ersue
</call-home> <mailto:mehmet.ersue@nsn.com>
</restconf-server>
WG Chair: Mahesh Jethanandani
<mailto:mjethanandani@gmail.com>
Editor: Kent Watsen
<mailto:kwatsen@juniper.net>";
description
"This module contains a collection of YANG definitions for
configuring NETCONF servers.
Copyright (c) 2014 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC VVVV; see
the RFC itself for full legal notices.";
revision "2015-07-06" {
description
"Initial version";
reference
"RFC VVVV: NETCONF Server and RESTCONF Server Configuration
Models";
}
// Features
feature ssh-listen {
description
"The ssh-listen feature indicates that the NETCONF server
supports opening a port to accept NETCONF over SSH
client connections.";
reference
"RFC 6242: Using the NETCONF Protocol over Secure Shell (SSH)";
}
feature ssh-call-home {
description
"The ssh-call-home feature indicates that the NETCONF
server supports initiating a NETCONF over SSH call
home connection to NETCONF clients.";
reference
"RFC YYYY: NETCONF Call Home and RESTCONF Call Home";
}
feature tls-listen {
description
"The tls-listen feature indicates that the NETCONF server
supports opening a port to accept NETCONF over TLS
client connections.";
reference
"RFC 5539: Using the NETCONF Protocol over Transport
Layer Security (TLS) with Mutual X.509
Authentication";
}
feature tls-call-home {
description
"The tls-call-home feature indicates that the NETCONF
server supports initiating a NETCONF over TLS call
home connection to NETCONF clients.";
reference
"RFC YYYY: NETCONF Call Home and RESTCONF Call Home";
}
feature ssh-x509-certs {
description
"The ssh-x509-certs feature indicates that the NETCONF server
supports RFC 6187";
reference
"RFC 6187: X.509v3 Certificates for Secure Shell Authentication";
}
// top-level container (groupings below)
container netconf-server {
description
"Top-level container for NETCONF server configuration.";
container session-options { // SHOULD WE REMOVE THIS ALTOGETHER?
description
"NETCONF session options, independent of transport
or connection strategy.";
leaf hello-timeout {
type uint16;
units "seconds";
default 600;
description
"Specifies the maximum number of seconds that a SSH/TLS
connection may wait for a hello message to be received.
A connection will be dropped if no hello message is
received before this number of seconds elapses. If set
to zero, then the server will wait forever for a hello
message.";
}
}
container listen {
description
"Configures listen behavior";
if-feature "(ssh-listen or tls-listen)";
leaf max-sessions {
type uint16;
default 0;
description
"Specifies the maximum number of concurrent sessions
that can be active at one time. The value 0 indicates
that no artificial session limit should be used.";
}
leaf idle-timeout {
type uint16;
units "seconds";
default 3600; // one hour
description
"Specifies the maximum number of seconds that a NETCONF
session may remain idle. A NETCONF session will be dropped
if it is idle for an interval longer than this number of
seconds. If set to zero, then the server will never drop
a session because it is idle. Sessions that have a
notification subscription active are never dropped.";
}
list endpoint {
key name;
description
"List of endpoints to listen for NETCONF connections on.";
leaf name {
type string;
description
"An arbitrary name for the NETCONF listen endpoint.";
}
choice transport {
mandatory true;
description
"Selects between available transports.";
case ssh {
if-feature ssh-listen;
container ssh {
description
"SSH-specific listening configuration for inbound
connections.";
uses address-and-port-grouping {
refine port {
default 830;
}
}
uses ss:ssh-server-grouping;
}
}
case tls {
if-feature tls-listen;
container tls {
description
"TLS-specific listening configuration for inbound
connections.";
uses address-and-port-grouping {
refine port {
default 6513;
}
}
uses tls-server-grouping;
}
}
}
}
}
container call-home {
if-feature "(ssh-call-home or tls-call-home)";
description
"Configures call-home behavior";
list netconf-client {
key name;
description
"List of NETCONF clients the NETCONF server is to initiate
call-home connections to.";
leaf name {
type string;
description
"An arbitrary name for the remote NETCONF client.";
}
choice transport {
mandatory true;
description
"Selects between available transports.";
case ssh {
if-feature ssh-call-home;
container ssh {
description
"Specifies SSH-specific call-home transport
configuration.";
uses endpoints-container {
refine endpoints/endpoint/port {
default 7777;
}
}
uses ss:ssh-server-grouping;
}
}
case tls {
if-feature tls-call-home;
container tls {
description
"Specifies TLS-specific call-home transport
configuration.";
uses endpoints-container {
refine endpoints/endpoint/port {
default 8888;
}
}
uses tls-server-grouping;
}
}
}
container connection-type {
description
"Indicates the kind of connection to use.";
choice connection-type {
description
"Selects between available connection types.";
case persistent-connection {
container persistent {
presence true;
description
"Maintain a persistent connection to the NETCONF
client. If the connection goes down, immediately
start trying to reconnect to it, using the
reconnection strategy.
This connection type minimizes any NETCONF client
to NETCONF server data-transfer delay, albeit at
the expense of holding resources longer.";
leaf idle-timeout {
type uint32;
units "seconds";
default 86400; // one day;
description
"Specifies the maximum number of seconds that a
a NETCONF session may remain idle. A NETCONF
session will be dropped if it is idle for an
interval longer than this number of seconds.
If set to zero, then the server will never drop
a session because it is idle. Sessions that
have a notification subscription active are
never dropped.";
}
container keep-alives {
description
"Configures the keep-alive policy, to proactively
test the aliveness of the SSH/TLS client. An
unresponsive SSH/TLS client will be dropped after
approximately (max-attempts * max-wait) seconds.";
reference
"RFC YYYY: NETCONF Call Home and RESTCONF Call Home,
Section 3.1, item S6";
leaf max-wait {
type uint16 {
range "1..max";
}
units seconds;
default 30;
description
"Sets the amount of time in seconds after which
if no data has been received from the SSH/TLS
client, a SSH/TLS-level message will be sent
to test the aliveness of the SSH/TLS client.";
}
leaf max-attempts {
type uint8;
default 3;
description
"Sets the number of sequential keep-alive messages
that can fail to obtain a response from the SSH/TLS
client before assuming the SSH/TLS client is no
longer alive.";
}
}
}
}
case periodic-connection {
container periodic {
presence true;
description
"Periodically connect to the NETCONF client, so that
the NETCONF client may deliver messages pending for
the NETCONF server. The NETCONF client is expected
to close the connection when it is ready to release
it, thus starting the NETCONF server's timer until
next connection.";
leaf idle-timeout {
type uint16;
units "seconds";
default 300; // five minutes
description
"Specifies the maximum number of seconds that a
a NETCONF session may remain idle. A NETCONF
session will be dropped if it is idle for an
interval longer than this number of seconds.
If set to zero, then the server will never drop
a session because it is idle. Sessions that
have a notification subscription active are
never dropped.";
}
leaf reconnect_timeout {
type uint16 {
range "1..max";
}
units minutes;
default 60;
description
"The maximum amount of unconnected time the NETCONF
server will wait before re-establishing a connection
to the NETCONF client. The NETCONF server may
initiate a connection before this time if desired
(e.g., to deliver a notification).";
}
}
}
}
}
container reconnect-strategy {
description
"The reconnection strategy guides how a NETCONF server
reconnects to an NETCONF client, after losing a connection
to it, even if due to a reboot. The NETCONF server starts
with the specified endpoint and tries to connect to it
max-attempts times before trying the next endpoint in the
list (round robin).";
leaf start-with {
type enumeration {
enum first-listed {
description
"Indicates that reconnections should start with
the first endpoint listed.";
}
enum last-connected {
description
"Indicates that reconnections should start with
the endpoint last connected to. If no previous
connection has ever been established, then the
first endpoint configured is used. NETCONF
servers SHOULD be able to remember the last
endpoint connected to across reboots.";
}
}
default first-listed;
description
"Specifies which of the NETCONF client's endpoints the
NETCONF server should start with when trying to connect
to the NETCONF client.";
}
leaf max-attempts {
type uint8 {
range "1..max";
}
default 3;
description
"Specifies the number times the NETCONF server tries to
connect to a specific endpoint before moving on to the
next endpoint in the list (round robin).";
}
}
}
}
}
grouping tls-server-grouping {
description
"An augmentation of tls-server-grouping, as defined in the
ietf-tls-server module, to add in cert-maps.";
uses ts:tls-server-grouping {
augment "client-auth" {
container cert-maps {
uses x509c2n:cert-to-name;
description
"The cert-maps container is used by a NETCONF server to
map the NETCONF client's presented X.509 certificate to a
NETCONF username. If no matching and valid cert-to-name
list entry can be found, then the NETCONF server MUST
close the connection, and MUST NOT accept NETCONF
messages over it.";
reference
"RFC WWWW: NETCONF over TLS, Section 7";
}
}
}
}
grouping address-and-port-grouping {
description
"This grouping is used by both the ssh and tls containers
for listen configuration.";
leaf address {
type inet:ip-address;
description
"The IP address of the interface to listen on. The NETCONF
server will listen on all interfaces if no value is
specified.";
}
leaf port {
type inet:port-number;
description
"The local port number on this interface the NETCONF server
listens on. The NETCONF server will use the IANA-assigned
well-known port if no value is specified.";
}
}
grouping endpoints-container {
description
"This grouping is used by both the ssh and tls containers
for call-home configurations.";
container endpoints {
description
"Container for the list of endpoints.";
list endpoint {
key name;
min-elements 1;
ordered-by user;
description
"User-ordered list of endpoints for this NETCONF client.
Defining more than one enables high-availability.";
leaf name {
type string;
description
"An arbitrary name for this endpoint.";
}
leaf address {
type inet:host;
mandatory true;
description
"The IP address or hostname of the endpoint. If a
hostname is configured and the DNS resolution results
in more than one IP address, the NETCONF server
will process the IP addresses as if they had been
explicitly configured in place of the hostname.";
}
leaf port {
type inet:port-number;
description
"The IP port for this endpoint. The NETCONF server will
use the IANA-assigned well-known port if no value is
specified.";
}
}
}
}
}
<CODE ENDS>
A.5. The RESTCONF Server Model
A.5.1. Tree Diagram
module: ietf-restconf-server-new
+--rw restconf-server
+--rw listen {tls-listen}?
| +--rw max-sessions? uint16
| +--rw endpoint* [name]
| +--rw name string
| +--rw (transport)
| +--:(tls)
| +--rw tls
| +--rw address? inet:ip-address
| +--rw port? inet:port-number
| +--rw certificates
| | +--rw certificate* [name]
| | +--rw name -> /kc:keychain/private-keys/private-key/certificates/certificate/name
| +--rw client-auth
| +--rw trusted-ca-certs? -> /kc:keychain/trusted-certificates/name
| +--rw trusted-client-certs? -> /kc:keychain/trusted-certificates/name
| +--rw cert-maps
| +--rw cert-to-name* [id]
| +--rw id uint32
| +--rw fingerprint x509c2n:tls-fingerprint
| +--rw map-type identityref
| +--rw name string
+--rw call-home {tls-call-home}?
+--rw restconf-client* [name]
+--rw name string
+--rw (transport)
| +--:(tls)
| +--rw tls
| +--rw endpoints
| | +--rw endpoint* [name]
| | +--rw name string
| | +--rw address inet:host
| | +--rw port? inet:port-number
| +--rw certificates
| | +--rw certificate* [name]
| | +--rw name -> /kc:keychain/private-keys/private-key/certificates/certificate/name
| +--rw client-auth
| +--rw trusted-ca-certs? -> /kc:keychain/trusted-certificates/name
| +--rw trusted-client-certs? -> /kc:keychain/trusted-certificates/name
| +--rw cert-maps
| +--rw cert-to-name* [id]
| +--rw id uint32
| +--rw fingerprint x509c2n:tls-fingerprint
| +--rw map-type identityref
| +--rw name string
+--rw connection-type
| +--rw (connection-type)?
| +--:(persistent-connection)
| | +--rw persistent!
| | +--rw keep-alives
| | +--rw max-wait? uint16
| | +--rw max-attempts? uint8
| +--:(periodic-connection)
| +--rw periodic!
| +--rw reconnect-timeout? uint16
+--rw reconnect-strategy
+--rw start-with? enumeration
+--rw max-attempts? uint8
A.5.2. Example Usage
TBD
A.5.3. YANG Model
This YANG module imports YANG types from [RFC6991] and [RFC7407].
<CODE BEGINS> file "ietf-restconf-server-new@2015-07-06.yang"
module ietf-restconf-server-new {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-restconf-server-new";
prefix "rcserver";
import ietf-netconf-acm {
prefix nacm; // RFC 6536
}
import ietf-inet-types { // RFC 6991
prefix inet;
}
import ietf-x509-cert-to-name { // RFC 7407
prefix x509c2n;
}
import ietf-tls-server { // RFC VVVV
prefix ts;
}
organization
"IETF NETCONF (Network Configuration) Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/netconf/>
WG List: <mailto:netconf@ietf.org>
WG Chair: Mehmet Ersue
<mailto:mehmet.ersue@nsn.com>
WG Chair: Mahesh Jethanandani
<mailto:mjethanandani@gmail.com>
Editor: Kent Watsen
<mailto:kwatsen@juniper.net>";
description
"This module contains a collection of YANG definitions for
configuring RESTCONF servers.
Copyright (c) 2014 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC VVVV; see
the RFC itself for full legal notices.";
revision "2015-07-06" {
description
"Initial version";
reference
"RFC VVVV: NETCONF Server and RESTCONF Server Configuration
Models";
}
// Features
feature tls-listen {
description
"The listen feature indicates that the RESTCONF server
supports opening a port to listen for incoming RESTCONF
client connections.";
reference
"RFC XXXX: RESTCONF Protocol";
}
feature tls-call-home {
description
"The call-home feature indicates that the RESTCONF server
supports initiating connections to RESTCONF clients.";
reference
"RFC YYYY: NETCONF Call Home and RESTCONF Call Home";
}
feature client-cert-auth {
description
"The client-cert-auth feature indicates that the RESTCONF
server supports the ClientCertificate authentication scheme.";
reference
"RFC ZZZZ: Client Authentication over New TLS Connection";
}
// top-level container (groupings below)
container restconf-server {
description
"Top-level container for RESTCONF server configuration.";
container listen {
description
"Configures listen behavior";
if-feature tls-listen;
leaf max-sessions {
type uint16;
default 0; // should this be 'max'?
description
"Specifies the maximum number of concurrent sessions
that can be active at one time. The value 0 indicates
that no artificial session limit should be used.";
}
list endpoint {
key name;
description
"List of endpoints to listen for RESTCONF connections on.";
leaf name {
type string;
description
"An arbitrary name for the RESTCONF listen endpoint.";
}
choice transport {
mandatory true;
description
"Selects between available transports.";
case tls {
container tls {
description
"TLS-specific listening configuration for inbound
connections.";
leaf address {
type inet:ip-address;
description
"The IP address of the interface to listen on. The
RESTCONF server will listen on all interfaces if
no value is specified.";
}
leaf port {
type inet:port-number;
default 443;
description
"The port number the RESTCONF server will listen on.";
}
uses tls-server-grouping;
}
}
}
}
}
container call-home {
if-feature tls-call-home;
description
"Configures call-home behavior";
list restconf-client {
key name;
description
"List of RESTCONF clients the RESTCONF server is to
initiate call-home connections to.";
leaf name {
type string;
description
"An arbitrary name for the remote RESTCONF client.";
}
choice transport {
mandatory true;
description
"Selects between TLS and any transports augmented in.";
case tls {
container tls {
description
"Specifies TLS-specific call-home transport
configuration.";
container endpoints {
description
"Container for the list of endpoints.";
list endpoint {
key name;
min-elements 1;
ordered-by user;
description
"User-ordered list of endpoints for this RESTCONF
client. More than one enables high-availability.";
leaf name {
type string;
description
"An arbitrary name for this endpoint.";
}
leaf address {
type inet:host;
mandatory true;
description
"The IP address or hostname of the endpoint. If
a hostname is configured and the DNS resolution
results in more than one IP address, the RESTCONF
server will process the IP addresses as if they
had been explicitly configured in place of the
hostname.";
}
leaf port {
type inet:port-number;
default 9999;
description
"The IP port for this endpoint. The RESTCONF
server will use the IANA-assigned well-known
port if no value is specified.";
}
}
}
uses tls-server-grouping;
}
}
}
container connection-type {
description
"Indicates the RESTCONF client's preference for how the
RESTCONF server's connection is maintained.";
choice connection-type {
description
"Selects between available connection types.";
case persistent-connection {
container persistent {
presence true;
description
"Maintain a persistent connection to the RESTCONF
client. If the connection goes down, immediately
start trying to reconnect to it, using the
reconnection strategy.
This connection type minimizes any RESTCONF client
to RESTCONF server data-transfer delay, albeit at
the expense of holding resources longer.";
container keep-alives {
description
"Configures the keep-alive policy, to proactively
test the aliveness of the TLS client. An
unresponsive TLS client will be dropped after
approximately (max-attempts * max-wait) seconds.";
reference
"RFC YYYY: NETCONF Call Home and RESTCONF Call Home,
Section 3.1, item S6";
leaf max-wait {
type uint16 {
range "1..max";
}
units seconds;
default 30;
description
"Sets the amount of time in seconds after which
if no data has been received from the TLS
client, a TLS-level message will be sent to
test the aliveness of the TLS client.";
}
leaf max-attempts {
type uint8;
default 3;
description
"Sets the number of sequential keep-alive messages
that can fail to obtain a response from the TLS
client before assuming the TLS client is no
longer alive.";
}
}
}
}
case periodic-connection {
container periodic {
presence true;
description
"Periodically connect to the RESTCONF client, so that
the RESTCONF client may deliver messages pending for
the RESTCONF server. The RESTCONF client is expected
to close the connection when it is ready to release
it, thus starting the RESTCONF server's timer until
next connection.";
leaf reconnect-timeout {
type uint16 {
range "1..max";
}
units minutes;
default 60;
description
"The maximum amount of unconnected time the RESTCONF
server will wait before re-establishing a connection
to the RESTCONF client. The RESTCONF server may
initiate a connection before this time if desired
(e.g., to deliver a notification).";
}
}
}
}
}
container reconnect-strategy {
description
"The reconnection strategy guides how a RESTCONF server
reconnects to an RESTCONF client, after losing a connection
to it, even if due to a reboot. The RESTCONF server starts
with the specified endpoint and tries to connect to it
max-attempts times before trying the next endpoint in the
list (round robin).";
leaf start-with {
type enumeration {
enum first-listed {
description
"Indicates that reconnections should start with
the first endpoint listed.";
}
enum last-connected {
description
"Indicates that reconnections should start with
the endpoint last connected to. If no previous
connection has ever been established, then the
first endpoint configured is used. RESTCONF
servers SHOULD be able to remember the last
endpoint connected to across reboots.";
}
}
default first-listed;
description
"Specifies which of the RESTCONF client's endpoints the
RESTCONF server should start with when trying to connect
to the RESTCONF client.";
}
leaf max-attempts {
type uint8 {
range "1..max";
}
default 3;
description
"Specifies the number times the RESTCONF server tries to
connect to a specific endpoint before moving on to the
next endpoint in the list (round robin).";
}
}
}
}
}
grouping tls-server-grouping {
description
"An augmentation of tls-server-grouping, as defined in the
ietf-tls-server module, to add in cert-maps.";
uses ts:tls-server-grouping {
augment "client-auth" {
container cert-maps {
uses x509c2n:cert-to-name;
description
"The cert-maps container is used by a NETCONF server to
map the NETCONF client's presented X.509 certificate to a
NETCONF username. If no matching and valid cert-to-name
list entry can be found, then the NETCONF server MUST
close the connection, and MUST NOT accept NETCONF
messages over it.";
reference
"RFC WWWW: NETCONF over TLS, Section 7";
}
}
}
}
}
<CODE ENDS>
Appendix B. Change Log Appendix B. Change Log
B.1. 00 to 01 B.1. 00 to 01
o Restructured document so it flows better o Restructured document so it flows better
o Added trusted-ca-certs and trusted-client-certs objects into the o Added trusted-ca-certs and trusted-client-certs objects into the
ietf-system-tls-auth module ietf-system-tls-auth module
B.2. 01 to 02 B.2. 01 to 02
o removed the "one-to-many" construct o removed the "one-to-many" construct
o removed "address" as a key field o removed "address" as a key field
o removed "network-manager" terminology o removed "network-manager" terminology
skipping to change at page 49, line 41 skipping to change at page 86, line 5
o Updated draft-ietf-netmod-snmp-cfg reference to RFC 7407 (issue o Updated draft-ietf-netmod-snmp-cfg reference to RFC 7407 (issue
#28). #28).
o Added description statements for groupings (issue #29). o Added description statements for groupings (issue #29).
o Added description for braces to tree diagram section (issue #30). o Added description for braces to tree diagram section (issue #30).
o Renamed feature from "rfc6187" to "ssh-x509-certs" (issue #31). o Renamed feature from "rfc6187" to "ssh-x509-certs" (issue #31).
B.7. 06 to 07
o Replaced "application" with "NETCONF/RESTCONF client" (issue #32).
o Reverted back to YANG 1.1 if-feature statements (issue #34).
o Removed import by revisions (issue #36).
o Removed groupings only used once (issue #37).
o Removed upper-bound on hello-timeout, idle-timeout, and max-
sessions (issue #38).
o Clarified that when no listen address is configured, the NETCONF/
RESTCONF server will listen on all addresses (issue #41).
o Update keep-alive reference to new section in Call Home draft
(issue #42).
o Modified connection-type/persistent/keep-alives/interval-secs
default value, removed the connection-type/periodic/linger-secs
node, and also removed the reconnect-strategy/interval-secs node
(issue #43).
o Clarified how last-connected reconnection type should work across
reboots (issue #44).
o Clarified how DNS-expanded hostnames should be processed (issue
#45).
o Removed text on how to implement keep-alives (now in the call-home
draft) and removed the keep-alive configuration for listen
connections (issue #46).
o Clarified text for .../periodic-connection/timeout-mins (issue
#47).
o Fixed description on the "trusted-ca-certs" leaf-list (issue #48).
o Added optional keychain-based solution in appendix A (issue #49).
o Fixed description text for the interval-secs leaf (issue #50).
o moved idle-time into the listen, persistent, and periodic subtrees
(issue #51).
o put presence statements on containers where it makes sense (issue
#53).
Appendix C. Open Issues Appendix C. Open Issues
Please see: https://github.com/netconf-wg/server-model/issues. Please see: https://github.com/netconf-wg/server-model/issues.
Authors' Addresses Authors' Addresses
Kent Watsen Kent Watsen
Juniper Networks Juniper Networks
EMail: kwatsen@juniper.net EMail: kwatsen@juniper.net
 End of changes. 206 change blocks. 
997 lines changed or deleted 2793 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/