[Isms] Re: modularity

[Randy Presuhn <randy_presuhn at mindspring.com>]

Hi -

> From: David B Harrington <ietfdbh at comcast.net>
> Sent: Aug 1, 2005 10:58 AM
> To: 'Randy Presuhn' <randy_presuhn at mindspring.com>, isms at ietf.org
> Subject: modularity
...
> > (1) what does the architecture say about, for example, two 
> > different access control
> > models making use of a commen table, if that table serves the 
> > needs of both models?
> 
> "Elements of procedure plus the MIB objects which are needed for
>          processing for a specific portion of an SNMP framework should
>          be defined in the same document, and as much as possible,
>         should not be referenced in other documents. "
>
> It was the consensus of the SNMPv3 WG that even models of the same
> subsystem should not share MIB modules, unless the MIB model is
> defined as a standard part of its containing subsystem (e.g.
> SNMP-MPD-MIB) or a standard part of an overall architecture (e.g.
> SNMP-FRAMEWORK-MIB). By consensus of the SNMPv3 WG, the
> vacmSecurityToGroupTable is part of a specific model, and thus should
> not be referenced by other models.

That's not 100% clear.  I think one could reasonably argue that the user/group
mapping concept belongs to the access control subsystem, and is not necessarily
limited to VACM.  The dual nature of the USM and VACM documents (they
describe both the subsystem and a specific model) doesn't help here,
but we didn't want the document explosion that would have resulted if we
had separated everything.

However, I also think it's fair to say that a properly general-purpose user/group
mapping designed for use by multiple access control models might look a little
different from what we have today.  For example, the 1:N might be M:N, there
might be expiration dates on entries, etc.

> If they choose to use it, ISMS needs to decide whether an
> xxxxSecurityToGroupTable should be part of a specific model proposal,
> part of a subsystem, or part of an overall architecture. 

Agreed, and I think there is a legitimate question whether ephemeral
user/group mappings should be visible via SNMP at all.  I think they should
be, but the I think one could reasonably argue otherwise, as did the EUSM
draft.

> In my personal opinion, it will be relatively easy to define a table
> that is part of an independent AC model; it be will harder to
> officially modify the RFC3411 architecture to move responsibility for
> user-to-group mappings into the security subsystem, and hardest to

I think we're in agreement, though an implementation reality is that
events in the security subsystem might trigger the (not-necessarily-SNMP)
protocol exchanges that can eventually result in the arrival of 
user/group mapping updates.

> retrofit moving the responsibility from the AC subsystem to the
> Security subsystem without officially modifying the architecture. Only
> the first option appears to be within the ISM charter, but any
> Transport-security approach will face the same problems.

I think one could also think about it as events in the security subsystem
triggering events that update access control:

--(snmp)--> security--(aaa)-->server--(aaa)-->accessControl
That is: security model decides to send something to AAA; the
response is internally routed to accessControl (after all, is it the
subsystem or the engine that is talking to the AAA server?)

 
> > (2) how do ASIs handle information updates that don't 
> > correspond to an SNMP
> > pdu, but rather contain information coming from a non-SNMP source?
>
> First let me respond to any assumption that ASIs are dependent on the
> PDU:
...
> So, RFC3411 doesn't state that the SNMP protocol must be used to do
> the configuration.
>
> Does that answer your Not-entirely rhetorical question #2?
...

We're largely in agreement, I think, but I'd like to emphasize the
timing and sequencing (or lack of sequencing) rather than conceptual
parameters and syntax.

The invocation of the ASIs corresponds to a chain of events triggered
by the receipt of a PDU or the decision by an application to request
transmission of a particular PDU.  The ASIs don't address, for example,
modification of configuration data through a CLI.  I think one could look
at dynamic creation / deletion of user/group mappings via an AAA-like
protocol as being no different, from the SNMP engine's perspective, from
those created / deleted via an ASI or netconf.

>From this perspective, I think an EUSM-like approach to obtaining the user/group
mappings as needed is not as much of an abomination as one might think.

Randy

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