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

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Jan 2014 14:58:35 +0100

On Fri, Dec 13, 2013 at 02:31:24PM -0500, ietfdbh wrote:
> 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?
> 

I suggest you go through the mailing list archive. This data model has
been reviewed by people familiar with widely used SNMP code bases. I
do not think it is the task of the WG to determine to what extend SNMP
implementations are fully compliant to the relevant SNMP and MIB
standards. (Speaking as contributor.)

/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: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Jan 2014 15:01:08 +0100

On Fri, Dec 13, 2013 at 01:09:44PM -0500, ietfdbh wrote:
> 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.
> 

If you know SNMP CLI configuration interfaces out there for which the
current configuration data model does not work, please let us know the
details. The document has evolved over time and it will be a rather
pointless exercise to determine why every detail worked out the way it
is. (writing as contributor)

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Jan 2014 15:22:13 +0100

On Tue, Dec 10, 2013 at 02:12:09PM -0800, Randy Presuhn wrote:

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

You can create an 'orphaned' (or better empty) group as well in the
Yang model if that is really useful.

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

Exactly. And it seems RFC 6536 also lists members as a leaf-list of a
group. To move a member in RFC 6536, you also need to make two changes.

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

Well, this might have been your intention but the text quoted above
actually can be read to mean something different...

> Thus my example:
> 
> > > 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.".
> 
> That would be fine with me.

OK. This is seems easily to change and it removes one weird looking CLR
from the YANG data model.

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

But I assume SNMP had to be rather explicit about these things because
you would have to potentially deal with a sequence of write operations
in order to make a conceptual change. With NETCONF, you can execute
much bigger atomic changes that you would typically expect with SNMP.
But if your concern boils down to the following RFC 3415 text, then
we can add something similiar to the YANG I-D:

                 When creating MIB views, it is strongly advised that
                 first the 'excluded' vacmViewTreeFamilyEntries are
                 created and then the 'included' entries.

                 When deleting MIB views, it is strongly advised that
                 first the 'included' vacmViewTreeFamilyEntries are
                 deleted and then the 'excluded' entries.

(Well the last one is somewhat pointless since one would not have to
delete every 'row' in the include/exclude lists individually with
NETCONF.)

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

Well it can't hurt to remind implementors that they need to ensure
that a transaction stays a transaction and does not fall apart due to
external events and it might be wise to remind them that failure to do
so may become a security issue. We can try to find some wording for
this.

/js

---

From: "ietfdbh" <[email-masked]>
Date: Mon, 6 Jan 2014 15:10:08 -0500

Given that the goal of the IETF is to develop standards in support of
interoperability, I am concerned about the interoperability between
standards-compliant NMSs and SNMP MIBs configured using SNMP versus SNMP
MIBs configured using the YANG modules.

I am less concerned about the interoperability between standards-compliant
NMSs and non-compliant implementations of SNMP MIBs.

Will a relevant standard SNMP MIB implementation be compliant if the YANG
module is used to do the configuration?
Is it possible to configure an SNMP MIB using the YANG module (in a
compliant manner) that would result in the implementation not being
compliant to the MIB standard, whereas using SNMP (in a compliant manner)
would result in the implementation being compliant?
Put more simply, can using the YANG *cause* an implementation of the
relevant MIB to be non-compliant to the MIB standard?

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

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Monday, January 06, 2014 8:59 AM
> To: ietfdbh
> Cc: [email-masked]
> Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 9 Jan 2014 14:05:32 +0100

On Mon, Jan 06, 2014 at 03:10:08PM -0500, ietfdbh wrote:
> 
> Will a relevant standard SNMP MIB implementation be compliant if the
> YANG module is used to do the configuration?

This is fairly abstract and general question. For me, an SNMP MIB
implementation will be compliant if it complies to the SNMP MIBs it
implements. Most SNMP agents I have seen read configurations from CLIs
and/or configuration files. Hence, I believe it is possible to have
other configuration interfaces. I also believe they are being used to
setup SNMP agents. (Frankly, I never configured VACM using the SNMP
tables - I always resorted to configuration files or CLIs. But then
this might have just been my lack of having access to smart software
to do this job for me. ;-)

> relevant MIB to be non-compliant to the MIB standard?

We are trying hard to ensure that this interworks nicely. If there are
any things that may cause problems that we might have missed, by all
means let us know so that we can take a look at it. For example, we
might have to say something about spin locks to handle situations
where a sequence of SNMP set operations in interleaved with NETCONF
updates. This is very useful input and appreciated.

The goal of this effort is to provide implementors with a YANG SNMP
configuration interface that to the best of our knowledge does not
cause conflicts with the implementation of SNMP configuration MIB
modules and I believe the IETF is the best place to do this work. The
alternative of doing this work is to let every NETCONF implementor
come up with his/her own model that may but various undocumented
constraints on the SNMP interface - I do not think this helps with
SNMP interoperability (and it surely does not help with NETCONF
interoperability either).

So please, tell us about any technical issues we might have missed.
This helps us much more than abstract discussions.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 11 Jan 2014 10:13:00 +0100 (CET)

Hi,

"ietfdbh" <[email-masked]> wrote:
> 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.

Operational state is out of scope for this draft.

The RFC 6643 translated MIB modules can be used.

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

RowStatus is an SNMP-specific construction.  A row that is not active
exists in the SNMP agent, but is "unavailable for use by the managed
device".

In NETCONF the transaction can be much bigger than traditional SNMP;
which means that a client can send everything in one operation, and
does not have to carefully construct multiple PDUs to first inactivate
some rows, then modify the values, then re-active the rows.

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

Yes.

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

This is a good point, thank you for catching it!

Implementations allowing both write access via SNMP and NETCONF should
be recommended (required?) to bump the spinlock when NETCONF modifies
the relevant parts of the SNMP tables.

(this applies of course to all (three) spin locks in these mibs)

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

These addresses are used in Appendix A.1 where it shows a listening
endpoint.  0.0.0.0 and :: are the IP any addresses used to listen on
any interface.

But we can change this to a documention-special address if the example
becomes more clear this way.

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

NETCONF generally over a secure and encrypted transport (this is
pointed out in the Security Considerations section) hence the SNMP
cloning mechanism is not needed.  I am not sure what kind of text you
are looking for.

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

The keys and the engineID have been copied from RFC 3414.

> 7) I am having some difficulty understanding the purpose of the YANG snmp
> models.

The same purpose as any YANG or MIB module - to provide a standardized
way to manage the underying subsystem if NETCONF/YANG or SNMP/MIBs are
used.

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

This might be one scenario.

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

usmCloneFrom is never intialized - when read it is always
zeroDotZero.  It is only used when a new user is created over SNMP.

So your statement that keychange cannot be done is not correct.

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

No.

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

Well, we don't think the models lack anything...

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

Another scenario are deployments (operators told the IETF that they
exist long ago) where SNMP agents run in read-only mode and other
mechanism (typically proprietary CLIs) are used to configure the SNMP
agent. This YANG configuration data model clearly targets such
deployments (that apparently do exist). It still allows to interwork
with SNMP-managed applications.

/martin

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 11 Jan 2014 01:56:01 -0800

Hi -
 
> From: "Martin Bjorklund" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Saturday, January 11, 2014 1:13 AM
...
> cloning mechanism is not needed.  I am not sure what kind of text you
...

There's more to cloning than transport security.  The way keyChange works
requires the cloner to know the authKey/privKey of the clone-from user as
well as the secret key(s) to be used for the new user.

The Netconf client does not need to know a cloneFrom authKey/privKey to
create new users, nor does it need to reference an existing user to clone
from.  Both of these are paths permitting the potential creation of users with
combinations of protocols not represented in the usmUserTable, or to which
clone access would have been effectively blocked by an unpublished key change.
This could, for example, result in a situation where the SNMP security administrator
has blocked the ability for delegated administrators to create a noAuth/noPriv
user, but left them the ability to create auth/priv users; yet the Netconf interface
would restore that ability to those delegated administrators.

That's a fairly obvious security implication.  There are probably subtler ones, too.
I don't know whether you consider it a problem, but the properties *are*
different and should be systematically thought through and documented.

Randy

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 11 Jan 2014 11:51:34 +0100 (CET)

> different and should be systematically thought through and documented.

Ok, I agree it makes sense to document this.  It could be viewed as a
feature since we now have a standardized way for the "SNMP security
administrator" to actually set up usm entries for cloning.  These
delegated administrators don't have to have NETCONF access of course.

/martin

---

From: B Lukovic <[email-masked]>
Date: Fri, 17 Jan 2014 18:16:31 -0500

Hi,

Re: target address/target params tables.
snmpTargetParamsName is not mapped into yang module.
This prevents agent from restoring snmp configuration after 
restart/reload (assuming configuration is yang based).
E.g. agent is configured through snmp, "t1" and "t2" are rows in 
targetAddress, "p1" is row in targetParams.
Both rows in targetAddressTable:
     "t1",...,"p1",...
     "t2",...,"p1",...
"point" to the same row in targetParamsTable:
     "p1", "v2c", "public"
saved as yang, targetParams row(s) are merged with rows of targetAddress:
     <target>
       <name>t1</name>
       ...
       <v2c>
         <security-name>public</security-name>
       </v2c>
     ..
     </target>
     <target>
       <name>t2</name>
       ...
       <v2c>
         <security-name>public</security-name>
       </v2c>
     ..
     </target>

SNMP agent initialized from this config would not know the original 
index ("p1") used in targetParamsTable.
One can argue that "locally arbitrary" in description of 
snmpTargetParamsName allows agent to reassign indices,
but I believe this would lead to confusion.

Possible solutions:
-  create "targetparams" list (index = leaf "name"), replace "params" 
choice with leaf "params" with type leafref { path 
"/snmp/targetparams/name" }
-  leave "params" choice, replace optional "notify-filter-profile" leaf 
with mandatory "param-name" leaf,
    explain relation between "param-name" and 
"notify-filter-profile/name" in description of "param-name"

     Borislav

On 1/11/2014 4:13 AM, Martin Bjorklund wrote:
> Hi,
>
> "ietfdbh"<[email-masked]>  wrote:
>> Hi,
>>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>