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

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

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

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

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.

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