From exim@www1.ietf.org Fri Apr 2 01:07:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11618 for ; Fri, 2 Apr 2004 01:07:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9E8g-0005nT-Gd for tcpm-archive@odin.ietf.org; Thu, 01 Apr 2004 21:10:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i322AYdt022284 for tcpm-archive@odin.ietf.org; Thu, 1 Apr 2004 21:10:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9BlX-00006a-VU for tcpm-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 18:38:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09659 for ; Thu, 1 Apr 2004 18:38:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9BlU-00032m-00 for tcpm-web-archive@ietf.org; Thu, 01 Apr 2004 18:38:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Bkc-0002wN-00 for tcpm-web-archive@ietf.org; Thu, 01 Apr 2004 18:37:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9Bjl-0002q2-00 for tcpm-web-archive@ietf.org; Thu, 01 Apr 2004 18:36:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B99YC-00083P-RC; Thu, 01 Apr 2004 16:16:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B94Yo-0006xr-Uh for tcpm@optimus.ietf.org; Thu, 01 Apr 2004 10:56:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17341 for ; Thu, 1 Apr 2004 10:54:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B94WI-0000Vv-00 for tcpm@ietf.org; Thu, 01 Apr 2004 10:54:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B94VQ-0000R2-00 for tcpm@ietf.org; Thu, 01 Apr 2004 10:53:24 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1B94Un-0000K0-00 for tcpm@ietf.org; Thu, 01 Apr 2004 10:52:45 -0500 Received: from bu-ewat02-01.uk.sun.com ([129.156.199.2]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i31FqEWA002659 for ; Thu, 1 Apr 2004 07:52:14 -0800 (PST) Received: from uk.sun.com (vpn-129-156-96-211.EMEA.Sun.COM [129.156.96.211]) by bu-ewat02-01.uk.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i31FqC3D000371 for ; Thu, 1 Apr 2004 16:52:13 +0100 (BST) Message-ID: <406C3AAD.2040506@uk.sun.com> Date: Thu, 01 Apr 2004 16:52:13 +0100 From: Jeremy Harris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.6) Gecko/20040113 X-Accept-Language: en, en-us MIME-Version: 1.0 To: tcpm@ietf.org Subject: Re: [Tsvwg] Re: [tcpm] Re: [e2e] Are you interested in TOEs and related issues(Resend) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit pat_thaler@agilent.com wrote: > I'll take the liberty of responding to your rhetorical question. I don't think the question can be answered outside the context of protocols like RDMA and iSCSI. A good part of the performance problem for 10 Gig links is the data copies required. Protocols like iSCSI and RDMA can allow the NIC to place the data into applications buffers. This is similar to the function of some Fibre Channel interfaces that allow it higher performance. This is a large part of the benefit gained from implementing a TOE. Protocols like RDMA and iSCSI require TCP (or an alternative transport layer) to be implemented other them which means you need a TOE. > > If you aren't doing placement on the NIC, it isn't clear that there is enough benefit from implementing a TOE. Because we want to do placement, we need a TOE. Hand the NIC recieve buffers off to the application, and you don't need to do placement. Both placement and TOE look like solutions looking for a nonexistent problem to me. - Jeremy _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Sat Apr 3 13:31:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29130 for ; Sat, 3 Apr 2004 13:31:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9pv2-00036C-4r for tcpm-archive@odin.ietf.org; Sat, 03 Apr 2004 13:31:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i33IV020011897 for tcpm-archive@odin.ietf.org; Sat, 3 Apr 2004 13:31:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9pv1-00035o-MJ for tcpm-web-archive@optimus.ietf.org; Sat, 03 Apr 2004 13:30:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29108 for ; Sat, 3 Apr 2004 13:30:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9puz-0002Dc-00 for tcpm-web-archive@ietf.org; Sat, 03 Apr 2004 13:30:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9pu3-00026w-00 for tcpm-web-archive@ietf.org; Sat, 03 Apr 2004 13:30:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9pt7-00020D-00 for tcpm-web-archive@ietf.org; Sat, 03 Apr 2004 13:29:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9pt6-0002au-M7; Sat, 03 Apr 2004 13:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9psI-0002Qv-8z for tcpm@optimus.ietf.org; Sat, 03 Apr 2004 13:28:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29048 for ; Sat, 3 Apr 2004 13:28:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9psG-0001sL-00 for tcpm@ietf.org; Sat, 03 Apr 2004 13:28:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9prO-0001iq-00 for tcpm@ietf.org; Sat, 03 Apr 2004 13:27:14 -0500 Received: from [170.210.17.130] (helo=libertad.frh.utn.edu.ar) by ietf-mx with esmtp (Exim 4.12) id 1B9pqE-0001Ts-00 for tcpm@ietf.org; Sat, 03 Apr 2004 13:26:02 -0500 Received: from fernando.gont.com.ar ([200.68.210.155]) by libertad.frh.utn.edu.ar (8.9.3/8.8.7) with ESMTP id PAA13615; Sat, 3 Apr 2004 15:52:02 -0400 Message-Id: <4.3.2.7.2.20040403152932.00b26ae0@mail.daleclick.com> X-Sender: fgont@mail.daleclick.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 03 Apr 2004 15:33:41 -0300 To: Pekka Savola From: Fernando Gont Subject: Re: [tcpm] TCP, multiple addresses and soft errors when connecting Cc: tcpm@ietf.org, , In-Reply-To: References: <4.3.2.7.2.20040322073643.00b1b4a0@mail.daleclick.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At 14:30 02/04/2004 +0300, Pekka Savola wrote: >What I propose as a way forward for this specific Informational >document: > 1) state the reasons why this specific connect() etc. behaviour is >desirable (read: why many vendors have already done that), and what >drawbacks it could have (if any), and I agree. > 2) state the desire for getting a better higher-level API which would >handle all of this and much more (instead of/in addition to 1), but >mention why this is not an only practical solution. What do you mean "this is not an only practical solution"? -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon Apr 5 17:03:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09480 for ; Mon, 5 Apr 2004 17:03:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAbEp-0003O5-9q for tcpm-archive@odin.ietf.org; Mon, 05 Apr 2004 17:02:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35L2ZOR013022 for tcpm-archive@odin.ietf.org; Mon, 5 Apr 2004 17:02:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAbEo-0003Ns-Ht for tcpm-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 17:02:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09380 for ; Mon, 5 Apr 2004 17:02:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAbEm-0003rS-00 for tcpm-web-archive@ietf.org; Mon, 05 Apr 2004 17:02:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAb3P-0001hJ-00 for tcpm-web-archive@ietf.org; Mon, 05 Apr 2004 16:50:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAace-0006b3-01 for tcpm-web-archive@ietf.org; Mon, 05 Apr 2004 16:23:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaO4-00051z-TP; Mon, 05 Apr 2004 16:08:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaNR-0004je-Ti for tcpm@optimus.ietf.org; Mon, 05 Apr 2004 16:07:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04196 for ; Mon, 5 Apr 2004 16:07:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAaNQ-00059z-00 for tcpm@ietf.org; Mon, 05 Apr 2004 16:07:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAaJN-0004Nm-00 for tcpm@ietf.org; Mon, 05 Apr 2004 16:03:14 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1BAa7s-0002HS-00 for tcpm@ietf.org; Mon, 05 Apr 2004 15:51:21 -0400 Received: from jurassic.eng.sun.com ([129.146.83.36]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i35JonLT027170; Mon, 5 Apr 2004 12:50:49 -0700 (PDT) Received: from sun.com (shield.SFBay.Sun.COM [129.144.60.49]) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i35Jolub913796; Mon, 5 Apr 2004 12:50:49 -0700 (PDT) Message-ID: <4071B897.5070905@sun.com> Date: Mon, 05 Apr 2004 12:50:47 -0700 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.6) Gecko/20040117 X-Accept-Language: en, zh-hk, zh-tw, zh-cn MIME-Version: 1.0 To: Fernando Gont CC: Pekka Savola , tcpm@ietf.org, v6ops@ops.ietf.org, sebastien.roy@sun.com Subject: Re: [tcpm] TCP, multiple addresses and soft errors when connecting References: <4.3.2.7.2.20040319123019.00bfc520@mail.daleclick.com> In-Reply-To: <4.3.2.7.2.20040319123019.00bfc520@mail.daleclick.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Fernando Gont wrote: > So why not implement such a "higher-level" connect(), and handle all the > relevant issues inside the API? FYI, SCTP has this same problem. So sctp_connectx() was added in the API draft to allow an app to pass in an array of addresses. How does the stack handle this is implementation dependent. One way may be to have a policy on the priority of addresses to try and when to switch to another one. If connectx() is implemented as a general call for other protocols, a policy for TCP may be that TCP will try another address if it gets an ICMPv6 message following the suggestion in draft-ietf-v6ops-v6onbydefault-01.txt, Check section 8.9 in draft-ietf-tsvwg-sctpsocket-08.txt on sctp_connectx(). -- K. Poon. kacheong.poon@sun.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Apr 6 00:16:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14853 for ; Tue, 6 Apr 2004 00:16:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAi02-0001QX-4o for tcpm-archive@odin.ietf.org; Tue, 06 Apr 2004 00:15:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i364Fk9h005476 for tcpm-archive@odin.ietf.org; Tue, 6 Apr 2004 00:15:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAi01-0001Pc-Ps for tcpm-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 00:15:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14772 for ; Tue, 6 Apr 2004 00:15:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAhzz-0005wi-00 for tcpm-web-archive@ietf.org; Tue, 06 Apr 2004 00:15:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAhUT-0002xO-00 for tcpm-web-archive@ietf.org; Mon, 05 Apr 2004 23:43:11 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAhEQ-0000Pe-02 for tcpm-web-archive@ietf.org; Mon, 05 Apr 2004 23:26:34 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAh4u-0006AC-Kh for tcpm-web-archive@ietf.org; Mon, 05 Apr 2004 23:16:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAh3I-0006lZ-8E; Mon, 05 Apr 2004 23:15:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAh2j-0006ZX-Fx for tcpm@optimus.ietf.org; Mon, 05 Apr 2004 23:14:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10826 for ; Mon, 5 Apr 2004 23:14:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAh2h-0007Ia-00 for tcpm@ietf.org; Mon, 05 Apr 2004 23:14:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAgbe-0004Sl-00 for tcpm@ietf.org; Mon, 05 Apr 2004 22:46:31 -0400 Received: from [170.210.17.130] (helo=libertad.frh.utn.edu.ar) by ietf-mx with esmtp (Exim 4.12) id 1BAgAa-0001LT-00 for tcpm@ietf.org; Mon, 05 Apr 2004 22:18:32 -0400 Received: from fernando.gont.com.ar ([200.68.210.165]) by libertad.frh.utn.edu.ar (8.9.3/8.8.7) with ESMTP id XAA22739; Mon, 5 Apr 2004 23:45:50 -0400 Message-Id: <4.3.2.7.2.20040405201058.02a45d80@mail.daleclick.com> X-Sender: fgont@mail.daleclick.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 05 Apr 2004 23:04:08 -0300 To: Pekka Savola From: Fernando Gont Subject: Re: [tcpm] TCP, multiple addresses and soft errors when connecting Cc: tcpm@ietf.org, , In-Reply-To: References: <4.3.2.7.2.20040403152932.00b26ae0@mail.daleclick.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At 09:25 05/04/2004 +0300, Pekka Savola wrote: > > > 2) state the desire for getting a better higher-level API which would > > >handle all of this and much more (instead of/in addition to 1), but > > >mention why this is not an only practical solution. > > What do you mean "this is not an only practical solution"? >What I should have said if "but mention why this is would not be a >practical solution, if there were no other solutions". Actually, I think it is the only real solution to the problem. Having the API report ICMP errors to the application is moving the problem from the API to the application, but *not* solving it. If you leave connect() as is, then you may have the delay problem you describe (i.e., you may suffer undesirable delays to use a service). If you make it report ICMP errors to the application, you still have a problem I mentioned in the other e-mails. You might even say that you'll have application programmers (probably *not* knowledgeable on TCP/IP internals) handling issues of the underlying protocols. So a real solution is to hide all this stuff from the application programmer. Let him just concentrate on actually using a service, and handle all the protocol-related issues inside the API. Furthermore, if for whatever reason you need to change the behavior of connect() in the future, then, unless you provide a more "abstract" connect(), you'll have to "bother" application programmers again. >That is, new APIs would be great, but we cannot stop fixing problems >current APIs until we have something more concrete out there. >Otherwise we'd end up with no practically (in short term) deployable >solution. If you consider it useful, I could try to continue thinking on the "abstract" API. I'm just thinking about writting some stuff down, so that there's a place from which which can move things forward. It may take me some time (say, months), but... (BTW, for those interested tcpm-only readers, I've just posted a message with subject "Some comments on draft-ietf-v6ops-v6onbydefault-01.txt" on the v6ops list, that's related to all this. I can forward it to to the tcpm list, if you want). -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Apr 6 00:16:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14859 for ; Tue, 6 Apr 2004 00:16:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAi03-0001TY-2W for tcpm-archive@odin.ietf.org; Tue, 06 Apr 2004 00:15:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i364Fl6b005658 for tcpm-archive@odin.ietf.org; Tue, 6 Apr 2004 00:15:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAi02-0001T6-Tp for tcpm-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 00:15:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14781 for ; Tue, 6 Apr 2004 00:15:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAi00-0005wy-00 for tcpm-web-archive@ietf.org; Tue, 06 Apr 2004 00:15:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAhUX-0002xf-00 for tcpm-web-archive@ietf.org; Mon, 05 Apr 2004 23:43:15 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAhER-0000Pe-00 for tcpm-web-archive@ietf.org; Mon, 05 Apr 2004 23:26:35 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAh4O-00069U-Dl for tcpm-web-archive@ietf.org; Mon, 05 Apr 2004 23:16:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAh4E-0006ww-6J; Mon, 05 Apr 2004 23:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAh3s-0006q6-PL for tcpm@optimus.ietf.org; Mon, 05 Apr 2004 23:15:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10892 for ; Mon, 5 Apr 2004 23:15:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAh3q-0007Nt-00 for tcpm@ietf.org; Mon, 05 Apr 2004 23:15:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAgcZ-0004ZU-00 for tcpm@ietf.org; Mon, 05 Apr 2004 22:47:28 -0400 Received: from [170.210.17.130] (helo=libertad.frh.utn.edu.ar) by ietf-mx with esmtp (Exim 4.12) id 1BAgBj-0001Ul-00 for tcpm@ietf.org; Mon, 05 Apr 2004 22:19:43 -0400 Received: from fernando.gont.com.ar ([200.68.210.165]) by libertad.frh.utn.edu.ar (8.9.3/8.8.7) with ESMTP id XAA22743; Mon, 5 Apr 2004 23:46:00 -0400 Message-Id: <4.3.2.7.2.20040405201120.00b18e70@mail.daleclick.com> X-Sender: fgont@mail.daleclick.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 05 Apr 2004 23:12:23 -0300 To: Kacheong Poon From: Fernando Gont Subject: Re: [tcpm] TCP, multiple addresses and soft errors when connecting Cc: Pekka Savola , tcpm@ietf.org, v6ops@ops.ietf.org, sebastien.roy@sun.com In-Reply-To: <4071B897.5070905@sun.com> References: <4.3.2.7.2.20040319123019.00bfc520@mail.daleclick.com> <4.3.2.7.2.20040319123019.00bfc520@mail.daleclick.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At 12:50 05/04/2004 -0700, Kacheong Poon wrote: >>So why not implement such a "higher-level" connect(), and handle all the >>relevant issues inside the API? >FYI, SCTP has this same problem. So sctp_connectx() was added in the >API draft to allow an app to pass in an array of addresses. Is there any reason for which an array of IP addresses is passed, instead of, say, a domain name? >How does >the stack handle this is implementation dependent. One way may be to >have a policy on the priority of addresses to try and when to switch >to another one. If connectx() is implemented as a general call for >other protocols, a policy for TCP may be that TCP will try another >address if it gets an ICMPv6 message following the suggestion in >draft-ietf-v6ops-v6onbydefault-01.txt, IMHO, it's a better approach than just having connect() fail when ICMP errors are received. However, unless there's a reason for it (as I asked above), I think it's still a low-level API. For example, if I want to get the document at http://www.example.com/index.html , why should I care about whether the webeserver is IPv4-only, IPv6-only or dual/stack? Does an application programmer really need to know the IP addresses the domain "www.example.com" map to? Actually, should an application programmer be supposed to be knowledgeable on network addressing? Best Regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Apr 6 18:43:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06811 for ; Tue, 6 Apr 2004 18:43:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAzHj-0006sQ-9C for tcpm-archive@odin.ietf.org; Tue, 06 Apr 2004 18:43:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36MhBUI026433 for tcpm-archive@odin.ietf.org; Tue, 6 Apr 2004 18:43:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAzHi-0006s0-OD for tcpm-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 18:43:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06786 for ; Tue, 6 Apr 2004 18:43:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAzHf-0005hA-00 for tcpm-web-archive@ietf.org; Tue, 06 Apr 2004 18:43:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAyLS-0006Ue-00 for tcpm-web-archive@ietf.org; Tue, 06 Apr 2004 17:43:00 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAxXa-0007iv-01 for tcpm-web-archive@ietf.org; Tue, 06 Apr 2004 16:51:26 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAxPY-0003qw-3B for tcpm-web-archive@ietf.org; Tue, 06 Apr 2004 16:43:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAxPQ-0001OS-WB; Tue, 06 Apr 2004 16:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Muo-0001mR-Q1 for tcpm@optimus.ietf.org; Fri, 02 Apr 2004 06:32:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04105 for ; Fri, 2 Apr 2004 06:32:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Muk-0007G9-00 for tcpm@ietf.org; Fri, 02 Apr 2004 06:32:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Mtn-0007AW-00 for tcpm@ietf.org; Fri, 02 Apr 2004 06:31:48 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9MtV-00074i-00 for tcpm@ietf.org; Fri, 02 Apr 2004 06:31:29 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i32BUtS29103; Fri, 2 Apr 2004 14:30:55 +0300 Date: Fri, 2 Apr 2004 14:30:55 +0300 (EEST) From: Pekka Savola To: Fernando Gont cc: tcpm@ietf.org, , Subject: Re: [tcpm] TCP, multiple addresses and soft errors when connecting In-Reply-To: <4.3.2.7.2.20040322073643.00b1b4a0@mail.daleclick.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 I've been waiting for other comments on this, but none have emerged so... What I propose as a way forward for this specific Informational document: 1) state the reasons why this specific connect() etc. behaviour is desirable (read: why many vendors have already done that), and what drawbacks it could have (if any), and 2) state the desire for getting a better higher-level API which would handle all of this and much more (instead of/in addition to 1), but mention why this is not an only practical solution. Does this sound reasonable and well-balanced? On Mon, 22 Mar 2004, Fernando Gont wrote: > At 16:39 20/03/2004 +0200, Pekka Savola wrote: > > > > Does it really make sense to handle the whole connection establishment > > > issue inside the app, instead of inside the API itself? > >Those are the core APIs we have today. We could have better ones, but > >IMHO I think we need to fix problems in the current ones as long as we > >don't have a widely-deployed alternative. > > IMHO, there are two points to note: > > * If you fix the current ones so that their behavior is "acceptable" to the > application programmer, then it'll be harder to introduce a new API. People > is reluctant to change, so they must have a reason for learning a new API. > If you try to fix the current one, they will find fewer reasons for the change. > > * You said "we don't have a widely-deployed alternative". Unless you meant > "we don't have a well-tested alternative", I'd say that it's a > chicken-and-egg problem. That means, for an API to be widely deployed, > people would have to use it. And for people to use it, they should be able > to find a good reason to do it. > > Yes, I'm aware that my proposal my sound as a long-term solution. But, > IMHO, it will certainly be harder to introduce a new API if you actually > want to do it "in long term". > I guess "timing" is an issue, here. > > > > > > I think that if we're debating this, we're implicitly assuming that > > > applications want to connect to say www.example.com, and not one specific > > > IP address to which it maps to. > > > > > > So why not implement such a "higher-level" connect(), and handle all the > > > relevant issues inside the API? > > > >Defining such APIs is probably beyond the scope of the work we can do, > >and the things we can fix except in the 5+ year timeframe.. but if I > >get you right, you're proposing that instead of: > > > > 1) getaddrinfo() or gethostbyname() and connect for one address, > >[where, arguably, TCP retry timeout could be warranted -- I don't > >think so myself, but you could argue for it] > > > > 2) getaddrinfo() / gethostbyname() loop to connect to one address > >[where TCP retry timeout could not be warranted] > > > >You'd be proposing to create a new function to accomplish 2) in such a > >manner that it would also react to ICMP messages, etc? > > Exactly. > > Then, within that function, each individual connect() could react to ICMP > messages a > as you proposed, but if all addresses fail because of ICMP errors, it could > let TCP retry in the hope the transiet problem will dissappear. > > > [....] > > > Doesn't the problem really have to do with having applications performing > > > such a low-level action? > > > >At some point, someone has to decide which behaviour is desirable. > >Isn't this only hiding the same policy decision inside an abstraction > >layer > > Yes, but even when the difference may sound subtle, IMHO it's not. > Having that abstraction layer is what let's you choose a policy, without > having the risk of causing any harm to existing apps. > That way, if you ever need to change the low-level-connect() behavoir for > whatever reason, you could still do it. As far as the high-level connect() > behaves the same, there would be no problem. > > Think about it. Why should an application programmer care about TCP > retries, ICMP erros, an the like? > In the same way, why should he care about setting "strange" options such as > SO_REUSEADDR on his listening socket? > Should *he* really handle byte-ordering issues by means of htons() and the > like? > > > >-- and the same could be achieved by e.g. a setsockopt() flag? > > Strictly speaking, you *could* do that. But then you'd have all programmers > implementing themselves a function you could provide them. > You'd have all them implementing the getaddrinfo()/gethostbyname() loop, > setting a strange socket option, etc. Why not provide them with a > well-tested function, and let them spend their time implementing their > application itself? > > > > >(I don't deny that better APIs would not hurt, but we still seem to > >require low-level C-like primitives, and unless there are additional > >ones implemented there, we still have to fix the problems somehow..) > > Well, the low-level ones could be provided as part of the new API. > > Or along with the providing a new API, the current one could be modified as > you suggest. It wouldn't hurt too much if the *low-level* API aborted a > connection establishment because an ICMP error is received. Being a > *low-level* API, you'd be suppossed to know the details behind the function. > > Best Regards, > > > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > > > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Apr 6 19:33:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06810 for ; Tue, 6 Apr 2004 18:43:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAzHj-0006sV-9R for tcpm-archive@odin.ietf.org; Tue, 06 Apr 2004 18:43:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36MhBUI026432 for tcpm-archive@odin.ietf.org; Tue, 6 Apr 2004 18:43:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAzHi-0006ro-LN for tcpm-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 18:43:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06785 for ; Tue, 6 Apr 2004 18:43:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAzHf-0005h6-00 for tcpm-web-archive@ietf.org; Tue, 06 Apr 2004 18:43:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAyLR-0006UV-00 for tcpm-web-archive@ietf.org; Tue, 06 Apr 2004 17:42:59 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAxXa-0007iv-00 for tcpm-web-archive@ietf.org; Tue, 06 Apr 2004 16:51:26 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAxPY-0003qx-3Z for tcpm-web-archive@ietf.org; Tue, 06 Apr 2004 16:43:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAxPR-0001Ob-BA; Tue, 06 Apr 2004 16:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BANai-0001mG-Tr for tcpm@optimus.ietf.org; Mon, 05 Apr 2004 02:28:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12409 for ; Mon, 5 Apr 2004 02:28:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BANaf-0007mc-00 for tcpm@ietf.org; Mon, 05 Apr 2004 02:28:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BANZc-0007fc-00 for tcpm@ietf.org; Mon, 05 Apr 2004 02:27:09 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BANYk-0007TF-00 for tcpm@ietf.org; Mon, 05 Apr 2004 02:26:14 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i356PfR19322; Mon, 5 Apr 2004 09:25:42 +0300 Date: Mon, 5 Apr 2004 09:25:41 +0300 (EEST) From: Pekka Savola To: Fernando Gont cc: tcpm@ietf.org, , Subject: Re: [tcpm] TCP, multiple addresses and soft errors when connecting In-Reply-To: <4.3.2.7.2.20040403152932.00b26ae0@mail.daleclick.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Sat, 3 Apr 2004, Fernando Gont wrote: > At 14:30 02/04/2004 +0300, Pekka Savola wrote: > >What I propose as a way forward for this specific Informational > >document: > > 1) state the reasons why this specific connect() etc. behaviour is > >desirable (read: why many vendors have already done that), and what > >drawbacks it could have (if any), and > > I agree. Great. > > 2) state the desire for getting a better higher-level API which would > >handle all of this and much more (instead of/in addition to 1), but > >mention why this is not an only practical solution. > > What do you mean "this is not an only practical solution"? What I should have said if "but mention why this is would not be a practical solution, if there were no other solutions". That is, new APIs would be great, but we cannot stop fixing problems current APIs until we have something more concrete out there. Otherwise we'd end up with no practically (in short term) deployable solution. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Apr 6 20:08:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15990 for ; Tue, 6 Apr 2004 20:08:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB0bK-0003st-Bk for tcpm-archive@odin.ietf.org; Tue, 06 Apr 2004 20:07:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3707UOV014932 for tcpm-archive@odin.ietf.org; Tue, 6 Apr 2004 20:07:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB0bJ-0003sg-Tb for tcpm-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 20:07:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15934 for ; Tue, 6 Apr 2004 20:07:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB0bI-0000hk-00 for tcpm-web-archive@ietf.org; Tue, 06 Apr 2004 20:07:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAzw1-0001rF-00 for tcpm-web-archive@ietf.org; Tue, 06 Apr 2004 19:24:50 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAyjI-0002Vk-00 for tcpm-web-archive@ietf.org; Tue, 06 Apr 2004 18:07:36 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAyjI-0001K1-Mm for tcpm-web-archive@ietf.org; Tue, 06 Apr 2004 18:07:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAyf1-0002GH-KK; Tue, 06 Apr 2004 18:03:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAyeb-0001d4-37 for tcpm@optimus.ietf.org; Tue, 06 Apr 2004 18:02:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03614 for ; Tue, 6 Apr 2004 18:02:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAyeY-0001iU-00 for tcpm@ietf.org; Tue, 06 Apr 2004 18:02:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAxz0-0002nK-00 for tcpm@ietf.org; Tue, 06 Apr 2004 17:19:47 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1BAwx3-0003sg-00 for tcpm@ietf.org; Tue, 06 Apr 2004 16:13:41 -0400 Received: from jurassic.eng.sun.com ([129.146.87.130]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i36KD9io004215; Tue, 6 Apr 2004 13:13:09 -0700 (PDT) Received: from sun.com (shield.SFBay.Sun.COM [129.144.60.49]) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i36KD9Ej266230; Tue, 6 Apr 2004 13:13:09 -0700 (PDT) Message-ID: <40730F55.7050006@sun.com> Date: Tue, 06 Apr 2004 13:13:09 -0700 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.6) Gecko/20040117 X-Accept-Language: en, zh-hk, zh-tw, zh-cn MIME-Version: 1.0 To: Fernando Gont CC: Pekka Savola , tcpm@ietf.org, v6ops@ops.ietf.org, sebastien.roy@sun.com Subject: Re: [tcpm] TCP, multiple addresses and soft errors when connecting References: <4.3.2.7.2.20040319123019.00bfc520@mail.daleclick.com> <4.3.2.7.2.20040319123019.00bfc520@mail.daleclick.com> <4.3.2.7.2.20040405201120.00b18e70@mail.daleclick.com> In-Reply-To: <4.3.2.7.2.20040405201120.00b18e70@mail.daleclick.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Fernando Gont wrote: >> FYI, SCTP has this same problem. So sctp_connectx() was added in the >> API draft to allow an app to pass in an array of addresses. > > > Is there any reason for which an array of IP addresses is passed, > instead of, say, a domain name? If the argument is a domain name, it will limit the usage of the call. For example, a caller may just want to use a subset of peer addresses to try to connect to it for whatever reason. We should have an API which allows that. Your suggestion on using a domain name is more suitable for a higher level API. > IMHO, it's a better approach than just having connect() fail when ICMP > errors are received. > > However, unless there's a reason for it (as I asked above), I think it's > still a low-level API. > For example, if I want to get the document at > http://www.example.com/index.html , why should I care about whether the > webeserver is IPv4-only, IPv6-only or dual/stack? > Does an application programmer really need to know the IP addresses the > domain "www.example.com" map to? > Actually, should an application programmer be supposed to be > knowledgeable on network addressing? Yes, sctp_connectx() or connectx() is supposed to be a "low" level API, as the other socket calls. The API you mentioned above is more like a library built on top of the socket call layer. The issue in this discussion thread is that we may need help from an even lower level than the socket call layer. Or we can have transport layer socket option on when a connect() attempt should fail (e.g. getting an ICMPv6 error) so that the app can respond to it quickly. Anyway, this is more like an implementation issue than a topic on TCP maintenances and extensions. -- K. Poon. kacheong.poon@sun.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu Apr 8 21:16:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19606 for ; Thu, 8 Apr 2004 21:16:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkcL-0003F7-Gv for tcpm-archive@odin.ietf.org; Thu, 08 Apr 2004 21:15:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i391FbPR012460 for tcpm-archive@odin.ietf.org; Thu, 8 Apr 2004 21:15:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkcH-0003Et-Lw for tcpm-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 21:15:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19520 for ; Thu, 8 Apr 2004 21:15:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBkcD-0000li-00 for tcpm-web-archive@ietf.org; Thu, 08 Apr 2004 21:15:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBkKO-0006pf-00 for tcpm-web-archive@ietf.org; Thu, 08 Apr 2004 20:57:08 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBk74-0004JV-00 for tcpm-web-archive@ietf.org; Thu, 08 Apr 2004 20:43:18 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBjuD-0005KF-Bq for tcpm-web-archive@ietf.org; Thu, 08 Apr 2004 20:30:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjtm-0005RY-N9; Thu, 08 Apr 2004 20:29:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjmY-0002Fu-Kx for tcpm@optimus.ietf.org; Thu, 08 Apr 2004 20:22:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14683 for ; Thu, 8 Apr 2004 20:22:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBjmV-0002Kf-00 for tcpm@ietf.org; Thu, 08 Apr 2004 20:22:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBj4g-0005QC-00 for tcpm@ietf.org; Thu, 08 Apr 2004 19:36:47 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBhxN-0005EN-00 for tcpm@ietf.org; Thu, 08 Apr 2004 18:25:09 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i38MONN07411; Fri, 9 Apr 2004 01:24:24 +0300 Date: Fri, 9 Apr 2004 01:24:23 +0300 (EEST) From: Pekka Savola To: Fernando Gont cc: tcpm@ietf.org, , Subject: Re: [tcpm] TCP, multiple addresses and soft errors when connecting In-Reply-To: <4.3.2.7.2.20040405201058.02a45d80@mail.daleclick.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, 5 Apr 2004, Fernando Gont wrote: > At 09:25 05/04/2004 +0300, Pekka Savola wrote: > > > > 2) state the desire for getting a better higher-level API which would > > > >handle all of this and much more (instead of/in addition to 1), but > > > >mention why this is not an only practical solution. > > > What do you mean "this is not an only practical solution"? > >What I should have said if "but mention why this is would not be a > >practical solution, if there were no other solutions". > > Actually, I think it is the only real solution to the problem. > Having the API report ICMP errors to the application is moving the problem > from the API to the application, but *not* solving it. > > If you leave connect() as is, then you may have the delay problem you > describe (i.e., you may suffer undesirable delays to use a service). > If you make it report ICMP errors to the application, you still have a > problem I mentioned in the other e-mails. You might even say that you'll > have application programmers (probably *not* knowledgeable on TCP/IP > internals) handling issues of the underlying protocols. I have to disagree here. Writing getaddrinfo() loops which include loops around socket() and even connect() are commonplace so this is nothing new. Actually this was discussed in draft-ietf-v6ops-application-transition-02.txt which we just shipped off to the IESG. Section 6.3.2 gives a specific example and section 6.3 describes alternative means; the user does not -- necessarily -- need to know anything and the coder only needs to know to build the right logic. (Which is required anyway for proper v6/v4 applications.) Again, high-level API which makes it smoother to use either v4 or v6 would not hurt either, and could be achieved in one shot. But again, this is not here and now. > So a real solution is to hide all this stuff from the application > programmer. Let him just concentrate on actually using a service, and > handle all the protocol-related issues inside the API. For long-term, yes, that would be preferable (even though I think still there should be low-level equivalents, but not necessarily integrated with connect()). But the problem is that the IETF has avoided specifying APIs whereever it has been able to, and even if we made these here (or elsewhere), there would have to be significant vendor buy-in (so that they could be used to create portable code), and implementation. Even if there would be significant interest, this would take 3 years (minimum). So, for all the good having such APIs would do, I fail to see how it could provide sufficiently short-term fix to this particular problem, and which is why we're documenting the connect() semantics change some have already done. > >That is, new APIs would be great, but we cannot stop fixing problems > >current APIs until we have something more concrete out there. > >Otherwise we'd end up with no practically (in short term) deployable > >solution. > > If you consider it useful, I could try to continue thinking on the > "abstract" API. I'm just thinking about writting some stuff down, so that > there's a place from which which can move things forward. It may take me > some time (say, months), but... I certainly think this is interesting work (actually, I've seen some abstractization libraries for Unix already a couple of years ago, doing something like you say -- but I can't find it now; maybe it was something along the lines of http://thf.ath.cx/snl), but as I stated above, there are significant barriers to be torn down first.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Apr 13 07:24:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06165 for ; Tue, 13 Apr 2004 07:24:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDM1e-0008IG-0q for tcpm-archive@odin.ietf.org; Tue, 13 Apr 2004 07:24:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DBOMO6031880 for tcpm-archive@odin.ietf.org; Tue, 13 Apr 2004 07:24:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDM1d-0008I7-RK for tcpm-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 07:24:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06133 for ; Tue, 13 Apr 2004 07:24:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDM1c-0000uh-00 for tcpm-web-archive@ietf.org; Tue, 13 Apr 2004 07:24:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDLwb-0000bm-00 for tcpm-web-archive@ietf.org; Tue, 13 Apr 2004 07:19:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDLte-0000DC-00 for tcpm-web-archive@ietf.org; Tue, 13 Apr 2004 07:16:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDLtY-0007cH-2Z; Tue, 13 Apr 2004 07:16:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDLsi-0007Vw-9u for tcpm@optimus.ietf.org; Tue, 13 Apr 2004 07:15:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05522 for ; Tue, 13 Apr 2004 07:15:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDLsh-00007a-00 for tcpm@ietf.org; Tue, 13 Apr 2004 07:15:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDLnd-0007ac-00 for tcpm@ietf.org; Tue, 13 Apr 2004 07:09:54 -0400 Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1BDLhe-00072k-00 for tcpm@ietf.org; Tue, 13 Apr 2004 07:03:42 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3DB3YWR019362 for ; Tue, 13 Apr 2004 13:03:34 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 13 Apr 2004 13:03:33 +0200 Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 25RJM6TF; Tue, 13 Apr 2004 13:03:34 +0200 Received: from EFT1701K2P109AD.ericsson.com (dhcp5-141.eed.ericsson.se [164.48.135.141]) by eed.ericsson.se (8.8.8p2+Sun/1.1.mit) with ESMTP id NAA08468 for ; Tue, 13 Apr 2004 13:03:31 +0200 (MET DST) Message-Id: <6.0.3.0.1.20040413092017.024d4720@imap.eed.ericsson.se> X-Sender: eedrel@imap.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Tue, 13 Apr 2004 11:02:19 +0200 To: tcpm@ietf.org From: Reiner Ludwig In-Reply-To: <20040312141734.B64DD77AA17@guns.icir.org> References: <20040312141734.B64DD77AA17@guns.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 13 Apr 2004 11:03:33.0942 (UTC) FILETIME=[F673AD60:01C42146] Subject: [tcpm] Re: frto Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I have finally read the -01 draft, and here are some comments. Editing stuff I will sent directly to the authors. Main comments ------------- - For SCTP, the specification of the F-RTO algorithm seems too vague. We have a paper in one of the upcoming CCR journals where we developed a version of Eifel for SCTP. Although SCTP is very similar to TCP in many ways, we still found a number of subtleties that required special treatment. So, I'm not convinced when you simply write "... the algorithms and other discussion should be applicable also to SCTP." Thus, I would like to see a more detailed specification + discussion for SCTP, or else the SCTP stuff removed. - You explicitly allow F-RTO to be triggered during an ongoing loss recovery, i.e., upon multiple timeouts for the same segment or upon a timeout during fast recovery. Are you sure this works? What if RFC3517 is triggered upon the 3rd DUPACK, the fast retransmit is sent + other segments are retransmitted, and the sender times out again? The fast retransmit could be lost or excessively delayed, or ... I haven't thought this through, but it seems to be a tricky situation. If you can't be 100 percent sure F-RTO works in all these cases, I suggest to only allow the triggering of F-RTO at the very beginning of loss recovery. The same comment applies to the SACK-version of F-RTO. - Algorithm 2b: "If the TCP sender does not have any new data to send, the TCP sender SHOULD transmit a segment from the retransmission queue." You don't say whether it should transmit one or two segments, and you also don't specify which segments. Later in this section you discuss various options. Some of those you do not encourage and some you leave unqualified. I think this is too vague. Implementors will have a hard time to make a choice. I suggest you settle for one option that gets specified and recommended. You can still discuss in some section why you have settled for that option and not for others - if you think that adds to the doc. - The SACK-version of F-RTO seems vague and is hard to follow. For example, ... * in step 2) you say "If duplicate ACKs arrive, ... but stay in step 2." What does 'staying in step 2' mean: continue waiting for ACKs or proceed to step 2a)? * "..., it MAY follow one of the [many] options presented in Section 2." * there are no explanations / motivations presented for the steps of SACK-verion of the algorithm. - Section 4 * Why don't you explicitly recommend using F-RTO with the Eifel response algorithm (a soon to be RFC) instead of outlining alternatives that have been proposed outside of the IETF? * Why do you consider the response to spurious timeouts a subject of further research when we have already reached consensus in the IETF about how to do this response? Minor comments -------------- - The 'RTO' is the retransmission timeout value. It's a value not an event. If you talk about a timeout (event), I think, you should say 'timeout' or '... when the retransmission timer expires ...'. Mixing everything up causes unnecessary double meanings, and potential confusion, especially for those who are not so familiar with the TCP-lingu. - Aligning terminology across RFCs: * "first unacknowledged segment" > "oldest outstanding segment" * "delay peak" > "delay spike" * "high_data" > "RecoveryPoint" [RFC3517] * "new ACK" > "acceptable ACK" [RFC793] - 2nd para in Intro: you should add that standard TCP usually breaks packet conservation after a spurious timeout. - I suggest to structure Section 2 into subsections: * one that contains nothing but the pure algorithm * a subsection for each step where you explain and motivate * a subsection for general discussion: the last three paragraphs of the current Section 2. - Your definition of a spurious timeout is not very precise. We had a lengthy discussion on this related to the Eifel detection algorithm, remember :-) This has resulted in the definition we give in Section 2 of RFC3522 (see 2nd para + the note). - Algorithm 2a: "If ... it [the ACK] is acknowleding a sequence number equal to (or above) the value of send_high [...] continue by retransmitting unacknowledged data in slow start" Really? I suggest to simply say "If the acknowledgement ... in step 1, the TCP sender MUST exit the F-RTO algorithm." (same in the the SACK version) - Algorithm 2b: "If the acknowledgement ... of send_high, ..." > "Else, ..." - Algorithm 3a: How about setting CWND to the loss window (LW) + 2 * MSS. Or instead of (2 * MSS) the ABC equivalent of that? - You talk about "bugfix" and RFC2582. This should be made consistent with the update to RFC2582. - You say that one benefit of F-RTO is that it allows the sender to take RTT sample sooner, and that this leads to larger RTOs. I don't think so because without timestamps and without F-RTO the RTO will stay backed off, i.e., rather large, until a previously unsent segment is sent and acknowledged due to Karn's algorithm [RFC2988]. I hope this helps. ///Reiner At 16:17 12.03.2004, Mark Allman wrote: >Hello! > >As discussed at the meeting last week we'd like to encourage folks to >read and comment on the F-RTO draft: draft-ietf-tsvwg-tcp-frto-01.txt. >Based on the feedback we've received so far it seems like all the large >issues have been working out of this draft and it is near ready to be >forwarded. We'd like folks to read the document and send any remaining >issues to the list. > >Thanks! > >allman > > >-- >Mark Allman -- ICIR -- http://www.icir.org/mallman/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Apr 13 09:52:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12142 for ; Tue, 13 Apr 2004 09:52:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDOKS-0000Hy-8K for tcpm-archive@odin.ietf.org; Tue, 13 Apr 2004 09:51:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DDpuwH001106 for tcpm-archive@odin.ietf.org; Tue, 13 Apr 2004 09:51:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDOKS-0000Hl-3o for tcpm-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 09:51:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12098 for ; Tue, 13 Apr 2004 09:51:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDOKQ-0003hI-00 for tcpm-web-archive@ietf.org; Tue, 13 Apr 2004 09:51:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDOIr-0003WK-00 for tcpm-web-archive@ietf.org; Tue, 13 Apr 2004 09:50:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDOGh-0003MJ-00 for tcpm-web-archive@ietf.org; Tue, 13 Apr 2004 09:48:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDOGf-0008W2-Gh; Tue, 13 Apr 2004 09:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDOGR-0008VT-Tn for tcpm@optimus.ietf.org; Tue, 13 Apr 2004 09:47:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11917 for ; Tue, 13 Apr 2004 09:47:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDOGN-0003KJ-00 for tcpm@ietf.org; Tue, 13 Apr 2004 09:47:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDOEf-0003CN-00 for tcpm@ietf.org; Tue, 13 Apr 2004 09:45:58 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BDODU-00034U-00 for tcpm@ietf.org; Tue, 13 Apr 2004 09:44:44 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3DDieH19387; Tue, 13 Apr 2004 16:44:40 +0300 (EET DST) X-Scanned: Tue, 13 Apr 2004 16:44:30 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3DDiU9C009108; Tue, 13 Apr 2004 16:44:30 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00FDsW7H; Tue, 13 Apr 2004 16:44:29 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3DDiQs18762; Tue, 13 Apr 2004 16:44:26 +0300 (EET DST) Received: from siddha.research.nokia.com ([172.21.40.117]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 13 Apr 2004 16:44:12 +0300 Subject: Re: [tcpm] Re: frto From: Pasi Sarolahti To: ext Reiner Ludwig Cc: tcpm@ietf.org In-Reply-To: <6.0.3.0.1.20040413092017.024d4720@imap.eed.ericsson.se> References: <20040312141734.B64DD77AA17@guns.icir.org> <6.0.3.0.1.20040413092017.024d4720@imap.eed.ericsson.se> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-uxy9KJfYitR2na7yCNML" Organization: Nokia Research Center Message-Id: <1081863861.13041.113.camel@siddha.research.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 13 Apr 2004 16:44:22 +0300 X-OriginalArrivalTime: 13 Apr 2004 13:44:12.0735 (UTC) FILETIME=[679EC4F0:01C4215D] Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --=-uxy9KJfYitR2na7yCNML Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Reiner, Thanks for the comments. My responses below. On Tue, 2004-04-13 at 12:02, ext Reiner Ludwig wrote: > - For SCTP, the specification of the F-RTO algorithm seems too vague. > We have a paper in one of the upcoming CCR journals where we developed > a version of Eifel for SCTP. Although SCTP is very similar to TCP in > many ways, we still found a number of subtleties that required special > treatment. So, I'm not convinced when you simply write "... the > algorithms and other discussion should be applicable also to SCTP." > Thus, I would like to see a more detailed specification + discussion > for SCTP, or else the SCTP stuff removed. Based on the current understanding I have on F-RTO & SCTP, I disagree. The draft discusses the known issues that make F-RTO with SCTP different from TCP, based on what was pointed out on the tsvwg mailing list about a year ago. Unless there are some more specific issues that are problematic for F-RTO with SCTP, I would like to keep the section. > - You explicitly allow F-RTO to be triggered during an ongoing loss > recovery, i.e., upon multiple timeouts for the same segment or upon a > timeout during fast recovery. Are you sure this works? What if RFC3517 > is triggered upon the 3rd DUPACK, the fast retransmit is sent + other > segments are retransmitted, and the sender times out again? The fast > retransmit could be lost or excessively delayed, or ...=20 > I haven't thought this through, but it seems to be a tricky situation. > If you can't be 100 percent sure F-RTO works in all these cases, I > suggest to only allow the triggering of F-RTO at the very beginning of > loss recovery. The same comment applies to the SACK-version of F-RTO. Yep, we also noticed that SACK loss recovery and F-RTO is a bit hairy combination. That's why we disallowed F-RTO if earlier SACK fast recovery is underway. This was already said for SACK-based algorithm, and the next version of the draft says the same also on the basic algorithm side, should someone apply the basic version with SACK TCP. With Reno/NewReno there should not be problems since they make only one retransmission per RTT. > - Algorithm 2b: > "If the TCP sender does not have any new data to send, the TCP sender > SHOULD transmit a segment from the retransmission queue." > You don't say whether it should transmit one or two segments, and you > also don't specify which segments. Later in this section you discuss > various options. Some of those you do not encourage and some you leave > unqualified. I think this is too vague. Implementors will have a hard > time to make a choice. I suggest you settle for one option that gets > specified and recommended. You can still discuss in some section why > you have settled for that option and not for others - if you think > that adds to the doc. We have had also some other comments on this, and it will be changed in the next version. It'll be about the way you outline above. > - The SACK-version of F-RTO seems vague and is hard to follow. For > example, ... [...] Agree. We have worked on the SACK section recently and it'll be hopefully clearer in the next version. > - Section 4=20 > * Why don't you explicitly recommend using F-RTO with the Eifel > response algorithm (a soon to be RFC) instead of outlining > alternatives that have been proposed outside of the IETF?=20 > * Why do you consider the response to spurious timeouts a subject of > further research when we have already reached consensus in the IETF > about how to do this response? Yes, there has been rough consensus for taking Eifel Response for Experimental RFC. However, since other kinds of responses have also been discussed in the IETF mailing lists and by some papers, we wanted to keep options open for those, and for any possible future work, too. I thought this was the main reason for doing the separation in to detection and response algorithms in the first place, right? Of course, since Eifel Response is (soon) the only response-related RFC so far, it'll be the likely option chosen by most. > Minor comments > -------------- [...] I generally acknowledge and agree with these, although... > - The 'RTO' is the retransmission timeout value. It's a value not an > event. If you talk about a timeout (event), I think, you should say > 'timeout' or '... when the retransmission timer expires ...'. Looking at the recent RFCs from tsvwg, this doesn't seem to be the common practice. However, I do agree that the terminology should be as clear as possible. We'll try to keep our focus on this. > - You say that one benefit of F-RTO is that it allows the sender to > take RTT sample sooner, and that this leads to larger RTOs. I don't > think so because without timestamps and without F-RTO the RTO will > stay backed off, i.e., rather large, until a previously unsent segment > is sent and acknowledged due to Karn's algorithm [RFC2988]. The draft just mentions about the side-effect of not retransmitting delayed segments has on the RTT estimator and thus on the RTO value. Well, I don't have too much against dropping or modifying the paragraph if folks don't like it, although I still would like to keep the current note we have there. > I hope this helps. Thanks, these are helpful indeed. - Pasi --=20 http://www.iki.fi/pasi.sarolahti --=-uxy9KJfYitR2na7yCNML Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQBAe+60oNa7NH1G2csRAjrQAJ9Q7GZ4xo+CqDhUZsR38UbLp998KQCfZ9rH /mlt+LJqXNzBVGT/QNg1iFo= =ZMGy -----END PGP SIGNATURE----- --=-uxy9KJfYitR2na7yCNML-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu Apr 15 18:26:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03978 for ; Thu, 15 Apr 2004 18:26:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEFHq-0004SD-In for tcpm-archive@odin.ietf.org; Thu, 15 Apr 2004 18:24:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FMOkds017117 for tcpm-archive@odin.ietf.org; Thu, 15 Apr 2004 18:24:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEFEZ-00036c-0X for tcpm-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 18:21:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02341 for ; Thu, 15 Apr 2004 18:21:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEFEW-0000kV-8H for tcpm-web-archive@ietf.org; Thu, 15 Apr 2004 18:21:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEF2X-0006xy-00 for tcpm-web-archive@ietf.org; Thu, 15 Apr 2004 18:08:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEEb9-00066Y-00 for tcpm-web-archive@ietf.org; Thu, 15 Apr 2004 17:40:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDkq-0000uB-EV; Thu, 15 Apr 2004 16:46:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDhJ-0008Ut-Ig for tcpm@optimus.ietf.org; Thu, 15 Apr 2004 16:42:57 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25732; Thu, 15 Apr 2004 16:42:53 -0400 (EDT) Message-Id: <200404152042.QAA25732@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: tcpm@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 15 Apr 2004 16:42:53 -0400 Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-dcr-00.txt Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Improving the robustness of TCP to Non-Congestion Events. Author(s) : S. Bhandarkar, A. Reddy Filename : draft-ietf-tcpm-tcp-dcr-00.txt Pages : 16 Date : 2004-4-15 This document proposes TCP-DCR, a simple modification to the TCP congestion control algorithm to make it more robust to non-congestion events. In the absence of explicit notification from the network, the TCP congestion control algorithm treats the receipt of three duplicate acknowledgements as an indication of congestion in the network. This is not always correct, notably so in wireless networks with channel errors or networks prone to excessive packet reordering, resulting in degraded performance. TCP-DCR aims to remedy this by delaying the congestion response of TCP for a short interval of time tau, thereby creating room to handle any non-congestion events that may have occurred. If at the end of the delay tau, the event is not handled, then it is treated as a congestion loss. The modifications themselves do not handle the non-congestion event, but rather rely on some underlying mechanism to do this. This document discusses the implications of delaying congestion response on the fairness, TCP- compatibility and network dynamics, and the benefits to be gained by applying the TCP-DCR modifications to TCP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-dcr-00.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-tcpm-tcp-dcr-00.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-tcpm-tcp-dcr-00.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: <2004-4-15154017.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-tcp-dcr-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-dcr-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-15154017.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 16 03:23:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18904 for ; Fri, 16 Apr 2004 03:23:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BENdP-0007bP-Dr for tcpm-archive@odin.ietf.org; Fri, 16 Apr 2004 03:19:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3G7JZOB029219 for tcpm-archive@odin.ietf.org; Fri, 16 Apr 2004 03:19:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BENZ9-0006i8-OA for tcpm-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 03:15:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18267 for ; Fri, 16 Apr 2004 03:15:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BENZ7-0002Un-Fq for tcpm-web-archive@ietf.org; Fri, 16 Apr 2004 03:15:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BENYO-0002Lh-00 for tcpm-web-archive@ietf.org; Fri, 16 Apr 2004 03:14:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BENXF-00028s-00 for tcpm-web-archive@ietf.org; Fri, 16 Apr 2004 03:13:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BENPL-0004qw-H0; Fri, 16 Apr 2004 03:05:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BENHV-0003GU-JA for tcpm@optimus.ietf.org; Fri, 16 Apr 2004 02:56:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16816 for ; Fri, 16 Apr 2004 02:56:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BENHR-0000Pt-I1 for tcpm@ietf.org; Fri, 16 Apr 2004 02:56:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BENGX-0000KS-00 for tcpm@ietf.org; Fri, 16 Apr 2004 02:55:58 -0400 Received: from gw2.cox.com ([24.248.72.254] helo=hatl0ms21.CORP.COX.COM) by ietf-mx with esmtp (Exim 4.12) id 1BENFa-0000A7-00; Fri, 16 Apr 2004 02:54:58 -0400 Received: from mail pickup service by hatl0ms21.CORP.COX.COM with Microsoft SMTPSVC; Fri, 16 Apr 2004 02:54:30 -0400 Received: from cox.com ([10.225.2.122]) by hatl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 15 Apr 2004 19:09:22 -0400 Received: from ([132.151.6.22]) by post4.cox.com with SMTP ; Thu, 15 Apr 2004 18:50:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDkp-0000tu-Bv; Thu, 15 Apr 2004 16:46:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDhJ-0008Ut-HH for i-d-announce@optimus.ietf.org; Thu, 15 Apr 2004 16:42:57 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25732; Thu, 15 Apr 2004 16:42:53 -0400 (EDT) Message-Id: <200404152042.QAA25732@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: tcpm@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 15 Apr 2004 16:42:53 -0400 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: internet-drafts@ietf.org X-OriginalArrivalTime: 15 Apr 2004 23:09:22.0947 (UTC) FILETIME=[B081FD30:01C4233E] Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-dcr-00.txt Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Improving the robustness of TCP to Non-Congestion Events. Author(s) : S. Bhandarkar, A. Reddy Filename : draft-ietf-tcpm-tcp-dcr-00.txt Pages : 16 Date : 2004-4-15 This document proposes TCP-DCR, a simple modification to the TCP congestion control algorithm to make it more robust to non-congestion events. In the absence of explicit notification from the network, the TCP congestion control algorithm treats the receipt of three duplicate acknowledgements as an indication of congestion in the network. This is not always correct, notably so in wireless networks with channel errors or networks prone to excessive packet reordering, resulting in degraded performance. TCP-DCR aims to remedy this by delaying the congestion response of TCP for a short interval of time tau, thereby creating room to handle any non-congestion events that may have occurred. If at the end of the delay tau, the event is not handled, then it is treated as a congestion loss. The modifications themselves do not handle the non-congestion event, but rather rely on some underlying mechanism to do this. This document discusses the implications of delaying congestion response on the fairness, TCP- compatibility and network dynamics, and the benefits to be gained by applying the TCP-DCR modifications to TCP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-dcr-00.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-tcpm-tcp-dcr-00.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-tcpm-tcp-dcr-00.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: <2004-4-15154017.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-tcp-dcr-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-dcr-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-15154017.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Apr 20 13:36:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06989 for ; Tue, 20 Apr 2004 13:36:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFywE-0002mm-FF for tcpm-archive@odin.ietf.org; Tue, 20 Apr 2004 13:21:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KHLcCb010704 for tcpm-archive@odin.ietf.org; Tue, 20 Apr 2004 13:21:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFydM-0003FT-RQ for tcpm-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 13:02:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04176 for ; Tue, 20 Apr 2004 13:02:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFydL-0000XW-4I for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 13:02:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFycL-0000Jb-00 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 13:01:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFybM-0007ne-00 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 13:00:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFyH7-0001Fl-Da; Tue, 20 Apr 2004 12:39:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFxlI-0001ZA-EW for tcpm@optimus.ietf.org; Tue, 20 Apr 2004 12:06:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29528 for ; Tue, 20 Apr 2004 12:06:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFxlH-0007Nh-4w for tcpm@ietf.org; Tue, 20 Apr 2004 12:06:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFxkX-00077p-00 for tcpm@ietf.org; Tue, 20 Apr 2004 12:05:30 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx with esmtp (Exim 4.12) id 1BFxju-0006qR-00 for tcpm@ietf.org; Tue, 20 Apr 2004 12:04:51 -0400 Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by wyvern.icir.org (8.12.9p1/8.12.8) with ESMTP id i3KG4lsM013573; Tue, 20 Apr 2004 09:04:47 -0700 (PDT) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 1D04377A9EB; Tue, 20 Apr 2004 12:04:46 -0400 (EDT) To: Pasi Sarolahti From: Mark Allman Reply-To: mallman@icir.org Cc: ext Reiner Ludwig , tcpm@ietf.org Subject: Re: [tcpm] Re: frto In-Reply-To: <1081863861.13041.113.camel@siddha.research.nokia.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Bad to the Bone MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 20 Apr 2004 12:04:46 -0400 Message-Id: <20040420160446.1D04377A9EB@guns.icir.org> Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 --=-=-= Content-Type: text/plain; charset=us-ascii > > - For SCTP, the specification of the F-RTO algorithm seems too vague. > > We have a paper in one of the upcoming CCR journals where we > > developed a version of Eifel for SCTP. Although SCTP is very similar > > to TCP in many ways, we still found a number of subtleties that > > required special treatment. So, I'm not convinced when you simply > > write "... the algorithms and other discussion should be applicable > > also to SCTP." Thus, I would like to see a more detailed > > specification + discussion for SCTP, or else the SCTP stuff removed. > > Based on the current understanding I have on F-RTO & SCTP, I disagree. > The draft discusses the known issues that make F-RTO with SCTP > different from TCP, based on what was pointed out on the tsvwg mailing > list about a year ago. Unless there are some more specific issues that > are problematic for F-RTO with SCTP, I would like to keep the section. Might I suggest a middle ground.... It seems as if Reiner's assertion is that the language about SCTP is vague -- indicating that maybe the SCTP stuff is not as well thought out. And, it seems that Pasi is saying that the SCTP stuff has been thought about. So, will a simple cleanup of the language (making the SCTP language less speculative) fix things here? > > - Section 4 > > * Why don't you explicitly recommend using F-RTO with the Eifel > > response algorithm (a soon to be RFC) instead of outlining > > alternatives that have been proposed outside of the IETF? > > * Why do you consider the response to spurious timeouts a subject of > > further research when we have already reached consensus in the IETF > > about how to do this response? > > Yes, there has been rough consensus for taking Eifel Response for > Experimental RFC. However, since other kinds of responses have also > been discussed in the IETF mailing lists and by some papers, we wanted > to keep options open for those, and for any possible future work, > too. I think I agree with Pasi. Although, at the same time, while not recommending or endorsing the Eifel response, I think that noting that it is the only one currently specified within the RFC series is a good idea (and, for all practical purposes, would constitute an implicit recommendation, I think). allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAhUodWyrrWs4yIs4RAgTjAJ9DwypIFKWqleIJO0Vy6nAVCDEtxwCgmABj LQkSejpqQQrFNMnQ1l9vxLY= =dDye -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Apr 20 13:43:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07521 for ; Tue, 20 Apr 2004 13:43:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFz2O-0005Zu-G9 for tcpm-archive@odin.ietf.org; Tue, 20 Apr 2004 13:28:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KHS0GD021425 for tcpm-archive@odin.ietf.org; Tue, 20 Apr 2004 13:28:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFyoy-0000fw-Sp for tcpm-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 13:14:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05100 for ; Tue, 20 Apr 2004 13:14:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFyox-0001DL-0b for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 13:14:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFyo6-0001AU-00 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 13:13:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFynD-00018J-00 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 13:12:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFyTj-0007aX-Vm; Tue, 20 Apr 2004 12:52:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFxzr-0000NS-W9 for tcpm@optimus.ietf.org; Tue, 20 Apr 2004 12:21:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01119 for ; Tue, 20 Apr 2004 12:21:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFxzq-0004BE-Ik for tcpm@ietf.org; Tue, 20 Apr 2004 12:21:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFxyy-0003tI-00 for tcpm@ietf.org; Tue, 20 Apr 2004 12:20:24 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx with esmtp (Exim 4.12) id 1BFxy6-0003bH-00 for tcpm@ietf.org; Tue, 20 Apr 2004 12:19:30 -0400 Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by wyvern.icir.org (8.12.9p1/8.12.8) with ESMTP id i3KGJTsM013776 for ; Tue, 20 Apr 2004 09:19:29 -0700 (PDT) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id A1FA577A9EB for ; Tue, 20 Apr 2004 12:19:28 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Reply-To: mallman@icir.org Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Bad to the Bone MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 20 Apr 2004 12:19:28 -0400 Message-Id: <20040420161928.A1FA577A9EB@guns.icir.org> Subject: [tcpm] issue tracker Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 --=-=-= Content-Type: text/plain; charset=us-ascii BTW, Ted and I are trying out the RT issue tracker for keeping track of ... well, issues raised with the tcpm documents. I just added a few for the f-rto document. Anyone can check in on the issue queues at: http://rt.psg.com/ There are instructions on the page for anonymous login. allman --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAhU2QWyrrWs4yIs4RAg3CAJ4wBs2CRJuY2hGg5npcgau05rsuUQCgjJE+ G/3ZxxILI7AifXLoaR56WQI= =hrHI -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Apr 20 15:49:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17708 for ; Tue, 20 Apr 2004 15:49:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG0yi-00067P-GJ for tcpm-archive@odin.ietf.org; Tue, 20 Apr 2004 15:32:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KJWKw0023515 for tcpm-archive@odin.ietf.org; Tue, 20 Apr 2004 15:32:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG0oy-0001YC-GS for tcpm-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 15:22:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15779 for ; Tue, 20 Apr 2004 15:22:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG0ox-0002jP-7K for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 15:22:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG0o2-0002eZ-00 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 15:21:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG0nT-0002bN-00 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 15:20:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG0Tn-0008VM-9d; Tue, 20 Apr 2004 15:00:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG0Fy-0002O5-Se for tcpm@optimus.ietf.org; Tue, 20 Apr 2004 14:46:06 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11813; Tue, 20 Apr 2004 14:46:02 -0400 (EDT) Message-Id: <200404201846.OAA11813@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: tcpm@ietf.org, mankin@psg.com From: Internet-Drafts@ietf.org Date: Tue, 20 Apr 2004 14:46:02 -0400 Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-tcpsecure-00.txt Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Transmission Control Protocol security considerations Author(s) : R. Stewart Filename : draft-ietf-tcpm-tcpsecure-00.txt Pages : 10 Date : 2004-4-20 TCP (RFC793 [1]) is widely deployed and one of the most often used reliable end to end protocols for data communication. Yet when it was defined over 20 years ago the internet, as we know it, was a different place lacking many of the threats that are now common. Recently several rather serious threats have been detailed that can pose new methods for both denial of service and possibly data injection by blind attackers. This document details those threats and also proposes some small changes to the way TCP handles inbound segments that either eliminate the threats or at least minimize them to a more acceptable level. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.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-tcpm-tcpsecure-00.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-tcpm-tcpsecure-00.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: <2004-4-20151043.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-tcpsecure-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-20151043.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Apr 20 18:21:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03235 for ; Tue, 20 Apr 2004 18:21:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG3Vi-00050R-RX for tcpm-archive@odin.ietf.org; Tue, 20 Apr 2004 18:14:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KMEYdl019235 for tcpm-archive@odin.ietf.org; Tue, 20 Apr 2004 18:14:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG3Dy-0005Q0-KI for tcpm-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 17:56:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29637 for ; Tue, 20 Apr 2004 17:56:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG3Dw-00041t-4K for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 17:56:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG3Cx-0003tq-00 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 17:55:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG3C3-0003nr-00 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 17:54:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG2pb-0000yQ-Ds; Tue, 20 Apr 2004 17:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG1Uw-0002oB-Nm for tcpm@optimus.ietf.org; Tue, 20 Apr 2004 16:05:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19196 for ; Tue, 20 Apr 2004 16:05:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG1Uv-0006It-3j for tcpm@ietf.org; Tue, 20 Apr 2004 16:05:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG1UC-0006C8-00 for tcpm@ietf.org; Tue, 20 Apr 2004 16:04:53 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx with esmtp (Exim 4.12) id 1BG1T5-000659-00 for tcpm@ietf.org; Tue, 20 Apr 2004 16:03:43 -0400 Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by wyvern.icir.org (8.12.9p1/8.12.8) with ESMTP id i3KK3g7A017344; Tue, 20 Apr 2004 13:03:42 -0700 (PDT) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id E690777A9EB; Tue, 20 Apr 2004 16:03:40 -0400 (EDT) To: tcpm@ietf.org Cc: "Ted Faber" From: Mark Allman Reply-To: mallman@icir.org Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Bad to the Bone MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 20 Apr 2004 16:03:40 -0400 Message-Id: <20040420200340.E690777A9EB@guns.icir.org> Subject: [tcpm] new work item: TCP security issue Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 --=-=-= Content-Type: text/plain; charset=us-ascii Just announced internet-draft: > Title : Transmission Control Protocol security considerations > Author(s) : R. Stewart > Filename : draft-ietf-tcpm-tcpsecure-00.txt > Pages : 10 > Date : 2004-4-20 > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt Hi folks! We wanted to announce a new I-D and TCPM work item. The draft is "Transmission Control Protocol security considerations" (draft-ietf-tcpm-tcpsecure-00.txt). We believe we owe a bit in the way of explanation since it seems that this is being foisted upon the WG without much input. The brief story is that a bunch of folks were made aware of the TCP security vulnerability outlined in the above draft. (I think many people have been aware of these things for a long time. But, the driver here is that there is a new conference paper that is going to show the ease with which the vulnerability can be exploited.) Many people from a number of TCP implementers (vendors) have been busily working behind the scenes to come up with reasonable fixes before the vulnerability was announced. The fixes are in the I-D. The vulnerability has been announced (via the standard security issues venues). As part of this process Randall Stewart wrote the above mentioned I-D for this WG to ponder. A few notes since this I-D got adopted as a WG item with zero public / open input: * Until the vulnerability was announced we didn't want to entertain a huge discussion on the public mailing list for obvious reasons. * The transport ADs, security ADs and TCPM WG chairs all agreed that this is an important problem to address and that TCPM is the correct WG in which to address it. That said, if folks think we made the wrong call here, please feel free to speak up and tell us why we screwed up. * The fixes suggested in the above I-D are not being pre-judged as *THE* answer. Rather, they represent *A POSSIBLE* solution (and running code) that this WG will consider. In other words, we are not trying to simply ram this document through the WG and produce an RFC. This WG will deliberate on the I-D as it would any other. * Alternate solutions are welcome. We would like to encourage folks who have different solutions to the problems outlined in the draft to put those forward for consideration. Any other comments folks have on this draft / issue are very welcome. Thanks! Mark & Ted --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAhYIcWyrrWs4yIs4RAqBvAJ9wWzecsGtL6gn8avrhj5I/nE+DwwCdEce2 USNUPckAlSbOpUDSdJs4YNM= =kxeo -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Apr 20 19:00:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05539 for ; Tue, 20 Apr 2004 19:00:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG4By-0003xT-Sb for tcpm-archive@odin.ietf.org; Tue, 20 Apr 2004 18:58:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KMwETb015211 for tcpm-archive@odin.ietf.org; Tue, 20 Apr 2004 18:58:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG3wW-00050o-6u for tcpm-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 18:42:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04565 for ; Tue, 20 Apr 2004 18:42:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG3wS-00010T-Un for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 18:42:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG3vW-0000vn-00 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 18:41:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG3ua-0000rl-00 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 18:40:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG3jl-0006uJ-FK; Tue, 20 Apr 2004 18:29:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG3Y9-0007XC-Mn for tcpm@optimus.ietf.org; Tue, 20 Apr 2004 18:17:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02496 for ; Tue, 20 Apr 2004 18:17:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG3Y6-0006UB-RF for tcpm@ietf.org; Tue, 20 Apr 2004 18:17:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG3WO-0006CJ-00 for tcpm@ietf.org; Tue, 20 Apr 2004 18:15:17 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BG3VC-0005w9-00 for tcpm@ietf.org; Tue, 20 Apr 2004 18:14:02 -0400 Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3KMDiN06759; Tue, 20 Apr 2004 15:13:44 -0700 (PDT) Message-ID: <4085A097.1060108@isi.edu> Date: Tue, 20 Apr 2004 15:13:43 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mallman@icir.org CC: tcpm@ietf.org, Ted Faber Subject: Re: [tcpm] new work item: TCP security issue References: <20040420200340.E690777A9EB@guns.icir.org> In-Reply-To: <20040420200340.E690777A9EB@guns.icir.org> X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig554CE7448EBC81F732D94C6B" X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig554CE7448EBC81F732D94C6B Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mark Allman wrote: > Just announced internet-draft: > >> Title : Transmission Control Protocol security considerations >> Author(s) : R. Stewart >> Filename : draft-ietf-tcpm-tcpsecure-00.txt >> Pages : 10 >> Date : 2004-4-20 >> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt > > > Hi folks! > > We wanted to announce a new I-D and TCPM work item. The draft is > "Transmission Control Protocol security considerations" > (draft-ietf-tcpm-tcpsecure-00.txt). We believe we owe a bit in the way > of explanation since it seems that this is being foisted upon the WG > without much input. > > The brief story is that a bunch of folks were made aware of the TCP > security vulnerability outlined in the above draft. (I think many > people have been aware of these things for a long time. But, the driver > here is that there is a new conference paper that is going to show the > ease with which the vulnerability can be exploited.) Many people from a > number of TCP implementers (vendors) have been busily working behind the > scenes to come up with reasonable fixes before the vulnerability was > announced. The fixes are in the I-D. The vulnerability has been > announced (via the standard security issues venues). As part of this > process Randall Stewart wrote the above mentioned I-D for this WG to > ponder. > > A few notes since this I-D got adopted as a WG item with zero public / > open input: Mark, Er, well. Let's talk about that. Last I checked, we rejected kings, which includes input of this sort from the top down. This draft should be withdrawn and resubmitted as individual immediately, since it is NOT YET a WG doc - not until _we_ start the process. The _WG_ - not the IAB, not the IESG, etc. - should decide for ourselves whether we want the individual item (after we READ it) as a WG item. Also, temporal order is important - i.e., 'it's a WG doc if the IESG/chair decide and THEN we get to nix it'. This is a bottom-up process. _THEN_ the hierarchy gets to decide whether we can work on it. Not the other way around. (FWIW, I would concur that this should be a WG doc anyway; this isn't about the doc, it's about the recurring abuse of process). Joe > > * Until the vulnerability was announced we didn't want to entertain a > huge discussion on the public mailing list for obvious reasons. > > * The transport ADs, security ADs and TCPM WG chairs all agreed that > this is an important problem to address and that TCPM is the correct > WG in which to address it. That said, if folks think we made the > wrong call here, please feel free to speak up and tell us why we > screwed up. > > * The fixes suggested in the above I-D are not being pre-judged as > *THE* answer. Rather, they represent *A POSSIBLE* solution (and > running code) that this WG will consider. In other words, we are > not trying to simply ram this document through the WG and produce an > RFC. This WG will deliberate on the I-D as it would any other. > > * Alternate solutions are welcome. We would like to encourage folks > who have different solutions to the problems outlined in the draft > to put those forward for consideration. > > Any other comments folks have on this draft / issue are very welcome. > > Thanks! > > Mark & Ted > > > --------------enig554CE7448EBC81F732D94C6B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAhaCcE5f5cImnZrsRAjK1AKD5jf7nPfvF2nGWQyMUVPLU/gMr4wCfZKuM 6SDwPNl+fBZZVOyHVViB1IE= =OkBr -----END PGP SIGNATURE----- --------------enig554CE7448EBC81F732D94C6B-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Apr 20 19:55:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08403 for ; Tue, 20 Apr 2004 19:55:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG51f-0001lQ-DF for tcpm-archive@odin.ietf.org; Tue, 20 Apr 2004 19:51:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KNpd1P006774 for tcpm-archive@odin.ietf.org; Tue, 20 Apr 2004 19:51:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG4vY-0007fQ-TI for tcpm-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 19:45:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07721 for ; Tue, 20 Apr 2004 19:45:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG4vX-0005g2-4V for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 19:45:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG4ub-0005cc-00 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 19:44:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG4uO-0005ZR-00 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 19:44:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG4cr-00077F-3g; Tue, 20 Apr 2004 19:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG4RV-0002Ib-1b for tcpm@optimus.ietf.org; Tue, 20 Apr 2004 19:14:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06154 for ; Tue, 20 Apr 2004 19:14:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG4RT-0003BL-DA for tcpm@ietf.org; Tue, 20 Apr 2004 19:14:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG4Qc-00037b-00 for tcpm@ietf.org; Tue, 20 Apr 2004 19:13:22 -0400 Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx with esmtp (Exim 4.12) id 1BG4Pl-00033H-00 for tcpm@ietf.org; Tue, 20 Apr 2004 19:12:29 -0400 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.9p1/8.12.8) with ESMTP id i3KNCMcb008483; Tue, 20 Apr 2004 16:12:22 -0700 (PDT) (envelope-from floyd@cougar.icir.org) Message-Id: <200404202312.i3KNCMcb008483@cougar.icir.org> To: Randall Stewart cc: tcpm@ietf.org From: Sally Floyd Date: Tue, 20 Apr 2004 16:12:22 -0700 Subject: [tcpm] draft-ietf-tcpm-tcpsecure Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Randall - Many thanks for the draft! I haven't read it carefully yet, but I have been worrying about this issue for HighSpeed TCP, where the receive window is likely to be quite large. The large receive window makes it even easier for an attacker to guess a valid sequence number for a reset. It also wasn't on my radar when I wrote the HighSpeed TCP document, now RFC 3649, so it is not mentioned in the Security Considerations section of that document, in terms of a security risk related to higher congestion windows. Regards, - Sally _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Apr 20 21:08:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12859 for ; Tue, 20 Apr 2004 21:08:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG69l-0002Sx-ME for tcpm-archive@odin.ietf.org; Tue, 20 Apr 2004 21:04:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L145RE009468 for tcpm-archive@odin.ietf.org; Tue, 20 Apr 2004 21:04:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG5yS-0004Vm-GD for tcpm-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 20:52:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11828 for ; Tue, 20 Apr 2004 20:52:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG5yQ-0003jE-8k for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 20:52:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG5xu-0003fK-00 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 20:51:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG5wt-0003Ye-00 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 20:50:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG5nR-0000XP-IR; Tue, 20 Apr 2004 20:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG5cF-0003PD-0r for tcpm@optimus.ietf.org; Tue, 20 Apr 2004 20:29:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10474 for ; Tue, 20 Apr 2004 20:29:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG5cC-0001eK-Rm for tcpm@ietf.org; Tue, 20 Apr 2004 20:29:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG5bE-0001YS-00 for tcpm@ietf.org; Tue, 20 Apr 2004 20:28:25 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx with esmtp (Exim 4.12) id 1BG5ah-0001UL-00 for tcpm@ietf.org; Tue, 20 Apr 2004 20:27:51 -0400 Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by wyvern.icir.org (8.12.9p1/8.12.8) with ESMTP id i3L0Rp7A021092; Tue, 20 Apr 2004 17:27:51 -0700 (PDT) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 9023477A9EB; Tue, 20 Apr 2004 20:27:49 -0400 (EDT) To: Joe Touch From: Mark Allman Reply-To: mallman@icir.org Cc: tcpm@ietf.org, Ted Faber Subject: Re: [tcpm] new work item: TCP security issue In-Reply-To: <4085A097.1060108@isi.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Bad to the Bone MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 20 Apr 2004 20:27:49 -0400 Message-Id: <20040421002749.9023477A9EB@guns.icir.org> Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 --=-=-= Content-Type: text/plain; charset=us-ascii Joe- > Er, well. Let's talk about that. Last I checked, we rejected kings, > which includes input of this sort from the top down. I agree. I also hope that we can agree that within the IETF we can drop the rigidity and can, on ocassion, trust the leadership to chart a reasonable *course* (note I *did not* say "make the correct *decision*"). We all chatted about this late last week and felt that it would be good to show that the IETF is actively interested in fixing one of its core protocols when the vulnerability was announced. Maybe that was the right call, maybe it was not. But, it was a call we made. To elaborate... * There are no black helicopters here, Joe. As soon as the draft was announced I sent a note that Ted and I drafted explaining things. We did not try to sneak this by the WG or the broader community. We were as up-front as we could be given the constraints. * I agree that this is not the right process in general. The WG should get first crack at determining whether a particular document will be a WG work item or not. That is the process the IETF uses. That will be the process this WG uses. I believe the chairs understand that quite well. * That said, I hope that we can allow for a little flexibility in certain situations. This is clearly not a normal situation any way you look at it. I hope that the community can withstand a little process bending in such cases. One can argue that a little bending leads to a lot of bending, of course. And, so it's fine with me that you think we have made the wrong call and that you have recorded the dissent. If it turns into a pattern we should be flogged in the plenary. * As indicated in the previous mail, we did not finalize anything. There was no RFC approved and queued up behind the scenes. We charted a course, we did not make a decision. There is a difference and I hope you can recognize that. Sometimes decisions need to be made. We have selected leadership to, among other things, lead. > (FWIW, I would concur that this should be a WG doc anyway; Good. I am glad we can agree on that. > this isn't about the doc, it's about the recurring abuse of process). I'd like you to elaborate because as that stands it smells like so much hyperbole and bullshit from where I am sitting (which is the target of your email). Thanks! allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAhcAFWyrrWs4yIs4RAqjqAKCOg/jHaUpVS9GbESun1/xY2PQOBQCeOFlI Vcf4khjYiDIRMkUdyHuhBac= =Cd/F -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Apr 20 21:28:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13666 for ; Tue, 20 Apr 2004 21:28:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG6Oc-0008Ri-8S for tcpm-archive@odin.ietf.org; Tue, 20 Apr 2004 21:19:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L1JQnx032461 for tcpm-archive@odin.ietf.org; Tue, 20 Apr 2004 21:19:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG6D0-0003u4-U7 for tcpm-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 21:07:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12826 for ; Tue, 20 Apr 2004 21:07:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG6Cy-0005Jp-Hj for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 21:07:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG6CD-0005Fl-00 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 21:06:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG6Bc-0005AR-00 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 21:06:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG66o-0008RB-0o; Tue, 20 Apr 2004 21:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG5ta-0002Vh-T6 for tcpm@optimus.ietf.org; Tue, 20 Apr 2004 20:47:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11629 for ; Tue, 20 Apr 2004 20:47:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG5tY-0003Ik-I5 for tcpm@ietf.org; Tue, 20 Apr 2004 20:47:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG5sc-0003FY-00 for tcpm@ietf.org; Tue, 20 Apr 2004 20:46:23 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BG5sS-0003C7-00 for tcpm@ietf.org; Tue, 20 Apr 2004 20:46:12 -0400 Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3L0jGN11320; Tue, 20 Apr 2004 17:45:16 -0700 (PDT) Message-ID: <4085C41C.7000004@isi.edu> Date: Tue, 20 Apr 2004 17:45:16 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mallman@icir.org CC: tcpm@ietf.org, Ted Faber Subject: Re: [tcpm] new work item: TCP security issue References: <20040421002749.9023477A9EB@guns.icir.org> In-Reply-To: <20040421002749.9023477A9EB@guns.icir.org> X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4EB7AF9EFC4E450B6448FD2E" X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4EB7AF9EFC4E450B6448FD2E Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mark Allman wrote: > Joe- > > >>Er, well. Let's talk about that. Last I checked, we rejected kings, >>which includes input of this sort from the top down. > > I agree. > > I also hope that we can agree that within the IETF we can drop the > rigidity and can, on ocassion, trust the leadership to chart a > reasonable *course* (note I *did not* say "make the correct > *decision*"). ... > ... We have selected leadership to, among other things, lead. Mark (and this will be the last post, primarily to elaborate as requested below; I'll be glad to take this offline otherwise), That's where we disagree. IMO, the 'leadership' is here to help the WGs get work done, not to lead us. ... >>this isn't about the doc, it's about the recurring abuse of process). > > I'd like you to elaborate because as that stands it smells like so much > hyperbole and bullshit from where I am sitting (which is the target of > your email). This is driven by the "leadership" at the last TSVWG meeting, where a presentation on yet-another (IMO) QoS system was presented. The WG gave the presentation a resounding thud (IMO), i.e., when people were asked to review the doc, a standing-room-only crowd couldn't offer the requested 3 volunteers sufficiently interested to participate. That smacked of the IESG deciding what was important for the WG; this does to. From where I sit, as Jose Wales said, "Don't piss down my back and tell me it's raining" (to continue the scatology). There were no helicopters, and thus there also was no URGENT need to usurp the process of the WG by side-stepping procedure. There was plenty of time to show that doc to the WG and get feedback; it would have taken a day or two. That's still the IETF "reacting to the situation". You didn't need to make a decision on behalf of the WG to appear to be acting quickly. Whether I trust you or not (and generally, you in particular I do) isn't the point. Joe --------------enig4EB7AF9EFC4E450B6448FD2E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAhcQgE5f5cImnZrsRAqq4AKCwpE5km6vPGN/y0znmz0VAKSiEBgCdGiUg LNs/sBrEph7l5BtnjE8iaZI= =ut65 -----END PGP SIGNATURE----- --------------enig4EB7AF9EFC4E450B6448FD2E-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Apr 20 21:52:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14791 for ; Tue, 20 Apr 2004 21:52:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG6lY-0001Tq-LU for tcpm-archive@odin.ietf.org; Tue, 20 Apr 2004 21:43:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L1h8Js005682 for tcpm-archive@odin.ietf.org; Tue, 20 Apr 2004 21:43:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG6ZB-0005IX-EH for tcpm-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 21:30:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13798 for ; Tue, 20 Apr 2004 21:30:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG6Z8-00079Y-L7 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 21:30:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG6Y9-00073k-00 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 21:29:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG6XC-0006wl-00 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 21:28:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG6PG-0000Jo-4E; Tue, 20 Apr 2004 21:20:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG6Fo-0004yV-Du for tcpm@optimus.ietf.org; Tue, 20 Apr 2004 21:10:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12920 for ; Tue, 20 Apr 2004 21:10:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG6Fl-0005Vm-UN for tcpm@ietf.org; Tue, 20 Apr 2004 21:10:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG6Eo-0005S3-00 for tcpm@ietf.org; Tue, 20 Apr 2004 21:09:19 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx with esmtp (Exim 4.12) id 1BG6Dw-0005L1-00 for tcpm@ietf.org; Tue, 20 Apr 2004 21:08:24 -0400 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id i3L17tSt008497; Wed, 21 Apr 2004 01:07:55 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Tue, 20 Apr 2004 21:07:55 -0400 Message-ID: From: "Peterson, Jon" To: Joe Touch Cc: tcpm@ietf.org Subject: Re: [tcpm] new work item: TCP security issue Date: Tue, 20 Apr 2004 21:07:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Just to be clear about why this happened, Mark and Ted are not to blame for this document appearing as an Internet-Draft with a WG-item title. We (the Area Directors) specifically requested that the secretariat publish it in this form, in consultation with the WG chairs, some other ADs and members of the IAB. The responsibility is ours. Your concern about the abuse of process is understandable, and I hope it is obvious that it was only the urgency of progressing this work which prompted us to take an action which, as you rightfully assert, we have no legitimate process grounds for taking. But before we go through the exercise of resubmitting this document as an individual submission, assessing consensus, and then potentially resubmitting this document as a working group item, can I ask if anyone here objects to the adoption of this draft as a working group item (on anything other than process grounds)? Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU] > Sent: Tuesday, April 20, 2004 3:14 PM > To: mallman@icir.org > Cc: tcpm@ietf.org; Ted Faber > Subject: Re: [tcpm] new work item: TCP security issue > > > > > Mark Allman wrote: > > > Just announced internet-draft: > > > >> Title : Transmission Control Protocol security > considerations > >> Author(s) : R. Stewart > >> Filename : draft-ietf-tcpm-tcpsecure-00.txt > >> Pages : 10 > >> Date : 2004-4-20 > >> > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt > > > > > > Hi folks! > > > > We wanted to announce a new I-D and TCPM work item. The draft is > > "Transmission Control Protocol security considerations" > > (draft-ietf-tcpm-tcpsecure-00.txt). We believe we owe a > bit in the way > > of explanation since it seems that this is being foisted upon the WG > > without much input. > > > > The brief story is that a bunch of folks were made aware of the TCP > > security vulnerability outlined in the above draft. (I think many > > people have been aware of these things for a long time. > But, the driver > > here is that there is a new conference paper that is going > to show the > > ease with which the vulnerability can be exploited.) Many > people from a > > number of TCP implementers (vendors) have been busily > working behind the > > scenes to come up with reasonable fixes before the vulnerability was > > announced. The fixes are in the I-D. The vulnerability has been > > announced (via the standard security issues venues). As > part of this > > process Randall Stewart wrote the above mentioned I-D for this WG to > > ponder. > > > > A few notes since this I-D got adopted as a WG item with > zero public / > > open input: > > Mark, > > Er, well. Let's talk about that. Last I checked, we rejected kings, > which includes input of this sort from the top down. > > This draft should be withdrawn and resubmitted as individual > immediately, since it is NOT YET a WG doc - not until _we_ start the > process. The _WG_ - not the IAB, not the IESG, etc. - should > decide for > ourselves whether we want the individual item (after we READ > it) as a WG > item. > > Also, temporal order is important - i.e., 'it's a WG doc if the > IESG/chair decide and THEN we get to nix it'. This is a bottom-up > process. _THEN_ the hierarchy gets to decide whether we can > work on it. > Not the other way around. > > (FWIW, I would concur that this should be a WG doc anyway; this isn't > about the doc, it's about the recurring abuse of process). > > Joe > > > > > * Until the vulnerability was announced we didn't want to > entertain a > > huge discussion on the public mailing list for obvious reasons. > > > > * The transport ADs, security ADs and TCPM WG chairs all > agreed that > > this is an important problem to address and that TCPM > is the correct > > WG in which to address it. That said, if folks think > we made the > > wrong call here, please feel free to speak up and tell us why we > > screwed up. > > > > * The fixes suggested in the above I-D are not being pre-judged as > > *THE* answer. Rather, they represent *A POSSIBLE* solution (and > > running code) that this WG will consider. In other > words, we are > > not trying to simply ram this document through the WG > and produce an > > RFC. This WG will deliberate on the I-D as it would any other. > > > > * Alternate solutions are welcome. We would like to > encourage folks > > who have different solutions to the problems outlined > in the draft > > to put those forward for consideration. > > > > Any other comments folks have on this draft / issue are > very welcome. > > > > Thanks! > > > > Mark & Ted > > > > > > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Apr 20 22:03:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15317 for ; Tue, 20 Apr 2004 22:03:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG6vg-0006E2-IS for tcpm-archive@odin.ietf.org; Tue, 20 Apr 2004 21:53:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L1rass023925 for tcpm-archive@odin.ietf.org; Tue, 20 Apr 2004 21:53:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG6sK-0004X8-LJ for tcpm-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 21:50:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14674 for ; Tue, 20 Apr 2004 21:50:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG6sH-0000tS-Np for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 21:50:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG6rO-0000kp-00 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 21:49:11 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BG6pr-0000ZL-01 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 21:47:35 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BG6aA-0005wN-F6 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 21:31:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG6Wv-0003jA-SV; Tue, 20 Apr 2004 21:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG6Md-0007YK-Vx for tcpm@optimus.ietf.org; Tue, 20 Apr 2004 21:17:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13155 for ; Tue, 20 Apr 2004 21:17:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG6Mb-00064J-Bj for tcpm@ietf.org; Tue, 20 Apr 2004 21:17:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG6Li-0005zb-00 for tcpm@ietf.org; Tue, 20 Apr 2004 21:16:26 -0400 Received: from [131.227.76.5] (helo=prue.eim.surrey.ac.uk ident=exim) by ietf-mx with esmtp (Exim 4.12) id 1BG6Ks-0005vb-00 for tcpm@ietf.org; Tue, 20 Apr 2004 21:15:35 -0400 Received: from argos.ee.surrey.ac.uk ([131.227.89.15] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 1BG6KE-0007Oz-00; Wed, 21 Apr 2004 02:14:55 +0100 Date: Wed, 21 Apr 2004 02:14:53 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@argos.ee.surrey.ac.uk To: Joe Touch cc: mallman@icir.org, "" , Ted Faber Subject: Re: [tcpm] new work item: TCP security issue In-Reply-To: <4085C41C.7000004@isi.edu> Message-ID: References: <20040421002749.9023477A9EB@guns.icir.org> <4085C41C.7000004@isi.edu> Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *1BG6KE-0007Oz-00*/vaP0NXq28U* (SECM, UniS) Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Tue, 20 Apr 2004, Joe Touch wrote: > That smacked of the IESG deciding what was important for the WG; this > does to. From where I sit, as Jose Wales said, "Don't piss down my back > and tell me it's raining" (to continue the scatology). Fletcher (John Vernon) said THAT - to the Senator. Josey Wales did not. what's in a (draft) name? L. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Apr 20 22:05:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15416 for ; Tue, 20 Apr 2004 22:05:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG760-0001jG-KR for tcpm-archive@odin.ietf.org; Tue, 20 Apr 2004 22:04:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L24G3A006637 for tcpm-archive@odin.ietf.org; Tue, 20 Apr 2004 22:04:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG6wa-0006cq-7j for tcpm-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 21:54:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14922 for ; Tue, 20 Apr 2004 21:54:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG6wX-0001Lm-B0 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 21:54:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG6ve-0001H0-00 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 21:53:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG6vD-0001BS-00 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 21:53:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG6mS-0001en-1z; Tue, 20 Apr 2004 21:44:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG6dC-0006kS-45 for tcpm@optimus.ietf.org; Tue, 20 Apr 2004 21:34:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14224 for ; Tue, 20 Apr 2004 21:34:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG6d9-0007WG-Bq for tcpm@ietf.org; Tue, 20 Apr 2004 21:34:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG6cH-0007SM-00 for tcpm@ietf.org; Tue, 20 Apr 2004 21:33:34 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BG6bn-0007Nn-00 for tcpm@ietf.org; Tue, 20 Apr 2004 21:33:04 -0400 Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3L1W9N20689; Tue, 20 Apr 2004 18:32:09 -0700 (PDT) Message-ID: <4085CF19.6030901@isi.edu> Date: Tue, 20 Apr 2004 18:32:09 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: mallman@icir.org, tcpm@ietf.org, Ted Faber Subject: Re: [tcpm] new work item: TCP security issue References: <20040420200340.E690777A9EB@guns.icir.org> <4085A097.1060108@isi.edu> In-Reply-To: <4085A097.1060108@isi.edu> X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig327535CB3A47425AA4065671" X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig327535CB3A47425AA4065671 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit A clarification, in case it was ambiguous: Joe Touch wrote: > Mark Allman wrote: > >> Just announced internet-draft: >> >>> Title : Transmission Control Protocol security considerations >>> Author(s) : R. Stewart >>> Filename : draft-ietf-tcpm-tcpsecure-00.txt >>> Pages : 10 >>> Date : 2004-4-20 >>> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt ... > (FWIW, I would concur that this should be a WG doc anyway; this isn't > about the doc, it's about the recurring abuse of process). By "recurring" I am referring to other actions by the IESG and other WG chairs, some of which are addressed in the process update revisions already underway. I am not referring to either Mark or Ted, in case that was not clear. Joe --------------enig327535CB3A47425AA4065671 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAhc8dE5f5cImnZrsRAltVAKDA1QA30TyelSQWES7FTYCThhL6pQCgkK8r uCT29Ht1W/I1Ig3YdEw51No= =w5Xv -----END PGP SIGNATURE----- --------------enig327535CB3A47425AA4065671-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Apr 20 22:35:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16923 for ; Tue, 20 Apr 2004 22:35:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG7TL-0003MA-T2 for tcpm-archive@odin.ietf.org; Tue, 20 Apr 2004 22:28:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L2SN7a012894 for tcpm-archive@odin.ietf.org; Tue, 20 Apr 2004 22:28:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG7E8-000681-9p for tcpm-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 22:12:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15851 for ; Tue, 20 Apr 2004 22:12:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG7E5-000342-9w for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 22:12:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG7DA-0002xt-00 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 22:11:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG7Cc-0002r7-00 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 22:11:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG76n-0002Wv-CP; Tue, 20 Apr 2004 22:05:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG73U-0000eD-Ou for tcpm@optimus.ietf.org; Tue, 20 Apr 2004 22:01:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15172 for ; Tue, 20 Apr 2004 22:01:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG73R-0001v9-Of for tcpm@ietf.org; Tue, 20 Apr 2004 22:01:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG72I-0001pE-00 for tcpm@ietf.org; Tue, 20 Apr 2004 22:00:27 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BG71Y-0001kt-00 for tcpm@ietf.org; Tue, 20 Apr 2004 21:59:40 -0400 Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3L1wbN25790; Tue, 20 Apr 2004 18:58:37 -0700 (PDT) Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.12.10/8.12.10) with ESMTP id i3L1waIx013857; Tue, 20 Apr 2004 18:58:36 -0700 (PDT) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.12.10/8.12.10/Submit) id i3L1wVa7013856; Tue, 20 Apr 2004 18:58:31 -0700 (PDT) (envelope-from faber) Date: Tue, 20 Apr 2004 18:58:31 -0700 From: Ted Faber To: "Peterson, Jon" Cc: Joe Touch , tcpm@ietf.org Subject: Re: [tcpm] new work item: TCP security issue Message-ID: <20040421015831.GK9795@pun.isi.edu> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yaPAUYI/0vT2YKpA" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: faber@isi.edu Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --yaPAUYI/0vT2YKpA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Apr 20, 2004 at 09:07:53PM -0400, Peterson, Jon wrote: > > Just to be clear about why this happened, Mark and Ted are not to blame for > this document appearing as an Internet-Draft with a WG-item title. We (the > Area Directors) specifically requested that the secretariat publish it in > this form, in consultation with the WG chairs, some other ADs and members of > the IAB. The responsibility is ours. Thanks, Jon, but while it was clear that the ADs wanted the draft published with a tcpm in the file name, I certainly agreed that there was no harm in publishing the draft with the name it has. I only agreed to that because it was very obviously work completely in line with the tcpm charter, there was a need to keep the draft under wraps until publication, and that there was an easy path for the WG to repidiate the unilateral position and drop the work item if all concerned turned out to be wrong. As I think Mark has stated clearly, we percieved these circumstances to be well out of the ordinary. Once we decided to take those actions, we presented the actions and the motives immediately to the WG. There is no hidden adgenda here. I don't believe that this action goes against the spirit of the WG process, but it did shortcut the letter. I certainly do not expect this to be standard operating procedure. I don't believe that any harm was done by this particular shortcut, but conditions will need to be extreme for me to take it again. And while I appreciate Jon's clarification, I don't hide from the consequences of my role in the decision here. As I've said to Joe privately, if the WG believes that this demonstrates that I'm unfit to act as WG chair, I'll resign. I'm hoping that the group will let me off with only a cut in pay. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG --yaPAUYI/0vT2YKpA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAhdVHaUz3f+Zf+XsRAnSUAKCFs7jjc8F2skBI2mKTP8NNrtVztwCg+nKs WQkhsVhaCRLbd4lIN44+kYE= =TlNu -----END PGP SIGNATURE----- --yaPAUYI/0vT2YKpA-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Apr 20 23:06:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18236 for ; Tue, 20 Apr 2004 23:06:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG7yv-0008Je-TJ for tcpm-archive@odin.ietf.org; Tue, 20 Apr 2004 23:01:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L311gP031957 for tcpm-archive@odin.ietf.org; Tue, 20 Apr 2004 23:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG7rc-00058i-0o for tcpm-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 22:53:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17674 for ; Tue, 20 Apr 2004 22:53:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG7rY-0006m0-GX for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 22:53:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG7qd-0006fe-00 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 22:52:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG7pj-0006Yx-00 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 22:51:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG7ec-0000o7-9v; Tue, 20 Apr 2004 22:40:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG7c3-0007W5-Fo for tcpm@optimus.ietf.org; Tue, 20 Apr 2004 22:37:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17002 for ; Tue, 20 Apr 2004 22:37:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG7c0-0005L3-3g for tcpm@ietf.org; Tue, 20 Apr 2004 22:37:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG7b1-0005FF-00 for tcpm@ietf.org; Tue, 20 Apr 2004 22:36:20 -0400 Received: from dsl092-066-146.bos1.dsl.speakeasy.net ([66.92.66.146] helo=alva.home) by ietf-mx with esmtp (Exim 4.12) id 1BG7a3-000575-00 for tcpm@ietf.org; Tue, 20 Apr 2004 22:35:19 -0400 Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1BG7ZZ-0004Kn-00 for ; Tue, 20 Apr 2004 22:34:49 -0400 From: Tim Shepard To: tcpm@ietf.org Date: Tue, 20 Apr 2004 22:34:49 -0400 Message-Id: Subject: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I just gave draft-ietf-tcpm-tcpsecure-00.txt a quick read. It seems to me this is not something we need to be worried about. An attacker not only needs to manage to have a sequence number land inside a range of TCP sequence number space, the attacker needs to know the two 16-bit port numbers of the TCP connection involved, and the two 32-bit IPv4 addresses, i.e. the attacker needs to somehow be aware of the existance of the TCP connection. If the attacker cannot see the traffic (spy on the net somewhere between the two endpoints of the TCP connection), then most all TCP connections will not be vulnerable simply because they are hiding in a very large space. If there are well-known long-lived TCP connections (where both IP addresses and one (or both) of the port numbers are well known) then maybe there is a problem, and perhaps the draft should explain that situation explicitly. If both port numbers are predictable, then perhaps implementations should pick a (good) random port number to come from, adding a 2^16 factor to the size of the search space for an attacker. If the attacker is spying on the net and seeing the packets go by, then the "solutions" proposed in this draft will not be of any help. Solution: Either protect the links and routers along the path to make spying more difficult, or deploy end-to-end encryption using some sort of tunnel (e.g. tunnel mode IPsec ESP) or transport mode IPsec ESP. -Tim Shepard shep@alum.mit.edu _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Apr 20 23:11:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18480 for ; Tue, 20 Apr 2004 23:11:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG84t-0002rG-PP for tcpm-archive@odin.ietf.org; Tue, 20 Apr 2004 23:07:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L37BpE010982 for tcpm-archive@odin.ietf.org; Tue, 20 Apr 2004 23:07:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG80I-0000mC-3e for tcpm-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 23:02:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18090 for ; Tue, 20 Apr 2004 23:02:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG80E-0007ZJ-MI for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 23:02:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG7zH-0007Sy-00 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 23:01:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG7yO-0007N9-00 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 23:00:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG7rD-0004rg-95; Tue, 20 Apr 2004 22:53:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG7jp-0002Zn-2V for tcpm@optimus.ietf.org; Tue, 20 Apr 2004 22:45:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17354 for ; Tue, 20 Apr 2004 22:45:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG7jl-00061W-Lq for tcpm@ietf.org; Tue, 20 Apr 2004 22:45:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG7is-0005xT-00 for tcpm@ietf.org; Tue, 20 Apr 2004 22:44:27 -0400 Received: from bay2-f166.bay2.hotmail.com ([65.54.247.166] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BG7iI-0005sQ-00 for tcpm@ietf.org; Tue, 20 Apr 2004 22:43:50 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 20 Apr 2004 19:43:21 -0700 Received: from 131.107.3.70 by by2fd.bay2.hotmail.msn.com with HTTP; Wed, 21 Apr 2004 02:43:20 GMT X-Originating-IP: [131.107.3.70] X-Originating-Email: [skaniyar@hotmail.com] X-Sender: skaniyar@hotmail.com From: "sanjay kaniyar" To: rrs@cisco.com Cc: tcpm@ietf.org Subject: RE: [tcpm] I-D ACTION:draft-ietf-tcpm-tcpsecure-00.txt Date: Tue, 20 Apr 2004 19:43:20 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Apr 2004 02:43:21.0061 (UTC) FILETIME=[68AF7950:01C4274A] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id WAA17355 Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello, I read through the draft and there might be an issue with how it deals wi= th=20 one of the reconnect cases. My question is outlined below: ------------------------------------------------------------------------ Let's consider the case where we have server[S] implementing this draft and a client[C] which is trying to connect to it and the ISS chosen by the client happens to be the same as the next expected sequence number on server. [S] Sitting in established state. RcvNxt =3D x SndUna =3D SndNxt =3D SndMax =3D y [C] comes up after a reboot, tries to reconnect to [S] (chooses the same 4-tuple) ISS =3D x Sends a SYN (seq =3D x, Ack =3D invalid) Follwing 3.2 (B), [S] sends back an ACK If the SYN bit is set and the sequence number is an exact match to the next expected sequence (RCV.NXT =3D=3D SEG.SEQ) then send an AC= K segment to the peer but before sending the ACK segment subtract one from value being acknowledged. [S] -> [C], ACK (seq =3D y, Ack =3D x) The segment reaches the client. [C] follows RFC 793 - and does the following: If the state is SYN-SENT then first check the ACK bit If the ACK bit is set If SEG.ACK =3D< ISS, or SEG.ACK > SND.NXT, send a reset (unless the RST bit is set, if so drop the segment and return) and discard the segment. Return. [C] -> [S], RST (seq =3D x, Ack =3D invalid) The Reset reaches the server: [S] follows (either 793 or the draft 2.2 [A]): A) If the RST bit is set and the sequence number is outside the expected window, silently drop the segment. .. and drops the RST. The client might/will retry a few times - but each time the sequence of events is the same - and this results in a valid connect attempt from succeeding - which would not have happened had the server followed RFC 79= 3 processing rules. My suggestion would be to abort the connection at [S] when ISS =3D=3D Rcv= Nxt. That would take care of this problem while not being any easier to exploi= t than just sending a RST is. Thanks, Sanjay _________________________________________________________________ Get rid of annoying pop-up ads with the new MSN Toolbar =96 FREE!=20 http://toolbar.msn.com/go/onm00200414ave/direct/01/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Apr 20 23:18:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18983 for ; Tue, 20 Apr 2004 23:18:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG8Cp-0006On-Bg for tcpm-archive@odin.ietf.org; Tue, 20 Apr 2004 23:15:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L3FNXs024589 for tcpm-archive@odin.ietf.org; Tue, 20 Apr 2004 23:15:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG89L-0004tv-Bn for tcpm-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 23:11:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18461 for ; Tue, 20 Apr 2004 23:11:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG89H-0000Vj-Kb for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 23:11:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG86j-0000IA-00 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 23:09:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG84f-00005P-00 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 23:06:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG7zx-0000hR-Qo; Tue, 20 Apr 2004 23:02:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG7wx-0007Zn-O1 for tcpm@optimus.ietf.org; Tue, 20 Apr 2004 22:58:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17920 for ; Tue, 20 Apr 2004 22:58:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG7wu-0007DZ-6l for tcpm@ietf.org; Tue, 20 Apr 2004 22:58:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG7vk-00076z-00 for tcpm@ietf.org; Tue, 20 Apr 2004 22:57:45 -0400 Received: from dsl092-066-146.bos1.dsl.speakeasy.net ([66.92.66.146] helo=alva.home) by ietf-mx with esmtp (Exim 4.12) id 1BG7v8-00070O-00 for tcpm@ietf.org; Tue, 20 Apr 2004 22:57:07 -0400 Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1BG7uK-0004Lf-00; Tue, 20 Apr 2004 22:56:16 -0400 From: Tim Shepard To: "Peterson, Jon" cc: Joe Touch , tcpm@ietf.org Subject: Re: [tcpm] new work item: TCP security issue In-reply-to: Your message of Tue, 20 Apr 2004 21:07:53 -0400. Date: Tue, 20 Apr 2004 22:56:16 -0400 Message-Id: Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 > Your concern about the abuse of process is understandable, and I hope it is > obvious that it was only the urgency of progressing this work which prompted > us to take an action which, as you rightfully assert, we have no legitimate > process grounds for taking. I must be missing something. Could someone please explain why this is urgent? (I've read the draft once, and I'm reading it again now, and I don't see why this would be considered urgent.) Has the stuff needed for me to understand why this is urgent been deliberately omitted from the draft (to avoid revealing something to the black hats)? -Tim Shepard shep@alum.mit.edu _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Apr 20 23:27:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19520 for ; Tue, 20 Apr 2004 23:27:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG8Ei-0007Lw-57 for tcpm-archive@odin.ietf.org; Tue, 20 Apr 2004 23:17:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L3HKoh028245 for tcpm-archive@odin.ietf.org; Tue, 20 Apr 2004 23:17:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG8B5-0005cj-EU for tcpm-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 23:13:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18642 for ; Tue, 20 Apr 2004 23:13:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG8B3-0000kf-8b for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 23:13:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG89z-0000cS-00 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 23:12:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG88V-0000Qz-00 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 23:10:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG84l-0002pb-Il; Tue, 20 Apr 2004 23:07:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG7zS-0008MD-O0 for tcpm@optimus.ietf.org; Tue, 20 Apr 2004 23:01:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18068 for ; Tue, 20 Apr 2004 23:01:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG7zP-0007Tx-6k for tcpm@ietf.org; Tue, 20 Apr 2004 23:01:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG7yV-0007OC-00 for tcpm@ietf.org; Tue, 20 Apr 2004 23:00:36 -0400 Received: from [207.68.165.18] (helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BG7xu-0007Hk-00 for tcpm@ietf.org; Tue, 20 Apr 2004 22:59:58 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 20 Apr 2004 19:59:25 -0700 Received: from 203.125.146.186 by sea2fd.sea2.hotmail.msn.com with HTTP; Wed, 21 Apr 2004 02:59:25 GMT X-Originating-IP: [203.125.146.186] X-Originating-Email: [sk_list@hotmail.com] X-Sender: sk_list@hotmail.com From: "S K" To: tcpm@ietf.org Subject: RE: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt Date: Wed, 21 Apr 2004 10:59:25 +0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Apr 2004 02:59:25.0827 (UTC) FILETIME=[A7BB1530:01C4274C] Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi, I am a bit confused as to how Section 2.2 solution (C) in http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt will prevent the blind RST attack. If the attacker is within the 'snoopable' network of the victim, he can answer to the extra ACK that is produced, just like in the case of the SYN flood. Am I missing something (looks like I am :)) ? _________________________________________________________________ Find gifts, buy online with MSN Shopping. http://shopping.msn.com.sg/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Apr 20 23:29:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19627 for ; Tue, 20 Apr 2004 23:29:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG8PR-0003Ei-Kb for tcpm-archive@odin.ietf.org; Tue, 20 Apr 2004 23:28:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L3SPrS012436 for tcpm-archive@odin.ietf.org; Tue, 20 Apr 2004 23:28:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG8Fw-0007zr-M0 for tcpm-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 23:18:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18974 for ; Tue, 20 Apr 2004 23:18:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG8Fu-0001Fr-O7 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 23:18:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG8Ez-00019W-00 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 23:17:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG8Dy-00014A-00 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 23:16:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG89Z-00059C-9s; Tue, 20 Apr 2004 23:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG84v-0002rn-EB for tcpm@optimus.ietf.org; Tue, 20 Apr 2004 23:07:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18302 for ; Tue, 20 Apr 2004 23:07:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG84q-00005r-Ky for tcpm@ietf.org; Tue, 20 Apr 2004 23:07:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG83T-0007nf-00 for tcpm@ietf.org; Tue, 20 Apr 2004 23:05:45 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx with esmtp (Exim 4.12) id 1BG82h-0007hv-00 for tcpm@ietf.org; Tue, 20 Apr 2004 23:04:55 -0400 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id i3L34KSt014745; Wed, 21 Apr 2004 03:04:20 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Tue, 20 Apr 2004 23:04:20 -0400 Message-ID: From: "Peterson, Jon" To: "'Tim Shepard'" Cc: Joe Touch , tcpm@ietf.org Subject: RE: [tcpm] new work item: TCP security issue Date: Tue, 20 Apr 2004 23:04:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 One specific protocol for which this is a concern is discussed here: http://www.us-cert.gov/cas/techalerts/TA04-111A.html I will note that exploits for this vulnerability are already known to be circulating in "black hat" circles. You may also have noticed that the press has demonstrated some interested in this today; there is much more speculation about the potential applicability of this vulnerability to be found there. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Tim Shepard [mailto:shep@alum.mit.edu] > Sent: Tuesday, April 20, 2004 7:56 PM > To: Peterson, Jon > Cc: Joe Touch; tcpm@ietf.org > Subject: Re: [tcpm] new work item: TCP security issue > > > > > Your concern about the abuse of process is understandable, > and I hope it is > > obvious that it was only the urgency of progressing this > work which prompted > > us to take an action which, as you rightfully assert, we > have no legitimate > > process grounds for taking. > > > I must be missing something. Could someone please explain why this > is urgent? (I've read the draft once, and I'm reading it again now, > and I don't see why this would be considered urgent.) > > Has the stuff needed for me to understand why this is urgent been > deliberately omitted from the draft (to avoid revealing something to > the black hats)? > > > -Tim Shepard > shep@alum.mit.edu > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Apr 20 23:47:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20296 for ; Tue, 20 Apr 2004 23:47:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG8ff-00019B-SH for tcpm-archive@odin.ietf.org; Tue, 20 Apr 2004 23:45:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L3jBtr004405 for tcpm-archive@odin.ietf.org; Tue, 20 Apr 2004 23:45:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG8QW-0003nn-OS for tcpm-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 23:29:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19609 for ; Tue, 20 Apr 2004 23:29:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG8QU-0002Go-R6 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 23:29:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG8PX-0002B9-00 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 23:28:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG8Ot-00026J-00 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 23:27:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG8FO-0007ko-Do; Tue, 20 Apr 2004 23:18:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG8AA-0005AE-A6 for tcpm@optimus.ietf.org; Tue, 20 Apr 2004 23:12:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18594 for ; Tue, 20 Apr 2004 23:12:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG8A8-0000eT-AC for tcpm@ietf.org; Tue, 20 Apr 2004 23:12:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG88v-0000SK-00 for tcpm@ietf.org; Tue, 20 Apr 2004 23:11:25 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BG86R-0000Gh-00 for tcpm@ietf.org; Tue, 20 Apr 2004 23:08:47 -0400 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BG86O-00020z-Kz; Wed, 21 Apr 2004 03:08:44 +0000 To: Tim Shepard cc: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt In-Reply-To: Message from Tim Shepard of "Tue, 20 Apr 2004 22:34:49 EDT." Date: Tue, 20 Apr 2004 20:08:44 -0700 From: Allison Mankin Message-Id: Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,WEIRD_PORT autolearn=no version=2.60 Hi, Tim, I agree the draft should mention the point about ports and addresses. Below is an interesting mail from nanog showing how addresses and ports can be found. Another nanog message mentioned that some router vendors limit the TCP port range. There is also some nanog chat about seeing scanners. Allison ----- Subject: tcp bgp vulnerability looking glass and route server issues. Date: Tue, 20 Apr 2004 14:38:18 -0600 From: "Smith, Donald" To: John Fraizer author of MRLG one of the looking glass implementations has updated his code to fix a flaw that provided too much information. MRLG-4.3.0 is available at: Available here: ftp://ftp.enterzone.net/looking-glass/CURRENT/ Some route servers also provide too much info. This audit was performed yesterday so if you have already fixed this issue please ignore:-) Part of this issue is the fact that some router servers provide too much information. Without knowing the source/destination ports and IP's this is still a difficult vulnerability to exploit. >From this URL I did a quick audit. http://www.traceroute.org/#Route%20Servers I did NOT look at the looking glass URLs just the route servers. This is the list of open route servers I did a quick audit on. No connection means I was unable to connect to it. Not misconfigured meant sho ip bgp nei did NOT work. Sho ip bgp nei gives full ports/ips means what you think it means. You have may want to see if any of them are yours of20 if you peer / are the upstream for any of them. "Route Servers" "telnet://ner-routes.bbnplanet.net" BBN Planet NER route monitor20 No connection "telnet://route-server.belwue.de" BelWue (AS553) Sho ip bgp nei gives full ports/ips. "telnet://route-views.on.bb.telus.com">Telus - East Coast (AS852) Sho ip bgp nei gives full ports/ips. telnet://route-views.ab.bb.telus.com" Telus - West Coast (AS852) Sho ip bgp nei gives full ports/ips. "telnet://route-server.cerf.net">CerfNet Route Server (AS1838) Sho ip bgp nei gives full ports/ips. "telnet://route-server.ip.tiscali.net">Tiscali (AS3257) Sho ip bgp nei gives full ports/ips. "telnet://route-server.gblx.net">Global Crossing (AS3549) Not misconfigured:-) "telnet://route-server.savvis.net/">SAVVIS Communications (AS3561) Sho ip bgp nei gives full ports/ips. "telnet://public-route-server.is.co.za" TARGET3DNEW>Internet Solutions (AS3741) Sho ip bgp nei gives full ports/ips. "telnet://route-server-ap.exodus.net">Exodus Communications Asia (AS4197) No connection "telnet://route-server.as5388.net">Planet Online (AS5388) Sho ip bgp nei gives full ports/ips. "telnet://route-server.opentransit.net">Opentransit (AS5511) Not misconfigured:-) "telnet://tpr-route-server.saix.net">South African Internet eXchange SAIX (AS5713) Not misconfigure:-) "telnet://route-server.gt.ca">GT Group Telecom (AS6539) Sho ip bgp nei gives full ports/ips. "telnet://route-server.as6667.net">EUNet Finland (AS6667) Sho ip bgp nei gives full ports/ips. "telnet://route-server.he.net">Hurricane Electric (AS6939) Sho ip bgp nei gives full ports/ips. "telnet://route-server.ip.att.net">AT&T (AS7018) No connection "telnet://route-views.optus.net.au">Optus Route Server Australia (AS7474) Sho ip bgp nei gives full ports/ips. "telnet://route-server.wcg.net">Wiltel (AS7911) Sho ip bgp nei gives full ports/ips. "telnet://route-server.colt.net">Colt Internet (AS8220) Sho ip bgp nei gives full ports/ips. "telnet://route-server-eu.exodus.net">Exodus Communications Europe (AS8709) No connection "telnet://route-views.bmcag.net">Broadnet mediascape communications AG (AS9132) Not misconfigured:-) "telnet://route-server-au.exodus.net">Exodus Communications Australia (AS9328) No connection "telnet://route-server.manilaix.net.ph">Manila Internet Exchange, Philippines (AS9670) Sho ip bgp nei gives full ports/ips. "telnet://route-server.east.attcanada.com">ATT Canada - East (AS15290) Sho ip bgp nei gives full ports/ips. "telnet://route-server.west.attcanada.com">ATT Canada - West (AS15290) Sho ip bgp nei gives full ports/ips. "telnet://route-server.ip.ndsoftware.net">NDSoftware (AS25358) Sho ip bgp nei gives full ports/ips. "telnet://route-server.loudpacket.net">Loud Packet (AS27276) No connection. "telnet://route-server.as28747.net/">RealROOT (AS28747) No connection "telnet://route-views.oregon-ix.net">Oregon-ix.net Route Server Sho ip bgp nei appears it WOULD provide full ports/ips if they had any? The command executed but came back empty!!?? This one can be used as a proxy bounce (connect ip port) too:-( "telnet://route-server.utah.rep.net">Utah Regional Exchange Point Route Server Sho ip bgp nei gives full ports/ips. "telnet://www.netlantis.org">The NetLantis Project Route Server Not misconfigured. http://pgp.mit.edu:11371/pks/lookup?op3Dget&search3D0xAF00EDCC pgpFingerPrint:9CE4 227B B9B3 601F B500 D076 43F1 0767 AF00 EDCC Increased trust is received by not violating the trust you have received. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 00:00:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21067 for ; Wed, 21 Apr 2004 00:00:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG8tT-0007i0-5F for tcpm-archive@odin.ietf.org; Tue, 20 Apr 2004 23:59:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L3xRhA029626 for tcpm-archive@odin.ietf.org; Tue, 20 Apr 2004 23:59:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG8hB-00024B-06 for tcpm-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 23:46:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20251 for ; Tue, 20 Apr 2004 23:46:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG8h8-0003hU-QF for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 23:46:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG8g4-0003ZD-00 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 23:45:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG8fI-0003TT-00 for tcpm-web-archive@ietf.org; Tue, 20 Apr 2004 23:44:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG8Q2-0003mi-ND; Tue, 20 Apr 2004 23:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG8Lb-000187-Vi for tcpm@optimus.ietf.org; Tue, 20 Apr 2004 23:24:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19366 for ; Tue, 20 Apr 2004 23:24:25 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG8La-0001oM-22 for tcpm@ietf.org; Tue, 20 Apr 2004 23:24:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG8Km-0001jw-00 for tcpm@ietf.org; Tue, 20 Apr 2004 23:23:37 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BG8Jz-0001eZ-00 for tcpm@ietf.org; Tue, 20 Apr 2004 23:22:47 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3L3J1O00313; Wed, 21 Apr 2004 06:19:01 +0300 (EET DST) X-Scanned: Wed, 21 Apr 2004 06:18:36 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3L3Ia4h020874; Wed, 21 Apr 2004 06:18:36 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00X1ZuYO; Wed, 21 Apr 2004 06:18:34 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3L3IWF18410; Wed, 21 Apr 2004 06:18:32 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 21 Apr 2004 06:18:34 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] new work item: TCP security issue Date: Wed, 21 Apr 2004 06:18:31 +0300 Message-ID: Thread-Topic: [tcpm] new work item: TCP security issue Thread-Index: AcQnIilZm9UX224vSIuIGcfYcnx2XwALO0uw To: , Cc: X-OriginalArrivalTime: 21 Apr 2004 03:18:34.0262 (UTC) FILETIME=[54405B60:01C4274F] Content-Transfer-Encoding: quoted-printable Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi all, > Just announced internet-draft: > > Title : Transmission Control Protocol security=20 > considerations > > Author(s) : R. Stewart > > Filename : draft-ietf-tcpm-tcpsecure-00.txt > > Pages : 10 > > Date : 2004-4-20 > > =20 > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt I support this being a working group document. However, rather than worrying about the name of the draft, I would imagine that getting comments / feedback on the draft is the more important part. Do the chairs plan to try to get feedback on the draft and progress the draft rather quickly? John _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 00:24:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22211 for ; Wed, 21 Apr 2004 00:24:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG9FP-0000Bo-1Y for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 00:22:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L4M7h4000722 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 00:22:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG9Bx-0007Hr-6R for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 00:18:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21808 for ; Wed, 21 Apr 2004 00:18:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG9Bu-0006hQ-Qp for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 00:18:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG9B1-0006cy-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 00:17:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG9Ak-0006YH-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 00:17:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG92m-0003wr-NK; Wed, 21 Apr 2004 00:09:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG8zJ-0001cV-LV for tcpm@optimus.ietf.org; Wed, 21 Apr 2004 00:05:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21350 for ; Wed, 21 Apr 2004 00:05:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG8zH-0005a6-Ag for tcpm@ietf.org; Wed, 21 Apr 2004 00:05:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG8yY-0005W3-00 for tcpm@ietf.org; Wed, 21 Apr 2004 00:04:43 -0400 Received: from dsl092-066-146.bos1.dsl.speakeasy.net ([66.92.66.146] helo=alva.home) by ietf-mx with esmtp (Exim 4.12) id 1BG8xv-0005PD-00 for tcpm@ietf.org; Wed, 21 Apr 2004 00:04:03 -0400 Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1BG8xQ-0004NY-00 for ; Wed, 21 Apr 2004 00:03:32 -0400 From: Tim Shepard To: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt Date: Wed, 21 Apr 2004 00:03:32 -0400 Message-Id: Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 OK. Many people have pointed me at the news about BGP sessions being long-lived and that the port numbers are exposed through publicly readable network management tools. (That explains the rather odd out-of-the-blue reference in the draft to the BGP MD5 security mechanism for TCP.) Anyway... Yep. That is a problem. But the draft itself mentions none of that, and fails to explain what real problem it is trying to solve. Whether or not this is the right place/way to be solving some problem is an interesting question. It was the mention of the urgency on the tcpm mailing list that got me to go read the draft. It was a false (or at least very misleading) alarm. Nothing in this version of the draft seems to be worthy of an urgent pointer. -Tim Shepard shep@alum.mit.edu _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 00:25:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22338 for ; Wed, 21 Apr 2004 00:25:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG9GN-0000jh-EH for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 00:23:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L4N702002821 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 00:23:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG9Dm-0007VL-Cq for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 00:20:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21859 for ; Wed, 21 Apr 2004 00:20:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG9Dk-0006uF-0A for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 00:20:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG9Cn-0006lZ-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 00:19:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG9Bt-0006hJ-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 00:18:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG92n-0003xB-L0; Wed, 21 Apr 2004 00:09:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG91E-0002jW-Rg for tcpm@optimus.ietf.org; Wed, 21 Apr 2004 00:07:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21393 for ; Wed, 21 Apr 2004 00:07:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG91C-0005im-F7 for tcpm@ietf.org; Wed, 21 Apr 2004 00:07:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG90H-0005ey-00 for tcpm@ietf.org; Wed, 21 Apr 2004 00:06:29 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx with esmtp (Exim 4.12) id 1BG8ze-0005ap-00 for tcpm@ietf.org; Wed, 21 Apr 2004 00:05:50 -0400 Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by wyvern.icir.org (8.12.9p1/8.12.8) with ESMTP id i3L45o7A023803; Tue, 20 Apr 2004 21:05:50 -0700 (PDT) (envelope-from mallman@icir.org) Received: from lawyers.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by guns.icir.org (Postfix) with ESMTP id 25F2477A6D5; Wed, 21 Apr 2004 00:05:48 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id A64A313B953; Wed, 21 Apr 2004 00:05:38 -0400 (EDT) To: john.loughney@nokia.com From: Mark Allman Reply-To: mallman@icir.org Cc: tcpm@ietf.org, faber@isi.edu Subject: Re: [tcpm] new work item: TCP security issue In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Bad to the Bone MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 21 Apr 2004 00:05:38 -0400 Message-Id: <20040421040538.A64A313B953@lawyers.icir.org> Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 --=-=-= Content-Type: text/plain > I support this being a working group document. However, rather than > worrying about the name of the draft, I would imagine that getting > comments / feedback on the draft is the more important part. Do the > chairs plan to try to get feedback on the draft and progress the draft > rather quickly? We welcome technical comments. We are always interested in timely comments. But, we do not have an apriori timeline that we have not revealed. As sketched in my first note today we are not pre-supposing that the ideas in the draft are even the best fixes. If everyone could read the drafts and send their comments to the list, that'd be great! allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin) iD8DBQFAhfMSWyrrWs4yIs4RAmgKAJ4oGwyg5jSxBvyLOgREnhyDtVqWdgCfd8HQ zQoOE+lZeBPSdTPvm9u2YVE= =QBD6 -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 00:56:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23816 for ; Wed, 21 Apr 2004 00:56:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG9kD-0005GS-4L for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 00:53:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L4rvnT020232 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 00:53:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG9jy-0004tH-PR for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 00:53:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23637 for ; Wed, 21 Apr 2004 00:53:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG9jw-0002Pp-6V for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 00:53:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG9ix-0002JK-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 00:52:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG9iH-0002DW-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 00:51:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG9Vo-0007sa-Q7; Wed, 21 Apr 2004 00:39:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG9RP-0005VR-Sh for tcpm@optimus.ietf.org; Wed, 21 Apr 2004 00:34:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22950 for ; Wed, 21 Apr 2004 00:34:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG9RN-0000jO-B3 for tcpm@ietf.org; Wed, 21 Apr 2004 00:34:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG9QU-0000dm-00 for tcpm@ietf.org; Wed, 21 Apr 2004 00:33:34 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BG9PX-0000Yq-00 for tcpm@ietf.org; Wed, 21 Apr 2004 00:32:35 -0400 Received: from isi.edu (lsanca1-ar42-4-61-183-026.lsanca1.dsl-verizon.net [4.61.183.26]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3L4VTN22180; Tue, 20 Apr 2004 21:31:29 -0700 (PDT) Message-ID: <4085F925.6010304@isi.edu> Date: Tue, 20 Apr 2004 21:31:33 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" CC: "'Tim Shepard'" , tcpm@ietf.org Subject: Re: [tcpm] new work item: TCP security issue References: In-Reply-To: X-Enigmail-Version: 0.83.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3BC5921C1EEBFA9BC0E5A60A" X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3BC5921C1EEBFA9BC0E5A60A Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Peterson, Jon wrote: > One specific protocol for which this is a concern is discussed here: > > http://www.us-cert.gov/cas/techalerts/TA04-111A.html And here: RFC 2385. Urgently. Nearly 6 years ago ;-) Joe > I will note that exploits for this vulnerability are already known to be > circulating in "black hat" circles. > > You may also have noticed that the press has demonstrated some interested in > this today; there is much more speculation about the potential applicability > of this vulnerability to be found there. > > Jon Peterson > NeuStar, Inc. > > >>-----Original Message----- >>From: Tim Shepard [mailto:shep@alum.mit.edu] >>Sent: Tuesday, April 20, 2004 7:56 PM >>To: Peterson, Jon >>Cc: Joe Touch; tcpm@ietf.org >>Subject: Re: [tcpm] new work item: TCP security issue >> >> >> >> >>>Your concern about the abuse of process is understandable, >> >>and I hope it is >> >>>obvious that it was only the urgency of progressing this >> >>work which prompted >> >>>us to take an action which, as you rightfully assert, we >> >>have no legitimate >> >>>process grounds for taking. >> >> >>I must be missing something. Could someone please explain why this >>is urgent? (I've read the draft once, and I'm reading it again now, >>and I don't see why this would be considered urgent.) >> >>Has the stuff needed for me to understand why this is urgent been >>deliberately omitted from the draft (to avoid revealing something to >>the black hats)? >> >> >> -Tim Shepard >> shep@alum.mit.edu >> --------------enig3BC5921C1EEBFA9BC0E5A60A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAhfkqE5f5cImnZrsRApnKAJ9QzpNwHXCmUXhiFhJ7gt+Vt0BYGACgvOh7 v/N9wD24hdurv6gocS+b5Eg= =cl7H -----END PGP SIGNATURE----- --------------enig3BC5921C1EEBFA9BC0E5A60A-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 01:03:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24121 for ; Wed, 21 Apr 2004 01:03:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG9sP-0000Ml-MP for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 01:02:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L52Psu001400 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 01:02:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG9l6-0005PU-9Y for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 00:54:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23702 for ; Wed, 21 Apr 2004 00:54:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG9l3-0002Ym-GL for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 00:54:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG9k0-0002Qe-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 00:53:45 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG9j7-0002Jx-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 00:52:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG9Vq-0007tA-Ds; Wed, 21 Apr 2004 00:39:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG9UQ-00077G-QZ for tcpm@optimus.ietf.org; Wed, 21 Apr 2004 00:37:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23090 for ; Wed, 21 Apr 2004 00:37:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG9UO-00011c-6l for tcpm@ietf.org; Wed, 21 Apr 2004 00:37:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG9TV-0000wE-00 for tcpm@ietf.org; Wed, 21 Apr 2004 00:36:42 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1BG9Sq-0000p1-00 for tcpm@ietf.org; Wed, 21 Apr 2004 00:36:00 -0400 Received: from ananth-u5.cisco.com (ananth-u5.cisco.com [128.107.162.225]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i3L4ZShF011256; Tue, 20 Apr 2004 21:35:28 -0700 (PDT) Date: Tue, 20 Apr 2004 21:35:28 -0700 (PDT) From: Anantha Ramaiah To: sanjay kaniyar cc: rrs@cisco.com, tcpm@ietf.org Subject: RE: [tcpm] I-D ACTION:draft-ietf-tcpm-tcpsecure-00.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Transfer-Encoding: QUOTED-PRINTABLE Sanjay, Randall can answer this but we thought about this case it is one of the *real corner cases* Good eye :) Actually B could be reworded as : C) If the SYN bit is set and the sequence number(isn) is one less then the next expected sequence (RCV.NXT) then send an ACK segment with the peer but subtracting one from RCV.NXT. to the peer. ie SEG.SEQ =3D (RCV.NXT - 1) By sending a ACK that is less than the RCV.NXT value in case of a spoofed segment the true peer will drop the ACK as an old duplicate. The restart case also gets satisfied and the reset would be sent back! Most of the TCP stacks treat (RCV.NXT - 1) as an RST of a keepalive packet and would accept that. Hmm.. we may have a corner case here in case if the RST gets dropped because of outside window. Also the suggestion of sending the RST for an exact match (SEG.SEQ =3D TCB.RCVNXT) was thought about, but the idea to squeeze as much as possible to make the attacker's life harder.. Probably needs more thought to address this corner case. Randall and Mitesh may have more comments here.. -Anantha On Tue, 20 Apr 2004, sanjay kaniyar wrote: > Hello, > > I read through the draft and there might be an issue with how it deals wi= th > one of the reconnect cases. My question is outlined below: > > ------------------------------------------------------------------------ > Let's consider the case where we have server[S] implementing this draft > and a client[C] which is trying to connect to it and the ISS chosen by > the client happens to be the same as the next expected sequence number > on server. > > [S] > Sitting in established state. > RcvNxt =3D x > SndUna =3D SndNxt =3D SndMax =3D y > > [C] > comes up after a reboot, > tries to reconnect to [S] (chooses the same 4-tuple) > ISS =3D x > Sends a SYN (seq =3D x, Ack =3D invalid) > > Follwing 3.2 (B), [S] sends back an ACK > > If the SYN bit is set and the sequence number is an exact match to > the next expected sequence (RCV.NXT =3D=3D SEG.SEQ) then send an AC= K > segment to the peer but before sending the ACK segment subtract > one from value being acknowledged. > > [S] -> [C], ACK (seq =3D y, Ack =3D x) > > The segment reaches the client. > > [C] follows RFC 793 - and does the following: > > If the state is SYN-SENT then > first check the ACK bit > If the ACK bit is set > If SEG.ACK =3D< ISS, or SEG.ACK > SND.NXT, send a reset (unless > the RST bit is set, if so drop the segment and return) > > and discard the segment. Return. > > [C] -> [S], RST (seq =3D x, Ack =3D invalid) > > The Reset reaches the server: > > [S] follows (either 793 or the draft 2.2 [A]): > > A) If the RST bit is set and the sequence number is outside the > expected window, silently drop the segment. > > .. and drops the RST. > > > The client might/will retry a few times - but each time the sequence of > events is the same - and this results in a valid connect attempt from > succeeding - which would not have happened had the server followed RFC 79= 3 > processing rules. > > My suggestion would be to abort the connection at [S] when ISS =3D=3D Rcv= Nxt. > That would take care of this problem while not being any easier to exploi= t > than just sending a RST is. > > Thanks, > Sanjay > > _________________________________________________________________ > Get rid of annoying pop-up ads with the new MSN Toolbar =96 FREE! > http://toolbar.msn.com/go/onm00200414ave/direct/01/ > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 01:43:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26770 for ; Wed, 21 Apr 2004 01:43:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGAR6-0007Fh-5X for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 01:38:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L5cGh7027872 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 01:38:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGAIg-0002xX-NN for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 01:29:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25964 for ; Wed, 21 Apr 2004 01:29:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGAId-0006Rq-NH for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 01:29:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGAHg-0006KN-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 01:28:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGAGs-0006DM-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 01:27:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGAEH-0001Jh-5M; Wed, 21 Apr 2004 01:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGA64-0005yn-Or for tcpm@optimus.ietf.org; Wed, 21 Apr 2004 01:16:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24582 for ; Wed, 21 Apr 2004 01:16:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGA61-0004Yt-QD for tcpm@ietf.org; Wed, 21 Apr 2004 01:16:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGA5F-0004UP-00 for tcpm@ietf.org; Wed, 21 Apr 2004 01:15:42 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGA4p-0004P6-00 for tcpm@ietf.org; Wed, 21 Apr 2004 01:15:15 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 20 Apr 2004 21:25:13 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3L5Ei7t026954; Tue, 20 Apr 2004 22:14:45 -0700 (PDT) Received: from irp-view8.cisco.com (irp-view8.cisco.com [171.70.65.145]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASH02726; Tue, 20 Apr 2004 22:13:57 -0700 (PDT) Date: Tue, 20 Apr 2004 22:14:43 -0700 (PDT) From: Mitesh Dalal To: S K cc: tcpm@ietf.org Subject: RE: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Wed, 21 Apr 2004, S K wrote: > Hi, > > I am a bit confused as to how Section 2.2 solution (C) in > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt > > will prevent the blind RST attack. If the attacker is within the > 'snoopable' network of the victim, he can answer to the extra ACK this fix is not targetted for an attacker who is sitting on the path between the peers, but a blind attacker outside of the path. Its a given that if an attacker is located on a path between 2 tcp peers he can clearly cause more havoc than this. thx Mitesh > that is produced, just like in the case of the SYN flood. > > Am I missing something (looks like I am :)) ? > > _________________________________________________________________ > Find gifts, buy online with MSN Shopping. http://shopping.msn.com.sg/ > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 03:02:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29247 for ; Wed, 21 Apr 2004 03:02:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGBZi-0003V5-Mb for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 02:51:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L6pEQl013451 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 02:51:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGBTj-0000lm-Be for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 02:45:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28080 for ; Wed, 21 Apr 2004 02:45:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGBTf-0007fV-HM for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 02:44:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGBST-0007NO-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 02:43:45 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGBRR-0007GP-01 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 02:42:41 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BGBOI-0000rg-6C for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 02:39:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGBI9-00045O-A0; Wed, 21 Apr 2004 02:33:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGBEi-0001vv-59 for tcpm@optimus.ietf.org; Wed, 21 Apr 2004 02:29:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24756 for ; Wed, 21 Apr 2004 02:29:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGBEe-0005mQ-GP for tcpm@ietf.org; Wed, 21 Apr 2004 02:29:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGBDf-0005cU-00 for tcpm@ietf.org; Wed, 21 Apr 2004 02:28:28 -0400 Received: from bay2-f114.bay2.hotmail.com ([65.54.247.114] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BGBCg-0005Ps-00 for tcpm@ietf.org; Wed, 21 Apr 2004 02:27:26 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 20 Apr 2004 23:26:57 -0700 Received: from 207.46.238.143 by by2fd.bay2.hotmail.msn.com with HTTP; Wed, 21 Apr 2004 06:26:57 GMT X-Originating-IP: [207.46.238.143] X-Originating-Email: [skaniyar@hotmail.com] X-Sender: skaniyar@hotmail.com From: "sanjay kaniyar" To: rrs@cisco.com Cc: tcpm@ietf.org Subject: RE: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt Date: Tue, 20 Apr 2004 23:26:57 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Apr 2004 06:26:57.0650 (UTC) FILETIME=[A5987D20:01C42769] Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Section [4.2]: An additional input check should be added to any incoming segment. The ACK value should be acceptable only if it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK < SND.NXT). The right edge of the acceptable ACK range should be SND.MAX actually. During the course of a retransmission, SND.NXT moves back and making that the right edge of the range would result in potentially dropping a lot of valid acknowledgements. Thanks, Sanjay _________________________________________________________________ From must-see cities to the best beaches, plan a getaway with the Spring Travel Guide! http://special.msn.com/local/springtravel.armx _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 03:32:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00587 for ; Wed, 21 Apr 2004 03:32:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGC98-0001Bg-FB for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 03:27:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L7Rofp004514 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 03:27:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGBzD-0005hu-HI for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 03:17:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00004 for ; Wed, 21 Apr 2004 03:17:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGBzB-0003Ku-CK for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 03:17:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGByF-0003ER-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 03:16:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGBxa-00037C-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 03:15:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGBo0-0000mj-UI; Wed, 21 Apr 2004 03:06:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGBkf-0007PC-MK for tcpm@optimus.ietf.org; Wed, 21 Apr 2004 03:02:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29225 for ; Wed, 21 Apr 2004 03:02:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGBkb-0001jT-Q0 for tcpm@ietf.org; Wed, 21 Apr 2004 03:02:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGBjd-0001dZ-00 for tcpm@ietf.org; Wed, 21 Apr 2004 03:01:29 -0400 Received: from bay2-f35.bay2.hotmail.com ([65.54.247.35] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BGBig-0001Td-00 for tcpm@ietf.org; Wed, 21 Apr 2004 03:00:30 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 21 Apr 2004 00:00:00 -0700 Received: from 131.107.3.74 by by2fd.bay2.hotmail.msn.com with HTTP; Wed, 21 Apr 2004 07:00:00 GMT X-Originating-IP: [131.107.3.74] X-Originating-Email: [skaniyar@hotmail.com] X-Sender: skaniyar@hotmail.com From: "sanjay kaniyar" To: rrs@cisco.com Cc: tcpm@ietf.org Subject: RE: [tcpm] I-D ACTION:draft-ietf-tcpm-tcpsecure-00.txt Date: Wed, 21 Apr 2004 00:00:00 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Apr 2004 07:00:00.0690 (UTC) FILETIME=[43946120:01C4276E] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id DAA29226 Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Section [4.2]: I think this mitigation can be strengthened. For connections with larger=20 (scaled) window sizes, the protection offered by ACK validation is quite=20 minimal. Here is a suggestion to improve upon what you have for long lived=20 connections with large windows which send/receive data intermittently:=20 Consider a connection between a server [S] and a client [C]. A TCP can ne= ver=20 send more than a receive window worth of data in a given RTT. This can be= =20 used in validating the ACK number as well. Let the RTT as seen by S be=20 RTT(S) and maximum receive window ever seen by S (advertised by C) be=20 MaxSndWnd. Let=92s assume the maximum amount of time we expect a reordere= d=20 segment sent by C to stay in the network be N * RTT(S) (I know =96 it is = MSL=20 in theory). This means, the ACK number on a segment that S accepts should= be=20 between {SndMax} and {SndMax - N * MaxSndWnd}. N should be reduced by 1 e= ach=20 RTT S does not send any data on this connection, eventually becoming just= 1=20 byte (SndUna). For simplicity, one could just start with [SndUna - MaxSndWnd, SndMax] an= d=20 clamp it down to [SndUna] if the connection does not send anything for 1=20 MSL. Thanks, Sanjay _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar =96 get it now!=20 http://toolbar.msn.com/go/onm00200415ave/direct/01/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 03:35:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00969 for ; Wed, 21 Apr 2004 03:35:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGCFm-00041i-03 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 03:34:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3L7YflQ015472 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 03:34:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGCDv-00038B-Nh for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 03:32:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00686 for ; Wed, 21 Apr 2004 03:32:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGCDt-0004r4-Aj for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 03:32:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGCCo-0004ia-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 03:31:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGCCJ-0004d4-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 03:31:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGC8K-0000t9-UG; Wed, 21 Apr 2004 03:27:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGBxx-0005V5-Hn for tcpm@optimus.ietf.org; Wed, 21 Apr 2004 03:16:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29915 for ; Wed, 21 Apr 2004 03:16:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGBxv-00038P-AI for tcpm@ietf.org; Wed, 21 Apr 2004 03:16:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGBwZ-00031g-00 for tcpm@ietf.org; Wed, 21 Apr 2004 03:14:52 -0400 Received: from ftp.netlab.nec.de ([195.37.70.21] helo=ftp.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1BGBvp-0002ul-00 for tcpm@ietf.org; Wed, 21 Apr 2004 03:14:05 -0400 Received: from netlab.nec.de (scout.netlab.nec.de [195.37.70.100]) by ftp.ccrle.nec.de (Postfix) with ESMTP id A7F36F674 for ; Wed, 21 Apr 2004 09:19:02 +0200 (CEST) Message-ID: <40861F36.2050304@netlab.nec.de> Date: Wed, 21 Apr 2004 09:13:58 +0200 From: Lars Eggert Organization: NEC Network Laboratories User-Agent: Mozilla Thunderbird 0.6+ (Macintosh/20040420) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030707030804040205090107" Subject: [tcpm] [Fwd: I-D ACTION:draft-eggert-tcpm-tcp-abort-timeout-option-00.txt] Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,MIME_SUSPECT_NAME autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms030707030804040205090107 Content-Type: multipart/mixed; boundary="------------030107080209060107000006" This is a multi-part message in MIME format. --------------030107080209060107000006 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, this announcement doesn't seem to have made it onto the list. I'd appreciate some group feedback on the ID. Thanks, Lars -- Lars Eggert NEC Network Laboratories --------------030107080209060107000006 Content-Type: message/rfc822; name="I-D ACTION:draft-eggert-tcpm-tcp-abort-timeout-option-00.txt" Content-Disposition: inline; filename="I-D ACTION:draft-eggert-tcpm-tcp-abort-timeout-option-00.txt" Return-Path: X-Sieve: cmu-sieve 2.0 Received: from tokyo.ccrle.nec.de (pluto.office [10.1.1.84]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 1CB0110B6CB; Tue, 20 Apr 2004 22:49:30 +0200 (CEST) Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i3KKnNri026290; Tue, 20 Apr 2004 22:49:25 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG1Qg-000147-VE; Tue, 20 Apr 2004 16:01:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG1HG-0005se-E9 for i-d-announce@optimus.ietf.org; Tue, 20 Apr 2004 15:51:30 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18165 for ; Tue, 20 Apr 2004 15:51:28 -0400 (EDT) Message-Id: <200404201951.PAA18165@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-eggert-tcpm-tcp-abort-timeout-option-00.txt Date: Tue, 20 Apr 2004 15:51:28 -0400 Sender: i-d-announce-admin@ietf.org Errors-To: i-d-announce-admin@ietf.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk Reply-To: internet-drafts@ietf.org List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Scanned-By: MIMEDefang 2.35 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : TCP Abort Timeout Option Author(s) : L. Eggert Filename : draft-eggert-tcpm-tcp-abort-timeout-option-00.txt Pages : 10 Date : 2004-4-20 The TCP Abort Timeout Option allows conforming TCP implementations to negotiate individual, per-connection abort timeouts. Lengthening abort timeouts allows established TCP connections to survive periods of disconnection. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-eggert-tcpm-tcp-abort-timeout-option-00.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-eggert-tcpm-tcp-abort-timeout-option-00.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-eggert-tcpm-tcp-abort-timeout-option-00.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: <2004-4-20160735.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-eggert-tcpm-tcp-abort-timeout-option-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-eggert-tcpm-tcp-abort-timeout-option-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-20160735.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce --------------030107080209060107000006-- --------------ms030707030804040205090107 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ/zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNaMIICw6ADAgECAgMLU6IwDQYJKoZIhvcNAQEE BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTAz MTIxNTEyMzEyOFoXDTA0MTIxNDEyMzEyOFowgYQxDzANBgNVBAQTBkVnZ2VydDENMAsGA1UE KhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdn ZXJ0QG5ldGxhYi5uZWMuZGUxIjAgBgkqhkiG9w0BCQEWE2xhcnMuZWdnZXJ0QGdteC5uZXQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWps58Zq8Buu2DKDl9crbvzSo6zWsZ TkQLr5zOTqUMs/eU7Mcohv64O4IxWWYGLfYsjDRxUlmdHdJUbyTtUh2lH452DUDJByXidlLm RDgohG0AVwztedqy1+hE3VnCdpMhUGks+6ntrr3dKSxMgLM0AM1kPWsH9lWX6IOPdxOC30gM PiQ65zH9PR70befQLgFPKcAv0wP8210l05n8ekwYAcq2cm3/j+nuDu0HEh5pgsnY7cVELeNJ ODvr4IiE1t3c2w4+0Nc/WJrqGCMl+gZ8c+7FtzjoyDeEsCjNFDeA2ymNd+10O6kjwvPHlzPr 3rW73RDRPAjMJ49HXlueiuoNAgMBAAGjdzB1MCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwOQYDVR0RBDIwMIEZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5k ZYETbGFycy5lZ2dlcnRAZ214Lm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB AHgrv3SQFD4AS4lY4oKcI3iTHcclEHbYfg3UUb8zzCUsl+OJoz0nmebGmOL+tvNj5GvCrWnN H4LvVLh8ZBhFXms7eKJ1YiHgbKwTRK23P8Y5NDit5ico0ZjpFWeenUWj3ajEbN6n4K8dNp+C 0b2apnSrlFVWY6BucZFIYqQ1Lf91MIIDWjCCAsOgAwIBAgIDC1OiMA0GCSqGSIb3DQEBBAUA MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wMzEy MTUxMjMxMjhaFw0wNDEyMTQxMjMxMjhaMIGEMQ8wDQYDVQQEEwZFZ2dlcnQxDTALBgNVBCoT BExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2Vy dEBuZXRsYWIubmVjLmRlMSIwIAYJKoZIhvcNAQkBFhNsYXJzLmVnZ2VydEBnbXgubmV0MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1qbOfGavAbrtgyg5fXK2780qOs1rGU5E C6+czk6lDLP3lOzHKIb+uDuCMVlmBi32LIw0cVJZnR3SVG8k7VIdpR+Odg1AyQcl4nZS5kQ4 KIRtAFcM7XnastfoRN1ZwnaTIVBpLPup7a693SksTICzNADNZD1rB/ZVl+iDj3cTgt9IDD4k Oucx/T0e9G3n0C4BTynAL9MD/NtdJdOZ/HpMGAHKtnJt/4/p7g7tBxIeaYLJ2O3FRC3jSTg7 6+CIhNbd3NsOPtDXP1ia6hgjJfoGfHPuxbc46Mg3hLAozRQ3gNspjXftdDupI8Lzx5cz6961 u90Q0TwIzCePR15bnorqDQIDAQABo3cwdTAqBgUrZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVN eWZmQk5VYk5KSmNkWjJzMDkGA1UdEQQyMDCBGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGWB E2xhcnMuZWdnZXJ0QGdteC5uZXQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQB4 K790kBQ+AEuJWOKCnCN4kx3HJRB22H4N1FG/M8wlLJfjiaM9J5nmxpji/rbzY+Rrwq1pzR+C 71S4fGQYRV5rO3iidWIh4GysE0Sttz/GOTQ4reYnKNGY6RVnnp1Fo92oxGzep+CvHTafgtG9 mqZ0q5RVVmOgbnGRSGKkNS3/dTGCAzswggM3AgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwCQYFKw4DAhoFAKCCAacwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwNDIxMDcxMzU5WjAjBgkqhkiG 9w0BCQQxFgQUkINbuwi1xNPgcWjSVDgFwm861hswUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECAwtTojB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwDQYJKoZIhvcNAQEBBQAEggEA gV3nOrqYLoxi1pxsNryOUWT7bJevhE7jq/P9ejv0NNd2eX2u6Or32D1X3UvuGqq4La1jxW1Q nRPX2B4UJsPLrX6bHCef3CHCBCbQecw5sT+4HdIt6+POgteIweEWVvwW3pz6LrW5nZ9oE+qv qxugfPpSbYiDL3VA3CgqBMwiRmA4P0Naw8du6loUl994c2E+7g1MZYt5H6z9mmxVdM+YXxke 4vuiomDABj00N3NjXprJGip7DDLez7DHvBkOcn7gahNkkx6W+GkqoxCfHHs7lC7iX26s9Qs+ ZBj6y0kswtapEMH1tHaokAxhxMDymBFEED6faZPXEz1D9GC6CiOK6wAAAAAAAA== --------------ms030707030804040205090107-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 06:25:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09061 for ; Wed, 21 Apr 2004 06:25:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGEtj-0008Hb-7L for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 06:24:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LAO7sM031831 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 06:24:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGEmm-0006Kc-SP for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 06:16:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08797 for ; Wed, 21 Apr 2004 06:16:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGEmj-00010P-46 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 06:16:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGElw-0000t2-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 06:16:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGEl9-0000lN-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 06:15:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGEiy-00050c-C3; Wed, 21 Apr 2004 06:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGEdy-0002uC-ST for tcpm@optimus.ietf.org; Wed, 21 Apr 2004 06:07:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08497 for ; Wed, 21 Apr 2004 06:07:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGEdv-0007ix-4O for tcpm@ietf.org; Wed, 21 Apr 2004 06:07:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGEd7-0007c0-00 for tcpm@ietf.org; Wed, 21 Apr 2004 06:06:58 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1BGEcX-0007SJ-00 for tcpm@ietf.org; Wed, 21 Apr 2004 06:06:21 -0400 Received: from bu-ewat02-01.uk.sun.com ([129.156.199.2]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3LA5pms028497 for ; Wed, 21 Apr 2004 03:05:52 -0700 (PDT) Received: from uk.sun.com (vpn-129-156-96-32.EMEA.Sun.COM [129.156.96.32]) by bu-ewat02-01.uk.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i3LA5o3D029766 for ; Wed, 21 Apr 2004 11:05:51 +0100 (BST) Message-ID: <40864778.40106@uk.sun.com> Date: Wed, 21 Apr 2004 11:05:44 +0100 From: Jeremy Harris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.6) Gecko/20040113 X-Accept-Language: en, en-us MIME-Version: 1.0 To: tcpm@ietf.org Subject: Re: [tcpm] new work item: TCP security issue References: <20040421040538.A64A313B953@lawyers.icir.org> In-Reply-To: <20040421040538.A64A313B953@lawyers.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Most of the mitigating techniques seem to boil down to increasing the search space for an attacker. To do that and better support LFN's - why not just use a longer sequence number field? Since back-compatibility is vital, this would need to be a TCP option. Is 64 bits enough or would we go direct to 128? - Jeremy _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 07:47:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13773 for ; Wed, 21 Apr 2004 07:47:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGGAc-00047q-8H for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 07:45:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LBjchI015850 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 07:45:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGG7I-0002Hc-D8 for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 07:42:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13388 for ; Wed, 21 Apr 2004 07:42:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGG7H-0004Rw-Mg for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 07:42:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGG6A-0004IL-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 07:41:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGG5g-00049U-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 07:40:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGG1I-00006b-3f; Wed, 21 Apr 2004 07:36:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGFqN-0004nI-Fz for tcpm@optimus.ietf.org; Wed, 21 Apr 2004 07:24:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12646 for ; Wed, 21 Apr 2004 07:24:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGFqM-00029j-Ta for tcpm@ietf.org; Wed, 21 Apr 2004 07:24:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGFpO-00022I-00 for tcpm@ietf.org; Wed, 21 Apr 2004 07:23:42 -0400 Received: from mail.enyo.de ([212.9.189.167]) by ietf-mx with esmtp (Exim 4.12) id 1BGFoT-0001uy-00 for tcpm@ietf.org; Wed, 21 Apr 2004 07:22:45 -0400 Received: (debugging) helo=deneb ip=212.9.189.171 name=deneb.enyo.de Received: from deneb.enyo.de ([212.9.189.171] helo=deneb) by mail.enyo.de with esmtp id 1BGFoQ-0002i8-CT; Wed, 21 Apr 2004 13:22:42 +0200 Received: from fw by deneb with local (Exim 4.32) id 1BGFoP-000118-Vx; Wed, 21 Apr 2004 13:22:41 +0200 To: Jeremy Harris Cc: tcpm@ietf.org Subject: Re: [tcpm] new work item: TCP security issue References: <20040421040538.A64A313B953@lawyers.icir.org> <40864778.40106@uk.sun.com> From: Florian Weimer Date: Wed, 21 Apr 2004 13:22:41 +0200 In-Reply-To: <40864778.40106@uk.sun.com> (Jeremy Harris's message of "Wed, 21 Apr 2004 11:05:44 +0100") Message-ID: <87brllmv7i.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Jeremy Harris writes: > Most of the mitigating techniques seem to boil down to > increasing the search space for an attacker. To do that > and better support LFN's - why not just use a longer > sequence number field? Wouldn't be a cookie that doesn't change during the connection be somewhat better? -- Current mail filters: many dial-up/DSL/cable modem hosts, and the following domains: atlas.cz, bigpond.com, postino.it, tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 08:51:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17730 for ; Wed, 21 Apr 2004 08:51:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGH9s-0001Y3-Sx for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 08:48:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LCmuv4005946 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 08:48:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGH5x-0008UC-3B for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 08:44:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17410 for ; Wed, 21 Apr 2004 08:44:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGH5v-0006Vk-Rb for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 08:44:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGH4y-0006NQ-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 08:43:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGH4B-0006Fp-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 08:43:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGH0F-0006w2-Pv; Wed, 21 Apr 2004 08:38:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGGtK-0003b6-Ka for tcpm@optimus.ietf.org; Wed, 21 Apr 2004 08:31:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16847 for ; Wed, 21 Apr 2004 08:31:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGGtJ-0004eK-E0 for tcpm@ietf.org; Wed, 21 Apr 2004 08:31:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGGsJ-0004Td-00 for tcpm@ietf.org; Wed, 21 Apr 2004 08:30:48 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1BGGrG-0004BK-00 for tcpm@ietf.org; Wed, 21 Apr 2004 08:29:42 -0400 Received: from bu-ewat02-01.uk.sun.com ([129.156.199.2]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i3LCT66b005339 for ; Wed, 21 Apr 2004 05:29:06 -0700 (PDT) Received: from uk.sun.com (vpn-129-156-96-32.EMEA.Sun.COM [129.156.96.32]) by bu-ewat02-01.uk.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i3LCT43D012257 for ; Wed, 21 Apr 2004 13:29:05 +0100 (BST) Message-ID: <40866906.2070900@uk.sun.com> Date: Wed, 21 Apr 2004 13:28:54 +0100 From: Jeremy Harris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.6) Gecko/20040113 X-Accept-Language: en, en-us MIME-Version: 1.0 To: tcpm@ietf.org Subject: Re: [tcpm] new work item: TCP security issue References: <20040421040538.A64A313B953@lawyers.icir.org> <40864778.40106@uk.sun.com> <87brllmv7i.fsf@deneb.enyo.de> In-Reply-To: <87brllmv7i.fsf@deneb.enyo.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Florian Weimer wrote: > Jeremy Harris writes: > > >>Most of the mitigating techniques seem to boil down to >>increasing the search space for an attacker. To do that >>and better support LFN's - why not just use a longer >>sequence number field? > > > Wouldn't be a cookie that doesn't change during the connection be > somewhat better? I'm assuming that performance on LFNs would be better supported by big windows, in turn requiring big sequence space. - Jeremy _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 10:55:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26184 for ; Wed, 21 Apr 2004 10:55:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGJ6J-0007i6-7o for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 10:53:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LErNFs029629 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 10:53:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGIzV-000555-KL for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 10:46:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25639 for ; Wed, 21 Apr 2004 10:46:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGIzT-00032T-9J for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 10:46:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGIyh-0002rB-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 10:45:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGIxd-0002dS-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 10:44:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGIma-00009F-D4; Wed, 21 Apr 2004 10:33:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG8OW-0002mn-CW for tcpm@optimus.ietf.org; Tue, 20 Apr 2004 23:27:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19512 for ; Tue, 20 Apr 2004 23:27:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG8OU-00024f-BS for tcpm@ietf.org; Tue, 20 Apr 2004 23:27:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG8NX-0001zr-00 for tcpm@ietf.org; Tue, 20 Apr 2004 23:26:28 -0400 Received: from web80110.mail.yahoo.com ([66.163.169.83]) by ietf-mx with smtp (Exim 4.12) id 1BG8Me-0001uo-00 for tcpm@ietf.org; Tue, 20 Apr 2004 23:25:32 -0400 Message-ID: <20040421032532.37940.qmail@web80110.mail.yahoo.com> Received: from [66.124.150.213] by web80110.mail.yahoo.com via HTTP; Tue, 20 Apr 2004 20:25:32 PDT Date: Tue, 20 Apr 2004 20:25:32 -0700 (PDT) From: Alan Evans To: tcpm@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [tcpm] TCP vulnerability Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Does draft-ietf-tcpm-tcpsecure-00.txt address the following? http://www.uniras.gov.uk/vuls/2004/236929/index.htm I think the urgency is due to it's high publicity!. Alan. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 10:58:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26297 for ; Wed, 21 Apr 2004 10:58:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGJ7z-0008Tx-FC for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 10:55:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LEt7ZA032601 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 10:55:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGJ4v-0007KS-TC for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 10:51:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25989 for ; Wed, 21 Apr 2004 10:51:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGJ4t-00043p-DH for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 10:51:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGJ46-0003un-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 10:51:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGJ3J-0003lC-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 10:50:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGIyD-0004iO-CP; Wed, 21 Apr 2004 10:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGIie-0007ZQ-VL for tcpm@optimus.ietf.org; Wed, 21 Apr 2004 10:28:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24534 for ; Wed, 21 Apr 2004 10:28:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGIic-00008u-Mw for tcpm@ietf.org; Wed, 21 Apr 2004 10:28:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGIhf-0007nf-00 for tcpm@ietf.org; Wed, 21 Apr 2004 10:27:55 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx with esmtp (Exim 4.12) id 1BGIh1-0007fZ-00 for tcpm@ietf.org; Wed, 21 Apr 2004 10:27:15 -0400 Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by wyvern.icir.org (8.12.9p1/8.12.8) with ESMTP id i3LEQv7A031902; Wed, 21 Apr 2004 07:26:59 -0700 (PDT) (envelope-from mallman@icir.org) Received: from lawyers.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by guns.icir.org (Postfix) with ESMTP id 22CEB77A6D5; Wed, 21 Apr 2004 10:26:56 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id E9A6F13BCA2; Wed, 21 Apr 2004 10:26:45 -0400 (EDT) To: Florian Weimer From: Mark Allman Reply-To: mallman@icir.org Cc: Jeremy Harris , tcpm@ietf.org Subject: Re: [tcpm] new work item: TCP security issue In-Reply-To: <87brllmv7i.fsf@deneb.enyo.de> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Bad to the Bone MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 21 Apr 2004 10:26:45 -0400 Message-Id: <20040421142646.E9A6F13BCA2@lawyers.icir.org> Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 --=-=-= Content-Type: text/plain > Wouldn't be a cookie that doesn't change during the connection be > somewhat better? Sometimes resets cross connections. I.e., think of my long-running and yet idle ssh connection to some remote machine. If the remote machine reboots while I am idle then the next time I try to use the connection I'll get a reset. But, the remote machine won't have this "cookie" anymore because all the state about the connection is gone. allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin) iD8DBQFAhoSlWyrrWs4yIs4RApd2AJ48S0gYuN7Si/zoS2/G8g82xEOATACfeBIk cpPRuIej/l1C4US+OX2Iys4= =SjMs -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 12:37:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01115 for ; Wed, 21 Apr 2004 12:36:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGKb0-0002ws-29 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 12:29:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LGTAID011330 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 12:29:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGKHZ-0002hj-Cq for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 12:09:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29470 for ; Wed, 21 Apr 2004 12:09:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGKHY-0001M0-3c for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 12:09:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGKGf-0001CD-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 12:08:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGKFz-00012K-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 12:07:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGJzc-00033C-3o; Wed, 21 Apr 2004 11:50:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGJJY-0004li-6e for tcpm@optimus.ietf.org; Wed, 21 Apr 2004 11:07:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26694 for ; Wed, 21 Apr 2004 11:07:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGJJV-0006Ow-Jz for tcpm@ietf.org; Wed, 21 Apr 2004 11:07:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGJIZ-0006Fg-00 for tcpm@ietf.org; Wed, 21 Apr 2004 11:06:04 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGJHv-00065J-00 for tcpm@ietf.org; Wed, 21 Apr 2004 11:05:23 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 21 Apr 2004 07:15:24 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3LF4o7t000446; Wed, 21 Apr 2004 08:04:51 -0700 (PDT) Received: from cisco.com (rtp-dial-1-162.cisco.com [10.83.97.162]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATF52430; Wed, 21 Apr 2004 08:04:49 -0700 (PDT) Message-ID: <40868D8A.5020100@cisco.com> Date: Wed, 21 Apr 2004 10:04:42 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sally Floyd CC: tcpm@ietf.org References: <200404202312.i3KNCMcb008483@cougar.icir.org> In-Reply-To: <200404202312.i3KNCMcb008483@cougar.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [tcpm] Re: draft-ietf-tcpm-tcpsecure Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sally Floyd wrote: >Randall - > >Many thanks for the draft! I haven't read it carefully yet, but I >have been worrying about this issue for HighSpeed TCP, where the >receive window is likely to be quite large. The large receive >window makes it even easier for an attacker to guess a valid sequence >number for a reset. > >It also wasn't on my radar when I wrote the HighSpeed TCP document, >now RFC 3649, so it is not mentioned in the Security Considerations >section of that document, in terms of a security risk related to >higher congestion windows. > >Regards, >- Sally > > > Sally: Thanks for the note... We (I say we since all of the contributors worked hard on this document and the fixes) would appreciate any and all feedback. The document was rushed out and it does have some errors.. I know.. so please fire away with corrections :-> Thanks R -- Randall R. Stewart ITD - Transport Technologies 815-477-2127(o) or 815-342-5222(c) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 12:37:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01149 for ; Wed, 21 Apr 2004 12:37:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGKb0-0002xQ-RH for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 12:29:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LGTAPK011360 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 12:29:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGKIT-0002nb-9h for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 12:10:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29531 for ; Wed, 21 Apr 2004 12:09:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGKIR-0001Wn-VI for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 12:10:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGKHV-0001Lf-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 12:09:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGKGY-0001BK-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 12:08:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGJzc-00033U-Ue; Wed, 21 Apr 2004 11:50:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGJLR-0005eO-6w for tcpm@optimus.ietf.org; Wed, 21 Apr 2004 11:09:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26745 for ; Wed, 21 Apr 2004 11:08:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGJLO-0006iC-Jf for tcpm@ietf.org; Wed, 21 Apr 2004 11:08:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGJKW-0006Z7-00 for tcpm@ietf.org; Wed, 21 Apr 2004 11:08:05 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGJJk-0006GF-00 for tcpm@ietf.org; Wed, 21 Apr 2004 11:07:16 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 21 Apr 2004 07:17:17 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3LF6i7t004399; Wed, 21 Apr 2004 08:06:44 -0700 (PDT) Received: from cisco.com (rtp-dial-1-162.cisco.com [10.83.97.162]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATF52725; Wed, 21 Apr 2004 08:06:38 -0700 (PDT) Message-ID: <40868DF7.70807@cisco.com> Date: Wed, 21 Apr 2004 10:06:31 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Evans CC: tcpm@ietf.org Subject: Re: [tcpm] TCP vulnerability References: <20040421032532.37940.qmail@web80110.mail.yahoo.com> In-Reply-To: <20040421032532.37940.qmail@web80110.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alan Evans wrote: >Does draft-ietf-tcpm-tcpsecure-00.txt address the >following? > >http://www.uniras.gov.uk/vuls/2004/236929/index.htm > >I think the urgency is due to it's high publicity!. > > >Alan. > > >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www1.ietf.org/mailman/listinfo/tcpm > > > Yes... it trys to... but has Mark stated.. we may change the fixes.. this is just one proposal. R -- Randall R. Stewart ITD - Transport Technologies 815-477-2127(o) or 815-342-5222(c) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 12:37:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01167 for ; Wed, 21 Apr 2004 12:37:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGKb4-0002z8-Jt for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 12:29:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LGTEG4011469 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 12:29:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGKIg-0002sL-DB for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 12:10:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29580 for ; Wed, 21 Apr 2004 12:10:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGKIf-0001YX-4R for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 12:10:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGKHk-0001O6-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 12:09:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGKHI-0001DG-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 12:08:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGJzf-00034F-Eo; Wed, 21 Apr 2004 11:50:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGJRx-0007v5-UZ for tcpm@optimus.ietf.org; Wed, 21 Apr 2004 11:15:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26962 for ; Wed, 21 Apr 2004 11:15:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGJRx-0007dh-3q for tcpm@ietf.org; Wed, 21 Apr 2004 11:15:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGJQQ-0007U8-00 for tcpm@ietf.org; Wed, 21 Apr 2004 11:14:11 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGJPT-0007AE-00 for tcpm@ietf.org; Wed, 21 Apr 2004 11:13:11 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 21 Apr 2004 07:24:25 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3LFCd7t017104; Wed, 21 Apr 2004 08:12:39 -0700 (PDT) Received: from cisco.com (rtp-dial-1-162.cisco.com [10.83.97.162]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATF53565; Wed, 21 Apr 2004 08:12:36 -0700 (PDT) Message-ID: <40868F5D.6050201@cisco.com> Date: Wed, 21 Apr 2004 10:12:29 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com CC: mallman@icir.org, tcpm@ietf.org, faber@isi.edu Subject: Re: [tcpm] new work item: TCP security issue References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Yes please :-D R john.loughney@nokia.com wrote: >Hi all, > > > > >>Just announced internet-draft: >> >> >>> Title : Transmission Control Protocol security >>> >>> >>considerations >> >> >>> Author(s) : R. Stewart >>> Filename : draft-ietf-tcpm-tcpsecure-00.txt >>> Pages : 10 >>> Date : 2004-4-20 >>> >>> >>> >>http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt >> >> > >I support this being a working group document. However, rather than >worrying >about the name of the draft, I would imagine that getting comments / >feedback on the draft is the more important part. Do the chairs plan >to try to get feedback on the draft and progress the draft rather >quickly? > >John > >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www1.ietf.org/mailman/listinfo/tcpm > > > -- Randall R. Stewart ITD - Transport Technologies 815-477-2127(o) or 815-342-5222(c) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 12:37:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01172 for ; Wed, 21 Apr 2004 12:37:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGKbQ-00031H-I3 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 12:29:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LGTaAf011603 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 12:29:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGKJV-00032T-IP for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 12:11:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29618 for ; Wed, 21 Apr 2004 12:11:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGKJU-0001ii-9Q for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 12:11:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGKIf-0001Yl-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 12:10:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGKHr-0001OG-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 12:09:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGJzg-00034V-O7; Wed, 21 Apr 2004 11:50:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGJTA-00007q-Pu for tcpm@optimus.ietf.org; Wed, 21 Apr 2004 11:17:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27012 for ; Wed, 21 Apr 2004 11:16:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGJT9-00009V-RD for tcpm@ietf.org; Wed, 21 Apr 2004 11:16:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGJSE-0007nB-00 for tcpm@ietf.org; Wed, 21 Apr 2004 11:16:02 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGJRo-0007cT-00 for tcpm@ietf.org; Wed, 21 Apr 2004 11:15:36 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 21 Apr 2004 07:25:27 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3LFEb8k015947; Wed, 21 Apr 2004 08:14:52 -0700 (PDT) Received: from cisco.com (rtp-dial-1-162.cisco.com [10.83.97.162]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATF53852; Wed, 21 Apr 2004 08:14:35 -0700 (PDT) Message-ID: <40868FD4.3080104@cisco.com> Date: Wed, 21 Apr 2004 10:14:28 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mallman@icir.org CC: Florian Weimer , Jeremy Harris , tcpm@ietf.org Subject: Re: [tcpm] new work item: TCP security issue References: <20040421142646.E9A6F13BCA2@lawyers.icir.org> In-Reply-To: <20040421142646.E9A6F13BCA2@lawyers.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mark Allman wrote: >>Wouldn't be a cookie that doesn't change during the connection be >>somewhat better? >> >> > >Sometimes resets cross connections. I.e., think of my long-running and >yet idle ssh connection to some remote machine. If the remote machine >reboots while I am idle then the next time I try to use the connection >I'll get a reset. But, the remote machine won't have this "cookie" >anymore because all the state about the connection is gone. > >allman > > >-- >Mark Allman -- ICIR -- http://www.icir.org/mallman/ > > > > > Mark: One would have to treat this situation (assuming we went with a cookie.. or has we call it in SCTP a v-tag) like SCTP does... i.e. you would need to have a bit to indicate that its "your tag" not the one I normally sent... R -- Randall R. Stewart ITD - Transport Technologies 815-477-2127(o) or 815-342-5222(c) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 12:38:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01237 for ; Wed, 21 Apr 2004 12:38:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGKbW-00035B-IF for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 12:29:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LGTg6A011841 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 12:29:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGKMK-0004jd-Oa for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 12:14:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29773 for ; Wed, 21 Apr 2004 12:13:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGKMJ-0002Ga-Ef for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 12:13:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGKLJ-00024T-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 12:12:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGKKH-0001q2-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 12:11:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGJzi-00035F-ML; Wed, 21 Apr 2004 11:50:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGJY2-0000xN-6f for tcpm@optimus.ietf.org; Wed, 21 Apr 2004 11:22:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27160 for ; Wed, 21 Apr 2004 11:21:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGJY1-0000vg-6z for tcpm@ietf.org; Wed, 21 Apr 2004 11:22:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGJX5-0000mI-00 for tcpm@ietf.org; Wed, 21 Apr 2004 11:21:04 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGJWI-0000Ty-00 for tcpm@ietf.org; Wed, 21 Apr 2004 11:20:14 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 21 Apr 2004 07:31:28 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3LFJf7t002055; Wed, 21 Apr 2004 08:19:42 -0700 (PDT) Received: from cisco.com (rtp-dial-1-162.cisco.com [10.83.97.162]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATF54666; Wed, 21 Apr 2004 08:19:39 -0700 (PDT) Message-ID: <40869104.50803@cisco.com> Date: Wed, 21 Apr 2004 10:19:32 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sanjay kaniyar CC: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sanjay: Good point I will add that to the next pass. I am also going to attempt to use the draft tracker Mark pointed to earlier :-> R sanjay kaniyar wrote: > Section [4.2]: > > An additional input check should be added to any incoming segment. > The ACK value should be acceptable only if it is in the range of > ((SND.UNA - MAX.SND.WND) <= SEG.ACK < SND.NXT). > > The right edge of the acceptable ACK range should be SND.MAX actually. > During the course of a retransmission, SND.NXT moves back and making > that the right edge of the range would result in potentially dropping > a lot of valid acknowledgements. > > Thanks, > Sanjay > > _________________________________________________________________ > >> From must-see cities to the best beaches, plan a getaway with the Spring > > Travel Guide! http://special.msn.com/local/springtravel.armx > > -- Randall R. Stewart ITD - Transport Technologies 815-477-2127(o) or 815-342-5222(c) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 12:38:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01300 for ; Wed, 21 Apr 2004 12:38:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGKba-00037s-M4 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 12:29:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LGTkvF012011 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 12:29:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGKNg-00052Z-LR for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 12:15:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29918 for ; Wed, 21 Apr 2004 12:15:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGKNf-0002WB-BE for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 12:15:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGKMj-0002KM-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 12:14:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGKLy-00028H-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 12:13:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGJzn-00036b-HL; Wed, 21 Apr 2004 11:50:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGJlY-0006Pm-MJ for tcpm@optimus.ietf.org; Wed, 21 Apr 2004 11:36:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27610 for ; Wed, 21 Apr 2004 11:35:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGJlX-00038S-JA for tcpm@ietf.org; Wed, 21 Apr 2004 11:35:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGJkX-0002wO-00 for tcpm@ietf.org; Wed, 21 Apr 2004 11:34:57 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BGJjY-0002lj-00 for tcpm@ietf.org; Wed, 21 Apr 2004 11:33:56 -0400 Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3LFX8N28481; Wed, 21 Apr 2004 08:33:08 -0700 (PDT) Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.12.10/8.12.10) with ESMTP id i3LFX8Ix018147; Wed, 21 Apr 2004 08:33:08 -0700 (PDT) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.12.10/8.12.10/Submit) id i3LFX8Nj018146; Wed, 21 Apr 2004 08:33:08 -0700 (PDT) (envelope-from faber) Date: Wed, 21 Apr 2004 08:33:08 -0700 From: Ted Faber To: Tim Shepard Cc: "Peterson, Jon" , Joe Touch , tcpm@ietf.org Subject: Re: [tcpm] new work item: TCP security issue Message-ID: <20040421153308.GB17952@pun.isi.edu> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TRYliJ5NKNqkz5bu" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: faber@isi.edu Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --TRYliJ5NKNqkz5bu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Apr 20, 2004 at 10:56:16PM -0400, Tim Shepard wrote: > > > Your concern about the abuse of process is understandable, and I hope it is > > obvious that it was only the urgency of progressing this work which prompted > > us to take an action which, as you rightfully assert, we have no legitimate > > process grounds for taking. > > > I must be missing something. Could someone please explain why this > is urgent? (I've read the draft once, and I'm reading it again now, > and I don't see why this would be considered urgent.) Your point that something labelled urgent should indicate why the labeller (me) thought it was urgent is well taken. Should I label somethign urgent for the WG again, I'll put a line in the front of the doc indicating why I believe it to be so. Holler if I forget. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG --TRYliJ5NKNqkz5bu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAhpQ0aUz3f+Zf+XsRAoPnAKCWp9kZYcaekirh/GnRa1Qpxw82qQCdGoG4 95psqCyrfhqoQQbVPrMK1Q0= =Fov/ -----END PGP SIGNATURE----- --TRYliJ5NKNqkz5bu-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 12:39:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01356 for ; Wed, 21 Apr 2004 12:39:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGKbg-0003IK-Pl for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 12:29:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LGTqPA012645 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 12:29:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGKPZ-0006IH-Lb for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 12:17:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00064 for ; Wed, 21 Apr 2004 12:17:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGKPY-0002vv-Ck for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 12:17:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGKOk-0002kB-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 12:16:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGKO4-0002Y2-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 12:15:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGJzs-00039D-OM; Wed, 21 Apr 2004 11:50:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGJtG-0008Ul-P7 for tcpm@optimus.ietf.org; Wed, 21 Apr 2004 11:43:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27987 for ; Wed, 21 Apr 2004 11:43:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGJtF-0004VZ-Kt for tcpm@ietf.org; Wed, 21 Apr 2004 11:43:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGJsF-0004IZ-00 for tcpm@ietf.org; Wed, 21 Apr 2004 11:42:56 -0400 Received: from ftp.netlab.nec.de ([195.37.70.21] helo=ftp.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1BGJrL-000495-00 for tcpm@ietf.org; Wed, 21 Apr 2004 11:41:59 -0400 Received: from netlab.nec.de (scout.netlab.nec.de [195.37.70.100]) by ftp.ccrle.nec.de (Postfix) with ESMTP id 443F8F674; Wed, 21 Apr 2004 17:47:00 +0200 (CEST) Message-ID: <40869644.2020509@netlab.nec.de> Date: Wed, 21 Apr 2004 17:41:56 +0200 From: Lars Eggert Organization: NEC Network Laboratories User-Agent: Mozilla Thunderbird 0.6+ (Macintosh/20040420) X-Accept-Language: en-us, en MIME-Version: 1.0 To: weddy@grc.nasa.gov Cc: tcpm@ietf.org References: <20040421151201.GC32188@grc.nasa.gov> In-Reply-To: <20040421151201.GC32188@grc.nasa.gov> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020005010104090605090605" Subject: [tcpm] Re: draft-eggert-tcpm-tcp-abort-timeout-option-00.txt Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms020005010104090605090605 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Wesley, Wesley Eddy wrote: > Is there really a need to allow the first ACK to carry an ATO? It > should be enough to just allow them on the SYN and SYN-ACK. If a host > sends an ATO of X on a SYN and gets back an ATO of X-Y on the SYN-ACK, it > probably won't want to go any shorter than X-Y, as that's already shorter > than it requested. thanks for the feedback. Allowing an ATO exchange using either the SYN/SYN-ACK segment pair or the SYN-ACK/ACK pair gives both the initiator and responder of a TCP connection (the client and server, if you will) the option of starting an ATO negotiation. Restricting it to the SYN/SYN-ACK means that only the initiator can request an ATO negotiation. This may be OK for most current uses of the option, but a more general solution can be useful. A negotiation always involves two segments. So in the example you give, the initiator cannot currently continue the negotiation using the first ACK. It made its offer in the SYN and got the response in the SYN-ACK. > If the SYN-ACK carries a value too-low, then it's just tough luck, > because it's likely a web server (or similar) saying "I'm too busy to > just keep your state around forever, but I am willing to hold onto it > for exactly this long". That's true, and I should point out in the draft that using the option to negotiate lower-than-default timouts is useful for exactly such cases. > Removing the ability to send an ATO on the first ACK would rid the draft > of some inconsistency (ie between figure 2 and the first paragraph of 2.1). I see no inconsistency - but the wording may need some improvement. The idea is that an INITIATOR can only use a segment with the SYN flag for its ATO offer, i.e., the SYN and SYN-ACK. The RESPONDER will respond in the very next segment, which obviously cannot be the initial SYN but must be either the SYN-ACK or first ACK. Does this clarify the intent? Lars -- Lars Eggert NEC Network Laboratories --------------ms020005010104090605090605 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ/zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNaMIICw6ADAgECAgMLU6IwDQYJKoZIhvcNAQEE BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTAz MTIxNTEyMzEyOFoXDTA0MTIxNDEyMzEyOFowgYQxDzANBgNVBAQTBkVnZ2VydDENMAsGA1UE KhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdn ZXJ0QG5ldGxhYi5uZWMuZGUxIjAgBgkqhkiG9w0BCQEWE2xhcnMuZWdnZXJ0QGdteC5uZXQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWps58Zq8Buu2DKDl9crbvzSo6zWsZ TkQLr5zOTqUMs/eU7Mcohv64O4IxWWYGLfYsjDRxUlmdHdJUbyTtUh2lH452DUDJByXidlLm RDgohG0AVwztedqy1+hE3VnCdpMhUGks+6ntrr3dKSxMgLM0AM1kPWsH9lWX6IOPdxOC30gM PiQ65zH9PR70befQLgFPKcAv0wP8210l05n8ekwYAcq2cm3/j+nuDu0HEh5pgsnY7cVELeNJ ODvr4IiE1t3c2w4+0Nc/WJrqGCMl+gZ8c+7FtzjoyDeEsCjNFDeA2ymNd+10O6kjwvPHlzPr 3rW73RDRPAjMJ49HXlueiuoNAgMBAAGjdzB1MCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwOQYDVR0RBDIwMIEZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5k ZYETbGFycy5lZ2dlcnRAZ214Lm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB AHgrv3SQFD4AS4lY4oKcI3iTHcclEHbYfg3UUb8zzCUsl+OJoz0nmebGmOL+tvNj5GvCrWnN H4LvVLh8ZBhFXms7eKJ1YiHgbKwTRK23P8Y5NDit5ico0ZjpFWeenUWj3ajEbN6n4K8dNp+C 0b2apnSrlFVWY6BucZFIYqQ1Lf91MIIDWjCCAsOgAwIBAgIDC1OiMA0GCSqGSIb3DQEBBAUA MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wMzEy MTUxMjMxMjhaFw0wNDEyMTQxMjMxMjhaMIGEMQ8wDQYDVQQEEwZFZ2dlcnQxDTALBgNVBCoT BExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2Vy dEBuZXRsYWIubmVjLmRlMSIwIAYJKoZIhvcNAQkBFhNsYXJzLmVnZ2VydEBnbXgubmV0MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1qbOfGavAbrtgyg5fXK2780qOs1rGU5E C6+czk6lDLP3lOzHKIb+uDuCMVlmBi32LIw0cVJZnR3SVG8k7VIdpR+Odg1AyQcl4nZS5kQ4 KIRtAFcM7XnastfoRN1ZwnaTIVBpLPup7a693SksTICzNADNZD1rB/ZVl+iDj3cTgt9IDD4k Oucx/T0e9G3n0C4BTynAL9MD/NtdJdOZ/HpMGAHKtnJt/4/p7g7tBxIeaYLJ2O3FRC3jSTg7 6+CIhNbd3NsOPtDXP1ia6hgjJfoGfHPuxbc46Mg3hLAozRQ3gNspjXftdDupI8Lzx5cz6961 u90Q0TwIzCePR15bnorqDQIDAQABo3cwdTAqBgUrZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVN eWZmQk5VYk5KSmNkWjJzMDkGA1UdEQQyMDCBGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGWB E2xhcnMuZWdnZXJ0QGdteC5uZXQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQB4 K790kBQ+AEuJWOKCnCN4kx3HJRB22H4N1FG/M8wlLJfjiaM9J5nmxpji/rbzY+Rrwq1pzR+C 71S4fGQYRV5rO3iidWIh4GysE0Sttz/GOTQ4reYnKNGY6RVnnp1Fo92oxGzep+CvHTafgtG9 mqZ0q5RVVmOgbnGRSGKkNS3/dTGCAzswggM3AgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwCQYFKw4DAhoFAKCCAacwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwNDIxMTU0MTU2WjAjBgkqhkiG 9w0BCQQxFgQUmgCxalrpXqP+IT4lOVRdMSiH+iowUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECAwtTojB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwDQYJKoZIhvcNAQEBBQAEggEA YS52ZI8yefhdIbsA7rIU9dNXmXxvdKQgptb1u0Mq9iJoOJxu7AykmmzcWOi5XgxRzFKaaHyE jALWLYFo2kFfiESY80L3/nM7JrvS2GiVM/lyqSXYR15CyKLJYn19CeZ1KvO3lfC35Acm0+LR 8gWnoP7UBHLgl1iOBHxiq2GuKhUfUdZNvzLk6wvOLGyZ3B3wQ2SwYm/no4Rs82/psUKT6nio II6TduFGXSlutYw5+OsjcreMhFvTaVC4p5V9y+G69b+yCv+IFzxfhYx812PW6Jao99iClAOf lFPj4/2gYs9yS02Id+2r02d6FVtHI30P5ugcHU/CKWupWhOhEgWEWAAAAAAAAA== --------------ms020005010104090605090605-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 12:39:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01392 for ; Wed, 21 Apr 2004 12:39:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGKc9-0003s0-7V for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 12:30:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LGULBr014873 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 12:30:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGKQJ-0006TV-50 for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 12:18:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00101 for ; Wed, 21 Apr 2004 12:18:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGKQH-00036W-Nr for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 12:18:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGKPR-0002un-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 12:17:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGKOd-0002jA-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 12:16:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGJzt-0003C7-VD; Wed, 21 Apr 2004 11:50:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGJuE-00005n-4y for tcpm@optimus.ietf.org; Wed, 21 Apr 2004 11:44:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28097 for ; Wed, 21 Apr 2004 11:44:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGJuC-0004jh-Uu for tcpm@ietf.org; Wed, 21 Apr 2004 11:44:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGJtE-0004VR-00 for tcpm@ietf.org; Wed, 21 Apr 2004 11:43:57 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx with esmtp (Exim 4.12) id 1BGJsF-0004IO-00 for tcpm@ietf.org; Wed, 21 Apr 2004 11:42:55 -0400 Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by wyvern.icir.org (8.12.9p1/8.12.8) with ESMTP id i3LFgj7A034325; Wed, 21 Apr 2004 08:42:45 -0700 (PDT) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 2C46E77A6D5; Wed, 21 Apr 2004 11:42:44 -0400 (EDT) To: "Randall Stewart (cisco)" From: Mark Allman Reply-To: mallman@icir.org Cc: Florian Weimer , Jeremy Harris , tcpm@ietf.org Subject: Re: [tcpm] new work item: TCP security issue In-Reply-To: <40868FD4.3080104@cisco.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: 57 Channels MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 21 Apr 2004 11:42:44 -0400 Message-Id: <20040421154244.2C46E77A6D5@guns.icir.org> Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 --=-=-= Content-Type: text/plain; charset=us-ascii > One would have to treat this situation (assuming we went with > a cookie.. or has we call it in SCTP a v-tag) like SCTP does... > > i.e. you would need to have a bit to indicate that its "your tag" > not the one I normally sent... I'm not the sharpest tool so you're going to have to be a bit more verbose... because I cannot parse the above at all. Thanks, allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAhpZ0WyrrWs4yIs4RAv8MAJ9VBUtMzf0wBA7TvG3INgZ+GuUAwgCdH64H HWvm5hhvQZFUmJ362vb/0K4= =ew4M -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 18:21:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23118 for ; Wed, 21 Apr 2004 18:21:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGPoy-0002Eh-Lu for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 18:03:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LM3u8T008587 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 18:03:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGOfZ-0005t5-Mc for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 16:50:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13446 for ; Wed, 21 Apr 2004 16:50:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGOfX-0002Uw-Ps for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 16:50:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGOeY-0002Jv-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 16:49:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGOdY-00022F-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 16:48:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGOYe-000306-OX; Wed, 21 Apr 2004 16:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGK9n-0006ra-VZ for tcpm@optimus.ietf.org; Wed, 21 Apr 2004 12:01:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28838 for ; Wed, 21 Apr 2004 12:01:00 -0400 (EDT) From: Yogesh.Swami@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGK9m-0007Qh-Gu for tcpm@ietf.org; Wed, 21 Apr 2004 12:01:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGK8v-0007HJ-00 for tcpm@ietf.org; Wed, 21 Apr 2004 12:00:09 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BGK8X-000776-00 for tcpm@ietf.org; Wed, 21 Apr 2004 11:59:45 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3LFxi216130 for ; Wed, 21 Apr 2004 18:59:44 +0300 (EET DST) X-Scanned: Wed, 21 Apr 2004 18:59:34 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3LFxYMb011944 for ; Wed, 21 Apr 2004 18:59:34 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00p5Szgg; Wed, 21 Apr 2004 18:59:33 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3LFxSs04055 for ; Wed, 21 Apr 2004 18:59:28 +0300 (EET DST) Received: from daebe004.NOE.Nokia.com ([10.241.35.104]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 21 Apr 2004 10:59:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Apr 2004 10:59:10 -0500 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE016E80E6@daebe004.americas.nokia.com> Thread-Index: AcQnub//Aqp4YU6vT6mMoZhV+4DD2Q== To: X-OriginalArrivalTime: 21 Apr 2004 15:59:11.0187 (UTC) FILETIME=[95FA7A30:01C427B9] Content-Transfer-Encoding: quoted-printable Subject: [tcpm] (no subject) Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable [Few late comments] Although I have not read the draft thoroughly, I believe it's probably a = good idea to fist define the scope of the problem that this working = group should try to solve. TCP has a lot of vulnerabilities -- lot more = than what this draft identifies -- and it's better to first define which = problems should be solved and which one should not be. (Also, if the = problem exists only because of BGP, which I don't think is the case, = then maybe routers can use IPSec with a well known permanent shared key = with different session keys. This will be more secure, compared to this = draft, and faster to deploy.) Moreover, it will also be useful to specify if the proposed solutions = can use cryptography or not. Many people are not comfortable with = cryptographic techniques partly because of throughput reasons. But in = many cases it might be useful to have a low computation cryptographic = methods to solve the problems without hurting the throughput. For = example, a TCP sender with Time Stamp option could just encrypt the 32 = bit timestamp using AES, and practically solve all the problems in this = draft. (I am not saying we should do this). Encrypting a 32 bit number = doesn't take a lot of time/computation and the receiver doesn't need to = keep states to make this work. And, in principle it's not different from = having a challenge response cookie.) --yogesh ext Mark Allman wrote: I support this being a working group document. However, rather than worrying about the name of the draft, I would imagine that getting comments / feedback on the draft is the more important part. Do the chairs plan to try to get feedback on the draft and progress the draft rather quickly? =20 We welcome technical comments. We are always interested in timely comments. But, we do not have an apriori timeline that we have not revealed. As sketched in my first note today we are not pre-supposing that the ideas in the draft are even the best fixes. If everyone could read the drafts and send their comments to the list, that'd be great! allman -- Mark Allman -- ICIR -- =20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 18:21:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23138 for ; Wed, 21 Apr 2004 18:21:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGPoz-0002F9-5J for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 18:03:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LM3v2I008618 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 18:03:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGOh0-0006GH-Rs for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 16:51:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13510 for ; Wed, 21 Apr 2004 16:51:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGOgy-0002jx-RK for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 16:51:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGOfq-0002Xg-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 16:50:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGOf6-0002Lk-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 16:49:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGOYf-00030u-0B; Wed, 21 Apr 2004 16:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGKB0-0007nR-QS for tcpm@optimus.ietf.org; Wed, 21 Apr 2004 12:02:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28850 for ; Wed, 21 Apr 2004 12:02:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGKAz-0007fU-JV for tcpm@ietf.org; Wed, 21 Apr 2004 12:02:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGK9n-0007Qs-00 for tcpm@ietf.org; Wed, 21 Apr 2004 12:01:04 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGK95-000779-00 for tcpm@ietf.org; Wed, 21 Apr 2004 12:00:19 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 21 Apr 2004 08:10:21 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3LFxl7t027253; Wed, 21 Apr 2004 08:59:47 -0700 (PDT) Received: from cisco.com (rtp-dial-1-162.cisco.com [10.83.97.162]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATF60817; Wed, 21 Apr 2004 08:59:44 -0700 (PDT) Message-ID: <40869A69.2070607@cisco.com> Date: Wed, 21 Apr 2004 10:59:37 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anantha Ramaiah CC: sanjay kaniyar , tcpm@ietf.org Subject: Re: [tcpm] I-D ACTION:draft-ietf-tcpm-tcpsecure-00.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Anantha: I agree with you... we need to fix this... but also it may not even be worth the extra code to check these conditions and generate a ACK accordingly.. it is a real real corner case... R Anantha Ramaiah wrote: >Sanjay, > Randall can answer this but we thought about this case it is >one of the *real corner cases* Good eye :) > >Actually B could be reworded as : > >C) If the SYN bit is set and the sequence number(isn) is one less then the >next expected sequence (RCV.NXT) then send an ACK segment with the peer >but subtracting one from RCV.NXT. to the peer. > ie SEG.SEQ = (RCV.NXT - 1) > >By sending a ACK that is less than the RCV.NXT value in case of a spoofed >segment the true peer will drop the ACK as an old duplicate. The restart >case also gets satisfied and the reset would be sent back! > >Most of the TCP stacks treat (RCV.NXT - 1) as an RST of a keepalive packet >and would accept that. Hmm.. we may have a corner case here in case if >the RST gets dropped because of outside window. > >Also the suggestion of sending the RST for an exact match (SEG.SEQ = >TCB.RCVNXT) was thought about, but the idea to squeeze as much as possible >to make the attacker's life harder.. Probably needs more thought to >address this corner case. > >Randall and Mitesh may have more comments here.. > >-Anantha >On Tue, 20 Apr 2004, sanjay kaniyar wrote: > > > >>Hello, >> >>I read through the draft and there might be an issue with how it deals with >>one of the reconnect cases. My question is outlined below: >> >>------------------------------------------------------------------------ >>Let's consider the case where we have server[S] implementing this draft >>and a client[C] which is trying to connect to it and the ISS chosen by >>the client happens to be the same as the next expected sequence number >>on server. >> >>[S] >>Sitting in established state. >>RcvNxt = x >>SndUna = SndNxt = SndMax = y >> >>[C] >>comes up after a reboot, >>tries to reconnect to [S] (chooses the same 4-tuple) >>ISS = x >>Sends a SYN (seq = x, Ack = invalid) >> >>Follwing 3.2 (B), [S] sends back an ACK >> >> If the SYN bit is set and the sequence number is an exact match to >> the next expected sequence (RCV.NXT == SEG.SEQ) then send an ACK >> segment to the peer but before sending the ACK segment subtract >> one from value being acknowledged. >> >>[S] -> [C], ACK (seq = y, Ack = x) >> >>The segment reaches the client. >> >>[C] follows RFC 793 - and does the following: >> >> If the state is SYN-SENT then >> first check the ACK bit >> If the ACK bit is set >> If SEG.ACK =< ISS, or SEG.ACK > SND.NXT, send a reset (unless >> the RST bit is set, if so drop the segment and return) >> >> and discard the segment. Return. >> >>[C] -> [S], RST (seq = x, Ack = invalid) >> >>The Reset reaches the server: >> >>[S] follows (either 793 or the draft 2.2 [A]): >> >> A) If the RST bit is set and the sequence number is outside the >> expected window, silently drop the segment. >> >>.. and drops the RST. >> >> >>The client might/will retry a few times - but each time the sequence of >>events is the same - and this results in a valid connect attempt from >>succeeding - which would not have happened had the server followed RFC 793 >>processing rules. >> >>My suggestion would be to abort the connection at [S] when ISS == RcvNxt. >>That would take care of this problem while not being any easier to exploit >>than just sending a RST is. >> >>Thanks, >>Sanjay >> >>_________________________________________________________________ >>Get rid of annoying pop-up ads with the new MSN Toolbar ? FREE! >>http://toolbar.msn.com/go/onm00200414ave/direct/01/ >> >> >>_______________________________________________ >>tcpm mailing list >>tcpm@ietf.org >>https://www1.ietf.org/mailman/listinfo/tcpm >> >> >> > > > -- Randall R. Stewart ITD - Transport Technologies 815-477-2127(o) or 815-342-5222(c) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 18:21:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23162 for ; Wed, 21 Apr 2004 18:21:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGPp0-0002Gp-Ri for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 18:03:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LM3wEY008722 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 18:03:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGOj0-0006mZ-1Y for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 16:53:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13570 for ; Wed, 21 Apr 2004 16:53:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGOiy-000357-15 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 16:53:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGOgl-0002iZ-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 16:51:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGOfd-0002Vg-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 16:50:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGOYh-00031L-B8; Wed, 21 Apr 2004 16:43:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGK7l-0005tp-1O for tcpm@optimus.ietf.org; Wed, 21 Apr 2004 11:58:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28725 for ; Wed, 21 Apr 2004 11:58:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGK7j-00075I-Qa for tcpm@ietf.org; Wed, 21 Apr 2004 11:58:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGK6k-0006vi-00 for tcpm@ietf.org; Wed, 21 Apr 2004 11:57:55 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGK5y-0006eP-00 for tcpm@ietf.org; Wed, 21 Apr 2004 11:57:06 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 21 Apr 2004 08:07:08 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3LFuP8k028393; Wed, 21 Apr 2004 08:56:33 -0700 (PDT) Received: from cisco.com (rtp-dial-1-162.cisco.com [10.83.97.162]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATF60290; Wed, 21 Apr 2004 08:56:23 -0700 (PDT) Message-ID: <408699A0.8070409@cisco.com> Date: Wed, 21 Apr 2004 10:56:16 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mallman@icir.org CC: Florian Weimer , Jeremy Harris , tcpm@ietf.org Subject: Re: [tcpm] new work item: TCP security issue References: <20040421154244.2C46E77A6D5@guns.icir.org> In-Reply-To: <20040421154244.2C46E77A6D5@guns.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mark Allman wrote: >>One would have to treat this situation (assuming we went with >>a cookie.. or has we call it in SCTP a v-tag) like SCTP does... >> >>i.e. you would need to have a bit to indicate that its "your tag" >>not the one I normally sent... >> >> > >I'm not the sharpest tool so you're going to have to be a bit more >verbose... because I cannot parse the above at all. > >Thanks, >allman > > >-- >Mark Allman -- ICIR -- http://www.icir.org/mallman/ > > > > > No its probably me.. In SCTP we do at setup E-A E-Z ------ ------- INIT(itag=X)----------------------> <-----------INIT-ACK(itag=Y)---- Now every packet must have the expected tag ------vtag=Y,DATA----------------> or <----------vtag=X,DATA------- So E-Z always expects to se the tag Y and E-A always expects to see the tag X in any packet. However.. if say one endpoint restarts.. lets say E-Z. When E-A sends a packet ------------vtag=Y,DATA----------> E-Z wants to reset it... so it sends <----------vtag=Y,ABORT(SPECIAL-Flag) if it does not have the v-tag (which it would not in a restart case). If it did have the vtag (had not destroyed the TCB) it would send <----------vtag=X,ABORT So: 1) We always send the tag of the peer, if known. 2) In the few corner cases where we don't know the peers tag and are sending a reset or such in response to a packet, we set a special flag and send the tag that was in the packet that caused us to send the response packet.. Is that better??? R -- Randall R. Stewart ITD - Transport Technologies 815-477-2127(o) or 815-342-5222(c) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 18:22:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23231 for ; Wed, 21 Apr 2004 18:22:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGPp8-0002Pa-Ra for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 18:04:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LM46Z1009256 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 18:04:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGOlT-0007UO-Ow for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 16:56:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13788 for ; Wed, 21 Apr 2004 16:56:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGOlR-0003jP-NH for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 16:56:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGOkZ-0003Wf-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 16:55:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGOji-0003Jq-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 16:54:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGOZg-0003Qn-Aj; Wed, 21 Apr 2004 16:44:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGJU4-0000Ss-4n for tcpm@optimus.ietf.org; Wed, 21 Apr 2004 11:17:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27033 for ; Wed, 21 Apr 2004 11:17:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGJU3-0000JE-6S for tcpm@ietf.org; Wed, 21 Apr 2004 11:17:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGJT3-00008a-00 for tcpm@ietf.org; Wed, 21 Apr 2004 11:16:54 -0400 Received: from seraph3.grc.nasa.gov ([128.156.10.12]) by ietf-mx with esmtp (Exim 4.12) id 1BGJS1-0007dZ-00 for tcpm@ietf.org; Wed, 21 Apr 2004 11:15:49 -0400 Received: from lombok-fi.grc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id C38046B9C6 for ; Wed, 21 Apr 2004 11:15:16 -0400 (EDT) Received: from drpepper.grc.nasa.gov (drpepper.grc.nasa.gov [139.88.122.76]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id i3LFFG3c016914; Wed, 21 Apr 2004 11:15:16 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501) id CBCDE289DF; Wed, 21 Apr 2004 11:12:01 -0400 (EDT) Date: Wed, 21 Apr 2004 11:12:01 -0400 From: Wesley Eddy To: tcpm@ietf.org, lars.eggert@netlab.nec.de Message-ID: <20040421151201.GC32188@grc.nasa.gov> Reply-To: weddy@grc.nasa.gov Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZmUaFz6apKcXQszQ" Content-Disposition: inline X-People-Whose-Mailers-Cant-See-This-Header-Are-Lame: true User-Agent: Mutt/1.5.5.1i Subject: [tcpm] draft-eggert-tcpm-tcp-abort-timeout-option-00.txt Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --ZmUaFz6apKcXQszQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Is there really a need to allow the first ACK to carry an ATO? It should be enough to just allow them on the SYN and SYN-ACK. If a host sends an ATO of X on a SYN and gets back an ATO of X-Y on the SYN-ACK, it probably won't want to go any shorter than X-Y, as that's already shorter than it requested. If the SYN-ACK carries a value too-low, then it's just tough luck, because it's likely a web server (or similar) saying "I'm too busy to just keep your state around forever, but I am willing to hold onto it for exactly this long". No matter how politely you ask in an ATO on a ACK you send back, I don't think it'll be convinced to oblige you with the longer ATO (and you'll have no way of knowing since it's not allowed to send any more ATO options back at that point). Removing the ability to send an ATO on the first ACK would rid the draft of some inconsistency (ie between figure 2 and the first paragraph of 2.1). -Wes --ZmUaFz6apKcXQszQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAho9BzBuYqbnj3IwRAqcnAKCEERn7G21pR5YUvFeU3cayNKoU+wCcCaAf LLvxLMWZ1ntYyf2BkFikx5E= =s/BX -----END PGP SIGNATURE----- --ZmUaFz6apKcXQszQ-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 18:22:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23243 for ; Wed, 21 Apr 2004 18:22:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGPpB-0002Tk-Fd for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 18:04:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LM492P009522 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 18:04:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGOmM-0008CY-93 for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 16:57:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13833 for ; Wed, 21 Apr 2004 16:57:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGOmK-0003vr-7k for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 16:57:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGOlM-0003il-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 16:56:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGOkS-0003Vi-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 16:55:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGOZj-0003S8-39; Wed, 21 Apr 2004 16:44:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGKuB-0002R8-9p for tcpm@optimus.ietf.org; Wed, 21 Apr 2004 12:48:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01719 for ; Wed, 21 Apr 2004 12:48:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGKu9-0000cl-K2 for tcpm@ietf.org; Wed, 21 Apr 2004 12:48:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGKtA-0000Sc-00 for tcpm@ietf.org; Wed, 21 Apr 2004 12:47:57 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGKs8-0000Ac-00 for tcpm@ietf.org; Wed, 21 Apr 2004 12:46:52 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 21 Apr 2004 08:56:52 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3LGkH7t016413; Wed, 21 Apr 2004 09:46:17 -0700 (PDT) Received: from cisco.com (rtp-dial-1-162.cisco.com [10.83.97.162]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATF69406; Wed, 21 Apr 2004 09:46:15 -0700 (PDT) Message-ID: <4086A550.30003@cisco.com> Date: Wed, 21 Apr 2004 11:46:08 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tcpm@ietf.org, Don Lewis Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all: Don Lewis from FreeBSD has raised this point to me privately.. and I thought it worth sharing... " From what I see here: I am concerned that step C will not solve the compatibility problem. The FreeBSD host is sending a FIN to close an established connection, and the peer host adding the window size advertised in the FIN packet to the sequence number acknowledged in the FIN packet, and using the sum as the sequence number for the RST packet, which puts the sequence number at the end of the receive window. " Don: I am still a bit fuzzy on this scenario... could you do something like: E-A E-Z --------------FIN(ack=X)----------------------------------> <----------------------------RST(ack=Y)----------------- and spell this out for me. Thanks Rb -- Randall R. Stewart ITD - Transport Technologies 815-477-2127(o) or 815-342-5222(c) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 18:22:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23321 for ; Wed, 21 Apr 2004 18:22:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGPpJ-0002ci-E7 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 18:04:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LM4HYe010080 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 18:04:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGOqU-0001WD-E7 for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 17:01:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14114 for ; Wed, 21 Apr 2004 17:01:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGOqS-0004j3-8r for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 17:01:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGOpV-0004Y2-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 17:00:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGOp7-0004M9-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 17:00:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGOZo-0003Ti-9k; Wed, 21 Apr 2004 16:44:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGL4u-0006Ku-Hq for tcpm@optimus.ietf.org; Wed, 21 Apr 2004 13:00:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02159 for ; Wed, 21 Apr 2004 13:00:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGL4s-0002Nb-II for tcpm@ietf.org; Wed, 21 Apr 2004 13:00:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGL3x-0002EL-00 for tcpm@ietf.org; Wed, 21 Apr 2004 12:59:06 -0400 Received: from mail1.cray.com ([136.162.0.111]) by ietf-mx with esmtp (Exim 4.12) id 1BGL3D-0001vB-00 for tcpm@ietf.org; Wed, 21 Apr 2004 12:58:20 -0400 Received: from relayb.mw.cray.com (relayb.us.cray.com [192.168.252.110]) by mail1.cray.com (8.12.10/8.12.10/gw-1.4) with ESMTP id i3LGvgFj001786 for ; Wed, 21 Apr 2004 11:57:43 -0500 (CDT) Received: from saffron.us.cray.com (saffron.mw.cray.com [172.31.27.14]) by relayb.mw.cray.com (8.12.11/8.12.10/hub-1.3) with ESMTP id i3LGvdP4005240 for ; Wed, 21 Apr 2004 11:57:40 -0500 (CDT) Received: from [172.31.18.222] (restive [172.31.18.222]) by saffron.us.cray.com (8.12.10/8.12.8/badger-1.4) with ESMTP id i3LGvdWd397715 for ; Wed, 21 Apr 2004 11:57:39 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <20040420200340.E690777A9EB@guns.icir.org> References: <20040420200340.E690777A9EB@guns.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: David Borman Subject: Re: [tcpm] new work item: TCP security issue Date: Wed, 21 Apr 2004 11:57:33 -0500 To: tcpm@ietf.org X-Mailer: Apple Mail (2.613) X-Cray-VirusStatus: clean Content-Transfer-Encoding: quoted-printable Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, Well, all the discussion about process has been interesting, but I'd=20 like to discuss the actual changes suggested in the draft. I received=20= initial information about this over a month ago, and I've already spent=20= a fair amount of time analyzing these 3 items. They do change TCP's=20 behavior wrt SYN packets. To state the obvious, these only address blind attacks. If the bad guy=20= can see any of the packets for the connection that is being attacked,=20 you can't do anything to the TCP protocol to protect things, except use=20= IPsec. Using application level security like SSH does not secure the=20 TCP connection, and so they are still vulnerable to these types of=20 attacks. What the draft addresses is the probability that an attacker=20= can forge a packet with a format that will be accepted as valid. This=20= story has made a splash on the news wires, and I think there's a bit of=20= "the sky is falling" in them. But then, that's what the news media=20 does, right? First, the RST issue. RST packets can be used to reset a connection,=20 and you just have to get it anywhere in the window, not an exact=20 sequence match. The additional check is that if the RST isn't exactly=20= what we expect it to be, generate an ACK, and if the original RST was=20 valid, another RST will be generated in response to that ACK with an=20 exact match and then the connection will be dropped. If the original=20 RST was bogus, our ACK will be ignored and the connection stays up. I=20= can think of some end-case scenarios where the second valid RST might=20 still not be exact, but that would just generate another ACK and it=20 should become deterministic at some point and the RST be accepted. The=20= only way you'd get into trouble would be if someone was generating an=20 RST in response to an ACK, and not properly swapping the seq/ack=20 fields. If that happened, you could get into an RST/ACK war... The change for in-window SYN processing actually changes TCP's=20 behavior. Currently, if you get a SYN in-window, you abort the=20 connection and send a RST back to the other side. So, the attacker=20 just has to get the SYN in the window to blow the connection away. The=20= change is to generate a current =C5CK in response to a SYN, and if the=20= SYN was legitimage, our ACK will cause a RST to be generated, which=20 will cause our half-open connection to be dropped. The change to TCP=20 is that the other side is still up, and when the SYN gets=20 retransmitted, we'll establish a new connection. This new connection=20 will have its sequence space overlapping the window of the old=20 half-open connection, so we now have the possibility that the new=20 connection will get and accept packets from the old connection... On the item of data injection, I haven't totally convinced myself of=20 the ((SND.UNA - MAX.SND.WND) <=3D SEG.ACK < SND.NXT) check. For a unidirectional data transfer, this isn't a problem,=20 because SEG.ACK remains constant. I'm wondering about the=20 bi-directional data transfer case, but I haven't come up with an=20 example yet to either prove or disprove that this check will not throw=20= away legitimate packets (but if it did, it should be a transient issue=20= and the retransmitted packets should have more current ACK information=20= and get accepted). Note that in the extreme case of using a window=20 scale of 14, and advertising the whole window (2^30), these changes=20 don't really provide much protection, since you'll have almost 1/2 of=20 the sequence space as being valid for the ACK check. If they can guess=20= an in-window sequence number (easier, since it's 1/4 of the sequence=20 space), they just a couple of packets with different ACK values should=20= get one of them into the connection. This protects things best when=20 the maximum window is kept small. Anyway, those are my initial comments, I'm sure others will have other=20= insights into this. (It's nice not to be under NDA anymore about this) -David Borman, dab@cray.com On Apr 20, 2004, at 3:03 PM, Mark Allman wrote: > > Just announced internet-draft: >> Title : Transmission Control Protocol security=20 >> considerations >> Author(s) : R. Stewart >> Filename : draft-ietf-tcpm-tcpsecure-00.txt >> Pages : 10 >> Date : 2004-4-20 >> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt > > Hi folks! > > We wanted to announce a new I-D and TCPM work item. The draft is > "Transmission Control Protocol security considerations" > (draft-ietf-tcpm-tcpsecure-00.txt). We believe we owe a bit in the = way > of explanation since it seems that this is being foisted upon the WG > without much input. > > The brief story is that a bunch of folks were made aware of the TCP > security vulnerability outlined in the above draft. (I think many > people have been aware of these things for a long time. But, the=20 > driver > here is that there is a new conference paper that is going to show the > ease with which the vulnerability can be exploited.) Many people from=20= > a > number of TCP implementers (vendors) have been busily working behind=20= > the > scenes to come up with reasonable fixes before the vulnerability was > announced. The fixes are in the I-D. The vulnerability has been > announced (via the standard security issues venues). As part of this > process Randall Stewart wrote the above mentioned I-D for this WG to > ponder. > > A few notes since this I-D got adopted as a WG item with zero public / > open input: > > * Until the vulnerability was announced we didn't want to entertain = a > huge discussion on the public mailing list for obvious reasons. > > * The transport ADs, security ADs and TCPM WG chairs all agreed that > this is an important problem to address and that TCPM is the=20 > correct > WG in which to address it. That said, if folks think we made the > wrong call here, please feel free to speak up and tell us why we > screwed up. > > * The fixes suggested in the above I-D are not being pre-judged as > *THE* answer. Rather, they represent *A POSSIBLE* solution (and > running code) that this WG will consider. In other words, we are > not trying to simply ram this document through the WG and produce=20= > an > RFC. This WG will deliberate on the I-D as it would any other. > > * Alternate solutions are welcome. We would like to encourage folks > who have different solutions to the problems outlined in the draft > to put those forward for consideration. > > Any other comments folks have on this draft / issue are very welcome. > > Thanks! > > Mark & Ted > > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 18:28:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24267 for ; Wed, 21 Apr 2004 18:28:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGPqy-0003bw-Js for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 18:06:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LM60Ao013875 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 18:06:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGP4s-0000rh-7l for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 17:16:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14915 for ; Wed, 21 Apr 2004 17:16:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGP4q-0007nm-1C for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 17:16:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGP3z-0007bU-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 17:15:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGP34-0007Px-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 17:14:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGOah-0003xo-1X; Wed, 21 Apr 2004 16:45:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGMTH-00031K-I8 for tcpm@optimus.ietf.org; Wed, 21 Apr 2004 14:29:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06222 for ; Wed, 21 Apr 2004 14:29:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGMTE-0001fF-VU for tcpm@ietf.org; Wed, 21 Apr 2004 14:29:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGMSG-0001Ul-00 for tcpm@ietf.org; Wed, 21 Apr 2004 14:28:17 -0400 Received: from cs180204.pp.htv.fi ([213.243.180.204] helo=hades.pp.htv.fi ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BGMRk-0001K5-00 for tcpm@ietf.org; Wed, 21 Apr 2004 14:27:44 -0400 Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.11/8.12.11/Debian-4) with ESMTP id i3LISCpA023926; Wed, 21 Apr 2004 21:28:13 +0300 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.11/8.12.11/Debian-4) id i3LISAUq023923; Wed, 21 Apr 2004 21:28:10 +0300 Subject: RE: [tcpm] I-D ACTION:draft-ietf-tcpm-tcpsecure-00.txt From: Mika Liljeberg To: sanjay kaniyar Cc: rrs@cisco.com, tcpm@ietf.org In-Reply-To: References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Message-Id: <1082572090.29392.2062.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 21 Apr 2004 21:28:10 +0300 Content-Transfer-Encoding: quoted-printable Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Fast recovery and SACK already assume that the maximum reordering distance in the network is 3 segments or less. The ack validation rule could be specified simply as: [SND.UNA - N * MSS, SND.NXT], where N =3D 3 No need to make it too fancy. Also, I believe SND.NXT is correct in the above. RFC793 does not recognize SND.MAX. Backing SND.NXT to SND.UNA on retransmit is a feature of a particular implementation, not something prescribed by RFC793. Regards, MikaL On Wed, 2004-04-21 at 10:00, sanjay kaniyar wrote: > Section [4.2]: >=20 > I think this mitigation can be strengthened. For connections with larger=20 > (scaled) window sizes, the protection offered by ACK validation is quite=20 > minimal. >=20 > Here is a suggestion to improve upon what you have for long lived=20 > connections with large windows which send/receive data intermittently:=20 > Consider a connection between a server [S] and a client [C]. A TCP can ne= ver=20 > send more than a receive window worth of data in a given RTT. This can be= =20 > used in validating the ACK number as well. Let the RTT as seen by S be=20 > RTT(S) and maximum receive window ever seen by S (advertised by C) be=20 > MaxSndWnd. Let=92s assume the maximum amount of time we expect a reordere= d=20 > segment sent by C to stay in the network be N * RTT(S) (I know =96 it is = MSL=20 > in theory). This means, the ACK number on a segment that S accepts should= be=20 > between {SndMax} and {SndMax - N * MaxSndWnd}. N should be reduced by 1 e= ach=20 > RTT S does not send any data on this connection, eventually becoming just= 1=20 > byte (SndUna). >=20 > For simplicity, one could just start with [SndUna - MaxSndWnd, SndMax] an= d=20 > clamp it down to [SndUna] if the connection does not send anything for 1=20 > MSL. >=20 > Thanks, > Sanjay >=20 > _________________________________________________________________ > FREE pop-up blocking with the new MSN Toolbar =96 get it now!=20 > http://toolbar.msn.com/go/onm00200415ave/direct/01/ >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 18:32:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25397 for ; Wed, 21 Apr 2004 18:32:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQ2R-0004Ht-4T for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 18:17:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LMHp30016477 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 18:17:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGPBQ-0005N0-LD for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 17:23:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15570 for ; Wed, 21 Apr 2004 17:23:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGPBO-0001jM-BY for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 17:23:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGP8P-0000u7-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 17:19:57 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGP6e-0000JF-05 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 17:18:09 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BGOyi-0007ja-78 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 17:09:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGOa2-0003XA-IB; Wed, 21 Apr 2004 16:44:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGLdp-00028j-Is for tcpm@optimus.ietf.org; Wed, 21 Apr 2004 13:36:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03507 for ; Wed, 21 Apr 2004 13:36:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGLdn-0000Jk-BC for tcpm@ietf.org; Wed, 21 Apr 2004 13:36:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGLcq-00009A-00 for tcpm@ietf.org; Wed, 21 Apr 2004 13:35:09 -0400 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 1BGLby-0007do-00 for tcpm@ietf.org; Wed, 21 Apr 2004 13:34:14 -0400 Received: from lombok-fi.grc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 160906897F for ; Wed, 21 Apr 2004 13:33:44 -0400 (EDT) Received: from sunfire.grc.nasa.gov (IDENT:postfix@sunfire.grc.nasa.gov [139.88.111.70]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id i3LHXh3c000215 for ; Wed, 21 Apr 2004 13:33:43 -0400 (EDT) Received: by sunfire.grc.nasa.gov (Postfix, from userid 500) id 81537BC218; Wed, 21 Apr 2004 13:35:09 -0400 (EDT) Date: Wed, 21 Apr 2004 13:35:09 -0400 From: Joseph Ishac To: tcpm@ietf.org Subject: Re: [tcpm] Re: draft-eggert-tcpm-tcp-abort-timeout-option-00.txt Message-ID: <20040421133509.A24692@sunfire.grc.nasa.gov> Reply-To: Joseph Ishac Mail-Followup-To: tcpm@ietf.org References: <20040421151201.GC32188@grc.nasa.gov> <40869644.2020509@netlab.nec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <40869644.2020509@netlab.nec.de>; from lars.eggert@netlab.nec.de on Wed, Apr 21, 2004 at 05:41:56PM +0200 Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 From my understanding: Page 3, Last Paragraph should read: Either/Or and not Both/And (or the "as well as" used in the text) Reason being that both the initiator and responder cannot initiate a negotiation of an ATO. As the initiator, the ATO if any, must be in the SYN. As a result the SYN/ACK will carry the reply to that ATO if any. The responder cannot 'initiate an ATO' if the initiator has already done so. However the responder can 'initiate an ATO' if the initiator simply sends a SYN without an ATO request. That's my take on the proposal... using the terminology in the draft. Confusion probably arises from the use of 'initiator' and 'responder' in the text. Also, I don't remember if I read it specifically, or if I just implied it... If an ATO is negotiated, I'm assuming both sides use that value. Finally, is it worth specifying what action should be taken if the ATO response is *larger* than the original request. Is the ATO rejected or accepted at the initial value? -Joseph On Wed, Apr 21, 2004 at 05:41:56PM +0200, Lars Eggert wrote: > Wesley, > > Wesley Eddy wrote: > > Is there really a need to allow the first ACK to carry an ATO? It > > should be enough to just allow them on the SYN and SYN-ACK. If a host > > sends an ATO of X on a SYN and gets back an ATO of X-Y on the SYN-ACK, it > > probably won't want to go any shorter than X-Y, as that's already shorter > > than it requested. > > thanks for the feedback. Allowing an ATO exchange using either the > SYN/SYN-ACK segment pair or the SYN-ACK/ACK pair gives both the > initiator and responder of a TCP connection (the client and server, if > you will) the option of starting an ATO negotiation. Restricting it to > the SYN/SYN-ACK means that only the initiator can request an ATO > negotiation. This may be OK for most current uses of the option, but a > more general solution can be useful. > > A negotiation always involves two segments. So in the example you give, > the initiator cannot currently continue the negotiation using the first > ACK. It made its offer in the SYN and got the response in the SYN-ACK. > > > If the SYN-ACK carries a value too-low, then it's just tough luck, > > because it's likely a web server (or similar) saying "I'm too busy to > > just keep your state around forever, but I am willing to hold onto it > > for exactly this long". > > That's true, and I should point out in the draft that using the option > to negotiate lower-than-default timouts is useful for exactly such cases. > > > Removing the ability to send an ATO on the first ACK would rid the draft > > of some inconsistency (ie between figure 2 and the first paragraph of 2.1). > > I see no inconsistency - but the wording may need some improvement. The > idea is that an INITIATOR can only use a segment with the SYN flag for > its ATO offer, i.e., the SYN and SYN-ACK. The RESPONDER will respond in > the very next segment, which obviously cannot be the initial SYN but > must be either the SYN-ACK or first ACK. > > Does this clarify the intent? > > Lars > -- > Lars Eggert NEC Network Laboratories _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 18:33:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25485 for ; Wed, 21 Apr 2004 18:33:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQ2U-0004LD-UG for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 18:17:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LMHsn5016683 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 18:17:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGPBo-0005bH-Er for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 17:23:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15664 for ; Wed, 21 Apr 2004 17:23:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGPBm-0001nD-3M for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 17:23:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGP8j-0000zj-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 17:20:18 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGP6g-0000Ke-01 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 17:18:10 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BGOwe-0007i3-Po for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 17:07:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGOZw-0003VI-JJ; Wed, 21 Apr 2004 16:44:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGLOF-00051g-Ss for tcpm@optimus.ietf.org; Wed, 21 Apr 2004 13:20:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02753 for ; Wed, 21 Apr 2004 13:20:01 -0400 (EDT) From: Yogesh.Swami@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGLOD-0005RF-RJ for tcpm@ietf.org; Wed, 21 Apr 2004 13:20:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGLNE-0005IC-00 for tcpm@ietf.org; Wed, 21 Apr 2004 13:19:01 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BGLME-00058a-00 for tcpm@ietf.org; Wed, 21 Apr 2004 13:17:58 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3LHHs322446 for ; Wed, 21 Apr 2004 20:17:54 +0300 (EET DST) X-Scanned: Wed, 21 Apr 2004 20:17:38 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3LHHcEY010146 for ; Wed, 21 Apr 2004 20:17:38 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00z8320G; Wed, 21 Apr 2004 20:17:36 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3LHHXF11422 for ; Wed, 21 Apr 2004 20:17:34 +0300 (EET DST) Received: from daebe004.NOE.Nokia.com ([10.241.35.104]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 21 Apr 2004 12:17:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: FW: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt Date: Wed, 21 Apr 2004 12:17:34 -0500 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE02885695@daebe004.americas.nokia.com> Thread-Index: AcQnub//Aqp4YU6vT6mMoZhV+4DD2QACtePQ To: X-OriginalArrivalTime: 21 Apr 2004 17:17:35.0187 (UTC) FILETIME=[89C7EA30:01C427C4] Content-Transfer-Encoding: quoted-printable Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Attempt #2 > -----Original Message----- > From: Swami Yogesh (Nokia-NRC/Dallas) =20 > Sent: Wednesday, April 21, 2004 10:59 AM > To: tcpm@ietf.org > Subject:=09 >=20 > [Few late comments] >=20 > Although I have not read the draft thoroughly, I believe it's probably = a good idea to fist define the scope of the problem that this working = group should try to solve. TCP has a lot of vulnerabilities -- lot more = than what this draft identifies -- and it's better to first define which = problems should be solved and which one should not be. (Also, if the = problem exists only because of BGP, which I don't think is the case, = then maybe routers can use IPSec with a well known permanent shared key = with different session keys. This will be more secure, compared to this = draft, and faster to deploy.) >=20 > Moreover, it will also be useful to specify if the proposed solutions = can use cryptography or not. Many people are not comfortable with = cryptographic techniques partly because of throughput reasons. But in = many cases it might be useful to have a low computation cryptographic = methods to solve the problems without hurting the throughput. For = example, a TCP sender with Time Stamp option could just encrypt the 32 = bit timestamp using AES, and practically solve all the problems in this = draft. (I am not saying we should do this). Encrypting a 32 bit number = doesn't take a lot of time/computation and the receiver doesn't need to = keep states to make this work. And, in principle it's not different from = having a challenge response cookie.) >=20 > --yogesh >=20 > ext Mark Allman wrote: > I support this being a working group document. However, rather than > worrying about the name of the draft, I would imagine that getting > comments / feedback on the draft is the more important part. Do the > chairs plan to try to get feedback on the draft and progress the = draft > rather quickly? > =20 >=20 > We welcome technical comments. We are always interested in timely > comments. But, we do not have an apriori timeline that we have not > revealed. As sketched in my first note today we are not pre-supposing > that the ideas in the draft are even the best fixes. If everyone = could > read the drafts and send their comments to the list, that'd be great! >=20 > allman >=20 >=20 > -- > Mark Allman -- ICIR -- >=20 > =20 >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 19:22:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29598 for ; Wed, 21 Apr 2004 19:22:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQe5-0002Yr-9b for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 18:56:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LMujsY009841 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 18:56:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQMf-00017g-So for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 18:38:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26077 for ; Wed, 21 Apr 2004 18:38:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGQMc-000371-SS for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 18:38:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGQLR-0002sk-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 18:37:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGQKy-0002gb-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 18:37:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQ40-0005zJ-Qv; Wed, 21 Apr 2004 18:19:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGPHg-0007kQ-Gd for tcpm@optimus.ietf.org; Wed, 21 Apr 2004 17:29:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16475 for ; Wed, 21 Apr 2004 17:29:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGPHe-0003Bx-4O for tcpm@ietf.org; Wed, 21 Apr 2004 17:29:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGPEg-0002VR-00 for tcpm@ietf.org; Wed, 21 Apr 2004 17:26:26 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGPBM-0001dA-00 for tcpm@ietf.org; Wed, 21 Apr 2004 17:23:00 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 21 Apr 2004 13:34:17 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3LLMTW9003148; Wed, 21 Apr 2004 14:22:29 -0700 (PDT) Received: from mdalal-u10.cisco.com (mdalal-u10.cisco.com [128.107.162.178]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id ASH74238; Wed, 21 Apr 2004 14:21:42 -0700 (PDT) Message-Id: <200404212121.ASH74238@mira-sjc5-b.cisco.com> Date: Wed, 21 Apr 2004 14:22:28 -0700 (PDT) From: Mitesh Dalal Reply-To: Mitesh Dalal Subject: Re: FW: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt To: tcpm@ietf.org, Yogesh.Swami@nokia.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: h7lcIx8BzjwHM+HL9hq8Bw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 >> -----Original Message----- >> From: Swami Yogesh (Nokia-NRC/Dallas) >> Sent: Wednesday, April 21, 2004 10:59 AM >> To: tcpm@ietf.org >> Subject: >> >> [Few late comments] >> >> Although I have not read the draft thoroughly, I believe it's probably a good idea to fist define the scope of the problem that this working group should try to solve. TCP has a lot of vulnerabilities -- lot more than what this draft identifies -- and it's better to first define which problems should be solved and which one should not be. (Also, if the problem exists only because of BGP, which I don't think is the case, then maybe routers can use IPSec with a well known permanent shared key with different session keys. This will be more secure, compared to this draft, and faster to deploy.) >> Yogesh, the idea is to address blind attack from an attacker sitting outside your path to the peer. The current problem is critical because it takes fewer packets than originally believed. By lots of vulnerabilities I assume you mean brute force attacks such as SYN attack, reflection attacks and man in the middle kind of attack. We are clearly not addressing these. I would be glad to hear if you have come across similar vulnerabilities as the current draft tries to address. >> Moreover, it will also be useful to specify if the proposed solutions can use cryptography or not. Many people are not comfortable with cryptographic techniques partly because of throughput reasons. But in many cases it might be useful to have a low computation cryptographic methods to solve the problems without hurting the throughput. For example, a TCP sender with Time Stamp option could just encrypt the 32 bit timestamp using AES, and practically solve all the problems in this draft. (I am not saying we should do this). Encrypting a 32 bit number doesn't take a lot of time/computation and the receiver doesn't need to keep states to make this work. And, in principle it's not different from having a challenge response cookie.) Cryptographic solutions have their own limitations. They have to be setup at both ends and have to be agreed upon. In the current solution you only need to worry about your side (fix is backward compatible), even if the other side is not up-to-date with patches, the fix will still work. thx Mitesh >> >> --yogesh >> >> ext Mark Allman wrote: >> I support this being a working group document. However, rather than >> worrying about the name of the draft, I would imagine that getting >> comments / feedback on the draft is the more important part. Do the >> chairs plan to try to get feedback on the draft and progress the draft >> rather quickly? >> >> >> We welcome technical comments. We are always interested in timely >> comments. But, we do not have an apriori timeline that we have not >> revealed. As sketched in my first note today we are not pre-supposing >> that the ideas in the draft are even the best fixes. If everyone could >> read the drafts and send their comments to the list, that'd be great! >> >> allman >> >> >> -- >> Mark Allman -- ICIR -- >> >> >> > >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www1.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 19:23:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29756 for ; Wed, 21 Apr 2004 19:23:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQgV-0003OB-4o for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 18:59:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LMxFw3013017 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 18:59:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQRB-0003pt-TC for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 18:43:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26613 for ; Wed, 21 Apr 2004 18:43:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGQR8-0004MU-VJ for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 18:43:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGQQA-00047L-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 18:42:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGQPC-0003qn-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 18:41:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQ73-0000WP-Gu; Wed, 21 Apr 2004 18:22:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGPeG-0006y0-V8 for tcpm@optimus.ietf.org; Wed, 21 Apr 2004 17:52:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19389 for ; Wed, 21 Apr 2004 17:52:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGPeE-00010s-Br for tcpm@ietf.org; Wed, 21 Apr 2004 17:52:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGPcP-0000cv-00 for tcpm@ietf.org; Wed, 21 Apr 2004 17:51:00 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGPaT-0007kl-00 for tcpm@ietf.org; Wed, 21 Apr 2004 17:48:57 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 21 Apr 2004 13:59:03 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3LLmQW9022819; Wed, 21 Apr 2004 14:48:26 -0700 (PDT) Received: from mdalal-u10.cisco.com (mdalal-u10.cisco.com [128.107.162.178]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id ASH77427; Wed, 21 Apr 2004 14:47:39 -0700 (PDT) Message-Id: <200404212147.ASH77427@mira-sjc5-b.cisco.com> Date: Wed, 21 Apr 2004 14:48:25 -0700 (PDT) From: Mitesh Dalal Reply-To: Mitesh Dalal Subject: Re: [tcpm] new work item: TCP security issue To: tcpm@ietf.org, dab@cray.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-MD5: NMRMVh4x3ujYABT5vrzH3A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Transfer-Encoding: QUOTED-PRINTABLE >From: David Borman >Hi, > >Well, all the discussion about process has been interesting, but I'd=20 >like to discuss the actual changes suggested in the draft. I received=20 >initial information about this over a month ago, and I've already spent=20 >a fair amount of time analyzing these 3 items. They do change TCP's=20 >behavior wrt SYN packets. > >To state the obvious, these only address blind attacks. If the bad guy=20 >can see any of the packets for the connection that is being attacked,=20 >you can't do anything to the TCP protocol to protect things, except use=20 >IPsec. Using application level security like SSH does not secure the=20 >TCP connection, and so they are still vulnerable to these types of=20 >attacks. What the draft addresses is the probability that an attacker=20 >can forge a packet with a format that will be accepted as valid. This=20 >story has made a splash on the news wires, and I think there's a bit of=20 >"the sky is falling" in them. But then, that's what the news media=20 >does, right? > >First, the RST issue. RST packets can be used to reset a connection,=20 >and you just have to get it anywhere in the window, not an exact=20 >sequence match. The additional check is that if the RST isn't exactly=20 >what we expect it to be, generate an ACK, and if the original RST was=20 >valid, another RST will be generated in response to that ACK with an=20 >exact match and then the connection will be dropped. If the original=20 >RST was bogus, our ACK will be ignored and the connection stays up. I=20 >can think of some end-case scenarios where the second valid RST might=20 >still not be exact, but that would just generate another ACK and it=20 >should become deterministic at some point and the RST be accepted. The=20 >only way you'd get into trouble would be if someone was generating an=20 >RST in response to an ACK, and not properly swapping the seq/ack=20 >fields. If that happened, you could get into an RST/ACK war... that would be a buggy implementation and we would be doing them a favor by exposing this bug :) >The change for in-window SYN processing actually changes TCP's=20 >behavior. Currently, if you get a SYN in-window, you abort the=20 >connection and send a RST back to the other side. So, the attacker=20 >just has to get the SYN in the window to blow the connection away. The=20 >change is to generate a current =C5CK in response to a SYN, and if the=20 >SYN was legitimage, our ACK will cause a RST to be generated, which=20 >will cause our half-open connection to be dropped. The change to TCP=20 >is that the other side is still up, and when the SYN gets=20 >retransmitted, we'll establish a new connection. This new connection=20 >will have its sequence space overlapping the window of the old=20 >half-open connection, so we now have the possibility that the new=20 >connection will get and accept packets from the old connection... From the above context by half open, I assume you mean in ESTAB from your end. The problem you have described above can also happen in a standard setup. Lets assume peering between 2 BGP systems. One end sends RST. Connection is closed and comes up again (fast enough!)=20 and happens to have the same sequence space. A packet delayed in=20 network for the old connection lands up in the new connection.=20 Same behavior should manifest, correct ? >On the item of data injection, I haven't totally convinced myself of=20 >the >=09((SND.UNA - MAX.SND.WND) <=3D SEG.ACK < SND.NXT) >check. For a unidirectional data transfer, this isn't a problem,=20 >because SEG.ACK remains constant. I'm wondering about the=20 >bi-directional data transfer case, but I haven't come up with an=20 >example yet to either prove or disprove that this check will not throw=20 >away legitimate packets (but if it did, it should be a transient issue=20 >and the retransmitted packets should have more current ACK information=20 >and get accepted). Note that in the extreme case of using a window=20 >scale of 14, and advertising the whole window (2^30), these changes=20 >don't really provide much protection, since you'll have almost 1/2 of=20 >the sequence space as being valid for the ACK check. If they can guess=20 >an in-window sequence number (easier, since it's 1/4 of the sequence=20 >space), they just a couple of packets with different ACK values should=20 >get one of them into the connection. This protects things best when=20 >the maximum window is kept small. yes, the advantage decreases as the window size increases. thx Mitesh >Anyway, those are my initial comments, I'm sure others will have other=20 >insights into this. (It's nice not to be under NDA anymore about this) > >=09=09=09-David Borman, dab@cray.com > > >On Apr 20, 2004, at 3:03 PM, Mark Allman wrote: > >> >> Just announced internet-draft: >>> Title : Transmission Control Protocol security=20 >>> considerations >>> Author(s) : R. Stewart >>> Filename : draft-ietf-tcpm-tcpsecure-00.txt >>> Pages : 10 >>> Date : 2004-4-20 >>> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt >> >> Hi folks! >> >> We wanted to announce a new I-D and TCPM work item. The draft is >> "Transmission Control Protocol security considerations" >> (draft-ietf-tcpm-tcpsecure-00.txt). We believe we owe a bit in the way >> of explanation since it seems that this is being foisted upon the WG >> without much input. >> >> The brief story is that a bunch of folks were made aware of the TCP >> security vulnerability outlined in the above draft. (I think many >> people have been aware of these things for a long time. But, the=20 >> driver >> here is that there is a new conference paper that is going to show the >> ease with which the vulnerability can be exploited.) Many people from= =20 >> a >> number of TCP implementers (vendors) have been busily working behind=20 >> the >> scenes to come up with reasonable fixes before the vulnerability was >> announced. The fixes are in the I-D. The vulnerability has been >> announced (via the standard security issues venues). As part of this >> process Randall Stewart wrote the above mentioned I-D for this WG to >> ponder. >> >> A few notes since this I-D got adopted as a WG item with zero public / >> open input: >> >> * Until the vulnerability was announced we didn't want to entertain a >> huge discussion on the public mailing list for obvious reasons. >> >> * The transport ADs, security ADs and TCPM WG chairs all agreed that >> this is an important problem to address and that TCPM is the=20 >> correct >> WG in which to address it. That said, if folks think we made the >> wrong call here, please feel free to speak up and tell us why we >> screwed up. >> >> * The fixes suggested in the above I-D are not being pre-judged as >> *THE* answer. Rather, they represent *A POSSIBLE* solution (and >> running code) that this WG will consider. In other words, we are >> not trying to simply ram this document through the WG and produce=20 >> an >> RFC. This WG will deliberate on the I-D as it would any other. >> >> * Alternate solutions are welcome. We would like to encourage folks >> who have different solutions to the problems outlined in the draft >> to put those forward for consideration. >> >> Any other comments folks have on this draft / issue are very welcome. >> >> Thanks! >> >> Mark & Ted >> >> >> > > >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www1.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 19:23:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29790 for ; Wed, 21 Apr 2004 19:23:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQgW-0003Qs-U2 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 18:59:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LMxGlq013185 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 18:59:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQT3-0004NG-48 for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 18:45:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26734 for ; Wed, 21 Apr 2004 18:45:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGQT0-0004kY-6D for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 18:45:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGQSA-0004aC-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 18:44:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGQRf-0004P9-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 18:43:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQ7A-0000YF-Hu; Wed, 21 Apr 2004 18:22:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGPfL-000736-Gc for tcpm@optimus.ietf.org; Wed, 21 Apr 2004 17:53:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19622 for ; Wed, 21 Apr 2004 17:53:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGPfI-0001JX-SN for tcpm@ietf.org; Wed, 21 Apr 2004 17:53:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGPeM-00012E-00 for tcpm@ietf.org; Wed, 21 Apr 2004 17:52:58 -0400 Received: from mail.enyo.de ([212.9.189.167]) by ietf-mx with esmtp (Exim 4.12) id 1BGPcf-0000fN-00 for tcpm@ietf.org; Wed, 21 Apr 2004 17:51:13 -0400 Received: (debugging) helo=deneb ip=212.9.189.171 name=deneb.enyo.de Received: from deneb.enyo.de ([212.9.189.171] helo=deneb) by mail.enyo.de with esmtp id 1BGPcf-0001SR-5B; Wed, 21 Apr 2004 23:51:13 +0200 Received: from fw by deneb with local (Exim 4.32) id 1BGPcd-0002Se-FR; Wed, 21 Apr 2004 23:51:11 +0200 To: Yogesh.Swami@nokia.com Cc: Subject: Re: [tcpm] (no subject) References: <025E7DD4182874489CC2F61EE0FA19CE016E80E6@daebe004.americas.nokia.com> From: Florian Weimer Date: Wed, 21 Apr 2004 23:51:11 +0200 In-Reply-To: <025E7DD4182874489CC2F61EE0FA19CE016E80E6@daebe004.americas.nokia.com> (Yogesh Swami's message of "Wed, 21 Apr 2004 10:59:10 -0500") Message-ID: <87wu49f19s.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Yogesh.Swami@nokia.com writes: > (Also, if the problem exists only because of BGP, which I don't > think is the case, BGP is in the focus because it sounds important (it surely is) and somewhat mystic. Of course, IRC is also affected. But other TCP-based services have pretty low reconnect costs (initially, this was also true of BGP, I assume). In this case, attack costs and its impact relate more unfavorbly to the attacker. > then maybe routers can use IPSec with a well known permanent shared > key with different session keys. This will be more secure, compared > to this draft, and faster to deploy.) I don't think IPsec on core routers is faster to deploy. RFC 2385 should be enough for now, but also has got its issues (higher CPU consumption for processing packets). IPsec would share these issues or would result in even more overhead. > Moreover, it will also be useful to specify if the proposed solutions > can use cryptography or not. Many people are not comfortable with > cryptographic techniques partly because of throughput reasons. Exactly. Keep in mind that 200 MHz MIPS CPUs are widely deployed. > But in many cases it might be useful to have a low computation > cryptographic methods to solve the problems without hurting the > throughput. For example, a TCP sender with Time Stamp option could > just encrypt the 32 bit timestamp using AES, and practically solve > all the problems in this draft. What about a new TCP option which contains a few random bytes that are constant for each connection? This option could be checked very cheaply, maybe some day even by those ASICs which operate at wirespeed. > (I am not saying we should do this). Encrypting a 32 bit > number doesn't take a lot of time/computation and the receiver doesn't > need to keep states to make this work. And, in principle it's not > different from having a challenge response cookie.) You have to encrypt a full 128 bit block, and I doubt it would be much cheaper than MD5/RFC 2385. -- Current mail filters: many dial-up/DSL/cable modem hosts, and the following domains: atlas.cz, bigpond.com, postino.it, tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 19:39:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00984 for ; Wed, 21 Apr 2004 19:39:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGR50-0008Ow-Jb for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 19:24:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LNOYuu032258 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 19:24:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQjx-00056b-OE for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 19:02:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28304 for ; Wed, 21 Apr 2004 19:02:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGQju-0000uo-HB for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 19:02:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGQj7-0000dx-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 19:01:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGQhm-0000JE-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 19:00:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQWh-0006JP-4k; Wed, 21 Apr 2004 18:49:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQ9h-0001TL-Ut for tcpm@optimus.ietf.org; Wed, 21 Apr 2004 18:25:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23566 for ; Wed, 21 Apr 2004 18:25:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGQ9f-0007gK-0o for tcpm@ietf.org; Wed, 21 Apr 2004 18:25:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGQ3o-0006ZG-00 for tcpm@ietf.org; Wed, 21 Apr 2004 18:19:17 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGPz0-0005Ks-00 for tcpm@ietf.org; Wed, 21 Apr 2004 18:14:18 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 21 Apr 2004 14:24:24 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3LMDkW9011897; Wed, 21 Apr 2004 15:13:46 -0700 (PDT) Received: from cisco.com (ananth-u5.cisco.com [128.107.162.225]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATG23972; Wed, 21 Apr 2004 15:13:45 -0700 (PDT) Message-ID: <4086F219.4BFCE2F5@cisco.com> Date: Wed, 21 Apr 2004 15:13:45 -0700 From: Anantha Ramaiah Organization: Cisco Systems X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Mika Liljeberg CC: sanjay kaniyar , rrs@cisco.com, tcpm@ietf.org Subject: Re: [tcpm] I-D ACTION:draft-ietf-tcpm-tcpsecure-00.txt References: <1082572090.29392.2062.camel@hades> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Wanted to reply to this yesterday. I agree with MikaL that SND.NXT is correct in the proposed equation. Backing SND.NXT to SND.UNA is done in the BSD based stacks and it is not a RFC requirement. I am also inclined to have a fixed range for acceptability otherwise it becomes more implementation specific. An implementation can chose to add intelligence into it by considering the MSS and RTT etc and decide the N. The question then becomes should RFC recommend tha math or probably suggest some preferable values ? The hard issue is chosing the value of N. It needs to be conservative ( as any RFC is) and should accomadate various networks for eg: the networks with high bandwidth * delay (LFN's) where assuming the network re-ordering distance to be 3 is kind of aggressive. -Anantha Mika Liljeberg wrote: > > Fast recovery and SACK already assume that the maximum reordering > distance in the network is 3 segments or less. The ack validation rule > could be specified simply as: > > [SND.UNA - N * MSS, SND.NXT], where N = 3 > > No need to make it too fancy. > > Also, I believe SND.NXT is correct in the above. RFC793 does not > recognize SND.MAX. Backing SND.NXT to SND.UNA on retransmit is a feature > of a particular implementation, not something prescribed by RFC793. > > Regards, > > MikaL > > On Wed, 2004-04-21 at 10:00, sanjay kaniyar wrote: > > Section [4.2]: > > > > I think this mitigation can be strengthened. For connections with larger > > (scaled) window sizes, the protection offered by ACK validation is quite > > minimal. > > > > Here is a suggestion to improve upon what you have for long lived > > connections with large windows which send/receive data intermittently: > > Consider a connection between a server [S] and a client [C]. A TCP can never > > send more than a receive window worth of data in a given RTT. This can be > > used in validating the ACK number as well. Let the RTT as seen by S be > > RTT(S) and maximum receive window ever seen by S (advertised by C) be > > MaxSndWnd. Let?s assume the maximum amount of time we expect a reordered > > segment sent by C to stay in the network be N * RTT(S) (I know - it is MSL > > in theory). This means, the ACK number on a segment that S accepts should be > > between {SndMax} and {SndMax - N * MaxSndWnd}. N should be reduced by 1 each > > RTT S does not send any data on this connection, eventually becoming just 1 > > byte (SndUna). > > > > For simplicity, one could just start with [SndUna - MaxSndWnd, SndMax] and > > clamp it down to [SndUna] if the connection does not send anything for 1 > > MSL. > > > > Thanks, > > Sanjay > > > > _________________________________________________________________ > > FREE pop-up blocking with the new MSN Toolbar - get it now! > > http://toolbar.msn.com/go/onm00200415ave/direct/01/ > > > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www1.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 19:39:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01006 for ; Wed, 21 Apr 2004 19:39:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGR51-0008Rd-Hr for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 19:24:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LNOZqr032425 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 19:24:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQkk-0005Uf-Ol for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 19:03:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28344 for ; Wed, 21 Apr 2004 19:03:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGQkh-00019F-IB for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 19:03:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGQjb-0000rx-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 19:02:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGQiZ-0000Yi-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 19:01:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQWj-0006KX-VC; Wed, 21 Apr 2004 18:49:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQBp-0001zY-49 for tcpm@optimus.ietf.org; Wed, 21 Apr 2004 18:27:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23789 for ; Wed, 21 Apr 2004 18:27:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGQBm-0000Lo-6g for tcpm@ietf.org; Wed, 21 Apr 2004 18:27:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGQ5Y-0006uX-00 for tcpm@ietf.org; Wed, 21 Apr 2004 18:21:05 -0400 Received: from mail.enyo.de ([212.9.189.167]) by ietf-mx with esmtp (Exim 4.12) id 1BGQ1L-0005r2-00 for tcpm@ietf.org; Wed, 21 Apr 2004 18:16:43 -0400 Received: (debugging) helo=deneb ip=212.9.189.171 name=deneb.enyo.de Received: from deneb.enyo.de ([212.9.189.171] helo=deneb) by mail.enyo.de with esmtp id 1BGPl2-0001mi-40 for tcpm@ietf.org; Wed, 21 Apr 2004 23:59:52 +0200 Received: from fw by deneb with local (Exim 4.32) id 1BGPl0-0002UX-BE for tcpm@ietf.org; Wed, 21 Apr 2004 23:59:50 +0200 To: tcpm@ietf.org Subject: Re: [tcpm] new work item: TCP security issue References: <20040420200340.E690777A9EB@guns.icir.org> From: Florian Weimer Date: Wed, 21 Apr 2004 23:59:50 +0200 In-Reply-To: <20040420200340.E690777A9EB@guns.icir.org> (Mark Allman's message of "Tue, 20 Apr 2004 16:03:40 -0400") Message-ID: <87smexf0vd.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I don't qyite like sending ACKs for RSTs. This might result in a loop when one side generates an ACK, the other side replies with an RST, and the first side sends the next ACK. Of course, the sequence and port numbers have to match. But if there are implementations out there that interact in this way, you might create a cure that is far worse than the disease. At least you should mention the requirement of rate-limiting those ACKs. (It's implicit for IOS because of the limits on the RST processing, but not for general implementations.) -- Current mail filters: many dial-up/DSL/cable modem hosts, and the following domains: atlas.cz, bigpond.com, postino.it, tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 19:44:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01387 for ; Wed, 21 Apr 2004 19:44:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGRFa-000563-Oq for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 19:35:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LNZUe3019586 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 19:35:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGR3x-00074w-Sy for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 19:23:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29705 for ; Wed, 21 Apr 2004 19:23:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGR3w-0005MS-98 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 19:23:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGR2y-00057f-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 19:22:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGR22-0004uE-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 19:21:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQdO-0002Kh-Pj; Wed, 21 Apr 2004 18:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQIV-0006Xh-0M for tcpm@optimus.ietf.org; Wed, 21 Apr 2004 18:34:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25724 for ; Wed, 21 Apr 2004 18:34:22 -0400 (EDT) From: Yogesh.Swami@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGQIR-0002Bl-Mg for tcpm@ietf.org; Wed, 21 Apr 2004 18:34:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGQGw-0001hM-00 for tcpm@ietf.org; Wed, 21 Apr 2004 18:32:50 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BGQFZ-0001II-00 for tcpm@ietf.org; Wed, 21 Apr 2004 18:31:26 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3LMVI325453; Thu, 22 Apr 2004 01:31:18 +0300 (EET DST) X-Scanned: Thu, 22 Apr 2004 01:30:44 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3LMUiB3023365; Thu, 22 Apr 2004 01:30:44 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00OdCV07; Thu, 22 Apr 2004 01:30:43 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3LMUds22579; Thu, 22 Apr 2004 01:30:39 +0300 (EET DST) Received: from daebe004.NOE.Nokia.com ([10.241.35.104]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 21 Apr 2004 17:30:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: FW: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt Date: Wed, 21 Apr 2004 17:30:38 -0500 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE02885696@daebe004.americas.nokia.com> Thread-Topic: FW: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt Thread-Index: AcQn5yLj7IPqIKQST2G8/f5yUaHHhwAABjCw To: , X-OriginalArrivalTime: 21 Apr 2004 22:30:40.0424 (UTC) FILETIME=[46A79A80:01C427F0] Content-Transfer-Encoding: quoted-printable Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Mitesh- > -----Original Message----- > From: ext Mitesh Dalal [mailto:mdalal@cisco.com] > Sent: Wednesday, April 21, 2004 4:22 PM > To: tcpm@ietf.org; Swami Yogesh (Nokia-NRC/Dallas) > Subject: Re: FW: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt=20 >=20 >=20 >=20 > >> -----Original Message----- > >> From: Swami Yogesh (Nokia-NRC/Dallas) =20 > >> Sent: Wednesday, April 21, 2004 10:59 AM > >> To: tcpm@ietf.org > >> Subject:=09 > >>=20 > >> [Few late comments] > >>=20 > >> Although I have not read the draft thoroughly, I believe=20 > it's probably a good=20 > idea to fist define the scope of the problem that this=20 > working group should try=20 > to solve. TCP has a lot of vulnerabilities -- lot more than=20 > what this draft=20 > identifies -- and it's better to first define which problems=20 > should be solved=20 > and which one should not be. (Also, if the problem exists=20 > only because of BGP,=20 > which I don't think is the case, then maybe routers can use=20 > IPSec with a well=20 > known permanent shared key with different session keys. This=20 > will be more=20 > secure, compared to this draft, and faster to deploy.) > >>=20 >=20 > Yogesh, > the idea is to address blind attack from an attacker sitting=20 > outside your > path to the peer. The current problem is critical because it=20 > takes fewer > packets than originally believed.=20 >=20 I don't know if the problem is critical or not and I wasn't questing = that. Sending 65,535 RST messages might be a problem for BGP, but in the = broader context of TCP it might not be. A very simple intrusion = detection system can (and already do) detect and drop such bursts of = packets, especially when each packet has the same socket attribute. > By lots of vulnerabilities I assume you mean brute force attacks such=20 > as SYN attack, reflection attacks and man in the middle kind=20 > of attack.=20 No, by lots of vulnerabilities, I don't mean brute force attacks. = Resetting a TCP connection might be a problem for BGP but might not the = best MO for other kinds of blind attacks. For example, an attacker who = wants to do blind DDoS attacks, might want to use exploit other TCP = vulnerabilities (e.g., use ECN to reduce data rate) to reduce the = connection handling capacity of the server than resetting the = connections altogether.=20 If the draft tries to make TCP more secure, as the title suggests, it = needs to take a broader look than just BGP. Or it should explicitly say: = "we are not looking at ..." (which is also perfectly alright with me). = That's why I said it's better to define the scope of the problem. > We are clearly not addressing these. I would be glad to hear=20 > if you have > come across similar vulnerabilities as the current draft=20 > tries to address. >=20 Although I have not come across these problems myself, conventional = wisdom says that if there is a security vulnerability in a protocol, it = will be exploited sooner or later. The fact that this draft exists today = and did not exist 10 years back, is a good evidence. > >> Moreover, it will also be useful to specify if the=20 > proposed solutions can use=20 > cryptography or not. Many people are not comfortable with=20 > cryptographic=20 > techniques partly because of throughput reasons. But in many=20 > cases it might be=20 > useful to have a low computation cryptographic methods to=20 > solve the problems=20 > without hurting the throughput. For example, a TCP sender=20 > with Time Stamp option=20 > could just encrypt the 32 bit timestamp using AES, and=20 > practically solve all the=20 > problems in this draft. (I am not saying we should do this).=20 > Encrypting a 32 bit=20 > number doesn't take a lot of time/computation and the=20 > receiver doesn't need to=20 > keep states to make this work. And, in principle it's not=20 > different from having=20 > a challenge response cookie.) >=20 > Cryptographic solutions have their own limitations. They have=20 > to be setup > at both ends and have to be agreed upon. In the current=20 Not necessarily. You need setup/key-exchange only if both ends need to = perform cryptographic operations on the same data fields. For TCP we = might not need that. Or we might, depending upon what the working group = considers as a secure solution. And, that exactly what my point was in = the last e-mail.=20 BTW, I doubt you will get easy consensus on the solutions without = precisely defining what "secure TCP" means. Security means different = things to different people at different times of the day. --Yogesh _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 19:47:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01817 for ; Wed, 21 Apr 2004 19:47:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGRMq-0001Wf-2d for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 19:43:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LNh0iD005861 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 19:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGRCm-0004EJ-64 for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 19:32:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00538 for ; Wed, 21 Apr 2004 19:32:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGRCk-0007Te-Ht for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 19:32:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGRBf-0007Cn-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 19:31:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGRAd-0006xD-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 19:30:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQqx-0000Jf-EP; Wed, 21 Apr 2004 19:10:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQZp-0007so-F7 for tcpm@optimus.ietf.org; Wed, 21 Apr 2004 18:52:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27177 for ; Wed, 21 Apr 2004 18:52:16 -0400 (EDT) From: Yogesh.Swami@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGQZm-0006Cc-AZ for tcpm@ietf.org; Wed, 21 Apr 2004 18:52:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGQYr-00061k-00 for tcpm@ietf.org; Wed, 21 Apr 2004 18:51:21 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BGQY3-0005qZ-00 for tcpm@ietf.org; Wed, 21 Apr 2004 18:50:31 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3LMoOd22273; Thu, 22 Apr 2004 01:50:24 +0300 (EET DST) X-Scanned: Thu, 22 Apr 2004 01:50:20 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3LMoK6W029095; Thu, 22 Apr 2004 01:50:20 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00GAm6FQ; Thu, 22 Apr 2004 01:50:18 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3LMoDs00802; Thu, 22 Apr 2004 01:50:14 +0300 (EET DST) Received: from daebe004.NOE.Nokia.com ([10.241.35.104]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 21 Apr 2004 17:49:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] (no subject) Date: Wed, 21 Apr 2004 17:50:00 -0500 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE02885697@daebe004.americas.nokia.com> Thread-Topic: [tcpm] (no subject) Thread-Index: AcQn6utKfTFTgMLGTomeEZyOF0RQRAABlpVg To: Cc: X-OriginalArrivalTime: 21 Apr 2004 22:49:59.0797 (UTC) FILETIME=[F9B1E250:01C427F2] Content-Transfer-Encoding: quoted-printable Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > then maybe routers can use IPSec with a well known permanent shared > > key with different session keys. This will be more secure, compared > > to this draft, and faster to deploy.) >=20 > I don't think IPsec on core routers is faster to deploy. RFC 2385 > should be enough for now, but also has got its issues (higher CPU > consumption for processing packets). IPsec would share these issues > or would result in even more overhead. >=20 I don't know much about router architectures, so I can't really comment = whether IPSec or changing TCP is a better solution. But if I were to = choose between a well defined protocol and a protocol that is still = under discussion in the IETF, I would choose the former. > > Moreover, it will also be useful to specify if the proposed=20 > solutions > > can use cryptography or not. Many people are not comfortable with > > cryptographic techniques partly because of throughput reasons. >=20 > Exactly. Keep in mind that 200 MHz MIPS CPUs are widely deployed. >=20 > > But in many cases it might be useful to have a low computation > > cryptographic methods to solve the problems without hurting the > > throughput. For example, a TCP sender with Time Stamp option could > > just encrypt the 32 bit timestamp using AES, and practically solve > > all the problems in this draft. >=20 > What about a new TCP option which contains a few random bytes that are > constant for each connection? This option could be checked very > cheaply, maybe some day even by those ASICs which operate at > wirespeed. Will work too, but remember that DOFF only allows 15, 32 bit words for = TCP options. With SACK, timestamps etc, there is not a lot of room left = for new options. Of course this is not too big of a problem. >=20 > > (I am not saying we should do this). Encrypting a 32 bit > > number doesn't take a lot of time/computation and the=20 > receiver doesn't > > need to keep states to make this work. And, in principle it's not > > different from having a challenge response cookie.) >=20 > You have to encrypt a full 128 bit block, and I doubt it would be much > cheaper than MD5/RFC 2385. >=20 Yes it will be much cheaper. With MD5/RFC 2385, you compute the hash on = the entire ~1400 byte packet. With AES or a different stream cipher, it = could be a lot less computation. --Yogesh _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 20:32:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04942 for ; Wed, 21 Apr 2004 20:32:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGRxg-000437-HS for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 20:21:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3M0L4xF015563 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 20:21:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGRq5-00086k-5K for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 20:13:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03206 for ; Wed, 21 Apr 2004 20:13:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGRq3-000094-84 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 20:13:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGRov-0007eG-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 20:12:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGRo3-0007Nh-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 20:11:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGRXU-0006qz-Rm; Wed, 21 Apr 2004 19:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGK7q-0005u9-7L for tcpm@optimus.ietf.org; Wed, 21 Apr 2004 11:59:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28747 for ; Wed, 21 Apr 2004 11:58:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGK7o-00075z-WC for tcpm@ietf.org; Wed, 21 Apr 2004 11:59:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGK6t-0006ww-00 for tcpm@ietf.org; Wed, 21 Apr 2004 11:58:04 -0400 Received: from seraph3.grc.nasa.gov ([128.156.10.12]) by ietf-mx with esmtp (Exim 4.12) id 1BGK6X-0006mF-00 for tcpm@ietf.org; Wed, 21 Apr 2004 11:57:41 -0400 Received: from lombok-fi.grc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id CD12B6B9C8 for ; Wed, 21 Apr 2004 11:57:11 -0400 (EDT) Received: from drpepper.grc.nasa.gov (drpepper.grc.nasa.gov [139.88.122.76]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id i3LFvB3c001367; Wed, 21 Apr 2004 11:57:11 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501) id 1ADA9289DF; Wed, 21 Apr 2004 11:53:57 -0400 (EDT) Date: Wed, 21 Apr 2004 11:53:57 -0400 From: Wesley Eddy To: Lars Eggert Cc: tcpm@ietf.org Message-ID: <20040421155357.GD32188@grc.nasa.gov> Reply-To: weddy@grc.nasa.gov References: <20040421151201.GC32188@grc.nasa.gov> <40869644.2020509@netlab.nec.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5p8PegU4iirBW1oA" Content-Disposition: inline In-Reply-To: <40869644.2020509@netlab.nec.de> X-People-Whose-Mailers-Cant-See-This-Header-Are-Lame: true User-Agent: Mutt/1.5.5.1i Subject: [tcpm] Re: draft-eggert-tcpm-tcp-abort-timeout-option-00.txt Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --5p8PegU4iirBW1oA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 21, 2004 at 05:41:56PM +0200, Lars Eggert wrote: >=20 > A negotiation always involves two segments. So in the example you give,= =20 > the initiator cannot currently continue the negotiation using the first= =20 > ACK. It made its offer in the SYN and got the response in the SYN-ACK. > Ah, that makes more sense. =20 > >Removing the ability to send an ATO on the first ACK would rid the draft > >of some inconsistency (ie between figure 2 and the first paragraph of 2.= 1). >=20 > I see no inconsistency - but the wording may need some improvement. The= =20 > idea is that an INITIATOR can only use a segment with the SYN flag for=20 > its ATO offer, i.e., the SYN and SYN-ACK. The RESPONDER will respond in= =20 > the very next segment, which obviously cannot be the initial SYN but=20 > must be either the SYN-ACK or first ACK. >=20 > Does this clarify the intent? Yes quite a bit. Although I see the lack of sending an ATO option on the initial SYN as indicating either "I don't care" or "I don't grok the ATO option", and so in both cases, it won't really matter what the ATO in the SYN-ACK is, because the other side will either be cool with it or not understand it. Keeping with the spirit of other TCP options, it might be best to put the ATO option in the SYN if you understand it, and not put it at all in the SYN-ACK if it wasn't in the SYN, on the goal of not breaking fragile stacks with options they can't parse. That would also remove the need to worry about the option coming in on non-SYN options. It's typical to use differe= nt option parsing routines for syn-set and syn-unset segments (sort of slow and fast paths through the option parsing), and so disallowing an ATO option on the first ACK also simplifies implementation. -Wes --5p8PegU4iirBW1oA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAhpkVzBuYqbnj3IwRAkvAAJ0c7UXGGE8IrK2sx7vwtJQOP7YDAwCghfCX fWnT7x8Jvm6rxSBUBDwc2u4= =Vaun -----END PGP SIGNATURE----- --5p8PegU4iirBW1oA-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 20:40:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05444 for ; Wed, 21 Apr 2004 20:40:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGS8z-00083S-CE for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 20:32:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3M0Wji7030957 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 20:32:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGRy4-00048i-IP for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 20:21:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04008 for ; Wed, 21 Apr 2004 20:21:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGRy2-00028p-J6 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 20:21:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGRxB-0001vy-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 20:20:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGRwL-0001it-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 20:19:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGRp2-0007pQ-Il; Wed, 21 Apr 2004 20:12:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGRee-0000jC-2i for tcpm@optimus.ietf.org; Wed, 21 Apr 2004 20:01:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02476 for ; Wed, 21 Apr 2004 20:01:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGRec-0005Si-5E for tcpm@ietf.org; Wed, 21 Apr 2004 20:01:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGRdg-0005Hj-00 for tcpm@ietf.org; Wed, 21 Apr 2004 20:00:25 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGRcx-0004w9-00 for tcpm@ietf.org; Wed, 21 Apr 2004 19:59:40 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 21 Apr 2004 16:09:46 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3LNx7W9001964; Wed, 21 Apr 2004 16:59:08 -0700 (PDT) Received: from cisco.com (ananth-u5.cisco.com [128.107.162.225]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATG37318; Wed, 21 Apr 2004 16:59:06 -0700 (PDT) Message-ID: <40870ACA.48D7295E@cisco.com> Date: Wed, 21 Apr 2004 16:59:06 -0700 From: Anantha Ramaiah Organization: Cisco Systems X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Yogesh.Swami@nokia.com CC: fw@deneb.enyo.de, tcpm@ietf.org Subject: Re: [tcpm] (no subject) References: <025E7DD4182874489CC2F61EE0FA19CE02885697@daebe004.americas.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Having alternative crypto methods for securing a TCP connection has been discussed before. Also RFC 2385 suggests the provision of having an algorithm type field to be negotiated instead of MD5 and states the reason why that was not pursued at that time.. -Anantha Yogesh.Swami@nokia.com wrote: > > > > then maybe routers can use IPSec with a well known permanent shared > > > key with different session keys. This will be more secure, compared > > > to this draft, and faster to deploy.) > > > > I don't think IPsec on core routers is faster to deploy. RFC 2385 > > should be enough for now, but also has got its issues (higher CPU > > consumption for processing packets). IPsec would share these issues > > or would result in even more overhead. > > > > I don't know much about router architectures, so I can't really comment whether IPSec or changing TCP is a better solution. But if I were to choose between a well defined protocol and a protocol that is still under discussion in the IETF, I would choose the former. > > > > Moreover, it will also be useful to specify if the proposed > > solutions > > > can use cryptography or not. Many people are not comfortable with > > > cryptographic techniques partly because of throughput reasons. > > > > Exactly. Keep in mind that 200 MHz MIPS CPUs are widely deployed. > > > > > But in many cases it might be useful to have a low computation > > > cryptographic methods to solve the problems without hurting the > > > throughput. For example, a TCP sender with Time Stamp option could > > > just encrypt the 32 bit timestamp using AES, and practically solve > > > all the problems in this draft. > > > > What about a new TCP option which contains a few random bytes that are > > constant for each connection? This option could be checked very > > cheaply, maybe some day even by those ASICs which operate at > > wirespeed. > > Will work too, but remember that DOFF only allows 15, 32 bit words for TCP options. With SACK, timestamps etc, there is not a lot of room left for new options. Of course this is not too big of a problem. > > > > > > (I am not saying we should do this). Encrypting a 32 bit > > > number doesn't take a lot of time/computation and the > > receiver doesn't > > > need to keep states to make this work. And, in principle it's not > > > different from having a challenge response cookie.) > > > > You have to encrypt a full 128 bit block, and I doubt it would be much > > cheaper than MD5/RFC 2385. > > > > Yes it will be much cheaper. With MD5/RFC 2385, you compute the hash on the entire ~1400 byte packet. With AES or a different stream cipher, it could be a lot less computation. > > --Yogesh > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 21 21:34:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08772 for ; Wed, 21 Apr 2004 21:34:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGT2y-00016x-R6 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 21:30:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3M1UaMq004266 for tcpm-archive@odin.ietf.org; Wed, 21 Apr 2004 21:30:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGSzy-0008R5-FW for tcpm-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 21:27:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08140 for ; Wed, 21 Apr 2004 21:27:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGSzv-00003z-Pf for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 21:27:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGSyo-0007bQ-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 21:26:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGSxn-0007Hx-00 for tcpm-web-archive@ietf.org; Wed, 21 Apr 2004 21:25:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGSve-0005Mr-3u; Wed, 21 Apr 2004 21:23:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGSlR-0001NF-63 for tcpm@optimus.ietf.org; Wed, 21 Apr 2004 21:12:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07436 for ; Wed, 21 Apr 2004 21:12:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGSlO-0004nC-J3 for tcpm@ietf.org; Wed, 21 Apr 2004 21:12:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGSkW-0004c3-00 for tcpm@ietf.org; Wed, 21 Apr 2004 21:11:32 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1BGSkA-0004QZ-00 for tcpm@ietf.org; Wed, 21 Apr 2004 21:11:11 -0400 Received: from jurassic.eng.sun.com ([129.146.88.130]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i3M1Ad6b022343; Wed, 21 Apr 2004 18:10:39 -0700 (PDT) Received: from sun.com (shield.SFBay.Sun.COM [129.144.60.49]) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i3M1Ad7F909819; Wed, 21 Apr 2004 18:10:39 -0700 (PDT) Message-ID: <40871B8F.7020306@sun.com> Date: Wed, 21 Apr 2004 18:10:39 -0700 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.6) Gecko/20040117 X-Accept-Language: en, zh-hk, zh-tw, zh-cn MIME-Version: 1.0 To: David Borman CC: tcpm@ietf.org Subject: Re: [tcpm] new work item: TCP security issue References: <20040420200340.E690777A9EB@guns.icir.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by nwkea-mail-1.sun.com id i3M1Ad6b022343 Content-Transfer-Encoding: quoted-printable Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable David Borman wrote: > First, the RST issue. RST packets can be used to reset a connection,=20 > and you just have to get it anywhere in the window, not an exact=20 > sequence match. The additional check is that if the RST isn't exactly=20 > what we expect it to be, generate an ACK, and if the original RST was=20 > valid, another RST will be generated in response to that ACK with an=20 > exact match and then the connection will be dropped. If the original=20 > RST was bogus, our ACK will be ignored and the connection stays up. I=20 > can think of some end-case scenarios where the second valid RST might=20 > still not be exact, but that would just generate another ACK and it=20 > should become deterministic at some point and the RST be accepted. The= =20 > only way you'd get into trouble would be if someone was generating an=20 > RST in response to an ACK, and not properly swapping the seq/ack=20 > fields. If that happened, you could get into an RST/ACK war... Yes. What I am worried is interaction with middlebox. I've seen broken stateful middlebox causing ACK war. With this kind of "subtle" change, I think it will hit someone. And since this kind of attack is mostly targeted at a specific type of TCP traffic, such as long lived, I think most implementors are not comfortable in making these changes. > The change for in-window SYN processing actually changes TCP's=20 > behavior. Currently, if you get a SYN in-window, you abort the=20 > connection and send a RST back to the other side. So, the attacker jus= t=20 > has to get the SYN in the window to blow the connection away. The=20 > change is to generate a current =C5CK in response to a SYN, and if the = SYN=20 > was legitimage, our ACK will cause a RST to be generated, which will=20 > cause our half-open connection to be dropped. The change to TCP is tha= t=20 > the other side is still up, and when the SYN gets retransmitted, we'll=20 > establish a new connection. This new connection will have its sequence= =20 > space overlapping the window of the old half-open connection, so we now= =20 > have the possibility that the new connection will get and accept packet= s=20 > from the old connection... Again, ACK is used as a form of challenge/response. It can be considered as "ingenious" or a "hack." > On the item of data injection, I haven't totally convinced myself of t= he > ((SND.UNA - MAX.SND.WND) <=3D SEG.ACK < SND.NXT) > check. For a unidirectional data transfer, this isn't a problem,=20 > because SEG.ACK remains constant. I'm wondering about the=20 > bi-directional data transfer case, but I haven't come up with an exampl= e=20 > yet to either prove or disprove that this check will not throw away=20 > legitimate packets (but if it did, it should be a transient issue and=20 > the retransmitted packets should have more current ACK information and=20 As you mentioned, can this happen in bidirectional transfer with delayed out of order segments and one side is sending faster than the other side? And the probability increases as the number of outstanding segments get big (large window) in both sides. > get accepted). Note that in the extreme case of using a window scale o= f=20 > 14, and advertising the whole window (2^30), these changes don't really= =20 > provide much protection, since you'll have almost 1/2 of the sequence=20 > space as being valid for the ACK check. If they can guess an in-window= =20 > sequence number (easier, since it's 1/4 of the sequence space), they=20 > just a couple of packets with different ACK values should get one of=20 > them into the connection. This protects things best when the maximum=20 > window is kept small. As people have already asked, should we have a more general solution? RFC 2385 is a solution, but it can be expensive and there needs to be a key exchange. Can a simple mechanism similar to SCTP verification tag be used? Randy already explained the mechanism in another mail. It can be enabled by a socket option so that only app protocol vulnerable to this type of attack will use it. And it is simple enough for header compression, if it is needed. What is the issue with that? --=20 K. Poon. kacheong.poon@sun.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu Apr 22 06:28:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16387 for ; Thu, 22 Apr 2004 06:28:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGbPc-0008RY-JT for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 06:26:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MAQWoj032456 for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 06:26:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGbM8-00060M-NZ for tcpm-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 06:22:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16210 for ; Thu, 22 Apr 2004 06:22:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGbM3-0005Mz-0i for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 06:22:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGbL4-00059W-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 06:21:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGbKj-0004w0-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 06:21:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGbCa-0003So-0J; Thu, 22 Apr 2004 06:13:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGb4g-0007bW-Oo for tcpm@optimus.ietf.org; Thu, 22 Apr 2004 06:04:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15684 for ; Thu, 22 Apr 2004 06:04:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGb4b-0001JX-4u for tcpm@ietf.org; Thu, 22 Apr 2004 06:04:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGb3d-00015M-00 for tcpm@ietf.org; Thu, 22 Apr 2004 06:03:50 -0400 Received: from ftp.netlab.nec.de ([195.37.70.21] helo=ftp.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1BGb2x-0000ru-00 for tcpm@ietf.org; Thu, 22 Apr 2004 06:03:07 -0400 Received: from netlab.nec.de (unknown [195.37.70.133]) by ftp.ccrle.nec.de (Postfix) with ESMTP id 6C40CF674; Thu, 22 Apr 2004 12:08:10 +0200 (CEST) Message-ID: <4087985A.5030409@netlab.nec.de> Date: Thu, 22 Apr 2004 12:03:06 +0200 From: Lars Eggert Organization: NEC Network Laboratories User-Agent: Mozilla Thunderbird 0.6+ (Macintosh/20040420) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joseph Ishac Cc: tcpm@ietf.org Subject: Re: [tcpm] Re: draft-eggert-tcpm-tcp-abort-timeout-option-00.txt References: <20040421151201.GC32188@grc.nasa.gov> <40869644.2020509@netlab.nec.de> <20040421133509.A24692@sunfire.grc.nasa.gov> In-Reply-To: <20040421133509.A24692@sunfire.grc.nasa.gov> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000205040705040605090402" Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms000205040705040605090402 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Joseph, Joseph Ishac wrote: > From my understanding: > > Page 3, Last Paragraph should read: > > Either/Or > and not > Both/And (or the "as well as" used in the text) you're correct, this clarifies the intent - change made. > Reason being that both the initiator and responder cannot initiate a > negotiation of an ATO. As the initiator, the ATO if any, must be in the > SYN. As a result the SYN/ACK will carry the reply to that ATO if any. > The responder cannot 'initiate an ATO' if the initiator has already done > so. However the responder can 'initiate an ATO' if the initiator simply > sends a SYN without an ATO request. Exactly right. > That's my take on the proposal... using the terminology in the draft. > Confusion probably arises from the use of 'initiator' and 'responder' in > the text. I delibertated wether to use client/server or initiator/responder during the description. The latter seemed more accurate, but the former may be more easily understood. Maybe a short paragraph defining the two terms would help? > Also, I don't remember if I read it specifically, or if I just implied > it... If an ATO is negotiated, I'm assuming both sides use that value. This is mentioned in two places, for both the initiator and responder, but stating it explicitly upfront can't hurt. > Finally, is it worth specifying what action should be taken if the ATO > response is *larger* than the original request. Is the ATO rejected or > accepted at the initial value? Following the "be liberal in what you accept" guideline I guess the regular default timeout should be used instead of rejecting and resetting the connection. Lars -- Lars Eggert NEC Network Laboratories --------------ms000205040705040605090402 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ/zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNaMIICw6ADAgECAgMLU6IwDQYJKoZIhvcNAQEE BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTAz MTIxNTEyMzEyOFoXDTA0MTIxNDEyMzEyOFowgYQxDzANBgNVBAQTBkVnZ2VydDENMAsGA1UE KhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdn ZXJ0QG5ldGxhYi5uZWMuZGUxIjAgBgkqhkiG9w0BCQEWE2xhcnMuZWdnZXJ0QGdteC5uZXQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWps58Zq8Buu2DKDl9crbvzSo6zWsZ TkQLr5zOTqUMs/eU7Mcohv64O4IxWWYGLfYsjDRxUlmdHdJUbyTtUh2lH452DUDJByXidlLm RDgohG0AVwztedqy1+hE3VnCdpMhUGks+6ntrr3dKSxMgLM0AM1kPWsH9lWX6IOPdxOC30gM PiQ65zH9PR70befQLgFPKcAv0wP8210l05n8ekwYAcq2cm3/j+nuDu0HEh5pgsnY7cVELeNJ ODvr4IiE1t3c2w4+0Nc/WJrqGCMl+gZ8c+7FtzjoyDeEsCjNFDeA2ymNd+10O6kjwvPHlzPr 3rW73RDRPAjMJ49HXlueiuoNAgMBAAGjdzB1MCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwOQYDVR0RBDIwMIEZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5k ZYETbGFycy5lZ2dlcnRAZ214Lm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB AHgrv3SQFD4AS4lY4oKcI3iTHcclEHbYfg3UUb8zzCUsl+OJoz0nmebGmOL+tvNj5GvCrWnN H4LvVLh8ZBhFXms7eKJ1YiHgbKwTRK23P8Y5NDit5ico0ZjpFWeenUWj3ajEbN6n4K8dNp+C 0b2apnSrlFVWY6BucZFIYqQ1Lf91MIIDWjCCAsOgAwIBAgIDC1OiMA0GCSqGSIb3DQEBBAUA MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wMzEy MTUxMjMxMjhaFw0wNDEyMTQxMjMxMjhaMIGEMQ8wDQYDVQQEEwZFZ2dlcnQxDTALBgNVBCoT BExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2Vy dEBuZXRsYWIubmVjLmRlMSIwIAYJKoZIhvcNAQkBFhNsYXJzLmVnZ2VydEBnbXgubmV0MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1qbOfGavAbrtgyg5fXK2780qOs1rGU5E C6+czk6lDLP3lOzHKIb+uDuCMVlmBi32LIw0cVJZnR3SVG8k7VIdpR+Odg1AyQcl4nZS5kQ4 KIRtAFcM7XnastfoRN1ZwnaTIVBpLPup7a693SksTICzNADNZD1rB/ZVl+iDj3cTgt9IDD4k Oucx/T0e9G3n0C4BTynAL9MD/NtdJdOZ/HpMGAHKtnJt/4/p7g7tBxIeaYLJ2O3FRC3jSTg7 6+CIhNbd3NsOPtDXP1ia6hgjJfoGfHPuxbc46Mg3hLAozRQ3gNspjXftdDupI8Lzx5cz6961 u90Q0TwIzCePR15bnorqDQIDAQABo3cwdTAqBgUrZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVN eWZmQk5VYk5KSmNkWjJzMDkGA1UdEQQyMDCBGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGWB E2xhcnMuZWdnZXJ0QGdteC5uZXQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQB4 K790kBQ+AEuJWOKCnCN4kx3HJRB22H4N1FG/M8wlLJfjiaM9J5nmxpji/rbzY+Rrwq1pzR+C 71S4fGQYRV5rO3iidWIh4GysE0Sttz/GOTQ4reYnKNGY6RVnnp1Fo92oxGzep+CvHTafgtG9 mqZ0q5RVVmOgbnGRSGKkNS3/dTGCAzswggM3AgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwCQYFKw4DAhoFAKCCAacwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwNDIyMTAwMzA2WjAjBgkqhkiG 9w0BCQQxFgQUrVOjcBU/ITtxG+2DB/JBCoeK1ekwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECAwtTojB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwDQYJKoZIhvcNAQEBBQAEggEA MlNKgzn9uV4lVSLcSuGMoiea4nVXsOs2Y9tKl6jm0QJosj6k5c81pj26jMQoNZvou9F3dvz8 LmqYQOEBkWT3Ov46MEcYiXVRoiIUMd/jwvdHnlHYd2QVlFNXdwzaR3atm2SIL9s8u1JeglYW 1q9tT6z9EYpF9WVYBP9VdtB2dpXiGymv2KWSP+x+IvVKr7+2HlbI0dL31tdYbHfaI3FcNgOZ 5m2LxA9pfWXuaZ55Hd5TjyDymgEXVq4gpHhSdzUkWC3//zuXRPAWdZJ04wyl06+RIS/3i496 fiCNTmPR483pV4VTsvN40OQDJddCQFQx1wKO2oJwAD3Qv+fJTjHEyAAAAAAAAA== --------------ms000205040705040605090402-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu Apr 22 09:16:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24915 for ; Thu, 22 Apr 2004 09:16:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdrN-0006a7-6M for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 09:03:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MD3LYV025289 for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 09:03:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdnM-0004i6-Ks for tcpm-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 08:59:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24082 for ; Thu, 22 Apr 2004 08:59:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGdnF-0005lS-Gm for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 08:59:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGdmC-0005WK-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 08:58:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGdlI-0005HF-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 08:57:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdbZ-0000es-79; Thu, 22 Apr 2004 08:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdSr-0006WU-SP for tcpm@optimus.ietf.org; Thu, 22 Apr 2004 08:38:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22839 for ; Thu, 22 Apr 2004 08:37:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGdSl-0000AR-0N for tcpm@ietf.org; Thu, 22 Apr 2004 08:37:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGdRo-0007gs-00 for tcpm@ietf.org; Thu, 22 Apr 2004 08:36:57 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGdQz-00077j-00 for tcpm@ietf.org; Thu, 22 Apr 2004 08:36:05 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 22 Apr 2004 04:46:18 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3MCZXW9016663; Thu, 22 Apr 2004 05:35:34 -0700 (PDT) Received: from cisco.com (rtp-dial-1-212.cisco.com [10.83.97.212]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATG80773; Thu, 22 Apr 2004 05:35:30 -0700 (PDT) Message-ID: <4087ADF8.7040108@cisco.com> Date: Thu, 22 Apr 2004 06:35:20 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anantha Ramaiah CC: Mika Liljeberg , sanjay kaniyar , tcpm@ietf.org Subject: Re: [tcpm] I-D ACTION:draft-ietf-tcpm-tcpsecure-00.txt References: <1082572090.29392.2062.camel@hades> <4086F219.4BFCE2F5@cisco.com> In-Reply-To: <4086F219.4BFCE2F5@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Anantha Ramaiah wrote: >Wanted to reply to this yesterday. I agree with MikaL that SND.NXT is >correct in the proposed equation. Backing SND.NXT to SND.UNA is done in >the BSD based stacks and it is not a RFC requirement. > Ok, I will stick with SND.NXT for the next revision... > >I am also inclined to have a fixed range for acceptability otherwise it >becomes more implementation specific. An implementation can chose to add >intelligence into it by considering the MSS and RTT etc and decide the N. >The question then becomes should RFC recommend tha math or probably suggest >some preferable values ? > >The hard issue is chosing the value of N. It needs to be conservative >( as any RFC is) and should accomadate various networks for eg: >the networks with high bandwidth * delay (LFN's) where assuming the >network re-ordering distance to be 3 is kind of aggressive. > Hmm.. should we instead leave the current equation and add some wording like: "The equation given will allow for any network reordering, a specific implementation MAY wish to use a smaller value then SND.MAX." Word smithing needed of course.. R > >-Anantha >Mika Liljeberg wrote: > > >>Fast recovery and SACK already assume that the maximum reordering >>distance in the network is 3 segments or less. The ack validation rule >>could be specified simply as: >> >> [SND.UNA - N * MSS, SND.NXT], where N = 3 >> >>No need to make it too fancy. >> >>Also, I believe SND.NXT is correct in the above. RFC793 does not >>recognize SND.MAX. Backing SND.NXT to SND.UNA on retransmit is a feature >>of a particular implementation, not something prescribed by RFC793. >> >>Regards, >> >> MikaL >> >>On Wed, 2004-04-21 at 10:00, sanjay kaniyar wrote: >> >> >>>Section [4.2]: >>> >>>I think this mitigation can be strengthened. For connections with larger >>>(scaled) window sizes, the protection offered by ACK validation is quite >>>minimal. >>> >>>Here is a suggestion to improve upon what you have for long lived >>>connections with large windows which send/receive data intermittently: >>>Consider a connection between a server [S] and a client [C]. A TCP can never >>>send more than a receive window worth of data in a given RTT. This can be >>>used in validating the ACK number as well. Let the RTT as seen by S be >>>RTT(S) and maximum receive window ever seen by S (advertised by C) be >>>MaxSndWnd. Let?s assume the maximum amount of time we expect a reordered >>>segment sent by C to stay in the network be N * RTT(S) (I know - it is MSL >>>in theory). This means, the ACK number on a segment that S accepts should be >>>between {SndMax} and {SndMax - N * MaxSndWnd}. N should be reduced by 1 each >>>RTT S does not send any data on this connection, eventually becoming just 1 >>>byte (SndUna). >>> >>>For simplicity, one could just start with [SndUna - MaxSndWnd, SndMax] and >>>clamp it down to [SndUna] if the connection does not send anything for 1 >>>MSL. >>> >>>Thanks, >>>Sanjay >>> >>>_________________________________________________________________ >>>FREE pop-up blocking with the new MSN Toolbar - get it now! >>>http://toolbar.msn.com/go/onm00200415ave/direct/01/ >>> >>> >>>_______________________________________________ >>>tcpm mailing list >>>tcpm@ietf.org >>>https://www1.ietf.org/mailman/listinfo/tcpm >>> >>> >>_______________________________________________ >>tcpm mailing list >>tcpm@ietf.org >>https://www1.ietf.org/mailman/listinfo/tcpm >> >> > > > -- Randall R. Stewart ITD - Transport Technologies 815-477-2127(o) or 815-342-5222(c) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu Apr 22 09:16:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24949 for ; Thu, 22 Apr 2004 09:16:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdrO-0006ai-4G for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 09:03:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MD3Mxv025331 for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 09:03:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdoB-00050c-Th for tcpm-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 09:00:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24138 for ; Thu, 22 Apr 2004 08:59:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGdo4-00060U-Ol for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 08:59:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGdnO-0005mW-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 08:59:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGdmj-0005Xd-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 08:58:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdbZ-0000gE-Me; Thu, 22 Apr 2004 08:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdUo-0006rs-C8 for tcpm@optimus.ietf.org; Thu, 22 Apr 2004 08:40:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22963 for ; Thu, 22 Apr 2004 08:39:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGdUh-0000e4-CU for tcpm@ietf.org; Thu, 22 Apr 2004 08:39:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGdTd-0000Pf-00 for tcpm@ietf.org; Thu, 22 Apr 2004 08:38:49 -0400 Received: from seraph3.grc.nasa.gov ([128.156.10.12]) by ietf-mx with esmtp (Exim 4.12) id 1BGdSn-0007kB-00 for tcpm@ietf.org; Thu, 22 Apr 2004 08:37:57 -0400 Received: from lombok-fi.grc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 569846BA51 for ; Thu, 22 Apr 2004 08:37:29 -0400 (EDT) Received: from drpepper.grc.nasa.gov (drpepper.grc.nasa.gov [139.88.122.76]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id i3MCbS3c014379 for ; Thu, 22 Apr 2004 08:37:29 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501) id 3751D289DF; Thu, 22 Apr 2004 08:34:13 -0400 (EDT) Date: Thu, 22 Apr 2004 08:34:13 -0400 From: Wesley Eddy To: tcpm@ietf.org Message-ID: <20040422123413.GA20156@grc.nasa.gov> Reply-To: weddy@grc.nasa.gov Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline X-People-Whose-Mailers-Cant-See-This-Header-Are-Lame: true User-Agent: Mutt/1.5.5.1i Subject: [tcpm] alternative RST processing Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline As an alternative to combat the blind RST attack, instead of using ACKs for challenge-response, it should also suffice to modify the TCP state machine to not go into CLOSED on a RST, but transition into the TIME-WAIT state. With another transition to come back to ESTABLISHED on receipt of data, this seems like it would work. -Wes --YZ5djTAD1cGYuMQK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAh7vEzBuYqbnj3IwRAvOoAKCKHI47bey9BciJxoT5t3QjR+ya/QCgiZxB zNCkncJW9mFmaw296XsK4uI= =CkSP -----END PGP SIGNATURE----- --YZ5djTAD1cGYuMQK-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu Apr 22 09:29:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25670 for ; Thu, 22 Apr 2004 09:29:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGe5d-00038j-A9 for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 09:18:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MDI5MG012065 for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 09:18:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdsv-00076F-TB for tcpm-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 09:04:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24459 for ; Thu, 22 Apr 2004 09:04:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGdso-0007FG-OI for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 09:04:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGdru-0006zv-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 09:03:55 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGdqx-0006jk-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 09:02:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdjQ-0003xc-Mp; Thu, 22 Apr 2004 08:55:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdaX-0008MC-DM for tcpm@optimus.ietf.org; Thu, 22 Apr 2004 08:45:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23383 for ; Thu, 22 Apr 2004 08:45:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGdaQ-0002Lk-Cg for tcpm@ietf.org; Thu, 22 Apr 2004 08:45:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGdZn-00027w-00 for tcpm@ietf.org; Thu, 22 Apr 2004 08:45:11 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGdYs-0001Wv-00 for tcpm@ietf.org; Thu, 22 Apr 2004 08:44:17 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3MChYW9023802; Thu, 22 Apr 2004 05:43:34 -0700 (PDT) Received: from cisco.com (rtp-dial-1-212.cisco.com [10.83.97.212]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATG81068; Thu, 22 Apr 2004 05:43:32 -0700 (PDT) Message-ID: <4087AFD9.6050201@cisco.com> Date: Thu, 22 Apr 2004 06:43:21 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Florian Weimer CC: tcpm@ietf.org Subject: Re: [tcpm] new work item: TCP security issue References: <20040420200340.E690777A9EB@guns.icir.org> <87smexf0vd.fsf@deneb.enyo.de> In-Reply-To: <87smexf0vd.fsf@deneb.enyo.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Florian Weimer wrote: >I don't qyite like sending ACKs for RSTs. This might result in a loop >when one side generates an ACK, the other side replies with an RST, >and the first side sends the next ACK. Of course, the sequence and >port numbers have to match. But if there are implementations out >there that interact in this way, you might create a cure that is far >worse than the disease. At least you should mention the requirement >of rate-limiting those ACKs. (It's implicit for IOS because of the >limits on the RST processing, but not for general implementations.) > So you are saying that the receiver of the ACK, which in theory sent the RST and has no state, is going to send a subsequent RST with a different value than is in the ACK? If this were true would it not be a bug in the implementation? R > > > -- Randall R. Stewart ITD - Transport Technologies 815-477-2127(o) or 815-342-5222(c) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu Apr 22 09:29:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25687 for ; Thu, 22 Apr 2004 09:29:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGe5k-0003AB-B5 for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 09:18:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MDICNm012151 for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 09:18:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdvq-0008Vs-Ty for tcpm-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 09:07:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24548 for ; Thu, 22 Apr 2004 09:07:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGdvj-0000A8-NE for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 09:07:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGdum-0007ij-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 09:06:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGdtn-0007Tz-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 09:05:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdq8-00060t-B0; Thu, 22 Apr 2004 09:02:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdgO-0002oV-6W for tcpm@optimus.ietf.org; Thu, 22 Apr 2004 08:52:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23611 for ; Thu, 22 Apr 2004 08:51:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGdgH-0003pt-27 for tcpm@ietf.org; Thu, 22 Apr 2004 08:51:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGdfO-0003c5-00 for tcpm@ietf.org; Thu, 22 Apr 2004 08:50:59 -0400 Received: from mail.enyo.de ([212.9.189.167]) by ietf-mx with esmtp (Exim 4.12) id 1BGdeY-0003Nw-00 for tcpm@ietf.org; Thu, 22 Apr 2004 08:50:06 -0400 Received: (debugging) helo=deneb ip=212.9.189.171 name=deneb.enyo.de Received: from deneb.enyo.de ([212.9.189.171] helo=deneb) by mail.enyo.de with esmtp id 1BGdeZ-0005ia-73; Thu, 22 Apr 2004 14:50:07 +0200 Received: from fw by deneb with local (Exim 4.32) id 1BGdeY-00016y-F6; Thu, 22 Apr 2004 14:50:06 +0200 To: "Randall Stewart (cisco)" Cc: tcpm@ietf.org Subject: Re: [tcpm] new work item: TCP security issue References: <20040420200340.E690777A9EB@guns.icir.org> <87smexf0vd.fsf@deneb.enyo.de> <4087AFD9.6050201@cisco.com> From: Florian Weimer Date: Thu, 22 Apr 2004 14:50:06 +0200 In-Reply-To: <4087AFD9.6050201@cisco.com> (Randall Stewart's message of "Thu, 22 Apr 2004 06:43:21 -0500") Message-ID: <87ekqgxjlt.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 "Randall Stewart (cisco)" writes: > So you are saying that the receiver of the ACK, which > in theory sent the RST and has no state, is going to > send a subsequent RST with a different value than > is in the ACK? If this were true would it not be a > bug in the implementation? It would certainly be a bug, but it's something to consider nevertheless, IMHO. -- Current mail filters: many dial-up/DSL/cable modem hosts, and the following domains: atlas.cz, bigpond.com, postino.it, tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu Apr 22 09:53:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26969 for ; Thu, 22 Apr 2004 09:53:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGeLa-0008Dx-OP for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 09:34:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MDYYi2031608 for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 09:34:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGe6j-0003K5-2H for tcpm-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 09:19:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25148 for ; Thu, 22 Apr 2004 09:19:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGe6b-0002tk-Ly for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 09:19:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGe5X-0002d3-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 09:18:00 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGe4f-0002O7-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 09:17:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGds4-0006dH-4B; Thu, 22 Apr 2004 09:04:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdkN-00046Q-60 for tcpm@optimus.ietf.org; Thu, 22 Apr 2004 08:56:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23961 for ; Thu, 22 Apr 2004 08:56:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGdkG-00050f-0X for tcpm@ietf.org; Thu, 22 Apr 2004 08:56:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGdjP-0004j8-00 for tcpm@ietf.org; Thu, 22 Apr 2004 08:55:08 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGdiR-00049d-00 for tcpm@ietf.org; Thu, 22 Apr 2004 08:54:07 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 22 Apr 2004 05:05:33 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3MCraSu024337; Thu, 22 Apr 2004 05:53:36 -0700 (PDT) Received: from cisco.com (rtp-dial-1-212.cisco.com [10.83.97.212]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATG81526; Thu, 22 Apr 2004 05:53:33 -0700 (PDT) Message-ID: <4087B232.4050203@cisco.com> Date: Thu, 22 Apr 2004 06:53:22 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yogesh.Swami@nokia.com CC: mdalal@cisco.com, tcpm@ietf.org Subject: Re: FW: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: <025E7DD4182874489CC2F61EE0FA19CE02885696@daebe004.americas.nokia.com> In-Reply-To: <025E7DD4182874489CC2F61EE0FA19CE02885696@daebe004.americas.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Yogesh: A few comments... First.. the draft name was quickly hacked together.. we can always change the name to reflect that it is a tweak to TCP to tighten things against blind attacks... Does it solve all problem.. no of course not... More comments below... Yogesh.Swami@nokia.com wrote: >Mitesh- > > > >>-----Original Message----- >>From: ext Mitesh Dalal [mailto:mdalal@cisco.com] >>Sent: Wednesday, April 21, 2004 4:22 PM >>To: tcpm@ietf.org; Swami Yogesh (Nokia-NRC/Dallas) >>Subject: Re: FW: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt >> >> >> >> >> >>>> -----Original Message----- >>>>From: Swami Yogesh (Nokia-NRC/Dallas) >>>>Sent: Wednesday, April 21, 2004 10:59 AM >>>>To: tcpm@ietf.org >>>>Subject: >>>> >>>>[Few late comments] >>>> >>>>Although I have not read the draft thoroughly, I believe >>>> >>>> >>it's probably a good >>idea to fist define the scope of the problem that this >>working group should try >>to solve. TCP has a lot of vulnerabilities -- lot more than >>what this draft >>identifies -- and it's better to first define which problems >>should be solved >>and which one should not be. (Also, if the problem exists >>only because of BGP, >>which I don't think is the case, then maybe routers can use >>IPSec with a well >>known permanent shared key with different session keys. This >>will be more >>secure, compared to this draft, and faster to deploy.) >> >> >>Yogesh, >>the idea is to address blind attack from an attacker sitting >>outside your >>path to the peer. The current problem is critical because it >>takes fewer >>packets than originally believed. >> >> >> > >I don't know if the problem is critical or not and I wasn't questing that. Sending 65,535 RST messages might be a problem for BGP, but in the broader context of TCP it might not be. A very simple intrusion detection system can (and already do) detect and drop such bursts of packets, especially when each packet has the same socket attribute. > > > Hmmm... it does not have to be a burst of packets.. they can be paced out to not cause alarm... and in practice it is far less than 64k packets... in general sending a a paced 50pps I was able to reset most TCP connections in a very very short time.. when I first started testing this thing... Now as to BGP and others.. what about H.323 and some of the other VoIP stuff .. I believe not all of them have went with SCTP ... many use TCP.. and these are all vulnerable... and I am sure there are a LOT of other apps that do database connections and such... I don't think this problem is limited to just BGP... > > >>By lots of vulnerabilities I assume you mean brute force attacks such >>as SYN attack, reflection attacks and man in the middle kind >>of attack. >> >> > >No, by lots of vulnerabilities, I don't mean brute force attacks. Resetting a TCP connection might be a problem for BGP but might not the best MO for other kinds of blind attacks. For example, an attacker who wants to do blind DDoS attacks, might want to use exploit other TCP vulnerabilities (e.g., use ECN to reduce data rate) to reduce the connection handling capacity of the server than resetting the connections altogether. > >If the draft tries to make TCP more secure, as the title suggests, it needs to take a broader look than just BGP. Or it should explicitly say: "we are not looking at ..." (which is also perfectly alright with me). That's why I said it's better to define the scope of the problem. > > The lets pick a new name... and yes, I have no problem adding limitation text at the beginning... To quote Scott.. Send text .... R > > >>We are clearly not addressing these. I would be glad to hear >>if you have >>come across similar vulnerabilities as the current draft >>tries to address. >> >> >> > >Although I have not come across these problems myself, conventional wisdom says that if there is a security vulnerability in a protocol, it will be exploited sooner or later. The fact that this draft exists today and did not exist 10 years back, is a good evidence. > > > > >>>>Moreover, it will also be useful to specify if the >>>> >>>> >>proposed solutions can use >>cryptography or not. Many people are not comfortable with >>cryptographic >>techniques partly because of throughput reasons. But in many >>cases it might be >>useful to have a low computation cryptographic methods to >>solve the problems >>without hurting the throughput. For example, a TCP sender >>with Time Stamp option >>could just encrypt the 32 bit timestamp using AES, and >>practically solve all the >>problems in this draft. (I am not saying we should do this). >>Encrypting a 32 bit >>number doesn't take a lot of time/computation and the >>receiver doesn't need to >>keep states to make this work. And, in principle it's not >>different from having >>a challenge response cookie.) >> >>Cryptographic solutions have their own limitations. They have >>to be setup >>at both ends and have to be agreed upon. In the current >> >> > >Not necessarily. You need setup/key-exchange only if both ends need to perform cryptographic operations on the same data fields. For TCP we might not need that. Or we might, depending upon what the working group considers as a secure solution. And, that exactly what my point was in the last e-mail. > >BTW, I doubt you will get easy consensus on the solutions without precisely defining what "secure TCP" means. Security means different things to different people at different times of the day. > >--Yogesh > >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www1.ietf.org/mailman/listinfo/tcpm > > > -- Randall R. Stewart ITD - Transport Technologies 815-477-2127(o) or 815-342-5222(c) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu Apr 22 10:00:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27292 for ; Thu, 22 Apr 2004 10:00:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGeQP-0001B9-E6 for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 09:39:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MDdXP3004527 for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 09:39:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGeHK-0006bn-5t for tcpm-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 09:30:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25748 for ; Thu, 22 Apr 2004 09:30:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGeHC-0005dx-NX for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 09:30:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGeGF-0005Oe-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 09:29:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGeFT-00059K-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 09:28:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGe4b-0002YK-LJ; Thu, 22 Apr 2004 09:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdrF-0006Tl-85 for tcpm@optimus.ietf.org; Thu, 22 Apr 2004 09:03:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24350 for ; Thu, 22 Apr 2004 09:03:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGdr8-0006l1-2n for tcpm@ietf.org; Thu, 22 Apr 2004 09:03:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGdqC-0006VR-00 for tcpm@ietf.org; Thu, 22 Apr 2004 09:02:09 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGdpX-0006Eq-00 for tcpm@ietf.org; Thu, 22 Apr 2004 09:01:30 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3MD0tW9011189; Thu, 22 Apr 2004 06:00:55 -0700 (PDT) Received: from cisco.com (rtp-dial-1-212.cisco.com [10.83.97.212]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATG81915; Thu, 22 Apr 2004 06:00:53 -0700 (PDT) Message-ID: <4087B3EA.8030405@cisco.com> Date: Thu, 22 Apr 2004 07:00:42 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: weddy@grc.nasa.gov CC: tcpm@ietf.org Subject: Re: [tcpm] alternative RST processing References: <20040422123413.GA20156@grc.nasa.gov> In-Reply-To: <20040422123413.GA20156@grc.nasa.gov> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Wesley Eddy wrote: >As an alternative to combat the blind RST attack, instead of using ACKs >for challenge-response, it should also suffice to modify the TCP state >machine to not go into CLOSED on a RST, but transition into the >TIME-WAIT state. With another transition to come back to ESTABLISHED on >receipt of data, this seems like it would work. > >-Wes > > Wes: Would this not cause any TIME-WAIT state connection to "revive" if a old data segment arrives from the network then? R -- Randall R. Stewart ITD - Transport Technologies 815-477-2127(o) or 815-342-5222(c) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu Apr 22 10:03:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27523 for ; Thu, 22 Apr 2004 10:03:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGek4-0006HV-Jl for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 09:59:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MDxqB0024129 for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 09:59:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGeMz-00005c-U4 for tcpm-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 09:36:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26199 for ; Thu, 22 Apr 2004 09:35:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGeMs-0007NT-GQ for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 09:35:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGeLx-00075Z-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 09:34:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGeKz-0006lv-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 09:33:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGe6c-0003Jh-Kq; Thu, 22 Apr 2004 09:19:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdyn-00017R-Ir for tcpm@optimus.ietf.org; Thu, 22 Apr 2004 09:11:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24707 for ; Thu, 22 Apr 2004 09:10:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGdyg-0000wK-AI for tcpm@ietf.org; Thu, 22 Apr 2004 09:10:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGdxt-0000hQ-00 for tcpm@ietf.org; Thu, 22 Apr 2004 09:10:06 -0400 Received: from seraph3.grc.nasa.gov ([128.156.10.12]) by ietf-mx with esmtp (Exim 4.12) id 1BGdxG-0000Pf-00 for tcpm@ietf.org; Thu, 22 Apr 2004 09:09:26 -0400 Received: from lombok-fi.grc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id DC2EE6BA68 for ; Thu, 22 Apr 2004 09:08:57 -0400 (EDT) Received: from drpepper.grc.nasa.gov (drpepper.grc.nasa.gov [139.88.122.76]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id i3MD8v3c022632; Thu, 22 Apr 2004 09:08:57 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501) id CAA35289DF; Thu, 22 Apr 2004 09:05:41 -0400 (EDT) Date: Thu, 22 Apr 2004 09:05:41 -0400 From: Wesley Eddy To: "Randall Stewart (cisco)" Cc: tcpm@ietf.org Subject: Re: [tcpm] alternative RST processing Message-ID: <20040422130541.GC20156@grc.nasa.gov> Reply-To: weddy@grc.nasa.gov References: <20040422123413.GA20156@grc.nasa.gov> <4087B3EA.8030405@cisco.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="O5XBE6gyVG5Rl6Rj" Content-Disposition: inline In-Reply-To: <4087B3EA.8030405@cisco.com> X-People-Whose-Mailers-Cant-See-This-Header-Are-Lame: true User-Agent: Mutt/1.5.5.1i Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --O5XBE6gyVG5Rl6Rj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 22, 2004 at 07:00:42AM -0500, Randall Stewart (cisco) wrote: >=20 > Would this not cause any TIME-WAIT state connection to > "revive" if a old data segment arrives from the network then? > It would likely make the most sense to only revive on the next expected data segment. -Wes=20 --O5XBE6gyVG5Rl6Rj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAh8MlzBuYqbnj3IwRAqaTAJwPiiUcPLTxsScWf35bLN5g50429gCfeOWg tSexYB3OFocNFlEoPd0IFXY= =pEru -----END PGP SIGNATURE----- --O5XBE6gyVG5Rl6Rj-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu Apr 22 10:20:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29677 for ; Thu, 22 Apr 2004 10:20:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGemO-0000LO-09 for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 10:02:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3ME2FhZ001315 for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 10:02:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGefQ-0005Wl-Bu for tcpm-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 09:55:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27064 for ; Thu, 22 Apr 2004 09:54:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGefI-0004Tj-MD for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 09:54:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGeeT-0004E7-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 09:54:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGedl-0003ya-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 09:53:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGeM2-0008M1-8o; Thu, 22 Apr 2004 09:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGe8a-0003Yy-2I for tcpm@optimus.ietf.org; Thu, 22 Apr 2004 09:21:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25349 for ; Thu, 22 Apr 2004 09:21:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGe8S-0003RS-Nr for tcpm@ietf.org; Thu, 22 Apr 2004 09:21:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGe7j-0003Co-00 for tcpm@ietf.org; Thu, 22 Apr 2004 09:20:16 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx with esmtp (Exim 4.12) id 1BGe6v-0002wa-00 for tcpm@ietf.org; Thu, 22 Apr 2004 09:19:25 -0400 Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by wyvern.icir.org (8.12.9p1/8.12.8) with ESMTP id i3MDJJjN052078; Thu, 22 Apr 2004 06:19:20 -0700 (PDT) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id AFBCE77A6E0; Thu, 22 Apr 2004 09:19:19 -0400 (EDT) To: "Randall Stewart (cisco)" From: Mark Allman Reply-To: mallman@icir.org Cc: Florian Weimer , Jeremy Harris , tcpm@ietf.org Subject: Re: [tcpm] new work item: TCP security issue In-Reply-To: <408699A0.8070409@cisco.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Wild Night MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 22 Apr 2004 09:19:19 -0400 Message-Id: <20040422131919.AFBCE77A6E0@guns.icir.org> Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 --=-=-= Content-Type: text/plain; charset=us-ascii > 1) We always send the tag of the peer, if known. > 2) In the few corner cases where we don't know the > peers tag and are sending a reset or such in response > to a packet, we set a special flag and send the tag that > was in the packet that caused us to send the response > packet.. > > Is that better??? Yep, I understand now. Thanks for the more detailed explanation. I agree that this would fix the current problem. I am not sure I think the wasted space in every packet is worth it, since there are alternatives that seem reasonable. But, it is certainly part of the design space. Thanks! allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAh8ZXWyrrWs4yIs4RAm0qAJ9YO8XGd1s4FztGYMWfNKS++QnEkgCfYNku VipF5WtE+OLX4Q8WDzA3Z1g= =wGQr -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu Apr 22 11:49:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06702 for ; Thu, 22 Apr 2004 11:49:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGgKU-0003Yn-1Z for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 11:41:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MFfXB5013680 for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 11:41:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGgAS-0007sw-B3 for tcpm-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 11:31:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05634 for ; Thu, 22 Apr 2004 11:31:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGgAP-0007fi-Bd for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 11:31:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGg9V-0007LC-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 11:30:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGg86-0006gD-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 11:28:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGfxl-0002k1-2x; Thu, 22 Apr 2004 11:18:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGfjf-0006jr-58 for tcpm@optimus.ietf.org; Thu, 22 Apr 2004 11:03:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03500 for ; Thu, 22 Apr 2004 11:03:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGfjW-0007Jx-SV for tcpm@ietf.org; Thu, 22 Apr 2004 11:03:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGfii-00071T-00 for tcpm@ietf.org; Thu, 22 Apr 2004 11:02:32 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BGfgg-0006Yq-00 for tcpm@ietf.org; Thu, 22 Apr 2004 11:00:27 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3MF0H602140; Thu, 22 Apr 2004 18:00:17 +0300 (EET DST) X-Scanned: Thu, 22 Apr 2004 18:00:08 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3MF08Nk015657; Thu, 22 Apr 2004 18:00:08 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00VKGsxZ; Thu, 22 Apr 2004 18:00:06 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3MF01s22119; Thu, 22 Apr 2004 18:00:01 +0300 (EET DST) Received: from nokia.com ([172.19.11.226]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 22 Apr 2004 17:59:58 +0300 Message-ID: <4087DDE6.3020703@nokia.com> Date: Thu, 22 Apr 2004 09:59:50 -0500 From: Yogesh Prem Swami User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ext Randall Stewart (cisco)" CC: mdalal@cisco.com, tcpm@ietf.org Subject: Re: FW: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: <025E7DD4182874489CC2F61EE0FA19CE02885696@daebe004.americas.nokia.com> <4087B232.4050203@cisco.com> In-Reply-To: <4087B232.4050203@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Apr 2004 14:59:58.0315 (UTC) FILETIME=[7AB6FBB0:01C4287A] Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Randall, Please see my comments inline: ext Randall Stewart (cisco) wrote: >>>Yogesh, >>>the idea is to address blind attack from an attacker sitting >>>outside your >>>path to the peer. The current problem is critical because it >>>takes fewer >>>packets than originally believed. >>> >>> >>> >>> >>> >>I don't know if the problem is critical or not and I wasn't questing that. Sending 65,535 RST messages might be a problem for BGP, but in the broader context of TCP it might not be. A very simple intrusion detection system can (and already do) detect and drop such bursts of packets, especially when each packet has the same socket attribute. >> >> >> >> >> >Hmmm... it does not have to be a burst of packets.. they can >be paced out to not cause alarm... and in practice it is >far less than 64k packets... in general sending a a paced >50pps I was able to reset most TCP connections in a very >very short time.. when I first started testing this thing... > > >Now as to BGP and others.. what about H.323 and some >of the other VoIP stuff .. I believe not all of them have >went with SCTP ... many use TCP.. and these are all >vulnerable... and I am sure there are a LOT of other >apps that do database connections and such... > >I don't think this problem is limited to just BGP... > > I agree. > >The lets pick a new name... and yes, I have no problem >adding limitation text at the beginning... > >To quote Scott.. > >Send text .... > > > Not the exact text.... But here are my thoughts. Three different kinds of attacks are possible on TCP. 1. Premature Resource Release (PRR) attacks: Attacks that are described in this draft fall in this category. The impact of these attacks are limited to a few connections, but if these few connections are very important as in case of BGP or H.323 (I am taking your word for H323), then the attacker can create a havoc. (BTW, in BGP when the connection is reset, the state machine restarts the connection withing some time period. Also, on my zebra/bgpd router running on Linux, the router did not immediately advertize that the link is down. I had the impression that bringing the TCP connection down will cause new route advertizements which will delay the convergence of routing tables, but this doesn't seem to be the case. Is this because I only have 6 routers in my lab? I am just trying to undertsand what the problem is. But back to attacks...) 2. Forced Resource Saturation (FRS) attacks: SYN flooding (without SYN cookies) is the most common example of FRS attack, but FRS is not limited to SYN flooding attacks. For example, an attacker can send an ACK for a data packet that was actually lost in the network. Since the receiver did not receive the packet, it will keep sending the duplicate ACKs for the lost packet, but since the sender has received an ACK, it will never retransmit the data packet (it doesn't have that packet in the send queue). This is a very expensive deadlock. (There are other similar--not necessarily as expensive--attacks possible. I can't exactly recollect them so early in the morning.) 3. Inappropriate Congestion Window (ICW) attacks: These attacks are mainly possible by a cheating sender or a middle box (but it can also be done by blind attackers with low success rates). Eifel detection algorithm could easily fall prey for this kind of attack in which the receiver never sends the timestamps for the recent most packet, but of the last packet received. This attack will allow the receiver to never go into slow start after real-timeout. There might be other attacks which I might not be aware of. So now my question is, which of these categories of attacks should be solved and which ones should not be. (I'd vote for 1 and 2, and leave 3 out). Also, there are different routes that one can take to solve these problems. Route-1: Fix individual vulnerabilities in the protocols by changing the protocol mechanism itself. "TCP secure" draft has taken this route. Route-2: Have a single protocol mechanism (e.g., by defining a new option or reusing an old one) that solves most of the problems.(I'd personally prefer this over Route-1). For Route-2, again there are couple of options. Route-2-a: Use crypto methods to solve the problem, but without doing key exchange. (Got my vote) Route-2-b: Use crypto, but with key exchange. I guess the working group needs to decide what is the best way forward. Yogesh _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu Apr 22 12:03:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07524 for ; Thu, 22 Apr 2004 12:03:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGgUu-0006k5-UO for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 11:52:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MFqKg3025911 for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 11:52:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGgOr-00055j-LO for tcpm-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 11:46:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06541 for ; Thu, 22 Apr 2004 11:46:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGgOo-00042K-EZ for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 11:46:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGgNs-0003mE-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 11:45:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGgN4-0003X3-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 11:44:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGgG4-0001eo-Me; Thu, 22 Apr 2004 11:37:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGg6W-0006XR-5j for tcpm@optimus.ietf.org; Thu, 22 Apr 2004 11:27:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05121 for ; Thu, 22 Apr 2004 11:27:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGg6T-0006DW-6L for tcpm@ietf.org; Thu, 22 Apr 2004 11:27:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGg5M-0005rj-00 for tcpm@ietf.org; Thu, 22 Apr 2004 11:25:57 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BGg4P-0005L0-00 for tcpm@ietf.org; Thu, 22 Apr 2004 11:24:57 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 22 Apr 2004 08:24:34 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3MFORW9023023; Thu, 22 Apr 2004 08:24:27 -0700 (PDT) Received: from cisco.com (rtp-dial-1-212.cisco.com [10.83.97.212]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATG92366; Thu, 22 Apr 2004 08:24:23 -0700 (PDT) Message-ID: <4087E36F.7000502@cisco.com> Date: Thu, 22 Apr 2004 10:23:27 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yogesh Prem Swami CC: mdalal@cisco.com, tcpm@ietf.org Subject: Re: FW: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: <025E7DD4182874489CC2F61EE0FA19CE02885696@daebe004.americas.nokia.com> <4087B232.4050203@cisco.com> <4087DDE6.3020703@nokia.com> In-Reply-To: <4087DDE6.3020703@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Yogesh Prem Swami wrote: > Hi Randall, > > Please see my comments inline: > > ext Randall Stewart (cisco) wrote: > >>>> Yogesh, >>>> the idea is to address blind attack from an attacker sitting >>>> outside your >>>> path to the peer. The current problem is critical because it takes >>>> fewer >>>> packets than originally believed. >>>> >>>> >>> >>> I don't know if the problem is critical or not and I wasn't questing >>> that. Sending 65,535 RST messages might be a problem for BGP, but in >>> the broader context of TCP it might not be. A very simple intrusion >>> detection system can (and already do) detect and drop such bursts of >>> packets, especially when each packet has the same socket attribute. >>> >>> >>> >>> >> >> Hmmm... it does not have to be a burst of packets.. they can >> be paced out to not cause alarm... and in practice it is >> far less than 64k packets... in general sending a a paced >> 50pps I was able to reset most TCP connections in a very >> very short time.. when I first started testing this thing... >> >> >> Now as to BGP and others.. what about H.323 and some >> of the other VoIP stuff .. I believe not all of them have >> went with SCTP ... many use TCP.. and these are all >> vulnerable... and I am sure there are a LOT of other >> apps that do database connections and such... >> >> I don't think this problem is limited to just BGP... >> >> > > I agree. > >> >> The lets pick a new name... and yes, I have no problem >> adding limitation text at the beginning... >> >> To quote Scott.. >> >> Send text .... >> >> >> > > Not the exact text.... But here are my thoughts. > > Three different kinds of attacks are possible on TCP. > > 1. Premature Resource Release (PRR) attacks: Attacks that are > described in this draft fall in this category. The impact of these > attacks are limited to a few connections, but if these few connections > are very important as in case of BGP or H.323 (I am taking your word > for H323), then the attacker can create a havoc. (BTW, in BGP when the > connection is reset, the state machine restarts the connection withing > some time period. Also, on my zebra/bgpd router running on Linux, the > router did not immediately advertize that the link is down. I had the > impression that bringing the TCP connection down will cause new route > advertizements which will delay the convergence of routing tables, but > this doesn't seem to be the case. Is this because I only have 6 > routers in my lab? I am just trying to undertsand what the problem is. > But back to attacks...) I am no BGP expert... but if I remember my BGP reading a year or so back the spec requires that when the connection breaks the routes are withdrawn... Zebra, If I remember right, is not a full complete BGP implementation.. and also different vendors do it differently.. some will pretend for some time that the connection stays up while a re-connect attempt is done.. others will not.. > > > 2. Forced Resource Saturation (FRS) attacks: SYN flooding (without > SYN cookies) is the most common example of FRS attack, but FRS is not > limited to SYN flooding attacks. For example, an attacker can send an > ACK for a data packet that was actually lost in the network. Since the > receiver did not receive the packet, it will keep sending the > duplicate ACKs for the lost packet, but since the sender has received > an ACK, it will never retransmit the data packet (it doesn't have that > packet in the send queue). This is a very expensive deadlock. (There > are other similar--not necessarily as expensive--attacks possible. I > can't exactly recollect them so early in the morning.) > > 3. Inappropriate Congestion Window (ICW) attacks: These attacks are > mainly possible by a cheating sender or a middle box (but it can also > be done by blind attackers with low success rates). Eifel detection > algorithm could easily fall prey for this kind of attack in which the > receiver never sends the timestamps for the recent most packet, but of > the last packet received. This attack will allow the receiver to never > go into slow start after real-timeout. > > There might be other attacks which I might not be aware of. > > So now my question is, which of these categories of attacks should be > solved and which ones should not be. (I'd vote for 1 and 2, and leave > 3 out). Also, there are different routes that one can take to solve > these problems. > > Route-1: Fix individual vulnerabilities in the protocols by changing > the protocol mechanism itself. "TCP secure" draft has taken this route. > > Route-2: Have a single protocol mechanism (e.g., by defining a new > option or reusing an old one) that solves most of the problems.(I'd > personally prefer this over Route-1). For Route-2, again there are > couple of options. > Route-2-a: Use crypto methods to solve the problem, but > without doing key exchange. (Got my vote) > > Route-2-b: Use crypto, but with key exchange. > > I guess the working group needs to decide what is the best way forward. I agree the wg needs to decide this... using route-2 normaly means you are adding more stuff in the options space... and some would not like this.. I am not sure I have an opinion as yet.. I would need to see details of the various proposal... Having been involved in this for quite some time... the draft puts forward simple small fixes that can be implemented quickly and close up most of the holes... is it the best solution probably not.. but considering the trade-offs it seemed the correct way to go... so I guess you know I vote for route-1 :-D R > > > Yogesh > > -- Randall R. Stewart ITD - Transport Technologies 815-477-2127(o) or 815-342-5222(c) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu Apr 22 13:06:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11036 for ; Thu, 22 Apr 2004 13:06:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGhYd-0004AM-1s for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 13:00:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MH0FVC016010 for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 13:00:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGhPp-0001OI-U3 for tcpm-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 12:51:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09860 for ; Thu, 22 Apr 2004 12:51:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGhPm-0006MW-3Q for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 12:51:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGhOm-00063z-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 12:50:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGhNq-0005nC-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 12:49:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGh6M-0002lk-TN; Thu, 22 Apr 2004 12:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGh1Y-0000Yq-Cd for tcpm@optimus.ietf.org; Thu, 22 Apr 2004 12:26:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08455 for ; Thu, 22 Apr 2004 12:26:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGh1U-000735-M2 for tcpm@ietf.org; Thu, 22 Apr 2004 12:26:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGh0e-0006nT-00 for tcpm@ietf.org; Thu, 22 Apr 2004 12:25:09 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGgzp-0006H4-00 for tcpm@ietf.org; Thu, 22 Apr 2004 12:24:17 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 22 Apr 2004 08:34:33 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3MGNlW9023098; Thu, 22 Apr 2004 09:23:47 -0700 (PDT) Received: from mdalal-u10.cisco.com (mdalal-u10.cisco.com [128.107.162.178]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASI39383; Thu, 22 Apr 2004 09:23:00 -0700 (PDT) Date: Thu, 22 Apr 2004 09:23:46 -0700 (PDT) From: Mitesh Dalal To: Kacheong Poon cc: David Borman , tcpm@ietf.org Subject: Re: [tcpm] new work item: TCP security issue In-Reply-To: <40871B8F.7020306@sun.com> Message-ID: References: <20040420200340.E690777A9EB@guns.icir.org> <40871B8F.7020306@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 21 Apr 2004, Kacheong Poon wrote: > David Borman wrote: > > > First, the RST issue. RST packets can be used to reset a connection, > > and you just have to get it anywhere in the window, not an exact > > sequence match. The additional check is that if the RST isn't exactly > > what we expect it to be, generate an ACK, and if the original RST was > > valid, another RST will be generated in response to that ACK with an > > exact match and then the connection will be dropped. If the original > > RST was bogus, our ACK will be ignored and the connection stays up. I > > can think of some end-case scenarios where the second valid RST might > > still not be exact, but that would just generate another ACK and it > > should become deterministic at some point and the RST be accepted. The > > only way you'd get into trouble would be if someone was generating an > > RST in response to an ACK, and not properly swapping the seq/ack > > fields. If that happened, you could get into an RST/ACK war... > > Yes. What I am worried is interaction with middlebox. I've > seen broken stateful middlebox causing ACK war. With this kind > of "subtle" change, I think it will hit someone. And since this > kind of attack is mostly targeted at a specific type of TCP > traffic, such as long lived, I think most implementors are not > comfortable in making these changes. could you please elaborate on a scenario which you think might potentially happen and could cause more problem with this fix than without this fix ? It would be nice to fix any scenario that we might have overlooked. Lets consider the scenario where we have a firewall B sitting in between peers A and C. C sends a RST that is not an exact match. B however does not have the current fix and cleanups its state and asks A to do the same. A however does not like the RST and sends an ACK. Since the firewall does not have an entry, it will drop the same. No harm done except that A is left holding the bag. Here your personal paranoia comes into picture. Is it better to be left holding a dead connection or get reset on a potential DOS RST packet. The same will hold true for the SYN part. and yes the firewall vendors need to catch up with the new RFCs. Example in point ECN. When ECN was standardized, most firewalls didnt even understand TCP ECN. thx Mitesh > > > The change for in-window SYN processing actually changes TCP's > > behavior. Currently, if you get a SYN in-window, you abort the > > connection and send a RST back to the other side. So, the attacker jus= t > > has to get the SYN in the window to blow the connection away. The > > change is to generate a current =C5CK in response to a SYN, and if the = SYN > > was legitimage, our ACK will cause a RST to be generated, which will > > cause our half-open connection to be dropped. The change to TCP is tha= t > > the other side is still up, and when the SYN gets retransmitted, we'll > > establish a new connection. This new connection will have its sequence > > space overlapping the window of the old half-open connection, so we now > > have the possibility that the new connection will get and accept packet= s > > from the old connection... > > Again, ACK is used as a form of challenge/response. It can be > considered as "ingenious" or a "hack." > > > On the item of data injection, I haven't totally convinced myself of t= he > > ((SND.UNA - MAX.SND.WND) <=3D SEG.ACK < SND.NXT) > > check. For a unidirectional data transfer, this isn't a problem, > > because SEG.ACK remains constant. I'm wondering about the > > bi-directional data transfer case, but I haven't come up with an exampl= e > > yet to either prove or disprove that this check will not throw away > > legitimate packets (but if it did, it should be a transient issue and > > the retransmitted packets should have more current ACK information and > > As you mentioned, can this happen in bidirectional transfer > with delayed out of order segments and one side is sending > faster than the other side? And the probability increases > as the number of outstanding segments get big (large window) in both > sides. > > > get accepted). Note that in the extreme case of using a window scale o= f > > 14, and advertising the whole window (2^30), these changes don't really > > provide much protection, since you'll have almost 1/2 of the sequence > > space as being valid for the ACK check. If they can guess an in-window > > sequence number (easier, since it's 1/4 of the sequence space), they > > just a couple of packets with different ACK values should get one of > > them into the connection. This protects things best when the maximum > > window is kept small. > > As people have already asked, should we have a more general solution? > RFC 2385 is a solution, but it can be expensive and there needs to be > a key exchange. Can a simple mechanism similar to SCTP verification > tag be used? Randy already explained the mechanism in another mail. > It can be enabled by a socket option so that only app protocol > vulnerable to this type of attack will use it. And it is simple > enough for header compression, if it is needed. What is the issue > with that? > > > -- > > =09=09=09=09=09=09K. Poon. > =09=09=09=09=09=09kacheong.poon@sun.com > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu Apr 22 13:58:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14413 for ; Thu, 22 Apr 2004 13:58:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGiRR-0006Ml-1G for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 13:56:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MHurtT024467 for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 13:56:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGiQq-00065y-E8 for tcpm-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 13:56:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14298 for ; Thu, 22 Apr 2004 13:56:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGiQm-0001hv-3p for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 13:56:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGiPm-0001RT-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 13:55:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGiPR-0001Bf-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 13:54:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGiJo-0004AB-NM; Thu, 22 Apr 2004 13:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGiG6-0002ph-Vs for tcpm@optimus.ietf.org; Thu, 22 Apr 2004 13:45:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13418 for ; Thu, 22 Apr 2004 13:45:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGiG2-0006Un-RN for tcpm@ietf.org; Thu, 22 Apr 2004 13:45:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGiFA-0006BO-00 for tcpm@ietf.org; Thu, 22 Apr 2004 13:44:13 -0400 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1BGiED-0005cR-00 for tcpm@ietf.org; Thu, 22 Apr 2004 13:43:13 -0400 Received: from localhost (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with SMTP id 95C2E3271E; Thu, 22 Apr 2004 19:42:43 +0200 (CEST) Received: from acorde.it.uc3m.es (acorde.it.uc3m.es [163.117.139.72]) by smtp01.uc3m.es (Postfix) with ESMTP id 08590326C3; Thu, 22 Apr 2004 19:42:37 +0200 (CEST) Subject: Re: [tcpm] new work item: TCP security issue From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: mallman@icir.org Cc: tcpm@ietf.org, Ted Faber In-Reply-To: <20040420200340.E690777A9EB@guns.icir.org> References: <20040420200340.E690777A9EB@guns.icir.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ByOBr8IpRPQzNa01R822" Organization: Universidad Carlos III de Madrid Message-Id: <1082655756.1144.30.camel@acorde> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 22 Apr 2004 19:42:36 +0200 Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --=-ByOBr8IpRPQzNa01R822 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Mark and all, Thanks for the draft. We have been working on a similar TCP attack to the ones pointed in this draft. We submitted an Internet-Draft to the TSVWG (the TCPM WG had not been created yet), and we are working on it to provide a new version. Current release can be downloaded from http://www.it.uc3m.es/cjbc/drafts/draft-azcorra-tsvwg-tcp-blind-ack-dos-01.= txt We think (and we have also performed some tests proving it) that the attack pointed in our draft is also a very dangerous threat and that the proposed changes (server-side changes) eliminate or at least minimise the treats to a more acceptable level. Please provide any comment. If the discussion results in this attack being interesting to take into account, we can provide a contribution to the tcpsecure draft in the form of a section. Kind regards, Carlos J. El mar, 20-04-2004 a las 22:03, Mark Allman escribi=F3: > Just announced internet-draft: > > Title : Transmission Control Protocol security consideration= s > > Author(s) : R. Stewart > > Filename : draft-ietf-tcpm-tcpsecure-00.txt > > Pages : 10 > > Date : 2004-4-20 > > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt > =20 > Hi folks! >=20 > We wanted to announce a new I-D and TCPM work item. The draft is > "Transmission Control Protocol security considerations" > (draft-ietf-tcpm-tcpsecure-00.txt). We believe we owe a bit in the way > of explanation since it seems that this is being foisted upon the WG > without much input. =20 >=20 > The brief story is that a bunch of folks were made aware of the TCP > security vulnerability outlined in the above draft. (I think many > people have been aware of these things for a long time. But, the driver > here is that there is a new conference paper that is going to show the > ease with which the vulnerability can be exploited.) Many people from a > number of TCP implementers (vendors) have been busily working behind the > scenes to come up with reasonable fixes before the vulnerability was > announced. The fixes are in the I-D. The vulnerability has been > announced (via the standard security issues venues). As part of this > process Randall Stewart wrote the above mentioned I-D for this WG to > ponder. >=20 > A few notes since this I-D got adopted as a WG item with zero public / > open input: >=20 > * Until the vulnerability was announced we didn't want to entertain a > huge discussion on the public mailing list for obvious reasons. >=20 > * The transport ADs, security ADs and TCPM WG chairs all agreed that > this is an important problem to address and that TCPM is the correct > WG in which to address it. That said, if folks think we made the > wrong call here, please feel free to speak up and tell us why we > screwed up. >=20 > * The fixes suggested in the above I-D are not being pre-judged as > *THE* answer. Rather, they represent *A POSSIBLE* solution (and > running code) that this WG will consider. In other words, we are > not trying to simply ram this document through the WG and produce an > RFC. This WG will deliberate on the I-D as it would any other. >=20 > * Alternate solutions are welcome. We would like to encourage folks > who have different solutions to the problems outlined in the draft > to put those forward for consideration. >=20 > Any other comments folks have on this draft / issue are very welcome. >=20 > Thanks! >=20 > Mark & Ted >=20 --=20 Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ GPG FP: 1880 80D3 8004 25C7 6537 8E02 252A D295 9CFF DEAF --=-ByOBr8IpRPQzNa01R822 Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBAiAQMJSrSlZz/3q8RAlzRAKDIDArBJnagxolXThkwDwuwMbOBDACfb0Po 8b12ChJx9PkrmIu4N2B5X2g= =2JHQ -----END PGP SIGNATURE----- --=-ByOBr8IpRPQzNa01R822-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu Apr 22 15:57:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24383 for ; Thu, 22 Apr 2004 15:57:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGk7i-0001rJ-VH for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 15:44:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MJicKY007137 for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 15:44:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGjbP-000274-Ru for tcpm-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 15:11:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19359 for ; Thu, 22 Apr 2004 15:11:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGjbK-0007Cg-Mb for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 15:11:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGjaL-0006wB-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 15:10:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGjZH-0006aS-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 15:09:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGjPc-00074i-JB; Thu, 22 Apr 2004 14:59:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGjE9-0003Qh-K2 for tcpm@optimus.ietf.org; Thu, 22 Apr 2004 14:47:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17191 for ; Thu, 22 Apr 2004 14:47:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGjE4-0000YS-Ms for tcpm@ietf.org; Thu, 22 Apr 2004 14:47:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGjD5-0000IL-00 for tcpm@ietf.org; Thu, 22 Apr 2004 14:46:08 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGjC6-0007a8-00 for tcpm@ietf.org; Thu, 22 Apr 2004 14:45:06 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 22 Apr 2004 10:55:24 +0000 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3MIiZW9028328; Thu, 22 Apr 2004 11:44:36 -0700 (PDT) Received: from localhost.localdomain (dhcp-171-71-137-62.cisco.com [171.71.137.62]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA11881; Thu, 22 Apr 2004 14:44:34 -0400 (EDT) Received: (from salehi@localhost) by localhost.localdomain (8.11.2/8.11.2) id i3MIiX410181; Thu, 22 Apr 2004 11:44:33 -0700 From: Nader Salehi MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16520.4753.925433.696685@gargle.gargle.HOWL> Date: Thu, 22 Apr 2004 11:44:33 -0700 To: Joe Touch Cc: "Peterson, Jon" , "'Tim Shepard'" , tcpm@ietf.org Subject: Re: [tcpm] new work item: TCP security issue In-Reply-To: <4085F925.6010304@isi.edu> References: <4085F925.6010304@isi.edu> X-Mailer: VM 7.14 under 21.4 (patch 12) "Portable Code" XEmacs Lucid X-URL: http://www.cisco.com Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am not saying there is no problem here, but there are already mechanisms in place to reduce the risk in BGP. BTSH can effectively eliminate the danger spoofing problem for eBGP. Many vendors either have already implemented BTSH or are in the process of it. Also, if MD5 checksum is enabled, then hackers cannot easily reset a TCP connection even the know the sequence number. I think the document should address (and incorporate) these mechanisms. My $0.02 Nader Joe Touch writes: > > > Peterson, Jon wrote: > > > One specific protocol for which this is a concern is discussed here: > > > > http://www.us-cert.gov/cas/techalerts/TA04-111A.html > > And here: > > RFC 2385. > > Urgently. Nearly 6 years ago ;-) > > Joe > > > I will note that exploits for this vulnerability are already known to be > > circulating in "black hat" circles. > > > > You may also have noticed that the press has demonstrated some interested in > > this today; there is much more speculation about the potential applicability > > of this vulnerability to be found there. > > > > Jon Peterson > > NeuStar, Inc. > > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 iD8DBQFAiBKRci9Jtawhs8URAh08AJ0aOPFZsjMo4phxchzkAaG2s0UbqQCeOnnq ryDfQbCiK69PJm5LJYjloWM= =pKnC -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu Apr 22 18:06:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05575 for ; Thu, 22 Apr 2004 18:06:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlxP-0007aW-2T for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 17:42:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MLg6kh029144 for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 17:42:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlOn-00059Z-Ix for tcpm-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 17:06:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00477 for ; Thu, 22 Apr 2004 17:06:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGlOj-0004Fp-Al for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 17:06:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGlNq-0003yq-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 17:05:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGlN5-0003iW-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 17:04:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGkKV-00071Z-T1; Thu, 22 Apr 2004 15:57:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGk5y-0001dP-1P for tcpm@optimus.ietf.org; Thu, 22 Apr 2004 15:42:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22658 for ; Thu, 22 Apr 2004 15:42:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGk5u-0001Wi-Is for tcpm@ietf.org; Thu, 22 Apr 2004 15:42:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGk4m-0001Bk-00 for tcpm@ietf.org; Thu, 22 Apr 2004 15:41:36 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1BGk3z-0000sT-00 for tcpm@ietf.org; Thu, 22 Apr 2004 15:40:47 -0400 Received: from jurassic.eng.sun.com ([129.146.89.50]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i3MJeg4U011663; Thu, 22 Apr 2004 13:40:42 -0600 (MDT) Received: from sun.com (shield.SFBay.Sun.COM [129.144.60.49]) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i3MJefka393697; Thu, 22 Apr 2004 12:40:41 -0700 (PDT) Message-ID: <40881FB9.701@sun.com> Date: Thu, 22 Apr 2004 12:40:41 -0700 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.6) Gecko/20040117 X-Accept-Language: en, zh-hk, zh-tw, zh-cn MIME-Version: 1.0 To: mallman@icir.org CC: dab@cray.com, tcpm@ietf.org Subject: Re: [tcpm] new work item: TCP security issue References: <20040422131919.AFBCE77A6E0@guns.icir.org> In-Reply-To: <20040422131919.AFBCE77A6E0@guns.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mark Allman wrote: > I agree that this would fix the current problem. I am not sure I think > the wasted space in every packet is worth it, since there are > alternatives that seem reasonable. But, it is certainly part of the > design space. Or can we use the timestamp option somehow? It should be used when large window is used anyway. So it is there. On page 18 of RFC 1323, it is recommended that timestamp should not be used in a RST. If we think about how it can be used, maybe this can solve the current problem without changing the basic TCP spec or introducing new option. Dave, do you have comments on the feasibility of using timestamp option for this purpose? -- K. Poon. kacheong.poon@sun.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu Apr 22 18:27:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07898 for ; Thu, 22 Apr 2004 18:27:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmPp-0007lw-Tx for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 18:11:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MMBTBd029856 for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 18:11:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGm5b-0002YX-Ud for tcpm-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 17:50:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04083 for ; Thu, 22 Apr 2004 17:50:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGm5X-000109-An for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 17:50:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGm2g-000063-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 17:47:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGlyn-0006uT-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 17:43:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGld3-00004w-Nr; Thu, 22 Apr 2004 17:21:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGkdk-00073F-LC for tcpm@optimus.ietf.org; Thu, 22 Apr 2004 16:17:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25583 for ; Thu, 22 Apr 2004 16:17:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGkdg-00043m-QJ for tcpm@ietf.org; Thu, 22 Apr 2004 16:17:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGkcZ-0003fX-00 for tcpm@ietf.org; Thu, 22 Apr 2004 16:16:32 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1BGkbU-00031P-00 for tcpm@ietf.org; Thu, 22 Apr 2004 16:15:24 -0400 Received: from jurassic.eng.sun.com ([129.146.87.130]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i3MKEY6b003383; Thu, 22 Apr 2004 13:14:34 -0700 (PDT) Received: from sun.com (shield.SFBay.Sun.COM [129.144.60.49]) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i3MKEYik405988; Thu, 22 Apr 2004 13:14:34 -0700 (PDT) Message-ID: <408827AA.2000102@sun.com> Date: Thu, 22 Apr 2004 13:14:34 -0700 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.6) Gecko/20040117 X-Accept-Language: en, zh-hk, zh-tw, zh-cn MIME-Version: 1.0 To: Mitesh Dalal CC: tcpm@ietf.org Subject: Re: [tcpm] new work item: TCP security issue References: <20040420200340.E690777A9EB@guns.icir.org> <40871B8F.7020306@sun.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mitesh Dalal wrote: > could you please elaborate on a scenario which you think might > potentially happen and could cause more problem with this fix > than without this fix ? It would be nice to fix any scenario > that we might have overlooked. The problem with middlebox, especially those targeted at home uses, is that one does not really know what it tries to do )-: > Lets consider the scenario where we have a firewall B sitting in > between peers A and C. C sends a RST that is not an exact match. > B however does not have the current fix and cleanups its state > and asks A to do the same. A however does not like the RST and > sends an ACK. Since the firewall does not have an entry, it will > drop the same. No harm done except that A is left holding the > bag. Here your personal paranoia comes into picture. Is it better > to be left holding a dead connection or get reset on a potential > DOS RST packet. The same will hold true for the SYN part. If you were the programmer for the firewall, I am happy (-: But the truth is that firewall code is sometimes not that good. A sends back the ACK and the firewall B does not have a state. But B may try to "optimize" traffic and generate a RST on its own. Now that B may also do NAT. Somehow there is a mix up when doing all the NAT/RST generation (or it is not a mix up as B is a NAT and it is "clever" enough to save up RSTs for exactly this kind of scenario) that it also sends a RST which A does not like. Oops... > and yes the firewall vendors need to catch up with the > new RFCs. Example in point ECN. When ECN was standardized, > most firewalls didnt even understand TCP ECN. The issue with ECN is easier to see, TCP connection just cannot be established. And the workaround is easy, disable ECN. But the changes we are discussing here is very fundamental and cannot be disabled, at least this is how I understand the draft. So I think we should be very cautious in moving forward. This is one reason why I prefer to have an option so that it can be disabled in case we find something bad happen later. Or reuse the timestamp option if feasible. -- K. Poon. kacheong.poon@sun.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu Apr 22 19:04:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10631 for ; Thu, 22 Apr 2004 19:04:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGn4H-00014L-Ao for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 18:53:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MMrHtA004105 for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 18:53:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmlP-0002jG-3N for tcpm-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 18:33:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08476 for ; Thu, 22 Apr 2004 18:33:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmlK-0005c3-49 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 18:33:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmk6-0005FX-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 18:32:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGmj4-0004ul-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 18:31:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmQr-0000bT-Gh; Thu, 22 Apr 2004 18:12:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGm6h-0002va-CH for tcpm@optimus.ietf.org; Thu, 22 Apr 2004 17:51:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04272 for ; Thu, 22 Apr 2004 17:51:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGm6c-0001CK-O3 for tcpm@ietf.org; Thu, 22 Apr 2004 17:51:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGm4W-0000dv-00 for tcpm@ietf.org; Thu, 22 Apr 2004 17:49:29 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BGm1L-0007Ui-00 for tcpm@ietf.org; Thu, 22 Apr 2004 17:46:12 -0400 Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3MLjkN27612; Thu, 22 Apr 2004 14:45:46 -0700 (PDT) Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.12.10/8.12.10) with ESMTP id i3MLjjIx036468; Thu, 22 Apr 2004 14:45:45 -0700 (PDT) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.12.10/8.12.10/Submit) id i3MLjjKY036467; Thu, 22 Apr 2004 14:45:45 -0700 (PDT) (envelope-from faber) Date: Thu, 22 Apr 2004 14:45:45 -0700 From: Ted Faber To: Wesley Eddy Cc: "Randall Stewart (cisco)" , tcpm@ietf.org Subject: Re: [tcpm] alternative RST processing Message-ID: <20040422214545.GH34492@pun.isi.edu> References: <20040422123413.GA20156@grc.nasa.gov> <4087B3EA.8030405@cisco.com> <20040422130541.GC20156@grc.nasa.gov> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mYYhpFXgKVw71fwr" Content-Disposition: inline In-Reply-To: <20040422130541.GC20156@grc.nasa.gov> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: faber@isi.edu Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --mYYhpFXgKVw71fwr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Apr 22, 2004 at 09:05:41AM -0400, Wesley Eddy wrote: > On Thu, Apr 22, 2004 at 07:00:42AM -0500, Randall Stewart (cisco) wrote: > > > > Would this not cause any TIME-WAIT state connection to > > "revive" if a old data segment arrives from the network then? > > > > It would likely make the most sense to only revive on the next expected > data segment. It would make a nice companion document to RFC1337 - TIME-WAIT Ressurrection Hazards. :-) I'm a little nervous about adding arcs to the TCP state diagram. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG --mYYhpFXgKVw71fwr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAiD0JaUz3f+Zf+XsRAjF/AJ9DYMCsM4U6ibb5SCzHRH0fhwdROgCgiVOs bAN//n9wnbeW3R8Hf3Y9VmM= =3vLQ -----END PGP SIGNATURE----- --mYYhpFXgKVw71fwr-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu Apr 22 19:14:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11493 for ; Thu, 22 Apr 2004 19:14:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGnFj-0005vQ-BU for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 19:05:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MN57hu022768 for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 19:05:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGnCF-0004PD-Lm for tcpm-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 19:01:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10331 for ; Thu, 22 Apr 2004 19:01:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGnCA-0005iz-BI for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 19:01:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGnBC-0005Pb-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 19:00:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGnAX-00058S-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 18:59:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmmc-0003Tf-Qa; Thu, 22 Apr 2004 18:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmSb-0001js-Ec for tcpm@optimus.ietf.org; Thu, 22 Apr 2004 18:14:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06540 for ; Thu, 22 Apr 2004 18:14:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmSW-0007fK-CO for tcpm@ietf.org; Thu, 22 Apr 2004 18:14:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmRp-0007QL-00 for tcpm@ietf.org; Thu, 22 Apr 2004 18:13:33 -0400 Received: from mail.enyo.de ([212.9.189.167]) by ietf-mx with esmtp (Exim 4.12) id 1BGmRA-00079z-00 for tcpm@ietf.org; Thu, 22 Apr 2004 18:12:53 -0400 Received: (debugging) helo=deneb ip=212.9.189.171 name=deneb.enyo.de Received: from deneb.enyo.de ([212.9.189.171] helo=deneb) by mail.enyo.de with esmtp id 1BGmRA-00011a-5G; Fri, 23 Apr 2004 00:12:52 +0200 Received: from fw by deneb with local (Exim 4.32) id 1BGmR9-0001IG-S3; Fri, 23 Apr 2004 00:12:51 +0200 To: Allison Mankin Cc: Tim Shepard , tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: From: Florian Weimer Date: Fri, 23 Apr 2004 00:12:51 +0200 In-Reply-To: (Allison Mankin's message of "Tue, 20 Apr 2004 20:08:44 -0700") Message-ID: <87llknsluk.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Allison Mankin writes: > I agree the draft should mention the point about ports and addresses. Vendors seem to disagree and hesitate to add source port randomization. I don't know why. 8-( -- Current mail filters: many dial-up/DSL/cable modem hosts, and the following domains: atlas.cz, bigpond.com, postino.it, tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu Apr 22 20:02:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13907 for ; Thu, 22 Apr 2004 20:02:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGntY-0003sD-02 for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 19:46:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MNkFR8014873 for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 19:46:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGnjy-0000BJ-4U for tcpm-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 19:36:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12763 for ; Thu, 22 Apr 2004 19:36:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGnju-000018-Bk for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 19:36:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGniu-0007XO-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 19:35:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGnhs-00076U-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 19:34:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGneo-0006SH-1e; Thu, 22 Apr 2004 19:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGnQe-0001i7-EI for tcpm@optimus.ietf.org; Thu, 22 Apr 2004 19:16:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11670 for ; Thu, 22 Apr 2004 19:16:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGnQa-0002S4-V6 for tcpm@ietf.org; Thu, 22 Apr 2004 19:16:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGnPh-0002BI-00 for tcpm@ietf.org; Thu, 22 Apr 2004 19:15:25 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BGnOk-0001tm-00 for tcpm@ietf.org; Thu, 22 Apr 2004 19:14:26 -0400 Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3MNCnN20540; Thu, 22 Apr 2004 16:12:49 -0700 (PDT) Message-ID: <40885173.6090804@isi.edu> Date: Thu, 22 Apr 2004 16:12:51 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tcpm@ietf.org Subject: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3ACE15A578679395AEFB7D2B" X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3ACE15A578679395AEFB7D2B Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit A few somewhat separate points: 1) I agree with a few others that this is not a substantially worrisome problem. The draft would be made much better by, e.g., pointing out early and directly that a) this problem was known before (RFC2385) b) the primary change is the increase in the window, which increases the chance of it working as an attack The current draft (IMO) obfuscates its relation to 2385, noting it only as an informative ref (if this isn't normative, though not a protocol, I'm not sure what is), and as a way to close the attack "incompletely" (FWIW, the RST trick is incomplete too). 2) The sky isn't falling This is critical ONLY for: - pairs of machines that OTHERS not in the path know are communicating - that others care to interrupt IMO, IPsec or the MD5 signature options are more than sufficient for these cases. Sure, there's an esoteric interest we share in exploring the space of "can we do better without slowing down the connection and without predeploying keys of some sort", but it's not clear it's worth #3 - it IS worth noting that, e.g., as others have pointed out: --a) data-level security won't help (TLS) --b) transport or network security will (MD5 signatures, IPsec) --c) cookies are as good as signatures for this purpose --d) transport security, whether cookies or signatures, requires a TCP option, which could break non-modified receivers (i.e., aren't as backward-compat as this might be) but since you have to modify the ones you're trying to protect anyway, so consider it as a 'dual stack' issue and move on ;-) 3) mucking with RSTs can be hazardous RST handling is rife with dragons. At the least, these include: --a) when you throw a RST, IMO, _YOU_ ought to have to go into TIME_WAIT if not, you can't ensure that the other end won't restart the connection and data will leak in and corrupt...either when the other side does - or more importantly does not - implement this solution if you're in TIME_WAIT, you shouldn't reply to ACKs with anything but silence (pg 72) the alternative is to add a new state - TIME_WAIT_RST, which replies to ACKs differently than TIME_WAIT (which is entered on other events) --b) what about when there's lossy pipes? You send a RST with the last SEQ number (after all the data you already sent). But the lost data means the other side ACKs a lower (modulo wraparound) SEQ. So you send a RST with that SEQ. In the meantime, some of the pipelined data arrives, increasing the SEQ no. So the new RST shows up. It get's dropped, and an extra ACK of the new SEQ goes back to you. --- The ID isn't clear that the ACK sent is i) just an ACK in which case this pattern can repeat until all the data is sent, which could be a LONG TIME ii) a RST-ACK which, since RST bits are processed before ACK bits, will cause you to reset, somewhat unexpectedly ;-) For these reasons and a few lurking suspicions, I'm hesitant to change the processing diagram to add new states OR new arcs; this appears to need BOTH. Joe --------------enig3ACE15A578679395AEFB7D2B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAiFF3E5f5cImnZrsRAqZnAKCXt8iVZYBsOrDVJzpMjc782gS7FACg3is8 Pf9I0MI45aQasreJRzJm8rU= =vd6N -----END PGP SIGNATURE----- --------------enig3ACE15A578679395AEFB7D2B-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu Apr 22 20:51:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15911 for ; Thu, 22 Apr 2004 20:51:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGopI-0005nT-HG for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 20:45:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3N0juxq022277 for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 20:45:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGohT-0002zl-AO for tcpm-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 20:37:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15078 for ; Thu, 22 Apr 2004 20:37:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGohP-0000Ai-2T for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 20:37:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGofN-0007RS-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 20:35:41 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGoeV-00079c-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 20:34:47 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BGoMm-0007AN-7X for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 20:16:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGoCg-0001nw-IQ; Thu, 22 Apr 2004 20:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGo8G-0008I1-9I for tcpm@optimus.ietf.org; Thu, 22 Apr 2004 20:01:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13820 for ; Thu, 22 Apr 2004 20:01:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGo8C-0006Yc-A8 for tcpm@ietf.org; Thu, 22 Apr 2004 20:01:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGo7I-0006Id-00 for tcpm@ietf.org; Thu, 22 Apr 2004 20:00:29 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGo6G-0005oW-00 for tcpm@ietf.org; Thu, 22 Apr 2004 19:59:24 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 22 Apr 2004 16:09:41 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3MNwqW9000374; Thu, 22 Apr 2004 16:58:52 -0700 (PDT) Received: from mdalal-u10.cisco.com (mdalal-u10.cisco.com [128.107.162.178]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASI87641; Thu, 22 Apr 2004 16:58:04 -0700 (PDT) Date: Thu, 22 Apr 2004 16:58:50 -0700 (PDT) From: Mitesh Dalal To: Florian Weimer cc: Allison Mankin , Tim Shepard , tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt In-Reply-To: <87llknsluk.fsf@deneb.enyo.de> Message-ID: References: <87llknsluk.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Fri, 23 Apr 2004, Florian Weimer wrote: > Allison Mankin writes: > > > I agree the draft should mention the point about ports and addresses. > > Vendors seem to disagree and hesitate to add source port > randomization. I don't know why. 8-( Port allocation is an implementation issue and the current issue we have at hand is a flaw in the original standard. Its the later that we are trying to address. yes, port randomization will help, but the amount of benefit we can derive is debatable. thx Mitesh > > -- > Current mail filters: many dial-up/DSL/cable modem hosts, and the > following domains: atlas.cz, bigpond.com, postino.it, tiscali.co.uk, > tiscali.cz, tiscali.it, voila.fr. > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu Apr 22 20:52:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15961 for ; Thu, 22 Apr 2004 20:52:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGopI-0005o5-UV for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 20:45:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3N0juMi022314 for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 20:45:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGohX-000337-AB for tcpm-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 20:37:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15095 for ; Thu, 22 Apr 2004 20:37:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGohT-0000BC-2D for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 20:37:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGofQ-0007S7-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 20:35:45 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGoeV-00079c-05 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 20:34:47 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BGoMJ-00079z-O1 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 20:15:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGoCf-0001nY-Ps; Thu, 22 Apr 2004 20:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGo5N-0006ls-Br for tcpm@optimus.ietf.org; Thu, 22 Apr 2004 19:58:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13737 for ; Thu, 22 Apr 2004 19:58:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGo5J-0005oG-Dh for tcpm@ietf.org; Thu, 22 Apr 2004 19:58:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGo4W-0005Z7-00 for tcpm@ietf.org; Thu, 22 Apr 2004 19:57:36 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BGo42-0005JO-00 for tcpm@ietf.org; Thu, 22 Apr 2004 19:57:07 -0400 Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3MNuLN00451; Thu, 22 Apr 2004 16:56:21 -0700 (PDT) Message-ID: <40885BAB.2070200@isi.edu> Date: Thu, 22 Apr 2004 16:56:27 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tcpm@ietf.org Subject: Re: FW: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: <025E7DD4182874489CC2F61EE0FA19CE02885696@daebe004.americas.nokia.com> <4087B232.4050203@cisco.com> <4087DDE6.3020703@nokia.com> <4087E36F.7000502@cisco.com> In-Reply-To: <4087E36F.7000502@cisco.com> X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8EA51DE89E2CA63D189523DC" X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8EA51DE89E2CA63D189523DC Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Randall Stewart (cisco) wrote: ... > I am no BGP expert... but if I remember my BGP reading a year or > so back the spec requires that when the connection breaks the routes > are withdrawn... Zebra, If I remember right, is not a full complete BGP > implementation.. and also different vendors do it differently.. some will > pretend for some time that the connection stays up while a re-connect > attempt is done.. others will not.. It would, FWIW, be useful to nail this down and cite something specific about it in the draft. I.e., there are two reasons this problem may be important: a) kills connections which could cause a loss of a lot of data, though (IMO) anything with that much data ought to know how to restart and recover from where it left-off (i.e., what it ACKd) b) killed connections can hurt BGP more than some other apps. that warrants a fix to BGP, IMO. Joe --------------enig8EA51DE89E2CA63D189523DC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAiFurE5f5cImnZrsRAhwYAKC2rT5dKMWWjrAVPlWFicQEPjdrzACeIqVm vPRXEdOGaBUlJUe3uFHz8WA= =OZpw -----END PGP SIGNATURE----- --------------enig8EA51DE89E2CA63D189523DC-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu Apr 22 20:54:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16169 for ; Thu, 22 Apr 2004 20:54:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGorW-0006Rf-Li for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 20:48:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3N0mE4L024770 for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 20:48:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGoim-0003JU-9y for tcpm-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 20:39:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15399 for ; Thu, 22 Apr 2004 20:39:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGoii-0000YW-1Y for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 20:39:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGogd-0007iX-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 20:37:00 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGoeq-00079c-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 20:35:08 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BGo9f-0006oo-7R for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 20:02:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGnuK-0004E9-HB; Thu, 22 Apr 2004 19:47:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGnm5-0001Po-TU for tcpm@optimus.ietf.org; Thu, 22 Apr 2004 19:38:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12851 for ; Thu, 22 Apr 2004 19:38:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGnm2-0000bx-4X for tcpm@ietf.org; Thu, 22 Apr 2004 19:38:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGnlB-0000LM-00 for tcpm@ietf.org; Thu, 22 Apr 2004 19:37:38 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGnkL-0007mg-00 for tcpm@ietf.org; Thu, 22 Apr 2004 19:36:45 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 22 Apr 2004 15:47:05 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3MNaCW9004664; Thu, 22 Apr 2004 16:36:13 -0700 (PDT) Received: from mdalal-u10.cisco.com (mdalal-u10.cisco.com [128.107.162.178]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASI85645; Thu, 22 Apr 2004 16:35:25 -0700 (PDT) Date: Thu, 22 Apr 2004 16:36:11 -0700 (PDT) From: Mitesh Dalal To: cjbc@it.uc3m.es, mallman@icir.org cc: tcpm@ietf.org, faber@isi.edu Subject: Re: [tcpm] new work item: TCP security issue In-Reply-To: <200404222325.QAA22830@cypher.cisco.com> Message-ID: References: <200404222325.QAA22830@cypher.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 >From: Carlos Jess Bernardos Cano > > Hi Mark and all, > > Thanks for the draft. We have been working on a similar TCP attack to > the ones pointed in this draft. We submitted an Internet-Draft to the > TSVWG (the TCPM WG had not been created yet), and we are working on it > to provide a new version. Current release can be downloaded from > http://www.it.uc3m.es/cjbc/drafts/draft-azcorra-tsvwg-tcp-blind-ack-dos-01.= > txt > > We think (and we have also performed some tests proving it) that the > attack pointed in our draft is also a very dangerous threat and that the > proposed changes (server-side changes) eliminate or at least minimise > the treats to a more acceptable level. > > Please provide any comment. If the discussion results in this attack > being interesting to take into account, we can provide a contribution to > the tcpsecure draft in the form of a section. > I had a cursory look at the paper and the paper seem to be making 3 HUGE assumptions: 1. The server will establish a connection with you. 2. The server has obscene amount of data to send. 3. The application has no authentication of its own. I have no idea what application you have in mind. Lets talk about ftp. ftp has username/password protection. Lets talk about rcp. Client has to be in the trusted database. Clearly, I cannot see opening a http connection to a web portal generating 25MB of data. I do not even want to go into the solution, but for starters: " The proposed changes are the following: 1. A server SHOULD reset the TCP connection (i.e. send a RST) if it receives an ACK for data that is in SND.NXT <= SEG.ACK <= (SND.UNA + SND.WND). " so you are saying that an attacker needs to hit your window to hose your legit connection ? thx Mitesh > Kind regards, > > Carlos J. > > El mar, 20-04-2004 a las 22:03, Mark Allman escribi=F3: > > Just announced internet-draft: > > > Title : Transmission Control Protocol security consideration= > s > > > Author(s) : R. Stewart > > > Filename : draft-ietf-tcpm-tcpsecure-00.txt > > > Pages : 10 > > > Date : 2004-4-20 > > > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt > > =20 > > Hi folks! > >=20 > > We wanted to announce a new I-D and TCPM work item. The draft is > > "Transmission Control Protocol security considerations" > > (draft-ietf-tcpm-tcpsecure-00.txt). We believe we owe a bit in the way > > of explanation since it seems that this is being foisted upon the WG > > without much input. =20 > >=20 > > The brief story is that a bunch of folks were made aware of the TCP > > security vulnerability outlined in the above draft. (I think many > > people have been aware of these things for a long time. But, the driver > > here is that there is a new conference paper that is going to show the > > ease with which the vulnerability can be exploited.) Many people from a > > number of TCP implementers (vendors) have been busily working behind the > > scenes to come up with reasonable fixes before the vulnerability was > > announced. The fixes are in the I-D. The vulnerability has been > > announced (via the standard security issues venues). As part of this > > process Randall Stewart wrote the above mentioned I-D for this WG to > > ponder. > >=20 > > A few notes since this I-D got adopted as a WG item with zero public / > > open input: > >=20 > > * Until the vulnerability was announced we didn't want to entertain a > > huge discussion on the public mailing list for obvious reasons. > >=20 > > * The transport ADs, security ADs and TCPM WG chairs all agreed that > > this is an important problem to address and that TCPM is the correct > > WG in which to address it. That said, if folks think we made the > > wrong call here, please feel free to speak up and tell us why we > > screwed up. > >=20 > > * The fixes suggested in the above I-D are not being pre-judged as > > *THE* answer. Rather, they represent *A POSSIBLE* solution (and > > running code) that this WG will consider. In other words, we are > > not trying to simply ram this document through the WG and produce an > > RFC. This WG will deliberate on the I-D as it would any other. > >=20 > > * Alternate solutions are welcome. We would like to encourage folks > > who have different solutions to the problems outlined in the draft > > to put those forward for consideration. > >=20 > > Any other comments folks have on this draft / issue are very welcome. > >=20 > > Thanks! > >=20 > > Mark & Ted > >=20 > --=20 > Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ > GPG FP: 1880 80D3 8004 25C7 6537 8E02 252A D295 9CFF DEAF > > --=-ByOBr8IpRPQzNa01R822 > Content-Type: application/pgp-signature; name=signature.asc > Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada > digitalmente > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (GNU/Linux) > > iD8DBQBAiAQMJSrSlZz/3q8RAlzRAKDIDArBJnagxolXThkwDwuwMbOBDACfb0Po > 8b12ChJx9PkrmIu4N2B5X2g= > =2JHQ > -----END PGP SIGNATURE----- > > --=-ByOBr8IpRPQzNa01R822-- > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu Apr 22 21:10:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17198 for ; Thu, 22 Apr 2004 21:10:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGp9o-0003Wz-Fb for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 21:07:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3N178fP013571 for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 21:07:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGp5N-0001bJ-AZ for tcpm-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 21:02:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16749 for ; Thu, 22 Apr 2004 21:02:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGp5I-00071k-Oo for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 21:02:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGp4H-0006mn-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 21:01:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGp3d-0006Xr-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 21:00:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGosI-0006jA-3y; Thu, 22 Apr 2004 20:49:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGoiw-0003Ra-Db for tcpm@optimus.ietf.org; Thu, 22 Apr 2004 20:39:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15444 for ; Thu, 22 Apr 2004 20:39:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGois-0000e1-3M for tcpm@ietf.org; Thu, 22 Apr 2004 20:39:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGogq-0007lk-00 for tcpm@ietf.org; Thu, 22 Apr 2004 20:37:13 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGoet-00079c-00 for tcpm@ietf.org; Thu, 22 Apr 2004 20:35:11 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BGo9C-0006md-Nx for tcpm@ietf.org; Thu, 22 Apr 2004 20:02:26 -0400 Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3N00HN01258; Thu, 22 Apr 2004 17:00:17 -0700 (PDT) Message-ID: <40885C96.2080002@isi.edu> Date: Thu, 22 Apr 2004 17:00:22 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Randall Stewart (cisco)" CC: weddy@grc.nasa.gov, tcpm@ietf.org Subject: Re: [tcpm] alternative RST processing References: <20040422123413.GA20156@grc.nasa.gov> <4087B3EA.8030405@cisco.com> In-Reply-To: <4087B3EA.8030405@cisco.com> X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig39763211F1CDF1CA24524373" X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig39763211F1CDF1CA24524373 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Randall Stewart (cisco) wrote: > Wesley Eddy wrote: > >> As an alternative to combat the blind RST attack, instead of using ACKs >> for challenge-response, it should also suffice to modify the TCP state >> machine to not go into CLOSED on a RST, but transition into the >> TIME-WAIT state. With another transition to come back to ESTABLISHED on >> receipt of data, this seems like it would work. >> >> -Wes >> >> > Wes: > > Would this not cause any TIME-WAIT state connection to > "revive" if a old data segment arrives from the network then? > > R At best, as I suggested in another post, it is the source of the RST that should go into TW not the receiver. There's no way for the source to know whether the receiver got the RST or not. FWIW, as Ted just pointed out when he walked by, TCP doesn't require this. Perhaps it's time for _that_ ID as a WG item? Joe --------------enig39763211F1CDF1CA24524373 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAiFyXE5f5cImnZrsRAiDtAKCJ0vVoCA0O4kMnHgY59t5qLNL6xACfWSpd 86kjIfYLBVvj8TFQDa4/dPw= =84Ou -----END PGP SIGNATURE----- --------------enig39763211F1CDF1CA24524373-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu Apr 22 21:31:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18012 for ; Thu, 22 Apr 2004 21:31:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGpVW-000234-Dk for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 21:29:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3N1TYaQ007870 for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 21:29:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGpKk-0007Ut-3w for tcpm-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 21:18:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17652 for ; Thu, 22 Apr 2004 21:18:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGpKf-0003fT-FD for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 21:18:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGpJg-0003Np-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 21:17:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGpIg-00031I-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 21:16:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGpGT-0006Ci-8S; Thu, 22 Apr 2004 21:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGpBB-0004IF-UV for tcpm@optimus.ietf.org; Thu, 22 Apr 2004 21:08:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16954 for ; Thu, 22 Apr 2004 21:08:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGpB7-0000pE-7T for tcpm@ietf.org; Thu, 22 Apr 2004 21:08:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGpA7-0000X9-00 for tcpm@ietf.org; Thu, 22 Apr 2004 21:07:28 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1BGp9F-000016-00 for tcpm@ietf.org; Thu, 22 Apr 2004 21:06:33 -0400 Received: from bu-ewat02-01.uk.sun.com ([129.156.199.2]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i3N1646b013460; Thu, 22 Apr 2004 18:06:05 -0700 (PDT) Received: from uk.sun.com (vpn-129-156-96-92.EMEA.Sun.COM [129.156.96.92]) by bu-ewat02-01.uk.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i3N1633D014286; Fri, 23 Apr 2004 02:06:03 +0100 (BST) Message-ID: <40886BD6.5000800@uk.sun.com> Date: Fri, 23 Apr 2004 02:05:26 +0100 From: Jeremy Harris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.6) Gecko/20040113 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Yogesh Prem Swami CC: tcpm@ietf.org Subject: Re: FW: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: <025E7DD4182874489CC2F61EE0FA19CE02885696@daebe004.americas.nokia.com> <4087B232.4050203@cisco.com> <4087DDE6.3020703@nokia.com> In-Reply-To: <4087DDE6.3020703@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Yogesh Prem Swami wrote: > So now my question is, which of these categories of attacks should be > solved and which ones should not be. (I'd vote for 1 and 2, and leave 3 > out). Also, there are different routes that one can take to solve these > problems. > > Route-1: Fix individual vulnerabilities in the protocols by changing the > protocol mechanism itself. "TCP secure" draft has taken this route. > > Route-2: Have a single protocol mechanism (e.g., by defining a new > option or reusing an old one) that solves most of the problems.(I'd > personally prefer this over Route-1). For Route-2, again there are > couple of options. > Route-2-a: Use crypto methods to solve the problem, but > without doing key exchange. (Got my vote) > Route-2-b: Use crypto, but with key exchange. Route-2-c: expand the sequence space. (No crypto, another option, two (say) 64-bit sequence numbers per packet; the probability swings against the attacker) - Jeremy _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu Apr 22 21:52:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19023 for ; Thu, 22 Apr 2004 21:52:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGpmZ-0007ya-Jr for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 21:47:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3N1lBrB030655 for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 21:47:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGpj8-0006fi-3z for tcpm-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 21:43:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18574 for ; Thu, 22 Apr 2004 21:43:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGpj3-0002Rn-8a for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 21:43:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGpi2-00029X-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 21:42:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGph9-0001sC-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 21:41:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGpWw-0002e4-G1; Thu, 22 Apr 2004 21:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGpTS-0001Fl-Up for tcpm@optimus.ietf.org; Thu, 22 Apr 2004 21:27:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17922 for ; Thu, 22 Apr 2004 21:27:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGpTO-0005we-6z for tcpm@ietf.org; Thu, 22 Apr 2004 21:27:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGpSS-0005iJ-00 for tcpm@ietf.org; Thu, 22 Apr 2004 21:26:25 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGpS9-0005Tz-00 for tcpm@ietf.org; Thu, 22 Apr 2004 21:26:05 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 22 Apr 2004 17:37:38 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3N1PXC1003157; Thu, 22 Apr 2004 18:25:34 -0700 (PDT) Received: from irp-view8.cisco.com (irp-view8.cisco.com [171.70.65.145]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASI94081; Thu, 22 Apr 2004 18:24:46 -0700 (PDT) Date: Thu, 22 Apr 2004 18:25:32 -0700 (PDT) From: Mitesh Dalal To: Jeremy Harris cc: Yogesh Prem Swami , tcpm@ietf.org Subject: Re: FW: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt In-Reply-To: <40886BD6.5000800@uk.sun.com> Message-ID: References: <025E7DD4182874489CC2F61EE0FA19CE02885696@daebe004.americas.nokia.com> <4087B232.4050203@cisco.com> <4087DDE6.3020703@nokia.com> <40886BD6.5000800@uk.sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Fri, 23 Apr 2004, Jeremy Harris wrote: > Yogesh Prem Swami wrote: > > > So now my question is, which of these categories of attacks should be > > solved and which ones should not be. (I'd vote for 1 and 2, and leave 3 > > out). Also, there are different routes that one can take to solve these > > problems. > > > > Route-1: Fix individual vulnerabilities in the protocols by changing the > > protocol mechanism itself. "TCP secure" draft has taken this route. > > > > Route-2: Have a single protocol mechanism (e.g., by defining a new > > option or reusing an old one) that solves most of the problems.(I'd > > personally prefer this over Route-1). For Route-2, again there are > > couple of options. > > Route-2-a: Use crypto methods to solve the problem, but > > without doing key exchange. (Got my vote) > > Route-2-b: Use crypto, but with key exchange. > > Route-2-c: expand the sequence space. > > (No crypto, another option, two (say) 64-bit sequence numbers > per packet; the probability swings against the attacker) > the problem with this route is that option space is already at a premium and further this may not be backward compatible. If option agreement fails you still remain vulnerable ? thx Mitesh _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu Apr 22 22:16:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20229 for ; Thu, 22 Apr 2004 22:16:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGq3v-0004jQ-G0 for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 22:05:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3N257SC018180 for tcpm-archive@odin.ietf.org; Thu, 22 Apr 2004 22:05:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGq1j-0003wr-Ge for tcpm-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 22:02:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19569 for ; Thu, 22 Apr 2004 22:02:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGq1e-0007ii-EH for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 22:02:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGq0p-0007Qq-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 22:01:55 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGq05-000789-00 for tcpm-web-archive@ietf.org; Thu, 22 Apr 2004 22:01:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGpsD-0001EE-8F; Thu, 22 Apr 2004 21:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGpjx-0006xZ-24 for tcpm@optimus.ietf.org; Thu, 22 Apr 2004 21:44:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18612 for ; Thu, 22 Apr 2004 21:44:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGpjs-0002kI-3G for tcpm@ietf.org; Thu, 22 Apr 2004 21:44:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGpiu-0002QS-00 for tcpm@ietf.org; Thu, 22 Apr 2004 21:43:25 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx with esmtp (Exim 4.12) id 1BGphn-0001uK-00 for tcpm@ietf.org; Thu, 22 Apr 2004 21:42:15 -0400 Received: from jurassic.eng.sun.com ([129.146.85.105]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i3N1f9sT016703 for ; Thu, 22 Apr 2004 19:41:09 -0600 (MDT) Received: from sun.com (shield.SFBay.Sun.COM [129.144.60.49]) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i3N1gIsY566437 for ; Thu, 22 Apr 2004 18:42:18 -0700 (PDT) Message-ID: <40887479.60409@sun.com> Date: Thu, 22 Apr 2004 18:42:17 -0700 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.6) Gecko/20040117 X-Accept-Language: en, zh-hk, zh-tw, zh-cn MIME-Version: 1.0 To: tcpm@ietf.org Subject: Re: [tcpm] new work item: TCP security issue References: <20040422131919.AFBCE77A6E0@guns.icir.org> <40881FB9.701@sun.com> In-Reply-To: <40881FB9.701@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit A follow up on the timestamp suggestion. Since most TCP stacks ignore the timestamp option if RST bit is set, following the suggestion in RFC 1323, including timestamp option in RST should not cause compatibility issue. If timestamp is included in RST, a TCP receiver A can choose to verify that the validity of the timestamp and/or timestamp echo. If the RST is triggered by a segment sent by the receiver A, it should be possible to include both valid timestamp and timestamp echo info. If the RST is generated by the sender B when the app aborts the connection, it should also contain the valid info for A to accept the RST. With this and a TCP socket option for an app to tell the stack to have a "strict" timestamp enforcement, will this solve the issues described in the draft? If the TCP option is not set, TCP's behavior does not change. Comments? -- K. Poon. kacheong.poon@sun.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 02:53:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17831 for ; Fri, 23 Apr 2004 02:53:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGuXX-0000E4-8w for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 02:51:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3N6pxdv000861 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 02:51:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGuUT-0007cR-8U for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 02:48:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17725 for ; Fri, 23 Apr 2004 02:48:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGuUN-0000DX-EB for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 02:48:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGuTQ-0007lK-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 02:47:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGuTA-0007Vd-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 02:47:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGuNt-00060i-HI; Fri, 23 Apr 2004 02:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGuEt-0002gN-RS for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 02:32:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17054 for ; Fri, 23 Apr 2004 02:32:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGuEn-0003rG-SM for tcpm@ietf.org; Fri, 23 Apr 2004 02:32:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGuDn-0003ao-00 for tcpm@ietf.org; Fri, 23 Apr 2004 02:31:35 -0400 Received: from mail.enyo.de ([212.9.189.167]) by ietf-mx with esmtp (Exim 4.12) id 1BGuCr-0003Kz-00 for tcpm@ietf.org; Fri, 23 Apr 2004 02:30:37 -0400 Received: (debugging) helo=deneb ip=212.9.189.171 name=deneb.enyo.de Received: from deneb.enyo.de ([212.9.189.171] helo=deneb) by mail.enyo.de with esmtp id 1BGuCo-0000Qs-HY; Fri, 23 Apr 2004 08:30:34 +0200 Received: from fw by deneb with local (Exim 4.32) id 1BGuCo-0000s9-84; Fri, 23 Apr 2004 08:30:34 +0200 To: Mitesh Dalal Cc: Allison Mankin , Tim Shepard , tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: <87llknsluk.fsf@deneb.enyo.de> From: Florian Weimer Date: Fri, 23 Apr 2004 08:30:34 +0200 In-Reply-To: (Mitesh Dalal's message of "Thu, 22 Apr 2004 16:58:50 -0700 (PDT)") Message-ID: <87isfrfbp1.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Mitesh Dalal writes: > On Fri, 23 Apr 2004, Florian Weimer wrote: > >> Allison Mankin writes: >> >> > I agree the draft should mention the point about ports and addresses. >> >> Vendors seem to disagree and hesitate to add source port >> randomization. I don't know why. 8-( > > Port allocation is an implementation issue and the current issue > we have at hand is a flaw in the original standard. Why do you think this is a flaw in TCP? Which specification is violated? -- Current mail filters: many dial-up/DSL/cable modem hosts, and the following domains: atlas.cz, bigpond.com, postino.it, tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 04:46:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22539 for ; Fri, 23 Apr 2004 04:46:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGwHM-0006NG-Mi for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 04:43:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3N8hOQW024502 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 04:43:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGwCs-0004vQ-5o for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 04:38:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22094 for ; Fri, 23 Apr 2004 04:38:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGwCn-0006dG-3t for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 04:38:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGwBp-0006MP-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 04:37:42 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGwAs-00065z-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 04:36:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGw7J-0003Hj-QM; Fri, 23 Apr 2004 04:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGw2H-0001jy-9C for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 04:27:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21600 for ; Fri, 23 Apr 2004 04:27:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGw2A-0003bG-0X for tcpm@ietf.org; Fri, 23 Apr 2004 04:27:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGw1B-0003Kx-00 for tcpm@ietf.org; Fri, 23 Apr 2004 04:26:42 -0400 Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx with esmtp (Exim 4.12) id 1BGw08-0002pg-00 for tcpm@ietf.org; Fri, 23 Apr 2004 04:25:36 -0400 Received: from localhost (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with SMTP id 191ED2392B; Fri, 23 Apr 2004 10:25:09 +0200 (CEST) Received: from acorde.it.uc3m.es (acorde.it.uc3m.es [163.117.139.72]) by smtp03.uc3m.es (Postfix) with ESMTP id ACA2B2392D; Fri, 23 Apr 2004 10:24:59 +0200 (CEST) Subject: Re: [tcpm] new work item: TCP security issue From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Mitesh Dalal Cc: mallman@icir.org, tcpm@ietf.org, faber@isi.edu, Ignacio Soto Campos In-Reply-To: References: <200404222325.QAA22830@cypher.cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-uXu0PWDvJr7PNRxX9DJh" Organization: Universidad Carlos III de Madrid Message-Id: <1082708698.1144.89.camel@acorde> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 23 Apr 2004 10:24:58 +0200 Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --=-uXu0PWDvJr7PNRxX9DJh Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Mitesh, Thanks for your comments. Please, see in-line. =09 El vie, 23-04-2004 a las 01:36, Mitesh Dalal escribi=F3: > >From: Carlos Jess Bernardos Cano > > > > Hi Mark and all, > > > > Thanks for the draft. We have been working on a similar TCP attack to > > the ones pointed in this draft. We submitted an Internet-Draft to the > > TSVWG (the TCPM WG had not been created yet), and we are working on it > > to provide a new version. Current release can be downloaded from > > http://www.it.uc3m.es/cjbc/drafts/draft-azcorra-tsvwg-tcp-blind-ack-dos= -01.=3D > > txt > > > > We think (and we have also performed some tests proving it) that the > > attack pointed in our draft is also a very dangerous threat and that th= e > > proposed changes (server-side changes) eliminate or at least minimise > > the treats to a more acceptable level. > > > > Please provide any comment. If the discussion results in this attack > > being interesting to take into account, we can provide a contribution t= o > > the tcpsecure draft in the form of a section. > > >=20 >=20 > I had a cursory look at the paper and the paper > seem to be making 3 HUGE assumptions: >=20 > 1. The server will establish a connection with you. > 2. The server has obscene amount of data to send. > 3. The application has no authentication of its own. >=20 > I have no idea what application you have in mind. > Lets talk about ftp. ftp has username/password > protection. Lets talk about rcp. Client has to > be in the trusted database. Clearly, I cannot > see opening a http connection to a web portal > generating 25MB of data. The attack can be performed with several tcp connections at the same time, so it is feasible to get an http server to send this rate (we tested it with an http server, you can see the numbers we got in the draft). Notice also, a lot of http servers provide access to quite big files. >=20 > I do not even want to go into the solution, but > for starters: >=20 > " > The proposed changes are the following: > 1. A server SHOULD reset the TCP connection (i.e. send a RST) if it > receives an ACK for data that is in SND.NXT <=3D SEG.ACK <=3D > (SND.UNA + SND.WND). > " >=20 > so you are saying that an attacker needs to hit your > window to hose your legit connection ? No, we aren't. An attacker has to forge the origin IP address and the ports numbers, not only the window. This is not new, because this can be done with a RST. Kind regards, Carlos J. >=20 > thx > Mitesh >=20 >=20 > > Kind regards, > > > > Carlos J. > > > > El mar, 20-04-2004 a las 22:03, Mark Allman escribi=3DF3: > > > Just announced internet-draft: > > > > Title : Transmission Control Protocol security considera= tion=3D > > s > > > > Author(s) : R. Stewart > > > > Filename : draft-ietf-tcpm-tcpsecure-00.txt > > > > Pages : 10 > > > > Date : 2004-4-20 > > > > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.t= xt > > > =3D20 > > > Hi folks! > > >=3D20 > > > We wanted to announce a new I-D and TCPM work item. The draft is > > > "Transmission Control Protocol security considerations" > > > (draft-ietf-tcpm-tcpsecure-00.txt). We believe we owe a bit in the w= ay > > > of explanation since it seems that this is being foisted upon the WG > > > without much input. =3D20 > > >=3D20 > > > The brief story is that a bunch of folks were made aware of the TCP > > > security vulnerability outlined in the above draft. (I think many > > > people have been aware of these things for a long time. But, the dri= ver > > > here is that there is a new conference paper that is going to show th= e > > > ease with which the vulnerability can be exploited.) Many people fro= m a > > > number of TCP implementers (vendors) have been busily working behind = the > > > scenes to come up with reasonable fixes before the vulnerability was > > > announced. The fixes are in the I-D. The vulnerability has been > > > announced (via the standard security issues venues). As part of this > > > process Randall Stewart wrote the above mentioned I-D for this WG to > > > ponder. > > >=3D20 > > > A few notes since this I-D got adopted as a WG item with zero public = / > > > open input: > > >=3D20 > > > * Until the vulnerability was announced we didn't want to entertain= a > > > huge discussion on the public mailing list for obvious reasons. > > >=3D20 > > > * The transport ADs, security ADs and TCPM WG chairs all agreed tha= t > > > this is an important problem to address and that TCPM is the corr= ect > > > WG in which to address it. That said, if folks think we made the > > > wrong call here, please feel free to speak up and tell us why we > > > screwed up. > > >=3D20 > > > * The fixes suggested in the above I-D are not being pre-judged as > > > *THE* answer. Rather, they represent *A POSSIBLE* solution (and > > > running code) that this WG will consider. In other words, we are > > > not trying to simply ram this document through the WG and produce= an > > > RFC. This WG will deliberate on the I-D as it would any other. > > >=3D20 > > > * Alternate solutions are welcome. We would like to encourage folk= s > > > who have different solutions to the problems outlined in the draf= t > > > to put those forward for consideration. > > >=3D20 > > > Any other comments folks have on this draft / issue are very welcome. > > >=3D20 > > > Thanks! > > >=3D20 > > > Mark & Ted > > >=3D20 > > --=3D20 > > Carlos Jes=3DFAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ > > GPG FP: 1880 80D3 8004 25C7 6537 8E02 252A D295 9CFF DEAF > > > > --=3D-ByOBr8IpRPQzNa01R822 > > Content-Type: application/pgp-signature; name=3Dsignature.asc > > Content-Description: Esta parte del mensaje =3D?ISO-8859-1?Q?est=3DE1?= =3D firmada > > digitalmente > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.2.4 (GNU/Linux) > > > > iD8DBQBAiAQMJSrSlZz/3q8RAlzRAKDIDArBJnagxolXThkwDwuwMbOBDACfb0Po > > 8b12ChJx9PkrmIu4N2B5X2g=3D > > =3D2JHQ > > -----END PGP SIGNATURE----- > > > > --=3D-ByOBr8IpRPQzNa01R822-- > > > > > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www1.ietf.org/mailman/listinfo/tcpm > > > > --=20 Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 --=-uXu0PWDvJr7PNRxX9DJh Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBAiNLZ5vKyPtrWqkARApzvAJ9X2u8UQ8ZDCQmBaLt9dkHM1B28kQCbB0AA sNw4gYn00rlY2GT/2eKsSEI= =0iTE -----END PGP SIGNATURE----- --=-uXu0PWDvJr7PNRxX9DJh-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 07:26:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28373 for ; Fri, 23 Apr 2004 07:26:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGynm-0006Dq-IH for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 07:25:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NBP2I0023912 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 07:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGyhu-0005AJ-Gy for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 07:18:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28147 for ; Fri, 23 Apr 2004 07:18:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGyhu-0002QS-3S for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 07:18:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGygx-0001wW-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 07:18:00 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGyft-0001gP-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 07:16:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGyc8-0003ek-K2; Fri, 23 Apr 2004 07:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGyaN-00037D-OR for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 07:11:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27876 for ; Fri, 23 Apr 2004 07:11:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGyaH-0000Jv-9r for tcpm@ietf.org; Fri, 23 Apr 2004 07:11:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGyZK-00002x-00 for tcpm@ietf.org; Fri, 23 Apr 2004 07:10:07 -0400 Received: from lmr1.uibk.ac.at ([138.232.1.142] helo=smtp.uibk.ac.at) by ietf-mx with esmtp (Exim 4.12) id 1BGyYa-0007X3-00 for tcpm@ietf.org; Fri, 23 Apr 2004 07:09:20 -0400 Received: from localhost (lwm1.uibk.ac.at [138.232.1.160]) by smtp.uibk.ac.at (8.12.10/8.12.10/F1) with ESMTP id i3NB8qkE019627; Fri, 23 Apr 2004 13:08:52 +0200 Received: from c703-pc442.uibk.ac.at (c703-pc442.uibk.ac.at [138.232.95.130]) by web-mail1.uibk.ac.at (IMP) with HTTP for ; Fri, 23 Apr 2004 13:08:52 +0200 Message-ID: <1082718532.4088f94444d8f@web-mail1.uibk.ac.at> Date: Fri, 23 Apr 2004 13:08:52 +0200 From: Michael Welzl To: "Fu Cheng Peng, Franklin" Cc: end2end-interest@postel.org, tcpm@ietf.org References: <7CD06E15ADF4104A9F2E4DC2DE678F89544487@EXCHANGE21.staff.main.ntu.edu.sg> In-Reply-To: <7CD06E15ADF4104A9F2E4DC2DE678F89544487@EXCHANGE21.staff.main.ntu.edu.sg> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 138.232.95.130 X-Spam-Score: -6.0 () RCV_SMTP_UIBK,RCV_WEBMAIL X-Scanned-By: MIMEDefang 2.42 at uibk.ac.at Content-Transfer-Encoding: 8bit Subject: [tcpm] RE: [e2e] Open the floodgate Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, I like this approach, and I know lots of related papers; I believe I even saw a draft on something like this recently (perhaps in tcpm, or tsvwg?). I am very much in favor of these things. Still, my question remains: why don't we have these separate checksums as a TCP option? It strikes me as a rather simple method for links where erroneous data are actually handed over, and I believe that it's about time we transferred these things from the world of research into the IETF. It's strange that we all know this problem and there are a billion related papers out there when my TCP/IP stack still doesn't do anything in this aspect. I'm cc'ing tcpm. Cheers, Michael Zitat von "Fu Cheng Peng, Franklin" : > One possible solution to solve the loss type distinghishing between > congestion loss and random loss, seeing TCP Veno at JSAC Feb.. 2003, or > at http://www.ntu.edu.sg/home/ascpfu/veno.pdf > > > -Franklin > > > > -----Original Message----- > > From: end2end-interest-bounces@postel.org > > [mailto:end2end-interest-bounces@postel.org] On Behalf Of > > Michael Welzl > > Sent: Friday, April 23, 2004 1:41 PM > > To: Noel Chiappa > > Cc: end2end-interest@postel.org > > Subject: Re: [e2e] Open the floodgate > > > > > > > > a protocol that believes it needs to slow down > > whenever it sees a > > > > packet loss. > > > > > > Look, we all have known for some time that i) TCP can't currently > > > distinguish between error loss and congestion loss, and ii) slowing > > > down for an error loss is a mistake. (In fact, I'm losing horribly > > > these days because my mail is kept on a host which is on a network > > > which is losing packets, so I am personally aware of this issue.) > > > We're not cretins. You don't need to keep repeating it. > > > > So why don't we have separate header/payload checksums in TCP > > yet via a header option, as we now have in DCCP? > > > > (Potential problem: no coverage field for the regular > > checksum in TCP - so this option would have to redefine the > > semantics of the TCP header ... oh well - is that the reason?) > > > > Cheers, > > Michael > > > > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 08:48:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02132 for ; Fri, 23 Apr 2004 08:48:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH056-00019B-05 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 08:47:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NCkxfW004405 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 08:46:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH03F-0000hf-SV for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 08:45:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01820 for ; Fri, 23 Apr 2004 08:45:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH03E-0001XB-Ji for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 08:45:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH02K-0001Ho-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 08:44:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH01h-00012a-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 08:43:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGzuU-0006ig-2d; Fri, 23 Apr 2004 08:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGzoI-0004w9-8C for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 08:29:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00803 for ; Fri, 23 Apr 2004 08:29:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGzoG-000552-Vm for tcpm@ietf.org; Fri, 23 Apr 2004 08:29:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGzml-0004j5-00 for tcpm@ietf.org; Fri, 23 Apr 2004 08:28:04 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGzm6-0004PM-00 for tcpm@ietf.org; Fri, 23 Apr 2004 08:27:22 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 23 Apr 2004 04:37:45 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3NCQlSu017838; Fri, 23 Apr 2004 05:26:48 -0700 (PDT) Received: from cisco.com (rtp-dial-1-8.cisco.com [10.83.97.8]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATH97970; Fri, 23 Apr 2004 05:26:45 -0700 (PDT) Message-ID: <40890B4D.4090607@cisco.com> Date: Fri, 23 Apr 2004 08:25:49 -0400 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kacheong Poon CC: tcpm@ietf.org Subject: Re: [tcpm] new work item: TCP security issue References: <20040422131919.AFBCE77A6E0@guns.icir.org> <40881FB9.701@sun.com> <40887479.60409@sun.com> In-Reply-To: <40887479.60409@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Kacheong: I don't see this has any more or any less work to whats in the draft... if I remember from my BSD coding of this it takes about 10 or so lines of code to do the things in the draft... I would think the T-S option would also take the same or maybe a bit more... And I think you probably will need to do a lot more in firewalls which currently ignore timestamps (I would imagine). R Kacheong Poon wrote: > A follow up on the timestamp suggestion. Since most TCP > stacks ignore the timestamp option if RST bit is set, > following the suggestion in RFC 1323, including timestamp > option in RST should not cause compatibility issue. > > If timestamp is included in RST, a TCP receiver A can > choose to verify that the validity of the timestamp > and/or timestamp echo. If the RST is triggered by a > segment sent by the receiver A, it should be possible to > include both valid timestamp and timestamp echo info. > If the RST is generated by the sender B when the app > aborts the connection, it should also contain the > valid info for A to accept the RST. > > With this and a TCP socket option for an app to tell the > stack to have a "strict" timestamp enforcement, will this > solve the issues described in the draft? If the TCP option > is not set, TCP's behavior does not change. Comments? > > -- Randall R. Stewart ITD - Transport Technologies 815-477-2127(o) or 815-342-5222(c) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 08:58:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02522 for ; Fri, 23 Apr 2004 08:58:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH0Ey-0003vh-Dy for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 08:57:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NCvCpX015100 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 08:57:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH06j-0001Zz-45 for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 08:48:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02065 for ; Fri, 23 Apr 2004 08:48:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH06h-0002L8-Pw for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 08:48:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH04z-00022Z-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 08:46:54 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH03x-0001fM-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 08:45:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGzua-0006kk-Ba; Fri, 23 Apr 2004 08:36:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGzqa-0005DY-3r for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 08:32:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01281 for ; Fri, 23 Apr 2004 08:31:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGzqY-00060R-RF for tcpm@ietf.org; Fri, 23 Apr 2004 08:31:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGzpg-0005hQ-00 for tcpm@ietf.org; Fri, 23 Apr 2004 08:31:06 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGzoL-000525-00 for tcpm@ietf.org; Fri, 23 Apr 2004 08:29:41 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 23 Apr 2004 04:41:16 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3NCT7Su019532; Fri, 23 Apr 2004 05:29:07 -0700 (PDT) Received: from cisco.com (rtp-dial-1-8.cisco.com [10.83.97.8]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATH98038; Fri, 23 Apr 2004 05:29:03 -0700 (PDT) Message-ID: <40890BD7.9020908@cisco.com> Date: Fri, 23 Apr 2004 08:28:07 -0400 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mitesh Dalal CC: cjbc@it.uc3m.es, mallman@icir.org, tcpm@ietf.org, faber@isi.edu Subject: Re: [tcpm] new work item: TCP security issue References: <200404222325.QAA22830@cypher.cisco.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mitesh Dalal wrote: >>From: Carlos Jess Bernardos Cano >> >>Hi Mark and all, >> >> Thanks for the draft. We have been working on a similar TCP attack to >>the ones pointed in this draft. We submitted an Internet-Draft to the >>TSVWG (the TCPM WG had not been created yet), and we are working on it >>to provide a new version. Current release can be downloaded from >>http://www.it.uc3m.es/cjbc/drafts/draft-azcorra-tsvwg-tcp-blind-ack-dos-01.= >>txt >> >> We think (and we have also performed some tests proving it) that the >>attack pointed in our draft is also a very dangerous threat and that the >>proposed changes (server-side changes) eliminate or at least minimise >>the treats to a more acceptable level. >> >> Please provide any comment. If the discussion results in this attack >>being interesting to take into account, we can provide a contribution to >>the tcpsecure draft in the form of a section. >> >> >> > > >I had a cursory look at the paper and the paper >seem to be making 3 HUGE assumptions: > >1. The server will establish a connection with you. >2. The server has obscene amount of data to send. >3. The application has no authentication of its own. > >I have no idea what application you have in mind. >Lets talk about ftp. ftp has username/password >protection. Lets talk about rcp. Client has to >be in the trusted database. Clearly, I cannot >see opening a http connection to a web portal >generating 25MB of data. > >I do not even want to go into the solution, but >for starters: > >" > The proposed changes are the following: > 1. A server SHOULD reset the TCP connection (i.e. send a RST) if it > receives an ACK for data that is in SND.NXT <= SEG.ACK <= > (SND.UNA + SND.WND). >" > Actually would not this make a RST attack possible to a blind attacker? All I have to do is send in a ACK to a connection from one endpoint to the other... and in a few short segments I can get one that the SEG.ACK is above SND.NXT and thus the peer will send a RST to its fellow... Not good.. R > >so you are saying that an attacker needs to hit your >window to hose your legit connection ? > >thx >Mitesh > > > > >> Kind regards, >> >> Carlos J. >> >>El mar, 20-04-2004 a las 22:03, Mark Allman escribi=F3: >> >> >>>Just announced internet-draft: >>> >>> >>>> Title : Transmission Control Protocol security consideration= >>>> >>>> >>s >> >> >>>> Author(s) : R. Stewart >>>> Filename : draft-ietf-tcpm-tcpsecure-00.txt >>>> Pages : 10 >>>> Date : 2004-4-20 >>>> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt >>>> >>>> >>>=20 >>>Hi folks! >>>=20 >>>We wanted to announce a new I-D and TCPM work item. The draft is >>>"Transmission Control Protocol security considerations" >>>(draft-ietf-tcpm-tcpsecure-00.txt). We believe we owe a bit in the way >>>of explanation since it seems that this is being foisted upon the WG >>>without much input. =20 >>>=20 >>>The brief story is that a bunch of folks were made aware of the TCP >>>security vulnerability outlined in the above draft. (I think many >>>people have been aware of these things for a long time. But, the driver >>>here is that there is a new conference paper that is going to show the >>>ease with which the vulnerability can be exploited.) Many people from a >>>number of TCP implementers (vendors) have been busily working behind the >>>scenes to come up with reasonable fixes before the vulnerability was >>>announced. The fixes are in the I-D. The vulnerability has been >>>announced (via the standard security issues venues). As part of this >>>process Randall Stewart wrote the above mentioned I-D for this WG to >>>ponder. >>>=20 >>>A few notes since this I-D got adopted as a WG item with zero public / >>>open input: >>>=20 >>> * Until the vulnerability was announced we didn't want to entertain a >>> huge discussion on the public mailing list for obvious reasons. >>>=20 >>> * The transport ADs, security ADs and TCPM WG chairs all agreed that >>> this is an important problem to address and that TCPM is the correct >>> WG in which to address it. That said, if folks think we made the >>> wrong call here, please feel free to speak up and tell us why we >>> screwed up. >>>=20 >>> * The fixes suggested in the above I-D are not being pre-judged as >>> *THE* answer. Rather, they represent *A POSSIBLE* solution (and >>> running code) that this WG will consider. In other words, we are >>> not trying to simply ram this document through the WG and produce an >>> RFC. This WG will deliberate on the I-D as it would any other. >>>=20 >>> * Alternate solutions are welcome. We would like to encourage folks >>> who have different solutions to the problems outlined in the draft >>> to put those forward for consideration. >>>=20 >>>Any other comments folks have on this draft / issue are very welcome. >>>=20 >>>Thanks! >>>=20 >>>Mark & Ted >>>=20 >>> >>> >>--=20 >>Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ >>GPG FP: 1880 80D3 8004 25C7 6537 8E02 252A D295 9CFF DEAF >> >>--=-ByOBr8IpRPQzNa01R822 >>Content-Type: application/pgp-signature; name=signature.asc >>Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada >> digitalmente >> >>-----BEGIN PGP SIGNATURE----- >>Version: GnuPG v1.2.4 (GNU/Linux) >> >>iD8DBQBAiAQMJSrSlZz/3q8RAlzRAKDIDArBJnagxolXThkwDwuwMbOBDACfb0Po >>8b12ChJx9PkrmIu4N2B5X2g= >>=2JHQ >>-----END PGP SIGNATURE----- >> >>--=-ByOBr8IpRPQzNa01R822-- >> >> >> >>_______________________________________________ >>tcpm mailing list >>tcpm@ietf.org >>https://www1.ietf.org/mailman/listinfo/tcpm >> >> >> >> > >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www1.ietf.org/mailman/listinfo/tcpm > > > -- Randall R. Stewart ITD - Transport Technologies 815-477-2127(o) or 815-342-5222(c) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 08:59:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02568 for ; Fri, 23 Apr 2004 08:59:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH0F4-0003yf-2p for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 08:57:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NCvItH015280 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 08:57:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH0A3-0002TU-0u for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 08:52:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02289 for ; Fri, 23 Apr 2004 08:52:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH0A1-0003N1-Fi for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 08:52:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH096-00037F-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 08:51:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH08W-0002ra-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 08:50:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH059-00019m-87; Fri, 23 Apr 2004 08:47:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGzzI-00082L-QJ for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 08:41:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01659 for ; Fri, 23 Apr 2004 08:40:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGzzH-0000V1-6D for tcpm@ietf.org; Fri, 23 Apr 2004 08:40:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGzyN-0000FC-00 for tcpm@ietf.org; Fri, 23 Apr 2004 08:40:05 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGzx0-0007Zb-00 for tcpm@ietf.org; Fri, 23 Apr 2004 08:38:38 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 23 Apr 2004 04:49:01 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3NCc5W9029576; Fri, 23 Apr 2004 05:38:05 -0700 (PDT) Received: from cisco.com (rtp-dial-1-8.cisco.com [10.83.97.8]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATH98415; Fri, 23 Apr 2004 05:38:02 -0700 (PDT) Message-ID: <40890DF2.1040700@cisco.com> Date: Fri, 23 Apr 2004 08:37:06 -0400 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Touch CC: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: <40885173.6090804@isi.edu> In-Reply-To: <40885173.6090804@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Joe Touch wrote: Joe: A few comments inline > A few somewhat separate points: > > 1) I agree with a few others that this is not a > substantially worrisome problem. > > The draft would be made much better by, e.g., > pointing out early and directly that > > a) this problem was known before (RFC2385) > > b) the primary change is the increase in the > window, which increases the chance of it > working as an attack > > The current draft (IMO) obfuscates its relation > to 2385, noting it only as an informative ref > (if this isn't normative, though not a protocol, > I'm not sure what is), and as a way to close > the attack "incompletely" (FWIW, the RST trick > is incomplete too). We were going to actually have different wording but could not get it in due to email crossing between Allison and myself... what should have been in the intro section of the document is: " For some uses of TCP, an alternative protection against the threats that these changes address has already been implemented and deployed in the TCP MD5 Signature Option (RFC2385 [2]). Because this option is not negotiated and is implemented with a manually established shared key or password, it has been used for protecting uses of TCP in which the endpoints are managed, such as for BGP peers. RFC3562 [2] provides importance guidance for users of RFC2385 [2] for decreasing their vulnerability to key-guessing. " The next pass will have Allison's wording in it :-D > > > 2) The sky isn't falling I don't think we meant to say that in the draft :-D > > This is critical ONLY for: > > - pairs of machines that OTHERS not > in the path know are communicating > > - that others care to interrupt > > IMO, IPsec or the MD5 signature options are > more than sufficient for these cases. Yep.. but for some reason deployment of these have not happened... I will note that I have heard more ISP's are now interested in MD5 now.. which is a "good thing" :-D > > > Sure, there's an esoteric interest we share > in exploring the space of "can we do better > without slowing down the connection and without > predeploying keys of some sort", but it's > not clear it's worth #3 > > - it IS worth noting that, e.g., as others have > pointed out: > --a) data-level security won't help (TLS) > --b) transport or network security will > (MD5 signatures, IPsec) > --c) cookies are as good as signatures > for this purpose > --d) transport security, whether cookies > or signatures, requires a TCP option, > which could break non-modified receivers > (i.e., aren't as backward-compat as this > might be) > > but since you have to modify the ones you're > trying to protect anyway, so consider it > as a 'dual stack' issue and move on ;-) So are you recommending cookies (or what I would call V-tags).... instead of the current draft proposals... If this is what the working group wants I would be happy to work with the co-authors to redo the document has such... > > > 3) mucking with RSTs can be hazardous > > RST handling is rife with dragons. At the least, > these include: > > --a) when you throw a RST, IMO, _YOU_ ought > to have to go into TIME_WAIT > > if not, you can't ensure that the other end > won't restart the connection and data will > leak in and corrupt...either when the other > side does - or more importantly does not - > implement this solution > > if you're in TIME_WAIT, you shouldn't reply > to ACKs with anything but silence (pg 72) > > the alternative is to add a new state - > TIME_WAIT_RST, which replies to ACKs differently > than TIME_WAIT (which is entered on other events) > > --b) what about when there's lossy pipes? > > You send a RST with the last SEQ number > (after all the data you already sent). But the lost > data means the other side ACKs a lower (modulo > wraparound) SEQ. So you send a RST with that SEQ. > > In the meantime, some of the pipelined data arrives, > increasing the SEQ no. So the new RST shows up. It > get's dropped, and an extra ACK of the new SEQ goes > back to you. > > --- The ID isn't clear that the ACK sent is > i) just an ACK > in which case this pattern can repeat > until all the data is sent, which could > be a LONG TIME Yep.. thats the plan.. a plain ole ACK.. and yep.. until all the data gets across you would have this issue... > > > ii) a RST-ACK > which, since RST bits are processed before > ACK bits, will cause you to reset, somewhat > unexpectedly ;-) Nope.. not this one.. we will need to add wording to emphasis its a plain ole ACK... > > > For these reasons and a few lurking suspicions, I'm hesitant to > change the processing diagram to add new states OR new arcs; > this appears to need BOTH. What would you recommed then? Not do anything? or something else?> R > > > Joe > -- Randall R. Stewart ITD - Transport Technologies 815-477-2127(o) or 815-342-5222(c) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 09:13:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05071 for ; Fri, 23 Apr 2004 09:13:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH0St-0008Ph-MO for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 09:11:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NDBZYE032329 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 09:11:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH0N7-0006No-UY for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 09:05:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04413 for ; Fri, 23 Apr 2004 09:05:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH0N6-0006xw-Dl for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 09:05:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH0Ls-0006b9-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 09:04:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH0KJ-000667-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 09:02:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH0Fo-0004HG-PZ; Fri, 23 Apr 2004 08:58:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH0A6-0002Tf-AK for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 08:52:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02303 for ; Fri, 23 Apr 2004 08:52:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH0A4-0003NQ-Rz for tcpm@ietf.org; Fri, 23 Apr 2004 08:52:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH09B-000381-00 for tcpm@ietf.org; Fri, 23 Apr 2004 08:51:14 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BH08k-0002rR-00 for tcpm@ietf.org; Fri, 23 Apr 2004 08:50:46 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 23 Apr 2004 05:01:09 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3NCoDW9008183; Fri, 23 Apr 2004 05:50:13 -0700 (PDT) Received: from cisco.com (rtp-dial-1-8.cisco.com [10.83.97.8]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATH98976; Fri, 23 Apr 2004 05:50:10 -0700 (PDT) Message-ID: <408910C9.7060700@cisco.com> Date: Fri, 23 Apr 2004 08:49:13 -0400 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Allison Mankin CC: Tim Shepard , tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,WEIRD_PORT autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Allison: How about if we add something like: " TCP implementations MAY also introduce ephemeral port randomization. By randomizing ephemeral ports an attacker would have a less easy time in guessing the four tuples needed to mount a successful attack. " To the introduction section has an addtion? R Allison Mankin wrote: >Hi, Tim, > >I agree the draft should mention the point about ports and addresses. > >Below is an interesting mail from nanog showing how addresses and >ports can be found. Another nanog message mentioned that some router >vendors limit the TCP port range. There is also some nanog chat about >seeing scanners. > >Allison > >----- > >Subject: tcp bgp vulnerability looking glass and route server issues. >Date: Tue, 20 Apr 2004 14:38:18 -0600 >From: "Smith, Donald" >To: > > >John Fraizer author of MRLG one of the looking glass implementations >has updated his code to fix a flaw that provided too much information. > >MRLG-4.3.0 is available at: >Available here: >ftp://ftp.enterzone.net/looking-glass/CURRENT/ > >Some route servers also provide too much info. >This audit was performed yesterday so if you have already fixed this >issue please ignore:-) >Part of this issue is the fact that some router servers provide too much >information. >Without knowing the source/destination ports and IP's this is still a >difficult vulnerability to exploit. > >>From this URL I did a quick audit. >http://www.traceroute.org/#Route%20Servers >I did NOT look at the looking glass URLs just the route servers. > >This is the list of open route servers I did a quick audit on. >No connection means I was unable to connect to it. >Not misconfigured meant sho ip bgp nei did NOT work. >Sho ip bgp nei gives full ports/ips means what you think it means. >You have may want to see if any of them are yours of20 >if you peer / are the upstream for any of them. > >"Route Servers" > >"telnet://ner-routes.bbnplanet.net" BBN Planet NER route monitor20 >No connection > >"telnet://route-server.belwue.de" BelWue (AS553) >Sho ip bgp nei gives full ports/ips. > >"telnet://route-views.on.bb.telus.com">Telus - East Coast (AS852) >Sho ip bgp nei gives full ports/ips. > >telnet://route-views.ab.bb.telus.com" Telus - West Coast (AS852) >Sho ip bgp nei gives full ports/ips. > >"telnet://route-server.cerf.net">CerfNet Route Server (AS1838) >Sho ip bgp nei gives full ports/ips. > >"telnet://route-server.ip.tiscali.net">Tiscali (AS3257) >Sho ip bgp nei gives full ports/ips. > >"telnet://route-server.gblx.net">Global Crossing (AS3549) >Not misconfigured:-) > >"telnet://route-server.savvis.net/">SAVVIS Communications >(AS3561) >Sho ip bgp nei gives full ports/ips. > >"telnet://public-route-server.is.co.za" TARGET3DNEW>Internet Solutions >(AS3741) >Sho ip bgp nei gives full ports/ips. > >"telnet://route-server-ap.exodus.net">Exodus Communications Asia >(AS4197) >No connection > >"telnet://route-server.as5388.net">Planet Online (AS5388) >Sho ip bgp nei gives full ports/ips. > >"telnet://route-server.opentransit.net">Opentransit (AS5511) >Not misconfigured:-) > >"telnet://tpr-route-server.saix.net">South African Internet eXchange >SAIX (AS5713) >Not misconfigure:-) > >"telnet://route-server.gt.ca">GT Group Telecom (AS6539) >Sho ip bgp nei gives full ports/ips. > >"telnet://route-server.as6667.net">EUNet Finland (AS6667) >Sho ip bgp nei gives full ports/ips. > >"telnet://route-server.he.net">Hurricane Electric (AS6939) >Sho ip bgp nei gives full ports/ips. > >"telnet://route-server.ip.att.net">AT&T (AS7018) >No connection > >"telnet://route-views.optus.net.au">Optus Route Server Australia >(AS7474) >Sho ip bgp nei gives full ports/ips. > >"telnet://route-server.wcg.net">Wiltel (AS7911) >Sho ip bgp nei gives full ports/ips. > >"telnet://route-server.colt.net">Colt Internet (AS8220) >Sho ip bgp nei gives full ports/ips. > >"telnet://route-server-eu.exodus.net">Exodus Communications Europe >(AS8709) >No connection > >"telnet://route-views.bmcag.net">Broadnet mediascape communications AG >(AS9132) >Not misconfigured:-) > >"telnet://route-server-au.exodus.net">Exodus Communications Australia >(AS9328) >No connection > >"telnet://route-server.manilaix.net.ph">Manila Internet Exchange, >Philippines (AS9670) >Sho ip bgp nei gives full ports/ips. > >"telnet://route-server.east.attcanada.com">ATT Canada - East >(AS15290) >Sho ip bgp nei gives full ports/ips. > >"telnet://route-server.west.attcanada.com">ATT Canada - West >(AS15290) >Sho ip bgp nei gives full ports/ips. > >"telnet://route-server.ip.ndsoftware.net">NDSoftware (AS25358) >Sho ip bgp nei gives full ports/ips. > >"telnet://route-server.loudpacket.net">Loud Packet (AS27276) >No connection. > >"telnet://route-server.as28747.net/">RealROOT (AS28747) >No connection > >"telnet://route-views.oregon-ix.net">Oregon-ix.net Route Server >Sho ip bgp nei appears it WOULD provide full ports/ips if they had any? >The command executed but came back empty!!?? This one can be used as a >proxy bounce (connect ip port) too:-( > >"telnet://route-server.utah.rep.net">Utah Regional Exchange Point Route >Server >Sho ip bgp nei gives full ports/ips. > >"telnet://www.netlantis.org">The NetLantis Project Route Server >Not misconfigured. > > >http://pgp.mit.edu:11371/pks/lookup?op3Dget&search3D0xAF00EDCC >pgpFingerPrint:9CE4 227B B9B3 601F B500 D076 43F1 0767 AF00 EDCC >Increased trust is received by not violating the trust you have >received. > >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www1.ietf.org/mailman/listinfo/tcpm > > > -- Randall R. Stewart ITD - Transport Technologies 815-477-2127(o) or 815-342-5222(c) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 09:39:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07195 for ; Fri, 23 Apr 2004 09:39:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH0rW-0007rI-6D for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 09:37:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NDb20Z030195 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 09:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH0pW-0007ET-KI for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 09:34:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06781 for ; Fri, 23 Apr 2004 09:34:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH0pU-0007iy-TO for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 09:34:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH0oU-0007SN-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 09:33:55 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH0nU-00076m-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 09:32:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH0h2-0004T3-Fx; Fri, 23 Apr 2004 09:26:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH0b0-0001yN-7f for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 09:19:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05705 for ; Fri, 23 Apr 2004 09:19:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH0ay-0003aL-Iv for tcpm@ietf.org; Fri, 23 Apr 2004 09:19:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH0Zy-0003Jz-00 for tcpm@ietf.org; Fri, 23 Apr 2004 09:18:54 -0400 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 1BH0Z4-0002ps-00 for tcpm@ietf.org; Fri, 23 Apr 2004 09:17:58 -0400 Received: from lombok-fi.grc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 4940368985 for ; Fri, 23 Apr 2004 09:17:28 -0400 (EDT) Received: from drpepper.grc.nasa.gov (drpepper.grc.nasa.gov [139.88.122.76]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id i3NDHR3c002703; Fri, 23 Apr 2004 09:17:27 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501) id 9C9C9289DF; Fri, 23 Apr 2004 09:14:10 -0400 (EDT) Date: Fri, 23 Apr 2004 09:14:10 -0400 From: Wesley Eddy To: Ted Faber Cc: "Randall Stewart (cisco)" , tcpm@ietf.org Subject: Re: [tcpm] alternative RST processing Message-ID: <20040423131410.GB22377@grc.nasa.gov> Reply-To: weddy@grc.nasa.gov References: <20040422123413.GA20156@grc.nasa.gov> <4087B3EA.8030405@cisco.com> <20040422130541.GC20156@grc.nasa.gov> <20040422214545.GH34492@pun.isi.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TakKZr9L6Hm6aLOc" Content-Disposition: inline In-Reply-To: <20040422214545.GH34492@pun.isi.edu> X-People-Whose-Mailers-Cant-See-This-Header-Are-Lame: true User-Agent: Mutt/1.5.5.1i Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --TakKZr9L6Hm6aLOc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 22, 2004 at 02:45:45PM -0700, Ted Faber wrote: >=20 > I'm a little nervous about adding arcs to the TCP state diagram. > The ACK challenge-response mechanisms add arcs to the state diagram too. They self-loop in established where previously they transitioned to closed. The differences don't seem hugely significant. It seems like if the sequence space had been guessed and an attacker sent a blind reset within the acceptable space, but not exactly correct, they might also be able to guess the proper response to the challenge. It's not as if the problem is cryptographically hard (or even close). Looping in TIME-WAIT instead of this challenge-response behavior seems to be significantly less gameable. -Wes=20 --TakKZr9L6Hm6aLOc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAiRaizBuYqbnj3IwRAlCxAJ0VSMh/fiA67CYGda2P8gU7MstO3QCdEoU8 iJDXUX+ymb0v/j173mDto4o= =xkb2 -----END PGP SIGNATURE----- --TakKZr9L6Hm6aLOc-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 10:14:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10573 for ; Fri, 23 Apr 2004 10:14:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH1L8-0002Aa-39 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 10:07:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NE7cIB008336 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 10:07:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH186-00041v-7C for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 09:54:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08435 for ; Fri, 23 Apr 2004 09:54:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH184-0005ZV-3I for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 09:54:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH16u-0005GX-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 09:52:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH15q-0004nU-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 09:51:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH0wN-0001Fd-31; Fri, 23 Apr 2004 09:42:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH0ta-0008Vb-VH for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 09:39:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07149 for ; Fri, 23 Apr 2004 09:39:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH0tZ-00016F-4h for tcpm@ietf.org; Fri, 23 Apr 2004 09:39:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH0sb-0000pa-00 for tcpm@ietf.org; Fri, 23 Apr 2004 09:38:10 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BH0rp-0000YP-00 for tcpm@ietf.org; Fri, 23 Apr 2004 09:37:21 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3NDbAY12458; Fri, 23 Apr 2004 16:37:10 +0300 (EET DST) X-Scanned: Fri, 23 Apr 2004 16:36:51 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3NDap07026463; Fri, 23 Apr 2004 16:36:51 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00IPaQhi; Fri, 23 Apr 2004 16:36:39 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3NDaZF13405; Fri, 23 Apr 2004 16:36:35 +0300 (EET DST) Received: from nokia.com ([10.241.48.8]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 23 Apr 2004 16:36:33 +0300 Message-ID: <40891BDD.5060409@nokia.com> Date: Fri, 23 Apr 2004 08:36:29 -0500 From: Yogesh Prem Swami User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Mitesh Dalal CC: cjbc@it.uc3m.es, mallman@icir.org, tcpm@ietf.org, faber@isi.edu Subject: Re: [tcpm] new work item: TCP security issue References: <200404222325.QAA22830@cypher.cisco.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Apr 2004 13:36:33.0529 (UTC) FILETIME=[FE0AFE90:01C42937] Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ext Mitesh Dalal wrote: >>From: Carlos Jess Bernardos Cano >> >>Hi Mark and all, >> >> Thanks for the draft. We have been working on a similar TCP attack to >>the ones pointed in this draft. We submitted an Internet-Draft to the >>TSVWG (the TCPM WG had not been created yet), and we are working on it >>to provide a new version. Current release can be downloaded from >>http://www.it.uc3m.es/cjbc/drafts/draft-azcorra-tsvwg-tcp-blind-ack-dos-01.= >>txt >> >> We think (and we have also performed some tests proving it) that the >>attack pointed in our draft is also a very dangerous threat and that the >>proposed changes (server-side changes) eliminate or at least minimise >>the treats to a more acceptable level. >> >> Please provide any comment. If the discussion results in this attack >>being interesting to take into account, we can provide a contribution to >>the tcpsecure draft in the form of a section. >> >> >> > > >I had a cursory look at the paper and the paper >seem to be making 3 HUGE assumptions: > >1. The server will establish a connection with you. >2. The server has obscene amount of data to send. >3. The application has no authentication of its own. > >I have no idea what application you have in mind. >Lets talk about ftp. ftp has username/password >protection. Lets talk about rcp. Client has to >be in the trusted database. Clearly, I cannot >see opening a http connection to a web portal >generating 25MB of data. > >I do not even want to go into the solution, but >for starters: > >" > The proposed changes are the following: > 1. A server SHOULD reset the TCP connection (i.e. send a RST) if it > receives an ACK for data that is in SND.NXT <= SEG.ACK <= > (SND.UNA + SND.WND). >" > >so you are saying that an attacker needs to hit your >window to hose your legit connection ? > >thx >Mitesh > > I haven't read this draft, but acking a lost packet is a potentially serious DoS attack as I pointed out in one of my previous e-mail. Once the sender receives the ACK (sent either by the attacker or by the receiver), the sender will throw away that packet from the send queue. But since the receiver has not received the packet (it was lost), it will keep generating duplicate ACKs (all of which will be discarded by the the sender). This deadlock will take numerous timeouts before the sender resets the connection and releases all resources. To perform this attack, the attacker has the same "sequence guessing" requirements as in the secure TCP draft. Moreover, such attacks are hard to troubleshoot since the connection in one direction will go smoothly, but in the other direction there will be a deadlock. In other words, the attacker can render TCP into simplex protocol, which is highly unintuitive for troubleshooting. So if you posted a web form, the request will reach the server, but there won't be any response. (Or in case of BGP, one router will be able to send it's routing table to its neighboring router, but the other router won't.) I don't think "tweaking" TCP will solve this problem but Cookies/Sigunatures will (more on that in next few e-mails).This makes me think if the problem described in the draft is same as the one I am pointing out... Maybe I should read the draft first :-) Yogesh _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 10:22:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11362 for ; Fri, 23 Apr 2004 10:22:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH1WV-0007Ze-Vf for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 10:19:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NEJNui029109 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 10:19:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH1Oc-0003p4-AZ for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 10:11:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10245 for ; Fri, 23 Apr 2004 10:11:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH1Oa-0002Ql-0k for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 10:11:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH1NY-00028k-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 10:10:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH1Md-0001ou-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 10:09:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH1Dl-0005Wm-Mj; Fri, 23 Apr 2004 10:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH15b-0003Q6-Hq for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 09:51:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08291 for ; Fri, 23 Apr 2004 09:51:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH15Z-0004mG-BJ for tcpm@ietf.org; Fri, 23 Apr 2004 09:51:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH14j-0004Uo-00 for tcpm@ietf.org; Fri, 23 Apr 2004 09:50:42 -0400 Received: from mail.enyo.de ([212.9.189.167]) by ietf-mx with esmtp (Exim 4.12) id 1BH13j-0004BD-00 for tcpm@ietf.org; Fri, 23 Apr 2004 09:49:39 -0400 Received: (debugging) helo=deneb ip=212.9.189.171 name=deneb.enyo.de Received: from deneb.enyo.de ([212.9.189.171] helo=deneb) by mail.enyo.de with esmtp id 1BH13h-0003iM-Jk; Fri, 23 Apr 2004 15:49:37 +0200 Received: from fw by deneb with local (Exim 4.32) id 1BH13g-00069Q-LK; Fri, 23 Apr 2004 15:49:36 +0200 To: Joe Touch Cc: tcpm@ietf.org Subject: Re: FW: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: <025E7DD4182874489CC2F61EE0FA19CE02885696@daebe004.americas.nokia.com> <4087B232.4050203@cisco.com> <4087DDE6.3020703@nokia.com> <4087E36F.7000502@cisco.com> <40885BAB.2070200@isi.edu> From: Florian Weimer Date: Fri, 23 Apr 2004 15:49:36 +0200 In-Reply-To: <40885BAB.2070200@isi.edu> (Joe Touch's message of "Thu, 22 Apr 2004 16:56:27 -0700") Message-ID: <87y8omrehb.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Joe Touch writes: > It would, FWIW, be useful to nail this down and cite something > specific about it in the draft. I.e., there are two reasons this > problem may be important: > > a) kills connections > which could cause a loss of a lot of data, > though (IMO) anything with that much data > ought to know how to restart and recover > from where it left-off (i.e., what it ACKd) Ahem, not what it ACKed. Proper recovery has to be done above the TCP level because data that has been ACKed can be discarded nevertheless (for example, when an RST ist received before the data has been delivered to the application). It's quite hard to find protocols that rely on long connections and have no appropriate restart handling. Are there any protocols commonly used over the Internet except BGP and IRC which have that property? > b) killed connections can hurt BGP more than some other > apps. > that warrants a fix to BGP, IMO. BGP tends to assume that a TCP connection can be established if and only if the link is working. This is not true with current TCP, it's neither a sufficient nor a necessary condition. -- Current mail filters: many dial-up/DSL/cable modem hosts, and the following domains: atlas.cz, bigpond.com, postino.it, tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 10:29:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11689 for ; Fri, 23 Apr 2004 10:29:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH1Yi-0000RF-CE for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 10:21:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NELeQQ001680 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 10:21:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH1UM-0006Un-Cv for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 10:17:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10929 for ; Fri, 23 Apr 2004 10:17:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH1UK-00043q-8b for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 10:17:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH1Th-0003o8-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 10:16:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH1Sn-0003WI-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 10:15:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH1NR-0003PP-Uk; Fri, 23 Apr 2004 10:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH1Ei-00060b-9D for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 10:01:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08836 for ; Fri, 23 Apr 2004 10:00:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH1Eg-0007PH-7b for tcpm@ietf.org; Fri, 23 Apr 2004 10:00:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH1Dh-00078I-00 for tcpm@ietf.org; Fri, 23 Apr 2004 09:59:58 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BH1Cd-0006dm-00 for tcpm@ietf.org; Fri, 23 Apr 2004 09:58:51 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i3NDwABm002571; Fri, 23 Apr 2004 06:58:10 -0700 (PDT) (envelope-from pgoyette@juniper.net) Received: from pgoyette600 (pgoyette-600.jnpr.net [172.24.0.73]) by merlot.juniper.net (8.11.3/8.11.3) with SMTP id i3NDwAJ50701; Fri, 23 Apr 2004 06:58:10 -0700 (PDT) (envelope-from pgoyette@juniper.net) From: "Paul Goyette" To: , "Ted Faber" Cc: "Randall Stewart \(cisco\)" , Subject: RE: [tcpm] alternative RST processing Date: Fri, 23 Apr 2004 06:58:09 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20040423131410.GB22377@grc.nasa.gov> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > It seems like if the sequence space had been guessed and an attacker sent > a blind reset within the acceptable space, but not exactly correct, > they might also be able to guess the proper response to the challenge. True. But then the guessing problem is expanded (returned?) to a probability of one-in-2**32 rather than one-in-(2**32 / RCV.WND). In other words, any RST segment with an exactly matching sequence number will still reset the session. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 10:31:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11883 for ; Fri, 23 Apr 2004 10:31:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH1fC-0002BL-2T for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 10:28:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NESMf4008382 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 10:28:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH1XB-0007vv-OL for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 10:20:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11201 for ; Fri, 23 Apr 2004 10:20:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH1X9-0004p4-Kc for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 10:20:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH1WC-0004Yx-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 10:19:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH1VD-0004Jz-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 10:18:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH1OS-0003nQ-DY; Fri, 23 Apr 2004 10:11:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH1In-0000YT-Ry for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 10:05:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09213 for ; Fri, 23 Apr 2004 10:05:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH1Il-0000eZ-Lu for tcpm@ietf.org; Fri, 23 Apr 2004 10:05:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH1Hk-0000O7-00 for tcpm@ietf.org; Fri, 23 Apr 2004 10:04:09 -0400 Received: from crl-mail.crl.dec.com ([192.58.206.9] helo=crl-mailb.crl.dec.com) by ietf-mx with esmtp (Exim 4.12) id 1BH1HI-00009C-00 for tcpm@ietf.org; Fri, 23 Apr 2004 10:03:40 -0400 Received: from minke.reed.com (out-191.tunnel.crl.dec.com [192.58.207.191]) by crl-mailb.crl.dec.com (8.12.9-20030917/8.12.9) with ESMTP id i3NE3QSu012082; Fri, 23 Apr 2004 10:03:26 -0400 Message-Id: <6.0.1.1.2.20040423094109.05322038@127.0.0.1> X-Sender: mail.reed.com:dpreed@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 23 Apr 2004 10:03:19 -0400 To: Michael Welzl , "Fu Cheng Peng, Franklin" From: "David P. Reed" Cc: tcpm@ietf.org, end2end-interest@postel.org In-Reply-To: <1082718532.4088f94444d8f@web-mail1.uibk.ac.at> References: <7CD06E15ADF4104A9F2E4DC2DE678F89544487@EXCHANGE21.staff.main.ntu.edu.sg> <1082718532.4088f94444d8f@web-mail1.uibk.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-HPLC-MailScanner-Information: Please contact the ISP for more information X-HPLC-MailScanner: Found to be clean X-HPLC-MailScanner-SpamCheck: not spam, SpamAssassin (score=-4.9, required 5, BAYES_00 -4.90) Subject: [tcpm] RE: [e2e] Open the floodgate Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At 07:08 AM 4/23/2004, Michael Welzl wrote: >Still, my question remains: why don't we have these separate >checksums as a TCP option? It strikes me as a rather simple >method for links where erroneous data are actually handed >over, and I believe that it's about time we transferred these >things from the world of research into the IETF. Let's say we implement what Cannara is calling for. A very simple thought experiment: if a packet is lost on a link, and it is possible to signal to one end or the other that data was lost due to an error, how would this happen? Call the sender A and the receiver B . A wraps packet. Sends bits to B. B receives something or nothing. B gets: Something, and is OK. We forward it. Something, and is garble, but we think we know its source and dest address: IP header checks out.. Does B discard it? Not unless it has a separate link level checksum. If not, The dest endpoint would know that a packet was garbled, and be less likely to respond as if congestion (though if the link is wireless, congestion is a major cause of garble - packet loss rates are load driven). If so, B would have discarded it, and perhaps asked A to retransmit. but if B did forward it, what would happen? it would not be confused with congestion. Is it an improvement to have A retransmit or to have the end-point retransmit? Something, and is garble, and we need to resync the link to make sense of the stream. We cannot do much, but if we need to know what packets were lost, we have to get them from A. Why doesn't A just retransmit them to B, then? The point here is that implementing a signal that differentiates ACTUAL congestion (not "ECN") requires the same work that link-level error correction requires - it requires A to keep a list of unacked packets that can then be transformed into such notifications. The one possible improvement is the deliberate forwarding of garbled packets that still have a reliable IP header, which is in fact what is done when there is no separate link level error correction. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 10:31:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11911 for ; Fri, 23 Apr 2004 10:31:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH1fc-0002Dh-Ki for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 10:28:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NESmkT008528 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 10:28:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH1YI-0000Ok-LA for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 10:21:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11279 for ; Fri, 23 Apr 2004 10:21:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH1YG-00058E-Fg for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 10:21:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH1XD-0004pf-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 10:20:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH1WQ-0004aH-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 10:19:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH1OS-0003nY-L2; Fri, 23 Apr 2004 10:11:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH1Jt-0001Lu-Lo for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 10:06:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09332 for ; Fri, 23 Apr 2004 10:06:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH1Jr-0000vz-Is for tcpm@ietf.org; Fri, 23 Apr 2004 10:06:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH1Im-0000em-00 for tcpm@ietf.org; Fri, 23 Apr 2004 10:05:13 -0400 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 1BH1IF-0000OC-00 for tcpm@ietf.org; Fri, 23 Apr 2004 10:04:39 -0400 Received: from lombok-fi.grc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 50854689AC for ; Fri, 23 Apr 2004 10:04:09 -0400 (EDT) Received: from drpepper.grc.nasa.gov (drpepper.grc.nasa.gov [139.88.122.76]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id i3NE483c015976; Fri, 23 Apr 2004 10:04:08 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501) id D212C289DF; Fri, 23 Apr 2004 10:00:51 -0400 (EDT) Date: Fri, 23 Apr 2004 10:00:51 -0400 From: Wesley Eddy To: Paul Goyette Cc: Ted Faber , "Randall Stewart (cisco)" , tcpm@ietf.org Subject: Re: [tcpm] alternative RST processing Message-ID: <20040423140051.GA501@grc.nasa.gov> Reply-To: weddy@grc.nasa.gov References: <20040423131410.GB22377@grc.nasa.gov> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J/dobhs11T7y2rNN" Content-Disposition: inline In-Reply-To: X-People-Whose-Mailers-Cant-See-This-Header-Are-Lame: true User-Agent: Mutt/1.5.5.1i Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 23, 2004 at 06:58:09AM -0700, Paul Goyette wrote: > > It seems like if the sequence space had been guessed and an attacker se= nt > > a blind reset within the acceptable space, but not exactly correct, > > they might also be able to guess the proper response to the challenge. >=20 > True. But then the guessing problem is expanded (returned?) to a=20 > probability of one-in-2**32 rather than one-in-(2**32 / RCV.WND). =20 > In other words, any RST segment with an exactly matching sequence=20 > number will still reset the session. > That statement is true of the solution in Randall's draft as well. See page 4, behavior B. -Wes=20 --J/dobhs11T7y2rNN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAiSGTzBuYqbnj3IwRAu8OAJ4savu6O6u6etXgeQFf/buVDtbJ4wCePSAe 8VS9cZ9+XIGuje/Kj1wSnuk= =QUMJ -----END PGP SIGNATURE----- --J/dobhs11T7y2rNN-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 10:41:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12324 for ; Fri, 23 Apr 2004 10:41:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH1ik-0003FG-6V for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 10:32:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NEW2hn012466 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 10:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH1h5-0002Qj-Cf for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 10:30:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11766 for ; Fri, 23 Apr 2004 10:30:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH1h2-0007Zh-Vf for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 10:30:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH1g5-0007Hr-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 10:29:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH1fO-00070u-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 10:28:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH1XC-0007w4-IL; Fri, 23 Apr 2004 10:20:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH1RR-0004wl-Bb for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 10:14:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10562 for ; Fri, 23 Apr 2004 10:14:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH1RO-0003C8-VJ for tcpm@ietf.org; Fri, 23 Apr 2004 10:14:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH1Qd-0002xH-00 for tcpm@ietf.org; Fri, 23 Apr 2004 10:13:20 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BH1Ps-0002ff-00 for tcpm@ietf.org; Fri, 23 Apr 2004 10:12:32 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i3NEC1Bm002616 for ; Fri, 23 Apr 2004 07:12:02 -0700 (PDT) (envelope-from pgoyette@juniper.net) Received: from pgoyette600 (pgoyette-600.jnpr.net [172.24.0.73]) by merlot.juniper.net (8.11.3/8.11.3) with SMTP id i3NEC1J52072 for ; Fri, 23 Apr 2004 07:12:01 -0700 (PDT) (envelope-from pgoyette@juniper.net) From: "Paul Goyette" To: Subject: RE: [tcpm] alternative RST processing Date: Fri, 23 Apr 2004 07:12:00 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20040423140051.GA501@grc.nasa.gov> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > That statement is true of the solution in Randall's draft as well. See > page 4, behavior B. Agreed. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 11:15:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13925 for ; Fri, 23 Apr 2004 11:15:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2Hn-0003vg-Iq for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 11:08:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NF8FCg015096 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 11:08:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2Ep-0002wX-UF for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 11:05:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13293 for ; Fri, 23 Apr 2004 11:05:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH2En-0000rk-Bx for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 11:05:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH2Do-0000cE-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 11:04:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH2D3-0000N6-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 11:03:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH250-0000Ye-Lu; Fri, 23 Apr 2004 10:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH1wL-0006SS-W7 for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 10:46:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12515 for ; Fri, 23 Apr 2004 10:46:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH1wJ-0003n8-CD for tcpm@ietf.org; Fri, 23 Apr 2004 10:46:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH1vG-0003Xz-00 for tcpm@ietf.org; Fri, 23 Apr 2004 10:44:58 -0400 Received: from ftp.netlab.nec.de ([195.37.70.21] helo=ftp.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1BH1uH-0003GI-00 for tcpm@ietf.org; Fri, 23 Apr 2004 10:43:57 -0400 Received: from netlab.nec.de (scout.netlab.nec.de [195.37.70.100]) by ftp.ccrle.nec.de (Postfix) with ESMTP id F3657F674; Fri, 23 Apr 2004 16:48:58 +0200 (CEST) Message-ID: <40892BAB.5010008@netlab.nec.de> Date: Fri, 23 Apr 2004 16:43:55 +0200 From: Lars Eggert Organization: NEC Network Laboratories User-Agent: Mozilla Thunderbird 0.6+ (Macintosh/20040420) X-Accept-Language: en-us, en MIME-Version: 1.0 To: weddy@grc.nasa.gov Cc: tcpm@ietf.org References: <20040421151201.GC32188@grc.nasa.gov> <40869644.2020509@netlab.nec.de> <20040421155357.GD32188@grc.nasa.gov> In-Reply-To: <20040421155357.GD32188@grc.nasa.gov> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080301080207020204010406" Subject: [tcpm] Re: draft-eggert-tcpm-tcp-abort-timeout-option-00.txt Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms080301080207020204010406 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Wesley, Wesley Eddy wrote: > > Yes quite a bit. Although I see the lack of sending an ATO option on the > initial SYN as indicating either "I don't care" or "I don't grok the ATO > option", and so in both cases, it won't really matter what the ATO in the > SYN-ACK is, because the other side will either be cool with it or not > understand it. > > Keeping with the spirit of other TCP options, it might be best to put the > ATO option in the SYN if you understand it, and not put it at all in the > SYN-ACK if it wasn't in the SYN, on the goal of not breaking fragile stacks > with options they can't parse. That would also remove the need to worry > about the option coming in on non-SYN options. It's typical to use different > option parsing routines for syn-set and syn-unset segments (sort of slow and > fast paths through the option parsing), and so disallowing an ATO option on > the first ACK also simplifies implementation. I agree that's a valid concern, and a possible approach. The ATO in the SYN could even contain a magic/invalid value to signal to the peer that ATOs are understood but no specific ATO is requested. However, if the ATO exchange is limited to the SYN/SYN-ACK exchange, only clients ever get a chance to start an ATO negotiation. That limits the generality and maybe usefulness of the option. Many other TCP options are somewhat different in this respect, because they just use the handshake to establish whether or not an extension is supported and that knowledge then influences later protocol behavior. Lars -- Lars Eggert NEC Network Laboratories --------------ms080301080207020204010406 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ/zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNaMIICw6ADAgECAgMLU6IwDQYJKoZIhvcNAQEE BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTAz MTIxNTEyMzEyOFoXDTA0MTIxNDEyMzEyOFowgYQxDzANBgNVBAQTBkVnZ2VydDENMAsGA1UE KhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdn ZXJ0QG5ldGxhYi5uZWMuZGUxIjAgBgkqhkiG9w0BCQEWE2xhcnMuZWdnZXJ0QGdteC5uZXQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWps58Zq8Buu2DKDl9crbvzSo6zWsZ TkQLr5zOTqUMs/eU7Mcohv64O4IxWWYGLfYsjDRxUlmdHdJUbyTtUh2lH452DUDJByXidlLm RDgohG0AVwztedqy1+hE3VnCdpMhUGks+6ntrr3dKSxMgLM0AM1kPWsH9lWX6IOPdxOC30gM PiQ65zH9PR70befQLgFPKcAv0wP8210l05n8ekwYAcq2cm3/j+nuDu0HEh5pgsnY7cVELeNJ ODvr4IiE1t3c2w4+0Nc/WJrqGCMl+gZ8c+7FtzjoyDeEsCjNFDeA2ymNd+10O6kjwvPHlzPr 3rW73RDRPAjMJ49HXlueiuoNAgMBAAGjdzB1MCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwOQYDVR0RBDIwMIEZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5k ZYETbGFycy5lZ2dlcnRAZ214Lm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB AHgrv3SQFD4AS4lY4oKcI3iTHcclEHbYfg3UUb8zzCUsl+OJoz0nmebGmOL+tvNj5GvCrWnN H4LvVLh8ZBhFXms7eKJ1YiHgbKwTRK23P8Y5NDit5ico0ZjpFWeenUWj3ajEbN6n4K8dNp+C 0b2apnSrlFVWY6BucZFIYqQ1Lf91MIIDWjCCAsOgAwIBAgIDC1OiMA0GCSqGSIb3DQEBBAUA MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wMzEy MTUxMjMxMjhaFw0wNDEyMTQxMjMxMjhaMIGEMQ8wDQYDVQQEEwZFZ2dlcnQxDTALBgNVBCoT BExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2Vy dEBuZXRsYWIubmVjLmRlMSIwIAYJKoZIhvcNAQkBFhNsYXJzLmVnZ2VydEBnbXgubmV0MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1qbOfGavAbrtgyg5fXK2780qOs1rGU5E C6+czk6lDLP3lOzHKIb+uDuCMVlmBi32LIw0cVJZnR3SVG8k7VIdpR+Odg1AyQcl4nZS5kQ4 KIRtAFcM7XnastfoRN1ZwnaTIVBpLPup7a693SksTICzNADNZD1rB/ZVl+iDj3cTgt9IDD4k Oucx/T0e9G3n0C4BTynAL9MD/NtdJdOZ/HpMGAHKtnJt/4/p7g7tBxIeaYLJ2O3FRC3jSTg7 6+CIhNbd3NsOPtDXP1ia6hgjJfoGfHPuxbc46Mg3hLAozRQ3gNspjXftdDupI8Lzx5cz6961 u90Q0TwIzCePR15bnorqDQIDAQABo3cwdTAqBgUrZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVN eWZmQk5VYk5KSmNkWjJzMDkGA1UdEQQyMDCBGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGWB E2xhcnMuZWdnZXJ0QGdteC5uZXQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQB4 K790kBQ+AEuJWOKCnCN4kx3HJRB22H4N1FG/M8wlLJfjiaM9J5nmxpji/rbzY+Rrwq1pzR+C 71S4fGQYRV5rO3iidWIh4GysE0Sttz/GOTQ4reYnKNGY6RVnnp1Fo92oxGzep+CvHTafgtG9 mqZ0q5RVVmOgbnGRSGKkNS3/dTGCAzswggM3AgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwCQYFKw4DAhoFAKCCAacwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwNDIzMTQ0MzU1WjAjBgkqhkiG 9w0BCQQxFgQUfpQwbJF4zbcA3xy7N/tqS4ZY8sYwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECAwtTojB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwDQYJKoZIhvcNAQEBBQAEggEA fOgqnoBmeE184h/p8mhhGvL5FMZV6ZK5T6R2BknHmTx+9+KNbiYt2yBGm5OQTPzZGbyDNCTt EiOESbdIMgJkX401iWKgfK01slo+0uKbqB8jmNjDWgOQmBMvUcq3+15j9/JwqTDKogsC187Z dY+QbXaSITLiqlsjGwaanBVdHIB/XwLd+LHYEDZRsQsLz/oUW5Td1cJYPq88+9J14DoW+cN8 5HQYAapJpCsYKNSxD5tkfR3+H/BvPWyGPZMcxqoImWsbEcarAtNccsTvECNveSydHBq7QGyz McIv4GOEapX3EYMZUuR0NY/9V2ZaIWS86mNPVyLNgdq3liGBl7qwigAAAAAAAA== --------------ms080301080207020204010406-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 11:49:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15757 for ; Fri, 23 Apr 2004 11:49:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2mT-0003sA-J6 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 11:39:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NFdvMM014882 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 11:39:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2fq-00028A-OE for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 11:33:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14870 for ; Fri, 23 Apr 2004 11:33:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH2fp-0000W7-PP for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 11:33:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH2f2-0000Fv-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 11:32:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH2eA-0007nF-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 11:31:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2V7-0007UH-26; Fri, 23 Apr 2004 11:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2NZ-0005Pj-SA for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 11:14:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13845 for ; Fri, 23 Apr 2004 11:14:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH2NZ-0003Mb-0N for tcpm@ietf.org; Fri, 23 Apr 2004 11:14:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH2Ml-000376-00 for tcpm@ietf.org; Fri, 23 Apr 2004 11:13:23 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BH2M2-0002nm-00 for tcpm@ietf.org; Fri, 23 Apr 2004 11:12:38 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 23 Apr 2004 08:12:26 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3NFC5W9013207; Fri, 23 Apr 2004 08:12:05 -0700 (PDT) Received: from cisco.com (rtp-dial-1-8.cisco.com [10.83.97.8]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATI08923; Fri, 23 Apr 2004 08:12:03 -0700 (PDT) Message-ID: <4089320A.9020104@cisco.com> Date: Fri, 23 Apr 2004 11:11:06 -0400 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: weddy@grc.nasa.gov CC: Ted Faber , tcpm@ietf.org Subject: Re: [tcpm] alternative RST processing References: <20040422123413.GA20156@grc.nasa.gov> <4087B3EA.8030405@cisco.com> <20040422130541.GC20156@grc.nasa.gov> <20040422214545.GH34492@pun.isi.edu> <20040423131410.GB22377@grc.nasa.gov> In-Reply-To: <20040423131410.GB22377@grc.nasa.gov> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Wesley Eddy wrote: >On Thu, Apr 22, 2004 at 02:45:45PM -0700, Ted Faber wrote: > > >>I'm a little nervous about adding arcs to the TCP state diagram. >> >> >> > >The ACK challenge-response mechanisms add arcs to the state diagram too. >They self-loop in established where previously they transitioned to >closed. The differences don't seem hugely significant. > >It seems like if the sequence space had been guessed and an attacker sent >a blind reset within the acceptable space, but not exactly correct, >they might also be able to guess the proper response to the challenge. >It's not as if the problem is cryptographically hard (or even close). >Looping in TIME-WAIT instead of this challenge-response behavior seems >to be significantly less gameable. > The guess MUST be exact.. not close.. so when the normal ACK is sent to the true peer.. the attacker must still turn around and guess a 1 in 2^^32 number.... and the attacker will not see the ACK itself.. or know the challenge went on.... R > >-Wes > > -- Randall R. Stewart ITD - Transport Technologies 815-477-2127(o) or 815-342-5222(c) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 12:26:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16998 for ; Fri, 23 Apr 2004 12:26:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3Cv-0002RU-MD for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 12:07:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NG7Hi4009383 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 12:07:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2xG-0006ko-J5 for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 11:51:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15871 for ; Fri, 23 Apr 2004 11:51:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH2xF-0005HX-Ff for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 11:51:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH2wE-0004zF-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 11:50:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH2vB-0004bz-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 11:48:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2lb-0003n3-4C; Fri, 23 Apr 2004 11:39:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2bI-0000uw-0U for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 11:28:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14611 for ; Fri, 23 Apr 2004 11:28:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH2bG-00072W-V0 for tcpm@ietf.org; Fri, 23 Apr 2004 11:28:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH2aa-0006mF-00 for tcpm@ietf.org; Fri, 23 Apr 2004 11:27:41 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BH2ZY-0006UG-00 for tcpm@ietf.org; Fri, 23 Apr 2004 11:26:36 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3NFQ0Y24425; Fri, 23 Apr 2004 18:26:00 +0300 (EET DST) X-Scanned: Fri, 23 Apr 2004 18:25:56 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3NFPuID019429; Fri, 23 Apr 2004 18:25:56 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00sel0Iz; Fri, 23 Apr 2004 18:25:53 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3NFPms16829; Fri, 23 Apr 2004 18:25:48 +0300 (EET DST) Received: from nokia.com ([172.19.11.226]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 23 Apr 2004 18:25:50 +0300 Message-ID: <4089357B.3060308@nokia.com> Date: Fri, 23 Apr 2004 10:25:47 -0500 From: Yogesh Prem Swami User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Jeremy Harris CC: tcpm@ietf.org Subject: Re: FW: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: <025E7DD4182874489CC2F61EE0FA19CE02885696@daebe004.americas.nokia.com> <4087B232.4050203@cisco.com> <4087DDE6.3020703@nokia.com> <40886BD6.5000800@uk.sun.com> In-Reply-To: <40886BD6.5000800@uk.sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Apr 2004 15:25:50.0208 (UTC) FILETIME=[4220D000:01C42947] Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ext Jeremy Harris wrote: >Yogesh Prem Swami wrote: > > > >>So now my question is, which of these categories of attacks should be >>solved and which ones should not be. (I'd vote for 1 and 2, and leave 3 >>out). Also, there are different routes that one can take to solve these >>problems. >> >>Route-1: Fix individual vulnerabilities in the protocols by changing the >>protocol mechanism itself. "TCP secure" draft has taken this route. >> >>Route-2: Have a single protocol mechanism (e.g., by defining a new >>option or reusing an old one) that solves most of the problems.(I'd >>personally prefer this over Route-1). For Route-2, again there are >>couple of options. >> Route-2-a: Use crypto methods to solve the problem, but >>without doing key exchange. (Got my vote) >> Route-2-b: Use crypto, but with key exchange. >> >> > >Route-2-c: expand the sequence space. > > (No crypto, another option, two (say) 64-bit sequence numbers > per packet; the probability swings against the attacker) > > This is a valid option and probably worth considering. But having a crypto based method can help in detecting, if not preventing, a broader range of attacks. For example, sequence numbers will not be able to detect/prevent if the attacker (typically a virus) can see packets on the end to end path. Although it might be hard to prevent such man-in-the-middle attacks, it will be useful to have a scheme which can detect (with high probability) the possibility. Yogesh _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 12:35:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18137 for ; Fri, 23 Apr 2004 12:35:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3ax-00030Z-Vx for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 12:32:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NGW7Sf011556 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 12:32:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3XI-0001Il-9R for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 12:28:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17138 for ; Fri, 23 Apr 2004 12:28:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH3WB-0006Fd-JD for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 12:27:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH3VL-0005yZ-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 12:26:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH3Uj-0005ip-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 12:25:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3Aj-0001ap-42; Fri, 23 Apr 2004 12:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2vM-0006HB-Ga for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 11:49:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15691 for ; Fri, 23 Apr 2004 11:49:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH2vL-0004jT-Aj for tcpm@ietf.org; Fri, 23 Apr 2004 11:49:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH2uX-0004UO-00 for tcpm@ietf.org; Fri, 23 Apr 2004 11:48:17 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BH2th-00040J-00 for tcpm@ietf.org; Fri, 23 Apr 2004 11:47:26 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 23 Apr 2004 07:57:51 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3NFkqW9001753; Fri, 23 Apr 2004 08:46:53 -0700 (PDT) Received: from irp-view8.cisco.com (irp-view8.cisco.com [171.70.65.145]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASJ30195; Fri, 23 Apr 2004 08:46:05 -0700 (PDT) Date: Fri, 23 Apr 2004 08:46:51 -0700 (PDT) From: Mitesh Dalal To: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano cc: mallman@icir.org, tcpm@ietf.org, faber@isi.edu, Ignacio Soto Campos Subject: Re: [tcpm] new work item: TCP security issue In-Reply-To: <1082708698.1144.89.camel@acorde> Message-ID: References: <200404222325.QAA22830@cypher.cisco.com> <1082708698.1144.89.camel@acorde> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 23 Apr 2004, Carlos [ISO-8859-1] Jes=FAs Bernardos Cano wrote: > > so you are saying that an attacker needs to hit your > > window to hose your legit connection ? > > =09No, we aren't. An attacker has to forge the origin IP address and the > ports numbers, not only the window. This is not new, because this can be > done with a RST. > you are missing my point. With the original spec, even if an attacker could "guess" the ports and IPs and "hit" the sequences, he will still not be able get the connection down. But with your change it can. Introducing the very problem that we are trying to fix. One important point to note is that in long lived connection, most of the time (SND.UNA =3D=3D SND.NXT) will hold true. An attacker will hence ha= ve ample time to DOS your connection with the above strategy. thx Mitesh _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 12:36:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18259 for ; Fri, 23 Apr 2004 12:36:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3bd-0003NE-Aq for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 12:32:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NGWnpd012952 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 12:32:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3YT-0001fz-1B for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 12:29:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17586 for ; Fri, 23 Apr 2004 12:29:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH3YR-00072M-IU for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 12:29:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH3XP-0006bG-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 12:28:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH3WF-0006GC-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 12:27:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3Di-00034e-IQ; Fri, 23 Apr 2004 12:08:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH32L-0007ul-7j for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 11:56:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16224 for ; Fri, 23 Apr 2004 11:56:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH32J-0006dI-U0 for tcpm@ietf.org; Fri, 23 Apr 2004 11:56:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH31I-0006M4-00 for tcpm@ietf.org; Fri, 23 Apr 2004 11:55:17 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BH30q-00066K-00 for tcpm@ietf.org; Fri, 23 Apr 2004 11:54:48 -0400 Received: from isi.edu (lsanca1-ar42-4-61-163-027.lsanca1.dsl-verizon.net [4.61.163.27]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3NFsIN01649; Fri, 23 Apr 2004 08:54:18 -0700 (PDT) Message-ID: <40893C27.8050902@isi.edu> Date: Fri, 23 Apr 2004 08:54:15 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Randall Stewart (cisco)" CC: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: <40885173.6090804@isi.edu> <40890DF2.1040700@cisco.com> In-Reply-To: <40890DF2.1040700@cisco.com> X-Enigmail-Version: 0.83.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB3DF312D17AF14CCA01CEC25" X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB3DF312D17AF14CCA01CEC25 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Randall Stewart (cisco) wrote: > Joe Touch wrote: ... >> IMO, IPsec or the MD5 signature options are >> more than sufficient for these cases. > > Yep.. but for some reason deployment of these have not > happened... I will note that I have heard more ISP's are now > interested in MD5 now.. which is a "good thing" :-D Actually, I would be more pleased if the ISPs used IPsec. ... >> --d) transport security, whether cookies >> or signatures, requires a TCP option, >> which could break non-modified receivers >> (i.e., aren't as backward-compat as this >> might be) >> >> but since you have to modify the ones you're >> trying to protect anyway, so consider it >> as a 'dual stack' issue and move on ;-) > > So are you recommending cookies (or what I would call V-tags).... instead > of the current draft proposals... If this is what the working group > wants I would be happy to work with the co-authors to redo the > document has such... The current draft ought to (IMO) be more complete in this regard. IF the draft is really about RST Assasination (which is what it, IMO, ought to be), then it ought to discuss and compare all viable solutions. The doc appears, however, to be more like "given RST Assasinations, here's a TCP mod". Since there are extant protocols that already solve this for the most important cases. Do physicists with huge windows really advertise the two machines that are transferring? do hackers care to kill their connections? - likely not, i.e., this is primarily a BGP and IRC issue, for which IPsec is a better, more secure solution. > What would you recommed then? Not do anything? or something else?> 1) use IPsec if you want to avoid this the attacker might find other holes - in TCP, or basically any other protocol these protocols (transport and above) are being attacked by a third party. they are NOT secure or safe - they were never intended to be (from attackers) the attack is completely avoided by IPsec, since the attack only works because someone is FAKING IP PACKETS so, IMO, solve the __problem__ - faked IP packets - at the source, not somewhere up the stack FWIW, if IPsec is too slow - if you want a cookie checker to stall an attacker but not slow down IP - then propose it (or I might ;-) -- at the IP layer, where it helps all protocols, not just IP 2) fix TCP to do the right thing for RST throwers as I mentioned, throwing a RST and jumping into CLOSE works for this solution, ___BUT___ is NOT what should be done i.e., this fixes TCP to solve an IP-level security hole, at the expense of relying on a broken TCP behavior (it should jump into TW on sending RST) that ought to be fixed; if we do this, we'll have trouble fixing the 'RSTer jumps into TW', which we should have done a while back, IMO Joe --------------enigB3DF312D17AF14CCA01CEC25 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAiTwrE5f5cImnZrsRAiMdAKD6WgPlNG5i22YQ+5ud3QUK8EmXoQCgy/ko Rut2mI3JYjHYidtyF87ZYB4= =p1HY -----END PGP SIGNATURE----- --------------enigB3DF312D17AF14CCA01CEC25-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 12:36:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18282 for ; Fri, 23 Apr 2004 12:36:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3bf-0003WF-Ol for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 12:32:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NGWpTr013523 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 12:32:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3Z6-00026s-Ln for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 12:30:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17644 for ; Fri, 23 Apr 2004 12:30:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH3Z5-0007EY-9i for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 12:30:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH3Xq-0006jx-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 12:28:54 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH3Wq-0006IO-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 12:27:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3Dj-00034s-2y; Fri, 23 Apr 2004 12:08:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH32O-0007vK-6o for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 11:56:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16240 for ; Fri, 23 Apr 2004 11:56:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH32N-0006dd-04 for tcpm@ietf.org; Fri, 23 Apr 2004 11:56:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH31L-0006Mf-00 for tcpm@ietf.org; Fri, 23 Apr 2004 11:55:20 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BH30w-00065w-00 for tcpm@ietf.org; Fri, 23 Apr 2004 11:54:54 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 23 Apr 2004 08:05:19 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3NFsKC1014936; Fri, 23 Apr 2004 08:54:20 -0700 (PDT) Received: from irp-view8.cisco.com (irp-view8.cisco.com [171.70.65.145]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASJ30859; Fri, 23 Apr 2004 08:53:33 -0700 (PDT) Date: Fri, 23 Apr 2004 08:54:19 -0700 (PDT) From: Mitesh Dalal To: Yogesh Prem Swami cc: cjbc@it.uc3m.es, mallman@icir.org, tcpm@ietf.org, faber@isi.edu Subject: Re: [tcpm] new work item: TCP security issue In-Reply-To: <40891BDD.5060409@nokia.com> Message-ID: References: <200404222325.QAA22830@cypher.cisco.com> <40891BDD.5060409@nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Fri, 23 Apr 2004, Yogesh Prem Swami wrote: > > > > I haven't read this draft, but acking a lost packet is a potentially > serious DoS attack as I pointed out in one of my previous e-mail. Once > the sender receives the ACK (sent either by the attacker or by the > receiver), the sender will throw away that packet from the send queue. > But since the receiver has not received the packet (it was lost), it > will keep generating duplicate ACKs (all of which will be discarded by > the the sender). This deadlock will take numerous timeouts before the > sender resets the connection and releases all resources. To perform this > attack, the attacker has the same "sequence guessing" requirements as in > the secure TCP draft. I disagree that its as bad as you think it is. For causing an ACK attack as above, the attacker has to be correct on 2 axis, on the number axis and the time axis. Sequence numbers will change throughout the life of the connection and hence the attacker has to keep up with the time factor as well. But yes there is a small(very small :) window of attack possible. thx Mitesh > > Moreover, such attacks are hard to troubleshoot since the connection in > one direction will go smoothly, but in the other direction there will be > a deadlock. In other words, the attacker can render TCP into simplex > protocol, which is highly unintuitive for troubleshooting. So if you > posted a web form, the request will reach the server, but there won't be > any response. (Or in case of BGP, one router will be able to send it's > routing table to its neighboring router, but the other router won't.) > > I don't think "tweaking" TCP will solve this problem but > Cookies/Sigunatures will (more on that in next few e-mails).This makes > me think if the problem described in the draft is same as the one I am > pointing out... Maybe I should read the draft first :-) > > Yogesh > > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 13:04:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20271 for ; Fri, 23 Apr 2004 13:04:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH40f-0003A2-9p for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 12:58:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NGwffs012146 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 12:58:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3wm-0001yo-VR for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 12:54:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19376 for ; Fri, 23 Apr 2004 12:54:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH3wl-0006c4-93 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 12:54:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH3vh-0006Jt-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 12:53:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH3ut-00062E-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 12:52:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3c3-0003cU-VW; Fri, 23 Apr 2004 12:33:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3Xh-0001NF-Od for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 12:28:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17428 for ; Fri, 23 Apr 2004 12:28:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH3H5-0002Yz-IG for tcpm@ietf.org; Fri, 23 Apr 2004 12:11:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH3Em-0002FK-00 for tcpm@ietf.org; Fri, 23 Apr 2004 12:09:13 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BH3D4-0001T3-00 for tcpm@ietf.org; Fri, 23 Apr 2004 12:07:27 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 23 Apr 2004 08:19:04 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3NG6sW9002230; Fri, 23 Apr 2004 09:06:54 -0700 (PDT) Received: from irp-view8.cisco.com (irp-view8.cisco.com [171.70.65.145]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASJ31969; Fri, 23 Apr 2004 09:06:06 -0700 (PDT) Date: Fri, 23 Apr 2004 09:06:52 -0700 (PDT) From: Mitesh Dalal To: Florian Weimer cc: Allison Mankin , Tim Shepard , tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt In-Reply-To: <87isfrfbp1.fsf@deneb.enyo.de> Message-ID: References: <87llknsluk.fsf@deneb.enyo.de> <87isfrfbp1.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Fri, 23 Apr 2004, Florian Weimer wrote: > Mitesh Dalal writes: > > > On Fri, 23 Apr 2004, Florian Weimer wrote: > > > >> Allison Mankin writes: > >> > >> > I agree the draft should mention the point about ports and addresses. > >> > >> Vendors seem to disagree and hesitate to add source port > >> randomization. I don't know why. 8-( > > > > Port allocation is an implementation issue and the current issue > > we have at hand is a flaw in the original standard. > > Why do you think this is a flaw in TCP? Which specification is > violated? in my opinion, the rst/syn processing recommended in the base spec for an ESTAB connection is rather agressive in todays world. thx Mitesh > > -- > Current mail filters: many dial-up/DSL/cable modem hosts, and the > following domains: atlas.cz, bigpond.com, postino.it, tiscali.co.uk, > tiscali.cz, tiscali.it, voila.fr. > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 13:13:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20740 for ; Fri, 23 Apr 2004 13:13:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4Bs-00069k-Cr for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 13:10:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NHAGuN023655 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 13:10:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH41O-0003Pl-Dr for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 12:59:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19855 for ; Fri, 23 Apr 2004 12:59:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH41M-0000E6-Kc for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 12:59:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH40G-0007lU-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 12:58:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH3zs-0007VX-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 12:57:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3wC-0001sF-OP; Fri, 23 Apr 2004 12:54:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3gq-0005TB-VO for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 12:38:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18386 for ; Fri, 23 Apr 2004 12:38:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH3gp-0001zv-7c for tcpm@ietf.org; Fri, 23 Apr 2004 12:38:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH3fn-0001hz-00 for tcpm@ietf.org; Fri, 23 Apr 2004 12:37:08 -0400 Received: from viefep19-int.chello.at ([213.46.255.28]) by ietf-mx with esmtp (Exim 4.12) id 1BH3em-0001Ao-00 for tcpm@ietf.org; Fri, 23 Apr 2004 12:36:04 -0400 Received: from fun ([80.109.142.58]) by viefep19-int.chello.at (InterMail vM.6.00.05.02 201-2115-109-103-20031105) with SMTP id <20040423163532.WHE19027.viefep19-int.chello.at@fun>; Fri, 23 Apr 2004 18:35:32 +0200 Message-ID: <001101c42950$e7b1d3d0$0200a8c0@fun> From: "Michael Welzl" To: "Saad Biaz" Cc: "Fu Cheng Peng, Franklin" , , References: Date: Fri, 23 Apr 2004 18:34:52 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [tcpm] Re: [e2e] Open the floodgate Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > Still, my question remains: why don't we have these separate > > checksums as a TCP option? It strikes me as a rather simple > > method for links where erroneous data are actually handed > > over, and I believe that it's about time we transferred these > > things from the world of research into the IETF. > > When you have erroneous packets (for whatever reaso other than > congestion), who will inform about that? Maybe the addresses themselves > are erroneous. Besides, some packets just get completely junked ... > Special headers will not solve the problem. This is a misunderstanding, and I guess it's because I didn't give enough details - sorry! So: The idea is to have a second checksum that lets you distinguish between an error that occured in the header and an error that occured in the payload (e.g., a checksum that covers only the header as opposed to the original TCP checksum that covers header+payload). If the header is broken, I agree that there is nothing you can do. However, if you know for sure that the error was in the payload and all the header information is intact, I don't quite see the point of doing standard TCP backoff as if it was a congestion event. Exactly this mechanism was introduced to DCCP by the name of a Data Checksum option. Cheers, Michael _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 13:27:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21923 for ; Fri, 23 Apr 2004 13:27:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4Lw-0000ZT-81 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 13:20:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NHKenl002191 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 13:20:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4Ff-0007av-V2 for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 13:14:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20766 for ; Fri, 23 Apr 2004 13:14:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH4Fd-0004Fc-Vu for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 13:14:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH4Eg-0003xq-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 13:13:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH4Dg-0003dt-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 13:12:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH44u-0004Fs-IV; Fri, 23 Apr 2004 13:03:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3zE-0002nK-72 for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 12:57:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19746 for ; Fri, 23 Apr 2004 12:57:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH3zC-0007UK-B7 for tcpm@ietf.org; Fri, 23 Apr 2004 12:57:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH3yJ-0007Cy-00 for tcpm@ietf.org; Fri, 23 Apr 2004 12:56:16 -0400 Received: from viefep12-int.chello.at ([213.46.255.25]) by ietf-mx with esmtp (Exim 4.12) id 1BH3xS-0006dZ-00 for tcpm@ietf.org; Fri, 23 Apr 2004 12:55:22 -0400 Received: from fun ([80.109.142.58]) by viefep12-int.chello.at (InterMail vM.6.00.05.02 201-2115-109-103-20031105) with SMTP id <20040423165450.FIRJ151.viefep12-int.chello.at@fun>; Fri, 23 Apr 2004 18:54:50 +0200 Message-ID: <000c01c42953$9a261d30$0200a8c0@fun> From: "Michael Welzl" To: "Fu Cheng Peng, Franklin" , , Cc: "Saad Biaz" References: <7CD06E15ADF4104A9F2E4DC2DE678F895444B9@EXCHANGE21.staff.main.ntu.edu.sg> Date: Fri, 23 Apr 2004 18:54:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [tcpm] Re: [e2e] Open the floodgate Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > > Still, my question remains: why don't we have these > > separate checksums > > > as a TCP option? It strikes me as a rather simple method for links > > > where erroneous data are actually handed over, and I > > believe that it's > > > about time we transferred these things from the world of > > research into > > > the IETF. > > > > When you have erroneous packets (for whatever reaso other > > than congestion), who will inform about that? Maybe the > > addresses themselves are erroneous. Besides, some packets > > just get completely junked ... Special headers will not solve > > the problem. > > Another reason may be due to deployability issue, if you add checksum in > TCP options, you have to modify both sending and receiving TCP stack. Is > it? That is not easy to deploy in real network. Not easy, but possible, in an incremental fashion. This is not a reason to abandon it IMO. It wasn't a reason to abandon ECN either. Cheers, Michael _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 13:28:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22060 for ; Fri, 23 Apr 2004 13:28:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4MA-0000pK-MC for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 13:20:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NHKsbK003173 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 13:20:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4Io-0008NC-Oy for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 13:17:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21043 for ; Fri, 23 Apr 2004 13:17:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH4Im-00057M-Az for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 13:17:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH4Hy-0004qr-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 13:16:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH4H5-0004ZV-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 13:15:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4Cc-0006RH-Pe; Fri, 23 Apr 2004 13:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH42Q-0003bw-5U for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 13:00:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19945 for ; Fri, 23 Apr 2004 13:00:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH42O-0000XB-9u for tcpm@ietf.org; Fri, 23 Apr 2004 13:00:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH41X-0000Ft-00 for tcpm@ietf.org; Fri, 23 Apr 2004 12:59:36 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BH40i-0007kv-00 for tcpm@ietf.org; Fri, 23 Apr 2004 12:58:44 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 23 Apr 2004 09:58:33 -0700 Received: from ananth-u5.cisco.com (ananth-u5.cisco.com [128.107.162.225]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i3NGwCjP021700; Fri, 23 Apr 2004 09:58:12 -0700 (PDT) Date: Fri, 23 Apr 2004 09:58:12 -0700 (PDT) From: Anantha Ramaiah To: "Randall Stewart (cisco)" cc: Allison Mankin , Tim Shepard , tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt In-Reply-To: <408910C9.7060700@cisco.com> Message-ID: References: <408910C9.7060700@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,WEIRD_PORT autolearn=no version=2.60 Randall: After watching some email suggestions, it appears that we could add : - Port randomization suggestion. [ Any good references, papers should help] - A note on MD5 and choosing MD5 secret.. -Anantha On Fri, 23 Apr 2004, Randall Stewart (cisco) wrote: > Allison: > > How about if we add something like: > " > TCP implementations MAY also introduce ephemeral port randomization. By > randomizing ephemeral ports an attacker would have a less easy time > in guessing the four tuples needed to mount a successful attack. > " > > To the introduction section has an addtion? > > R > > Allison Mankin wrote: > > >Hi, Tim, > > > >I agree the draft should mention the point about ports and addresses. > > > >Below is an interesting mail from nanog showing how addresses and > >ports can be found. Another nanog message mentioned that some router > >vendors limit the TCP port range. There is also some nanog chat about > >seeing scanners. > > > >Allison > > > >----- > > > >Subject: tcp bgp vulnerability looking glass and route server issues. > >Date: Tue, 20 Apr 2004 14:38:18 -0600 > >From: "Smith, Donald" > >To: > > > > > >John Fraizer author of MRLG one of the looking glass implementations > >has updated his code to fix a flaw that provided too much information. > > > >MRLG-4.3.0 is available at: > >Available here: > >ftp://ftp.enterzone.net/looking-glass/CURRENT/ > > > >Some route servers also provide too much info. > >This audit was performed yesterday so if you have already fixed this > >issue please ignore:-) > >Part of this issue is the fact that some router servers provide too much > >information. > >Without knowing the source/destination ports and IP's this is still a > >difficult vulnerability to exploit. > > > >>From this URL I did a quick audit. > >http://www.traceroute.org/#Route%20Servers > >I did NOT look at the looking glass URLs just the route servers. > > > >This is the list of open route servers I did a quick audit on. > >No connection means I was unable to connect to it. > >Not misconfigured meant sho ip bgp nei did NOT work. > >Sho ip bgp nei gives full ports/ips means what you think it means. > >You have may want to see if any of them are yours of20 > >if you peer / are the upstream for any of them. > > > >"Route Servers" > > > >"telnet://ner-routes.bbnplanet.net" BBN Planet NER route monitor20 > >No connection > > > >"telnet://route-server.belwue.de" BelWue (AS553) > >Sho ip bgp nei gives full ports/ips. > > > >"telnet://route-views.on.bb.telus.com">Telus - East Coast (AS852) > >Sho ip bgp nei gives full ports/ips. > > > >telnet://route-views.ab.bb.telus.com" Telus - West Coast (AS852) > >Sho ip bgp nei gives full ports/ips. > > > >"telnet://route-server.cerf.net">CerfNet Route Server (AS1838) > >Sho ip bgp nei gives full ports/ips. > > > >"telnet://route-server.ip.tiscali.net">Tiscali (AS3257) > >Sho ip bgp nei gives full ports/ips. > > > >"telnet://route-server.gblx.net">Global Crossing (AS3549) > >Not misconfigured:-) > > > >"telnet://route-server.savvis.net/">SAVVIS Communications > >(AS3561) > >Sho ip bgp nei gives full ports/ips. > > > >"telnet://public-route-server.is.co.za" TARGET3DNEW>Internet Solutions > >(AS3741) > >Sho ip bgp nei gives full ports/ips. > > > >"telnet://route-server-ap.exodus.net">Exodus Communications Asia > >(AS4197) > >No connection > > > >"telnet://route-server.as5388.net">Planet Online (AS5388) > >Sho ip bgp nei gives full ports/ips. > > > >"telnet://route-server.opentransit.net">Opentransit (AS5511) > >Not misconfigured:-) > > > >"telnet://tpr-route-server.saix.net">South African Internet eXchange > >SAIX (AS5713) > >Not misconfigure:-) > > > >"telnet://route-server.gt.ca">GT Group Telecom (AS6539) > >Sho ip bgp nei gives full ports/ips. > > > >"telnet://route-server.as6667.net">EUNet Finland (AS6667) > >Sho ip bgp nei gives full ports/ips. > > > >"telnet://route-server.he.net">Hurricane Electric (AS6939) > >Sho ip bgp nei gives full ports/ips. > > > >"telnet://route-server.ip.att.net">AT&T (AS7018) > >No connection > > > >"telnet://route-views.optus.net.au">Optus Route Server Australia > >(AS7474) > >Sho ip bgp nei gives full ports/ips. > > > >"telnet://route-server.wcg.net">Wiltel (AS7911) > >Sho ip bgp nei gives full ports/ips. > > > >"telnet://route-server.colt.net">Colt Internet (AS8220) > >Sho ip bgp nei gives full ports/ips. > > > >"telnet://route-server-eu.exodus.net">Exodus Communications Europe > >(AS8709) > >No connection > > > >"telnet://route-views.bmcag.net">Broadnet mediascape communications AG > >(AS9132) > >Not misconfigured:-) > > > >"telnet://route-server-au.exodus.net">Exodus Communications Australia > >(AS9328) > >No connection > > > >"telnet://route-server.manilaix.net.ph">Manila Internet Exchange, > >Philippines (AS9670) > >Sho ip bgp nei gives full ports/ips. > > > >"telnet://route-server.east.attcanada.com">ATT Canada - East > >(AS15290) > >Sho ip bgp nei gives full ports/ips. > > > >"telnet://route-server.west.attcanada.com">ATT Canada - West > >(AS15290) > >Sho ip bgp nei gives full ports/ips. > > > >"telnet://route-server.ip.ndsoftware.net">NDSoftware (AS25358) > >Sho ip bgp nei gives full ports/ips. > > > >"telnet://route-server.loudpacket.net">Loud Packet (AS27276) > >No connection. > > > >"telnet://route-server.as28747.net/">RealROOT (AS28747) > >No connection > > > >"telnet://route-views.oregon-ix.net">Oregon-ix.net Route Server > >Sho ip bgp nei appears it WOULD provide full ports/ips if they had any? > >The command executed but came back empty!!?? This one can be used as a > >proxy bounce (connect ip port) too:-( > > > >"telnet://route-server.utah.rep.net">Utah Regional Exchange Point Route > >Server > >Sho ip bgp nei gives full ports/ips. > > > >"telnet://www.netlantis.org">The NetLantis Project Route Server > >Not misconfigured. > > > > > >http://pgp.mit.edu:11371/pks/lookup?op3Dget&search3D0xAF00EDCC > >pgpFingerPrint:9CE4 227B B9B3 601F B500 D076 43F1 0767 AF00 EDCC > >Increased trust is received by not violating the trust you have > >received. > > > >_______________________________________________ > >tcpm mailing list > >tcpm@ietf.org > >https://www1.ietf.org/mailman/listinfo/tcpm > > > > > > > > > -- > Randall R. Stewart > ITD - Transport Technologies > 815-477-2127(o) or 815-342-5222(c) > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 14:21:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24863 for ; Fri, 23 Apr 2004 14:21:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH593-0006yw-FX for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 14:11:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NIBPg9026833 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 14:11:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4zN-00044P-Ea for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 14:01:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23764 for ; Fri, 23 Apr 2004 14:01:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH4zL-0001A1-3D for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 14:01:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH4yp-0000sj-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 14:00:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH4wx-0000On-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 13:58:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4pM-0001Q2-PN; Fri, 23 Apr 2004 13:51:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4ft-0006l4-Vj for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 13:41:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22714 for ; Fri, 23 Apr 2004 13:41:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH4fr-0003ca-Oy for tcpm@ietf.org; Fri, 23 Apr 2004 13:41:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH4ex-0003Mp-00 for tcpm@ietf.org; Fri, 23 Apr 2004 13:40:20 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BH4eB-00037A-00 for tcpm@ietf.org; Fri, 23 Apr 2004 13:39:31 -0400 Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3NHc3N00359; Fri, 23 Apr 2004 10:38:03 -0700 (PDT) Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.12.10/8.12.10) with ESMTP id i3NHc3Ix043414; Fri, 23 Apr 2004 10:38:03 -0700 (PDT) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.12.10/8.12.10/Submit) id i3NHbxs2043413; Fri, 23 Apr 2004 10:37:59 -0700 (PDT) (envelope-from faber) Date: Fri, 23 Apr 2004 10:37:59 -0700 From: Ted Faber To: Wesley Eddy Cc: "Randall Stewart (cisco)" , tcpm@ietf.org Subject: Re: [tcpm] alternative RST processing Message-ID: <20040423173759.GC42190@pun.isi.edu> References: <20040422123413.GA20156@grc.nasa.gov> <4087B3EA.8030405@cisco.com> <20040422130541.GC20156@grc.nasa.gov> <20040422214545.GH34492@pun.isi.edu> <20040423131410.GB22377@grc.nasa.gov> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0lnxQi9hkpPO77W3" Content-Disposition: inline In-Reply-To: <20040423131410.GB22377@grc.nasa.gov> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: faber@isi.edu Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --0lnxQi9hkpPO77W3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Apr 23, 2004 at 09:14:10AM -0400, Wesley Eddy wrote: > On Thu, Apr 22, 2004 at 02:45:45PM -0700, Ted Faber wrote: > > > > I'm a little nervous about adding arcs to the TCP state diagram. > > > > The ACK challenge-response mechanisms add arcs to the state diagram too. > They self-loop in established where previously they transitioned to > closed. The differences don't seem hugely significant. Let me be more precise in my objections and try to point out where I believe the complexity lies, then. My concern is not really in adding arcs to a graph, which as you say, we're doing anyway. My concern is that in jumping from the ESTABLISHED state where the TCP connection is open to one in which the connection is closed (TIME-WAIT) there will be both transient behavior that will break applications or that the solution will require significant changes to the semantics of the TIME-WAIT state in order to work. The Stewart changes to the semantics of ESTABLISHED are minimal by comparison. Data in segments arriving to a connection in TIME-WAIT are essentially discarded as it stands now. The state is currently only entered after a successful FIN exchange, so any arriving data segments are assumed to be invalid because the endpoints have agreed that there is no more data to be transferred. So, if the endpoint enters TIME-WAIT on reciept of a segment containing a valid RST flag from a blind attacker, the fate of subsequent valid data from the real sender arriving at the connection in TIME-WAIT is unclear. I understand that you're proposing that one returns to ESTABLISHED on reciept of data, but this means that the TIME-WAIT state that the connection entered has to contain the extra information that the conection is not in a "real" TIME-WAIT state, but one that will be invalidated on receipt of new data. That seems like a different state to me. Furthermore consider in this case: a blind RST arrives to a largely quiescent connection. The connection enters TIME-WAIT and 2 MSL time passes before the endpoint that knows nothing of the RST sends another packet. The connection closes on the endpoint that got the RST, or there's some more state in the TIME-WAIT state that will ignore the 2 MSL timeout if it was entered as a result of a questionable RST. I wouldn't be surprised to see some other complexities working in there, to. Jumping from ESTABLISHED around all the state changes implied in the FIN_WAITs/CLOSING nest over there is not to be undertaken lightly, IMHO. It seems to me that the state you're talking about transitioning to really isn't TIME-WAIT but something like BAD-RESET-P. I think that the insight from Randall and company is that one can emit a challenge from ESTABLISHED that requires no change of state in the TCB or in the state diagram (I know one implies the other, it's just for emphasis :-)), but provides some protection. The connection doesn't have to remember that it's seen the RST, nor does it have to change how it handles data or other packets until theres some confirmation elicited by the simple challenge that is embodied in the new ACK. (The fact that this interoperates with unmodified TCPs, and that an unmodified TCP partnered with one that generates the challenge will do the right thing whether trying to reset or being attacked is also good). Now, there may be an argument to be made that staying in ESTABLISHED doesn't keep track of some new state needed to resolve the validity of the RST and that a new state is needed, but you haven't convinced me that we need that state, or that TIME-WAIT is that state. > > It seems like if the sequence space had been guessed and an attacker sent > a blind reset within the acceptable space, but not exactly correct, > they might also be able to guess the proper response to the challenge. The attacker in question cannot see the challenge, or the attack wouldn't be a blind one. If the attacker can snoop packets, the system in the Stewart draft is useless, because the attacker will simply pick the correct sequence number for the RST the first time, and never elicit a challenge. > It's not as if the problem is cryptographically hard (or even close). No, it would be "read back the sequence number" hard. :-) The challenge would be an indication to the attacker that they'd been close, but if the attacker can see it, they not only know that they're close, but what the correct answer is. > Looping in TIME-WAIT instead of this challenge-response behavior seems > to be significantly less gameable. My concerns aren't with the difficulty for the attacker, but in the disruption to the protocol. I don't want to add a state unnecessarily, and I believe that the modifications necessary to make TIME-WAIT serve this purpose amount to adding a new state. Your mileage may, of course, vary. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG --0lnxQi9hkpPO77W3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAiVR3aUz3f+Zf+XsRArR9AJ0YPhwQWLggP1O7B+cvvmUFy3MSRACeKGIf UDWDLWaSLZ3dDFtuMLaMztc= =e/8F -----END PGP SIGNATURE----- --0lnxQi9hkpPO77W3-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 14:51:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27440 for ; Fri, 23 Apr 2004 14:51:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH5JC-0002He-GE for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 14:21:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NILsl9008774 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 14:21:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH5Ci-00009l-DJ for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 14:15:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24486 for ; Fri, 23 Apr 2004 14:15:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH5Cf-0004mJ-Ui for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 14:15:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH5Bi-0004UJ-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 14:14:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH5Ao-0004DJ-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 14:13:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH500-0004N8-HY; Fri, 23 Apr 2004 14:02:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4tT-0002T4-2V for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 13:55:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23421 for ; Fri, 23 Apr 2004 13:55:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH4tQ-0007ON-Jz for tcpm@ietf.org; Fri, 23 Apr 2004 13:55:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH4sM-00079C-00 for tcpm@ietf.org; Fri, 23 Apr 2004 13:54:11 -0400 Received: from viefep16-int.chello.at ([213.46.255.17]) by ietf-mx with esmtp (Exim 4.12) id 1BH4rT-0006gH-00 for tcpm@ietf.org; Fri, 23 Apr 2004 13:53:15 -0400 Received: from fun ([80.109.142.58]) by viefep16-int.chello.at (InterMail vM.6.00.05.02 201-2115-109-103-20031105) with SMTP id <20040423175244.TQUE19659.viefep16-int.chello.at@fun>; Fri, 23 Apr 2004 19:52:44 +0200 Message-ID: <001701c4295b$b056d560$0200a8c0@fun> From: "Michael Welzl" To: "Fu Cheng Peng, Franklin" , "David P. Reed" Cc: , References: <7CD06E15ADF4104A9F2E4DC2DE678F89544487@EXCHANGE21.staff.main.ntu.edu.sg><1082718532.4088f94444d8f@web-mail1.uibk.ac.at> <6.0.1.1.2.20040423094109.05322038@127.0.0.1> Date: Fri, 23 Apr 2004 19:52:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [tcpm] Re: [e2e] Open the floodgate Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > At 07:08 AM 4/23/2004, Michael Welzl wrote: > >Still, my question remains: why don't we have these separate > >checksums as a TCP option? It strikes me as a rather simple > >method for links where erroneous data are actually handed > >over, and I believe that it's about time we transferred these > >things from the world of research into the IETF. > > Let's say we implement what Cannara is calling for. A very simple thought > experiment: if a packet is lost on a link, and it is possible to signal to > one end or the other that data was lost due to an error, how would this happen? > > Call the sender A and the receiver B . A wraps packet. Sends bits to > B. B receives something or nothing. B gets: > Something, and is OK. We forward it. > Something, and is garble, but we think we know its source and dest > address: IP header checks out.. > > Does B discard it? Not unless it has a separate link > level checksum. > If not, The dest endpoint would know that a packet > was garbled, and be less likely to respond as if > congestion (though if the link is > wireless, congestion is a major cause of garble - packet > loss rates are load driven). This is why I wouldn't necessarily recommend to the TCP sender to act as if _NOTHING_ had happened - but it might make sense to implement a less severe reaction to this type of congestion because TCP CC. was designed to react upon overloaded queues - link layer MAC is already designed to deal with this type of overload. Let's say TCP CC. wouldn't react to erroneous bits in the payload at all - the link layer could try to cope with it via its MAC mechanism. If it keeps getting flooded by the sender and just can't deal with it, it can still drop an erroneous packet every once in a while; what we now have is implicit communication between the wireless link somewhere along the path and TCP, somewhat similar to the way RED communicates with TCP. > If so, B would have discarded it, and perhaps asked A to > retransmit. > but if B did forward it, what would happen? it would not > be confused with congestion. > Is it an improvement to have A retransmit or to have the > end-point retransmit? > > Something, and is garble, and we need to resync the link to make > sense of the stream. > We cannot do much, but if we need to know what packets > were lost, we have > to get them from A. Why doesn't A just retransmit them > to B, then? I'm not against having A retransmit - the A-B connection may be much shorter than the end-to-end TCP connection, after all. This is however not always practical; if A-B had perfect persistence (i.e. would just retry endlessly), A would require an endless buffer. So, in reality, most link layers seem to give up after a while. In such a case, B shouldn't just drop the data in my opinion but rather forward it to inform B of the problem. > The point here is that implementing a signal that differentiates ACTUAL > congestion (not "ECN") requires the same work that link-level error > correction requires - it requires A to keep a list of unacked packets that > can then be transformed into such notifications. Hm, but the point is to avoid TCP's multiplicative decrease in response to a packet that was not dropped in a queue but just garbled along the way. This, of course, doesn't solve the retransmission problem - but, as I said above, link layer retransmission has its limits. If B just decides to give up after a while, dropping the data doesn't help much. I'm not trying to make a statement against link layer ARQ here; all I say is that link layer designers should be motivated to have their link layers occasionally forward erroneous data (in situations when link layer ARQ fails). This option is available in some link layers already (see the URL in my previous mail). > The one possible improvement is the deliberate forwarding of garbled > packets that still have a reliable IP header, which is in fact what is done > when there is no separate link level error correction. Hm? This is exactly what I'm proposing - only forward packets that still have a reliable IP header, at least SOMETIMES, or in special situations (e.g., when link layer ARQ fails). Without a working header, everything is useless ... but if TCP has some means to detect that bit errors occured only in the payload and the headers are still intact, a more reasonable congestion avoidance decision could be made. Cheers, Michael _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 14:51:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27486 for ; Fri, 23 Apr 2004 14:51:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH5JD-0002I7-4A for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 14:21:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NILtPa008803 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 14:21:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH5D0-0000IB-Se for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 14:15:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24514 for ; Fri, 23 Apr 2004 14:15:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH5Cy-0004oz-By for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 14:15:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH5C2-0004XP-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 14:14:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH5BL-0004GD-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 14:13:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH501-0004NO-9D; Fri, 23 Apr 2004 14:02:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4vP-00030z-38 for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 13:57:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23467 for ; Fri, 23 Apr 2004 13:57:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH4vM-00006N-Ot for tcpm@ietf.org; Fri, 23 Apr 2004 13:57:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH4uF-0007dO-00 for tcpm@ietf.org; Fri, 23 Apr 2004 13:56:08 -0400 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 1BH4tJ-0007A6-00 for tcpm@ietf.org; Fri, 23 Apr 2004 13:55:09 -0400 Received: from lombok-fi.grc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 9D00B689E2 for ; Fri, 23 Apr 2004 13:54:39 -0400 (EDT) Received: from drpepper.grc.nasa.gov (drpepper.grc.nasa.gov [139.88.122.76]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id i3NHsd3c023546; Fri, 23 Apr 2004 13:54:39 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501) id AE3CE289DF; Fri, 23 Apr 2004 13:51:21 -0400 (EDT) Date: Fri, 23 Apr 2004 13:51:21 -0400 From: Wesley Eddy To: Ted Faber Cc: "Randall Stewart (cisco)" , tcpm@ietf.org Subject: Re: [tcpm] alternative RST processing Message-ID: <20040423175121.GH501@grc.nasa.gov> Reply-To: weddy@grc.nasa.gov References: <20040422123413.GA20156@grc.nasa.gov> <4087B3EA.8030405@cisco.com> <20040422130541.GC20156@grc.nasa.gov> <20040422214545.GH34492@pun.isi.edu> <20040423131410.GB22377@grc.nasa.gov> <20040423173759.GC42190@pun.isi.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qM81t570OJUP5TU/" Content-Disposition: inline In-Reply-To: <20040423173759.GC42190@pun.isi.edu> X-People-Whose-Mailers-Cant-See-This-Header-Are-Lame: true User-Agent: Mutt/1.5.5.1i Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --qM81t570OJUP5TU/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 23, 2004 at 10:37:59AM -0700, Ted Faber wrote: >=20 > > Looping in TIME-WAIT instead of this challenge-response behavior seems > > to be significantly less gameable. >=20 > My concerns aren't with the difficulty for the attacker, but in the > disruption to the protocol. I don't want to add a state unnecessarily, > and I believe that the modifications necessary to make TIME-WAIT serve > this purpose amount to adding a new state. > Mark convinced me a little earlier today that the behavior in the Stewart draft is more reasonable than changing states, so I'm now in full agreement. We had one slight refinement though ... A connection could be slightly disturbed by RST probing that sent 3 segments per slice of sequence space. If 3 duplicate acks were generated then there could be an unwarranted congestion response as a result of the RST attack on the other side. Although not breaking the connection, it could be slowed a bit, and the process might be repeated. This is probably not a huge issue. The fix would just consist of not sending repeated ACKs for multiple RSTs within the same window. -Wes --qM81t570OJUP5TU/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAiVeZzBuYqbnj3IwRAsSEAJ0eCW07Tf/hMLRgRjgmo1wP2SAo5gCgiqXT tES5iIG7/25Ec7dUKZlOBVc= =7n9k -----END PGP SIGNATURE----- --qM81t570OJUP5TU/-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 14:52:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27583 for ; Fri, 23 Apr 2004 14:52:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH5MY-00032x-NE for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 14:25:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NIPMp8011707 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 14:25:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH5Dy-0000Z2-1K for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 14:16:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24591 for ; Fri, 23 Apr 2004 14:16:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH5Dv-00057V-H6 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 14:16:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH5D5-0004q7-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 14:15:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH5C6-0004Y9-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 14:14:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH503-0004Ns-F8; Fri, 23 Apr 2004 14:02:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4wO-0003HK-72 for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 13:58:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23548 for ; Fri, 23 Apr 2004 13:58:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH4wK-0000Ml-2h for tcpm@ietf.org; Fri, 23 Apr 2004 13:58:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH4vI-00005p-00 for tcpm@ietf.org; Fri, 23 Apr 2004 13:57:13 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1BH4uD-0007Pa-00 for tcpm@ietf.org; Fri, 23 Apr 2004 13:56:06 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i3NHtW0Q006320; Fri, 23 Apr 2004 10:55:33 -0700 (PDT) Received: from mdalal-u10.cisco.com (mdalal-u10.cisco.com [128.107.162.178]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASJ42927; Fri, 23 Apr 2004 10:54:46 -0700 (PDT) Date: Fri, 23 Apr 2004 10:55:32 -0700 (PDT) From: Mitesh Dalal To: Joe Touch cc: "Randall Stewart (cisco)" , tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt In-Reply-To: <40893C27.8050902@isi.edu> Message-ID: References: <40885173.6090804@isi.edu> <40890DF2.1040700@cisco.com> <40893C27.8050902@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Fri, 23 Apr 2004, Joe Touch wrote: > Randall Stewart (cisco) wrote: > > > Joe Touch wrote: > ... > >> IMO, IPsec or the MD5 signature options are > >> more than sufficient for these cases. > > > > Yep.. but for some reason deployment of these have not > > happened... I will note that I have heard more ISP's are now > > interested in MD5 now.. which is a "good thing" :-D > > Actually, I would be more pleased if the ISPs used IPsec. > > ... > >> --d) transport security, whether cookies > >> or signatures, requires a TCP option, > >> which could break non-modified receivers > >> (i.e., aren't as backward-compat as this > >> might be) > >> > >> but since you have to modify the ones you're > >> trying to protect anyway, so consider it > >> as a 'dual stack' issue and move on ;-) > > > > So are you recommending cookies (or what I would call V-tags).... instead > > of the current draft proposals... If this is what the working group > > wants I would be happy to work with the co-authors to redo the > > document has such... > > The current draft ought to (IMO) be more complete in this regard. IF the > draft is really about RST Assasination (which is what it, IMO, ought to > be), then it ought to discuss and compare all viable solutions. > > The doc appears, however, to be more like "given RST Assasinations, > here's a TCP mod". Since there are extant protocols that already solve > this for the most important cases. Do physicists with huge windows > really advertise the two machines that are transferring? do hackers care > to kill their connections? - likely not, i.e., this is primarily a BGP > and IRC issue, for which IPsec is a better, more secure solution. > > > What would you recommed then? Not do anything? or something else?> > > 1) use IPsec if you want to avoid this > > the attacker might find other holes - in TCP, or basically > any other protocol > > these protocols (transport and above) are being attacked by > a third party. they are NOT secure or safe - they were never > intended to be (from attackers) > > the attack is completely avoided by IPsec, since the attack > only works because someone is FAKING IP PACKETS > > so, IMO, solve the __problem__ - faked IP packets - > at the source, not somewhere up the stack > > FWIW, if IPsec is too slow - if you want a cookie checker > to stall an attacker but not slow down IP - then propose > it (or I might ;-) -- at the IP layer, where it helps > all protocols, not just IP > Hi Joe, Can we realy do this ? I mean suggesting using IPSec, using MD5, using IPv6(since security is mandatory) are all end user choices. I doubt a WG could really spell this out, expcept maybe an informational draft or BCP. > 2) fix TCP to do the right thing for RST throwers > > as I mentioned, throwing a RST and jumping into CLOSE > works for this solution, ___BUT___ is NOT what should > be done > > i.e., this fixes TCP to solve an IP-level security hole, > at the expense of relying on a broken TCP behavior > (it should jump into TW on sending RST) that ought to > be fixed; if we do this, we'll have trouble fixing the > 'RSTer jumps into TW', which we should have done a while > back, IMO > fixing the standard is a better approach (not that I agree with your TW suggestion :) since the onus in now on IETF and the vendors to provide correct solution to end users, who do not have to worry about config, admin and cost issues of deploying yet another technology to mitigate an attack in another protocol. thx Mitesh _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 15:32:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03151 for ; Fri, 23 Apr 2004 15:32:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6FP-0003ko-8y for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 15:22:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NJM32F014426 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 15:22:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH68p-0006zH-RJ for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 15:15:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01532 for ; Fri, 23 Apr 2004 15:15:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH68o-0006HF-N4 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 15:15:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH67N-0005lL-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 15:13:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH65B-0005Ht-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 15:11:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH5nO-00078q-5h; Fri, 23 Apr 2004 14:53:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH5RH-0004KS-2d for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 14:30:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25351 for ; Fri, 23 Apr 2004 14:30:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH5RE-00011H-Dc for tcpm@ietf.org; Fri, 23 Apr 2004 14:30:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH5QM-0000mb-00 for tcpm@ietf.org; Fri, 23 Apr 2004 14:29:18 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BH5Q0-0000Xa-00 for tcpm@ietf.org; Fri, 23 Apr 2004 14:28:56 -0400 Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3NIRvN16771; Fri, 23 Apr 2004 11:27:57 -0700 (PDT) Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.12.10/8.12.10) with ESMTP id i3NIRvIx044344; Fri, 23 Apr 2004 11:27:57 -0700 (PDT) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.12.10/8.12.10/Submit) id i3NIRvUN044343; Fri, 23 Apr 2004 11:27:57 -0700 (PDT) (envelope-from faber) Date: Fri, 23 Apr 2004 11:27:57 -0700 From: Ted Faber To: Wesley Eddy Cc: "Randall Stewart (cisco)" , tcpm@ietf.org Subject: Re: [tcpm] alternative RST processing Message-ID: <20040423182757.GB43716@pun.isi.edu> References: <20040422123413.GA20156@grc.nasa.gov> <4087B3EA.8030405@cisco.com> <20040422130541.GC20156@grc.nasa.gov> <20040422214545.GH34492@pun.isi.edu> <20040423131410.GB22377@grc.nasa.gov> <20040423173759.GC42190@pun.isi.edu> <20040423175121.GH501@grc.nasa.gov> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ADZbWkCsHQ7r3kzd" Content-Disposition: inline In-Reply-To: <20040423175121.GH501@grc.nasa.gov> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: faber@isi.edu Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --ADZbWkCsHQ7r3kzd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Apr 23, 2004 at 01:51:21PM -0400, Wesley Eddy wrote: > Mark convinced me a little earlier today that the behavior in the Stewart > draft is more reasonable than changing states, so I'm now in full agreement. Cool. > We had one slight refinement though ... > > A connection could be slightly disturbed by RST probing that sent 3 segments > per slice of sequence space. If 3 duplicate acks were generated then there > could be an unwarranted congestion response as a result of the RST attack > on the other side. Although not breaking the connection, it could be slowed > a bit, and the process might be repeated. This is probably not a huge > issue. > > The fix would just consist of not sending repeated ACKs for multiple RSTs > within the same window. Hmmm. That's an interesting problem. While we can fix it for RSTs, I think the attacker could just send bogus short data packets and achieve the same effect, right? -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG --ADZbWkCsHQ7r3kzd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAiWAsaUz3f+Zf+XsRAkzSAKD5mFlBcHSKOvNJVAI5Z9UdwKklRgCcDrqy U3iASgD1PVA9wHiTmz2kGZo= =pK8v -----END PGP SIGNATURE----- --ADZbWkCsHQ7r3kzd-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 15:35:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03339 for ; Fri, 23 Apr 2004 15:35:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6I0-0004dH-7p for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 15:24:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NJOipu017802 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 15:24:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6C1-0000Zz-9s for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 15:18:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02015 for ; Fri, 23 Apr 2004 15:18:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH6C0-0007JG-3O for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 15:18:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH6Ax-00071J-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 15:17:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH6A7-0006kA-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 15:16:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH5pN-000874-A6; Fri, 23 Apr 2004 14:55:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH5ai-0000Yo-IG for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 14:40:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26264 for ; Fri, 23 Apr 2004 14:39:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH5af-0003r6-QI for tcpm@ietf.org; Fri, 23 Apr 2004 14:39:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH5ZZ-0003VZ-00 for tcpm@ietf.org; Fri, 23 Apr 2004 14:38:49 -0400 Received: from cs180204.pp.htv.fi ([213.243.180.204] helo=hades.pp.htv.fi ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BH5Yf-0003Ay-00 for tcpm@ietf.org; Fri, 23 Apr 2004 14:37:54 -0400 Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.11/8.12.11/Debian-4) with ESMTP id i3NIeKI3002590; Fri, 23 Apr 2004 21:40:21 +0300 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.11/8.12.11/Debian-4) id i3NIeGZw002589; Fri, 23 Apr 2004 21:40:16 +0300 Subject: Re: [tcpm] alternative RST processing From: Mika Liljeberg To: weddy@grc.nasa.gov Cc: Ted Faber , "Randall Stewart (cisco)" , tcpm@ietf.org In-Reply-To: <20040423175121.GH501@grc.nasa.gov> References: <20040422123413.GA20156@grc.nasa.gov> <4087B3EA.8030405@cisco.com> <20040422130541.GC20156@grc.nasa.gov> <20040422214545.GH34492@pun.isi.edu> <20040423131410.GB22377@grc.nasa.gov> <20040423173759.GC42190@pun.isi.edu> <20040423175121.GH501@grc.nasa.gov> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1082745616.29392.2289.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 23 Apr 2004 21:40:16 +0300 Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Fri, 2004-04-23 at 20:51, Wesley Eddy wrote: > A connection could be slightly disturbed by RST probing that sent 3 segments > per slice of sequence space. If 3 duplicate acks were generated then there > could be an unwarranted congestion response as a result of the RST attack > on the other side. Although not breaking the connection, it could be slowed > a bit, and the process might be repeated. This is probably not a huge > issue. > > The fix would just consist of not sending repeated ACKs for multiple RSTs > within the same window. I don't think we need to worry about a blind attacker sending 100k packets just to cause a fast retransmit. :-) Certainly not worth introducing another state variable. MikaL _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 15:43:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04682 for ; Fri, 23 Apr 2004 15:43:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6P9-0007bY-SX for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 15:32:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NJW7DK029227 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 15:32:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6Ei-0002y5-1v for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 15:21:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02391 for ; Fri, 23 Apr 2004 15:21:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH6Eg-0000O1-Nu for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 15:21:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH6Dn-00005P-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 15:20:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH6Co-0007aV-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 15:19:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH5vA-0003uY-0h; Fri, 23 Apr 2004 15:01:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH5g2-00045l-Cd for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 14:45:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26823 for ; Fri, 23 Apr 2004 14:45:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH5fz-0005sn-Ky for tcpm@ietf.org; Fri, 23 Apr 2004 14:45:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH5ee-0005Iq-00 for tcpm@ietf.org; Fri, 23 Apr 2004 14:44:05 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BH5dR-0004tX-00 for tcpm@ietf.org; Fri, 23 Apr 2004 14:42:50 -0400 Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3NIfCN21092; Fri, 23 Apr 2004 11:41:12 -0700 (PDT) Message-ID: <40896331.2010704@isi.edu> Date: Fri, 23 Apr 2004 11:40:49 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mitesh Dalal CC: "Randall Stewart (cisco)" , tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: <40885173.6090804@isi.edu> <40890DF2.1040700@cisco.com> <40893C27.8050902@isi.edu> In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3EE0FE47720A688C587EDFEF" X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3EE0FE47720A688C587EDFEF Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mitesh Dalal wrote: > On Fri, 23 Apr 2004, Joe Touch wrote: > > >>Randall Stewart (cisco) wrote: >> >> >>>Joe Touch wrote: >> >>... >> >>>> IMO, IPsec or the MD5 signature options are >>>> more than sufficient for these cases. >>> >>>Yep.. but for some reason deployment of these have not >>>happened... I will note that I have heard more ISP's are now >>>interested in MD5 now.. which is a "good thing" :-D >> >>Actually, I would be more pleased if the ISPs used IPsec. >> >>... >> >>>> --d) transport security, whether cookies >>>> or signatures, requires a TCP option, >>>> which could break non-modified receivers >>>> (i.e., aren't as backward-compat as this >>>> might be) >>>> >>>> but since you have to modify the ones you're >>>> trying to protect anyway, so consider it >>>> as a 'dual stack' issue and move on ;-) >>> >>>So are you recommending cookies (or what I would call V-tags).... instead >>>of the current draft proposals... If this is what the working group >>>wants I would be happy to work with the co-authors to redo the >>>document has such... >> >>The current draft ought to (IMO) be more complete in this regard. IF the >>draft is really about RST Assasination (which is what it, IMO, ought to >>be), then it ought to discuss and compare all viable solutions. >> >>The doc appears, however, to be more like "given RST Assasinations, >>here's a TCP mod". Since there are extant protocols that already solve >>this for the most important cases. Do physicists with huge windows >>really advertise the two machines that are transferring? do hackers care >>to kill their connections? - likely not, i.e., this is primarily a BGP >>and IRC issue, for which IPsec is a better, more secure solution. >> >> >>>What would you recommed then? Not do anything? or something else?> >> >>1) use IPsec if you want to avoid this >> >> the attacker might find other holes - in TCP, or basically >> any other protocol >> >> these protocols (transport and above) are being attacked by >> a third party. they are NOT secure or safe - they were never >> intended to be (from attackers) >> >> the attack is completely avoided by IPsec, since the attack >> only works because someone is FAKING IP PACKETS >> >> so, IMO, solve the __problem__ - faked IP packets - >> at the source, not somewhere up the stack >> >> FWIW, if IPsec is too slow - if you want a cookie checker >> to stall an attacker but not slow down IP - then propose >> it (or I might ;-) -- at the IP layer, where it helps >> all protocols, not just IP >> > > > Hi Joe, > > Can we realy do this ? I mean suggesting using IPSec, using MD5, > using IPv6(since security is mandatory) are all end user choices. > I doubt a WG could really spell this out, expcept maybe an > informational draft or BCP. IMO, we can surely do this. The IESG took the task to us to address; addressing it is clearly within scope. Certainly the result would be a BCP at best, since it would not indicate a new protocol. >>2) fix TCP to do the right thing for RST throwers >> >> as I mentioned, throwing a RST and jumping into CLOSE >> works for this solution, ___BUT___ is NOT what should >> be done >> >> i.e., this fixes TCP to solve an IP-level security hole, >> at the expense of relying on a broken TCP behavior >> (it should jump into TW on sending RST) that ought to >> be fixed; if we do this, we'll have trouble fixing the >> 'RSTer jumps into TW', which we should have done a while >> back, IMO > > fixing the standard is a better approach (not that I agree with > your TW suggestion :) since the onus in now on IETF and the vendors > to provide correct solution to end users, who do not have to worry > about config, admin and cost issues of deploying yet another technology > to mitigate an attack in another protocol. > > thx > Mitesh I don't agree; fixing TCP to deal with the fact that you can't trust the source of a RST is a bit of a layerer 'violation' (fixing the wrong layer). Joe --------------enig3EE0FE47720A688C587EDFEF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAiWM1E5f5cImnZrsRAtdjAKDTB7VacZfvj/C8ZQgotYOBt/C/2wCfW+d3 KJxpNnLxDyzMYMfn8GmGkQ8= =zAsc -----END PGP SIGNATURE----- --------------enig3EE0FE47720A688C587EDFEF-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 15:43:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04777 for ; Fri, 23 Apr 2004 15:43:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6R5-0008P0-Iz for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 15:34:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NJY7xC032294 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 15:34:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6G2-0003uE-Dk for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 15:22:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02502 for ; Fri, 23 Apr 2004 15:22:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH6G1-0000kF-64 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 15:22:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH6Em-0000Os-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 15:21:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH6Dv-00006Z-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 15:20:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH5wE-0005H7-6F; Fri, 23 Apr 2004 15:02:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH5kd-0005uP-7E for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 14:50:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27355 for ; Fri, 23 Apr 2004 14:50:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH5ka-0007Xv-Dp for tcpm@ietf.org; Fri, 23 Apr 2004 14:50:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH5jj-0007Em-00 for tcpm@ietf.org; Fri, 23 Apr 2004 14:49:19 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BH5ie-0006k1-00 for tcpm@ietf.org; Fri, 23 Apr 2004 14:48:12 -0400 Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3NIknN23696; Fri, 23 Apr 2004 11:46:49 -0700 (PDT) Message-ID: <40896485.5070507@isi.edu> Date: Fri, 23 Apr 2004 11:46:29 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tcpm@ietf.org References: <20040422123413.GA20156@grc.nasa.gov> <4087B3EA.8030405@cisco.com> <20040422130541.GC20156@grc.nasa.gov> <20040422214545.GH34492@pun.isi.edu> <20040423131410.GB22377@grc.nasa.gov> <20040423173759.GC42190@pun.isi.edu> <20040423175121.GH501@grc.nasa.gov> In-Reply-To: <20040423175121.GH501@grc.nasa.gov> X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig484D10FE823AB700D57990F4" X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: [tcpm] securing TCP Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig484D10FE823AB700D57990F4 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, all, The draft currently under discussion tries to secure TCP from third-party attacks via RSTs. This is only one of a number of attacks, including (but not limited to): - SYN attacks - RST attacks (as per the current discussion) - ACK attacks (as per Savage's pubs, throwing either data, or acks, or - in the new discussion - RSTs, to force a sender to open their window too much and flood the net) As has been said (someone can help with attribution or correcting the quote): Think twice before you modify TCP. Then don't. Since the current attack is already well-handled by the use of IPsec, I'd like to suggest that IF TCPM is going to move forward on 'radiation hardening' of TCP, we do so as a concerted effort, rather than as a set of potentially mutually-interfering point-wise solutions. Joe --------------enig484D10FE823AB700D57990F4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAiWSFE5f5cImnZrsRAi1oAJwJncWdgINU0BcZUSvCUrI5UdKi8ACeLFv3 W98Z6/Pe8ts+gipp6AVrDl8= =HQ3j -----END PGP SIGNATURE----- --------------enig484D10FE823AB700D57990F4-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 15:46:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04962 for ; Fri, 23 Apr 2004 15:46:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6Zf-0003Qk-PF for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 15:42:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NJgxJQ013172 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 15:42:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6Q7-0007vc-KH for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 15:33:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03184 for ; Fri, 23 Apr 2004 15:33:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH6Q6-00046p-4R for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 15:33:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH6NW-0003Fy-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 15:30:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH6Km-0002MY-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 15:27:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6DS-0001rS-8E; Fri, 23 Apr 2004 15:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH5uJ-0001iZ-8u for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 15:00:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28315 for ; Fri, 23 Apr 2004 15:00:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH5uF-0002Pa-OL for tcpm@ietf.org; Fri, 23 Apr 2004 15:00:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH5pu-0001Im-00 for tcpm@ietf.org; Fri, 23 Apr 2004 14:55:42 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BH5nd-0000bm-00 for tcpm@ietf.org; Fri, 23 Apr 2004 14:53:22 -0400 Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3NIq3N26018; Fri, 23 Apr 2004 11:52:03 -0700 (PDT) Message-ID: <408965BF.5020208@isi.edu> Date: Fri, 23 Apr 2004 11:51:43 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tcpm@ietf.org X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5B7093B4A7FAE62748650105" X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: [tcpm] securing TCP using IPsec with cookies Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5B7093B4A7FAE62748650105 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, all, In an earlier message, I wondered whether it would be useful to consider a 'cookie mode' to IPsec. I believe, FWIW, that a null-mode algorithm will suffice. The SPI becomes the shared cookie, and no further packet processing occurs. Currently 2401 prohibits use of null-mode; only one of either encryption or authentication can be null. That might be something that can be revisited in the Security Area, since its use would be appropriate for avoiding all but man-in-the-middle spoofing. Joe --------------enig5B7093B4A7FAE62748650105 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAiWW/E5f5cImnZrsRAqfbAKCSRAvOAZ+cL4neS0SlNP/yRY9ZkQCgomsR giXZWQhveeYtmj8CZT9ZYCQ= =ZSZ/ -----END PGP SIGNATURE----- --------------enig5B7093B4A7FAE62748650105-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 15:47:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05035 for ; Fri, 23 Apr 2004 15:47:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6aL-0003iw-D9 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 15:43:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NJhfnL014310 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 15:43:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6Xf-0002Yw-Gi for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 15:40:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04162 for ; Fri, 23 Apr 2004 15:40:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH6Xe-0006Eg-6J for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 15:40:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH6Ue-0005J0-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 15:37:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH6Qp-0004HW-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 15:33:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6Ff-0003rE-Ax; Fri, 23 Apr 2004 15:22:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH673-00066Q-5u for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 15:13:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01147 for ; Fri, 23 Apr 2004 15:13:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH671-0005i0-QH for tcpm@ietf.org; Fri, 23 Apr 2004 15:13:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH64J-0005AZ-00 for tcpm@ietf.org; Fri, 23 Apr 2004 15:10:36 -0400 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1BH60l-00043n-00 for tcpm@ietf.org; Fri, 23 Apr 2004 15:06:55 -0400 Received: from localhost (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with SMTP id 8929331DCC; Fri, 23 Apr 2004 21:06:24 +0200 (CEST) Received: from acorde.it.uc3m.es (acorde.it.uc3m.es [163.117.139.72]) by smtp01.uc3m.es (Postfix) with ESMTP id 8E42531DCC; Fri, 23 Apr 2004 21:06:23 +0200 (CEST) Subject: Re: [tcpm] new work item: TCP security issue From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Mitesh Dalal Cc: mallman@icir.org, tcpm@ietf.org, faber@isi.edu, Ignacio Soto Campos In-Reply-To: References: <200404222325.QAA22830@cypher.cisco.com> <1082708698.1144.89.camel@acorde> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-I/fStfWOvY+aCN532yZa" Organization: Universidad Carlos III de Madrid Message-Id: <1082747181.1144.110.camel@acorde> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 23 Apr 2004 21:06:21 +0200 Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,LINES_OF_YELLING, LINES_OF_YELLING_2 autolearn=no version=2.60 --=-I/fStfWOvY+aCN532yZa Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Hi Mitesh, Please, see in-line El vie, 23-04-2004 a las 17:46, Mitesh Dalal escribi=F3:=20 > On Fri, 23 Apr 2004, Carlos [ISO-8859-1] Jess Bernardos Cano wrote: > > > > so you are saying that an attacker needs to hit your > > > window to hose your legit connection ? > > > > No, we aren't. An attacker has to forge the origin IP address and the > > ports numbers, not only the window. This is not new, because this can b= e > > done with a RST. > > >=20 > you are missing my point. With the original spec, even if an attacker > could "guess" the ports and IPs and "hit" the sequences, he will still no= t > be able get the connection down. But with your change it can. Introducing > the very problem that we are trying to fix. Let's see if I get your point. If there is a TCP connection between A and B, and there is a malicious node M that wants to make A to reset the connection with B, it may do: - (TCP stack in A with the modification we propose to make more difficult the DoS attack described in our draft). M has to send a ACK with SEG.SEQ: RCV.NXT =3D< SEG.SEQ < (RCV.NXT + RCV.WND) Besides, the SEG.ACK has to match: SND.NXT <=3D SEG.ACK <=3D (SND.UNA + SND.WND) But notice that with a standard RFC793 TCP, M can send a RST with SEG.SEQ: RCV.NXT =3D< SEG.SEQ < (RCV.NXT + RCV.WND) and this attack is easier to perform than the first one, isn't it?. So it doesn't seem that our proposal increases the feasibility of this kind of attack. Kind regards, Carlos J. > One important point to note is that in long lived connection, most of > the time (SND.UNA =3D=3D SND.NXT) will hold true. An attacker will hence = have > ample time to DOS your connection with the above strategy. >=20 > thx > Mitesh --=20 Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 --=-I/fStfWOvY+aCN532yZa Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBAiWkt5vKyPtrWqkARAslTAJ0fOHQq5xYbF3BM63mvBrchdvQiDwCfT3Dc PdRJXytTN8tNwxAIBGYK7JU= =y0W9 -----END PGP SIGNATURE----- --=-I/fStfWOvY+aCN532yZa-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 17:13:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12431 for ; Fri, 23 Apr 2004 17:13:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH7qi-0006rk-CI for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 17:04:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NL4evP026388 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 17:04:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH7RU-0003hB-0m for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 16:38:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09682 for ; Fri, 23 Apr 2004 16:38:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH7RS-0000u8-2D for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 16:38:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH7QU-0000c7-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 16:37:35 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BH7Ph-0000Kn-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 16:36:45 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BH7Ph-0007se-HZ for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 16:36:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6bL-00049M-Mt; Fri, 23 Apr 2004 15:44:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6YV-0002p3-7F for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 15:41:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04431 for ; Fri, 23 Apr 2004 15:41:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH6YT-0006aC-NC for tcpm@ietf.org; Fri, 23 Apr 2004 15:41:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH6WB-0005xN-00 for tcpm@ietf.org; Fri, 23 Apr 2004 15:39:24 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BH6Sg-0004kY-00 for tcpm@ietf.org; Fri, 23 Apr 2004 15:35:46 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 23 Apr 2004 11:47:26 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3NJZEW9027721; Fri, 23 Apr 2004 12:35:14 -0700 (PDT) Received: from mdalal-u10.cisco.com (mdalal-u10.cisco.com [128.107.162.178]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASJ53565; Fri, 23 Apr 2004 12:34:26 -0700 (PDT) Date: Fri, 23 Apr 2004 12:35:13 -0700 (PDT) From: Mitesh Dalal To: Mika Liljeberg cc: weddy@grc.nasa.gov, Ted Faber , "Randall Stewart (cisco)" , tcpm@ietf.org Subject: Re: [tcpm] alternative RST processing In-Reply-To: <1082745616.29392.2289.camel@hades> Message-ID: References: <20040422123413.GA20156@grc.nasa.gov> <4087B3EA.8030405@cisco.com> <20040422130541.GC20156@grc.nasa.gov> <20040422214545.GH34492@pun.isi.edu> <20040423131410.GB22377@grc.nasa.gov> <20040423173759.GC42190@pun.isi.edu> <20040423175121.GH501@grc.nasa.gov> <1082745616.29392.2289.camel@hades> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,NO_COST autolearn=no version=2.60 On Fri, 23 Apr 2004, Mika Liljeberg wrote: > On Fri, 2004-04-23 at 20:51, Wesley Eddy wrote: > > A connection could be slightly disturbed by RST probing that sent 3 segments > > per slice of sequence space. If 3 duplicate acks were generated then there > > could be an unwarranted congestion response as a result of the RST attack > > on the other side. Although not breaking the connection, it could be slowed > > a bit, and the process might be repeated. This is probably not a huge > > issue. > > > > The fix would just consist of not sending repeated ACKs for multiple RSTs > > within the same window. > > I don't think we need to worry about a blind attacker sending 100k > packets just to cause a fast retransmit. :-) Certainly not worth > introducing another state variable. > exactly. there are so many places in the spec that ask to send an ACK that the above can be caused even without the new solution (ACK was supposed to be a no cost solution for all problems). Morever in the new solution, the packet has to be in the window thrice in a row. thx Mitesh _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 17:44:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15201 for ; Fri, 23 Apr 2004 17:44:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH8K4-0002qU-BH for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 17:35:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NLZ0tm010933 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 17:35:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH80I-0004Ce-2m for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 17:14:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12509 for ; Fri, 23 Apr 2004 17:14:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH80F-0003BA-Rk for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 17:14:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH7wN-0002Sr-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 17:10:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH7v6-0001r4-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 17:09:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH7dZ-00087m-6m; Fri, 23 Apr 2004 16:51:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH7B6-0007Ud-9M for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 16:21:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07760 for ; Fri, 23 Apr 2004 16:21:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH7B4-0003FP-Gj for tcpm@ietf.org; Fri, 23 Apr 2004 16:21:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH7A2-0002vW-00 for tcpm@ietf.org; Fri, 23 Apr 2004 16:20:34 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1BH795-0002NC-00 for tcpm@ietf.org; Fri, 23 Apr 2004 16:19:35 -0400 Received: from jurassic.eng.sun.com ([129.146.87.31]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i3NKJ56b020571 for ; Fri, 23 Apr 2004 13:19:05 -0700 (PDT) Received: from sun.com (shield.SFBay.Sun.COM [129.144.60.49]) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i3NKJ5mC953787 for ; Fri, 23 Apr 2004 13:19:05 -0700 (PDT) Message-ID: <40897A39.9060707@sun.com> Date: Fri, 23 Apr 2004 13:19:05 -0700 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.6) Gecko/20040117 X-Accept-Language: en, zh-hk, zh-tw, zh-cn MIME-Version: 1.0 CC: tcpm@ietf.org Subject: Re: [tcpm] new work item: TCP security issue References: <20040422131919.AFBCE77A6E0@guns.icir.org> <40881FB9.701@sun.com> <40887479.60409@sun.com> <40890B4D.4090607@cisco.com> In-Reply-To: <40890B4D.4090607@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Randall Stewart (cisco) wrote: > I don't see this has any more or any less work to whats > in the draft... if I remember from my BSD coding of this it > takes about 10 or so lines of code to do the things in the > draft... I would think the T-S option would also take the same > or maybe a bit more... Actually it is not about amount of code changes in TCP implementation. It is about backward compatibility and the probability of causing problems. If we think about it, timestamp echo can also be seen as a "cookie." If we are thinking about using cookie as a solution, I guess the timestamp option should be investigated. And as the issue is related to the window size and timestamp option has to be used for large window anyway, having a "strict" timestamp test should not cause any packet overhead. IMHO, it is much safer to go this route than modifying the very basic things in TCP. Anyway, just my $0.02... -- K. Poon. kacheong.poon@sun.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 17:50:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15550 for ; Fri, 23 Apr 2004 17:50:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH8MP-0003sC-4s for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 17:37:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NLbPoL014875 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 17:37:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH86z-0006dI-PF for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 17:21:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13565 for ; Fri, 23 Apr 2004 17:21:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH86x-0004uS-GH for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 17:21:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH84y-0004LY-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 17:19:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH81E-0003TN-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 17:15:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH7rE-00074k-5v; Fri, 23 Apr 2004 17:05:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH7Ku-0001p0-02 for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 16:31:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08992 for ; Fri, 23 Apr 2004 16:31:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH7Ks-0006fo-4j for tcpm@ietf.org; Fri, 23 Apr 2004 16:31:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH7Jw-0006ML-00 for tcpm@ietf.org; Fri, 23 Apr 2004 16:30:48 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BH7J3-00061v-00 for tcpm@ietf.org; Fri, 23 Apr 2004 16:29:53 -0400 Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3NKSUN23356; Fri, 23 Apr 2004 13:28:30 -0700 (PDT) Message-ID: <40897C4C.9020900@isi.edu> Date: Fri, 23 Apr 2004 13:27:56 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Florian Weimer CC: tcpm@ietf.org Subject: Re: FW: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: <025E7DD4182874489CC2F61EE0FA19CE02885696@daebe004.americas.nokia.com> <4087B232.4050203@cisco.com> <4087DDE6.3020703@nokia.com> <4087E36F.7000502@cisco.com> <40885BAB.2070200@isi.edu> <87y8omrehb.fsf@deneb.enyo.de> In-Reply-To: <87y8omrehb.fsf@deneb.enyo.de> X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB67DD09402B519273D6DFBA6" X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB67DD09402B519273D6DFBA6 Content-Type: multipart/mixed; boundary="------------020405030505030000060300" This is a multi-part message in MIME format. --------------020405030505030000060300 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Florian Weimer wrote: > Joe Touch writes: > > >>It would, FWIW, be useful to nail this down and cite something >>specific about it in the draft. I.e., there are two reasons this >>problem may be important: >> >> a) kills connections >> which could cause a loss of a lot of data, >> though (IMO) anything with that much data >> ought to know how to restart and recover >> from where it left-off (i.e., what it ACKd) > > > Ahem, not what it ACKed. The ACKd data is potentially lost, as you note below, by the apps. > Proper recovery has to be done above the TCP > level because data that has been ACKed can be discarded nevertheless > (for example, when an RST ist received before the data has been > delivered to the application). Certainly - some apps do this, some don't. What I'm suggesting is that one reccomendation of this sort of ID would be "apps sensitive to assasination of longstanting connections should support restart". > It's quite hard to find protocols that rely on long connections and > have no appropriate restart handling. Are there any protocols > commonly used over the Internet except BGP and IRC which have that > property? File transfer sometimes does and sometimes does not support it; that's at least one example I was thinking of. (FTP supports it, but it is often not used). >> b) killed connections can hurt BGP more than some other >> apps. >> that warrants a fix to BGP, IMO. > > BGP tends to assume that a TCP connection can be established if and > only if the link is working. This is not true with current TCP, it's > neither a sufficient nor a necessary condition. TCP is a protocol for reordering and retransmitting data (among other things, e.g., controlling flow of the data, etc.). A link 'liveness' indicator it is not; consider how much it tells you about a link if the transfer goes idle. I.e., if BGP is using TCP as a heartbeat or link tester, it is BGP that is committing the error and needs a fix. Joe --------------020405030505030000060300 Content-Type: application/pgp-signature; name="signature.asc" Content-Disposition: inline; filename="signature.asc" Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYxLjIuMyAo TWluZ1czMikNCkNvbW1lbnQ6IFVzaW5nIEdudVBHIHdpdGggVGh1bmRlcmJpcmQgLSBodHRw Oi8vZW5pZ21haWwubW96ZGV2Lm9yZw0KDQppRDhEQlFGQWlUZndFNWY1Y0ltblpyc1JBa29X QUtDVUN4bGlzQWRVcWJrOXpiZkVVOXJ1TFNyS3hBQ2VON3JnDQpKdWpmci9HYWNta1dra3Zz blE0ZjNjQT0NCj1GQUNlDQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0NCg0K --------------020405030505030000060300-- --------------enigB67DD09402B519273D6DFBA6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAiXxME5f5cImnZrsRAvx5AKCpoFZrLlXUyXtUK+WVzlO0sLzZVACdHblY Vk2no5ec3ZnkGm+RZE57yts= =soqk -----END PGP SIGNATURE----- --------------enigB67DD09402B519273D6DFBA6-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 17:50:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15570 for ; Fri, 23 Apr 2004 17:50:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH8MX-00041Y-4o for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 17:37:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NLbX3i015459 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 17:37:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH87z-0006kP-Oq for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 17:22:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13701 for ; Fri, 23 Apr 2004 17:22:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH87x-0005DP-GV for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 17:22:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH869-0004nP-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 17:20:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH83W-0003x0-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 17:17:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH7rV-0007Ky-Fo; Fri, 23 Apr 2004 17:05:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH7RS-0003h4-3b for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 16:38:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09663 for ; Fri, 23 Apr 2004 16:38:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH7RP-0000tt-Qu for tcpm@ietf.org; Fri, 23 Apr 2004 16:38:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH7QS-0000bj-00 for tcpm@ietf.org; Fri, 23 Apr 2004 16:37:33 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BH7PV-0000Kf-00 for tcpm@ietf.org; Fri, 23 Apr 2004 16:36:33 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3NKaMY19526; Fri, 23 Apr 2004 23:36:22 +0300 (EET DST) X-Scanned: Fri, 23 Apr 2004 23:36:12 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3NKaCx5030683; Fri, 23 Apr 2004 23:36:12 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00PuqTdr; Fri, 23 Apr 2004 23:36:11 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3NKa7F08792; Fri, 23 Apr 2004 23:36:07 +0300 (EET DST) Received: from nokia.com ([172.19.11.226]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 23 Apr 2004 23:36:01 +0300 Message-ID: <40897E2E.1010900@nokia.com> Date: Fri, 23 Apr 2004 15:35:58 -0500 From: Yogesh Prem Swami User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Mitesh Dalal CC: cjbc@it.uc3m.es, mallman@icir.org, tcpm@ietf.org, faber@isi.edu Subject: Re: [tcpm] new work item: TCP security issue References: <200404222325.QAA22830@cypher.cisco.com> <40891BDD.5060409@nokia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Apr 2004 20:36:01.0260 (UTC) FILETIME=[972DFAC0:01C42972] Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ext Mitesh Dalal wrote: >On Fri, 23 Apr 2004, Yogesh Prem Swami wrote: > > > >>I haven't read this draft, but acking a lost packet is a potentially >>serious DoS attack as I pointed out in one of my previous e-mail. Once >>the sender receives the ACK (sent either by the attacker or by the >>receiver), the sender will throw away that packet from the send queue. >>But since the receiver has not received the packet (it was lost), it >>will keep generating duplicate ACKs (all of which will be discarded by >>the the sender). This deadlock will take numerous timeouts before the >>sender resets the connection and releases all resources. To perform this >>attack, the attacker has the same "sequence guessing" requirements as in >>the secure TCP draft. >> >> > >I disagree that its as bad as you think it is. For causing an ACK >attack as above, the attacker has to be correct on 2 axis, on the >number axis and the time axis. Sequence numbers will change throughout >the life of the connection and hence the attacker has to keep up >with the time factor as well. But yes there is a small(very small :) >window of attack possible. > I agree that the probability is smaller, but not as small as you seem to suggest (How small is "very small" in your definition?). The probability of guessing a valid sequence number within advertised window is as much as is pointed out in the draft. An attacker can just keep sending an ACK with ACK sequence number ACK_guessed + rcv_wnd. At some point, the tcp congestion window will slide over this sequence number, and if there happens to be a packet loss, the connection will get deadlocked. So there is no time axis ... The fact that there is a need for packet loss, is what reduces the probability of an attack. But on the other hand, once attackers have achieved their goal, it will take ~hours (depending upon RTO_MAX and other parameters) before anyone will notice something is wrong. I don't know if you would consider this as a worrisome situation. Yogesh _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 17:54:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15917 for ; Fri, 23 Apr 2004 17:54:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH8Tt-0007c8-Tv for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 17:45:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NLj9X7029260 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 17:45:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH8Kc-0002wv-Kd for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 17:35:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14558 for ; Fri, 23 Apr 2004 17:35:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH8Ka-00010q-7J for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 17:35:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH8JR-0000Tu-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 17:34:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH8I5-00006D-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 17:32:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH7w3-0002X8-T9; Fri, 23 Apr 2004 17:10:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH7hk-00013X-U2 for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 16:55:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10720 for ; Fri, 23 Apr 2004 16:55:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH7hi-0005Ux-Rh for tcpm@ietf.org; Fri, 23 Apr 2004 16:55:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH7gl-0005G5-00 for tcpm@ietf.org; Fri, 23 Apr 2004 16:54:23 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BH7fy-0004jR-00 for tcpm@ietf.org; Fri, 23 Apr 2004 16:53:34 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 23 Apr 2004 13:04:02 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3NKr1Su021834; Fri, 23 Apr 2004 13:53:01 -0700 (PDT) Received: from mdalal-u10.cisco.com (mdalal-u10.cisco.com [128.107.162.178]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASJ60123; Fri, 23 Apr 2004 13:52:13 -0700 (PDT) Date: Fri, 23 Apr 2004 13:53:00 -0700 (PDT) From: Mitesh Dalal To: Yogesh Prem Swami cc: cjbc@it.uc3m.es, mallman@icir.org, tcpm@ietf.org, faber@isi.edu Subject: Re: [tcpm] new work item: TCP security issue In-Reply-To: <40897E2E.1010900@nokia.com> Message-ID: References: <200404222325.QAA22830@cypher.cisco.com> <40891BDD.5060409@nokia.com> <40897E2E.1010900@nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 On Fri, 23 Apr 2004, Yogesh Prem Swami wrote: > ext Mitesh Dalal wrote: > > >On Fri, 23 Apr 2004, Yogesh Prem Swami wrote: > > > > > > > >>I haven't read this draft, but acking a lost packet is a potentially > >>serious DoS attack as I pointed out in one of my previous e-mail. Once > >>the sender receives the ACK (sent either by the attacker or by the > >>receiver), the sender will throw away that packet from the send queue. > >>But since the receiver has not received the packet (it was lost), it > >>will keep generating duplicate ACKs (all of which will be discarded by > >>the the sender). This deadlock will take numerous timeouts before the > >>sender resets the connection and releases all resources. To perform this > >>attack, the attacker has the same "sequence guessing" requirements as in > >>the secure TCP draft. > >> > >> > > > >I disagree that its as bad as you think it is. For causing an ACK > >attack as above, the attacker has to be correct on 2 axis, on the > >number axis and the time axis. Sequence numbers will change throughout > >the life of the connection and hence the attacker has to keep up > >with the time factor as well. But yes there is a small(very small :) > >window of attack possible. > > > > I agree that the probability is smaller, but not as small as you seem to > suggest (How small is "very small" in your definition?). The to the point of being negligible. > probability of guessing a valid sequence number within advertised > window is as much as is pointed out in the draft. An attacker can just I do not think the comparison holds. In the attack as described in the draft, its most focuses on long lived connection where no data/ACK is inflight. Here the attacker has ample time to guess the window. He simply needs to systematically increase sequence by window size. But if you are actively sending and receiving stuff, how does an attacker keep up with this. What algorithm does he need to use ? try this: setup a rcp connection between 2 boxes and do an active data transfer. Try to hose this connection with the ACK attack you mention. Now try the RST attack in the draft. You have a steady telnet (or bgp) connection and systematically send it RST with incremental sequences. Which do you think will be harder to achieve ? > keep sending an ACK with ACK sequence number ACK_guessed + rcv_wnd. At > some point, the tcp congestion window will slide over this sequence > number, and if there happens to be a packet loss, the connection will for this you have to send ACKs much faster than the data transfer actually underway. thx Mitesh > get deadlocked. So there is no time axis ... > > The fact that there is a need for packet loss, is what reduces the > probability of an attack. But on the other hand, once attackers have > achieved their goal, it will take ~hours (depending upon RTO_MAX and > other parameters) before anyone will notice something is wrong. I don't > know if you would consider this as a worrisome situation. > > Yogesh > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 18:25:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18565 for ; Fri, 23 Apr 2004 18:25:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH91s-0000kZ-Me for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 18:20:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NMKGX6002879 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 18:20:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH8wP-0005o9-AA for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 18:14:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17708 for ; Fri, 23 Apr 2004 18:14:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH8wM-0003mH-Gq for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 18:14:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH8vV-0003WA-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 18:13:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH8uz-0003Eu-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 18:13:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH8dW-0002uk-PL; Fri, 23 Apr 2004 17:55:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH8at-0001hz-0r for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 17:52:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15735 for ; Fri, 23 Apr 2004 17:52:18 -0400 (EDT) From: Yogesh.Swami@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH8aq-0005hI-Ak for tcpm@ietf.org; Fri, 23 Apr 2004 17:52:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH8Zr-0005Q0-00 for tcpm@ietf.org; Fri, 23 Apr 2004 17:51:20 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BH8Yx-00058R-00 for tcpm@ietf.org; Fri, 23 Apr 2004 17:50:23 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3NLoBs23606; Sat, 24 Apr 2004 00:50:11 +0300 (EET DST) X-Scanned: Sat, 24 Apr 2004 00:50:03 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3NLo3DV030155; Sat, 24 Apr 2004 00:50:03 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 009JfHjk; Sat, 24 Apr 2004 00:50:03 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3NLnvF00351; Sat, 24 Apr 2004 00:49:58 +0300 (EET DST) Received: from daebe004.NOE.Nokia.com ([10.241.35.104]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 23 Apr 2004 16:49:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] new work item: TCP security issue Date: Fri, 23 Apr 2004 16:49:57 -0500 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE016E80EC@daebe004.americas.nokia.com> Thread-Topic: [tcpm] new work item: TCP security issue Thread-Index: AcQpdtV2blngyqjHRgS4zFSdMSa6EAABWrSQ To: Cc: , , , X-OriginalArrivalTime: 23 Apr 2004 21:49:58.0418 (UTC) FILETIME=[EBEE8F20:01C4297C] Content-Transfer-Encoding: quoted-printable Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >=20 > I do not think the comparison holds. In the attack as described in the > draft, its most focuses on long lived connection where no data/ACK is > inflight. Here the attacker has ample time to guess the window. He Hoon... Now I understand better.=20 Yogesh > simply needs to systematically increase sequence by window=20 > size. But if > you are actively sending and receiving stuff, how does an=20 > attacker keep > up with this. What algorithm does he need to use ? >=20 > try this: setup a rcp connection between 2 boxes and do an active data > transfer. Try to hose this connection with the ACK attack you mention. > Now try the RST attack in the draft. You have a steady telnet (or bgp) > connection and systematically send it RST with incremental sequences. >=20 > Which do you think will be harder to achieve ? >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 18:42:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19664 for ; Fri, 23 Apr 2004 18:42:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH9BU-0005Hi-Q5 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 18:30:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NMUCsf020308 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 18:30:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH96w-0003Ly-Ll for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 18:25:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18649 for ; Fri, 23 Apr 2004 18:25:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH96t-0006kX-MY for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 18:25:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH95z-0006UP-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 18:24:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH95Q-0006ED-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 18:23:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH91d-0000if-MP; Fri, 23 Apr 2004 18:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH8tG-0003mw-Ma for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 18:11:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17323 for ; Fri, 23 Apr 2004 18:11:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH8tD-0002vS-Qn for tcpm@ietf.org; Fri, 23 Apr 2004 18:11:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH8sI-0002ep-00 for tcpm@ietf.org; Fri, 23 Apr 2004 18:10:22 -0400 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 1BH8rI-0002Nz-00 for tcpm@ietf.org; Fri, 23 Apr 2004 18:09:20 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate.mot.com (Motorola/Motgate) with ESMTP id i3NM96ib024071; Fri, 23 Apr 2004 15:09:06 -0700 (MST) Received: from motorola.com (d1421-0a1071e2.cig.mot.com [10.16.113.226]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i3NM4Nqg017760; Fri, 23 Apr 2004 17:04:23 -0500 Message-ID: <40899421.5030105@motorola.com> Date: Fri, 23 Apr 2004 17:09:37 -0500 From: Qiaobing Xie User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Touch CC: Florian Weimer , tcpm@ietf.org Subject: Re: FW: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: <025E7DD4182874489CC2F61EE0FA19CE02885696@daebe004.americas.nokia.com> <4087B232.4050203@cisco.com> <4087DDE6.3020703@nokia.com> <4087E36F.7000502@cisco.com> <40885BAB.2070200@isi.edu> <87y8omrehb.fsf@deneb.enyo.de> <40897C4C.9020900@isi.edu> In-Reply-To: <40897C4C.9020900@isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Joe Touch wrote: ... >>> b) killed connections can hurt BGP more than some other >>> apps. >>> that warrants a fix to BGP, IMO. >> >> >> BGP tends to assume that a TCP connection can be established if and >> only if the link is working. This is not true with current TCP, it's >> neither a sufficient nor a necessary condition. > > TCP is a protocol for reordering and retransmitting data (among other > things, e.g., controlling flow of the data, etc.). A link 'liveness' > indicator it is not; consider how much it tells you about a link if the > transfer goes idle. > > I.e., if BGP is using TCP as a heartbeat or link tester, it is BGP that > is committing the error and needs a fix. If it can be sufficiently established that in the real world there are only a few app protocols (BGP as one of them) that are actually impacted by those vulnerabilities, it may make more sense to leave TCP alone and simply recommend those few apps to consider using SCTP which seems to be fairly robust against those attacks. regards, -Qiaobing > > Joe > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 18:51:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20275 for ; Fri, 23 Apr 2004 18:51:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH9SN-0002Ux-J2 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 18:47:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NMldu0009599 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 18:47:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH9PN-0001TF-Hd for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 18:44:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19794 for ; Fri, 23 Apr 2004 18:44:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH9PK-000467-K7 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 18:44:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH9OW-0003pw-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 18:43:40 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH9Np-0003Z7-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 18:42:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH9CI-0005dk-6m; Fri, 23 Apr 2004 18:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH98t-0004MU-3u for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 18:27:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18752 for ; Fri, 23 Apr 2004 18:27:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH98q-0007Gr-2d for tcpm@ietf.org; Fri, 23 Apr 2004 18:27:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH97q-00070s-00 for tcpm@ietf.org; Fri, 23 Apr 2004 18:26:26 -0400 Received: from [131.227.76.5] (helo=prue.eim.surrey.ac.uk ident=exim) by ietf-mx with esmtp (Exim 4.12) id 1BH96s-0006jO-00 for tcpm@ietf.org; Fri, 23 Apr 2004 18:25:26 -0400 Received: from argos.ee.surrey.ac.uk ([131.227.89.15] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 1BH96f-0005TB-00; Fri, 23 Apr 2004 23:25:13 +0100 Date: Fri, 23 Apr 2004 23:25:11 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@argos.ee.surrey.ac.uk To: tcpm@ietf.org, "" Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt In-Reply-To: <40897C4C.9020900@isi.edu> Message-ID: References: <025E7DD4182874489CC2F61EE0FA19CE02885696@daebe004.americas.nokia.com> <4087B232.4050203@cisco.com> <4087DDE6.3020703@nokia.com> <4087E36F.7000502@cisco.com> <40885BAB.2070200@isi.edu> <87y8omrehb.fsf@deneb.enyo.de> <40897C4C.9020900@isi.edu> Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: no MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *1BH96f-0005TB-00*vSsLgRk5IrM* (SECM, UniS) Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I'm interested in the proposed RST ack challenge/response mechanism. I expect the case that the valid packet received containing the RST flag is _not_ the packet the receiver was expecting with the next expected sequence number to be quite common, with packet reordering in the Internet, loss (and don't users often kill slow browser connections?), and whatnot. Connections don't always get closed under the best of conditions. It strikes me that, a priori, both sender and receiver know and can remember the initial sequence number ever used on their connection, which is (pseudo-randomly) selected. Randomness of initial sequence numbers was recently improved, after much media fuss: http://www.google.com/search?q=initial+sequence+number+randomness We can use this randomness to our advantage. This first sequence number information can be used to form part of the challenge-response; if the sender has sent an RST packet whose sequence number lies in the window, but it is not the next expected packet, the ack sent back by the receiver can be an indicator for the RST sender to pass the first sequence number in a subsequent packet (also containing a confirming RST flag. 'I told you to close. I'm telling you to close again. And here's a reminder of when we first spoke and agreed to open. It's a random number we both know.'.) I suppose this could be passed as (sigh) a new TCP option -- or, better, you could just use the existing sequence number field. Existing TCP implementations would ignore this second RST packet containing the original first sequence number in that field if that correct number lies outside the window, and if it's inside, well, you've already sent one RST anyway. You're likely backwards compatible. This weak authentication might give added protection to long-lived TCP flows, as the attacker would need to snoop on the start of the connection to know that first sequence number - and if she's doing that, your unsecure data can already be hers. (Why is there so much fuss about a weak DoS attack and no fuss about the widespread reliance on an unsecure transfer protocol?) And in tying to sequence space, which is where our problem lies, storing and resending the initial sequence number on request as a cookie seems somewhat easier to code and deal with than the later and optional timestamps (K Poon's suggestion), as we avoid option fields entirely. L. apologies if this has already been suggested in these related threads. Unfortunately, my life prevents me from reading email full-time. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 19:41:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22634 for ; Fri, 23 Apr 2004 19:41:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHAGi-0001me-Ar for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 19:39:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NNdeJp006851 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 19:39:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHACi-0008To-D5 for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 19:35:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22287 for ; Fri, 23 Apr 2004 19:35:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHACg-0001wh-MZ for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 19:35:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHABp-0001h4-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 19:34:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BHABJ-0001Rg-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 19:34:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH9vk-0003Yn-RO; Fri, 23 Apr 2004 19:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH9sI-0002Jq-Kv for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 19:14:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21330 for ; Fri, 23 Apr 2004 19:14:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH9sH-0004LA-0f for tcpm@ietf.org; Fri, 23 Apr 2004 19:14:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH9rO-00046X-00 for tcpm@ietf.org; Fri, 23 Apr 2004 19:13:31 -0400 Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 1BH9qf-0003hG-00 for tcpm@ietf.org; Fri, 23 Apr 2004 19:12:45 -0400 Received: from lombok-fi.grc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 9D8DC68976 for ; Fri, 23 Apr 2004 19:12:15 -0400 (EDT) Received: from sunfire.grc.nasa.gov (IDENT:postfix@sunfire.grc.nasa.gov [139.88.111.70]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id i3NNCF3c000209 for ; Fri, 23 Apr 2004 19:12:15 -0400 (EDT) Received: by sunfire.grc.nasa.gov (Postfix, from userid 500) id 0F398BC218; Fri, 23 Apr 2004 19:13:29 -0400 (EDT) Date: Fri, 23 Apr 2004 19:13:29 -0400 From: Joseph Ishac To: tcpm@ietf.org Subject: Re: [tcpm] Re: draft-eggert-tcpm-tcp-abort-timeout-option-00.txt Message-ID: <20040423191329.A28664@sunfire.grc.nasa.gov> Reply-To: Joseph Ishac Mail-Followup-To: tcpm@ietf.org References: <20040421151201.GC32188@grc.nasa.gov> <40869644.2020509@netlab.nec.de> <20040421133509.A24692@sunfire.grc.nasa.gov> <4087985A.5030409@netlab.nec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <4087985A.5030409@netlab.nec.de>; from lars.eggert@netlab.nec.de on Thu, Apr 22, 2004 at 12:03:06PM +0200 Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Thu, Apr 22, 2004 at 12:03:06PM +0200, Lars Eggert wrote: > Joseph Ishac wrote: > > > That's my take on the proposal... using the terminology in the draft. > > Confusion probably arises from the use of 'initiator' and 'responder' in > > the text. > > I delibertated wether to use client/server or initiator/responder during > the description. The latter seemed more accurate, but the former may be > more easily understood. Maybe a short paragraph defining the two terms > would help? An added explanation in the text may be beneficial. In particular, I think it's confusing because (like you mention) no other options are like this (well... that I know of). Also, I'm with Wes' note earlier on trying to consolidate this all into the SYN and SYN/ACK. If the 'initiator of the connection' or client can support ATO then it should advertise it on the SYN. It should just set the value to what it would tolerate had it been responding to a request. If they don't care, they could just set it to the default value they would be using anyways. I don't think a magic value would be needed. What may be need instead is a flag that exists within the option to distinguish it between a request and an offer. The way I understand it, both A and B can have at most two values in mind for the ATO. X) Value that I'd like to request given the chance (set by maybe a sock opt or some other knowledge... and dependent on resources) Y) Max value that I can apply too an incoming request (based on resources, number of connections, and heuristics) Those 2 values being independent of any other nodes' 2 values and known before the next connection is even made or received. Example: A (X1,Y1) --> B (X2,Y2) SYN SYN/ACK + X2 ACK + ??? Case 1) Say ??? is silent: this could have been accomplished by the "B" simply inferring that ATO wasn't supported on "A"s empty SYN Case 2) Say ??? is less than X2: meaning "A" is expressing it's max (Y1). Had "A" expressed it's max in the SYN the result would be the same. Case 3) Say ??? matches X2: meaning that you were below "A"s max. The same result would have occurred had "A" started with its max in the SYN, as "B" would knock it down to X2. The only problem with case 3 is that "B" needs to know that the value in the SYN is not a request. Hence, the thought of using a flag to distinguish the two. > > Finally, is it worth specifying what action should be taken if the ATO > > response is *larger* than the original request. Is the ATO rejected or > > accepted at the initial value? > > Following the "be liberal in what you accept" guideline I guess the > regular default timeout should be used instead of rejecting and > resetting the connection. Right, falling back on the defaults seems fine. -Joseph _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 19:48:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23041 for ; Fri, 23 Apr 2004 19:48:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHANy-0003lD-3o for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 19:47:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NNl9Rm014451 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 19:47:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHAIC-0002Nx-6V for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 19:41:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22620 for ; Fri, 23 Apr 2004 19:41:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHAIA-00037S-Gz for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 19:41:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHAH6-0002lv-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 19:40:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BHAEm-0002Sg-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 19:37:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHACE-0008Hb-Mq; Fri, 23 Apr 2004 19:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH9z9-0004KB-KB for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 19:21:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21669 for ; Fri, 23 Apr 2004 19:21:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH9z8-00067r-0p for tcpm@ietf.org; Fri, 23 Apr 2004 19:21:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH9yW-0005rq-00 for tcpm@ietf.org; Fri, 23 Apr 2004 19:20:53 -0400 Received: from dsl092-066-146.bos1.dsl.speakeasy.net ([66.92.66.146] helo=alva.home) by ietf-mx with esmtp (Exim 4.12) id 1BH9xS-0005Ms-00 for tcpm@ietf.org; Fri, 23 Apr 2004 19:19:46 -0400 Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1BH9wo-0005j0-00 for ; Fri, 23 Apr 2004 19:19:06 -0400 From: Tim Shepard To: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt In-reply-to: Your message of Fri, 23 Apr 2004 23:25:11 +0100. Date: Fri, 23 Apr 2004 19:19:06 -0400 Message-Id: Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 > This first sequence number information can be used to form part of the > challenge-response; if the sender has sent an RST packet whose > sequence number lies in the window, but it is not the next expected > packet, the ack sent back by the receiver can be an indicator for the > RST sender to pass the first sequence number in a subsequent packet > (also containing a confirming RST flag. 'I told you to close. I'm > telling you to close again. And here's a reminder of when we first > spoke and agreed to open. It's a random number we both know.'.) If I'm sending you a RST because I rebooted and lost all state and don't have any state for the TCP connection that you apparently have becasue you are sending me packets, how am I supposed to remember what the initial sequence number was? Here's an idea (just thinkint out loud here) for solving the BGP problem: Ignore RSTs and just let keep alive failures and timers take care of tearing down old connections. (and continuing to think out loud here....) Joe Touch recently suggested that IPsec/ESP with Null encryption and authentication would effectively put in place a cookie mechanism (the SPI being the cookie) which would be sufficient to solve these probelms. But that just pushes the problem of handling a TCP RST to figuring out how to "RST" a IPsec SA. And my understanding of that problem (which is based on recent discussion in HIP WG) is that when a packet shows up with an unknown SPI, that you might have a mechanism that sends back an advisory "unknown SPI" notification, but that when you receive an "unknown SPI" notification, there's not much you can do with it because it could be someone spoofing you. So it seems just hacking your TCP implementation to ignore RSTs might give you the same robustness that you'd get from null-encryption, null-authentication IPsec ESP. -Tim Shepard shep@alum.mit.edu _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 20:09:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24304 for ; Fri, 23 Apr 2004 20:09:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHAiG-0001rv-6K for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 20:08:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3O088Mk007178 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 20:08:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHAfB-0000We-7h for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 20:04:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23961 for ; Fri, 23 Apr 2004 20:04:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHAf9-0001pV-Cc for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 20:04:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHAdx-0001Wh-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 20:03:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BHAdL-0001FY-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 20:03:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHAZR-0007Di-DN; Fri, 23 Apr 2004 19:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHAT9-00052l-Fv for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 19:52:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23234 for ; Fri, 23 Apr 2004 19:52:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHAT7-0006Hg-IW for tcpm@ietf.org; Fri, 23 Apr 2004 19:52:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHASB-000626-00 for tcpm@ietf.org; Fri, 23 Apr 2004 19:51:32 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BHARS-0005ml-00 for tcpm@ietf.org; Fri, 23 Apr 2004 19:50:46 -0400 Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3NNnbN12324; Fri, 23 Apr 2004 16:49:37 -0700 (PDT) Message-ID: <4089AB50.1090101@isi.edu> Date: Fri, 23 Apr 2004 16:48:32 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Shepard CC: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3BC8657487B94DC6AE289769" X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3BC8657487B94DC6AE289769 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Tim Shepard wrote: ... > (and continuing to think out loud here....) > > Joe Touch recently suggested that IPsec/ESP with Null encryption and > authentication would effectively put in place a cookie mechanism (the > SPI being the cookie) which would be sufficient to solve these > probelms. But that just pushes the problem of handling a TCP RST to > figuring out how to "RST" a IPsec SA. Why do I have to RST an SA? I certainly have to re-key. But otherwise the only party sending a RST will be inside the SA anyway. > And my understanding of that > problem (which is based on recent discussion in HIP WG) is that when a > packet shows up with an unknown SPI, that you might have a mechanism > that sends back an advisory "unknown SPI" notification, but that when > you receive an "unknown SPI" notification, there's not much you can do > with it because it could be someone spoofing you. Sure - which begs the question as to why you're doing anything with unknown SPIs other than dropping the packet silently, as required. To reply in any way would be a violation of 2401. > So it seems just hacking your TCP implementation to ignore RSTs > might give you the same robustness that you'd get from > null-encryption, null-authentication IPsec ESP. > > -Tim Shepard > shep@alum.mit.edu --------------enig3BC8657487B94DC6AE289769 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAiatQE5f5cImnZrsRAsyDAKDS+mYLfjDlnnfuxV0BxheF+WII9ACeI1PF yHb1Mvurc2nOd8jCA0/bczc= =Z9Y1 -----END PGP SIGNATURE----- --------------enig3BC8657487B94DC6AE289769-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 20:10:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24326 for ; Fri, 23 Apr 2004 20:10:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHAib-0001t0-Pn for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 20:08:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3O08T72007246 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 20:08:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHAg6-0000mw-CW for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 20:05:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24107 for ; Fri, 23 Apr 2004 20:05:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHAg4-00027R-Er for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 20:05:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHAfA-0001pi-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 20:04:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BHAeA-0001Wp-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 20:03:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHAaS-0007XY-NH; Fri, 23 Apr 2004 20:00:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHAW0-0005tX-AA for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 19:55:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23374 for ; Fri, 23 Apr 2004 19:55:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHAVy-00071p-BT for tcpm@ietf.org; Fri, 23 Apr 2004 19:55:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHAV8-0006nL-00 for tcpm@ietf.org; Fri, 23 Apr 2004 19:54:35 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1BHAUc-0006XY-00 for tcpm@ietf.org; Fri, 23 Apr 2004 19:54:02 -0400 Received: from jurassic.eng.sun.com ([129.146.82.166]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i3NNrV6b026962; Fri, 23 Apr 2004 16:53:31 -0700 (PDT) Received: from sun.com (shield.SFBay.Sun.COM [129.144.60.49]) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i3NNrVvr140116; Fri, 23 Apr 2004 16:53:31 -0700 (PDT) Message-ID: <4089AC7B.8090504@sun.com> Date: Fri, 23 Apr 2004 16:53:31 -0700 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.6) Gecko/20040117 X-Accept-Language: en, zh-hk, zh-tw, zh-cn MIME-Version: 1.0 To: shep@alum.mit.edu CC: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Tim Shepard wrote: > If I'm sending you a RST because I rebooted and lost all state and > don't have any state for the TCP connection that you apparently have > becasue you are sending me packets, how am I supposed to remember what > the initial sequence number was? Although people do not seem to be considering this... But if timestamp option is used, the receiver of the RST can check the timetstamp echo value and verify that the RST is indeed triggered by its own TCP segment. > Here's an idea (just thinkint out loud here) for solving the BGP problem: > > Ignore RSTs and just let keep alive failures and timers take care of > tearing down old connections. I assume that you were only suggesting this as a TCP socket option which an app could set to tell the stack to ignore RST. IMHO, this is really not acceptable as a general mechanism in TCP. -- K. Poon. kacheong.poon@sun.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 20:17:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24658 for ; Fri, 23 Apr 2004 20:17:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHAjx-0002Wo-Mo for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 20:09:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3O09reK009714 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 20:09:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHAij-0001tc-Ce for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 20:08:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24227 for ; Fri, 23 Apr 2004 20:08:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHAih-0002sb-EJ for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 20:08:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHAhb-0002cC-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 20:07:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BHAh0-0002Lq-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 20:06:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHAaT-0007Y0-Ks; Fri, 23 Apr 2004 20:00:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHAXr-0006eh-Pw for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 19:57:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23437 for ; Fri, 23 Apr 2004 19:57:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHAXp-0007Vb-Uf for tcpm@ietf.org; Fri, 23 Apr 2004 19:57:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHAWs-0007GM-00 for tcpm@ietf.org; Fri, 23 Apr 2004 19:56:22 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BHAVy-00071q-00 for tcpm@ietf.org; Fri, 23 Apr 2004 19:55:26 -0400 Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3NNsWN13451; Fri, 23 Apr 2004 16:54:32 -0700 (PDT) Message-ID: <4089AC77.6090207@isi.edu> Date: Fri, 23 Apr 2004 16:53:27 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Qiaobing Xie CC: Florian Weimer , tcpm@ietf.org Subject: Re: FW: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: <025E7DD4182874489CC2F61EE0FA19CE02885696@daebe004.americas.nokia.com> <4087B232.4050203@cisco.com> <4087DDE6.3020703@nokia.com> <4087E36F.7000502@cisco.com> <40885BAB.2070200@isi.edu> <87y8omrehb.fsf@deneb.enyo.de> <40897C4C.9020900@isi.edu> <40899421.5030105@motorola.com> In-Reply-To: <40899421.5030105@motorola.com> X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE0023D5A879EF0E82919A2AE" X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE0023D5A879EF0E82919A2AE Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Qiaobing Xie wrote: > Joe Touch wrote: > > ... > >>>> b) killed connections can hurt BGP more than some other >>>> apps. >>>> that warrants a fix to BGP, IMO. >>> >>> >>> >>> BGP tends to assume that a TCP connection can be established if and >>> only if the link is working. This is not true with current TCP, it's >>> neither a sufficient nor a necessary condition. >> >> >> TCP is a protocol for reordering and retransmitting data (among other >> things, e.g., controlling flow of the data, etc.). A link 'liveness' >> indicator it is not; consider how much it tells you about a link if the >> transfer goes idle. >> >> I.e., if BGP is using TCP as a heartbeat or link tester, it is BGP that >> is committing the error and needs a fix. > > > If it can be sufficiently established that in the real world there are > only a few app > protocols (BGP as one of them) that are actually impacted by those > vulnerabilities, it may > make more sense to leave TCP alone and simply recommend those few apps > to consider using > SCTP which seems to be fairly robust against those attacks. > > regards, > -Qiaobing The routers in question are more likely (IMO) to support IPsec already than to already have SCTP. Besides, as I noted, this is an IPsec issue - you want to trust who you get a RST from. There are other good reasons to want IPsec here, since there are other similar attacks that you might want to protect. I.e., BGP is infrastructure. Secure it. (IMO) Joe --------------enigE0023D5A879EF0E82919A2AE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAiax3E5f5cImnZrsRAmiAAKDARSw9JHSykwSWlzTr+kn/Y61brQCg89H1 +wOJXgifBL146L1R80ICGDc= =q61S -----END PGP SIGNATURE----- --------------enigE0023D5A879EF0E82919A2AE-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 23 20:32:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25123 for ; Fri, 23 Apr 2004 20:32:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHB1z-0006xp-19 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 20:28:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3O0SVOp026764 for tcpm-archive@odin.ietf.org; Fri, 23 Apr 2004 20:28:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHAsD-0004NR-Ng for tcpm-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 20:18:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24702 for ; Fri, 23 Apr 2004 20:18:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHAsB-0005Qg-NW for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 20:18:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHArH-0005BF-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 20:17:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BHAqP-0004w1-00 for tcpm-web-archive@ietf.org; Fri, 23 Apr 2004 20:16:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHAjF-0002CZ-I3; Fri, 23 Apr 2004 20:09:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHAdy-000056-6x for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 20:03:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23923 for ; Fri, 23 Apr 2004 20:03:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHAdw-0001WU-8h for tcpm@ietf.org; Fri, 23 Apr 2004 20:03:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHAcx-0001FP-00 for tcpm@ietf.org; Fri, 23 Apr 2004 20:02:39 -0400 Received: from prue.eim.surrey.ac.uk ([131.227.76.5] ident=exim) by ietf-mx with esmtp (Exim 4.12) id 1BHAcX-0000z0-00 for tcpm@ietf.org; Fri, 23 Apr 2004 20:02:13 -0400 Received: from argos.ee.surrey.ac.uk ([131.227.89.15] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 1BHAbz-0001Em-00; Sat, 24 Apr 2004 01:01:39 +0100 Date: Sat, 24 Apr 2004 01:01:37 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@argos.ee.surrey.ac.uk To: Tim Shepard cc: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt In-Reply-To: Message-ID: References: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *1BHAbz-0001Em-00*6RZcrdCDJ/I* (SECM, UniS) Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Fri, 23 Apr 2004, Tim Shepard wrote: > > This first sequence number information can be used to form part of the > > challenge-response; if the sender has sent an RST packet whose > > sequence number lies in the window, but it is not the next expected > > packet, the ack sent back by the receiver can be an indicator for the > > RST sender to pass the first sequence number in a subsequent packet > > (also containing a confirming RST flag. 'I told you to close. I'm > > telling you to close again. And here's a reminder of when we first > > spoke and agreed to open. It's a random number we both know.'.) > > If I'm sending you a RST because I rebooted and lost all state and > don't have any state for the TCP connection that you apparently have > becasue you are sending me packets, how am I supposed to remember what > the initial sequence number was? If you've rebooted, it's much more likely that the RST you send will be next-in-sequence, given decreased window sizes while the other open end hangs around waiting for you to reboot. The RST ACK mechanism in intended for in-window-but-not-next- expected-seq-no RST packets (ahem, TCP segments): | I expect the case that the valid packet received containing the RST | flag is _not_ the packet the receiver was expecting with the next | expected sequence number to be quite common, with packet reordering | in the Internet, loss (and don't users often kill slow browser | connections?), and whatnot. L. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Sun Apr 25 16:33:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16243 for ; Sun, 25 Apr 2004 16:33:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHqG4-0007jZ-C3 for tcpm-archive@odin.ietf.org; Sun, 25 Apr 2004 16:29:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3PKTmkB029723 for tcpm-archive@odin.ietf.org; Sun, 25 Apr 2004 16:29:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHqFW-0007SG-7k for tcpm-web-archive@optimus.ietf.org; Sun, 25 Apr 2004 16:29:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16106 for ; Sun, 25 Apr 2004 16:29:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHqFU-0007hd-EG for tcpm-web-archive@ietf.org; Sun, 25 Apr 2004 16:29:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHqEW-0007VU-00 for tcpm-web-archive@ietf.org; Sun, 25 Apr 2004 16:28:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BHqDV-0007GO-00 for tcpm-web-archive@ietf.org; Sun, 25 Apr 2004 16:27:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHq6c-0004t5-Jq; Sun, 25 Apr 2004 16:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHq4r-0004AQ-QA for tcpm@optimus.ietf.org; Sun, 25 Apr 2004 16:18:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15755 for ; Sun, 25 Apr 2004 16:18:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHq4q-0005ab-2k for tcpm@ietf.org; Sun, 25 Apr 2004 16:18:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHq3t-0005P3-00 for tcpm@ietf.org; Sun, 25 Apr 2004 16:17:13 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx with esmtp (Exim 4.12) id 1BHq2y-0005DQ-00 for tcpm@ietf.org; Sun, 25 Apr 2004 16:16:16 -0400 Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by wyvern.icir.org (8.12.9p1/8.12.8) with ESMTP id i3PKGCjN017477; Sun, 25 Apr 2004 13:16:12 -0700 (PDT) (envelope-from mallman@icir.org) Received: from lawyers.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by guns.icir.org (Postfix) with ESMTP id 0E82C77A71D; Sun, 25 Apr 2004 16:16:10 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 699B91402F5; Sun, 25 Apr 2004 10:50:05 -0400 (EDT) To: tcpm@ietf.org Cc: Joseph Ishac From: Mark Allman Reply-To: mallman@icir.org Subject: Re: [tcpm] Re: draft-eggert-tcpm-tcp-abort-timeout-option-00.txt In-Reply-To: <20040423191329.A28664@sunfire.grc.nasa.gov> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: The Bug MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sun, 25 Apr 2004 10:50:05 -0400 Message-Id: <20040425145005.699B91402F5@lawyers.icir.org> Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,DATE_IN_PAST_03_06 autolearn=no version=2.60 --=-=-= Content-Type: text/plain > Also, I'm with Wes' note earlier on trying to consolidate this all > into the SYN and SYN/ACK. I just read the draft and my concern with this business of carrying the ATO on the ACK has less to do with consistency or beauty, but rather with the ACK of the SYN+ACK being unreliable. It is pretty easy to construct a case whereby the two endpoints will be out of sync because the ACK is lost. allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin) iD8DBQFAi9AcWyrrWs4yIs4RArjQAJ966VjcvrMGEdfRAy9iBjBn0KBq/ACdGXDg l55GFHODITVs7yOPScLywYg= =SXpl -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon Apr 26 04:43:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03948 for ; Mon, 26 Apr 2004 04:43:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI1Zn-0006Ip-Aw for tcpm-archive@odin.ietf.org; Mon, 26 Apr 2004 04:34:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3Q8Ytpj024227 for tcpm-archive@odin.ietf.org; Mon, 26 Apr 2004 04:34:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI1Vq-0005An-27 for tcpm-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 04:30:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02786 for ; Mon, 26 Apr 2004 04:30:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI1Vn-0004dg-7S for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 04:30:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI1Us-0004P7-00 for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 04:29:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI1Tu-0004BZ-00 for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 04:28:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI1PH-0003EE-Az; Mon, 26 Apr 2004 04:24:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI1L9-00029r-SQ for tcpm@optimus.ietf.org; Mon, 26 Apr 2004 04:19:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02073 for ; Mon, 26 Apr 2004 04:19:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI1L6-0002Jx-SG for tcpm@ietf.org; Mon, 26 Apr 2004 04:19:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI1KD-00028i-00 for tcpm@ietf.org; Mon, 26 Apr 2004 04:18:50 -0400 Received: from mail.enyo.de ([212.9.189.167]) by ietf-mx with esmtp (Exim 4.12) id 1BI1Ji-0001x8-00 for tcpm@ietf.org; Mon, 26 Apr 2004 04:18:18 -0400 Received: (debugging) helo=deneb ip=212.9.189.171 name=deneb.enyo.de Received: from deneb.enyo.de ([212.9.189.171] helo=deneb) by mail.enyo.de with esmtp id 1BI1Jf-0007ee-7Y; Mon, 26 Apr 2004 10:18:15 +0200 Received: from fw by deneb with local (Exim 4.32) id 1BI1Jf-0000ns-0f; Mon, 26 Apr 2004 10:18:15 +0200 To: "Randall Stewart (cisco)" Cc: Joe Touch , tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: <40885173.6090804@isi.edu> <40890DF2.1040700@cisco.com> From: Florian Weimer Date: Mon, 26 Apr 2004 10:18:14 +0200 In-Reply-To: <40890DF2.1040700@cisco.com> (Randall Stewart's message of "Fri, 23 Apr 2004 08:37:06 -0400") Message-ID: <87d65vcfuh.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 "Randall Stewart (cisco)" writes: > So are you recommending cookies (or what I would call V-tags).... instead > of the current draft proposals... If this is what the working group > wants I would be happy to work with the co-authors to redo the > document has such... Cookies/V-tags have the advantage that we can hope that we have to deploy a fix just *once*. If you tweak the TCP state machine to work around the two problems identified so far, this won't help against feature issues that might be discovered. Given the costs of a fix like this one, I'd rather prefer to be on the safe side. -- Current mail filters: many dial-up/DSL/cable modem hosts, and the following domains: atlas.cz, bigpond.com, di-ve.com, netscape.net, postino.it, tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon Apr 26 04:53:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04837 for ; Mon, 26 Apr 2004 04:53:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI1pa-0002tO-2w for tcpm-archive@odin.ietf.org; Mon, 26 Apr 2004 04:51:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3Q8pEVc011109 for tcpm-archive@odin.ietf.org; Mon, 26 Apr 2004 04:51:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI1nE-0002BE-PV for tcpm-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 04:48:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04311 for ; Mon, 26 Apr 2004 04:48:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI1nB-00010W-Lg for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 04:48:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI1mA-0000ma-00 for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 04:47:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI1l7-0000Sp-00 for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 04:46:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI1ib-0000gC-5U; Mon, 26 Apr 2004 04:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI1Yx-0005yA-Qq for tcpm@optimus.ietf.org; Mon, 26 Apr 2004 04:34:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03091 for ; Mon, 26 Apr 2004 04:34:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI1Yu-0005LJ-UN for tcpm@ietf.org; Mon, 26 Apr 2004 04:34:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI1Xw-00057q-00 for tcpm@ietf.org; Mon, 26 Apr 2004 04:33:01 -0400 Received: from ftp.netlab.nec.de ([195.37.70.21] helo=ftp.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1BI1XI-0004uo-00 for tcpm@ietf.org; Mon, 26 Apr 2004 04:32:20 -0400 Received: from netlab.nec.de (scout.netlab.nec.de [195.37.70.100]) by ftp.ccrle.nec.de (Postfix) with ESMTP id 07DE8F674; Mon, 26 Apr 2004 10:37:23 +0200 (CEST) Message-ID: <408CC914.2000709@netlab.nec.de> Date: Mon, 26 Apr 2004 10:32:20 +0200 From: Lars Eggert Organization: NEC Network Laboratories User-Agent: Mozilla Thunderbird 0.6b (Macintosh/20040425) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mallman@icir.org Cc: tcpm@ietf.org, Joseph Ishac Subject: Re: [tcpm] Re: draft-eggert-tcpm-tcp-abort-timeout-option-00.txt References: <20040425145005.699B91402F5@lawyers.icir.org> In-Reply-To: <20040425145005.699B91402F5@lawyers.icir.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050002040207020603070605" Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms050002040207020603070605 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mark Allman wrote: >>Also, I'm with Wes' note earlier on trying to consolidate this all >>into the SYN and SYN/ACK. > > > I just read the draft and my concern with this business of carrying the > ATO on the ACK has less to do with consistency or beauty, but rather > with the ACK of the SYN+ACK being unreliable. It is pretty easy to > construct a case whereby the two endpoints will be out of sync because > the ACK is lost. Joseph has also send a very detailed note about this. I'll take a stab at rewriting things for the -01 revision accordingly when I have a few cycles. Thanks, Lars -- Lars Eggert NEC Network Laboratories --------------ms050002040207020603070605 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ/zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNaMIICw6ADAgECAgMLU6IwDQYJKoZIhvcNAQEE BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTAz MTIxNTEyMzEyOFoXDTA0MTIxNDEyMzEyOFowgYQxDzANBgNVBAQTBkVnZ2VydDENMAsGA1UE KhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdn ZXJ0QG5ldGxhYi5uZWMuZGUxIjAgBgkqhkiG9w0BCQEWE2xhcnMuZWdnZXJ0QGdteC5uZXQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWps58Zq8Buu2DKDl9crbvzSo6zWsZ TkQLr5zOTqUMs/eU7Mcohv64O4IxWWYGLfYsjDRxUlmdHdJUbyTtUh2lH452DUDJByXidlLm RDgohG0AVwztedqy1+hE3VnCdpMhUGks+6ntrr3dKSxMgLM0AM1kPWsH9lWX6IOPdxOC30gM PiQ65zH9PR70befQLgFPKcAv0wP8210l05n8ekwYAcq2cm3/j+nuDu0HEh5pgsnY7cVELeNJ ODvr4IiE1t3c2w4+0Nc/WJrqGCMl+gZ8c+7FtzjoyDeEsCjNFDeA2ymNd+10O6kjwvPHlzPr 3rW73RDRPAjMJ49HXlueiuoNAgMBAAGjdzB1MCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwOQYDVR0RBDIwMIEZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5k ZYETbGFycy5lZ2dlcnRAZ214Lm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB AHgrv3SQFD4AS4lY4oKcI3iTHcclEHbYfg3UUb8zzCUsl+OJoz0nmebGmOL+tvNj5GvCrWnN H4LvVLh8ZBhFXms7eKJ1YiHgbKwTRK23P8Y5NDit5ico0ZjpFWeenUWj3ajEbN6n4K8dNp+C 0b2apnSrlFVWY6BucZFIYqQ1Lf91MIIDWjCCAsOgAwIBAgIDC1OiMA0GCSqGSIb3DQEBBAUA MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wMzEy MTUxMjMxMjhaFw0wNDEyMTQxMjMxMjhaMIGEMQ8wDQYDVQQEEwZFZ2dlcnQxDTALBgNVBCoT BExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2Vy dEBuZXRsYWIubmVjLmRlMSIwIAYJKoZIhvcNAQkBFhNsYXJzLmVnZ2VydEBnbXgubmV0MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1qbOfGavAbrtgyg5fXK2780qOs1rGU5E C6+czk6lDLP3lOzHKIb+uDuCMVlmBi32LIw0cVJZnR3SVG8k7VIdpR+Odg1AyQcl4nZS5kQ4 KIRtAFcM7XnastfoRN1ZwnaTIVBpLPup7a693SksTICzNADNZD1rB/ZVl+iDj3cTgt9IDD4k Oucx/T0e9G3n0C4BTynAL9MD/NtdJdOZ/HpMGAHKtnJt/4/p7g7tBxIeaYLJ2O3FRC3jSTg7 6+CIhNbd3NsOPtDXP1ia6hgjJfoGfHPuxbc46Mg3hLAozRQ3gNspjXftdDupI8Lzx5cz6961 u90Q0TwIzCePR15bnorqDQIDAQABo3cwdTAqBgUrZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVN eWZmQk5VYk5KSmNkWjJzMDkGA1UdEQQyMDCBGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGWB E2xhcnMuZWdnZXJ0QGdteC5uZXQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQB4 K790kBQ+AEuJWOKCnCN4kx3HJRB22H4N1FG/M8wlLJfjiaM9J5nmxpji/rbzY+Rrwq1pzR+C 71S4fGQYRV5rO3iidWIh4GysE0Sttz/GOTQ4reYnKNGY6RVnnp1Fo92oxGzep+CvHTafgtG9 mqZ0q5RVVmOgbnGRSGKkNS3/dTGCAzswggM3AgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwCQYFKw4DAhoFAKCCAacwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwNDI2MDgzMjIwWjAjBgkqhkiG 9w0BCQQxFgQUXSkEmYMZPgB9hsuFG2Q7FbZ524UwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECAwtTojB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwDQYJKoZIhvcNAQEBBQAEggEA TpgrxmLn6ae2w3khsvIQ7ys5Wc9PlBfpHYQT/wSNIOt6sNfMVuoDEzyz4ODzDZbE1VvbHDcz 1n7OGKukUGb1zzGu9Zl1tBtWWRtdIa7na/pshcDIcQp6dbDTCGaCqw04XoEayxQtsPcvvl+V quZJ4m2fa0O/U6yhxeX+yzqjmb5JiuKuoD/QMDWcnPqQB5ZwYxWWOYWmITeZpkoB8rhW7JqF /5E042aiSCGg7c9iUiekYLZJwX3F4NBn4H2M2t6ddqAsX/cC5aWe8wt83AKeR32HEXXcVDMs 97Eh9QURMGnFZg015jREvfAgt6MoCtHJUb+oNtgrCPNg9D0nqWnCmwAAAAAAAA== --------------ms050002040207020603070605-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon Apr 26 08:07:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13988 for ; Mon, 26 Apr 2004 08:07:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI4oz-0005MK-H4 for tcpm-archive@odin.ietf.org; Mon, 26 Apr 2004 08:02:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QC2nx6020595 for tcpm-archive@odin.ietf.org; Mon, 26 Apr 2004 08:02:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI4iQ-0004Bx-Mf for tcpm-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 07:56:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13523 for ; Mon, 26 Apr 2004 07:56:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI4iP-00025x-Nz for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 07:56:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI4hW-0001tq-00 for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 07:55:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI4gs-0001hW-00 for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 07:54:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI4cc-0003Qx-PZ; Mon, 26 Apr 2004 07:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI4ak-000310-8Y for tcpm@optimus.ietf.org; Mon, 26 Apr 2004 07:48:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13076 for ; Mon, 26 Apr 2004 07:48:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI4aj-0000LF-Ct for tcpm@ietf.org; Mon, 26 Apr 2004 07:48:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI4Zj-00005T-00 for tcpm@ietf.org; Mon, 26 Apr 2004 07:47:04 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BI4Yy-0007Se-00 for tcpm@ietf.org; Mon, 26 Apr 2004 07:46:16 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 26 Apr 2004 04:46:30 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i3QBjX0Q028704; Mon, 26 Apr 2004 04:45:33 -0700 (PDT) Received: from cisco.com (rtp-dial-1-65.cisco.com [10.83.97.65]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATJ59866; Mon, 26 Apr 2004 04:45:30 -0700 (PDT) Message-ID: <408CF617.4030205@cisco.com> Date: Mon, 26 Apr 2004 07:44:23 -0400 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Touch CC: Qiaobing Xie , Florian Weimer , tcpm@ietf.org Subject: Re: FW: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: <025E7DD4182874489CC2F61EE0FA19CE02885696@daebe004.americas.nokia.com> <4087B232.4050203@cisco.com> <4087DDE6.3020703@nokia.com> <4087E36F.7000502@cisco.com> <40885BAB.2070200@isi.edu> <87y8omrehb.fsf@deneb.enyo.de> <40897C4C.9020900@isi.edu> <40899421.5030105@motorola.com> <4089AC77.6090207@isi.edu> In-Reply-To: <4089AC77.6090207@isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Joe Touch wrote: >> >> >> If it can be sufficiently established that in the real world there >> are only a few app >> protocols (BGP as one of them) that are actually impacted by those >> vulnerabilities, it may >> make more sense to leave TCP alone and simply recommend those few >> apps to consider using >> SCTP which seems to be fairly robust against those attacks. >> >> regards, >> -Qiaobing > > > The routers in question are more likely (IMO) to support IPsec already > than to already have SCTP. Besides, as I noted, this is an IPsec issue > - you want to trust who you get a RST from. There are other good > reasons to want IPsec here, since there are other similar attacks that > you might want to protect. Cisco routers already support SCTP... I believe it would be almost a no-op for a Juniper router to pick up the KAME-SCTP code for there routers... not sure about the rest of the router vendors out there.. And I am sure that most router vendors are considering or have considered SCTP for BGP... but like anything there would always be a transition time when moving to a "new" solution.. this can be a bit hap-hazard to deal with so if such a thing were to occur it would not be anytime soon :-o R > > > I.e., BGP is infrastructure. Secure it. (IMO) > > Joe -- Randall R. Stewart ITD - Transport Technologies 815-477-2127(o) or 815-342-5222(c) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon Apr 26 08:21:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14642 for ; Mon, 26 Apr 2004 08:21:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI52T-0000Jn-96 for tcpm-archive@odin.ietf.org; Mon, 26 Apr 2004 08:16:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QCGjJp001217 for tcpm-archive@odin.ietf.org; Mon, 26 Apr 2004 08:16:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI4z5-0007nr-9v for tcpm-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 08:13:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14236 for ; Mon, 26 Apr 2004 08:13:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI4z4-0005dt-7v for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 08:13:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI4yB-0005QU-00 for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 08:12:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI4xY-0005CD-00 for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 08:11:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI4u2-0006yR-2a; Mon, 26 Apr 2004 08:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI4o9-0005Ex-Te for tcpm@optimus.ietf.org; Mon, 26 Apr 2004 08:01:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13735 for ; Mon, 26 Apr 2004 08:01:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI4o9-0003Ig-0S for tcpm@ietf.org; Mon, 26 Apr 2004 08:01:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI4nD-00036u-00 for tcpm@ietf.org; Mon, 26 Apr 2004 08:01:00 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BI4mT-0002j5-00 for tcpm@ietf.org; Mon, 26 Apr 2004 08:00:13 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 26 Apr 2004 04:12:24 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3QBxeW9029736; Mon, 26 Apr 2004 04:59:40 -0700 (PDT) Received: from cisco.com (rtp-dial-1-65.cisco.com [10.83.97.65]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATJ60313; Mon, 26 Apr 2004 04:59:37 -0700 (PDT) Message-ID: <408CF966.8070607@cisco.com> Date: Mon, 26 Apr 2004 07:58:30 -0400 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Florian Weimer CC: Joe Touch , tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: <40885173.6090804@isi.edu> <40890DF2.1040700@cisco.com> <87d65vcfuh.fsf@deneb.enyo.de> In-Reply-To: <87d65vcfuh.fsf@deneb.enyo.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Florian Weimer wrote: >"Randall Stewart (cisco)" writes: > > > >>So are you recommending cookies (or what I would call V-tags).... instead >>of the current draft proposals... If this is what the working group >>wants I would be happy to work with the co-authors to redo the >>document has such... >> >> > >Cookies/V-tags have the advantage that we can hope that we have to >deploy a fix just *once*. If you tweak the TCP state machine to work >around the two problems identified so far, this won't help against >feature issues that might be discovered. > >Given the costs of a fix like this one, I'd rather prefer to be on the >safe side. > > > Florian: I have always liked the V-tag mechanism .. but that is not surprising seeing my involvement with SCTP :-D .. If the WG feels this is a better way to go, then thats fine.. However it will require a larger fix then just the few minor tweaks the current draft proposes.. R -- Randall R. Stewart ITD - Transport Technologies 815-477-2127(o) or 815-342-5222(c) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon Apr 26 08:28:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14923 for ; Mon, 26 Apr 2004 08:28:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI57a-00012z-2p for tcpm-archive@odin.ietf.org; Mon, 26 Apr 2004 08:22:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QCM2oo004021 for tcpm-archive@odin.ietf.org; Mon, 26 Apr 2004 08:22:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI52l-0000OJ-7P for tcpm-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 08:17:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14464 for ; Mon, 26 Apr 2004 08:17:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI52k-0006UY-AM for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 08:17:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI51q-0006Hn-00 for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 08:16:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI51P-00064p-00 for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 08:15:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI4uz-0007AV-AM; Mon, 26 Apr 2004 08:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI4r0-00060r-RH for tcpm@optimus.ietf.org; Mon, 26 Apr 2004 08:04:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13818 for ; Mon, 26 Apr 2004 08:04:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI4qz-0003wb-Tk for tcpm@ietf.org; Mon, 26 Apr 2004 08:04:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI4q0-0003ig-00 for tcpm@ietf.org; Mon, 26 Apr 2004 08:03:53 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BI4p1-0003KG-00 for tcpm@ietf.org; Mon, 26 Apr 2004 08:02:51 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3QC2BSu001942; Mon, 26 Apr 2004 05:02:11 -0700 (PDT) Received: from cisco.com (rtp-dial-1-65.cisco.com [10.83.97.65]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATJ60436; Mon, 26 Apr 2004 05:02:08 -0700 (PDT) Message-ID: <408CF9FD.6090009@cisco.com> Date: Mon, 26 Apr 2004 08:01:01 -0400 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Shepard CC: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Tim: Good point on the ISN issue... (i.e. how do I remember it when I reboot)... Your idea of ignoring RST's might work.. but what about SYN's .. do you still want to do as the draft recommends? If so, the ACK would illicit a RST... which you would then ignore.... Hmm.. R Tim Shepard wrote: >>This first sequence number information can be used to form part of the >>challenge-response; if the sender has sent an RST packet whose >>sequence number lies in the window, but it is not the next expected >>packet, the ack sent back by the receiver can be an indicator for the >>RST sender to pass the first sequence number in a subsequent packet >>(also containing a confirming RST flag. 'I told you to close. I'm >>telling you to close again. And here's a reminder of when we first >>spoke and agreed to open. It's a random number we both know.'.) >> >> > >If I'm sending you a RST because I rebooted and lost all state and >don't have any state for the TCP connection that you apparently have >becasue you are sending me packets, how am I supposed to remember what >the initial sequence number was? > > > > >Here's an idea (just thinkint out loud here) for solving the BGP problem: > >Ignore RSTs and just let keep alive failures and timers take care of >tearing down old connections. > >(and continuing to think out loud here....) > >Joe Touch recently suggested that IPsec/ESP with Null encryption and >authentication would effectively put in place a cookie mechanism (the >SPI being the cookie) which would be sufficient to solve these >probelms. But that just pushes the problem of handling a TCP RST to >figuring out how to "RST" a IPsec SA. And my understanding of that >problem (which is based on recent discussion in HIP WG) is that when a >packet shows up with an unknown SPI, that you might have a mechanism >that sends back an advisory "unknown SPI" notification, but that when >you receive an "unknown SPI" notification, there's not much you can do >with it because it could be someone spoofing you. > >So it seems just hacking your TCP implementation to ignore RSTs >might give you the same robustness that you'd get from >null-encryption, null-authentication IPsec ESP. > > -Tim Shepard > shep@alum.mit.edu > >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www1.ietf.org/mailman/listinfo/tcpm > > > -- Randall R. Stewart ITD - Transport Technologies 815-477-2127(o) or 815-342-5222(c) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon Apr 26 12:55:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02161 for ; Mon, 26 Apr 2004 12:55:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI99T-0000ZC-PJ for tcpm-archive@odin.ietf.org; Mon, 26 Apr 2004 12:40:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QGeFQ3002178 for tcpm-archive@odin.ietf.org; Mon, 26 Apr 2004 12:40:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI94O-0006nx-Gl for tcpm-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 12:35:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01083 for ; Mon, 26 Apr 2004 12:34:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI94M-0003e2-Sr for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 12:34:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI93O-0003Zq-00 for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 12:33:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI92O-0003Vv-00 for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 12:32:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI8tk-0002jx-IL; Mon, 26 Apr 2004 12:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH0TK-0000G6-4K for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 09:12:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04840 for ; Fri, 23 Apr 2004 09:11:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH0TI-000150-HL for tcpm@ietf.org; Fri, 23 Apr 2004 09:12:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH0SG-0000j7-00 for tcpm@ietf.org; Fri, 23 Apr 2004 09:10:57 -0400 Received: from dns.eng.auburn.edu ([131.204.10.13] helo=Eng.Auburn.EDU) by ietf-mx with esmtp (Exim 4.12) id 1BH0RJ-0000Pt-00 for tcpm@ietf.org; Fri, 23 Apr 2004 09:09:57 -0400 Received: from chadia.eng.auburn.edu (IDENT:31366@chadia.eng.auburn.edu [131.204.19.11]) by Eng.Auburn.EDU (8.12.10/8.12.10) with ESMTP id i3ND9nsK022710; Fri, 23 Apr 2004 08:09:49 -0500 (CDT) Received: from localhost (biazsaa@localhost) by chadia.eng.auburn.edu (8.10.2+Sun/8.6.4) with ESMTP id i3ND9ln07326; Fri, 23 Apr 2004 08:09:47 -0500 (CDT) X-Authentication-Warning: chadia.eng.auburn.edu: biazsaa owned process doing -bs Date: Fri, 23 Apr 2004 08:09:47 -0500 (CDT) From: Saad Biaz To: Michael Welzl cc: "Fu Cheng Peng, Franklin" , , In-Reply-To: <1082718532.4088f94444d8f@web-mail1.uibk.ac.at> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [tcpm] RE: [e2e] Open the floodgate Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Fri, 23 Apr 2004, Michael Welzl wrote: > Still, my question remains: why don't we have these separate > checksums as a TCP option? It strikes me as a rather simple > method for links where erroneous data are actually handed > over, and I believe that it's about time we transferred these > things from the world of research into the IETF. When you have erroneous packets (for whatever reaso other than congestion), who will inform about that? Maybe the addresses themselves are erroneous. Besides, some packets just get completely junked ... Special headers will not solve the problem. ---------------------------------------------------------------------- Saad Biaz, Ph.D., Assistant Prof. Voice: (334) 844 6307 114 Dunstan Hall Auburn University Fax : (334) 844 6329 Auburn, AL 36849-5347, USA http://www.eng.auburn.edu/~sbiaz ---------------------------------------------------------------------- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon Apr 26 12:55:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02197 for ; Mon, 26 Apr 2004 12:55:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI99Y-0000Zv-PX for tcpm-archive@odin.ietf.org; Mon, 26 Apr 2004 12:40:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QGeKuO002219 for tcpm-archive@odin.ietf.org; Mon, 26 Apr 2004 12:40:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI94T-0006pE-Bc for tcpm-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 12:35:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01104 for ; Mon, 26 Apr 2004 12:35:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI94R-0003ej-Ra for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 12:35:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI93Z-0003bI-00 for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 12:34:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI92o-0003Xt-00 for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 12:33:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI8tk-0002k7-PR; Mon, 26 Apr 2004 12:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH0yQ-0001Yg-Io for tcpm@optimus.ietf.org; Fri, 23 Apr 2004 09:44:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07547 for ; Fri, 23 Apr 2004 09:44:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH0yO-0002Re-Kd for tcpm@ietf.org; Fri, 23 Apr 2004 09:44:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH0xI-00029W-00 for tcpm@ietf.org; Fri, 23 Apr 2004 09:43:01 -0400 Received: from mbox1.ntu.edu.sg ([155.69.5.171]) by ietf-mx with esmtp (Exim 4.12) id 1BH0wP-0001eo-00 for tcpm@ietf.org; Fri, 23 Apr 2004 09:42:05 -0400 Received: from EXCHANGE21.staff.main.ntu.edu.sg ([155.69.5.79]) by mbox1.ntu.edu.sg with Microsoft SMTPSVC(6.0.3790.0); Fri, 23 Apr 2004 21:41:28 +0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Fri, 23 Apr 2004 21:41:18 +0800 Message-ID: <7CD06E15ADF4104A9F2E4DC2DE678F895444B9@EXCHANGE21.staff.main.ntu.edu.sg> Thread-Topic: [e2e] Open the floodgate Thread-Index: AcQpNEcS3/qYjf9uTMuP2McatEtOQAAAzCIQ From: "Fu Cheng Peng, Franklin" To: , Cc: "Saad Biaz" , "Michael Welzl" X-OriginalArrivalTime: 23 Apr 2004 13:41:28.0172 (UTC) FILETIME=[ADA9F2C0:01C42938] Content-Transfer-Encoding: quoted-printable Subject: [tcpm] RE: [e2e] Open the floodgate Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable =20 >=20 > On Fri, 23 Apr 2004, Michael Welzl wrote: >=20 > > Still, my question remains: why don't we have these=20 > separate checksums=20 > > as a TCP option? It strikes me as a rather simple method for links=20 > > where erroneous data are actually handed over, and I=20 > believe that it's=20 > > about time we transferred these things from the world of=20 > research into=20 > > the IETF. >=20 > When you have erroneous packets (for whatever reaso other=20 > than congestion), who will inform about that? Maybe the=20 > addresses themselves are erroneous. Besides, some packets=20 > just get completely junked ... Special headers will not solve=20 > the problem. Another reason may be due to deployability issue, if you add checksum in TCP options, you have to modify both sending and receiving TCP stack. Is it? That is not easy to deploy in real network. =20 -Franlkin =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr. Fu Cheng Peng, Franklin Asst Professor=20 School of Computer Engineering Nanyang Technological University, Singapore 639798 Tel: (65) 6790-4287 Fax: (65) 6792-6559=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon Apr 26 12:55:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02215 for ; Mon, 26 Apr 2004 12:55:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI99Z-0000aM-Av for tcpm-archive@odin.ietf.org; Mon, 26 Apr 2004 12:40:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QGeLUi002245 for tcpm-archive@odin.ietf.org; Mon, 26 Apr 2004 12:40:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI94W-0006pV-29 for tcpm-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 12:35:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01118 for ; Mon, 26 Apr 2004 12:35:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI94U-0003fC-KV for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 12:35:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI93e-0003bp-00 for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 12:34:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI93H-0003Y5-00 for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 12:33:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI8tl-0002kV-34; Mon, 26 Apr 2004 12:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHJgU-00079Z-8U for tcpm@optimus.ietf.org; Sat, 24 Apr 2004 05:42:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04824 for ; Sat, 24 Apr 2004 05:42:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHJgQ-00014u-LQ for tcpm@ietf.org; Sat, 24 Apr 2004 05:42:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHJfV-0000pd-00 for tcpm@ietf.org; Sat, 24 Apr 2004 05:41:53 -0400 Received: from 217-ip-163.nccn.net ([209.79.217.163] helo=gw.catspoiler.org) by ietf-mx with esmtp (Exim 4.12) id 1BHJev-0000Z4-00 for tcpm@ietf.org; Sat, 24 Apr 2004 05:41:17 -0400 Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id i3O9eX7E053356; Sat, 24 Apr 2004 02:40:37 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200404240940.i3O9eX7E053356@gw.catspoiler.org> Date: Sat, 24 Apr 2004 02:40:33 -0700 (PDT) From: Don Lewis Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt To: rrs@cisco.com cc: tcpm@ietf.org In-Reply-To: <4086A550.30003@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On 21 Apr, Randall Stewart (cisco) wrote: > Hi all: > > Don Lewis from FreeBSD has raised this point > to me privately.. and I thought it worth sharing... > " > > From what I see here: > > I am concerned that step C will not solve the compatibility problem. The > FreeBSD host is sending a FIN to close an established connection, and > the peer host adding the window size advertised in the FIN packet to the > sequence number acknowledged in the FIN packet, and using the sum as the > sequence number for the RST packet, which puts the sequence number at > the end of the receive window. > > " > > Don: > > I am still a bit fuzzy on this scenario... could you do something like: > > E-A E-Z > --------------FIN(ack=X)----------------------------------> > <----------------------------RST(ack=Y)----------------- > > and spell this out for me. It turns out that the problem mentioned in the FreeBSD archives is a rather special case. The traffic captured in the tcpdump trace is between a web server and a load balancing device that sits between the web server and its clients. At the end of the server's response to the client, the server sends a FIN packet to close down the connection. The load balancer is detecting the FIN packet, and immediately sending a RST response to the web server to cause the web server to immediately tear down the connection state in order to free up resources on the web server as quickly as possible, without having the web server wait for an ACK from the possibly quite distant client. The quirk is that the RST packet constructed by the load balancer does not use as its sequence number the last acknowledged sequence number that it extracted from the FIN packet. Instead it appears to add the window size (less one?) advertised by the FIN packet to the last acknowledged sequence number in the FIN packet to get the value of the sequence number in the RST packet. I would assume that the load balancing device is forwarding the FIN packet to the client, and that it is handling any necessary retransmissions. I suspect that step C in the solution to the RST vulnerability mentioned in draft-ietf-tcpm-tcpsecure-00 would not help in this case, since the load balancing device appears to totally ignore retransmissions of the FIN packet by the web server if the web server drops the initial RST packet because of strict sequence number checking. The fix currently proposed for the the FreeBSD stack is to enforce the exact sequence match check (step B in draft-ietf-tcpm-tcpsecure-00) for ESTABLISHED connections, but use the more permissive RFC 793 check for connections in other states. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon Apr 26 14:33:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08634 for ; Mon, 26 Apr 2004 14:33:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIAmp-0003ra-Sm for tcpm-archive@odin.ietf.org; Mon, 26 Apr 2004 14:25:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QIOxdD014850 for tcpm-archive@odin.ietf.org; Mon, 26 Apr 2004 14:24:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIAht-000242-0c for tcpm-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 14:19:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07135 for ; Mon, 26 Apr 2004 14:19:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIAhq-0003vc-DT for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 14:19:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIAev-0003MX-00 for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 14:16:51 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIAc2-0002rx-00 for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 14:13:50 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIALs-0006XU-3P for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 13:57:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIAB7-0001UP-SJ; Mon, 26 Apr 2004 13:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIA0V-0003OC-DE for tcpm@optimus.ietf.org; Mon, 26 Apr 2004 13:35:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04675 for ; Mon, 26 Apr 2004 13:35:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIA0T-0000Xe-9z for tcpm@ietf.org; Mon, 26 Apr 2004 13:35:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI9zT-0000Uy-00 for tcpm@ietf.org; Mon, 26 Apr 2004 13:34:00 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BI9yY-0000SY-00 for tcpm@ietf.org; Mon, 26 Apr 2004 13:33:02 -0400 Received: from isi.edu (116.sub-69-83-56.myvzw.com [69.83.56.116]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3QHWYN07404; Mon, 26 Apr 2004 10:32:34 -0700 (PDT) Message-ID: <408D47AD.7090508@isi.edu> Date: Mon, 26 Apr 2004 10:32:29 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Randall Stewart (cisco)" CC: Qiaobing Xie , Florian Weimer , tcpm@ietf.org Subject: Re: FW: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: <025E7DD4182874489CC2F61EE0FA19CE02885696@daebe004.americas.nokia.com> <4087B232.4050203@cisco.com> <4087DDE6.3020703@nokia.com> <4087E36F.7000502@cisco.com> <40885BAB.2070200@isi.edu> <87y8omrehb.fsf@deneb.enyo.de> <40897C4C.9020900@isi.edu> <40899421.5030105@motorola.com> <4089AC77.6090207@isi.edu> <408CF617.4030205@cisco.com> In-Reply-To: <408CF617.4030205@cisco.com> X-Enigmail-Version: 0.83.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig64FEAED3B83D82E611B9B986" X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig64FEAED3B83D82E611B9B986 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Randall Stewart (cisco) wrote: > Joe Touch wrote: > >>> >>> >>> If it can be sufficiently established that in the real world there >>> are only a few app >>> protocols (BGP as one of them) that are actually impacted by those >>> vulnerabilities, it may >>> make more sense to leave TCP alone and simply recommend those few >>> apps to consider using >>> SCTP which seems to be fairly robust against those attacks. >>> >>> regards, >>> -Qiaobing >> >> >> >> The routers in question are more likely (IMO) to support IPsec already >> than to already have SCTP. Besides, as I noted, this is an IPsec issue >> - you want to trust who you get a RST from. There are other good >> reasons to want IPsec here, since there are other similar attacks that >> you might want to protect. > > > Cisco routers already support SCTP... I believe it would be almost > a no-op for a Juniper router to pick up the KAME-SCTP code for > there routers... not sure about the rest of the router vendors out there.. > > And I am sure that most router vendors are considering or have considered > SCTP for BGP... but like anything there would always be a transition > time when moving to a "new" solution.. this can be a bit hap-hazard to > deal with so if such a thing were to occur it would not be anytime soon :-o Any transition - use of IPsec, a new TCP, porting SCTP - involves a transition. I am frankly surprised that the router vendors are so eager right now to consider a mod to TCP to fix this, given our collective experience with the complexity of TCP mods. Joe > > R > >> >> >> I.e., BGP is infrastructure. Secure it. (IMO) >> >> Joe --------------enig64FEAED3B83D82E611B9B986 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAjUeuE5f5cImnZrsRAscXAKDE2wyIDKff6b89hnrgMG07elsUkgCg6LhO i2U0U4BOsfSwKXDDqogdbSQ= =X4J6 -----END PGP SIGNATURE----- --------------enig64FEAED3B83D82E611B9B986-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon Apr 26 18:33:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00470 for ; Mon, 26 Apr 2004 18:33:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEZz-0004Sp-8R for tcpm-archive@odin.ietf.org; Mon, 26 Apr 2004 18:27:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QMRxZF017153 for tcpm-archive@odin.ietf.org; Mon, 26 Apr 2004 18:27:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEQ0-0002HR-MI for tcpm-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 18:17:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29207 for ; Mon, 26 Apr 2004 18:17:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIEPx-0001x6-Qk for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 18:17:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIEP7-0001qO-00 for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 18:16:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIEO8-0001jZ-00 for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 18:15:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEFh-0004xv-7V; Mon, 26 Apr 2004 18:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEAI-0001M7-3g for tcpm@optimus.ietf.org; Mon, 26 Apr 2004 18:01:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27060 for ; Mon, 26 Apr 2004 18:01:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIEAF-0000hr-D1 for tcpm@ietf.org; Mon, 26 Apr 2004 18:01:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIE9O-0000cm-00 for tcpm@ietf.org; Mon, 26 Apr 2004 18:00:31 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BIE8a-0000TR-00 for tcpm@ietf.org; Mon, 26 Apr 2004 17:59:40 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 26 Apr 2004 14:10:44 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3QLx9W9013062; Mon, 26 Apr 2004 14:59:09 -0700 (PDT) Received: from mdalal-u10.cisco.com (mdalal-u10.cisco.com [128.107.162.178]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASL34901; Mon, 26 Apr 2004 14:58:22 -0700 (PDT) Date: Mon, 26 Apr 2004 14:59:08 -0700 (PDT) From: Mitesh Dalal To: Don Lewis cc: rrs@cisco.com, tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt In-Reply-To: <200404240940.i3O9eX7E053356@gw.catspoiler.org> Message-ID: References: <200404240940.i3O9eX7E053356@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 On Sat, 24 Apr 2004, Don Lewis wrote: > On 21 Apr, Randall Stewart (cisco) wrote: > > Hi all: > > > > Don Lewis from FreeBSD has raised this point > > to me privately.. and I thought it worth sharing... > > " > > > > From what I see here: > > > > I am concerned that step C will not solve the compatibility problem. The > > FreeBSD host is sending a FIN to close an established connection, and > > the peer host adding the window size advertised in the FIN packet to the > > sequence number acknowledged in the FIN packet, and using the sum as the > > sequence number for the RST packet, which puts the sequence number at > > the end of the receive window. > > > > " > > > > Don: > > > > I am still a bit fuzzy on this scenario... could you do something like: > > > > E-A E-Z > > --------------FIN(ack=X)----------------------------------> > > <----------------------------RST(ack=Y)----------------- > > > > and spell this out for me. > > It turns out that the problem mentioned in the FreeBSD archives is a > rather special case. The traffic captured in the tcpdump trace is > between a web server and a load balancing device that sits between the > web server and its clients. > > At the end of the server's response to the client, the server sends a > FIN packet to close down the connection. The load balancer is detecting > the FIN packet, and immediately sending a RST response to the web server > to cause the web server to immediately tear down the connection state in > order to free up resources on the web server as quickly as possible, > without having the web server wait for an ACK from the possibly quite > distant client. The quirk is that the RST packet constructed by the > load balancer does not use as its sequence number the last acknowledged > sequence number that it extracted from the FIN packet. Instead it > appears to add the window size (less one?) advertised by the FIN packet > to the last acknowledged sequence number in the FIN packet to get the > value of the sequence number in the RST packet. > IMHO, this is rather unusual. I am not sure why the load balancer decides to compute the sequence number in such a special way. Since this is actually a deviation from the base spec, I am not sure how much consideration we need to give to this scenario. > I would assume that the load balancing device is forwarding the FIN > packet to the client, and that it is handling any necessary > retransmissions. > > I suspect that step C in the solution to the RST vulnerability mentioned > in draft-ietf-tcpm-tcpsecure-00 would not help in this case, since the since we have a load balancer in picture, I hypothesize that most connections will be short lived and hence do not need to worry about the current solution. But if we do decide to go down this road and the servers in question do want the fix, maybe the load balancers could also be expected to upgrade to this scenario ? > load balancing device appears to totally ignore retransmissions of the > FIN packet by the web server if the web server drops the initial RST > packet because of strict sequence number checking. this does not sound right. Without our changes, what if the first RST from the load balancer to the server is lost in the network ? How does the server recover ? > The fix currently proposed for the the FreeBSD stack is to enforce the > exact sequence match check (step B in draft-ietf-tcpm-tcpsecure-00) for > ESTABLISHED connections, but use the more permissive RFC 793 check for > connections in other states. > although when we wrote the draft the main intention was to protect connections in the ESTAB state. However, since the base spec interprets synchronized state to mean anything greater than ESTAB, we think that this should easily apply to other states too. Baring the above, are there any end-to-end scenarios that we might have overlooked ? Thanks Mitesh _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon Apr 26 19:09:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02196 for ; Mon, 26 Apr 2004 19:09:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIF3x-0000qi-1u for tcpm-archive@odin.ietf.org; Mon, 26 Apr 2004 18:58:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QMwvSh003260 for tcpm-archive@odin.ietf.org; Mon, 26 Apr 2004 18:58:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEzZ-0000Be-Ki for tcpm-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 18:54:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01560 for ; Mon, 26 Apr 2004 18:54:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIEzW-0004hq-FY for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 18:54:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIEyj-0004dq-00 for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 18:53:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIExy-0004Yw-00 for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 18:52:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEsP-0007fq-Q6; Mon, 26 Apr 2004 18:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIEl4-0006mR-3Z for tcpm@optimus.ietf.org; Mon, 26 Apr 2004 18:39:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00689 for ; Mon, 26 Apr 2004 18:39:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIEl1-0003Ju-1P for tcpm@ietf.org; Mon, 26 Apr 2004 18:39:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIEk1-0003Fq-00 for tcpm@ietf.org; Mon, 26 Apr 2004 18:38:22 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BIEjI-00039B-00 for tcpm@ietf.org; Mon, 26 Apr 2004 18:37:36 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 26 Apr 2004 14:49:40 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3QMapW9007319; Mon, 26 Apr 2004 15:36:51 -0700 (PDT) Received: from cisco.com (ananth-u5.cisco.com [128.107.162.225]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATK29413; Mon, 26 Apr 2004 15:36:50 -0700 (PDT) Message-ID: <408D8F02.7F042EAF@cisco.com> Date: Mon, 26 Apr 2004 15:36:50 -0700 From: Anantha Ramaiah Organization: Cisco Systems X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Mitesh Dalal CC: Don Lewis , rrs@cisco.com, tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: <200404240940.i3O9eX7E053356@gw.catspoiler.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Just wanted throw in my few cents: In the load balancer case, like Mitesh pointed out the - RST could get lost. - in case the RST makes it, the server ( with the fix) should send an ACK back to solicit the "acceptable RST". the load balancer should not drop the ACK, since by originally sending RST it means that it has *released* the control block resources and should act according to the RFC by sending RST for future packets targetted towards this control block (TCB or PCB). If this is not being done, then the host restart cases,dropped RST cases wouldn't work. Probably it was noticed because the load balancer never ran into such situation before. Also regarding the draft... - We wanted carefully choose the wording for the current draft to reflect the base spec. This is the reason we wanted to keep with the > ESTAB terminology. I don't think there should be any corner cases which we could have missed. I do agree that the main cause of concern is tearing down the connection in ESTAB state. For other states we could have choosen to do the older way but it is always better to to maintain the same semantics to avoid adding more arcs to the state diagram. -Anantha Mitesh Dalal wrote: > > On Sat, 24 Apr 2004, Don Lewis wrote: > > > On 21 Apr, Randall Stewart (cisco) wrote: > > > Hi all: > > > > > > Don Lewis from FreeBSD has raised this point > > > to me privately.. and I thought it worth sharing... > > > " > > > > > > From what I see here: > > > > > > I am concerned that step C will not solve the compatibility problem. The > > > FreeBSD host is sending a FIN to close an established connection, and > > > the peer host adding the window size advertised in the FIN packet to the > > > sequence number acknowledged in the FIN packet, and using the sum as the > > > sequence number for the RST packet, which puts the sequence number at > > > the end of the receive window. > > > > > > " > > > > > > Don: > > > > > > I am still a bit fuzzy on this scenario... could you do something like: > > > > > > E-A E-Z > > > --------------FIN(ack=X)----------------------------------> > > > <----------------------------RST(ack=Y)----------------- > > > > > > and spell this out for me. > > > > It turns out that the problem mentioned in the FreeBSD archives is a > > rather special case. The traffic captured in the tcpdump trace is > > between a web server and a load balancing device that sits between the > > web server and its clients. > > > > At the end of the server's response to the client, the server sends a > > FIN packet to close down the connection. The load balancer is detecting > > the FIN packet, and immediately sending a RST response to the web server > > to cause the web server to immediately tear down the connection state in > > order to free up resources on the web server as quickly as possible, > > without having the web server wait for an ACK from the possibly quite > > distant client. The quirk is that the RST packet constructed by the > > load balancer does not use as its sequence number the last acknowledged > > sequence number that it extracted from the FIN packet. Instead it > > appears to add the window size (less one?) advertised by the FIN packet > > to the last acknowledged sequence number in the FIN packet to get the > > value of the sequence number in the RST packet. > > > > IMHO, this is rather unusual. I am not sure why the load balancer > decides to compute the sequence number in such a special way. Since > this is actually a deviation from the base spec, I am not sure how > much consideration we need to give to this scenario. > > > I would assume that the load balancing device is forwarding the FIN > > packet to the client, and that it is handling any necessary > > retransmissions. > > > > I suspect that step C in the solution to the RST vulnerability mentioned > > in draft-ietf-tcpm-tcpsecure-00 would not help in this case, since the > > since we have a load balancer in picture, I hypothesize that most > connections will be short lived and hence do not need to worry about > the current solution. But if we do decide to go down this road and > the servers in question do want the fix, maybe the load balancers > could also be expected to upgrade to this scenario ? > > > load balancing device appears to totally ignore retransmissions of the > > FIN packet by the web server if the web server drops the initial RST > > packet because of strict sequence number checking. > > this does not sound right. Without our changes, what if the first RST from > the load balancer to the server is lost in the network ? How does the > server recover ? > > > The fix currently proposed for the the FreeBSD stack is to enforce the > > exact sequence match check (step B in draft-ietf-tcpm-tcpsecure-00) for > > ESTABLISHED connections, but use the more permissive RFC 793 check for > > connections in other states. > > > > although when we wrote the draft the main intention was to protect > connections in the ESTAB state. However, since the base spec interprets > synchronized state to mean anything greater than ESTAB, we think that > this should easily apply to other states too. Baring the above, > are there any end-to-end scenarios that we might have overlooked ? > > Thanks > Mitesh > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon Apr 26 21:28:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08568 for ; Mon, 26 Apr 2004 21:28:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIHNm-0003F8-Fl for tcpm-archive@odin.ietf.org; Mon, 26 Apr 2004 21:27:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R1RYU2012461 for tcpm-archive@odin.ietf.org; Mon, 26 Apr 2004 21:27:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIHK2-0002nk-7Z for tcpm-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 21:23:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08293 for ; Mon, 26 Apr 2004 21:23:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIHJz-0002NZ-Hq for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 21:23:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIHJ6-0002GZ-00 for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 21:22:45 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIHI1-00029S-00 for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 21:21:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIH9k-0001aD-G5; Mon, 26 Apr 2004 21:13:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIH8E-0001HI-Ug for tcpm@optimus.ietf.org; Mon, 26 Apr 2004 21:11:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07725 for ; Mon, 26 Apr 2004 21:11:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIH8C-00014o-8S for tcpm@ietf.org; Mon, 26 Apr 2004 21:11:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIH7H-0000yx-00 for tcpm@ietf.org; Mon, 26 Apr 2004 21:10:32 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1BIH6J-0000nP-00 for tcpm@ietf.org; Mon, 26 Apr 2004 21:09:32 -0400 Received: from jurassic.eng.sun.com ([129.146.88.31]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3R18sms018557; Mon, 26 Apr 2004 18:08:54 -0700 (PDT) Received: from sun.com (shield.SFBay.Sun.COM [129.144.60.49]) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i3R18sLB355216; Mon, 26 Apr 2004 18:08:54 -0700 (PDT) Message-ID: <408DB2A6.90307@sun.com> Date: Mon, 26 Apr 2004 18:08:54 -0700 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.6) Gecko/20040117 X-Accept-Language: en, zh-hk, zh-tw, zh-cn MIME-Version: 1.0 To: Mitesh Dalal CC: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: <200404240940.i3O9eX7E053356@gw.catspoiler.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mitesh Dalal wrote: > IMHO, this is rather unusual. I am not sure why the load balancer > decides to compute the sequence number in such a special way. Since > this is actually a deviation from the base spec, I am not sure how > much consideration we need to give to this scenario. I think most host TCP implementors will say that the above is not unusual at all. A host TCP stack talks to so many different kinds of devices that nearly everything can be wrong will probably go wrong. From a router TCP stack's point of view, the changes suggested in the draft may be acceptable. But I think most host TCP implementors will hesitate to implement that. -- K. Poon. kacheong.poon@sun.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon Apr 26 22:22:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11306 for ; Mon, 26 Apr 2004 22:22:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIIAn-0001PQ-OL for tcpm-archive@odin.ietf.org; Mon, 26 Apr 2004 22:18:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R2IDEn005411 for tcpm-archive@odin.ietf.org; Mon, 26 Apr 2004 22:18:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BII93-0001Ap-L5 for tcpm-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 22:16:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10918 for ; Mon, 26 Apr 2004 22:16:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BII90-0000bZ-HZ for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 22:16:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BII82-0000V8-00 for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 22:15:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BII77-0000PA-00 for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 22:14:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIHz0-0007r9-6Q; Mon, 26 Apr 2004 22:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIHuf-00071b-Dh for tcpm@optimus.ietf.org; Mon, 26 Apr 2004 22:01:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10209 for ; Mon, 26 Apr 2004 22:01:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIHuc-0006fU-DO for tcpm@ietf.org; Mon, 26 Apr 2004 22:01:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIHti-0006Yn-00 for tcpm@ietf.org; Mon, 26 Apr 2004 22:00:35 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BIHst-0006Mu-00 for tcpm@ietf.org; Mon, 26 Apr 2004 21:59:43 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i3R1wdBm018722; Mon, 26 Apr 2004 18:58:39 -0700 (PDT) (envelope-from pgoyette@juniper.net) Received: from pgoyette600 ([172.24.236.5]) by merlot.juniper.net (8.11.3/8.11.3) with SMTP id i3R1wdJ04486; Mon, 26 Apr 2004 18:58:39 -0700 (PDT) (envelope-from pgoyette@juniper.net) From: "Paul Goyette" To: "Kacheong Poon" , "Mitesh Dalal" Cc: Subject: RE: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt Date: Mon, 26 Apr 2004 18:58:36 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <408DB2A6.90307@sun.com> Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > ... But I think most host TCP implementors > will hesitate to implement that. Frankly, I'd be surprised if host TCP implementors made any changes whatsoever. That's why I like the proposed changes in Randall's draft. (Well, that and the fact that I had a small hand in helping him!) These changes impose no requirements at all on changes being made on the TCP peer unless the peer wants to be protected from the RST or SYN attack, or data injection. And that's probably not very likely, since most host TCPs won't engage in long-lived sessions that are painful to restart. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon Apr 26 22:41:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12345 for ; Mon, 26 Apr 2004 22:41:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIIOW-0002uL-Sq for tcpm-archive@odin.ietf.org; Mon, 26 Apr 2004 22:32:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R2WOPA011173 for tcpm-archive@odin.ietf.org; Mon, 26 Apr 2004 22:32:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIILr-0002Zl-GS for tcpm-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 22:29:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11944 for ; Mon, 26 Apr 2004 22:29:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIILo-0002NY-8f for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 22:29:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIIL3-0002Gs-00 for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 22:28:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIIKM-00029e-00 for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 22:28:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIIBZ-0001Uo-5B; Mon, 26 Apr 2004 22:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BII98-0001BG-0d for tcpm@optimus.ietf.org; Mon, 26 Apr 2004 22:16:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10925 for ; Mon, 26 Apr 2004 22:16:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BII94-0000c7-SC for tcpm@ietf.org; Mon, 26 Apr 2004 22:16:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BII8B-0000WK-00 for tcpm@ietf.org; Mon, 26 Apr 2004 22:15:32 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1BII7q-0000QP-00 for tcpm@ietf.org; Mon, 26 Apr 2004 22:15:10 -0400 Received: from jurassic.eng.sun.com ([129.146.87.130]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3R2Eems023712; Mon, 26 Apr 2004 19:14:40 -0700 (PDT) Received: from sun.com (shield.SFBay.Sun.COM [129.144.60.49]) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i3R2EeGl372726; Mon, 26 Apr 2004 19:14:40 -0700 (PDT) Message-ID: <408DC210.4090701@sun.com> Date: Mon, 26 Apr 2004 19:14:40 -0700 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.6) Gecko/20040117 X-Accept-Language: en, zh-hk, zh-tw, zh-cn MIME-Version: 1.0 To: Paul Goyette CC: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Goyette wrote: > Frankly, I'd be surprised if host TCP implementors made any changes > whatsoever. That's why I like the proposed changes in Randall's > draft. (Well, that and the fact that I had a small hand in helping > him!) These changes impose no requirements at all on changes being > made on the TCP peer unless the peer wants to be protected from the > RST or SYN attack, or data injection. And that's probably not very > likely, since most host TCPs won't engage in long-lived sessions > that are painful to restart. You expect the vast majority of TCP stacks out there will not care about this change and yet this change is proposed in tcpm as a "fix" to TCP? I'd suggest this draft to be removed as a WG doc. -- K. Poon. kacheong.poon@sun.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon Apr 26 22:52:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12879 for ; Mon, 26 Apr 2004 22:52:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIIZm-0004bz-VG for tcpm-archive@odin.ietf.org; Mon, 26 Apr 2004 22:44:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R2i2SY017723 for tcpm-archive@odin.ietf.org; Mon, 26 Apr 2004 22:44:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIIWM-0004Bh-WA for tcpm-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 22:40:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12259 for ; Mon, 26 Apr 2004 22:40:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIIWJ-0003Zd-Ng for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 22:40:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIIVQ-0003Se-00 for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 22:39:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIIUZ-0003MB-00 for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 22:38:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIIMH-0002fN-Kt; Mon, 26 Apr 2004 22:30:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIIIk-00022a-NX for tcpm@optimus.ietf.org; Mon, 26 Apr 2004 22:26:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11735 for ; Mon, 26 Apr 2004 22:26:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIIIh-0001zJ-Dt for tcpm@ietf.org; Mon, 26 Apr 2004 22:26:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIIHf-0001lV-00 for tcpm@ietf.org; Mon, 26 Apr 2004 22:25:20 -0400 Received: from mail4.microsoft.com ([131.107.3.122]) by ietf-mx with esmtp (Exim 4.12) id 1BIIFw-0001Tt-00 for tcpm@ietf.org; Mon, 26 Apr 2004 22:23:32 -0400 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 26 Apr 2004 19:23:02 -0700 Received: from 157.54.8.155 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 26 Apr 2004 19:23:07 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 26 Apr 2004 19:23:01 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 26 Apr 2004 19:22:51 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 26 Apr 2004 19:22:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt Date: Mon, 26 Apr 2004 19:22:45 -0700 Message-ID: Thread-Topic: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt Thread-Index: AcQr/V+KNbfmXpygQsmDnhELbIXT7wAACqEQ From: "Christian Huitema" To: "Paul Goyette" , "Kacheong Poon" , "Mitesh Dalal" Cc: X-OriginalArrivalTime: 27 Apr 2004 02:22:48.0533 (UTC) FILETIME=[88852050:01C42BFE] Content-Transfer-Encoding: quoted-printable Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > ... But I think most host TCP implementors > > will hesitate to implement that. >=20 > Frankly, I'd be surprised if host TCP implementors made any changes > whatsoever. That's why I like the proposed changes in Randall's > draft. (Well, that and the fact that I had a small hand in helping > him!) These changes impose no requirements at all on changes being > made on the TCP peer unless the peer wants to be protected from the > RST or SYN attack, or data injection. And that's probably not very > likely, since most host TCPs won't engage in long-lived sessions > that are painful to restart. You also have to consider that any change can backfire and break some application somewhere. You are trading one risk, a DOS attack that will sometimes succeed in breaking connections, against another, a change that will sometimes break existing applications. You want to be very careful for that kind of trade-off. The DOS attack requires 4 conditions: 1) The attack requires identification of two ends of a connection; 2) The attack is easier to conduct if the port numbers of both ends of a connection can be predicted; 3) Long duration sessions are more at risk that short connections; 4) The attack is amplified if the loss of a connection results in a change in application behavior. BGP is a bit unique because it meets all of these requirements. Very few other applications meet more than 2 of the 4. Hence the desire to not rush a solution that might backfire. -- Christian Huitema _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon Apr 26 23:45:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14944 for ; Mon, 26 Apr 2004 23:45:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIJVu-0002uo-RG for tcpm-archive@odin.ietf.org; Mon, 26 Apr 2004 23:44:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R3i6UX011199 for tcpm-archive@odin.ietf.org; Mon, 26 Apr 2004 23:44:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIJSR-0002Ze-Pa for tcpm-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 23:40:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14545 for ; Mon, 26 Apr 2004 23:40:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIJSP-0002tH-NB for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 23:40:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIJRD-0002ci-00 for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 23:39:16 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIJPU-0002Kb-01 for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 23:37:28 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIJCv-0005vk-1w for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 23:24:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIJ9Z-0000ZS-G6; Mon, 26 Apr 2004 23:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIJ85-0000KE-V1 for tcpm@optimus.ietf.org; Mon, 26 Apr 2004 23:19:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13917 for ; Mon, 26 Apr 2004 23:19:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIJ84-0000RX-2r for tcpm@ietf.org; Mon, 26 Apr 2004 23:19:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIJ7F-0000LH-00 for tcpm@ietf.org; Mon, 26 Apr 2004 23:18:37 -0400 Received: from dsl092-066-146.bos1.dsl.speakeasy.net ([66.92.66.146] helo=alva.home) by ietf-mx with esmtp (Exim 4.12) id 1BIJ6x-0000F4-00 for tcpm@ietf.org; Mon, 26 Apr 2004 23:18:20 -0400 Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1BIJ6U-0007KP-00 for ; Mon, 26 Apr 2004 23:17:50 -0400 From: Tim Shepard To: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt In-reply-to: Your message of Mon, 26 Apr 2004 19:22:45 -0700. Date: Mon, 26 Apr 2004 23:17:50 -0400 Message-Id: Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I think if we do have any change, it would not be a general change to TCP, but rather a special mode you could put a TCP into with a call to ioctl(,SO_TCP_RADIATION_HARDEN,) which would cause it to treat bare RSTs skeptically (and somehow handle the other two problems). At least for a while. Perhaps after some years of experience with this, we could later recommend that it be turned on by default. Those particular services that need to be secured sooner (like BGP connections) can turn it on explicitly if they lack some better way to secure the connection. (And now for some half-baked ideas....) The timestamp option seems useful here. The other end is constantly proving to you that has received a recent timestamp value from you (by sending it back to you). I'm not sure though if RSTs typically include a timestamp option if the packet that triggered the RST had a timestamp in it. If they do, then that's probably the right cookie we need. (If your TCP had gotten to ESTABLISHED with the timestamp options enabled, then the other end clearly supported the timestamp option before, and presumably they will still support the timestamp option if they should inadvertently reboot and lose state of this connection. So it seems reasonable to expect the other end to include a timestamp option in the RST.) But..... are the timestamps used in the timestamp option offset by some secret value (e.g. a good random number selected by a good secret hash of the IP addresses and port numbers involved)? Otherwise, the timestamps might be guessable by an attacker. -Tim Shepard shep@alum.mit.edu _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Apr 27 00:04:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15921 for ; Tue, 27 Apr 2004 00:04:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIJo2-0004lX-Cp for tcpm-archive@odin.ietf.org; Tue, 27 Apr 2004 00:02:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R42o7s018312 for tcpm-archive@odin.ietf.org; Tue, 27 Apr 2004 00:02:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIJnN-0004g0-3e for tcpm-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 00:02:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15364 for ; Tue, 27 Apr 2004 00:02:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIJnK-0005gD-LR for tcpm-web-archive@ietf.org; Tue, 27 Apr 2004 00:02:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIJks-0005Bb-00 for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 23:59:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIJk9-00054R-00 for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 23:58:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIJgT-0003hq-Sc; Mon, 26 Apr 2004 23:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIJaC-0003Nr-N0 for tcpm@optimus.ietf.org; Mon, 26 Apr 2004 23:48:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15019 for ; Mon, 26 Apr 2004 23:48:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIJaA-0003xZ-HN for tcpm@ietf.org; Mon, 26 Apr 2004 23:48:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIJZC-0003rJ-00 for tcpm@ietf.org; Mon, 26 Apr 2004 23:47:31 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BIJZ3-0003kx-00 for tcpm@ietf.org; Mon, 26 Apr 2004 23:47:21 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 26 Apr 2004 19:58:27 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3R3knW9020275; Mon, 26 Apr 2004 20:46:49 -0700 (PDT) Received: from irp-view8.cisco.com (irp-view8.cisco.com [171.70.65.145]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASL57841; Mon, 26 Apr 2004 20:46:02 -0700 (PDT) Date: Mon, 26 Apr 2004 20:46:48 -0700 (PDT) From: Mitesh Dalal To: Kacheong Poon cc: Paul Goyette , tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt In-Reply-To: <408DC210.4090701@sun.com> Message-ID: References: <408DC210.4090701@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Mon, 26 Apr 2004, Kacheong Poon wrote: > Paul Goyette wrote: > > > Frankly, I'd be surprised if host TCP implementors made any changes > > whatsoever. That's why I like the proposed changes in Randall's > > draft. (Well, that and the fact that I had a small hand in helping > > him!) These changes impose no requirements at all on changes being > > made on the TCP peer unless the peer wants to be protected from the > > RST or SYN attack, or data injection. And that's probably not very > > likely, since most host TCPs won't engage in long-lived sessions > > that are painful to restart. > > You expect the vast majority of TCP stacks out there will not > care about this change and yet this change is proposed in tcpm > as a "fix" to TCP? I'd suggest this draft to be removed as a WG > doc. if we decide to make the solution a standard, it does not necessarily mean that all tcp stack vendors out their have to run out and fix their stack. It IMHO, means that the engineering community and the IETF have made due diligence in studying the solution and that there is general consensus that yes, this is a vulnerability and yes we agree that this is likely the best solution given all considerations. If you are believe that you have a solution this is easier to implement, backward compatible, appears to be minimally disruptive, I am sure we would all like to hear it and review it. FWIW, I do consider your timestamp option as a valid proposition, but the very fact that you are banking on an "optional" option to fix this problem is speculative, because in this solution not only does the client need to upgrade but also the middlebox in order for them to not drop your RST and if your answer to this is that since its an option and it can be turned off later if we find issues then, its like saying that here is a solution that I think will work, but I am not confident enough and if you happen to find a problem, please turn it off and let the vulnerability open again. So please put forward scenarios to the WG to ponder that you think may not work. If you are successful in doing so, we would be more than glad to take back our proposal. thanks Mitesh _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Apr 27 00:12:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17149 for ; Tue, 27 Apr 2004 00:12:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIJsK-0005Xh-57 for tcpm-archive@odin.ietf.org; Tue, 27 Apr 2004 00:07:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R47GVK021301 for tcpm-archive@odin.ietf.org; Tue, 27 Apr 2004 00:07:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIJqN-0005B6-LI for tcpm-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 00:05:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16170 for ; Tue, 27 Apr 2004 00:05:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIJqL-0006Cg-Cg for tcpm-web-archive@ietf.org; Tue, 27 Apr 2004 00:05:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIJng-0005jG-00 for tcpm-web-archive@ietf.org; Tue, 27 Apr 2004 00:02:29 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIJkw-00054V-01 for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 23:59:39 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIJZG-0006JR-5f for tcpm-web-archive@ietf.org; Mon, 26 Apr 2004 23:47:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIJWm-00033G-QE; Mon, 26 Apr 2004 23:45:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIJSf-0002cK-EP for tcpm@optimus.ietf.org; Mon, 26 Apr 2004 23:40:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14587 for ; Mon, 26 Apr 2004 23:40:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIJSd-0002yh-7D for tcpm@ietf.org; Mon, 26 Apr 2004 23:40:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIJRO-0002f4-00 for tcpm@ietf.org; Mon, 26 Apr 2004 23:39:27 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIJPV-0002LP-02 for tcpm@ietf.org; Mon, 26 Apr 2004 23:37:29 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIJB7-0005tM-AZ for tcpm@ietf.org; Mon, 26 Apr 2004 23:22:37 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 26 Apr 2004 19:33:41 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3R3M3Su009672; Mon, 26 Apr 2004 20:22:03 -0700 (PDT) Received: from irp-view8.cisco.com (irp-view8.cisco.com [171.70.65.145]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASL57074; Mon, 26 Apr 2004 20:21:16 -0700 (PDT) Date: Mon, 26 Apr 2004 20:22:02 -0700 (PDT) From: Mitesh Dalal To: Kacheong Poon cc: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt In-Reply-To: <408DB2A6.90307@sun.com> Message-ID: References: <200404240940.i3O9eX7E053356@gw.catspoiler.org> <408DB2A6.90307@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Mon, 26 Apr 2004, Kacheong Poon wrote: > Mitesh Dalal wrote: > > > IMHO, this is rather unusual. I am not sure why the load balancer > > decides to compute the sequence number in such a special way. Since > > this is actually a deviation from the base spec, I am not sure how > > much consideration we need to give to this scenario. > > I think most host TCP implementors will say that the above is not > unusual at all. A host TCP stack talks to so many different kinds > of devices that nearly everything can be wrong will probably go wrong. > From a router TCP stack's point of view, the changes suggested in the > draft may be acceptable. But I think most host TCP implementors > will hesitate to implement that. > I went and looked at the freebsd thread that Don pointed in his earlier email. I do not see any reference to load balancers(Don, I hope I am looking at the right place, or is this that you personally tested ?) But a subsequent reply (by venkat) to that question points to a valid scenario where its possible to receive a RST with a sequence number which is much beyond the rcvnxt. Here again since the RST is resulting from the endhost but not from an intermediate system, our solution will still hold. thanks Mitesh _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Apr 27 00:12:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17166 for ; Tue, 27 Apr 2004 00:12:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIJss-0005o8-To for tcpm-archive@odin.ietf.org; Tue, 27 Apr 2004 00:07:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R47onr022320 for tcpm-archive@odin.ietf.org; Tue, 27 Apr 2004 00:07:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIJrF-0005Is-BA for tcpm-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 00:06:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16355 for ; Tue, 27 Apr 2004 00:06:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIJrD-0006Qe-2F for tcpm-web-archive@ietf.org; Tue, 27 Apr 2004 00:06:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIJpM-00060I-00 for tcpm-web-archive@ietf.org; Tue, 27 Apr 2004 00:04:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIJmT-0005VF-00 for tcpm-web-archive@ietf.org; Tue, 27 Apr 2004 00:01:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIJjN-00042j-PP; Mon, 26 Apr 2004 23:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIJg1-0003fU-TP for tcpm@optimus.ietf.org; Mon, 26 Apr 2004 23:54:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15160 for ; Mon, 26 Apr 2004 23:54:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIJfz-0004cg-NS for tcpm@ietf.org; Mon, 26 Apr 2004 23:54:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIJf3-0004WB-00 for tcpm@ietf.org; Mon, 26 Apr 2004 23:53:33 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BIJec-0004Oz-00 for tcpm@ietf.org; Mon, 26 Apr 2004 23:53:06 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 26 Apr 2004 20:53:35 -0700 Received: from ananth-u5.cisco.com (ananth-u5.cisco.com [128.107.162.225]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i3R3qVjP015055; Mon, 26 Apr 2004 20:52:31 -0700 (PDT) Date: Mon, 26 Apr 2004 20:52:31 -0700 (PDT) From: Anantha Ramaiah To: Kacheong Poon cc: Paul Goyette , tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt In-Reply-To: <408DC210.4090701@sun.com> Message-ID: References: <408DC210.4090701@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, 26 Apr 2004, Kacheong Poon wrote: > Paul Goyette wrote: > > > Frankly, I'd be surprised if host TCP implementors made any changes > > whatsoever. That's why I like the proposed changes in Randall's > > draft. (Well, that and the fact that I had a small hand in helping > > him!) These changes impose no requirements at all on changes being > > made on the TCP peer unless the peer wants to be protected from the > > RST or SYN attack, or data injection. And that's probably not very > > likely, since most host TCPs won't engage in long-lived sessions > > that are painful to restart. > > You expect the vast majority of TCP stacks out there will not > care about this change and yet this change is proposed in tcpm > as a "fix" to TCP? I'd suggest this draft to be removed as a WG > doc. Well, I guess the point Paul was trying to make is in terms of various TCP stacks adapting this solution once it is standardized. The philosophy is whoever implements this gets the additional security needed for applications riding over TCP. Suppose you have some RFC written, which talks about some eficient flow control or congestion control or window handling. It is not necessary that all stacks out there needs to pick it up and implement it. Wheover implements gets the benefit others not. Probably lot of people won't care if telnet is not buying this new proposal. Because there isn't much harm you will be causing resetting a telnet connection as opposed BGP or a VOIP control connection. Well, telling that "since vast majority of stacks out there wont care about this and remove this as WG doc" is analogous to "since vast majority of people cannot afford business class in flights", don't provide business class... :) -Anantha > > > -- > > K. Poon. > kacheong.poon@sun.com > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Apr 27 13:22:02 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14966 for ; Tue, 27 Apr 2004 13:22:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIWAC-0005sS-DU for tcpm-archive@odin.ietf.org; Tue, 27 Apr 2004 13:14:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RHEWiq022592 for tcpm-archive@odin.ietf.org; Tue, 27 Apr 2004 13:14:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIW2v-0003Is-8B for tcpm-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 13:07:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13124 for ; Tue, 27 Apr 2004 13:06:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIW2r-0005Tv-Ce for tcpm-web-archive@ietf.org; Tue, 27 Apr 2004 13:06:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIW06-00059j-00 for tcpm-web-archive@ietf.org; Tue, 27 Apr 2004 13:04:07 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIVzh-00055Y-00 for tcpm-web-archive@ietf.org; Tue, 27 Apr 2004 13:03:42 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIVzl-0005G6-Hy for tcpm-web-archive@ietf.org; Tue, 27 Apr 2004 13:03:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVpQ-0000nT-Ta; Tue, 27 Apr 2004 12:53:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVfn-0005eW-BB for tcpm@optimus.ietf.org; Tue, 27 Apr 2004 12:43:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11219 for ; Tue, 27 Apr 2004 12:43:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIVfj-0003L9-Lt for tcpm@ietf.org; Tue, 27 Apr 2004 12:43:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIVdJ-0002rV-00 for tcpm@ietf.org; Tue, 27 Apr 2004 12:40:34 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIVbj-0002a7-01 for tcpm@ietf.org; Tue, 27 Apr 2004 12:38:55 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIVPE-0004CM-Ss for tcpm@ietf.org; Tue, 27 Apr 2004 12:26:01 -0400 Received: from isi.edu (lsanca1-ar42-4-61-163-089.lsanca1.dsl-verizon.net [4.61.163.89]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3RGOxN00375; Tue, 27 Apr 2004 09:25:00 -0700 (PDT) Message-ID: <408E8961.9090806@isi.edu> Date: Tue, 27 Apr 2004 09:25:05 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Shepard CC: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: In-Reply-To: X-Enigmail-Version: 0.83.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB546E4CDB835763A4B2DB543" X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB546E4CDB835763A4B2DB543 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Tim Shepard wrote: > I think if we do have any change, it would not be a general change to > TCP, but rather a special mode you could put a TCP into with a call to > ioctl(,SO_TCP_RADIATION_HARDEN,) which would cause it to treat bare > RSTs skeptically (and somehow handle the other two problems). At > least for a while. Perhaps after some years of experience with this, > we could later recommend that it be turned on by default. Those > particular services that need to be secured sooner (like BGP > connections) can turn it on explicitly if they lack some better way to > secure the connection. That sounds very much like the EXPERIMENTAL track, ala some of the fast TCP mods, which appear equally benign, but are equally niche right now. Joe --------------enigB546E4CDB835763A4B2DB543 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAjolhE5f5cImnZrsRAr79AKCLCPwIFDs1aRB4QhVx/OX0wYvP9gCfffx+ DdoluIZP+sVUZV8BePGE2zw= =Yiad -----END PGP SIGNATURE----- --------------enigB546E4CDB835763A4B2DB543-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Apr 27 21:51:18 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16572 for ; Tue, 27 Apr 2004 21:51:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIeBD-0000H3-Ly for tcpm-archive@odin.ietf.org; Tue, 27 Apr 2004 21:48:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3S1m7uv001053 for tcpm-archive@odin.ietf.org; Tue, 27 Apr 2004 21:48:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIe8Y-0008OA-16 for tcpm-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 21:45:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16371 for ; Tue, 27 Apr 2004 21:45:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIe8T-0004Zx-5p for tcpm-web-archive@ietf.org; Tue, 27 Apr 2004 21:45:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIe7U-0004Sb-00 for tcpm-web-archive@ietf.org; Tue, 27 Apr 2004 21:44:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIe6c-0004LT-00 for tcpm-web-archive@ietf.org; Tue, 27 Apr 2004 21:43:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIe0V-0007F7-9x; Tue, 27 Apr 2004 21:37:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIdw0-0006QG-B0 for tcpm@optimus.ietf.org; Tue, 27 Apr 2004 21:32:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16032 for ; Tue, 27 Apr 2004 21:32:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIdvv-0002yr-Fz for tcpm@ietf.org; Tue, 27 Apr 2004 21:32:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIdv1-0002sD-00 for tcpm@ietf.org; Tue, 27 Apr 2004 21:31:24 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1BIduR-0002l6-00 for tcpm@ietf.org; Tue, 27 Apr 2004 21:30:47 -0400 Received: from jurassic.eng.sun.com ([129.146.17.57]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i3S1Un4U028269; Tue, 27 Apr 2004 19:30:49 -0600 (MDT) Received: from sun.com (shield.SFBay.Sun.COM [129.144.60.49]) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i3S1UnDF913286; Tue, 27 Apr 2004 18:30:49 -0700 (PDT) Message-ID: <408F0948.6030103@sun.com> Date: Tue, 27 Apr 2004 18:30:48 -0700 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.6) Gecko/20040117 X-Accept-Language: en, zh-hk, zh-tw, zh-cn MIME-Version: 1.0 To: Tim Shepard CC: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Tim Shepard wrote: > But..... are the timestamps used in the timestamp option offset by > some secret value (e.g. a good random number selected by a good secret > hash of the IP addresses and port numbers involved)? Otherwise, the > timestamps might be guessable by an attacker. This depends on the implementation. RFC 1323 does not specifies how the timestamp is chosen as long as the value increases at least at a certain rate. So a TCP stack using this mechanism for protection, it should choose the value carefully. -- K. Poon. kacheong.poon@sun.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue Apr 27 22:30:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18108 for ; Tue, 27 Apr 2004 22:30:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIekd-0004CY-NM for tcpm-archive@odin.ietf.org; Tue, 27 Apr 2004 22:24:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3S2OhMQ016145 for tcpm-archive@odin.ietf.org; Tue, 27 Apr 2004 22:24:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIeff-0003gM-7G for tcpm-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 22:19:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17479 for ; Tue, 27 Apr 2004 22:19:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIefa-0001C9-2s for tcpm-web-archive@ietf.org; Tue, 27 Apr 2004 22:19:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIeeX-0000vd-00 for tcpm-web-archive@ietf.org; Tue, 27 Apr 2004 22:18:26 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIedY-0000m6-01 for tcpm-web-archive@ietf.org; Tue, 27 Apr 2004 22:17:24 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIeaP-0006Ab-9L for tcpm-web-archive@ietf.org; Tue, 27 Apr 2004 22:14:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIeXO-0002ws-Pd; Tue, 27 Apr 2004 22:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIeUw-0002eC-VP for tcpm@optimus.ietf.org; Tue, 27 Apr 2004 22:08:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17228 for ; Tue, 27 Apr 2004 22:08:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIeUr-0007ZA-Th for tcpm@ietf.org; Tue, 27 Apr 2004 22:08:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIeTy-0007RT-00 for tcpm@ietf.org; Tue, 27 Apr 2004 22:07:31 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1BIeTX-0007JK-00 for tcpm@ietf.org; Tue, 27 Apr 2004 22:07:03 -0400 Received: from jurassic.eng.sun.com ([129.146.87.130]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3S26Sms024871; Tue, 27 Apr 2004 19:06:28 -0700 (PDT) Received: from sun.com (shield.SFBay.Sun.COM [129.144.60.49]) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i3S26RsH922983; Tue, 27 Apr 2004 19:06:28 -0700 (PDT) Message-ID: <408F11A3.8020704@sun.com> Date: Tue, 27 Apr 2004 19:06:27 -0700 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.6) Gecko/20040117 X-Accept-Language: en, zh-hk, zh-tw, zh-cn MIME-Version: 1.0 To: Mitesh Dalal CC: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: <408DC210.4090701@sun.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mitesh Dalal wrote: > if we decide to make the solution a standard, it does > not necessarily mean that all tcp stack vendors out their have to > run out and fix their stack. It IMHO, means that the engineering > community and the IETF have made due diligence in studying the > solution and that there is general consensus that yes, this is > a vulnerability and yes we agree that this is likely the best > solution given all considerations. This is the question. Is this really the "best" solution to this issue? If most, if not all, host TCP implementors are not comfortable with this "proposed solution" because it involves a new "challenge/response" behavior and will not implement it, I guess we cannot say that we have a general consensus. I'd like to hear other host TCP implementors' opinion on this. > If you are believe that you have a solution this is easier > to implement, backward compatible, appears to be minimally > disruptive, I am sure we would all like to hear it and review > it. As I mentioned in a previous mail, a cookie mechanism is better because it does not require modifying the basic TCP mechanism, especially no extra TCP segment is generated in response to a RST. The latter point is my main concern. Well, if the hosts can use TCP MD5 option or IPsec, this is not needed... But if people really like to have another alternative, I think it is better than having the TCP stack to respond to a RST. Let me submit a very short individual draft on this mechanism using the timetstamp option so that the WG can discuss it. > FWIW, I do consider your timestamp option as a valid proposition, > but the very fact that you are banking on an "optional" option > to fix this problem is speculative, because in this solution > not only does the client need to upgrade but also the middlebox > in order for them to not drop your RST and if your answer to this > is that since its an option and it can be turned off later if > we find issues then, its like saying that here is a solution that > I think will work, but I am not confident enough and if you happen > to find a problem, please turn it off and let the vulnerability > open again. I think the lesson we learned from ECN applies here. If ECN cannot be turned off in Solaris (there are actually 3 options, off, passive and active), I don't think Sun can ever include it in a production version, at least not until we are pretty sure that all middleboxes are fixed. And Solaris supports ECN since 2002. I think including it in a production version actually helps the deployment of ECN. People can use it now if they want. Please do not underestimate the power of turning off something. It does not necessarily mean that the mechanism has issues, it is simply a good engineering practice in a world full of surprises. Back to the timestamp option. First, RST with timetstamp option is actually legal according to RFC 1323. And in the case when a middlebox actually drops a RST with timestamp because of a bug, the result is equivalent to dropping a RST. There is no RST/ACK war possible. It is safe. The connection stays up and if there is something to retransmit, the sender will eventually time out. Safety is very important. I think IETF normally recommends conservativeness and safety. The fact that the vulnerability increases as the window size increases and timestamp option should be used in these cases makes this mechanism more attractive. > So please put forward scenarios to the WG to ponder that you > think may not work. If you are successful in doing so, we would > be more than glad to take back our proposal. As I mentioned, what is the method to handle a possible RST/ACK war? By limiting the number of ACK generated in response to RST? By falling back to the original TCP method? I think this should be discussed in the draft. -- K. Poon. kacheong.poon@sun.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 28 12:55:57 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28435 for ; Wed, 28 Apr 2004 12:55:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsBZ-0005Fr-78 for tcpm-archive@odin.ietf.org; Wed, 28 Apr 2004 12:45:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SGjPZm020199 for tcpm-archive@odin.ietf.org; Wed, 28 Apr 2004 12:45:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIs4G-00039Y-CA for tcpm-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 12:37:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27189 for ; Wed, 28 Apr 2004 12:37:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIs4D-0005VI-Cs for tcpm-web-archive@ietf.org; Wed, 28 Apr 2004 12:37:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIs3J-0005Tn-00 for tcpm-web-archive@ietf.org; Wed, 28 Apr 2004 12:36:54 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIs2l-0005S2-00 for tcpm-web-archive@ietf.org; Wed, 28 Apr 2004 12:36:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIruk-00016I-3D; Wed, 28 Apr 2004 12:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIrdv-0005P2-0U for tcpm@optimus.ietf.org; Wed, 28 Apr 2004 12:10:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24776 for ; Wed, 28 Apr 2004 12:10:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIrds-0003WR-BZ for tcpm@ietf.org; Wed, 28 Apr 2004 12:10:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIrcw-0003SZ-00 for tcpm@ietf.org; Wed, 28 Apr 2004 12:09:38 -0400 Received: from cs180204.pp.htv.fi ([213.243.180.204] helo=hades.pp.htv.fi) by ietf-mx with esmtp (Exim 4.12) id 1BIrck-0003OW-00 for tcpm@ietf.org; Wed, 28 Apr 2004 12:09:27 -0400 Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.11/8.12.11/Debian-4) with ESMTP id i3SGDjnF002051; Wed, 28 Apr 2004 19:13:45 +0300 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.11/8.12.11/Debian-4) id i3SGDfmZ002050; Wed, 28 Apr 2004 19:13:41 +0300 Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt From: Mika Liljeberg To: Kacheong Poon Cc: Mitesh Dalal , tcpm@ietf.org In-Reply-To: <408F11A3.8020704@sun.com> References: <408DC210.4090701@sun.com> <408F11A3.8020704@sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1083168821.29392.2319.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 28 Apr 2004 19:13:41 +0300 Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wed, 2004-04-28 at 05:06, Kacheong Poon wrote: > This is the question. Is this really the "best" solution > to this issue? If most, if not all, host TCP implementors > are not comfortable with this "proposed solution" because > it involves a new "challenge/response" behavior and will not > implement it, I guess we cannot say that we have a general > consensus. > > I'd like to hear other host TCP implementors' opinion on this. I work with what you might call smartphones and my gut feeling is that in this case the cure may potentially be worse than the disease. The proposed challenge/response mechanism attempts to solve something we basically see as a non-problem in our environment. On the other hand, we have plenty of connection-tracking middleboxes of unknown make out there in mobile operator networks, which makes it the Devil's own breeding ground for interop trouble. As it is, we're seeing enough of it with the standard TCP behaviour. So, I'm perfectly happy to sit this one out and let others sort out the middleboxes. Regards, MikaL _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 28 14:17:17 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05291 for ; Wed, 28 Apr 2004 14:17:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItVC-0008Iz-KF for tcpm-archive@odin.ietf.org; Wed, 28 Apr 2004 14:09:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SI9kaN031918 for tcpm-archive@odin.ietf.org; Wed, 28 Apr 2004 14:09:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItM8-00060A-D6 for tcpm-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 14:00:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03866 for ; Wed, 28 Apr 2004 14:00:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BItM4-0003c3-Oy for tcpm-web-archive@ietf.org; Wed, 28 Apr 2004 14:00:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BItLB-0003a6-00 for tcpm-web-archive@ietf.org; Wed, 28 Apr 2004 13:59:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BItKV-0003Y7-00 for tcpm-web-archive@ietf.org; Wed, 28 Apr 2004 13:58:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIt9D-0003SV-No; Wed, 28 Apr 2004 13:47:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIt34-000297-0E for tcpm@optimus.ietf.org; Wed, 28 Apr 2004 13:40:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02269 for ; Wed, 28 Apr 2004 13:40:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIt30-0002DL-In for tcpm@ietf.org; Wed, 28 Apr 2004 13:40:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIt21-00027x-00 for tcpm@ietf.org; Wed, 28 Apr 2004 13:39:38 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BIt19-00020P-00 for tcpm@ietf.org; Wed, 28 Apr 2004 13:38:43 -0400 Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3SHb8U03360 for ; Wed, 28 Apr 2004 10:37:08 -0700 (PDT) Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.12.10/8.12.10) with ESMTP id i3SHb8Ix062497 for ; Wed, 28 Apr 2004 10:37:08 -0700 (PDT) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.12.10/8.12.10/Submit) id i3SHb8Qw062492 for tcpm@ietf.org; Wed, 28 Apr 2004 10:37:08 -0700 (PDT) (envelope-from faber) Date: Wed, 28 Apr 2004 10:37:08 -0700 From: Ted Faber To: tcpm@ietf.org Message-ID: <20040428173708.GE87868@pun.isi.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OZkY3AIuv2LYvjdk" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: faber@isi.edu Subject: [tcpm] WG consensus sought (deadline 5 May): abort timeout negotiation Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --OZkY3AIuv2LYvjdk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, all. A few days ago Lars Eggert posted a draft to the group describing a way to negotiate TCP abort timeouts at connection establishment, draft-eggert-tcpm-tcp-abort-timeout-option-00.txt . Those concerned about process (which should be everyone) note that despite the presence of the string "tcpm" in the draft name, it is not a working group item, but an individual submission targeted to tcpm. My black helicopter is in the shop. Before we try to get consensus on the draft itself, Mark and I are seeking consensus on the topic. The draft itself does a good job of describing the issue and is a good place to start if you want to understand it (it's not a very complex issue). The short form is that mobile or intermittently connected hosts may want to request that endpoints wait a long time before tearing down an idle TCP connection, and that there's currently no way to do that. The question before the group is "do we want to address negotiating the abort timeout in TCP?" If we reach a positive consensus on that, we'll talk about adopting Lars's draft. We need to hear from folks who have opinions either way. I propose that we close discussion and come to a resolution by Wed 5 May. If you have opinions you want considered, at least get a placeholder out to the tcpm mailing list by then. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG --OZkY3AIuv2LYvjdk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAj+vEaUz3f+Zf+XsRAvQEAKDNL16zHH2fa3n8KLQx6eDViCBvlwCglKY3 YPX5ZWkZaFcJMVAvgZqWvsE= =1jLD -----END PGP SIGNATURE----- --OZkY3AIuv2LYvjdk-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 28 15:06:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08560 for ; Wed, 28 Apr 2004 15:06:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuGb-0002NK-4V for tcpm-archive@odin.ietf.org; Wed, 28 Apr 2004 14:58:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SIwj7S009125 for tcpm-archive@odin.ietf.org; Wed, 28 Apr 2004 14:58:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuDg-0001WQ-LX for tcpm-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 14:55:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07396 for ; Wed, 28 Apr 2004 14:55:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIuDc-0007G1-Gz for tcpm-web-archive@ietf.org; Wed, 28 Apr 2004 14:55:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIuCb-0007Ay-00 for tcpm-web-archive@ietf.org; Wed, 28 Apr 2004 14:54:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIuBz-00076d-00 for tcpm-web-archive@ietf.org; Wed, 28 Apr 2004 14:53:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIu0R-0007kX-CX; Wed, 28 Apr 2004 14:42:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItu8-0005Ps-CI for tcpm@optimus.ietf.org; Wed, 28 Apr 2004 14:35:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06188 for ; Wed, 28 Apr 2004 14:35:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BItu4-0005t9-Dy for tcpm@ietf.org; Wed, 28 Apr 2004 14:35:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BItt3-0005kG-00 for tcpm@ietf.org; Wed, 28 Apr 2004 14:34:26 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BItrz-0005aV-01 for tcpm@ietf.org; Wed, 28 Apr 2004 14:33:19 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIth1-0005Xf-Mt for tcpm@ietf.org; Wed, 28 Apr 2004 14:21:59 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id LAA01886 for ; Wed, 28 Apr 2004 11:21:26 -0700 (PDT) Received: from xch-nw-23p.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i3SILQV18280 for ; Wed, 28 Apr 2004 11:21:26 -0700 (PDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by xch-nw-23p.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 28 Apr 2004 11:21:24 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Subject: RE: [tcpm] WG consensus sought (deadline 5 May): abort timeout negotiation Date: Wed, 28 Apr 2004 11:21:24 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040605DC@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [tcpm] WG consensus sought (deadline 5 May): abort timeout negotiation Thread-Index: AcQtSpepxLTFy92mQzyvp89MMnpoOAAAWspQ From: "Henderson, Thomas R" To: X-OriginalArrivalTime: 28 Apr 2004 18:21:24.0975 (UTC) FILETIME=[9D676FF0:01C42D4D] Content-Transfer-Encoding: quoted-printable Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I would like to support this as a work item-- I know of wireless and satellite scenarios where it would be operationally helpful. But to clarify one thing: > The short form is that > mobile or intermittently connected hosts may want to request that > endpoints wait a long time before tearing down an idle TCP connection, > and that there's currently no way to do that. It is not an idle connection that is the problem-- it is a connection with outstanding data. Tom _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 28 17:08:23 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20763 for ; Wed, 28 Apr 2004 17:08:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuy9-0004v7-25 for tcpm-archive@odin.ietf.org; Wed, 28 Apr 2004 15:43:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SJhj5Z018913 for tcpm-archive@odin.ietf.org; Wed, 28 Apr 2004 15:43:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIupF-0002yl-BT for tcpm-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 15:34:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11442 for ; Wed, 28 Apr 2004 15:34:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIupC-0001tE-Jy for tcpm-web-archive@ietf.org; Wed, 28 Apr 2004 15:34:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIuoI-0001qZ-00 for tcpm-web-archive@ietf.org; Wed, 28 Apr 2004 15:33:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIung-0001nf-00 for tcpm-web-archive@ietf.org; Wed, 28 Apr 2004 15:32:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIue5-00087o-Fj; Wed, 28 Apr 2004 15:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuYo-0006HQ-TX for tcpm@optimus.ietf.org; Wed, 28 Apr 2004 15:17:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09667 for ; Wed, 28 Apr 2004 15:17:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIuYl-00013C-VF for tcpm@ietf.org; Wed, 28 Apr 2004 15:17:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIuXr-00010K-00 for tcpm@ietf.org; Wed, 28 Apr 2004 15:16:35 -0400 Received: from ftp.netlab.nec.de ([195.37.70.21] helo=ftp.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1BIuXB-0000xK-00 for tcpm@ietf.org; Wed, 28 Apr 2004 15:15:53 -0400 Received: from netlab.nec.de (p508437FC.dip0.t-ipconnect.de [80.132.55.252]) by ftp.ccrle.nec.de (Postfix) with ESMTP id 2AC33F674; Wed, 28 Apr 2004 21:20:51 +0200 (CEST) Message-ID: <409002E1.8040603@netlab.nec.de> Date: Wed, 28 Apr 2004 21:15:45 +0200 From: Lars Eggert Organization: NEC Network Laboratories User-Agent: Mozilla Thunderbird 0.6b (Macintosh/20040425) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Henderson, Thomas R" Cc: tcpm@ietf.org Subject: Re: [tcpm] WG consensus sought (deadline 5 May): abort timeout negotiation References: <6938661A6EDA8A4EA8D1419BCE46F24C040605DC@xch-nw-27.nw.nos.boeing.com> In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040605DC@xch-nw-27.nw.nos.boeing.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000702030509060406020407" Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms000702030509060406020407 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Henderson, Thomas R wrote: >>The short form is that >>mobile or intermittently connected hosts may want to request that >>endpoints wait a long time before tearing down an idle TCP connection, >>and that there's currently no way to do that. > > It is not an idle connection that is the problem-- it is a connection > with outstanding data. Or when keepalives are used, esp. with servers that use more aggressive keepalives than the default 2 hours. (But in a sense, that falls under "outstanding data.") Lars -- Lars Eggert NEC Network Laboratories --------------ms000702030509060406020407 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ/zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNaMIICw6ADAgECAgMLU6IwDQYJKoZIhvcNAQEE BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTAz MTIxNTEyMzEyOFoXDTA0MTIxNDEyMzEyOFowgYQxDzANBgNVBAQTBkVnZ2VydDENMAsGA1UE KhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdn ZXJ0QG5ldGxhYi5uZWMuZGUxIjAgBgkqhkiG9w0BCQEWE2xhcnMuZWdnZXJ0QGdteC5uZXQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWps58Zq8Buu2DKDl9crbvzSo6zWsZ TkQLr5zOTqUMs/eU7Mcohv64O4IxWWYGLfYsjDRxUlmdHdJUbyTtUh2lH452DUDJByXidlLm RDgohG0AVwztedqy1+hE3VnCdpMhUGks+6ntrr3dKSxMgLM0AM1kPWsH9lWX6IOPdxOC30gM PiQ65zH9PR70befQLgFPKcAv0wP8210l05n8ekwYAcq2cm3/j+nuDu0HEh5pgsnY7cVELeNJ ODvr4IiE1t3c2w4+0Nc/WJrqGCMl+gZ8c+7FtzjoyDeEsCjNFDeA2ymNd+10O6kjwvPHlzPr 3rW73RDRPAjMJ49HXlueiuoNAgMBAAGjdzB1MCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwOQYDVR0RBDIwMIEZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5k ZYETbGFycy5lZ2dlcnRAZ214Lm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB AHgrv3SQFD4AS4lY4oKcI3iTHcclEHbYfg3UUb8zzCUsl+OJoz0nmebGmOL+tvNj5GvCrWnN H4LvVLh8ZBhFXms7eKJ1YiHgbKwTRK23P8Y5NDit5ico0ZjpFWeenUWj3ajEbN6n4K8dNp+C 0b2apnSrlFVWY6BucZFIYqQ1Lf91MIIDWjCCAsOgAwIBAgIDC1OiMA0GCSqGSIb3DQEBBAUA MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wMzEy MTUxMjMxMjhaFw0wNDEyMTQxMjMxMjhaMIGEMQ8wDQYDVQQEEwZFZ2dlcnQxDTALBgNVBCoT BExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2Vy dEBuZXRsYWIubmVjLmRlMSIwIAYJKoZIhvcNAQkBFhNsYXJzLmVnZ2VydEBnbXgubmV0MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1qbOfGavAbrtgyg5fXK2780qOs1rGU5E C6+czk6lDLP3lOzHKIb+uDuCMVlmBi32LIw0cVJZnR3SVG8k7VIdpR+Odg1AyQcl4nZS5kQ4 KIRtAFcM7XnastfoRN1ZwnaTIVBpLPup7a693SksTICzNADNZD1rB/ZVl+iDj3cTgt9IDD4k Oucx/T0e9G3n0C4BTynAL9MD/NtdJdOZ/HpMGAHKtnJt/4/p7g7tBxIeaYLJ2O3FRC3jSTg7 6+CIhNbd3NsOPtDXP1ia6hgjJfoGfHPuxbc46Mg3hLAozRQ3gNspjXftdDupI8Lzx5cz6961 u90Q0TwIzCePR15bnorqDQIDAQABo3cwdTAqBgUrZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVN eWZmQk5VYk5KSmNkWjJzMDkGA1UdEQQyMDCBGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGWB E2xhcnMuZWdnZXJ0QGdteC5uZXQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQB4 K790kBQ+AEuJWOKCnCN4kx3HJRB22H4N1FG/M8wlLJfjiaM9J5nmxpji/rbzY+Rrwq1pzR+C 71S4fGQYRV5rO3iidWIh4GysE0Sttz/GOTQ4reYnKNGY6RVnnp1Fo92oxGzep+CvHTafgtG9 mqZ0q5RVVmOgbnGRSGKkNS3/dTGCAzswggM3AgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwCQYFKw4DAhoFAKCCAacwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwNDI4MTkxNTQ1WjAjBgkqhkiG 9w0BCQQxFgQU1Wrfo/udN8/g2FqF8VHDZrQQRyAwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECAwtTojB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwDQYJKoZIhvcNAQEBBQAEggEA sTboDR0Ly5XG6hbrZrJuhPzL9wzB3nQPDNTPiKdhUnxa5ieRv2bGYHsPsLlzkfL5UimRTp1P dasPe/dfsKTOIHCrToX5i/zMArKsi4gxSxwYf0/WI8M8Joaszyvp+IRkBIfhQnsz/afUZpkK tBJXTCAjrhHzTb+6vIB/gA1S7cVkZmE9FcQmz4bsh19CWzrRgBwHn0O1uUvQznwbAFbJMERC 7e0oWBror6txirPED3v6RwN5RlUJdCCndbJSd/2Br0UQ8EDpijAWIzfMhMxJFrEd2aXdlaqh sAR3tS/o/cUJx6IUYKGYsiP4g7I6axdprPufBE6gcKmDwjQsN0+7yAAAAAAAAA== --------------ms000702030509060406020407-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 28 18:00:22 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26892 for ; Wed, 28 Apr 2004 18:00:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwv5-0005nD-Ut for tcpm-archive@odin.ietf.org; Wed, 28 Apr 2004 17:48:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SLmhHC022265 for tcpm-archive@odin.ietf.org; Wed, 28 Apr 2004 17:48:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwhX-0006cC-5M for tcpm-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 17:34:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24704 for ; Wed, 28 Apr 2004 17:34:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIwhT-0001Ym-J2 for tcpm-web-archive@ietf.org; Wed, 28 Apr 2004 17:34:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIwgi-0001TO-00 for tcpm-web-archive@ietf.org; Wed, 28 Apr 2004 17:33:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIwgE-0001OA-00 for tcpm-web-archive@ietf.org; Wed, 28 Apr 2004 17:33:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwMX-00035f-Fl; Wed, 28 Apr 2004 17:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIvIE-0002aK-C4 for tcpm@optimus.ietf.org; Wed, 28 Apr 2004 16:04:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13720 for ; Wed, 28 Apr 2004 16:04:28 -0400 (EDT) From: bill@strahm.net Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIvIB-0004IN-G6 for tcpm@ietf.org; Wed, 28 Apr 2004 16:04:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIvHJ-0004EF-00 for tcpm@ietf.org; Wed, 28 Apr 2004 16:03:33 -0400 Received: from smtpout-1-1c.secureserver.net ([64.202.165.65]) by ietf-mx with smtp (Exim 4.12) id 1BIvGX-00045q-00 for tcpm@ietf.org; Wed, 28 Apr 2004 16:02:46 -0400 Received: (qmail 3558 invoked from network); 28 Apr 2004 20:02:25 -0000 Received: from unknown (HELO webmail-2-5.mesa1.secureserver.net) (64.202.166.92) by smtpout-1-1c.secureserver.net with SMTP; 28 Apr 2004 20:02:25 -0000 Received: (qmail 14347 invoked by uid 99); 28 Apr 2004 20:02:16 -0000 Message-ID: <20040428200216.14346.qmail@webmail-2-5.mesa1.secureserver.net> Date: Wed, 28 Apr 2004 13:02:16 -0700 Subject: RE: [tcpm] WG consensus sought (deadline 5 May): abort timeout negotiation To: Ted Faber cc: tcpm@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 I will say the discussion should belong inside the WG. (time to get on the soapbox) I would like to say however (for those people that DO see Black Helicopters and wear there AFBs on a regular bassis... The use of ietf-draft-name-wg-foo-00.txt as an individual submission is a well honored practice when the work belongs within the charter of a working group. It is much easier as a WG chair to get a new work item put into the WG charter when there is a draft to base it off of. Now it is up to the WG chairs to go off and find out if it indeed belongs in the WG as a charter item, and if so instruct the new editor to change the name of the updated draft to reflect it (or to continue down the Individual Submission path if it is decided not to become a WG item) I am slightly more concerned with the tcp security draft that went out, but there were reasons for doing it the way that it was done, and I am happy with the results (OK - I wish I had been included in the secret audience before it was announced - don't we all ). Even then there is no requirement that I am aware of that drafts be exposed outside the authors before initial submission (or that internal discussions among the editors be disclosed outside of summary - here are the decisions that we have made, to the Working Group), so I don't think any process has been violated. These are my opinions only (stepping off of my soapbox now) Bill > -------- Original Message -------- > Subject: [tcpm] WG consensus sought (deadline 5 May): abort timeout > negotiation > From: "Ted Faber" > Date: Wed, April 28, 2004 10:37 am > To: tcpm@ietf.org > > Hi, all. > > A few days ago Lars Eggert posted a draft to the group describing a > way > to negotiate TCP abort timeouts at connection establishment, > draft-eggert-tcpm-tcp-abort-timeout-option-00.txt . Those concerned > about process (which should be everyone) note that despite the > presence > of the string "tcpm" in the draft name, it is not a working group > item, > but an individual submission targeted to tcpm. My black helicopter is > in the shop. > > Before we try to get consensus on the draft itself, Mark and I are > seeking consensus on the topic. The draft itself does a good job of > describing the issue and is a good place to start if you want to > understand it (it's not a very complex issue). The short form is that > mobile or intermittently connected hosts may want to request that > endpoints wait a long time before tearing down an idle TCP connection, > and that there's currently no way to do that. > > The question before the group is "do we want to address negotiating > the > abort timeout in TCP?" If we reach a positive consensus on that, > we'll > talk about adopting Lars's draft. > > We need to hear from folks who have opinions either way. I propose > that > we close discussion and come to a resolution by Wed 5 May. If you > have > opinions you want considered, at least get a placeholder out to the > tcpm > mailing list by then. > > -- > Ted Faber > http://www.isi.edu/~faber PGP: > http://www.isi.edu/~faber/pubkeys.asc > Unexpected attachment on this mail? See > http://www.isi.edu/~faber/FAQ.html#SIG _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 28 19:30:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03244 for ; Wed, 28 Apr 2004 19:30:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIyTQ-0001hP-F1 for tcpm-archive@odin.ietf.org; Wed, 28 Apr 2004 19:28:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SNSGND006527 for tcpm-archive@odin.ietf.org; Wed, 28 Apr 2004 19:28:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIyCO-0006Fh-De for tcpm-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 19:10:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01992 for ; Wed, 28 Apr 2004 19:10:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIyCJ-0001hv-Ti for tcpm-web-archive@ietf.org; Wed, 28 Apr 2004 19:10:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIyBM-0001cg-00 for tcpm-web-archive@ietf.org; Wed, 28 Apr 2004 19:09:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIyAs-0001ZL-00 for tcpm-web-archive@ietf.org; Wed, 28 Apr 2004 19:09:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIy5w-0003aU-KP; Wed, 28 Apr 2004 19:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxuv-0007ur-EZ for tcpm@optimus.ietf.org; Wed, 28 Apr 2004 18:52:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00976 for ; Wed, 28 Apr 2004 18:52:32 -0400 (EDT) From: Yogesh.Swami@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIxuq-0000Cr-U4 for tcpm@ietf.org; Wed, 28 Apr 2004 18:52:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIxtu-00008z-00 for tcpm@ietf.org; Wed, 28 Apr 2004 18:51:35 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BIxta-00005I-00 for tcpm@ietf.org; Wed, 28 Apr 2004 18:51:14 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3SMp2J21835; Thu, 29 Apr 2004 01:51:02 +0300 (EET DST) X-Scanned: Thu, 29 Apr 2004 01:50:35 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3SMoZhr003035; Thu, 29 Apr 2004 01:50:35 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00Rk1Umc; Thu, 29 Apr 2004 01:50:34 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3SMoXH29610; Thu, 29 Apr 2004 01:50:33 +0300 (EET DST) Received: from daebe004.NOE.Nokia.com ([10.241.35.104]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 28 Apr 2004 17:50:11 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [tcpm] WG consensus sought (deadline 5 May): abort timeout negotiation Date: Wed, 28 Apr 2004 17:50:10 -0500 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE016E80F0@daebe004.americas.nokia.com> Thread-Topic: [tcpm] WG consensus sought (deadline 5 May): abort timeout negotiation Thread-Index: AcQtV80tV9Qvo2k5QUyPLm5qPTS8WwAF7T5w To: , Cc: X-OriginalArrivalTime: 28 Apr 2004 22:50:11.0475 (UTC) FILETIME=[298C0E30:01C42D73] Content-Transfer-Encoding: quoted-printable Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable While I am still to form an opinion on this, I would like to know in what cases such connection aborts take place. From my understanding, host mobility almost always gets completed within 8 round trips (in the wired network) at the very worst (please correct me if I am wrong) and it should not typically take more than 10-20 seconds to completely establish a new working route within this time period. The only case where such aborts can take place is when a user moves into a poor wireless coverage area (e.g., a tunnel) during an active session and comes out after a few minutes. But in these cases, I am not clear what is the algorithm to select the timeout value. If poor coverage area is the only case, then it might be better to let the application solve the problem rather than using a TCP option. Some applications/servers might not want to keep the connection hanging beyond certain delay anyway. Yogesh > -----Original Message----- > From: tcpm-admin@ietf.org [mailto:tcpm-admin@ietf.org]On Behalf Of ext > Lars Eggert > Sent: Wednesday, April 28, 2004 2:16 PM > To: Henderson, Thomas R > Cc: tcpm@ietf.org > Subject: Re: [tcpm] WG consensus sought (deadline 5 May):=20 > abort timeout > negotiation >=20 >=20 > Henderson, Thomas R wrote: > >>The short form is that > >>mobile or intermittently connected hosts may want to request that > >>endpoints wait a long time before tearing down an idle TCP=20 > connection, > >>and that there's currently no way to do that. > >=20 > > It is not an idle connection that is the problem-- it is a=20 > connection > > with outstanding data. >=20 > Or when keepalives are used, esp. with servers that use more=20 > aggressive=20 > keepalives than the default 2 hours. (But in a sense, that=20 > falls under=20 > "outstanding data.") >=20 > Lars > --=20 > Lars Eggert NEC Network=20 > Laboratories >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 28 20:22:23 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06697 for ; Wed, 28 Apr 2004 20:22:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIz7w-0005tK-5L for tcpm-archive@odin.ietf.org; Wed, 28 Apr 2004 20:10:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T0A8Zr022640 for tcpm-archive@odin.ietf.org; Wed, 28 Apr 2004 20:10:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIz3j-0004X6-Rc for tcpm-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 20:05:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05897 for ; Wed, 28 Apr 2004 20:05:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIz3g-0007TZ-Mz for tcpm-web-archive@ietf.org; Wed, 28 Apr 2004 20:05:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIz2e-0007Ni-00 for tcpm-web-archive@ietf.org; Wed, 28 Apr 2004 20:04:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIz1u-0007JC-00 for tcpm-web-archive@ietf.org; Wed, 28 Apr 2004 20:03:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIyvE-0001J6-Ph; Wed, 28 Apr 2004 19:57:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIyk9-0007Cf-ID for tcpm@optimus.ietf.org; Wed, 28 Apr 2004 19:45:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04250 for ; Wed, 28 Apr 2004 19:45:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIyk6-00053m-BL for tcpm@ietf.org; Wed, 28 Apr 2004 19:45:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIyj8-0004yW-00 for tcpm@ietf.org; Wed, 28 Apr 2004 19:44:31 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx with esmtp (Exim 4.12) id 1BIyiA-0004rA-00 for tcpm@ietf.org; Wed, 28 Apr 2004 19:43:30 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id QAA06984 for ; Wed, 28 Apr 2004 16:43:00 -0700 (PDT) Received: from XCH-NWBH-01.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i3SNh0V07969 for ; Wed, 28 Apr 2004 16:43:00 -0700 (PDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Wed, 28 Apr 2004 16:42:59 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Subject: RE: [tcpm] WG consensus sought (deadline 5 May): abort timeout negotiation Date: Wed, 28 Apr 2004 16:42:59 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040605E0@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [tcpm] WG consensus sought (deadline 5 May): abort timeout negotiation Thread-Index: AcQtV80tV9Qvo2k5QUyPLm5qPTS8WwAF7T5wAAGC+pA= From: "Henderson, Thomas R" To: X-OriginalArrivalTime: 28 Apr 2004 23:42:59.0641 (UTC) FILETIME=[89EBD290:01C42D7A] Content-Transfer-Encoding: quoted-printable Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Yogesh.Swami@nokia.com [mailto:Yogesh.Swami@nokia.com]=20 > Sent: Wednesday, April 28, 2004 3:50 PM > To: lars.eggert@netlab.nec.de; Henderson, Thomas R > Cc: tcpm@ietf.org > Subject: RE: [tcpm] WG consensus sought (deadline 5 May):=20 > abort timeout negotiation >=20 >=20 > While I am still to form an opinion on this, I would like to know in > what cases such connection aborts take place. From my understanding, > host mobility almost always gets completed within 8 round=20 > trips (in the > wired network) at the very worst (please correct me if I am wrong) and > it should not typically take more than 10-20 seconds to completely > establish a new working route within this time period. >=20 > The only case where such aborts can take place is when a user=20 > moves into > a poor wireless coverage area (e.g., a tunnel) during an=20 > active session > and comes out after a few minutes.=20 It seems to me that it would be difficult to establish reliable=20 bounds on the time that a mobility or link fade event is completed. =20 Everyone's mileage may vary. The various desktop OSes will typically retransmit 10-15 times=20 before aborting a connection. This leads to aborts in some cases=20 within two minutes of outage. =20 > But in these cases, I am not clear > what is the algorithm to select the timeout value. If poor=20 > coverage area > is the only case, then it might be better to let the application solve > the problem rather than using a TCP option. Some applications/servers > might not want to keep the connection hanging beyond certain delay > anyway. >=20 I think that we should separate mechanism from policy in this=20 discussion. To me, this is analogous to window scale, from an application perspective. TCP provides a mechanism whereby, if applications do a setsockopt() for more buffer space, more=20 window scale is negotiated. But 1323 doesn't address how an=20 implementation selects its maximum buffer size. Likewise, it=20 may be that applications or hosts want a more persistent TCP=20 connection if possible. The converse may also be true-- an application may not want to sit around in a lengthy backed=20 off state, not able to transfer data even though connectivity was restored (this was discussed in the link-up notification=20 debate). The peer server can make its own decisions on the=20 value that it is willing to support. Tom=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed Apr 28 22:37:32 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11834 for ; Wed, 28 Apr 2004 22:37:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ1K9-000820-SC for tcpm-archive@odin.ietf.org; Wed, 28 Apr 2004 22:30:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T2Ur7B030856 for tcpm-archive@odin.ietf.org; Wed, 28 Apr 2004 22:30:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ1I4-0007V7-3Q for tcpm-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 22:28:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11647 for ; Wed, 28 Apr 2004 22:28:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ1Hz-00053q-Ij for tcpm-web-archive@ietf.org; Wed, 28 Apr 2004 22:28:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ1H6-0004yO-00 for tcpm-web-archive@ietf.org; Wed, 28 Apr 2004 22:27:45 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJ1GC-0004sp-00 for tcpm-web-archive@ietf.org; Wed, 28 Apr 2004 22:26:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ1Ac-0006F8-CM; Wed, 28 Apr 2004 22:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ17Q-0005pG-AD for tcpm@optimus.ietf.org; Wed, 28 Apr 2004 22:17:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11273 for ; Wed, 28 Apr 2004 22:17:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ17L-0003wH-St for tcpm@ietf.org; Wed, 28 Apr 2004 22:17:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ16N-0003pQ-00 for tcpm@ietf.org; Wed, 28 Apr 2004 22:16:39 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx with esmtp (Exim 4.12) id 1BJ15R-0003iE-00 for tcpm@ietf.org; Wed, 28 Apr 2004 22:15:41 -0400 Received: from lawyers.icir.org (wyvern.icir.org [192.150.187.14]) by wyvern.icir.org (8.12.9p1/8.12.8) with ESMTP id i3T2Fehw082522; Wed, 28 Apr 2004 19:15:41 -0700 (PDT) (envelope-from mallman@icir.org) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id C4F76144067; Wed, 28 Apr 2004 22:15:40 -0400 (EDT) To: Yogesh.Swami@nokia.com From: Mark Allman Reply-To: mallman@icir.org Cc: lars.eggert@netlab.nec.de, thomas.r.henderson@boeing.com, tcpm@ietf.org Subject: Re: [tcpm] WG consensus sought (deadline 5 May): abort timeout negotiation In-Reply-To: <025E7DD4182874489CC2F61EE0FA19CE016E80F0@daebe004.americas.nokia.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Hey Jealousy MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 28 Apr 2004 22:15:40 -0400 Message-Id: <20040429021540.C4F76144067@lawyers.icir.org> Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --=-=-= Content-Type: text/plain > While I am still to form an opinion on this, I would like to know in > what cases such connection aborts take place. From my understanding, > host mobility almost always gets completed within 8 round trips (in > the wired network) at the very worst (please correct me if I am wrong) > and it should not typically take more than 10-20 seconds to completely > establish a new working route within this time period. I think this is not for active mobility sorts of cases --- which, I agree, generally survive such transients. But, think of this scenario .... I use my laptop on my office network and have a bunch of connections up and running (say long-lived ssh connections .... which I usually have a few of). Now, I take my laptop off the network all together for whatever reason (say, because I throw it in my backpack to go to a meeting or whatever). I don't put the laptop on the network until I return to my office. When I plug back in, it might be nice to have my connections still alive and kicking (say, after a bit of a transient startup). Lars- is that a plausible scenario that you intend to cover? So, the question Ted is asking - just to re-play - is whether this is a worthy goal for TCP and whether this WG should tackle some scheme for doing it (not necessarily precisely what is in Lars' ATO i-d). Thanks! allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin) iD8DBQFAkGVMWyrrWs4yIs4RAqINAJ9galaqJ7cCIwkk/ZhcuCXvTnreuwCfawOP MPXR1Rxi+76MWeY/8JXH/so= =9YHX -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu Apr 29 03:01:31 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09415 for ; Thu, 29 Apr 2004 03:01:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ5Up-00070l-TL for tcpm-archive@odin.ietf.org; Thu, 29 Apr 2004 02:58:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T6wBUY026951 for tcpm-archive@odin.ietf.org; Thu, 29 Apr 2004 02:58:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ5Mp-0004vT-7o for tcpm-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 02:49:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08814 for ; Thu, 29 Apr 2004 02:49:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ5Mi-00075k-Dx for tcpm-web-archive@ietf.org; Thu, 29 Apr 2004 02:49:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ5Lk-0006x4-00 for tcpm-web-archive@ietf.org; Thu, 29 Apr 2004 02:48:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJ5Km-0006p7-00 for tcpm-web-archive@ietf.org; Thu, 29 Apr 2004 02:47:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ5BP-00029b-Oh; Thu, 29 Apr 2004 02:38:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ58J-0000xH-Nr for tcpm@optimus.ietf.org; Thu, 29 Apr 2004 02:34:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07988 for ; Thu, 29 Apr 2004 02:34:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ58C-00051J-HN for tcpm@ietf.org; Thu, 29 Apr 2004 02:34:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ57D-0004tV-00 for tcpm@ietf.org; Thu, 29 Apr 2004 02:33:48 -0400 Received: from ftp.netlab.nec.de ([195.37.70.21] helo=ftp.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1BJ56J-0004le-00 for tcpm@ietf.org; Thu, 29 Apr 2004 02:32:51 -0400 Received: from netlab.nec.de (scout.netlab.nec.de [195.37.70.100]) by ftp.ccrle.nec.de (Postfix) with ESMTP id 3C245F674; Thu, 29 Apr 2004 08:37:52 +0200 (CEST) Message-ID: <4090A18D.8000301@netlab.nec.de> Date: Thu, 29 Apr 2004 08:32:45 +0200 From: Lars Eggert Organization: NEC Network Laboratories User-Agent: Mozilla Thunderbird 0.6b (Macintosh/20040425) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mallman@icir.org Cc: Yogesh.Swami@nokia.com, thomas.r.henderson@boeing.com, tcpm@ietf.org Subject: Re: [tcpm] WG consensus sought (deadline 5 May): abort timeout negotiation References: <20040429021540.C4F76144067@lawyers.icir.org> In-Reply-To: <20040429021540.C4F76144067@lawyers.icir.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010208030600030003010207" Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms010208030600030003010207 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mark Allman wrote: >>While I am still to form an opinion on this, I would like to know in >>what cases such connection aborts take place. From my understanding, >>host mobility almost always gets completed within 8 round trips (in >>the wired network) at the very worst (please correct me if I am wrong) >>and it should not typically take more than 10-20 seconds to completely >>establish a new working route within this time period. > > I think this is not for active mobility sorts of cases --- which, I > agree, generally survive such transients. > > But, think of this scenario .... I use my laptop on my office network > and have a bunch of connections up and running (say long-lived ssh > connections .... which I usually have a few of). Now, I take my laptop > off the network all together for whatever reason (say, because I throw > it in my backpack to go to a meeting or whatever). I don't put the > laptop on the network until I return to my office. When I plug back in, > it might be nice to have my connections still alive and kicking (say, > after a bit of a transient startup). > > Lars- is that a plausible scenario that you intend to cover? Exactly. We actually also play with a slightly different scenario, where the TCP session runs over HIP. This lets you plug in anywhere - your connections are bound to the host identities and thus survive the address changes at the new location. The issue then is that by the time you plug back in, the retransmission abort timer has on the peers may have fired and the connections have been reset. > So, the question Ted is asking - just to re-play - is whether this is a > worthy goal for TCP and whether this WG should tackle some scheme for > doing it (not necessarily precisely what is in Lars' ATO i-d). > > Thanks! > > allman > > > -- > Mark Allman -- ICIR -- http://www.icir.org/mallman/ > > > -- Lars Eggert NEC Network Laboratories --------------ms010208030600030003010207 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ/zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNaMIICw6ADAgECAgMLU6IwDQYJKoZIhvcNAQEE BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTAz MTIxNTEyMzEyOFoXDTA0MTIxNDEyMzEyOFowgYQxDzANBgNVBAQTBkVnZ2VydDENMAsGA1UE KhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdn ZXJ0QG5ldGxhYi5uZWMuZGUxIjAgBgkqhkiG9w0BCQEWE2xhcnMuZWdnZXJ0QGdteC5uZXQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWps58Zq8Buu2DKDl9crbvzSo6zWsZ TkQLr5zOTqUMs/eU7Mcohv64O4IxWWYGLfYsjDRxUlmdHdJUbyTtUh2lH452DUDJByXidlLm RDgohG0AVwztedqy1+hE3VnCdpMhUGks+6ntrr3dKSxMgLM0AM1kPWsH9lWX6IOPdxOC30gM PiQ65zH9PR70befQLgFPKcAv0wP8210l05n8ekwYAcq2cm3/j+nuDu0HEh5pgsnY7cVELeNJ ODvr4IiE1t3c2w4+0Nc/WJrqGCMl+gZ8c+7FtzjoyDeEsCjNFDeA2ymNd+10O6kjwvPHlzPr 3rW73RDRPAjMJ49HXlueiuoNAgMBAAGjdzB1MCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwOQYDVR0RBDIwMIEZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5k ZYETbGFycy5lZ2dlcnRAZ214Lm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB AHgrv3SQFD4AS4lY4oKcI3iTHcclEHbYfg3UUb8zzCUsl+OJoz0nmebGmOL+tvNj5GvCrWnN H4LvVLh8ZBhFXms7eKJ1YiHgbKwTRK23P8Y5NDit5ico0ZjpFWeenUWj3ajEbN6n4K8dNp+C 0b2apnSrlFVWY6BucZFIYqQ1Lf91MIIDWjCCAsOgAwIBAgIDC1OiMA0GCSqGSIb3DQEBBAUA MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wMzEy MTUxMjMxMjhaFw0wNDEyMTQxMjMxMjhaMIGEMQ8wDQYDVQQEEwZFZ2dlcnQxDTALBgNVBCoT BExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2Vy dEBuZXRsYWIubmVjLmRlMSIwIAYJKoZIhvcNAQkBFhNsYXJzLmVnZ2VydEBnbXgubmV0MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1qbOfGavAbrtgyg5fXK2780qOs1rGU5E C6+czk6lDLP3lOzHKIb+uDuCMVlmBi32LIw0cVJZnR3SVG8k7VIdpR+Odg1AyQcl4nZS5kQ4 KIRtAFcM7XnastfoRN1ZwnaTIVBpLPup7a693SksTICzNADNZD1rB/ZVl+iDj3cTgt9IDD4k Oucx/T0e9G3n0C4BTynAL9MD/NtdJdOZ/HpMGAHKtnJt/4/p7g7tBxIeaYLJ2O3FRC3jSTg7 6+CIhNbd3NsOPtDXP1ia6hgjJfoGfHPuxbc46Mg3hLAozRQ3gNspjXftdDupI8Lzx5cz6961 u90Q0TwIzCePR15bnorqDQIDAQABo3cwdTAqBgUrZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVN eWZmQk5VYk5KSmNkWjJzMDkGA1UdEQQyMDCBGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGWB E2xhcnMuZWdnZXJ0QGdteC5uZXQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQB4 K790kBQ+AEuJWOKCnCN4kx3HJRB22H4N1FG/M8wlLJfjiaM9J5nmxpji/rbzY+Rrwq1pzR+C 71S4fGQYRV5rO3iidWIh4GysE0Sttz/GOTQ4reYnKNGY6RVnnp1Fo92oxGzep+CvHTafgtG9 mqZ0q5RVVmOgbnGRSGKkNS3/dTGCAzswggM3AgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwCQYFKw4DAhoFAKCCAacwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwNDI5MDYzMjQ1WjAjBgkqhkiG 9w0BCQQxFgQUSf4sSIujIc9a00NyruruCht+FQkwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECAwtTojB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwDQYJKoZIhvcNAQEBBQAEggEA E4bHuwjqS2ASqkx6AHsPDQN/e2aA0RUqOE3Mfsn9VsAVNTm5aO23vF4Aejz6jI2zUhLjv5KC ZWFlch56485LLCeDf/0ic/kcg23x5QbvLj3QeB97unLk/r06nyvA6X8R2xpRD/yH/ljvZBvJ 03cGyUXiniXO/Lu3t130+p/+MSaKMmqlt+Z5WUe/J+bdWDPJDexa/4r+BB3HYE3fTJUVTkrZ b1p6l2NDj23eVfQoex/Znnd6Dfg9gS0lMFwG3ugXnDeeEECOhTZaG9zLMzNW0d0LoAQxLinl wDGxO3TzhpeRJBLSC+hs5sX+RaykpPTPeefLLU4yHHOAGZmoqxIVBQAAAAAAAA== --------------ms010208030600030003010207-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu Apr 29 03:08:59 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09724 for ; Thu, 29 Apr 2004 03:08:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ5Yq-0007ZC-0b for tcpm-archive@odin.ietf.org; Thu, 29 Apr 2004 03:02:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T72JDA029087 for tcpm-archive@odin.ietf.org; Thu, 29 Apr 2004 03:02:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ5Ve-00074E-Ma for tcpm-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 02:59:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09270 for ; Thu, 29 Apr 2004 02:58:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ5VX-0000gS-NW for tcpm-web-archive@ietf.org; Thu, 29 Apr 2004 02:58:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ5Uj-0000Uw-00 for tcpm-web-archive@ietf.org; Thu, 29 Apr 2004 02:58:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJ5Tk-0000LI-00 for tcpm-web-archive@ietf.org; Thu, 29 Apr 2004 02:57:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ5M3-0004jH-DM; Thu, 29 Apr 2004 02:49:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ5G5-0002y8-24 for tcpm@optimus.ietf.org; Thu, 29 Apr 2004 02:42:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08541 for ; Thu, 29 Apr 2004 02:42:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ5Fy-00069i-6j for tcpm@ietf.org; Thu, 29 Apr 2004 02:42:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ5F7-00062L-00 for tcpm@ietf.org; Thu, 29 Apr 2004 02:41:58 -0400 Received: from ftp.netlab.nec.de ([195.37.70.21] helo=ftp.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1BJ5EU-0005uT-00 for tcpm@ietf.org; Thu, 29 Apr 2004 02:41:19 -0400 Received: from netlab.nec.de (scout.netlab.nec.de [195.37.70.100]) by ftp.ccrle.nec.de (Postfix) with ESMTP id 43E67F674; Thu, 29 Apr 2004 08:46:23 +0200 (CEST) Message-ID: <4090A38E.4010801@netlab.nec.de> Date: Thu, 29 Apr 2004 08:41:18 +0200 From: Lars Eggert Organization: NEC Network Laboratories User-Agent: Mozilla Thunderbird 0.6b (Macintosh/20040425) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Henderson, Thomas R" Cc: tcpm@ietf.org Subject: Re: [tcpm] WG consensus sought (deadline 5 May): abort timeout negotiation References: <6938661A6EDA8A4EA8D1419BCE46F24C040605E0@xch-nw-27.nw.nos.boeing.com> In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040605E0@xch-nw-27.nw.nos.boeing.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010602040003090503080201" Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms010602040003090503080201 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Henderson, Thomas R wrote: >>But in these cases, I am not clear >>what is the algorithm to select the timeout value. If poor >>coverage area >>is the only case, then it might be better to let the application solve >>the problem rather than using a TCP option. Some applications/servers >>might not want to keep the connection hanging beyond certain delay >>anyway. > > I think that we should separate mechanism from policy in this > discussion. To me, this is analogous to window scale, from an > application perspective. TCP provides a mechanism whereby, if > applications do a setsockopt() for more buffer space, more > window scale is negotiated. But 1323 doesn't address how an > implementation selects its maximum buffer size. Likewise, it > may be that applications or hosts want a more persistent TCP > connection if possible. The converse may also be true-- > an application may not want to sit around in a lengthy backed > off state, not able to transfer data even though connectivity > was restored (this was discussed in the link-up notification > debate). The peer server can make its own decisions on the > value that it is willing to support. Exactly. Section 2.2 discusses some aspects of using ATOs of various lengths. I should probably preface it with the rationale for not restricting ATO values, which is pretty much what Tom outlined above. This is trying to be a general mechanism and the ID discusses some potential uses. It does not try to restrict the applicability of the option to only those uses by introducing limits. Lars -- Lars Eggert NEC Network Laboratories --------------ms010602040003090503080201 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ/zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNaMIICw6ADAgECAgMLU6IwDQYJKoZIhvcNAQEE BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTAz MTIxNTEyMzEyOFoXDTA0MTIxNDEyMzEyOFowgYQxDzANBgNVBAQTBkVnZ2VydDENMAsGA1UE KhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdn ZXJ0QG5ldGxhYi5uZWMuZGUxIjAgBgkqhkiG9w0BCQEWE2xhcnMuZWdnZXJ0QGdteC5uZXQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWps58Zq8Buu2DKDl9crbvzSo6zWsZ TkQLr5zOTqUMs/eU7Mcohv64O4IxWWYGLfYsjDRxUlmdHdJUbyTtUh2lH452DUDJByXidlLm RDgohG0AVwztedqy1+hE3VnCdpMhUGks+6ntrr3dKSxMgLM0AM1kPWsH9lWX6IOPdxOC30gM PiQ65zH9PR70befQLgFPKcAv0wP8210l05n8ekwYAcq2cm3/j+nuDu0HEh5pgsnY7cVELeNJ ODvr4IiE1t3c2w4+0Nc/WJrqGCMl+gZ8c+7FtzjoyDeEsCjNFDeA2ymNd+10O6kjwvPHlzPr 3rW73RDRPAjMJ49HXlueiuoNAgMBAAGjdzB1MCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwOQYDVR0RBDIwMIEZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5k ZYETbGFycy5lZ2dlcnRAZ214Lm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB AHgrv3SQFD4AS4lY4oKcI3iTHcclEHbYfg3UUb8zzCUsl+OJoz0nmebGmOL+tvNj5GvCrWnN H4LvVLh8ZBhFXms7eKJ1YiHgbKwTRK23P8Y5NDit5ico0ZjpFWeenUWj3ajEbN6n4K8dNp+C 0b2apnSrlFVWY6BucZFIYqQ1Lf91MIIDWjCCAsOgAwIBAgIDC1OiMA0GCSqGSIb3DQEBBAUA MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wMzEy MTUxMjMxMjhaFw0wNDEyMTQxMjMxMjhaMIGEMQ8wDQYDVQQEEwZFZ2dlcnQxDTALBgNVBCoT BExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2Vy dEBuZXRsYWIubmVjLmRlMSIwIAYJKoZIhvcNAQkBFhNsYXJzLmVnZ2VydEBnbXgubmV0MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1qbOfGavAbrtgyg5fXK2780qOs1rGU5E C6+czk6lDLP3lOzHKIb+uDuCMVlmBi32LIw0cVJZnR3SVG8k7VIdpR+Odg1AyQcl4nZS5kQ4 KIRtAFcM7XnastfoRN1ZwnaTIVBpLPup7a693SksTICzNADNZD1rB/ZVl+iDj3cTgt9IDD4k Oucx/T0e9G3n0C4BTynAL9MD/NtdJdOZ/HpMGAHKtnJt/4/p7g7tBxIeaYLJ2O3FRC3jSTg7 6+CIhNbd3NsOPtDXP1ia6hgjJfoGfHPuxbc46Mg3hLAozRQ3gNspjXftdDupI8Lzx5cz6961 u90Q0TwIzCePR15bnorqDQIDAQABo3cwdTAqBgUrZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVN eWZmQk5VYk5KSmNkWjJzMDkGA1UdEQQyMDCBGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGWB E2xhcnMuZWdnZXJ0QGdteC5uZXQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQB4 K790kBQ+AEuJWOKCnCN4kx3HJRB22H4N1FG/M8wlLJfjiaM9J5nmxpji/rbzY+Rrwq1pzR+C 71S4fGQYRV5rO3iidWIh4GysE0Sttz/GOTQ4reYnKNGY6RVnnp1Fo92oxGzep+CvHTafgtG9 mqZ0q5RVVmOgbnGRSGKkNS3/dTGCAzswggM3AgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwCQYFKw4DAhoFAKCCAacwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwNDI5MDY0MTE4WjAjBgkqhkiG 9w0BCQQxFgQUEiHtQ8pqnAmRqoZ5x94my7fdMIowUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECAwtTojB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwDQYJKoZIhvcNAQEBBQAEggEA aNnJzzd24VTPThZGE2Nu4LkCoiueSwFcqh24CJWf/XKVHXetfNDHj5ZsWVqmFP3zife3fHZM 9lVm+mVyf2ksbywG4NreowI15iNZxAC6C+88NG4xxbpEa/FRZfPAB3kkpOGbgdOLAtmo++OK 93jvU1/zjmp26OF+XvMyVcMP+gZMzjeBGKawPjZlb6ez0CgIPMbOWBeG9EXp9qgH/0NTXILg EGFCHOCrdYUCKbED+F5pSYJ77qP566sj2+7aSZG1xyfYE57RsaXOqedYv14d3fCV2GcOQbzB yvjljv1PO+vJS/fR9Wh2g9RM0d438VUDvL+nJEf7N2oRzC0xBz8YowAAAAAAAA== --------------ms010602040003090503080201-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu Apr 29 11:33:52 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09414 for ; Thu, 29 Apr 2004 11:33:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDLT-0005iE-Df for tcpm-archive@odin.ietf.org; Thu, 29 Apr 2004 11:21:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TFL3OD021944 for tcpm-archive@odin.ietf.org; Thu, 29 Apr 2004 11:21:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDC9-0003cl-Ou for tcpm-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 11:11:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08210 for ; Thu, 29 Apr 2004 11:11:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJDBy-0002QW-Bo for tcpm-web-archive@ietf.org; Thu, 29 Apr 2004 11:11:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJDAy-00028z-00 for tcpm-web-archive@ietf.org; Thu, 29 Apr 2004 11:10:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJDA1-0001sL-00 for tcpm-web-archive@ietf.org; Thu, 29 Apr 2004 11:09:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJCoj-00052b-Ey; Thu, 29 Apr 2004 10:47:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJCh9-0002fi-9z for tcpm@optimus.ietf.org; Thu, 29 Apr 2004 10:39:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06062 for ; Thu, 29 Apr 2004 10:39:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJCgy-0001Gv-2C for tcpm@ietf.org; Thu, 29 Apr 2004 10:39:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJCfy-00010k-00 for tcpm@ietf.org; Thu, 29 Apr 2004 10:38:10 -0400 Received: from shockwave.systems.pipex.net ([62.241.160.9]) by ietf-mx with esmtp (Exim 4.12) id 1BJCf0-0000Y2-00 for tcpm@ietf.org; Thu, 29 Apr 2004 10:37:10 -0400 Received: from tom3 (1Cust7.tnt16.lnd4.gbr.da.uu.net [62.188.145.7]) by shockwave.systems.pipex.net (Postfix) with SMTP id 31F971C000ED; Thu, 29 Apr 2004 15:36:39 +0100 (BST) Message-ID: <000501c42df7$1343d0c0$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: "Ted Faber" , Subject: Re: [tcpm] WG consensus sought (deadline 5 May): abort timeout negotiation Date: Thu, 29 Apr 2004 11:34:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,DATE_IN_PAST_03_06 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----Original Message----- From: Ted Faber To: tcpm@ietf.org Date: 28 April 2004 18:57 Subject: [tcpm] WG consensus sought (deadline 5 May): abort timeout negotiation > >The question before the group is "do we want to address negotiating the >abort timeout in TCP?" If we reach a positive consensus on that, we'll >talk about adopting Lars's draft. > The current charter has a number of specific work items on it and from what I see on this list, we will miss the milestone date for each and every one of them. So while this may be a worthwhile activity, I would like to see progress on what we are meant to be doing before considering other items ie defer the question until we have something with the IESG. Tom Petch _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu Apr 29 15:27:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22729 for ; Thu, 29 Apr 2004 15:27:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJH8C-0005NL-1T for tcpm-archive@odin.ietf.org; Thu, 29 Apr 2004 15:23:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TJNa55020658 for tcpm-archive@odin.ietf.org; Thu, 29 Apr 2004 15:23:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJGxO-0006x1-Rk for tcpm-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 15:12:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20869 for ; Thu, 29 Apr 2004 15:12:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJGxI-0003Mc-Hp for tcpm-web-archive@ietf.org; Thu, 29 Apr 2004 15:12:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJGwK-0003Jq-00 for tcpm-web-archive@ietf.org; Thu, 29 Apr 2004 15:11:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJGvi-0003Hk-00 for tcpm-web-archive@ietf.org; Thu, 29 Apr 2004 15:10:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJGhC-0003mg-EH; Thu, 29 Apr 2004 14:55:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJFdl-000624-A5 for tcpm@optimus.ietf.org; Thu, 29 Apr 2004 13:48:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16336 for ; Thu, 29 Apr 2004 13:48:02 -0400 (EDT) From: Yogesh.Swami@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJFdf-0006Gr-K6 for tcpm@ietf.org; Thu, 29 Apr 2004 13:47:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJFcq-0005wF-00 for tcpm@ietf.org; Thu, 29 Apr 2004 13:47:08 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BJFbp-0005aV-00 for tcpm@ietf.org; Thu, 29 Apr 2004 13:46:05 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3THk5G22694; Thu, 29 Apr 2004 20:46:05 +0300 (EET DST) X-Scanned: Thu, 29 Apr 2004 20:45:55 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3THjtq2012984; Thu, 29 Apr 2004 20:45:55 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00pIuwNb; Thu, 29 Apr 2004 20:45:53 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3THjpH01454; Thu, 29 Apr 2004 20:45:51 +0300 (EET DST) Received: from daebe004.NOE.Nokia.com ([10.241.35.104]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 29 Apr 2004 12:45:49 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [tcpm] WG consensus sought (deadline 5 May): abort timeout negotiation Date: Thu, 29 Apr 2004 12:45:49 -0500 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE016E80F1@daebe004.americas.nokia.com> Thread-Topic: [tcpm] WG consensus sought (deadline 5 May): abort timeout negotiation Thread-Index: AcQttkL1PGBI14hZTWeDcliANETD+AAVLYNQ To: , Cc: , X-OriginalArrivalTime: 29 Apr 2004 17:45:49.0979 (UTC) FILETIME=[CF42A6B0:01C42E11] Content-Transfer-Encoding: quoted-printable Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >=20 > Exactly. >=20 > We actually also play with a slightly different scenario,=20 > where the TCP=20 > session runs over HIP. This lets you plug in anywhere - your=20 > connections=20 > are bound to the host identities and thus survive the address=20 > changes at=20 > the new location. The issue then is that by the time you plug=20 > back in,=20 > the retransmission abort timer has on the peers may have=20 > fired and the=20 > connections have been reset. >=20 On the record ... ATO negotiation might be useful, especially for sessions that use secure channels (TLS or SSH as Mark pointed out) and require a password for authentication. It's a hassle to type in the password over and over again every few minutes.=20 So, I'd like to support this as a working group item.=20 Off the record ... I am not sure how ATO will facilitate host portability. There are quite a few roadblocks apart from ATO that affect portability more than ATO. Here are a few: 1. Unless the laptop has a fixed IP address or the DHCP somehow assigns the same address to a particular interface, the session cannot continue. 2. I am skeptical about how soon HIP could be deployed. HIP relies heavily on DNSSec, and one thing I have learned from studying several PKI cases is that it take for ever to materialize. Although DNSSec is not PKI per se, it too will take a long time (10+ years) before being useful. (I might be a little pessimistic here, but ...)=20 3. The application layer itself might have timed session keys so even though the lower layer might be active, the application layer might abort the session for security reasons. But, in spite of all these issues, TCP should do its job .... So I would like to see this as a WG item. Yogesh _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu Apr 29 17:12:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02043 for ; Thu, 29 Apr 2004 17:12:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJIbx-0004h4-Ju for tcpm-archive@odin.ietf.org; Thu, 29 Apr 2004 16:58:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TKwPlF018033 for tcpm-archive@odin.ietf.org; Thu, 29 Apr 2004 16:58:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJI5H-00074E-1X for tcpm-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 16:24:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26398 for ; Thu, 29 Apr 2004 16:24:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJI5A-0000Ti-2d for tcpm-web-archive@ietf.org; Thu, 29 Apr 2004 16:24:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJI25-0007jt-00 for tcpm-web-archive@ietf.org; Thu, 29 Apr 2004 16:21:22 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BJHz8-0007EQ-04 for tcpm-web-archive@ietf.org; Thu, 29 Apr 2004 16:18:19 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BJHWP-0007Fh-FH for tcpm-web-archive@ietf.org; Thu, 29 Apr 2004 15:48:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJHDS-0006y4-4d; Thu, 29 Apr 2004 15:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJH5V-0003uK-3Y for tcpm@optimus.ietf.org; Thu, 29 Apr 2004 15:20:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21965 for ; Thu, 29 Apr 2004 15:20:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJH5O-0003tc-Mg for tcpm@ietf.org; Thu, 29 Apr 2004 15:20:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJH4H-0003pW-00 for tcpm@ietf.org; Thu, 29 Apr 2004 15:19:34 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BJH3u-0003lZ-00 for tcpm@ietf.org; Thu, 29 Apr 2004 15:19:10 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 29 Apr 2004 11:32:04 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3TJIfW9016905; Thu, 29 Apr 2004 12:18:42 -0700 (PDT) Received: from mdalal-u10.cisco.com (mdalal-u10.cisco.com [128.107.162.178]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASO25029; Thu, 29 Apr 2004 12:17:55 -0700 (PDT) Date: Thu, 29 Apr 2004 12:18:41 -0700 (PDT) From: Mitesh Dalal To: Kacheong Poon cc: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt In-Reply-To: <408F11A3.8020704@sun.com> Message-ID: References: <408DC210.4090701@sun.com> <408F11A3.8020704@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi Kacheong, Please see inline. On Tue, 27 Apr 2004, Kacheong Poon wrote: > > FWIW, I do consider your timestamp option as a valid proposition, > > but the very fact that you are banking on an "optional" option > > to fix this problem is speculative, because in this solution > > not only does the client need to upgrade but also the middlebox > > in order for them to not drop your RST and if your answer to this > > is that since its an option and it can be turned off later if > > we find issues then, its like saying that here is a solution that > > I think will work, but I am not confident enough and if you happen > > to find a problem, please turn it off and let the vulnerability > > open again. > > I think the lesson we learned from ECN applies here. If ECN cannot > be turned off in Solaris (there are actually 3 options, off, passive > and active), I don't think Sun can ever include it in a production > version, at least not until we are pretty sure that all middleboxes > are fixed. And Solaris supports ECN since 2002. I think including > it in a production version actually helps the deployment of ECN. > People can use it now if they want. Please do not underestimate the I totally agree with your take above as I also provide a cli to turn the feature on/off when I implemented ECN in IOS. But ECN is more of a new feature addition which is necessarily not benign. As I see it the proposal that we have put forward very much uses the behavior described in 793 to protect its own weakness. Ted Faber succintly summarized our proposal in one of his earlier post. I dont think we are adding new state as such. > power of turning off something. It does not necessarily mean that the > mechanism has issues, it is simply a good engineering practice in a > world full of surprises. I agree. But the objective should be to accommodate most valid 793 compliant scenarios. We may have an offending middlebox that does not follow the spec. It would be difficult to accommodate those and to have a knob to accommodate those would be detrimental, as we would now expect the vast majority of tcp users to adapt to them, rather than have a small bunch of stacks to rectify the implementation. (again I am assuming here that this problem will arise cause somebody did something that was a deviation from the spec, if there are genuine scenarios that can happen with a correct implementation of the base spec, I would really like to hear it) > > Back to the timestamp option. First, RST with timetstamp option is > actually legal according to RFC 1323. And in the case when a middlebox > actually drops a RST with timestamp because of a bug, the result is rfc 1323 says the following: " It is recommended that RST segments NOT carry timestamps, and that RST segments be acceptable regardless of their timestamp. Old duplicate RST segments should be exceedingly unlikely, and their cleanup function should take precedence over timestamps. " So I believe many implementors might actually take it like a MUST kind of thing and not like timestamps in RST. But the next sentence clouds it implying that its possible to see timestamp in RST. So I am not sure what to make of this. Opinions anybody ? > equivalent to dropping a RST. There is no RST/ACK war possible. It > is safe. The connection stays up and if there is something to > retransmit, the sender will eventually time out. Safety is very > important. I think IETF normally recommends conservativeness and > safety. The fact that the vulnerability increases as the window size > increases and timestamp option should be used in these cases makes > this mechanism more attractive. > > > So please put forward scenarios to the WG to ponder that you > > think may not work. If you are successful in doing so, we would > > be more than glad to take back our proposal. > > As I mentioned, what is the method to handle a possible RST/ACK war? I would like to put more thought on this. Could you please elaborate on the RST/ACK war scenario you see happening. > By limiting the number of ACK generated in response to RST? By falling > back to the original TCP method? I think this should be discussed in > the draft. > the next pass of the draft will have more scenarios explaining its backward compatibility and capturing all the questions that have bee raised so far. Thanks Mitesh _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 30 03:09:48 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00038 for ; Fri, 30 Apr 2004 03:09:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJS8F-00073c-CM for tcpm-archive@odin.ietf.org; Fri, 30 Apr 2004 03:08:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3U78Nx6027117 for tcpm-archive@odin.ietf.org; Fri, 30 Apr 2004 03:08:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJS4m-00069j-BF for tcpm-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 03:04:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29917 for ; Fri, 30 Apr 2004 03:04:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJS4f-0003RC-3W for tcpm-web-archive@ietf.org; Fri, 30 Apr 2004 03:04:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJS3g-0003KQ-00 for tcpm-web-archive@ietf.org; Fri, 30 Apr 2004 03:03:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJS32-0003Ey-00 for tcpm-web-archive@ietf.org; Fri, 30 Apr 2004 03:03:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJRzB-0005Sy-ET; Fri, 30 Apr 2004 02:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJRv8-0004oM-H8 for tcpm@optimus.ietf.org; Fri, 30 Apr 2004 02:54:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29443 for ; Fri, 30 Apr 2004 02:54:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJRv1-0002BL-Az for tcpm@ietf.org; Fri, 30 Apr 2004 02:54:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJRu6-00025m-00 for tcpm@ietf.org; Fri, 30 Apr 2004 02:53:46 -0400 Received: from ftp.netlab.nec.de ([195.37.70.21] helo=ftp.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1BJRtj-000200-00 for tcpm@ietf.org; Fri, 30 Apr 2004 02:53:23 -0400 Received: from netlab.nec.de (scout.netlab.nec.de [195.37.70.100]) by ftp.ccrle.nec.de (Postfix) with ESMTP id DD1EEF6B6; Fri, 30 Apr 2004 08:58:29 +0200 (CEST) Message-ID: <4091F7E5.5090400@netlab.nec.de> Date: Fri, 30 Apr 2004 08:53:25 +0200 From: Lars Eggert Organization: NEC Network Laboratories User-Agent: Mozilla Thunderbird 0.6b (Macintosh/20040425) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yogesh.Swami@nokia.com Cc: mallman@icir.org, thomas.r.henderson@boeing.com, tcpm@ietf.org Subject: Re: [tcpm] WG consensus sought (deadline 5 May): abort timeout negotiation References: <025E7DD4182874489CC2F61EE0FA19CE016E80F1@daebe004.americas.nokia.com> In-Reply-To: <025E7DD4182874489CC2F61EE0FA19CE016E80F1@daebe004.americas.nokia.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020705060609000001090208" Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms020705060609000001090208 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Yogesh, thanks for the comments! Yogesh.Swami@nokia.com wrote: > Off the record ... > > I am not sure how ATO will facilitate host portability. There are quite > a few roadblocks apart from ATO that affect portability more than ATO. > Here are a few: > > 1. Unless the laptop has a fixed IP address or the DHCP somehow assigns > the same address to a particular interface, the session cannot continue. True. Connections need to bind to something fairly static, like HIP identities. (The MobileP equivalent - home addresses? - may also work, but I don't know MobileIP very well.) > 2. I am skeptical about how soon HIP could be deployed. HIP relies > heavily on DNSSec, and one thing I have learned from studying several > PKI cases is that it take for ever to materialize. Although DNSSec is > not PKI per se, it too will take a long time (10+ years) before being > useful. (I might be a little pessimistic here, but ...) It only depends on DNSSec for peer authentication. For opportunistic encryption, it doesn't. (We use HIP mainly for its mobility features and not because it adds much in terms of security.) > 3. The application layer itself might have timed session keys so even > though the lower layer might be active, the application layer might > abort the session for security reasons. Also true. But as you know, that's a separate issue of course. If it turns out that once TCP survives intermittent connectivity, application timers start to become an issue, then those protocols and applications will require changes as well. Thanks, Lars -- Lars Eggert NEC Network Laboratories --------------ms020705060609000001090208 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ/zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNaMIICw6ADAgECAgMLU6IwDQYJKoZIhvcNAQEE BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTAz MTIxNTEyMzEyOFoXDTA0MTIxNDEyMzEyOFowgYQxDzANBgNVBAQTBkVnZ2VydDENMAsGA1UE KhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdn ZXJ0QG5ldGxhYi5uZWMuZGUxIjAgBgkqhkiG9w0BCQEWE2xhcnMuZWdnZXJ0QGdteC5uZXQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWps58Zq8Buu2DKDl9crbvzSo6zWsZ TkQLr5zOTqUMs/eU7Mcohv64O4IxWWYGLfYsjDRxUlmdHdJUbyTtUh2lH452DUDJByXidlLm RDgohG0AVwztedqy1+hE3VnCdpMhUGks+6ntrr3dKSxMgLM0AM1kPWsH9lWX6IOPdxOC30gM PiQ65zH9PR70befQLgFPKcAv0wP8210l05n8ekwYAcq2cm3/j+nuDu0HEh5pgsnY7cVELeNJ ODvr4IiE1t3c2w4+0Nc/WJrqGCMl+gZ8c+7FtzjoyDeEsCjNFDeA2ymNd+10O6kjwvPHlzPr 3rW73RDRPAjMJ49HXlueiuoNAgMBAAGjdzB1MCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwOQYDVR0RBDIwMIEZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5k ZYETbGFycy5lZ2dlcnRAZ214Lm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB AHgrv3SQFD4AS4lY4oKcI3iTHcclEHbYfg3UUb8zzCUsl+OJoz0nmebGmOL+tvNj5GvCrWnN H4LvVLh8ZBhFXms7eKJ1YiHgbKwTRK23P8Y5NDit5ico0ZjpFWeenUWj3ajEbN6n4K8dNp+C 0b2apnSrlFVWY6BucZFIYqQ1Lf91MIIDWjCCAsOgAwIBAgIDC1OiMA0GCSqGSIb3DQEBBAUA MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wMzEy MTUxMjMxMjhaFw0wNDEyMTQxMjMxMjhaMIGEMQ8wDQYDVQQEEwZFZ2dlcnQxDTALBgNVBCoT BExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2Vy dEBuZXRsYWIubmVjLmRlMSIwIAYJKoZIhvcNAQkBFhNsYXJzLmVnZ2VydEBnbXgubmV0MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1qbOfGavAbrtgyg5fXK2780qOs1rGU5E C6+czk6lDLP3lOzHKIb+uDuCMVlmBi32LIw0cVJZnR3SVG8k7VIdpR+Odg1AyQcl4nZS5kQ4 KIRtAFcM7XnastfoRN1ZwnaTIVBpLPup7a693SksTICzNADNZD1rB/ZVl+iDj3cTgt9IDD4k Oucx/T0e9G3n0C4BTynAL9MD/NtdJdOZ/HpMGAHKtnJt/4/p7g7tBxIeaYLJ2O3FRC3jSTg7 6+CIhNbd3NsOPtDXP1ia6hgjJfoGfHPuxbc46Mg3hLAozRQ3gNspjXftdDupI8Lzx5cz6961 u90Q0TwIzCePR15bnorqDQIDAQABo3cwdTAqBgUrZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVN eWZmQk5VYk5KSmNkWjJzMDkGA1UdEQQyMDCBGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGWB E2xhcnMuZWdnZXJ0QGdteC5uZXQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQB4 K790kBQ+AEuJWOKCnCN4kx3HJRB22H4N1FG/M8wlLJfjiaM9J5nmxpji/rbzY+Rrwq1pzR+C 71S4fGQYRV5rO3iidWIh4GysE0Sttz/GOTQ4reYnKNGY6RVnnp1Fo92oxGzep+CvHTafgtG9 mqZ0q5RVVmOgbnGRSGKkNS3/dTGCAzswggM3AgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwCQYFKw4DAhoFAKCCAacwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwNDMwMDY1MzI1WjAjBgkqhkiG 9w0BCQQxFgQUQHFSymSkly1PtqR7sMOmP0IsW1owUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECAwtTojB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwDQYJKoZIhvcNAQEBBQAEggEA tE4+br3BBuYys18dbEThQJ5T+8eLK8ujNNlwX37kuSmFylTfUZjQShZ70mxA6PXCIe9d4Vqw 5lAdFVh+/nakFB8RKWVLxwRUwn4Ehqey2XjAXYcWqVwJAelawLnRC63C5v3ZsZTlSKyVOBv7 Ro6t5XHgTuLiw7ubqo1KAKaHRs3FdWUW8JD/HEGB/zZH+oWkiUIkrmPG0bgFLbeYkWwNm/Vf ufdam4eB+Pk72JBpkP6IEUKHXw0DiUuMSnE9T8Xr0mCRKj2pBOlOW4lG+pLTwapwgblB0a4+ kD6O1kSN9FwiCONqzzA9bosranWijprRuC88Js881/PsRjG0Mz8ERQAAAAAAAA== --------------ms020705060609000001090208-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 30 11:23:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08080 for ; Fri, 30 Apr 2004 11:23:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZnk-00005C-PD for tcpm-archive@odin.ietf.org; Fri, 30 Apr 2004 11:19:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UFJi8x032766 for tcpm-archive@odin.ietf.org; Fri, 30 Apr 2004 11:19:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZWt-0005Vo-AE for tcpm-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 11:02:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06216 for ; Fri, 30 Apr 2004 11:02:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJZWq-00076C-Lk for tcpm-web-archive@ietf.org; Fri, 30 Apr 2004 11:02:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJZVx-00073B-00 for tcpm-web-archive@ietf.org; Fri, 30 Apr 2004 11:01:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJZVB-0006zv-00 for tcpm-web-archive@ietf.org; Fri, 30 Apr 2004 11:00:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZMu-0003PX-SI; Fri, 30 Apr 2004 10:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZAP-0001Ug-Kg for tcpm@optimus.ietf.org; Fri, 30 Apr 2004 10:39:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04926 for ; Fri, 30 Apr 2004 10:39:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJZAN-0005ic-87 for tcpm@ietf.org; Fri, 30 Apr 2004 10:39:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJZ9U-0005fr-00 for tcpm@ietf.org; Fri, 30 Apr 2004 10:38:08 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx with esmtp (Exim 4.12) id 1BJZ8a-0005dw-00 for tcpm@ietf.org; Fri, 30 Apr 2004 10:37:12 -0400 Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by wyvern.icir.org (8.12.9p1/8.12.8) with ESMTP id i3UEbBhw008941 for ; Fri, 30 Apr 2004 07:37:11 -0700 (PDT) (envelope-from mallman@icir.org) Received: from lawyers.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by guns.icir.org (Postfix) with ESMTP id 2AF0177AC74 for ; Fri, 30 Apr 2004 10:37:10 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 9B74E1447D3 for ; Fri, 30 Apr 2004 09:17:01 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Reply-To: mallman@icir.org Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Hey Jealousy MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 30 Apr 2004 09:16:59 -0400 Message-Id: <20040430131701.9B74E1447D3@lawyers.icir.org> Subject: [tcpm] security draft input request Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 --=-=-= Content-Type: text/plain Hi folks! We'd first like to thank everyone for the rousing discussion on Randall's security draft. As a next step, we'd like to hear opinions on the path forward -- from a very high level (i.e., about the topic, in general, not the specifics of the i-d). In particular, we'd like to ask folks to pick one of the options that best summarizes your opinion, providing any additional justification as you feel is necessary. Option #1: Do nothing. There is no problem that needs any sort of IETF attention at all. Option #2: Document the problem and the existing techniques that can be used to mitigate the vulnerability. I.e., spell out the attack and that one could use IPsec or the MD5 option to reduce (or eliminate) the vulnerability. Option #3: Document the problem, the existing mitigations, as well as exploring additional mitigations. Note that this "exploration" leaves open the possibility that we will find no mitigations that have consensus. If that is the case, then this option basically becomes option #2 (possibly with some additional thoughts from this group on why we didn't like anything else in the solution space). Option #N: We *think* the above options pretty much cover the space at a high level. However, if you feel there is some slice of the space not covered, please make up a new option. (But, please do this sparingly.) Thanks! Mark & Ted --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin) iD8DBQFAklHLWyrrWs4yIs4RApHwAJ9UAWarDN08+AU6+Z4WSgdCi7iQBgCfebIU kItCNAQfCBxkIEXvp7kJqPI= =a+h5 -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 30 12:28:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12715 for ; Fri, 30 Apr 2004 12:28:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJamV-0004ap-Qx for tcpm-archive@odin.ietf.org; Fri, 30 Apr 2004 12:22:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UGMV2s017651 for tcpm-archive@odin.ietf.org; Fri, 30 Apr 2004 12:22:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJaSy-0008Na-Tr for tcpm-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 12:02:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11355 for ; Fri, 30 Apr 2004 12:02:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJaSx-0004Kv-M0 for tcpm-web-archive@ietf.org; Fri, 30 Apr 2004 12:02:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJaRu-0004Hf-00 for tcpm-web-archive@ietf.org; Fri, 30 Apr 2004 12:01:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJaRY-0004F0-00 for tcpm-web-archive@ietf.org; Fri, 30 Apr 2004 12:00:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJaLx-00079t-6r; Fri, 30 Apr 2004 11:55:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJaBM-0005Sb-Ep for tcpm@optimus.ietf.org; Fri, 30 Apr 2004 11:44:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10098 for ; Fri, 30 Apr 2004 11:44:05 -0400 (EDT) From: AClarke@attotech.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJaBL-0002yL-8E for tcpm@ietf.org; Fri, 30 Apr 2004 11:44:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJaAN-0002v7-00 for tcpm@ietf.org; Fri, 30 Apr 2004 11:43:08 -0400 Received: from sw.attotech.com ([12.32.232.56] helo=noteserv1.attotech.com) by ietf-mx with esmtp (Exim 4.12) id 1BJa9W-0002ra-00; Fri, 30 Apr 2004 11:42:14 -0400 Subject: Re: [tcpm] security draft input request To: mallman@icir.org Cc: tcpm@ietf.org, tcpm-admin@ietf.org Message-ID: Date: Fri, 30 Apr 2004 11:42:04 -0400 MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=0ABBE415DFC007248f9e8a93df938690918c0ABBE415DFC00724" Content-Disposition: inline Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 --0__=0ABBE415DFC007248f9e8a93df938690918c0ABBE415DFC00724 Content-type: text/plain; charset=us-ascii Hello, I have been following this WG since this draft was submitted (to the public). We are implementing a particular long-lived TCP application - iSCSI. If I may, I vote for option #2. My reasons are presented in the context of implementing iSCSI in a firmware device, but I think they would be true of other applications. For iSCSI the security considerations are covered in the rfc (rfc3720) and further in a separate rfc (rfc3723). Please review for yourself but In short, IPSec is recommended. I think that minor TCP updates for security will give a false sense of security (no pun intended) and will need constant revision as attackers undoubtedly will outsmart the fixes. I'm sure that the entire internet cannot update its TCP stack for every new threat. In particular, I do not want to have to implement IPSec as required, then also change the TCP stack for every new threat that can happen with IPSec disabled. I also wonder if some of these issues, if they need to be acted on, are better placed in the security area of the ietf. At least I do not see any mention of security in the TCPM work group description or goals. I appreciate any comments and do not wish to devalue any of the work that has been done. Regards, Aaron Clarke aclarke@attotech.com Mark Allman cc: Sent by: Subject: [tcpm] security draft input request tcpm-admin@ietf.o rg 04/30/2004 09:16 AM Please respond to mallman Hi folks! We'd first like to thank everyone for the rousing discussion on Randall's security draft. As a next step, we'd like to hear opinions on the path forward -- from a very high level (i.e., about the topic, in general, not the specifics of the i-d). In particular, we'd like to ask folks to pick one of the options that best summarizes your opinion, providing any additional justification as you feel is necessary. Option #1: Do nothing. There is no problem that needs any sort of IETF attention at all. Option #2: Document the problem and the existing techniques that can be used to mitigate the vulnerability. I.e., spell out the attack and that one could use IPsec or the MD5 option to reduce (or eliminate) the vulnerability. Option #3: Document the problem, the existing mitigations, as well as exploring additional mitigations. Note that this "exploration" leaves open the possibility that we will find no mitigations that have consensus. If that is the case, then this option basically becomes option #2 (possibly with some additional thoughts from this group on why we didn't like anything else in the solution space). Option #N: We *think* the above options pretty much cover the space at a high level. However, if you feel there is some slice of the space not covered, please make up a new option. (But, please do this sparingly.) Thanks! Mark & Ted (See attached file: att8yd6p.dat) --0__=0ABBE415DFC007248f9e8a93df938690918c0ABBE415DFC00724 Content-type: application/octet-stream; name="att8yd6p.dat" Content-Disposition: attachment; filename="att8yd6p.dat" Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYxLjIuMiAoRGFy d2luKQ0KDQppRDhEQlFGQWtsSExXeXJyV3M0eUlzNFJBcEh3QUo5VUFXYXJETjA4K0FVNitaNFdT Z2RDaTdpUUJnQ2ZlYklVDQprSXRDTkFRZkNCeGtJRVh2cDdrSnFQST0NCj1hK2g1DQotLS0tLUVO RCBQR1AgU0lHTkFUVVJFLS0tLS0= --0__=0ABBE415DFC007248f9e8a93df938690918c0ABBE415DFC00724-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri Apr 30 17:37:52 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05870 for ; Fri, 30 Apr 2004 17:37:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJfZL-0006Cl-Ed for tcpm-archive@odin.ietf.org; Fri, 30 Apr 2004 17:29:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3ULTF94023851 for tcpm-archive@odin.ietf.org; Fri, 30 Apr 2004 17:29:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJfSS-0003bR-9m for tcpm-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 17:22:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04568 for ; Fri, 30 Apr 2004 17:22:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJfSP-0003SK-UB for tcpm-web-archive@ietf.org; Fri, 30 Apr 2004 17:22:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJfQa-00035n-00 for tcpm-web-archive@ietf.org; Fri, 30 Apr 2004 17:20:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJfN2-0002fy-00 for tcpm-web-archive@ietf.org; Fri, 30 Apr 2004 17:16:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJf82-0004oe-Ie; Fri, 30 Apr 2004 17:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJeF5-0004aj-Hy for tcpm@optimus.ietf.org; Fri, 30 Apr 2004 16:04:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27503 for ; Fri, 30 Apr 2004 16:04:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJeF3-0000Ok-Qk for tcpm@ietf.org; Fri, 30 Apr 2004 16:04:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJeE5-0000LB-00 for tcpm@ietf.org; Fri, 30 Apr 2004 16:03:14 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1BJeDL-0000EA-00 for tcpm@ietf.org; Fri, 30 Apr 2004 16:02:28 -0400 Received: from jurassic.eng.sun.com ([129.146.87.31]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3UK0ums015675; Fri, 30 Apr 2004 13:00:56 -0700 (PDT) Received: from sun.com (shield.SFBay.Sun.COM [129.144.60.49]) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i3UK0u3O721264; Fri, 30 Apr 2004 13:00:56 -0700 (PDT) Message-ID: <4092B077.9000609@sun.com> Date: Fri, 30 Apr 2004 13:00:55 -0700 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.6) Gecko/20040117 X-Accept-Language: en, zh-hk, zh-tw, zh-cn MIME-Version: 1.0 To: Mitesh Dalal CC: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: <408DC210.4090701@sun.com> <408F11A3.8020704@sun.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tcpm-admin@ietf.org Errors-To: tcpm-admin@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: TCP Maintenance and Minor Extensions Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mitesh Dalal wrote: > I totally agree with your take above as I also provide a > cli to turn the feature on/off when I implemented ECN in IOS. > But ECN is more of a new feature addition which is > necessarily not benign. As I see it the proposal that we > have put forward very much uses the behavior described in > 793 to protect its own weakness. > Ted Faber succintly summarized our proposal in one of his > earlier post. I dont think we are adding new state as such. I don't agree that the current proposal uses the "behavior described in 793" for protection. Responding to a RST is not a correct behavior. It is very clear in RFC 793 what a RST means. A stack can ignore the RST (pretend that the RST is dropped elsewhere (-:), but responding to it is bad. I think any proposal suggesting a response to a RST is not acceptable to a host vendor. > I agree. But the objective should be to accommodate most > valid 793 compliant scenarios. We may have an offending > middlebox that does not follow the spec. It would be > difficult to accommodate those and to have a knob to > accommodate those would be detrimental, as we would now > expect the vast majority of tcp users to adapt to them, > rather than have a small bunch of stacks to rectify the > implementation. (again I am assuming here that this problem > will arise cause somebody did something that was a > deviation from the spec, if there are genuine scenarios that > can happen with a correct implementation of the base spec, > I would really like to hear it) Note that RFC 793 does not specify how a middlebox should work. And a middlebox which won't break any current RFC 793 conforming stack can still have problems with the proposed changes. For example, as I mentioned in a previous mail, a middlebox caching a RST for retransmission is quite acceptable to a RFC 793 conforming stack. The stack will take the RST. With the proposed change in TCP behavior, this will not be the case and may lead to a RST/ACK war. I am not advocating that any protocol improvement should stop because of middlebox. Unfortunately, middlebox is a fact of life. And the proposed change for a problem which already has more than one solution, TCP MD5 option and IPsec, does not justify a change in the base TCP protocol behavior. This is especially true as the change is not really a protocol improvement, IMHO. > rfc 1323 says the following: > > " > It is recommended that RST segments NOT carry timestamps, and that > RST segments be acceptable regardless of their timestamp. Old > duplicate RST segments should be exceedingly unlikely, and > their cleanup function should take precedence over > timestamps. > " > > So I believe many implementors might actually take it like a > MUST kind of thing and not like timestamps in RST. But the > next sentence clouds it implying that its possible to see > timestamp in RST. So I am not sure what to make of this. > Opinions anybody ? I expect a normal stack will just ignore the timestamp in the RST. I think this is the behavior of most, if not all, host stacks out there. So sending a RST with timestamps to those stacks should cause no harm. Note that a host stack normally is quite "liberal" in what it accepts. Unless there is a clear MUST, a host stack will take the extra effort to make things work. The simple reason is that a host stack needs to talk to some many different kinds of TCP implementations out there... As I mentioned in a previous email, a TCP level option can be used to tell a stack what it needs to do with timestamp option. I'll get to this in the short draft I said I would submit. I hope I can do it during this weekend. > I would like to put more thought on this. Could you please > elaborate on the RST/ACK war scenario you see happening. The key here is what should happen if the RST is "always" not acceptable to a modified stack. A simple solution may be to keep a counter there for the number of RST it has responded to with an ACK. But I don't really think that it is a good idea to patch up things for the wrong reason: responding to a RST. -- K. Poon. kacheong.poon@sun.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm