Re: [anonsec] Comments on connection latching draft
Nicolas Williams <Nicolas.Williams@sun.com> Fri, 07 December 2007 00:06 UTC
Return-path: <anonsec-bounces@postel.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Qjx-0003fW-DX for btns-archive-waDah9Oh@lists.ietf.org; Thu, 06 Dec 2007 19:06:49 -0500
Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0Qjv-00079e-R5 for btns-archive-waDah9Oh@lists.ietf.org; Thu, 06 Dec 2007 19:06:49 -0500
Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lB6NvwYZ006377; Thu, 6 Dec 2007 15:57:58 -0800 (PST)
Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lB6NvfoF006287 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for <anonsec@postel.org>; Thu, 6 Dec 2007 15:57:42 -0800 (PST)
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 lB6Nve0s012460 for <anonsec@postel.org>; Thu, 6 Dec 2007 23:57:40 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 lB6Nvd8r002780 for <anonsec@postel.org>; Thu, 6 Dec 2007 16:57:40 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lB6NvdDx009346; Thu, 6 Dec 2007 17:57:39 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lB6NvduZ009345; Thu, 6 Dec 2007 17:57:39 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Thu, 06 Dec 2007 17:57:39 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Sam Hartman <hartmans-ietf@mit.edu>
Message-ID: <20071206235738.GA8628@Sun.COM>
Mail-Followup-To: Sam Hartman <hartmans-ietf@mit.edu>, anonsec@postel.org
References: <tsld4tjjsw3.fsf@mit.edu>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <tsld4tjjsw3.fsf@mit.edu>
User-Agent: Mutt/1.5.7i
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: nicolas.williams@sun.com
Cc: anonsec@postel.org
Subject: Re: [anonsec] Comments on connection latching draft
X-BeenThere: anonsec@postel.org
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Discussions of anonymous Internet security." <anonsec.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/anonsec>, <mailto:anonsec-request@postel.org?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/anonsec>
List-Post: <mailto:anonsec@postel.org>
List-Help: <mailto:anonsec-request@postel.org?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/anonsec>, <mailto:anonsec-request@postel.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: anonsec-bounces@postel.org
Errors-To: anonsec-bounces@postel.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
On Thu, Dec 06, 2007 at 06:38:36PM -0500, Sam Hartman wrote: > What is the purpose of the connection states? I see them enumerated but never used. To help describe the process by which latches are created and torn down. > Why must implementations make available nat state? I'm unconvinced > that is well enough defined to actually be useful. I think this is Michael's requirement. > o Any IPsec channel created with a given peer while another > distinct, established IPsec channel exists with the same source > and destination addresses SHOULD be bound to the same peer. > > > How does this interact with nats? Hmmm, badly :) > Is it really desirable? It's a mitigation for BTNS clients using non-channel binding applications with multiple TCP connections. It's not important to me, and I'll be glad to remove it. > It seems like the BITS model plus proprietary extensions might work for channel binding. That's native IPsec built with BITS components. > Section 2.1: What does it mean for connection latches to be broken? That ULPs (and applications) are informed. ULPs are informed synchronously, so they can close/reset the connection before any subsequent packets can be accepted. > Section 2.1: define what a conflicting latch is; you use the term > several times but don't define it. There is what I think is a > definition but it is not associated with the term. Here: o Create a connection latch object for a ULP 5-tuple (local and remote address, protocol and local and remote port numbers). This operation succeeds when no conflicting connection latch objects exist and when there exist no child SAs encompassing the given 5-tuple or when all such SAs are with the same peer and equal quality of protection. The key manager SHOULD attempt to create a suitable SA pair if one does not already exist; if it does then it MUST use the 5-tuple as the initial traffic selectors of the proposed child SAs. s/no conflicting connection latch objects exist/no connection latch exists already with the same 5-tuple/ I.e., "conflicting connection latch" there means that a latch with the same 5-tuple as the proposed new latch already exists. The latch manager can know this while the ULP cannot, which is why the latch manager checks this. So far I'm putting latch management in the same place as key management, but this is very abstract -- it need not translate into latch management being done by an IKE daemon. _______________________________________________
- [anonsec] Comments on connection latching draft Sam Hartman
- Re: [anonsec] Comments on connection latching dra… Nicolas Williams
- Re: [anonsec] Comments on connection latching dra… Sam Hartman
- Re: [anonsec] Comments on connection latching dra… Paul Wouters
- Re: [anonsec] Comments on connection latching dra… Nicolas Williams
- Re: [anonsec] Comments on connection latching dra… Michael Richardson