Re: [Isms] wg last call followup - sshtm

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

----- Original Message -----
From: "David Harrington" <ietfdbh at comcast.net>
To: "'tom.petch'" <cfinss at dial.pipex.com>; "'Wes Hardaker'"
<wjhns1 at hardakers.net>; "'Jeffrey Hutzelman'" <jhutz at cmu.edu>
Cc: "'Juergen Schoenwaelder'" <j.schoenwaelder at jacobs-university.de>;
<isms at ietf.org>
Sent: Tuesday, March 03, 2009 6:15 PM
Subject: RE: wg last call followup - sshtm


> Actually, I think it is incorrect to say that no mention is made of
> caching the tmSecurityName.
>
> The openSession takes a tmStateReference that already contains a
> tmSecurityName, and openSession adds the corresponding tmSessionID to
> the tmStateReference cache. This binds the tmTransportAddress and the
> tmSecurityName and the tmSessionID together.
>
> When a response is received, it will be received over the existing
> session. And by looking up the tmSessionID, we find both the
> corresponding tmSecurityName and the correspnding "user@"
> transportAddress to pass up the stack.
>
> Apparently you didn't find that obvious ;-)

Well now, you can if you have a session cache whose entries remain invariant for
the duration of the session.  Which is not what the I-Ds currently say to me.
5.1 2) says create a tmStateReference cache and that is now the thrust, that a
tmStateReference cache entry is created per inbound message and only lasts for
the duration of the transaction as opposed to a cache entry that is per session
and lasts for the duration of the session.  I think that such a cache must now
exist but see it as too much of a stretch to read that meaning into the current
text.  We are, I hope, writing this for those who have not spent five years
working on it.

Recall too that in November you said .
"The sessionID field that is contained in the tmState is used for one
and only one purpose - to match corresponding request and response
sessions to ensure sameSecurity. It is never used for any other
purpose. And it is opaque to the security model."

So I am now proposing - see another of my e-mails - a different use for
tmSessionID, that it is used as a session identifier between sshtm and ssh in a
Command Generator so as to match the request and response sessions, nothing to
do with sameSecurity in a Command Responder.

Also note that s.3 says
" SSH sessions are uniquely identified within the SSH Transport Model
   by the combination of tmTransportAddress and tmSecurityName
   associated with each session."
and this must now mean except when sessions are uniquely identified by
tmSessionID so I have a sentence to add there as well to the effect that there
must be a one-to-one correspondence between the unique
tmTransportAddress+tmSecurityName and the unique tmSessionId.

And as I already asked, why has openSession  been changed to

   statusInformation =
   openSession(
   IN   tmStateReference       -- transport information to be used
   OUT  tmStateReference       -- transport information to be used
   IN   maxMessageSize           -- of the sending SNMP entity
    )

Or is this the obvious statement that the three parameters are cached
together:-)

Tom Petch
> We'll try to make it more obvious.
>
> > -----Original Message-----
> > From: tom.petch [mailto:cfinss at dial.pipex.com]
> > Sent: Tuesday, March 03, 2009 9:05 AM
> > To: Wes Hardaker; Jeffrey Hutzelman
> > Cc: David Harrington; 'Juergen Schoenwaelder'; isms at ietf.org
> > Subject: Re: wg last call followup - sshtm
> >
> > Wes
> >
<snip>