Re: [Isms] tm table was Re: pre-08 for TSM document

["tom.petch" <cfinss at dial.pipex.com>]

<inline>
Tom Petch

----- Original Message -----
From: "David Harrington" <ietfdbh at comcast.net>
To: "'tom.petch'" <cfinss at dial.pipex.com>;
<j.schoenwaelder at jacobs-university.de>
Cc: <isms at ietf.org>
Sent: Friday, June 27, 2008 3:06 PM
Subject: RE: tm table was Re: [Isms] pre-08 for TSM document
>
> > -----Original Message-----
> > From: tom.petch [mailto:cfinss at dial.pipex.com]
> > Sent: Friday, June 27, 2008 6:49 PM
> > To: j.schoenwaelder at jacobs-university.de
> > Cc: David Harrington; isms at ietf.org
> > Subject: tm table was Re: [Isms] pre-08 for TSM document
> >
> > Juergen
> >
> > Just continuing with the first point, my concern is a SSHTM
> > one in that I cannot
> > see how it works.
> >
> > On an incoming call, the SSHTM will know transport addresses,
> > ports and type,
> > SSH user name, SSH host name and will have an SSH session
> > identifier; I assume
> > that this will be stored in an internal SSHTM table(or
> > cache).  When a message
> > subsequently arrives over that session, SSHTM cannot know the
> > securityLevel or
> > securityName (as generated by the message originator), the
> > former is buried in
> > the ASN.1, the latter is the province of the SM not the TM.
>
> Correct, the TM knows nothing about what is requested in the ASN.1
> message.
>
> The tmSecurityLevel in the TM for an incoming message is supplied by
> interpreting the SSH security proprties. In SSH, this is not
> necessarily available so we assert that it is always authPriv. The SM
> will compare tmSecurityLevel with msgSecurityLevel to see if
> thSecurityLevel is greater than or equal to msgSecurityLevel (and for
> SSHTM, it always will be because authpriv is the highest level).
>

Understand and am happy with that.

> >
> > So on an outgoing message at some later time, it cannot match
> > the 4-tuple of
> > transportDomain and transportAddress, securityName and
> > securityLevel that is
> > used elsewhere in the stack to identify the session to be
> > used for a message.  I
> > thought that snmpTsmLCDTable would provide an answer but I
> > don't see it.
>
> The tmStateReference actually contains the requested level for an
> outgoing message (tmRequestedSecurityLevel). SSHTM then tells SSH to
> apply authpriv regardless of the (possibly lower level) request.
>

Understand again.

> Are you trying to identify a particular SSH session, where there might
> be multiple sessions associated with the 4-tuple? We have explicitly
> said the 4-tuple is unique; there cannot be two sessions for the same
> 4-tuple in SSHTM.
>

Again, understand, but ...

> > (The SSHTM I-D says
> > "     1) Determine the target index by extracting the
> transportDomain,
> >       transportAddress, securityName, and securityLevel from the
> >       tmStateReference.
> >       2) Lookup the session in the Local Configuration Datastore
> using
> >       the target index " )

... from the information that the SSHTM has from receiving a session and
subsequent inbound messages, it has no knowledge of securityName and
securityLevel.  So when an outbound message is passed down to it, and the SSHTM,
as per EOP, is expected to use the 4-tuple to look for a session, then this may
be the first that the SSHTM has ever heard of the particular values of
securityName and securityLevel; it may have a match on tranportAddress and
transportDomain in the table of sessions it has (initiated or) received (along
with other SSH data), it could have several but how can it tell if the two
security parameters match?

(eg it cannot use tmTransportSecurityLevel as that is always authPriv for SSH
and the application creating the outbound message may have had other ideas)

I was envisaging that some unique index could pass from TM to SM so that SM
could hand back index+securityName+securityLevel; or that there is a common
table into which SM inserts securityName+securityLevel so that TM now can
associate them with a session (but which the structure of the snmpTsmLCDTable
now seems to rule out as a candiate) or ..

Puzzled,

Tom Petch


> >
> > Tom Petch
> >
> > ----- Original Message -----
> > From: "Juergen Schoenwaelder" <j.schoenwaelder at jacobs-university.de>
> > To: "tom.petch" <cfinss at dial.pipex.com>
> > Cc: "David Harrington" <ietfdbh at comcast.net>; <isms at ietf.org>
> > Sent: Friday, June 27, 2008 9:12 AM
> > Subject: Re: [Isms] pre-08 for TSM document
> >
> >
> > > On Tue, Jun 24, 2008 at 09:58:24AM +0200, tom.petch wrote:
> > >
> > > > Focussing on this I-D, you say that the TM will not alter the
> LCD
> > > > table, but I think that it will struggle to read it, at least on
> > > > inbound messages, as it cannot be sure what the
> > securityName is and
> > > > so cannot index into the table.  It could walk the table
> > looking for
> > > > a matching snmpTsmLCDName ... well perhaps not.
> > >
> > > I fail to see why a TM needs to read the table. The TM just
> > passes the
> > > name provided by the transport via the tmStateReferences
> > and TSM then
> > > does any mappings as needed.
> > >
> >
> > <snip>
> >
> >
>

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