From anonsec-bounces@postel.org Tue Dec 04 13:11:32 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzcF2-0001g2-6e for btns-archive-waDah9Oh@lists.ietf.org; Tue, 04 Dec 2007 13:11:32 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzcF0-0005Jl-Ln for btns-archive-waDah9Oh@lists.ietf.org; Tue, 04 Dec 2007 13:11:32 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lB4HwpSn017432; Tue, 4 Dec 2007 09:58:51 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (dhcp-178f.ietf70.org [130.129.23.143]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lB4Hw8BS017098 for ; Tue, 4 Dec 2007 09:58:09 -0800 (PST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4EDC84819; Tue, 4 Dec 2007 12:58:08 -0500 (EST) To: anonsec@postel.org From: Sam Hartman Message-Id: <20071204175808.4EDC84819@carter-zimmerman.suchdamage.org> Date: Tue, 4 Dec 2007 12:58:08 -0500 (EST) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: hartmans@mit.edu Subject: [anonsec] Five minutes to discuss nfs interactions X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 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: 2870a44b67ee17965ce5ad0177e150f4 I'd like to request five minutes on the agenda to discuss interactions between our work and nfs. _______________________________________________ From anonsec-bounces@postel.org Thu Dec 06 18:46:17 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0QQ5-0002be-RP for btns-archive-waDah9Oh@lists.ietf.org; Thu, 06 Dec 2007 18:46:17 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0QQ5-0005nG-GH for btns-archive-waDah9Oh@lists.ietf.org; Thu, 06 Dec 2007 18:46:17 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lB6Ncwiw028776; Thu, 6 Dec 2007 15:38:58 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (dhcp-178f.ietf70.org [130.129.23.143]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lB6Ncbgd028695 for ; Thu, 6 Dec 2007 15:38:38 -0800 (PST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A5E014815; Thu, 6 Dec 2007 18:38:36 -0500 (EST) From: Sam Hartman To: anonsec@postel.org Date: Thu, 06 Dec 2007 18:38:36 -0500 Message-ID: MIME-Version: 1.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: hartmans@mit.edu Subject: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 7655788c23eb79e336f5f8ba8bce7906 What is the purpose of the connection states? I see them enumerated but never used. Why must implementations make available nat state? I'm unconvinced that is well enough defined to actually be useful. 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? Is it really desirable? It seems like the BITS model plus proprietary extensions might work for channel binding. Section 2.1: What does it mean for connection latches to be broken? 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. _______________________________________________ From anonsec-bounces@postel.org Thu Dec 06 19:06:49 2007 Return-path: 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 ; 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 ; 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 ; 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, 6 Dec 2007 17:57:39 -0600 From: Nicolas Williams To: Sam Hartman Message-ID: <20071206235738.GA8628@Sun.COM> Mail-Followup-To: Sam Hartman , anonsec@postel.org References: Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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. _______________________________________________ From anonsec-bounces@postel.org Thu Dec 06 19:20:07 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Qwp-0001xz-9E for btns-archive-waDah9Oh@lists.ietf.org; Thu, 06 Dec 2007 19:20:07 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0Qwo-0007wm-Oh for btns-archive-waDah9Oh@lists.ietf.org; Thu, 06 Dec 2007 19:20:07 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lB709aRB009806; Thu, 6 Dec 2007 16:09:36 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (dhcp-178f.ietf70.org [130.129.23.143]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lB708a8x009649 for ; Thu, 6 Dec 2007 16:08:37 -0800 (PST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 423AE4815; Thu, 6 Dec 2007 19:08:36 -0500 (EST) From: Sam Hartman To: anonsec@postel.org References: <20071206235738.GA8628@Sun.COM> Date: Thu, 06 Dec 2007 19:08:36 -0500 In-Reply-To: <20071206235738.GA8628@Sun.COM> (Nicolas Williams's message of "Thu, 6 Dec 2007 17:57:39 -0600") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: hartmans@mit.edu 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 00e94c813bef7832af255170dca19e36 >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Thu, Dec 06, 2007 at 06:38:36PM -0500, Sam Hartman Nicolas> wrote: >> What is the purpose of the connection states? I see them >> enumerated but never used. Nicolas> To help describe the process by which latches are created Nicolas> and torn down. Then actually use the states in section 2 etc. >> Why must implementations make available nat state? I'm >> unconvinced that is well enough defined to actually be useful. Nicolas> 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? Nicolas> Hmmm, badly :) >> Is it really desirable? Nicolas> It's a mitigation for BTNS clients using non-channel Nicolas> binding applications with multiple TCP connections. It's Nicolas> 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. Nicolas> That's native IPsec built with BITS components. >> Section 2.1: What does it mean for connection latches to be >> broken? Nicolas> That ULPs (and applications) are informed. ULPs are Nicolas> informed synchronously, so they can close/reset the Nicolas> 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. Nicolas> Here: Nicolas> o Create a connection latch object for a ULP 5-tuple Nicolas> (local and remote address, protocol and local and remote Nicolas> port numbers). This operation succeeds when no Nicolas> conflicting connection latch objects exist and when there Nicolas> exist no child SAs encompassing the given 5-tuple or when Nicolas> all such SAs are with the same peer and equal quality of Nicolas> protection. The key manager SHOULD attempt to create a Nicolas> suitable SA pair if one does not already exist; if it Nicolas> does then it MUST use the 5-tuple as the initial traffic Nicolas> selectors of the proposed child SAs. Nicolas> s/no conflicting connection latch objects exist/no Nicolas> connection latch exists already with the same 5-tuple/ Nicolas> I.e., "conflicting connection latch" there means that a Nicolas> latch with the same 5-tuple as the proposed new latch Nicolas> already exists. The latch manager can know this while Nicolas> the ULP cannot, which is why the latch manager checks Nicolas> this. Nicolas> So far I'm putting latch management in the same place as Nicolas> key management, but this is very abstract -- it need not Nicolas> translate into latch management being done by an IKE Nicolas> daemon. _______________________________________________ From anonsec-bounces@postel.org Thu Dec 06 23:55:56 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0VFk-0001NA-UY for btns-archive-waDah9Oh@lists.ietf.org; Thu, 06 Dec 2007 23:55:56 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0VFk-00087E-Iy for btns-archive-waDah9Oh@lists.ietf.org; Thu, 06 Dec 2007 23:55:56 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lB74lEel014441; Thu, 6 Dec 2007 20:47:14 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lB74kk05014203 for ; Thu, 6 Dec 2007 20:46:48 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) by newtla.xelerance.com (Postfix) with ESMTP id 98627C0BD; Thu, 6 Dec 2007 23:50:06 -0500 (EST) Date: Thu, 6 Dec 2007 23:50:06 -0500 (EST) From: Paul Wouters To: Nicolas Williams In-Reply-To: <20071206235738.GA8628@Sun.COM> Message-ID: References: <20071206235738.GA8628@Sun.COM> MIME-Version: 1.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: paul@xelerance.com Cc: anonsec@postel.org, Sam Hartman 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: ea4ac80f790299f943f0a53be7e1a21a On Thu, 6 Dec 2007, Nicolas Williams wrote: > 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. I think this might have to do with detecting multiple clients behind the same NAT router. > > 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 :) Why not make it souce and destination address plus port? > o Create a connection latch object for a ULP 5-tuple (local and > remote address, protocol and local and remote port numbers). Like here. Paul _______________________________________________ From anonsec-bounces@postel.org Sun Dec 09 01:49:21 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1Fyb-0000pa-54 for btns-archive-waDah9Oh@lists.ietf.org; Sun, 09 Dec 2007 01:49:21 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1Fya-0000qS-OT for btns-archive-waDah9Oh@lists.ietf.org; Sun, 09 Dec 2007 01:49:21 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lB96i9CL016551; Sat, 8 Dec 2007 22:44:09 -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 lB96hqDd016498 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Sat, 8 Dec 2007 22:43:53 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lB96hqpJ008294 for ; Sun, 9 Dec 2007 06:43:52 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 lB96hpmI040460 for ; Sat, 8 Dec 2007 23:43:51 -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 lB96hpAT011144; Sun, 9 Dec 2007 00:43:51 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lB96hoIF011143; Sun, 9 Dec 2007 00:43:50 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Sun, 9 Dec 2007 00:43:50 -0600 From: Nicolas Williams To: Paul Wouters Message-ID: <20071209064350.GB11013@Sun.COM> Mail-Followup-To: Paul Wouters , Sam Hartman , anonsec@postel.org References: <20071206235738.GA8628@Sun.COM> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: 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, Sam Hartman 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: e5ba305d0e64821bf3d8bc5d3bb07228 On Thu, Dec 06, 2007 at 11:50:06PM -0500, Paul Wouters wrote: > On Thu, 6 Dec 2007, Nicolas Williams wrote: > > > 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. > > I think this might have to do with detecting multiple clients behind > the same NAT router. The information is available, therefore requiring that it be made available seems reasonable. Making this a recommendation is also reasonable. > > > 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 :) > > Why not make it souce and destination address plus port? Did you mean only one port, and if so, the destination port, or both ports? (Connection latching already does this for all five elements of the 5-tuple, so if your answer is "both" then note that that's the whole point of connection latching :) _______________________________________________ From anonsec-bounces@postel.org Sun Dec 09 03:40:41 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1HiL-0000Si-2C for btns-archive-waDah9Oh@lists.ietf.org; Sun, 09 Dec 2007 03:40:41 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1HiK-0002o1-Fm for btns-archive-waDah9Oh@lists.ietf.org; Sun, 09 Dec 2007 03:40:41 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lB98VC26010319; Sun, 9 Dec 2007 00:31:12 -0800 (PST) Received: from ns0.neustar.com (ns0.neustar.com [156.154.16.158]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lB98U2Ib009835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 9 Dec 2007 00:30:03 -0800 (PST) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id B53903286E; Sun, 9 Dec 2007 08:30:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1J1HY1-0000Yi-L9; Sun, 09 Dec 2007 03:30:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sun, 09 Dec 2007 03:30:01 -0500 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: ietf@ietf.org Cc: anonsec@postel.org Subject: [anonsec] I-D Action:draft-ietf-btns-connection-latching-04.txt X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: anonsec-bounces@postel.org Errors-To: anonsec-bounces@postel.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Better-Than-Nothing Security Working Group of the IETF. Title : IPsec Channels: Connection Latching Author(s) : N. Williams Filename : draft-ietf-btns-connection-latching-04.txt Pages : 20 Date : 2007-12-09 This document specifies, abstractly, how to interface applications and transport protocols with IPsec so as to create "channels" by "latching" "connections" (packet flows) to certain IPsec Security Association (SA) parameters for the lifetime of the connections. This can be used to protect applications against accidentally exposing live packet flows to unintended peers, whether as the result of a reconfiguration of IPsec or as the result of using weak peer identity to peer address associations. Weak association of peer ID and peer addresses is at the core of Better Than Nothing Security (BTNS), thus connection latching can add a significant measure of protection to BTNS IPsec nodes. A model of of connection latching is given. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-btns-connection-latching-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-btns-connection-latching-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-btns-connection-latching-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-12-09032920.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-btns-connection-latching-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-btns-connection-latching-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-09032920.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ --NextPart-- From anonsec-bounces@postel.org Thu Dec 13 09:05:41 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2oh3-0005J6-8s for btns-archive-waDah9Oh@lists.ietf.org; Thu, 13 Dec 2007 09:05:41 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2ogx-00033Y-Vo for btns-archive-waDah9Oh@lists.ietf.org; Thu, 13 Dec 2007 09:05:41 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lBDDq03w015483; Thu, 13 Dec 2007 05:52:00 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lBDDpYCY015355 for ; Thu, 13 Dec 2007 05:51:35 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b2so171296ana.81 for ; Thu, 13 Dec 2007 05:51:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=h0ghQGgPa55IDPzjwLFgbT8SduecOEEtZvq/JNYZJu0=; b=LCS01kTJypsJRWSNCzUz2zMBXH1kJh5PW4Xfn+CihmozmoidrZxopOFmyxcYqF5CDc6rylZLaqx7yVgIpdrnjdQjXS3r2/MCvesGRfouAOtS9ifdjiDuDl7V3IW5NpjBR4NnX1erm3gg16K/6eCKIBYh/W0Es6XVFFfxerwCSXI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=opr6QIsXSh4ldhFoUYEtZm3qjHr3ajuT+enaj4CwibhM0uIY1p9t8656/fCOtqgRhXpn7m5V/JcShTNp63+GsW6ZQUcV3EalDg++hV/kKDQd+L7zun1RaTGeQ/WpaNnxttZ5qyg5W4zOa+LnzWHQtjmt4ZYG6u4ENTAKgJQx12Y= Received: by 10.100.112.6 with SMTP id k6mr4128895anc.110.1197553894360; Thu, 13 Dec 2007 05:51:34 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id f4sm2193983nfh.2007.12.13.05.51.30 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 13 Dec 2007 05:51:31 -0800 (PST) From: Julien Laganier To: anonsec@postel.org Date: Thu, 13 Dec 2007 14:51:35 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200712131451.37565.julien.IETF@laposte.net> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: julien.laganier@gmail.com Cc: Love =?iso-8859-1?q?H=F6rnquist_=C5strand?= Subject: [anonsec] Minutes of BTNS session at IETF-70 X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 68c8cc8a64a9d0402e43b8eee9fc4199 Folks, Minutes of the meeting are available there: Please send to chairs corrections and/or add-ons, if any. Thanks. --julien _______________________________________________ From anonsec-bounces@postel.org Sat Dec 15 20:13:32 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3i4S-0003Rg-GZ for btns-archive-waDah9Oh@lists.ietf.org; Sat, 15 Dec 2007 20:13:32 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3i4R-0005nH-UO for btns-archive-waDah9Oh@lists.ietf.org; Sat, 15 Dec 2007 20:13:32 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lBG0wlg3022545; Sat, 15 Dec 2007 16:58:47 -0800 (PST) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lBG0vlBw022422 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Sat, 15 Dec 2007 16:57:49 -0800 (PST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1J3hp3-0004rD-04 for anonsec@postel.org; Sun, 16 Dec 2007 00:57:37 +0000 Received: from wlan199.sandelman.ca ([209.87.252.199]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 16 Dec 2007 00:57:36 +0000 Received: from mcr by wlan199.sandelman.ca with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 16 Dec 2007 00:57:36 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: anonsec@postel.org From: Michael Richardson Date: Sat, 15 Dec 2007 19:57:14 -0500 Lines: 34 Message-ID: References: <20071206235738.GA8628@Sun.COM> Mime-Version: 1.0 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: wlan199.sandelman.ca User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.13pre) Gecko/20070505 Iceape/1.0.9 (Debian-1.0.11~pre071022-0etch1) In-Reply-To: <20071206235738.GA8628@Sun.COM> X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: gia-anonsec@m.gmane.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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 52e1467c2184c31006318542db5614d5 Nicolas Williams wrote: > 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 :) If as you say, it's my requirement, let me remember why. I thought that we had ruled NAT interaction as out-of-scope. BTW: real world case where channel binding is necessary: http://www.schneier.com/blog/archives/2007/12/defeating_the_s.html ... This works because the two security systems are decoupled. And the shoe screening machine is so crowded and chaotic, and so poorly manned, that no one notices the switch. _______________________________________________ From anonsec-bounces@postel.org Thu Dec 20 15:31:31 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5S3H-0002IO-PR for btns-archive-waDah9Oh@lists.ietf.org; Thu, 20 Dec 2007 15:31:31 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5S3H-0001kF-AU for btns-archive-waDah9Oh@lists.ietf.org; Thu, 20 Dec 2007 15:31:31 -0500 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lBKKPSTp025362; Thu, 20 Dec 2007 12:25:29 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lBKKPB0F025294 for ; Thu, 20 Dec 2007 12:25:12 -0800 (PST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 017174815; Thu, 20 Dec 2007 15:25:07 -0500 (EST) From: Sam Hartman To: anonsec@postel.org Date: Thu, 20 Dec 2007 15:25:07 -0500 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: hartmans@mit.edu Subject: [anonsec] AD review comments on draft-ietf-btns-core X-BeenThere: anonsec@postel.org X-Mailman-Version: 2.1.6 Precedence: list List-Id: "Discussions of anonymous Internet security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 798b2e660f1819ae38035ac1d8d5e3ab Hi. I've sent the core document to last call. It was not as readable as I would like. If you get a bunch of comments back from people who do not understand you probably should take a style and readability pass. I have two changes I'd like te request as last call comments myself. First, when you require bare RSA cert payloads, please reference a specific section of the IKE V2 spec for a definition of this. Also, how can BTNS work with DSA if nodes are required to include RSA payloads? Please replace the statement in section 4.2 that leap of faith is being handled by BTNS with a statement that it is an item for future work. _______________________________________________