(usagi-users 03134) Re: [Ipsec] Re: [Ipsec-tools-devel] How to send additional data from kernel to racoon?

[Dan McDonald <danmcd@xxxxxxxxxxxx>]

First off, I'm not 100% sure the IETF IPsec is appropriate for
platform-specific details, but since such things may apply to general IPsec
implementations, we ought not migrate off.

Having said that...

On Sat, Nov 20, 2004 at 09:53:14AM -0800, Park Lee wrote:
> On Sat, 20 Nov 2004 at 18:23, Emmanuel Dreyfus wrote:
>  
> >    Park Lee <parklee_sel@xxxxxxxxx> wrote:
> > > I've looked through the RFC2367 (PF_KEY Key Management API, 
> > > Version 2), But it seems that the messages, such as 
> > > SADB_ACQUIRE, are unsuitable to carry my data from kernel to 
> > > racoon. How to acheive this? Could you please give me some 
> > > hints? 
> >
> > What about making a pseudo-device driver to get your data from the
> > kernel?  
<SNIP!>
>  What's a pseudo-device driver? and How to make it? Would you please elaborate it for me? 
>  Can it not absolutely achieve through PF_KEY ? (i.e. can we do some modification to PF_KEY to achieve our goal ?)
> and Is there other method to achieve the goal? 

I wish I'd saved the original message, but I'm not sure which sort of data
you're trying to send from the kernel up to user-land.  (Is it IPsec policy?)

You can augment PF_KEY to express something you wish.  Please use the _x_/_X_
naming convention, though.  Some revs of the *BSD PF_KEY does not do this in
places, and people go assume that their code will compile on other platforms
because the augmentations do not have the _x_/_X_ in them.

Another option is to create a new socket type.  Look at the Solaris
ipsecconf(1m) command and what it does.  Our PF_POLICY socket is publically
defined, but we're considering it.  (And when Open Solaris happens, you'll
get to see it anyway.)

A third option is to exploit whatever native platform support you have for
kernel --> user-space communication.  Device drivers (as Emmanuel suggested)
are one such route.

Dan