Message-Id: <1175094915.3085.503.camel@faith.austin.ibm.com>
Date:	Wed, 28 Mar 2007 09:15:15 -0600
From:	Joy Latten <latten@...tin.ibm.com>
To:	David Miller <davem@...emloft.net>
Cc:	eparis@...hat.com, netdev@...r.kernel.org,
	herbert@...dor.apana.org.au, jmorris@...ei.org, paul.moore@...com,
	vyekkirala@...stedcs.com
Subject: Re: [PATCH]: SAD sometimes has double SAs.

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 <eparis@...hat.com>
> > 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 majordomo@...r.kernel.org
> 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists