Re: Core draft last call update.

[nisse%lysator.liu.se@localhost (Niels Möller)]

Bill Sommerfeld <sommerfeld%east.sun.com@localhost> writes:

> > 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?  
> 
> 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.
> 
> Any implementors want to comment on this in more detail?

This is my analysis: 

Discarding packets on the server side should be easy, except that one
must not discard any connection-level packets that are sent after the
userauth request that succeeded. But this logic should fit well with
the logic for discarding userauth messages received after the
succeeding one.

On the client side, one would compute the initial one or more packets
one wants to send after userauthentiation, and piggyback them onto
each send userauth request. After the succeeding userauth packet that
succeeds, one would expect the replies to the initial packets.

However, consider the client sending several userauth requests
(corresponding to the user's several public keys, say), with a piggy
backed SSH_MSG_CHANNEL_OPEN after each of them. In order:

 SSH_MSG_USERAUTH_REQUEST
 SSH_MSG_CHANNEL_OPEN
 SSH_MSG_USERAUTH_REQUEST
 SSH_MSG_CHANNEL_OPEN

If the second and final userauth request is that which succeeds, all
is well, if the above rules are applied. But if the first userauth
request succeeds, the second userauth request will be discarded, but
*both* SSH_MSG_CHANNEL_OPEN requests will be processed by the server,
so the client gets more than it wanted.

One solution to this is to require the client that wants to piggyback
non-userauth messages to wait for the reply to the first userauth
request before sending the second, but then we get more roundtrips.
Another might be to not *discard* non-userauth messages, but queue
them for later processing after a successful userauthentication. Then
the client could send

 SSH_MSG_CHANNEL_OPEN
 SSH_MSG_USERAUTH_REQUEST
 SSH_MSG_USERAUTH_REQUEST

and the server would process the channel open request exactly once,
*after* user authentication. But I think this reordering trick gets a
little ugly.

BTW, which implementations set the first_kex_packet_follows flag in
the SSH_MSG_KEXINIT? Perhaps we should evaluate that feature before
trying to optimize away some more roundtrips.

/Niels