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

"Tom.Petch" <> Thu, 13 August 2009 10:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2B7A63A6872; Thu, 13 Aug 2009 03:45:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ffXKlc6rNDlP; Thu, 13 Aug 2009 03:45:50 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 903143A67AC; Thu, 13 Aug 2009 03:45:49 -0700 (PDT)
X-Trace: 187201858/$PIPEX-ACCEPTED/pipex-customers/
X-SBRS: None
X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106
X-IP-BHB: Once
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhcFADOGg0o+vGTG/2dsb2JhbACDMGGMbsMhCYQQBYIn
X-IronPort-AV: E=Sophos;i="4.43,373,1246834800"; d="scan'208";a="187201858"
X-IP-Direction: IN
Received: from (HELO allison) ([]) by with SMTP; 13 Aug 2009 11:21:00 +0100
Message-ID: <016701ca1bf7$400ac480$0601a8c0@allison>
From: "Tom.Petch" <>
To: Stephen Hanna <>,,,
References: <>
Date: Thu, 13 Aug 2009 09:59:40 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mailman-Approved-At: Thu, 13 Aug 2009 04:15:32 -0700
Subject: Re: [secdir] secdir review of draft-ietf-netconf-partial-lock-09.txt
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: "Tom.Petch" <>
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 Aug 2009 10:45:51 -0000

----- Original Message -----
From: "Stephen Hanna" <>
To: <>; <>; <>;
Sent: Monday, August 10, 2009 4:28 PM

> 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.
As a participant in netconf, I see authorization as one of those topics
which the Working Group sees as necessary but cannot be tackled just
yet.  As RFC4741 says,
"  This document does not specify an authorization scheme, as such a
   scheme should be tied to a meta-data model or a data model."
and as yet, there is no data model; hence, no authorization, not yet,
nor, IMHO, for some time to come.  In the light of this, I am not sure
what adding a normative statement to this I-D would do; delay
publication sine die?

Tom Petch

> 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".
> _______________________________________________
> Ietf mailing list