[Openswan dev] Yet another DPD issue

[Mark-Andre Hopf]

On Tue 17.07. 08:58, Michael Richardson wrote:

>   You can't send DPD messages until the phase 1 is finished.
> 
>   So, the earliest you can initialize DPD *messages* is once the phase 2
> has started.   
>
>   What has changed in the code is that now
> connection_check_phase2() is called regularly from the timer, and it
> looks to see if the phase 1 has taken too long. Too long is defined by
> the DPD timeout. If so, it kicks off the DPD action, which either kills
> the SA, or it restarts it, etc.
> 
>     Mark-Andre> This is the wrong place and it's also too
>     Mark-Andre> late. Eg. Initiator initates ISAKMP SA, Responder
>     Mark-Andre> powercycles and Initiator still believes that it has a
>     Mark-Andre> valid ISAKMP SA, can't establish an IPsec SA and thus
>     Mark-Andre> DPD won't be started.
> 
>   Re-reading the above, perhaps you are right... the timer should be
> started in quick_outI1, not outI2.    Oh, pluto can't always cope with
> multiple phase 2 exchanges at the same time, although that may well be
> complete history, since we added the multinet code.

 What about main_inI3_outR3 and main_inR3? I know, this does not guarantee
that the phase 1 is really finished as some packets may have been lost and
need to be send again. This could be handled by a greater initial DPD delay.

 But nevertheless, even if we start DPD during phase 2, it should still be
associated with phase 1 to avoid the deactivation of DPD while phase 2 is
renegotiated.
 One DPD_EVENT could then handle multiple IPsec SAs like this: When Pluto
receives an R-U-THERE, it will only answer with an R-U-THERE-ACK when _all_
connections using this phase 1 SA have also a valid phase 2 SA.

(There's still a problem here: If the one connection is temporarily removed
or not added yet, Pluto would not know about it and would send a
R-U-THERE-ACK even if not all IPsec SAs are ready.

The only solution would be to extend the DPD protocol itself to carry
information about the IPsec SAs being monitored. Eg. R-U-THERE contains a
list of the IPsec SAs to be checked and the R-U-THERE-ACK contains a list of
the IPsec SAs which are ready. With a bit of luck this could be even
compatible with other DPD implementations, when they ignore the additional
payload.

This would also limit IPsec SA renegotiation to the IPsec SAs which need to
renegotiated.)

>   Perhaps, I would greatly appreciate a repeatable test case.
> 
>   I think that we'd have to create a new flag to whack such that a test
> case could ask pluto to create the phase 1 only, and then we could crash
> the other end (or firewall port 500), and then do a stock --up.

This sounds like good idea.

Mark

-- 
Dipl.-Inf. Mark-André Hopf
Senior Software Engineer
Innominate Security Technologies AG
protecting industrial networks
tel: +49.30.6392-3284
fax: +49.30.6392-3307
Albert-Einstein-Str. 14
D-12489 Berlin, Germany
www.innominate.com

Register Court: AG Charlottenburg, HR B 81603
Management Board: Joachim Fietz, Dirk Seewald
Chairman of the Supervisory Board: Edward M. Stadum