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

[Andy Bierman <[e-mail]>]

On Mon, Nov 27, 2017 at 8:53 AM, Ladislav Lhotka <[e-mail]> wrote:

> 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.
>
>

>From a NACM POV, the rule to allow "create /foo/case1" works differently
depending on whether server auto-deletion is used.

IMO, NACM controls client access, and auto-deletion is server access,
which is mandated by the specific YANG data-def statements.




> >
> >
> > > > 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.
>
>

The YANG designers need to consider the impact of when statements on the
data model usage.
NACM needs to be used at a sufficiently course granularity and it is quite
possible
to setup NACM with inappropriate granularity, where intended access is
blocked
and unintended access is allowed.



>
> > 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.
>
>

The widespread use of vendor extensions and deviations makes it impossible
to
focus on just the standard modules when considering access control.
Perhaps the best the IETF can do is identify YANG usage patterns that need
to considered
when configuring NACM.

Another option is to create smarter NACM filters, based on tags, not data
nodes.
Data rules are very sharp knifes that need to be used with care.

Lada
>
>
Andy


>
> >
> >
> > > 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
>
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>