Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.txt

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Wed, 06 October 2010 22:45 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
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 BB38B3A71F1 for <netconf@core3.amsl.com>; Wed, 6 Oct 2010 15:45:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.99
X-Spam-Level:
X-Spam-Status: No, score=-101.99 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 ao5J3M3S11yn for <netconf@core3.amsl.com>; Wed, 6 Oct 2010 15:45:06 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id EAEAD3A6F50 for <netconf@ietf.org>; Wed, 6 Oct 2010 15:45:05 -0700 (PDT)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 37293C0019; Thu, 7 Oct 2010 00:46:06 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id WKTtZpMeCEbU; Thu, 7 Oct 2010 00:46:05 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EF015C0008; Thu, 7 Oct 2010 00:46:04 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 2CE401515EAA; Thu, 7 Oct 2010 00:45:35 +0200 (CEST)
Date: Thu, 07 Oct 2010 00:45:35 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Ladislav Lhotka <lhotka@cesnet.cz>
Message-ID: <20101006224535.GA55303@elstar.local>
Mail-Followup-To: Ladislav Lhotka <lhotka@cesnet.cz>, "Ersue, Mehmet (NSN - DE/Munich)" <mehmet.ersue@nsn.com>, Netconf <netconf@ietf.org>
References: <CB69B162C87647AE97AB749466633F54@BertLaptop> <4C9B3E60.5030000@bwijnen.net> <80A0822C5E9A4440A5117C2F4CD36A640106532D@DEMUEXC006.nsn-intra.net> <20101003172455.GA16616@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A640106533B@DEMUEXC006.nsn-intra.net> <20101003205540.GA16936@elstar.local> <87y6abodxw.fsf@cesnet.cz> <20101006103533.GB52604@elstar.local> <1286390271.13680.12.camel@missotis>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <1286390271.13680.12.camel@missotis>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Netconf <netconf@ietf.org>
Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
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: Wed, 06 Oct 2010 22:45:07 -0000

On Wed, Oct 06, 2010 at 08:37:51PM +0200, Ladislav Lhotka wrote:
> On St, 2010-10-06 at 12:35 +0200, Juergen Schoenwaelder wrote:
> > On Wed, Oct 06, 2010 at 11:42:03AM +0200, Ladislav Lhotka wrote:
> > > On Sun, 3 Oct 2010 22:55:40 +0200, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> > > > On Sun, Oct 03, 2010 at 09:42:25PM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote:
> > > > > > > Section 9. Security Considerations
> > > > > > >
> > > > > > > I would suggest to add a few sentences for the EOM handling
> > > > > > > and the possible thread concerning section 3. It would be
> > > > > > > interesting to recommend a possible reaction if this happens
> > > > > > > frequently, e.g. to drop the NETCONF session.
> > > > > > 
> > > > > > 4741bis does not have an EOM marker - so how can we discuss it in
> > > > > > the security considerations?
> > > > > 
> > > > > EOM handling is for sure not part of NETCONF but the possible 
> > > > > thread concerning EOM handling is. I think security considerations 
> > > > > section should discuss the related security thread, as we did on 
> > > > > NETCONF ML with a long mail thread.
> > > > 
> > > > There is no EOM issue if you run NETCONF over BEEP. We should stick to
> > > > modularity and discuss things where they belong. Perhaps you want
> > > > different text than the one I currently image you want...
> > > 
> > > SSH is the *mandatory* transport, so any appearance of ']]>]]>' in the
> > > Messages, Operation or Content layer necessarily has an impact on
> > > operation and is a potential security hole. So I agree with Mehmet that
> > > 4741bis should not dismiss this issue completely. The protocol
> > > modularity has been damaged by the unfortunate EOM choice.
> > > 
> > > Apart from Security Considerations, text in Sec. 3 should be changed as
> > > follows:
> > > 
> > > OLD
> > > 
> > >   All NETCONF messages MUST be well-formed XML, encoded in UTF-8.
> > > 
> > > NEW
> > > 
> > >   All NETCONF messages MUST be well-formed XML, encoded in UTF-8, and
> > >   MUST NOT contain the character sequence ']]>]]>'.
> > 
> > Still I believe it is the transport that has to deal with this. If a
> > message contains ']]>]]>', a transport that can not handle this should
> > either not accept to transport that message or have a mechanism to
> > deal with it by quoting it or whatever. Pushing this issue up to the
> > content layer just on the ground that the mandatory SSH transport is
> > not totally robust seems odd from an architectural point of view.
> 
> OK, but according to section 2.4 the mandatory transport protocol is RFC
> 4742, which does not handle the EOM issue properly. So sec. 2.4 in fact
> says that every compliant implementation MUST have that security hole.
> 

I am willing to accept an addition to the security considerations that
says that readers should consult the security considerations of the
NETCONF transports in addition to the 4741bis security considerations
section since the 4741bis security considerations only covers the base
message layer and the base operations of NETCONF. A first quick
attempt:

	This section provides security considerations for the base
	NETCONF message layer and the base operations of the NETCONF
	protocol. Security considerations for the NETCONF transports
	are provided in the transport documents and security
	considerations for the content manipulated by NETCONF can be
	found in the document defining data models.

We could add this right at the beginning of section 9 and then it
should be clear even to the causal reader that just reading section 9
of 4741bis is not sufficient to understand all security aspects of
NETCONF.

Note that this approach allows to add/fix security problems in all our
transports without causing any text in 4741bis to become obsolete or
incomplete.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>