Re: [secdir] secdir review of draft-ietf-netconf-monitoring

Martin Bjorklund <mbj@tail-f.com> Fri, 11 June 2010 08:19 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F6AA28C136; Fri, 11 Jun 2010 01:19:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.09
X-Spam-Level:
X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_50=0.001, HELO_MISMATCH_COM=0.553]
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 PhXacRTT068k; Fri, 11 Jun 2010 01:19:44 -0700 (PDT)
Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 8A89F3A677D; Fri, 11 Jun 2010 01:19:44 -0700 (PDT)
Received: from localhost (c213-100-166-156.swipnet.se [213.100.166.156]) by mail.tail-f.com (Postfix) with ESMTPSA id 607DA616002; Fri, 11 Jun 2010 10:19:45 +0200 (CEST)
Date: Fri, 11 Jun 2010 10:19:49 +0200
Message-Id: <20100611.101949.192441308.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <20100611080956.GA5257@elstar.local>
References: <4C11ED2B.1070707@deployingradius.com> <20100611080956.GA5257@elstar.local>
X-Mailer: Mew version 7.0.50 on Emacs 22.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 14 Jun 2010 08:03:01 -0700
Cc: draft-ietf-netconf-monitoring@tools.ietf.org, secdir@ietf.org, iesg@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-netconf-monitoring
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Jun 2010 08:19:45 -0000

Hi,

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> On Fri, Jun 11, 2010 at 10:00:43AM +0200, Alan DeKok wrote:
> > I have reviewed this document as part of the security directorate's
> > ongoing effort to review all IETF documents being processed by the
> > IESG.  These comments were written primarily for the benefit of the
> > security area directors.  Document editors and WG chairs should treat
> > these comments just like any other last call comments.
> > 
> > The document defines a data model for netconf monitoring.  The security
> > considerations section says in part:
> > 
> >    Some of the readable data nodes in this YANG module may be
> >    considered sensitive or vulnerable in some network environments.
> >    It is thus important to control read access (e.g. via get,
> >    get-config or notification) to these data nodes.
> > 
> > What is unclear from the document is whether or not the data is secure
> > *after* access is gained.  i.e. is there a secure transport layer?
> > Should one be used?  If not, why?
> 
> NETCONF runs over SSH or TLS or TLS/BEEP or SOAP/HTTPS. In other
> words, all existing NETCONF transports are "secure". The revision of
> the NETCONF specification being worked on is going to make this
> hopefully clearer by calling the transport layer "secure transports".
> 
> There has been progress very recently on formulating a security
> considerations template for documents that contain NETCONF/YANG data
> models and I think it would be good if this document would indeed
> follow these guidelines.

Actually, this document follows the latest security considerations
template.

However, the template does not mention that NETCONF runs over a secure
transport.  Maybe the template (and this document) should be updated
to make this clear?


/martin