Vincent Cridlig wrote:
Andy Bierman a écrit :Vincent Cridlig wrote:Andy Bierman a écrit :Balazs Lengyel wrote:Hello, You are right, we need access control.For this reason each action defined in the data model should be defined as read/write/disturb-traffic. read: it only reads configuration and state data and doesn't effect the trafficwrite: it writes configuration data, but does not disturb the traffic disturb-traffic: means it can do anything.IMO, a clean access control model for NETCONF need to recognize the RPC model and the configuration datastore architecture. First, there is the RPC method, defined by a QName. The user must have access to invoke the RPC method. Completely independent of that is the data access control model applied to all configuration datastores. The NETCONF operations are create, delete, merge, and replace. For access control purposes, merge and replace operations are treated as a 'create' if the target data instance does not exist. The granularity could be a coarse as read/write, but that would totally defeat the purpose of create and delete operations in the edit-config method. An access control that matches the capabilities of the protocol needs to include read/write/create+delete as the 3 levels of data access (4 if you count 'none'). It makes no sense to have an 'exec' or 'disturb-traffic' access control classification in the data space. Either the user can invoke the RPC method or not. Remember, it is the PROTOCOL that needs an access control model, not blobs of XML. IMO, focusing the ACM on the XML is the wrong approach.I don't really agree with this. When you define an access control model, you have to define permissions as a (action, resources) combination set. I think it is not possible to define permissions without a way of addressing data (XML-based or not). The ACM is usually strongly dependant on the data model. I don't understand what kind of access control policy you can specify if you don't consider the data but only the RPC ? Can you please give an example ?<ping> or other action RPCsOk but these RPCs are not some of the regular operations of the Netconf draft !
The protocol defines an RPC mechanism, and then later defines RPC methods in the netconf-base namespace. Just as the VACM can be used in SNMP for MIB objects defined in the enterprise OID tree, the ACM for NETCONF must work for any RPC method in any namespace.
To counterbalance the previous comments, it could be possible to specify an ACM with RPCs if the operations are specialized like get-interface or set-route-map. The granularity would be very large in that case but possible. But Netconf chose to have generic operations (get, edit) with parameters and therefore needs the protected resources locations as part of the ACM.
Any RPC method is potentially capable of touching any configuration datastore in unknown ways. Rather than define a hard-wired ACM for 7 known RPC methods, I prefer to have a more generalized system that handles any RPC and any data.
Regards Vincent
Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/netconf/>