>> I agree with what you stated here, but I feel you are addressing
something
>> that is not limited to a simultaneous rekey of the IKE SA. It deals with
>> any
>> rekey of an IKE SA. In my opinion the text is misplaced and should be in a
>> section that deals with handling of outstanding exchanges when an IKE SA
>> is rekeyed.
>
>True. This wait is not really because of simultaneous rekey, but rekey
>in general. The reason I brought this up here, is that I think that
>wait is important and the solution for simulatenous rekey should be
>one that works with such wait.
>
>> With that said I'm not sure I agree with how you propose to
>> handle the outstanding exchanges.
>
>I do not think there is any other way than to wait some time to get
>them finished (or at least failed and acked). The other end who
>started those outstanding exchanges MUST know whether they were
>processed or not. If IKE SA is deleted immediately there is no way
>other end can know that as after IKE SA is deleted the other end does
>not send ACKs back.
RFC 4718 states:
It seems this situation is tricky to handle correctly. Our proposal
is as follows: if a host receives a request to rekey the IKE_SA when
it has CHILD_SAs in "half-open" state (currently being created or
rekeyed), it should reply with NO_PROPOSAL_CHOSEN. If a host
receives a request to create or rekey a CHILD_SA after it has started
rekeying the IKE_SA, it should reply with NO_ADDITIONAL_SAS.
If you have outstanding requests to rekey a CHILD SA when you get
a request to rekey the IKE SA you should respond with
NO_PROPOSAL_CHOSEN. Given that is seems reasonable that you would not
start the rekey of an IKE SA while you have outstanding requests to rekey
a child SA, but if you did then it would make sense that you'd delay
sending the delete request associated with your own successful rekeying
of the IKE SA until those outstanding requests have been responded to.
If you follow 4718 the only request you can have outstanding when you
send a non-error response to an IKE SA rekey request is your own request
to rekey the IKE SA.
>
>> > I agree it should mark the SA so that it is no longer used for the new
>> > SAs initiated from this end, but the other end might have its own
>> > exchanges ongoing when the rekey started, and waiting those to finish
>> > makes protocol work better. When both end mark the old SA as being
>> > "old", meaning no new exchanges are started on it, but old exchanges
>> > are allowed to finished then when those old exchanges are finished,
>> > then the old IKE SA should be deleted (and all operations done on the
>> > old IKE SA should be moved to the winning SA).
>>
>> This sounds like a good idea, but it's not what 4306 required and is a
>> protocol change.
>
>Not really. The RFC4306 do say that you MUST be able to process
>incoming requests while having your own requests out:
>
>2.3. Window Size for Overlapping Requests
>...
> .... An
> IKE endpoint MUST be prepared to accept and process a request while
> it has a request outstanding in order to avoid a deadlock in this
> situation. An IKE endpoint SHOULD be prepared to accept and process
> multiple requests while it has a request outstanding.
>
I see nothing in this text that says you must delay deleting the IKE SA
or accept new requests on an IKE SA that you've rekeyed. That is what
you wish to do and that is a protocol change.
>I.e. when you have REKEY started and even when the rekey itself has
>finished, and delete request sent out (and even replied), you still
>might receive requests from the other end which were started before
>the REKEY was started.
If RFC 4718 is followed the only outstanding create child request that
can be received is a request to rekey the IKE SA. There is little
value in waiting for this. When the peer receives the request to
delete that IKE SA it will know one of two things happened.
The first is the simultaneous rekey was not detected by both peers. The
second is the simultaneous rekey was detected by both peers and the peer
sending the delete did not have the lowest nonce. These are the only
valid reasons for receiving a delete in this case.
>
>I agree that the behavior how to handle the deleting of IKE SA after
>rekey is not described explicitly in RFC4306, but the generic text
>that you MUST be able toprocess incoming requests while having your
>own requests out is there, and that is regardless what those requests
>are.
>
>
>> Based on 4306 I think when an informational exchange request is received
>> containing the delete of an IKE_SA that the receiver can conclude that most
>> likely any outstanding request will fail once a response to the delete is
>> sent. The receiver of the delete request has ways to deal with this.
>
>The other end cannot know that, and IKEv2 is deterministic protocol,
>thus such "most likely" is not enough for it. Here is example to show
>the situation:
As I said above there are only 2 reasons for getting the delete, so
strike the most likely from my original text. If RFC 4718 is followed
the receiver of the delete request can deterministically conclude that
any outstanding create child requests will fail. In addition, the only
outstanding create child request possible in this case is one to rekey
the IKE SA.
>
> Host A Host B
> -------- ----------
> <-- sends request
> packet is dropped by network it
> never reaches the host A
> starts rekey -->
> <-- replies to rekey
If you follow the recommendation in RFC 4718 Host B will reply with
NO_PROPOSAL_CHOSEN and HOST A would not delete the IKE SA.
> starts IKE SA delete -->
> <-- replies to IKE SA delete
>
>Now Host A will delete all of the state of old IKE SA and cannot then
>process the request from Host B even if it ever reaches it. It cannot
>even send error back as the crypto keys and so on are already deleted.
>Host B does not know whether the request was processed or not, as
>situation could have also been this:
>
>
> Host A Host B
> -------- ----------
> <-- sends request
> processes request and sends reply -->
> reply packet is dropped by network it
> never reaches the host B
> starts rekey -->
> <-- replies to rekey
Again, if you follow the recommendation in RFC 4718 Host B will reply with
NO_PROPOSAL_CHOSEN and HOST A would not delete the IKE SA.
> starts IKE SA delete -->
> <-- replies to IKE SA delete
>
>Now Host A thinks that the request host B sent was done and finished
>before rekey, but the Host B does not know that. Host A will not
>retransmit the reply packet unless host B retransmits its request, but
>if the IKE SA is deleted by A before that host B might not have time
>to ever send retransmission for its request, thus B does not know
>whether its request was processed or not.
>
>If host A delays deleting of the IKE SA so long that Host B's
>retransmissions reach it (i.e. time depending on the retransmission
>timers, i.e. for example 31.5 seconds if original retry timer is 500
>ms, and retry timer is doubled after each retry, and retry limit is 6
>packets) then after that time it knows that host B should have been
>able to finish ongoing exchanges during that time, thus it is safe to
>delete IKE SA after that.
>
>During that time it can either process the requests or fail them (I.e.
>it can fail the CREATE_CHILD_SA exchanges trying to create new Child
>SAs, or it can finish them, but if it finishes them, then it should
>make sure the Child SAs are moved to new IKE SA before old IKE SA is
>deleted.
>
>> It can delay sending a response until it receives responses to all
>> outstanding requests.
>
>It cannot as that could reach deadlock situation, and would be against
>the MUST in RFC4306, which says you MUST be able process a request
>while it has a request outstanding.
>
>> It can send a response immediately and conclude
>> that all outstanding requests will fail. In that case it can restart the
>> outstanding request on a newer IKE_SA or wait for traffic to require the
>> creation of a new SA.
>
>As the host A might have already processed the outstanding request
>before it even started the rekey, but the reply was lost, that would
>mean that the host A and B are out of sync.
>
>> > Sending some more suitable error could most likely also work, but
>> > still the IKE SA cannot be deleted immediately. It can only be deleted
>> > when ongoing exchanges have been finished.
>> >
>> > I have not checked out if your suggested version works with all
>> > possible combinations of simulatenous rekeys, but from the first look
>> > it seems it might also work.
>> >
>> > On the other hand there is no text indicating such behavior in the
>> > IKEv2 document, so it is protocol change compared to the old text
>> > which said that simulatenous rekey is processed by checking out the
>> > nonces. The rekeys in this case are simulatenous even when Host A
>> > didn't initially detect that.
>> >
>>
>> Agreed, so we have two possible protocol changes if we need to mandate one
>> or we could allow implementations solve the problem as they see fit. I
>> think
>> my solution is consistent with what is stated in Section 5.11.4 of RFC
>> 4718.
>> You are introducing the need to detect a simultaneous rekey after the fact.
>
>The RFC4306 says what you need to do when you see simultaneous rekey,
>and it only gives you one option: Check for the nonces. The rekey is
>simultaneous, if either end detects it was simultanoues, it is
>completely possible that other end didn't notice it.
RFC 4306 does not say that. RFC 4306 never uses the term simultaneous
rekey. What it does say is:
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.
If only one host detects the simultaneous rekey then redundant SAs
are not created. By adding a timer to delay sending the delete you
are going out of the way to try to create redundant SAs.
>
>Not the that RFC4718 do consider even that case as simultanoues rekey,
>as given by the 5.11.3 as last example. It does give the
>N(NO_PROPOSAL_CHOSEN) option for handling that instead of checking for
>nonces, but I think RFC4718 is in error there, as RFC4306 still says
>you should use nonces even there. 5.11.4 says the simultaneous rekey
>is detect in the same way as was done in 5.11.3.
No, RFC 4306 says if redundant SAs are created use the nonce. If
only one side detects a possible simultaneous reky then redundant SAs
are not created.
>
>And I think the 5.11.4 is also quite wrong there. Remember that
>RFC4718 is only Information RFC trying to clarify things in the
>RFC4306, the RFC4306 is still the standard track document which
>specifies how things are supposed to work.
I suspect that many vendors did what we did with regards to RFC 4718.
We implemented what RFC 4718 suggested. RFC 4718 was the starting
point for the IKEv2bis work. I see no reason to reinvent solutions
contained in RFC 4718.
>
>>
>> > That delay does not have anything to do with simultaneous rekey, it is
>> > needed to allow the ongoing exchanges to finish before old IKE SA is
>> > deleted.
>>
>> As I said earlier I think the ongoing exchange issue should be documented
>> separately from the simultaneous rekey case, although I agree there can
>> be a tie to it if your solution is agreed to.
>
>Yes, we need to add text for that in the ikev2bis somewhere. Where do
>you think it would be best?
I am not sure where it would be best to document how to handle
outstanding exchanges, but I think they should be handled as RFC 4718
recommended.
>
>> > On the other hand RFC4306 specifies exactly ONE way to handle
>> > simulatenous rekey and that is by checking the nonces. The rekey is
>> > simulatenous even when one host didn't immediately detect it as
>> > simulatenous because some packet was lost.
>> >
>> > I agree now that "MUST NOT immediately delete" was too strong, so
>> > "SHOULD NOT immediately delete" is better. If implementation does not
>> > implement larger window sizes, and is used in environments where there
>> > is very limited number of CHILD SAs per IKE SA, so the probability of
>> > getting CREATE_CHILD_SA just when other ends decides to rekey is so
>> > small, that it does not matter even if the whole IKE SA gets deleted
>> > in that case then it can ignore that SHOULD.
>>
>> I think "SHOULD NOT immediately delete" is still too strong. I think
>> "MAY delay the deletion to allow ongoing exchanges to complete" is
>> more appropriate at this point.
>
>I think we should encourage people to allow ongoing exchanes to
>complete in the rekey case, so I think SHOULD is better than MAY.
I do not agree that we should encourage people to go out of their way
to detect a simultaneous IKE SA rekey. I'm fine with allowing an
implementation to do that. I think MAY is the correct way to go.
Dave Wierbowski
z/OS Comm Server Developer
Phone:
Tie line: 620-4055
External: 607-429-4055_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
