[Netconf] Netconf-partial-lock comment/discuss

[Balazs Lengyel <balazs.lengyel at ericsson.com>]

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: Balazs.Lengyel at ericsson.com