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

["David Harrington" <ietfdbh at comcast.net>]

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

> 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