[Openswan dev] Yet another DPD issue

Mark-Andre Hopf mhopf at innominate.com
Tue Jul 17 05:43:15 EDT 2007

On Mon 16.07. 12:21, Michael Richardson wrote:

> >>>>> "Mark-Andre" == Mark-Andre Hopf <mhopf at innominate.com> writes:
>     Mark-Andre> The git repository is Openswan 3.0.0 only, right?
>   2.5.xx onwards.
>     Mark-Andre> (And does that mean that 'DPD issue with multiple
>     Mark-Andre> tunnels between two peers' is fixed in Openswan
>     Mark-Andre> 3.0.0. What about the stable branch? There was no
>     Mark-Andre> response on the list.)
>     Mark-Andre> Anyway, would you agree that binding DPD to the IPsec SA
>     Mark-Andre> during quick mode is the wrong approach and that doing
>     Mark-Andre> it during main/aggressive mode would be the right thing
>     Mark-Andre> to do?
>   Yes, and that's what the code does.

Are you sure? dpd_init is called during quick_inR1_outI2 and quick_inI2.

This is the wrong place and it's also too late. Eg. Initiator initates ISAKMP
SA, Responder powercycles and Initiator still believes that it has a valid
ISAKMP SA, can't establish an IPsec SA and thus DPD won't be started.

>   However, DPD says that if the phase 2 was active at the IPsec SA
> level, that you can skip the DPD on the IKE SA.

Uh, where? I've found "The IPSec traffic itself serves as the proof of
liveliness." on page 6 of RFC 3706.

And valid ESP traffic proofes that the remote peer has one valid IPsec SA.
(And in case of multiple IPsec SAs to the same peer, one should look for
traffic on _all_ IPsec SAs and in case one had none during a certain time
interval, DPD should send an ARE-YOU-THERE.)

It also does not qualify to _halt_ DPD when a new IPsec SA is to be
negotiated as it is done now.

Looking forward for your answer,
happy hacking,
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

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

More information about the Dev mailing list