Re: [i2rs] topo model use of NACM

[Martin Bjorklund <[e-mail]>]

Andy Bierman <[e-mail]> wrote:
> Hi,
> 
> I am most concerned about getting the architecture right.
> We have ignored server-created nodes until now.
> I am glad I2RS WG is trying to deal with the problem.
> Just make sure we have a reusable solution.
> 
> Also concerned about tool automation.
> There was some discussion of a 'server-created' extension at some point I
> think.

That old discussion was about a different (and simpler) use case; it
was about when a server would add some nodes to the configuration as
part of a client's creation request.  For example, a server would
automatically assign a 'uid' to a newly created user.

The topology use case is more complicated.  The server can discover a
topology and instantiate it somewhere - originally it was instantiated
in the configuration, but that is questionable.  I still don't really
understand the expected lifecycle of these server provided instances;
specifically, can they come and go completely dynamically, even if
there are other instances that refer to them?


/martin




> This would help, because the server-created leaf is not really
> deterministic.
> It is just a convention.
> 
> e.g.
> 
> 
>   container networks {
>      list network {
>          i2rs:server-created;
>          ...
>          leaf server-created { ... }
>          ...
>      }
>   }
> 
> 
> Andy
> 
> 
> On Thu, Feb 16, 2017 at 11:47 AM, Susan Hares <[e-mail]> wrote:
> 
> > Andy:
> >
> > <chair hat off, individual contributor hat on>
> >
> >
> >
> > AFAIK – I believe the revised data store model is right approach.   It is
> > an important question to ask whether the ability to have a mixture of
> > “server-provided” and “configured” is important for all topology models.  I
> > hope Xufeng and other topology models will comment on this point.
> >
> >
> >
> >
> >
> > Does the NETCONF data store in the revised data-store future include the
> > control plane data stores? I thought the answer was “no” it does not.
> >  Here’s some text from draft-ietf-netconf-rfc6536bis that leads me to
> > believe that
> >
> >
> >
> > On NACM, draft-ietf-netconf-rfc6536bis it says:
> >
> >
> >
> >    It is necessary to control access to specific nodes and subtrees
> >
> >    within the NETCONF datastore, regardless of which protocol operation,
> >
> >    standard or proprietary, was used to access the datastore.
> >
> >
> > 3.2
> > <https://tools.ietf.org/html/draft-ietf-netconf-rfc6536bis-00#section-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.  Local or remote files or datastores
> >
> >    accessed via the <url> parameter are not controlled by NACM.  A
> >
> >    standalone RESTCONF server (i.e., not co-located with a NETCONF
> >
> >    server) applies NACM rules to a conceptual datastore, since
> >
> >    datastores are not supported in RESTCONF.
> >
> >
> >
> >
> >
> > ===========
> >
> >
> >
> > The I2RS security environment actually looks at 3 policies on the server
> >
> >
> >
> > Network Access ß-à server ß-à routing-system access
> >
> >               (aka I2RS agent)
> >
> >                     |ßà System access
> >
> >
> >
> > It also looks at application access to the client
> >
> >
> >
> >   Network accessßà client ßà application-access
> >
> >
> >
> >
> >
> > The protocol only needs to consider the NACM Access, but the routing
> > infrastructure need to consider the server to/from routing system, and
> > server to/from system.  My understanding is that the Routing system access
> > control module (RACM) and the system access control module (SACM) functions
> > were not in NACM.
> >
> >
> >
> > Thanks again for posting,
> >
> >
> >
> > Sue
> >
> >
> >
> > *From:* i2rs [mailto:[e-mail]] *On Behalf Of *Andy Bierman
> > *Sent:* Thursday, February 16, 2017 2:00 PM
> > *To:* [e-mail]
> > *Subject:* [i2rs] topo model use of NACM
> >
> >
> >
> > Hi,
> >
> >
> >
> > The use of NACM for server-provided data is under-specified (at best)
> >
> >
> >
> >
> >
> > from sec. 4.1:
> >
> >
> >
> >    Finally, there is an object "server-provided".  This object is state
> >
> >    that indicates how the network came into being.  Network data can
> >
> >    come into being in one of two ways.  In one way, network data is
> >
> >    configured by client applications, for example in case of overlay
> >
> >    networks that are configured by an SDN Controller application.  In
> >
> >    annother way, it is populated by the server, in case of networks that
> >
> >    can be discovered.
> >
> >
> >
> >    If server-provided is set to false, the network was configured by a
> >
> >    client application, for example in the case of an overlay network
> >
> >    that is configured by a controller application.  If server-provided
> >
> >    is set to true, the network was populated by the server itself,
> >
> >    respectively an application on the server that is able to discover
> >
> >    the network.  *Client applications SHOULD NOT modify configurations of*
> >
> > *   networks for which "server-provided" is true.*  When they do, they
> >
> >    need to be aware that any modifications they make are subject to be
> >
> >    reverted by the server.  For servers that support NACM (Netconf
> >
> >    Access Control Model), *data node rules should ideally prevent* write
> >
> >    access by other clients to network instances for which server-
> >
> >    provided is set to true.
> >
> >
> >
> > The SHOULD NOT above is really odd, considering is not supported by YANG
> >
> > or the NC/RC protocols.
> >
> >
> >
> > "data node rules should ideally prevent"
> >
> >
> >
> > s/should/SHOULD/
> >
> >
> >
> > Ideally prevent?
> >
> > Is that a new engineering term?
> >
> > Either this new usage of NACM works or it doesn't.
> >
> >
> >
> > Also, there is no guidance or examples of the NACM config that the
> >
> > server is supposed to magically create for server-provided topology data.
> >
> > There is nothing in NACM at all about server-created data rules.
> >
> > This is not supported by NACM.
> >
> >
> >
> > Does the I2RS text imply that the server-provided property extends
> >
> > to the NACM sub-trees? They are also subject to replacement by the server?
> >
> > The client SHOULD NOT change these NACM rules?
> >
> >
> >
> > IMO the way this server-provided property is being done is a short-sighted
> >
> > point solution, but this should be a fundamental part of the revised
> > datastores work.
> >
> > Is there something special about network topology such that
> >
> > server-provided data for a different module will require a different
> >
> > solution? If not, is the topo module solution reusable?
> >
> >
> >
> >
> >
> > Andy
> >
> >
> >
> >
> >
> >
> >