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

	last sentence may be bogus, I misread what you have proposed.

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

	correction: 2nd line should read "SPD entries into kernel".

itojun