[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