Re: [Isms] Comments on the BTSMS proposal

["Tom Petch" <nwnetworks at dial.pipex.com>]

   <inline>
Tom Petch

----- Original Message -----
From: "Juergen Schoenwaelder" <j.schoenwaelder at iu-bremen.de>
To: "Tom Petch" <nwnetworks at dial.pipex.com>
Cc: "EKR" <ekr at rtfm.com>; "Sam Hartman" <hartmans-ietf at mit.edu>; <isms at ietf.org>
Sent: Tuesday, August 02, 2005 1:20 PM
Subject: Re: [Isms] Comments on the BTSMS proposal


> On Tue, Aug 02, 2005 at 11:48:19AM +0200, Tom Petch wrote:
>
> > When security is outside SNMP, at the transport layer, then
> > somewhere in the SNMP engine needs to tell TMSM or transport what is
> > wanted, which then says yes or no; and the level on the wire may
> > exceed what is requested (eg authPriv v authNoPriv) which, IMHO,
> > needs recording in the packet (where?) and needs passing up the
> > stack of the recipient (how?).
>
> 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.

> > None of this is in the architecture or ASIs.  And recall that the
> > PDU is ASN.1 so the transport layer cannot readily set or reset
> > flags in it, even in the space set aside for security parms ie we
> > are in a sense modifying the SNMPv3 PDU format by moving the
> > securityParms outside the ASN.1 SEQUENCE.
>
> 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.
>
> /js
>
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.

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.


Tom Petch

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