In message <E1BQbUu-00049J-00@smeg.dsg.stanford.edu>Jonathan Stone writes

[Problems with PF_KEY being an unreliable channel, leading to
marshalling bugs with PF_KEY dump requests]

Here's one way to fix the immediate problem with PF_KEY dump requests:
less elegant, but much much simpler, than the approaches Matt Thomas
and I discussed a few months back:

Add a special per-socket ``reserve tank'' or ``overdraft'' flag.  If
the flag is set, and the receive-buffer on the socket is not 100%
full, allow _one_ request to arbitrarily overflow the so->so_rcv
socket-buffer limits.  (The receive socket-buffer is then over 100%
full, and will not allow further overflows until the socket's
so-rcv buffer is drained below the normal hard limit.)
Only the superuser may set this socket option.

Then, rework the PF_KEY dump implementation to prebuild a single huge
chain, with each entry in a separate `packet'.  Rework or replace
key_sendup() to drop that single monster chain directly onto the
receive buffer of just the socket who requested the dump.

We already have the code to build the single-monster-chain: the sysctl
API uses it.  All that's needed is the ability to append that chain to
a socket receive queue, whilst preserving its internal record
boundaries; plus the ``reserve-tank'' or overdraft socket option.

Comments?  It doesn't solve the rate problems with other, non-dump
PF_KEY requests, but it would definitely fix the non-adherence to RFC-2367.