[IPsec] Finishing #22 (was: Re: Closing the IKEv2bis open issues)

Paul Hoffman <paul.hoffman@vpnc.org> Thu, 12 November 2009 02:28 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BD0B3A689F for <ipsec@core3.amsl.com>; Wed, 11 Nov 2009 18:28:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.255
X-Spam-Level:
X-Spam-Status: No, score=-5.255 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzyZl1PYfKHo for <ipsec@core3.amsl.com>; Wed, 11 Nov 2009 18:28:55 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 015D33A6828 for <ipsec@ietf.org>; Wed, 11 Nov 2009 18:28:54 -0800 (PST)
Received: from [133.93.128.35] (host-40-59.meeting.ietf.org [133.93.40.59]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nAC2TKLl075439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ipsec@ietf.org>; Wed, 11 Nov 2009 19:29:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p06240818c72122e87220@[133.93.128.35]>
In-Reply-To: <OF2772CC5D.A3AE43C1-ON8825766B.0069F220-8825766B.006C4336@us.ibm.com>
References: <OF2772CC5D.A3AE43C1-ON8825766B.0069F220-8825766B.006C4336@us.ibm.com>
Date: Thu, 12 Nov 2009 11:29:15 +0900
To: ipsec@ietf.org
From: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/html; charset="us-ascii"
Subject: [IPsec] Finishing #22 (was: Re: Closing the IKEv2bis open issues)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Nov 2009 02:28:56 -0000

Finishing #22 (was: Re: [IPsec] Closing the IKEv2bis open
Resent so that the issue number is in subject line only. Please reply to this thread.

At 11:42 AM -0800 11/11/09, Keith Welter wrote:
> Issue #22, Add section on simultaneous IKE SA rekey
> <
http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/22" rel="nofollow">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)

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec