Re: [Isms] ISMS/SSH and notifications

[<Pasi.Eronen at nokia.com>]

David Harrington wrote:

> > 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.)
> 
> The WG decided that reuse of existing connections was acceptable, so
> one  connection could be used for both R/R traffic and notifications.
> I don't think we discussed the different port numbers used and how
> that might impact this approach. Are you saying that reuse might be a
> problem? Or that the application would need to deliberately request
> reuse of a (presumably) existing connection (by specifying  the right
> destination port)? (We did discuss that the receiving port would need
> to be listening for incoming traffic of both types.)

Let's see how this could work...

Suppose a management station (apologies for sloppy use of terminology
-- this is just an example :-) at 192.0.2.1 opens an SSH connection 
to an agent at 192.0.2.33. The TCP connection would be, for example, 
from 192.0.2.1/1418 (where 1418 is a random ephemeral port) to
192.0.2.33/NNN (where NNN is the port allocated by IANA for SSHTM).

Let's assume that there's a GetRequest/Response exchange, but the
SSH connection is left open in case it's needed in the future.

The SSHTM on the agent side will have a table (or something)
containing all the currently open transport connections, probably
indexed by (at least) transportDomain, transportAddress, securityName,
and securityLevel. The most obvious choice (but perhaps not the only
one) for transportAddress in this case would 192.0.2.1/1418.

If the agent now wants to send a notification, the transportAddress
given by notification originator application would probably be
192.0.2.1/NNN -- so it won't match the existing transport connection
(and the agent will open a new one).

In general, it seems if the transportAddress contains the TCP port
number, and TCP source ports are ephemeral random ports, there are
situations when two simultaneous connections between two entities are
needed (e.g., a connection opened by manager for sending requests will
be used also for responses, but not notifications).

However, I don't think this is really a problem. This comes from
using TCP (and is not really SSH specific), and it seems to be exactly 
how the current TCP transport mapping (RFC 3430) works:

   TCP connections are established on behalf of the SNMP applications
   which initiate a transaction.  In particular, command generator
   applications are responsible for opening TCP connections to command
   responder applications and notification originator applications are
   responsible for initiating TCP connections to notification receiver
   applications, which are selected as described in Section 3 of STD 62,
   RFC 3413 [8].  

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