Re: Core draft last call update.

[Derek Fawcus <dfawcus%cisco.com@localhost>]

On Fri, Mar 08, 2002 at 02:57:39PM -0500, Bill Sommerfeld wrote:
> > Maybe I'm missing something,  but I can't see the need to disconnect in this
> > case,  as opposed to simply discarding these messages.  
> 
> I don't think think it's that simple.  Have you actually prototyped
> this?  

Not yet.  I'm working on an implementation,  but I've not got to the
user auth part yet.

My concern is pipelining messages in anticipation of success,  and
being able to cope with an error occuring.  Looking at the packet
sequences,  the current restriction forces another RTT into the
log in sequence.

> Many of these message types are ones for which the client expects a
> response -- simply discarding such requests on the server will confuse
> and/or hang clients which were expecting responses.

I did state in the original message that returning an error was also
acceptable to me,  I just didn't want them to cause the connection
to be terminated if there was no security implication of doing so.

I also don't think it'll cause a problem for existing clients,  as
they simply won't trigger this situation.

> Any implementors want to comment on this in more detail?

I'd not have thought there'd be any implication of existing client's,
as they'd not send the message until the RTT had expired,  and they'd
got a response.

There would be an issue for new clients connecting to existing servers,
but I was going to deal with that by having a flag which would delay
based upon a CLI flag,  so I could connect through old servers.

It would also mean that existing servers would strictly be non conforming,
but that could be dealt with during upgrades.

If as you state there is a problem with silent discard,  I'd be happy
with the following alternate text:

   Message numbers of 80 and higher are reserved for protocols running
   after this authentication protocol, so any of these messages received
   before authentication has completed cannot be processed;  if this
   situation occurs the server MUST respond with an error response,  and
   then not act upon the message.

For the error response,  I'd suggest that SSH_MSG_UNIMPLEMENTED would be
workable.  I'd rather have a generic message as a response,  as this
means we don't place a burden on the higher level protocols or always
have a failure type of response.  An alternate would be a message sent
back to state that the message was explicity exgnored (as opposed to
unimplemented),  which would in all other regards look like an unimplemented
message,  i.e. 

   byte SSH_MSG_IGNORED
   uint32 packet sequence number of ignored message

However that would then place more restrictions upon the sender in
that they'd have to check for IGNORED and UNIMPLEMENTED,  and decide
if they wish to allow the connection to continue.

DF