Subject: Re: Proposed Update to Netconf Charter

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 29 Jun 2005 13:46:47 -0700

Hi -

> From: "Sharon Chisholm" <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, June 29, 2005 1:33 PM
> Subject: Proposed Update to Netconf Charter
...
> As promised, here are the proposed updates to the  Netconf charter to cover
> the work coming down the pipe:
>
> "Additional phase 2 work including:
>
> - Requirements and Guidelines for defining Netconf content to enable
> interoperable, high-quality and usable netconf implementations. Requirements
> will be defined around specification language,  access control, compliance,
> backwards compatibility, depicting relationships, event specification, and
> application error message specification.
>
> - An initial set of application-level re-usable data types such as IP
> Addresses, MAC addresses, etc. This definition would be compliant to the
> above defined requirements and guidelines for Netconf content.
>
> - An XML Schema for reporting information about the Netconf system. This
> definition would be compliant to the above defined requirements and
> guidelines for Netconf content.
>
> - A netconf protocol specification for asynchronous messaging to enable the
> sending of events. This must preserve the netconf layers."
...

I'm glad to see access control mentioned.  Is the intent to define an
interoperable access control policy representation?

Randy

--
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, 05 Jul 2005 09:26:37 -0700

Sharon Chisholm wrote:

<chair-hat-on>
I have some real concerns with the wording of this charter text,
but rather than focus on that, let's just try to agree on a bullet list
form of the charter.

I would much rather see agreement on specific features first,
(and then let people propose solutions, from which the WG
may select starting points for 1 or more standard documents),
rather than have the WG deal with an ad-hoc array of individual
submissions, as they come in.
</chair-hat-on>

[In the interest of transparency,  I am posting my
personal preferences for charter extensions]

<chair-hat-off>
Clearly, the addition of notifications is important to many people,
and its already in the charter, so that seems like a no-brainer.
However, a clean solution across all application mappings was
not achieved in the first attempt, so let's see what new ideas
come in this time around..

I also think that core data types are critical.
There is actually no reason whatsoever this document couldn't have been
published years ago -- it has no coupling to NETCONF at all -- it is just
more XSD types to NETCONF.

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 am also interested in the "SW image load" channel that has been
discussed in the past.  Often config reloads are coupled with image
reloads, and it would be nice if NETCONF could integrate some
SW image management features to support this requirement.
</chair-hat-off>

Andy

>hi
>Sharon Chisholm
>Nortel 
>Ottawa, Ontario
>Canada

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 5 Jul 2005 14:51:48 -0400

Hi Andy,

> 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. 

David Harrington
[email-masked]

---

From: "David T. Perkins" <[email-masked]>
Date: Tue, 5 Jul 2005 13:53:54 -0700 (PDT)

HI,

Two specific items...
1) I don't see the need for contexts in NETCONF data modeling,
   since contexts are simply "a mechanism to add extra
   indexing when the MIB designer failed to predict the future
   evolution of technology" (or bandaid for poor MIB design).
   With XML, I don't really believe this limitation is
   present, and, thus, a "context" will not be needed.

2) SNMP VACM access control is based on
    1) the identication of the management information
        (the variable name)
    2) the operation type (read/write/notify)
    3) the security model
    4) the security level
    5) the context
    6) the group
   It doesn't depend on the value of object instance. This
   has resulted in MIB design patterns where objects are
   made (unnaturally) into index object(s). The usual
   case is where the security name (or group name)
   is made into an index. Many other systems, especially
   data base systems have access control based on
   data values.

   In the work that I have done explaining VACM, the
   concept that what security level is used can affect
   what can be accessed is always a very big surprise.

   So far, there is a single security model. If several
   were present, then the number of entries in the VACM
   table could increase by a factor of the number.

   In general, the SNMP acess model is unlike anything
   that most users are use to. Thus, they can not
   understand it, and its richness is typically never 
   used. It is also typically not used because the
   objects used by management apps are not typically
   characterized. Thus, most systems that I've seen
   provide no restriction to management platforms, and
   any restriction is done by a management platform
   as to which management applications any specific
   user can run.

   Thus, I would characterize VACM as completely missing
   the target. It is too complex for typical usage,
   and not rich enough for realworld usage.

Regards,
/david t. perkins

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 5 Jul 2005 23:52:50 +0200

>    present, and, thus, a "context" will not be needed.

Using XML does not prevent MIB designers from failing to "predict
the future evolution of technology". Once you cast an XML schema
into stone, you can screw up as well. The hope, however, is that
we do not need to introduce an extra mechanism like contexts to 
fix such problems.

>    what can be accessed is always a very big surprise.

A story from real life here. I was trying to setup a subversion
server (subversion is basically a better cvs version control 
system) using apache and the webdav/deltav modules. I wanted to
make the configuration such that users who have authenticated
using a cleartext channel will be treated differently from
users who have authenticated over an encrypted channel. So far,
I have not managed to do this in a nice way because the 
authorization decision only knows whether someone has been
authenticated but not how this was carried out. I then realized
that SNMP actually got this right and I am still surprised that
I have not found someone to explain me how this can be done
nicely in the above mentioned scenario.
 
>    and not rich enough for realworld usage.

This may be true. The main problem with VACM is that the burden of
defining suitable security profiles is left to the operators who
really have other things to worry about. So what is left are in
most cases the "default" read-only and read-write profiles.

If we do netconf access control, we should investigate how command 
line interfaces typically deal with access control. We should not
constrain ourself by the VACM design since the number of non-default 
VACM tables I have seen on production systems is close to zero. If
someone has different experiences with deployed VACM configurations,
please speak up.

/js

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 5 Jul 2005 14:51:28 -0700

Hi -

> From: "David T. Perkins" <[email-masked]>
> To: "David B Harrington" <[email-masked]>
> Cc: "'Andy Bierman'" <[email-masked]>; "'Sharon Chisholm'" <[email-masked]>; <[email-masked]>
> Sent: Tuesday, July 05, 2005 1:53 PM
> Subject: RE: Proposed Update to Netconf Charter
>
> HI,
>
> Two specific items...

However, netconf adds the notion of configuration datastores.
If there is ever any reason to treat different configuration datastores
differently, they'll need to be accounted for in the access control
model.  To me they resemble the SNMPv2p temporal domains,
which were part of what eventually morphed into contexts.

>    data base systems have access control based on

All the cases I have seen of using indexing information in conjunction
with VACM have been driven by the need to conveniently represent
ownership, rather than any requirement for the access control policy
to be sensitive to either the value of the object being set or the
value being proposed.

>    what can be accessed is always a very big surprise.

I believe this is more a comment on the level of awareness of
what goes into forming a security policy, than it is on VACM.
If access control policies for netconf cannot distinguish whether,
for example, the communication channel is encrypted or not,
then there's a serious defect.

>    table could increase by a factor of the number.

Only the vacmSecurityToGroupTable and vacmAccessTable
would be affected, though I think twisting VACM into securing
netconf data would be, well, twisted.  :-)

>    that most users are use to.

Agreed.

>   Thus, they can not

I don't think these conclusions flow solely from the fact
that VACM is "different".  I think *any* non-trivial access
control model will be at risk of these same problems.

>    and not rich enough for realworld usage.

I don't think anyone has suggested using VACM for netconf.
The heart of DavidH's question is how would access control
for netconf need to be different from VACM.

For example, if there is a need to control access to different portions
of the configuration based on a notion of ownership, then if one used
something like xpath to represent that aspect of the policy, one might
end up putting "owner strings" in, and end up with something uncomfortably
(from your perspective) similar to VACM's way of coping with the ownership
concept.

All this leads to the fundamental question of how much expressive power
netconf access control policies will need.

Randy

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 06 Jul 2005 10:18:33 -0700

>>>>> On Tue, 5 Jul 2005 23:52:50 +0200, Juergen Schoenwaelder <[email-masked]> said:

Juergen> I wanted to make the configuration such that users who have
Juergen> authenticated using a cleartext channel will be treated
Juergen> differently from users who have authenticated over an
Juergen> encrypted channel.

I agree this is actually a nice thing about SNMP.  Users of mine
actually do just this because they have different avenues of security
coming in.  Most system administrators would probably even like to do
something like this for telnet vs ssh, but can't, so they do the only
other acceptable thing which is to turn off telnet instead because
doing anything else would be completely insecure.

Juergen> If we do netconf access control, we should investigate how
Juergen> command line interfaces typically deal with access
Juergen> control. We should not constrain ourself by the VACM design
Juergen> since the number of non-default VACM tables I have seen on
Juergen> production systems is close to zero. If someone has different
Juergen> experiences with deployed VACM configurations, please speak
Juergen> up.

I have described before in front of microphones that I think in an
ideal world we need some sort of pseudo-API in our RFCs that describe
*how* you need to use the data.  IE, setup_new_user(username,
securitylevel, ...) would be described to perform these particular
SETs in SNMP to the mib objects.  This is totally independent of the
protocol.  Netconf needs something as well, IMHO, because if you think
just having the data in XML will let you magically stuff it in with
one command you're missing the very big light on the front of the
train that is about to run you over.  Unfortunately, it's not that
easy, because you need to worry about testing for existence of user
names that already exist, do an replace if they do and you actually
wanted this, or abort if you didn't.  Then ...  Anyway, high level "to
do this frequent task, follow these steps" would be a great boon to
application writers and would potentially convince them to design
decent infrastructure in their agents and managers.

I normally try to shy away from talking about a particular project of
mine, but sometimes it serves as an example so I'm going to break my
personal rule this time.  In Net-SNMP we had issues with the
complexity of the VACM for a long time as well.  Having said that, we
have users that are using probably every aspect of its complexity in
their environments.  The problem wasn't that it isn't useful, it was
that it's hard to understand and more importantly isn't needed for the
95% case.  So, to fix this we added a ton of documentation about how
to set it up and added a few very simple configuration wrappers for
the 95% case that are easy to understand.  The majority of our users
probably have lines similar to this in their snmp agent configuration
files:

  rocommunity public
  rwuser      wes

And they're done.  In 2 lines they've added like 8 rows to the VACM
tables without knowing anything about it.  It's this sort of simple,
common-case API that the RFCs need to offer readers.  With the advent
of the above "wrapping" configuration items and with the documentation
we get very few questions now, and if we do its frequently from people
trying to understand the more complex scenarios because they actually
need it.  (as an aside the above configuration tokens actually have
additional parameters that add a single oid-tree restriction, add
minimum security level (default is authNoPriv, etc)).

Visualizing how the whole ball of wax works is hard.  Unfortunately,
in any system where you have a high degree of variation in how
something needs to work you're not going to get away from that.  The
best you can do is to try and offer *both* a simple case and a hard
case.  The problem with our RFCs is that 99% of the time because we
need the hard cases to exist, that's all we offer rather than offering
both.

(ok, as long as I'm breaking rules...  pet project 2 for the day is
visualizing SNMPv3 VACM configuration from live data pulled from the network:

  http://net-policy.sourceforge.net/screenshots-2004-07-28/viz_snmpv3.png
)
-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

---

From: Andy Bierman <[email-masked]>
Date: Wed, 06 Jul 2005 17:59:07 -0700

>doing anything else would be completely insecure.

We've discussed this in many forums before and many people claim
this is an administrative issue, solved (for example) by disabling
telnet support on devices and enabling ssh instead.

There's no reason you can't have an element in the 'sessions' data model
that describes the security-level in use.  The agent can access the data
as well (implementation-specific).

>decent infrastructure in their agents and managers.

I have been spending some cycles recently, trying to optimize some code 
design
for NETCONF's strengths, and this is a critical area.  The relationship 
between
the data-driven approach (e.g., MIBs) and the object-level RPC method 
approach
does not need to be understood by the NETCONF agent engine.  IMO, there does
not always have to be a mapping between them either, and that's why the 
2 tier AC model
I suggested is decoupled -- RPC method access and data model access are 
separate.

This is probably not the mailing list to debate API design, but the protocol
supports individual RPC methods for a procedural approach, and it also 
supports
a core operation set on a configuration datastore represented as an XML 
instance
document.  IMO, there is no intention in the document to constrain RPC usage
in any way, and any coupling between static data models and particular RPC
methods is outside the scope of the protocol.

For example,  in SNMP we would define a "resetDevice" OBJECT-TYPE macro
with a MAX-ACCESS or read-write, to reset the device.  But this isn't data.
There are no semantics in the value range, only semantics in the reset 
action itself.
These "exec commands" do not need a data-oriented access mechanism.
It can also be argued that high-level RPC methods that provide a procedural
interface to some configuration tasks (e.g., add_bgp_peer) can stand on 
their own
without being coupled to a static data model that can be accessed with 
edit-config.

Andy