[Openswan dev] Losing shared phase1
harald at a-little-linux-box.at
Thu Oct 28 10:35:22 EDT 2010
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
> ipsec auto --up conn1
> 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
> | > | 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!
> Dev mailing list
> Dev at openswan.org
More information about the Dev