Re: [i2rs] topo model use of NACM

["Susan Hares" <[e-mail]>]

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.

 


 <https://tools.ietf.org/html/draft-ietf-netconf-rfc6536bis-00#section-3.2> 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