[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(racoon 804) Re: Dual, synchronous quick mode
On Wed, 13 Oct 2004 00:33:59 +0200, Francis Dupont
<francis.dupont@enst-bretagne.fr> wrote:
> In your previous mail you wrote:
>
> I am a (french) NetBSD/Racoon user, and I have an IKE/IPsec problem.
> It happens when, simultaneously, two hosts begin a quick mode with
> each other, with the same parameters. Accoding to my experiments, it
> ends with two SA created instead of one, which do not satisfy me.
>
> => this is explicitely addressed in IKE specs (but I am afraid
> racoon as usual is not compliant at all about this).
> The best text about this is in the IKEv2 draft and begins with:
> If the two ends ...
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)
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) 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).
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)
Will that be sufficient to have a working IKE implementation or do I
miss something else ?
And what if two phase 1 start simultaneously ? Do racoon handle this
case ? 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().
Best regards.