draft-ietf-netconf-netconf-client-server-01.txt   draft-ietf-netconf-netconf-client-server-02.txt 
NETCONF Working Group K. Watsen NETCONF Working Group K. Watsen
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Standards Track G. Wu Intended status: Standards Track G. Wu
Expires: May 7, 2017 Cisco Networks Expires: September 14, 2017 Cisco Networks
J. Schoenwaelder J. Schoenwaelder
Jacobs University Bremen Jacobs University Bremen
November 3, 2016 March 13, 2017
NETCONF Client and Server Models NETCONF Client and Server Models
draft-ietf-netconf-netconf-client-server-01 draft-ietf-netconf-netconf-client-server-02
Abstract Abstract
This document defines two YANG modules, one module to configure a This document defines two YANG modules, one module to configure a
NETCONF client and the other module to configure a NETCONF server. NETCONF client and the other module to configure a NETCONF server.
Both modules support both the SSH and TLS transport protocols, and Both modules support both the SSH and TLS transport protocols, and
support both standard NETCONF and NETCONF Call Home connections. support both standard NETCONF and NETCONF Call Home connections.
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. No other RFC summarizes all of the substitutions that are needed. No other RFC
Editor instructions are specified elsewhere in this document. Editor instructions are specified elsewhere in 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-keystore o I-D.ietf-netconf-keystore
o draft-ietf-netconf-ssh-client-server o I-D.ietf-netconf-ssh-client-server
o draft-ietf-netconf-tls-client-server o I-D.ietf-netconf-tls-client-server
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 "XXXX" --> the assigned RFC value for this draft o "XXXX" --> the assigned RFC value for this draft
o "YYYY" --> the assigned RFC value for draft-ietf-netconf-ssh- o "YYYY" --> the assigned RFC value for I-D.ietf-netconf-ssh-client-
client-server server
o "ZZZZ" --> the assigned RFC value for draft-ietf-netconf-tls-
client-server
o "AAAA" --> the assigned RFC value for draft-ietf-netconf-call-home o "ZZZZ" --> the assigned RFC value for I-D.ietf-netconf-tls-client-
server
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 "2016-11-02" --> the publication date of this draft o "2017-03-13" --> 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 A. Change Log o Appendix A. Change Log
o Appendix B. Open Issues o Appendix B. Open Issues
Status of This Memo Status of This Memo
skipping to change at page 2, line 34 skipping to change at page 2, line 32
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 May 7, 2017. This Internet-Draft will expire on September 14, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4
2. The NETCONF Client Model . . . . . . . . . . . . . . . . . . 4 2. The NETCONF Client Model . . . . . . . . . . . . . . . . . . 4
2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 8
2.3. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 8 2.3. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 10
3. The NETCONF Server Model . . . . . . . . . . . . . . . . . . 14 3. The NETCONF Server Model . . . . . . . . . . . . . . . . . . 19
3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 15 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 20
3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 17 3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 23
3.3. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 21 3.3. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 26
4. Design Considerations . . . . . . . . . . . . . . . . . . . . 31 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 37
4.1. Support all NETCONF transports . . . . . . . . . . . . . 31 4.1. Support all NETCONF transports . . . . . . . . . . . . . 37
4.2. Enable each transport to select which keys to use . . . . 32 4.2. Enable each transport to select which keys to use . . . . 37
4.3. Support authenticating NETCONF clients certificates . . . 32 4.3. Support authenticating NETCONF clients certificates . . . 37
4.4. Support mapping authenticated NETCONF client certificates 4.4. Support mapping authenticated NETCONF client certificates
to usernames . . . . . . . . . . . . . . . . . . . . . . 32 to usernames . . . . . . . . . . . . . . . . . . . . . . 38
4.5. Support both listening for connections and call home . . 32 4.5. Support both listening for connections and call home . . 38
4.6. For Call Home connections . . . . . . . . . . . . . . . . 32 4.6. For Call Home connections . . . . . . . . . . . . . . . . 38
4.6.1. Support more than one NETCONF client . . . . . . . . 32 4.6.1. Support more than one NETCONF client . . . . . . . . 38
4.6.2. Support NETCONF clients having more than one endpoint 33 4.6.2. Support NETCONF clients having more than one endpoint 38
4.6.3. Support a reconnection strategy . . . . . . . . . . . 33 4.6.3. Support a reconnection strategy . . . . . . . . . . . 38
4.6.4. Support both persistent and periodic connections . . 33 4.6.4. Support both persistent and periodic connections . . 39
4.6.5. Reconnection strategy for periodic connections . . . 33 4.6.5. Reconnection strategy for periodic connections . . . 39
4.6.6. Keep-alives for persistent connections . . . . . . . 33 4.6.6. Keep-alives for persistent connections . . . . . . . 39
4.6.7. Customizations for periodic connections . . . . . . . 34 4.6.7. Customizations for periodic connections . . . . . . . 39
5. Security Considerations . . . . . . . . . . . . . . . . . . . 34 5. Security Considerations . . . . . . . . . . . . . . . . . . . 39
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
6.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 34 6.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 41
6.2. The YANG Module Names Registry . . . . . . . . . . . . . 34 6.2. The YANG Module Names Registry . . . . . . . . . . . . . 41
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.1. Normative References . . . . . . . . . . . . . . . . . . 35 8.1. Normative References . . . . . . . . . . . . . . . . . . 42
8.2. Informative References . . . . . . . . . . . . . . . . . 36 8.2. Informative References . . . . . . . . . . . . . . . . . 43
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 38 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 44
A.1. server-model-09 to 00 . . . . . . . . . . . . . . . . . . 38 A.1. server-model-09 to 00 . . . . . . . . . . . . . . . . . . 44
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 38 A.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 A.3. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 44
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
This document defines two YANG [RFC6020] modules, one module to This document defines two YANG [RFC7950] modules, one module to
configure a NETCONF client and the other module to configure a configure a NETCONF client and the other module to configure a
NETCONF server. Both modules support both the SSH and TLS transport NETCONF server. Both modules support both the SSH and TLS transport
protocols, and support both standard NETCONF and NETCONF Call Home protocols, and support both standard NETCONF and NETCONF Call Home
connections. connections.
NETCONF is defined by [RFC6241]. SSH is defined by [RFC4252], NETCONF is defined by [RFC6241]. SSH is defined by [RFC4252],
[RFC4253], and [RFC4254]. TLS is defined by [RFC5246]. NETCONF Call [RFC4253], and [RFC4254]. TLS is defined by [RFC5246]. NETCONF Call
Home is defined by [draft-ietf-netconf-call-home]). Home is defined by [RFC8071]).
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 4, line 46 skipping to change at page 4, line 48
shown. shown.
2. The NETCONF Client Model 2. The NETCONF Client Model
The NETCONF client model presented in this section supports both The NETCONF client model presented in this section supports both
clients initiating connections to servers, as well as clients clients initiating connections to servers, as well as clients
listening for connections from servers calling home. listening for connections from servers calling home.
This model supports both the SSH and TLS transport protocols, using This model supports both the SSH and TLS transport protocols, using
the SSH client and TLS client groupings defined in the SSH client and TLS client groupings defined in
[draft-ietf-netconf-ssh-client-server] and [I-D.ietf-netconf-ssh-client-server] and
[draft-ietf-netconf-tls-client-server] respectively. [I-D.ietf-netconf-tls-client-server] respectively.
All private keys and trusted certificates are held in the keystore All private keys and trusted certificates are held in the keystore
model defined in [draft-ietf-netconf-keystore]. model defined in [I-D.ietf-netconf-keystore].
YANG feature statements are used to enable implementations to YANG feature statements are used to enable implementations to
advertise which parts of the model the NETCONF client supports. advertise which parts of the model the NETCONF client supports.
2.1. Tree Diagram 2.1. Tree Diagram
Note: all lines are folded at column 71 with no '\' character. Note: all lines are folded at column 71 with no '\' character.
module: ietf-netconf-client module: ietf-netconf-client
+--rw netconf-client +--rw netconf-client
+--rw initiate {initiate}? +--rw initiate {initiate}?
| +--rw netconf-server* [name] | +--rw netconf-server* [name]
| +--rw name string | +--rw name string
| +--rw (transport) | +--rw (transport)
| +--:(ssh) {ssh-initiate}? | | +--:(ssh) {ssh-initiate}?
| +--rw ssh | | | +--rw ssh
| +--rw address inet:host | | | +--rw endpoints
| +--rw port? inet:port-number | | | | +--rw endpoint* [name]
| +--rw server-auth | | | | +--rw name string
| | +--rw trusted-ssh-host-keys? -> /ks:keystore | | | | +--rw address inet:host
/trusted-ssh-host-keys/name | | | | +--rw port? inet:port-number
| | +--rw trusted-ca-certs? -> /ks:keystore | | | +--rw server-auth
/trusted-certificates/name {ssh-x509-certs}? | | | | +--rw trusted-ssh-host-keys?
| | +--rw trusted-server-certs? -> /ks:keystore | | | | | -> /ks:keystore/trusted-host-keys/name
/trusted-certificates/name | | | | +--rw trusted-ca-certs? leafref
| +--rw client-auth | | | | | {sshcom:ssh-x509-certs}?
| +--rw matches* [name] | | | | +--rw trusted-server-certs? leafref
| +--rw name string | | | | {sshcom:ssh-x509-certs}?
| +--rw match* [name] | | | +--rw client-auth
| | +--rw name string | | | | +--rw username? string
| | +--rw trusted-ssh-host-keys? -> /ks:ke | | | | +--rw (auth-type)?
ystore/trusted-ssh-host-keys/name | | | | +--:(certificate)
| | +--rw trusted-ca-certs? -> /ks:ke | | | | | +--rw certificate? leafref
ystore/trusted-certificates/name | | | | | {sshcom:ssh-x509-certs}?
| | +--rw trusted-server-certs? -> /ks:ke | | | | +--:(public-key)
ystore/trusted-certificates/name | | | | | +--rw public-key?
| +--rw user-auth-credentials? -> /ks:keyst | | | | | -> /ks:keystore/keys/key/name
ore/user-auth-credentials/user-auth-credential/username | | | | +--:(password)
| | | | +--rw password? union
| | | +--rw transport-params
| | | {ssh-client-transport-params-config}?
| | | +--rw host-key
| | | | +--rw host-key-alg* identityref
| | | +--rw key-exchange
| | | | +--rw key-exchange-alg* identityref
| | | +--rw encryption
| | | | +--rw encryption-alg* identityref
| | | +--rw mac
| | | | +--rw mac-alg* identityref
| | | +--rw compression
| | | +--rw compression-alg* identityref
| | +--:(tls) {tls-initiate}?
| | +--rw tls
| | +--rw endpoints
| | | +--rw endpoint* [name]
| | | +--rw name string
| | | +--rw address inet:host
| | | +--rw port? inet:port-number
| | +--rw server-auth
| | | +--rw trusted-ca-certs? leafref
| | | +--rw trusted-server-certs? leafref
| | +--rw client-auth
| | | +--rw (auth-type)?
| | | +--:(certificate)
| | | +--rw certificate? leafref
| | +--rw hello-params
| | {tls-client-hello-params-config}?
| | +--rw tls-versions
| | | +--rw tls-version* identityref
| | +--rw cipher-suites
| | +--rw cipher-suite* identityref
| +--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
+--rw listen {listen}? +--rw listen {listen}?
+--rw max-sessions? uint16 +--rw max-sessions? uint16
+--rw idle-timeout? uint16 +--rw idle-timeout? uint16
+--rw endpoint* [name] +--rw endpoint* [name]
+--rw name string +--rw name string
+--rw (transport) +--rw (transport)
+--:(ssh) {ssh-listen}? +--:(ssh) {ssh-listen}?
+--rw ssh | +--rw ssh
+--rw address? inet:ip-address | +--rw address? inet:ip-address
+--rw port? inet:port-number | +--rw port? inet:port-number
| +--rw server-auth
| | +--rw trusted-ssh-host-keys?
| | | -> /ks:keystore/trusted-host-keys/name
| | +--rw trusted-ca-certs? leafref
| | | {sshcom:ssh-x509-certs}?
| | +--rw trusted-server-certs? leafref
| | {sshcom:ssh-x509-certs}?
| +--rw client-auth
| | +--rw username? string
| | +--rw (auth-type)?
| | +--:(certificate)
| | | +--rw certificate? leafref
| | | {sshcom:ssh-x509-certs}?
| | +--:(public-key)
| | | +--rw public-key?
| | | -> /ks:keystore/keys/key/name
| | +--:(password)
| | +--rw password? union
| +--rw transport-params
| {ssh-client-transport-params-config}?
| +--rw host-key
| | +--rw host-key-alg* identityref
| +--rw key-exchange
| | +--rw key-exchange-alg* identityref
| +--rw encryption
| | +--rw encryption-alg* identityref
| +--rw mac
| | +--rw mac-alg* identityref
| +--rw compression
| +--rw compression-alg* identityref
+--:(tls) {tls-listen}?
+--rw tls
+--rw address? inet:ip-address
+--rw port? inet:port-number
+--rw server-auth +--rw server-auth
| +--rw trusted-ssh-host-keys? -> /ks:keystore | +--rw trusted-ca-certs? leafref
/trusted-ssh-host-keys/name | +--rw trusted-server-certs? leafref
| +--rw trusted-ca-certs? -> /ks:keystore
/trusted-certificates/name {ssh-x509-certs}?
| +--rw trusted-server-certs? -> /ks:keystore
/trusted-certificates/name
+--rw client-auth +--rw client-auth
+--rw matches* [name] | +--rw (auth-type)?
+--rw name string | +--:(certificate)
+--rw match* [name] | +--rw certificate? leafref
| +--rw name string +--rw hello-params
| +--rw trusted-ssh-host-keys? -> /ks:ke {tls-client-hello-params-config}?
ystore/trusted-ssh-host-keys/name +--rw tls-versions
| +--rw trusted-ca-certs? -> /ks:ke | +--rw tls-version* identityref
ystore/trusted-certificates/name +--rw cipher-suites
| +--rw trusted-server-certs? -> /ks:ke +--rw cipher-suite* identityref
ystore/trusted-certificates/name
+--rw user-auth-credentials? -> /ks:keyst
ore/user-auth-credentials/user-auth-credential/username
2.2. Example Usage 2.2. Example Usage
The following example illustrates configuring a NETCONF client to The following example illustrates configuring a NETCONF client to
initiate connections, using both the SSH and TLS transport protocols, initiate connections, using both the SSH and TLS transport protocols,
as well as listening for call-home connections, again using both the as well as listening for call-home connections, again using both the
SSH and TLS transport protocols. SSH and TLS transport protocols.
This example is consistent with the examples presented in Section 2.2 This example is consistent with the examples presented in Section 2.2
of [draft-ietf-netconf-keystore]. of [I-D.ietf-netconf-keystore].
<netconf-client
xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-client">
<!-- NETCONF servers to initiate NETCONF connections to -->
<initiate>
<netconf-server>
<name>corp-fw1</name>
<ssh>
<address>corp-fw1.example.com</address>
<server-auth>
<trusted-server-certs>
deployment-specific-ca-certs
</trusted-server-certs>
</server-auth>
<client-auth>
<matches>
<match>
<trusted-ca-certs>
deployment-specific-ca-certs
</trusted-ca-certs>
</match>
<user-auth-credentials>Bob</user-auth-credentials>
</matches>
</client-auth>
</ssh>
</netconf-server>
</initiate>
<!-- endpoints to listen for NETCONF Call Home connections on --> <netconf-client
<listen> xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-client">
<endpoint>
<name>Intranet-facing listener</name>
<ssh>
<address>11.22.33.44</address>
<server-auth>
<trusted-ca-certs>
deployment-specific-ca-certs
</trusted-ca-certs>
<trusted-server-certs>
explicitly-trusted-server-certs
</trusted-server-certs>
<trusted-ssh-host-keys>
explicitly-trusted-ssh-host-keys
</trusted-ssh-host-keys>
</server-auth>
<client-auth>
<matches>
<match>
<trusted-ca-certs>
deployment-specific-ca-certs
</trusted-ca-certs>
</match>
<user-auth-credentials>admin</user-auth-credentials>
</matches>
<matches>
<match>
<trusted-ca-certs>
explicitly-trusted-server-certs
</trusted-ca-certs>
</match>
<user-auth-credentials>admin</user-auth-credentials>
</matches>
<matches>
<match>
<trusted-ca-certs>
explicitly-trusted-ssh-host-keys
</trusted-ca-certs> <!-- NETCONF servers to initiate connections to -->
</match> <initiate>
<user-auth-credentials>admin</user-auth-credentials> <netconf-server>
</matches> <name>corp-fw1</name>
</client-auth> <ssh>
</ssh> <endpoints>
</endpoint> <endpoint>
</listen> <name>corp-fw1.example.com</name>
</netconf-client> <address>corp-fw1.example.com</address>
</endpoint>
<endpoint>
<name>corp-fw2.example.com</name>
<address>corp-fw2.example.com</address>
</endpoint>
</endpoints>
<server-auth>
<trusted-server-certs>deployment-specific-ca-certs</trusted-server-certs>
</server-auth>
<client-auth>
<username>foobar</username>
<public-key>ex-rsa-key</public-key>
</client-auth>
</ssh>
</netconf-server>
</initiate>
<!-- endpoints to listen for NETCONF Call Home connections on -->
<listen>
<endpoint>
<name>Intranet-facing listener</name>
<ssh>
<address>11.22.33.44</address>
<server-auth>
<trusted-ca-certs>deployment-specific-ca-certs</trusted-ca-certs>
<trusted-server-certs>explicitly-trusted-server-certs</trusted-server-certs>
<trusted-ssh-host-keys>explicitly-trusted-ssh-host-keys</trusted-ssh-host-keys>
</server-auth>
<client-auth>
<username>foobar</username>
<public-key>ex-rsa-key</public-key>
</client-auth>
</ssh>
</endpoint>
</listen>
</netconf-client>
2.3. YANG Model 2.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-client@2016-11-02.yang" <CODE BEGINS> file "ietf-netconf-client@2017-03-13.yang"
module ietf-netconf-client { module ietf-netconf-client {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-client"; namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-client";
prefix "ncc"; prefix "ncc";
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
reference reference
"RFC 6991: Common YANG Data Types"; "RFC 6991: Common YANG Data Types";
} }
import ietf-x509-cert-to-name { import ietf-ssh-client {
prefix x509c2n; prefix ss;
reference revision-date 2017-03-13; // stable grouping definitions
"RFC 7407: A YANG Data Model for SNMP Configuration"; reference
} "RFC YYYY: SSH Client and Server Models";
}
import ietf-ssh-client { import ietf-tls-client {
prefix ss; prefix ts;
revision-date 2016-11-02; // stable grouping definitions revision-date 2017-03-13; // stable grouping definitions
reference reference
"RFC YYYY: SSH Client and Server Models"; "RFC ZZZZ: TLS Client and Server Models";
} }
// import ietf-tls-client { organization
// prefix ts; "IETF NETCONF (Network Configuration) Working Group";
// revision-date 2016-11-02; // stable grouping definitions
// reference
// "RFC ZZZZ: TLS Client and Server Models";
// }
organization
"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 Author: Kent Watsen
<mailto:mehmet.ersue@nsn.com> <mailto:kwatsen@juniper.net>
WG Chair: Mahesh Jethanandani Author: Gary Wu
<mailto:mjethanandani@gmail.com> <mailto:garywu@cisco.com>";
Author: Kent Watsen description
<mailto:kwatsen@juniper.net> "This module contains a collection of YANG definitions for
configuring NETCONF clients.
Author: Gary Wu Copyright (c) 2014 IETF Trust and the persons identified as
<mailto:garywu@cisco.com>"; authors of the code. All rights reserved.
description Redistribution and use in source and binary forms, with or
"This module contains a collection of YANG definitions for without modification, is permitted pursuant to, and subject
configuring NETCONF servers. 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).
Copyright (c) 2014 IETF Trust and the persons identified as This version of this YANG module is part of RFC XXXX; see
authors of the code. All rights reserved. the RFC itself for full legal notices.";
Redistribution and use in source and binary forms, with or revision "2017-03-13" {
without modification, is permitted pursuant to, and subject description
to the license terms contained in, the Simplified BSD "Initial version";
License set forth in Section 4.c of the IETF Trust's reference
Legal Provisions Relating to IETF Documents "RFC XXXX: NETCONF Client and Server Models";
(http://trustee.ietf.org/license-info). }
This version of this YANG module is part of RFC XXXX; see // Features
the RFC itself for full legal notices.";
revision "2016-11-02" { feature initiate {
description description
"Initial version"; "The 'initiate' feature indicates that the NETCONF client
reference supports initiating NETCONF connections to NETCONF servers
"RFC XXXX: NETCONF Client and Server Models"; using at least one transport (e.g., SSH, TLS, etc.).";
} }
// Features feature ssh-initiate {
description
"The 'ssh-initiate' feature indicates that the NETCONF client
supports initiating SSH connections to NETCONF servers.";
reference
"RFC 6242: Using the NETCONF Protocol over Secure Shell (SSH)";
}
feature initiate { feature tls-initiate {
description description
"The 'initiate' feature indicates that the NETCONF client "The 'tls-initiate' feature indicates that the NETCONF client
supports initiating NETCONF connections to NETCONF servers supports initiating TLS connections to NETCONF servers.";
using at least one transport (e.g., SSH, TLS, etc.)."; reference
} "RFC 7589: Using the NETCONF Protocol over Transport
Layer Security (TLS) with Mutual X.509
Authentication";
feature ssh-initiate { }
description
"The 'ssh-initiate' feature indicates that the NETCONF client
supports initiating SSH connections to NETCONF servers.";
reference
"RFC 6242: Using the NETCONF Protocol over Secure Shell (SSH)";
}
feature tls-initiate { feature listen {
description description
"The 'tls-initiate' feature indicates that the NETCONF client "The 'listen' feature indicates that the NETCONF client
supports initiating TLS connections to NETCONF servers."; supports opening a port to accept NETCONF server call
reference home connections using at least one transport (e.g.,
"RFC 7589: Using the NETCONF Protocol over Transport SSH, TLS, etc.).";
Layer Security (TLS) with Mutual X.509 }
Authentication";
}
feature listen { feature ssh-listen {
description description
"The 'listen' feature indicates that the NETCONF client "The 'ssh-listen' feature indicates that the NETCONF client
supports opening a port to accept NETCONF server call supports opening a port to listen for incoming NETCONF
home connections using at least one transport (e.g., server call-home SSH connections.";
SSH, TLS, etc.)."; reference
} "RFC 8071: NETCONF Call Home and RESTCONF Call Home";
}
feature ssh-listen { feature tls-listen {
description description
"The 'ssh-listen' feature indicates that the NETCONF client "The 'tls-listen' feature indicates that the NETCONF client
supports opening a port to listen for incoming NETCONF supports opening a port to listen for incoming NETCONF
server call-home SSH connections."; server call-home TLS connections.";
reference reference
"RFC AAAA: NETCONF Call Home and RESTCONF Call Home"; "RFC 8071: NETCONF Call Home and RESTCONF Call Home";
} }
feature tls-listen { container netconf-client {
description description
"The 'tls-listen' feature indicates that the NETCONF client "Top-level container for NETCONF client configuration.";
supports opening a port to listen for incoming NETCONF
server call-home TLS connections.";
reference
"RFC AAAA: NETCONF Call Home and RESTCONF Call Home";
}
container netconf-client {
description
"Top-level container for NETCONF client configuration.";
container initiate { container initiate {
if-feature initiate; if-feature initiate;
description description
"Configures client intiating underlying TCP connections."; "Configures client initiating underlying TCP connections.";
list netconf-server { list netconf-server {
key name; key name;
description description
"List of NETCONF servers the NETCONF client is to initiate "List of NETCONF servers the NETCONF client is to initiate
connections to."; connections to.";
leaf name { leaf name {
type string; type string;
description description
"An arbitrary name for the NETCONF server."; "An arbitrary name for the NETCONF server.";
} }
choice transport { choice transport {
mandatory true; mandatory true;
description description
"Selects between available transports."; "Selects between available transports.";
case ssh {
if-feature ssh-initiate;
container ssh {
description
"Specifies SSH-specific transport configuration.";
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
client will process the IP addresses as if they
had been explicitly configured in place of the
hostname.";
}
leaf port {
type inet:port-number;
default 830;
description
"The IP port for this endpoint. The NETCONF client
will use the IANA-assigned well-known port if no
value is specified.";
}
uses ss:initiating-ssh-client-grouping;
}
} case ssh {
/* if-feature ssh-initiate;
case tls { container ssh {
if-feature tls-initiate; description
container tls { "Specifies SSH-specific transport configuration.";
description uses endpoints-container {
"Specifies TLS-specific transport configuration."; refine endpoints/endpoint/port {
uses endpoints-container { default 830;
refine endpoints/endpoint/port { }
default 6513; }
} uses ss:ssh-client-grouping;
} }
uses ts:listening-tls-client-grouping { } // end ssh
augment "client-auth" {
description
"Augments in the cert-to-name structure.";
uses cert-maps-grouping;
}
}
}
}
*/
}
}
} // end initiate
container listen { case tls {
if-feature listen; if-feature tls-initiate;
description container tls {
"Configures client accepting call-home TCP connections."; description
leaf max-sessions { "Specifies TLS-specific transport configuration.";
type uint16; uses endpoints-container {
default 0; refine endpoints/endpoint/port {
description default 6513;
"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."; uses ts:tls-client-grouping;
} }
leaf idle-timeout { } // end tls
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 ss:listening-ssh-client-grouping {
refine port {
default 4334;
}
}
}
}
/*
case tls {
if-feature tls-listen;
container tls {
description
"TLS-specific listening configuration for inbound
connections.";
uses ts:listening-tls-client-grouping {
refine port {
default 4335;
}
augment "client-auth" {
description
"Augments in the cert-to-name structure.";
uses cert-maps-grouping;
}
}
}
}
*/
}
}
} // end listen
}
grouping cert-maps-grouping { } // end transport
description
"A grouping that defines a container around the
cert-to-name structure defined in RFC 7407.";
container cert-maps {
uses x509c2n:cert-to-name;
description
"The cert-maps container is used by a TLS-based 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";
}
}
} 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
server. If the connection goes down, immediately
start trying to reconnect to it, using the
reconnection strategy.
<CODE ENDS> This connection type minimizes any NETCONF server
to NETCONF client 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 client 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 server. An
unresponsive SSH/TLS server will be dropped after
approximately max-attempts * max-wait seconds.";
reference
"RFC 8071: 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
server, a SSH/TLS-level message will be sent
to test the aliveness of the SSH/TLS server.";
}
leaf max-attempts {
type uint8;
default 3;
description
"Sets the maximum number of sequential keep-alive
messages that can fail to obtain a response from
the SSH/TLS server before assuming the SSH/TLS
server is no longer alive.";
}
}
}
}
case periodic-connection {
container periodic {
presence true;
description
"Periodically connect to the NETCONF server, so that
the NETCONF server may deliver messages pending for
the NETCONF client. The NETCONF server must close
the connection when it is ready to release it. Once
the connection has been closed, the NETCONF client
will restart its timer until the 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
"Sets the maximum amount of unconnected time the
NETCONF client will wait before re-establishing
a connection to the NETCONF server. The NETCONF
client may initiate a connection before this
time if desired (e.g., to set configuration).";
}
}
}
}
}
container reconnect-strategy {
description
"The reconnection strategy directs how a NETCONF client
reconnects to a NETCONF server, after discovering its
connection to the server has dropped, even if due to a
reboot. The NETCONF client 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
clients SHOULD be able to remember the last
endpoint connected to across reboots.";
}
}
default first-listed;
description
"Specifies which of the NETCONF server's endpoints the
NETCONF client should start with when trying to connect
to the NETCONF server.";
}
leaf max-attempts {
type uint8 {
range "1..max";
}
default 3;
description
"Specifies the number times the NETCONF client tries to
connect to a specific endpoint before moving on to the
next endpoint in the list (round robin).";
}
}
} // end netconf-server
} // end initiate
container listen {
if-feature listen;
description
"Configures client accepting call-home TCP connections.";
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.";
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.";
leaf address {
type inet:ip-address;
description
"The IP address to listen for call-home connections.";
}
leaf port {
type inet:port-number;
default 4334;
description
"The port number to listen for call-home connections.";
}
uses ss:ssh-client-grouping;
}
}
case tls {
if-feature tls-listen;
container tls {
description
"TLS-specific listening configuration for inbound
connections.";
leaf address {
type inet:ip-address;
description
"The IP address to listen for call-home connections.";
}
leaf port {
type inet:port-number;
default 4335;
description
"The port number to listen for call-home connections.";
}
uses ts:tls-client-grouping;
}
}
} // end transport
} // end endpoint
} // end listen
} // end netconf-client
grouping endpoints-container {
description
"This grouping is used to configure a set of NETCONF servers
a NETCONF client may initiate connections to.";
container endpoints {
description
"Container for the list of endpoints.";
list endpoint {
key name;
unique "address port";
min-elements 1;
ordered-by user;
description
"A non-empty user-ordered list of endpoints for this NETCONF
client to try to connect to. 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 client
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 client will
use the IANA-assigned well-known port (set via a refine
statement when uses) if no value is specified.";
}
}
}
}
}
<CODE ENDS>
3. The NETCONF Server Model 3. The NETCONF Server Model
The NETCONF server model presented in this section supports servers The NETCONF server model presented in this section supports servers
both listening for connections as well as initiating call-home both listening for connections as well as initiating call-home
connections. connections.
This model also supports both the SSH and TLS transport protocols, This model supports both the SSH and TLS transport protocols, using
using the SSH server and TLS server groupings defined in the SSH server and TLS server groupings defined in
[draft-ietf-netconf-ssh-client-server] and [I-D.ietf-netconf-ssh-client-server] and
[draft-ietf-netconf-tls-client-server] respectively. [I-D.ietf-netconf-tls-client-server] respectively.
All private keys and trusted certificates are held in the keystore All private keys and trusted certificates are held in the keystore
model defined in [draft-ietf-netconf-keystore]. model defined in [I-D.ietf-netconf-keystore].
YANG feature statements are used to enable implementations to YANG feature statements are used to enable implementations to
advertise which parts of the model the NETCONF server supports. advertise which parts of the model the NETCONF server supports.
3.1. Tree Diagram 3.1. Tree Diagram
Note: all lines are folded at column 71 with no '\' character. Note: all lines are folded at column 71 with no '\' character.
module: ietf-netconf-server module: ietf-netconf-server
+--rw netconf-server +--rw netconf-server
+--rw session-options +--rw session-options
| +--rw hello-timeout? uint16 | +--rw hello-timeout? uint16
+--rw listen {listen}? +--rw listen {listen}?
| +--rw max-sessions? uint16 | +--rw max-sessions? uint16
| +--rw idle-timeout? uint16 | +--rw idle-timeout? uint16
| +--rw endpoint* [name] | +--rw endpoint* [name]
| +--rw name string | +--rw name string
| +--rw (transport) | +--rw (transport)
| +--:(ssh) {ssh-listen}? | +--:(ssh) {ssh-listen}?
| | +--rw ssh | | +--rw ssh
| | +--rw address? inet:ip-address | | +--rw address? inet:ip-address
| | +--rw port? inet:port-number | | +--rw port? inet:port-number
| | +--rw host-keys | | +--rw host-keys
| | | +--rw host-key* [name] | | | +--rw host-key* [name]
| | | +--rw name string | | | +--rw name string
| | | +--rw (host-key-type) | | | +--rw (host-key-type)
| | | +--:(public-key) | | | +--:(public-key)
| | | | +--rw public-key? -> /ks:keystore/ | | | | +--rw public-key?
private-keys/private-key/name | | | | -> /ks:keystore/keys/key/name
| | | +--:(certificate) | | | +--:(certificate)
| | | +--rw certificate? -> /ks:keystore/ | | | +--rw certificate? leafref
private-keys/private-key/certificate-chains/certificate-chain/name {ssh | | | {sshcom:ssh-x509-certs}?
-x509-certs}? | | +--rw client-cert-auth {sshcom:ssh-x509-certs}?
| | +--rw client-cert-auth {ssh-x509-certs}? | | | +--rw trusted-ca-certs? leafref
| | +--rw trusted-ca-certs? -> /ks:keystore/ | | | +--rw trusted-client-certs? leafref
trusted-certificates/name | | +--rw transport-params
| | +--rw trusted-client-certs? -> /ks:keystore/ | | {ssh-server-transport-params-config}?
trusted-certificates/name | | +--rw host-key
| +--:(tls) {tls-listen}? | | | +--rw host-key-alg* identityref
| +--rw tls | | +--rw key-exchange
| +--rw address? inet:ip-address | | | +--rw key-exchange-alg* identityref
| +--rw port? inet:port-number | | +--rw encryption
| +--rw certificates | | | +--rw encryption-alg* identityref
| | +--rw certificate* [name] | | +--rw mac
| | +--rw name -> /ks:keystore/private-keys/ | | | +--rw mac-alg* identityref
private-key/certificate-chains/certificate-chain/name | | +--rw compression
| +--rw client-auth | | +--rw compression-alg* identityref
| +--rw trusted-ca-certs? -> /ks:keystore/ | +--:(tls) {tls-listen}?
trusted-certificates/name | +--rw tls
| +--rw trusted-client-certs? -> /ks:keystore/ | +--rw address? inet:ip-address
trusted-certificates/name | +--rw port? inet:port-number
| +--rw cert-maps | +--rw certificates
| +--rw cert-to-name* [id] | | +--rw certificate* [name]
| +--rw id uint32 | | +--rw name leafref
| +--rw fingerprint x509c2n:tls-fingerp | +--rw client-auth
rint | | +--rw trusted-ca-certs? leafref
| +--rw map-type identityref | | +--rw trusted-client-certs? leafref
| +--rw name string | | +--rw cert-maps
+--rw call-home {call-home}? | | +--rw cert-to-name* [id]
+--rw netconf-client* [name] | | +--rw id uint32
+--rw name string | | +--rw fingerprint x509c2n:tls-fingerprint
+--rw (transport) | | +--rw map-type identityref
| +--:(ssh) {ssh-call-home}? | | +--rw name string
| | +--rw ssh | +--rw hello-params
| | +--rw endpoints | {tls-server-hello-params-config}?
| | | +--rw endpoint* [name] | +--rw tls-versions
| | | +--rw name string | | +--rw tls-version* identityref
| | | +--rw address inet:host | +--rw cipher-suites
| | | +--rw port? inet:port-number | +--rw cipher-suite* identityref
| | +--rw host-keys +--rw call-home {call-home}?
| | | +--rw host-key* [name] +--rw netconf-client* [name]
| | | +--rw name string +--rw name string
| | | +--rw (host-key-type) +--rw (transport)
| | | +--:(public-key) | +--:(ssh) {ssh-call-home}?
| | | | +--rw public-key? -> /ks:keystore/ | | +--rw ssh
private-keys/private-key/name | | +--rw endpoints
| | | +--:(certificate) | | | +--rw endpoint* [name]
| | | +--rw certificate? -> /ks:keystore/ | | | +--rw name string
private-keys/private-key/certificate-chains/certificate-chain/name {ssh | | | +--rw address inet:host
-x509-certs}? | | | +--rw port? inet:port-number
| | +--rw client-cert-auth {ssh-x509-certs}? | | +--rw host-keys
| | +--rw trusted-ca-certs? -> /ks:keystore/ | | | +--rw host-key* [name]
trusted-certificates/name | | | +--rw name string
| | +--rw trusted-client-certs? -> /ks:keystore/ | | | +--rw (host-key-type)
trusted-certificates/name | | | +--:(public-key)
| +--:(tls) {tls-call-home}? | | | | +--rw public-key?
| +--rw tls | | | | -> /ks:keystore/keys/key/name
| +--rw endpoints | | | +--:(certificate)
| | +--rw endpoint* [name] | | | +--rw certificate? leafref
| | +--rw name string | | | {sshcom:ssh-x509-certs}?
| | +--rw address inet:host | | +--rw client-cert-auth {sshcom:ssh-x509-certs}?
| | +--rw port? inet:port-number | | | +--rw trusted-ca-certs? leafref
| +--rw certificates | | | +--rw trusted-client-certs? leafref
| | +--rw certificate* [name] | | +--rw transport-params
| | +--rw name -> /ks:keystore/private-keys/ | | {ssh-server-transport-params-config}?
private-key/certificate-chains/certificate-chain/name | | +--rw host-key
| +--rw client-auth | | | +--rw host-key-alg* identityref
| +--rw trusted-ca-certs? -> /ks:keystore/ | | +--rw key-exchange
trusted-certificates/name | | | +--rw key-exchange-alg* identityref
| +--rw trusted-client-certs? -> /ks:keystore/ | | +--rw encryption
| | | +--rw encryption-alg* identityref
trusted-certificates/name | | +--rw mac
| +--rw cert-maps | | | +--rw mac-alg* identityref
| +--rw cert-to-name* [id] | | +--rw compression
| +--rw id uint32 | | +--rw compression-alg* identityref
| +--rw fingerprint x509c2n:tls-fingerp | +--:(tls) {tls-call-home}?
rint | +--rw tls
| +--rw map-type identityref | +--rw endpoints
| +--rw name string | | +--rw endpoint* [name]
+--rw connection-type | | +--rw name string
| +--rw (connection-type)? | | +--rw address inet:host
| +--:(persistent-connection) | | +--rw port? inet:port-number
| | +--rw persistent! | +--rw certificates
| | +--rw idle-timeout? uint32 | | +--rw certificate* [name]
| | +--rw keep-alives | | +--rw name leafref
| | +--rw max-wait? uint16 | +--rw client-auth
| | +--rw max-attempts? uint8 | | +--rw trusted-ca-certs? leafref
| +--:(periodic-connection) | | +--rw trusted-client-certs? leafref
| +--rw periodic! | | +--rw cert-maps
| +--rw idle-timeout? uint16 | | +--rw cert-to-name* [id]
| +--rw reconnect_timeout? uint16 | | +--rw id uint32
+--rw reconnect-strategy | | +--rw fingerprint x509c2n:tls-fingerprint
+--rw start-with? enumeration | | +--rw map-type identityref
+--rw max-attempts? uint8 | | +--rw name string
| +--rw hello-params
| {tls-server-hello-params-config}?
| +--rw tls-versions
| | +--rw tls-version* identityref
| +--rw cipher-suites
| +--rw cipher-suite* identityref
+--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
3.2. Example Usage 3.2. Example Usage
The following example illustrates configuring a NETCONF server to The following example illustrates configuring a NETCONF server to
listen for NETCONF client connections using both the SSH and TLS listen for NETCONF client connections using both the SSH and TLS
transport protocols, as well as configuring call-home to two NETCONF transport protocols, as well as configuring call-home to two NETCONF
clients, one using SSH and the other using TLS. clients, one using SSH and the other using TLS.
This example is consistent with the examples presented in Section 2.2 This example is consistent with the examples presented in Section 2.2
of [draft-ietf-netconf-keystore]. of [I-D.ietf-netconf-keystore].
<netconf-server
xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-server">
<listen>
<!-- listening for SSH connections -->
<endpoint>
<name>netconf/ssh</name>
<ssh>
<address>11.22.33.44</address>
<host-keys>
<host-key>
<public-key>my-rsa-key</public-key>
</host-key>
<host-key>
<certificate>TPM key</certificate>
</host-key>
</host-keys>
<client-cert-auth>
<trusted-ca-certs>
deployment-specific-ca-certs
</trusted-ca-certs>
<trusted-client-certs>
explicitly-trusted-client-certs
</trusted-client-certs>
</client-cert-auth>
</ssh>
</endpoint>
<!-- listening for TLS connections -->
<endpoint>
<name>netconf/tls</name>
<tls>
<address>11.22.33.44</address>
<certificates>
<certificate>ex-key-sect571r1-cert</certificate>
</certificates>
<client-auth>
<trusted-ca-certs>
deployment-specific-ca-certs
</trusted-ca-certs>
<trusted-client-certs>
explicitly-trusted-client-certs
</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>
</endpoint>
</listen> <netconf-server
<call-home> xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-server"
<!-- calling home to an SSH-based NETCONF client --> xmlns:x509c2n="urn:ietf:params:xml:ns:yang:ietf-x509-cert-to-name">
<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>
<certificate>TPM key</certificate>
</host-key>
</host-keys>
<client-cert-auth>
<trusted-ca-certs>
deployment-specific-ca-certs
</trusted-ca-certs>
<trusted-client-certs>
explicitly-trusted-client-certs
</trusted-client-certs>
</client-cert-auth>
</ssh>
<connection-type>
<periodic>
<idle-timeout>300</idle-timeout>
<reconnect-timeout>60</reconnect-timeout>
</periodic>
</connection-type>
<reconnect-strategy>
<start-with>last-connected</start-with>
<max-attempts>3</max-attempts>
</reconnect-strategy>
</netconf-client>
<!-- calling home to a TLS-based NETCONF client --> <!-- listening for SSH and TLS connections -->
<netconf-client> <listen>
<name>event-correlator</name> <endpoint> <!-- listening for SSH connections -->
<tls> <name>netconf/ssh</name>
<endpoints> <ssh>
<endpoint> <address>11.22.33.44</address>
<name>east-data-center</name> <host-keys>
<address>22.33.44.55</address> <host-key>
<name>public-key</name>
<public-key>ex-rsa-key</public-key>
</host-key>
<host-key>
<name>certificate</name>
<certificate>builtin-idevid-cert</certificate>
</host-key>
</host-keys>
<client-cert-auth>
<trusted-ca-certs>deployment-specific-ca-certs</trusted-ca-certs>
<trusted-client-certs>explicitly-trusted-client-certs</trusted-client-certs>
</client-cert-auth>
</ssh>
</endpoint>
<endpoint> <!-- listening for TLS sessions -->
<name>netconf/tls</name>
<tls>
<address>11.22.33.44</address>
<certificates>
<certificate>
<name>tls-ec-cert</name>
</certificate>
</certificates>
<client-auth>
<trusted-ca-certs>deployment-specific-ca-certs</trusted-ca-certs>
<trusted-client-certs>explicitly-trusted-client-certs</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>
</endpoint>
</listen>
</endpoint> <!-- calling home to an SSH and TLS based NETCONF clients -->
<endpoint> <call-home>
<name>west-data-center</name> <netconf-client> <!-- SSH-based client -->
<address>33.44.55.66</address> <name>config-mgr</name>
</endpoint> <ssh>
</endpoints> <endpoints>
<certificates> <endpoint>
<certificate>ex-key-sect571r1-cert</certificate> <name>east-data-center</name>
</certificates> <address>11.22.33.44</address>
<client-auth> </endpoint>
<trusted-ca-certs> <endpoint>
deployment-specific-ca-certs <name>west-data-center</name>
</trusted-ca-certs> <address>55.66.77.88</address>
<trusted-client-certs> </endpoint>
explicitly-trusted-client-certs </endpoints>
</trusted-client-certs> <host-keys>
<cert-maps> <host-key>
<cert-to-name> <name>certificate</name>
<id>1</id> <certificate>builtin-idevid-cert</certificate>
<fingerprint>11:0A:05:11:00</fingerprint> </host-key>
<map-type>x509c2n:san-any</map-type> </host-keys>
</cert-to-name> <client-cert-auth>
<cert-to-name> <trusted-ca-certs>deployment-specific-ca-certs</trusted-ca-certs>
<id>2</id> <trusted-client-certs>explicitly-trusted-client-certs</trusted-client-certs>
<fingerprint>B3:4F:A1:8C:54</fingerprint> </client-cert-auth>
<map-type>x509c2n:specified</map-type> </ssh>
<name>scooby-doo</name> <connection-type>
</cert-to-name> <periodic>
</cert-maps> <idle-timeout>300</idle-timeout>
</client-auth> <reconnect-timeout>60</reconnect-timeout>
</tls>
<connection-type>
<persistent>
<idle-timeout>300</idle-timeout>
<keep-alives>
<max-wait>30</max-wait>
<max-attempts>3</max-attempts>
</keep-alives>
</persistent>
</connection-type>
<reconnect-strategy>
<start-with>first-listed</start-with>
<max-attempts>3</max-attempts>
</reconnect-strategy>
</netconf-client>
</call-home> </periodic>
</netconf-server> </connection-type>
<reconnect-strategy>
<start-with>last-connected</start-with>
<max-attempts>3</max-attempts>
</reconnect-strategy>
</netconf-client>
<netconf-client> <!-- TLS-based client -->
<name>event-correlator</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>
<name>tls-ec-cert</name>
</certificate>
</certificates>
<client-auth>
<trusted-ca-certs>deployment-specific-ca-certs</trusted-ca-certs>
<trusted-client-certs>explicitly-trusted-client-certs</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>
<connection-type>
<persistent>
<idle-timeout>300</idle-timeout>
<keep-alives>
<max-wait>30</max-wait>
<max-attempts>3</max-attempts>
</keep-alives>
</persistent>
</connection-type>
<reconnect-strategy>
<start-with>first-listed</start-with>
<max-attempts>3</max-attempts>
</reconnect-strategy>
</netconf-client>
</call-home>
</netconf-server>
3.3. YANG Model 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@2016-11-02.yang" <CODE BEGINS> file "ietf-netconf-server@2017-03-13.yang"
module ietf-netconf-server {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-server";
prefix "ncs";
import ietf-inet-types { module ietf-netconf-server {
prefix inet; yang-version 1.1;
reference
"RFC 6991: Common YANG Data Types";
}
import ietf-x509-cert-to-name { namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-server";
prefix x509c2n; prefix "ncs";
reference
"RFC 7407: A YANG Data Model for SNMP Configuration";
}
import ietf-ssh-server { import ietf-inet-types {
prefix ss; prefix inet;
revision-date 2016-11-02; // stable grouping definitions reference
reference "RFC 6991: Common YANG Data Types";
"RFC YYYY: SSH Client and Server Models"; }
}
import ietf-tls-server { import ietf-x509-cert-to-name {
prefix ts; prefix x509c2n;
revision-date 2016-11-02; // stable grouping definitions reference
reference "RFC 7407: A YANG Data Model for SNMP Configuration";
"RFC ZZZZ: TLS Client and Server Models"; }
}
organization import ietf-ssh-server {
"IETF NETCONF (Network Configuration) Working Group"; prefix ss;
revision-date 2017-03-13; // stable grouping definitions
reference
"RFC YYYY: SSH Client and Server Models";
}
contact import ietf-tls-server {
"WG Web: <http://tools.ietf.org/wg/netconf/> prefix ts;
WG List: <mailto:netconf@ietf.org> revision-date 2017-03-13; // stable grouping definitions
reference
"RFC ZZZZ: TLS Client and Server Models";
}
WG Chair: Mehmet Ersue organization
<mailto:mehmet.ersue@nsn.com> "IETF NETCONF (Network Configuration) Working Group";
WG Chair: Mahesh Jethanandani contact
<mailto:mjethanandani@gmail.com> "WG Web: <http://tools.ietf.org/wg/netconf/>
WG List: <mailto:netconf@ietf.org>
Editor: Kent Watsen Author: Kent Watsen
<mailto:kwatsen@juniper.net>"; <mailto:kwatsen@juniper.net>";
description description
"This module contains a collection of YANG definitions for "This module contains a collection of YANG definitions for
configuring NETCONF servers. configuring NETCONF servers.
Copyright (c) 2014 IETF Trust and the persons identified as Copyright (c) 2014 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
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 XXXX; see This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision "2016-11-02" { revision "2017-03-13" {
description description
"Initial version"; "Initial version";
reference reference
"RFC XXXX: NETCONF Client and Server Models"; "RFC XXXX: NETCONF Client and Server Models";
} }
// Features // Features
feature listen { feature listen {
description description
"The 'listen' feature indicates that the NETCONF server "The 'listen' feature indicates that the NETCONF server
supports opening a port to accept NETCONF client connections supports opening a port to accept NETCONF client connections
using at least one transport (e.g., SSH, TLS, etc.)."; using at least one transport (e.g., SSH, TLS, etc.).";
} }
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-listen { feature tls-listen {
description description
"The 'ssh-listen' feature indicates that the NETCONF server "The 'tls-listen' feature indicates that the NETCONF server
supports opening a port to accept NETCONF over SSH supports opening a port to accept NETCONF over TLS
client connections."; client connections.";
reference reference
"RFC 6242: Using the NETCONF Protocol over Secure Shell (SSH)"; "RFC 7589: Using the NETCONF Protocol over Transport
Layer Security (TLS) with Mutual X.509
Authentication";
}
} feature call-home {
description
"The 'call-home' feature indicates that the NETCONF server
supports initiating NETCONF call home connections to NETCONF
clients using at least one transport (e.g., SSH, TLS, etc.).";
reference
"RFC 8071: NETCONF Call Home and RESTCONF Call Home";
}
feature tls-listen { feature ssh-call-home {
description description
"The 'tls-listen' feature indicates that the NETCONF server "The 'ssh-call-home' feature indicates that the NETCONF
supports opening a port to accept NETCONF over TLS server supports initiating a NETCONF over SSH call
client connections."; home connection to NETCONF clients.";
reference reference
"RFC 7589: Using the NETCONF Protocol over Transport "RFC 8071: NETCONF Call Home and RESTCONF Call Home";
Layer Security (TLS) with Mutual X.509 }
Authentication";
}
feature call-home { feature tls-call-home {
description description
"The 'call-home' feature indicates that the NETCONF server "The 'tls-call-home' feature indicates that the NETCONF
supports initiating NETCONF call home connections to NETCONF server supports initiating a NETCONF over TLS call
clients using at least one transport (e.g., SSH, TLS, etc.)."; home connection to NETCONF clients.";
reference reference
"RFC YYYY: NETCONF Call Home and RESTCONF Call Home"; "RFC 8071: NETCONF Call Home and RESTCONF Call Home";
} }
feature ssh-call-home { // top-level container (groupings below)
description container netconf-server {
"The 'ssh-call-home' feature indicates that the NETCONF description
server supports initiating a NETCONF over SSH call "Top-level container for NETCONF server configuration.";
home connection to NETCONF clients.";
reference
"RFC YYYY: NETCONF Call Home and RESTCONF Call Home";
}
feature tls-call-home { container session-options { // SHOULD WE REMOVE THIS ALTOGETHER?
description description
"The 'tls-call-home' feature indicates that the NETCONF "NETCONF session options, independent of transport
server supports initiating a NETCONF over TLS call or connection strategy.";
home connection to NETCONF clients."; leaf hello-timeout {
reference type uint16;
"RFC YYYY: NETCONF Call Home and RESTCONF Call Home"; 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.";
}
} }
// top-level container (groupings below) container listen {
container netconf-server { if-feature listen;
description description
"Top-level container for NETCONF server configuration."; "Configures listen behavior";
leaf max-sessions {
container session-options { // SHOULD WE REMOVE THIS ALTOGETHER? type uint16;
default 0;
description description
"NETCONF session options, independent of transport "Specifies the maximum number of concurrent sessions
or connection strategy."; that can be active at one time. The value 0 indicates
leaf hello-timeout { that no artificial session limit should be used.";
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.";
}
} }
leaf idle-timeout {
container listen { type uint16;
if-feature listen; units "seconds";
default 3600; // one hour
description description
"Configures listen behavior"; "Specifies the maximum number of seconds that a NETCONF
leaf max-sessions { session may remain idle. A NETCONF session will be dropped
type uint16; if it is idle for an interval longer than this number of
default 0; seconds. If set to zero, then the server will never drop
description a session because it is idle. Sessions that have a
"Specifies the maximum number of concurrent sessions notification subscription active are never dropped.";
that can be active at one time. The value 0 indicates }
that no artificial session limit should be used."; list endpoint {
} key name;
leaf idle-timeout { description
type uint16; "List of endpoints to listen for NETCONF connections.";
units "seconds"; leaf name {
default 3600; // one hour type string;
description description
"Specifies the maximum number of seconds that a NETCONF "An arbitrary name for the NETCONF listen endpoint.";
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 {
choice transport { mandatory true;
mandatory true; description
description "Selects between available transports.";
"Selects between available transports."; case ssh {
case ssh { if-feature ssh-listen;
if-feature ssh-listen; container ssh {
container ssh { description
"SSH-specific listening configuration for inbound
connections.";
leaf address {
type inet:ip-address;
description description
"SSH-specific listening configuration for inbound "The IP address of the interface to listen on. The
connections."; SSH server will listen on all interfaces if no value
uses ss:listening-ssh-server-grouping { is specified. Please note that some addresses have
refine port { special meanings (e.g., '0.0.0.0' and '::').";
default 830; }
} leaf port {
} type inet:port-number;
default 830;
description
"The local port number on this interface the SSH server
listens on.";
} }
uses ss:ssh-server-grouping;
} }
case tls { }
if-feature tls-listen; case tls {
container tls { if-feature tls-listen;
container tls {
description
"TLS-specific listening configuration for inbound
connections.";
leaf address {
type inet:ip-address;
description description
"TLS-specific listening configuration for inbound "The IP address of the interface to listen on. The
connections."; TLS server will listen on all interfaces if no value
uses ts:listening-tls-server-grouping { is specified. Please note that some addresses have
refine port { special meanings (e.g., '0.0.0.0' and '::').";
default 6513; }
} leaf port {
augment "client-auth" { type inet:port-number;
description default 6513;
"Augments in the cert-to-name structure."; description
uses cert-maps-grouping; "The local port number on this interface the TLS server
} listens on.";
}
uses ts:tls-server-grouping {
augment "client-auth" {
description
"Augments in the cert-to-name structure.";
uses cert-maps-grouping;
} }
} }
} }
} }
} }
} }
}
container call-home { container call-home {
if-feature call-home; if-feature call-home;
description
"Configures call-home behavior";
list netconf-client {
key name;
description description
"Configures call-home behavior"; "List of NETCONF clients the NETCONF server is to initiate
list netconf-client { call-home connections to.";
key name; leaf name {
type string;
description description
"List of NETCONF clients the NETCONF server is to initiate "An arbitrary name for the remote NETCONF client.";
call-home connections to."; }
leaf name { choice transport {
type string; mandatory true;
description description
"An arbitrary name for the remote NETCONF client."; "Selects between available transports.";
} case ssh {
choice transport { if-feature ssh-call-home;
mandatory true; container ssh {
description description
"Selects between available transports."; "Specifies SSH-specific call-home transport
case ssh { configuration.";
if-feature ssh-call-home; uses endpoints-container {
container ssh { refine endpoints/endpoint/port {
description default 4334;
"Specifies SSH-specific call-home transport
configuration.";
uses endpoints-container {
refine endpoints/endpoint/port {
default 4334;
}
} }
uses ss:non-listening-ssh-server-grouping;
} }
uses ss:ssh-server-grouping;
} }
case tls { }
if-feature tls-call-home; case tls {
container tls { if-feature tls-call-home;
description container tls {
"Specifies TLS-specific call-home transport description
configuration."; "Specifies TLS-specific call-home transport
uses endpoints-container { configuration.";
refine endpoints/endpoint/port { uses endpoints-container {
default 4335; refine endpoints/endpoint/port {
} default 4335;
} }
uses ts:non-listening-tls-server-grouping { }
augment "client-auth" { uses ts:tls-server-grouping {
description augment "client-auth" {
"Augments in the cert-to-name structure."; description
uses cert-maps-grouping; "Augments in the cert-to-name structure.";
} uses cert-maps-grouping;
} }
} }
} }
} }
container connection-type { }
container connection-type {
description
"Indicates the kind of connection to use.";
choice connection-type {
description description
"Indicates the kind of connection to use."; "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.
choice connection-type { This connection type minimizes any NETCONF client
description to NETCONF server data-transfer delay, albeit at
"Selects between available connection types."; the expense of holding resources longer.";
case persistent-connection { leaf idle-timeout {
container persistent { type uint32;
presence true; units "seconds";
default 86400; // one day;
description description
"Maintain a persistent connection to the NETCONF "Specifies the maximum number of seconds that a
client. If the connection goes down, immediately a NETCONF session may remain idle. A NETCONF
start trying to reconnect to it, using the session will be dropped if it is idle for an
reconnection strategy. interval longer than this number of seconds.
If set to zero, then the server will never drop
This connection type minimizes any NETCONF client a session because it is idle. Sessions that
to NETCONF server data-transfer delay, albeit at have a notification subscription active are
the expense of holding resources longer."; never dropped.";
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 maximum 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.";
}
}
} }
} container keep-alives {
case periodic-connection {
container periodic {
presence true;
description description
"Periodically connect to the NETCONF client, so that "Configures the keep-alive policy, to proactively
the NETCONF client may deliver messages pending for test the aliveness of the SSH/TLS client. An
the NETCONF server. The NETCONF client must close unresponsive SSH/TLS client will be dropped after
the connection when it is ready to release it. Once approximately max-attempts * max-wait seconds.";
the connection has been closed, the NETCONF server reference
will restart its timer until the next connection."; "RFC 8071: NETCONF Call Home and RESTCONF Call
leaf idle-timeout { Home, Section 3.1, item S6";
type uint16; leaf max-wait {
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 { type uint16 {
range "1..max"; range "1..max";
} }
units minutes; units seconds;
default 60; default 30;
description description
"Sets the maximum amount of unconnected time the "Sets the amount of time in seconds after which
NETCONF server will wait before re-establishing if no data has been received from the SSH/TLS
a connection to the NETCONF client. The NETCONF client, a SSH/TLS-level message will be sent
server may initiate a connection before this to test the aliveness of the SSH/TLS client.";
time if desired (e.g., to deliver an event }
notification message)."; leaf max-attempts {
type uint8;
default 3;
description
"Sets the maximum 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 reconnect-strategy { container periodic {
description presence true;
"The reconnection strategy directs how a NETCONF server description
reconnects to a NETCONF client, after discovering its "Periodically connect to the NETCONF client, so that
connection to the client has dropped, even if due to a the NETCONF client may deliver messages pending for
reboot. The NETCONF server starts with the specified the NETCONF server. The NETCONF client must close
endpoint and tries to connect to it max-attempts times the connection when it is ready to release it. Once
before trying the next endpoint in the list (round the connection has been closed, the NETCONF server
robin)."; will restart its timer until the next connection.";
leaf start-with { leaf idle-timeout {
type enumeration { type uint16;
enum first-listed { units "seconds";
default 300; // five minutes
description description
"Indicates that reconnections should start with "Specifies the maximum number of seconds that a
the first endpoint listed."; 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.";
} }
enum last-connected { leaf reconnect-timeout {
type uint16 {
range "1..max";
}
units minutes;
default 60;
description description
"Indicates that reconnections should start with "Sets the maximum amount of unconnected time the
the endpoint last connected to. If no previous NETCONF server will wait before re-establishing
connection has ever been established, then the a connection to the NETCONF client. The NETCONF
first endpoint configured is used. NETCONF server may initiate a connection before this
servers SHOULD be able to remember the last time if desired (e.g., to deliver an event
endpoint connected to across reboots."; notification message).";
} }
} }
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"; container reconnect-strategy {
description
"The reconnection strategy directs how a NETCONF server
reconnects to a NETCONF client, after discovering its
connection to the client has dropped, 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 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).";
} }
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 cert-maps-grouping { grouping cert-maps-grouping {
description
"A grouping that defines a container around the
cert-to-name structure defined in RFC 7407.";
container cert-maps {
uses x509c2n:cert-to-name;
description description
"A grouping that defines a container around the "The cert-maps container is used by a TLS-based NETCONF
cert-to-name structure defined in RFC 7407."; server to map the NETCONF client's presented X.509
container cert-maps { certificate to a NETCONF username. If no matching and
uses x509c2n:cert-to-name; valid cert-to-name list entry can be found, then the
description NETCONF server MUST close the connection, and MUST NOT
"The cert-maps container is used by a TLS-based NETCONF accept NETCONF messages over it.";
server to map the NETCONF client's presented X.509 reference
certificate to a NETCONF username. If no matching and "RFC WWWW: NETCONF over TLS, Section 7";
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 endpoints-container { grouping endpoints-container {
description
"This grouping is used to configure a set of NETCONF clients
a NETCONF server may initiate call-home connections to.";
container endpoints {
description description
"This grouping is used by both the ssh and tls containers "Container for the list of endpoints.";
for call-home configurations."; list endpoint {
container endpoints { key name;
unique "address port";
min-elements 1;
ordered-by user;
description description
"Container for the list of endpoints."; "A non-empty user-ordered list of endpoints for this NETCONF
list endpoint { server to try to connect to. Defining more than one enables
key name; high-availability.";
min-elements 1; leaf name {
ordered-by user; type string;
description description
"User-ordered list of endpoints for this NETCONF client. "An arbitrary name for this endpoint.";
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.";
}
} }
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 (set via a refine
statement when uses) if no value is specified.";
}
} }
} }
} }
<CODE ENDS> }
<CODE ENDS>
4. Design Considerations 4. Design Considerations
Editorial: this section is a hold over from before, previously called Editorial: this section is a hold over from before, previously called
"Objectives". It was only written two support the "server" (not the "Objectives". It was only written two support the "server" (not the
"client"). The question is if it's better to add the missing "client"). The question is if it's better to add the missing
"client" parts, or remove this section altogether. "client" parts, or remove this section altogether.
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 client and servers. This scope the configuration of the NETCONF client and servers. This scope
skipping to change at page 32, line 35 skipping to change at page 38, line 17
When a client certificate is used for TLS client authentication, the When a client certificate is used for TLS client authentication, the
NETCONF server must be able to derive a username from the NETCONF server must be able to derive a username from the
authenticated certificate. Thus the modules defined herein should authenticated certificate. Thus the modules defined herein should
enable this mapping to be configured. enable this mapping to be configured.
4.5. Support both listening for connections and call home 4.5. Support both listening for connections and call home
The NETCONF protocols were originally defined as having the server The NETCONF protocols were originally defined as having the server
opening a port to listen for client connections. More recently the opening a port to listen for client connections. More recently the
NETCONF working group defined support for call-home NETCONF working group defined support for call-home ([RFC8071]),
([draft-ietf-netconf-call-home]), enabling the server to initiate the enabling the server to initiate the connection to the client. Thus
connection to the client. Thus the modules defined herein should the modules defined herein should enable configuration for both
enable configuration for both listening for connections and calling listening for connections and calling home. Because implementations
home. Because implementations may not support both listening for may not support both listening for connections and calling home, YANG
connections and calling home, YANG "feature" statements should be "feature" statements should be used so that implementation can
used so that implementation can accurately advertise the connection accurately advertise the connection types it supports.
types it supports.
4.6. For Call Home connections 4.6. For Call Home connections
The following objectives only pertain to call home connections. The following objectives only pertain to call home connections.
4.6.1. Support more than one NETCONF client 4.6.1. Support more than one NETCONF client
A NETCONF server may be managed by more than one NETCONF client. For A NETCONF server may be managed by more than one NETCONF client. For
instance, a deployment may have one client for provisioning and instance, a deployment may have one client for provisioning and
another for fault monitoring. Therefore, when it is desired for a another for fault monitoring. Therefore, when it is desired for a
skipping to change at page 34, line 26 skipping to change at page 40, line 7
5. Security Considerations 5. Security Considerations
A denial of service (DoS) attack MAY occur if the NETCONF server A denial of service (DoS) attack MAY occur if the NETCONF server
limits the maximum number of NETCONF sessions it will accept (i.e. limits the maximum number of NETCONF sessions it will accept (i.e.
the 'max-sessions' field in the ietf-netconf-server module is not the 'max-sessions' field in the ietf-netconf-server module is not
zero) and either the "hello-timeout" or "idle-timeout" fields in zero) and either the "hello-timeout" or "idle-timeout" fields in
ietf-netconf-server module have been set to indicate the NETCONF ietf-netconf-server module have been set to indicate the NETCONF
server should wait forever (i.e. set to zero). server should wait forever (i.e. set to zero).
The YANG module defined in this document uses groupings defined in
[I-D.ietf-netconf-ssh-client-server] and
[I-D.ietf-netconf-tls-client-server]. Please see the Security
Considerations section in those documents for concerns related those
groupings.
The YANG module defined in this document is designed to be accessed
via YANG based management protocols, such as NETCONF [RFC6241] and
RESTCONF [RFC8040]. Both of these protocols have mandatory-to-
implement secure transport layers (e.g., SSH, TLS) with mutual
authentication.
The NETCONF access control model (NACM) [RFC6536] provides the means
to restrict access for particular users to a pre-configured subset of
all available protocol operations and content.
There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., edit-config)
to these data nodes without proper protection can have a negative
effect on network operations. These are the subtrees and data nodes
and their sensitivity/vulnerability:
NONE
Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or
notification) to these data nodes. These are the subtrees and data
nodes and their sensitivity/vulnerability:
NONE
Some of the RPC operations in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus
important to control access to these operations. These are the
operations and their sensitivity/vulnerability:
NONE
6. IANA Considerations 6. IANA Considerations
6.1. The IETF XML Registry 6.1. The IETF XML Registry
This document registers two URIs in the IETF XML registry [RFC2119]. This document registers two URIs in the IETF XML registry [RFC3688].
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-client URI: urn:ietf:params:xml:ns:yang:ietf-netconf-client
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-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.
6.2. The YANG Module Names Registry 6.2. The YANG Module Names Registry
This document registers two YANG modules in the YANG Module Names This document registers two YANG modules in the YANG Module Names
registry [RFC6020]. Following the format in [RFC6020], the the registry [RFC7950]. Following the format in [RFC7950], the the
following registrations are requested: following registrations are requested:
name: ietf-netconf-client name: ietf-netconf-client
namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-client namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-client
prefix: ncc prefix: ncc
reference: RFC XXXX reference: RFC XXXX
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: ncs prefix: ncs
skipping to change at page 35, line 31 skipping to change at page 42, line 9
and Bert Wijnen. and Bert 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.
8. References 8. References
8.1. Normative References 8.1. Normative References
[draft-ietf-netconf-keystore] [I-D.ietf-netconf-keystore]
Watsen, K., "Keystore Model", draft-ieft-netconf- Watsen, K. and G. Wu, "Keystore Model", draft-ietf-
keystore-00 (work in progress), 2016, netconf-keystore-00 (work in progress), October 2016.
<https://datatracker.ietf.org/html/draft-ieft-netconf-
keystore>.
[draft-ietf-netconf-ssh-client-server] [I-D.ietf-netconf-ssh-client-server]
Watsen, K., "SSH Client and Server Models", draft-ieft- Watsen, K. and G. Wu, "SSH Client and Server Models",
netconf-ssh-client-server-00 (work in progress), 2016, draft-ietf-netconf-ssh-client-server-01 (work in
<https://datatracker.ietf.org/html/draft-ieft-netconf-ssh- progress), November 2016.
client-server>.
[draft-ietf-netconf-tls-client-server] [I-D.ietf-netconf-tls-client-server]
Watsen, K., "TLS Client and Server Models", draft-ieft- Watsen, K., "TLS Client and Server Models", draft-ietf-
netconf-tls-client-server-00 (work in progress), 2016, netconf-tls-client-server-01 (work in progress), November
<https://datatracker.ietf.org/html/draft-ieft-netconf-tls- 2016.
client-server>.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<http://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>. <http://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<http://www.rfc-editor.org/info/rfc6242>. <http://www.rfc-editor.org/info/rfc6242>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
skipping to change at page 36, line 33 skipping to change at page 43, line 5
[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, DOI 10.17487/RFC7407, SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407,
December 2014, <http://www.rfc-editor.org/info/rfc7407>. December 2014, <http://www.rfc-editor.org/info/rfc7407>.
[RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the
NETCONF Protocol over Transport Layer Security (TLS) with NETCONF Protocol over Transport Layer Security (TLS) with
Mutual X.509 Authentication", RFC 7589, Mutual X.509 Authentication", RFC 7589,
DOI 10.17487/RFC7589, June 2015, DOI 10.17487/RFC7589, June 2015,
<http://www.rfc-editor.org/info/rfc7589>. <http://www.rfc-editor.org/info/rfc7589>.
8.2. Informative References [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<http://www.rfc-editor.org/info/rfc7950>.
[draft-ietf-netconf-call-home] 8.2. Informative References
Watsen, K., "NETCONF Call Home and RESTCONF Call Home",
draft-ieft-netconf-call-home-17 (work in progress), 2015,
<https://datatracker.ietf.org/html/draft-ieft-netconf-
call-home-17>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<http://www.rfc-editor.org/info/rfc3688>. <http://www.rfc-editor.org/info/rfc3688>.
[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
January 2006, <http://www.rfc-editor.org/info/rfc4252>. January 2006, <http://www.rfc-editor.org/info/rfc4252>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
skipping to change at page 38, line 5 skipping to change at page 43, line 32
[RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) [RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Connection Protocol", RFC 4254, DOI 10.17487/RFC4254, Connection Protocol", RFC 4254, DOI 10.17487/RFC4254,
January 2006, <http://www.rfc-editor.org/info/rfc4254>. January 2006, <http://www.rfc-editor.org/info/rfc4254>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <http://www.rfc-editor.org/info/rfc5246>.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536,
DOI 10.17487/RFC6536, March 2012,
<http://www.rfc-editor.org/info/rfc6536>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<http://www.rfc-editor.org/info/rfc8040>.
[RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home",
RFC 8071, DOI 10.17487/RFC8071, February 2017,
<http://www.rfc-editor.org/info/rfc8071>.
Appendix A. Change Log Appendix A. Change Log
A.1. server-model-09 to 00 A.1. server-model-09 to 00
o This draft was split out from draft-ietf-netconf-server-model-09. o This draft was split out from draft-ietf-netconf-server-model-09.
o Added in previously missing ietf-netconf-client module. o Added in previously missing ietf-netconf-client module.
o Added in new features 'listen' and 'call-home' so future o Added in new features 'listen' and 'call-home' so future
transports can be augmented in. transports can be augmented in.
A.2. 00 to 01
o Renamed "keychain" to "keystore".
A.3. 01 to 02
o Added to ietf-netconf-client ability to connected to a cluster of
endpoints, including a reconnection-strategy.
o Added to ietf-netconf-client the ability to configure connection-
type and also keep-alive strategy.
o Updated both modules to accomodate new groupings in the ssh/tls
drafts.
Appendix B. Open Issues Appendix B. Open Issues
Please see: https://github.com/netconf-wg/netconf-client-server/ Please see: https://github.com/netconf-wg/netconf-client-server/
issues. issues.
Authors' Addresses Authors' Addresses
Kent Watsen Kent Watsen
Juniper Networks Juniper Networks
 End of changes. 147 change blocks. 
1164 lines changed or deleted 1450 lines changed or added

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