Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)

["ietfdbh" <[e-mail]>]

Hi,

I have a question.
This document says the model is based on real-world CLI configuration of the
SNMP system.
Which vendor's CLI's were used as the basis for this model?
Are the vendors approach to CLI configuration of SNMP substantially
different or similar?

I am interested in understanding whether the bases for the model have
substantially different approaches, so we can see that the YANG model can
handle a significant range of implementation differences. 
I would be concerned if this model was derived from, for example, the Cisco
CLI and from other vendors who deliberately use a Cisco-like CLI, without
consideration of CLIs that are substantially different than Cisco's, or if
the model was derived from the configuration needs of a particular SNMP
toolkit, used by all the vendors in the sample.
I do not expect a list of the specific vendor's CLIs to be put into the
text, but I think some discussion of the size and characteristics of the
sample used to derive the new model should be discussed in the document
text.

David Harrington
[e-mail]
[phone]

> -----Original Message-----
> From: netmod [mailto:[e-mail]] On Behalf Of Juergen
> Schoenwaelder
> Sent: Tuesday, December 10, 2013 3:29 PM
> To: Randy Presuhn
> Cc: [e-mail]
> Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)
> 
> On Mon, Dec 09, 2013 at 03:59:19PM -0800, Randy Presuhn wrote:
> > Hi -
> >
> > > From: "David Kessens" <[e-mail]>
> > > To: <[e-mail]>
> > > Sent: Monday, December 09, 2013 2:25 PM
> > > Subject: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)
> > ...
> > > I would hereby like to start a Last Call for:
> > >
> > > http://tools.ietf.org/html/draft-ietf-netmod-snmp-cfg-03
> > >
> > > Please indicate your support by Dec 20, 2013. We appreciate any type
of
> > > feedback, from "I have read the document and I like it" to more
lengthy
> > > reviews and implementation reports.
> >
> > I haven't the time or interest to spend a lot of time on this, but a
cursory
> > look at the VACM section leaves me quite concerned.
> >
> >
> > On page 49, the draft states:
> >              "VACM Groups.
> >
> >               This data model has a different structure than the MIB.
> >               Groups are explicitly defined in this list, and group
> >               members are defined in the 'member' list (mapped to
> >               vacmSecurityToGroupTable), and access for the group is
> >               defined in the 'access' list (mapped to
> >               vacmAccessTable).";
> >
> > It's not clear to me whether the Yang model can represent all valid
> > configurations of the MIB, and (see below) I have an uneasy feeling
> > that in some cases it cannot.   Constraints like "A certain combination
> > of security-name and security-model MUST NOT be present in
> > more than one group" strongly suggest to me that this is a very
> > unnatural way of modeling this.   What is gained by making this
> > model substantially different from the resource being managed?
> 
> The cited constraint "A certain combination of security-name and
> security-model MUST NOT be present in more than one group." comes from
> the way the VACM tables are organized. The vacmSecurityToGroupTable
> table is indexed by (vacmSecurityModel, vacmSecurityName). We are
> simply documenting a VACM constraint.
> 
> What is gained by the model layout? Groups become a first class
> citizen and members are naturally assigned to groups and most
> importantly you do not have to perform a join of several tables in
> order to understand the access policy of a certain group. With SNMP,
> the editing semantics cause a table organization that seems more
> complex than needed and that have certain side effects.
> 
> > I recognize that the transactional model is different here, but I'm
> > also concerned how some VACM usage scenarios would play
> > out in this model.  Consider, for example, a routine task like
> > re-assigning a "user" (identified by a [SecurityModel, SecurityName]
> > tuple) from one group to another.  It's trivial and seamless in VACM
> > (simply set a new value to vacmGroupName) but it's unclear what
> > the recommended sequence of operations would be in this proposal.
> 
> You delete the user form one group and at the same time add it to the
> target group. This feels quite natural and NETCONF can do such changes
> in an atomic edit-config.
> 
> > On page 49, the draft states:
> >
> >          list member {
> >              key "security-name";
> >              min-elements 1;
> >              description
> >                "A member of this VACM group. According to VACM, every
> >                 group must have at least one member.
> >
> > AFAICT, RFC 3415 contains no such statement, and there are legal
> > VACM configurations that seem at odds with it.  The notion of a
> > "member" of a group is only mentioned in passing, and in a set-
> > theoretical sense at that.
> 
> The question is what really defines a group in VACM. Section 7.2. says:
> 
>    [...] Within the View-Based Access Control Model, a groupName is
>    considered to exist if that groupName is listed in the
>    vacmSecurityToGroupTable.
> 
> In order to be listed in the vacmSecurityToGroupTable, the group must
> have a member (since the vacmSecurityName is part of the INDEX). Hence
> the above statement.
> 
> > Consider the case where one or more entries exist in the
> > vacmAccessTable with an index of vacmGroupName="foo", but no
> > corresponding entries exist in the vacmSecurityToGroupTable.  Such
> > configurations are explicitly supported by RFC 3415.
> 
> We could easily allow for that as well by removing "According to VACM,
> every group must have at least one member.".
> 
> > A quick look at the Security Considerations section leaves me even
> > more worried.   An important consideration in the design of the
> > VACM MIB was to be absolutely clear on the impact of the order
> > of operations on security so that, for example, provisioning access
> > permissions for a new user (or set of users) could be interrupted
> > without creating security holes.  This is an extension of my concern
> > about how trivial VACM operations could become quite elaborate in
> > this model.
> 
> I have re-read the Security Considerations section and I am not sure
> what makes you worried regarding order of operations and such things.
> 
> /js
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod