[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Ikev2 IKE-SA rekey collision
Hi,
> > Actually, one could have the same problem you point out, on
> establishment of
> > the original IKE-SA. The spec does say that one should randomize
> > the rekeying time to minimize the likelihood of duplicate
> > SA's resulting from rekeying. I think your suggestion
> > would work...
>
>I'm all for writing something like this into the spec. While it
>trivial to do and implement, it's impossible to retrofit without
>standard-support, since iut'll wind up being non-interoperable, if
>everyone does it differently (one picks the larger nonce, the other
>the smaller nonce, and you wind up with nothing).
>
>Any objections to writing this into the standard?
>
I think it is a good idea to make it standard. otherwise the re-keying
is a major interoperable issue, if we try to avoid duplicate SAs. These
duplicate SAs have some effect from the memory requirements point
of view.
> >if you notice you have duplicate SAs, then drop
> > the one with the larger initiator nonce. With that rule, it also
> > works if there's a collision on the initial IKE-SA (where there
> > isn't a unique initiator, since each of the duplicate SAs would be
> initiated
> > by one end).
> >
> >
> > David Faucher said:
> > Regarding draft-ietf-ipsec-ikev2-02.tx IKE-SA rekeying:
> >
> > If there is a collision where both sides attempt to
> > rekey an IKE-SA at the same time, which one ends up
> > owning the child-SAs?
> >
> > It is possible to avoid this condition all together by
> > simply using some value within the messages to determine
> > who will "win" the rekey. For example, the side whose
> > nonce has the greater value. Alternatively, one could
> > use the initiator of the current IKE-SA to determine
> > who "wins" the rekey.
> >
> > David
> >
> >
>
> --
>Jan Vilhuber vilhuber@cisco.com
>Cisco Systems, San Jose (408) 527-0847
>
>http://www.eff.org/cafe