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

From: Syed Ajim Hussain <[email-masked]>
Date: Fri, 2 May 2014 12:27:41 +0000

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

---

From: Yoav Nir <[email-masked]>
Date: Sun, 4 May 2014 10:18:46 +0300

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 <[email-masked]> wrote:

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Syed Ajim Hussain <[email-masked]>
Date: Mon, 5 May 2014 04:53:27 +0000

Hi Yoav  
       Thanks for your reply, This problem happened in real scenario,  problem is-  both the Tunnel end points are different vendor, 
       They handle it differently.    

       We can defined this behavior in RFC,

       Also we have some other scenarios, it will be better if we define these extreme case behavior also in RFC, 
       to make inter-op smooth.                                         

With Regards
Syed Ajim 

-----Original Message-----
From: Yoav Nir [mailto:[email-masked]] 
Sent: 2014年5月4日 12:49
To: Syed Ajim Hussain
Cc: [email-masked]
Subject: Re: [IPsec] Simultaneous Child SA Creation tigger from both the side.

Hi

Yoav

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 5 May 2014 10:35:19 +0400

Hi Syed Ajim,

> Hi Yoav
>       Thanks for your reply, This problem happened in real scenario, 
> problem is-  both the Tunnel end points are different vendor,

I agree with Yoav that this situation is extremely rare in practice.
Note, that RFC4301 deliberately allows to have multiple IPsec SAs
established betwen the same peers with the same traffic selectors
(for example for the purposes of QoS). So, you can't just delete
"erroneous" SA because you have SA with the same traffic selector -
the peer may create it for purpose.

What about your use case - what's wrong if there are two SAs?
Of course, it is some waste of resources, but if your implementation
selects outgoing SA deterministically and both peers use the same
SA, the other will eventually die by lifetime expiration
(as no traffic will flow through it).

Regards,
Valery Smyslov.

> 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.
>
> 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.
>
>>    Assume  Host-A & Host-B want to established IPSEC Tunnel, First they 
>> established one IKE SA and  one IPSEC SA (Child SA).
>>
>>    This Child SA creation hit simultaneous Child SA Creation condition. 
>> Since both the side triggered for  Child SA
>>    In RFC 5996 , there is no point mention about simultaneous exchange 
>> during  Child SA create, it only mention Simultaneous
>>    What should be the behavior in case of Simultaneous  Child SA 
>> Creation, if implementation maintain one Child SA per one Traffic Flow 
>> (SPD).
>>

---

From: Paul Wouters <[email-masked]>
Date: Mon, 5 May 2014 09:09:09 -0400 (EDT)

>       Also we have some other scenarios, it will be better if we define these extreme case behavior also in RFC,

In libreswan (openswan) the daemon processes one packet at a time, so by
definition one of the child SA's finishes before the other, no matter
how close the timing is. It also has a feature "uniqueids" that would
(dis)allow identical Child SA's, so the latter one establishing replaces
the previous one established.

I'm not convinced your issue is a protocol issue. It seems more like an
implementation issue? If any of your endpoints involved
libreswan/openswan, feel free to contact me.

Paul

---

From: Nico Williams <[email-masked]>
Date: Mon, 5 May 2014 14:53:19 -0500

>        They handle it differently.

Near as I can tell there are two possible behaviors: two (or more)
sets of SAs, or one set with each exchange resulting in new SAs that
replace the old ones.  If other behaviors result, I'd like to hear it!

>        We can defined this behavior in RFC,

If the two behaviors result straightforwardly from the RFC as it
stands and local implementation choices, then I don't see a need to
"define", just describe.  Publishing a new RFC to describe this seems
a bit wasteful of resources.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 5 May 2014 14:56:40 -0500

Also, it seems clear that any implementation that adheres to the spec
as it is will either a) produce just one set of SAs in this case (see
Paul's response), or b) propose N>=1 sets of SAs.  The (b) case should
interop with the (a) case just fine, resulting in N==1 set of SAs.
All three possible combinations of implementation behaviors should
interop.

Nico
--

---

From: Yoav Nir <[email-masked]>
Date: Mon, 5 May 2014 23:49:24 +0300

The premise is that the implementation supports just one set of SAs.

So both send out a request, and both receive the other request first, and then the response to their respective original request. If both peers now send out a DELETE to remove the SA initiated by the other side, they will end up with no SAs at all.  

That may be interop, but it’s not a good result.

Yoav

---

From: Praveen Sathyanarayan <[email-masked]>
Date: Mon, 5 May 2014 20:54:15 +0000

I agree, it is a corner case. Example, out of 5000 tunnels, may be we will
see 10 to 15 tunnels end up in this scenario. So memory/resource is not a
concern. But question is, how do we handle once we are in that state. For
example, which phase1/phase2 SA we should continue to hold (Rekey) and
which one we need drop it, etc.

This is where the confusion comes. Each vendor may end up choosing
different way to handle it and it may cause confusion with other vendor.
If there is a clear description on how to handle (which one to choose and
which one to drop), will help.

Thanks,
Praveen

On 5/5/14, 6:09 AM, "Paul Wouters" <[email-masked]> wrote:

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 6 May 2014 15:50:00 +0300

Praveen Sathyanarayan writes:
> concern. 

There are two cases: Your implementation is very limited, and support
very few Child SAs and cannot cope when there are two SAs. In that
case your implementation will reply with NO_ADDITIONAL_SAS to
CREATE_CHILD_SA requests coming in, when they do not have space in the
Child SA table. If both ends are limited implementations and both of
them reply with NO_ADDITIONAL_SAS, then following the section 4 of
RFC5996 they need to delete the IKE SA and start over.

----------------------------------------------------------------------
1.3.  The CREATE_CHILD_SA Exchange
...
   The responder sends a NO_ADDITIONAL_SAS notification to indicate that
   a CREATE_CHILD_SA request is unacceptable because the responder is
   unwilling to accept any more Child SAs on this IKE SA.  This
   notification can also be used to reject IKE SA rekey.  Some minimal
   implementations may only accept a single Child SA setup in the
   context of an initial IKE exchange and reject any subsequent attempts
   to add more.
...
4.  Conformance Requirements
...
                                                           A minimal
   implementation MAY support the CREATE_CHILD_SA exchange only in so
   far as to recognize requests and reject them with a Notify payload of
   type NO_ADDITIONAL_SAS.  A minimal implementation need not be able to
   initiate CREATE_CHILD_SA or INFORMATIONAL exchanges.  When an SA
   expires (based on locally configured values of either lifetime or
   octets passed), and implementation MAY either try to renew it with a
   CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and
   create a new one.  If the responder rejects the CREATE_CHILD_SA
   request with a NO_ADDITIONAL_SAS notification, the implementation
   MUST be capable of instead deleting the old SA and creating a new
   one.
----------------------------------------------------------------------

If your implemenations do support multiple SAs, then you MUST accept
to create two SAs, as there is no way from the responder to know why
the other end is creating the SA. It might be that the other end is
creating it because of this policy reload, but it might also be caused
because the other end got traffic on different QoS level, and needs to
create separate SA for that QoS level. Section 4.1 of RFC4301 says:

----------------------------------------------------------------------
4.1.  Definition and Scope
...
				Therefore, a sender SHOULD
   put traffic of different classes, but with the same selector values,
   on different SAs to support Quality of Service (QoS) appropriately.
   To permit this, the IPsec implementation MUST permit establishment
   and maintenance of multiple SAs between a given sender and receiver,
   with the same selectors.  Distribution of traffic among these
   parallel SAs to support QoS is locally determined by the sender and
   is not negotiated by IKE.  The receiver MUST process the packets from
   the different SAs without prejudice.
...
----------------------------------------------------------------------

and Section 2.8 in RFC5996

----------------------------------------------------------------------
2.8.  Rekeying
...
   Note that IKEv2 deliberately allows parallel SAs with the same
   Traffic Selectors between common endpoints.  One of the purposes of
   this is to support traffic quality of service (QoS) differences among
   the SAs (see [DIFFSERVFIELD], [DIFFSERVARCH], and Section 4.1 of
   [DIFFTUNNEL]).  Hence unlike IKEv1, the combination of the endpoints
   and the Traffic Selectors may not uniquely identify an SA between
   those endpoints, so the IKEv1 rekeying heuristic of deleting SAs on
   the basis of duplicate Traffic Selectors SHOULD NOT be used.
----------------------------------------------------------------------	

So the end result with non-minimal implementations is that there will
be two Child SAs with same traffic selectors.

> But question is, how do we handle once we are in that state. For

Both of the SAs are valid and both ends needs to process packets
coming from either of SA without prejudice. Each implementation will
most likely pick one SA when sending traffic and it will send traffic
out from that SA. Neither end should not drop SAs as it does not know
why the other end created them.

When it comes time to rekey, then it depends on the implementation
what will happen. If both ends happened to select same SA pair for
their traffic, then when it comes to time to rekey the second SA, it
is dropped as there has not been traffic on it at all (there is no
point of rekeying SA which do not have traffic).

If they picked different SAs for their traffic and one of them is
going to rekey his outbound SA, then he will rekey that and the old SA
is deleted. Now the other peer might notice that when his outbound SA
is about to expire, he notices that there is already good Child SA
with same traffic selectors which is going to be valid, so he might
simply just skip the rekeying and instead move the traffic to the
other SA. Then as he didn't do rekey, then when the SA actually
expires, then he will delete it.

If they happened to do rekey exactly same time (both of them happen to
have exactly same lifetimes), then it might be possible that both ends
rekey their own outgoing SA and the situation continues. There is no
possibility for getting more SAs as this is rekey, not creating new
SA, so simultaneous rekeys are already covered by the protocol. Also
both ends only use one SA for sending, so at most there can be two SA
pairs between the peers that has traffic, and all others should not be
rekeyed, as there has not been any traffic. 

All of that is just implementation details, not protocol issues. As
there is no concept of "one Child SA per one Traffic Flow (SPD)" in
the IPsec architecture, if you implement such concept you need to
define how it should work. On the other hand IKEv2 do have mandatory
feature that you support multiple Child SAs with same Traffic
Selectors... On the other hand Traffic Flow and Traffic Selectors are
not the same thing. Traffic flow could include other things which
cannot be expressed in Traffic Selectors, like QoS parameters etc.
-- 
[email-masked]