Yoav Nir writes:
>
> 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
^^^^^^^^^^^^
It is not unacceptable to initiate rekeying at the same time. It can
and will happen. What is unacceptable is that we get two IKE SAs and
parties do not agree on which one is the one that should be used, and
to which one the Child SAs are moved to.
> 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
Again we cannot avoid the case where they start CREATE_CHILD_SA
exchange simultaneously. We can only give rules how to solve this.
> 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.
This is completely unacceptable. Firstly it is not following the rules
already in the RFC4306 which cleary says that both IKE SAs are created
as normally, and then the one follow the rule: "the SA created with
the lowest of the four nonces used in the two exchanges SHOULD be
closed by the endpoint that created it."
With IKE SAs this just requires that both ends need to agree that
child SAs are always moved to the other IKE SA.
We already do implement this rule specified in the RFC4306 for IKE
SAs, we do not care about the simultaneous CHILD_SA/IPsec SA rekeys as
they do not really cause problems (there will be duplicate
CHILD_SAs/IPsec SAs but everything still works).
Anyways we cannot "silently discard" any IKE SA packets, IKE SA basic
principle is to provide request/reply exchages, thus there must be
reply, as otherwise the other end will tear down the IKE SA.
> 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.
This will be major change to the existing RFC4306 behavior. Especially
is it violates the basic IKEv2 exchange principles. I thing doing this
is really bad idea.
It requires quite big changes to all over the code (i.e. ability to
get messages back from the retransmit and window processing queue),
and so on.
The current code we have already implemented, and which works (I only
use the example where all request packets from responder are lost for
duration of the initiators exchnage as that covers all possible
cases):
Host A Host B
------------ ----------------
# Start rekey # Start rekey
HDR, SK{SA(SPIa1), Ni1, KEi1} --->
X <--- HDR, SK{SA(SPIb2), Ni2, KEi2}
This is dropped
# B receives A's requst
# It knows there is simultaneous
# rekey, but it will not yet
# know A's reply nonce, so cannot
# do anything. It ties both
# rekeyed SAs together and to old IKE
# SA, and replies normaly
<--- HDR, SK{SA(SPIb1), Nr1, KEr1}
# A receives B's reply, but it
# still does not know there
# is simultaneous rekey as
# it has not seen B's
# request yet.
# It processes request
# normally, creates new IKE SA1
# and moves Child SAs from old
# IKE SA to this IKE SA1.
# It starts timer that will
# delete old IKE SA after a
# while (60 seconds or so)
# It will still tie
# old IKE SA and new IKE SA1
# together.
# B retransmits and A gets the request
<--- HDR, SK{SA(SPIb2), Ni2, KEi2}
# Now A notices there was
# Simultaneous rekey
# It will process the request
# normally and create new IKE SA2
# and send reply back
HDR, SK{SA(SPIa2), Nr2, KEr2} --->
# A knows there was # B already knows there was
# simultaneous rekey # simultaneous rekey so it
# so it starts to handle # finishes the IKE SA2
# the case. It has already # and starts to handle
# tied the old IKE SA and # the case. It also has
# IKE SA1 togther, and now # old IKE SA and both
# it adds IKE SA2 there, and # new IKE SAs tied together
# compares the Nonces (Ni1, # so it will do the same thing
# Ni2, Nr1, Nr2) and finds # as A does, i.e. checks
# the lowest one of them. # which one of new IKE SAs
# If it was one if his # survived, and moves
# then it starts timer # all child SAs from
# to close that SA after # loosing IKE SA to the
# timeout. In any case # surviving one.
# it makes sure all # If it was the one
# child SAs of that # creating the loosing one
# losing IKE SA is moved # it will start
# to the surviving IKE SA. # timer to delete it.
# Lets say IKE SA1 lost, so
# A will delete it after some
# timeout (60 seconds or so
# to make sure other end has
# received all packets)
HDR(IKE SA1), SK{D} --->
# B deletes IKE SA 1, which
# is already empty, and
# sends reply
<--- HDR(IKE SA1), SK{}
# Either end can delete the old IKE SA (normally it is done
# by the host who started rekey, but as both here started
# it either end can delete it). Lets assume here that
# A's timer expires first (most likely as it started it before it
# even knew B has started rekey), so A will send delete for that SA
# too.
HDR(old IKE SA), SK{D} --->
# B deletes old IKE SA, which
# is already empty, and
# sends reply
<--- HDR(old IKE SA), SK{}
This is what we have in our implementation and this is also what is
described in the RFC4306. As RFC4306 only says this very briefly and
bit vague terms (i.e. just refers to SA, not separting Child SAs and
IKE SAs), this requires more text to the bis document, but I do not
think we want to completely change the behavior of the protocol in
this exeptional case. Especially we do not want to break IKEv2 rules
where (from section 1 Introduction):
- All IKE communications consist of pairs of messages:
a request and a response.
- IKE message flow always consists of a request followed by a
response. It is the responsibility of the requester to ensure
reliability. If the response is not received within a timeout
interval, the requester needs to retransmit the request (or
abandon the connection)
For example I do not have any idea what happens to the message IDs of
the old IKE SA in your case, i.e. if request is pulled back, is the
message ID still incremented, and if request is silently ignored is
that message id still marked as used in the window etc. What if we
sent first IKE SA rekey and then another message (i.e using window
size > 1), now if we pupp back that IKE SA rekey request, do we reuse
the empty slot we have in window. If we do not have any other exchange
we want to send do we fill it with some junk exchange. Also for
example mobike do assume that message IDs are used in order, i.e.
message ID n must be sent AFTER message ID n-1, i.e. address update in
message ID n-1 can be safely ignored when address update in message ID
n is seen, as message ID n is newer than message ID n-1, thus refers
to the latest situation.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
