Re: [IPsec] ikev2bis issue #181: Section 2.4 unclear on Child SA failing

David Wierbowski <wierbows@us.ibm.com> Thu, 01 April 2010 13:28 UTC

Return-Path: <wierbows@us.ibm.com>
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 968113A6959; Thu, 1 Apr 2010 06:28:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.469
X-Spam-Level:
X-Spam-Status: No, score=-5.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 G4bbrH8ZxlEK; Thu, 1 Apr 2010 06:28:27 -0700 (PDT)
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by core3.amsl.com (Postfix) with ESMTP id 789343A688F; Thu, 1 Apr 2010 06:28:16 -0700 (PDT)
Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by e5.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o31DDxm3009809; Thu, 1 Apr 2010 09:13:59 -0400
Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o31DSf1k151264; Thu, 1 Apr 2010 09:28:41 -0400
Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o31DSfS1032132; Thu, 1 Apr 2010 10:28:41 -0300
Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av03.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o31DSfha032113; Thu, 1 Apr 2010 10:28:41 -0300
In-Reply-To: <19380.36219.405774.979743@fireball.kivinen.iki.fi>
References: <p06240807c7d83e28b337@[10.20.30.158]> <19380.36219.405774.979743@fireball.kivinen.iki.fi>
X-KeepSent: AA07B3B6:DC1182C8-852576F8:00482D57; type=4; name=$KeepSent
To: Tero Kivinen <kivinen@iki.fi>
X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009
Message-ID: <OFAA07B3B6.DC1182C8-ON852576F8.00482D57-852576F8.004A0903@us.ibm.com>
From: David Wierbowski <wierbows@us.ibm.com>
Date: Thu, 01 Apr 2010 09:28:40 -0400
X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 04/01/2010 09:28:40
MIME-Version: 1.0
Content-type: text/plain; charset="US-ASCII"
Cc: IPsecme WG <ipsec@ietf.org>, ipsec-bounces@ietf.org
Subject: Re: [IPsec] ikev2bis issue #181: Section 2.4 unclear on Child SA failing
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, 01 Apr 2010 13:28:28 -0000

>> I propose removing the sentence, or greatly clarifying it.
>
> For me the current text is very clear, and I do not see how we can
> clarify greatly. This issue usually only affects implementations where
> there are multiple subsystems which can fail independently from each
> other. If the only failure model is that the whole device
> crashed/rebooted etc then this text does not apply, as all IPsec SAs
> (and IKE SAs) disappear at the same time.

I disagree with the Tero's comment statement that the text is very clear,
I've never understood exactly what the statement  meant until I read the
example that Tero provided.  Based on that I would at least recommend
changing the text as follows:

If sets of Child SAs can fail independently from one
another without the associated IKE SA being able to send a delete
message, then each set of Child SAs MUST be negotiated by separate IKE SAs.

It might even be approbate to add Tero's example:

For example if sets of IPsec SAs are associated with different crypto
chips, and
each chip can fail independently causing all IPsec SAs associated with the
chip
to disappear then each set of IPsec SAs should be negotiated with a
different IKE SA.

Dave Wierbowski