Re: [Netconf] WG Last Call for draft-ietf-netconf-access-control-04.txt

["Bert (IETF) Wijnen" <[e-mail]>]

I did review this document

Here are my comments/questions:

- replace references to rfc4741bis with references to rfc6241.
- replace references to rfc4742bis with references to rfc6242.
- Sect 2.
    Remove editors note or make some real text out of it.
-Sect 2.4.3, page 9
    [Editor's note: ditto for "replace" (and copy-config...)  Note that
    with this rule, a client w/o read access can guess db content by
    sending merge requests - if access-denied is not returned, it means
    the db has that value.]

   So the info about replace and copy-config is text that I would make
   part of the text here.

   The latter part (about guessing without having read access) should go in
   (maybe already is) in the Security Considerations section.
   But I wonder then, why would we not require read access for these
   cases? If we do, then the guessing can be controlled, no?

- at the end of sect 2,7:
      Existing mechanisms can be used to identify the subtree(s) for this purpose.
   May I ask "which existing mechanisms" ??

- section 2.8
   I wonder if the title "Identifying Security Holes" and phrases like "..security
   holes introduced by a new YANG module." are the proper language.
   I guess we mean something aka "security sensitive objects" or some
   such ?? no? I suspect "security holes" may trigger the wrong reactions
   from security folk who will review our document.
   We want to "protect (by default)" such "security sensitive objects"
   instead of we want to "close security holes".

   I think I would state in this sec 2.8, that the "extension secure" is
   defined in the YANG module to address this.

- second bullet on page 17:
       If the configuration datastore or conceptual state data is
       accessed by the protocol operation, then the data node access MUST
       be authorized.  If the session is authorized to perform the
       requested operation on the requested data, then processing
       continues.
   "then the data node access MUST be authorized" ??
   Do you mean "then the session MUST have authorization to read the data node" ?
   or maybe "then access to the data node MUST be authorized"?

- at the end of sect 3.1.3 (page 17)
    should thee not be a bullet that the data nodes present in the notification
    must be checked to make sure that the subscriber has read access?
    Mmm, not sure. From pge 27 I get the impression that if an event-type
    is authorized then automagically also all included data is accessible?
    I guess this change in thinking was made without me noticing?
    Can you explain why that works?

- section 3.2.4
      The same access permissions MUST stay in effect for the processing of
      a particular message.
   I think you mean "a whole" or "a single" message or "a complete".
   That is not very clear from the term "particular message". But it may be my
   non-native Englisg that causes just confusion with me

- sect 3.2.4
     The server MUST use the access control rules in effect at the time
      the message is processed.
   Would it be clearer (assuming that is what you intend) to say:
     The server MUST use the access control rules in effect at the time
     it starts processing the message.
   It may be just me who find that clearer.

- sect 3.3.1
      Upon the very first start-up of the NETCONF server, the access
      control configuration will probably not be present.  If it isn't, a
      server MUST NOT allow any write access to any session role except a
      "recovery session", if supported.

   So if a "recovery session" is not supported, must a server than allow access
   or not? And if yes, what kind of access to whom? Would be a big security
   issue, no?

- page 23:
       7.   For each rule-list entry found, process all rules, in order,
   What is "in order".
   I guess I am also somehwat confused by the YANG module stating:
      list rule-list {
        key "name";
        ordered-by user;
   Maybe I am not fully getting the structure here.

- Same question on "in order" on page 24, point 6.

- Same for point 6 on page 27.

- Page 27
       2.   If the session is identified as a "recovery session", then the
            notification is permitted.
   I wonder if (in recovery mode or recover session) you need to be able to
   receive notifications??? I can live with it... but if the purpose is really
   recovery, then maybe we should provide this functionality in recovery mode?


Consistency and clarfying questions/related remarks:

- The concept of a "recovery session" is mentioned a few times and it is stated
    that it is outside the scope of this document. I suppose that also means that it
    is "implementation dependent" or "an implementation matter". I think it would be
    good to state so explicitly, otherwise I suspect we may get questions
    if/how/where/when it is defined/specified.

- this document speaks about "NETCONF datastore". I believe that rfc6241 speaks about
   just "datastore" in a few places and mostly speaks about "configuration datastore".
   Should we be consistent and use "configuration datastore"?
   Or is there special meaning for "NETCONF datastore"??

- it seems to me that figure 2 uses different terminology than figure 1.
    fig 1 speaks about an acc ctl point for "operations" while figure 2 seems to
    identify that control point with "rpc access control".
   I suggest to take a close look at both figures and try to use as much as
   possible consistent terminology.
   Same for page 16 and subsequent pages. "RPC operation" is a term we did
   away with a while ago I believe.
   Also check sect 3.3.4 for consistency in terminology and names of acc ctl points

- section 3.2.4
    speaks about "server data".
    Is that the "conceptual configuration data store" or what?
    I prefer we use terms that we already have. If we must use the term "server data",
    then pls define it in the terminology section

- page 28
     leaf <denied-rpcs>
   would a better name not be:
    leaf <denied-operations>


Bert (speaking as a technical contributor)