Re: [Isms] pre11 comments

["Bert Wijnen - IETF" <bertietf at bwijnen.net>]

W.r.t. David's question:
>
> Wes Hardaker writes...
>
> > The security to group table is indexed by the model and the name
> > that the model provides:
> >
> >   +--vacmSecurityToGroupTable(2)
> >      |
> >      +--vacmSecurityToGroupEntry(1)
> >         |  Index: vacmSecurityModel, vacmSecurityName
> >         |
> >         +-- ---- INTEGER   vacmSecurityModel(1)
> >         +-- ---- String    vacmSecurityName(2)
> >         +-- CR-- String    vacmGroupName(3)
> >         +-- CR-- EnumVal   vacmSecurityToGroupStorageType(4)
> >         +-- CR-- EnumVal   vacmSecurityToGroupStatus(5)
> >
> > It provided the ability for "wes" in USM land to be different
> > than "wes" in KSM land.  Or the same; it was an operator decision.
>
> Was that a conscious goal of the VACM design, or was that simply an
> unplanned outcome that some may have taken advantage of later?  After all,
> if vacmSecurityName is supposed to be a model independent name,
> it seems odd to make it model dependent again in this fashion.
>

I remember the discussion very well, and I was opposed to see the
vacmSecurityModel as one of the index objects. But in the end I
was unable to convince (enough) others and so (rough) WG consensus
was to indeed include it.

> > Now with the ISMS based solution then all future transport protocols
> > operating as a TM underneath TSM will always have identical
> > securityNames mapped to the same group and there is no way to change
> > that.  "wes" in SSH will have to be equivalent to "wes" in TLS because
> > the model number will be constant for both (which will be the enum
> > value for TSM).
>
> I happen to think that level of simplification is probably a Good
> Idea (tm).
> I also think that the level of access control complexity (down to
> leaf node
> granularity) is more than 80% of operators find a valid use for.
> Sometimes having too many choices is a Bad Idea (tm).
>

I agree. In hindight, I think we overdesigned it which made it far more
complex than needed.

> > The WG needs to make a decision whether we care about this or not.
>
> I personally don't care.  I think we can solve the 80% problem by having a
> single TSM that is always "good enough" when correctly configured.  BTW,
> correct configuration is *always* going to be a caveat for any security
> related solution.  As Dave H. says, if there is a market demand for
> "Differentiated Services" TSM, one could always take the current work and
> spin up another document to describe it.
>
> I think (and this is my subjective opinion) that to be true to SNMPv3
> architecture, you'd need to have multiple Security Models, each
> with its own name, rather than a single, parameterized Security Model that
> could export a pseudonym for the purpose of VACM mapping.  At least for
the sake of
> architectural description; the implementation could optimize by creating a
> single parameterized model, I suppose.
>

Well, given my above comment, I guess you can understand that I am
in favor of just using TSM (at least for now) as the security model, no
matter what unerlying technology is being used.

Bert

_______________________________________________
Isms mailing list
Isms at ietf.org
https://www.ietf.org/mailman/listinfo/isms