Re: [btns] Minor connection-latch problem in AUTH48

Nicolas Williams <Nicolas.Williams@sun.com> Fri, 16 October 2009 20:51 UTC

Return-Path: <Nicolas.Williams@sun.com>
X-Original-To: btns@core3.amsl.com
Delivered-To: btns@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D22883A68E4 for <btns@core3.amsl.com>; Fri, 16 Oct 2009 13:51:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.437
X-Spam-Level:
X-Spam-Status: No, score=-5.437 tagged_above=-999 required=5 tests=[AWL=0.610, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 u9mhWnCGbY4l for <btns@core3.amsl.com>; Fri, 16 Oct 2009 13:51:17 -0700 (PDT)
Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id F19A63A68A3 for <btns@ietf.org>; Fri, 16 Oct 2009 13:51:16 -0700 (PDT)
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n9GKpF8w014702 for <btns@ietf.org>; Fri, 16 Oct 2009 20:51:15 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n9GKpEV0050462 for <btns@ietf.org>; Fri, 16 Oct 2009 14:51:14 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n9GKdrth002159; Fri, 16 Oct 2009 15:39:53 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9GKdrlE002158; Fri, 16 Oct 2009 15:39:53 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Fri, 16 Oct 2009 15:39:53 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: "Laganier, Julien" <julienl@qualcomm.com>
Message-ID: <20091016203953.GQ892@Sun.COM>
References: <20091015221608.GC907@Sun.COM> <BF345F63074F8040B58C00A186FCA57F1C2A67DF98@NALASEXMB04.na.qualcomm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BF345F63074F8040B58C00A186FCA57F1C2A67DF98@NALASEXMB04.na.qualcomm.com>
User-Agent: Mutt/1.5.7i
Cc: "btns@ietf.org" <btns@ietf.org>
Subject: Re: [btns] Minor connection-latch problem in AUTH48
X-BeenThere: btns@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Better-Than-Nothing-Security Working Group discussion list <btns.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/btns>, <mailto:btns-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/btns>
List-Post: <mailto:btns@ietf.org>
List-Help: <mailto:btns-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/btns>, <mailto:btns-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Oct 2009 20:51:17 -0000

On Fri, Oct 16, 2009 at 12:48:16PM -0700, Laganier, Julien wrote:
> I understand your proposal below tries to removes some sort of
> chicken-and-egg problem with the ULP creating the latch before sending
> a packet, the latch creation triggering key management to create an SA
> if there's none, and the packet being sent triggering the key
> management.

Actually, I was just trying to resolve a three-way conflict in the
text.  As a secondary goal I thought it would be a good idea to not
REQUIRE that the key manager initiate IKE/child SAs just because a ULP
is expected soon to send a packet that will require child SAs.  I think
that should be at least a MAY, and at most a SHOULD.

Perhaps the WG would say that we should REQUIRE that the key manager
initiate IKE/child SAs ahead of any triggering packet as a
simplification of the model (then we don't need a LARVAL state).  But I
could certainly see implementors not wanting to do that (for one it
makes the CREATE_CONNECTION_LATCH() call slow).

An alternative would be to say "must" instead of "MUST" and then explain
that if the key manager does not initiate IKE/child SAs as part of the
CREATE_CONNECTION_LATCH() call, then it must have a LARVAL state that we
have not defined.

You can see why I think this is a minor problem, but also why it'd be
better to address it.

> I'd like to make sure I understand the issue and your proposal, and in
> particular why we can't have the latch DB triggering directly the key
> manager: The existing text you have quoted below says "... if there
> exist no child SAs that match the given 5-tuple, and if local policy
> permits it", which implies that the 5-tuple is matched against the
> SPD. Couldn't this action trigger the key manager to establish a child
> SA without having to be triggered by an actual packet?

Indeed.  We don't absolutely need the LARVAL state.  Perhaps we should
describe it as an OPTIONAL state, since an implementation might not have
such a state at all.

Nico
--