[Openswan dev] Losing shared phase1

[D. Hugh Redelmeier]

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

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

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

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