RE: Vendor Extensions

["Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>]

We use the vendor id payload, as does pretty much every other vendor that I
know of. Anyone who has implemented NAT traversal is using them, as it is
required by the spec. Without the vendor id, the situation would be much
worse, as there would be no means to smoothly transition to the
IANA-assigned numbers when they are available. We also use it to recognize
our own implemetations in the field and enable some proprietary extentions.

Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.



> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of
> Charlie_Kaufman@notesdev.ibm.com
> Sent: Tuesday, July 23, 2002 11:45 AM
> To: ipsec@lists.tislabs.com
> Cc: Steve Bellovin; jis@mit.edu
> Subject: Vendor Extensions
>
>
>
>
>
>
> > 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)
>