[Openswan dev] Yet another DPD issue

[Michael Richardson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


{I prefer to keep things on the list, where google can find them}

>>>>> "Mark-Andre" == Mark-Andre Hopf <mhopf at innominate.com> writes:
    >> >>>>> "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.

    Mark-Andre> Are you sure? dpd_init is called during quick_inR1_outI2
    Mark-Andre> and quick_inI2.

  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.

  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.

  I think that the phase 2 would continue to live on the pending list,
and so the above code would kill the phase 1 and start again.  

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

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

  Yes, that's what I'm talking about.  It often isn't really enough.
  We don't really do that, because it's hard to see incoming traffic counts.

- -- 
]            Bear: "Me, I'm just the shape of a bear."          |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr at xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBRpy89ICLcPvd0N1lAQJkOAf+PugqbghU7Hyzby9g89uRE5MwPSAZjbTx
FN8Ex5pLP0mETck5YMAh+8VcOSTIfXjLGIqggIqOp+oBez5SGV1PrBOEZofFcjWo
HTdU4i1gF7I25Qo34LtMVK5CQ2W0pjkpoZLsLJ05HZL9ZqPS3xMfCG1rkUkolhxp
qAfvh86Z7Y9BayxSw6u2tjLJu4tMDH/jdI2vZhXBW0T6ozBnlmDxNLFRrzlPkz0y
cN2nvJgCnVEhLdwn5Zi7QOwV6C50Nmvu4dUXYxj0Q3dZrz5jw1s9qFj8KvwRdxGE
jLnNh9AcFSC9pD5j0IlYkW9NYErGx7BnXfXQwT0XtD+ZixS9dIfv6Q==
=LKLL
-----END PGP SIGNATURE-----