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

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

----- 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: Saturday, June 28, 2008 4:46 AM
Subject: RE: tm table was Re: [Isms] pre-08 for TSM document


> > > > (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.
>
> OK. sometimes we talk about the concept instead the exact variable
> name that must be used. We are not implementing this, we are
> describing how it works conceptually. I will make sure to change this
> to say tmSecurityName and tmSecurityLevel. (or more accurately,
> tmRequestedSecurityLevel and tmTransportSecurityLevel).
>

I still think that it cannot work, conceptually or otherwise:-)

A session is received, the TM gets information about the session which it can
use to identify it but which cannot include the securityName and securityLevel
as used by the application which has or is about to transport a message over the
session.

A message is received over this session which has this security information
embedded within it but which is inaccessible to the TM, only to SM and MPM
respectively, neither of which tell the TM about it; the TSM will put such
information into a cache, which, as Juergen said, he saw no point in the TM even
reading.

An outbound message is now passed to the TM and the session to use is identified
by the 4-tuple which includes securityName and securityLevel, which the TM has
never heard of and which there is nowhere to use as an index to translate to
information which the TM does understand (eg SSH session ID, SSH host name, SSH
user name ...).  Nor do I see how any model in the stack can create such a
translation table so I do not see how can a message ever be sent over a session
that already exists, and that includes a response to a request.

The part that does work is when an outbound message creates a session; then and
only then does the TM know the securityLevel and securityName associated with
the session (and to create a new session if the transport details match but the
security details differ).

When I use securityName and securityLevel here I mean literally that, the values
used by the application and most of the models in the stack to identify the
session to be used (in conjunction with the two transport parameters) and not
the proposed or such level parameters that may be translated into or from the
application level parameters by the Security Model..

Tom Petch


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