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
- [IPsec] Another round of IKEv2-bis issues Yoav Nir
- [IPsec] Issue #187, was: Re: Another round of IKEā¦ Yaron Sheffer
- [IPsec] Another round of IKEv2-bis issues Tero Kivinen
- Re: [IPsec] Another round of IKEv2-bis issues David Wierbowski
- Re: [IPsec] Another round of IKEv2-bis issues Tero Kivinen
- Re: [IPsec] Another round of IKEv2-bis issues David Wierbowski
- Re: [IPsec] Another round of IKEv2-bis issues Tero Kivinen
- Re: [IPsec] Another round of IKEv2-bis issues David Wierbowski
- Re: [IPsec] Another round of IKEv2-bis issues Tero Kivinen
- Re: [IPsec] Another round of IKEv2-bis issues David Wierbowski
- Re: [IPsec] Another round of IKEv2-bis issues Tero Kivinen
- Re: [IPsec] Another round of IKEv2-bis issues David Wierbowski