Re: IKEv1 and multiple SAs ?

["Mohan Parthasarathy" <mohanp@sbcglobal.net>]

Francis,


> In your previous mail you wrote:
>
>    IKEv2 (section 2.8) draft talks about the IKEv1 rekying heuristic where
>    IKEv1 implementations delete old SAs when a new SA is established for
the
>    same traffic selector.
>
> => 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.
>
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 ?

>    Do these implementations delete the SA always in these cases
>
> => IPsec SAs are always deleted when asked or when they have reached their
> hard timeout.
>
That's not what i read from section 2.8 of IKEv2 draft.

>    or only when they see a INITIAL_CONTACT notify message also ?
>
> => the INITIAL_CONTACT is very different: it is sent by a peer which
> believes it has no SA, i.e., already existing SAs are from a previous
> session and the peer has lost any state about it.
>
This means, only when i see a INITIAL_CONTACT, i can clean up all old
IKE SAs and IPsec SAs. Correct ? Is that what the existing implementations
do ?

>    Any information would be appreciated.
>
> => RFC 2407 4.6.3.3 for INITIAL_CONTACT
>    draft-ietf-ipsec-ikev2-11.txt pages 64-65
>     (different because the IKEv2 spec is about previous IKE SAs)

This is a bit confusing. Why would you keep the IPsec SAs around in this
case ?
The sender by sending INITIAL_CONTACT says that this is the only IKE SA.
This implies that he has no previous IKE SAs or IPsec SAs which means the
receiver can delete all of them. Why is it specific to IKE SAs ?

-mohan

>    isakmp_inf.c:info_recv_initialcontact()
>      (with this cryptic comment:
>         /*
>          * delete all phase2 sa relatived to the destination address.
>          * Don't delete Phase 1 handlers on INITIAL-CONTACT, and don't
ignore
>          * an INITIAL-CONTACT if we have contacted the peer.  This matches
the
>          * Sun IKE behavior, and makes rekeying work much better when the
peer
>          * restarts.
>          */)
>
> Regards
>
> Francis.Dupont@enst-bretagne.fr