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

Nicolas Williams <Nicolas.Williams@sun.com> Mon, 19 October 2009 16: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 8F6F83A6836 for <btns@core3.amsl.com>; Mon, 19 Oct 2009 09:51:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.382
X-Spam-Level:
X-Spam-Status: No, score=-4.382 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_40=-0.185, 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 I+htnHucoqHg for <btns@core3.amsl.com>; Mon, 19 Oct 2009 09:51:34 -0700 (PDT)
Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id A71963A681E for <btns@ietf.org>; Mon, 19 Oct 2009 09:51:32 -0700 (PDT)
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n9JGpdBO007240 for <btns@ietf.org>; Mon, 19 Oct 2009 16:51:39 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n9JGpdgW030692 for <btns@ietf.org>; Mon, 19 Oct 2009 10:51:39 -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 n9JGeGji003141; Mon, 19 Oct 2009 11:40:16 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9JGeEnc003140; Mon, 19 Oct 2009 11:40:14 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Mon, 19 Oct 2009 11:40:14 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: "Laganier, Julien" <julienl@qualcomm.com>
Message-ID: <20091019164014.GF892@Sun.COM>
References: <20091015221608.GC907@Sun.COM> <BF345F63074F8040B58C00A186FCA57F1C2A67DF98@NALASEXMB04.na.qualcomm.com> <20091016203953.GQ892@Sun.COM> <BF345F63074F8040B58C00A186FCA57F1C2A67DFC1@NALASEXMB04.na.qualcomm.com> <20091016211652.GV892@Sun.COM> <BF345F63074F8040B58C00A186FCA57F1C2A67DFD7@NALASEXMB04.na.qualcomm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BF345F63074F8040B58C00A186FCA57F1C2A67DFD7@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: Mon, 19 Oct 2009 16:51:35 -0000

OK, this way the changes are much smaller and localized -- only the
description of CREATE_CONNECTION_LATCH() changes, to:

   o  CREATE_CONNECTION_LATCH(5-tuple, [type and quality-of-protection
      parameters], [peer ID], [local ID]) -> latch handle | error

         If a) the requested latch does not exist (or exists, but is in
         the CLOSED state), b) all the latch parameters are provided, or
         if suitable SAs exist in the SAD from which to derive them, and
         c) if there are no conflicts with the SPD and SAD, then this
         creates a connection latch in the ESTABLISHED state.  If the
         latch parameters are not provided and no suitable SAs exist in
         the SAD from which to derive those parameters, then the key
         manager MUST initiate child SAs, and if need be, IKE_SA, from
         which to derive those parameters.

         The key manager MAY delay the child SA setup and return
         immediately after the policy check, knowing that the ULP that
         requested the latch will subsequently output a packet that will
         trigger the SA establishment.  Such an implementation may
         require an additional state in the connection latch state
         machine, a "LARVAL" state, that is not described herein.

         If the connection latch ultimately cannot be established,
         either because of conflicts or because no SAs can be
         established with the peer at the destination address, then an
         error is returned to the ULP.  (If the key manager delayed SA
         establishment, and SA establishment ultimately fails, then the
         key manager has to inform the ULP, possibly asynchornously.
         This is one of several details that implementors who use a
         LARVAL state must take care of.)

How's that?

This way the change is small enough that it wouldn't have required WG
discussion.  I should have thought of this.  Thanks Julien!

Nico
--