Re: [Isms] ISMS/SSH and notifications

[<Pasi.Eronen at nokia.com>]

David Harrington wrote:

> > -- table that's used when SSHTM needs to open a connection in
> > -- SSH client role
> 
> Here's the crux of the problem from the standpoint of editing the
> secshell draft - how does the TM know it needs to open a connection
> in a client role or in a server role?
> 
> The information the TM is given includes transportDomain,
> transportAddress, securityName, securityLevel, and a wholeMsg  which
> is opaque to the TM. It is asked to send the message. It checks to see
> if there is already a connection associated with (transportDomain,
> transportAddress, securityName, securityLevel) and does not find one.
> The PDU in wholeMsg might contain an outgoing GET-REQUEST or a Trap;
> it doesn't know. 
> 
> How does the TM determine whether to open the new connection as a
> client or as a server? Where in the system is that decision made? what
> information is needed by the module making that decision? which
> subsystem *has* the necessary information to make that decision? 

If there's no existing connection, and the TM needs to send a message,
it needs to open connection. In SSH, the party opening the connection
is always in the client role, so there's no decision needed.

> If an existing connection is available, should the TM use it? Does the
> TM need to know in which direction that connection was opened, i.e.
> does it need to know whether it is acting as a client or server to
> reuse the connection? Do the security properties differ if the TM's
> role is client or server? Is the TM the right place to make that reuse
> decision - it is obviously the only module that understand SSH
> client/server roles so it appears that it must, but if the security
> properties are different, which module should be making that decision
> (or should it be the admin)?

I guess for e.g. Response PDUs, we usually get a tmStateReference that
identifies a connection -- if that connection still exists, that would
be used, right?

On the other hand, if transportAddress includes both the IP address
and TCP port number, a "client" connection (connection I opened)
wouldn't match a "server" connection (connection the other end
opened), because in the latter case, the (remote) source port number
isn't the well-known port, but some ephemeral randomly selected port.

(Using the same well-known port for both source and destination
wouldn't work in TCP.)

However, in this case, if we're sending a Response PDU, and the connection
identified by tmStateReference doesn't exist any more, we can't use
that port number (=the ephemeral port used as source port by the
entity that sent the GetRequest) to connect back. So responses would
always have to use the same transport session as the request, unless
we treat transportAddress in some special fashion.

Best regards,
Pasi
_______________________________________________
Isms mailing list
Isms at ietf.org
https://www.ietf.org/mailman/listinfo/isms