[Openswan dev] Losing shared phase1

[Harald Jenny]

On Tue, Oct 26, 2010 at 03:10:05PM -0400, D. Hugh Redelmeier wrote:
> | From: Paul Wouters <paul at xelerance.com>
> | 
> | On Mon, 25 Oct 2010, D. Hugh Redelmeier wrote:
> | 
> | > The ISAKMP SA will belong to net1 or net2, depending on which got
> | > initiated first.
> | 
> | But it would be nice if it could somehow be marked/remembered as shared, so
> | we can keep it when we are deleting an (arbitrary) phase2 that just happened
> | to have been the first to initiate and thus getting the phase1.
> 
> That doesn't really match how Pluto was designed.
> 
> 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.

As freeswan was in it's beginning rather meant as an OE solution (at least as
far as I can remember) this was also perfectly valid but the requirements have
changed IMHO and I think we will need to honor this...

> 
> | > My recollection is that the phase 2 will only go away (be deleted) if
> | > it belongs to net1.
> | 
> | Correct.
> | 
> | > I would have expected (based on very fuzzy memory) that an IKE SA
> | > would be negotiated whenever needed.  Perhaps sending delete isn't
> | > considered a need.
> | 
> | But that would be even worse with more nets. In our case we were doing 500
> | phase2s to one phase1 for benchmarking. And we'd start them using:
> 
> Benchmarking isn't a convincing application.
> 
> Do real users do this?  Why?  (That's not a rhetorical question.)
> 
> | for i in `seq 1 500` do
> |   ipsec auto --up conn$i
> | done
> 
> 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
> 
> or:
>  have an IKE-only conn, separately created and torn down.
> That seems to match this case quite well.

For testing for sure but in real life?

> 
> | Then we do the same tearing down, but then the receiving end only gets 1
> | Delete/Notify
> | because conn1 would have the phase1. If this would cause another phase1 to
> | establish,
> | just to send a delete, that would be extremely bad, and result in 499 new ike
> | negotiations just to send Delete's.
> 
> Delete notifications in IKEv1 are neither mandatory nor reliable.  So
> they should not matter much.
> 
> | > | Question: Should we not keep the phase1 around on the first delete?
> | >
> | > I don't think so.  Just create an IKE SA if and when needed.
> | 
> | That would be fine for bringing up new things, just not as good for sending
> | notifications
> | about delete.
> 
> If you know what you want, you can do it.  Perhaps not naturally, but
> then what you want doesn't seem natural to me.
> 
> | > It is possible that the IKEv2 standard mandates another model.
> | 
> | I think that part remains pretty similar.
> 
> I vaguely thought that IKEv2 had reliable notifications.  But I've not
> checked.
> 
> | > | I guess this can be difficult to determine. Perhaps that's why it was not
> | > | implemented?
> | >
> | > No.
> | 
> | Okay. So what if we would just let the phase1 linger if there was a request to
> | --down
> | a tunnel, but we have shared it with another phase2?
> 
> You could perhaps create a new --downipsec that left the IKE SA.  But
> then when would the IKE SA get deleted?
> 
> A conn's IKE SA is hard to attach to a different conn.  For one thing,
> the settings might be different.
> 
> | 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.

Seems in programs/pluto/nat_traversal.c sending keep alives for NAT-T requires
the existence of an ISAKMP state so it seems like this may be a problem...

/**
 * Find ISAKMP States with NAT-T and send keep-alive
 */
static void nat_traversal_ka_event_state (struct state *st, void *data)


> 
> Why did you down a conn if you didn't want it to go down?

Maybe a little example which can clarify this: From my laptop I have remote
access to my companies LAN and DMZ via two different conns, the LAN one being
the first. Working via an UMTS connection which is doing NAT I have to use NAT
traversal to get my VPN up and running. I open both connections to check my
mails on my virtual Windows Outlook PC in the LAN and the health of a important
production server in the DMZ. Being a good citizens after having finished my
work in the LAN I close the connection (which removes the ISAKMP state) and
want to continue to work in the DMZ and... there it ends ;-).

To come to an end: I think that the design principles regarding ISAKMP and
IPSec will have to be adapted to match the current needs - but please don't
rush here as this will really need planning!

Kind regards
Harald

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