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

From: Randy Presuhn <[email-masked]>
Date: Mon, 6 Jan 2014 10:11:43 -0800 (GMT-08:00)

Hi -

>From: Juergen Schoenwaelder <[email-masked]>
>Sent: Jan 6, 2014 6:22 AM
>To: Randy Presuhn <[email-masked]>
>Cc: David Kessens <[email-masked]>, [email-masked]
>Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)
>
>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.

Since the group serves like a container for the members in
the Yang model, I don't see how it's possible to "leave
the 'members' in place" when deleting the group.  It's
not the empty group that's useful, but rather this: if
one wants to be able to represent valid VACM configurations,
then one must be able to represent configurations in which
one or more "members" refer to a group which does not exist
at the moment.

If VACM has been configured with one or more users referring
to groups that don't happen to exist at the moment, a fairly
reasonable thing to do, the Yang/Netconf interface cannot
represent that configuration.

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

That's over-specifying things a bit.

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

That's also an over-specification.

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

I think this, combined with your comments above, is a crucial point.
There are operations, such as changing a user's group membership,
that are simple atomic transactions in VACM, that the Yang/Netconf model
could turn into TWO transactions in a naive implementation.

Randy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 06 Jan 2014 22:53:50 +0100 (CET)

> one or more "members" refer to a group which does not exist

What do you mean by a "group which does not exist"?  

Maybe you can provide an example (MIB) configuration that is not
possible to express in the YANG model?  (assuming also that we remove
the min-elements constraint from the "member" list).

> represent that configuration.

If you mean an entry in vacmSecurityToGroupTable with a vacmGroupName
that does not exist in vacmAccessTable, this is possible to express
with the YANG model.

/martin

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 6 Jan 2014 15:15:46 -0800

Hi -

> From: "Martin Bjorklund" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, January 06, 2014 1:53 PM
...
> the min-elements constraint from the "member" list).

Sure.  An instance of  vacmGroupName with value "TBD",
when no entry exists in vacmAccessTable with such a value.
Note that this is explicitly permitted by the definitions of
vacmGroupName.

> that does not exist in vacmAccessTable, this is possible to express

Cool.  I couldn't see how the Yang model would allow it, since the list "member"
is contained by the list "group".  Could you explain how one could create
a "member" without creating the containing "group"?

Randy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 07 Jan 2014 08:13:03 +0100 (CET)

> Note that this is explicitly permitted by the definitions of

This is expressable, see below.

> a "member" without creating the containing "group"?

That's not what I wrote.  Let's be concrete.

  vacmGroupName.3.3.b.o.b = TBD
  vacmGroupName.3.5.a.l.i.c.e = TBD

can be represented as

  <group>
    <name>TBD</name>
    <member>
      <security-name>alice</security-name>
      <security-model>usm</security-model>
    </member>
    <member>
      <security-name>bob</security-name>
      <security-model>usm</security-model>
    </member>
  </group>

/martin