Re: [Netconf] WG LC for draft-ietf-netconf-rfc6536bis

[Martin Bjorklund <[e-mail]>]

Andy Bierman <[e-mail]> wrote:
> On Thu, May 4, 2017 at 11:21 AM, Alexander Clemm <[e-mail]
> > wrote:
> 
> > As mentioned in my message, I don’t think specific access control will be
> > needed (I am not aware of specific use cases), but specifically with the
> > revised datastore architecture about to the be introduced, its impact or
> > nonimpact and interrelation with NACM should be discussed.  This can be as
> > simple as a small paragraph or subsection “Revised Datastore
> > Considerations”.
> >
> >
> >
> 
> there is no text about candidate vs. running vs. startup.
> The NACM rules apply to all of them the same.
> I could add text that says there is no consideration for specific
> datastores.

Actually, the document already says:

3.2.  Datastore Access

   The same access control rules apply to all datastores, for example,
   the candidate configuration datastore or the running configuration
   datastore.

   Only the standard NETCONF datastores (candidate, running, and
   startup) are controlled by NACM.


Somehow this needs to be updated when the revised datastore work is
done.  E.g., I expect read access to intended to follow the same NACM
rules.


/martin


> Most rules apply to the schema tree. Data rules apply to instance data
> but they apply to all instances in all datastores).  I can make this clear
> in the next revision
> 
> Andy
> 
> 
> > I also do think that clarification regarding Netconf/Restconf vs other
> > protocols is in fact needed.  I do think that NACM rules _*should*_ in
> > fact be applicable.  Again, at a minimum something needs to be stated along
> > those lines.  Otherwise you cannot introduce another transport without
> > facing the choice between needing yet-another access control mechanism that
> > may require redundant and potentially inconsistent configuration by
> > administrators, or leaving out a big backdoor that would render NACM
> > irrelevant.
> >
> >
> >
> > --- Alex
> >
> >
> >
> >
> >
> > *From:* Andy Bierman [mailto:[e-mail]]
> > *Sent:* Thursday, May 04, 2017 10:40 AM
> > *To:* Alexander Clemm <[e-mail]>
> > *Cc:* Mahesh Jethanandani <[e-mail]>; Netconf <
> > [e-mail]>
> > *Subject:* Re: [Netconf] WG LC for draft-ietf-netconf-rfc6536bis
> >
> >
> >
> > Hi,
> >
> >
> >
> > I am strongly opposed to datastore-specific access control.
> >
> > I need to see a use-case that demonstrates why a particular client
> >
> > needs to be denied access to a specific subtree in 1 datastore vs. another
> > datastore.
> >
> >
> >
> >
> >
> > The NACM procedures need to be mapped to protocol operations.
> >
> > It is easier to do this for actual protocols than a generic placeholder.
> >
> > It may be possible.
> >
> >
> >
> > I do not agree NACM controls the internal access.
> >
> > That is an implementation detail. NACM is enforced on clients using
> >
> > NETCONF of RESTCONF.
> >
> >
> >
> > If the WG wants the NACM procedures mapping to protocols to be more
> > generic,
> >
> > I could work on some proposed text to do that.
> >
> >
> >
> >
> >
> > Andy
> >
> >
> >
> >
> >
> > On Thu, May 4, 2017 at 10:22 AM, Alexander Clemm <
> > [e-mail]> wrote:
> >
> > Hi,
> >
> >
> >
> > FWIW, I do have a few comments.  Overall the document is in good shape,
> > but there are a few items where I think it can be made even better:-)
> >
> >
> >
> > -          I think it would be good to include a section on how the
> > revised datastores will impact requirements on NACM.  I don’t think
> > anything major is required, but there are a few places where some updates
> > could be made, and/or perhaps a brief section could be added somewhere
> > discussing this.  For example, in Figure 1 (Section 2.1) where it says
> > “datastore or state data access” (technically, this remains correct, but
> > this seems to have the previous model in mind), also fig 3 assuming RPCs
> > will always be against config datastore).   It might also mention which
> > datastore NACM rules apply to when the same data is contained in multiple
> > datastores.  Technically, I don’t think there will be a distinction (any
> > differentiation would apply to read operations, and I cannot think of a
> > good example where such differentiation would be needed), still it might be
> > good to be explicit about it.
> >
> > -          In section 3.4.6 (outgoing <notification> authorization), it
> > states that access control is applied only to notification as a whole, not
> > to any data it contains.  This is clear enough; however, it is a
> > limitation.  Specifically, in YANG-Push there is a requirement to be able
> > to apply a security filter to not push data that the receiver is not
> > authorized to receive (or not accept/terminate a subscription which
> > contains such data altogether).  If NACM does not provide this, another
> > mechanism or a NACM extension will be needed (that will still need to use
> > the privileges configured in NACM).  At a minimum, this needs to be clearly
> > called out.
> >
> > -          I wonder why NACM is restricted to NETCONF or RESTCONF.
> > Really, this restricts access to data in YANG datastores; while NETCONF and
> > RESTCONF do need to be called out specifically and the document does need
> > to spell out how it is applied in this context, it would probably be good
> > to clarify that NACM should apply to other protocol access.
> >
> > -          It would be good to indicate that the source of access control
> > rules is not restricted to external clients, but that they could originate
> > from the server itself.  This is the same config/operational state
> > discussion that has come up in other contexts (e.g. the topology models),
> > and I think it applies here as well.  Again, this is where the revised
> > datastores model is intended to provide a solution – i.e. the NACM rules in
> > the config datastore may be only a subset of the ones in the operational
> > datastore, etc – but I think it is important enough to be called.
> >
> >
> >
> > Thanks
> >
> > --- Alex
> >
> >
> >
> > *From:* Netconf [mailto:[e-mail]] *On Behalf Of *Mahesh
> > Jethanandani
> > *Sent:* Wednesday, May 03, 2017 2:18 PM
> > *To:* Netconf <[e-mail]>
> > *Subject:* Re: [Netconf] WG LC for draft-ietf-netconf-rfc6536bis
> >
> >
> >
> > Folks,
> >
> >
> >
> > There has been literally no feedback on this document, either to say they
> > have read the document and support it, or to express concerns about the
> > document. Silence, unfortunately is not a good guide for us. To move the
> > document forward, we need to hear from folks, including those who were in
> > IETF 98.
> >
> >
> >
> > Thanks.
> >
> >
> >
> > On Apr 18, 2017, at 5:34 PM, Mahesh Jethanandani <[e-mail]>
> > wrote:
> >
> >
> >
> > NETCONF WG,
> >
> > In IETF 98, the authors indicated that the above draft was ready for Last
> > Call, and the consensus in the room indicated as much.
> >
> >
> >
> > This is a start of a 2 week WG Last Call for
> > draft-ietf-netconf-rfc6536bis. After two weeks, the document will be
> > assigned a shepherd, and the document will be prepared for IESG.
> >
> > The latest version of the draft can be found at:
> > https://tools.ietf.org/html/draft-ietf-netconf-rfc6536bis-01
> >
> > Please review and send any comments to the WG mailing list or by
> > responding to this e-mail. Comments can be statements such as, I
> > read/reviewed the document and believe it is ready for publication, or I
> > have concerns about the document. For the latter, please indicate what your
> > concerns are.
> >
> > Any reports on implementation status or plans to implement are also very
> > useful.
> >
> >
> >
> > Authors, please indicate if you are aware of any IPRs related to the draft.
> >
> >
> >
> > Thanks.
> >
> > Mahesh and Mehmet
> >
> >
> >
> >
> >
> >
> >
> > Mahesh & Mehmet
> >
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Netconf mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netconf
> >
> >
> >