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
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
