Subject: Re: Fix for KAME PF_KEY DUMP-truncation marshalling bug
To: Jason Thorpe <thorpej@wasabisystems.com>
From: Jonathan Stone <jonathan@dsg.stanford.edu>
List: tech-net
Date: 05/27/2004 10:38:23
In message <A7548138-AF77-11D8-A125-000A957650EC@wasabisystems.com>,
Jason Thorpe writes:

>This patch looks OK to me.  Are you going to do one for the KAME code, 
>too, or just fast-ipsec?

I dont want to tread on Itojun's toes, and I see he fixed it a
different way, with a PF_KEY-socket level buffer for `overflows',
which also maintains the old broadcast behaviour.

But the nice thing about the sbappendaddrchain() approach is that it
moves the socket-buffer-limit check entirely to the socket/protocol.

I have additional patches which reuse sbappendaddrchain() to treat
kernel-to-user ACQUIRE messages (well, really all `KEY_SENDUP_REGISTERED'
messages) on PF_KEY registered sockets specially:  I created a new,
sysctl'able limit, and append the message to registered sockets
if the space on that socket is less than the new length.

The point being, the limit for AQCUIRES can then exceed the normal
kern.sbmax. Which you might not want to set to 8 Mbytes or 16 Mbytes,
or whatever it takes to guarantee a worst-case slew of ACQUIREs.

Sam Leffler thought that was a reasonable approach, given we put
ourselves in the  precarious position of needing "reliable"[*]
delivery from a datagram socket.

So ... on balance, I would prefer to see our sys/netkey code use the
sbappendaddrchain() rework, rather than Itojun's, but I can see that
might be contentious.


[*] Yes, I know what RFC-2367 says. If ACQUIREs are unreliable, then
IPsec using those ACQUIREs is unreliable. IKE is soft state, and
making soft-state work reliably can be a tricky trade-off.  Note that
even RFC-2367 says kernel-to-user ACQUIRE traffic should be treated
``specially''.