Re: [Ipsec-tools-devel] phase1 phase2 association

[Paul Moore <paul.moore@ce...>]

In transport mode (I dont know about tunnel) deletes are very important. If m1 deletes an m1-m2 SA and m2 does not know then m2 will try to use the SA to talk to m1. This communication will fail and the two system can no longer talk to each other. This is why I am tracking down all lost delete notifications. I appreciate that the whole thing is unreliable anyway but I can at least try to minimize the bad outcomes.

I appreciate that a phase2 is not bound to a phase1 in any protocol sense. It is allowable to shut down a phase1 and have its phase2 live on, etc. But in order to send or receive informational messages about a phase2 a phase1 is required.

I have 2 very specific problems

If a phase1 goes away I now have a bunch of phase2s that I cannot announce deletes for. Seems that the best thing to do here is to use another phase1 to the same peer or if there isn't one then I should make one

Talking to Windows: when it expires a phase1 it next sends deletes for the phase2 (if it decides to shut them down not always). It send the ph2 deletes after the phase1 delete (!). So now racoon cant read them becuase it threw away the phase1 state. This really seems like a windows bug to me. This one cannot be solved in the same way - here I must retain the phase1 until all the derived phase2 go away

[Ipsec-tools-devel] phase1 phase2 association

[Paul Moore <paul.moore@ce...>]

This is all based on .7x

once a phase2 is set up it is unlinked from its phase1

if that phase1 goes away (forcibly closed, expires,...) we throw it away
because its phase2 chain is empty

now when the phase2 is deleted (expiry, setkey -F,...) we cannot tell
the far side about it because we dont have its phase 1

seems to me that the simple thing is to not unbind the phase2 (and hence
make the phase1 linger) but I suspect that this is fixed a different way
in 0.8. Is that right? Seems like it will adopt orphans

Re: [Ipsec-tools-devel] phase1 phase2 association

[Timo Teräs <timo.teras@ik...>]

Paul Moore wrote:
> This is all based on .7x
> 
> once a phase2 is set up it is unlinked from its phase1

Yes, according to specification phase2 is not stricly bound to phase1.
When sending notify about phase2, any valid phase1 for the remote can
be used.

> if that phase1 goes away (forcibly closed, expires,...) we throw it away
> because its phase2 chain is empty

Doesn't purge_remote use SADB dump to get list of all IPsec SA:s and
purge all SA:s that do not have any valid phase1 left.

Please do note also that you need to send the phase2 deletion notifys
before the phase1 deletion notify. I think currently in various places,
the phase1 deletion notify is sent before purge_remote() call that
would now send the phase2 notifys. After sending the phase1 notify
the remote effectively would ignore the further phase2 notifys as the
far side phase1 was cleared earlier.

> now when the phase2 is deleted (expiry, setkey -F,...) we cannot tell
> the far side about it because we dont have its phase 1

Correct. And it does not make sense to renegotiate phase1 only for
the notification. Additionally, notifications are not reliable so
this should not matter anyway.

> seems to me that the simple thing is to not unbind the phase2 (and hence
> make the phase1 linger) but I suspect that this is fixed a different way
> in 0.8. Is that right? Seems like it will adopt orphans

Correct. In CVS HEAD, the phase2 is always bound to some valid phase1
if one exists. There is also a "rekey" option that will renew expiring
phase1:s as long as there are valid phase2:s around (this is a requirement
for working DPD).

Cheers,
  Timo

Re: [Ipsec-tools-devel] phase1 phase2 association

[Paul Moore <paul.moore@ce...>]

In transport mode (I dont know about tunnel) deletes are very important. If m1 deletes an m1-m2 SA and m2 does not know then m2 will try to use the SA to talk to m1. This communication will fail and the two system can no longer talk to each other. This is why I am tracking down all lost delete notifications. I appreciate that the whole thing is unreliable anyway but I can at least try to minimize the bad outcomes.

I appreciate that a phase2 is not bound to a phase1 in any protocol sense. It is allowable to shut down a phase1 and have its phase2 live on, etc. But in order to send or receive informational messages about a phase2 a phase1 is required.

I have 2 very specific problems

If a phase1 goes away I now have a bunch of phase2s that I cannot announce deletes for. Seems that the best thing to do here is to use another phase1 to the same peer or if there isn't one then I should make one

Talking to Windows: when it expires a phase1 it next sends deletes for the phase2 (if it decides to shut them down not always). It send the ph2 deletes after the phase1 delete (!). So now racoon cant read them becuase it threw away the phase1 state. This really seems like a windows bug to me. This one cannot be solved in the same way - here I must retain the phase1 until all the derived phase2 go away

Re: [Ipsec-tools-devel] phase1 phase2 association

[Timo Teräs <timo.teras@ik...>]

Paul Moore wrote:
> In transport mode (I dont know about tunnel) deletes are very
> important. If m1 deletes an m1-m2 SA and m2 does not know then m2
> will try to use the SA to talk to m1. This communication will fail
> and the two system can no longer talk to each other. This is why I am
> tracking down all lost delete notifications. I appreciate that the
> whole thing is unreliable anyway but I can at least try to minimize
> the bad outcomes.

Yes, I know non-deleted SA:s can become problematic.

> I appreciate that a phase2 is not bound to a phase1 in any protocol
> sense. It is allowable to shut down a phase1 and have its phase2 live
> on, etc. But in order to send or receive informational messages about
> a phase2 a phase1 is required.

Correct.

> I have 2 very specific problems
> 
> If a phase1 goes away I now have a bunch of phase2s that I cannot
> announce deletes for. Seems that the best thing to do here is to use
> another phase1 to the same peer or if there isn't one then I should
> make one

You should consider using the 0.8 branch code and turn rekeying on.
This way you'll always have valid phase1 if there are valid phase2:s.
I think this is also what Windows does.

Also you might consider using DPD. This way the SA:s get deleted
automatically if the remote does not recognize the phase1 anymore.

> Talking to Windows: when it expires a phase1 it next sends deletes
> for the phase2 (if it decides to shut them down not always). It send
> the ph2 deletes after the phase1 delete (!). So now racoon cant read
> them becuase it threw away the phase1 state. This really seems like a
> windows bug to me. This one cannot be solved in the same way - here I
> must retain the phase1 until all the derived phase2 go away

Sounds like broken Windows. I think on receipt of delete payload,
we should not delete immediately the phase1. Instead you just mark
it to expire e.g. in 2 seconds or so. That way you can still process
the possible incoming phase2 deletes.

- Timo