Subject: Re: IKEv1 and multiple SAs ?

From: Francis Dupont <[email-masked]>
Date: Fri, 09 Jan 2004 10:27:23 +0100

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.

   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.

   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.

   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)
   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

[email-masked]

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 8 Jan 2004 15:04:18 -0800

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. Do these implementations delete the SA always in
these cases or only when they see a INITIAL_CONTACT notify message also ?
Are these common ?

thanks
mohan

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Fri, 9 Jan 2004 10:13:49 -0800

Francis,

> 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 ?

> => IPsec SAs are always deleted when asked or when they have reached their
That's not what i read from section 2.8 of IKEv2 draft.

> 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 ?

>     (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

---

From: Francis Dupont <[email-masked]>
Date: Sat, 10 Jan 2004 13:10:46 +0100

> 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.

=> 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.

   >    Do these implementations delete the SA always in these cases?
   >

=> An IPsec SA has two lifetimes, a soft one (when it is reached, the SA
enters the DYING state and a PF_KEY SADB_EXPIRE is sent to IKE) and a hard
one (when it is reached, the SA enters the DEAD state. is no more usable
and will be garbaged collected), this is managed by the kernel itself
(in KAME the SADB is scaned every second).

   This means, only when i see a INITIAL_CONTACT, i can clean up all old
   IKE SAs and IPsec SAs. Correct ?

=> yes. BTW racoon only deletes IPsec SAs matching source and destination.

   Is that what the existing implementations do ?

=> IMHO yes when they don't implement some kind of dead peer detection.

=> in IKEv2 when an IKE SA is closed all the IPsec SAs it manages are
closed too. So the effect is the same but in a cleaner way (the fact
in IKEv2 the IKE SA is used to manage the IPsec SAs (in place of to be
used only to establish and delete some of them) is one of its major
improvements).

Regards

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 12 Jan 2004 09:54:25 -0800

>    > => this is about rekeying of IPsec SAs (not what happens with
IKE/ISAKMP
>    SAs).
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