RE: Specification of tunnel/transport attribute in IKEv2

["Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>]

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.

Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.



> -----Original Message-----
> From: Markku Savela [mailto:msa@burp.tkv.asdf.org]
> Sent: Wednesday, May 08, 2002 6:23 PM
> To: andrew.krywaniuk@alcatel.com
> Cc: ipsec@lists.tislabs.com
> Subject: Re: Specification of tunnel/transport attribute in IKEv2
>
>
>
> > Also, we decided that the ordering of the protocols in the proposal
> > shouldn't matter, since the only ordering that makes sense is
> > [AH][ESP]
>
> But, if I do *WANT* to do [ESP][AH]? Basicly, I want to check IP
> headers, but not wanting the sniffers to know that I'm checking...
>
> ...and if someone wonders what is checked: if I have
>
>   [IP-hdrs][ESP][AH]...
>
> then first ESP gets applied and removed resulting
>
>   [IP-hdrs][AH]...
>
> and then AH checks the IP-hdrs.
>
> (and yes, the IPSEC I wrote can do this, if IKE wouldn't object.. :-)
>
>
>