Subject: Re: action RPC I-D

From: Andy Bierman <[email-masked]>
Date: Wed, 01 Nov 2006 08:44:25 -0800

Randy Presuhn wrote:
> Hi -
> 
>> From: "Andy Bierman" <[email-masked]>
>> To: "Vincent Cridlig" <[email-masked]>
>> Cc: "'Netconf (E-mail)'" <[email-masked]>
>> Sent: Monday, October 30, 2006 8:00 AM
>> Subject: Re: action RPC I-D
> ...
>> 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.
> ...
> 
>>From this I gather that the only way to represent the configuration
> (for purposes of disaster recovery, for example) of a system that
> supports these RPCs would be to record the sequence of RPCs
> over the lifetime of the box so they can be replayed into the new
> system.  The alternative would be to retrieve the entire configuration
> of the managed system as some kind of checkpoint to minimuize the
> number RPC replays required.  Neither approach sounds to me
> like a very good way to do real configuration management.
> 
> But then, maybe I'm missing something about what edit-config
> and its friends really do...
> 

The point is that netconf has an extensible RPC mechanism,
not just a dozen or so standard commands.  Vendors want to
use the extensibility built into the protocol, so the ACM
needs to support it.

Recording RPCs for audit or recovery purposes is a feature.
It seems you would want to do that for XML, if you already do it for CLI.

> If one knows a system's initial configuration, and has a sequence
> of successful edit-config operations, is it possible to compute
> the final configuration state (in order to support, for example, 
> disaster recovery) without knowing the internals of the system
> being configured?

Replay on the same box with the same conditions should produce
the same results.  Replay across arbitrary boxes from different
vendors?  It depends on the RPCs and the data models.

> Randy

Andy

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 1 Nov 2006 12:16:40 -0800

Hi -

> To: "Randy Presuhn" <[email-masked]>
> Sent: Wednesday, November 01, 2006 8:44 AM
...
> vendors?  It depends on the RPCs and the data models.

That's the question I'm asking.  Let me break it into some simpler
questions:

    1) if one successfully plays the same sequence of commands
        into two different boxes with the same starting configuration
        (not asking about whether the vendors are different, just whether
        the boxes' configurations are identical) can one assume that 
        the resulting configurations will be the same?

    2) is the result (in terms of how the system's configuration will change)
        of a successfully completed RPC deterministic?

    3) is the result (in terms of the changes to a system's configuration)
        of a successfully completed RPC predictable?

If the answer is "no" to any of these questions, then I think we're in
for a tough time explaining how this belongs in "configuration management",
and need to face up to what this protocol really is.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 01 Nov 2006 13:53:51 -0800

> and need to face up to what this protocol really is.

Seems like the quality of the RPC or data model definition
and documentation would determine how predictable the result
would be on any given system.  No different than SNMP here.
A bad MIB design does not prove that SNMP is broken either.

IMO, the RPC model allows complex high-level procedures to
be isolated and easily defined.  The SNMP "data-centric" approach
is to define a bunch of MIB tables which depend on each other,
and require possibly undocumented PDU sequences to set up
related rows in those tables, and then set a master RowStatus
object to 'active' to kick the whole thing off.  Often the PDU
sequences required (or permitted) by an agent vary greatly
across implementations.

The RPC approach allows the high-level operation to be modeled
directly and efficiently.

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 1 Nov 2006 17:54:13 -0800

Hi -

> Sent: Wednesday, November 01, 2006 1:53 PM
...
...

We're not talking about SNMP.  Were talking netconf, a protocol that
was supposed to better support configuration management than SNMP.

With this kind of behaviour, what's the point of tracking configurations?
It seems the only workable solution if equipment can be this arbitrary
will be to tweak things until the device works, and then do a get-config
to figure out what the configuration really is, and hope that none of
the RPCs did things that won't be reflected in the results of get-config,
and hope that replaying the results of the get-config back into a device at
some time in the future will result in the desired configuration.

This seems somewhat suboptimal.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 01 Nov 2006 18:40:13 -0800

> This seems somewhat suboptimal.

I don't understand your objection.
We should assume that programmers use RPC methods with
an understanding of what each one does.

This is no different than understanding every single data model
and knowing what happens when it is changed with edit-config.

I would assume that a standard RPC method template would
include details like how any portion of the configuration
database is affected (if at all) by the RPC.

I think it is presumptive to assume that proper NE device management
requires all configuration procedures to be modeled as data, which can
be editing in almost arbitrary ways, as if if was nothing more than
a text file on the managed device.   IMO this approach has failed
spectacularly, and it's time to try something else.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 02 Nov 2006 11:57:50 +0100

Hello,
I feel that we should be careful not to make access control to complicated. While 
technically it is possible to design a good, fine grained access control model, I fear the 
user (operator) will have difficulties understanding it.

I see that read/write (and possibly disturb traffic) are three easy to understand concepts 
that might be executed by different people in the network operator's organization. On the 
other hand I don't see who would be the operator who is allowed to modify a route(or a 
customer), but not to create a new one.

I agree that operationally separating delete, replace, etc. is a useful notion, but I 
don't see the need for the same with access control.

Balazs

Andy Bierman wrote:
> 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 traffic
>> write: 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.
> 
> 
>>
>> One can debate that these are the good categories for access control. 
>> Still the basic statement is that for each action defined in the data 
>> model you need to specify it's access properties in the data model as 
>> well.
>> Balazs
>>
>> Andy Bierman wrote:
>>> Your access control model should be more robust than
>>> simply allowing user X to do anything called <action>.
>>> I don't see what benefit an intermediate SW component
>>> can realize if an extra generic container is added to <rpc>.
>>>
>>
>>
> 
> 
> Andy
> 

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Thu, 02 Nov 2006 06:43:33 -0800

Balazs Lengyel wrote:
> Hello,
> I feel that we should be careful not to make access control to 
> complicated. While technically it is possible to design a good, fine 
> grained access control model, I fear the user (operator) will have 
> difficulties understanding it.
> 
> I see that read/write (and possibly disturb traffic) are three easy to 
> understand concepts that might be executed by different people in the 
> network operator's organization. On the other hand I don't see who would 
> be the operator who is allowed to modify a route(or a customer), but not 
> to create a new one.
> 
> I agree that operationally separating delete, replace, etc. is a useful 
> notion, but I don't see the need for the same with access control.
> 

I suggest that people implement NETCONF, and also implement
some kind of ACM, and prove to operators and the WG that the
design and feature set is necessary and sufficient.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 02 Nov 2006 07:41:13 -0800

> notion, but I don't see the need for the same with access control.

There are 4 components to implementing an isAccessAllowed internal API:

   - maximum access that makes protocol sense
     - SNMP uses read-create to identify table rows that the NMS
       and agent can create, and read-write to identify scalars and
       table rows that only the agent can create.

   - access requested in the PDU

   - identity or the requester (e.g., user name, group name)

   - maximum access allowed for the requester (configured on the agent)

If the granularity of the entire ACM is read or write, then how do
you identify (in the data model schema) which subtrees can be created
by any NMS?   Also, how do you tell the agent that the user is allowed
to create specific child nodes of <interface>, but not an <interface>
node itself?

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 2 Nov 2006 17:25:43 +0100

>   - maximum access allowed for the requester (configured on the agent)

The maximum access that makes protocol sense is IMHO not an input to
isAccessAllowed - there is no runtime decision to make. The maximum
access that makes protocol sense is input for the tools that drive
your implementation; there simply is no write method to call for
read-only objects. In the SNMP processing, you return an error before
you ever get to the isAccessAllowed() function if I remember things
well.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Vincent Cridlig <[email-masked]>
Date: Thu, 02 Nov 2006 17:29:54 +0100

Andy Bierman a écrit :
>> I see that read/write (and possibly disturb traffic) are three easy 
>> to understand concepts that might be executed by different people in 
>> the network operator's organization. On the other hand I don't see 
>> who would be the operator who is allowed to modify a route(or a 
>> I agree that operationally separating delete, replace, etc. is a 
>> useful notion, but I don't see the need for the same with access 
>> control.
>>
>

We have some kind of implemented ACM which assumes an XML data model.
I don't know if it is necessary and sufficient ! Here is a quick overview:

Each permission is expressed with two things:
- an XPath expression, saying which nodes are concerned,
- an attribute which can be "r", "w", or "rw".

In our implementation, having access to one node grants the privilege to 
the whole subtree of this node. Only positive privileges can be 
specified to avoid conflicts.

Also, since we implemented an RBAC model, we define roles like 
SuperManager, RoutingManager, ExteriorRoutingManager, SecurityManager 
and so on... These roles have some permissions, and each manager may 
have some roles. (Roles can be hierarchical if you need.)

For people who think it is not necessary to have such fine-grained ACM, 
they can use the SuperManagerRole and give access to everything. For the 
others, they can specify privileges more carefully.

One of the cool thing is that the scope of operations is limited when 
you have one role active. This decreases misconfigurations risks. There 
are other advantages.

Regards,
Vincent

---

From: Andy Bierman <[email-masked]>
Date: Thu, 02 Nov 2006 08:52:11 -0800

> you ever get to the isAccessAllowed() function if I remember things

The maxAccess check could also be part of validation phase at runtime.
The implementation aspects are not really important here.

In a real data model, there are going to be
  - nodes that should be there every time (e.g., <interfaces> container)
  - nodes that the agent is only allowed to create, but may not be present
  - nodes that both the agent and NMS are allowed to create
  - nodes that only the NMS will create (based on desired feature config)

Perhaps new <appInfo> mechanisms will be needed, totally unrelated
to the way SMIv2 handles this issue.

IMO, distinguishing between editing existing instances and creating
new instances is useful, but probably not important.

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 2 Nov 2006 10:13:05 -0800

Hi -

> To: "Andy Bierman" <[email-masked]>; "Balazs Lengyel" <[email-masked]>; "Martin Bjorklund" <[email-masked]>;
<[email-masked]>
> Sent: Thursday, November 02, 2006 8:52 AM
> Subject: Re: Access control [was: action RPC I-D]
...
...

If the order in which the checks are performed could affect what
error code is returned on the wire, then this *does* matter.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 02 Nov 2006 11:21:02 -0800

> I don't know if it is necessary and sufficient ! Here is a quick overview:

Sounds very good to me.
I bet it could be easily extended to configure the RPC method
access control as a list of Xpath expressions.

There seems to be WG consensus that actions should not
be modeled as data, but rather as RPC methods.  Therefore,
restricting access to certain RPC methods (<delete-config>,
<reset-device>, etc.) is going to be important.

> - an attribute which can be "r", "w", or "rw".

What happens if Xpath expressions overlap (i.e. 1 or more nodes
are selected by more than 1 Xpath expression)?  Do you just
execute the list in order, like an ACL on a router?

I am giving in on the "create/delete" feature in the ACM.
The fact is that this is more effort to implement and
takes more runtime cycles, because you have to check the
actual configuration database to know if a merge or replace
is really a create or delete.

If the ACM allows for read/write, then you only have to check
the PDU, not the configuration target as well.

BTW, I like the enum "w" -- it is useful for storing keys and
passwords in configuration databases.

> you have one role active. This decreases misconfigurations risks. There 

Sounds interesting.
You should write a draft about it.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 03 Nov 2006 08:50:32 +0100

Hello,

> the PDU, not the configuration target as well.
[BALAZS]: Sadly even with read/write, for a merge operation you still need the database, 
the PDU is not enough. Just from the PDU you do not know if an XML element is just a 
pointer to a lower level element or if it is actually a create order.

Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 03 Nov 2006 14:48:56 +0100

Hello,
My point with the action draft was not to provide an access control solution, but to
provide a way to transfer non-standard action type commands/operations to the Netconf
server. I believe I showed that my draft will not have problems with access control as 
there is a place (the data model) to put access control characteristics/information about 
an individual action.

So I would still like the group to consider my generic action draft. I would like to
promote it into a workgroup document.

Balazs

---

From: Andy Bierman <[email-masked]>
Date: Fri, 03 Nov 2006 08:05:51 -0800

Balazs Lengyel wrote:
> server. I believe I showed that my draft will not have problems with 
> access control as there is a place (the data model) to put access 
> control characteristics/information about an individual action.
> 

I do not think the WG wants the extra layer for RPC methods
that have a purpose which is characterized as an action.
There has been some support for defining some standard actions
which use the existing RPC mechanism.

IMO, basing a protocol feature on presumed implementation
advantages for intermediate systems will be difficult to
achieve, unless there is widespread use of some tools that
actually need the data in this format.  This made sense
for the SOAP wrapper for NETCONF because there are many
pre-existing tools which expect the data in a certain format.

The same is not true for this new 'action' RPC wrapper.
Several people have stated that this new wrapper will not
make their code any easier to write.  Some have stated
that it will actually make some tasks much harder
if hard-wired element names (like <ping>) are moved to
string content instead.

I think the WG members who want to change the RPC mechanism
in this manner need to speak up on the mailing list.

In the meantime, we have only one chartered work item,
which is not finished.  Any new work will require a change to
the charter.

Andy

---

From: "David B Harrington" <[email-masked]>
Date: Fri, 3 Nov 2006 12:03:28 -0500

Hi,

In SNMP, the permissions are based on a tree of data; data tends to be
statically defined and low-level.

In netconf, the permissions will be based on RPC methods; RPC methods
are dynamic high-level sets of functionality. The functionality may
actually call other methods within the system, so "create vlan" may
actually also manipulate an interface. The VLAN methodas may be
defined as part of one capability, while the interface may be part of
another capability. 

Should the ACM assume that permission to "create vlan" implies
permission to "manipulate interface"?

Dbh

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 3 Nov 2006 21:10:12 +0100

On Fri, Nov 03, 2006 at 12:03:28PM -0500, David B Harrington wrote:
 
> are dynamic high-level sets of functionality. 

I have no clue what you mean with "static" and "dynamic" here. 

> The functionality may actually call other methods within the system,
> so "create vlan" may actually also manipulate an interface. The VLAN
> methodas may be defined as part of one capability, while the
> interface may be part of another capability.

> permission to "manipulate interface"?

Sorry, but I have trouble to follow you. Creating a VLAN via SNMP sets
has always caused changes of the interface table (at least on all
devices I have seen so far) and it does not matter from the SNMP
perspective whether you have read or write access to that
interface. In general, management operations usually cause changes in
operational state, in some cases even across a whole network.
Expanding access control to cover all the potentially affected
operational state is clearly unrealistic (and it does not really
matter here whether you use a data-oriented, a command-oriented, an
object-oriented or a document-oriented management protocol).

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 06 Nov 2006 09:48:45 +0100 (CET)

> - an attribute which can be "r", "w", or "rw".

We have a slightly different approach.  Here's a somewhat simplified
description:

Based on a number of parameters (such as user name, access method,
operation etc), a netconf session is associated with an ordered list
of rules.  Each rule has a "path" and an "action".  A "path" is a
restricted XPath; an absolute expression with instance selection
(e.g. "/interfaces", "/interfaces/interface[name='eth0']/mtu").  An
"action" is "accept" or "reject".

Logically, for each object that the user tries to
read/write/create/delete, the list of rules is searched for a match.
The "action" associated with the first match is the result of the
access control for this object.  If no match is found, the access is
rejected.

We also have read/write only (i.e. no create/delete).

This execution scheme is very similar to how iptables works for ip
packet filtering in linux.

With this scheme it's easy to include/exclude certain subtrees for
access.

Implementation-wise, this can be done pretty efficiently.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 06 Nov 2006 10:46:25 +0100 (CET)

Andy Bierman <[email-masked]> wrote:
> be modeled as data, but rather as RPC methods.

Just to be clear - I don't think anyone has suggested that actions
should be modeled as data.  Many people seem to agree that it should
be possible to define actions in the DM.  There are different opinions
on how these actions should be encoded in XML (in a generic <action>
rpc or specialized rpcs).

/martin