[secdir] secdir review of draft-ietf-netconf-partial-lock-09.txt

Stephen Hanna <shanna@juniper.net> Mon, 10 August 2009 14:32 UTC

Return-Path: <shanna@juniper.net>
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 47C1A28C124; Mon, 10 Aug 2009 07:32:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id yuYtHh2wtuaB; Mon, 10 Aug 2009 07:32:24 -0700 (PDT)
Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com []) by core3.amsl.com (Postfix) with ESMTP id 4B64F3A6DA9; Mon, 10 Aug 2009 07:32:21 -0700 (PDT)
Received: from source ([]) (using TLSv1) by exprod7ob105.postini.com ([]) with SMTP ID DSNKSoAveFd+N+ZJT7bOxLIRRYIWNlqSYZq2@postini.com; Mon, 10 Aug 2009 07:32:28 PDT
Received: from p-emfe02-wf.jnpr.net ( by P-EMHUB03-HQ.jnpr.net ( with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 10 Aug 2009 07:29:26 -0700
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 10 Aug 2009 10:29:25 -0400
From: Stephen Hanna <shanna@juniper.net>
To: "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-netconf-partial-lock@tools.ietf.org" <draft-ietf-netconf-partial-lock@tools.ietf.org>
Date: Mon, 10 Aug 2009 10:28:38 -0400
Thread-Topic: secdir review of draft-ietf-netconf-partial-lock-09.txt
Thread-Index: AcoPYx3URs99g7Z4T5WHm8QuiidkTgKXveKA
Message-ID: <AC6674AB7BC78549BB231821ABF7A9AE8E775BCA45@EMBX01-WF.jnpr.net>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [secdir] secdir review of draft-ietf-netconf-partial-lock-09.txt
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: Mon, 10 Aug 2009 14:32:25 -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.

This document defines optional partial-lock and partial-unlock
operations to be added to the NETCONF protocol. These operations
are used to lock only part of a configuration datastore, allowing
multiple management sessions to modify the configuration of a
device at a single time.

The Security Considerations section of the document highlights
the risk that a malicious party might employ partial locks to
impede access to a device's configuration. Therefore, it states
"Only an authenticated and authorized user can request a partial
lock." Unfortunately, I cannot find any normative text (MUST)
that supports this statement. The NETCONF spec (RFC 4741) says
"NETCONF connections must be authenticated" but this is not
clearly normative. Perhaps a NETCONF expert can point to some
normative text requiring authentication and authorization for
any party requesting a partial lock. If not, I suggest that
such normative text be added to the partial-lock specification.

Another security concern that I have related to the partial-lock
operation is that the configuration might become inconsistent if
one manager changes one part of a datastore at the same time that
another manager changes another part. The resulting inconsistency
could have security implications. For example, an organization might
have a rule that either the firewall or the intrusion detection
features must be enabled on a device. If one manager might lock
intrusion detection configuration, check that the firewall is
enabled, and then disable intrusion detection. Another manager
might lock the firewall configuration, check that intrusion detection
is enabled, and then disable the firewall. If those operations
were interleaved, they could result in a violation of policy.
To address this concern, I suggest that the draft contain a
warning that parallel operations are tricky and should be
carefully considered. Sometimes, it may be necessary to lock
a portion of the datastore that will not be modified, just to
ensure the datastore remains consistent and compliant with policy.

Of course, a human administrator using a GUI could easily
run into this same problem if the human does not have the
ability to control configuration locks. The human might
look at the firewall configuration to make sure that it's
enabled and then switch to another section of the display
to disable the intrusion detection function. If the management
console only locks the datastore to execute the administrator's
request to disable intrusion detection, overlapping operations
from another administrator could result in a bad configuration.
This problem can arise even without the partial lock operation.
Probably the best that can be done here is to include language
warning of this sort of problem. Warning human administrators
that someone else is also editing the device should help and
giving these administrators the ability to easily communicate
with each other to coordinate their work would also probably help.

Here are a few minor issues:

* At the end of section, the comma in the last
  sentence is superfluous.

* In section in the sentence "Manager A terminates it's
  session", the apostrophe should be removed.

* In section 2.4.1, I think that the sentence that begins with
  "If someone later creates a new interface" would be clearer
  if the second comma was changed to "so".

* Later in section 2.4.1, the sentence that begins with
  "A NETCONF server MUST" should instead start with "A NETCONF
  server that supports partial locks MUST". I think that
  paragraph should end with "all of the overlapping locks are
  released" not "all of the locks are released".