David Wierbowski writes:
> 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.
> > 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.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.
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:
Host A Host B
-------- ----------
<-- sends request
packet is dropped by network it
never reaches the host A
starts rekey -->
<-- replies to rekey
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
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.
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.
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.
>
> > 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?
> > 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.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
