Re: Remove private-use values from IKEv2

[Dan Harkins <dharkins@tibernian.com>]

On: Thu, 14 Mar 2002 20:26:58 PST you wrote
> At 3:42 PM -0800 3/14/02, Dan Harkins wrote:
> >How can you do a tunnel discovery protocol *in* a vendor ID payload?
> 
> Like Jan said, using the first part as the ID and the rest of the 
> payload as a TLV list (or ASN.1 or whatever).

That will give you a new attribute or some new information to use in
the already existing protocol (that is already well-defined). It will not
allow you to do things that require, for instance, new exchange types.

> >The only reason to try to test interoperability of implementations using
> >private use values is because the thing they are doing with private use
> >values cannot be done in a standard fashion and that thing is important
> >enough that multi-vendor interoperability is important.
> >
> >But if it is that important then why don't we come up with a standard way
> >to do it? Politics is one. Bureaucracy and WG inertia is another (that
> >it takes longer for the WG to decide something than for huge companies
> >to go through two complete product cycles is sad).
> >
> >If a solution to a problem that people are demanding a solution to is
> >either politically forbidden or only likely to to come out in 3-5 years
> >then vendors are going to bypass the process.
> >
> >Taking away private use values because people are misusing them (how to
> >standardize something outside of the standardization process) will only
> >cause the workarounds they devise to be more novel and problematic. We
> >should fix the problem that is causing them to misuse the private use
> >values in the first place.
> 
> We completely agree here. Any you have already covered it in Section 
> 10.3: new payload numbers are allocated when getting an RFC 
> published, not by waiting around for the WG. That is the right way to 
> do things, particularly because at some point this WG is supposed to 
> shut down.

10.3 deals with payloads. Private use values exist for more than payloads.

And I don't believe that the problems I mentioned will necessarily go away
when the IPsec WG does. There are currently deployed and widely used
implementations which use vendor ID and private use values (not just 
payloads!) with IKE to do things that are chartered to be solved by the 
IPSRA and IPSP WGs. 

Not only that but IANA Considerations are not always followed by IANA! 
Internet Drafts have obtained IANA assigned numbers in violation of
section 11.4 of RFC2409. And there are other I-Ds that have had IANA
assign numbers to them for new algorithms and authentication methods.
A dangerous practice since I-Ds expire every 6 months. Go check out 
http://www.iana.org/assignments/ipsec-registry and see hom many names 
appear instead of RFC numbers under the "reference" column. 

Some of these may be needed so the question is why aren't they RFCs?
For others you should ask yourself if IKEv2 had assigned those numbers
itself whether you would've put an (*) next to them for recommended removal.
Do we really need two each of EC groups for GF[2^163] and GF[2^283] and
GF[2^409] and GF[2^571]? How much interoperability have you seen with with
SHA2-384? More than with Tiger?

  Dan.