[Openswan dev] Losing shared phase1
paul at xelerance.com
Thu Oct 28 11:36:52 EDT 2010
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.
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.
> You could, of course recode this to avoid the "problem":
> for i in `seq 2 500` do
> ipsec auto --up conn$i
> 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
> 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.
> 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?
> 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
Thanks for the answers on the design Hugh,
More information about the Dev