From: Krzysztof Oledzki <[EMAIL PROTECTED]> Date: Fri, 16 Dec 2005 01:04:47 +0100 (CET)
> It looks like XFRM caches that information, so kernel does need to search > whole SADB for each packet and this is the reason why usage of old SA is > observed. This is my theory only, someone who wrote XFRM probably knows > this for sure. This would be true when not using a route cached to a socket. If the socket has the IPSEC route cached, it will not notice the SA change even if you flush the routing cache, because the IPSEC route, which is what is attached to the socket, does not get invalidated and thus sk_dst_check() won't see an invalid route entry. Now, when acting as a security gateway, yes the routing cache flush trick will work. A new policy lookup will be performed on each packet, and subsequently a bundle lookup will check xfrm_bundle_ok() which will notice that the path is not valid and thus it will not return this entry. This will force re-resolution of the SA by resolving the policy's template. (xfrm_lookup() --> __xfrm4_find_bundle() --> xfrm_bundle_ok() ... --> xfrm_tmpl_resolve()) But, as stated, for cached routes this will never kick in. I'm trying to see if there is a clever way to make existing SA entries get invalidated upon insertion of a new SA which "shadows" them. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
