< draft-ietf-netconf-server-model-05.txt   draft-ietf-netconf-server-model-06.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: June 14, 2015 Jacobs University Bremen Expires: August 6, 2015 Jacobs University Bremen
December 11, 2014 February 2, 2015
NETCONF Server and RESTCONF Server Configuration Models NETCONF Server and RESTCONF Server Configuration Models
draft-ietf-netconf-server-model-05 draft-ietf-netconf-server-model-06
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 listens on, whether call-home is supported, and associated
parameters. parameters.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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-rfc5539bis
o draft-ietf-netconf-restconf o draft-ietf-netconf-restconf
o draft-ietf-netconf-call-home o draft-ietf-netconf-call-home
o draft-ietf-netmod-snmp-cfg
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- o "WWWW" --> the assigned RFC value for draft-ietf-netconf-
rfc5539bis 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-ietf-netmod-snmp-cfg 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"
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 "2014-12-11" --> the publication date of this draft o "2015-02-02" --> 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 48 skipping to change at page 2, line 45
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 June 14, 2015. This Internet-Draft will expire on August 6, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . 4
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 clients certificates . . . 5 2.3. Support authenticating NETCONF/RESTCONF clients
2.4. Support mapping authenticated NETCONF client-certificates certificates . . . . . . . . . . . . . . . . . . . . . . 5
to usernames . . . . . . . . . . . . . . . . . . . . . . 6 2.4. Support mapping authenticated NETCONF/RESTCONF client
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 northbound application . . . . 6
2.6.2. Support applications having more than one server . . 6 2.6.2. Support applications having more than one server . . 6
2.6.3. Support a reconnection strategy . . . . . . . . . . . 6 2.6.3. Support a reconnection strategy . . . . . . . . . . . 6
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 . . . . . . . 7
3. The NETCONF Server Configuration Model . . . . . . . . . . . 8 3. The NETCONF Server Configuration Model . . . . . . . . . . . 8
skipping to change at page 3, line 52 skipping to change at page 3, line 48
3.1.1. The "session-options" subtree . . . . . . . . . . . . 8 3.1.1. The "session-options" subtree . . . . . . . . . . . . 8
3.1.2. The "listen" subtree . . . . . . . . . . . . . . . . 8 3.1.2. The "listen" subtree . . . . . . . . . . . . . . . . 8
3.1.3. The "call-home" subtree . . . . . . . . . . . . . . . 9 3.1.3. The "call-home" subtree . . . . . . . . . . . . . . . 9
3.1.4. The "ssh" subtree . . . . . . . . . . . . . . . . . . 11 3.1.4. The "ssh" subtree . . . . . . . . . . . . . . . . . . 11
3.1.5. The "tls" subtree . . . . . . . . . . . . . . . . . . 11 3.1.5. The "tls" subtree . . . . . . . . . . . . . . . . . . 11
3.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 12 3.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 12
4. The RESTCONF Server Configuration Model . . . . . . . . . . . 25 4. The RESTCONF Server Configuration Model . . . . . . . . . . . 25
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 25 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.1. The "listen" subtree . . . . . . . . . . . . . . . . 25 4.1.1. The "listen" subtree . . . . . . . . . . . . . . . . 25
4.1.2. The "call-home" subtree . . . . . . . . . . . . . . . 26 4.1.2. The "call-home" subtree . . . . . . . . . . . . . . . 26
4.1.3. The "client-cert-auth" subtree . . . . . . . . . . . 28
4.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 28 4.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 28
5. Implementation strategy for keep-alives . . . . . . . . . . . 39
5.1. Keep-alives for SSH . . . . . . . . . . . . . . . . . . . 39
5.2. Keep-alives for TLS . . . . . . . . . . . . . . . . . . . 40
5. Implementation strategy for keep-alives . . . . . . . . . . . 36 6. Security Considerations . . . . . . . . . . . . . . . . . . . 40
5.1. Keep-alives for SSH . . . . . . . . . . . . . . . . . . . 37 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
5.2. Keep-alives for TLS . . . . . . . . . . . . . . . . . . . 37 8. Other Considerations . . . . . . . . . . . . . . . . . . . . 41
6. Security Considerations . . . . . . . . . . . . . . . . . . . 37 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
8. Other Considerations . . . . . . . . . . . . . . . . . . . . 39 10.1. Normative References . . . . . . . . . . . . . . . . . . 42
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 10.2. Informative References . . . . . . . . . . . . . . . . . 43
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 44
10.1. Normative References . . . . . . . . . . . . . . . . . . 39 A.1. NETCONF Configuration using SSH Transport . . . . . . . . 44
10.2. Informative References . . . . . . . . . . . . . . . . . 40 A.2. NETCONF Configuration using TLS Transport . . . . . . . . 45
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 41 A.3. RESTCONF Configuration using TLS Transport . . . . . . . 47
A.1. NETCONF Configuration using SSH Transport . . . . . . . . 41 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 47
A.2. NETCONF Configuration using TLS Transport . . . . . . . . 42 B.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 47
A.3. RESTCONF Configuration using TLS Transport . . . . . . . 44 B.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 48
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 44 B.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 48
B.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 44 B.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 48
B.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 45 B.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 48
B.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 45 B.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 49
B.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 45 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 49
B.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 45
Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 46
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 listens on, whether
call-home is supported, and associated parameters. call-home is supported, and associated parameters.
skipping to change at page 4, line 50 skipping to change at page 4, line 48
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
this document. The meaning of the symbols in these diagrams is as this document. The meaning of the symbols in these diagrams is as
follows: follows:
o Brackets "[" and "]" enclose list keys. o Brackets "[" and "]" enclose list keys.
o Braces "{" and "}" enclose feature names, and indicate that the
named feature must be present for the subtree to be present.
o Abbreviations before data node names: "rw" means configuration o Abbreviations before data node names: "rw" means configuration
(read-write) and "ro" state data (read-only). (read-write) and "ro" state data (read-only).
o Symbols after data node names: "?" means an optional node, "!" o Symbols after data node names: "?" means an optional node, "!"
means a presence container, and "*" denotes a list and leaf-list. means a presence container, and "*" denotes a list and leaf-list.
o Parentheses enclose choice and case nodes, and case nodes are also o Parentheses enclose choice and case nodes, and case nodes are also
marked with a colon (":"). marked with a colon (":").
o Ellipsis ("...") stands for contents of subtrees that are not o Ellipsis ("...") stands for contents of subtrees that are not
skipping to change at page 5, line 41 skipping to change at page 5, line 41
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
listening on port 830, and a different set of SSH host-keys when listening on port 830, and a different set of SSH host-keys when
calling home. The data models provided herein should enable calling home. The data models provided herein should enable
configuration of which keys to use on a per-use basis. configuration of which keys to use on a per-use basis.
2.3. Support authenticating NETCONF clients certificates 2.3. Support authenticating NETCONF/RESTCONF clients certificates
When a certificate is used to authenticate a NETCONF client, either When a certificate is used to authenticate a NETCONF or RESTCONF
when using the TLS transport or the SSH transport with X.509 client, there is a need to configure the server to know how to
certificates [RFC6187], there is a need to configure the server to authenticate the certificates. The server should be able to
know how to authenticate the certificates. The server should be able authenticate the client's certificate either by using path-validation
to do this either by using path-validation to a configured trust to a configured trust anchor or by matching the client-certificate to
anchor or by matching the client-certificate to one previously one previously configured.
configured.
2.4. Support mapping authenticated NETCONF client-certificates to 2.4. Support mapping authenticated NETCONF/RESTCONF client certificates
usernames to usernames
Some NETCONF transports (e.g., TLS) need additional support to map When a client certifcate is used for TLS transport-level
authenticated transport-level sessions to a NETCONF username. The authentication, the NETCONF/RESTCONF server must be able to derive a
NETCONF server model defined herein should define an ability for this username from the authenticated certifcate. Thus the modules defined
mapping to be configured." herein should 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.
skipping to change at page 7, line 34 skipping to change at page 7, line 34
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 application requirements, and therefore keep-alive settings should be
configurable on a per-application basis. configurable on a per-application 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 device
to know how often it should connect. This delay essentially to know how often it should connect. This delay essentially
skipping to change at page 8, line 21 skipping to change at page 8, line 21
time of no data being transmitted as transpired. time of no data being transmitted as transpired.
3. The NETCONF Server Configuration Model 3. The NETCONF Server Configuration Model
3.1. Overview 3.1. Overview
3.1.1. The "session-options" subtree 3.1.1. The "session-options" subtree
module: ietf-netconf-server module: ietf-netconf-server
+--rw netconf-server +--rw netconf-server
+--rw session-options {session-options}? +--rw session-options
+--rw hello-timeout? uint32 +--rw hello-timeout? uint32
+--rw idle-timeout? uint32 +--rw idle-timeout? uint32
The above subtree illustrates how the ietf-netconf-server YANG module The above subtree illustrates how the ietf-netconf-server YANG module
enables configuration of NETCONF session options, independent of any enables configuration of NETCONF session options, independent of any
transport or connection strategy. A feature statement is used for transport or connection strategy. Please see the YANG module
the server to advertise support for configuring these NETCONF server (Section 3.2) for a complete description of these configuration
options. Please see the YANG module (Section 3.2) for a complete knobs.
description of these configuration knobs.
3.1.2. The "listen" subtree 3.1.2. The "listen" subtree
module: ietf-netconf-server module: ietf-netconf-server
+--rw netconf-server +--rw netconf-server
+--rw listen {listen}? +--rw listen {listen}?
+--rw max-sessions? uint16 +--rw max-sessions? uint16
+--rw endpoint* [name] +--rw endpoint* [name]
+--rw name string +--rw name string
+--rw (transport) +--rw (transport)
| +--:(ssh) {ssh}? | +--:(ssh) {ssh}?
skipping to change at page 9, line 29 skipping to change at page 9, line 29
| +--rw address? inet:ip-address | +--rw address? inet:ip-address
| +--rw port? inet:port-number | +--rw port? inet:port-number
| +--rw certificates | +--rw certificates
| +--rw certificate* string | +--rw certificate* string
+--rw keep-alives +--rw keep-alives
+--rw interval-secs? uint8 +--rw interval-secs? uint8
+--rw count-max? uint8 +--rw count-max? uint8
The above subtree illustrates how the ietf-netconf-server YANG module The above subtree illustrates how the ietf-netconf-server YANG module
enables configuration for listening for remote connections, as enables configuration for listening for remote connections, as
described in [RFC6242] and [draft-ietf-netconf-call-home]. Feature described in [RFC6242]. Feature statements are used to limit both if
statements are used to limit both if listening is supported at all as listening is supported at all as well as for which transports. If
well as for which transports. If listening for connections is listening for connections is supported, then the model enables
supported, then the model enables configuring a list of listening configuring a list of listening endpoints, each configured with a
endpoints, each configured with a user-specified name (the key user-specified name (the key field), the transport to use (i.e. SSH,
field), the transport to use (i.e. SSH, TLS), and the IP address and TLS), and the IP address and port to listen on. The port field is
port to listen on. The port field is optional, defaulting to the optional, defaulting to the transport-specific port when not
transport-specific port when not configured. Please see the YANG configured. Please see the YANG module (Section 3.2) for a complete
module (Section 3.2) for a complete description of these description of these configuration knobs.
configuration knobs.
3.1.3. The "call-home" subtree 3.1.3. The "call-home" subtree
module: ietf-netconf-server module: ietf-netconf-server
+--rw netconf-server +--rw netconf-server
+--rw call-home {call-home}? +--rw call-home {call-home}?
+--rw application* [name] +--rw application* [name]
+--rw name string +--rw name string
+--rw (transport) +--rw (transport)
| +--:(ssh) {ssh}? | +--:(ssh) {ssh}?
| | +--rw ssh | | +--rw ssh
skipping to change at page 11, line 16 skipping to change at page 11, line 16
the connection-type (persistent vs. periodic) and associated the connection-type (persistent vs. periodic) and associated
parameters, as well as the reconnection strategy to use. Please see parameters, as well as the reconnection strategy to use. Please see
the YANG module (Section 3.2) for a complete description of these the YANG module (Section 3.2) for a complete description of these
configuration knobs. configuration knobs.
3.1.4. The "ssh" subtree 3.1.4. The "ssh" subtree
module: ietf-netconf-server module: ietf-netconf-server
+--rw netconf-server +--rw netconf-server
+--rw ssh {ssh}? +--rw ssh {ssh}?
+--rw x509 {rfc6187}? +--rw x509 {ssh-x509-certs}?
+--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
The above subtree illustrates how the ietf-netconf-server YANG module The above subtree illustrates how the ietf-netconf-server YANG module
enables some SSH configuration independent of if the NETCONF server enables some SSH configuration independent of if the NETCONF server
is listening or calling home. Specifically, when RFC 6187 is is listening or calling home. Specifically, when RFC 6187 is
supported, this data model provides an ability to configure how supported, this data model provides an ability to configure how
client-certificates are authenticated. Please see the YANG module client-certificates are authenticated. Please see the YANG module
skipping to change at page 12, line 9 skipping to change at page 12, line 9
The above subtree illustrates how the ietf-netconf-server YANG module The above subtree illustrates how the ietf-netconf-server YANG module
enables TLS configuration independent of if the NETCONF server is enables TLS configuration independent of if the NETCONF server is
listening or calling home. Specifically, this data-model provides 1) listening or calling home. Specifically, this data-model provides 1)
an ability to configure how client-certificates are authenticated and an ability to configure how client-certificates are authenticated and
2) how authenticated client-certificates are mapped to NETCONF user 2) how authenticated client-certificates are mapped to NETCONF user
names. Please see the YANG module (Section 3.2) for a complete names. Please see the YANG module (Section 3.2) for a complete
description of these configuration knobs. description of these configuration knobs.
3.2. YANG Module 3.2. YANG Module
This YANG module imports YANG types from [RFC6991], and This YANG module imports YANG types from [RFC6991] and [RFC7407].
[draft-ietf-netmod-snmp-cfg].
<CODE BEGINS> file "ietf-netconf-server@2014-12-11.yang" <CODE BEGINS> file "ietf-netconf-server@2015-02-02.yang"
module ietf-netconf-server { module 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";
import ietf-netconf-acm {
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; revision-date 2013-07-15;
} }
import ietf-x509-cert-to-name { // RFC ZZZZ import ietf-x509-cert-to-name { // RFC 7407
prefix x509c2n; prefix x509c2n;
revision-date 2014-05-06; 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 15 skipping to change at page 13, line 18
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 "2014-12-11" { revision "2015-02-02" {
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 session-options {
description
"The session-options feature indicates that the NETCONF server
supports the session-options container.";
}
feature ssh { feature ssh {
description description
"The ssh feature indicates that the server supports the "The ssh feature indicates that the server supports the
SSH transport protocol."; SSH transport protocol.";
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 tls {
description description
skipping to change at page 14, line 6 skipping to change at page 14, line 4
} }
feature listen { feature listen {
description description
"The listen feature indicates that the server supports "The listen feature indicates that the server supports
opening a port to listen for incoming client connections."; opening a port to listen for incoming client connections.";
reference reference
"RFC 6242: Using the NETCONF Protocol over Secure Shell (SSH) "RFC 6242: Using the NETCONF Protocol over Secure Shell (SSH)
RFC 5539: NETCONF over Transport Layer Security (TLS)"; RFC 5539: NETCONF over Transport Layer Security (TLS)";
} }
feature call-home { feature call-home {
description description
"The call-home feature indicates that the server supports "The call-home feature indicates that the server supports
connecting to the client"; connecting to the client";
reference reference
"RFC YYYY: NETCONF Call Home and RESTCONF Call Home"; "RFC YYYY: NETCONF Call Home and RESTCONF Call Home";
} }
feature rfc6187 { feature ssh-x509-certs {
description description
"The rfc6187 feature indicates that the NETCONF server supports "The ssh-x509-certs feature indicates that the NETCONF server
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; uses session-options-container;
uses listen-container; uses listen-container;
uses call-home-container; uses call-home-container;
uses ssh-container; uses ssh-container;
uses tls-container; uses tls-container;
} }
grouping session-options-container { grouping session-options-container {
description description
""; "This grouping is used only to help improve readability
of the YANG module.";
container session-options { container session-options {
description description
"NETCONF session options, independent of transport or "NETCONF session options, independent of transport
connection strategy."; or connection strategy.";
if-feature session-options;
leaf hello-timeout { leaf hello-timeout {
type uint32 { type uint32 {
range "0 | 10 .. 3600"; range "0 | 10 .. 3600";
} }
units "seconds"; units "seconds";
default '600'; default '600';
description description
"Specifies the number of seconds that a session may exist "Specifies the number of seconds that a session may exist
before the hello PDU is received. A session will be before the hello PDU is received. A session will be
dropped if no hello PDU is received before this number dropped if no hello PDU is received before this number
skipping to change at page 15, line 43 skipping to change at page 15, line 40
This mechanism is independent of keep-alives, as it regards This mechanism is independent of keep-alives, as it regards
activity occurring at the NETCONF protocol layer, whereas activity occurring at the NETCONF protocol layer, whereas
the keep-alive mechanism regards transport-level activity."; the keep-alive mechanism regards transport-level activity.";
} }
} }
} }
grouping listen-container { grouping listen-container {
description 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 listen;
leaf max-sessions { leaf max-sessions {
type uint16 { type uint16 {
range "0 .. 1024"; 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.";
} }
list endpoint { list endpoint {
key name; key name;
description description
"List of endpoints to listen for 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 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 SSH and TLS transports.";
case ssh { case ssh {
if-feature ssh; if-feature ssh;
container ssh { container ssh {
description description
"SSH-specific listening configuration for inbound "SSH-specific listening configuration for inbound
skipping to change at page 17, line 15 skipping to change at page 17, line 13
refine keep-alives/interval-secs { refine keep-alives/interval-secs {
default 0; // disabled by default for listen connections default 0; // disabled by default for listen connections
} }
} }
} }
} }
} }
grouping call-home-container { grouping call-home-container {
description 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 call-home;
description description
"Configures call-home behavior"; "Configures call-home behavior";
list application { list application {
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 {
skipping to change at page 18, line 17 skipping to change at page 18, line 16
refine endpoints/endpoint/port { refine endpoints/endpoint/port {
default 8888; default 8888;
} }
} }
uses certificates-container; uses certificates-container;
} }
} }
} }
container connection-type { container connection-type {
description description
"Indicates the kind of connection to be maintained."; "Indicates the kind of connection to use.";
choice connection-type { choice connection-type {
default persistent-connection; default persistent-connection;
description description
"Selects between persistent and periodic connections."; "Selects between persistent and periodic connections.";
case persistent-connection { case persistent-connection {
container persistent { container persistent {
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
skipping to change at page 20, line 39 skipping to change at page 20, line 38
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 { grouping ssh-container {
description 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;
container x509 { container x509 {
if-feature rfc6187; if-feature ssh-x509-certs;
uses trusted-certs-grouping; uses trusted-certs-grouping;
} }
} }
} }
grouping tls-container { grouping tls-container {
description description
""; "This grouping is used only to help improve readability
of the YANG module.";
container tls { container tls {
description description
"Configures TLS properties not specific to the listen "Configures TLS properties for authenticating clients.";
or call-home use-cases";
if-feature tls; if-feature tls;
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
skipping to change at page 21, line 32 skipping to change at page 21, line 32
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.";
} }
} }
} }
} }
grouping trusted-certs-grouping { grouping trusted-certs-grouping {
description description
""; "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. A client's certificate is authenticated
if there is a chain of trust to a configured trusted CA if there is a chain of trust to a configured trusted CA
certificate. The client certificate MAY be accompanied certificate. The client certificate MAY be accompanied
with additional certificates forming a chain of trust. with additional certificates forming a chain of trust.
The client's certificate is authenticated if there is The client's certificate is authenticated if there is
path-validation from any of the certificates it presents path-validation from any of the certificates it presents
to a configured trust anchor."; to a configured trust anchor.";
leaf-list trusted-ca-cert { leaf-list trusted-ca-cert {
type binary; type binary;
ordered-by system; ordered-by system;
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
match to a configured trusted client certificates."; match to a configured trusted client certificates.";
leaf-list trusted-client-cert { leaf-list trusted-client-cert {
type binary; type binary;
ordered-by system; ordered-by system;
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-container {
description description
""; "This grouping is used by both the listen and
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;
description description
"A user-ordered list of host-keys the SSH server "A user-ordered list of host-keys the SSH server
considers when composing the list of server host considers when composing the list of server host
skipping to change at page 23, line 11 skipping to change at page 23, line 14
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-container {
description description
""; "This grouping is used by both the listen and
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
"An unordered list of certificates the TLS server can pick "An unordered list of certificates the TLS server can pick
from when sending its Server Certificate message. The value from when sending its Server Certificate message. The value
of the string is the unique identifier for a certificate of the string is the unique identifier for a certificate
skipping to change at page 23, line 34 skipping to change at page 23, line 38
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
"a common grouping"; "This grouping is usd by both the ssh and tls containers
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.";
} }
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.";
skipping to change at page 23, line 47 skipping to change at page 24, line 4
description description
"The IP address of the interface to listen on."; "The IP address of the interface to listen on.";
} }
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.";
} }
} }
grouping endpoints-container { grouping endpoints-container {
description description
"Grouping for transport-specific configuration for "This grouping is used by both the ssh and tls containers
call-home connections."; 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;
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.";
skipping to change at page 24, line 42 skipping to change at page 24, line 45
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 not specified.";
} }
} }
} }
} }
grouping keep-alives-container { grouping keep-alives-container {
description description
""; "This grouping is use by both listen and call-home configurations.";
container keep-alives { container keep-alives {
description description
"Configures the keep-alive policy, to proactively test the "Configures the keep-alive policy, to proactively test the
aliveness of the NETCONF client, in order to know when a aliveness of the NETCONF client.";
new call home connection should be established.";
reference reference
"RFC VVVV: NETCONF Server and RESTCONF Server Configuration "RFC VVVV: NETCONF Server and RESTCONF Server Configuration
Models, Section 4"; Models, Section 4";
leaf interval-secs { leaf interval-secs {
type uint8; type uint8;
units seconds; units seconds;
description description
"Sets a timeout interval in seconds after which if no data "Sets a timeout interval in seconds after which if no data
has been received from the NETCONF client, a message will has been received from the NETCONF client, a message will
be sent to request a response from the NETCONF client. A be sent to request a response from the NETCONF client. A
skipping to change at page 25, line 24 skipping to change at page 25, line 26
type uint8; type uint8;
default 3; default 3;
description description
"Sets the number of keep-alive messages that may be sent "Sets the number of keep-alive messages that may be sent
without receiving any data from the NETCONF client before without receiving any data from the NETCONF client before
assuming the NETCONF client is no longer alive. If this assuming the NETCONF client is no longer alive. If this
threshold is reached, the transport-level connection will threshold is reached, the transport-level connection will
be disconnected, which will trigger the reconnection be disconnected, which will trigger the reconnection
strategy). The interval timer is reset after each strategy). The interval timer is reset after each
transmission, thus an unresponsive NETCONF client will transmission, thus an unresponsive NETCONF client will
be dropped after ~count-max * interval-secs seconds."; be dropped after approximately (count-max * interval-secs)
seconds.";
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
4. The RESTCONF Server Configuration Model 4. The RESTCONF Server Configuration Model
4.1. Overview 4.1. Overview
skipping to change at page 26, line 23 skipping to change at page 26, line 23
| +--rw address? inet:ip-address | +--rw address? inet:ip-address
| +--rw port? inet:port-number | +--rw port? inet:port-number
| +--rw certificates | +--rw certificates
| +--rw certificate* string | +--rw certificate* string
+--rw keep-alives +--rw keep-alives
+--rw interval-secs? uint8 +--rw interval-secs? uint8
+--rw count-max? uint8 +--rw count-max? uint8
The above subtree illustrates how the ietf-restconf-server YANG The above subtree illustrates how the ietf-restconf-server YANG
module enables configuration for listening for remote connections, as module enables configuration for listening for remote connections, as
described in [draft-ietf-netconf-restconf] and described in [draft-ietf-netconf-restconf]. Feature statements are
[draft-ietf-netconf-call-home]. Feature statements are used to limit used to limit both if listening is supported at all as well as for
both if listening is supported at all as well as for which which transports. If listening for connections is supported, then
transports. If listening for connections is supported, then the the model enables configuring a list of listening endpoints, each
model enables configuring a list of listening endpoints, each
configured with a user-specified name (the key field), the transport configured with a user-specified name (the key field), the transport
to use (i.e. SSH, TLS), and the IP address and port to listen on. to use (i.e. TLS), and the IP address and port to listen on. The
The port field is optional, defaulting to the transport-specific port port field is optional, defaulting to the transport-specific port
when not configured. Please see the YANG module (Section 4.2) for a when not configured. Please see the YANG module (Section 4.2) for a
complete description of these configuration knobs. complete description of these configuration knobs.
4.1.2. The "call-home" subtree 4.1.2. The "call-home" subtree
module: ietf-restconf-server module: ietf-restconf-server
+--rw restconf-server +--rw restconf-server
+--rw call-home {call-home}? +--rw call-home {call-home}?
+--rw application* [name] +--rw application* [name]
+--rw name string +--rw name string
+--rw (transport) +--rw (transport)
skipping to change at page 27, line 42 skipping to change at page 27, line 42
+--rw interval-secs? uint8 +--rw interval-secs? uint8
+--rw count-max? uint8 +--rw count-max? uint8
The above subtree illustrates how the ietf-restconf-server YANG The above subtree illustrates how the ietf-restconf-server YANG
module enables configuration for call home, as described in module enables configuration for call home, as described in
[draft-ietf-netconf-call-home]. Feature statements are used to limit [draft-ietf-netconf-call-home]. Feature statements are used to limit
both if call-home is supported at all as well as for which 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 transports, if it is. If call-home is supported, then the model
supports configuring a list of applications to connect to. Each supports configuring a list of applications to connect to. Each
application is configured with a user-specified name (the key field), 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 the transport to be used (i.e. TLS), and a list of remote endpoints,
endpoints, each having a name, an IP address, and an optional port. each having a name, an IP address, and an optional port.
Additionally, the configuration for each remote application indicates Additionally, the configuration for each remote application indicates
the connection-type (persistent vs. periodic) and associated the connection-type (persistent vs. periodic) and associated
parameters, as well as the reconnection strategy to use. Please see parameters, as well as the reconnection strategy to use. Please see
the YANG module (Section 4.2) for a complete description of these the YANG module (Section 4.2) for a complete description of these
configuration knobs. configuration knobs.
4.1.3. The "client-cert-auth" subtree
module: ietf-restconf-server
+--rw restconf-server
+--rw client-cert-auth {client-cert-auth}?
+--rw trusted-ca-certs
| +--rw trusted-ca-cert* binary
+--rw trusted-client-certs
| +--rw trusted-client-cert* binary
+--rw cert-maps
+--rw cert-to-name* [id]
+--rw id uint32
+--rw fingerprint x509c2n:tls-fingerprint
+--rw map-type identityref
+--rw name string
The above subtree illustrates how the ietf-restconf-server YANG
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. YANG Module
This YANG module imports YANG types from [RFC6991]. This YANG module imports YANG types from [RFC6991] and [RFC7407].
<CODE BEGINS> file "ietf-restconf-server@2014-12-11.yang" <CODE BEGINS> file "ietf-restconf-server@2015-02-02.yang"
module ietf-restconf-server { module 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";
import ietf-netconf-acm {
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; revision-date 2013-07-15;
} }
import ietf-x509-cert-to-name { // RFC 7407
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 6 skipping to change at page 29, line 37
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 "2014-12-11" { revision "2015-02-02" {
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 {
description description
skipping to change at page 29, line 19 skipping to change at page 30, line 4
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 {
description description
"The tls feature indicates that the server supports RESTCONF "The tls feature indicates that the server supports RESTCONF
over the TLS transport protocol."; over the TLS transport protocol.";
reference reference
"RFC XXXX: RESTCONF Protocol"; "RFC XXXX: RESTCONF Protocol";
} }
feature listen { feature listen {
description description
"The listen feature indicates that the server supports "The listen feature indicates that the server supports
opening a port to listen for incoming client connections."; opening a port to listen for incoming client connections.";
reference reference
"RFC XXXX: RESTCONF Protocol"; "RFC XXXX: RESTCONF Protocol";
} }
feature call-home { feature call-home {
description description
"The call-home feature indicates that the server supports "The call-home feature indicates that the server supports
connecting to the client"; connecting to the client.";
reference reference
"RFC YYYY: NETCONF Call Home and RESTCONF Call Home"; "RFC YYYY: NETCONF Call Home and RESTCONF Call Home";
} }
feature client-cert-auth {
description
"The client-cert-auth feature indicatres that the server
supports the ClientCertificate authentication scheme.";
reference
"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 listen-container;
uses call-home-container; uses call-home-container;
uses client-cert-auth-container;
} }
grouping listen-container { grouping listen-container {
description 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 listen;
leaf max-sessions { leaf max-sessions {
type uint16 { type uint16 {
range "0 .. 1024"; 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.";
} }
list endpoint { list endpoint {
key name; key name;
description description
"List of endpoints to listen for 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 listen endpoint."; "An arbitrary name for the RESTCONF listen endpoint.";
} }
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 { uses address-and-port-grouping {
refine port { refine port {
default 6513; default 443;
} }
} }
uses certificates-container; uses certificates-container;
} }
} }
} }
uses keep-alives-container { uses keep-alives-container {
refine keep-alives/interval-secs { refine keep-alives/interval-secs {
default 0; // disabled by default for listen connections default 0; // disabled by default for listen connections
} }
skipping to change at page 31, line 4 skipping to change at page 31, line 46
} }
uses certificates-container; uses certificates-container;
} }
} }
} }
uses keep-alives-container { uses keep-alives-container {
refine keep-alives/interval-secs { refine keep-alives/interval-secs {
default 0; // disabled by default for listen connections default 0; // disabled by default for listen connections
} }
} }
} }
} }
} }
grouping call-home-container { grouping call-home-container {
description 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 call-home;
description description
"Configures call-home behavior"; "Configures call-home behavior";
list application { list application {
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 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 RESTCONF client."; "An arbitrary name for the remote RESTCONF client.";
} }
choice transport { choice transport {
mandatory true; mandatory true;
description description
"Selects between SSH and TLS transports."; "Selects between TLS and any future transports augmented in.";
case tls { case tls {
if-feature 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 { uses endpoints-container {
refine endpoints/endpoint/port { refine endpoints/endpoint/port {
default 9999; default 9999;
} }
skipping to change at page 34, line 4 skipping to change at page 34, line 48
the first endpoint listed."; the first endpoint listed.";
} }
leaf interval-secs { leaf interval-secs {
type uint8; type uint8;
units seconds; units seconds;
default 5; default 5;
description description
"Specifies the time delay between connection attempts "Specifies the time delay between connection attempts
to the same endpoint. Note: this value differs from to the same endpoint. Note: this value differs from
the periodic-connection's timeout-mins value."; the periodic-connection's timeout-mins value.";
} }
leaf count-max { leaf count-max {
type uint8; type uint8;
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 {
if-feature client-cert-auth;
description
"Container for TLS client certificate authentication
configuration.";
container trusted-ca-certs {
description
"A list of Certificate Authority (CA) certificates that
a NETCONF server can use to authenticate NETCONF client
certificates. A client's certificate is authenticated
if there is a chain of trust to a configured trusted CA
certificate. The client certificate MAY be accompanied
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 {
type binary;
ordered-by system;
nacm:default-deny-write;
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";
}
}
container trusted-client-certs {
description
"A list of client certificates that a NETCONF server can
use to authenticate a NETCONF client's certificate. A
client's certificate is authenticated if it is an exact
match to a configured trusted client certificates.";
leaf-list trusted-client-cert {
type binary;
ordered-by system;
nacm:default-deny-write;
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";
}
}
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.";
}
}
}
grouping certificates-container { grouping certificates-container {
description description
""; "This grouping is used by both the listen and
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
"An unordered list of certificates the TLS server can pick "An unordered list of certificates the TLS server can pick
from when sending its Server Certificate message. The value from when sending its Server Certificate message. The value
of the string is the unique identifier for a certificate of the string is the unique identifier for a certificate
skipping to change at page 34, line 44 skipping to change at page 37, line 14
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
"a common grouping"; "This grouping is usd by both the ssh and tls containers
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.";
} }
leaf port { leaf port {
type inet:port-number; type inet:port-number;
description description
"The local port number on this interface the RESTCONF server "The local port number on this interface the RESTCONF server
listens on."; listens on.";
} }
} }
grouping endpoints-container { grouping endpoints-container {
description description
"Grouping for transport-specific configuration for "This grouping is used by both the ssh and tls containers
call-home connections."; 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;
ordered-by user; ordered-by user;
description description
"User-ordered list of endpoints for this RESTCONF client. "User-ordered list of endpoints for this RESTCONF client.
Defining more than one enables high-availability."; Defining more than one enables high-availability.";
skipping to change at page 35, line 50 skipping to change at page 38, line 23
description description
"The IP port for this endpoint. The RESTCONF server will "The IP port for this endpoint. The RESTCONF server will
use the IANA-assigned well-known port if not specified."; use the IANA-assigned well-known port if not specified.";
} }
} }
} }
} }
grouping keep-alives-container { grouping keep-alives-container {
description description
""; "This grouping is use by both listen and call-home configurations.";
container keep-alives { container keep-alives {
description description
"Configures the keep-alive policy, to proactively test the "Configures the keep-alive policy, to proactively test the
aliveness of the RESTCONF client, in order to know when a aliveness of the RESTCONF client.";
new call home connection should be established.";
reference reference
"RFC VVVV: NETCONF Server and RESTCONF Server Configuration "RFC VVVV: NETCONF Server and RESTCONF Server Configuration
Models, Section 4"; Models, Section 4";
leaf interval-secs { leaf interval-secs {
type uint8; type uint8;
units seconds; units seconds;
description description
"Sets a timeout interval in seconds after which if no data "Sets a timeout interval in seconds after which if no data
has been received from the RESTCONF client, a message will has been received from the RESTCONF client, a message will
be sent to request a response from the RESTCONF client. A be sent to request a response from the RESTCONF client. A
skipping to change at page 36, line 34 skipping to change at page 39, line 4
type uint8; type uint8;
default 3; default 3;
description description
"Sets the number of keep-alive messages that may be sent "Sets the number of keep-alive messages that may be sent
without receiving any data from the RESTCONF client before without receiving any data from the RESTCONF client before
assuming the RESTCONF client is no longer alive. If this assuming the RESTCONF client is no longer alive. If this
threshold is reached, the transport-level connection will threshold is reached, the transport-level connection will
be disconnected, which will trigger the reconnection be disconnected, which will trigger the reconnection
strategy). The interval timer is reset after each strategy). The interval timer is reset after each
transmission, thus an unresponsive RESTCONF client will transmission, thus an unresponsive RESTCONF client will
be dropped after ~count-max * interval-secs seconds."; be dropped after approximately (count-max * interval-secs)
seconds.";
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
5. Implementation strategy for keep-alives 5. Implementation strategy for keep-alives
One of the objectives listed above, Keep-alives for persistent One of the objectives listed above, Keep-alives for persistent
skipping to change at page 38, line 12 skipping to change at page 40, line 36
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:
o This container contains certificates that the server is to use as o This container contains certificates that a NETCONF server is to
trust anchors for authenticating TLS-specific client certificates. use as trust anchors for authenticating X.509-based client
Write access to this node should be protected. certificates. Write access to this node is protected using an
nacm:default-deny-write statement.
netconf-server/tls/client-auth/trusted-client-certs: netconf-server/tls/client-auth/trusted-client-certs:
o This container contains certificates that the server is to trust o This container contains certificates that a NETCONF server is to
directly when authenticating TLS-specific client certificates. trust directly when authenticating X.509-based client
Write access to this node should be protected. certificates. Write access to this node is protected using an
nacm:default-deny-write statement.
netconf-server/tls/client-auth/cert-map: restconf-server/tls/client-auth/trusted-ca-certs:
o This container contains a user name that some deployments may o This container contains certificates that a RESTCONF server is to
consider sensitive information. Read access to this node may need use as trust anchors for authenticating X.509-based client
to be guarded. certificates. Write access to this node is protected using an
nacm:default-deny-write statement.
restconf-server/tls/client-auth/trusted-client-certs:
o This container contains certificates that a RESTCONF server is to
trust directly when authenticating X.509-based client
certificates. Write access to this node is protected using an
nacm:default-deny-write statement.
7. IANA Considerations 7. 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.
skipping to change at page 40, line 23 skipping to change at page 43, line 8
Layer Security (TLS) and Datagram Transport Layer Security Layer Security (TLS) and Datagram Transport Layer Security
(DTLS) Heartbeat Extension", RFC 6520, February 2012. (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
SNMP Configuration", RFC 7407, December 2014.
[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] [draft-ietf-netconf-rfc5539bis]
Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the
NETCONF Protocol over Transport Layer Security (TLS)", NETCONF Protocol over Transport Layer Security (TLS)",
draft-ietf-netconf-rfc5539bis-06 (work in progress), 2014. draft-ietf-netconf-rfc5539bis-06 (work in progress), 2014.
[draft-ietf-netmod-snmp-cfg]
Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for
SNMP Configuration", draft-ietf-netmod-snmp-cfg-08 (work
in progress), September 2014.
10.2. Informative References 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. Examples
A.1. NETCONF Configuration using SSH Transport A.1. NETCONF Configuration using SSH Transport
The following example illustrates the <get> response from a NETCONF The following example illustrates the <get> response from a NETCONF
skipping to change at page 46, line 19 skipping to change at page 49, line 19
o Added ability to configure trust-anchors for SSH X.509 client o Added ability to configure trust-anchors for SSH X.509 client
certs certs
o Now imports by revision, per best practice o Now imports by revision, per best practice
o Added support for RESTCONF server o Added support for RESTCONF server
o Added RFC Editor instructions o Added RFC Editor instructions
B.6. 05 to 06
o Removed feature statement on the session-options container (issue
#21).
o Added NACM statements to YANG modules for sensitive nodes (issue
#24).
o Fixed default RESTCONF server port value to be 443 (issue #26).
o Added client-cert-auth subtree to ietf-restconf-server module
(issue #27).
o Updated draft-ietf-netmod-snmp-cfg reference to RFC 7407 (issue
#28).
o Added description statements for groupings (issue #29).
o Added description for braces to tree diagram section (issue #30).
o Renamed feature from "rfc6187" to "ssh-x509-certs" (issue #31).
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. 90 change blocks. 
152 lines changed or deleted 295 lines changed or added

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