Re: divergent interpretations of IKE/IPsec - interop issues

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

> > This and some other entries just show that IKE should not do
> > bundles. Creates unnecessary combinatory complexties.
> 
> No, it says that IKE should not do bundles without good reason.  There is
> a cost, but there are also benefits.  Setting up a connection requires
> negotiating bundles, not SAs.  If IKE does not do the bundling, something
> else must -- manual bundle setup is in general unacceptable.  Please point
> to the RFC that defines the something else. 

IKE does not need to do the bundles. They are handled through the
policy and SPD (as per RFC 2401).

As I keep saying, there no good reason for IKE to do any policy
checking. The kernel side which implements the RFC-2401 must do it
anyway.

So far, the *only* even barely good reason for IKE policy checking
that has been presented here, is "black hole detection". But, I claim
IKE is wrong place to detect this anyway.

The correct place to detect a mismashed policy, is the kernel side
IPSEC, and there is a very clear and definite place for it:

 When a IPSEC packet arrives, has ESP and/or AH, which decode
 correctly, and packet passes the replay checks, then

 you have a policy mismatch, if that packet and the applied SA's do
 not match the policy!

At that point, IPSEC is supposed to log some event, and drop
packet. It could also generate, *for example*, a PFKEY message which
would contain the SA(s) and selector fields from the packet.

Now, a IKE (or whatever key management) sees this message, it can
check whether it has an open phase I session with the culprit.

My suggestion: IKEv2 includes a notify message for reporting a policy
mismatch (black hole). (which is generated from the kernel mismatch
report).

This method catches also black holes which are caused by other end
sending stuff using wrong SA (even if SA negotiated for some other
selectors).

Also, the advantage is that there is only ONE entity interpreting the
policy data base (and not the kernel and IKE separately).

To me the above seems like clean architecture, it has an enourmously
simplifying effect on IKE phase 2 negotiations. You only need consider
each SA indipendently. No worries about ordering, no worries whether
SA is tunnel or not.