Hi all.
Section 2.8.1 of the draft discusses what to do when Child SAs are rekeyed
simultaneously by both peers. Issue #22 asks to clarify the same thing for
simultaneous rekeying of IKE SAs.
We've written a proposed additional section, that should be labeled 2.8.2.
Since this specifies new behavior that was not specified before, we want your
comments before putting this into the draft.
Thanks
Yoav
2.8.2. Simultaneous IKE SA rekeying
If the two ends have the same key lifetime policies for IKE SAs, it
is possible that both will initiate a rekeying at the same time.
This is unacceptable for IKE SAs, because the IKE SAs own the child
SAs, and deleting the IKE SA leeds to deletion of all child 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).
To avoid the case of two IKE SAs created by simultaneous
CREATE_CHILD_SA exchanges, the IKE SA with the lowest of the
initiator nonces is silently discarded, and the dependent child SAs
are transferred only to the IKE SA with the higher of the two
initiator nonces. Here "higher" and "lower" refer to octet-by-octet,
lexicographical comparison of the nonces as large integers.
The rules are as follows:
1. If a rekey request is received before this host has sent a rekey
request of its own, this host MUST NOT send a rekey request.
Instead, it MUST reply to the rekey request it has received.
2. If a rekey request is received after this host has sent a rekey
request, then this host MUST compare the two initiator nonce
values. If the received nonce is higher than its own, it MUST
reply to the received request, and SHOULD stop retransmissions of
its own request. If the received nonce is lower, it MUST ignore
the received request.
3. If a rekey request is received after this host has sent a rekey
request, and the peer has already replied, the new received
request MUST be ignored.
Following these rules should prevent any case of multiple successful
rekeys of an IKE SA. The only case where the 2nd rule would be
needed is if both requests were sent before either of them was
processed. The implementation whose rekey request was answered
SHOULD delete the old IKE SA soon after. The other implementation
SHOULD wait at least one minute before deleting the IKE SA unless its
peer requests the deletion earlier.
The following is an explanation of the impact this has on
implementations. Assume that hosts A and B have an existing IKE SA,
and both start rekeying it at the same time:
Host A Host B
-----------------------------------------------------------------
send req1: SK{SA, Ni1, [KEi]}
-->
<-- send req2: SK{SA, Ni2, [KEi]}
recv req2 <--
At this point, host A knows there is a simultaneous rekeying going
on. Assume that Ni2<Ni1. A knows that req1 is the one to answer, so
it ignores req2.
--> recv req1
Now host B also knows that simultaneous rekeying is going on. It has
also figured out that req1 is the one to respond to, so it does so.
<-- send resp1: SK {SA, Nr,[KEr]}
recv resp1 <--
Now let's look at the other case, namely where Ni1<Ni2.
Host A Host B
-----------------------------------------------------------------
send req1: SK{SA, Ni1, [KEi]}
-->
<-- send req2: SK{SA, Ni2, [KEi]}
recv req2 <--
Host A knows that req1 is the one to ignore, because req2 has a
higher nonce. It replies to req2, and will not re-transmit req1.
send resp2: SK {SA, Nr,[KEr]}
--> recv req1
Now host B is in exactly the same position as host A was in the first
example. It compares nonces, and ignores req1.
--> recv resp2
Host B now knows that the rekey is complete.
To demonstrate the third rule, let's assume again that Ni1<Ni2, but
that the sequence of messages is as follows:
Host A Host B
-----------------------------------------------------------------
send req1: SK{SA, Ni1, [KEi]}
-->
<-- send req2: SK{SA, Ni2, [KEi]}
recv req2 <--
--> recv resp2
Now host B knows nothing about req1, and assumes that its rekey
request was the only one. Host A, however, is aware of the
simultaneous rekey, and has decided that only req2 is to proceed.
--> recv req1
Host B now knows about req1, but since it has already received a
response, it ignores req1. There is no need to compare nonces.
Email secured by Check Point
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
