Re: [Isms] Comments about draft-ietf-isms-secshell-13, Section 5

["David Harrington" <ietfdbh at comcast.net>]

Hi Pasi,

Iam not certain that I have addressed all your issues. 
Can you please check the latest rev?
comments inline.

 
> Comments about draft-ietf-isms-secshell-13, Section 5:
> 
> Overall: I think we're *almost* done -- I think we need to fill in
> some minor details, but those shouldn't affect the overall
processing.
> 
> - The distinction between tmStateReference cache and LCD is a bit
> unclear -- do these actually mean the same thing? For example,
Section
> 5.3 talks about creating an LCD entry when the SSH client has
> established a connection (step 7), and Section 5.2 checks if the LCD
> entry exists (step 2).

I removed all references to an LCD.

> 
> But there's no text saying that the SSH server ever creates any LCD
> entries -- so step 2 of Section 5.2 would always fail when
> e.g. sending command responses. That's clearly not the intention.
> Section 5.1 does talk about creating a tmStateReference cache --
> perhaps it should talk about creating a LCD cache entry? Or perhaps
> Sections 5.2/5.3 should talk about tmStateReference cache? Or
perhaps 
> we need to describe opening a session also from SSH server's point 
> of view? (Section 5.3 talks only about what the SSH client does, and

> says basically nothing about what the server does.)

We now have no mechanism for storing any long-term information about a
connection from the server's point of view, or lomg-term information
about a connection from a ciient's point of view either.
All we have is the tmStateReference cache, and I don't know quite how
long that lives.

> 
> - Section 5.2 (step 2) says the LCD entry is indexed by
> (destTransportAddress,tmSecurityName) but 5.3 (step 7) says it's
> (destTransportAddress,tmStateReference). Probably the former is
> correct? (but in that case, there's no need to store tmSecurityName 
> in the entry itself, so step 7 of 5.3 may need some editing)
> 
> - Section 5.3, step 1: it would be *really* useful to add a note 
> that to authenticate the server, the client usually stores
> (destTransportAddress, server host public key) pairs in
> implementation-dependent manner.  (Otherwise, this text gets
difficult
> to understand.)

I rewrote this section to make it much cleaner. Hopefully, I got all
the steps right.

> 
> - Section 5.1: we shouldneed a better description of how 
> tmSecurityName
> works on the SSH client side; IMHO the current behavior isn't quite
> right: Suppose a command generator sends a command with
> tmSecurityName="alice" and
> destTransportAddress="ahopkins at router1.example.net:1234". An SSH
> connection is opened and so on. When the command response is
received,
> the current text in Section 5.1 would lead to having
> tmSecurityName="ahopkins" in the response -- a slightly unexpected
> response.  Would it be better to extract the tmSecurityName from the
> "LCD cache entry" (or whatever is the right term) that was created
> when the client first established the session?
> 
> - Section 5.1, on related note, on SSH client side, the
> tmTransportAddress in incoming messages should probably also be
> extracted from the "LCD cache entry", so that it's exactly the same
as
> was used for the outgoing message (that triggered creating the SSH
> connection).

It seems that needs to be done or the MPM will not match the response
to the outstanding request to determine to which application the PDU
must be delivered.

> 
> - Section 5.1, we should say what the tmTransportAddress for
incoming
> messages looks on the SSH server side: it's "address:port" form (not
> user at address:port).

under discussion.

> 
> - Typos:
> Section 5.3, "tmSecurtityName"
> Section 5.4, "sever"
> Several sections (including the MIB): 
> "sshtmSessionUnavaliableSubsystems"
> 
> Best regards,
> Pasi
> _______________________________________________
> Isms mailing list
> Isms at ietf.org
> https://www.ietf.org/mailman/listinfo/isms
>