draft-ietf-netconf-call-home-00.txt   draft-ietf-netconf-call-home-01.txt 
NETCONF Working Group K. Watsen NETCONF Working Group K. Watsen
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Updates: 4253 (if approved) August 19, 2014 Updates: 4253 (if approved) October 10, 2014
Intended status: Standards Track Intended status: Standards Track
Expires: February 20, 2015 Expires: April 13, 2015
NETCONF Call Home NETCONF Call Home
draft-ietf-netconf-call-home-00 draft-ietf-netconf-call-home-01
Abstract Abstract
This document presents NETCONF Call Home, which enables a NETCONF This document presents NETCONF Call Home, which enables a NETCONF
server to initiate a secure connection to the NETCONF client. server to initiate a secure connection to the NETCONF client.
NETCONF Call Home supports both the SSH and TLS transports, and does NETCONF Call Home supports both the SSH and TLS transports, and does
so in a way that preserves the SSH and TLS roles when compared to so in a way that preserves the SSH and TLS roles when compared to
standard NETCONF over SSH or TLS connections. standard NETCONF over SSH or TLS connections.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 February 20, 2015. This Internet-Draft will expire on April 13, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Terminology . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 1.2. Requirements Terminology . . . . . . . . . . . . . . . . 3
4. Update to RFC 4253 . . . . . . . . . . . . . . . . . . . . . 3 1.3. Applicability Statement . . . . . . . . . . . . . . . . . 3
5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.4. Update to RFC 4253 . . . . . . . . . . . . . . . . . . . 4
6. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. The NETCONF Server . . . . . . . . . . . . . . . . . . . . . 4
7. NETCONF Server Identification and Verification . . . . . . . 5 2.1. Protocol Operation . . . . . . . . . . . . . . . . . . . 4
8. Configuration Data Model . . . . . . . . . . . . . . . . . . 6 2.2. Configuration Data Model . . . . . . . . . . . . . . . . 5
9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 3. The NETCONF Client . . . . . . . . . . . . . . . . . . . . . 5
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 3.1. Protocol Operation . . . . . . . . . . . . . . . . . . . 5
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Server Identification and Verification . . . . . . . . . 5
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
12.1. Normative References . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
12.2. Informative References . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 10
A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Motivation 1. Introduction
This document presents NETCONF Call Home, which enables a NETCONF
server to initiate a secure connection to the NETCONF client.
NETCONF Call Home supports both the SSH and TLS transports, and does
so in a way that preserves the SSH and TLS roles when compared to
standard NETCONF over SSH or TLS connections.
The same technique is used to enabled call home for both the SSH and
TLS transports. The technique is to have the NETCONF server initiate
a TCP connection to the intended NETCONF client. The NETCONF client
then uses the established TCP connection to initiate either the SSH
or TLS protocols. In this way, the NETCONF server is always the SSH
or TLS server, regardless if call home is used or not.
Enabling the NETCONF server to maintain the role of SSH or TLS server
is both necessary and desirable. It is necessary for the SSH
protocol, as SSH channels and subsystems can only be opened on the
SSH server. It is desirable for both the SSH and TLS protocols as it
conveniently leverages infrastructure that may be deployed for host-
key or certificate verification and user authentication.
1.1. Motivation
Call home is generally useful for both the initial deployment and on- Call home is generally useful for both the initial deployment and on-
going management of networking elements. Here are some scenarios going management of networking elements. Here are some scenarios
enabled by call home: enabled by call home:
o The network element may proactively call home after being powered o The network element may proactively call home after being powered
on for the first time to register itself with its management on for the first time in order to register itself with its
system. management system.
o The network element may access the network in a way that o The network element may access the network in a way that
dynamically assigns it an IP address and it doesn't register its dynamically assigns it an IP address and it doesn't register its
assigned IP addressed to a mapping service. assigned IP addressed to a mapping service.
o The network element may be configured in "stealth mode" and thus o The network element may be configured in "stealth mode" and thus
doesn't have any open ports for the management system to connect doesn't have any open ports for the management system to connect
to. to.
o The network element may be deployed behind a firewall that doesn't o The network element may be deployed behind a firewall that doesn't
skipping to change at page 3, line 11 skipping to change at page 3, line 40
o The operator may prefer to have network elements initiate o The operator may prefer to have network elements initiate
management connections believing it is easier to secure one open- management connections believing it is easier to secure one open-
port in the data center than to have an open port on each network port in the data center than to have an open port on each network
element in the network. element in the network.
Having call home for NETCONF is particularly useful as NETCONF is the Having call home for NETCONF is particularly useful as NETCONF is the
recommended protocol for configuration [iesg-statement], which is recommended protocol for configuration [iesg-statement], which is
needed for provisioning workflows. needed for provisioning workflows.
2. Requirements Terminology 1.2. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "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].
3. Applicability Statement 1.3. Applicability Statement
The techniques described in this document are suitable for network The techniques described in this document are suitable for network
management scenarios such as the ones described in section 3. management scenarios such as the ones described in Section 1.1.
However, these techniques SHOULD only be used for a NETCONF server to However, these techniques SHOULD only be used for a NETCONF server to
initiate a connection to a NETCONF client, as described in this initiate a connection to a NETCONF client, as described in this
document. document.
The reason for this restriction is that different protocols have The reason for this restriction is that different protocols have
different security assumptions. The NETCONF transport specifications different security assumptions. The NETCONF transport specifications
require NETCONF clients and servers to verify the identity of the require NETCONF clients and servers to verify the identity of the
other party before starting the NETCONF protocol (section 6 of other party before starting the NETCONF protocol (section 2.2 of
[RFC6242]). [RFC6241].
This contrasts with the base SSH and TLS protocols, which do not This contrasts with the base SSH and TLS protocols, which do not
require programmatic verification of the other party (e.g., section require programmatic verification of the other party (e.g., section
9.3.4 of [RFC4251] and section 4 of [RFC4252]). In such 9.3.4 of [RFC4251] and section 4 of [RFC4252]). In such
circumstances, allowing the SSH/TLS server to contact the SSH/TLS circumstances, allowing the SSH/TLS server to contact the SSH/TLS
client would open new vulnerabilities. Any use of call home with client would open new vulnerabilities. Any use of call home with
SSH/TLS for purposes other than NETCONF will need a thorough, SSH/TLS for purposes other than NETCONF will need a thorough,
contextual security analysis. contextual security analysis.
4. Update to RFC 4253 1.4. Update to RFC 4253
This document updates the SSH Transport Layer Protocol [RFC4253] only This document updates the SSH Transport Layer Protocol [RFC4253] only
by removing the restriction in Section 4 (Connection Setup) of by removing the "The client initiates the connection" statement made
[RFC4253] that the SSH client initiates the connection. Security in Section 4 (Connection Setup). This document assumes that the
implications related to this change are discussed in Security reference to "connection" refers to the underlying transport
Considerations (Section 9). connection (e.g., TCP). Security implications related to this change
are discussed in Security Considerations (Section 4).
5. Overview
The same technique is used to enabled call home for both the SSH and
TLS transports. The technique is to have the network element
initiate a TCP connection to its remote peer. The remote peer then
uses the established TCP connection to initiate either the SSH or TLS
protocols. In this way, the network element is always the SSH or TLS
server, regardless if call home is used or not.
Enabling the network element to maintain the role of SSH or TLS
server is both necessary and desirable. It is necessary for the SSH
protocol, as SSH channels and subsystems can only be opened on the
SSH server. It is desirable for both the SSH and TLS protocols as it
conveniently leverages infrastructure that may be deployed for host-
key or certificate verification and user authentication.
6. Operation 2. The NETCONF Server
The NETCONF server's perspective (e.g., the network element) 2.1. Protocol Operation
o The NETCONF server initiates a TCP connection to the NETCONF o The NETCONF server initiates a TCP connection to the NETCONF
client on one of the IANA-assigned ports for NETCONF Call Home client on one of the IANA-assigned ports for NETCONF Call Home
(YYYY or ZZZZ). (YYYY for netconf-ch-ssh and ZZZZ for netconf-ch-tls).
o The TCP connection is accepted and a TCP session is established. o The TCP connection is accepted and a TCP session is established.
o Using this TCP connection, the NETCONF server immediately starts o Using this TCP session, the NETCONF server immediately starts
either the SSH-server or TLS-server protocol. That is, the next either the SSH-server or the TLS-server protocol, depending on
message sent on the TCP stream is the initial message defined for which port is connected. The NETCONF server MUST start the SSH-
these protocols, per [RFC4253] or [RFC5246]. server protocol when port YYYY is connected and the TLS-server
protocol when port ZZZZ is connected. The SSH-server and TLS-
server protocols are described by [RFC4253] and [RFC5246]
respectively.
o The NETCONF protocol proceeds normally for SSH and TLS, as defined o The NETCONF protocol proceeds normally for SSH and TLS, as defined
in [RFC4253] and [RFC5539] respectively. in [RFC6242] and [RFC5539] respectively.
The NETCONF client's perspective (e.g., the management system) 2.2. Configuration Data Model
How to configure a NETCONF server to initiate a NETCONF Call Home
connection is outside the scope of this document, as implementations
can support this protocol using proprietary configuration data
models. That said, a YANG [RFC6020] model for configuring NETCONF
Call Home is provided in [draft-ietf-netconf-server-model].
3. The NETCONF Client
3.1. Protocol Operation
o The NETCONF client listens for TCP connections on one or both of o The NETCONF client listens for TCP connections on one or both of
the IANA-assigned ports for NETCONF Call Home port (YYYY and/or the IANA-assigned ports for NETCONF Call Home (YYYY for netconf-
ZZZZ). ch-ssh and ZZZZ for netconf-ch-tls).
o The NETCONF client accepts an incoming TCP connection and a TCP o The NETCONF client accepts an incoming TCP connection and a TCP
session is established. session is established.
o Using this TCP connection, the NETCONF client immediately starts o Using this TCP session, the NETCONF client immediately starts
either the SSH-server or TLS-server protocol. That is, the next either the SSH-client or the TLS-client protocol, depending on
message sent on the TCP stream is the initial message defined for which port is connected. The NETCONF client MUST start the SSH-
these protocols, per xref target="RFC4253"/> or [RFC5246]. client protocol when port YYYY is connected and the TLS-client
protocol when port ZZZZ is connected. The SSH-client and TLS-
client protocols are described by [RFC4253] and [RFC5246]
respectively.
o The NETCONF protocol proceeds normally for SSH and TLS, as defined o The NETCONF protocol proceeds normally for SSH and TLS, as is
in [RFC4253] and [RFC5539] respectively. defined in [RFC6242] and [RFC5539] respectively.
7. NETCONF Server Identification and Verification 3.2. Server Identification and Verification
Under normal circumstances, a management system initiates the NETCONF Under normal circumstances, a NETCONF client initiates the NETCONF
connection to the network element. This action provides essential connection to the NETCONF server. This action provides essential
input to verify the network element's identity. For instance, when input to verify the NETCONF server's identity. For instance, when
using TLS, the input can be compared to the domain names and IP using TLS, the input can be compared to the domain names and IP
addresses encoded in X.509 certificates. Similarly, when using SSH, addresses encoded in X.509 certificates. Similarly, when using SSH,
the input can be compared to information persisted previously. the input can be compared to information persisted previously.
However, when receiving a NETCONF Call Home connection, the However, when receiving a NETCONF Call Home connection, the NETCONF
management system does not have an expectation for the connection to client does not have any context leading it to know the connection is
be from a specific network element, and thus must derived the network from a particular NETCONF server. Thus the NETCONF client must
element's identity using information provided by the network and the derive the NETCONF server's identity using information provided by
network element itself. This section describes strategies a the network and the NETCONF server itself. This section describes
management system can use to identify a network element. strategies a NETCONF client can use to identify a NETCONF server.
In addition to identifying a network element, a management system In addition to identifying a NETCONF server, a NETCONF client must
must also be able to verify the network element's credentials. also be able to verify the NETCONF server's credentials. Verifying a
Verifying a network element's credentials is of course necessary NETCONF server's credentials is necessary under normal circumstances
under normal circumstances, but due to call home being commonly used but, due to call home being commonly used for newly deployed NETCONF
for newly deployed network elements, how to verify its credentials servers, how to verify its credentials the very first time becomes a
the very first time becomes a critical concern. Therefore, this prominent concern. Therefore, this section also describes strategies
section also describes strategies a management system can use to a NETCONF client can use to verify a NETCONF server's credentials.
verify a network element's credentials.
The first information a management system learns from a NETCONF Call The first information a NETCONF client learns from a NETCONF Call
Home connection is the IP address of the remote peer, as provided as Home connection is the IP address of the NETCONF server, as provided
the source address of the TCP connection. This IP address could be by the source address of the TCP connection. This IP address could
used as an identifier, but it can only work in networks that use be used as an identifier directly, but doing so would only work in
known static addresses, in which case having the management system networks that use known static addresses, in which case a standard
initiate the NETCONF connection to the network element would have NETCONF connection would have worked just as well. Due to this
worked just as well. Due to its limited use, it is not recommended limited use, it is not recommended to identify a NETCONF server based
to identify a network element based on its source IP address. on its source IP address.
The next information a management system learns is provided by the The next information a NETCONF client learns is provided by the
network element in the form of a host-key or a certificate, for the NETCONF server in the form of a host-key or a certificate, for the
SSH and TLS protocols respectively. Without examining the contents SSH and TLS protocols respectively. Without examining the contents
of the host-key or certificate, it is possible to form an identity of the host-key or certificate, it is possible to form an identity
for the network element using it (e.g., a fingerprint), since each for the NETCONF server using it (e.g., a fingerprint), since each
network element is assumed to have a statistically unique public key, NETCONF server is assumed to have a statistically unique public key,
even in virtualized environments. This strategy also provides a even in virtualized environments. This strategy also provides a
mechanism to verify the network element, in that a secure connection mechanism to verify the NETCONF server, in that a secure connection
can only be established with the network element having the matching can only be established with the NETCONF server having the matching
private key. This strategy is commonly implemented by SSH clients, private key. This strategy is commonly implemented by SSH clients,
but could be used equally well by TLS-based clients, such as may be and could be used equally well by TLS-based clients, such as may be
required when the network elements have self-signed certificates. required when the NETCONF servers have self-signed certificates.
This strategy is viable and useful when the network elements call This strategy is viable and useful when the NETCONF servers call home
home using either SSH with standard RSA/DSA host-keys, or using TLS using either SSH with standard RSA/DSA host-keys, or using TLS with
with self-signed certificates. self-signed certificates.
Yet another option for identifying a network element is for its host Yet another option for identifying a NETCONF server is for its host
key or certificate to encode its identity directly (e.g., within the key or certificate to encode its identity directly (e.g., within the
"Subject" field). However, in order to trust the content encoded "Subject" field). However, in order to trust the content encoded
within a host-key or certificate, it must be signed by a trust anchor within a host-key or certificate, it must be signed by a certificate
known to the management application. This strategy enables a authority trusted by the NETCONF client. This strategy's use of PKI
management application to transparently authenticate network enables a NETCONF client to transparently authenticate NETCONF
elements, thus eliminating the need for manual authentication, as servers, thus eliminating the need for manual authentication, as
required by the previously discussed strategy. Elimination of manual required by the previously discussed strategies. Elimination of
steps is needed to achieve scalable solutions, however one can claim manual steps is needed to achieve scalable solutions, however one can
that this merely pushes equivalent work to provisioning the network claim that this merely pushes equivalent work to provisioning the
elements with signed credentials. This assessment is accurate in NETCONF servers with signed credentials. This assessment is accurate
general, but not in the case where the manufacturer itself provisions in general, but not in the case where the manufacturer itself
the credentials, such as is described by [Std-802.1AR-2009]. When provisions the credentials, such as is described by
network elements are pre-provisioned this way, management [Std-802.1AR-2009]. When NETCONF servers are pre-provisioned this
applications can transparently authenticate network elements using way, NETCONF clients can transparently authenticate NETCONF servers
just the manufacturer's trust anchor and a list of expected network using just the manufacturer's trust anchor and a list of expected
element identifiers, which could be provided along with shipping NETCONF server identifiers, which could be provided along with
information. shipping information. This strategy is recommended for all
deployment scenarios.
TLS uses X.509 certificates by default. To use X.509 certificates
with SSH, implementations should reference [RFC6187].
8. Configuration Data Model
How to configure a network element to initiate a NETCONF Call Home In discussing the use of certificates, it is worth noting that TLS
connection is outside the scope of this document, as implementations uses X.509 certificates by default. However, to use X.509
can support this protocol using proprietary configuration data certificates with SSH, both the NETCONF client and server must
models. That said, a YANG [RFC6020] model configuring NETCONF Call support [RFC6187].
Home is provided in [draft-ietf-netconf-server-model].
9. Security Considerations 4. Security Considerations
The security considerations described throughout [RFC6242] and The security considerations described throughout [RFC6242] and
[RFC5539], and by extension [RFC4253] and [RFC5246], apply here as [RFC5539], and by extension [RFC4253] and [RFC5246], apply here as
well. well.
This RFC deviates from standard SSH and TLS usage by having the SSH/ This RFC deviates from standard SSH and TLS usage by having the SSH/
TLS server initiate the underlying TCP connection. For SSH, TLS server initiate the underlying TCP connection. For SSH,
[RFC4253] says "the client initiates the connection", whereas for [RFC4253] says "the client initiates the connection", whereas for
TLS, [RFC5246] says it is layered on top of "some reliable transport TLS, [RFC5246] says it is layered on top of "some reliable transport
protocol" without further attribution. protocol" without further attribution.
For SSH, not having the SSH client initiate the TCP connection means For SSH, not having the SSH client initiate the TCP connection means
that it does not have a preconceived notion of the SSH server's that it does not have a preconceived notion of the SSH server's
identity, and therefore must dynamically derive one from information identity, and therefore must dynamically derive one from information
provided by the network or the SSH server itself. Security provided by the network or the SSH server itself. Security
Considerations for strategies for this are described in Section 7. Considerations for strategies for this are described in Section 3.2.
An attacker could DoS the management application by having it perform An attacker could DoS the NETCONF client by having it perform
computationally expensive operations, before deducing that the computationally expensive operations, before deducing that the
attacker doesn't posses a valid key. This is no different than any attacker doesn't posses a valid key. This is no different than any
secured service and all common precautions apply (e.g., blacklisting secured service and all common precautions apply (e.g., blacklisting
the source address after a set number of unsuccessful login the source address after a set number of unsuccessful login
attempts). attempts).
10. IANA Considerations 5. IANA Considerations
This document requests that IANA assigns two TCP port numbers in the This document requests that IANA assigns two TCP port numbers in the
"Registered Port Numbers" range with the service names "netconf-ch- "Registered Port Numbers" range with the service names "netconf-ch-
ssh" and "netconf-ch-tls". These ports will be the default ports for ssh" and "netconf-ch-tls". These ports will be the default ports for
NETCONF Call Home protocol when using SSH and TLS respectively. NETCONF Call Home protocol when using SSH and TLS respectively.
Below is the registration template following the rules in [RFC6335]. Below is the registration template following the rules in [RFC6335].
Service Name: netconf-ch-ssh Service Name: netconf-ch-ssh
Transport Protocol(s): TCP Transport Protocol(s): TCP
Assignee: IESG <iesg@ietf.org> Assignee: IESG <iesg@ietf.org>
skipping to change at page 7, line 38 skipping to change at page 8, line 21
Port Number: YYYY Port Number: YYYY
Service Name: netconf-ch-tls Service Name: netconf-ch-tls
Transport Protocol(s): TCP Transport Protocol(s): TCP
Assignee: IESG <iesg@ietf.org> Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org> Contact: IETF Chair <chair@ietf.org>
Description: NETCONF Call Home (TLS) Description: NETCONF Call Home (TLS)
Reference: RFC XXXX Reference: RFC XXXX
Port Number: ZZZZ Port Number: ZZZZ
11. Acknowledgements 6. Acknowledgements
The author would like to thank for following for lively discussions The author would like to thank for following for lively discussions
on list and in the halls (ordered by last name): Andy Bierman, Martin on list and in the halls (ordered by last name): Andy Bierman, Martin
Bjorklund, Mehmet Ersue, Wes Hardaker, Stephen Hanna, David Bjorklund, Mehmet Ersue, Wes Hardaker, Stephen Hanna, David
Harrington, Jeffrey Hutzelman, Radek Krejci, Alan Luchuk, Mouse, Russ Harrington, Jeffrey Hutzelman, Radek Krejci, Alan Luchuk, Mouse, Russ
Mundy, Tom Petch, Peter Saint-Andre, Joe Touch, Sean Turner, Bert Mundy, Tom Petch, Peter Saint-Andre, Joe Touch, Sean Turner, Bert
Wijnen. Wijnen.
12. References 7. References
12.1. Normative References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, January 2006. Protocol Architecture", RFC 4251, January 2006.
[RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, January 2006. Authentication Protocol", RFC 4252, January 2006.
skipping to change at page 8, line 31 skipping to change at page 9, line 12
[RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)", [RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)",
RFC 5539, May 2009. RFC 5539, May 2009.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020, Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010. October 2010.
[RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure
Shell Authentication", RFC 6187, March 2011. Shell Authentication", RFC 6187, March 2011.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", RFC
6241, June 2011.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, June 2011. Shell (SSH)", RFC 6242, June 2011.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA) Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, RFC Transport Protocol Port Number Registry", BCP 165, RFC
6335, August 2011. 6335, August 2011.
12.2. Informative References 7.2. Informative References
[Std-802.1AR-2009] [Std-802.1AR-2009]
IEEE SA-Standards Board, "IEEE Standard for Local and IEEE SA-Standards Board, "IEEE Standard for Local and
metropolitan area networks - Secure Device Identity", metropolitan area networks - Secure Device Identity",
December 2009, <http://standards.ieee.org/findstds/ December 2009, <http://standards.ieee.org/findstds/
standard/802.1AR-2009.html>. standard/802.1AR-2009.html>.
[draft-ietf-netconf-server-model] [draft-ietf-netconf-server-model]
Watsen, K. and J. Schoenwaelder, "NETCONF Server Watsen, K. and J. Schoenwaelder, "NETCONF Server
Configuration Model", 2014, <http://tools.ietf.org/html/ Configuration Model", 2014, <http://tools.ietf.org/html/
draft-ietf-netconf-server-model>. draft-ietf-netconf-server-model>.
[iesg-statement] [iesg-statement]
"Writable MIB Module IESG Statement", March 2014, "Writable MIB Module IESG Statement", March 2014,
<https://www.ietf.org/iesg/statement/writable-mib- <https://www.ietf.org/iesg/statement/writable-mib-
module.html>. module.html>.
Appendix A. Change Log
A.1. 00 to 01
o The term "TCP connection" is now used throughout.
o The terms "network element" and "management system" are now only
used in the Motivation section.
o Restructured doc a little to create an Introduction section.
o Fixed reference in Applicability Statement so it would work
equally well for SSH and TLS.
o Fixed reported odd wording and three references.
Author's Address Author's Address
Kent Watsen Kent Watsen
Juniper Networks Juniper Networks
EMail: kwatsen@juniper.net EMail: kwatsen@juniper.net
 End of changes. 43 change blocks. 
135 lines changed or deleted 178 lines changed or added

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