[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(racoon 806) Re: Dual, synchronous quick mode
- To: Yves-Emmanuel Jutard <email@example.com>
- Subject: (racoon 806) Re: Dual, synchronous quick mode
- From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
- Date: Wed, 13 Oct 2004 23:56:43 +0200
- Cc: firstname.lastname@example.org
- Delivered-to: email@example.com
- Delivered-to: firstname.lastname@example.org
- Delivered-to: email@example.com
- In-reply-to: Your message of Wed, 13 Oct 2004 17:41:39 +0200. <firstname.lastname@example.org>
- Reply-to: email@example.com
- Sender: firstname.lastname@example.org
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
=> 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
=> 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).