Subject: Re: [IPsec] Closing the IKEv2bis open issues

From: Keith Welter <[email-masked]>
Date: Wed, 11 Nov 2009 11:42:30 -0800

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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 12 Nov 2009 11:29:15 +0900

Resent so that the issue number is in subject line only. Please
reply to this thread.

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

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

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.

more complex situations, especially if requests are processed out
of

order. In this section, we concentrate on problems that can
arise

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.

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.

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

o the IKE SA, and the host is currently creating,
rekeying,

o the IKE SA, and the host is currently trying to close the IKE
SA:

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

payloads.

o the IKE SA, and the host is currently rekeying the IKE SA:
reply

o the IKE SA, and the host is currently trying to close the IKE
SA:

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

...

...

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

"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

_______________________________________________

IPsec mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 23 Nov 2009 18:37:46 -0800

At 11:42 AM -0800 11/11/09, Keith Welter wrote:
>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: . . .

Many, many thanks for all this work. I have now input all the text (with some wordsmithing and rearranging) in -06. However, I have changed one part:

>NOTIFY messages: error types Value

The values 40 and 41 *are already taken* in the IANA registry. I have substituted {TBA1} and {TBA2} for them in -06. (This reaffirms my desire to implement issue #123 and rip out the old tables.)

--Paul Hoffman, Director
--VPN Consortium

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 24 Nov 2009 08:58:05 +0200

And this is exactly the table that I claim needs to remain in the spec. A list of errors - even if partial! - is essential to understanding a protocol.

Thanks,
	Yaron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Hoffman
> Sent: Tuesday, November 24, 2009 4:38
> To: Keith Welter
> Cc: [email-masked]
> Subject: [IPsec] Closing #25
> 
> specific proposed text: . . .
> 
> Many, many thanks for all this work. I have now input all the text (with
> some wordsmithing and rearranging) in -06. However, I have changed one
> part:
> 
> The values 40 and 41 *are already taken* in the IANA registry. I have
> substituted {TBA1} and {TBA2} for them in -06. (This reaffirms my desire
> to implement issue #123 and rip out the old tables.)
> 
> --Paul Hoffman, Director
> --VPN Consortium
> Scanned by Check Point Total Security Gateway.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 24 Nov 2009 07:43:42 -0800

>And this is exactly the table that I claim needs to remain in the spec. A list of errors - even if partial! - is essential to understanding a protocol.

The table is fine: as proven by the fact that none of many authors of this new text, the numbers are not.

--Paul Hoffman, Director
--VPN Consortium