Re: [Isms] pre11 comments

["David B. Nelson" <d.b.nelson at comcast.net>]

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

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


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