Re: [IPsec] Another round of IKEv2-bis issues

David Wierbowski <wierbows@us.ibm.com> Mon, 26 April 2010 13:25 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 266F328C16B; Mon, 26 Apr 2010 06:25:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.267
X-Spam-Level:
X-Spam-Status: No, score=-5.267 tagged_above=-999 required=5 tests=[AWL=-0.527, BAYES_20=-0.74, 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 c5OXNEqM1-ET; Mon, 26 Apr 2010 06:25:11 -0700 (PDT)
Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by core3.amsl.com (Postfix) with ESMTP id B87C23A6A8F; Mon, 26 Apr 2010 06:23:10 -0700 (PDT)
Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by e4.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o3QDAh2E025104; Mon, 26 Apr 2010 09:10:43 -0400
Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o3QDMoiV125516; Mon, 26 Apr 2010 09:22:50 -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 o3QDMobL032553; Mon, 26 Apr 2010 10:22:50 -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 o3QDMo64032412; Mon, 26 Apr 2010 10:22:50 -0300
In-Reply-To: <19413.30405.5158.838402@fireball.kivinen.iki.fi>
References: <006FEB08D9C6444AB014105C9AEB133FB37650C568@il-ex01.ad.checkpoint.com> <19389.52595.209726.960078@fireball.kivinen.iki.fi> <OF6AD2BFF8.4EBFBC83-ON852576FF.0050D170-852576FF.0054E2E4@us.ibm.com> <19400.25514.92364.300616@fireball.kivinen.iki.fi> <OF07C3799E.286E8226-ON8525770D.00754FB1-8525770D.00766EAC@us.ibm.com> <19409.38762.719146.5305@fireball.kivinen.iki.fi> <OF2C6B98B2.0772F8F1-ON0025770E.004890F9-8525770E.004E35FE@us.ibm.com> <19413.30405.5158.838402@fireball.kivinen.iki.fi>
X-KeepSent: 0F6264F9:FAD2B467-85257711:0047B610; type=4; name=$KeepSent
To: Tero Kivinen <kivinen@iki.fi>
X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009
Message-ID: <OF0F6264F9.FAD2B467-ON85257711.0047B610-85257711.00497E92@us.ibm.com>
From: David Wierbowski <wierbows@us.ibm.com>
Date: Mon, 26 Apr 2010 09:22:44 -0400
X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 04/26/2010 09:22:49
MIME-Version: 1.0
Content-type: text/plain; charset="US-ASCII"
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, ipsec-bounces@ietf.org
Subject: Re: [IPsec] Another round of IKEv2-bis 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: Mon, 26 Apr 2010 13:25:13 -0000

>Do you think it is legal to create a system where one Child SA can
>fail in such way that IKE SA cannot send delete notification?

I do not think a robust IKE implementation would allow this.

>
>The current text says it is not legal, but your replacement text
>allows it.

The current bis text is:
   If a system creates Child SAs that can fail independently from one
   another without the associated IKE SA being able to send a delete
   message, then the system MUST negotiate such Child SAs using separate
   IKE SAs.

This text also does not prevent the above.  It just says how the
children can be created.  It says nothing about what happens when
they fail.

>
>I do not think such setup should be allowed. I.e. if any of the Child
>SAs or the associated IKE SA fail, in such way that delete
>notification cannot be sent, then all the Child SAs AND the IKE SA
>needs to be destroyed.

Then say that.  Say if a Child SA fails and a delete notification
cannot be sent then the IKE SA must be deleted.  Personally I think
you change how you interpret the sentence each time you respond which
just echoes Paul's original point, that the text is not clear.

Dave Wierbowski