Subject: [IPsec] Resolution of the current set of open issues

From: Paul Hoffman <[email-masked]>
Date: Sat, 19 Sep 2009 15:39:44 -0700

#22 - Add section on simultaneous IKE SA rekey
    There was no discussion. We will bring this up one more time
    because it is important, but if there is not more interest and
    more inclination to review Tero's text, we will write a short
    note in the document that simultaneous IKE SA rekey is an issue
    but nothing else.

#26 - Missing treatment of error cases
    Will use Tero's last wording as a proposed way forward. There is
    an open issue about what other payloads might or might not be in
    the error responses, so we will leave the issue open for
    discussion after the draft with the new wording is posted. I also
    copy editied the section, so it needs to be reviewed.

#28 - Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP
    Added Tero's text as section 2.23.1. Changed one MUST to a MAY
    based on the discussion with Scott. Note that I removed any
    mention of RFC 3947, which is not part of IKEv2. I also heavily
    copy edited the section, so it needs to be reviewed.

#79 - Remove CP from Create_Child_SA?
    There was no agreement on this. We should probably close out the issue
    unless those interested can agree on the semantics.

#107 - Sending certificate chains in IKEv2
    Fixed in -05. Added "Note that with this encoding, if a chain of
    certificates needs to be sent, multiple CERT payloads are used,
    only the  first of which holds the public key used to validate
    the sender's AUTH payload."

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 21 Sep 2009 15:16:46 +0300

>     note in the document that simultaneous IKE SA rekey is an issue

I would propose cut & pasting the simultaneous IKE SA rekey issue from
the clarifications RFC 4718, and adding some more text:
----------------------------------------------------------------------
X.Y.Z  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,  however, it is important to ensure that
   the CHILD_SAs are inherited by the right IKE_SA.

   After the CREATE_CHILD_SA exchanges, two new IKE_SAs exist between
   A and B; the one containing the lowest nonce inherits the
   CHILD_SAs. The old IKE SA is deleted by the node which created the
   winning IKE SA. The loosing IKE SA is deleted by the node which
   created it. 

   The basic case is where both ends notice this is simultaneous
   rekey, and can delay moving of the CHILD_SAs until they know which
   one wins. The more complex case happens where there is dropped
   packets and one end does not detect simultaneous rekey until it has
   already finished its rekey and moved CHILD_SAs. As the basic case
   can be processed in similar way as the more complex case, this
   example here only covers the more complex case.

   In this case host A and B has IKE SA up and running and both ends
   decide to rekey it:

       Host A			        Host B
     -----------                      -----------
     send req1: ... Ni1  ... -->
			     <-- send req2: ... Ni2 ...
			      --> recv req1

   Now if the req2 is dropped for some reason, the Host A does not
   know there is simultaneous rekey, but host B will know it when it
   receives the req1. It will process the req1, but it cannot yet move
   the CHILD_SAs as it does not know the Nr2. It postpones the
   CHILD_SA moving until the req2/resp2 rekey finishes. It sends resp1
   back to the Host A to answer req1 IKE SA rekey:

			     <-- send resp1: ... Nr1 ...
     recv resp1 <--

   Now the Host A has finished the IKE SA rekey without knowing it was
   simultaneous rekey. It will move the CHILD_SAs from the old IKE SA
   to new rekeyed IKE SA A. It MUST NOT immediately delete the old IKE
   SA, but instead wait for some time to see in case there was
   simultaneous rekey ongoing or not. When Host B retransmits its req2
   the Host A will notice that there was simultaneous rekey going on,
   and it will send normal reply to that:

     recv req1 <--
     send resp2: ... Nr2 ... -->
			      --> recv resp2

   After sending that reply that also creates the second IKE SA B in
   Host A and then Host A can check all the four nonces and see which
   of them is lowest, and it will then move all the CHILD_SAs to that
   new IKE SA having lowest nonce unless they were already there (i.e.
   if the IKE SA A had lowest nonce, Host A has already moved the
   CHILD_SAs there, if IKE SA B had lowest nonce, host A needs to move
   CHILD_SAs from the IKE SA A to this IKE SA B, and start timer to
   delete IKE SA A).

   When Host B receives the resp2 it knows that simultaneous rekey is
   finished, and it can check the nonces and move CHILD_SAs from the
   original IKE SA to either IKE SA A or B depending which had lowest
   nonce. If it was IKE SA A, the host B needs to start timer to
   delete IKE SA B.

   Depending who created the winning rekeyed IKE SA decides who is
   going to delete the old IKE SA, i.e. the one who created the
   winning IKE SA also cleans up the old IKE SA.

   Note, that Host B processing is identical to the basic case where
   host notices during processing that there is simultaneous rekey
   ongoing. 

   In case the Host A didn't wait for long enough before start
   deleting old IKE SA there can be case where host B is still trying
   to retransmit its req2 in the old IKE SA when it receives the
   delete to the old IKE SA. In that case it knows that Host A has NOT
   received any of its requests, thus is unaware that there is
   simultaneous rekey ongoing, thus it can safely stop retrasnmitting
   req2, and allow old IKE SA to be deleted, and move all CHILD_SAs to
   the IKE SA A created by Host A. 
-- 
[email-masked]

---

From: David Wierbowski <[email-masked]>
Date: Mon, 21 Sep 2009 22:52:58 -0400

>Tero states:

>  In this case host A and B has IKE SA up and running and both ends
I see no reason why Host A MUST NOT immediately delete the old IKE SA.
In fact I think is SHOULD immediately delete the old IKE SA.  By this
I mean it should mark the SA as being deleted, it should send a delete
payload, and it should refuse to create any additional SAs.
>    send resp2: ... Nr2 ... -->
Host A should respond with NO_ADDITIONAL SAS in this case because
Host A did not detect a simultaneous rekey and should have immediately
deleted the original IKE_SA.
>                                          --> recv resp2
Host B should receive the NO_ADDITIONAL_SAS notification and it should
realize that Host A did not detect the simultaneous rekey.  Host B
should now move the child SAs from the original IKE SA to the one
initiated by Host A.  In reality, it's more likely that Host B has
already received Host A's delete notification and will ignore the
response.
>  CHILD_SAs from the IKE SA A to this IKE SA B, and start timer to
Why do you want to mandate all this complication for a case that will
occur infrequently?  You are impacting every IKE_SA rekey, not just
the simultaneous case.  I doubt that anybody delays the delete of an
IKE_SA on a rekey based on RFC 4306.  At the very least I'm sure there
are implementations that do not delay the delete.  Requiring this
delay is a protocol change and one that I do not see the need for.

If Host A deletes the IKE_SA immediately then either Host B will see
the delete and be able to infer that there is no simultaneous rekey or
Host B may also get a NO_ADDITIONAL SAS notification and be able to
infer that there is no simultaneous rekey.
>  the IKE SA A created by Host A.
And it can do the same when it immediately gets a delete for the
original IKE SA or a NO_ADDITIONAL_SAS notification.

If you want to defer the delete of the IKE SA that's fine with me.  I
just don't want to have to do that.  I see no value in doing it,
especially given the text above indicate one has to handle the delete
case anyway.

Dave Wierbowski

---

From: Matthew Cini Sarreo <[email-masked]>
Date: Tue, 22 Sep 2009 08:26:42 +0200

I agree with Dave Wierbowsk, deletion will still occur (for the old IKE SA)
so deleting it while Host B is retransmitting (or waiting for some timer to
retrasmit) seems to make most sense. Host B notices the delete payload (or
NO_ADDITIONAL_SAS), stops retransmitting the request and go on as if there
was only one rekeying requested (the one requested by Host A). I don't see a
reason to delay the deletion.

Regards,
Matt

2009/9/22 Matthew Cini Sarreo <[email-masked]>

>
> I agree with Dave Wierbowsk, deletion will still occur (for the old IKE SA)
> so deleting it while Host B is retransmitting (or waiting for some timer to
> retrasmit) seems to make most sense. Host B notices the delete payload (or
> NO_ADDITIONAL_SAS), stops retransmitting the request and go on as if there
> was only one rekeying requested (the one requested by Host A). I don't see a
> reason to delay the deletion.
>
> Regards,
> Matt
>
> 2009/9/22 David Wierbowski <[email-masked]>
>
>>  >Tero states:
>>
>>
>> _______________________________________________
>> IPsec mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ipsec
>>
>>
>

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 22 Sep 2009 14:53:40 +0300

> I see no reason why Host A MUST NOT immediately delete the old IKE SA.

Deleting the IKE SA immediately makes it impossible to know what
happened to other exchanges going on the same IKE SA. Waiting for 30
seconds or so after rekey would allow those other exchanges to finish
before the old IKE SA is deleted.

The current IKEv2 document does not specify what happens to the
ongoing exchanges when IKE SA is deleted. In normal case that does not
matter, as all the IKE SA state goes away when SA is deleted, thus it
is simply the case that all exchanges are immediately discarded and
all CHILD_SAs on the IKE SA are deleted.

This is not the case on the rekey case, as here there might be
CREATE_CHILD_SAs and other exchanges ongoing on the IKE SA when it is
rekeyed. Now if the IKE SA is deleted immediately without waiting
those to finish when rekey finishes the other end does not know what
the node deleting the IKE SA did for those exchanges. It might have
silently discarded them, or it might have already processed them but
their responses were lost because of network error etc. 

This causes the peers state to get out of sync, which will lead
problems and will cause IKE SAs to be deleted completely later.

> payload, and it should refuse to create any additional SAs.

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

> deleted the original IKE_SA.

NO_ADDITIONAL_SAS is not correct error for this case, as we are
talking about IKE SAs not about CHILD_SAs. The NO_ADDITIONAL_SAS
description clearly says it is used when no more CHILD_SAs are to be
used.

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.

> delay is a protocol change and one that I do not see the need for.

We do delay the delete, as we do want to wait for the ongoing
exchanges to finish. On the other hand we are almost only one of the
implementations who also implement the window size > 1, which means we
have cases where might have several CREATE_CHILD_SA exchanges
initiated by the host B ongoing when host A decides to do rekey on the
IKE SA.

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.

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. 

> infer that there is no simultaneous rekey.

Regardless what host A thinks there was still simultaneous rekey
ongoing, and RFC4306 gives only one way to solve that so sending error
in that case is against RFC4306. That is also protocol change.

If we do protocol change, I would rather make it so we always for
example make the original initiator to win in case of simulatenous IKE
SA rekey case, and not care about nonces at all...
-- 
[email-masked]

---

From: David Wierbowski <[email-masked]>
Date: Tue, 22 Sep 2009 09:53:58 -0400

>Tero Stated:

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.  With that said I'm not sure I agree with how you propose to
handle the outstanding exchanges.

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

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.

It can delay sending a response until it receives responses to all
outstanding requests.  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.

If one of the outstanding requests is for a perceived simultaneous rekey
it now knows it was not perceived that way by the peer.  In this case
it should move the child SAs to the newer IKE SA.  Even with your solution
an
implementation has to be able to handle the case where a perceived
simultaneous rekey of the IKE SA fails.

>   description clearly says it is used when no more CHILD_SAs are to be

Correct, sorry I misspoke.  We actually send NO_PROPOSAL_CHOSEN, but the
same
logic still applies.  I believe we used to send NO_ADDITIONAL_SAS, but
due to previous discussion on the mailing list we switched to
NO_PROPOSAL_CHOSEN.

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

>   initiated by the host B ongoing when host A decides to do rekey on the

We have tested our code using a window size greater than 1.

>   needed to allow the ongoing exchanges to finish before old IKE SA is

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.

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

Dave Wierbowski

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 30 Sep 2009 18:15:22 +0300

David Wierbowski writes:
> 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

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.

> This sounds like a good idea, but it's not what 4306 required and is a

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.

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

> 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

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.

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

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

> 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. 
-- 
[email-masked]