Re: Remove private-use values from IKEv2

[Jan Vilhuber <vilhuber@cisco.com>]

On Thu, 14 Mar 2002, Dan Harkins wrote:

>   If the whole reason for private use values was to roll out new
> algorithms then dictating a vendor ID payload to say "replace this
> attribute with that attribute" would make them unnecessary. But
> that is not the whole reason.
>
>   Vendor ID payloads are used to identify a like implementation and
> when two like implementations discover each other they can use the
> private use values to refer to new capabilities, not merely a new
> twist on an existing capability.
>

If you add some TLV type encoding into your vendor-id, then you could
do the same thing as with a private-range number, couldn't you?

I think the biggest issue we've seen is when you wind up with two
different vendors trying to use each others' vendor-id's (say one
company buys the other), and now the private ranges may conflict.

If you hide the private range INSIDE the vendor-id, this can't happen,
and I suspect will be just as powerful.

This would be much closer to how radius does vendor-specific
attributes, i.e. there a SINGLE vendor-id type (like in IKE) which has
the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |  Length       |            Vendor-Id
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Vendor-Id (cont)           |  String...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-


   Vendor-Id

      The high-order octet is 0 and the low-order 3 octets are the SMI
      Network Management Private Enterprise Code of the Vendor in
      network byte order, as defined in the Assigned Numbers RFC [3].


   String

      The String field is one or more octets.  The actual format of
      the
      information is site or application specific, and a robust
      implementation SHOULD support the field as undistinguished
      octets.


Radius recommends just using more radius headers in the STRING field
(but now you get to control the <type> field in your own TLV's.

While using the 'SMI Network Management Private Enterprise Code'
may be equivalent to the hash as indicated in the ISAKMP rfc, it just
strikes me as a bit more deterministic. I could go either way, though.

Encoding the inside of the vendor-id as TLV's (of whatever form you
like) seems like it could solve the same problem as the private range
values, and be much more resilient to overlap when companies merge.

In other words, I don't think we loose any flexibility or power.

>   New capabilities are things like a tunnel discovery protocol, a
> policy download capability, and new techniques at authentication.
> These do not fit nicely into the "replace this with that" model
> you are suggesting.
>
>   Also the critical bit is useful even without private use numbers. It
> is unreasonable to assume a nationwide flag day to upgrade everyone to
> new bits that include use of a new payload with an IANA-assigned value.
> Using the critical bit will allow existing implementations that do not
> know about this new IANA-assigned payload to safely ignore it or properly
> discard the message containing the unknown payload.
>

Wouldn't it be better to use the minor-version number for this? Of
course then we'd have to come up with verbiage that says what to do
with unknown payloads (ignore and fail? Ignore and continue? Crash and
reload?)...

jan


>   Finally, interoperability problems using private use values is a
> symptom of a problem. We should fix the problem, not the symptom.
>
>   Dan.
>
> On Thu, 14 Mar 2002 11:08:07 PST you wrote
> > Private-use values for payloads, attributes, and so on lead to lack
> > of interoperability and are not needed. The only time private-use
> > numbers should be used is for limited testing experimental changes to
> > IKE, but such testing can just as easily be done using vendor-id
> > payloads. For example, a message with a particular vendor ID payload
> > could mean "ignore the encryption algorithm specified in the SA
> > payload and use WhizzyAlg-128 instead."
> >
> > The IETF has a long history of problems with private-use anything.
> > Because implementations often get out of the laboratory, there are
> > often value clashes. Worse yet, there often demands that, because so
> > many people are using private value xyz to mean the abc feature, we
> > should not give abc a regular value when it becomes an RFC, we should
> > keep using xyz (or at least say in the RFC that xyz is equivalent to
> > the new number).
> >
> > Real testing of new algorithms (as compared to the more common "early
> > implementation") is rare, and when it happens, it is quite easy to
> > control with vendor ID payloads.
> >
> > Note that, if private-use payload types are forbidden, there is no
> > longer any use for the critical bit. In that case, the critical bit
> > should be removed from IKEv2 in order to make the protocol simpler.
> >
> > --Paul Hoffman, Director
> > --VPN Consortium
>

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