[Openswan dev] Losing shared phase1

[Paul Wouters]

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
>    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.

> 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
issues?

Thanks for the answers on the design Hugh,

Paul