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

Re: Remove private-use values from IKEv2



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