>>Let's review some of the bad things that happen with racoon.  Many of
>>these problems will affect *any* IKE/ISAKMP daemon, not just racoon.
>>* It's possible to get the SPD and racoon out of sync, because racoon
>>  does not manage the SPD itself.
>
>        This is because racoon does not follow what kernel says
>        (we need to configure two locations exactly the same).
>        racoon should grab policy configuration from the kernel and compile
>        IKE phase proposal based on it.  sakane (cc'ed) is working on it.

I'm not convinced that's the right choice.  With that approach, I have
to configure half of IPsec with setkey and half with racoon.conf.
That seems poor.

>>* It's possible for SAD entries to expire (or reach their soft limit)
>>  at a different time in the kernel than they do in racoon (c.f. the
>>  timeout() lossage mention in my racoon PR).
>
>        racoon manages IKE phase 2 timeouts, not kernel SA timeouts.
>        When kernel SA reaches its timeout, a PF_KEY message (EXPIRE) will
>        be transmitted to the userland and userland IKE daemon (racoon) would 
>        notice the lifetime expire.

My point is that you have two places handling the *same* timeout.  It
should be done in *one* place.  I don't particularly care which.

>>       actually, we follow RFC2367.  It is because RFC2367 that we can
>>       run isakmpd at ease on top of KAME-based IPsec kernel.  If we need
>>       to talk about changing it, we need to revise RFC2367, not just by
>>       hacking NetBSD.  If we introduce incompatibility (like "less frequent
>>       ACQUIRE") we'll degreade chances to run other IKE daemons.

The problem with the way ACQUIREs work are:

a) We can get a flood of unusable SAs in bad cases.  This is
   unacceptable.

b) It makes '/use' (as opposed to `/require') almost useless, because
   we'll try to negotiate a new SA for every 10 packets.  This is also
   unacceptable.  We should not be continually trying to renegotiate
   after a failure.  At the very least, this should be based on some
   clock timer, not on a per-packet basis.

>>       None of the above can be handled by userland.  If we do not put
>>       SPD entries into userland, we end up sending every packet to the
>>       userland (like FreeBSD divert socket) so that racoon can check if
>>       the packet makes sense.
>
>        correction: 2nd line should read "SPD entries into kernel".

The point was to have racoon manage the SPD *in the kernel*.