Re: Vendor Extensions

[Jan Vilhuber <vilhuber@cisco.com>]

On Tue, 23 Jul 2002 Charlie_Kaufman@notesdev.ibm.com wrote:

>
>
>
>
> > 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?
>

Yes. Xauth and config mode for one (whether that's a good thing is
debatable). We used it extensively to gather experience with keepalive
mechanisms, and others have used it to gather experience with new
ciphers.

This is extensively used.

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

Absolutely, yes. A protocol that doesn't have ways of extending it is
a dead protocol (from the start). And if there's no way to gather
experiences with new mechanisms, that's bad, too.

Let's face it: people will experiment with different stuff. Getting
things standardized in the IETF is a gory process. You don't want to
just voice an opinion, you want to back it up with implementational
and deployment experience to make your case.

Without some vendor extension (or private extension, if you want to
make it sound less controversial), people will just use existing
payload numbers from the reserved space, which will REALLY break
interoperability big-time.


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

No, although I have some thoughts on an alternate vendor-id mechanism,
similar to the one radius has, that is in my opinion a little clearer
semantically (but no more or less powerful).

jan


> 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)
>

 --
Jan Vilhuber                                            vilhuber@cisco.com
Cisco Systems, San Jose                                     (408) 527-0847

http://www.eff.org/cafe