draft-ietf-netconf-reverse-ssh-05.txt   draft-ietf-netconf-reverse-ssh-06.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) July 2014
Intended status: Standards Track Intended status: Standards Track
Expires: October 03, 2014 Expires: January 02, 2015
NETCONF over SSH Call Home NETCONF Call Home using SSH
draft-ietf-netconf-reverse-ssh-05 draft-ietf-netconf-reverse-ssh-06
Abstract Abstract
This document presents a technique for a NETCONF server to initiate a This document presents a technique for a NETCONF server to request
SSH connection to a NETCONF client. This is accomplished by the that a NETCONF client initiates a SSH connection to the NETCONF
NETCONF client listening on IANA-assigned TCP port YYYY and starting server, a technique referred to as 'call home'. Call home is needed
the SSH client protocol immediately after accepting a TCP connection to support deployments where the NETCONF client is otherwise unable
on it. This role-reversal is necessary as the NETCONF server must to initiate a SSH connection to the NETCONF server directly.
also be the SSH server, in order for the NETCONF client to open the
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 October 03, 2014. This Internet-Draft will expire on January 02, 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. 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
2.3. Draft Naming . . . . . . . . . . . . . . . . . . . . . . 3
3. Benefits to Device Management . . . . . . . . . . . . . . . . 3 3. Benefits to Device Management . . . . . . . . . . . . . . . . 3
4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . 7
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. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 9 A.1. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 9
A.2. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 9 A.2. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 10
A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 10 A.3. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 10
A.4. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 10 A.4. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 11
A.5. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 10 A.5. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 11
A.6. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 11
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 server to request
This document presents a technique for a NETCONF [RFC6241] server to that a NETCONF [RFC6241] client initiates a SSH [RFC4251] connection
initiate a Secure Shell (SSH) [RFC4251] connection to a NETCONF to the NETCONF server, a technique referred to as 'call home'. Call
client. This is accomplished by the NETCONF client listening on home is needed to support deployments where the NETCONF client is
IANA-assigned TCP port YYYY and starting the SSH client protocol otherwise unable to initiate a SSH connection to the NETCONF server
immediately after accepting a TCP connection on it. This role- directly.
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
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 SHOULD 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 (section 6 of other party before starting the NETCONF protocol (section 6 of
[RFC6242]). This contrasts with the base SSH protocol, which does [RFC6242]). This contrasts with the base SSH protocol, which does
not require programmatic verification of the other party (section not require programmatic verification of the other party (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
skipping to change at page 3, line 29 skipping to change at page 3, line 39
security analysis. 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 2.3. Draft Naming
(this section should be removed if this draft becomes an RFC)
This draft's name includes the string "reverse-ssh", and yet
currently nowhere in this draft is there any reference to reversing
SSH. This appearant ommision comes from the -05 edit of this draft,
where "Reverse SSH" was changed to "Call Home" throughout. If this
draft becomes an RFC, its name would no longer contain the obsolete
"reverse-ssh" reference, thus self-correcting this inconsistency.
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.
NETCONF over SSH Call Home enables the network element to NETCONF over SSH Call Home enables the network element to
consistently be the SSH server regardless of which peer initiates the consistently be the SSH server regardless of which peer initiates the
underlying TCP connection. Maintaining the role of SSH server is underlying TCP connection. Maintaining the role of SSH server is
both necessary and desirable. It is necessary because SSH channels both necessary and desirable. It is necessary because SSH channels
skipping to change at page 6, line 30 skipping to change at page 6, line 42
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 identifier (e.g., its serial number) and key that can encode a unique identifier (e.g., its serial number) and
be signed by a common trust anchor (e.g., a certificate authority). be signed by a common trust anchor (e.g., a certificate authority).
Examples of suitable public host keys are the X.509v3 keys defined in Examples of suitable public host keys are the X.509v3 keys defined in
defined in [RFC6187]. defined in [RFC6187] and the PGP keys defined in [RFC4253].
6. Device Configuration 6. Device Configuration
Configuring a device to initiate a NETCONF over SSH Call Home How to configure a device to initiate a NETCONF over SSH Call Home
connection is outside the scope of this document, but entails setting connection is outside the scope of this document, as implementations
what IP address a device should connect to and what SSH host-key it can support this protocol using a proprietary configuration data
should present. A complete YANG [RFC6020] model to configure NETCONF model. That said, a YANG [RFC6020] model to configure NETCONF over
over SSH Call Home is specified in [draft-ietf-netconf-server-model] 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 7, line 48 skipping to change at page 8, line 13
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
may want to keep this information private. If this is a concern, may want to keep this information private. If this is a concern,
deployments MAY consider using instead a hash of the device's serial deployments SHOULD use an alternate unique identifier, if even just
number or an application-specified unique identifier. the hash of the device's serial number.
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
skipping to change at page 9, line 39 skipping to change at page 9, line 51
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. 04 to 05 A.1. 05 to 06
Changed title to "NETCONF Call Home using SSH"
Revised the Abstract and Introduction to better explain what the
document regards.
Changed "MUST" to "SHOULD" in the Applicability Statement.
Added a "Draft Naming" section explaining why, despite its name,
reversing SSH is nowhere in the text
Added PGP keys as another kind of SSH host key encoding identity
and signed by a trust anchor.
Revised the Device Considerations section to more clearly explain
why a device configuration data model is out of scope, and hence
an Informative reference.
Clarified Security Considerations section on use of serial
numbers.
A.2. 04 to 05
Changed "Reverse SSH" to "Call Home" Changed "Reverse SSH" to "Call Home"
Added references to Applicability Statement Added references to Applicability Statement
A.2. 03 to 04 A.3. 03 to 04
Changed title to "SSH for NETCONF Call Home" (changed again in Changed title to "Reverse SSH for NETCONF Call Home" (changed
-05) 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
skipping to change at page 10, line 17 skipping to change at page 11, line 4
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
A.3. 02 to 03 A.4. 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.4. 01 to 02 A.5. 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.5. 00 to 01 A.6. 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. 25 change blocks. 
48 lines changed or deleted 75 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/