[IPsec] Simultaneous Child SA Creation tigger from both the side.

[Syed Ajim Hussain <[e-mail]>]

Hi All. 

        Host A --------------Host B  

    Assume  Host-A & Host-B want to established IPSEC Tunnel, First they established one IKE SA and  one IPSEC SA (Child SA).    

    After that due to addition of a new IPSEC Policy(SPD),  Both the sides triggered one more Child  SA creation. 

    This Child SA creation hit simultaneous Child SA Creation condition. Since both the side triggered for  Child SA   
    Creation for one Configured SPD (Traffic Flow). 

    In RFC 5996 , there is no point mention about simultaneous exchange during  Child SA create, it only mention Simultaneous 
    Handling during Child SA Rekey.               

    What should be the behavior in case of Simultaneous  Child SA Creation, if implementation maintain one Child SA per one Traffic Flow (SPD).  

    Does  Simultaneous Child SA Rekeying - method also applicable in case of Child SA Creation (not Rekey).          
          

2.8.1.  Simultaneous Child SA Rekeying

   If the two ends have the same lifetime policies, it is possible that
   both will initiate a rekeying at the same time (which will result in
   redundant SAs).  To reduce the probability of this happening, the
   timing of rekeying requests SHOULD be jittered (delayed by a random
   amount of time after the need for rekeying is noticed).




Kaufman, et al.              Standards Track                   [Page 36]
 
RFC 5996                        IKEv2bis                  September 2010


   This form of rekeying may temporarily result in multiple similar SAs
   between the same pairs of nodes.  When there are two SAs eligible to
   receive packets, a node MUST accept incoming packets through either
   SA.  If redundant SAs are created though such a collision, the SA
   created with the lowest of the four nonces used in the two exchanges
   SHOULD be closed by the endpoint that created it.  "Lowest" means an
   octet-by-octet comparison (instead of, for instance, comparing the
   nonces as large integers).  In other words, start by comparing the
   first octet; if they're equal, move to the next octet, and so on.  If
   you reach the end of one nonce, that nonce is the lower one.  The
   node that initiated the surviving rekeyed SA should delete the
   replaced SA after the new one is established.

   The following is an explanation on the impact this has on
   implementations.  Assume that hosts A and B have an existing Child SA
   pair with SPIs (SPIa1,SPIb1), and both start rekeying it at the same
   time:

   Host A                            Host B
   -------------------------------------------------------------------
   send req1: N(REKEY_SA,SPIa1),
       SA(..,SPIa2,..),Ni1,..  -->
                                <--  send req2: N(REKEY_SA,SPIb1),
                                         SA(..,SPIb2,..),Ni2
   recv req2 <--

   At this point, A knows there is a simultaneous rekeying happening.
   However, it cannot yet know which of the exchanges will have the
   lowest nonce, so it will just note the situation and respond as
   usual.

   send resp2: SA(..,SPIa3,..),
        Nr1,..  -->
                                -->  recv req1

   Now B also knows that simultaneous rekeying is going on.  It responds
   as usual.

                               <--  send resp1: SA(..,SPIb3,..),
                                        Nr2,..
   recv resp1 <--
                               -->  recv resp2

   At this point, there are three Child SA pairs between A and B (the
   old one and two new ones).  A and B can now compare the nonces.
   Suppose that the lowest nonce was Nr1 in message resp2; in this case,
   B (the sender of req2) deletes the redundant new SA, and A (the node
   that initiated the surviving rekeyed SA), deletes the old one.



Kaufman, et al.              Standards Track                   [Page 37]
 
RFC 5996                        IKEv2bis                  September 2010


   send req3: D(SPIa1) -->
                                <--  send req4: D(SPIb2)
                                -->  recv req3
                                <--  send resp3: D(SPIb1)
   recv req4 <--
   send resp4: D(SPIa3) -->

   The rekeying is now finished.

   However, there is a second possible sequence of events that can
   happen if some packets are lost in the network, resulting in
   retransmissions.  The rekeying begins as usual, but A's first packet
   (req1) is lost.

   Host A                            Host B
   -------------------------------------------------------------------
   send req1: N(REKEY_SA,SPIa1),
       SA(..,SPIa2,..),
       Ni1,..  -->  (lost)
                                <--  send req2: N(REKEY_SA,SPIb1),
                                         SA(..,SPIb2,..),Ni2
   recv req2 <--
   send resp2: SA(..,SPIa3,..),
       Nr1,.. -->
                                -->  recv resp2
                                <--  send req3: D(SPIb1)
   recv req3 <--
   send resp3: D(SPIa1) -->
                                -->  recv resp3

   From B's point of view, the rekeying is now completed, and since it
   has not yet received A's req1, it does not even know that there was
   simultaneous rekeying.  However, A will continue retransmitting the
   message, and eventually it will reach B.

   resend req1 -->
                                -->  recv req1

   To B, it looks like A is trying to rekey an SA that no longer exists;
   thus, B responds to the request with something non-fatal such as
   CHILD_SA_NOT_FOUND.

                                <--  send resp1: N(CHILD_SA_NOT_FOUND)
   recv resp1 <--

   When A receives this error, it already knows there was simultaneous
   rekeying, so it can ignore the error message