Re: Specification of tunnel/transport attribute in IKEv2

[Markku Savela <msa@burp.tkv.asdf.org>]

> The merit of this ordering is not the point. Since 90% of IPsec
> implementations either fundamentally do not support this feature, or maybe
> could support it but have no desire to do so, yours is a rather edge case.
> Therefore, I suggest that you enable it via a proprietary extension.
> 
> Leaving the specification vague on some critical issues because a few people
> had some esoteric objections is exactly where we went wrong with IKEv1.

In my opinion, IKE went wrong when it started doing policy checking,
instead of just being a key negotiation.

If IKE negotiated only keys, these ordering issues would never have
surfaced.

As far as RFC-2401 is concerned, any ordering is possible (and policy
dictates the required order). Requiring something to be "proprietary
extension" just because some couldn't read the RFC-2401 properly, is
somewhat sad thing.