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

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

>* Because we always use the oldest SA to send a packet, when one
>  machine is rebooted, or the SAs get out of sync in some other way,
>  no communication is possible until all of the stale SAs time out.
>  This is unacceptable.

	This is because we have some features missing (like DELETE
	information payload handling).
	We basically need to follow draft-jenkins-ipsec-rekeying-04.txt.
	I think this is the right way to handle the situation.

>In short, the netkey API appears to be extremely suboptimal.

	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.

>I propose a few things:
>
>* If racoon is running, SPD entries should be managed by racoon.  It's
>  certainly quite wrong to have done in both places, and it is better
>  to have all configuration done by racoon in this case.

	Not sure what exactly you mean "managed by racoon" here, however, for me
	in-kernel SPD makes more sense.

	SPDs lives in two places: per-socket and per-packet (IP address
	based).  SPD entries has two roles:
	- whenever incoming packet reaches the socket/ip layer, SPD will
	  check if the incoming packet make sense against the SPD.
	  For example, a policy like "in ipsec esp/transport//require" requires
	  an inbound packet to have ESP.
	- whenever outgoing packet reaches the ip layer, SAD entries will be
	  looked up against the matching SPD entry.  If there is no SAD
	  entries, kernel raises ACQUIRE message to the userland.

	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.

>* Expiration of keys (both soft and hard limits) should be handled
>  entirely by the kernel -- sending a message to racoon when a new key
>  needs to be negotiated.

	kernel SA expiration handling is already done in the kernel.
	racoon has some duplicated effort for IKE phase 2 timeout handling
	which may need correction/improvement.

itojun