#52 INITIAL CONTACT message implementation issues

0.6 branch

This issue applies to the 0.6.6 release (at least).

The implementation of the isakmp INITIAL CONTACT
message can corrupt the PF_KEY interface during phase 2
negotiations. The info_recv_initialcontact() uses the
pfkey_dump_sadb() which (can) discard kernel replies to
the getspi PF_KEY message (which is required for phase2)

To demonstrate the problem take two freshly started
racoons: one server and one roadwarrior (anonymous).
Initiate a key exchange from the road warrior. When
phase 1 completes both parties will send the INITIAL
CONTACT message before phase2 completes. The
roadwarrior will (can?) discard the getspi kernel
replies on the PF_KEY interface. This will halt the
key exchange. A second attempt will succeed since
there will be no INITIAL CONTACT message sent.

It seems to me like it is necessary to have a single
point of interface to the PF_KEY socket. Maybe via the
pfkey_handler?. Going in the "back door" with
pfkey_sadb_dump() looks like a way to guarantee broken
code. And then there is the question about whether the
SADB_DUMP message should be used at all since RFC 2367
cautions against it.




  • Timo Teras

    Timo Teras - 2009-01-16
    • status: open --> closed
  • Timo Teras

    Timo Teras - 2009-01-16

    Closing all sourceforge.net bugs. If this issue has not been cared for please submit a new bug report to https://trac.ipsec-tools.net/ issue tracker. Thank you.


Log in to post a comment.