Re: Transport I-D: KEXINIT reserved field needs description

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

On Wed, Jul 23, 2003 at 09:57:24AM +0200, Markus Friedl wrote:
> On Tue, Jul 22, 2003 at 03:44:42PM -0700, Nicolas Williams wrote:
> > I think the fact that some implementations do not tolerate KEXINIT
> > "extensions" should not precluse the proposed change.  Several
> > implementations already map the peer's version string to compatibility
> > notes and react accordingly.  While I hope that we can put stop adding
> > to this database of compatibility notes I think that this particular
> > issue (KEXINIT extensibility) is worth the trouble to fix.
> 
> I don't think it's a good idea to break the protocol at
> this point.  This compatibility database is always a pain
> and you always miss some implementations.
> 
> I think you could only assume that the peer is able to deal with
> the extension if it sends a non-zero value in the reserved field,
> but I doubt this helps for what you want.  On the other hand, you
> could send the extension data in an extra packet if the reserved byte
> is not zero.

Of all the things in the compat db, this would be amongst the most
important things to have in there.

So if a peer has a version string that according to the compat db means
that the peer does not support KEXINIT non-zero reserved field, then you
send zero in your KEXINIT's reserved field and no extra data in that
packet.  Otherwise you are free to use KEXINIT extensions.

Cheers,

Nico
--