Re: [Isms] Comments on the BTSMS proposal

[Juergen Schoenwaelder <j.schoenwaelder at iu-bremen.de>]

On Wed, Aug 03, 2005 at 10:57:31AM +0200, Tom Petch wrote:

> > The TMSM document discusses this in some detail. I fail to see why you
> > think it is necessary to touch the flags in the SNMP packet. Can you
> > please elaborate?
> >
> The auth priv flags in the SNMP PDU reflect the request of the
> application and I do not see these as being changed by SSH (not
> wanted, not feasible).  The reality on the wire may be different; I
> think that that should be passed to the SNMP engine but that that
> cannot be done in the SNMP PDU.  I see this as at best a fudge of
> the architecture, perhaps even a change.  We no longer have in the
> PDU information we should have.

I don't think the security parameters of the session must be exchanged
over the network and hence I don't thing they have to be in the PDU.

> > The TMSM document currently proposes to pass this information between
> > the pieces of the split security model via a cache referred to by a
> > cache reference. Again, I like to understand why you think it is
> > necessary to change the SNMPv3 PDU format.
>
> Same argument.  The security model is expected to derive a
> securityName from the msgSecurityParameters in the PDU.  When
> security is done at transport level, this information never makes it
> into the SNMP PDU.  There are security parameters but they are
> outside the remit of the SNMP engine and architecture.  Same
> conclusion.

Please point to the RFC from which you derive this requirement for all
security models.

> I accept that this is a judgment call and you see it differently.  I
> was interested to be reminded by dbh of the SNMP 'WG consensus
> requirements such as "the mandatory-to-implement models should have
> no dependencies on external protocols" '.  We are now introducing a
> greater dependence on external protocols - SSH et al - albeit for
> non-mandatory models and for me, that puts the architecture under
> strain.
>
> dbh also says
> 'If the TMSM is going to pass transport information from the transport
> mapping to the SM subsystem, either through a cache or an ASI
> parameter, we need to standardize how this is done, how it affects
> existing models and MIB modules, and how to document these changes
> within the IETF.'
> 
> Again, a matter of judgment, but I see this as close to suggesting a small
> change to the architecture as defined in RFC3411 caused by a dependency on
> external protocols.

I guess you have seen my recharter proposal and it in particular
allows for updates that describe how security state information is
passed around. I am actually not sure what your problem really is.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

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