[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: comments on jfk and ikev2 drafts

Michael Richardson wrote:
> Suggested text:
> 
>    The Vendor ID Payload contains a vendor defined constant.  The
>    constant is used by vendors to identify and recognize remote
>    instances of their implementations.  This mechanism allows a vendor
>    to experiment with new features while maintaining backwards
>    compatibility.
> 
>    The Vendor ID payload is both an announcement from the sender of which
>    space private payload types will come from, and also an announcement of
>    the sort of private payloads it is willing to accept. The implementation
>    sending the Vendor ID MAY make assumptions about private payloads that it
>    may send, provided that all are not marked critical. Upon reception of a
                             ===========
                             -> none are
>    Vendor ID of like stature, a sender may then send critically marked
>    payloads as as well.  Multiple Vendor ID payloads MAY be sent. An
>    implementation is NOT REQUIRED to send any Vendor ID payload at all.

I like this part.

> 
>    A Vendor ID payload may be sent as part of any message.  Reception of
>    a familiar Vendor ID payload allows an implementation to make use of
>    Private USE numbers described throughout this memo-- private
>    payloads, private exchanges, private notifications, etc. Unfamiliar
>    Vendor ID's MUST be ignored.

This would seem to prevent anyone from proposing a proprietary crypto algorithm
in message 1. Is it intentional? Of course, not all usages of this existing
mechanism are that nice (e.g. x-auth authentication type hack), but there 
are likely to be valid uses as well. The problem in IKEv1 is that it doesn't 
specify exactly what to do if a private use number exist in a proposal. Like
with the x-auth authentication type, most vendors skip it and try to match the
next one, some abort the negotiation.

> 
>    Writers of Internet-Drafts who wish to extend this protocol MUST
>    define a Vendor ID payload to announce the ability to implement the
>    extension in the Internet-Draft. It is expected that Internet-Drafts
>    which gain acceptance and are standardized will be given "magic
>    numbers" out of the Future Use range by IANA and the requirement to
>    use a Vendor ID will go away.

There's no point in demanding something that can't be enforced, like
this demand for making an ID about every VID. There should also be some
text describing how the transition period when some products use the VID
method and others use IANA assigned numbers should be handled.

Ari

-- 
"They that can give up essential liberty to obtain a little 
temporary safety deserve neither liberty nor safety." - Benjamin Franklin

Ari Huttunen                   phone: +358 9 2520 0700
Software Architect             fax  : +358 9 2520 5001

F-Secure Corporation       http://www.F-Secure.com 

F(ully)-Secure products: Securing the Mobile Enterprise
Follow-Ups: References: