[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IBM VPN Bakeoff Issues
[Resending - my mailer screwed up the quoting when I replied to the HTML
original so my first version was incomprehensible.]
A compliant implementation would only propose bundles that put IPCOMP before
ESP. On the other hand, if you are talking to another implementation
(perhaps misconfigured or broken) that proposes ESP before IPCOMP, as a
liberal receiver I think the best choice is to accept the other
implementation's proposal. A second valid choice would be to refuse the
proposal. Accepting the proposal but silently reordering it to put IPCOMP
before ESP seems totally strange & wrong.
The key thing is that the ordering in the proposals be well-defined. If one
implementation thinks it means left-to-right and another thinks
right-to-left, there will be problems.
> I think I see where you're coming from here. However, the
> order isn't fixed
> by policy; it's fixed by the documents. We MUST put IPCOMP
> before ESP. I
> think it also says that we MUST put ESP before AH (this makes sense,
> anyway). So if we also disallow ESP+ESP in the same SA
> payload, it makes the
> order very determinable, regardless of the order the
> proposals appear in
> inside the SA payload.
>
> So even though IKE can negotiate AH over ESP over IPCOMP,
> that's not what
> should be implemented. So we need to determine what should be
> implemented
> when IKE does negotiate AH over ESP over IPCOMP, so that
> interoperability is
> more reasonably assured.