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

Re: IKEv1 and multiple SAs ?




> In your previous mail you wrote:
>
>    > => this is about rekeying of IPsec SAs (not what happens with
IKE/ISAKMP
>    SAs).
>    > In IKEv1 the replaced IPsec SAs are explicitely deleted, in
IKEv2 they are
>    > flushed on timeout, i.e., implicitely deleted.
>
> => note that I was wrong: in IKEv2 one should delete the replaced SA
too.
> The IKEv2 spec is not very clear, for instance it implicitely uses
the
> terms delete and close for ending a SA. I believe that "delete"
implies
> sending a delete payload.
>
>    Thanks for the clarification. I  was asking about the old IPsec
SAs (not the
>    replaced SAs)
>    which IKEv1 implementations implicitly deleted. Does all IKEv1
>    implementations do so when
>    a new IPsec SA is setup for the same traffic selectors ?
>
> => I believe you refer to: "the IKEv1 rekeying heuristic of deleting
> SAs on the basis of duplicate traffic selectors" (BTW where this is
> specified?). Racoon doesn't do this: in racoon only the initiator
> rekeys (something which doesn't work in IKEv2 because the lifetimes
> are no more negociated).
> This is not explained in section 2.8 but the rekey collision can be
> detected because a REKEY_SA notification is in the CREATE_CHILD_SA.
> As this message is copied in the list, I'd like this is explained
> in the next IKEv2 spec or rationale/tutorial.
>
Right. If REKEY_SA is explained in section 2.8 which explains about
rekeying,
it would really clarify this case.  Only if REKEY_SA is included, the
old IPsec SAs
SHOULD be deleted. Otherwise, the old IPsec SA should be left around
till it expires.

-mohan