Re: Remove private-use values from IKEv2

[Paul Hoffman / VPNC <paul.hoffman@xxxxxxxx>]

At 2:14 PM -0800 3/14/02, Dan Harkins wrote:
>   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.

They can, but they don't have to: they can also use additional Vendor 
ID payloads or parts of the Vendor ID payload that got them synched 
up.

>   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.

Right: they can be done *in* the Vendor ID payload itself.

>   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.

And that can be handled other ways as well, such as different numbers 
for security-critical payloads. Allowing an implementation to decide 
"I'm saying this is security-critical" instead of the IPsec WG 
deciding whether or not it is security-critical is a bad design and 
is sure to lead to interop problems.

>   Finally, interoperability problems using private use values is a
> symptom of a problem. We should fix the problem, not the symptom.

Please say more!

--Paul Hoffman, Director
--VPN Consortium