In message <20040522010918.CC67F17921@portal.hamachi.org>Bill Sommerfeld writes
>> 	ask Craig Metz who designed PF_KEY.  you can reach him at
>> 	cmetz at inner.net.
>
>On the other hand, the other name on that RFC sits in an office across
>the hall from me, implemented PF_KEY in solaris (including reliable
>start/end records for SADB_DUMP) and later agreed that a fully
>reliable SADB_DUMP made sense.

I'd tend to agree.  But don't let Itojun bamboozle you about the
poor quality of the KAME code.

The issue here is that when KAME PF_KEY overflows socket-buffers with
DUMP responses, the DUMP response is truncated: apps get everything
from the start to the drop-point, everything else is lost [*].  Apps
reading the stream never see the end-of-dump record, so they can never
*find* again it to resynchronize.  Given how the KAME userlevel code
for processing SADB dumps is structured, that's a fatal bug: the apps
`know' they haven't seen the end-of-stream marker, so they deadlock,
attempting to read more DUMP records which just aren't there.

Either the last response with the end-of-dump marker has to be
reliable; or you need a *fully reliable* error indication, even after
the last-delivered DUMP message has completely filled the socket
buffer.  (Which, obviously, may require exceeding the socket-buffer
limits to some small degree).

That's the bug. Itojun's defense on the grounds of RFC-2367 sec 1.4 is
...  incomprehensible, if not downright incompetent on technical grounds.



[*] At least for big-lock kernels: PF_KEY generates all the DUMP
responses, and either delivers or drops them, before userspace gets to
run again after the DUMP request.  thus 

It may actually be different on a fine-grained SMP system like FreeBSD
5.x, if PF_KEY's sendup*() is made fine-grained; AFAIK that hasn't
happened in FreeBSD