In message <20040521070837.C736A5F@coconut.itojun.org>Jun-ichiro itojun Hagino 
writes
>>     Jonathan> Its also ... trivial to trigger ACQUIREs to racoon at a
>>     Jonathan> sufficiently high rate that (at least for my FAST_IPSEC
>>     Jonathan> tree), racoon stats warnings about malformed ACQUIREs.
>> 
>>   This discussion is interesting...
>>   Linux IPsec (FreeS/WAN, Openswan) has a similiar problem with ACQUIREs
>> they are not reliable under memory exhaustion. To solve this problem,
>> one must scan a /proc system, which has a 4k page problem.
>>   The plan to fix things is to have the keying deamon send requests down
>> to the kernel that would get returned with ACQUIRE's. If one can't
>> allocate an available ACQUIRE, the packet that caused it would get
>> dropped. 
>> 
>>   Basically, unreliable PF_KEY is a bad idea. 
>>   The idea of making it routing-socket like (with the broadcast
>> property) was a bad idea. Get rid of it.
>
>	PF_KEY is unreliable, it is a feature not a bug.

No, Itojun, it's a bug. Please stop playing silly games.
This is a bug, and denying it only makes you look bad. 

We all know that the IETF works on

	``Rough consensus and working To''.

The KAME code doesn't work. Not *just* because its unreliable; but
because it drops messages from a dump stream and then fails to give
the application with *any* indication that messages were lost.
Applications then deadlock because they cannot find the end of the
dump stream.  That's a bug.

Appealing to an Informational RFC to deny that a bug (a well-known
bug) is a bug can only harm your reputation in both the BSD community
and the IETF.