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

From: David Kessens <[email-masked]>
Date: Mon, 9 Dec 2013 14:25:30 -0800

Hi,

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.

Thanks!

David Kessens
co-chair netmod wg
---

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 9 Dec 2013 15:59:19 -0800

Hi -

> From: "David Kessens" <[email-masked]>
> To: <[email-masked]>
> Sent: Monday, December 09, 2013 2:25 PM
> Subject: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)
...
> 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?

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.

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

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.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Dec 2013 21:29:11 +0100

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

> about how trivial VACM operations could become quite elaborate in

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: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 10 Dec 2013 14:12:09 -0800

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: "David Kessens" <[email-masked]>; <[email-masked]>
> Sent: Tuesday, December 10, 2013 12:29 PM
> Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)
>

> simply documenting a VACM constraint.

I understand that the constraint is a consequence of VACM's indexing
structure (and a logical requirement for non-ambiguity).  My point is
that in the Yang model (1) the reason for such a constraint becomes
non-obvious and (2) it has implications for operations like changing
a user's group membership.

> complex than needed and that have certain side effects.

The structural change comes with what to me seems an important
semantic change.    In VACM, a "user" ([securityLevel,securityName]
tuple) is associated with a group whose members should enjoy the
same access permissions, and that association is easily changed
by the security administrator.  In the propose Yang model, what
was merely an associated becomes a *structural* "element-of"
relationship.

In VACM, the administrator may delete the group, but leave
the "members" in place (though deletion of the group means
a categorical "access-denied" for those "orphaned" members.)
Not possible in the Yang model.

> in an atomic edit-config.

Requiring deletion of a user in order to change access permissions seems
odd.  Yes, it would work, but it seems very unnatural to me.  I guess it
depends on how one thinks about this stuff.
  
> have a member (since the vacmSecurityName is part of the INDEX). Hence

Ok, I see how you came to that understanding, though FWIW that text was
put there to explain the behaviour of the ASI "noGroupName" status.

When I think about "groups", I generally have in mind the set of
vacmAccessTable entries with the same vacmGroupName, and
when I think about "members", it's the set of vacmSecurityToGroupTable
entries with a matching value of vacmGroupName.

In *that* frame of reference (which more closely maps to what I'd
expect a user interface to present) it's perfectly reasonable to talk
about a group with no members.

> every group must have at least one member.".

That would be fine with me.
 
> what makes you worried regarding order of operations and such things.

Simple example.  Consider an access control policy expressed in the
vacmViewTreeFamilyTable containing entries with overlapping
vacmViewTreeFamilySubtree / vacmViewTreeFamilyMask and
vacmViewTreeFamilyType values of both included(1) and excluded(2).

There are lots of ways to formulate the constraints on how to "safely"
bring such a policy into being, but in general one needs to ensure that
any given "excluded" entry is put into service no earlier than any
"included" entry that would overlap that portion of the OID tree.
The Netconf user must ensure that "commits" don't happen in a
way that would defeat this, and the implementation, in its interface
into VACM, needs to make sure that however it causes the MIB
updates to happen honors these constraints as well.

Another example: security administrator updating his/her own
group membership. (Analogous to a sysadmin conscientiously
using "su" only when absolutely necessary.)  If this becomes a
"delete-and-re-instantiate" operation with netconf, then the
instrumentation needs to be done in such a way that the
delete/create is somehow interpreted to be a single MIB
attribute write.  (If it is blindly mapped to a delete/create
cycle internally, then there need to be sufficient protections
in place so that, for example, power fail immediately after delete
doesn't leave the administrator locked out.)

Perhaps all this is blindingly obvious to implementors, in which
case the document doesn't need to mention it.

Randy

---

From: "ietfdbh" <[email-masked]>
Date: Fri, 13 Dec 2013 13:09:44 -0500

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
[email-masked]
+1-603-828-1401

> -----Original Message-----
> From: netmod [mailto:[email-masked]] On Behalf Of Juergen
> Schoenwaelder
> Sent: Tuesday, December 10, 2013 3:29 PM
> To: Randy Presuhn
> Cc: [email-masked]
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: "ietfdbh" <[email-masked]>
Date: Fri, 13 Dec 2013 14:31:24 -0500

Hi,

It occurs to me that another question should be asked about the
implementations used as the basis for this model.
Were all the SNMP/MIB implementations used fully compliant to the relevant
SNMP and MIB standards?

David Harrington
[email-masked]
+1-603-828-1401

> From: netmod [mailto:[email-masked]] On Behalf Of ietfdbh
> Sent: Friday, December 13, 2013 1:10 PM
> To: 'Juergen Schoenwaelder'; 'Randy Presuhn'
> Cc: [email-masked]

---

From: "ietfdbh" <[email-masked]>
Date: Fri, 13 Dec 2013 18:31:52 -0500

Hi,

I apologize for not getting a review done earlier in the process.

After a quick comparison between rfc3413 and ietf-snmp-common, I have some
comments and concerns.

I question the statement in the Introduction, "The configuration model is
consistent

   with the MIB modules defined in ."

1) I am concerned that StorageType is not modeled.

I understand the different persistence approaches; I don't consider
StorageType to be only about persistence of dynamically-set data, and which
datastore to use, but rather reporting on implementation choices. 

Looking at RFC3413 as an example, I would think an operator might want to
know whether an SnmpTargetAddrEntry is implemented in RAM or ROM. Being able
to read the StorageType of the existing table could save a client the chore
of weeding out rows of configuration data that are sure to fail, if the row
is not writable. At a minimum, I think this should be reported as
operational state, so an operator can determine why a particular
configuration attempt is failing.

2) I am concerned that RowStatus is not modeled. Rowstatus objects
constrains how configuration can be performed on the row. For example,
snmpTargetAddrRowStatus states that TDomain and TAddress may not be modified
if the value of RowStatus is active(1). I assume there was a very good
reason for putting that constraint into this table. Does NETCONF get to just
ignore that constraint, and overwrite the values of TDomain and TAddress
even if RowStatus is active? 

This has nothing to do with persistence across reboots; it has to do with
controlling how the row can be modified at runtime, and how a row can be
created and deleted. Some of these constraints are to ensure that changes
cannot be made in the middle of an operation, thereby affecting the
operation. Some of these constraints relate to security, such as the control
of who gets notified of a security violation. Having NETCONF
create/modify/delete rows while ignoring the RowStatus rules would seem to
create both operational and security risks.

3) "When the snmpTargetAddrParams object contains a reference

              to a non-existing snmpTargetParamsEntry, this choice does

              not contain any case, and vice versa.";

Is this consistent with RFC3413: 

"            Until instances of all corresponding columns are

            appropriately configured, the value of the

            corresponding instance of the snmpTargetAddrRowStatus

            column is 'notReady'.

            In particular, a newly created row cannot be made

            active until the corresponding instances of

            snmpTargetAddrTDomain, snmpTargetAddrTAddress, and

            snmpTargetAddrParams have all been set."

Are all required objects in target and params required when using NETCONF to
create a row?

3) From RFC3414: "The use of usmUserSpinlock is to avoid conflicts with
another SNMP command generator application which may also be acting on the
usmUserTable." The YANG model doesn't support spinlock; how does Netconf
avoid conflicts with other command generators working on the usmUserTable?
Let's assume a command generator has started building the necessary tables,
using spinlock to differentiate their processes from other processes, and
Netconf interrupts that process. 

4) Is there a reason the example for configuring the engine in appendix A
uses ip=0.0.0.0 and ip=::? I didn't notice any special semantics associated
with this value in the description of <ip> or inet:ip-address. RFC5737
contains blocks of addresses reserved for documentation purposes.

5) The security implications of not using the RFC3414 method for cloning and
key change are not discussed.

6) I think the examples could benefit from a few comment lines to indicate
why the choice of values, such as the value of engineID, the values of IP
addresses, and the value of the key in the usm config example.

7) I am having some difficulty understanding the purpose of the YANG snmp
models. I would assume one might use the YANG model with NETCONF to
initially configure the SNMP subsystem on a device, and then to subsequently
use SNMP based on that configuration. But the YANG model is omitting objects
that are REQUIRED for some aspects of SNMP to work properly. For example, as
far as I can tell, an SNMP admin (or security admin or SNMP application)
could not perform a keychange operation using SNMP because the YANG model
would not have initialized the necessary SNMP objects, such as clonefrom.
But other than to say that the YANG doesn't include some of the objects
defined in the MIB, there is no discussion of the operational and security
implications of not configuring these objects for subsequent use in SNMP.

I guess the answer is that if you use Netconf and YANG to initially
configure USM, then you can only manage it in the future using NETCONF and
YANG; it seems that it stops being manageable via SNMP. SNMP-manageable
security and SNMP-manageable access control were important goals of the
SNMPv3 WG, as documented in RFC3411 design requirement sections A.1.2 and
A.4.

I question whether this document should be allowed to advance given this
lack of complete configuration of the targeted SNMP MIB modules, but if it
is, then I think it is really important to spell out the implications in an
operational considerations section, and in the security considerations
section.

David Harrington

 <mailto:[email-masked]> [email-masked]

+1-603-828-1401

From: netmod [mailto:[email-masked]] On Behalf Of David Kessens
Sent: Monday, December 09, 2013 5:26 PM
To: [email-masked]
Subject: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)

Hi,

     

Thanks!

David Kessens
co-chair netmod wg
---