Technical Summary
This document describes a method for invoking and running
the NETCONF protocol within a Secure Shell (SSH) session
as an SSH subsystem.
Working Group Summary
This document has been longly discussed in the Working Group, including
several WG Last Calls. The comments and reviews helped to improve the
document a lot and the current version reflects the consensus of the WG.
The document incorporates all accepted errata against RFC4742. After a
long debate the WG decided to have the way a NETCONF Server extracts
the SSH user name from the SSH layer as implementation-dependent.
There was a long discussion on the handling of the EOM character sequence.
As the workgroup had only a mandate for bug fixing the workgroup first
agreed to keep using the EOM sequence to avoid incompatibility with existing
implementations. After the discussion on this issue in IETF #79 a few WG
members proposed to figure out if a proper framing solution can be found
now, while being backwards compatible with the rfc4742.
The old EOM framing has been seen as not secure enough:
- RFC4742 assumes that the EOM sequence, ]]>]]>, cannot appear in any
well-formed XML document, which turned out to be mistaken.
- The EOM sequence can cause operational problems and open space for
attacks if sent deliberately in RPC messages.
NETCONF co-chairs agreed to consider a solution only if there is a real WG
consensus (i.e. near 100%) on such a change. First a possible solution has
been discussed in a small team, which included most of the implementers
for NETCONF-related tools and protocol code. The solution proposes to
encode all NETCONF messages with a chunked framing (similar but not equal
to HTTP chunked framing). The document still uses the EOM sequence for the
initial <hello> message to avoid incompatibility with existing implementations.
NETCONF co-chairs asked the AD to hold the documents for 4741bis and
4742bis for a short period of time and the result of the discussion in the small
team has been sent to the WG for consensus.
Some of the discussion points were:
- The proposal makes it a little bit harder to do just an SSH-session and then do
cut-and-paste input. The implementers believe that the proposed solution for
proper/decent framing is acceptable and that most implementation can/will
provide a simple scripting front-end to allow for some form of cut-and-paste.
- It came out that less experienced implementers find it as helpful to see the
"invisible LineFeed" in the examples. The WG concluded that '\n' is the most
common character for this purpose. One WG member though was against '\n'
and wanted to use '}', which has been noted.
- One WG member didn't want to stick the usage of the Chunked Framing
Mechanism to capability "base:1.1" only and wanted rather to state ":base:1.1
or later". The WG concluded that we should stick to "base:1.1" and extend it
with a new version, which most likely will introduce other changes.
The changes have been accepted by the WG with some additional discussion
and bug fixing. As the result of the WG discussion the WG co-chairs concluded
near FULL consensus on the proposed edits and started a WGLC. The WGLC
did raise only minor issues. After a short discussion in a small team including
the WG co-chairs, the editor of 4742bis Margaret Wasserman, editors of 4741bis
Martin Bjorklund, Andy Bierman and Juergen Schoenwaelder the document
shepherd sent the collected bug fixing and change requests to NETCONF ML
and announced it as the result of the WG last call.
Document Quality
Since SSH is mandatory transport for NETCONF there are numerous
implementations of RFC 4742. It is expected that existing implementations
will be updated based on the 4742bis document once it gets published as
proposed standard.
Personnel
Mehmet Ersue is the Document Shepherd for this document. Dan
Romascanu is the Responsible Area Director.
RFC Editor Note
Please make the following changes:
1. Please reinstate Appendix A from version 07 (accidentally dropped)
Appendix A. Changes from RFC 4742
This section lists major changes between this document and RFC 4742.
o Introduced the new Chunked Framing Mechanism to solve known
security issues with the EOM framing.
o Extended text in Security Considerations, added text on EOM
issues.
o Added examples to show new chunked encoding properly, highlighted
the location of new lines.
o Added text for NETCONF username handling following the requirements on
usernames in [I-D.ietf-netconf-4741bis].
o Changed use of the terms client/server, manager/agent to SSH
client/server and NETCONF client/server.
o Consistently used the term operation, instead of command or
message.
o Integrated previously-approved errata from
http://rfc-editor.org/errata_search.php?rfc=4742
2. in Section 3.1.
OLD (v08):
As specified in [I-D.ietf-netconf-4741bis] the NETCONF server MUST
indicate its capabilities by sending an XML document containing a
<hello> element as soon as the NETCONF session is established. The
NETCONF client can parse this message to determine which NETCONF
capabilities are supported by the NETCONF server.
As [I-D.ietf-netconf-4741bis] states the NETCONF client must also
send an XML document containing a <hello> element to indicate the
NETCONF client's capabilities to the NETCONF server. The document
containing the <hello> element MUST be the first XML document that
the NETCONF client sends after the NETCONF session is established.
NEW:
As specified in [I-D.ietf-netconf-4741bis] the NETCONF server indicates its
capabilities by sending an XML document containing a <hello> element as
soon as the NETCONF session is established. The NETCONF client can parse
this message to determine which NETCONF capabilities are supported by the
NETCONF server.
As [I-D.ietf-netconf-4741bis] further specifies, the NETCONF client also
sends an XML document containing a <hello> element to indicate the NETCONF
client's capabilities to the NETCONF server. The document containing the
<hello> element is the first XML document that the NETCONF client sends
after the NETCONF session is established.