Subject: max-access: access control model discussion

From: Andy Bierman <[email-masked]>
Date: Fri, 19 May 2006 11:49:01 -0700

Hi,

This discussion is somewhat out of charter scope, but since access control
for notifications and data models keeps coming up, I think we should
discuss the basics.

IMO, the max-access mechanism in the draft is too complicated,
and it doesn't account for all operation attribute and
SMI MAX-ACCESS enumerations.  I also don't understand
the preference for making the XML as complicated as possible.
I prefer simple as possible, and reusing as much SMI as
possible (without breaking netconf ;-)

Here is a snippet from the draft as an example:

 <xs:appinfo>
   <nm:minAccess><read/></nm:minAccess>
   <nm:maxAccess><read/> <write/> <create/> <delete/></nm:maxAccess>
 </xs:appinfo>

===============================================================================
Here is something to throw darts at:

I have created a hierarchical max-access enumeration,
similar to the one in SMIv2, except it adds a few
enumerations for well-known 'mid-states' which can only
be defined in DESCRIPTION clauses.

The hierarchy is:

notify-only: object can appear in a /notification/data element 
       (SMI: notify-only)

read-only: notify + object can be retrieved in any type of
       read operation  (SMI: read-only)

write-only: object can be written only if it already exists.
       No read access at all -- agent created objects for passwords, etc.
       (SMI: write-only)

create-only: object can be created and deleted, but not edited or read.
        For passwords, etc. in dynamic objects.
        (SMI: read-create + DESCRIPTION says no read or edit if 
rowStatus=active)

read-write: notify + read + object can be edited if it already exists
        (SMI: read-write)

read-create: notify + read + object can be created and deleted, but not 
edited.
        (SMI: read-create + DESCRIPTION says no edit if rowStatus=active)
        (I know this name is confusing...)

read-create-edit: notify + read + create/delete + edit
        (SMI: read-create) (alias 'all' also accepted)

Mapping to the Operation Attribute
----------------------------------

Key:  name : allowed max-access values (to permit the operation)

none : any value

merge: if object currently exists:
         write-only, read-write, all
       otherwise:
         create-only, read-create, all

replace: create-only, read-create, all

create:  create-only, read-create, all

delete: same as create

I've implemented this, and the code really is as easy
as the little table above suggests. This algorithm
treats a replace as a delete+create, so it doesn't
work for static (write-only or read-write) objects.
This keeps the code simpler, but is more restrictive.
Maybe too restrictive, I don't know yet.

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: "Sharon Chisholm" <[email-masked]>
Date: Tue, 23 May 2006 15:15:42 -0400

hi

This seems much more complicated then what is in the draft. I prefer the
approach of defining a list of values rather then enumerating all the
combinations and permutations of the items in the list as unique values.

The draft considers notification another form of reading. I believe all
the other values are covered.

Sharon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Andy Bierman
Sent: Friday, May 19, 2006 2:49 PM
To: Netconf (E-mail); Netconf Data Model Discussion
Subject: max-access: access control model discussion

Hi,

This discussion is somewhat out of charter scope, but since access
control for notifications and data models keeps coming up, I think we
should discuss the basics.

IMO, the max-access mechanism in the draft is too complicated, and it
doesn't account for all operation attribute and SMI MAX-ACCESS
enumerations.  I also don't understand the preference for making the XML
as complicated as possible. I prefer simple as possible, and reusing as
much SMI as possible (without breaking netconf ;-)

 <xs:appinfo>

========================================================================
=======
Here is something to throw darts at:

The hierarchy is:

write-only: object can be written only if it already exists.
       No read access at all -- agent created objects for passwords,
etc.
       (SMI: write-only)

read-create: notify + read + object can be created and deleted, but not 
edited.
        (SMI: read-create + DESCRIPTION says no edit if
rowStatus=active)
        (I know this name is confusing...)

none : any value

delete: same as create

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: Andy Bierman <[email-masked]>
Date: Tue, 23 May 2006 13:00:55 -0700

> combinations and permutations of the items in the list as unique values.

What is in the draft is rather under-specified.

Forget my "extended MAX-ACCESS".  That was a mistake.
Think of the MAX-ACCESS clause exactly as defined in SMIv2 instead.

The real issue is whether the application of SMIv2 MIB modules
for use in the NETCONF protocol is of any interest whatsoever.
If so, then a mapping of the MAX-ACCESS clause to
the NETCONF protocol operations is required.
The operations 'notify' and 'read' are easy.
The other operations (merge, replace, create, delete)
are not as easy.  There are plenty of interesting
corner-cases where 'merge' and 'replace' do not behave
the same wrt/ access control (or function).

IMO, it would be better to use 1 MAX-ACCESS string
per clause, and use the enumerated values from SMIv2 MAX-ACCESS.
Normative text describing the mapping to the NETCONF protocol
is also needed. This small amount of reuse would be a step in the
right direction.

> the other values are covered.

Operational experience with SNMP has shown that sometimes
there is a need to define data that is sent in a notification
but not stored in the agent as retrievable data.
That's why 'notify-only' was added to SMIv2.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 29 May 2006 17:36:23 +0200

Let's assume we have the following data model:

<if>
   <name>eth0</name>
   <opstate>up</opstate>
</if>

- if can be created/deleted max-access: all
- name must be created together with if max-access: all
- opstate is a read only variable that might be created automatically by the managed 
system max-access: read-only

If I want to create <if> can I create the read-only <opstate> object or do I have to rely 
  on the managed system to automaticaly create it ?

If I want to remove the <if> can I remove the read-only <opstate>? (I do not want to allow 
  removing <opstate> without removing <if>.)

What are the correct max-access setting ? (The question is the same both for Andy's and 
Sharon's solution.)

Balazs

---

From: Andy Bierman <[email-masked]>
Date: Mon, 29 May 2006 08:52:52 -0700

Balazs Lengyel wrote:
> - opstate is a read only variable that might be created automatically by 
> the managed system max-access: read-only
> 
> If I want to create <if> can I create the read-only <opstate> object or 
> do I have to rely  on the managed system to automaticaly create it ?
> 
> If I want to remove the <if> can I remove the read-only <opstate>? (I do 
> not want to allow  removing <opstate> without removing <if>.)
> 
> What are the correct max-access setting ? (The question is the same both 
> for Andy's and Sharon's solution.)
> 

I will rewrite my original email to use existing MAX-ACCESS from SMIv2
instead of my extended MAX-ACCESS (based on well-known sub-states in MIBs),
In your example, read-create covers the case where read-write and read-only
data objects are instantiated by the agent, concurrently with the
objects instantiated by the NMS.

IMO, the actual netconf operations need to be explicitly supported
(notify, read, merge, replace, create, delete) with detailed text
explaining the mapping.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 29 May 2006 09:00:12 -0700

Balazs Lengyel wrote:
> The draft proposes  a min-access part to describe conformance. I would 
> like to ask how much is the conformance statement used in SNMP? Do 
> management tools read it and handle MIBs according to it?

I pointed this out before.
MIN-ACCESS is compliance-specific, not data-model specific.
The entire module compliance and agent variance problem
needs to be thought out carefully.

Many WGs and vendors use MIN-ACCESS in MODULE-COMPLIANCE macros.
This is commonly done to define separate 'read-only' and 'read-write'
conformance statements for the same MIB module.
Some vendors also make use of AGENT-CAPABILITIES modules,
which describe agent-specific variations from the conformance
statements in the MIB modules.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 29 May 2006 18:06:04 +0200

I agree that a detailed mapping of max-access to operations is needed. The recent 
discussion about the operation parameter in edit-config also shows us that much of the 
complexity lies in understanding different access clauses on nested elements.

I would also say that mapping from the SMI-2 max-access clause is needed as we will be 
borrowing from the modeling work of SNMP.

I see the following main points about the two versions:
Sharon's max-access:
- It is assumed that the read,write,create,delete,execute rights are orthogonal in a sense 
so the netconf server needs to check only one of them for each operation not the complete set.

Andy's max-access:
_ It is assumed that the set of access possibilities is completely hierarchical so it is 
easier to use a smaller list then the 25 possible permutations in Sharon's list.

I believe both solutions could do the job.

Balazs

Andy Bierman wrote:
>> - opstate is a read only variable that might be created automatically 
>> by the managed system max-access: read-only
>>
>> If I want to create <if> can I create the read-only <opstate> object 
>> or do I have to rely  on the managed system to automaticaly create it ?
>>
>> If I want to remove the <if> can I remove the read-only <opstate>? (I 
>> do not want to allow  removing <opstate> without removing <if>.)
>>
>> What are the correct max-access setting ? (The question is the same 
>> both for Andy's and Sharon's solution.)
>>
> 

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

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 29 May 2006 17:14:44 +0200

The draft proposes  a min-access part to describe conformance. I would like to ask how 
much is the conformance statement used in SNMP? Do management tools read it and handle 
MIBs according to it?

Balazs

---

From: Andy Bierman <[email-masked]>
Date: Mon, 29 May 2006 10:54:32 -0700

Balazs Lengyel wrote:
> I agree that a detailed mapping of max-access to operations is needed. 
> The recent discussion about the operation parameter in edit-config also 
> shows us that much of the complexity lies in understanding different 
> access clauses on nested elements.

This problem has been studied before in the SMIng WG.
Nested MAX-ACCESS is not purely hierarchical.

This is one area where containers really help.
Consider nested containers in dynamic 'rows'.
The NMS creates the parent row, and the agent
creates a read-only container in that row.
After this operation succeeds, the NMS has read-create
access to create entries in that nested container.

> 
> I would also say that mapping from the SMI-2 max-access clause is needed 
> as we will be borrowing from the modeling work of SNMP.
> 
> - It is assumed that the read,write,create,delete,execute rights are 
> orthogonal in a sense so the netconf server needs to check only one of 
> them for each operation not the complete set.

This is not true.
Consider the 'replace' operation carefully.
It can be any or all of "create, write, delete",
in the same PDU.

> 
> Andy's max-access:
> _ It is assumed that the set of access possibilities is completely 
> hierarchical so it is easier to use a smaller list then the 25 possible 
> permutations in Sharon's list.
> 

Andy

---

From: "Tom Petch" <[email-masked]>
Date: Tue, 30 May 2006 17:38:20 +0200

<inline>

Tom Petch

----- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: "Netconf Data Model Discussion" <[email-masked]>
Cc: "Netconf (E-mail)" <[email-masked]>; "Netconf Data Model Discussion"
<[email-masked]>
Sent: Tuesday, May 23, 2006 10:00 PM
Subject: Re: max-access: access control model discussion

> is also needed. This small amount of reuse would be a step in the
Agree strongly.  Of course we can come up with something more sophisticated,
perhaps we can produce something noticeably better, but there is much to be said
in engineering for the reuse of familiar building bricks that have stood the
test of time, and have not, AFAIK, been the subject of significant criticism.
It is not, for me, a question of wanting to reuse MIB modules written in SMIv2,
but having a good concept that is worth perpetuating.

This logic equally says if there is a better model elsewhere, perhaps in the
libraries of ITU-T, then I would support the use of that but, AFAIK, there is
not.

Tom Petch

<snip>

---

From: "David T. Perkins" <[email-masked]>
Date: Tue, 30 May 2006 11:59:18 -0700 (PDT)

HI,

So it looks like you have also misinterpreted what
"MODULE-COMPLIANCE" and "AGENT-CAPABILITIES" are to
be used for.

A MODULE-COMPLIANCE is a "requirements specification".
It can be used in standards documents to say in
a formal way what must be implemented by an SNMP agent
to conform to the standard. It can also be used in
a Request for Proposal to indicate what you want.
And finally, it can be used by management applications
to say what must be implemented by an SNMP agent so
that the management app can work.

A AGENT-CAPABILITIES is a formal specification of
what is implemented by an SNMP agent. It doesn't
indicate what instances are presently in existance.

Are MODULE-COMPLIANCE and AGENT-CAPABILITIES used?
This is an long running question, with a very
spotty answer. Part of it's problem is with
the definition of what "implemented by the SNMP
agent" means.

Regards,
/david t. perkins