[Openswan dev] Losing shared phase1

D. Hugh Redelmeier hugh at mimosa.com
Mon Oct 25 20:51:36 EDT 2010


| From: Paul Wouters <paul at xelerance.com>

| I just noticed the following behaviour and wondered if this was bug or intent:
| 
| Image the following:
| 
| conn net1
| 	also=base
| 	leftsubnet=1.2.3.0/24
| conn net2
| 	also=base
| 	leftsubnet=1.2.88.0/24
| conn base
| 	[...]
| 
| When you bring up these two tunnels, you will end up with 1 ISAKMP and 2 IPsec
| SA's.

The ISAKMP SA will belong to net1 or net2, depending on which got
initiated first.  

When the second one is initiated, it will discover that it can use the
already existing ISAKMP SA rather than negotiating a new one.

An arbitrary decision made during the design of Pluto was that there
would not be two kinds of connections (phase 1 and phase 2).

| Now when you do:
| 
| ipsec auto --down net1
| 
| then the phase1 and one of the phase2's will go away. You are left with one
| phase2
| that has no phase1.

My recollection is that the phase 2 will only go away (be deleted) if
it belongs to net1.

| If you would do:
| 
| ipsec auto --down net2
| 
| then no Delete/Notify ever makes it to the other end.

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.

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

It is possible that the IKEv2 standard mandates another model.

| I guess this can be difficult to determine. Perhaps that's why it was not
| implemented?

No.


More information about the Dev mailing list