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

[Jeffrey Hutzelman <jhutz%cmu.edu@localhost>]

On Wednesday, July 23, 2003 09:57:24 +0200 Markus Friedl 
<markus%openbsd.org@localhost> 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.

Actually, I think that would work.

Based on what people have said about what implementations do, I will 
suggest that the core transport draft specify the following behavior:

- MUST send 0 in the KEXINIT reserved field
- MUST ignored the received value in the KEXINIT reserved field
- MUST NOT add any fields after the reserved field
- MAY reject KEXINIT packets with extra fields

At which point we can (in a later document) use the reserved field to 
indicate support for extensions, which are then negotiated in a separate 
exchange of packets after the KEXINIT messages have been received.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+%cmu.edu@localhost>
  Sr. Research Systems Programmer
  School of Computer Science - Research Computing Facility
  Carnegie Mellon University - Pittsburgh, PA