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

Re: IKEv1 and multiple SAs ?



 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

Francis.Dupont@enst-bretagne.fr