Questions about PF_KEY interface

[blue]

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