Subject: [Netconf] Protocol Action: 'Using the NETCONF Configuration Protocol over Secure Shell (SSH)' to Proposed Standard (draft-ietf-netconf-rfc4742bis-08.txt)

From: The IESG <[email-masked]>
Date: Fri, 25 Mar 2011 10:42:26 -0700

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.