Re: [Isms] ISMS/SSH and notifications
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Isms] ISMS/SSH and notifications



Hi,
 
> > 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? 
> 
> In SSH, the party opening the connection
> is always in the client role, so there's no decision needed.

Duh! Forget I asked. ;-)

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

Yes, for responses, we're all set. the securityStatereference caches
the transport information to ensure the same session can be used.

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

I usually work with UDP and I don't think I've ever tried to use the
same port number for source and destination. Is using the same port
for source and destination a problem in TCP? or just for well-known
ports? Is this something I should be recognizing as obvious and am
simply overlooking? ;-)

dbh



_______________________________________________
Isms mailing list
Isms at ietf.org
https://www.ietf.org/mailman/listinfo/isms



Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.