[Openswan dev] Phase 2 Negotiation Reliability

[Michael Richardson]

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Herbert" == Herbert Xu <herbert at gondor.apana.org.au> writes:
    Herbert> Well since a modified DPD will solve the problem as well
    Herbert> (along with some other problems, e.g., phase 2 rekeyed,
    Herbert> responder reboots, phase 1 rekeyed due to normal expiration

    >> I don't agree that it is as easy to implement.
    >> 
    >> The idea is to send ESP packets in the IPsec SA periodically.

    Herbert> I was thinking of something slightly different.

    Herbert> Based on a vendor ID, we can modify the DPD NOTIFYs to
    Herbert> carry information that identified a particular phase 2 SA.
    Herbert> That way we can directly verify its liveliness.

  I think that this can be done.
  We can actually just add an additional notify that contains the list
of current phase 2 SAs. 
  Unless I'm mis-thinking, each phase 2 has its own set of cookies, and
the DPD messages use the phase 1 cookies. 
  So, we could simply list the phase 2 cookies that we think are active.

  Alternatively, each end could list the IPsec SAs that are active for
incoming traffic. I would propose a notify that looks like:

             
	 +--------+--------+--------+--------+
         |  ver=4 |proto=50|       SPI#      |
         +--------+--------+-----------------+
         |    SPI#         |  IP dest of SPI |   
         +--------+--------+-----------------+
         | IP dest of SPI  |continues for v6 |
         +-----------------------------------+

  I.e. a 10 byte structure for IPv4, and a 22 byte structure for IPv6.

  Upon receiption of such a notify, look up each SPI# and see if we are
using it. If we are *not* using it then send a delete.

  The assumption is that if one delete's the SAs that didn't get created
properly that they should get rekeyed.  This is the lazy version.

  A more active version would check to see if we have a hanging phase 2,
then attempt a rekey.
 
  I was also thinking ... why is it that message 2 of the phase 2 isn't
getting retransmitted longer when message 3 gets lost. The original
thread had some comments from about only 3 retransmits... 
  Can anyone suggest any netfilter modules that might help to build a
test case? I.e. something that will drop the first n-packets of a
stream. Or maybe I should use QoS for that.
  
] Train travel features AC outlets with no take-off restrictions|  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQUmUvYqHRg3pndX9AQFMfgQA0cMJ2mvfW8KFzgHdlHHPg+MYw9AOiVo5
4cZkNRQqUoUzsOAW1W7hC3UPR5y+oLZd9hBuiEuAGjMYXLOIN8Ip9mXIzjKm7erg
oIXvSkB0Dd1/U/63AQEYsT/UvaAiBCxm8akYJmMDuMiKexLhXAufQYFvffuJKUW4
9vLz+rNDCXY=
=SGMl
-----END PGP SIGNATURE-----