Re: [IPsec] Another round of IKEv2-bis issues
David Wierbowski <wierbows@us.ibm.com> Fri, 23 April 2010 14:14 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 DF6BB3A6928; Fri, 23 Apr 2010 07:14:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.995
X-Spam-Level:
X-Spam-Status: No, score=-5.995 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, 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 jOA3PtuSXO9G; Fri, 23 Apr 2010 07:14:51 -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 6F5723A691B; Fri, 23 Apr 2010 07:14:34 -0700 (PDT)
Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e4.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o3NE2Dcq004558; Fri, 23 Apr 2010 10:02:13 -0400
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o3NEEHkk157810; Fri, 23 Apr 2010 10:14:17 -0400
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o3NEEGCv010376; Fri, 23 Apr 2010 11:14:16 -0300
Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av02.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o3NEEGsI010357; Fri, 23 Apr 2010 11:14:16 -0300
In-Reply-To: <19409.38762.719146.5305@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>
X-KeepSent: 2C6B98B2:0772F8F1-0025770E:004890F9; type=4; name=$KeepSent
To: Tero Kivinen <kivinen@iki.fi>
X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009
Message-ID: <OF2C6B98B2.0772F8F1-ON0025770E.004890F9-8525770E.004E35FE@us.ibm.com>
From: David Wierbowski <wierbows@us.ibm.com>
Date: Fri, 23 Apr 2010 10:14:15 -0400
X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 04/23/2010 10:14:15
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: Fri, 23 Apr 2010 14:14:53 -0000
>> I don't think we need to mandate how a particular situation should be
>> handled. That is up to the implementer. The implementer just needs to
>> know that there is a rule that states the it is not for some child SAs
>> stay up when the IKE_SA disappears. I think the existing text could be
>> deleted.
>
>But the existing text is the text which gives this rule or at least
>try to. I.e. it tries to say that if implementation cannot guarantee
>that all Child SAs and IKE SAs stay up together, then you cannot
>negotiate all those Child SAs using the same IKE SA.
>
>This same can partially be seen from the:
>
> Receipt of a fresh cryptographically protected message on an IKE SA
> or any of its Child SAs ensures liveness of the IKE SA and all of
> its Child SAs.
>
>text, but some people might be missing the point that ALL Child SAs
>and corresponding IKE SAs must stay up together.
What I do not like about the text is that it is a rule related to the
life of the Child SAs. I think it would be clearer to tie the rule
to the termination of the IKE SA. For example I think replacing the
text with some thing like the following is more straight forward:
If an IKE SA fails without being able to send a delete
message, then all Child SAs created by the IKE SA MUST be silently
deleted.
On the other hand I am not saying the existing text must be removed.
I'm just saying that I think it could be removed.
Dave Wierbowski
z/OS Comm Server Developer
Phone:
Tie line: 620-4055
External: 607-429-4055
- [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