I do not believe the algorithm below is consistent with what was said in section 5.11.4 of RFC 4718. Section 5.11.4 of RFC 4718 said:
5.11.4. Simultaneous IKE_SA Rekeying
Probably the most complex case occurs when both peers try to rekey
the IKE_SA at the same time. Basically, the text in Section 2.8
applies to this case as well; however, it is important to ensure that
the CHILD_SAs are inherited by the right IKE_SA.
The case where both endpoints notice the simultaneous rekeying works
the same way as with CHILD_SAs. After the CREATE_CHILD_SA exchanges,
three IKE_SAs exist between A and B; the one containing the lowest
nonce inherits the CHILD_SAs.
"After the CREATE_CHILD_SA exchanges" implies the exchanges are expected to
complete before the simultaneous rekey is resolved. The algorithm below
resolves the simultaneous rekey during the CREATE_CHILD_SA exchange and
only allows one rekey to complete. My concern is that the algorithm below
will be incompatible with anybody that implemented to RFC 4718.
A slight tangent to this is that the possibility of a simultaneous
reauthentication exists, however, RFC 4306, RFC 4718, and the current bis
draft does not address that scenario. Given that the a reauthentication is
done by creating a new IKE_SA from scratch I'm not even sure if it is
possible to detect a simultaneous reauthentication of an IKE_SA, but it
would be nice if we could.
Yoav Nir
<y...@checkpoint.
com> To
Sent by: "ipsec@ietf.org" <ipsec@ietf.org>
ipsec-boun...@iet cc
f.org
Subject
[IPsec] Issue #22: simultaneous IKE
02/17/2009 05:03 SA rekeys
AM
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
<<inline: graycol.gif>>
<<inline: pic04356.gif>>
<<inline: ecblank.gif>>
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
