Re: [IPsec] Some comments to draft-ietf-ipsecme-dh-checks-01

Paul Hoffman <paul.hoffman@vpnc.org> Thu, 04 April 2013 14:56 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7EF721F93FC for <ipsec@ietfa.amsl.com>; Thu, 4 Apr 2013 07:56:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9I1mev4E4602 for <ipsec@ietfa.amsl.com>; Thu, 4 Apr 2013 07:56:52 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 52BF721F93F1 for <ipsec@ietf.org>; Thu, 4 Apr 2013 07:56:52 -0700 (PDT)
Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r34EunfN004731 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 4 Apr 2013 07:56:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <20829.22084.868314.364667@fireball.kivinen.iki.fi>
Date: Thu, 04 Apr 2013 07:56:49 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <E5B91873-EB8E-4256-971E-261635E5F38F@vpnc.org>
References: <20826.55248.860637.210630@fireball.kivinen.iki.fi> <A113ACFD9DF8B04F96395BDEACB3404209051DF4@xmb-rcd-x04.cisco.com> <20829.22084.868314.364667@fireball.kivinen.iki.fi>
To: Tero Kivinen <kivinen@iki.fi>
X-Mailer: Apple Mail (2.1503)
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>
Subject: Re: [IPsec] Some comments to draft-ietf-ipsecme-dh-checks-01
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 04 Apr 2013 14:56:52 -0000

On Apr 4, 2013, at 3:30 AM, Tero Kivinen <kivinen@iki.fi> wrote:

> Scott Fluhrer (sfluhrer) writes:
>> While I don't think the below text is wrong (except I would point
>> out that there is no security requirement to discard the parent IKE
>> SA during a test failure while generating a child SA), I would also
>> point out that these don't appear to have any advantage over the
>> current text. 
> 
> There is no security requirement to discard IKE SA, but there
> operatinal reasons to do it. I.e. that would be clear indication that
> something is wrong, thus most likely will cause one of the peers to
> start investingating the problem, especially if it is persistent
> problem. On the other hand if the problem is not persistent, and is
> fixed by starting IKE SA over, then even better...

It would be useful to add one or two sentences to the draft explaining that the discarding is for operational, not security, reasons.

--Paul Hoffman