draft-ietf-netconf-reverse-ssh-03.txt   draft-ietf-netconf-reverse-ssh-04.txt 
NETCONF Working Group K. Watsen NETCONF Working Group K. Watsen
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Updates: 4253 (if approved) February 14, 2014 Updates: 4253 (if approved) April 2014
Intended status: Standards Track Intended status: Standards Track
Expires: August 18, 2014 Expires: October 03, 2014
Reverse Secure Shell (Reverse SSH) Reverse SSH for NETCONF Call Home
draft-ietf-netconf-reverse-ssh-03 draft-ietf-netconf-reverse-ssh-04
Abstract Abstract
This memo presents a technique for a NETCONF server to initiate a SSH This document presents a technique for a NETCONF server to initiate a
connection to a NETCONF client. This is accomplished by the NETCONF SSH connection to a NETCONF client. This is accomplished by the
client listening on IANA-assigned TCP port YYYY and starting the SSH NETCONF client listening on IANA-assigned TCP port YYYY and starting
client protocol immediately after accepting a TCP connection on it. the SSH client protocol immediately after accepting a TCP connection
This role-reversal is necessary as the NETCONF server must also be on it. This role-reversal is necessary as the NETCONF server must
the SSH Server, in order for the NETCONF client to open the IANA- also be the SSH server, in order for the NETCONF client to open the
assigned SSH subsystem "netconf". IANA-assigned SSH subsystem "netconf".
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 18, 2014. This Internet-Draft will expire on October 03, 2014.
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. Requirements Terminology . . . . . . . . . . . . . . . . . . 2 1. Requirements Terminology . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Applicability Statement . . . . . . . . . . . . . . . . . 2 2.1. Applicability Statement . . . . . . . . . . . . . . . . . 3
2.2. Update to RFC 4253 . . . . . . . . . . . . . . . . . . . 3 2.2. Update to RFC 4253 . . . . . . . . . . . . . . . . . . . 3
3. Benefits to Device Management . . . . . . . . . . . . . . . . 3 3. Benefits to Device Management . . . . . . . . . . . . . . . . 3
4. The Reverse SSH Protocol . . . . . . . . . . . . . . . . . . 4 4. The Reverse SSH Protocol . . . . . . . . . . . . . . . . . . 4
5. SSH Server Identification and Verification . . . . . . . . . 5 5. SSH Server Identification and Verification . . . . . . . . . 5
6. Device Configuration . . . . . . . . . . . . . . . . . . . . 6 6. Device Configuration . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 9 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 9
A.1. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 9 A.1. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 9
A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 9 A.2. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 10
A.3. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 10 A.3. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 10
A.4. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Requirements Terminology 1. 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].
2. Introduction 2. Introduction
This memo presents a technique for a NETCONF [RFC6241] server to This document presents a technique for a NETCONF [RFC6241] server to
initiate a Secure Shell (SSH) [RFC4251] connection to a NETCONF initiate a Secure Shell (SSH) [RFC4251] connection to a NETCONF
client. This is accomplished by the NETCONF client listening on client. This is accomplished by the NETCONF client listening on
IANA-assigned TCP port YYYY and starting the SSH client protocol IANA-assigned TCP port YYYY and starting the SSH client protocol
immediately after accepting a TCP connection on it. This role- immediately after accepting a TCP connection on it. This role-
reversal is necessary as the NETCONF server must also be the SSH reversal is necessary as the NETCONF server must also be the SSH
Server, in order for the NETCONF client to open the IANA-assigned SSH server, in order for the NETCONF client to open the IANA-assigned SSH
subsystem "netconf" [RFC6242]. subsystem "netconf" [RFC6242].
2.1. Applicability Statement 2.1. 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 3.
However, these techniques MUST only be used for a NETCONF server to However, these techniques MUST 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 over SSH specification different security assumptions. The NETCONF over SSH specification
requires NETCONF clients and servers to verify the identity of the requires NETCONF clients and servers to verify the identity of the
other party before starting the NETCONF protocol. This contrasts other party before starting the NETCONF protocol. This contrasts
skipping to change at page 3, line 38 skipping to change at page 3, line 41
3. Benefits to Device Management 3. Benefits to Device Management
The SSH protocol is nearly ubiquitous for device management, as it is The SSH protocol is nearly ubiquitous for device management, as it is
the transport for the command-line applications `ssh`, `scp`, and the transport for the command-line applications `ssh`, `scp`, and
`sftp` and is the required transport for the NETCONF protocol `sftp` and is the required transport for the NETCONF protocol
[RFC6241]. However, all these SSH-based protocols expect the network [RFC6241]. However, all these SSH-based protocols expect the network
element to be the SSH server. element to be the SSH server.
Reverse SSH enables the network element to consistently be the SSH Reverse SSH enables the network element to consistently be the SSH
server regardless of which peer initiates the underlying TCP server regardless of which peer initiates the underlying TCP
connection. Maintaining the role of SSH Server is both necessary and connection. Maintaining the role of SSH server is both necessary and
desirable. It is necessary because SSH channels and subsystems can desirable. It is necessary because SSH channels and subsystems can
only be opened on the SSH Server. It is desirable because it only be opened on the SSH server. It is desirable because it
conveniently leverages infrastructure that may be deployed for host- conveniently leverages infrastructure that may be deployed for host-
key verification and user authentication. key verification and user authentication.
Reverse SSH is useful for both initial deployment and on-going device Reverse SSH is useful for both initial deployment and on-going device
management and may be used to enable any of the following scenarios: management and may be used to enable any of the following scenarios:
o The network element may proactively "call home" after being o The network element may proactively "call home" after being
powered on for the first time to register itself with its powered on for the first time to register itself with its
management system. management system.
skipping to change at page 4, line 30 skipping to change at page 4, line 30
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.
One key benefit of using SSH as the transport protocol is its ability One key benefit of using SSH as the transport protocol is its ability
to multiplex an unspecified number of independently flow-controlled to multiplex an unspecified number of independently flow-controlled
TCP sessions [RFC4254]. This is valuable as the network element only TCP sessions [RFC4254]. This is valuable as the network element only
needs to be configured to initiate a single Reverse SSH connection to needs to be configured to initiate a single Reverse SSH connection to
the management system, regardless the number of TCP-based protocols the management system, regardless the number of NETCONF channels the
the management system wishes to support. For instance, in addition management system wants to open.
to having a SSH channel for NETCONF, the management system may "pin
up" channels for Syslog, SNMP, or file-transfers.
4. The Reverse SSH Protocol 4. The Reverse SSH Protocol
The NETCONF server's perspective (e.g., the network element) The NETCONF server's perspective (e.g., the network element)
o The NETCONF server initiates a TCP connection to the NETCONF o The NETCONF server initiates a TCP connection to the NETCONF
client on the IANA-assigned Reverse SSH port YYYY. client on the IANA-assigned Reverse SSH port YYYY.
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 connection, the NETCONF server immediately starts
the SSH Server protocol. That is, the next message sent on the the SSH server protocol. That is, the next message sent on the
TCP stream is SSH's Protocol Version Exchange message (section TCP stream is SSH's Protocol Version Exchange message (section
4.2, [RFC4253]). 4.2, [RFC4253]).
o The SSH connection is established. o The SSH connection is established.
The NETCONF client's perspective (e.g., the management system) The NETCONF client's perspective (e.g., the management system)
o The NETCONF client listens for TCP connections on the IANA- o The NETCONF client listens for TCP connections on the IANA-
assigned SSH port YYYY. assigned SSH port YYYY.
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 connection, the NETCONF client immediately starts
the SSH Client protocol, starting with sending the SSH's Protocol the SSH Client protocol, starting with sending the SSH's Protocol
Version Exchange message (section 4.2, [RFC4253]). Version Exchange message (section 4.2, [RFC4253]).
skipping to change at page 5, line 18 skipping to change at page 5, line 16
session is established. session is established.
o Using this TCP connection, the NETCONF client immediately starts o Using this TCP connection, the NETCONF client immediately starts
the SSH Client protocol, starting with sending the SSH's Protocol the SSH Client protocol, starting with sending the SSH's Protocol
Version Exchange message (section 4.2, [RFC4253]). Version Exchange message (section 4.2, [RFC4253]).
o The SSH connection is established. o The SSH connection is established.
5. SSH Server Identification and Verification 5. SSH Server Identification and Verification
When the management system accepts a new incoming connection, it When the management system accepts a new incoming TCP connection on
needs to authenticate the remote peer. Ultimately, this entails the Reverse SSH port, it starts the SSH client protocol. As the SSH
identifying the peer and verifying its SSH host key. client, it MUST authenticate the SSH server, by both identifying the
network element and verifying its SSH host key.
Due to Reverse SSH having the network element initiate the TCP Due to Reverse SSH having the network element initiate the TCP
connection, the first data the management system has to identify it connection, the management system MAY identify the remote peer using
with is the source IP address of the TCP connection. But this the source IP address of the TCP connection. However, identifying
approach is limited as it only works in networks that use known the remote peer using the source IP address of the TCP connection is
static addresses. NOT RECOMMENDED as it can only work in networks that use known static
addresses.
To support network-elements having dynamically-assigned IP addresses To support network elements having dynamically-assigned IP addresses,
or deployed behind gateways that translate their IP address (e.g., or deployed behind gateways that translate their IP addresses (e.g.,
NAT), the management system MAY identify the device using its SSH NAT), the management system MAY identify the device using its SSH
host key. For instance, a fingerprint of the network element's host host key. For instance, a fingerprint of the network element's host
key could be used as an identifier since the probability of collision key could itself be used as an identifier since each device has a
is acceptably low. But this solution requires the management system statistically unique host key. However, identifying the remote peer
to be configured with each device's host key each time it changes. using its host key directly is NOT RECOMMENDED as it requires the
host key to be manually verified the first time the network element
connects and anytime its host key changes thereafter.
Yet another option for identifying the network element is for its Yet another option for identifying the network element is for its
host key to encode its identity, such as if it were a certificate. host key to encode the network element's identity, such as if the
This option enables the host key to change over time, but brings the host key were a certificate. This option enables the host key to
next issue of how the mangement element can verify the network change over time, so long as it continues to encode the same
element's host key is authentic. identity, but brings the next issue of how the management system can
verify the network element's host key is authentic.
The security of SSH is anchored in the ability for the SSH client to The security of SSH is anchored in the ability for the SSH client to
verify the SSH server's hostkey. Typically this is done by comparing verify the SSH server's host key. Typically this is done by
the host key presented by the SSH server with one that was previously comparing the host key presented by the SSH server with one that was
configured on the SSH client, looking it up in a local database using previously configured on the SSH client, looking it up in a local
the identity of the SSH client as the lookup key. Nothing changes database using the identity of the SSH client as the lookup key.
regarding this requirement due to the direction reversal of the Nothing changes regarding this requirement due to the direction
underlying TCP connection. To ensure security, the management system reversal of the underlying TCP connection. To ensure security, the
MUST verify the network element's SSH host key each time a SSH management system MUST verify the network element's SSH host key each
session is established. time a SSH session is established.
However, configuring distinct host keys on the management system However, configuring distinct host keys on the management system
doesn't scale well, which is an important consideration to a network doesn't scale well, which is an important consideration to a network
management system. A more scalable strategy is to have the network management system. A more scalable strategy for the management
element's host key signed by a common trusted key, such as a system is for the network element's manufacturer to sign the network-
certificate authority. Thus, the mangement system only needs to element's host key with a common trusted key, such as a certificate
trust a single public key, which vouches for the authenticity of the authority. Then, when the network-element is deployed, the
various network element public keys. management system only needs to trust a single certificate, which
vouches for the authenticity of the various network element host
keys.
Since both the identification and verification issues are addressed Since both the identification and verification issues are addressed
using certificates, this draft RECOMMENDS network elements use a host using certificates, this draft RECOMMENDS network elements use a host
key that can encode a unique (e.g., its serial number) and be signed key that can encode a unique (e.g., its serial number) and be signed
by a common trust anchor (e.g., a certificate authority). Examples by a common trust anchor (e.g., a certificate authority). Examples
of suitable public host keys are the X.509v3 keys defined in defined of suitable public host keys are the X.509v3 keys defined in defined
in [RFC6187]. in [RFC6187].
6. Device Configuration 6. Device Configuration
Configuring a device to initiate a Reverse SSH connection entails it Configuring a device to initiate a Reverse SSH connection is outside
knowing what IP address it should connect to and what SSH host-key it the scope of this document, but entails setting what IP address a
should present. A complete YANG module [RFC6020] to configure device should connect to and what SSH host-key it should present. A
Reverse SSH is defined in [I.D.kwatsen-netconf-server] . This YANG complete YANG [RFC6020] model to configure Reverse SSH is specified
module enables a NETCONF client to generically manage a NETCONF in [draft-ietf-netconf-server-model]
server's Reverse SSH configuration. Key aspects of this YANG module
include support for more than one application, more than one server
per application, and a reconnection strategy.
7. Security Considerations 7. Security Considerations
This RFC deviates from standard SSH protocol usage by allowing the This RFC deviates from standard SSH protocol usage by allowing the
SSH server to initiate the TCP connection. This conflicts with SSH server to initiate the TCP connection. This conflicts with
section 4 of the SSH Transport Layer Protocol RFC [RFC4253], which section 4 of the SSH Transport Layer Protocol RFC [RFC4253], which
states "The client initiates the connection". However this statement states "The client initiates the connection". However this statement
is made without rationalization and it's not clear how it impacts the is made without rationalization and it's not clear how it impacts the
security of the protocol, so this section analyzes the security security of the protocol, so this section analyzes the security
offered by having the client initiate the connection. offered by having the client initiate the connection.
skipping to change at page 7, line 8 skipping to change at page 7, line 4
SSH server to initiate the TCP connection. This conflicts with SSH server to initiate the TCP connection. This conflicts with
section 4 of the SSH Transport Layer Protocol RFC [RFC4253], which section 4 of the SSH Transport Layer Protocol RFC [RFC4253], which
states "The client initiates the connection". However this statement states "The client initiates the connection". However this statement
is made without rationalization and it's not clear how it impacts the is made without rationalization and it's not clear how it impacts the
security of the protocol, so this section analyzes the security security of the protocol, so this section analyzes the security
offered by having the client initiate the connection. offered by having the client initiate the connection.
First, assuming the SSH server is not using a public host key First, assuming the SSH server is not using a public host key
algorithm that certifies its identity, the security of the protocol algorithm that certifies its identity, the security of the protocol
doesn't seem to be sensitive to which peer initiates the connection. doesn't seem to be sensitive to which peer initiates the connection.
That is, it is still the case that reliable distribution of host keys That is, it is still the case that reliable distribution of host keys
(or their fingerprints) should occur prior to first connection and (or their fingerprints) should occur prior to first connection and
that verification for subsequent connections happens by comparing the that verification for subsequent connections happens by comparing the
host keys in locally cached database. It does not seem to matter if host keys in a locally cached database. It does not seem to matter
the SSH Server's host name is derived from user-input or extracted if the SSH server's host name is derived from user-input or extracted
from the TCP layer, potentially via a reverse-DNS lookup. Once the from the TCP layer, potentially via a reverse-DNS lookup. Once the
host name-to-key association is stored in a local database, no man- host name-to-key association is stored in a local database, no man-
in-the-middle attack is possible due to the attacker being unable to in-the-middle attack is possible due to the attacker being unable to
guess the real SSH server's private key (Section 9.3.4 (Man-in-th- guess the real SSH server's private key (Section 9.3.4 (Man-in-the-
middle) of [RFC4251]). middle) of [RFC4251]).
That said, this RFC recommends implementations use a public host key That said, this RFC recommends implementations use a public host key
algorithm that certifies the SSH server's identity. The identity can algorithm that certifies the SSH server's identity. The identity can
be any unique identifier, such as a device's serial number or a be any unique identifier, such as a device's serial number or a
deployment-specific value. If this recommendation is followed, then deployment-specific value. If this recommendation is followed, then
no information from the TCP layer would be needed to lookup the no information from the TCP layer would be needed to lookup the
device in a local database and therefore the directionality of the device in a local database and therefore the directionality of the
TCP layer is clearly inconsequential. TCP layer is clearly inconsequential.
skipping to change at page 7, line 38 skipping to change at page 7, line 35
exchange (Section 7.1 (Algorithm Negotiation) in [RFC4253]). The exchange (Section 7.1 (Algorithm Negotiation) in [RFC4253]). The
algorithm selected is essentially the first compatible algorithm algorithm selected is essentially the first compatible algorithm
listed by the SSH client that is also listed by the SSH server. For listed by the SSH client that is also listed by the SSH server. For
a network management application, there may be a need to advertise a a network management application, there may be a need to advertise a
large number of algorithms to be compatible with the various devices large number of algorithms to be compatible with the various devices
it manages. The SSH client SHOULD order its list of public host key it manages. The SSH client SHOULD order its list of public host key
algorithms such that all the certifiable public host key algorithms algorithms such that all the certifiable public host key algorithms
are listed first. Additionally, when possible, SSH servers SHOULD are listed first. Additionally, when possible, SSH servers SHOULD
only list certifiable public host key algorithms. Note that since only list certifiable public host key algorithms. Note that since
the SSH server would have to be configured to know which IP address the SSH server would have to be configured to know which IP address
it needs to connect to, it is expected that it will also be it is to connect to, it is expected that it will also be configured
configured to know which host key algorithm to use for the particular to know which host key algorithm to use for the particular
application, and hence only needs to list just that one public host application, and hence only needs to list just that one public host
key algorithm. key algorithm.
This RFC suggests implementations can use a device's serial number as This RFC suggests implementations can use a device's serial number as
a form of identity. A potential concern with using a serial number a form of identity. A potential concern with using a serial number
is that the SSH protocol passes the SSH server's host-key in the is that the SSH protocol passes the SSH server's host-key in the
clear and many times serial numbers encode revealing information clear and many times serial numbers encode revealing information
about the device, such as what kind of device it is and when it was about the device, such as what kind of device it is and when it was
manufactured. While there is little security in trying to hide this manufactured. While there is little security in trying to hide this
information from an attacker, it is understood that some deployments information from an attacker, it is understood that some deployments
skipping to change at page 8, line 15 skipping to change at page 8, line 12
An attacker could DoS the application by having it perform An attacker could DoS the application 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).
8. IANA Considerations 8. IANA Considerations
This document requests that IANA assigns a TCP port number in the This document requests that IANA assigns a TCP port number in the
"Registered Port Numbers" range with the service name "reverse-ssh". "Registered Port Numbers" range with the service name "netconf-ssh-
This port will be the default port for the Reverse SSH protocol and ch". This port will be the default port for the Reverse SSH for
will be used when the NETCONF server needs to initiate a connection NETCONF Call Home protocol and will be used when the NETCONF server
to a NETCONF client using SSH. Below is the registration template is to initiate a connection to a NETCONF client using SSH. Below is
following the rules in [RFC6335]. the registration template following the rules in [RFC6335].
Service Name: reverse-ssh Service Name: netconf-ssh-ch
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: Reverse SSH (call home) Description: Reverse SSH for NETCONF Call Home
Reference: RFC XXXX Reference: RFC XXXX
Port Number: YYYY Port Number: YYYY
9. Acknowledgements 9. 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, Mouse, Russ Mundy, Tom Petch, Peter Harrington, Jeffrey Hutzelman, Radek Krejci, Alan Luchuk, Mouse, Russ
Saint-Andre, Joe Touch, Sean Turner, Bert Wijnen. Mundy, Tom Petch, Peter Saint-Andre, Joe Touch, Sean Turner, Bert
Wijnen.
10. References 10. References
10.1. Normative References 10.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.
[RFC4250] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH) [RFC4250] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH)
Protocol Assigned Numbers ", RFC 4250, December 2005. Protocol Assigned Numbers ", RFC 4250, December 2005.
skipping to change at page 9, line 33 skipping to change at page 9, line 33
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", RFC 6335, August Transport Protocol Port Number Registry", RFC 6335, August
2011. 2011.
10.2. Informative References 10.2. Informative References
[I.D.kwatsen-netconf-server] [draft-ietf-netconf-server-model]
Watsen, K. and J. Schoenwaelder, "A YANG Data Model for Watsen, K. and J. Schoenwaelder, "A YANG Data Model for
NETCONF Server Configuration", RFC 6242, June 2011. NETCONF Server Configuration", RFC 6242, June 2011.
Appendix A. Change Log Appendix A. Change Log
A.1. 02 to 03 A.1. 03 to 04
Changed title to "Reverse SSH for NETCONF Call Home"
Removed statement on how other SSH channels might be used for
other protocols
Improved language on how the management system, as the SSH client,
MUST authenticate the SSH server
Clarified that identifying the network element using source IP
address is NOT RECOMMENDED
Clarified that identifying the NE using simple certificate
comparison is NOT RECOMMENDED
Device Configuration section now more clearly states that the YANG
model is out of scope
Change requested port name to "netconf-ssh-ch"
General edits for grammer, capitalization, and spellings
A.2. 02 to 03
Updated Device Configuration section to reference Updated Device Configuration section to reference
[I.D.kwatsen-netconf-server] [draft-ietf-netconf-server-model]
A.2. 01 to 02 A.3. 01 to 02
Added Applicability Statement Added Applicability Statement
Removed references to ZeroConf / ZeroTouch Removed references to ZeroConf / ZeroTouch
Clarified the protocol section Clarified the protocol section
Added a section for identification and verification Added a section for identification and verification
A.3. 00 to 01 A.4. 00 to 01
Removed the hmac-* family of algorithms Removed the hmac-* family of algorithms
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. 35 change blocks. 
86 lines changed or deleted 115 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/