Subject: Re: Proposed Update to Netconf Charter

From: Andy Bierman <[email-masked]>
Date: Tue, 05 Jul 2005 15:14:52 -0700

David B Harrington wrote:

>Hi Andy,
>
>  
>
>>Access control is also critical to get in place early on.
>>I prefer to start simple and evolve the complexity over time.
>>IMO, a mapping to ISMS should be a separate work effort,
>>and probably in that WG.
>>
>>NETCONF AC is unique because it is both "RPC method" and 
>>document oriented.
>>IMO, old approaches like VACM will be clumsy and/or bloated if
>>    
>>
>applied
>  
>
>>to NETCONF.  Some new innovation is required  here.
>>
>>    
>>
>
>I'm interested in your views about the uniqueness of netconf AC. 
>
>In SNMPv3, as you know, we found that all operations could be
>abstracted into read/write/notify types of operations for purposes of
>AC. There was not a real need to distinguish between GET, GETBULK, and
>other proposed GET-XXXX operations. Do you see a real need to
>distinguish between the various <get-xxx> RPC methods, etc., that
>would be initiated by an operator? 
>
>In the SNMPv3 isAccessAllowed() ASI, variableName names the instance
>of the managed object. Would netconf use a similar (XML-based)
>variablename to identify the instance of the managed object? 
>
>Do you expect that "documents" will be aggregations of objects that
>are not necessarily from the same XML subtree? I can see this if the
>document is an HTML web page; but if it is built from data elements
>defined as an XML instance, then would AC based on the underlying XML
>suffice? Cf: a varbind list with an aggregation of various managed
>objects. Do you have something different in mind for documents?
>
>In SNMPv3, we have contexts to differentiate MIB instances. I assume
>such a concept would also be needed for netconf. Do you agree? Is
>"running" and "candidate" about as deep as you need to go for netconf
>contexts, or do you need the greater depth found in the SNMP contexts?
>Do you anticipate a future need to be able to configure, for example,
>the XML instance for a specific blade in a server?
>
>I'm interested in your thoughts on this because VACM has not gained
>very wide acceptance, and a simpler AC model that could be used with
>both netconf's XML hierarchical naming scheme and SNMP's OID
>hierarchical naming scheme (or an XML-based SNMP naming scheme) could
>help both protocols. I'm also interested in probing how the
>requirements for netconf AC and SNMP AC might differ, since this could
>also have an impact on whether ISMS design should even try to be
>future-compatible with netconf. 
>  
>

Since you asked...

IMO, we need a simple 2-tier access control model
that is independent of higher layer abstractions.

1) access is by group-name, and a group contains a list of user names.
   A user can be included in any number of groups.

2) tier 1 is RPC method access, which is defined by the tuple:
      { namespace-uri, method-name }
   and access is granted by configuring via the tuple
      { namespace-uri, method-name, group-list }

   Example 1: access to the groups 'staff' and 'root' are granted for
   the edit-config method via the following configlet:

   <rpc-access>
     <namespace-uri>urn:ietf:params:xml:ns:netconf:base:1.0</namespace-uri>
     <method-name>edit-config</method-name>
     <group-list>root, staff</group-list>
   </rpc-access>

   Example 2: access to everybody given to 'my-own-method':
  
   <rpc-access>
     <namespace-uri>http://example.net/me/my-own/1.0</namespace-uri>
     <method-name>my-own-method</method-name>
     <group-list>all</group-list>
   </rpc-access>

3) tier 2 is data model access, and defined by the tuple:

  { operation-list, data-namespace, data-path, group-list }

where:
 
  operation-list is zero or more of the following strings:
     { notify, read, create, merge, replace, delete }
     [Shorthand: the term 'write' == create, merge, replace, delete]
  data-namespace is the URI identifying the data model namespace
  data-path is an absolute XPATH expression identifying the
     top-level data model node that this access applies
  group-list is a list of group names granted access

For example, root is given all access to the path 'users/user':

 <data-access>
   <operation-list>all</operation-list>
   <data-namespace>http://example.com/1.0</data-namespace>
   <data-path>/top/users/user</data-path>
   <group-list>root</group-list>
 </data-access>

Multiple overlapping entries need to be handled
and a sequential processing model needs to be defined,
but IMO this type of simple approach could be good enough to
start with.

>David Harrington
>[email-masked]

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: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 6 Jul 2005 00:43:56 +0200

>  group-list is a list of group names granted access

While all this sounds reasonable, I am really surprised that you
propose XPATH expressions given the lengthy discussion in the past
that XPATH expressions are too expensive for filtering. Or is it
because you expect access control on the 2nd tier not to be
mandatory to implement and an optional feature like XPATH 
filtering?

Sorry, I could not resist to ask this question. But despite this
somewhat polemic question, I do like the 2 tier approach that you
have outlined.

/js

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

---

From: Andy Bierman <[email-masked]>
Date: Tue, 05 Jul 2005 16:40:30 -0700

>mandatory to implement and an optional feature like XPATH 

I am envisioning that a simple absolute path expression be the mandatory
requirement and full XPATH expressions would be optional.  This restricted
XPATH is what we have within the 'rpc-error' structure, and the WG
already agreed on this simple string format which happens to be a
particular subset of XPATH.

>somewhat polemic question, I do like the 2 tier approach that you

I didn't really clarify the XPATH usage, but since you brought it up,
it would be a powerful way to specify access control filters.

I think this 2-tier approach makes sense because NETCONF is extensible,
and we can't hard-wire the tier-1 configuration.  Even though the document
seems to make a special case out of NETCONF operations, all the protocol
really has are RPC methods defined within specific namespaces.  We
need to deal with vendor (and maybe later standard) RPC extensions anyway.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 6 Jul 2005 02:00:06 +0200

> particular subset of XPATH.

I must have missed that. Makes it even more interesting since subsetting
XPATH for filtering was also rejected in favour of a home-grown filtering
mechanism.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 05 Jul 2005 19:11:19 -0700

>XPATH for filtering was also rejected in favour of a home-grown filtering

Actually this is totally consistent with the rpc-error design.
The user should be able to specify a qualified name (QName)
like 'error-info/bad-element', or specify a node via simple XPATH, like
the 'error-path' element.  

The error-path element is optional so even this trivial XPATH usage
can be avoided, if desired.

IMO this is not inconsistent with the WG's choice to use subtree filtering.
This is an extremely restricted subset of XPATH, much easier to
define than a subset to do some real filtering.

Andy

---

From: Vincent Cridlig <[email-masked]>
Date: Wed, 06 Jul 2005 09:59:35 +0200

Hi,

The tests made on our Netconf implementation shown us that XPath 
filtering is as fast as subtree filtering except
in the following situation: a XPath expression that is not an absolute 
path like '//user'

In that case, it is hard to predict what part of the data model is 
concerned. Two solutions were possible for us:
- parse the XML Schemas from our database and try to find the ones which 
have a "user" element
- build the whole configuration document and apply the XPath expression 
on it

The first approach is difficult to perform and suppose that all data 
models are defined with XML Schema (not DTD or other).
The second approach is time consuming.

We chose the second one since it's easier in our environment even if not 
satisfying.

To improve this, what I suggest is to modify XPath filtering a little bit.
Most programming languages allow to define a namespace context before 
applying an XPath expression to a document.
It would be nice to allow namespaces contexts definition in the Netconf 
requests:

<filter type="xpath">
    <expression>//net:network/if:interfaces/if:iface/if:name</expression>
    <ns-contexts>
        <ns-context>
            <ns-short>net</ns-short>
            <ns-long>urn:network:data:model</ns-long>
        </ns-context>
       <ns-context>
            <ns-short>if</ns-short>
            <ns-long>urn:network:interfaces:data:model</ns-long>
        </ns-context>
    </ns-contexts>
</filter>

Currently, a way to do something equivalent is the following:
<filter type="xpath">
//*[namespace-uri()='urn:network:data:model' and 
local-name()='network']/*[namespace-uri()='urn:network:interfaces:data:model' 
and 
local-name()=interfaces]/*[namespace-uri()='urn:network:interfaces:data:model' 
and 
local-name()='iface'/*[namespace-uri()='urn:network:interfaces:data:model' 
and local-name()='name']
</filter>

While the first one is easy to read and write for a human, the second is 
more difficult.

In both cases, it allows to bind easily the XPath expression to the 
right part of the data model.

I think the problem is similar in the case of access control which is 
somewhat the same process as XPath or subtree filtering (in the case of 
a read operation). To illustrate this, our implementation expresses the 
access control policy with XPath and uses the same methods to filter the 
document for access control or filtering operations.

Vincent CRIDLIG

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 6 Jul 2005 10:59:43 +0200

>            <ns-long>urn:network:interfaces:data:model</ns-long>

I think this WG is not the right place to change XPath. Some of us have 
quite some experience with adapted subsets and I prefer not to do this
again. Subsetting for conformance might be OK, adapting is IMHO a poor
choice.

If relative paths are a real issue, why can a device not use a hash table
lookup to find out where potential starting points in its schemas are?
Yes, this might require some more coding but at the end there is the
benefit that you do not have to invent something special which might
bite you when XPath gets revised.

/js

---

From: Vincent Cridlig <[email-masked]>
Date: Wed, 06 Jul 2005 11:36:13 +0200

Let me give more details about what I proposed.

The prefix concept is well defined in the XPath recommendation. I didn't 
invent this concept and I don't want to change XPath.

Using XPath prefix needs a namespace declaration. This is why I 
suggested to add some namespace declaration along with the Netconf request.
In fact, I might be wrong but I think it is not possible to fully 
support XPath without making it possible to send these declarations. 
These declarations are needed to build the expression context as 
described in the XPath recommendation.
If a manager sends an XPath request which contains prefixes, I don't 
know how an agent could guess the related (real) namespace URI.

Best regards,
Vincent CRIDLIG

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 6 Jul 2005 11:55:09 +0200

> know how an agent could guess the related (real) namespace URI.

Thanks for this clarification. This now sounds much more reasonable.
I guess I have to go back to the XPath specs.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 6 Jul 2005 15:31:14 +0200

> define than a subset to do some real filtering.

The future will tell us whether the mixture of some XPath here, a bit 
less XPath there and some required other mechanism with optional XPath
over there will be loved or seen as a curiosity.

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 06 Jul 2005 06:42:58 -0700

>over there will be loved or seen as a curiosity.

I think (hope) that over time, it will be common for NETCONF devices
to support the xpath capability, and perhaps subtree filtering will fade 
away.

As for QName vs. absolute XPATH expression, I think QName will be
used whenever possible (just as intended in rpc-error) since it is simpler.

Andy

---

From: "Tom Petch" <[email-masked]>
Date: Thu, 7 Jul 2005 12:35:41 +0200

<inline>
Tom Petch

----- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: <[email-masked]>
Cc: "'Sharon Chisholm'" <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 06, 2005 12:14 AM
Subject: Re: Proposed Update to Netconf Charter
<snip>
>    A user can be included in any number of groups.

I would like to see groups permitted to contain group-names as well as users, at
least in a simple tree structure (ie recursive membership not allowed).  This
has been a feature of Windows-style access control for many years and I would
not want to be without it, particularly when there are predefined groups (eg
from the provider of the software, not necessarily specified in a standard) to
help get the system up and running quickly.

>       { namespace-uri, method-name, group-list }

<snip>