Subject: [Ipsec] Re: [Ipsec-tools-devel] How to send additional data from kernel to racoon?

From: Park Lee <[email-masked]>
Date: Sat, 20 Nov 2004 09:53:14 -0800 (PST)

On Sat, 20 Nov 2004 at 18:23, Emmanuel Dreyfus wrote:
 
>    Park Lee <[email-masked]> 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?  

 Thanks.
 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? 

--
Best Regards,
Park Lee <[email-masked]> 

---------------------------------
Do you Yahoo!?
 The all-new My Yahoo! – Get yours free!    

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Dan McDonald <[email-masked]>
Date: Sat, 20 Nov 2004 13:19:52 -0500

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...

> > What about making a pseudo-device driver to get your data from the
<SNIP!>
> 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