Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change

[Ladislav Lhotka <[e-mail]>]

On Mon, 2017-11-27 at 08:26 -0800, Andy Bierman wrote:
> 
> 
> On Mon, Nov 27, 2017 at 7:44 AM, Robert Wilton <[e-mail]> wrote:
> > 
> > On 27/11/2017 15:12, Andy Bierman wrote:
> > > 
> > > On Mon, Nov 27, 2017 at 2:39 AM, Robert Wilton <[e-mail]> wrote:
> > > > I do get the point that Tom is making here, and have quite a lot of
> > > > sympathy for it.  E.g. by automatically allowing the side effects of
> > > > when/choice statements then we are introducing a potential security hole
> > > > here that operators may find hard to be aware of and mitigate.
> > > > It also seems odd to me that a client is allowed to implicitly remove
> > > > some configuration through the side effect of a when/choice statement
> > > > that they are not allowed to delete explicitly.
> > > > The alternative of requiring appropriate access for the side-effects,
> > > > seems like an intuitively safer design, but I also get Andy's concern
> > > > that security isn't useful if it become so unwieldy that nobody uses it.
> > > > So, I guess the question here is, do we have some concrete examples
> > > > using real data models where the extra NACM delete rules would be
> > > > required?  If not then perhaps requiring the explicit access for side
> > > > effects would be better.
> > > > 
> > > 
> > > 
> > > Yes -- please provide some examples where it is better to force the
> > > operator
> > > to provide extra "delete" rules to allow false-when data nodes to be
> > > deleted.
> >  
> > > It seems to me that these rules would allow individual data structures to
> > > be
> > > removed by the client, that would not otherwise be possible.
> >  Yes, this is true.
> > 
> > But it is still odd that they a client is allowed to delete the
> > configuration, just not explicitly.  I.e. it is strange that they     are
> > not allowed to put in a semantically equivalent request that explicitly
> > deletes the configuration, they are only allowed to do it if the delete is
> > implicit.  This seems inconsistent.
> > 
> > 
> 
> It is just as odd that a request  to create /foo/case1 will work if nothing
> from
> the choice-stmt exists, but will fail if /foo/case2 has to be deleted in order
> to create /foo/case1.

Why is this odd? RFC 7950 says:

   The "choice" statement defines a set of alternatives, only one of
   which may be present in any one data tree.

So it is quite clear that adding /foo/case1 makes the data tree invalid if
/foo/case2 exists.

> 
> 
> > > If 3 data structures need to be in place "when /foo exists" then
> > > deleting 1 or 2 of them directly may not be desirable.  Deleting
> > > them all together (i.e., via when-false deletion) may be the intended
> > > usage.
> >  If there is a dependency that all three exist then that may be better
> > expressed with a must statement instead.
> > 
> > > The vendor and operator need to be aware of the data model dependencies.
> > > That said, how come CLI-based configuration does not have this problem?
> >  My experience of CLI based configurations do have these sorts of problems,
> > and many more :-)
> > 
> > 
> > > (Or rather, why has this problem been ignored for so long? Maybe it not
> > > that real?)
> >  This may be the real crux of the argument:
> > 
> > It probably doesn't make sense to use when statements on disjoint parts of
> > the YANG schema (e.g. it does not make sense for the OSPF YANG model to
> > depend on whether an interface it runs over has an IP address configured). 
> > Instead, a more normal usage would be a flag (e.g. like interface type) to
> > allow/prevent certain child nodes from being available.  In these scenarios,
> > if a user is allowed to change the type of an interface then they are most
> > likely allowed to change the other settings on the interface as well.
> > 
> > So for 'normal' when statements, it probably doesn't make much difference
> > whether or not explicit NACM access is required to the nodes being
> > implicitly deleted because the client probably already has the necessary
> > access rights.
> > 
> > But for the 'corner case' when statement scenario, that are unlikely to be
> > used, it still seems safer to require explicit access permissions than
> > implicitly accepting the side effect with no NACM validation.
> > 
> 
> 
> This is fine, except there is no way to tell a normal when from a corner-case
> when.
> 
> In all cases, the false-when evaluation means the node is not relevant to the
> model anymore.

The client that causes the when expression to become invalid may not be entitled
to decide whether the node is relevant or not.


> Same for a case that is being replaced by a different case.
> In order for this NACM threat to be real. the YANG modeler needs to be wrong
> about
> whether the false-when states are actually irrelevant to the model in its new
> state.

The YANG modeller may be absolutely correct but other modules (out of his
control) may change this.

Lada


> 
> 
> > Thanks,
> > Rob
> > 
> 
> 
> Andy
>  
> > 
> > > > Thanks,
> > > > Rob
> > > > 
> > > 
> > > Andy
> > >  
> > > > On 25/11/2017 15:53, Andy Bierman wrote:
> > > > > 
> > > > > On Sat, Nov 25, 2017 at 4:42 AM, t.petch <[e-mail]> wrote:
> > > > > > ----- Original Message -----
> > > > > > From: "Andy Bierman" <[e-mail]>
> > > > > > To: "t.petch" <[e-mail]>
> > > > > > 
> > > > > > 
> > > > > > > On Fri, Nov 24, 2017 at 3:02 AM, t.petch <[e-mail]>
> > > > > > wrote:
> > > > > > >
> > > > > > > > <inline>
> > > > > > > >
> > > > > > > > Tom Petch
> > > > > > > >
> > > > > > > > ----- Original Message -----
> > > > > > > > From: "Robert Wilton" <[e-mail]>
> > > > > > > > Sent: Thursday, November 23, 2017 10:44 AM
> > > > > > > >
> > > > > > > > > Hi Andy,
> > > > > > > > >
> > > > > > > > > On 22/11/2017 18:09, Andy Bierman wrote:
> > > > > > > > > > On Wed, Nov 22, 2017 at 5:41 AM, Benoit Claise wrote:
> > > > > > > > > >
> > > > > > > > > >     Hi Rob,
> > > > > > > > > >
> > > > > > > > > >     At that points in time, if it clarifies the spec. and
> > > > > > the
> > > > > > > > authors
> > > > > > > > > >     agree with this, let's do the right thing.
> > > > > > > > > >
> > > > > > > > > > I will add the new text if that is what the WG wants.
> > > > > > > >
> > > > > > > > > Having read this draft, I was undecided what the intended
> > > > > > behavior
> > > > > > > > > actually should be.
> > > > > > > > >
> > > > > > > > > The way that Yumapro and Tail-f have implemented this is
> > > > > > reasonable,
> > > > > > > > and
> > > > > > > > > is probably also the way that I would implemented it.
> > > > > > > > >
> > > > > > > > > But I also think that it would be a reasonable implementation
> > > > > > for
> > > > > > a
> > > > > > > > > server to calculate the full change set (taking account of
> > > > > > side
> > > > > > > > effects
> > > > > > > > > from when and choice statements) to the datastore before
> > > > > > checking
> > > > > > the
> > > > > > > > > "write data node access control" against the resultant change
> > > > > > set.
> > > > > > > > >
> > > > > > > > > My interpretation is that the RFC text is ambiguous on what
> > > > > > the
> > > > > > > > correct
> > > > > > > > > behavior is, and one could make a reasonable argument that the
> > > > > > current
> > > > > > > > > RFC actually specifies that the alternative behavior is
> > > > > > correct,
> > > > > > i.e.
> > > > > > > > > requiring delete access even if a node is implicitly changes
> > > > > > as a
> > > > > > side
> > > > > > > > > effect. E.g. section 3.2.3 of RFC 6536 states:
> > > > > > > > >
> > > > > > > > >     If the protocol operation would result in the deletion of
> > > > > > a
> > > > > > > > datastore
> > > > > > > > >     node and the user does not have "delete" access permission
> > > > > > for
> > > > > > > > that
> > > > > > > > >     node, the protocol operation is rejected with an
> > > > > > "access-denied"
> > > > > > > > >     error.
> > > > > > > >
> > > > > > > > Rob
> > > > > > > >
> > > > > > > > I have been reading that paragraph since this thread started and
> > > > > > > > wondering how it could be thought unclear, what am I missing:-)
> > > > > > > >
> > > > > > > > To me it clearly states that the user must have the appropriate
> > > > > > access
> > > > > > > > for the consequences of whatever they do, be that 'when',
> > > > > > 'choice'
> > > > > > or
> > > > > > > > anything else! Indeed, I see exactly that behaviour in
> > > > > > operational
> > > > > > > > (non-network) databases of which I am a user with limited
> > > > > > privileges.
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > This is not correct.
> > > > > > > The server is the entity that is cleaning up false when-stmt or
> > > > > > unselected
> > > > > > > cases
> > > > > > > for a choice-stmt.
> > > > > > >
> > > > > > > NACM does not prevent the sever from making any changes to the
> > > > > > system.
> > > > > > > It only affects the operations requested by a client.
> > > > > > 
> > > > > > Andy
> > > > > > 
> > > > > > My model is slightly different, that the server is a black box, with
> > > > > > an
> > > > > > interface through which I can make authorised changes.  If something
> > > > > > I
> > > > > > do causes the deletion of something I am not allowed to delete, may
> > > > > > be
> > > > > > not even to read, well, we part company on the acceptability of
> > > > > > that!
> > > > > > 
> > > > > > I do accept, as Randy points out, that the situation is
> > > > > > complicated.  I
> > > > > > am reminded of the issues that came up relating to the 'when'
> > > > > > statement
> > > > > > when preparing YANG 1.1.  Yes, 'when' makes things possible and is
> > > > > > very
> > > > > > useful but at the same time, its side effects can be troublesome.  I
> > > > > > would like to wrap it up in a conceptual bubble so you could not
> > > > > > have
> > > > > > the sort of fine-grained access control that allows the case that
> > > > > > Rob
> > > > > > postulates to occur but have no idea what that might look like.  And
> > > > > > I
> > > > > > don't know how much 'when' is used in that way in existing YANG
> > > > > > modules - uh huh, more reading required.
> > > > > > 
> > > > > 
> > > > > 
> > > > > When the access control is too complicated, it does not get used.
> > > > > Instead, the most likely access control is "everybody is the root
> > > > > user".
> > > > > The server pruning of false when/choice data nodes is considered
> > > > > cleanup.
> > > > > The pruned data is no longer relevant to the data model. This is the
> > > > > indended
> > > > > use, but when-stmt can easily be abused.
> > > > > 
> > > > > The complex tangled web of dependencies is no worse
> > > > > than it has been with CLI for 30 years, where every dependency is ad-
> > > > > hoc
> > > > > and probably undocumented. The granularity of CLI-based access control
> > > > > is less granular than NACM.
> > > > > 
> > > > > It is possible that vendors and operators are willing to spend hours
> > > > > and days
> > > > > figuring out how to tune the NACM rules to allow a specific edit to
> > > > > work.
> > > > > Of course the operator will not even be told by the server which nodes
> > > > > are blocking the edit. That would be a security risk.
> > > > > 
> > > > > IMO NACM will be completely unusable if rules are needed to allow
> > > > > server cleanup of dead nodes.  The additional NACM rules required
> > > > > might provide more access than intended (unless lots of delete-only
> > > > > rules are added). The huge jump in NACM rule management complexity is
> > > > > a new security vulnerability, which might even be worse than the
> > > > > vulnerability it is intended to fix.
> > > > > 
> > > > > 
> > > > > > Tom Petch
> > > > > > 
> > > > > > >
> > > > > > > Andy
> > > > > > >
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > 
> > > > > Andy
> > > > > 
> > > > >  
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > > My other thought was that given all the complexities of 'when'
> > > > > > that
> > > > > > > > emerged during the specification of YANG 1.1, perhaps, were I an
> > > > > > > > implementor of this, I would take the easy option and ignore the
> > > > > > side
> > > > > > > > effects of 'when'; but I might feel guilty about doing so.
> > > > > > > >
> > > > > > > > If the new paragraphs go in as proposed, then I think that the
> > > > > > two
> > > > > > > > paragraphs you quote need changing else that section looks to me
> > > > > > like an
> > > > > > > > oxymoron.
> > > > > > > >
> > > > > > > > Tom Petch
> > > > > > > >
> > > > > > > > > An <edit-data> request that causes a when constraint to
> > > > > > evaluate
> > > > > > > > > differently does result in a deletion of those data nodes from
> > > > > > the
> > > > > > > > > datastore, and hence according to the text above, requires
> > > > > > explicit
> > > > > > > > > "delete" access permission to accomplish that.
> > > > > > > > >
> > > > > > > > > Clearly it would be an interop issue if different servers
> > > > > > implemented
> > > > > > > > > the NACM path based filtering differently.
> > > > > > > > >
> > > > > > > > > Hence why I think that it would be prudent for the draft to be
> > > > > > more
> > > > > > > > > explicit on when and choice statement handling.
> > > > > > > > >
> > > > > > > > > Rob
> > > > > > > > >
> > > > > > > > > > There have not been any comments on this issue.
> > > > > > > > > >
> > > > > > > > > > Andy
> > > > > > > > > >
> > > > > > > > > >     Regards, Benoit.
> > > > > > > > > >>
> > > > > > > > > >>     Hi Benoit,
> > > > > > > > > >>
> > > > > > > > > >>     There is also one further, unrelated change that I am
> > > > > > proposing
> > > > > > > > > >>     is made the draft before it is published, to help
> > > > > > better
> > > > > > > > clarify
> > > > > > > > > >>     the expected behavior. It isn't the end of the world if
> > > > > > this
> > > > > > > > > >>     doesn't go in, but I think that it prevents sometime
> > > > > > taking
> > > > > > a
> > > > > > > > > >>     different, but IMO reasonable, interpretation of how
> > > > > > "when"
> > > > > > > > > >>     statements are considered, and then having a future
> > > > > > argument
> > > > > > > > > >>     about what behavior it specified in the standard.
> > > > > > > > > >>
> > > > > > > > > >>     If we clarify it now, then it closes that door :-)
> > > > > > > > > >>
> > > > > > > > > >>     I've proposed text to Andy and Martin on Monday, but
> > > > > > I've
> > > > > > not
> > > > > > > > > >>     heard back yet.
> > > > > > > > > >>
> > > > > > > > > >>     Netconf email with proposed text attached. The text
> > > > > > doesn't
> > > > > > > > > >>     necessarily have to match this, but personally I think
> > > > > > that
> > > > > > it
> > > > > > > > is
> > > > > > > > > >>     useful if the draft says something on this.
> > > > > > > > > >>
> > > > > > > > > >>     Thanks,
> > > > > > > > > >>     Rob
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >>     On 22/11/2017 13:25, Benoit Claise wrote:
> > > > > > > > > >>>     On 11/10/2017 7:23 PM, Andy Bierman wrote:
> > > > > > > > > >>>>     Hi,
> > > > > > > > > >>>>
> > > > > > > > > >>>>     Here are some proposed edits to make the data rule
> > > > > > consistent
> > > > > > > > > >>>>     with the examples.
> > > > > > > > > >>>>     Note that this issue is not related to the edit in
> > > > > > the
> > > > > > > > original
> > > > > > > > > >>>>     1-week change.
> > > > > > > > > >>>     That's right, but we found a source of
> > > > > > misinterpretation
> > > > > > in
> > > > > > > > the
> > > > > > > > > >>>     draft and you have rightly corrected it in the github
> > > > > > v9.
> > > > > > > > > >>>
> > > > > > > > > >>>     Regards, Benoit
> > > > > > > > > >>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>>     sec. 3.3.5:
> > > > > > > > > >>>>
> > > > > > > > > >>>>     OLD:
> > > > > > > > > >>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>>     data node rule: controls access for a specific data
> > > > > > > > > >>>>     node, identified
> > > > > > > > > >>>>     by its path location within the conceptual XML
> > > > > > document
> > > > > > > > > >>>>     for the
> > > > > > > > > >>>>     data node.
> > > > > > > > > >>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>>     NEW:
> > > > > > > > > >>>>
> > > > > > > > > >>>>     data node rule: controls access for a specific data
> > > > > > node
> > > > > > > > > >>>>     and its descendants,
> > > > > > > > > >>>>     identified by its path location within the conceptual
> > > > > > XML
> > > > > > > > > >>>>     document for the
> > > > > > > > > >>>>     data node.
> > > > > > > > > >>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>>     sec 3.4.5, step 6, bullet 2:
> > > > > > > > > >>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>>     OLD:
> > > > > > > > > >>>>
> > > > > > > > > >>>>     * The rule does not have a "rule-type" defined or the
> > > > > > > > > >>>>     "rule-
> > > > > > > > > >>>>     type" is "data-node" and the "path" matches the
> > > > > > > > > >>>>     requested
> > > > > > > > > >>>>     data node, action node, or notification node.
> > > > > > > > > >>>>
> > > > > > > > > >>>>     NEW:
> > > > > > > > > >>>>     * The rule does not have a "rule-type" defined or the
> > > > > > > > > >>>>     "rule-
> > > > > > > > > >>>>     type" is "data-node" and the "path" matches the
> > > > > > > > > >>>>     requested
> > > > > > > > > >>>>     data node, action node, or notification node. A path
> > > > > > is
> > > > > > > > > >>>>     considered to match if the current data node is the
> > > > > > > > > >>>>     data node
> > > > > > > > > >>>>     specified by the path, or is a descendant data node
> > > > > > > > > >>>>     of this data node.
> > > > > > > > > >>>>     appendix B.4: (2 bugs in explanation)
> > > > > > > > > >>>>     OLD:
> > > > > > > > > >>>>     deny-nacm: This rule denies the "guest" group any
> > > > > > access
> > > > > > to
> > > > > > > > the
> > > > > > > > > >>>>     <nacm> subtree. Note that the default namespace is
> > > > > > only
> > > > > > > > > >>>>     applicable because this subtree is defined in the
> > > > > > same
> > > > > > > > > >>>>     namespace as the <data-rule> element.
> > > > > > > > > >>>>     NEW:
> > > > > > > > > >>>>     deny-nacm: This rule denies the "guest" group any
> > > > > > access
> > > > > > to
> > > > > > > > the
> > > > > > > > > >>>>     <nacm> subtree.
> > > > > > > > > >>>>     Andy
> > > > > > > > > >>>>
> > > > > > > > > >>>>     On Fri, Nov 10, 2017 at 9:24 AM, Robert Wilton
> > > > > > > > > >>>>     <[e-mail] <mailto:[e-mail]>> wrote:
> > > > > > > > > >>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>>         On 10/11/2017 16:33, Andy Bierman wrote:
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>         On Fri, Nov 10, 2017 at 8:16 AM, Robert Wilton
> > > > > > > > > >>>>>         <[e-mail] <mailto:[e-mail]>>
> > > > > > wrote:
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>             On 10/11/2017 15:49, Andy Bierman wrote:
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>>
> > > > > > > > <snip>
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > 
> > > > > > 
> > > >  
> > > > 
> >  
> 
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67