RE: Remove private-use values from IKEv2

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

Paul,

I'm going to disagree with this. I don't think you have fully thought this
through from the perspective of an implementer.

A typical software implementation of IKE is going to contain a statement
resembling:

enum {
ENCR_DES_IV64=1,
ENCR_DES=2,
ENCR_3DES=3,
ENCR_IDEA=4,
ENCR_CAST=5,
ENCR_BLOWFISH=6,
...
ENCR_MY_EXPERIMENTAL_ALG=123456
}

When dealing with private values, it is far more useful to the programmer to
be able to define a unique id for each algorithm and read what is in the
packet, rather than figuring it our from some multi-variable heuristics.

Also, the vendor id has so far been used mostly to advertise capabilities,
and not to make actual decisions.

e.g:
- The NAT-T vid means "I am capable of NAT traversal should we detect a
NAT," not "I want to do NAT traversal."
- The XAuth v6 vid means "If we do XAuth, it should be version 6," not "I
want to do XAuth."

The fact that there is a private range means that experimental protocols
shouldn't conflict with the IANA-controlled range. The two exceptions have
been much discussed and the authors were duly chastised. (And there would be
less chance of a value clash in the private range if people would choose
random values, rather than always starting at the beginning of the private
range.)

Also, I fail to see how vendor ids will obviate the need for the critical
bit. Let's say that you want to test the NAT-T solution. How do you add the
NAT-D payload to the message if there were no private payload ids? Would you
interpret the vendor id to mean that the second SA payload in the message
should be interpreted as a NAT-D? Seems silly, doesn't it. Probably, you
would just choose a number from the high end of the IANA range that is
unlikely to be officially assigned any time soon, in which case you
basically have a private range again.

Finally, some IETF'ers seem to believe that early adoption and/or use of
proprietary features is evil, and that this justifies designing protocols
which are resistant to any attempt to improve or extend them. I should point
out that the IETF has does not have this kind of legal authority over the
way its protocols are used, and there is clearly no consensus that any forms
of proprietary vendor extension is a bad thing.

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 Paul Hoffman / VPNC
> Sent: Thursday, March 14, 2002 2:08 PM
> To: ipsec@lists.tislabs.com
> Subject: Remove private-use values from IKEv2
>
>
> 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
>