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

Alan DeKok <aland@deployingradius.com> Fri, 11 June 2010 08:00 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 1A3AF3A69DD; Fri, 11 Jun 2010 01:00:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.11
X-Spam-Status: No, score=0.11 tagged_above=-999 required=5 tests=[AWL=0.850, BAYES_20=-0.74]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id VqbyaJ00XdbM; Fri, 11 Jun 2010 01:00:41 -0700 (PDT)
Received: from liberty.deployingradius.com (liberty.deployingradius.com []) by core3.amsl.com (Postfix) with ESMTP id 404CB3A69D5; Fri, 11 Jun 2010 01:00:41 -0700 (PDT)
Message-ID: <4C11ED2B.1070707@deployingradius.com>
Date: Fri, 11 Jun 2010 10:00:43 +0200
From: Alan DeKok <aland@deployingradius.com>
User-Agent: Thunderbird (Macintosh/20100228)
MIME-Version: 1.0
To: secdir@ietf.org, IESG IESG <iesg@ietf.org>, draft-ietf-netconf-monitoring@tools.ietf.org
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [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:00:42 -0000

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?

  A statement about privacy and security, with a reference to an
existing netconf document would be good.