Re: [IPsec] Closing the IKEv2bis open issues

[Keith Welter <[e-mail]>]

> Issue #22, Add section on simultaneous IKE SA rekey
> <http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/22>
> There is no consensus on this issue. Tero Kivinen and David Wierbowski 
have deep differences of 
> opinion, and almost no one else has participated. I have reviewed the 
discussion, and I think 
> both people have strong merits to their opinion. Therefore, Yaron and I 
will try to coordinate 
> a design team effort that includes Tero, David, and any others who have 
thought about this issue 
> in depth. If that fails to come out with an agreed-to solution, we will 
probably drop back to 
> adding a short, inconclusive, descriptive > note in the IKEv2bis 
document.

A design team was convened including Dan McDonald, Tero Kivinen, Raj 
Singh, David Wierbowski and Keith Welter to resolve Issue #22.  The design 
team reached agreement on the following general approach as well as 
specific proposed text:
- Import text from RFC 4718 section 5.11.10 into new ikev2biz draft 
section 2.25 "Exchange Collisions"
- Replace NO_PROPOSAL_CHOSEN and NO_ADDITIONAL_SAS with new 
TEMPORARY_FAILURE error type notify.
- Add new CHILD_SA_NOT_FOUND error type notify for one collision case.
- Add text in new section 2.25 describing what to do when the new notify 
types are received.

The proposed text that follows includes a new section and updates to 
existing sections for ikev2bis.

2.25 Exchange Collisions (New Section)

Since IKEv2 exchanges can be initiated by both peers, it is possible
that two exchanges affecting the same SA partly overlap. This can
lead to a situation where the SA state information is temporarily not
synchronized, and a peer can receive a request it cannot process in a
normal fashion. 

Obviously, using a window size greater than one leads to 
more complex situations, especially if requests are processed out of
order. In this section, we concentrate on problems that can arise
even with window size 1 and recommend solutions. 

A TEMPORARY_FAILURE notification SHOULD be sent when a host receives 
a request that cannot be completed due to a temporary condition such 
as a rekeying operation. When a host receives a TEMPORARY_FAILURE 
notification, it MUST NOT immediately retry the operation but wait so
that the sender may complete whatever operation caused the temporary
condition. The recipient MAY retry the request one or more times over 
a period of several minutes. If a host continues to receive 
TEMPORARY_FAILURE on the same IKE SA after several minutes then it 
SHOULD conclude that state information is out-of-sync and close the 
IKE SA. 

A CHILD_SA_NOT_FOUND notification SHOULD be sent when a host receives 
a request to rekey a Child SA that does not exist. A host that 
receives a CHILD_SA_NOT_FOUND notification SHOULD silently delete the 
Child SA and send a request to create a new Child SA from scratch. 

If a host receives a request to rekey:

o a Child SA that the host is currently trying to close: reply 
with TEMPORARY_FAILURE. 

o a Child SA that the host is currently rekeying: reply as
usual, but prepare to close redundant SAs later based on the
nonces. 

o a Child SA that does not exist: reply with 
CHILD_SA_NOT_FOUND. 

o the IKE SA, and the host is currently rekeying the IKE SA: reply
as usual, but prepare to close redundant SAs and move inherited
Child SAs later based on the nonces.

o the IKE SA, and the host is currently creating, rekeying, 
or closing a Child SA: reply with TEMPORARY_FAILURE. 

o the IKE SA, and the host is currently trying to close the IKE SA: 
reply with TEMPORARY_FAILURE. 

If a host receives a request to close:

o a Child SA that the host is currently trying to close: reply
without Delete payloads. 

o a Child SA that the host is currently rekeying: reply as
usual, with Delete payload.

o a Child SA that does not exist: reply without Delete
payloads.

o the IKE SA, and the host is currently rekeying the IKE SA: reply
as usual, and forget about our own rekeying request.

o the IKE SA, and the host is currently trying to close the IKE SA:
reply as usual, and forget about our own close request.

If a host receives a request to create or rekey a CHILD_SA when it is 
currently rekeying the IKE_SA: reply with TEMPORARY_FAILURE. 

If a host receives a request to delete a Child SA when it is
currently rekeying the IKE SA: 
reply as usual, with Delete payload.


3.10.1. Notify Message Types (Updates)
... 
NOTIFY messages: error types Value
-------------------------------------------------------------------
...
TEMPORARY_FAILURE 40
See section 2.25. 

CHILD_SA_NOT_FOUND 41
See section 2.25.

RESERVED TO IANA 42-8191 
... 

1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange (Updates)

Add the following sentence to the end of the first paragraph of section 
1.3.2:
"Once a host receives a request to rekey an IKE SA or sends a request to 
rekey 
an IKE SA it SHOULD NOT start any new CREATE_CHILD_SA exchanges on the IKE 
SA 
being rekeyed."

The new paragraph should now read:
"The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
payload, and a Diffie-Hellman value in the KEi payload. The KEi
payload MUST be included. New initiator and responder SPIs are
supplied in the SPI fields of the SA payload. Once a host receives 
a request to rekey an IKE SA or sends a request to rekey an IKE SA 
it SHOULD NOT start any new CREATE_CHILD_SA exchanges on the IKE SA 
being rekeyed."

2.8.2. Simultaneous IKE SA Rekeying (Updates)

Update the second paragraph so that it reads as follows:
"The case where both endpoints notice the simultaneous rekeying works
the same way as with Child SAs. After the CREATE_CHILD_SA exchanges, 
three IKE SAs exist between A and B; the old IKE SA and two new IKE SAs. 
The new IKE SA containing the lowest nonce inherits the Child SAs. 
If only one side detects a simultaneous rekey then redundant SAs are 
not created. In this case, when the end which didn't notice the 
simultaneous rekey gets the request to rekey the IKE SA that it has 
already successfully rekeyed, it will return TEMPORARY_FAILURE as it 
is an IKE SA it is currently trying to close (whether it has already 
sent the delete notification for it or not). If the end which did 
notice the simultaneous rekey gets the delete from the other end for 
the old IKE SA then it knows that the other end didn't detect 
simultaneous rekey, and it can forget its own rekey attempt."

Keith Welter
IBM z/OS Communications Server Developer
1-415-545-2694 (T/L: 473-2694)