[Openswan dev] Losing shared phase1

[Harald Jenny]

On Thu, Oct 28, 2010 at 11:36:52AM -0400, Paul Wouters wrote:
> On Tue, 26 Oct 2010, D. Hugh Redelmeier wrote:
> 
> > The IKE and IPSec stuff are all combined in one conn.  So if you stop
> > the conn, you are in some sense stopping that authentication.
> >
> > There could have been two levels of conn, one for IKE and one for
> > IPSec.  That could more cleanly match to protocols.  It was decided
> > that that distinction didn't actually help the usage we expected.
> 
> I guess that is still true in almost all cases. And even in a case where
> two legit IPsec SA's share an ISAKMP SA, as in Harald's example, pluto
> can easilly setup a new ISAKMP.

Hmmm but does it also really do this in case of NAT-T as the code I've looked
at rather suggests that a keepalive is only sent when an ISAKMP SA already
exists... (please don't beat me in case I read the code wrong).

> 
> I guess it is really mostly a matter when you have very many tunnels between
> the same two endpoints, which almost always is a non-real testing scenario.

Well what if two headquarters with multiple subnets have to be interconnected?
Apart from the above scenario only natting the IPSec nets comes to my mind and
this can get really ugly!

> 
> > You could, of course recode this to avoid the "problem":
> >    for i in `seq 2 500` do
> >      ipsec auto --up conn$i
> >    done
> >    ipsec auto --up conn1
> 
> Yes, that is exactly what we ended up doing. Well, not exactly, as your example
> only works for the down case if you go 1-500 in the up case. Your example
> would just move the ISAKMP to conn2, which in the down would be quickly killed
> as well.
> 
> > or:
> > have an IKE-only conn, separately created and torn down.
> > That seems to match this case quite well.
> 
> How would you create an "ike-only" conn? I thought your design didn't allow
> for that? :) But I know what you mean, pick a host-host one that's outside
> the loop of 500 tunnels.

*ggg*

> 
> > Delete notifications in IKEv1 are neither mandatory nor reliable.  So
> > they should not matter much.
> 
> True, and again mostly relevant in testing and benchmarking.
> 
> > You could perhaps create a new --downipsec that left the IKE SA.  But
> > then when would the IKE SA get deleted?
> 
> I don't think this integrates well in the real-world uses though. What
> would you do on receiving a delete/notify? --down or --downipsec?

What exactly does the delete notification tell us? That the ISAKMP or the IPSec
SA terminates?

> 
> > A conn's IKE SA is hard to attach to a different conn.  For one thing,
> > the settings might be different.
> 
> Agreed, it seems very unwise.
> 
> > | There are more reasons this is important too. Imagine NAT-T keep alives no
> > | longer being
> > | send because there is no phase1.
> >
> > I know little about NAT-T and its requirements.
> 
> NAT keepalives are send to keep the NAT hole open in the absence of traffic.
> 
> > Why did you down a conn if you didn't want it to go down?
> 
> And if it would go down, it can easilly come back up. It's not a scaling issue.
> 
> I'll document this case and part of this discussion in the wiki. But I don't
> think we should do any coding for this corner case. Unless anyone else has a
> real case scenario where re-establishing the phase1 causes packet loss or other
> issues?

Sorry when I'm nitpicking but could anyone (with more experience) have a look
at the keepalive code?

> 
> Thanks for the answers on the design Hugh,
> 
> Paul

Kind regards
Harald

> _______________________________________________
> Dev mailing list
> Dev at openswan.org
> http://lists.openswan.org/mailman/listinfo/dev