draft-ietf-netconf-reverse-ssh-04.txt   draft-ietf-netconf-reverse-ssh-05.txt 
NETCONF Working Group K. Watsen NETCONF Working Group K. Watsen
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Updates: 4253 (if approved) April 2014 Updates: 4253 (if approved) April 2014
Intended status: Standards Track Intended status: Standards Track
Expires: October 03, 2014 Expires: October 03, 2014
Reverse SSH for NETCONF Call Home NETCONF over SSH Call Home
draft-ietf-netconf-reverse-ssh-04 draft-ietf-netconf-reverse-ssh-05
Abstract Abstract
This document presents a technique for a NETCONF server to initiate a This document presents a technique for a NETCONF server to initiate a
SSH connection to a NETCONF client. This is accomplished by the SSH connection to a NETCONF client. This is accomplished by the
NETCONF client listening on IANA-assigned TCP port YYYY and starting NETCONF client listening on IANA-assigned TCP port YYYY and starting
the SSH client protocol immediately after accepting a TCP connection the SSH client protocol immediately after accepting a TCP connection
on it. This role-reversal is necessary as the NETCONF server must on it. This role-reversal is necessary as the NETCONF server must
also be the SSH server, in order for the NETCONF client to open the also be the SSH server, in order for the NETCONF client to open the
IANA-assigned SSH subsystem "netconf". IANA-assigned SSH subsystem "netconf".
skipping to change at page 2, line 12 skipping to change at page 2, line 12
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 . . . . . . . . . . . . . . . . . 3 2.1. Applicability Statement . . . . . . . . . . . . . . . . . 2
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. 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. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 9 A.1. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 9
A.2. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 10 A.2. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 9
A.3. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 10 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 10
A.4. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 10 A.4. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 10
A.5. 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 document presents a technique for a NETCONF [RFC6241] server to This document presents a technique for a NETCONF [RFC6241] server to
skipping to change at page 3, line 9 skipping to change at page 3, line 4
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 (section 6 of
with the base SSH protocol, which does not require programmatic [RFC6242]). This contrasts with the base SSH protocol, which does
verification of the other party. In such circumstances, allowing the not require programmatic verification of the other party (section
SSH server to contact the SSH client would open new vulnerabilities. 9.3.4 of [RFC4251] and section 4 of [RFC4252]). In such
Therefore, any use of Reverse SSH for purposes other than NETCONF circumstances, allowing the SSH server to contact the SSH client
will need a thorough, contextual security analysis. would open new vulnerabilities. Therefore, any use of call home with
SSH for purposes other than NETCONF will need a thorough, contextual
security analysis.
2.2. Update to RFC 4253 2.2. 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 restriction in Section 4 (Connection Setup) of
[RFC4252] that the SSH Client must initiate the transport connection. [RFC4252] that the SSH Client must initiate the transport connection.
Security implications related to this change are discussed in Security implications related to this change are discussed in
Security Considerations (Section 7). Security Considerations (Section 7).
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 NETCONF over SSH Call Home enables the network element to
server regardless of which peer initiates the underlying TCP consistently be the SSH server regardless of which peer initiates the
connection. Maintaining the role of SSH server is both necessary and underlying TCP connection. Maintaining the role of SSH server is
desirable. It is necessary because SSH channels and subsystems can both necessary and desirable. It is necessary because SSH channels
only be opened on the SSH server. It is desirable because it and subsystems can only be opened on the SSH server. It is desirable
conveniently leverages infrastructure that may be deployed for host- because it conveniently leverages infrastructure that may be deployed
key verification and user authentication. for host-key verification and user authentication.
Reverse SSH is useful for both initial deployment and on-going device Call home 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
powered on for the first time to register itself with its on for the first time to register itself with its management
management system. 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 4, line 29 skipping to change at page 4, line 29
management system to connect to it. management system to connect to it.
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 call home connection to a
the management system, regardless the number of NETCONF channels the management system, regardless the number of NETCONF channels the
management system wants to open. management system wants to open.
4. The Reverse SSH Protocol 4. 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 SSH for NETCONF Call Home 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 NETCONF over SSH Call Home 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]).
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 TCP connection on When the management system accepts a new incoming TCP connection on
the Reverse SSH port, it starts the SSH client protocol. As the SSH the NETCONF over SSH Call Home port, it starts the SSH client
client, it MUST authenticate the SSH server, by both identifying the protocol. As the SSH client, it MUST authenticate the SSH server, by
network element and verifying its SSH host key. both identifying the network element and verifying its SSH host key.
Due to Reverse SSH having the network element initiate the TCP Due to call home having the network element initiate the TCP
connection, the management system MAY identify the remote peer using connection, the management system MAY identify the remote peer using
the source IP address of the TCP connection. However, identifying the source IP address of the TCP connection. However, identifying
the remote peer using the source IP address of the TCP connection is the remote peer using the source IP address of the TCP connection is
NOT RECOMMENDED as it can only work in networks that use known static NOT RECOMMENDED as it can only work in networks that use known static
addresses. 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 addresses (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
skipping to change at page 6, line 27 skipping to change at page 6, line 27
management system. A more scalable strategy for the management management system. A more scalable strategy for the management
system is for the network element's manufacturer to sign the network- system is for the network element's manufacturer to sign the network-
element's host key with a common trusted key, such as a certificate element's host key with a common trusted key, such as a certificate
authority. Then, when the network-element is deployed, the authority. Then, when the network-element is deployed, the
management system only needs to trust a single certificate, which management system only needs to trust a single certificate, which
vouches for the authenticity of the various network element host vouches for the authenticity of the various network element host
keys. 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 identifier (e.g., its serial number) and
by a common trust anchor (e.g., a certificate authority). Examples be signed by a common trust anchor (e.g., a certificate authority).
of suitable public host keys are the X.509v3 keys defined in defined Examples of suitable public host keys are the X.509v3 keys defined in
in [RFC6187]. defined in [RFC6187].
6. Device Configuration 6. Device Configuration
Configuring a device to initiate a Reverse SSH connection is outside Configuring a device to initiate a NETCONF over SSH Call Home
the scope of this document, but entails setting what IP address a connection is outside the scope of this document, but entails setting
device should connect to and what SSH host-key it should present. A what IP address a device should connect to and what SSH host-key it
complete YANG [RFC6020] model to configure Reverse SSH is specified should present. A complete YANG [RFC6020] model to configure NETCONF
in [draft-ietf-netconf-server-model] over SSH Call Home is specified in [draft-ietf-netconf-server-model]
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 8, line 13 skipping to change at page 8, line 13
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 "netconf-ssh- "Registered Port Numbers" range with the service name "netconf-ssh-
ch". This port will be the default port for the Reverse SSH for ch". This port will be the default port for NETCONF over SSH Call
NETCONF Call Home protocol and will be used when the NETCONF server Home protocol and will be used when the NETCONF server is to initiate
is to initiate a connection to a NETCONF client using SSH. Below is a connection to a NETCONF client using SSH. Below is the
the registration template following the rules in [RFC6335]. registration template following the rules in [RFC6335].
Service Name: netconf-ssh-ch 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 for NETCONF Call Home Description: NETCONF over SSH 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, 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.
skipping to change at page 9, line 39 skipping to change at page 9, line 39
2011. 2011.
10.2. Informative References 10.2. Informative References
[draft-ietf-netconf-server-model] [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. 03 to 04 A.1. 04 to 05
Changed title to "Reverse SSH for NETCONF Call Home" Changed "Reverse SSH" to "Call Home"
Added references to Applicability Statement
A.2. 03 to 04
Changed title to "SSH for NETCONF Call Home" (changed again in
-05)
Removed statement on how other SSH channels might be used for Removed statement on how other SSH channels might be used for
other protocols other protocols
Improved language on how the management system, as the SSH client, Improved language on how the management system, as the SSH client,
MUST authenticate the SSH server MUST authenticate the SSH server
Clarified that identifying the network element using source IP Clarified that identifying the network element using source IP
address is NOT RECOMMENDED address is NOT RECOMMENDED
Clarified that identifying the NE using simple certificate Clarified that identifying the NE using simple certificate
comparison is NOT RECOMMENDED comparison is NOT RECOMMENDED
Device Configuration section now more clearly states that the YANG Device Configuration section now more clearly states that the YANG
model is out of scope model is out of scope
Change requested port name to "netconf-ssh-ch" Change requested port name to "netconf-ssh-ch"
General edits for grammer, capitalization, and spellings General edits for grammer, capitalization, and spellings
skipping to change at page 10, line 14 skipping to change at page 10, line 20
Clarified that identifying the NE using simple certificate Clarified that identifying the NE using simple certificate
comparison is NOT RECOMMENDED comparison is NOT RECOMMENDED
Device Configuration section now more clearly states that the YANG Device Configuration section now more clearly states that the YANG
model is out of scope model is out of scope
Change requested port name to "netconf-ssh-ch" Change requested port name to "netconf-ssh-ch"
General edits for grammer, capitalization, and spellings General edits for grammer, capitalization, and spellings
A.2. 02 to 03 A.3. 02 to 03
Updated Device Configuration section to reference Updated Device Configuration section to reference
[draft-ietf-netconf-server-model] [draft-ietf-netconf-server-model]
A.3. 01 to 02 A.4. 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.4. 00 to 01 A.5. 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. 26 change blocks. 
60 lines changed or deleted 71 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/