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

"Laganier, Julien" <> Fri, 16 October 2009 21:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F23BC3A682B for <>; Fri, 16 Oct 2009 14:13:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -105.414
X-Spam-Status: No, score=-105.414 tagged_above=-999 required=5 tests=[AWL=1.185, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QmirjU0ubPsi for <>; Fri, 16 Oct 2009 14:13:11 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D1CE03A6358 for <>; Fri, 16 Oct 2009 14:13:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=qcdkim; t=1255727596; x=1287263596; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Laganier,=20Julien"=20<> |To:=20Nicolas=20Williams=20<> |CC:=20""=20<>|Date:=20Fri,=201 6=20Oct=202009=2014:13:13=20-0700|Subject:=20RE:=20[btns] =20Minor=20connection-latch=20problem=20in=20AUTH48 |Thread-Topic:=20[btns]=20Minor=20connection-latch=20prob lem=20in=20AUTH48|Thread-Index:=20AcpOo3bPggPZz765RK6MwvU yWuQX8wAAOeow|Message-ID:=20<BF345F63074F8040B58C00A186FC>|References: =20<20091015221608.GC907@Sun.COM>=0D=0A=20<BF345F63074F80> =0D=0A=20<20091016203953.GQ892@Sun.COM>|In-Reply-To:=20<2 0091016203953.GQ892@Sun.COM>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5773"=3B=20a=3D"25427614"; bh=F1oM9cASjzaxSWdyW5zYXuYCO8SuRb3jCa5juTHA5G4=; b=VAqYzVOneOIDX1Q9ONvMZSMEPnTrPXlr8JYyc1xecOOvS760U1Lf0XSR tfgMtXuoV8t2xEST9vIaEAOADRYikUNqNbyp+0z9sRx4lK4qYOv2UugWT 7NYLsK7bhCUwS/uxvVvRT8TAT0G/ei1+KhLghshUG5lwnIR20W9fFJma0 E=;
X-IronPort-AV: E=McAfee;i="5300,2777,5773"; a="25427614"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Oct 2009 14:13:16 -0700
Received: from ( []) by (8.14.2/8.14.2/1.0) with ESMTP id n9GLDFrb019390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 16 Oct 2009 14:13:15 -0700
Received: from ( []) by (8.14.2/8.14.2/1.0) with ESMTP id n9GLDFth006481 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 16 Oct 2009 14:13:15 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 16 Oct 2009 14:13:14 -0700
Received: from ([]) by ([]) with mapi; Fri, 16 Oct 2009 14:13:14 -0700
From: "Laganier, Julien" <>
To: Nicolas Williams <>
Date: Fri, 16 Oct 2009 14:13:13 -0700
Thread-Topic: [btns] Minor connection-latch problem in AUTH48
Thread-Index: AcpOo3bPggPZz765RK6MwvUyWuQX8wAAOeow
Message-ID: <>
References: <20091015221608.GC907@Sun.COM> <> <20091016203953.GQ892@Sun.COM>
In-Reply-To: <20091016203953.GQ892@Sun.COM>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [btns] Minor connection-latch problem in AUTH48
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Better-Than-Nothing-Security Working Group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 16 Oct 2009 21:13:13 -0000

Nicolas Williams wrote
> 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).

I think this is the external behavior that we want to capture. The specifics of how a given implementation achieves that need not to be specified in the RFC as long as the conceptual behavior is clear and guarantees interoperability.

Both style of implementation would conform to that behavior, whether or not the triggering occurs directly as a result of latch creation, or indirectly via triggering by the first packet.
> 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.

FWIW - from my perspective there's no difference between "must" and "MUST", RFC 2119 says about key word that "These words are often capitalized", but does not make it a must.

> 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.

I tend to think that we do not need the state at all. It is a valid implementation strategy, but it does not need to be captured in the standard since there are as-valid alternatives (e.g., Latch Manager triggers key Management directly)_