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

Re: Remove private-use values from IKEv2



  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. 

  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.

  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