The IESG has approved the following document: - 'Using the NETCONF Configuration Protocol over Secure Shell (SSH)' (draft-ietf-netconf-rfc4742bis-08.txt) as a Proposed Standard
This document is the product of the Network Configuration Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-netconf-rfc4742bis/ 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. _______________________________________________ IETF-Announce mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-announce
