Subject: Re: [Isms] new SSH draft to review

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 09 Mar 2009 15:46:49 -0400

--On Friday, March 06, 2009 04:20:48 PM -0800 Wes Hardaker 
<[email-masked]> wrote:

>
> After much thinking about the text, I've modified the incoming/outgoing
> EOPs quite a bit.  They're a lot simpler and easier to understand I
> think and incorporate all the issues people had with them.
>
> See what you think of them.  I certainly could have made some mistakes
> typo-wise since I'm too brain dead to look at them further today to
> double check them (again).  David will probably work on them more Monday.

Looks good overall.  A few minor comments.  Also, remember that the I-D 
submission deadline is 1700 PDT today (in about 4 hours).

]] Because naming policies might differ between administrative domains,	
]] many SSH client software packages support a user@hostname:port	
]] addressing syntax that operators can use to align non-equivalent	
]] account names. The SnmpSSHAddress Textual Convention supports this	
]] common SSH notation.

s/supports this common SSH notation/echoes this common SSH notation/

We chose the syntax we did because it is in common use and thus will be 
familiar to many users of SSH, but not to "support" the behavior of any 
given implementation.  In particular, it is SSHTM, not SSH, which is 
responsible for handling an SnmpSSHAddress, breaking it apart into its 
constituent parts, and passing those on to the SSH layer via whatever 
interface is provided.

Similarly with the next paragraph -- the SSH client never uses the 
tmSecurityName for anything; it is not part of SNMP and so never sees that 
field.  SSHTM passes a username to the SSH client, using whatever interface 
the SSH implementation provides for that purpose.  It may obtain that 
username from the transport address or from tmSecurityName, but that is 
done in SSHTM, _not_ in the SSH client.

In 5.1(2)(A):

]] It MUST exactly and include any "user@" prefix

I think you mean s/and //

In 5.2(3)(B):

]] If there is a session that matches the sessionID, select that session

Change to "If tmSameSecurity is true and..."
s/sessionID/sessionID, tmSecurityName, and tmTransportAddress/

In 5.2(3)(C):

]] If there is a session that matches...

Change to "If tmSameSecurity is false and..."

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 09 Mar 2009 13:55:28 -0700

>>>>> On Mon, 09 Mar 2009 15:46:49 -0400, Jeffrey Hutzelman <[email-masked]> said:

JH> --On Friday, March 06, 2009 04:20:48 PM -0800 Wes Hardaker

>> double check them (again).  David will probably work on them more Monday.

JH> Looks good overall.  A few minor comments.  Also, remember that the
JH> I-D
JH> submission deadline is 1700 PDT today (in about 4 hours).

Oh, yes.  I'm well aware of that at this point....

Good points on your edits and thanks for the rest of them I'm not
commenting on (the changes were made).

JH> Similarly with the next paragraph -- the SSH client never uses the
JH> tmSecurityName for anything; it is not part of SNMP and so never sees
JH> that field.  SSHTM passes a username to the SSH client, using whatever
JH> interface the SSH implementation provides for that purpose.  It may
JH> obtain that username from the transport address or from
JH> tmSecurityName, but that is done in SSHTM, _not_ in the SSH client.

Good point on the wording.  How's this:

	  <t>Because naming policies might differ between administrative
	    domains, many SSH client software packages support a
	    user@hostname:port addressing syntax that operators can use
	    to align non-equivalent account names. The SnmpSSHAddress
	    Textual Convention echos this common SSH notation.</t>

	  <t>When this notation is used in an SnmpSSHAddress, the SSH
	    connection should be established with a SSH user name matching
	    the "user" portion of the notation when establishing a
	    session with the remote SSH server. The "user" portion may
	    or may not match the tmSecurityName parameter passed from
	    the security model.  If no "user@" portion is specified in
	    the SnmpSSHAddress, then the SSH connection should be
	    established using the tmSecurityName as the SSH user name when
	    establishing a session with the remote SSH server.</t>

(it's annoyingly hard to write generic text like that).

JH> In 5.2(3)(C):

JH> ]] If there is a session that matches...

JH> Change to "If tmSameSecurity is false and..."

Ok, then how's this:

   3.  Identify an SSH session to send the messages over:

       A.  If tmSameSecurity is true and there is no existing session
           with a matching sessionID, tmSecurityName and
           tmTransportAddress, then increment the
           sshtmSessionNoAvailableSessions counter, discard the message
           and return the error indication in the statusInformation.
           Processing of this message stops.

       B.  If there is a session with a matching sessionID,
           tmTransportAddress and tmSecurityName, then select that
           session.

       C.  If there is a session that matches the tmTransportAddress and
           tmSecurityName, then select that session.

       D.  If the above steps failed to select a session to use, then
           call openSession() with the tmStateReference as a parameter.

           +  If openSession fails, then discard the message, release
              tmStateReference and pass the error indication returned by
              openSession back to the calling module.  Processing stops
              for this message.

           +  If openSession succeeds, then record the
              destTransportDomain, destTransportAddress, tmSecurityname
              and tmSessionID in an implementation-dependent manner.
              This will be needed when processing an incoming message.

That should ensure that:

- tmSameSecurity=true requires an exact session match
- tmSameSecurity=false allows selecting on the same session, or a
  matching session (just address and name but not sessionID) or creates
  an entirely new one.
-- 
Wes Hardaker
Sparta, Inc.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 09 Mar 2009 17:07:35 -0400

> Good point on the wording.  How's this:

Looks good.

>   matching session (just address and name but not sessionID) or creates

My reading was that tmSessionID was meaningless unless tmSameSecurity is 
true, and so I was trying to arrive at wording that ensures that the 
sessionID is not used when tmSameSecurity is not true.  If the intent is 
that the sessionID may be valid even when tmSameSecurity is false, then 
this latest text is good.

-- Jeff

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 09 Mar 2009 14:12:43 -0700

>>>>> On Mon, 09 Mar 2009 17:07:35 -0400, Jeffrey Hutzelman <[email-masked]> said:

JH> My reading was that tmSessionID was meaningless unless tmSameSecurity
JH> is true, and so I was trying to arrive at wording that ensures that
JH> the sessionID is not used when tmSameSecurity is not true.  If the
JH> intent is that the sessionID may be valid even when tmSameSecurity is
JH> false, then this latest text is good.

I think most people will have a cache that points sessionID -> real
pointer much faster than doing a lookup on just secName and address.

Most importantly, if there are multiple sessions established "for some
reason" that both have the same address and secName then we should
always prefer the one with a matching sessionID if it exists.

(we don't discuss multiple sessions with matching parameters and don't
say we're suggesting people support it, but I don't think we should
write the rules so that it's prohibited if an implementation wants to do
it)
-- 
Wes Hardaker
Sparta, Inc.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 09 Mar 2009 17:20:25 -0400

> always prefer the one with a matching sessionID if it exists.

Provided there _is_ a sessionID, which was the point I was unclear on and, 
perhaps, still am.  But as long as we're clear on when the sessionID is 
expected to be present, I think we're fine.

---

From: "tom.petch" <[email-masked]>
Date: Tue, 10 Mar 2009 17:37:01 +0100

---- Original Message -----
From: "Jeffrey Hutzelman" <[email-masked]>
To: "Wes Hardaker" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, March 09, 2009 10:20 PM
Subject: Re: [Isms] new SSH draft to review

> expected to be present, I think we're fine.

tmSessionID will not always exist and must be valid when tmSameSecurity is
false, namely in the NO/CG at least prior to the first message when that message
establishes the session.

We need tmSessionID in CR to ensure that a Response goes back over the same
session as the Request came in on; that is the easy one, tmSessionID must exist,
can always be used to identify the session, tmSecurityName and
tmTransportAddress are not needed for that purpose, could be omitted.

We need tmSessionID in CG.  Prior to the first message establishing a session,
there can be no tmSessionID (IMHO).  So coming down the stack to sshtm, the
session is identified by tmSecurityName and tmTransportAddress, sshtm says
uniquely so (s.3.1.4).   openSession creates and stores tmSessionID alongside
tmSecurityName and tmTransportAddress.

When a Response arrives in CG, tmSessionID enables sshtm to extract
tmSecurityName and tmTransportAddress so that MPP gets back the values it saw
earlier and so passes the Response to the right place (MPP has no knowledge of
tmStateReference).  SSH does not know the correct tmSecurityName (when SSH
username comes from user@)  and tmTransportAddress (eg lacks user@), only sshtm
can do the mapping back to the correct tmSecurityName+tmTransportAddress from
tmSessionID.

When CG/NO send subsequent messages down the stack, tmSessionID exists but they
can have no knowledge of it, they can only (implicitly) use tmSecurityName and
tmTransportAddress to identify the session to sshtm (uniquely so, as
s.3.1.4.says).

Hence, in CG,  5.2 3) C applies, then 5.1 2) A and 3) A using the unmentioned
tmSessionID to derive tmSecurityName and tmTransportAddress.

In CR, in 5.1 2) and 3), I do not really follow the distinction between B and C.
(My take is that for the first message, sshtm is fed tmSessionID with matching
tmSecurityName+tmTransportAddress and for subsequent ones it only uses
tmSessionID to extract the two last from a cache, but that may just be my way of
implementing).   Then we have 5.2 3) A.

5.2 3 B) (outbound, all three matching)  I cannot see happening, anywhere.

If a session is pre-established, as sshtm allows, then the session will exist,
arguably so will a tmSessionID, but this will not be used by sshtm until CG/NO
sends a first messsage whereupon openSession will be a No-OP and sshtm will
cache the tmSessionID alongside the tmSecurityName and tmTransportAddress.

If you say that tmSessionID only exists in a CR with tmSameSecurity set to true,
then you need something with exactly the same semantics in CG to tie together
the three parameters.  I am calling that tmSessionID, as 5.3 sort of says.

sessionID or tmSessionID? I think that they are the same and that we should only
use the one term because securityName and tmSecurityName are different and we
spell that out.  Hence I use tmSessionID.

There is nothing in sstm-15 to gainsay what I have described above although in
places, the wording might be clearer.

Tom Petch

 _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 10 Mar 2009 11:53:06 -0700

David H: make sure you read the line starting with ****

>>>>> On Tue, 10 Mar 2009 17:37:01 +0100, "tom.petch" <[email-masked]> said:

tp> tmSessionID will not always exist and must be valid when
tp> tmSameSecurity is false, namely in the NO/CG at least prior to the
tp> first message when that message establishes the session.

You seem to be saying conflicting things there.  You say it won't always
exist but must be valid?  Possibly because the word "exist" implies both
existing in the processing point of view and in the global "a live
session with this sessionID exists".

- It won't passed for the first message going out.
- It will have to be passed and match for replies (in which case,
  tmSameSecurity should be true because TSM will have set it).  A
  session may exist, but the SSHTM can look up the session from the
  address and name ***as long as tmSameSecurity is false***. 
- it won't necessarily be passed for other messages going out (other
  GETs/GETNEXTs/INFORMs).

tp> When a Response arrives in CG, tmSessionID enables sshtm to extract
tp> tmSecurityName and tmTransportAddress so that MPP gets back the
tp> values it saw earlier and so passes the Response to the right place
tp> (MPP has no knowledge of tmStateReference).

Most implementations will likely use some sort of sessionID for handling
this, but the details are actually implementation specific and don't
need to be standardized.  Most implementations will probably just use a
pointer a file-handle, I'd assume.  Anything that can be used to
communicate the proper session stream to the SSHTM.

tp> SSH does not know the correct tmSecurityName (when SSH username
tp> comes from user@) and tmTransportAddress (eg lacks user@), only
tp> sshtm can do the mapping back to the correct
tp> tmSecurityName+tmTransportAddress from tmSessionID.

from "something".  Again, it doesn't need to be standardized strictly
speaking (but then, I think a lot of what is documented doesn't need to
be spelled out as strictly; we're trying to define the V3 architecture
so we spell things out more completely).  The layer between SSHTM and
SSH is *not* being standardized except minimally where necessary (more
requirements of the interface than standardization).  The layer between
SSHTM and "up" (through the V3 arch to the application) is the layers
that are getting careful and specific wording and standardization.

What does need to happen for TMSM and above to work is to somehow, when
a message comes in, to be able to associate the correct tmSessionID,
tmTransportAddress and tmSecurityname with it.  How this happens is
implementation dependent.  It doesn't matter if all 3 are cached in one
location, or only the (unique) sessionID and then that is used as a
lookup to retrieve the other two.  The important thing is that all 3 are
available for every incoming message.  Section 5.1 steps 2 and 3 spell
this out with great detail to discuss what exact values must be
cached/held/matched/whatever from previous points in time.

tp> When CG/NO send subsequent messages down the stack, tmSessionID
tp> exists but they can have no knowledge of it, they can only
tp> (implicitly) use tmSecurityName and tmTransportAddress to identify
tp> the session to sshtm (uniquely so, as s.3.1.4.says).

Yep.

tp> Hence, in CG, 5.2 3) C applies, then 5.1 2) A and 3) A using the
tp> unmentioned tmSessionID to derive tmSecurityName and
tp> tmTransportAddress.

That may be how an implementation does it.  Or they may cache the
address directly with the session if they're working with a stack that
can cache the address directly within a structure that is passed
around.  It's implementation dependent.

tp> In CR, in 5.1 2) and 3), I do not really follow the distinction
tp> between B and C.

As the first sentence says of each Bs: The B step is for the first
message transported on the SSH server side and step C is for all others
transported on the SSH server side.  I think the wording is pretty
clear.

tp> 5.2 3 B) (outbound, all three matching) I cannot see happening,
tp> anywhere.

If TSM specifies all three *and* tmSameSecurity is true, then this step
has to happen.  If tmSameSecurity is false, it becomes a "may happen".

I'm not sure why you can't see it happening?

tp> sessionID or tmSessionID?

Well, I think the wording could go either way.  Right now it's worded so
that the sessionID is generic to the SSH stack and cache of sessions,
tmSessionID is specific to the SSHTM.  Much of the time the tmSessionID
is used to look through all the sessionIDs in the stack to find the
matching one.  Or on the incoming side, the tmSessionID is assigned
based on the incoming sessionID.

I think it's probably safe to convert everything to the same term, but I
also think it's fine as is.

-- 
Wes Hardaker
Sparta, Inc.

---

From: "tom.petch" <[email-masked]>
Date: Wed, 11 Mar 2009 14:21:38 +0100

----- Original Message -----
From: "Wes Hardaker" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: "Jeffrey Hutzelman" <[email-masked]>; "Wes Hardaker" <[email-masked]>;
<[email-masked]>
Sent: Tuesday, March 10, 2009 7:53 PM
Subject: Re: new SSH draft to review

> You seem to be saying conflicting things there.

Wes

I was responding to two separate points of Jeff who was speculating about
tmSessionID ie I was saying
- tmSessionID will not always exist
- there are times when tmSessionID must be valid even though tmSameSecurity is
false
AND the two together and yes, it does not make sense.

The only textual change in this context that we might make to sshtm is an
explicit mention of the use of tmSessionID in the CG.  We have that in 5.3 for
openSession which implies to me that this is what will be used inbound to
identify the correct tmSecurityName and tmTransportAddress.  I agree that we
have a lot of details that might be considered implementation and might have
been be left out.  But they are there now and so should stay there.  Then I look
for consistency in our approach, of giving the same level of detail, be it
implementation or no, for all functions and it is on this basis that I would add
more detail to inbound processing for an CG. We go into a lot of detail for CR,
less so for CG.  Yes they can implement it in another way, but that is true for
a lot of what we say, so having introduced tmSessionID in 5.3 openSession, I
would add text to 5.1 and 4.1.2 to make the document coherent.

See also below.

> I'm not sure why you can't see it happening?

My other comment.

My mistake; it will happen in a CG (I was mentally inserting a spurious
condition).  Jeff suggested adding 'If tmSameSecurity is true .." to B) and "If
tmSameSecurity is false .." to C) which I think is correct and clearer.

Then, 5.2  is outbound processing.  In a CR, tmSameSecurity must be true so
messages get binned in 3) A or handled by 3) B; strictly, 3 B) need only match
on tmSessionID, no need for tmTransportAddress or tmSecurityName.

In a CG/NO, tmSameSecurity is false, so 3) C applies; tmSessionID is unknown at
this stage.

Tom Petch