Last night I browsed the ipsec-tools code and saw places in racoon where improvement would actually fix this problem. I am working on a patch and will pursue this on the ipsec-tools mailing list.
I apologize for any inconvenience. Eric, sorry as I know you already patched lspp kernel for testing. I strongly think this should be fixed in userspace. The permission check before flushing does still need to be added to kernel. Regards, Joy On Mon, 2007-03-26 at 19:04 -0600, Joy Latten wrote: > On Mon, 2007-03-26 at 14:48 -0700, David Miller wrote: > > From: Eric Paris <[EMAIL PROTECTED]> > > Date: Mon, 26 Mar 2007 17:34:59 -0400 > > > > > I'm not at all able to speak on the correctness or validity of the > > > solution, > > > > Neither am I yet :) > > > > > but shouldn't the ipv6 case be a && not an || like the ipv4 > > > case? Isn't this going to match all sorts of things? Did you test this > > > patch on ipv6 and see it to solve your problem? > > > > > > I'm also not enjoying the formatting in the ipv6 part where the first > > > time you have the cast on the same time as the object but not the second > > > part where x->props.saddr.a6 is on its own little line. > > > > Also, I want to understand what is going to tear down these > > "other direction" fake entries later on? I think I can review > > this patch better if I understand that. > > > I am going to refer to the other-direction-placeholder as the "fake" > entry. And the larval SA that gets created for the new > spi as result of a GETSPI message as the "real" entry. > > The fake entry gets created when the real entry does and does not have > an spi. It shares some of the same properties of a "real" larval SA > (they are created using same code) and it's state > is marked as XFRM_STATE_ACQ. The real entry has a timeout. So, should > IKE negotiation fail, take too long, etc... it will eventually timeout > and be deleted. So does the fake entry. It will timeout and should be > eventually deleted. (I will test this part tomorrow for assurance.) > > When the IKE negotiations are successful, xfrm_state_add() and the > xfrm_state_update() look for larval SAs in that they look for an SA with > same src, dst, etc... and with state==XFRM_STATE_ACQUIRE. Any that are > found are deleted and new SA added. This removes the real larval SA, and > should also remove the fake entry too. > > Of course, this is all based on my assumption that IKE will install > two SAs, one for incoming and one for outgoing. > > Hopefully this answers how fake entries will be removed. > Admittedly, I may miss something or didn't understand something > correctly as I learn the code, so please let me know. > There may even be a better solution that I don't readily see. > > > As it stands, this looks to me like a workaround for an improperly > > implemented IPSEC daemon. Joy states it as saying that the current > > code requires the keying daemon to manage it's SAs, and I wonder > > whether any other implementation is even valid. > > > My big mouth. :-) But yes, I do think more SA management in > userspace would be ideal. > > This fix will hopefully ensure kernel doesn't send any > extra acquires regardless. > > Joy > - > 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 - 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
