Subject: Re: [Netconf] DISCUSS: draft-ietf-netconf-partial-lock

From: Balazs Lengyel <[email-masked]>
Date: Wed, 05 Aug 2009 13:54:07 +0200

Hello Adrian,
Thanks for the comments. See my answers below!
regards Balazs

Adrian Farrel wrote:
> Discuss:
> 
> If I read it right, in 2.4.1 where you have...
>    A partial lock operation MUST fail if:
> 
>    o  Any NETCONF session (including the current session) owns the
>       global lock on any target datastore.
> ...you are saying that if I want to drop down from the global lock to
> a partial lock, I must first unlock everything and then take up the
> partial lock. Of course, this opens up a small window, so the 
> application is encouraged (in order to not open the window) to retain
> the global lock longer than needed. Did you consider letting a session
> take up a partial lock and then release the global lock (in exactly the
> way overlapping partial locks are allowed at the same time - since the
> global lock is only a special case of a partial lock!)
> 
> Ditto the reverse case. That is, why can't a session holding a partial
> lock increase this to the global lock without first releaseing the 
> partial lock (and opening a window). This is less of an issue because
> the session could grab a second, overlapping partial lock that includes
> every node. That might be messy, but achieves the desired function.

BALAZS: The exact same question was debated in the WG with the conclusion:
- For compatibility reasons don't change how the (global) lock works in rfc4741. There it says:
"An attempt to lock the configuration MUST fail if an existing
  session or other entity holds a lock on any portion of the lock
target."
This means going from a partial to a global lock is not allowed without releasing the partial lock.

- Don't allow a session to hold both a partial and global lock at the same time. There is no 
real need and this method makes implementation more simple. If we don't allow partial lock and 
later the global lock(see above), allowing global and afterwards a partial lock would be confusing.
The correct procedure should be that the user starts with partial locking immediately, in 
extreme with a partial lock that covers the entire datastore. This way he can reduce the scope 
of partial locking without any unlocked interval.
-

> 
> ===
> 
> I think that the XML examples in 2.4.1.1 etc., schema in Appendix A,
> and YANG in Appendix B qualify for code license statements.

BALAZS: See separate mail. I will follow the correct procedure.

> 
> ===
> 
> I'm sure security has been extensively debated in the context of
> RFC 4741 and I don't want to rehash any debates. 
> 
> I wondered whether (2.4.1.1)...
> 
>    Negative Response:
> 
>    If a lock is already held by another session on any node within the
>    subtrees to be locked, the <error-tag> element is 'lock-denied' and
>    the <error-info> element includes the <session-id> of the lock owner.
> 
> ...was potentially giving out more information than necesary/desirbale.
> Probably you need to state that the filter (2.4.1.1)...
> 
>    If access control denies the partial lock, the <error-tag> is
>    'access-denied'.
> 
> ...and (3.)...
> 
>       Only an authenticated and authorized user can request a partial
>       lock.

BALAZS: It is a property of the NETCONF protocol, that only authenticated users can request any 
operation. So IMO we don't have to deal with the issue here. From rfc4741:
"NETCONF connections must provide authentication..."

> 
> ...SHOULD be evaluated first. Otherwise, an unauthrised user can easily
> determine the identities of the authorised users. In 2.4.1.1 this will
> need reordering of the text as well as the "SHOULD" statement.

BALAZS: The rpc-reply only gives back the sessionId of the locking user not the userId. I don't 
see much risk associated with the sessionId. At most the attacker may determine the number of 
live Netconf sessions, but that can be inferred from the number of TCP connections to the 
dedicated NETCONF port(s) as well.

BALAZS: checking access control before checking for conflicting locks seems to be a good idea. 
I will add the text :
"Access control SHOULD be checked before checking for conflicting locks to avoid giving out 
information about other sessions to an unauthorized client."

> 
> It also seemed to me that (3.) ...
> 
>    A lock that is hung for some reason (e.g., a broken TCP connection
>    that the server has not yet recognised) can be released using another
>    NETCONF session by explicitly killing the session owning that lock
>    using the <kill-session> operation.
> 
> ...seemed quite an amusing attack. But I presume that the session 
> issuing the <kill-session> is suitably qualified.

BALAZS: Yes, from NETCONF rfc4741:
"NETCONF connections must provide authentication..."
"Implementors SHOULD provide a comprehensive authorization scheme with NETCONF."
Anyway this has not been changed compared to rfc4741.

> 
> ===
> 
> 2.4.2.  <partial-unlock>
> 
>    The operation unlocks the parts of the datastores that were
>    previously locked using <partial-lock> during the same session.
> 
> This is not true in the case of overlapping partial locks as previously 
> described. Just need to tweak the text a little.

BALAZS: OK. Added: "The operation unlocks the parts that are covered by the lock identified by 
the lock-id parameter."

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

---

From: WashamFan <[email-masked]>
Date: Fri, 07 Aug 2009 14:14:16 +0800

>  of partial locking without any unlocked interval.

A partial lock covering the entire datastore can be treated as a global lock
allowing overlapping locks. Can I understand in this way?

washam