Subject: [Netconf] Netconf-partial-lock comment/discuss

From: Balazs Lengyel <[email-masked]>
Date: Mon, 19 Oct 2009 14:45:46 +0200

Hello Tim,
In the tracker https://datatracker.ietf.org/idtracker/ballot/3035 about the 
draft-ietf-netconf-partial-lock-09 you have the comment:

Discuss [2009-08-13]:
[revised discuss: I now agree that 4741 is not updated by this spec.]

The following two issues (initially raised in Steve Hanna's late secdir review
posted Monday
August 11, see the email for the gory details) are also blocking:

(1) The document assumes an access control mechanism is in place, but does not
actually
impose this as a requirement.  I would like to see this language
strengthened, since I do
not see reasonable deployment scenarios that leverage
partial locking and do not require
access control.  That is, if partial lock is
supported an appropriate access control mechanism
MUST also be in place.

----
ANSWER: Updated text in 2.4.1 to indicate authentication is MANDATORY and access control (if 
implemented) must be also passed. Access control is not standardized for NETCONF so we cant 
make it mandatory, however it is strongly recommended (In the security section). If access 
control is implemented by the Netconf server, partial-lock must be subject to it. Today 
practically all implementations implement access control even if in a proprietary way, so the 
situation is quite good. Updated security section to indicate this. Excerpts from the already 
stored -10 draft:
2.4.1
"   A partial lock operation MUST fail if:

    o  The requesting user is not successfully authenticated.

    o  The NETCONF server implements access control, and the locking user
       does not have sufficient access rights.  The exact handling of
       access rights is outside the scope of this document, but it is
       assumed that there is an access control system that MAY deny or
       allow the partial lock operation.
"

3.  Security Considerations

"  The same considerations are relevant as for the base NETCONF Protocol
    [NETCONF]. <partial-lock> and <partial-unlock> RPCs MUST only be
    allowed for an authenticated user. <partial-lock> and <partial-
    unlock> RPCs SHOULD only be allowed for an authorized user.  However
    as NETCONF access control is not standardized and not a mandatory
    part of a NETCONF implementation, it is strongly recommended, but
    OPTIONAL (although nearly all implementations include some kind of
    access control).

    A lock (either a partial lock or a global lock) might prevent other
    users from configuring the system.  The following mechanisms are in
    place to prevent the misuse of this possibility:

       A user, that is not successfully authenticated, MUST NOT be
       granted a partial lock.

       Only an authorized user SHOULD be able to request a partial lock.

       ...
"
----

Discuss:
(2) The complexities of specifying the scope for related operations should be
highlighted,
along with the consequences of incorrect scoping.
(Steve's review
includes a specific example of the results when the scope is specified without
considering related operations.)

I would also recommend adding a pointer in the security considerations to
section 2.1.1.3, where
the dangers of multiple managers in a semi-coordinated
mode are detailed.  The results are
sufficiently bad to merit a reminder in the

----
ANSWER: The complexities of specifying the scope and some related issues are pointed out in 2.4.1
"
    o  If part of the running datastore is locked, this has no effect on
       any unlocked parts of the datastore.  If this is a problem (e.g.,
       changes depend on data values or nodes outside the protected part
       of the datastore), these nodes SHOULD be included in the protected
       area of the lock.

    o  Configuration data can be edited both inside and outside the
       protected area of a lock.  It is the responsibility of the NETCONF
       client application to lock all relevant parts of the datastore
       that are crucial for a specific management action.
"

Due to other comments the possibility of locking the candidate database have been removed and 
with that the whole use case (and the chapter 2.1.1.3).
----

Comment [2009-08-13]:
Steve's review included a number of editorial comments the authors may wish to
consider.

----
ANSWER: Comments accepted, document updated. See the already stored -10 draft for details.
----

Please indicate if you can accept these answers!

regards Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320                  email: [email-masked]

---

From: "Polk, William T." <[email-masked]>
Date: Mon, 19 Oct 2009 10:12:45 -0400

Hi Balazs,

Looks great!  I have cleared.

Thnaks,

Tim

On 10/19/09 8:45 AM, "Balazs Lengyel" <[email-masked]> wrote:

Hello Tim,

Discuss [2009-08-13]:

----

       ...
"
----

Discuss:

----

Comment [2009-08-13]:

----

regards Balazs

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Mon, 19 Oct 2009 16:32:07 +0200

Thanks TIm,

Bert Wijnen
Document shepherd