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

[Yoav Nir <[e-mail]>]

Hi

The reason that we don’t have any mention of simultaneous SA creation is that this issue has not come up in practice.  When two IPsec hosts don’t have an SA for a particular flow (because said flow hasn’t had traffic in a while), it’s highly unlikely that bidirectional traffic on this flow will begin simultaneously, or at least before the 1-2 roundtrips it takes to set up a child SA.

On the other hand, when SA lifetimes are set and traffic is continuous, it’s very likely that two such implementations will begin a rekeying at the same time.

So what would happen?  Both implementations get a CreateChildSA request (or an IKE_AUTH request) after each has sent out its own request. I guess we could specify it the same way as in section 2.8.1, but doing this would be a problem because this is not specified and other implementations are likely not to do it.

Sorry I don’t have a better answer for you.

Yoav

On May 2, 2014, at 3:27 PM, Syed Ajim Hussain <[e-mail]> wrote:

> 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
> 
> 
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec