Subject: Re: [IPsec] #22 Simultaneous IKE SA rekey text

From: David Wierbowski <[email-masked]>
Date: Wed, 7 Oct 2009 11:21:41 -0400

>> 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

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 9 Oct 2009 16:03:00 +0300

> >other end can know that as after IKE SA is deleted the other end does

RFC4718 is informational and tried to clarify things which are not
clear in RFC4306. Now we are writing standard track document when
revising RFC4306 and in that case we can even change things specified
in RFC4306, if needed. In this case I do not think we need to change
things from RFC4306, but I think the text in RFC4718 is not correct as
it does not consider the case completely.

>    rekeying the IKE_SA, it should reply with NO_ADDITIONAL_SAS.

This solution might cause peers to stay in live lock state, causing
the whole IKE SA to be unusable. I.e. host A starts IKE SA rekey and
host B starts Create Child SA. Host B replies NO_PROPOSAL_CHOSEN to
host A's IKE SA rekey, and Host A replies NO_ADDITIONAL_SAS to Host
B's Create Child SA request. Both ends process replies, and notices
they failed, thus both start again, causing both ends to be trying
these operations as fast as they can. This situation will stay as it
is unless something kicks hosts out of sync.

Or returning NO_ADDITIONAL_SAS might cause other end to delete the
whole IKE SA and start from scratch.

> NO_PROPOSAL_CHOSEN.

This is not in RFC4306, this is just one proposal given in RFC4718
which might be used, but as I noted above, it can cause live lock
loop, thus it is not really acceptable. 

> Given that is seems reasonable that you would not

The proposed solution in RFC4718 does not really work, so I do not
think we should include that to RFC4306 (yes, I know I should have
noticed this when RFC4718 was being processed not now, but better now
than never).

> you wish to do and that is a protocol change.

The text above implies that regardless what you do you should be able
to allow other end to start exchanges and process them. I.e. IKEv2
protocol tries to be specified in such way that both ends can start
exchanges at any times and expect them to either fail or succeed and
get reply back, but not stay in situation where you do not know,
whether other end processed your request or not.

If you delete the IKE SA immediately that will happen.

> delete that IKE SA it will know one of two things happened.

As the RFC4718 text can make situatuation much worse by causing live
lock, I think that solution proposed there isn't usable as is.

> outstanding create child request possible in this case is one to rekey

Informational RFC 4718 proposes much bigger change to the standard
track RFC 4306 than what I want to do and also the solution has
problems which needs to fixed first before it can be taken to
IKEv2bis. I would propose much smaller change to the RFC4306, which
says that wait a while before deleting the IKE SA after successful
rekey so that exchanges from other end has time to finish before
deleting the IKE SA. Those exchanges happening after the IKE SA was
rekeyed should either be failed or if they are processed, they should
be processed in such way that they are done on the Child SAs which are
already moved to new IKE SA (i.e. creating IPsec SAs or rekeying IPsec
SAs should be failed, and deleting IPsec SAs should be processed, so
that IPsec SAs is deleted from the IKE SA where it was moved to).

> are going out of the way to try to create redundant SAs.

That is not my reading of the text. But I think it is bit pointless to
argue about this text as I think we can only agree that it is not
clear.

There is nothing there in RFC4306 to say that you cannot wait after
doing rekey of IKE sa, and as that is only way to properly and cleanly
process other ends exchanges to end before deleting the SA, that is
what implementation should do.

If that cause redundant SAs to be created then then we do have those
and we need to check nonces to check which of them should be deleted.

The RFC4718 text is NOT in RFC4306, that is one (broken) proposal to
try to solve this problem. The text in RFC4718 even says "Our poposal
is at follows" which would indicate that it was not really meant to be
final protocol for that case.

> point for the IKEv2bis work.  I see no reason to reinvent solutions

Mostly that is true, but we should not include broken proposals from
RFC4718 to IKEv2bis, but instead we should try to find solution that
works. 

> implementation to do that.  I think MAY is the correct way to go.

Implementation needs to still have the code that detects the
simultaneous rekey, and other end might still use this delay, thus you
need to be able to cope with the case where this happens.
Implementations need to be able to handle both cases regardless
whether we use SHOULD or MAY, only thing that is different is whether
they allow other end finish exchanges or not.
-- 
[email-masked]

---

From: David Wierbowski <[email-masked]>
Date: Wed, 14 Oct 2009 16:37:07 -0400

> it does not consider the case completely.

I'm not sure this makes RFC4718 incorrect.  It just makes it incomplete.

> whole IKE SA and start from scratch.

I do not like that RFC 4718 used NO_PROPOSAL_CHOSEN as the indicator that
a rekey is being rejected because there are outstanding requests.  To me
a new notify would have made sense.  Given that RFC 4718 did use
NO_PROPOSAL_CHOSEN it seems to me that when HOST A is rekeying
the IKE_SA it should assume the peer is busy when it receives
NO_PROPOSAL_CHOSEN and should continue to attempt to periodically rekey
the IKE SA again.

I do not agree that when Host B receives NO_ADDITIONAL_SAS that it
should retry the operation using the same IKE SA.  As such I do not think
there is a live lock state.  What should be done is up to the
implementation.  An implementation could assume the other end is in the
process of rekeying or deleting the IKE SA and delay taking any action
or it could take immendiate action.  If it takes immediate action it
would need to do so on a new IKE SA.

> loop, thus it is not really acceptable.

I think it is appropriate to add this to the new draft.  If you are
concerned about the lock state then a warning should be added stating
that when you receive NO_ADDITIONAL_SAS that you should not attempt to
retry that operation on the same IKE SA, although that seems
self-evident.

> noticed this when RFC4718 was being processed not now, but better now

I'm not convinced it is broken, I'm just convinced that if you
attempt to retry an operation on the same IKE SA that you received
NO_ADDITIONAL_SAS on that you can get into a lock state.  To reduce that
concern we can come up with a new REKEYING_IKE_SA notification, but that's
likely to cause problems with old implementations, so better to stick with
what RFC 4718 proposed.

> If you delete the IKE SA immediately that will happen.

You can never guarantee you are going to get a response back to a
request.  I do not see what makes this situation any different.

> lock, I think that solution proposed there isn't usable as is.

I do not agree.

> that IPsec SAs is deleted from the IKE SA where it was moved to).

Everything in RFC 4718 is allowable in 4306.  Both proposals may require
an implementation to change their processing.  I do not think these
proposals are incompatible.

> argue about this text as I think we can only agree that it is not

Agreed

> what implementation should do.

I agree that there is nothing that says you cannot wait to delete the
IKE SA.  I do not agree that it is the only way to handle the situation.
I think what is in RFC 4718 can work.

> final protocol for that case.

I understand that RFC 4718 is just one proposal, but it's one that I
expect some vendors tried to implement.  I doubt there are many that are
currently delaying the deletion of the IKE SA.

> RFC4718 to IKEv2bis, but instead we should try to find solution that

I'm not convinced yet that RFC 4718 is broken or at least that it cannot
be made to work.

> they allow other end finish exchanges or not.

Agreed, but I still think delaying the deletion is at most a MAY.

Dave Wierbowski

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 21 Oct 2009 15:37:38 +0300

> I'm not sure this makes RFC4718 incorrect.  It just makes it incomplete.

Ok, but that still means we need to find a way to fix that problem
before we can use that solution in IKEv2bis. 

> a new notify would have made sense.

True, but as RFC4718 tried to be so it does not modify IKEv2, it could
not define new error code. In IKEv2bis we can do this, so I think we
should define new error code something like "TEMPORAL_FAILURE" which
means there was some kind of temporal error (i.e. the problem will
disappear without anybody changing policy) and other end should try
again after short timeout.

This error code could have uses for other places too.

NO_PROPOSAL_CHOSEN has indication that the problem will NOT disappear
unless someone changes something (i.e. proposals or policy or traffic
selectors etc). So some implementations might (and should) use much
larger timeout before trying again with exactly same parameters. 

> Given that RFC 4718 did use NO_PROPOSAL_CHOSEN it seems to me that
> when HOST A is rekeying the IKE_SA it should assume the peer is busy
> when it receives NO_PROPOSAL_CHOSEN and should continue to attempt
> to periodically rekey the IKE SA again.

Yes.

> should retry the operation using the same IKE SA.

True, if it follows the RFC4306, it should tear down the whole IKE SA,
and start from beginning:
----------------------------------------------------------------------
4.  Conformance Requirements
...
			If the responder rejects the CREATE_CHILD_SA
   request with a NO_ADDITIONAL_SAS notification, the implementation
   MUST be capable of instead closing the old SA and creating a new one.
...
----------------------------------------------------------------------

This would be very unfortunate operation to be done in this case, as
it would tear down the whole IKE SA, and all the IPsec SAs along with
it. I do not think we can use NO_ADDITIONAL_SAS with the current
definition anywhere else because of this.

If on the other hand the host B which receives NO_ADDITIONAL_SAS does
not tear down the whole IKE SA, but decides to keep the existing IKE
SA up and running, there is no text anywhere saying it cannot start
create child exchange again in future. Most likely it will do that
whenever next packet requiring IPsec SA to be created is received,
thus if there is constant stream of packets which would require
protection it will trigger new create child exchange immediately.

If we want that when host B receives NO_ADDITIONAL_SAS or when it
rejects the IKE SA rekey with NO_PROPOSAL_CHOSEN (or with new
TEMPORAL_FAILURE) then it needs to mark the IKE SA in some kind of on
hold state, which means no new exchanges can be started on it, that
needs to be explictly mentioned.

> As such I do not think there is a live lock state. What should be
> done is up to the implementation. An implementation could assume the
> other end is in the process of rekeying or deleting the IKE SA and
> delay taking any action or it could take immendiate action. If it
> takes immediate action it would need to do so on a new IKE SA.

How long should it delay those operations? Forever? Does that include
DPD? If so how is the other end going to get rid of the IKE SA if Host
A crashes and forgets everything about the IKE SA, as there will not
be any more exchanges from Host A from that on etc.

As the behavior of the nodes affects interoperability we should define
what to do in this case. 

> retry that operation on the same IKE SA, although that seems

Yes, I would want to have some kind of text describing that, and also
describing how long does this limit for retry take effect, and I
assume that if the other end does not rekey or delete the IKE SA for
certain timeout then the other node which received NO_ADDITIONAL_SAS
should delete the IKE SA and start over.

> likely to cause problems with old implementations, so better to stick with

Adding new error notifications cannot be problem for complient
implementations as RFC4306 says:

----------------------------------------------------------------------
3.10.1.  Notify Message Types
...
   Types in the range 0 - 16383 are intended for reporting errors.  An
   implementation receiving a Notify payload with one of these types
   that it does not recognize in a response MUST assume that the
   corresponding request has failed entirely.  ...
----------------------------------------------------------------------

Thus every complient implementation MUSST assume that corresponding
request has failed if they receive unrecognized error notify on
response. Thus every implementation should handle new error messages
just as we wanted, i.e. assume the IKE SA rekey failed.

> request.  I do not see what makes this situation any different.

If I do not get response back (after dozen retransmissions over a
period of at least several minutes) to a request on IKEv2 protocol
that means the IKE SA is dead, and I silently discard it (i.e. assume
other end is dead).

Only case where you might not reply back is if the other end has
deleted the IKE SA or if the network is broken. In both cases the
correct fix is to remove the IKE SA and start over and it does not
matter whether your request got other end or not.

But that is not true with rekey case as some of the operations you do
on the old IKE SA do affect the state of the new IKE SA, thus you need
to know whether other end processed your request or not.

> currently delaying the deletion of the IKE SA.

As our implementation does that, I guess all our customers
implementations do it... :-)

But I do not think that is an issue here.

Simultaneous rekeys are not things that happen that often (if ever
outside laboratory tests :-), so even if there are old implementations
which do not do what IKEv2bis document will say, that shouldn't really
matter.

So I think we need to write some text that will work, and not be to
concerned about what current implementations are now doing (I am sure
all implementations out there are going to need minor modifications
anyways when IKEv2bis comes out). 

> I'm not convinced yet that RFC 4718 is broken or at least that it cannot

I think it can be made to work, I do consider it broken or at least
underspecified as it is now, as it might lead live locks, but adding
text to it might solve the problem (before I see the text and solution
I cannot say for sure it will solve the problem). 

> Agreed, but I still think delaying the deletion is at most a MAY.

Ok.
-- 
[email-masked]