Subject: RE: [Isms] securityName

From: Randy Presuhn <[email-masked]>
Date: Mon, 1 Aug 2005 09:07:48 -0500 (GMT-05:00)

Hi -

> From: David B Harrington <[email-masked]>
> Sent: Aug 1, 2005 8:54 AM
> To: 'Wes Hardaker' <[email-masked]>, 
>	'Tom Petch' <[email-masked]>
> Cc: [email-masked]
> Subject: RE: [Isms] securityName
...
> If the xxxxSecurityToGroupTable were moved to the SM subsystem from
> the AC subsystem, that we need to address how to reconcile this shift
> of responsibility from the existing AC models (VACM) to the existing
> SM models (USM and Community), how to move the MIB module from one
> subsystem to the other subsystem, and how to document the change to
> the architecture and the models given the IETF/RFC process.
...

Not-entirely rhetorical questions:

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

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

Randy

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 1 Aug 2005 11:58:36 -0400

Hi Randy,

Let me try to comment as co-chair of the concluded SNMPv3 WG:

>From RFC3411 Design Decisions:

      - Architecture
         An architecture should be defined which identifies the
         conceptual boundaries between the documents.  Subsystems
should
         be defined which describe the abstract services provided by
         specific portions of an SNMP framework.  Abstract service
         interfaces, as described by service primitives, define the
         abstract boundaries between documents, and the abstract
         services that are provided by the conceptual subsystems of an
         SNMP framework.

      - Self-contained Documents
         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.  This allows
         pieces to be designed and documented as independent and self-
         contained parts, which is consistent with the general SNMP
MIB
         module approach.  As portions of SNMP change over time, the
         documents describing other portions of SNMP are not directly
         impacted.  This modularity allows, for example, Security
         Models, authentication and privacy mechanisms, and message
         formats to be upgraded and supplemented as the need arises.
         The self-contained documents can move along the standards
track
         on different time-lines.

         This modularity of specification is not meant to be
interpreted
         as imposing any specific requirements on implementation.

      - Remote Configuration
         The Security and Access Control Subsystems add a whole new
set
         of SNMP configuration parameters.  The Security Subsystem
also
         requires frequent changes of secrets at the various SNMP
         entities.  To make this deployable in a large operational
         environment, these SNMP parameters must be remotely
         configurable.

> models making use of a commen table, if that table serves the 

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

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. 

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

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

>From RFC3412:

"3.3.  pduType

   A value of the pduType represents a specific type of protocol
   operation.  The values of the pduType are specific to the version
of
   the PDU contained in a message.

   Applications register to support particular pduTypes for particular
   contextEngineIDs.

   For incoming messages, pduType is provided to the Dispatcher by a
   version-specific Message Processing module.  It is subsequently
used
   to dispatch the PDU to the application which registered for the
   pduType for the contextEngineID of the associated scopedPDU."

ASIs are designed as the interfaces between subsystems, and are
typically independent of the PDU, since the PDU is specific to the
message-processing-model and the application model.

Second, SNMP generally provides a standardized interface to underlying
non-SNMP instumentation. If a non-SNMP source modifies the underlying
instrumentation, that may or may not show up in an SNMP standardized
interface (a MIB module).

By SNMPv3 WG consensus, it is expected that the SNMP parameters for
the Security and AC subsystem models can be remotely configured.

>From RFC3411 A.1.2:

   Each Security Model may allow multiple security protocols to be
used
   concurrently within an implementation of the model.  Each Security
   Model defines how to determine which protocol to use, given the
   securityLevel and the security parameters relevant to the message.
   Each Security Model, with its associated protocol(s) defines how
the
   sending/receiving entities are identified, and how secrets are
   configured.

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?

David Harrington
[email-masked]
co-chair IETF SNMPv3 WG, concluded