Re: Revised Publickey subsystem draft

[Joseph Galbraith <galb-list%vandyke.com@localhost>]

Brent McClure wrote:

> > 3.1 Version Packet
> >
> >   Both sides MUST start by sending a version packet that indicates the
> >   version of the protocol they are using.
> >
> >   string "version"
> >   uint32 protocol-version-number
> >
> >   The version of the protocol described by this document is version 1.
> >
> >   Both sides send the highest version that they implement. The lower of
> >   the version numbers is the version of the protocol to use.  If either
> >   side can't support the lower version, it should close the subsystem
> >   and notify the other side by sending an SSH_MSG_CHANNEL_CLOSE
> >   message.
> >
> >   Both sides MUST wait to receive this version before continuing.
>
>
> I think we need to bump the version to 2.
>
> I also just remembered something that I found awkward about the current protocol:
>
> If there is a version mismatch then the channel gets slammed shut with no
> opportunity to communicate what the problem was to the other side. It would
> be nice to allow for shoving a status packet down the channel indicating
> a version mismatch before sending the SSH_MSG_CHANNEL_CLOSE. This would
> be a benefit both to clients trying to figure out why their channel won't
> open or to admins reading through a server log.

This occurs if one of the sides has dropped support for
older versions, and the other side is still using an
older version.

In this case, the newer-versioned implementation has no
choice but to close the channel (it can't communicate with
the older version.)  The older version will just assume
that, as per the spec, the new version will downgrade to
talk to it.

So, if and only if, the newer-version is willing to
keep support for sending status packets for all older
versions, we could allow either side to send a
status packet at any time describing a general failure
of some sort, and followed immeadiately by a channel
close.

Perhaps we should create a new message that is only
sent during a general failure (i.e, when the failure is
not the failure of a given request.)

If we are going to add a message to handle this case, I
think I need to be able to tell the difference between
'the command you just sent failed' and 'there was a general
failure, not related to the command you just sent, which in
fact, I haven't yet recieved, but you don't know that.'

So, maybe:

	string "general-failure"
	uint32 reason-code [same as for status]
	string human-readable-variant
	string language

	Either side may send "general-failure" at
	any time during the session.

	"general-failure" MUST NOT be sent in
	response to a request, unless the request
	itself is malformed (a protocol conformance
	failure.)

	"general-failure" MUST always be followed
	immediately by the channel closing.

	"general-failure" is used to indicate failure
	on either side that is not related to request
	processing, but that requires communication
	to be aborted.

	One example of such failure is the case where
	one of the sides does not support the version
	of the other side.

	Another example is protocol failures, such as
	short packets, malformed packets, etc.  This
	message MUST NOT be sent in response to a well
	formed, but unrecognized request.  In this case,
	'well formed' means that the packet length
	was at least long enough to hold the request
	string itself.

	A server or client MAY also send this message
	in response to a termination signal.

	The purpose of this message is to give users
	and administrators more information with which
	to troubleshoot a failure.

Implementations of version 1 will not be able to recieve
this message, so this only helps if version 2 becomes
obsolete.

On a different note, we might want to restrict to
request names to us-ascii (probably the same subset
used by DNS.)  This would allow better detection of
protocol error vs. unrecognized request.

- Joseph