Re: IKEv1 and multiple SAs ?

[Francis Dupont <Francis.Dupont@enst-bretagne.fr>]

 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.

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

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

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

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

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

Francis.Dupont@enst-bretagne.fr