On Sat, 2005-17-12 at 15:03 -0800, David S. Miller wrote: > From: Krzysztof Oledzki <[EMAIL PROTECTED]> > Date: Fri, 16 Dec 2005 13:15:58 +0100 (CET) > > > Thank you! Will test ASAP. Need day or two, I need to reassemble my > > IPSec netlab. ;) > > Please let me know if it works as soon as you know. > > I think for now it's more important to have things working than to > have the fastest implementation. So if Krzysztof's tests go good I'll > push that minimal fix into 2.6.15 and 2.6.14-stable. > > Meanwhile I have been brainstorming on how to do this efficiently. > If we could have a mapping from xfrm_state to bundles using that > state, it would help a lot. Let's assume that we had that via > a list hung off of the struct xfrm_state, then at add time all > we'd need to do is something like the patch attached to the end > of this email. > > In fact, with this list we can accurately say at delete time > whether "some xdst refers to this xfrm_state" and flush the > bundles precisely. Subsequently xfrm_flush_bundles() moves > privately into xfrm_policy.c and it is only used on device > down events, and even that can be simplified further with this > new information. > > The socket end of the deal is taken care of transparently, since > __sk_dst_check() will check dst->obsolete and thusly invoke > dst->ops->check(). The list addition code will add the top-level > bundle dst to the list hung off of xfrm_state, and that makes it > all work out. > > After this, the only major hole remaining right now is wrt. new > policies being inserted. Sockets having cached IPSEC routes don't > notice that currently. We will probably need to do a forced bundle > flush on all existing policies in order to cure that, and given the > frequency of policy insertions that probably isn't a big deal. >
Just an addendum: If this works it should be sysctl controlled i hope. This is definetely more efficient than Herbert's approach. Herbert's could be modified to make it only check every x seconds or n packets instead of every packet. Also thinking about it some more, I think we could do without any changes to racoon. A second approach inspired from your current patch: Just delete the route cache entry for the one specific SA on update. I could attempt such a patch when i get back from work tonight. cheers, jamal - 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
