[Netconf] FW: Protocol Action: 'Using the NETCONF ConfigurationProtocol over Secure Shell (SSH)' to ProposedStandard (draft-ietf-netconf-rfc4742bis-08.txt)

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Sat, 26 March 2011 17:07 UTC

Return-Path: <dromasca@avaya.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 127543A6958 for <netconf@core3.amsl.com>; Sat, 26 Mar 2011 10:07:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.1
X-Spam-Level:
X-Spam-Status: No, score=-103.1 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSx3DdJZ6c5H for <netconf@core3.amsl.com>; Sat, 26 Mar 2011 10:07:02 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 96CDC28C0F1 for <netconf@ietf.org>; Sat, 26 Mar 2011 10:07:01 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvYAAFMtcU3GmAcF/2dsb2JhbACYKo47dIhcnB0CmRaCIHkMgjwEkAw
X-IronPort-AV: E=Sophos;i="4.63,248,1299474000"; d="scan'208";a="238670690"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 26 Mar 2011 13:08:35 -0400
X-IronPort-AV: E=Sophos;i="4.63,248,1299474000"; d="scan'208";a="601020906"
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 26 Mar 2011 13:08:34 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sat, 26 Mar 2011 18:08:12 +0100
Message-ID: <EDC652A26FB23C4EB6384A4584434A0402E6FF0A@307622ANEX5.global.avaya.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Netconf] Protocol Action: 'Using the NETCONF ConfigurationProtocol over Secure Shell (SSH)' to ProposedStandard (draft-ietf-netconf-rfc4742bis-08.txt)
Thread-Index: AcvrFyc683QEVwtfRbev5jngp7a1FQAwTUqw
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: netconf <netconf@ietf.org>
Subject: [Netconf] FW: Protocol Action: 'Using the NETCONF ConfigurationProtocol over Secure Shell (SSH)' to ProposedStandard (draft-ietf-netconf-rfc4742bis-08.txt)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 26 Mar 2011 17:07:04 -0000

 
Hi, 

Thanks and Congratulations to the editors, contributors, chairs and the
whole WG for achieving this target. 

Regards,

Dan 

-----Original Message-----
From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On
Behalf Of The IESG
Sent: Friday, March 25, 2011 7:42 PM
To: IETF-Announce
Cc: Internet Architecture Board; netconf mailing list; netconf chair;
RFC Editor
Subject: [Netconf] Protocol Action: 'Using the NETCONF
ConfigurationProtocol over Secure Shell (SSH)' to ProposedStandard
(draft-ietf-netconf-rfc4742bis-08.txt)

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.
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf