[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

(racoon 806) Re: Dual, synchronous quick mode

 In your previous mail you wrote:

   Thanks for the quickness and accuracy of your response. For other
   readers, the entire outlined passage is :
   
   "If the two ends have the same lifetime policies, it is possible that
      both will initiate a rekeying at the same time (which will result in
      redundant SAs). To reduce the probability of this happening, the
      timing of rekeying requests SHOULD be jittered (delayed by a random
      amount of time after the need for rekeying is noticed)."
   (draft-ietf-ipsec-ikev2-17.txt, page 21)
   
=> please add the two next paragraphs because only the last one is
really about IKEv1 even the IKEv2 solution seems better.

   So, if I understand well, it means that an IKE design flaw not
   described in IKEv1 RFC (impossibility to merge two concurrent phase 2
   into one)

=> this is not a design flaw...

   provoque, under certain conditions, the creation of
   redundant SA. This phenomenon cannot be fully avoided but only made
   less common by tweaking the IPsec layer (jittering the soft limit
   before asking IKE to renew).
   
=> it cannot be avoided but it must be solved, i.e., one of the two
SA pairs must be closed.

   So, provided that I protect all my traffic between two hosts with a
   single SP, a SADB must be able to store at last 2 SA for each  SP,
   instead of only one, as one could have thought at first glance. (here
   is my mistake)
   
=> you missed a detail: if the problem is not solved you'll get an extra
SA pair at each rekey.

   Will that be sufficient to have a working IKE implementation or do I
   miss something else ?
   
=> IMHO the bug should be fixed.

   And what if two phase 1 start simultaneously ? Do racoon handle this
   case ?

=> no but the issue is different. BTW why not put one side passive?

   It's harder to produce such a collision and I have not yet
   figured out in racoon code what happen when a base_i1send() call is
   followed by base_r1recv().
   
=> it doesn't happen with two different peers (i.e., racoon not talking
to itself) because the cookies (ISAKMP SA SPI) are different.
With one peer the IV computation fails (at least the last time I tried).

Regards

Francis.Dupont@enst-bretagne.fr