Re: Questions about PF_KEY interface

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
_______________________________________________
freebsd-net@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"