Vendor Extensions

[Charlie_Kaufman@notesdev.ibm.com]

> Steve Bellovin, Security Area Director, strongly commented that any
drafts
> that contained specific vendor extensions would cause the IESG to be
> concerned and may even cause it to be rejected.  He states this in his
> capacity of Area Director, not as a co-author of the JFK draft.

Could we get clarification of IESG policy on vendor extensions and also
feedback from the working group on their usefulness? IKEv1 contains
an optional field called "Vendor Extensions" that a compliant
implementation is
required to ignore if it does not understand it. This is intended to allow
people to build implementations that can either run the standard protocol
or
can smoothly negotiate over to proprietary protocol if both ends support
it.

It does not contain any registry of values assigned to any specific
vendors.

I don't know whether anyone uses this field in IKEv1. We copied it in IKEv2
since is seemed at least potentially useful without introducing any threats
to
interoperability of compliant implementations.

My questions are:

1) Is anyone using the field in IKEv1?

2) Does anyone (besides me) feel the field is useful enough to leave it
in IKEv2?

3) Does anyone feel the field adds unjustified complexity to the
protocol and hence should be removed?

4) Is there some IESG policy that we should be aware of that might override
working group consensus on the utility of such a field.

I don't feel strongly about the need for such a field. Assuming we leave in
the capability of non-critical extensions so that implementations of future
standard versions of IKE
can interoperate with implementations of this version, vendors will be able
to accomplish what they want (albeit by violating the specification and
with
some risk of future interoperability problems). I don't like rules that
were
made to be broken, but I'd be happy to do it if it were working group
consensus and willing to do it if it were IESG mandate.

      --Charlie Kaufman
      (ckaufman@notesdev.ibm.com)