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

RE: IBM VPN Bakeoff Issues



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 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.