Date: Mon, 25 Jun 2007 16:42:42 +0800 From: blue <susan.lan@zyxel.com.tw> To: VANHULLEBUS Yvan <vanhu_bsd@zeninc.net> Cc: freebsd-net@freebsd.org Subject: Re: Questions about PF_KEY interface Message-ID: <467F8002.9010803@zyxel.com.tw> In-Reply-To: <20070625070547.GA24243@zen.inc> References: <467F65A0.9010900@zyxel.com.tw> <20070625070547.GA24243@zen.inc>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, Thanks for your kindly and quick response :> I still have some questions, though... VANHULLEBUS Yvan wrote: >On Mon, Jun 25, 2007 at 02:50:08PM +0800, blue wrote: > > >>Dear all: >> >> > >Hi. > > > > >>I found there are two directories about PF_KEY interface: netkey and >>netipsec under $FreeBSD src$\sys\. >> >>Looking into the makefile, the one that is currently used and built in >>is netkey. >> >>However, I am wondering what's the purpose for netipsec? >> >> > >netkey is used if you compile with IPSEC (KAME's stack). >netipsec is used if you compile with FAST_IPSEC. > > > I have read the manual page for fast_ipsec and ipsec. However, the man page for fast_ipsec on FreeBSD-6.1Release said currently fast_ipsec does not support IPv6. However, I thought it could properly deal with IPv6 packets after tracing code. Could fast_ipsec support IPv6? Another problem is: if the only difference between fast_ipsec and ipsec is about crypto acceleration, why fast_ipsec needs to modify a bunch of files (including ip6_input, ip6_output, ip6_forward, ..., etc.), not only the encap/decap part? > > >>Besides, the handling for the global variable "regtree", which is used >>for key registery, in netipsec seems more proper to me. >> >>For example, when a key is needed to register, the static function, >>key_register(), which is defined in [netkey/netipsec]/key.c, will be called. >> >>However, in netkey/key.c, key_register() will not call mtx_lock before >>the operation of the global variable, regtree. On the other hand, in >>netipsec/key.c, key_register() will mtx_lock. In my opinion, I think the >>latter should be correct since there may be various processes to call >>the function. Without the protection, race condition will occur! >> >> > >KAME's IPSec stack is still giant locked, so doesn't needs more fined >locking. > >FAST_IPSEC used fined grain locking. > > > The function, key_output(), which is defined in netkey\keysock.c, does not lock Giant before key_parse(). According to the comments (see below), maybe the author wants to lock Giant before the operation? However, does it mean currently it may have race condition problem? / /*XXX giant lock*/ s = splnet(); error = key_parse(m, so); m = NULL; splx(s);/ >KAME's stack will probably be removed in the future (for 7.0 ?) thanks >George V. Neville-Neil's work to provide all KAME's stack features on >FAST_IPSEC. > > > > Do you mean FAST_IPSEC feature will be embedded in FreeBSD-7.0 or later version instead of IPSEC? >Yvan. > > > Thanks for your help :> Best regards, blue
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?467F8002.9010803>