From exim@www1.ietf.org Sat May 1 13:42:16 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05220 for ; Sat, 1 May 2004 13:40: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 1BJyRE-0001Gs-7c for tcpm-archive@odin.ietf.org; Sat, 01 May 2004 13:38:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i41Hc8NL004886 for tcpm-archive@odin.ietf.org; Sat, 1 May 2004 13:38:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJy34-00018t-GU for tcpm-web-archive@optimus.ietf.org; Sat, 01 May 2004 13:13: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 NAA03598 for ; Sat, 1 May 2004 13:13: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 1BJy32-0005sF-Kh for tcpm-web-archive@ietf.org; Sat, 01 May 2004 13:13:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJy0Q-0003bH-00 for tcpm-web-archive@ietf.org; Sat, 01 May 2004 13:10:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJxyk-0002CV-00 for tcpm-web-archive@ietf.org; Sat, 01 May 2004 13:08:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJxXy-0007N8-Ly; Sat, 01 May 2004 12:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJwAn-0000aM-6D for tcpm@optimus.ietf.org; Sat, 01 May 2004 11:13: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 LAA24384 for ; Sat, 1 May 2004 11:12: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 1BJwAm-0000yi-CT for tcpm@ietf.org; Sat, 01 May 2004 11:13:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJw9k-0000lO-00 for tcpm@ietf.org; Sat, 01 May 2004 11:11:56 -0400 Received: from mercury.is.co.za ([196.4.160.222]) by ietf-mx with esmtp (Exim 4.12) id 1BJw8k-0000QI-00 for tcpm@ietf.org; Sat, 01 May 2004 11:10:54 -0400 Received: from hypatia.dns.net (c4-rba-412.dial-up.net [196.39.31.113]) by mercury.is.co.za (Postfix) with ESMTP id 7D762C02BB; Sat, 1 May 2004 17:10:50 +0200 (SAST) Received: (from andras@localhost) by hypatia.dns.net (8.11.3/8.11.3) id i41ElST06853; Sat, 1 May 2004 16:47:28 +0200 Date: Sat, 1 May 2004 16:47:27 +0200 From: Andras Salamon To: tcpm@ietf.org Subject: Re: [tcpm] security draft input request Message-ID: <20040501144727.GA6533@dns.net> References: <20040430131701.9B74E1447D3@lawyers.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040430131701.9B74E1447D3@lawyers.icir.org> User-Agent: Mutt/1.5.6i 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.5 required=5.0 tests=AWL,ROUND_THE_WORLD_LOCAL autolearn=no version=2.60 On Fri, Apr 30, 2004 at 09:16:59AM -0400, Mark Allman wrote: > 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 #2: Count me in for this one. Perhaps some of the folks over on the IDR working group should also be nudged to recommend randomized source ports for BGP connections. As pointed out by Christian Huitema, this would remove one of the four pillars of an attack. Unfortunately, draft-ietf-idr-bgp-implementation-00.txt did not consider source port randomization in the survey. draft-ietf-idr-restart-09.txt and draft-ietf-idr-bgp-gr-survey-01.txt do address the bad BGP application behaviour resulting from TCP connections terminating unexpectedly, knocking out one of the other pillars. -- Andras Salamon andras@dns.net _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon May 3 03:23: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 DAA11632 for ; Mon, 3 May 2004 03:23: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 1BKXjV-0005Hm-D2 for tcpm-archive@odin.ietf.org; Mon, 03 May 2004 03:19:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i437JLfB020318 for tcpm-archive@odin.ietf.org; Mon, 3 May 2004 03:19:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKXdl-00030s-Ma for tcpm-web-archive@optimus.ietf.org; Mon, 03 May 2004 03: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 DAA11110 for ; Mon, 3 May 2004 03:13: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 1BKXdj-0006RW-AU for tcpm-web-archive@ietf.org; Mon, 03 May 2004 03:13:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKXZl-0005p5-00 for tcpm-web-archive@ietf.org; Mon, 03 May 2004 03:09:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKXWe-0005DM-00 for tcpm-web-archive@ietf.org; Mon, 03 May 2004 03:06:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKXK2-0002tO-Px; Mon, 03 May 2004 02:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKXEe-0008Lz-0t for tcpm@optimus.ietf.org; Mon, 03 May 2004 02:47: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 CAA09834 for ; Mon, 3 May 2004 02:47: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 1BKXEa-0001yv-74 for tcpm@ietf.org; Mon, 03 May 2004 02:47:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKXBT-0001SC-00 for tcpm@ietf.org; Mon, 03 May 2004 02:44:12 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1BKX7z-0000kh-00 for tcpm@ietf.org; Mon, 03 May 2004 02:40:35 -0400 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Sun, 2 May 2004 23:40:27 -0700 Received: from 157.54.8.23 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 02 May 2004 23:40:04 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 2 May 2004 23:40:02 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Sun, 2 May 2004 23:39:58 -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); Sun, 2 May 2004 23:39:50 -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] security draft input request Date: Sun, 2 May 2004 23:39:52 -0700 Message-ID: Thread-Topic: [tcpm] security draft input request Thread-Index: AcQux3Um0odRM2b1T7+SxzwhC8HvHgCED9mg From: "Christian Huitema" To: , X-OriginalArrivalTime: 03 May 2004 06:39:50.0821 (UTC) FILETIME=[6F660550:01C430D9] 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 > Option #2: >=20 > 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. The MD5 option is specific to BGP, and should not be mentioned in a generic TCP document. The proper mitigations are: 1) Use IPSEC: this entirely eliminates the attack, including when the attacker is on-path. 2) Use a security protocol over the TCP connection, such as SSL, TLS, or application specific security protocols (e.g. MD5 signature of BGP packets): this mitigates the risk of data injection, but does not mitigate the denial of service attacks. 3) Randomize one of the two port numbers used in the TCP connection, generally the calling port: proper randomization effectively mitigates the attacks by making them less interesting than alternative DOS attacks, unless the attacker is on-path. > Option #3: >=20 > 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). I believe we should do option 2 in any case, i.e. document how a proper use of TCP can reduce the vulnerability. Since few applications are actually at risk, we should recommend that applications that are at risk implement the simple fixes (IPSEC or port randomization). This will defuse any sense of urgency, and give us time to agree on any fixes to the TCP protocol. -- Christian Huitema _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon May 3 11:51: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 LAA09280 for ; Mon, 3 May 2004 11:51: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 1BKffd-0002hw-4b for tcpm-archive@odin.ietf.org; Mon, 03 May 2004 11:47:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43FlrUp010408 for tcpm-archive@odin.ietf.org; Mon, 3 May 2004 11:47:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKfYe-0001Ot-AG for tcpm-web-archive@optimus.ietf.org; Mon, 03 May 2004 11:40: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 LAA08643 for ; Mon, 3 May 2004 11:40: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 1BKfYd-0001iz-53 for tcpm-web-archive@ietf.org; Mon, 03 May 2004 11:40:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKfXk-0001fV-00 for tcpm-web-archive@ietf.org; Mon, 03 May 2004 11:39:45 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKfWw-0001cl-00 for tcpm-web-archive@ietf.org; Mon, 03 May 2004 11:38:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKfPJ-0007Tu-8c; Mon, 03 May 2004 11:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKfGH-0000Ko-H1 for tcpm@optimus.ietf.org; Mon, 03 May 2004 11:21: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 LAA07763 for ; Mon, 3 May 2004 11:21: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 1BKfGG-0000YG-GU for tcpm@ietf.org; Mon, 03 May 2004 11:21:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKfFI-0000UN-00 for tcpm@ietf.org; Mon, 03 May 2004 11:20:41 -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 1BKfEO-0000Or-00 for tcpm@ietf.org; Mon, 03 May 2004 11:19:44 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 03 May 2004 07:33:20 +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 i43FJBW9007587; Mon, 3 May 2004 08:19:12 -0700 (PDT) Received: from cisco.com (rtp-dial-1-124.cisco.com [10.83.97.124]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATQ27289; Mon, 3 May 2004 08:19:08 -0700 (PDT) Message-ID: <40966289.3060700@cisco.com> Date: Mon, 03 May 2004 11:17:29 -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: Christian Huitema CC: mallman@icir.org, tcpm@ietf.org Subject: Re: [tcpm] security draft input request 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 Christian: I have a question about random ports... I have been told that some ACL/Firewalls will block out ranges of ports for peers to get through on (this seems a bit hard from me to accept so I have sent a email to the source of the news asking for clearification)... if this is true then randomization of ports would be interfered with by middle boxes as well... sigh.. Have you heard of such a thing happening in the world ... Coding for middle boxes in an end2end protocol... gee seems like fun dosn't it :-0 R Christian Huitema wrote: >>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. >> >> > >The MD5 option is specific to BGP, and should not be mentioned in a >generic TCP document. The proper mitigations are: > >1) Use IPSEC: this entirely eliminates the attack, including when the >attacker is on-path. >2) Use a security protocol over the TCP connection, such as SSL, TLS, or >application specific security protocols (e.g. MD5 signature of BGP >packets): this mitigates the risk of data injection, but does not >mitigate the denial of service attacks. >3) Randomize one of the two port numbers used in the TCP connection, >generally the calling port: proper randomization effectively mitigates >the attacks by making them less interesting than alternative DOS >attacks, unless the attacker is on-path. > > > >>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). >> >> > >I believe we should do option 2 in any case, i.e. document how a proper >use of TCP can reduce the vulnerability. Since few applications are >actually at risk, we should recommend that applications that are at risk >implement the simple fixes (IPSEC or port randomization). This will >defuse any sense of urgency, and give us time to agree on any fixes to >the TCP protocol. > >-- Christian Huitema > >_______________________________________________ >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 May 3 13:12:39 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14501 for ; Mon, 3 May 2004 13:12: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 1BKgme-000597-Hj for tcpm-archive@odin.ietf.org; Mon, 03 May 2004 12:59:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43GxCrt019782 for tcpm-archive@odin.ietf.org; Mon, 3 May 2004 12:59:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKgfE-0003Ty-53 for tcpm-web-archive@optimus.ietf.org; Mon, 03 May 2004 12:51: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 MAA13183 for ; Mon, 3 May 2004 12:51: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 1BKgfC-0000Bp-G0 for tcpm-web-archive@ietf.org; Mon, 03 May 2004 12:51:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKgeI-00002t-00 for tcpm-web-archive@ietf.org; Mon, 03 May 2004 12:50:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKgdB-0007ff-00 for tcpm-web-archive@ietf.org; Mon, 03 May 2004 12:49:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKgWy-0000tT-Q4; Mon, 03 May 2004 12: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 1BKgIF-0005Yc-N3 for tcpm@optimus.ietf.org; Mon, 03 May 2004 12:27: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 MAA11266 for ; Mon, 3 May 2004 12:27: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 1BKgIE-0005Bg-4Z for tcpm@ietf.org; Mon, 03 May 2004 12:27:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKgHX-00057u-00 for tcpm@ietf.org; Mon, 03 May 2004 12:27:04 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BKgGz-00052M-00 for tcpm@ietf.org; Mon, 03 May 2004 12:26:29 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 03 May 2004 09:26:01 -0700 Received: from ananth-u5.cisco.com (ananth-u5.cisco.com [128.107.162.225]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i43GPv0R019064; Mon, 3 May 2004 09:25:57 -0700 (PDT) Date: Mon, 3 May 2004 09:25:57 -0700 (PDT) From: Anantha Ramaiah To: "Randall Stewart (cisco)" cc: Christian Huitema , mallman@icir.org, tcpm@ietf.org Subject: Re: [tcpm] security draft input request In-Reply-To: <40966289.3060700@cisco.com> Message-ID: References: <40966289.3060700@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.1 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, 3 May 2004, Randall Stewart (cisco) wrote: > Christian: > > I have a question about random ports... I have been > told that some ACL/Firewalls will block out ranges of ports > for peers to get through on (this seems a bit hard from me > to accept so I have sent a email to the source of the news > asking for clearification)... if this is true then randomization > of ports would be interfered with by middle boxes as well... sigh.. > > Have you heard of such a thing happening in the world ... > > Coding for middle boxes in an end2end protocol... gee seems like > fun dosn't it :-0 It does sound funny. If the middleboxes chose to ignore the e2e changes, then I wonder it is whose problem? TCP was not written to take into account the middlebox compatibility, it is the other way round. :) -Anantha > > R > > Christian Huitema wrote: > > >>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. > >> > >> > > > >The MD5 option is specific to BGP, and should not be mentioned in a > >generic TCP document. The proper mitigations are: > > > >1) Use IPSEC: this entirely eliminates the attack, including when the > >attacker is on-path. > >2) Use a security protocol over the TCP connection, such as SSL, TLS, or > >application specific security protocols (e.g. MD5 signature of BGP > >packets): this mitigates the risk of data injection, but does not > >mitigate the denial of service attacks. > >3) Randomize one of the two port numbers used in the TCP connection, > >generally the calling port: proper randomization effectively mitigates > >the attacks by making them less interesting than alternative DOS > >attacks, unless the attacker is on-path. > > > > > > > >>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). > >> > >> > > > >I believe we should do option 2 in any case, i.e. document how a proper > >use of TCP can reduce the vulnerability. Since few applications are > >actually at risk, we should recommend that applications that are at risk > >implement the simple fixes (IPSEC or port randomization). This will > >defuse any sense of urgency, and give us time to agree on any fixes to > >the TCP protocol. > > > >-- Christian Huitema > > > >_______________________________________________ > >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 Mon May 3 13:13:09 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14539 for ; Mon, 3 May 2004 13:13: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 1BKgmp-0005BA-Aj for tcpm-archive@odin.ietf.org; Mon, 03 May 2004 12:59:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43GxNFU019903 for tcpm-archive@odin.ietf.org; Mon, 3 May 2004 12:59:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKgfy-0003n6-AW for tcpm-web-archive@optimus.ietf.org; Mon, 03 May 2004 12:52: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 MAA13227 for ; Mon, 3 May 2004 12:52: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 1BKgfw-0000Ji-Ia for tcpm-web-archive@ietf.org; Mon, 03 May 2004 12:52:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKgf6-0000B5-00 for tcpm-web-archive@ietf.org; Mon, 03 May 2004 12:51:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKge8-00001w-00 for tcpm-web-archive@ietf.org; Mon, 03 May 2004 12:50:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKgXx-00010x-6M; Mon, 03 May 2004 12: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 1BKgJ5-0005os-UL for tcpm@optimus.ietf.org; Mon, 03 May 2004 12:28: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 MAA11294 for ; Mon, 3 May 2004 12:28: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 1BKgJ4-0005FW-HU for tcpm@ietf.org; Mon, 03 May 2004 12:28:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKgI6-0005AV-00 for tcpm@ietf.org; Mon, 03 May 2004 12:27:38 -0400 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1BKgH9-00053K-00 for tcpm@ietf.org; Mon, 03 May 2004 12:26:39 -0400 Received: from mail5.microsoft.com ([157.54.6.156]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 3 May 2004 09:26:09 -0700 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Mon, 3 May 2004 09:26:07 -0700 Received: from 157.54.8.23 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 03 May 2004 09:26:07 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 3 May 2004 09:26:05 -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, 3 May 2004 09:26:06 -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, 3 May 2004 09:25:56 -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] security draft input request Date: Mon, 3 May 2004 09:25:59 -0700 Message-ID: Thread-Topic: [tcpm] security draft input request Thread-Index: AcQxIgPEUt3Dza56T+Sd46ugSMg8EAABTcUA From: "Christian Huitema" To: "Randall Stewart \(cisco\)" Cc: , X-OriginalArrivalTime: 03 May 2004 16:25:56.0129 (UTC) FILETIME=[4F8E3110:01C4312B] 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 have a question about random ports... I have been > told that some ACL/Firewalls will block out ranges of ports > for peers to get through on (this seems a bit hard from me > to accept so I have sent a email to the source of the news > asking for clearification)... if this is true then randomization > of ports would be interfered with by middle boxes as well... sigh.. Firewalls do indeed block random port numbers, as well as random combinations of TCP flags. However, firewalls typically classify connections as incoming or outgoing, and will typically only examine the "server" port, i.e. the destination port in the first SYN packet. For example, a web connection is typically established to port 80 from a random source port, and firewalls don't block that.=20 In the case of BGP, instead of starting a connection from port 179 to port 179, routers could presumably start a connection from a random port to port 179. It would take a very stubborn firewall to allow a connection to 179 from 179, and block a connection from random to 179.=20 There are two ways of obtaining this randomization of the source port. Using the socket API, the simplest way is to simply leave the source port number unspecified, and rely on the OS to implement randomization. The more complex way is to draw a random port number in the application and bind to that port number before issuing the socket call; the programmer will have to manage collisions if the port happens to be already in use. The firewall issue does limit what the OS can do. This is not so much an issue with BGP as it is with some applications that do not use fixed port numbers for either the servers or the clients; instead, the clients rely on a name service (RPCDSS for RPC and DCOM in Windows) or a signaling service (SIP or H.323) to learn both the address and the listening port of the server. Some firewalls attempt to accommodate these applications by guessing the range of ports that the applications will use, and then opening that range. This creates an "application compatibility" issue: if we change the way in which the OS allocates port numbers, we risk picking ports that these firewalls don't expect. Users will see an RPC or H.323 application suddenly fail after an OS upgrade, and they will question the sanity of the upgrade. But the firewall compatibility issue does not occur when the server side of the application uses a fixed port, such as 179. Firewalls can be reliably programmed to allow or disallow BGP, or any fixed port application. For these applications, and specially for critical applications like BGP, it makes a lot of sense to explicitly bind to a random port number before issuing a connect call. (Add mandatory reference to RFC 1750 for the choice of random numbers.) You will get a solution that is robust, regardless of the level of port randomization or TCP protection implemented in the platform. -- Christian Huitema _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon May 3 15:34:44 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24362 for ; Mon, 3 May 2004 15:34: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 1BKj7c-0005VD-KJ for tcpm-archive@odin.ietf.org; Mon, 03 May 2004 15:29:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43JT01U021152 for tcpm-archive@odin.ietf.org; Mon, 3 May 2004 15:29:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKiuu-0001tR-Ml for tcpm-web-archive@optimus.ietf.org; Mon, 03 May 2004 15:15: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 PAA22750 for ; Mon, 3 May 2004 15:15: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 1BKiut-0000rm-EM for tcpm-web-archive@ietf.org; Mon, 03 May 2004 15:15:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKitz-0000l0-00 for tcpm-web-archive@ietf.org; Mon, 03 May 2004 15:14:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKitL-0000ez-00 for tcpm-web-archive@ietf.org; Mon, 03 May 2004 15:14:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKijW-0006VG-2M; Mon, 03 May 2004 15: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 1BKiRt-0006HE-9L for tcpm@optimus.ietf.org; Mon, 03 May 2004 14:45: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 OAA19870 for ; Mon, 3 May 2004 14:45: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 1BKiRo-0004wY-4t for tcpm@ietf.org; Mon, 03 May 2004 14:45:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKiQz-0004rf-00 for tcpm@ietf.org; Mon, 03 May 2004 14:44:58 -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 1BKiQi-0004lo-00 for tcpm@ietf.org; Mon, 03 May 2004 14:44:40 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i43Ii8C1003991; Mon, 3 May 2004 11:44:08 -0700 (PDT) Received: from cisco.com (rtp-dial-1-124.cisco.com [10.83.97.124]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATQ53030; Mon, 3 May 2004 11:44:04 -0700 (PDT) Message-ID: <40969291.8030803@cisco.com> Date: Mon, 03 May 2004 14:42:25 -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: Christian Huitema CC: mallman@icir.org, tcpm@ietf.org Subject: Re: [tcpm] security draft input request 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 Christian: I am aware of the methods to get randomized ports... and it seemed kinda funny to me.... Here is a quote from the response email I got from one of my colleages... " Yes, it's true, and yes, it's a huge problem. RTP can be anywhere in the range 16384 to 32768. We have ALGs to open single ports dynamically, but they break when the voice signaling is encrypted as we're now doing in CCM 4.0. As an alternate, we can let those ports initiate a connection through the firewall (or used the "established" param in an ACL) as long as it originates on a more trusted interface. That works as long as all of the devices on the more trusted interface will begin streaming media as soon as the connection is open. Virtually everything will do that with the possible exception of conference bridges and transcoders. But it's not just RTP we're worried about, and unfortunately, we're weak on the details. That's why I'm working on it right now. But for instance, IPMA uses a random port somewhere in the 5000-6000 range. There's no ALG for that. H.323 can use a myriad of ports. Fortunately, we usually don't have to let them out to the end user community. I know there's more, but I can't tell you what they are right now. Give me a couple of weeks and I should know a whole lot more. But it scares me when something new comes along and suggests we use random ports. " So it would appear that true random ports will cause some apps pain too... sigh.. it appears that middle boxes do further and further nasty things... or maybe its like fire arms.. its not the weapons themselves but the people who use them that cause the problems :-0 When I get further details I will forward them on to the list. R Christian Huitema wrote: >>I have a question about random ports... I have been >>told that some ACL/Firewalls will block out ranges of ports >>for peers to get through on (this seems a bit hard from me >>to accept so I have sent a email to the source of the news >>asking for clearification)... if this is true then randomization >>of ports would be interfered with by middle boxes as well... sigh.. >> >> > >Firewalls do indeed block random port numbers, as well as random >combinations of TCP flags. However, firewalls typically classify >connections as incoming or outgoing, and will typically only examine the >"server" port, i.e. the destination port in the first SYN packet. For >example, a web connection is typically established to port 80 from a >random source port, and firewalls don't block that. > >In the case of BGP, instead of starting a connection from port 179 to >port 179, routers could presumably start a connection from a random port >to port 179. It would take a very stubborn firewall to allow a >connection to 179 from 179, and block a connection from random to 179. > >There are two ways of obtaining this randomization of the source port. >Using the socket API, the simplest way is to simply leave the source >port number unspecified, and rely on the OS to implement randomization. >The more complex way is to draw a random port number in the application >and bind to that port number before issuing the socket call; the >programmer will have to manage collisions if the port happens to be >already in use. > >The firewall issue does limit what the OS can do. This is not so much an >issue with BGP as it is with some applications that do not use fixed >port numbers for either the servers or the clients; instead, the clients >rely on a name service (RPCDSS for RPC and DCOM in Windows) or a >signaling service (SIP or H.323) to learn both the address and the >listening port of the server. Some firewalls attempt to accommodate >these applications by guessing the range of ports that the applications >will use, and then opening that range. This creates an "application >compatibility" issue: if we change the way in which the OS allocates >port numbers, we risk picking ports that these firewalls don't expect. >Users will see an RPC or H.323 application suddenly fail after an OS >upgrade, and they will question the sanity of the upgrade. > >But the firewall compatibility issue does not occur when the server side >of the application uses a fixed port, such as 179. Firewalls can be >reliably programmed to allow or disallow BGP, or any fixed port >application. For these applications, and specially for critical >applications like BGP, it makes a lot of sense to explicitly bind to a >random port number before issuing a connect call. (Add mandatory >reference to RFC 1750 for the choice of random numbers.) You will get a >solution that is robust, regardless of the level of port randomization >or TCP protection implemented in the platform. > >-- Christian Huitema > >_______________________________________________ >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 May 3 18:07: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 SAA06996 for ; Mon, 3 May 2004 18:07: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 1BKlW3-0005Jf-8A for tcpm-archive@odin.ietf.org; Mon, 03 May 2004 18:02:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43M2Nbm020432 for tcpm-archive@odin.ietf.org; Mon, 3 May 2004 18:02:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKlEa-00007E-V7 for tcpm-web-archive@optimus.ietf.org; Mon, 03 May 2004 17:44: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 RAA05163 for ; Mon, 3 May 2004 17:44: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 1BKlEY-0007cu-E1 for tcpm-web-archive@ietf.org; Mon, 03 May 2004 17:44:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKlDZ-0007SS-00 for tcpm-web-archive@ietf.org; Mon, 03 May 2004 17:43:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKlCb-0007IT-00 for tcpm-web-archive@ietf.org; Mon, 03 May 2004 17:42:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKl2K-0002eI-Om; Mon, 03 May 2004 17:31:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKkMB-0005G9-DQ for tcpm@optimus.ietf.org; Mon, 03 May 2004 16:48: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 QAA29721 for ; Mon, 3 May 2004 16: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 1BKkM9-0005jh-D7 for tcpm@ietf.org; Mon, 03 May 2004 16:48:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKkLP-0005bC-00 for tcpm@ietf.org; Mon, 03 May 2004 16:47:20 -0400 Received: from scmail.arc.com ([63.206.101.3]) by ietf-mx with esmtp (Exim 4.12) id 1BKkKX-0005N7-00 for tcpm@ietf.org; Mon, 03 May 2004 16:46:25 -0400 Received: from scexch01.arc.com (scexch01 [192.9.200.149]) by scmail.arc.com (8.12.8/8.12.5) with SMTP id i43KSjux008583 for ; Mon, 3 May 2004 13:28:45 -0700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Importance: normal Priority: normal Content-Transfer-Encoding: 7bit Subject: [tcpm] security draft input request Date: Mon, 3 May 2004 13:45:55 -0700 Message-ID: <2EFAFC388B9C4C48B581846AEC20A020016CA87A@scexch01.arc.com> Thread-Topic: [tcpm] security draft input request thread-index: AcQxT6FiNhB1t21kTHqJcJ3ZY7Ggtg== From: "Charlet, Ricky" To: 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 Howdy, I've just joined this list because of specific interest in draft-ietf-tcpm-tcpsecure-00.txt. I browsed the archives so far on this and feel that TCPM will achieve a consensus solution in about a year if at all. (don't take that as meanness on my part, I know the pain of moving discussions forward in IETF). With regard to Mark Allman's request about which direction to head off in (menu choice of options...) could I chip in this idea: Do draft-ietf-tcpm-tcpsecure-00.txt as an informational RFC and all its patches to be included under a socket option. That way the application has control of if the new behavior is on/off and can make interoperability/security tradeoff decisions based upon its own particular environment. Then this WG can collect field experience and do a standards track RFC at a more realistic pace. If anyone cares about were I am coming from... I am the network protocols engineer for a small commercial RTOS. Some of my customers have applications (other than BGP) which do in fact rely on long-lived TCP connections. They've read the news. They've assessed their application's (real) vulnerability. They want a patch yesterday. I want to satisfy them but not move so far out ahead of IETF that I get my branch cut off behind me. Therefore, I'm tossing the idea of a two track pace out to this working group. Do something quick and informational under a socket option and figure out the wise path at a normal pace. --- Ricky Charlet Ricky.Charlet@arc.com USA 831.466.4968 ----------------------------------------------------------- Unless otherwise expressly stated, this message does not create or vary any contractual relationship between you and ARC International. The contents of this e-mail may be confidential and if you have received it in error, please delete it from your system, destroy any hard copies and telephone the above number. Incoming emails to ARC may be subject to monitoring other than by the addressee. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon May 3 18:22: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 SAA08380 for ; Mon, 3 May 2004 18:22: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 1BKlaw-0000eh-Cz for tcpm-archive@odin.ietf.org; Mon, 03 May 2004 18:07:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43M7Q3t002500 for tcpm-archive@odin.ietf.org; Mon, 3 May 2004 18:07:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKlYd-0007Ih-5q for tcpm-web-archive@optimus.ietf.org; Mon, 03 May 2004 18:05: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 SAA06705 for ; Mon, 3 May 2004 18:04: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 1BKlYa-0002mk-Ep for tcpm-web-archive@ietf.org; Mon, 03 May 2004 18:05:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKlXo-0002fC-00 for tcpm-web-archive@ietf.org; Mon, 03 May 2004 18:04:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKlWo-0002XB-00 for tcpm-web-archive@ietf.org; Mon, 03 May 2004 18:03:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKlFJ-0000TO-3P; Mon, 03 May 2004 17:45:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKl5S-0004D5-Bi for tcpm@optimus.ietf.org; Mon, 03 May 2004 17:34: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 RAA03717 for ; Mon, 3 May 2004 17: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 1BKl5P-0005iF-Us for tcpm@ietf.org; Mon, 03 May 2004 17:34:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKl1u-0005GX-00 for tcpm@ietf.org; Mon, 03 May 2004 17:31:15 -0400 Received: from artax.karlin.mff.cuni.cz ([195.113.31.125] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1BKl0X-0004t6-00 for tcpm@ietf.org; Mon, 03 May 2004 17:29:49 -0400 Received: by artax.karlin.mff.cuni.cz (Postfix, from userid 17421) id 34FE94131; Mon, 3 May 2004 23:30:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by artax.karlin.mff.cuni.cz (Postfix) with ESMTP id 3466740F7 for ; Mon, 3 May 2004 23:30:44 +0200 (CEST) Date: Mon, 3 May 2004 23:30:44 +0200 (CEST) From: Mikulas Patocka To: tcpm@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [tcpm] TCP hangs 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 This is tcpdump of hung TCP connection (from paranoia.kolej.mff.cuni.cz's point of view). What do you think, which machine did misbehave? 213.29.7.213 is a Linux box. paranoia.kolej.mff.cuni.cz is stack that I wrote myself. Linux is sending only ACKs without any data as zero-window probes. My stack ignores them. It it wrong or not? From my reading of RFCs, I thought that zero-window probe must contain some new unacked data. Linux people told me that it doesn't have to, but I didn't find it mentioned in RFCs. I also have no idea how to distinguish between normal ACKs (to which TCP should not respond) and zero-window probe ACKs (to which I should reply with another ACK). Mikulas 16:34:49.832097 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: SWE 1711254266:1711254266(0) win 8192 16:34:49.838957 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: S 1163781419:1163781419(0) ack 1711254267 win 5840 16:34:49.838968 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: P ack 1 win 8 16:34:49.840002 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: P 1:500(499) ack 1 win 8 16:34:49.847349 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . ack 500 win 6432 16:34:49.863592 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . 1:1461(1460) ack 500 win 6432 16:34:49.863651 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: P ack 1461 win 6 16:34:49.867490 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . 1461:2921(1460) ack 500 win 6432 16:34:49.867558 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: P ack 2921 win 6 16:34:49.871498 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . 2921:4381(1460) ack 500 win 6432 16:34:49.871567 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: P ack 4381 win 5 16:34:49.872729 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . 4381:5841(1460) ack 500 win 6432 16:34:49.872777 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: P ack 5841 win 3 16:34:49.875631 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . 7301:8761(1460) ack 500 win 6432 16:34:49.875714 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: P ack 5841 win 3 16:34:49.876881 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . 5841:7301(1460) ack 500 win 6432 16:34:49.876953 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: P ack 8761 win 0 16:34:49.907290 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: P ack 8761 win 2 ^^^^ this packet was probably lost or the last two were reordered 16:34:50.088544 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . ack 500 win 6432 16:34:50.512936 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . ack 500 win 6432 ^^^ this looks to me like a bug --- window probe doesn't contain data 16:34:51.348911 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . ack 500 win 6432 16:34:53.028754 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . ack 500 win 6432 16:34:56.389624 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . ack 500 win 6432 16:35:03.110512 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . ack 500 win 6432 ^^^ exponential backoff on window probes is fine, except that the packets are pure acks 16:35:16.552095 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . ack 500 win 6432 16:35:43.435482 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . ack 500 win 6432 16:35:58.706896 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: FP 500:500(0) ack 8761 win 17 ^^^ paranoia closed the connection without receiving any data 16:35:58.717487 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . 10221:11681(1460) ack 501 win 6432 16:35:58.717569 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: R 501:501(0) ack 11681 win 0 16:35:58.718673 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . 8761:10221(1460) ack 501 win 6432 16:35:58.718692 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: R 501:501(0) ack 10221 win 0 16:35:58.720054 IP 213.29.7.213.http > paranoia.kolej.mff.cuni.cz.65461: . 11681:13141(1460) ack 501 win 6432 16:35:58.720074 IP paranoia.kolej.mff.cuni.cz.65461 > 213.29.7.213.http: R 501:501(0) ack 13141 win 0 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue May 4 04:48:49 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 EAA17658 for ; Tue, 4 May 2004 04:48: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 1BKvaK-0001zE-GR for tcpm-archive@odin.ietf.org; Tue, 04 May 2004 04:47:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i448lSJx007637 for tcpm-archive@odin.ietf.org; Tue, 4 May 2004 04:47:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKvXT-0001CW-BS for tcpm-web-archive@optimus.ietf.org; Tue, 04 May 2004 04:44: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 EAA17517 for ; Tue, 4 May 2004 04: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 1BKvXQ-0005JS-Du for tcpm-web-archive@ietf.org; Tue, 04 May 2004 04:44:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKvWT-00057B-00 for tcpm-web-archive@ietf.org; Tue, 04 May 2004 04:43:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKvVU-0004vA-00 for tcpm-web-archive@ietf.org; Tue, 04 May 2004 04:42:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKvQD-0007kR-7y; Tue, 04 May 2004 04:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKvNr-0007Ad-5i for tcpm@optimus.ietf.org; Tue, 04 May 2004 04:34: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 EAA17034 for ; Tue, 4 May 2004 04:34: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 1BKvNo-0003KZ-6c for tcpm@ietf.org; Tue, 04 May 2004 04:34:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKvMg-00038H-00 for tcpm@ietf.org; Tue, 04 May 2004 04:33:22 -0400 Received: from mail.enyo.de ([212.9.189.167]) by ietf-mx with esmtp (Exim 4.12) id 1BKvLt-0002yD-00 for tcpm@ietf.org; Tue, 04 May 2004 04:32:33 -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 1BKvLt-0004sM-3u; Tue, 04 May 2004 10:32:33 +0200 Received: from fw by deneb with local (Exim 4.32) id 1BKvLs-0001Aa-Fw; Tue, 04 May 2004 10:32:32 +0200 To: mallman@icir.org Cc: tcpm@ietf.org Subject: Re: [tcpm] security draft input request References: <20040430131701.9B74E1447D3@lawyers.icir.org> From: Florian Weimer Date: Tue, 04 May 2004 10:32:32 +0200 In-Reply-To: <20040430131701.9B74E1447D3@lawyers.icir.org> (Mark Allman's message of "Fri, 30 Apr 2004 09:16:59 -0400") Message-ID: <877jvswq1r.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 Mark Allman writes: > 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). I'm in favor of this option, but I could live with #2 as well. Apart from that, I feel that the draft, as proposed, is not ready for publication as an RFC, informational or not. -- Current mail filters: many dial-up/DSL/cable modem hosts, and the following domains: atlas.cz, bigpond.com, di-ve.com, hotmail.com, jumpy.it, libero.it, netscape.net, postino.it, simplesnet.pt, 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 Tue May 4 11:54:35 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 LAA09737 for ; Tue, 4 May 2004 11:54: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 1BL2Eq-00020Q-0N for tcpm-archive@odin.ietf.org; Tue, 04 May 2004 11:53:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44FrhSW007706 for tcpm-archive@odin.ietf.org; Tue, 4 May 2004 11:53:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL2Cp-0001ia-2v for tcpm-web-archive@optimus.ietf.org; Tue, 04 May 2004 11:51: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 LAA09538 for ; Tue, 4 May 2004 11:51: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 1BL2Cn-00050j-TZ for tcpm-web-archive@ietf.org; Tue, 04 May 2004 11:51:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL2Bq-0004v1-00 for tcpm-web-archive@ietf.org; Tue, 04 May 2004 11:50:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL2Av-0004qE-00 for tcpm-web-archive@ietf.org; Tue, 04 May 2004 11:49:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL28K-0000Mv-ER; Tue, 04 May 2004 11:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL20F-0006wW-Rn for tcpm@optimus.ietf.org; Tue, 04 May 2004 11:38: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 LAA09061 for ; Tue, 4 May 2004 11:38: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 1BL20E-00047n-Lx for tcpm@ietf.org; Tue, 04 May 2004 11:38:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL1zK-00043o-00 for tcpm@ietf.org; Tue, 04 May 2004 11:37:42 -0400 Received: from mercury.is.co.za ([196.4.160.222]) by ietf-mx with esmtp (Exim 4.12) id 1BL1yY-0003zx-00 for tcpm@ietf.org; Tue, 04 May 2004 11:36:55 -0400 Received: from hypatia.dns.net (c11-rba-139.dial-up.net [196.39.0.139]) by mercury.is.co.za (Postfix) with ESMTP id 4C7C1BF72E; Tue, 4 May 2004 17:36:51 +0200 (SAST) Received: (from andras@localhost) by hypatia.dns.net (8.11.3/8.11.3) id i44F1Du18007; Tue, 4 May 2004 17:01:13 +0200 Date: Tue, 4 May 2004 17:01:13 +0200 From: Andras Salamon To: tcpm@ietf.org Subject: Re: [tcpm] security draft input request Message-ID: <20040504150113.GE17696@dns.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i 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.9 required=5.0 tests=AWL,ROUND_THE_WORLD_LOCAL autolearn=no version=2.60 On Mon, May 03, 2004 at 09:25:59AM -0700, Christian Huitema wrote: > In the case of BGP, instead of starting a connection from port 179 to > port 179, routers could presumably start a connection from a random port > to port 179. It would take a very stubborn firewall to allow a > connection to 179 from 179, and block a connection from random to 179. Unfortunately, we saw something similar when the default zone transfer settings for the BIND DNS name server changed. For many years, BIND used source port 53 when initiating TCP zone transfers (the destination port for these is of course 53), and some years ago the default changed to use a random source port. It took several years for the BIND port randomization to penetrate the firewall community and for middleware boxes to stop blocking zone transfer attempts from newer BIND servers. A lot of firewall implementors seem to believe that attackers are unable to spoof source ports. It would be nice if firewall implementors understood that specifying any source port is trivial, that script kiddie attack kits already do this, and that firewall rule sets therefore should not rely on source port numbers to classify goodness or badness of packets. However, we need to start nudging the process even if it is going to take several years to filter into the less enlightened parts of the net, so I still suggest the BGP people (Pekka et al?) be encouraged to explicitly mention that random source ports are allowed. This is fine according to the BGP standards, but for some reason everyone seems to have derived firewall rule sets from the existing implementations instead of the standards -- just like with DNS. If we agree with the existing usage, then we should formalise the de facto usage in the standards process. If we disagree, then we should tell the middleware people to conform to the standards. Since when does middleware dictate protocol standards, anyway -- what happened to the end-to-end argument? -- Andras Salamon andras@dns.net _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue May 4 12:31: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 MAA11580 for ; Tue, 4 May 2004 12:31: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 1BL2na-00047E-3R for tcpm-archive@odin.ietf.org; Tue, 04 May 2004 12:29:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44GTcjh015815 for tcpm-archive@odin.ietf.org; Tue, 4 May 2004 12:29:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL2li-0003Pe-0B for tcpm-web-archive@optimus.ietf.org; Tue, 04 May 2004 12:27: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 MAA11320 for ; Tue, 4 May 2004 12:27: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 1BL2lg-0000DJ-IU for tcpm-web-archive@ietf.org; Tue, 04 May 2004 12:27:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL2kl-00008f-00 for tcpm-web-archive@ietf.org; Tue, 04 May 2004 12:26:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL2kB-00004A-00 for tcpm-web-archive@ietf.org; Tue, 04 May 2004 12:26:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL2dN-0001c1-Uz; Tue, 04 May 2004 12:19:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL2TK-00065w-94 for tcpm@optimus.ietf.org; Tue, 04 May 2004 12:08: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 MAA10515 for ; Tue, 4 May 2004 12:08: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 1BL2TI-0006US-UY for tcpm@ietf.org; Tue, 04 May 2004 12:08:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL2SS-0006QZ-00 for tcpm@ietf.org; Tue, 04 May 2004 12:07:49 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx with esmtp (Exim 4.12) id 1BL2Rc-0006Lv-00 for tcpm@ietf.org; Tue, 04 May 2004 12:06:56 -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 i44G6ohw076116; Tue, 4 May 2004 09:06:50 -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 DD56377A71D; Tue, 4 May 2004 12:06:48 -0400 (EDT) To: AClarke@attotech.com From: Mark Allman Reply-To: mallman@icir.org Cc: tcpm@ietf.org Subject: Re: [tcpm] security draft input request In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Little Miss Can't Be Wrong MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 04 May 2004 12:06:48 -0400 Message-Id: <20040504160648.DD56377A71D@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 > 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. I agree with this statement. But, from the analysis in the i-d it would seem as if the technique makes these blind attacks quite hard. Do you have further thoughts into the vulnerability of the proposed scheme? If you do, I think that would be very useful to hear. allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAl7+YWyrrWs4yIs4RAvqxAKCKwCWy/965E6pAJEeBp1j8xU7NAACff0oB 2sm2OQaN0wpbmcJlUnjmwyY= =oGfs -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue May 4 12:37: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 MAA11790 for ; Tue, 4 May 2004 12:37: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 1BL2pO-0004mH-NM for tcpm-archive@odin.ietf.org; Tue, 04 May 2004 12:31:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44GVUVN018360 for tcpm-archive@odin.ietf.org; Tue, 4 May 2004 12:31:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL2nc-00047v-RQ for tcpm-web-archive@optimus.ietf.org; Tue, 04 May 2004 12:29: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 MAA11393 for ; Tue, 4 May 2004 12:29: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 1BL2nb-0000PA-7m for tcpm-web-archive@ietf.org; Tue, 04 May 2004 12:29:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL2mh-0000It-00 for tcpm-web-archive@ietf.org; Tue, 04 May 2004 12:28:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL2lm-0000E5-00 for tcpm-web-archive@ietf.org; Tue, 04 May 2004 12:27:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL2dX-0001kv-BO; Tue, 04 May 2004 12:19:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL2ZE-0000B5-FH for tcpm@optimus.ietf.org; Tue, 04 May 2004 12:14: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 MAA10759 for ; Tue, 4 May 2004 12:14: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 1BL2ZD-00070I-2w for tcpm@ietf.org; Tue, 04 May 2004 12:14:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL2YM-0006wI-00 for tcpm@ietf.org; Tue, 04 May 2004 12:13:54 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx with esmtp (Exim 4.12) id 1BL2Xl-0006rr-00 for tcpm@ietf.org; Tue, 04 May 2004 12:13:17 -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 i44GAdhw076165; Tue, 4 May 2004 09:10:40 -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 52F2577A71D; Tue, 4 May 2004 12:10:38 -0400 (EDT) To: Kacheong Poon From: Mark Allman Reply-To: mallman@icir.org Cc: Mitesh Dalal , tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt In-Reply-To: <4092B077.9000609@sun.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Little Miss Can't Be Wrong MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 04 May 2004 12:10:38 -0400 Message-Id: <20040504161038.52F2577A71D@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 > 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 that the proposed scheme is not rfc793 conformant. But, I don't see how the last sentence above follows from the previous few. We can evolve and change. RFC793 has been and will continue to be updated. (I'm not arguing that the proposed change is The Way To Go, just trying to understand your argument.) Thanks! allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAl8B+WyrrWs4yIs4RArsNAJ96H4a/tjf7cTfclX2b+pjBUsNVuACdHVAB k/Le0IzJCbSjOsIqRp0b28Q= =37hV -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue May 4 14:30: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 OAA18359 for ; Tue, 4 May 2004 14:30: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 1BL4cE-0006jH-8v for tcpm-archive@odin.ietf.org; Tue, 04 May 2004 14:26:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44IQ21a025863 for tcpm-archive@odin.ietf.org; Tue, 4 May 2004 14:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL4UK-0004Oa-IR for tcpm-web-archive@optimus.ietf.org; Tue, 04 May 2004 14:17: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 OAA17290 for ; Tue, 4 May 2004 14:17: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 1BL4UI-0003Rc-3r for tcpm-web-archive@ietf.org; Tue, 04 May 2004 14:17:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL4TK-0003MA-00 for tcpm-web-archive@ietf.org; Tue, 04 May 2004 14:16:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL4Sh-0003H0-00 for tcpm-web-archive@ietf.org; Tue, 04 May 2004 14:16:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL4Oe-0002dp-LF; Tue, 04 May 2004 14:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL4Bt-0006qh-Sb for tcpm@optimus.ietf.org; Tue, 04 May 2004 13:58: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 NAA16010 for ; Tue, 4 May 2004 13:58:47 -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 1BL4Br-0001LZ-Cy for tcpm@ietf.org; Tue, 04 May 2004 13:58:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL4Aw-0001Fi-00 for tcpm@ietf.org; Tue, 04 May 2004 13:57:50 -0400 Received: from noteserv1.attotech.com ([12.32.232.51]) by ietf-mx with esmtp (Exim 4.12) id 1BL4A9-0001AR-00; Tue, 04 May 2004 13:57:01 -0400 Subject: Re: [tcpm] security draft input request To: mallman@icir.org, tcpm@ietf.org, tcpm-admin@ietf.org Message-ID: Date: Tue, 4 May 2004 13:56:41 -0400 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.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 >> 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. >I agree with this statement. But, from the analysis in the i-d it would >seem as if the technique makes these blind attacks quite hard. Do you >have further thoughts into the vulnerability of the proposed scheme? If >you do, I think that would be very useful to hear. That's a fair question, I don't have any specific technical issues in mind at this time. I planned on spending more time looking at the i-d until you posted your input request. You did ask for high-level non i-d specific input, and it seems to me if we settle on option 1 or 2 the i-d is not relevant. If I am mistaken, please let me know more about how things will move forward with the i-d so that I can be more helpful. Aaron _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue May 4 14:38:47 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19357 for ; Tue, 4 May 2004 14:38: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 1BL4fQ-0007oj-H2 for tcpm-archive@odin.ietf.org; Tue, 04 May 2004 14:29:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44ITKHE030043 for tcpm-archive@odin.ietf.org; Tue, 4 May 2004 14:29:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL4bC-0006Mr-EE for tcpm-web-archive@optimus.ietf.org; Tue, 04 May 2004 14:24: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 OAA17856 for ; Tue, 4 May 2004 14:24: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 1BL4b9-0004FH-Ts for tcpm-web-archive@ietf.org; Tue, 04 May 2004 14:24:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL4aK-000499-00 for tcpm-web-archive@ietf.org; Tue, 04 May 2004 14:24:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL4Zf-00042W-00 for tcpm-web-archive@ietf.org; Tue, 04 May 2004 14:23:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL4Qb-0003Jb-Cq; Tue, 04 May 2004 14: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 1BL4Gj-0008ET-6U for tcpm@optimus.ietf.org; Tue, 04 May 2004 14:03: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 OAA16325 for ; Tue, 4 May 2004 14:03: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 1BL4Gg-0001tz-RM for tcpm@ietf.org; Tue, 04 May 2004 14:03:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL4Ft-0001nh-00 for tcpm@ietf.org; Tue, 04 May 2004 14:02:58 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx with esmtp (Exim 4.12) id 1BL4Ew-0001fW-00 for tcpm@ietf.org; Tue, 04 May 2004 14:01:58 -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 i44I1uhw077770; Tue, 4 May 2004 11:01:56 -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 8E69377A71D; Tue, 4 May 2004 14:01:54 -0400 (EDT) To: AClarke@attotech.com From: Mark Allman Reply-To: mallman@icir.org Cc: tcpm@ietf.org Subject: Re: [tcpm] security draft input request In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Little Miss Can't Be Wrong MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 04 May 2004 14:01:54 -0400 Message-Id: <20040504180154.8E69377A71D@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 > That's a fair question, I don't have any specific technical issues in > mind at this time. I planned on spending more time looking at the i-d > until you posted your input request. You did ask for high-level non > i-d specific input, and it seems to me if we settle on option 1 or 2 > the i-d is not relevant. If I am mistaken, please let me know more > about how things will move forward with the i-d so that I can be more > helpful. You are right. I was just curious as to whether there were specifics of the given proposal that were making you shy away from choosing that option. Thanks, allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAl9qSWyrrWs4yIs4RAr63AJ9oobNknPUDd5T9GKczVr45KeHd6QCfUPuh t2t+9M0HA/Be/UC7ThalYUw= =tLvz -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue May 4 14:52:33 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20539 for ; Tue, 4 May 2004 14:52: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 1BL50G-0005Li-3A for tcpm-archive@odin.ietf.org; Tue, 04 May 2004 14:50:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44Ioqjr020558 for tcpm-archive@odin.ietf.org; Tue, 4 May 2004 14:50:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL4rj-0002wl-ET for tcpm-web-archive@optimus.ietf.org; Tue, 04 May 2004 14:42: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 OAA19621 for ; Tue, 4 May 2004 14:42: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 1BL4rg-0006Wt-PV for tcpm-web-archive@ietf.org; Tue, 04 May 2004 14:42:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL4qn-0006Oy-00 for tcpm-web-archive@ietf.org; Tue, 04 May 2004 14:41:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL4ph-0006GY-00 for tcpm-web-archive@ietf.org; Tue, 04 May 2004 14:39:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL4lu-0001Be-5E; Tue, 04 May 2004 14: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 1BL4dG-0006wl-Ij for tcpm@optimus.ietf.org; Tue, 04 May 2004 14:27: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 OAA18046 for ; Tue, 4 May 2004 14:27: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 1BL4dE-0004Vh-0L for tcpm@ietf.org; Tue, 04 May 2004 14:27:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL4cE-0004N4-00 for tcpm@ietf.org; Tue, 04 May 2004 14:26:03 -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 1BL4bV-0004E7-00 for tcpm@ietf.org; Tue, 04 May 2004 14:25:17 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 04 May 2004 10:39:06 +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 i44IOjW9009792; Tue, 4 May 2004 11:24:45 -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 ASW60919; Tue, 4 May 2004 11:23:57 -0700 (PDT) Date: Tue, 4 May 2004 11:24:43 -0700 (PDT) From: Mitesh Dalal To: Mark Allman cc: Kacheong Poon , tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt In-Reply-To: <20040504161038.52F2577A71D@guns.icir.org> Message-ID: References: <20040504161038.52F2577A71D@guns.icir.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.0 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, 4 May 2004, Mark Allman wrote: > > > 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 that the proposed scheme is not rfc793 conformant. But, I don't > see how the last sentence above follows from the previous few. We can > evolve and change. RFC793 has been and will continue to be updated. > (I'm not arguing that the proposed change is The Way To Go, just trying > to understand your argument.) Here are few of my thoughts to the above discussion: There are 2 main aspects of our solution that needs justification as to how they may fit into the existing spec. 1. Only an exact match RST is acceptable. (as opposed to a RST within window) 2. Sending an ACK for an in-window RST (as opposed to aborting the connection). The case 1 above is easy to see. An RST is unreliable and can be dropped in the network. Hence if we drop a RST that was in window but not an exact match, we can safely assume that it was never send. No harm done. I believe Kacheong and others have already figured this out. Now case 2 above: Here is a scenario which can readily happen with base spec. A and B are peers in ESTAB state. B is sendind data to A. data 2 gets dropped. B has a critical failure, decides to send a RST. sequence number 4 is within window of A. A sends ACKs; which are in flight relative to RST 4, for data 1 and 3 (hence I have shown the RST to reach A after the ACK has been sent out). But as far as B (and the imaginary middlebox) is concerned, it appeared later in time wrt to RST and may have actually be triggered by the RST itself. B has no way of knowing this. It will ultimately send an RST with a sequence number that was borrowed from the ACK. So, if this scenario cannot be successfully handled by middleboxes and endhosts, it may not be able to handle our changes as well. The point I am trying to emphasize is sending an ACK looks totally benign and is still looks like a plausible scenario within the semantics of the base spec. A B |<----1---2-----3--------<--------| | | | <--RST--4---------| |---------> ACK 1--------> | |---------> ACK 1 (for 3) | |<---RST-4--- | | | | <--RST-1------------------------| similarly for the SYN part, ACKs from A to B maybe in flight, when a SYN lands up at A. Middleboxes and endhost have no way of knowing if the ACK was send after the SYN was received at A or otherwise and given the liberal principle, they will still need to act on it based on the guidelines laid down in 793. Further, I even hypothesize that the middleboxes on receiving the SYN, will actually send a RST to the inside endhost and not simply forward the SYN and hence converting the SYN scenario to a RST scenario. If there are no middleboxes, our fix is even more cleaner (except for the very rare scenario where the SYN carries an ISN that matches our rcv.nxt-1) The above logic can be extrapolated if we put in a middlebox. Difference will be seen based on where the RST gets dropped, between the middlebox and B or between the middlebox and A. But since both of them have equal probability of happening, we can safely disregard the details. Thanks Mitesh _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue May 4 16:01:58 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 QAA25935 for ; Tue, 4 May 2004 16:01: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 1BL64R-0006DP-2D for tcpm-archive@odin.ietf.org; Tue, 04 May 2004 15:59:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44JxFUY023891 for tcpm-archive@odin.ietf.org; Tue, 4 May 2004 15: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 1BL5wX-0004fH-NA for tcpm-web-archive@optimus.ietf.org; Tue, 04 May 2004 15:51: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 PAA25385 for ; Tue, 4 May 2004 15: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 1BL5wW-0006mT-7t for tcpm-web-archive@ietf.org; Tue, 04 May 2004 15:51:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL5vc-0006f4-00 for tcpm-web-archive@ietf.org; Tue, 04 May 2004 15:50:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL5vA-0006X9-00 for tcpm-web-archive@ietf.org; Tue, 04 May 2004 15: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 1BL5pi-0002fx-Ns; Tue, 04 May 2004 15: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 1BL5jm-0001AS-Bj for tcpm@optimus.ietf.org; Tue, 04 May 2004 15:37: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 PAA24561 for ; Tue, 4 May 2004 15: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 1BL5jk-0005BD-Vf for tcpm@ietf.org; Tue, 04 May 2004 15:37:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL5ir-00055B-00 for tcpm@ietf.org; Tue, 04 May 2004 15:36:58 -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 1BL5iW-0004yz-00 for tcpm@ietf.org; Tue, 04 May 2004 15:36:36 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 04 May 2004 11:49:12 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i44Ja3C1011650; Tue, 4 May 2004 12:36:04 -0700 (PDT) Received: from cisco.com (rtp-dial-1-191.cisco.com [10.83.97.191]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATR77191; Tue, 4 May 2004 12:35:59 -0700 (PDT) Message-ID: <4097F039.5000906@cisco.com> Date: Tue, 04 May 2004 15:34:17 -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: Mark Allman , Kacheong Poon , tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: <20040504161038.52F2577A71D@guns.icir.org> 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,HTML_MESSAGE autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mitesh: I agree with your logic.. but I think the salient point that Kacheong and others are trying to make is on a "hypothetical middle box" This middle box: a) When seeing a RST caches it in its state and marks the entry to be destroyed (the peer is gone now). b) The RST arrives with the wrong seq number so the draft has them send back an ACK. c) The middle box gets this and realizes that the peer is gone (and so is the pin-hole in the firewall) so instead of following RFC793 it resends the cached RST instead of creating one from the ACK like it should d) goto step Now first of all: 1) This is really silly behaviour... after all if you were to follow the spec you need LESS code and LESS state, i.e. why would you want to save a RST when you have to be capable of creating one from an ACK anyway (imagine the connection goes dormant for a LONG time.. and the middle box state gets cleaned up.. it has to know how to send a RST from the ACK).. and you store less in memory in your state blob.. 2) No one has yet pointed to a middle box that does this... It is nothing but ... hey this could happen with a buggy middle box...AFAIK I would like someone to point out an actual box that does this.. not something from ten years ago.. but some network gear that is out there and waiting for this pit to happen.. if it does exists then it is a concern since you would have an ACK war until after the middle box cleaned up its state (that could last minutes or more). If this mythical box does not exist.. then its a moot point and not an issue... I can dream up hundreds of "broken middle box" scenarios that break existing TCP and cause all sorts of other horrible things.. hey this and others may be out there.. I would like to know if it is true... or just imagination... R Mitesh Dalal wrote: >On Tue, 4 May 2004, Mark Allman wrote: > > > >>>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 that the proposed scheme is not rfc793 conformant. But, I don't >>see how the last sentence above follows from the previous few. We can >>evolve and change. RFC793 has been and will continue to be updated. >>(I'm not arguing that the proposed change is The Way To Go, just trying >>to understand your argument.) >> >> > >Here are few of my thoughts to the above discussion: > >There are 2 main aspects of our solution that needs justification >as to how they may fit into the existing spec. > >1. Only an exact match RST is acceptable. >(as opposed to a RST within window) > >2. Sending an ACK for an in-window RST >(as opposed to aborting the connection). > >The case 1 above is easy to see. An RST is unreliable and can be >dropped in the network. Hence if we drop a RST that was in window >but not an exact match, we can safely assume that it was never send. >No harm done. I believe Kacheong and others have already figured this out. > >Now case 2 above: > >Here is a scenario which can readily happen with base spec. A and >B are peers in ESTAB state. B is sendind data to A. data 2 gets >dropped. B has a critical failure, decides to send a RST. sequence >number 4 is within window of A. A sends ACKs; which are in flight >relative to RST 4, for data 1 and 3 (hence I have shown the RST >to reach A after the ACK has been sent out). But as far as B (and the >imaginary middlebox) is concerned, it appeared later in time wrt to >RST and may have actually be triggered by the RST itself. B has no >way of knowing this. It will ultimately send an RST with a sequence >number that was borrowed from the ACK. So, if this scenario cannot be >successfully handled by middleboxes and endhosts, it may not be able >to handle our changes as well. The point I am trying to emphasize is >sending an ACK looks totally benign and is still looks like a plausible >scenario within the semantics of the base spec. > >A B >|<----1---2-----3--------<--------| >| | >| <--RST--4---------| >|---------> ACK 1--------> | >|---------> ACK 1 (for 3) | >|<---RST-4--- | >| | >| <--RST-1------------------------| > > >similarly for the SYN part, ACKs from A to B maybe in flight, when >a SYN lands up at A. Middleboxes and endhost have no way of knowing >if the ACK was send after the SYN was received at A or otherwise and >given the liberal principle, they will still need to act on it based >on the guidelines laid down in 793. >Further, I even hypothesize that the middleboxes on receiving the >SYN, will actually send a RST to the inside endhost and not >simply forward the SYN and hence converting the SYN scenario to >a RST scenario. If there are no middleboxes, our fix is even more >cleaner (except for the very rare scenario where the SYN carries >an ISN that matches our rcv.nxt-1) > >The above logic can be extrapolated if we put in a middlebox. >Difference will be seen based on where the RST gets dropped, between >the middlebox and B or between the middlebox and A. But since both >of them have equal probability of happening, we can safely disregard >the details. > >Thanks >Mitesh > > >_______________________________________________ >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 Tue May 4 22:33: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 WAA16147 for ; Tue, 4 May 2004 22:33: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 1BLCBd-00020M-VA for tcpm-archive@odin.ietf.org; Tue, 04 May 2004 22:31:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i452V518007704 for tcpm-archive@odin.ietf.org; Tue, 4 May 2004 22:31:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLC7k-0000n0-EH for tcpm-web-archive@optimus.ietf.org; Tue, 04 May 2004 22:27: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 WAA15847 for ; Tue, 4 May 2004 22:27: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 1BLC7h-0002HN-8d for tcpm-web-archive@ietf.org; Tue, 04 May 2004 22:27:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLC6j-00029i-00 for tcpm-web-archive@ietf.org; Tue, 04 May 2004 22:26:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLC5n-00021h-00 for tcpm-web-archive@ietf.org; Tue, 04 May 2004 22:25:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLC2r-0007ur-5E; Tue, 04 May 2004 22: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 1BLBz5-000706-Q1 for tcpm@optimus.ietf.org; Tue, 04 May 2004 22: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 WAA15488 for ; Tue, 4 May 2004 22: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 1BLBz2-00014s-GY for tcpm@ietf.org; Tue, 04 May 2004 22:18:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLBy2-0000vJ-00 for tcpm@ietf.org; Tue, 04 May 2004 22:17:03 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx with esmtp (Exim 4.12) id 1BLBx7-0000mK-00 for tcpm@ietf.org; Tue, 04 May 2004 22:16:05 -0400 Received: from jurassic.eng.sun.com ([129.146.84.45]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i452EmsT018364 for ; Tue, 4 May 2004 20:14:48 -0600 (MDT) Received: from sun.com (shield.SFBay.Sun.COM [129.144.60.49]) by jurassic.eng.sun.com (8.13.0.Beta0+Sun/8.13.0.Beta0) with ESMTP id i452G5U6988856 for ; Tue, 4 May 2004 19:16:05 -0700 (PDT) Message-ID: <40984E65.7090204@sun.com> Date: Tue, 04 May 2004 19:16: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 To: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: <20040504161038.52F2577A71D@guns.icir.org> In-Reply-To: <20040504161038.52F2577A71D@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 the proposed scheme is not rfc793 conformant. But, I don't > see how the last sentence above follows from the previous few. We can > evolve and change. RFC793 has been and will continue to be updated. > (I'm not arguing that the proposed change is The Way To Go, just trying > to understand your argument.) Having seen some ACK wars interacting with middlebox, I am not comfortable with a change which responds to a RST, which is supposed to tell the other side to stop sending. It is similar to responding to an ACK with an ACK. As I mentioned before, I am not against changing TCP. But I think we should be careful in doing it. -- 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 May 4 23:06: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 XAA17234 for ; Tue, 4 May 2004 23:06: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 1BLCfw-0000ut-3X for tcpm-archive@odin.ietf.org; Tue, 04 May 2004 23:02:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4532O0n003517 for tcpm-archive@odin.ietf.org; Tue, 4 May 2004 23:02:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLCc0-00005R-1s for tcpm-web-archive@optimus.ietf.org; Tue, 04 May 2004 22: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 WAA16922 for ; Tue, 4 May 2004 22: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 1BLCbw-0006X3-H9 for tcpm-web-archive@ietf.org; Tue, 04 May 2004 22:58:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLCb2-0006No-00 for tcpm-web-archive@ietf.org; Tue, 04 May 2004 22:57:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLCaL-0006Ek-00 for tcpm-web-archive@ietf.org; Tue, 04 May 2004 22:56:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLCWr-00074R-TL; Tue, 04 May 2004 22: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 1BLCS9-0006Dd-3Z for tcpm@optimus.ietf.org; Tue, 04 May 2004 22:48: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 WAA16651 for ; Tue, 4 May 2004 22: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 1BLCS5-0005C0-Jc for tcpm@ietf.org; Tue, 04 May 2004 22:48:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLCRN-00053r-00 for tcpm@ietf.org; Tue, 04 May 2004 22:47:21 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx with esmtp (Exim 4.12) id 1BLCQG-0004vl-00 for tcpm@ietf.org; Tue, 04 May 2004 22:46:13 -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 i452kAhw084412; Tue, 4 May 2004 19:46:10 -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 E1B5F77A71D; Tue, 4 May 2004 22:46:07 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 1C9C11461C2; Tue, 4 May 2004 22:46:07 -0400 (EDT) To: "Randall Stewart (cisco)" From: Mark Allman Reply-To: mallman@icir.org Cc: Mitesh Dalal , Kacheong Poon , tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt In-Reply-To: <4097F039.5000906@cisco.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Little Miss Can't Be Wrong MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 04 May 2004 22:46:06 -0400 Message-Id: <20040505024607.1C9C11461C2@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 On the general notion, not any specifics that have been discussed thus far ... > I can dream up hundreds of "broken middle box" scenarios that break > existing TCP and cause all sorts of other horrible things.. hey this > and others may be out there.. I would like to know if it is true... or > just imagination... There is some experience with throwing new things out that middleboxes don't grok and therefore deal badly with (e.g., ECN). So, I don't think the middlebox concern is irrational. However, I agree that we can take this way too far and wave our hands at dozens or hundreds of potential screw ups that are just not there. It'd be good to run any suggestions through some common middleboxes to see what might or might not happen. allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin) iD8DBQFAmFVuWyrrWs4yIs4RAuIIAKCMaBqh5xNriORJzZh9d4/GfVEH8ACeKOkK gHJ5qF1N80/5k79iluXswyE= =NO3q -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue May 4 23:51:25 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 XAA19612 for ; Tue, 4 May 2004 23:51: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 1BLDOq-0004H9-NN for tcpm-archive@odin.ietf.org; Tue, 04 May 2004 23:48:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i453mmpJ016431 for tcpm-archive@odin.ietf.org; Tue, 4 May 2004 23:48:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLDIa-0002gi-MI for tcpm-web-archive@optimus.ietf.org; Tue, 04 May 2004 23:42: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 XAA19172 for ; Tue, 4 May 2004 23:42: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 1BLDIY-0005Bm-Kx for tcpm-web-archive@ietf.org; Tue, 04 May 2004 23:42:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLDHf-000520-00 for tcpm-web-archive@ietf.org; Tue, 04 May 2004 23:41:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLDGq-0004sy-00 for tcpm-web-archive@ietf.org; Tue, 04 May 2004 23: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 1BLDCT-0000cw-IE; Tue, 04 May 2004 23:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLDAd-0008Cu-Dy for tcpm@optimus.ietf.org; Tue, 04 May 2004 23:34: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 XAA18610 for ; Tue, 4 May 2004 23:34: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 1BLDAb-0003wv-EN for tcpm@ietf.org; Tue, 04 May 2004 23:34:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLD9g-0003mr-00 for tcpm@ietf.org; Tue, 04 May 2004 23:33:08 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1BLD8t-0003WW-00 for tcpm@ietf.org; Tue, 04 May 2004 23:32:19 -0400 Received: from jurassic.eng.sun.com ([129.146.88.130]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i453Vnms005968 for ; Tue, 4 May 2004 20:31:49 -0700 (PDT) Received: from sun.com (shield.SFBay.Sun.COM [129.144.60.49]) by jurassic.eng.sun.com (8.13.0.Beta0+Sun/8.13.0.Beta0) with ESMTP id i453VnUv108945 for ; Tue, 4 May 2004 20:31:49 -0700 (PDT) Message-ID: <40986025.2090605@sun.com> Date: Tue, 04 May 2004 20:31:49 -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] draft-ietf-tcpm-tcpsecure-00.txt References: <20040504161038.52F2577A71D@guns.icir.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: > Here is a scenario which can readily happen with base spec. A and > B are peers in ESTAB state. B is sendind data to A. data 2 gets > dropped. B has a critical failure, decides to send a RST. sequence > number 4 is within window of A. A sends ACKs; which are in flight > relative to RST 4, for data 1 and 3 (hence I have shown the RST > to reach A after the ACK has been sent out). But as far as B (and the > imaginary middlebox) is concerned, it appeared later in time wrt to > RST and may have actually be triggered by the RST itself. B has no > way of knowing this. It will ultimately send an RST with a sequence > number that was borrowed from the ACK. So, if this scenario cannot be > successfully handled by middleboxes and endhosts, it may not be able > to handle our changes as well. The point I am trying to emphasize is > sending an ACK looks totally benign and is still looks like a plausible > scenario within the semantics of the base spec. > > A B > |<----1---2-----3--------<--------| > | | > | <--RST--4---------| > |---------> ACK 1--------> | > |---------> ACK 1 (for 3) | > |<---RST-4--- | > | | > | <--RST-1------------------------| There are 1 ACK (because of the RST-4) and 2 more RSTs (because of the 2 ACKs) missing from the above picture. This brings up a question. The number of extra segments exchanged can be very large. The draft should at least put down the formula stating the upper bound of the number of extra segments exchanged for a RFC793 conforming TCP as the sender of RST. Note that the above case is not the worst. Another case can be like this. Assume that there is no re-ordering in the network, segment 2 is not lost in the above picture but RST-4 is lost, and A does not do delayed ACK (just for simplicity). For every ACK B receives except the last ACK-3, it will send a RST using an unacceptable sequence number to A. And for each of those RSTs, the modified stack will in turn send back an ACK, which will trigger a RST, but should be acceptable to A now, from B. This is not the worst case. If re-ordering takes place, the extra exchange can be worse. Now if there is a middlebox which behaves in some interesting way... The above scenario brings up an interesting observation. Assume that the RST attack is very easy to do and that the stack is modified to send back an ACK for defense as described in the draft. Since the ACKs are most likely treated as duplicate ACKs in the receiver of those ACKs and duplicate ACKs trigger fast retransmit and halving the congestion window, does it mean that the RST attack is changed to another form of DoS attack, slowing down the sender to always have a cwnd of 1 MSS and trigger a lot of unnecessary retransmissions? Actually, I think this slow down can also easily be done by simply generating unacceptable segment as TCP will respond with an ACK. Should this be also dealt with? > similarly for the SYN part, ACKs from A to B maybe in flight, when > a SYN lands up at A. Middleboxes and endhost have no way of knowing > if the ACK was send after the SYN was received at A or otherwise and > given the liberal principle, they will still need to act on it based > on the guidelines laid down in 793. > Further, I even hypothesize that the middleboxes on receiving the > SYN, will actually send a RST to the inside endhost and not > simply forward the SYN and hence converting the SYN scenario to > a RST scenario. If there are no middleboxes, our fix is even more > cleaner (except for the very rare scenario where the SYN carries > an ISN that matches our rcv.nxt-1) > > The above logic can be extrapolated if we put in a middlebox. > Difference will be seen based on where the RST gets dropped, between > the middlebox and B or between the middlebox and A. But since both > of them have equal probability of happening, we can safely disregard > the details. Honestly, I don't know how middlebox can behave. But a one time "challenge/response" can become an infinite loop. I don't think the gain justifies the risk. Anyway, this is the last time I'll raise this point again. Other host vendors can voice their opinions, maybe they are completely opposite to what I said... -- 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 May 5 00:02:30 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 AAA20174 for ; Wed, 5 May 2004 00:02: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 1BLDYc-0006gG-TL for tcpm-archive@odin.ietf.org; Tue, 04 May 2004 23:58:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i453wsNc025676 for tcpm-archive@odin.ietf.org; Tue, 4 May 2004 23:58:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLDS7-0005GK-Gf for tcpm-web-archive@optimus.ietf.org; Tue, 04 May 2004 23:52: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 XAA19670 for ; Tue, 4 May 2004 23:52: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 1BLDS5-0006da-Bd for tcpm-web-archive@ietf.org; Tue, 04 May 2004 23:52:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLDR9-0006Uy-00 for tcpm-web-archive@ietf.org; Tue, 04 May 2004 23:51:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLDQX-0006N6-00 for tcpm-web-archive@ietf.org; Tue, 04 May 2004 23:50:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLDN7-0003zZ-7n; Tue, 04 May 2004 23: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 1BLDGa-00026j-Sp for tcpm@optimus.ietf.org; Tue, 04 May 2004 23:40: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 XAA19104 for ; Tue, 4 May 2004 23:40: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 1BLDGY-0004re-OH for tcpm@ietf.org; Tue, 04 May 2004 23:40:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLDFZ-0004ig-00 for tcpm@ietf.org; Tue, 04 May 2004 23:39:13 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1BLDEm-0004S4-00 for tcpm@ietf.org; Tue, 04 May 2004 23:38:24 -0400 Received: from jurassic.eng.sun.com ([129.146.83.130]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i453bs6b019551 for ; Tue, 4 May 2004 20:37:55 -0700 (PDT) Received: from sun.com (shield.SFBay.Sun.COM [129.144.60.49]) by jurassic.eng.sun.com (8.13.0.Beta0+Sun/8.13.0.Beta0) with ESMTP id i453bsBO109858 for ; Tue, 4 May 2004 20:37:54 -0700 (PDT) Message-ID: <40986192.6070103@sun.com> Date: Tue, 04 May 2004 20:37: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: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: <20040504161038.52F2577A71D@guns.icir.org> <4097F039.5000906@cisco.com> In-Reply-To: <4097F039.5000906@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 would like someone to point out an actual box that does this.. not > something > from ten years ago.. but some network gear that is out there and > waiting for this pit to happen.. if it does exists then it is a concern > since > you would have an ACK war until after the middle box cleaned up > its state (that could last minutes or more). > > If this mythical box does not exist.. then its a moot point and not > an issue... > > I can dream up hundreds of "broken middle box" scenarios that break > existing TCP and cause all sorts of other horrible things.. hey this and > others > may be out there.. I would like to know if it is true... or just > imagination... I think Randy will probably have a different opinion if he had ever worked in a company selling machines which need to talk to a lot of broken TCP stacks... No one knows who that broken box will hit, and it may hit at the worst possible time. There goes any uptime guarantee... -- 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 May 5 01:20:09 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 BAA23440 for ; Wed, 5 May 2004 01:20: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 1BLEnI-0002vZ-GT for tcpm-archive@odin.ietf.org; Wed, 05 May 2004 01:18:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i455I8BV011248 for tcpm-archive@odin.ietf.org; Wed, 5 May 2004 01:18:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLElY-0002Qv-JG for tcpm-web-archive@optimus.ietf.org; Wed, 05 May 2004 01:16: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 BAA23255 for ; Wed, 5 May 2004 01:16: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 1BLElV-0003m2-IO for tcpm-web-archive@ietf.org; Wed, 05 May 2004 01:16:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLEkV-0003ci-00 for tcpm-web-archive@ietf.org; Wed, 05 May 2004 01:15:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLEjj-0003U3-00 for tcpm-web-archive@ietf.org; Wed, 05 May 2004 01:14:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLEeT-0008Op-3j; Wed, 05 May 2004 01: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 1BLEcp-0007fH-S1 for tcpm@optimus.ietf.org; Wed, 05 May 2004 01:07: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 BAA22960 for ; Wed, 5 May 2004 01:07: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 1BLEcm-0002JQ-SD for tcpm@ietf.org; Wed, 05 May 2004 01:07:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLEbr-00029k-00 for tcpm@ietf.org; Wed, 05 May 2004 01:06:20 -0400 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1BLEav-0001rO-00 for tcpm@ietf.org; Wed, 05 May 2004 01:05:21 -0400 Received: from horh1.emsr.lucent.com (h135-17-1-40.lucent.com [135.17.1.40]) by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4554hV08207; Wed, 5 May 2004 00:04:43 -0500 (CDT) Received: from new-wopr.eng.ascend.com ([135.140.53.19]) by horh1.emsr.lucent.com (8.11.7+Sun/EMS-1.5 Solaris/emsr) id i4554g518774 for ; Wed, 5 May 2004 00:04:42 -0500 (CDT) Received: from grigri.eng.ascend.com (grigri.eng.ascend.com [135.140.53.45]) by new-wopr.eng.ascend.com (8.11.6+Sun/8.10.2) with ESMTP id i4554gD06744; Tue, 4 May 2004 22:04:42 -0700 (PDT) Received: from lucent.com (gauri.eng.ascend.com [135.140.26.53]) by grigri.eng.ascend.com (8.8.8+Sun/8.8.8) with ESMTP id WAA29705; Tue, 4 May 2004 22:04:41 -0700 (PDT) Message-ID: <409875E9.C64FA34D@lucent.com> Date: Tue, 04 May 2004 22:04:41 -0700 From: Allwyn Carvalho X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Kacheong Poon CC: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: <20040504161038.52F2577A71D@guns.icir.org> <40984E65.7090204@sun.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 I'm no TCP expert, but like someone else on this list, I've had to look into this issue because of the panic this vulnerability has created. My first reaction to the Vulnerability Advisory was that it was overblown. That said, my first reaction to the proposed fixes were that they were simple, clever, ingenous, and even though buggy, were at least in the right direction for a solution. After going through the mail archives, I think some very valid points have been brought up. If this i-d progresses, like others on this list, I think the possibility of a RST/ACK-war needs to be addressed, even if it's the fault of the other router/host/middlebox. Another point I haven't seen discussed -- for the SYN attack, the i-d proposed solution is: A) If the SYN bit is set and the sequence number is outside the expected window, send an ACK back to the peer. B) 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. C) If the SYN bit is set and the sequence number is acceptable i.e.: (RCV.NXT < SEG.SEQ <= RCV.NXT+RCV.WND) then send an ACK segment to the peer. Couple of questions: 1. For case B, I think you need to worry about RCV.NXT being in the range of [SEG.SEQ, SEG.SEQ + SEG.LEN] instead of simply being equal to SEG.SEQ. For example, if SEG.SEQ is 1000 and RCV.NXT is 1001, it is still a special case. 2. Isn't the treatment of case C the same as case A? If so, shouldn't this be re-phrased to make it less confusing? Allwyn. Kacheong Poon wrote: > > Mark Allman wrote: > > > I agree that the proposed scheme is not rfc793 conformant. But, I don't > > see how the last sentence above follows from the previous few. We can > > evolve and change. RFC793 has been and will continue to be updated. > > (I'm not arguing that the proposed change is The Way To Go, just trying > > to understand your argument.) > > Having seen some ACK wars interacting with middlebox, I am not > comfortable with a change which responds to a RST, which is > supposed to tell the other side to stop sending. It is similar to > responding to an ACK with an ACK. As I mentioned before, I am > not against changing TCP. But I think we should be careful > in doing it. > > -- > > 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 Wed May 5 01:20: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 BAA23463 for ; Wed, 5 May 2004 01:20: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 1BLEnI-0002vp-Mr for tcpm-archive@odin.ietf.org; Wed, 05 May 2004 01:18:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i455I8nA011265 for tcpm-archive@odin.ietf.org; Wed, 5 May 2004 01:18:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLElZ-0002Qz-PY for tcpm-web-archive@optimus.ietf.org; Wed, 05 May 2004 01:16: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 BAA23261 for ; Wed, 5 May 2004 01: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 1BLElW-0003mC-QF for tcpm-web-archive@ietf.org; Wed, 05 May 2004 01:16:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLEkW-0003cy-00 for tcpm-web-archive@ietf.org; Wed, 05 May 2004 01:15:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLEkI-0003UA-00 for tcpm-web-archive@ietf.org; Wed, 05 May 2004 01:15:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLEeT-0008Ox-Br; Wed, 05 May 2004 01: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 1BLEcu-0007iM-RZ for tcpm@optimus.ietf.org; Wed, 05 May 2004 01:07: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 BAA22988 for ; Wed, 5 May 2004 01:07: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 1BLEcs-0002KK-1j for tcpm@ietf.org; Wed, 05 May 2004 01:07:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLEbv-0002AP-00 for tcpm@ietf.org; Wed, 05 May 2004 01:06:24 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1BLEbG-0001zM-00 for tcpm@ietf.org; Wed, 05 May 2004 01:05:42 -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 i455590Q021664; Tue, 4 May 2004 22:05:09 -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 ASX08371; Tue, 4 May 2004 22:04:22 -0700 (PDT) Date: Tue, 4 May 2004 22:05:08 -0700 (PDT) From: Mitesh Dalal To: Kacheong Poon cc: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt In-Reply-To: <40986025.2090605@sun.com> Message-ID: References: <20040504161038.52F2577A71D@guns.icir.org> <40986025.2090605@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 Tue, 4 May 2004, Kacheong Poon wrote: > Mitesh Dalal wrote: > > > Here is a scenario which can readily happen with base spec. A and > > B are peers in ESTAB state. B is sendind data to A. data 2 gets > > dropped. B has a critical failure, decides to send a RST. sequence > > number 4 is within window of A. A sends ACKs; which are in flight > > relative to RST 4, for data 1 and 3 (hence I have shown the RST > > to reach A after the ACK has been sent out). But as far as B (and the > > imaginary middlebox) is concerned, it appeared later in time wrt to > > RST and may have actually be triggered by the RST itself. B has no > > way of knowing this. It will ultimately send an RST with a sequence > > number that was borrowed from the ACK. So, if this scenario cannot be > > successfully handled by middleboxes and endhosts, it may not be able > > to handle our changes as well. The point I am trying to emphasize is > > sending an ACK looks totally benign and is still looks like a plausible > > scenario within the semantics of the base spec. > > > > A B > > |<----1---2-----3--------<--------| > > | | > > | <--RST--4---------| > > |---------> ACK 1--------> | > > |---------> ACK 1 (for 3) | > > |<---RST-4--- | > > | | > > | <--RST-1------------------------| > > > There are 1 ACK (because of the RST-4) and 2 more RSTs (because > of the 2 ACKs) missing from the above picture. This brings up a thanks for clarifying the omission. > question. The number of extra segments exchanged can be very > large. The draft should at least put down the formula stating the > upper bound of the number of extra segments exchanged for a RFC793 > conforming TCP as the sender of RST. Note that the above case is yes, something to this effect will be put in the next version of the draft. > not the worst. Another case can be like this. Assume that there is > no re-ordering in the network, segment 2 is not lost in the above > picture but RST-4 is lost, and A does not do delayed ACK (just for > simplicity). For every ACK B receives except the last ACK-3, it will > send a RST using an unacceptable sequence number to A. And for each > of those RSTs, the modified stack will in turn send back an ACK, actually they will not be acceptable, since rcv.nxt would have moved and the seq number of those incoming RSTs will now fall outside the window of A and hence only the RST corresponding to the last ACK-3 will be an exact match and acceptable. > which will trigger a RST, but should be acceptable to A now, from B. > This is not the worst case. If re-ordering takes place, the extra > exchange can be worse. > > Now if there is a middlebox which behaves in some interesting way... > > The above scenario brings up an interesting observation. Assume > that the RST attack is very easy to do and that the stack is modified > to send back an ACK for defense as described in the draft. Since > the ACKs are most likely treated as duplicate ACKs in the receiver > of those ACKs and duplicate ACKs trigger fast retransmit and halving > the congestion window, does it mean that the RST attack is changed > to another form of DoS attack, slowing down the sender to always > have a cwnd of 1 MSS and trigger a lot of unnecessary retransmissions? yes, this was brought up earlier in the discussion by Wesley E. and Mika L. > Actually, I think this slow down can also easily be done by simply > generating unacceptable segment as TCP will respond with an ACK. and thats what was my reply too ;) > Should this be also dealt with? > this is one of the scenario in which the data injection part of our fix will help. thx Mitesh _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed May 5 02:13:45 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08410 for ; Wed, 5 May 2004 02:13: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 1BLFco-0002u3-VZ for tcpm-archive@odin.ietf.org; Wed, 05 May 2004 02:11:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i456BMam011157 for tcpm-archive@odin.ietf.org; Wed, 5 May 2004 02:11:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLFVw-0007Rv-CI for tcpm-web-archive@optimus.ietf.org; Wed, 05 May 2004 02:04: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 CAA29416 for ; Wed, 5 May 2004 02:04: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 1BLFVs-0003hr-VS for tcpm-web-archive@ietf.org; Wed, 05 May 2004 02:04:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLFV0-0003Xx-00 for tcpm-web-archive@ietf.org; Wed, 05 May 2004 02:03:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLFUJ-0003OV-00 for tcpm-web-archive@ietf.org; Wed, 05 May 2004 02:02:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLFO0-0003ZC-9G; Wed, 05 May 2004 01:56:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLFMJ-0002w8-C0 for tcpm@optimus.ietf.org; Wed, 05 May 2004 01:54: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 BAA24630 for ; Wed, 5 May 2004 01:54: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 1BLFMG-00021w-4F for tcpm@ietf.org; Wed, 05 May 2004 01:54:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLFLT-0001sc-00 for tcpm@ietf.org; Wed, 05 May 2004 01:53:28 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BLFKa-0001Ys-00 for tcpm@ietf.org; Wed, 05 May 2004 01:52:32 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 04 May 2004 22:52:25 -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 i455q1jP024438; Tue, 4 May 2004 22:52:02 -0700 (PDT) Date: Tue, 4 May 2004 22:52:01 -0700 (PDT) From: Anantha Ramaiah To: Allwyn Carvalho cc: Kacheong Poon , tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt In-Reply-To: <409875E9.C64FA34D@lucent.com> Message-ID: References: <20040504161038.52F2577A71D@guns.icir.org> <40984E65.7090204@sun.com> <409875E9.C64FA34D@lucent.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 Allwyn, On Tue, 4 May 2004, Allwyn Carvalho wrote: > I'm no TCP expert, but like someone else on this list, I've had to look into this issue because of the panic this vulnerability has created. > > My first reaction to the Vulnerability Advisory was that it was overblown. That said, my first reaction to the proposed fixes were that they were simple, clever, ingenous, and even though buggy, were at least in the right direction for a solution. > > After going through the mail archives, I think some very valid points have been brought up. If this i-d progresses, like others on this list, I think the possibility of a RST/ACK-war needs to be addressed, even if it's the fault of the other router/host/middlebox. > > Another point I haven't seen discussed -- for the SYN attack, the i-d proposed solution is: > > A) If the SYN bit is set and the sequence number is outside the > expected window, send an ACK back to the peer. > B) 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. > C) If the SYN bit is set and the sequence number is acceptable i.e.: > (RCV.NXT < SEG.SEQ <= RCV.NXT+RCV.WND) then send an ACK segment to > the peer. > > Couple of questions: > > 1. For case B, I think you need to worry about RCV.NXT being in the range of [SEG.SEQ, SEG.SEQ + SEG.LEN] instead of simply being equal to SEG.SEQ. For example, if SEG.SEQ is 1000 and RCV.NXT is 1001, it is still a special case. Actually the revision to the draft (which will be posted soon) will clarify the above more clearly and list out one of the corner cases where if the sequence # chosen by the restarted host happens to be (seq# == RCV.NXT - 1) it would receive back an ACK = RCV.NXT which is an acceptable ACK in which case the RST wouldn't be sent back and the host would timeout the SYN. The next time if it attempts the SYN the initial sequence number would be different and should work hunky-dory. Actually some implementations treat a RST with SNDUNA -1 as a RST of a keepalive packet and would consider the RST valid, but agreed it is implementation specific. The reason I am pointing this is because we could exploit this for modified case B) which would be re-worded as : "if the SYN bit is set and the sequence # == next expected sequence - 1, then send ACK to the peer with ACK# = RCVNXT - 1. Actually there is no issue with B) above. Pl see my reply to one of the earlier emails in this thread. > > 2. Isn't the treatment of case C the same as case A? If so, shouldn't this be re-phrased to make it less confusing? The reason it was posted seperately was that original RFC behaviour was to abort the connection and send RST, in the current solution we send ACK even for this case... -Anantha > > Allwyn. > > > Kacheong Poon wrote: > > > > Mark Allman wrote: > > > > > I agree that the proposed scheme is not rfc793 conformant. But, I don't > > > see how the last sentence above follows from the previous few. We can > > > evolve and change. RFC793 has been and will continue to be updated. > > > (I'm not arguing that the proposed change is The Way To Go, just trying > > > to understand your argument.) > > > > Having seen some ACK wars interacting with middlebox, I am not > > comfortable with a change which responds to a RST, which is > > supposed to tell the other side to stop sending. It is similar to > > responding to an ACK with an ACK. As I mentioned before, I am > > not against changing TCP. But I think we should be careful > > in doing it. > > > > -- > > > > 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 > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed May 5 12:44: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 MAA24938 for ; Wed, 5 May 2004 12:44: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 1BLPRM-0006Uf-Qr for tcpm-archive@odin.ietf.org; Wed, 05 May 2004 12:40:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45GeCCx024957 for tcpm-archive@odin.ietf.org; Wed, 5 May 2004 12:40:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLPEM-0001PV-1P for tcpm-web-archive@optimus.ietf.org; Wed, 05 May 2004 12:26: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 MAA23585 for ; Wed, 5 May 2004 12:26: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 1BLPEK-0007mD-Jn for tcpm-web-archive@ietf.org; Wed, 05 May 2004 12:26:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLPDJ-0007TS-00 for tcpm-web-archive@ietf.org; Wed, 05 May 2004 12:25:42 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLPCI-00076r-00 for tcpm-web-archive@ietf.org; Wed, 05 May 2004 12:24:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLOuJ-0001Sl-HB; Wed, 05 May 2004 12:06:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLOnE-0006c9-3s for tcpm@optimus.ietf.org; Wed, 05 May 2004 11:58: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 LAA22591 for ; Wed, 5 May 2004 11:58: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 1BLOnC-0000dL-Tf for tcpm@ietf.org; Wed, 05 May 2004 11:58:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLOmO-0000O5-00 for tcpm@ietf.org; Wed, 05 May 2004 11:57:52 -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 1BLOla-0007fd-00 for tcpm@ietf.org; Wed, 05 May 2004 11:57:03 -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-5) with ESMTP id i45FvBDp004589; Wed, 5 May 2004 18:57:11 +0300 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.11/8.12.11/Debian-5) id i45Fv9I3004588; Wed, 5 May 2004 18:57:09 +0300 Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt From: Mika Liljeberg To: Anantha Ramaiah Cc: Allwyn Carvalho , Kacheong Poon , tcpm@ietf.org In-Reply-To: References: <20040504161038.52F2577A71D@guns.icir.org> <40984E65.7090204@sun.com> <409875E9.C64FA34D@lucent.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1083772629.1129.13.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 05 May 2004 18:57:09 +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-05-05 at 08:52, Anantha Ramaiah wrote: > Actually some implementations treat a RST with SNDUNA -1 as a RST of a > keepalive packet and would consider the RST valid, but agreed it is > implementation specific. The reason I am pointing this is because we could > exploit this for modified case B) which would be re-worded as : > "if the SYN bit is set and the sequence # == next expected sequence - 1, > then send ACK to the peer with ACK# = RCVNXT - 1. Actually, because of delayed acks, RCV.NXT may be different from the left edge of the last advertised window. Hence, some implementations store the last advertised window, and use that to validate incoming RSTs. MikaL _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed May 5 12:57: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 MAA25629 for ; Wed, 5 May 2004 12:57: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 1BLPVC-0000DD-TJ for tcpm-archive@odin.ietf.org; Wed, 05 May 2004 12:44:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45GiA5u000810 for tcpm-archive@odin.ietf.org; Wed, 5 May 2004 12:44:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLPR1-0006EK-DY for tcpm-web-archive@optimus.ietf.org; Wed, 05 May 2004 12:39: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 MAA24742 for ; Wed, 5 May 2004 12:39: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 1BLPQz-0003on-SZ for tcpm-web-archive@ietf.org; Wed, 05 May 2004 12:39:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLPQ2-0003Yr-00 for tcpm-web-archive@ietf.org; Wed, 05 May 2004 12:38:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLPPB-0003Iq-00 for tcpm-web-archive@ietf.org; Wed, 05 May 2004 12:37:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLPDh-0001Ng-88; Wed, 05 May 2004 12:26:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLP2m-0004Ze-9q for tcpm@optimus.ietf.org; Wed, 05 May 2004 12:14: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 MAA23155 for ; Wed, 5 May 2004 12:14: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 1BLP2k-0004gf-V3 for tcpm@ietf.org; Wed, 05 May 2004 12:14:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLP1x-0004S9-00 for tcpm@ietf.org; Wed, 05 May 2004 12:13:57 -0400 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1BLP1U-0004CX-00 for tcpm@ietf.org; Wed, 05 May 2004 12:13:28 -0400 Received: from horh1.emsr.lucent.com (h135-17-1-40.lucent.com [135.17.1.40]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i45GCrB17291; Wed, 5 May 2004 11:12:54 -0500 (CDT) Received: from new-wopr.eng.ascend.com ([135.140.53.19]) by horh1.emsr.lucent.com (8.11.7+Sun/EMS-1.5 Solaris/emsr) id i45GCqs15142 for ; Wed, 5 May 2004 11:12:52 -0500 (CDT) Received: from grigri.eng.ascend.com (grigri.eng.ascend.com [135.140.53.45]) by new-wopr.eng.ascend.com (8.11.6+Sun/8.10.2) with ESMTP id i45GCqD26927; Wed, 5 May 2004 09:12:52 -0700 (PDT) Received: from lucent.com (allwyn.lra.lucent.com [192.11.63.4]) by grigri.eng.ascend.com (8.8.8+Sun/8.8.8) with ESMTP id JAA17557; Wed, 5 May 2004 09:12:50 -0700 (PDT) Message-ID: <409912B5.5080307@lucent.com> Date: Wed, 05 May 2004 09:13:41 -0700 From: Allwyn Carvalho 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: Anantha Ramaiah CC: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: <20040504161038.52F2577A71D@guns.icir.org> <40984E65.7090204@sun.com> <409875E9.C64FA34D@lucent.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 Hi Anantha, Thanks for your response. See reply inline. Anantha Ramaiah wrote: [snip] >>1. For case B, I think you need to worry about RCV.NXT being in the range of >>[SEG.SEQ, SEG.SEQ + SEG.LEN] instead of simply being equal to SEG.SEQ. For >>example, if SEG.SEQ is 1000 and RCV.NXT is 1001, it is still a special case. > > > Actually the revision to the draft (which will be posted soon) will > clarify the above more clearly and list out one of the corner cases where > if the sequence # chosen by the restarted host happens to be (seq# == > RCV.NXT - 1) it would receive back an ACK = RCV.NXT which is an acceptable > ACK in which case the RST wouldn't be sent back and the host would timeout > the SYN. The next time if it attempts the SYN the initial sequence number > would be different and should work hunky-dory. I believe there are applications out there that will send all in the first segment, and no it doesn't violate RFC 793. I'm not so sure what will happen if they are partially acked. Just making sure you cover this. > > Actually some implementations treat a RST with SNDUNA -1 as a RST of a > keepalive packet and would consider the RST valid, but agreed it is > implementation specific. The reason I am pointing this is because we could > exploit this for modified case B) which would be re-worded as : > "if the SYN bit is set and the sequence # == next expected sequence - 1, > then send ACK to the peer with ACK# = RCVNXT - 1. > > Actually there is no issue with B) above. Pl see my reply to one of > the earlier emails in this thread. > > >>2. Isn't the treatment of case C the same as case A? If so, shouldn't this be >>re-phrased to make it less confusing? > > > The reason it was posted seperately was that original RFC behaviour was to > abort the connection and send RST, in the current solution we send ACK > even for this case... If you continue to keep A) and C) as separate cases, can you at least make sure that the wording is consistent. One says "send an ACK back" and one says "send an ACK segment". It's a minor point, but I think it's important to be consistent. Allwyn. > > -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed May 5 13:03: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 NAA26279 for ; Wed, 5 May 2004 13:03: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 1BLPd2-0003Ak-U6 for tcpm-archive@odin.ietf.org; Wed, 05 May 2004 12:52:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45GqGAZ012190 for tcpm-archive@odin.ietf.org; Wed, 5 May 2004 12:52:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLPTu-0007zT-Un for tcpm-web-archive@optimus.ietf.org; Wed, 05 May 2004 12: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 MAA24865 for ; Wed, 5 May 2004 12: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 1BLPTt-0004cI-CG for tcpm-web-archive@ietf.org; Wed, 05 May 2004 12:42:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLPT1-0004Mc-00 for tcpm-web-archive@ietf.org; Wed, 05 May 2004 12:41:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLPSO-00046d-00 for tcpm-web-archive@ietf.org; Wed, 05 May 2004 12:41:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLPJR-0003mF-2m; Wed, 05 May 2004 12:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLPCZ-00012p-Ls for tcpm@optimus.ietf.org; Wed, 05 May 2004 12:24: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 MAA23471 for ; Wed, 5 May 2004 12:24: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 1BLPCY-0007Cg-83 for tcpm@ietf.org; Wed, 05 May 2004 12:24:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLPBX-0006vL-00 for tcpm@ietf.org; Wed, 05 May 2004 12:23:52 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx with esmtp (Exim 4.12) id 1BLPAa-0006fF-00 for tcpm@ietf.org; Wed, 05 May 2004 12:22:52 -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 i45GMjhw095197; Wed, 5 May 2004 09:22: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 8EC8577A6D5; Wed, 5 May 2004 12:22:44 -0400 (EDT) To: Kacheong Poon From: Mark Allman Reply-To: mallman@icir.org Cc: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt In-Reply-To: <40984E65.7090204@sun.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Lonesome Day MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 05 May 2004 12:22:44 -0400 Message-Id: <20040505162244.8EC8577A6D5@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 > Having seen some ACK wars interacting with middlebox, I am not > comfortable with a change which responds to a RST, which is supposed > to tell the other side to stop sending. It is similar to responding > to an ACK with an ACK. I disagree. ACKing an ACK is ... err, pointless (at least at first blush). Having some form of handshake to bring down a connection is not, IMO. I think these are two fundementally different situations. If we were to start from scratch today, we'd no-doubt invent some scheme so that a RST had to include a handshake sort of thing, or that the RST had to include some sort of a hash or nonce or something to prove it saw the segment it is responding to (ala, the SCTP vtag scheme). Given that, can we make some sort of modest change to TCP to get such functionality? Of course, we're not designing from a clean slate and so this is more difficult. But, I think ruling out a verification scheme out-of-hand is not the right approach, because that is fundementally what we need. > As I mentioned before, I am not against changing TCP. But I think we > should be careful in doing it. Absolutely. allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAmRTUWyrrWs4yIs4RAvEbAJ99gj/Aj1R0mEV4caaloYCBvaFFBgCgn01B o4x46rmdc/MJmomzvlPU/nY= =BeZt -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed May 5 13:24: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 NAA27401 for ; Wed, 5 May 2004 13:24: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 1BLPrh-0008AO-N1 for tcpm-archive@odin.ietf.org; Wed, 05 May 2004 13:07:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45H7PXE031388 for tcpm-archive@odin.ietf.org; Wed, 5 May 2004 13:07:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLPmH-0005qG-HL for tcpm-web-archive@optimus.ietf.org; Wed, 05 May 2004 13:01: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 NAA26052 for ; Wed, 5 May 2004 13:01: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 1BLPmF-0001yk-ST for tcpm-web-archive@ietf.org; Wed, 05 May 2004 13:01:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLPlJ-0001h2-00 for tcpm-web-archive@ietf.org; Wed, 05 May 2004 13:00:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLPkL-0001Ns-00 for tcpm-web-archive@ietf.org; Wed, 05 May 2004 12:59:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLPW1-0000YT-OJ; Wed, 05 May 2004 12: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 1BLPQ5-00067Q-S7 for tcpm@optimus.ietf.org; Wed, 05 May 2004 12:38: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 MAA24709 for ; Wed, 5 May 2004 12:38: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 1BLPQ4-0003Z4-8K for tcpm@ietf.org; Wed, 05 May 2004 12:38:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLPPC-0003J7-00 for tcpm@ietf.org; Wed, 05 May 2004 12:37:59 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx with esmtp (Exim 4.12) id 1BLPOT-00032d-00 for tcpm@ietf.org; Wed, 05 May 2004 12:37:13 -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 i45GbChw095371; Wed, 5 May 2004 09:37:12 -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 7848B77A6D5; Wed, 5 May 2004 12:37:11 -0400 (EDT) To: Kacheong Poon From: Mark Allman Reply-To: mallman@icir.org Cc: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt In-Reply-To: <40986025.2090605@sun.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Lonesome Day MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 05 May 2004 12:37:11 -0400 Message-Id: <20040505163711.7848B77A6D5@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 > Since the ACKs are most likely treated as duplicate ACKs in the > receiver of those ACKs and duplicate ACKs trigger fast retransmit and > halving the congestion window, does it mean that the RST attack is > changed to another form of DoS attack, slowing down the sender to > always have a cwnd of 1 MSS and trigger a lot of unnecessary > retransmissions? Wes Eddy and I iterated about this and he posted this a couple weeks ago: >> 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. Someone then pointed out that this was really quite a minor interuption -- especially compared to the massive number of RSTs required to trigger it. Wes and I agreed. But, I am wondering if the above proposed rule (don't send repeated "challenges" to RSTs in a given window ... or, maybe not more than 2) is useful in preventing the infinite ACK/RST patterns you're worrying about. In other words, we take the stance that there is no reason to be challenging a bunch of RSTs in a window and so they silently get dropped. The worst case is that the RSTs were legit (in window, but not exact) and the challenges (ACKs) get lost. In that case the connection ends up holding state for a long time. Does that case have low enough probability to not worry about? allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAmRg3WyrrWs4yIs4RAm0YAJ0QzzW7ApYTekfrbN7LEsJV9YR9NwCfXU6P F4lCYrTt/YO4n+1bpY7nLjA= =vsVA -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed May 5 13:45:36 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 NAA29002 for ; Wed, 5 May 2004 13:45: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 1BLQNB-0008Dw-V1 for tcpm-archive@odin.ietf.org; Wed, 05 May 2004 13:39:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45Hdvtm031603 for tcpm-archive@odin.ietf.org; Wed, 5 May 2004 13: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 1BLQHG-0004ve-MP for tcpm-web-archive@optimus.ietf.org; Wed, 05 May 2004 13:33: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 NAA27983 for ; Wed, 5 May 2004 13:33: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 1BLQHE-00036W-IA for tcpm-web-archive@ietf.org; Wed, 05 May 2004 13:33:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLQGQ-0002qh-00 for tcpm-web-archive@ietf.org; Wed, 05 May 2004 13:32:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLQFY-0002ar-00 for tcpm-web-archive@ietf.org; Wed, 05 May 2004 13:32:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLQBm-0000p9-RY; Wed, 05 May 2004 13:28:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLQ1k-0003xb-NT for tcpm@optimus.ietf.org; Wed, 05 May 2004 13:17: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 NAA27111 for ; Wed, 5 May 2004 13:17: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 1BLQ1i-0006Sk-PC for tcpm@ietf.org; Wed, 05 May 2004 13:17:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLQ0g-0006CG-00 for tcpm@ietf.org; Wed, 05 May 2004 13:16:43 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BLPzg-0005iI-00 for tcpm@ietf.org; Wed, 05 May 2004 13:15:40 -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 i45HDSU25553; Wed, 5 May 2004 10:13:28 -0700 (PDT) Message-ID: <40992137.30508@isi.edu> Date: Wed, 05 May 2004 10:15:35 -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: Kacheong Poon , tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: <20040505163711.7848B77A6D5@guns.icir.org> In-Reply-To: <20040505163711.7848B77A6D5@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="------------enigB40EC308FFF3FED94055AB9D" 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) --------------enigB40EC308FFF3FED94055AB9D Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mark Allman wrote: ... > But, I am wondering if the above proposed rule (don't send repeated > "challenges" to RSTs in a given window ... or, maybe not more than 2) is > useful in preventing the infinite ACK/RST patterns you're worrying > about. In other words, we take the stance that there is no reason to be > challenging a bunch of RSTs in a window and so they silently get > dropped. The worst case is that the RSTs were legit (in window, but not > exact) and the challenges (ACKs) get lost. In that case the connection > ends up holding state for a long time. Does that case have low enough > probability to not worry about? > > allman Doesn't this mean you can defeat someone else's ability to RST a connection by flooding them with RSTs? Holding state for a long time in that case means one party can't reset a connection they want - or need to, doesn't it? Joe --------------enigB40EC308FFF3FED94055AB9D 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 iD8DBQFAmSE3E5f5cImnZrsRAhNIAJ0YroLXZvQuoJ+TthEAKYSx5I77yQCgilF5 XuCo2qBIa93djUTS3ivdM44= =axnP -----END PGP SIGNATURE----- --------------enigB40EC308FFF3FED94055AB9D-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed May 5 13:48:45 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 NAA29181 for ; Wed, 5 May 2004 13:48: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 1BLQNQ-0008O2-ET for tcpm-archive@odin.ietf.org; Wed, 05 May 2004 13:40:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45HeCW2032237 for tcpm-archive@odin.ietf.org; Wed, 5 May 2004 13:40:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLQIJ-0005H6-RA for tcpm-web-archive@optimus.ietf.org; Wed, 05 May 2004 13:34: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 NAA28039 for ; Wed, 5 May 2004 13:34: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 1BLQIH-0003NP-Nu for tcpm-web-archive@ietf.org; Wed, 05 May 2004 13:34:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLQHI-000373-00 for tcpm-web-archive@ietf.org; Wed, 05 May 2004 13:33:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLQGg-0002rQ-00 for tcpm-web-archive@ietf.org; Wed, 05 May 2004 13:33:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLQBo-0000ph-Rk; Wed, 05 May 2004 13:28:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLQ1w-00048n-0R for tcpm@optimus.ietf.org; Wed, 05 May 2004 13:18: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 NAA27155 for ; Wed, 5 May 2004 13:17: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 1BLQ1u-0006U9-2Z for tcpm@ietf.org; Wed, 05 May 2004 13:17:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLQ0r-0006EA-00 for tcpm@ietf.org; Wed, 05 May 2004 13:16:53 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BLQ06-0005ik-00 for tcpm@ietf.org; Wed, 05 May 2004 13:16:06 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i45HFal11638; Wed, 5 May 2004 10:15:36 -0700 (PDT) (envelope-from pgoyette@juniper.net) Received: from pgoyette600 (pgoyette-600.jnpr.net [172.24.0.72]) by merlot.juniper.net (8.11.3/8.11.3) with SMTP id i45HFVJ31094; Wed, 5 May 2004 10:15:31 -0700 (PDT) (envelope-from pgoyette@juniper.net) From: "Paul Goyette" To: , "Kacheong Poon" Cc: Subject: RE: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt Date: Wed, 5 May 2004 10:15:27 -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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <20040505163711.7848B77A6D5@guns.icir.org> 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 > But, I am wondering if the above proposed rule (don't send repeated > "challenges" to RSTs in a given window ... or, maybe not more than 2) is > useful in preventing the infinite ACK/RST patterns you're worrying > about. In other words, we take the stance that there is no reason to be > challenging a bunch of RSTs in a window and so they silently get > dropped. The worst case is that the RSTs were legit (in window, but not > exact) and the challenges (ACKs) get lost. In that case the connection > ends up holding state for a long time. Does that case have low enough > probability to not worry about? Perhaps "Don't send repeated challenges with the same ACK value" would be adequate? Then you only need to keep track of one new state value, the last value sent in a challenge ACK. This should eliminate the ACK war scenario. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed May 5 13:51:40 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 NAA29405 for ; Wed, 5 May 2004 13:51: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 1BLQOq-0000Sp-Rz for tcpm-archive@odin.ietf.org; Wed, 05 May 2004 13:41:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45Hfeix001778 for tcpm-archive@odin.ietf.org; Wed, 5 May 2004 13:41:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLQKL-0006tJ-9H for tcpm-web-archive@optimus.ietf.org; Wed, 05 May 2004 13:37: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 NAA28120 for ; Wed, 5 May 2004 13:36: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 1BLQKI-0003vk-Vs for tcpm-web-archive@ietf.org; Wed, 05 May 2004 13:36:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLQJJ-0003es-00 for tcpm-web-archive@ietf.org; Wed, 05 May 2004 13:35:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLQIc-0003OU-00 for tcpm-web-archive@ietf.org; Wed, 05 May 2004 13:35:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLQCa-0001Dh-Ng; Wed, 05 May 2004 13:29:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLQ8g-0006xJ-6n for tcpm@optimus.ietf.org; Wed, 05 May 2004 13:24: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 NAA27440 for ; Wed, 5 May 2004 13:24: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 1BLQ8e-0000Yp-6j for tcpm@ietf.org; Wed, 05 May 2004 13:24:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLQ7d-0000Gn-00 for tcpm@ietf.org; Wed, 05 May 2004 13:23:54 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx with esmtp (Exim 4.12) id 1BLQ6m-0007nh-00 for tcpm@ietf.org; Wed, 05 May 2004 13:23:00 -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 i45HN0hw095961; Wed, 5 May 2004 10:23:00 -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 DEF2A77A6D5; Wed, 5 May 2004 13:22:58 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id CEDEA146CA8; Wed, 5 May 2004 13:22:57 -0400 (EDT) To: Joe Touch From: Mark Allman Reply-To: mallman@icir.org Cc: Kacheong Poon , tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt In-Reply-To: <40992137.30508@isi.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Lonesome Day MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 05 May 2004 13:22:57 -0400 Message-Id: <20040505172257.CEDEA146CA8@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 Content-Transfer-Encoding: quoted-printable > > But, I am wondering if the above proposed rule (don't send repeated > > "challenges" to RSTs in a given window ... or, maybe not more than > > 2) is useful in preventing the infinite ACK/RST patterns you're > > worrying about. In other words, we take the stance that there is no > > reason to be challenging a bunch of RSTs in a window and so they > > silently get dropped. The worst case is that the RSTs were legit > > (in window, but not exact) and the challenges (ACKs) get lost. In > > that case the connection ends up holding state for a long time. > > Does that case have low enough probability to not worry about? > > allman >=20 > Doesn't this mean you can defeat someone else's ability to RST a > connection by flooding them with RSTs? I was sort of wondering if this could be gamed while I was typing. > Holding state for a long time in that case means one party can't > reset a connection they want - or need to, doesn't it? So, sure ... if someone RSTs in your window and then a party in the connection also wants to RST in that same window then you could be hosed. Seems like a low probability sort of event to me. (At least From=20a blind attacker -- which is the context of the fix.) Am I misrepresenting the chances of this? allman =2D- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin) iD8DBQFAmSLxWyrrWs4yIs4RAvcaAJ0UP93upj5C0dsMJgTVhho5AlEwwwCfXvbF Mpmq0zNAgBZ8g2PIOWKYFKQ= =hEKL -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed May 5 13:59:05 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 NAA29989 for ; Wed, 5 May 2004 13:59: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 1BLQZ0-0004jM-HJ for tcpm-archive@odin.ietf.org; Wed, 05 May 2004 13:52:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45HqA23018185 for tcpm-archive@odin.ietf.org; Wed, 5 May 2004 13:52:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLQQs-0001Jn-Cm for tcpm-web-archive@optimus.ietf.org; Wed, 05 May 2004 13:43: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 NAA28834 for ; Wed, 5 May 2004 13:43: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 1BLQQq-0005yP-8R for tcpm-web-archive@ietf.org; Wed, 05 May 2004 13:43:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLQPC-0005NT-00 for tcpm-web-archive@ietf.org; Wed, 05 May 2004 13:42:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLQMk-0004aH-00 for tcpm-web-archive@ietf.org; Wed, 05 May 2004 13:39:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLQEY-0001x1-45; Wed, 05 May 2004 13: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 1BLQBh-0000XT-Ix for tcpm@optimus.ietf.org; Wed, 05 May 2004 13:28: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 NAA27657 for ; Wed, 5 May 2004 13:28: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 1BLQBf-0001Ro-GZ for tcpm@ietf.org; Wed, 05 May 2004 13:28:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLQAa-000191-00 for tcpm@ietf.org; Wed, 05 May 2004 13:26:57 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx with esmtp (Exim 4.12) id 1BLQ9v-0000se-00 for tcpm@ietf.org; Wed, 05 May 2004 13:26: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 i45HQFhw096013; Wed, 5 May 2004 10:26:15 -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 B212F77A6D5; Wed, 5 May 2004 13:26:13 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 946DC146CC6; Wed, 5 May 2004 13:26:12 -0400 (EDT) To: "Paul Goyette" From: Mark Allman Reply-To: mallman@icir.org Cc: "Kacheong Poon" , tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Lonesome Day MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 05 May 2004 13:26:12 -0400 Message-Id: <20040505172612.946DC146CC6@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 > Perhaps "Don't send repeated challenges with the same ACK value" would > be adequate? Then you only need to keep track of one new state value, > the last value sent in a challenge ACK. This should eliminate the ACK > war scenario. But, then you're depending on the other side. If you just place a limit on the number of acceptable RSTs a host will accept (& respond to) then that's a local decision. If the point is to avoid a war because of some sort of buggy something then it would seem best to pick an avoidance strategy that didn't also involve the buggy something. (At least that makes sense to me as an initial thought. I could be wrong.) allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin) iD8DBQFAmSO0WyrrWs4yIs4RApCsAKCEaIshTy5Tu+TZqtDZScM9D1dedACeInJZ jMH18i7Lo2hPLyj138MbTvA= =iXNk -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed May 5 13:59: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 NAA00068 for ; Wed, 5 May 2004 13:59: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 1BLQZ2-0004ky-PE for tcpm-archive@odin.ietf.org; Wed, 05 May 2004 13:52:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45HqCVG018279 for tcpm-archive@odin.ietf.org; Wed, 5 May 2004 13:52:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLQRI-0001ch-Jo for tcpm-web-archive@optimus.ietf.org; Wed, 05 May 2004 13:44: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 NAA28885 for ; Wed, 5 May 2004 13:44: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 1BLQRG-00068s-FP for tcpm-web-archive@ietf.org; Wed, 05 May 2004 13:44:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLQQK-0005mG-00 for tcpm-web-archive@ietf.org; Wed, 05 May 2004 13:43:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLQOK-000570-00 for tcpm-web-archive@ietf.org; Wed, 05 May 2004 13:41:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLQJQ-0006T6-Nq; Wed, 05 May 2004 13:36:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLQDO-0001GF-Hk for tcpm@optimus.ietf.org; Wed, 05 May 2004 13:29: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 NAA27844 for ; Wed, 5 May 2004 13:29: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 1BLQDM-00023L-Cz for tcpm@ietf.org; Wed, 05 May 2004 13:29:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLQCS-0001lZ-00 for tcpm@ietf.org; Wed, 05 May 2004 13:28:53 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx with esmtp (Exim 4.12) id 1BLQBV-0001QV-00 for tcpm@ietf.org; Wed, 05 May 2004 13:27:53 -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 i45HRrhw096020; Wed, 5 May 2004 10:27:53 -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 B49E677A6D5; Wed, 5 May 2004 13:27:51 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id F0730146CE5; Wed, 5 May 2004 13:27:50 -0400 (EDT) To: Joe Touch From: Mark Allman Reply-To: mallman@icir.org Cc: Kacheong Poon , tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt In-Reply-To: <40992137.30508@isi.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Lonesome Day MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 05 May 2004 13:27:50 -0400 Message-Id: <20040505172751.F0730146CE5@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 > Doesn't this mean you can defeat someone else's ability to RST a > connection by flooding them with RSTs? > > Holding state for a long time in that case means one party can't > reset a connection they want - or need to, doesn't it? Oh, well another approach I'll throw out is not more than one RST challenge per time period. E.g., no more than 1/second. That limits the damage of an ACK war without allowing someone to deny the legitimate ripping down of a connection for minutes. (At the expense of some state.) allman --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin) iD8DBQFAmSQWWyrrWs4yIs4RAnS7AKCGOFwRtiiC0BV55Tyrwn2JU8L3BgCeMUO4 JMPWun24EQYrf+FzFKe9Lcg= =XcDO -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed May 5 13:59:41 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 NAA00198 for ; Wed, 5 May 2004 13:59: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 1BLQZX-0004wr-2m for tcpm-archive@odin.ietf.org; Wed, 05 May 2004 13:52:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45HqhYu019012 for tcpm-archive@odin.ietf.org; Wed, 5 May 2004 13:52:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLQWo-0003Oe-Si for tcpm-web-archive@optimus.ietf.org; Wed, 05 May 2004 13:49: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 NAA29282 for ; Wed, 5 May 2004 13:49: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 1BLQWm-000041-PW for tcpm-web-archive@ietf.org; Wed, 05 May 2004 13:49:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLQVj-0007Yq-00 for tcpm-web-archive@ietf.org; Wed, 05 May 2004 13:48:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLQUh-0007F5-00 for tcpm-web-archive@ietf.org; Wed, 05 May 2004 13:47:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLQNG-0008Lz-9x; Wed, 05 May 2004 13: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 1BLQFJ-00020k-Pn for tcpm@optimus.ietf.org; Wed, 05 May 2004 13:31: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 NAA27898 for ; Wed, 5 May 2004 13:31: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 1BLQFH-0002Yx-JI for tcpm@ietf.org; Wed, 05 May 2004 13:31:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLQEJ-0002It-00 for tcpm@ietf.org; Wed, 05 May 2004 13:30:48 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BLQDX-0001oh-00 for tcpm@ietf.org; Wed, 05 May 2004 13:29:59 -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 i45HSqU29777; Wed, 5 May 2004 10:28:52 -0700 (PDT) Message-ID: <409924D3.1090903@isi.edu> Date: Wed, 05 May 2004 10:30:59 -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: Kacheong Poon , tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: <20040505172257.CEDEA146CA8@lawyers.icir.org> In-Reply-To: <20040505172257.CEDEA146CA8@lawyers.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="------------enigAD001367B51E5410B75C11B7" 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) --------------enigAD001367B51E5410B75C11B7 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Low probability for sure, but if we're talking about security, it should be included in the revision at least... Joe Mark Allman wrote: >>>But, I am wondering if the above proposed rule (don't send repeated >>>"challenges" to RSTs in a given window ... or, maybe not more than >>>2) is useful in preventing the infinite ACK/RST patterns you're >>>worrying about. In other words, we take the stance that there is no >>>reason to be challenging a bunch of RSTs in a window and so they >>>silently get dropped. The worst case is that the RSTs were legit >>>(in window, but not exact) and the challenges (ACKs) get lost. In >>>that case the connection ends up holding state for a long time. >>>Does that case have low enough probability to not worry about? >>>allman >> >>Doesn't this mean you can defeat someone else's ability to RST a >>connection by flooding them with RSTs? > > > I was sort of wondering if this could be gamed while I was typing. > > >>Holding state for a long time in that case means one party can't >>reset a connection they want - or need to, doesn't it? > > > So, sure ... if someone RSTs in your window and then a party in the > connection also wants to RST in that same window then you could be > hosed. Seems like a low probability sort of event to me. (At least > From a blind attacker -- which is the context of the fix.) Am I > misrepresenting the chances of this? > > allman > > > -- > Mark Allman -- ICIR -- http://www.icir.org/mallman/ > > > --------------enigAD001367B51E5410B75C11B7 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 iD8DBQFAmSTTE5f5cImnZrsRAirzAJ9BI61sX0f4kBEuNndE4rEXLKA3uQCdELLD XXjrm1ROYy+s45ULjodFtb8= =Jg3a -----END PGP SIGNATURE----- --------------enigAD001367B51E5410B75C11B7-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed May 5 14:34:38 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 OAA03429 for ; Wed, 5 May 2004 14:34: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 1BLR7J-0002us-6e for tcpm-archive@odin.ietf.org; Wed, 05 May 2004 14:27:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45IRbT1011205 for tcpm-archive@odin.ietf.org; Wed, 5 May 2004 14:27:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLR2j-0000sD-V6 for tcpm-web-archive@optimus.ietf.org; Wed, 05 May 2004 14:22: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 OAA02359 for ; Wed, 5 May 2004 14:22: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 1BLR2h-0001v9-GF for tcpm-web-archive@ietf.org; Wed, 05 May 2004 14:22:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLR0v-00018f-00 for tcpm-web-archive@ietf.org; Wed, 05 May 2004 14:21:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLQyS-0000Rk-00 for tcpm-web-archive@ietf.org; Wed, 05 May 2004 14:18:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLQqQ-0004Vs-KA; Wed, 05 May 2004 14:10:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLQhI-0007zl-VX for tcpm@optimus.ietf.org; Wed, 05 May 2004 14:00: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 OAA00493 for ; Wed, 5 May 2004 14:00: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 1BLQhG-00033x-Lb for tcpm@ietf.org; Wed, 05 May 2004 14:00:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLQer-0002LE-00 for tcpm@ietf.org; Wed, 05 May 2004 13:58:14 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx with esmtp (Exim 4.12) id 1BLQcL-0001bW-00 for tcpm@ietf.org; Wed, 05 May 2004 13:55:38 -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 i45Htbhw096439; Wed, 5 May 2004 10:55:37 -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 1E6CF77A6D5; Wed, 5 May 2004 13:55:36 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 8AC59146E4A; Wed, 5 May 2004 13:55:35 -0400 (EDT) To: Joe Touch From: Mark Allman Reply-To: mallman@icir.org Cc: Kacheong Poon , tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt In-Reply-To: <409924D3.1090903@isi.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Lonesome Day MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 05 May 2004 13:55:35 -0400 Message-Id: <20040505175535.8AC59146E4A@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 > Low probability for sure, but if we're talking about security, it > should be included in the revision at least... Oh, sure! If one were to include an idea like this in any draft then it and its implications and failings should be fully addressed. allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin) iD8DBQFAmSqXWyrrWs4yIs4RAiW1AKCBpiWLDY4Y67vNehL8h+xRR07VUACaA5aE RpImyqToqkh1qNY7RU3iTwI= =Z3nR -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed May 5 14:48: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 OAA04100 for ; Wed, 5 May 2004 14: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 1BLRE4-0006N2-UO for tcpm-archive@odin.ietf.org; Wed, 05 May 2004 14:34:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45IYaqg024479 for tcpm-archive@odin.ietf.org; Wed, 5 May 2004 14:34:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLR7e-0003EY-RF for tcpm-web-archive@optimus.ietf.org; Wed, 05 May 2004 14:27: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 OAA03024 for ; Wed, 5 May 2004 14:27: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 1BLR7c-0003dM-AH for tcpm-web-archive@ietf.org; Wed, 05 May 2004 14:27:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLR6p-0003Jq-00 for tcpm-web-archive@ietf.org; Wed, 05 May 2004 14:27:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLR5F-0002cr-00 for tcpm-web-archive@ietf.org; Wed, 05 May 2004 14:25:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLQw6-0006Zx-41; Wed, 05 May 2004 14: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 1BLQoK-0003RK-1n for tcpm@optimus.ietf.org; Wed, 05 May 2004 14:08: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 OAA01200 for ; Wed, 5 May 2004 14:07: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 1BLQoH-0005Hr-KW for tcpm@ietf.org; Wed, 05 May 2004 14:07:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLQnN-00050R-00 for tcpm@ietf.org; Wed, 05 May 2004 14:07:02 -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 1BLQmW-0004Rw-00 for tcpm@ietf.org; Wed, 05 May 2004 14:06:08 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 05 May 2004 10:20:08 +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 i45I5WWB000451; Wed, 5 May 2004 11:05:36 -0700 (PDT) Received: from cisco.com (rtp-dial-1-240.cisco.com [10.83.97.240]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATS82130; Wed, 5 May 2004 11:04:28 -0700 (PDT) Message-ID: <40992C44.7020906@cisco.com> Date: Wed, 05 May 2004 14:02:44 -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: Allwyn Carvalho CC: Anantha Ramaiah , tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: <20040504161038.52F2577A71D@guns.icir.org> <40984E65.7090204@sun.com> <409875E9.C64FA34D@lucent.com> <409912B5.5080307@lucent.com> In-Reply-To: <409912B5.5080307@lucent.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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Allwyn: One comment in line has editor/typest :-0 Allwyn Carvalho wrote: > Hi Anantha, > Thanks for your response. See reply inline. > > Anantha Ramaiah wrote: > [snip] > >>> 1. For case B, I think you need to worry about RCV.NXT being in the >>> range of >>> [SEG.SEQ, SEG.SEQ + SEG.LEN] instead of simply being equal to >>> SEG.SEQ. For example, if SEG.SEQ is 1000 and RCV.NXT is 1001, it is >>> still a special case. >> >> >> >> Actually the revision to the draft (which will be posted soon) will >> clarify the above more clearly and list out one of the corner cases >> where >> if the sequence # chosen by the restarted host happens to be (seq# == >> RCV.NXT - 1) it would receive back an ACK = RCV.NXT which is an >> acceptable >> ACK in which case the RST wouldn't be sent back and the host would >> timeout >> the SYN. The next time if it attempts the SYN the initial sequence >> number >> would be different and should work hunky-dory. > > > I believe there are applications out there that will send FIN> all in the first segment, and no it doesn't violate RFC 793. > I'm not so sure what will happen if they are partially acked. Just > making sure you cover this. > >> >> Actually some implementations treat a RST with SNDUNA -1 as a RST of a >> keepalive packet and would consider the RST valid, but agreed it is >> implementation specific. The reason I am pointing this is because we >> could >> exploit this for modified case B) which would be re-worded as : >> "if the SYN bit is set and the sequence # == next expected sequence - 1, >> then send ACK to the peer with ACK# = RCVNXT - 1. >> >> Actually there is no issue with B) above. Pl see my reply to one of >> the earlier emails in this thread. >> >> >>> 2. Isn't the treatment of case C the same as case A? If so, >>> shouldn't this be re-phrased to make it less confusing? >> >> >> >> The reason it was posted seperately was that original RFC behaviour >> was to >> abort the connection and send RST, in the current solution we send ACK >> even for this case... > > > If you continue to keep A) and C) as separate cases, can you at least > make sure that the wording is consistent. One says "send an ACK back" > and one says "send an ACK segment". It's a minor point, but I think > it's important to be consistent. Ok I have changed these to both say send an ACK segment.... R > > > Allwyn. > >> >> -Anantha > > > > > _______________________________________________ > 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 May 5 15:24:30 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06711 for ; Wed, 5 May 2004 15:24: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 1BLRpN-0005hQ-62 for tcpm-archive@odin.ietf.org; Wed, 05 May 2004 15:13:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45JD9ua021907 for tcpm-archive@odin.ietf.org; Wed, 5 May 2004 15:13:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLRhL-0007LJ-Vp for tcpm-web-archive@optimus.ietf.org; Wed, 05 May 2004 15:04: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 PAA05138 for ; Wed, 5 May 2004 15: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 1BLRhI-0006NS-W5 for tcpm-web-archive@ietf.org; Wed, 05 May 2004 15:04:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLRgJ-00065r-00 for tcpm-web-archive@ietf.org; Wed, 05 May 2004 15:03:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLRfK-0005o0-00 for tcpm-web-archive@ietf.org; Wed, 05 May 2004 15:02:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLRZn-0007qj-5P; Wed, 05 May 2004 14:57:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLRU6-0005EL-1F for tcpm@optimus.ietf.org; Wed, 05 May 2004 14: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 OAA04275 for ; Wed, 5 May 2004 14:51:06 -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 1BLRU3-0002NS-6M for tcpm@ietf.org; Wed, 05 May 2004 14:51:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLRTH-00025A-00 for tcpm@ietf.org; Wed, 05 May 2004 14:50:20 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BLRS6-0001lh-00 for tcpm@ietf.org; Wed, 05 May 2004 14:49:06 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i45In2v06287; Wed, 5 May 2004 21:49:03 +0300 (EET DST) X-Scanned: Wed, 5 May 2004 21:48:58 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i45ImwgV030642; Wed, 5 May 2004 21:48:58 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00Vktmb7; Wed, 05 May 2004 21:48:57 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 i45ImtH14152; Wed, 5 May 2004 21:48:56 +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, 5 May 2004 13:48:55 -0500 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.6487.1 Subject: RE: [tcpm] security draft input request Date: Wed, 5 May 2004 13:48:54 -0500 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE016E80F5@daebe004.americas.nokia.com> Thread-Topic: [tcpm] security draft input request Thread-Index: AcQux3Um0odRM2b1T7+SxzwhC8HvHgCED9mgAHyc1dA= To: , , X-OriginalArrivalTime: 05 May 2004 18:48:55.0177 (UTC) FILETIME=[9DE48790:01C432D1] 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 [Few late comments...] > -----Original Message----- > From: tcpm-admin@ietf.org [mailto:tcpm-admin@ietf.org]On Behalf Of ext > Christian Huitema > Sent: 03 May, 2004 1:40 AM > To: mallman@icir.org; tcpm@ietf.org > Subject: RE: [tcpm] security draft input request >=20 >=20 > > Option #2: > >=20 > > Document the problem and the existing techniques that=20 > 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. >=20 > The MD5 option is specific to BGP, and should not be mentioned in a > generic TCP document. The proper mitigations are: >=20 > 1) Use IPSEC: this entirely eliminates the attack, including when the > attacker is on-path. I would agree that IPSec will solve the problem in principle, but in = practice that requires every TCP host (interested in preventing DoS = attacks) to have some form of PKI dependent credentials. This might be = okay for BGP router vendors if they have a vendor defined CA just for = this purpose, but it's not a valid option for every host on the = Internet. And even if it were possible to provide these credentials, = people would need to buy expensive new certificates (at least home = users) just to prevent some simple attacks every couple of years. I guess key-exchange (and the associated delay--typically 2 round trips = on top of TCP) is what makes IPSec less attractive to me. And without a = proper key exchange, it's practically impossible to prevent such = attacks. For example, establishing a session key using a well known long = term key will not work to prevent such attacks. An attacker who can find = the IP address of BGP hosts, can also establish an IPSec session with = one of the BGP hosts and send a Tunnel mode packet with the RST packet = in the tunnel part. Most IPSec policies will gladly send this packet to = TCP layer which will close the connection. (Of course with proper key = exchange, this is not a problem.) So although I don't fully agree with the "Secure TCP" draft, I think = it's better for TCP to have its own mechanism. Yogesh _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed May 5 15:59:28 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 PAA08657 for ; Wed, 5 May 2004 15:59: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 1BLSSs-0008NK-UN for tcpm-archive@odin.ietf.org; Wed, 05 May 2004 15:53:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45JrwF0032185 for tcpm-archive@odin.ietf.org; Wed, 5 May 2004 15:53:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLSJ9-00045m-Ot for tcpm-web-archive@optimus.ietf.org; Wed, 05 May 2004 15:43: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 PAA07755 for ; Wed, 5 May 2004 15:43: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 1BLSJ8-0001mH-6O for tcpm-web-archive@ietf.org; Wed, 05 May 2004 15:43:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLSIC-0001Ta-00 for tcpm-web-archive@ietf.org; Wed, 05 May 2004 15:42:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLSHH-0001AB-00 for tcpm-web-archive@ietf.org; Wed, 05 May 2004 15:41:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLS8c-0006e7-LG; Wed, 05 May 2004 15:33:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLS0x-0003wm-KF for tcpm@optimus.ietf.org; Wed, 05 May 2004 15:25: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 PAA06781 for ; Wed, 5 May 2004 15:25: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 1BLS0w-00044N-9X for tcpm@ietf.org; Wed, 05 May 2004 15:25:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLS03-0003nX-00 for tcpm@ietf.org; Wed, 05 May 2004 15:24:12 -0400 Received: from noteserv1.attotech.com ([12.32.232.51]) by ietf-mx with esmtp (Exim 4.12) id 1BLRzX-0003WV-00 for tcpm@ietf.org; Wed, 05 May 2004 15:23:40 -0400 Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt To: tcpm@ietf.org Cc: mallman@icir.org, Kacheong Poon , Joe Touch Message-ID: Date: Wed, 5 May 2004 15:23:17 -0400 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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 >> Doesn't this mean you can defeat someone else's ability to RST a >> connection by flooding them with RSTs? >> >> Holding state for a long time in that case means one party can't >> reset a connection they want - or need to, doesn't it? > >Oh, well another approach I'll throw out is not more than one RST >challenge per time period. E.g., no more than 1/second. That limits >the damage of an ACK war without allowing someone to deny the legitimate >ripping down of a connection for minutes. (At the expense of some >state.) Would a longer time period be better - reduce the probability of a successful attack? If a legitimate reset were lost when would you expect another? Can you guess based on RTT? Sorry for all the questions but I haven't had time to look in to this more deeply yet. I'm sure some of you can answer them right off. I have been wondering about this in the context of the long lived connections where the RST attack problem occurs. It seems to me they can handle some delay unless they need the resources immediately to start a new connection. For my application, iSCSI, we probe the connection at the application level after a period of inactivity in minutes, so we are OK. I'm not as familiar with the other long-lived applications that this affects. I wonder if what would have the most problem with the delay. Aaron _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 6 01:53: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 BAA06479 for ; Thu, 6 May 2004 01:53: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 1BLbkE-0004SP-3X for tcpm-archive@odin.ietf.org; Thu, 06 May 2004 01:48:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i465mUiL017133 for tcpm-archive@odin.ietf.org; Thu, 6 May 2004 01:48:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLbjM-00046L-PN for tcpm-web-archive@optimus.ietf.org; Thu, 06 May 2004 01:47: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 BAA05962 for ; Thu, 6 May 2004 01:47: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 1BLbjJ-0001Su-Jk for tcpm-web-archive@ietf.org; Thu, 06 May 2004 01:47:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLbiF-00016V-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 01:46:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLbho-0000lu-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 01:46:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLbc2-0001Ws-HD; Thu, 06 May 2004 01: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 1BLbaa-0000oU-Pf for tcpm@optimus.ietf.org; Thu, 06 May 2004 01:38: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 BAA05669 for ; Thu, 6 May 2004 01: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 1BLbaX-0006Ch-KX for tcpm@ietf.org; Thu, 06 May 2004 01:38:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLbZk-0005rr-00 for tcpm@ietf.org; Thu, 06 May 2004 01:37:41 -0400 Received: from [170.210.17.130] (helo=libertad.frh.utn.edu.ar) by ietf-mx with esmtp (Exim 4.12) id 1BLbYx-0005NI-00 for tcpm@ietf.org; Thu, 06 May 2004 01:36:51 -0400 Received: from fernando.gont.com.ar ([200.68.238.98]) by libertad.frh.utn.edu.ar (8.9.3/8.8.7) with ESMTP id DAA26397; Thu, 6 May 2004 03:09:21 -0400 Message-Id: <4.3.2.7.2.20040505094658.00c22240@mail.daleclick.com> X-Sender: fgont@mail.daleclick.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 06 May 2004 02:36:10 -0300 To: Lars Eggert , tcpm@ietf.org From: Fernando Gont Subject: Re: [tcpm] [Fwd: I-D ACTION:draft-eggert-tcpm-tcp-abort-timeout-option-00.txt] In-Reply-To: <40861F36.2050304@netlab.nec.de> 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:13 21/04/2004 +0200, Lars Eggert wrote: >this announcement doesn't seem to have made it onto the list. I'd >appreciate some group feedback on the ID. Here's my feedback on your draft. Note that some of my comments are some "eitorial" notes, while others are technical stuff. Page 2, first para: It says "In between connected periods, mobile hosts may experience disconnected periods during which no network service is available." I'd probably re-phrase it as "Mobile hosts may experience periods of time during which no network service is available." Page 2, first para: It says "....their established TCP connections can abort during periods of disconnection." I'd write it as "....their established connections may be aborted during periods of disconnection." Page 2, second para: It says "If a disconnection lasts longer than the user timeout, the TCP connection will abort". I'd say "....will be aborted", instead. Page 2, third para: It says "Instead of a single user timeout, some TCP implementations offer finer-grained mechanisms" IMHO, it should say "policies" instead of "mechanisms". Page 2, third para: It says "The Host Requirements document". I'd say "RFC" instead of "document". Page 2, fourth para: It says "This document specifies a new TCP option - the Abort Timeout Option". IMHO, "Abort timeout" is a misnomer. I'd call it "Connection Timeout", instead. (I would also change all instances of "abort timeout" to "connection timeout"). Page 3, first para: It says "A host wishing to negotiate a specific abort timeout for a connection MAY include the TCP Abort Timeout Option". As you say "A host wishing to negotiate a specific abort timeout", I'm not sure whether I'd say "MAY" (i.e., I'd probably say "MUST"). (I would do say "MAY" if you just said "A host MAY include the TCP Abort Timeout Option"). Page 3, first para: It says "It MUST NOT include an Abort Timeout Option in any other segment." Note that the ATO is included in segments other than those with the SYN bit set. See Figure 2, the one on the right: The ATO is included in a pure-ACK segment (i.e., the SYN bit is not set). Page 3, second para: It says "Connections use abort timeouts negotiated with Abort Timeout Options during the ESTABLISHED state only." I'd write it as "The negotiated timeout is meant to be used only during the ESTABLISHED state." Page 3, fourth para: It says "Upon receipt of a segment with the Abort Timeout Option, the receiving host decides whether to accept, shorten, or reject its peer's proposed abort timeout." Why shouldn't the receiving host be able to *enlarge* the proposed abort timeout? Page 3, fifth para: It says "This will either be the SYN-ACK, if it received the peer's Timeout Abort Option...." It should say "Abort Timeout Option" instead of "Timeout Abort Option". Page 3, fifth para: It says: " When a receiving host accepts or shortens the offered abort timeout, it MUST include an Abort Timeout Option with the corresponding timeout value in the next segment it sends. This will either be the SYN-ACK, if it received the peer's Timeout Abort Option in the SYN segment, or the first ACK if it received the option in the SYN-ACK segment." Consider the following scenario: Host A receives the peer's ATO in the SYN-ACK segment, and thus includes the ATO in the first ACK. This ACK is lost. Before the peer timouts and retransmits the SYN-ACK segment, A sends some data to the peer. In this scenario, the peer will think A does not support the ATO, when it *does* support it. Page 4: Have you considered using the "TCP Abort Timeout Option" in a similar fashion to TCP's MSS option? I mean, rather than "negotiating" a timeout, I'd just make the end-points "suggest" a timeout. The option would be sent in the SYN segment, in the same way as the MSS option. The timout wouldn't need to be symmetrical, either. How to deal with the option would be a policy of each system. However, I'd probably suggest that the larger of both values (in case both end-points included the ATO) is chosen, provided it's not larger than a per-system defined limit (that means, if one of the endpoints specifies a timeout period of, say, 60 minutes, but the system limit is 40 minutes, then *40* minutes would be chosen for the timeout period). Page 4, second para: It says "It MUST then also use its default timeout value for the connection." I'd probably remove the word "also". Page 4, fourth para: It says "If it does, the connection MUST use the abort timeout contained inside the Abort Timeout Option." I'd say "TCP" instead of "the connection". Page 4, fourth para: It says "If it does, the connection MUST use the abort timeout contained inside the Abort Timeout Option." I'd say "TCP" instead of "the connection". Page 4, fifth para: It says "This causes the connection to use the default abort timeout, thus ensuring interoperability." I'd say "TCP" instead of "the connection". Page 5, first para: "The TCP specification [1] does not define a range for permitted abort timeouts." Shouldn't it say "of" instead of "for"? Page 5, second para: It says "Very short timeout values can affect TCP retransmissions over high-delay paths." I'm not sure what you mean here. Page 6, first para: It says "Connections could default to starting with shorter timeouts and only negotiate longer timeouts when disconnection was imminent." I'd probably say "short" instead of "shorter". Page 6, first para: It says "Connections could default to starting with shorter timeouts and only negotiate longer timeouts when disconnection was imminent." What do you mean by "when disconnection was imminent"? Page 6, first para: It says "This may reduce the amount of state held during times of disconnection." I'm not sure what you mean here. Page 6, third para: It says "It may be useful to permit finer-grained timeouts, e.g., milliseconds instead of seconds." What would you use such a timeout period for? Page 6, third para: "For example, a 16-bit timeout value with a granularity of seconds allows timeout values up to 18.2 hours, whereas a 32-bit timestamp with millisecond granularity allows timeout values up to 49.7 days." I'd stick to a granularity of seconds. Regarding the length of the timeout field, I'm not sure there's a real use for a timeout of, say 49.7 days. So I'd probably stick to a 16-bit field. Page 7, second para: It says " However, when an attacker completes the three-way handshakes of its throw-away connections it can amplify the effects of resource exhaustion attacks, because the attacked server must maintain the connection state associated with the throw-away connections for longer durations." If the attacker was able to complete the three-way handshake, then it's likely he will also be able to ACK whatever the victim is sending over the connection, so that the connection is not aborted. OTOH, note that, in principle, the throw-away connections will be aborted only if the victim sends data on the connection. If that's not the case then there's no reason for the connection to timeout. If you're thinking about TCP's Keepalive mechanism, I'd say that given the large timeout values it usually has, it would not stop the attack. Page 7, third para: It says "Although this is arguably the most complete solution, it depends on external mechanisms to establish trust." I'd probably say "the trust relationship", instead of "trust". Page 8, it says: ' [6] Moskowitz, R., "Host Identity Protocol Architecture", draft-moskowitz-hip-arch-05 (work in progress), October 2003.' I think there should be a new version of this draft. Just my two cents, -- 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 Thu May 6 03:56:53 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25283 for ; Thu, 6 May 2004 03:56: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 1BLdi9-00026Z-FQ for tcpm-archive@odin.ietf.org; Thu, 06 May 2004 03:54:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i467sTvG008090 for tcpm-archive@odin.ietf.org; Thu, 6 May 2004 03:54:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLdZW-0006Lx-RV for tcpm-web-archive@optimus.ietf.org; Thu, 06 May 2004 03:45: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 DAA24696 for ; Thu, 6 May 2004 03: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 1BLdZT-0003Os-Qd for tcpm-web-archive@ietf.org; Thu, 06 May 2004 03:45:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLdYW-000336-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 03:44:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLdXz-0002hG-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 03:44:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLdOO-0002Pv-Fq; Thu, 06 May 2004 03:34:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLdMn-0001X1-HE for tcpm@optimus.ietf.org; Thu, 06 May 2004 03:32: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 DAA24075 for ; Thu, 6 May 2004 03:32: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 1BLdMl-0006Ty-5D for tcpm@ietf.org; Thu, 06 May 2004 03:32:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLdLo-00069B-00 for tcpm@ietf.org; Thu, 06 May 2004 03:31:24 -0400 Received: from [170.210.17.130] (helo=libertad.frh.utn.edu.ar) by ietf-mx with esmtp (Exim 4.12) id 1BLdKw-0005TS-00 for tcpm@ietf.org; Thu, 06 May 2004 03:30:31 -0400 Received: from fernando.gont.com.ar ([200.68.222.215]) by libertad.frh.utn.edu.ar (8.9.3/8.8.7) with ESMTP id FAA26807; Thu, 6 May 2004 05:02:25 -0400 Message-Id: <4.3.2.7.2.20040506030415.00b35870@mail.daleclick.com> X-Sender: fgont@mail.daleclick.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 06 May 2004 04:30:13 -0300 To: tcpm@ietf.org From: Fernando Gont Subject: Re: [tcpm] security draft input request Cc: mallman@icir.org, Kacheong Poon , "Randall Stewart (cisco)" In-Reply-To: <20040430131701.9B74E1447D3@lawyers.icir.org> 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:16 30/04/2004 -0400, Mark Allman wrote: >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). I have not been able to follow all the messages related to this issue, so I beg your pardon if I'm just out of sync. Readin Randall's draft, I see that in the "Blind data injection attack" solution, an additional input check is proposed. Is there any reason for which the same solution is *not* proposed for the "Blind reset attack using the RST bit"? -- 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 Thu May 6 04:59:00 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 EAA28648 for ; Thu, 6 May 2004 04:59: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 1BLee4-00011q-9R for tcpm-archive@odin.ietf.org; Thu, 06 May 2004 04:54:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i468sKFW003925 for tcpm-archive@odin.ietf.org; Thu, 6 May 2004 04:54:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLeVi-00069V-6U for tcpm-web-archive@optimus.ietf.org; Thu, 06 May 2004 04:45: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 EAA28018 for ; Thu, 6 May 2004 04:45: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 1BLeVf-00033L-3Y for tcpm-web-archive@ietf.org; Thu, 06 May 2004 04:45:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLeUg-0002ed-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 04:44:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLeTm-0002FN-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 04:43:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLeKZ-0001RS-Lr; Thu, 06 May 2004 04:34:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLeFH-00070q-38 for tcpm@optimus.ietf.org; Thu, 06 May 2004 04:28: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 EAA27169 for ; Thu, 6 May 2004 04:28: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 1BLeFD-0004LA-Kt for tcpm@ietf.org; Thu, 06 May 2004 04:28:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLeEF-0003x9-00 for tcpm@ietf.org; Thu, 06 May 2004 04:27:40 -0400 Received: from [170.210.17.130] (helo=libertad.frh.utn.edu.ar) by ietf-mx with esmtp (Exim 4.12) id 1BLeDg-0003YN-00 for tcpm@ietf.org; Thu, 06 May 2004 04:27:05 -0400 Received: from fernando.gont.com.ar ([200.68.238.157]) by libertad.frh.utn.edu.ar (8.9.3/8.8.7) with ESMTP id FAA26886; Thu, 6 May 2004 05:52:28 -0400 Message-Id: <4.3.2.7.2.20040506050423.00c391a0@mail.daleclick.com> X-Sender: fgont@mail.daleclick.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 06 May 2004 05:06:09 -0300 To: mallman@icir.org, Yogesh.Swami@nokia.com From: Fernando Gont Subject: Re: [tcpm] WG consensus sought (deadline 5 May): abort timeout negotiation Cc: lars.eggert@netlab.nec.de, thomas.r.henderson@boeing.com, tcpm@ietf.org In-Reply-To: <20040429021540.C4F76144067@lawyers.icir.org> References: <025E7DD4182874489CC2F61EE0FA19CE016E80F0@daebe004.americas.nokia.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 22:15 28/04/2004 -0400, Mark Allman wrote: >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). IMO, "Yes". -- 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 Thu May 6 06:49: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 GAA05142 for ; Thu, 6 May 2004 06:49: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 1BLgL4-0002Tu-PY for tcpm-archive@odin.ietf.org; Thu, 06 May 2004 06:42:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46AgoGf009537 for tcpm-archive@odin.ietf.org; Thu, 6 May 2004 06:42:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLgIv-0001kZ-Ng for tcpm-web-archive@optimus.ietf.org; Thu, 06 May 2004 06:40: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 GAA04641 for ; Thu, 6 May 2004 06:40: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 1BLgIr-00016G-Rm for tcpm-web-archive@ietf.org; Thu, 06 May 2004 06:40:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLgHq-0000hq-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 06:39:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLgGm-000097-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 06:38:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLg9d-0007UW-5j; Thu, 06 May 2004 06:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLg2m-0004aG-D5 for tcpm@optimus.ietf.org; Thu, 06 May 2004 06:23: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 GAA03673 for ; Thu, 6 May 2004 06:23: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 1BLg2i-0002A7-I0 for tcpm@ietf.org; Thu, 06 May 2004 06:23:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLg1O-0001Tp-00 for tcpm@ietf.org; Thu, 06 May 2004 06:22: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 1BLfzq-0000Z1-00 for tcpm@ietf.org; Thu, 06 May 2004 06:20:54 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 06 May 2004 02:33:50 +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 i46AKNW9021319; Thu, 6 May 2004 03:20:23 -0700 (PDT) Received: from cisco.com (rtp-dial-1-86.cisco.com [10.83.97.86]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATT66520; Thu, 6 May 2004 03:20:19 -0700 (PDT) Message-ID: <409A10FA.2090001@cisco.com> Date: Thu, 06 May 2004 06:18:34 -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: AClarke@attotech.com CC: tcpm@ietf.org, mallman@icir.org, Kacheong Poon , Joe Touch 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 AClarke@attotech.com wrote: >>>Doesn't this mean you can defeat someone else's ability to RST a >>>connection by flooding them with RSTs? >>> >>>Holding state for a long time in that case means one party can't >>>reset a connection they want - or need to, doesn't it? >>> >>> >>Oh, well another approach I'll throw out is not more than one RST >>challenge per time period. E.g., no more than 1/second. That limits >>the damage of an ACK war without allowing someone to deny the legitimate >>ripping down of a connection for minutes. (At the expense of some >>state.) >> >> >Would a longer time period be better - reduce the probability of a >successful attack? If a legitimate reset were lost >when would you expect another? Can you guess based on RTT? > It seems to me one could add at a minimum a dampening so that you would respond to RST's/Ack wars with a slower rate.. say start with RST_ACK_DELAY = 0 Then when you get a RST and respond with an ACK, add the current RTT to the RST_ACK_DELAY. Next RST since RST_ACK_DELAY is not 0, you start a timer and at expiration send your ACK and add yet another RTT to the RST_ACK_DELAY. This gives you a kind of exponential backoff (not quite though).. and one could even ignore all further RST's if the timer was running... It would slow the RST process down a tad.. but you would have to be real unlucky to get a real RST slowed down more than 1 or 2 RTTs... The bad side to this is it is no longer just a tweak to to the stack.. you really must add a timer and quite a few more bytes to the TCB to track this... R > >Sorry for all the questions but I haven't had time to look in to >this more deeply yet. I'm sure some of you can answer them right off. > >I have been wondering about this in the context of the long lived >connections where the RST attack problem occurs. It seems to me >they can handle some delay unless they need the resources immediately >to start a new connection. For my application, iSCSI, we probe the >connection at the application level after a period of inactivity in >minutes, so we are OK. I'm not as familiar with the other long-lived >applications that this affects. I wonder if what would have the most >problem with the delay. > >Aaron > > > >_______________________________________________ >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 May 6 06:58: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 GAA05471 for ; Thu, 6 May 2004 06:58: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 1BLgR8-0006CC-1F for tcpm-archive@odin.ietf.org; Thu, 06 May 2004 06:49:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46An5Ok023810 for tcpm-archive@odin.ietf.org; Thu, 6 May 2004 06:49:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLgKP-0002Pm-0A for tcpm-web-archive@optimus.ietf.org; Thu, 06 May 2004 06:42: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 GAA04792 for ; Thu, 6 May 2004 06:42: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 1BLgKL-0001bG-1I for tcpm-web-archive@ietf.org; Thu, 06 May 2004 06:42:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLgJF-0001AB-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 06:40:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLgIK-0000jg-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 06:40:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLgAb-0007gR-0l; Thu, 06 May 2004 06:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLg4M-0005MO-HF for tcpm@optimus.ietf.org; Thu, 06 May 2004 06:25: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 GAA03804 for ; Thu, 6 May 2004 06:25: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 1BLg4I-0002yk-Ln for tcpm@ietf.org; Thu, 06 May 2004 06:25:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLg3L-0002Yz-00 for tcpm@ietf.org; Thu, 06 May 2004 06:24:32 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BLg2H-0001ii-00 for tcpm@ietf.org; Thu, 06 May 2004 06:23:25 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 06 May 2004 03:23:06 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i46AMrjO018629; Thu, 6 May 2004 03:22:54 -0700 (PDT) Received: from cisco.com (rtp-dial-1-86.cisco.com [10.83.97.86]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATT66606; Thu, 6 May 2004 03:22:51 -0700 (PDT) Message-ID: <409A1191.90807@cisco.com> Date: Thu, 06 May 2004 06:21:05 -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: Fernando Gont CC: tcpm@ietf.org, mallman@icir.org, Kacheong Poon Subject: Re: [tcpm] security draft input request References: <4.3.2.7.2.20040506030415.00b35870@mail.daleclick.com> In-Reply-To: <4.3.2.7.2.20040506030415.00b35870@mail.daleclick.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 Fernando Gont wrote: > At 09:16 30/04/2004 -0400, Mark Allman wrote: > >> 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). > > > I have not been able to follow all the messages related to this issue, > so I beg your pardon if I'm just out of sync. > > Readin Randall's draft, I see that in the "Blind data injection > attack" solution, an additional input check is proposed. > Is there any reason for which the same solution is *not* proposed for > the "Blind reset attack using the RST bit"? We talked about this (the folks in the contributors section) and if I remember right they all rightly pointed out that the ACK value is not necessarily something that one can count on in a RST... the sequence number is I think the only thing that is copied per 793... R > > > > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > > > -- 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 May 6 06:59: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 GAA05490 for ; Thu, 6 May 2004 06:59: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 1BLgSa-0006Ss-4v for tcpm-archive@odin.ietf.org; Thu, 06 May 2004 06:50:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46AoaMW024845 for tcpm-archive@odin.ietf.org; Thu, 6 May 2004 06: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 1BLgOi-00055L-CY for tcpm-web-archive@optimus.ietf.org; Thu, 06 May 2004 06:46: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 GAA05013 for ; Thu, 6 May 2004 06:46: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 1BLgOe-0003Vr-88 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 06:46:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLgNj-00039S-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 06:45:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLgNS-0002mv-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 06:45:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLgJK-0001vN-W8; Thu, 06 May 2004 06:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLgCL-0007kN-EP for tcpm@optimus.ietf.org; Thu, 06 May 2004 06:33: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 GAA04234 for ; Thu, 6 May 2004 06:33: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 1BLgCH-0006C5-GT for tcpm@ietf.org; Thu, 06 May 2004 06:33:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLgBT-0005ol-00 for tcpm@ietf.org; Thu, 06 May 2004 06:32:56 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BLgAg-0005Lc-00 for tcpm@ietf.org; Thu, 06 May 2004 06:32:06 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 06 May 2004 03:31:47 -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 i46AVZW9029910; Thu, 6 May 2004 03:31:35 -0700 (PDT) Received: from cisco.com (rtp-dial-1-86.cisco.com [10.83.97.86]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATT66827; Thu, 6 May 2004 03:31:32 -0700 (PDT) Message-ID: <409A139B.90005@cisco.com> Date: Thu, 06 May 2004 06:29:47 -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: mallman@icir.org CC: Kacheong Poon , tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: <20040505162244.8EC8577A6D5@guns.icir.org> In-Reply-To: <20040505162244.8EC8577A6D5@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: >>Having seen some ACK wars interacting with middlebox, I am not >>comfortable with a change which responds to a RST, which is supposed >>to tell the other side to stop sending. It is similar to responding >>to an ACK with an ACK. >> >> > >I disagree. ACKing an ACK is ... err, pointless (at least at first >blush). Having some form of handshake to bring down a connection is >not, IMO. I think these are two fundementally different situations. If >we were to start from scratch today, we'd no-doubt invent some scheme so >that a RST had to include a handshake sort of thing, or that the RST had >to include some sort of a hash or nonce or something to prove it saw the >segment it is responding to (ala, the SCTP vtag scheme). Given that, >can we make some sort of modest change to TCP to get such functionality? >Of course, we're not designing from a clean slate and so this is more >difficult. But, I think ruling out a verification scheme out-of-hand is >not the right approach, because that is fundementally what we need. > > Well, has Kacheong as put forward earlier.. one could always use a similar scheme to SCTP... pick a random hash and add it to every packet. Then RST's and such could validate this hash. But that does not cover the SYN in window issue I think.. or am I missing something? In SCTP we always respond to the SYN equivilant (INIT) with a SYN-ACK sort of thing (INIT-ACK) but we never change the state of the existing connection... The SYN sender must instead send back a cooke that is in the INIT-ACK... and then finally a COOKIE-ACK is sent (a fourth leg in the handshake). I do know that cookie's have been done in TCP and some implementations do them.. not sure how they work since I know its still a 3-way handshake and I think the SYN problem still exists... ??? R Of course I > > >>As I mentioned before, I am not against changing TCP. But I think we >>should be careful in doing it. >> >> > >Absolutely. > >allman > > >-- >Mark Allman -- ICIR -- http://www.icir.org/mallman/ > > > > > -- 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 May 6 10:25:55 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16501 for ; Thu, 6 May 2004 10:25: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 1BLjgD-000281-3D for tcpm-archive@odin.ietf.org; Thu, 06 May 2004 10:16:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46EGrqH008181 for tcpm-archive@odin.ietf.org; Thu, 6 May 2004 10:16:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLjYg-0005qf-Lm for tcpm-web-archive@optimus.ietf.org; Thu, 06 May 2004 10:09: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 KAA14883 for ; Thu, 6 May 2004 10:09: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 1BLjYe-0007Ag-Io for tcpm-web-archive@ietf.org; Thu, 06 May 2004 10:09:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLjXi-0006jL-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 10:08:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLjWz-0006Gz-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 10:07:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLjR1-0008CG-HX; Thu, 06 May 2004 10:01:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLjIp-0003bG-Oi for tcpm@optimus.ietf.org; Thu, 06 May 2004 09:52: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 JAA13434 for ; Thu, 6 May 2004 09:52: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 1BLjIn-0000Fz-PG for tcpm@ietf.org; Thu, 06 May 2004 09:52:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLjHx-0007d8-00 for tcpm@ietf.org; Thu, 06 May 2004 09:51:50 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BLjGy-0006lP-00 for tcpm@ietf.org; Thu, 06 May 2004 09:50:48 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i46DoHl19394 for ; Thu, 6 May 2004 06:50:17 -0700 (PDT) (envelope-from pgoyette@juniper.net) Received: from pgoyette600 (pgoyette-600.jnpr.net [172.24.0.72]) by merlot.juniper.net (8.11.3/8.11.3) with SMTP id i46DoCJ60888 for ; Thu, 6 May 2004 06:50:12 -0700 (PDT) (envelope-from pgoyette@juniper.net) From: "Paul Goyette" To: Subject: RE: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt Date: Thu, 6 May 2004 06:50:11 -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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: 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 Clarifying my own post from yesterday: > Perhaps "Don't send repeated challenges with the same ACK value" would > be adequate? Then you only need to keep track of one new state value, > the last value sent in a challenge ACK. This should eliminate the ACK > war scenario. At least one person took this to mean that I was suggesting we select a _new_ ACK value for repeated RST segments. That's not what I meant. The intent of this is "If the value in the challenge ACK would be the same as the value sent in the previous challenge ACK, don't send any ACK at all." _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 6 13:49:07 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06866 for ; Thu, 6 May 2004 13: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 1BLmfd-0000Cz-Ux for tcpm-archive@odin.ietf.org; Thu, 06 May 2004 13:28:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46HSTi7000802 for tcpm-archive@odin.ietf.org; Thu, 6 May 2004 13:28:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLmQY-00050Z-Cq for tcpm-web-archive@optimus.ietf.org; Thu, 06 May 2004 13:12: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 NAA02398 for ; Thu, 6 May 2004 13:12: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 1BLmQW-0000jS-IH for tcpm-web-archive@ietf.org; Thu, 06 May 2004 13:12:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLmNX-00074N-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 13:09:48 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BLmKq-00062L-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 13:07:00 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BLmKs-0002It-Dx for tcpm-web-archive@ietf.org; Thu, 06 May 2004 13:07:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLlNR-0007NN-Gg; Thu, 06 May 2004 12:05:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLku7-00079n-WC for tcpm@optimus.ietf.org; Thu, 06 May 2004 11:35: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 LAA20595 for ; Thu, 6 May 2004 11:35: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 1BLku6-00051k-Vm for tcpm@ietf.org; Thu, 06 May 2004 11:35:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLkt4-0004ZH-00 for tcpm@ietf.org; Thu, 06 May 2004 11:34:15 -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 1BLksO-00046Q-00 for tcpm@ietf.org; Thu, 06 May 2004 11:33:32 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 06 May 2004 07:47:42 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i46FWxC1001819; Thu, 6 May 2004 08:32:59 -0700 (PDT) Received: from cisco.com (rtp-dial-1-228.cisco.com [10.83.97.228]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATT83292; Thu, 6 May 2004 08:32:48 -0700 (PDT) Message-ID: <409A5A29.1060702@cisco.com> Date: Thu, 06 May 2004 11:30: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: 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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Goyette wrote: >Clarifying my own post from yesterday: > > > >>Perhaps "Don't send repeated challenges with the same ACK value" would >>be adequate? Then you only need to keep track of one new state value, >>the last value sent in a challenge ACK. This should eliminate the ACK >>war scenario. >> >> > >At least one person took this to mean that I was suggesting we select a >_new_ ACK value for repeated RST segments. That's not what I meant. > >The intent of this is "If the value in the challenge ACK would be the >same as the value sent in the previous challenge ACK, don't send any >ACK at all." > > Hmm.. that would surely prevent any ACK war from occuring... R > >_______________________________________________ >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 May 6 13:50:32 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06976 for ; Thu, 6 May 2004 13:50: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 1BLmgs-0000fC-UR for tcpm-archive@odin.ietf.org; Thu, 06 May 2004 13:29:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46HTkRL002544 for tcpm-archive@odin.ietf.org; Thu, 6 May 2004 13: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 1BLmTG-0006mU-Ap for tcpm-web-archive@optimus.ietf.org; Thu, 06 May 2004 13:15: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 NAA02637 for ; Thu, 6 May 2004 13:15: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 1BLmTE-0001Vf-En for tcpm-web-archive@ietf.org; Thu, 06 May 2004 13:15:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLmPN-0000Bk-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 13:11:42 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BLmMX-0006mU-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 13:08: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 1BLmMY-0002NF-Ed for tcpm-web-archive@ietf.org; Thu, 06 May 2004 13:08:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLlNV-0007Qb-TH; Thu, 06 May 2004 12:05:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLkuG-0007ha-S7 for tcpm@optimus.ietf.org; Thu, 06 May 2004 11:35:28 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20602; Thu, 6 May 2004 11:35:26 -0400 (EDT) Message-Id: <200405061535.LAA20602@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, 06 May 2004 11:35:26 -0400 Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-frto-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 : F-RTO: An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and SCTP Author(s) : P. Sarolahti, M. Kojo Filename : draft-ietf-tcpm-frto-00.txt Pages : 22 Date : 2004-5-5 Spurious retransmission timeouts cause suboptimal TCP performance, because they often result in unnecessary retransmission of the last window of data. This document describes the F-RTO detection algorithm for detecting spurious TCP retransmission timeouts. F-RTO is a TCP sender only algorithm that does not require any TCP options to operate. After retransmitting the first unacknowledged segment triggered by a timeout, the F-RTO algorithm at a TCP sender monitors the incoming acknowledgments to determine whether the timeout was spurious and to decide whether to send new segments or retransmit unacknowledged segments. The algorithm effectively helps to avoid additional unnecessary retransmissions and thereby improves TCP performance in case of a spurious timeout. The F-RTO algorithm can also be applied to SCTP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-frto-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-frto-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-frto-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-5-6113614.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-frto-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-frto-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-6113614.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 6 13:51:30 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07064 for ; Thu, 6 May 2004 13:51: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 1BLmiz-0002Mu-62 for tcpm-archive@odin.ietf.org; Thu, 06 May 2004 13:31:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46HVv8S009069 for tcpm-archive@odin.ietf.org; Thu, 6 May 2004 13:31:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLmY7-0002Px-2V for tcpm-web-archive@optimus.ietf.org; Thu, 06 May 2004 13:20: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 NAA03506 for ; Thu, 6 May 2004 13:20: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 1BLmY5-0003K2-8E for tcpm-web-archive@ietf.org; Thu, 06 May 2004 13:20:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLmWW-0002ie-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 13:19:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLmTa-0001gs-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 13:16:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLlrJ-00083D-T1; Thu, 06 May 2004 12:36:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLl8P-0007KN-PR for tcpm@optimus.ietf.org; Thu, 06 May 2004 11:50: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 LAA21926 for ; Thu, 6 May 2004 11:50: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 1BLl8O-0004R1-Ln for tcpm@ietf.org; Thu, 06 May 2004 11:50:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLl7M-0003vZ-00 for tcpm@ietf.org; Thu, 06 May 2004 11:49:01 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BLl6R-00030U-00 for tcpm@ietf.org; Thu, 06 May 2004 11:48:03 -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 i46FkuJ07287; Thu, 6 May 2004 08:46:56 -0700 (PDT) Message-ID: <409A5E6A.3070808@isi.edu> Date: Thu, 06 May 2004 08:48:58 -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="------------enig8DCC8081D2CF3A43F56C95DF" X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: [tcpm] new internet draft - drafft-touch-anonsec 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) --------------enig8DCC8081D2CF3A43F56C95DF Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, all, The following I-D is soon to appear in the drafts directory; until then, here is the title and abstract, and it is available now at: http://www.isi.edu/touch/pubs/draft-touch-anonsec-00.txt At this time, I'm soliciting discussion and feedback on both TCPM and IPsec mailing lists, where discussion of the issues of IPsec have been ongoing. I track both lists; please do NOT cross-post. I'll cross-summarize periodically if it proves necessary. I'd also like to solicit input on in which WG to proceed. Joe ---- ANONsec: Anonymous IPsec to Defend Against Spoofing Attacks draft-touch-anonsec Recent attacks on core Internet infrastructure indicate an increased vulnerability of TCP connections to spurious resets (RSTs). TCP has always been susceptible to such RST spoof attacks, which were indirectly protected by checking that the RST sequence number was inside the current receive window, as well as via the obfuscation of TCP endpoint and port numbers. For pairs of well-known endpoints often over predictable port pairs, such as BGP, increases in the path bandwidth-delay product of a connection have sufficiently increased the receive window space that off-path third parties can guess a viable RST sequence number. This document addresses this vulnerability, discussing proposed solutions at the transport level and their inherent challenges, as well as existing network level solutions and the feasibility of their deployment. Finally, it proposes an extension to IPsec configuration called ANONsec that intends to efficiently and scalably secure any transport protocol from such off-path third-party spoofing attacks. ---- --------------enig8DCC8081D2CF3A43F56C95DF 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 iD8DBQFAml5wE5f5cImnZrsRAp3+AKDv5hbglmQkoyo560lwz/S0oy4/TQCgigPW 2RkCB3ewa4u3zTMDdrv/Zlk= =EQxM -----END PGP SIGNATURE----- --------------enig8DCC8081D2CF3A43F56C95DF-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 6 13:52: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 NAA07188 for ; Thu, 6 May 2004 13:52: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 1BLmlV-0003Wr-3G for tcpm-archive@odin.ietf.org; Thu, 06 May 2004 13:34:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46HYXoH013561 for tcpm-archive@odin.ietf.org; Thu, 6 May 2004 13:34:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLmZh-0003yl-KY for tcpm-web-archive@optimus.ietf.org; Thu, 06 May 2004 13:22: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 NAA03751 for ; Thu, 6 May 2004 13:22: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 1BLmZf-0004Gt-Pn for tcpm-web-archive@ietf.org; Thu, 06 May 2004 13:22:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLmYB-0003O0-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 13:20:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLmWj-0002kM-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 13:19:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLlsB-00006r-U2; Thu, 06 May 2004 12:37:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLlEl-0002Pt-9M for tcpm@optimus.ietf.org; Thu, 06 May 2004 11:56: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 LAA22532 for ; Thu, 6 May 2004 11:56: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 1BLlEk-0007Op-3b for tcpm@ietf.org; Thu, 06 May 2004 11:56:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLlDM-0006pJ-00 for tcpm@ietf.org; Thu, 06 May 2004 11:55:12 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BLlC9-0005sN-00 for tcpm@ietf.org; Thu, 06 May 2004 11:53:57 -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 i46FqwJ08898; Thu, 6 May 2004 08:52:58 -0700 (PDT) Message-ID: <409A5FDA.9080102@isi.edu> Date: Thu, 06 May 2004 08:55:06 -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 Subject: Re: [tcpm] security draft input request References: <20040430131701.9B74E1447D3@lawyers.icir.org> In-Reply-To: <20040430131701.9B74E1447D3@lawyers.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="------------enig952CEE84DE6F138F8F28C139" 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) --------------enig952CEE84DE6F138F8F28C139 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, all, Mark Allman wrote: > > 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 My attempt at option #3 was just posted - draft-touch-anonsec I do not believe this is fundamentally a TCP issue, as I have stated on this list before, and this draft summarizes. That suggests that it is not clear whether this should be a WG output; at this time, it is an individual submission only. Joe --------------enig952CEE84DE6F138F8F28C139 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 iD8DBQFAml/aE5f5cImnZrsRAoMYAKDThlKcQoksvXnu5brqsL6KhxKO+QCePEKl cZ8f0UnoTRqgNqFH0fAu+0o= =tXWf -----END PGP SIGNATURE----- --------------enig952CEE84DE6F138F8F28C139-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 6 13:59:01 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07720 for ; Thu, 6 May 2004 13:59: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 1BLmzG-0001Hf-67 for tcpm-archive@odin.ietf.org; Thu, 06 May 2004 13:48:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46HmkQ5004936 for tcpm-archive@odin.ietf.org; Thu, 6 May 2004 13:48:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLmg0-0000LK-GD for tcpm-web-archive@optimus.ietf.org; Thu, 06 May 2004 13:28: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 NAA04853 for ; Thu, 6 May 2004 13:28: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 1BLmfy-00077U-GF for tcpm-web-archive@ietf.org; Thu, 06 May 2004 13:28:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLmeG-0006ET-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 13:27:04 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BLmbt-0005LK-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 13:24:37 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BLmbv-0002m8-9R for tcpm-web-archive@ietf.org; Thu, 06 May 2004 13:24:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLmNv-0002uH-WE; Thu, 06 May 2004 13: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 1BLlP1-0000TI-2d for tcpm@optimus.ietf.org; Thu, 06 May 2004 12:07: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 MAA23875 for ; Thu, 6 May 2004 12:07: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 1BLlOz-0003lW-Pq for tcpm@ietf.org; Thu, 06 May 2004 12:07:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLlLl-0002Ww-00 for tcpm@ietf.org; Thu, 06 May 2004 12:03:55 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BLlIP-0001CJ-00 for tcpm@ietf.org; Thu, 06 May 2004 12:00:25 -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 i46FwMBm064090; Thu, 6 May 2004 08:58:23 -0700 (PDT) (envelope-from pgoyette@juniper.net) Received: from pgoyette600 (pgoyette-600.jnpr.net [172.24.0.72]) by merlot.juniper.net (8.11.3/8.11.3) with SMTP id i46FwMJ72988; Thu, 6 May 2004 08:58:22 -0700 (PDT) (envelope-from pgoyette@juniper.net) From: "Paul Goyette" To: "Randall Stewart \(cisco\)" Cc: Subject: RE: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt Date: Thu, 6 May 2004 08:58:20 -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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <409A5A29.1060702@cisco.com> 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 > > ... "If the value in the challenge ACK would be the > > same as the value sent in the previous challenge ACK, don't > > send any ACK at all." > > Hmm.. that would surely prevent any ACK war from occuring... Of course, if the one-and-only challenge ACK we send gets lost in transit (or blocked by a middlebox), then the peer doesn't get a chance to send us a corrected RST, and we won't ever tear down our half of the session. But that's no different than if the RST got lost. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 6 14:17:10 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08720 for ; Thu, 6 May 2004 14:17: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 1BLnEY-0001Ep-Q8 for tcpm-archive@odin.ietf.org; Thu, 06 May 2004 14:04:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46I4Yrm004753 for tcpm-archive@odin.ietf.org; Thu, 6 May 2004 14:04:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLn2b-0004Cp-7Z for tcpm-web-archive@optimus.ietf.org; Thu, 06 May 2004 13:52: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 NAA07142 for ; Thu, 6 May 2004 13:52: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 1BLn2Z-0002H2-1e for tcpm-web-archive@ietf.org; Thu, 06 May 2004 13:52:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLn1f-0001oE-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 13:51:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLn0l-0001MX-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 13:50:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLmhO-0001AI-2l; Thu, 06 May 2004 13:30:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLmU8-00086n-66 for tcpm@optimus.ietf.org; Thu, 06 May 2004 13:16: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 NAA02774 for ; Thu, 6 May 2004 13:16: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 1BLmU6-0001zs-37 for tcpm@ietf.org; Thu, 06 May 2004 13:16:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLmQP-0000iK-00 for tcpm@ietf.org; Thu, 06 May 2004 13:12:46 -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 1BLmNS-0006tg-00 for tcpm@ietf.org; Thu, 06 May 2004 13:09:42 -0400 Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1BLmMm-0006Ew-00; Thu, 06 May 2004 13:09:00 -0400 From: Tim Shepard To: "Randall Stewart (cisco)" cc: Paul Goyette , tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt In-reply-to: Your message of Thu, 06 May 2004 11:30:49 -0400. <409A5A29.1060702@cisco.com> Date: Thu, 06 May 2004 13:09:00 -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 > >The intent of this is "If the value in the challenge ACK would be the > >same as the value sent in the previous challenge ACK, don't send any > >ACK at all." > > > > > > Hmm.. that would surely prevent any ACK war from > occuring... But what if the previous challenge ACK was dropped? -Tim Shepard shep@alum.mit.edu _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 6 14:24: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 OAA09124 for ; Thu, 6 May 2004 14:24: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 1BLnJX-00041C-Qm for tcpm-archive@odin.ietf.org; Thu, 06 May 2004 14:09:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46I9h6G015442 for tcpm-archive@odin.ietf.org; Thu, 6 May 2004 14:09:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLnCD-0000Fc-Ai for tcpm-web-archive@optimus.ietf.org; Thu, 06 May 2004 14: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 OAA08019 for ; Thu, 6 May 2004 14:02: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 1BLnCB-0006n4-1N for tcpm-web-archive@ietf.org; Thu, 06 May 2004 14:02:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLnBO-0006Mj-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 14:01:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLnAN-0005v2-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 14:00:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLn0T-0002Lf-2i; Thu, 06 May 2004 13:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLmgA-0000T8-QH for tcpm@optimus.ietf.org; Thu, 06 May 2004 13:29: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 NAA04862 for ; Thu, 6 May 2004 13:29: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 1BLmg8-0007AN-P7 for tcpm@ietf.org; Thu, 06 May 2004 13:29:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLmeP-0006QL-00 for tcpm@ietf.org; Thu, 06 May 2004 13:27:14 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx with esmtp (Exim 4.12) id 1BLmc1-0005N8-00 for tcpm@ietf.org; Thu, 06 May 2004 13:24:45 -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 i46HOihw015028; Thu, 6 May 2004 10:24:44 -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 0FDA577A71D; Thu, 6 May 2004 13:24:43 -0400 (EDT) To: "Paul Goyette" From: Mark Allman Reply-To: mallman@icir.org Cc: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Sweet Emotion MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 06 May 2004 13:24:43 -0400 Message-Id: <20040506172443.0FDA577A71D@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 > Clarifying my own post from yesterday: > > > Perhaps "Don't send repeated challenges with the same ACK value" would > > be adequate? Then you only need to keep track of one new state value, > > the last value sent in a challenge ACK. This should eliminate the ACK > > war scenario. > > At least one person took this to mean that I was suggesting we select a > _new_ ACK value for repeated RST segments. That's not what I meant. > > The intent of this is "If the value in the challenge ACK would be the > same as the value sent in the previous challenge ACK, don't send any > ACK at all." As the one person, I'll just note that I didn't understand what Paul was saying and that the above sounds fine to me -- even though that might not have been the impression I gave yesterday. allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAmnTbWyrrWs4yIs4RAu3VAJ4n9d+gfeUkK/bdCQqbEfcf1ty0ewCeKm6q Uq4wGuQW+s+6pi1QqdKivDA= =qwrd -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 6 14:38:47 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 OAA10112 for ; Thu, 6 May 2004 14:38: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 1BLndh-00044k-Oo for tcpm-archive@odin.ietf.org; Thu, 06 May 2004 14:30:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46IUXeg015666 for tcpm-archive@odin.ietf.org; Thu, 6 May 2004 14:30:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLnXM-0001We-3P for tcpm-web-archive@optimus.ietf.org; Thu, 06 May 2004 14:24: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 OAA09089 for ; Thu, 6 May 2004 14:23: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 1BLnXJ-0000QF-KS for tcpm-web-archive@ietf.org; Thu, 06 May 2004 14:23:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLnWQ-000017-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 14:23:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLnVq-0007Pw-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 14:22:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLnHy-0003W0-5o; Thu, 06 May 2004 14: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 1BLn6M-0005yG-Le for tcpm@optimus.ietf.org; Thu, 06 May 2004 13:56: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 NAA07524 for ; Thu, 6 May 2004 13:56: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 1BLn6K-00047G-Bn for tcpm@ietf.org; Thu, 06 May 2004 13:56:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLn5U-0003hW-00 for tcpm@ietf.org; Thu, 06 May 2004 13:55:13 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx with esmtp (Exim 4.12) id 1BLn4v-0003Gp-00 for tcpm@ietf.org; Thu, 06 May 2004 13:54:37 -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 i46Hqqhw015416; Thu, 6 May 2004 10:52:53 -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 A48ED77A71D; Thu, 6 May 2004 13:52:51 -0400 (EDT) To: Tim Shepard From: Mark Allman Reply-To: mallman@icir.org Cc: "Randall Stewart (cisco)" , Paul Goyette , tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Sweet Emotion MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 06 May 2004 13:52:51 -0400 Message-Id: <20040506175251.A48ED77A71D@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 > > > >The intent of this is "If the value in the challenge ACK would be the > > >same as the value sent in the previous challenge ACK, don't send any > > >ACK at all." > > > > > > > Hmm.. that would surely prevent any ACK war from > > occuring... > > But what if the previous challenge ACK was dropped? I think you have to allow a small number to be sent. Like three sounds like a good number. It seems that the probabilities are way on your side at that point. And, the downside is that one connection is going to hang around in established far too long -- which could be a resource problem. But, given the probability of all this happening I am comfortable with it. But, that's just me. allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAmntzWyrrWs4yIs4RAumrAJ9AeWgYnDfubncvNZCzhLr87H20CQCgmw2e faEQ2adPpvFgtoHCOsZiOus= =e5CT -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 6 14:41:17 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 OAA10280 for ; Thu, 6 May 2004 14:41: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 1BLnik-00061W-Cc for tcpm-archive@odin.ietf.org; Thu, 06 May 2004 14:35:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46IZkE7023147 for tcpm-archive@odin.ietf.org; Thu, 6 May 2004 14:35:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLnZP-0002Nh-26 for tcpm-web-archive@optimus.ietf.org; Thu, 06 May 2004 14:26: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 OAA09219 for ; Thu, 6 May 2004 14:26: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 1BLnZM-0001Ga-LD for tcpm-web-archive@ietf.org; Thu, 06 May 2004 14:26:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLnYN-0000qd-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 14:25:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLnXa-0000RQ-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 14:24:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLnIr-0003yS-Aw; Thu, 06 May 2004 14: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 1BLnBL-0008TF-Nd for tcpm@optimus.ietf.org; Thu, 06 May 2004 14:01: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 OAA07867 for ; Thu, 6 May 2004 14:01: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 1BLnBJ-0006M2-Cb for tcpm@ietf.org; Thu, 06 May 2004 14:01:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLnAJ-0005uA-00 for tcpm@ietf.org; Thu, 06 May 2004 14:00:11 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1BLn9H-00053L-00 for tcpm@ietf.org; Thu, 06 May 2004 13:59:07 -0400 Received: from mail6.microsoft.com ([157.54.6.196]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Thu, 6 May 2004 10:59:03 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 6 May 2004 11:01:11 -0700 Received: from 157.54.8.23 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 06 May 2004 10:58:36 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 6 May 2004 10:58:36 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 6 May 2004 10:58:29 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 6 May 2004 10:58:35 -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] new internet draft - drafft-touch-anonsec Date: Thu, 6 May 2004 10:58:37 -0700 Message-ID: Thread-Topic: [tcpm] new internet draft - drafft-touch-anonsec Thread-Index: AcQzjYj+LxCQB/P/RTurIz3M4iyFYwABPL/g From: "Christian Huitema" To: "Joe Touch" , X-OriginalArrivalTime: 06 May 2004 17:58:35.0058 (UTC) FILETIME=[C02CB120:01C43393] 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 > The following I-D is soon to appear in the drafts directory; until then, > here is the title and abstract, and it is available now at: >=20 > http://www.isi.edu/touch/pubs/draft-touch-anonsec-00.txt >=20 > At this time, I'm soliciting discussion and feedback on both TCPM and > IPsec mailing lists, where discussion of the issues of IPsec have been > ongoing. I track both lists; please do NOT cross-post. I'll > cross-summarize periodically if it proves necessary. Your draft starts with a description of the state of the art, which mentions how the BGP MD5 option can be used to protect the connection against some attacks (notably, data injection). However, this option is BGP specific, and there is no intention to generalize its usage to other applications of TCP. In the interest of clarity, you should mention the limits of applicability of this MD5 option, and you should mention the obvious alternative, use SSL or TLS. Now, on a practical note, I observe that your proposal requires a code change. There is an alternative, which is to use a well known secret. Yes, I know this is an oxymoron, but such well known secret would have exactly the same properties as "anonymous IPSEC", i.e. they will protect against random attacks by virtue of the initial DH exchange, but they will not protect from a man-in-the-middle attack against IKE. The advantage of the well known secret approach is that it does not require a code change or a protocol update. Many implementations of IKE support the use of a shared secret to secure an IPSEC connection when PKI certificates are not available.=20 -- Christian Huitema _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 6 15:14:34 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 PAA12708 for ; Thu, 6 May 2004 15:14: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 1BLoHZ-0002cf-BL for tcpm-archive@odin.ietf.org; Thu, 06 May 2004 15:11:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46JBjLw010073 for tcpm-archive@odin.ietf.org; Thu, 6 May 2004 15:11:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLo2I-0005Mn-BM for tcpm-web-archive@optimus.ietf.org; Thu, 06 May 2004 14:55: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 OAA10887 for ; Thu, 6 May 2004 14:55: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 1BLo2F-0005z2-J5 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 14:55:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLo1F-0005ZD-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 14:54:54 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLo06-0004mU-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 14:53:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLntc-00026U-Tr; Thu, 06 May 2004 14:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLnlt-0007VK-Gl for tcpm@optimus.ietf.org; Thu, 06 May 2004 14:39: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 OAA10152 for ; Thu, 6 May 2004 14:38: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 1BLnlq-0006ft-Rh for tcpm@ietf.org; Thu, 06 May 2004 14:38:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLnku-0006Gh-00 for tcpm@ietf.org; Thu, 06 May 2004 14:38:01 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1BLnjy-0005Rl-00 for tcpm@ietf.org; Thu, 06 May 2004 14:37:02 -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 i46IaTW9021900; Thu, 6 May 2004 11:36:29 -0700 (PDT) Received: from cisco.com (rtp-dial-1-228.cisco.com [10.83.97.228]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATU11889; Thu, 6 May 2004 11:36:27 -0700 (PDT) Message-ID: <409A8541.6090805@cisco.com> Date: Thu, 06 May 2004 14:34:41 -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] new internet draft - drafft-touch-anonsec References: <409A5E6A.3070808@isi.edu> In-Reply-To: <409A5E6A.3070808@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: Two quick comments .. and then I will re-read the draft again and give you a more detailed appriasal... complete with nits and nats :-D 1) You mention somewhere in the document: " *[AUTH - DCCP may be removing cookies from the spec for the redundancies discussed above, because the use of cookies at the transport layer primarily supports connection mobility (a design goal of SCTP, but not DCCP) rather than security. " I take issue with the "a design goal of SCTP" if I read this statement correctly.. SCTP was NEVER designed with mobility in mind. There are some folks that have written a draft on this I think.. but this was NEVER the design goal. 2) Throughout the document you focus on BGP. And while I admit BGP is a primary concern of mine, I have others too. CallManger and other VoIP control systems do at times use TCP instead of SCTP. I know H.323 for example did not have SCTP to rely on like sigtran did. These types of applications are ALSO at risk and so I think you should possibly craft another wording then just "BGP".. I think you really mean applications that have long lived TCP connections and exchange some critical control information. Maybe a new term needs to be defined. I will work through your document later... on a second read and give you detailed comments... R Joe Touch wrote: > Hi, all, > > The following I-D is soon to appear in the drafts directory; until > then, here is the title and abstract, and it is available now at: > > http://www.isi.edu/touch/pubs/draft-touch-anonsec-00.txt > > At this time, I'm soliciting discussion and feedback on both TCPM and > IPsec mailing lists, where discussion of the issues of IPsec have been > ongoing. I track both lists; please do NOT cross-post. I'll > cross-summarize periodically if it proves necessary. > > I'd also like to solicit input on in which WG to proceed. > > Joe > > ---- > > ANONsec: Anonymous IPsec to Defend Against Spoofing Attacks > draft-touch-anonsec > > Recent attacks on core Internet infrastructure indicate an increased > vulnerability of TCP connections to spurious resets (RSTs). TCP has > always been susceptible to such RST spoof attacks, which were > indirectly protected by checking that the RST sequence number was > inside the current receive window, as well as via the obfuscation of > TCP endpoint and port numbers. For pairs of well-known endpoints > often over predictable port pairs, such as BGP, increases in the path > bandwidth-delay product of a connection have sufficiently increased > the receive window space that off-path third parties can guess a > viable RST sequence number. This document addresses this > vulnerability, discussing proposed solutions at the transport level > and their inherent challenges, as well as existing network level > solutions and the feasibility of their deployment. Finally, it > proposes an extension to IPsec configuration called ANONsec that > intends to efficiently and scalably secure any transport protocol > from such off-path third-party spoofing attacks. > > ---- -- 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 May 6 15:29: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 PAA14296 for ; Thu, 6 May 2004 15:29: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 1BLoUe-0000iv-UA for tcpm-archive@odin.ietf.org; Thu, 06 May 2004 15:25:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46JPGEi002777 for tcpm-archive@odin.ietf.org; Thu, 6 May 2004 15:25:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLoNb-0006AK-2c for tcpm-web-archive@optimus.ietf.org; Thu, 06 May 2004 15:17: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 PAA13162 for ; Thu, 6 May 2004 15:17: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 1BLoNZ-0007R4-PE for tcpm-web-archive@ietf.org; Thu, 06 May 2004 15:17:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLoMf-00072Z-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 15:17:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLoM3-0006dz-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 15: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 1BLoHo-00032Q-TP; Thu, 06 May 2004 15:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLo1O-00059N-AJ for tcpm@optimus.ietf.org; Thu, 06 May 2004 14:55: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 OAA10868 for ; Thu, 6 May 2004 14:54: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 1BLo1L-0005Zx-IB for tcpm@ietf.org; Thu, 06 May 2004 14:54:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLo0P-0005Ap-00 for tcpm@ietf.org; Thu, 06 May 2004 14:54:02 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BLnzq-0004kT-00 for tcpm@ietf.org; Thu, 06 May 2004 14:53:27 -0400 Received: from isi.edu ([206.117.31.151]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i46IoeJ23091; Thu, 6 May 2004 11:50:40 -0700 (PDT) Message-ID: <409A88F6.9070003@isi.edu> Date: Thu, 06 May 2004 11:50:30 -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] new internet draft - drafft-touch-anonsec References: <409A5E6A.3070808@isi.edu> <409A8541.6090805@cisco.com> In-Reply-To: <409A8541.6090805@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="------------enig634D6BEC8750597FF9B82552" 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) --------------enig634D6BEC8750597FF9B82552 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Randall Stewart (cisco) wrote: > Joe: > > Two quick comments .. and then I will re-read the draft > again and give you a more detailed appriasal... complete > with nits and nats :-D > > 1) You mention somewhere in the document: > " > > *[AUTH - DCCP may be removing cookies from the spec for the > redundancies discussed above, because the use of cookies at the > transport layer primarily supports connection mobility (a design goal > of SCTP, but not DCCP) rather than security. > > > " > > I take issue with the "a design goal of SCTP" if I read this statement > correctly.. SCTP was NEVER designed with mobility in mind. There > are some folks that have written a draft on this I think.. but this > was NEVER the design goal. Hi, Randall, Connection mobility != mobility. With this clarificiation, is this still something SCTP was not designed for? If so, I'm confused about all the multihoming and endpoint switching stuff which was around at the start of the SCTP discussions... > 2) Throughout the document you focus on BGP. And while I admit > BGP is a primary concern of mine, I have others too. CallManger and > other VoIP control systems do at times use TCP instead of SCTP. I > know H.323 for example did not have SCTP to rely on like sigtran did. > These types of applications are ALSO at risk and so I think you should > possibly craft another wording then just "BGP".. I think you really mean > applications that have long lived TCP connections and exchange > some critical control information. Maybe a new term needs to be > defined. The document was certainly motivated by the recent attacks on BGP, and (I thought) tried to focus on the more general case of spoofing attacks throughout. I'd be glad to cite other examples of related issues, and to clarify the document to focus on long-lived TCP in the next revision. > I will work through your document later... on a second read and give > you detailed comments... > > R > > > > Joe Touch wrote: > >> Hi, all, >> >> The following I-D is soon to appear in the drafts directory; until >> then, here is the title and abstract, and it is available now at: >> >> http://www.isi.edu/touch/pubs/draft-touch-anonsec-00.txt >> >> At this time, I'm soliciting discussion and feedback on both TCPM and >> IPsec mailing lists, where discussion of the issues of IPsec have been >> ongoing. I track both lists; please do NOT cross-post. I'll >> cross-summarize periodically if it proves necessary. >> >> I'd also like to solicit input on in which WG to proceed. >> >> Joe >> >> ---- >> >> ANONsec: Anonymous IPsec to Defend Against Spoofing Attacks >> draft-touch-anonsec >> >> Recent attacks on core Internet infrastructure indicate an increased >> vulnerability of TCP connections to spurious resets (RSTs). TCP has >> always been susceptible to such RST spoof attacks, which were >> indirectly protected by checking that the RST sequence number was >> inside the current receive window, as well as via the obfuscation of >> TCP endpoint and port numbers. For pairs of well-known endpoints >> often over predictable port pairs, such as BGP, increases in the path >> bandwidth-delay product of a connection have sufficiently increased >> the receive window space that off-path third parties can guess a >> viable RST sequence number. This document addresses this >> vulnerability, discussing proposed solutions at the transport level >> and their inherent challenges, as well as existing network level >> solutions and the feasibility of their deployment. Finally, it >> proposes an extension to IPsec configuration called ANONsec that >> intends to efficiently and scalably secure any transport protocol >> from such off-path third-party spoofing attacks. >> >> ---- > > > > --------------enig634D6BEC8750597FF9B82552 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 iD8DBQFAmoj8E5f5cImnZrsRApJUAKDQmSJtmRMdS0S96ezcrbUDdJl1hACgo4rI /8FCocj8r12hmhI8vyXMjQY= =KagP -----END PGP SIGNATURE----- --------------enig634D6BEC8750597FF9B82552-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 6 15:47: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 PAA15565 for ; Thu, 6 May 2004 15:47: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 1BLojn-00079o-Ps for tcpm-archive@odin.ietf.org; Thu, 06 May 2004 15:40:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46JetGO027454 for tcpm-archive@odin.ietf.org; Thu, 6 May 2004 15:40:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLof9-00054z-8a for tcpm-web-archive@optimus.ietf.org; Thu, 06 May 2004 15:36: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 PAA14605 for ; Thu, 6 May 2004 15:36: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 1BLof7-0007EQ-V9 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 15:36:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLoeB-0006oS-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 15:35:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLodB-0006P2-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 15: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 1BLoVO-00015W-4D; Thu, 06 May 2004 15:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLoNY-00061D-Rx for tcpm@optimus.ietf.org; Thu, 06 May 2004 15:17: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 PAA13152 for ; Thu, 6 May 2004 15:17: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 1BLoNX-0007Qg-Hn for tcpm@ietf.org; Thu, 06 May 2004 15:17:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLoMZ-00071m-00 for tcpm@ietf.org; Thu, 06 May 2004 15:16:56 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BLoLe-0006Dj-00 for tcpm@ietf.org; Thu, 06 May 2004 15:15:59 -0400 Received: from isi.edu ([206.117.31.151]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i46JDWJ29080; Thu, 6 May 2004 12:13:32 -0700 (PDT) Message-ID: <409A8E4C.5020105@isi.edu> Date: Thu, 06 May 2004 12:13:16 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Huitema CC: tcpm@ietf.org Subject: Re: [tcpm] new internet draft - drafft-touch-anonsec 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="------------enig4476909C1CA22DAB84F3E4C3" 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) --------------enig4476909C1CA22DAB84F3E4C3 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Christian Huitema wrote: >>The following I-D is soon to appear in the drafts directory; until > > then, > >>here is the title and abstract, and it is available now at: >> >> http://www.isi.edu/touch/pubs/draft-touch-anonsec-00.txt >> >>At this time, I'm soliciting discussion and feedback on both TCPM and >>IPsec mailing lists, where discussion of the issues of IPsec have been >>ongoing. I track both lists; please do NOT cross-post. I'll >>cross-summarize periodically if it proves necessary. > > Your draft starts with a description of the state of the art, which > mentions how the BGP MD5 option can be used to protect the connection > against some attacks (notably, data injection). However, this option is > BGP specific, and there is no intention to generalize its usage to other > applications of TCP. In the interest of clarity, you should mention the > limits of applicability of this MD5 option, and you should mention the > obvious alternative, use SSL or TLS. Section 3.1.1 refers to RFC2385, which introduces a TCP option (the first reference to MD5). The RFC discusses this in regard to the same kind of attack to BGP at the transport layer (RST attacks in specific). Recommending this RFC as "standards track" may be limited to BGP, but there is nothing in the option that appears to be BGP-specific or even BGP-related. There are application-layer solutions discussed in section 4.3, including SSL and TLS, as well as BGP-layer authentication. > Now, on a practical note, I observe that your proposal requires a code > change. There is an alternative, which is to use a well known secret. > Yes, I know this is an oxymoron, but such well known secret would have > exactly the same properties as "anonymous IPSEC", i.e. they will protect > against random attacks by virtue of the initial DH exchange, but they > will not protect from a man-in-the-middle attack against IKE. I'm suggesting that the well-known secret be "0" in section 5.1.1. I'd be VERY glad if this does not require a mod to IKE - as noted in the doc, the purpose is to show how to use IKE when CAs are not known; I'm not an IKE expert, and I didn't see that IKE already supports this. I'll look deeper, but if you can suggest where in the spec to start digging, that'd be helpful. However, there still may be utility to the code mods for headerANON and nullANON. > The advantage of the well known secret approach is that it does not > require a code change or a protocol update. Many implementations of IKE > support the use of a shared secret to secure an IPSEC connection when > PKI certificates are not available. > > -- Christian Huitema Thanks for your observations! Joe --------------enig4476909C1CA22DAB84F3E4C3 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 iD8DBQFAmo5YE5f5cImnZrsRAnwIAKCdzzB2O9Z7lRxJuo60+Yd50AH6hACgvp88 D+3SVad/yhVp/lgbi7WdvF0= =Peh6 -----END PGP SIGNATURE----- --------------enig4476909C1CA22DAB84F3E4C3-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 6 16:34: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 QAA17576 for ; Thu, 6 May 2004 16:34: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 1BLpUO-0008V4-Em for tcpm-archive@odin.ietf.org; Thu, 06 May 2004 16:29:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46KT4bJ032670 for tcpm-archive@odin.ietf.org; Thu, 6 May 2004 16:29:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLpOe-0005tg-Se for tcpm-web-archive@optimus.ietf.org; Thu, 06 May 2004 16:23: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 QAA17143 for ; Thu, 6 May 2004 16:23: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 1BLpOd-0003rG-5R for tcpm-web-archive@ietf.org; Thu, 06 May 2004 16:23:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLpNc-0003R2-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 16:22:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLpMp-00031s-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 16:21:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLpDt-0001wg-Qe; Thu, 06 May 2004 16: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 1BLpB1-0000Ya-Vc for tcpm@optimus.ietf.org; Thu, 06 May 2004 16:09: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 QAA16796 for ; Thu, 6 May 2004 16:09: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 1BLpB0-0005yL-05 for tcpm@ietf.org; Thu, 06 May 2004 16:09:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLpA3-0005ZX-00 for tcpm@ietf.org; Thu, 06 May 2004 16:08:04 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BLp9E-0005Am-00 for tcpm@ietf.org; Thu, 06 May 2004 16:07:12 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i46K75v17374; Thu, 6 May 2004 23:07:05 +0300 (EET DST) X-Scanned: Thu, 6 May 2004 23:06:24 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i46K6O4C021944; Thu, 6 May 2004 23:06:24 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00sk4QUJ; Thu, 06 May 2004 23:06:23 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 i46K6MH22427; Thu, 6 May 2004 23:06:22 +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, 6 May 2004 15:06:14 -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 internet draft - drafft-touch-anonsec Date: Thu, 6 May 2004 15:06:13 -0500 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE016E80F6@daebe004.americas.nokia.com> Thread-Topic: [tcpm] new internet draft - drafft-touch-anonsec Thread-Index: AcQzjYj+LxCQB/P/RTurIz3M4iyFYwABPL/gAALwGYA= To: , , X-OriginalArrivalTime: 06 May 2004 20:06:14.0148 (UTC) FILETIME=[95591440:01C433A5] 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 Joe- In one of my previous e-mail, I pointed out that without a CA or = long-term shared key between each host (which doesn't scale), it's sort = of impossible to protect transport layer by using IP layer security. I = wasn't very clear, but let me describe the problem.=20 Let's say Alice and Bob are two BGP routers who follow anonsec (or IPSec = with a well-known shared key), and Trudy is an attacker who wants to = disrupt the connection. Let's also say, Trudy somehow knows the IP = address and TCP port numbers of the connection between Alice and Bob = (these conditions are essentially the prerequisite for any of these = attacks to be possible). Alice and Bob use anonsec to get a SPI1 and start communicating. Trudy, = sometime later, initiates Anonsec with Alice(or what ever) and gets = another SPI2 (In anonynsec there is no shared secret/CA that prevents = Trudy from establishing this security association, and that's the main = source of problem.) Graphically, this is how it looks: SPI1 ALICE <-----------------------> BOB=20 ^ | SPI2=20 +---------------------------> Trudy Now Trudy constructs packets as=20 [IP-Trudy, IP-Alice, SPI2, next-hdr=3DAH/ES, next-hdr=3DIP [IP-Bob, = IP-Alice, next-hdr=3DTCP, Flags=3DRST], ICV ] i.e., Trudy sends a packet with her SPI (SPI2) to Alice, but in the = inner packet she sends a packet which has IP address of Alice and Bob = and TCP ports of Alice and Bob. Please also note that Trudy can use just = one SPI2 to attack hundreds of TCP connection that might originate from = Alice. Most IPSec policies will authenticate the packet based on SPI2 and find = it okay (with CA/secrets, getting this SPI2 would have been impossible = and that's why this attack would have failed in normal IPSec operation). = But in this case, the IPSec engine will give the inner IP packet to the = actual IP engine which will give the packet to TCP layer, which will = reset the connection :-) BTW, It might seem like MITM attack, but it's not (I like to call it Man = in the Corner attack :-) ). Trudy, in this case, doesn't need to = intercept (actively or passively) any packets between Alice and Bob so = it's not an MITM. =20 So, Anonysec will protect against an attacker who just wanted to throw = some random RST packet, but if the attacker is even a little bit more = sophisticated, then TCP is on it's own. Also, the fact that Trudy's IP = address will be revealed in this attack is not of much solace, because = most such attacks are distributed anyways (and calling an ISP to block = some packets doesn't work fast enough). Without shared secrets (not known keys) or CAs, the only way (known to = me) to protect transport layer is to modify the transport layer itself. = But I will let security experts comment on this. Of course other = solution is to have strict policies, but that might interfere with other = needs. Yogesh > -----Original Message----- > From: tcpm-admin@ietf.org [mailto:tcpm-admin@ietf.org]On Behalf Of ext > Christian Huitema > Sent: Thursday, May 06, 2004 12:59 PM > To: Joe Touch; tcpm@ietf.org > Subject: RE: [tcpm] new internet draft - drafft-touch-anonsec >=20 >=20 > > The following I-D is soon to appear in the drafts directory; until > then, > > here is the title and abstract, and it is available now at: > >=20 > > http://www.isi.edu/touch/pubs/draft-touch-anonsec-00.txt > >=20 > > At this time, I'm soliciting discussion and feedback on=20 > both TCPM and > > IPsec mailing lists, where discussion of the issues of=20 > IPsec have been > > ongoing. I track both lists; please do NOT cross-post. I'll > > cross-summarize periodically if it proves necessary. >=20 > Your draft starts with a description of the state of the art, which > mentions how the BGP MD5 option can be used to protect the connection > against some attacks (notably, data injection). However, this=20 > option is > BGP specific, and there is no intention to generalize its=20 > usage to other > applications of TCP. In the interest of clarity, you should=20 > mention the > limits of applicability of this MD5 option, and you should mention the > obvious alternative, use SSL or TLS. >=20 > Now, on a practical note, I observe that your proposal requires a code > change. There is an alternative, which is to use a well known secret. > Yes, I know this is an oxymoron, but such well known secret would have > exactly the same properties as "anonymous IPSEC", i.e. they=20 > will protect > against random attacks by virtue of the initial DH exchange, but they > will not protect from a man-in-the-middle attack against IKE. >=20 > The advantage of the well known secret approach is that it does not > require a code change or a protocol update. Many=20 > implementations of IKE > support the use of a shared secret to secure an IPSEC connection when > PKI certificates are not available.=20 >=20 > -- Christian Huitema >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 6 16:57: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 QAA18558 for ; Thu, 6 May 2004 16:57:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLpuI-0002XO-2V for tcpm-archive@odin.ietf.org; Thu, 06 May 2004 16:55:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46Kton5009747 for tcpm-archive@odin.ietf.org; Thu, 6 May 2004 16:55:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLpoe-0000VZ-Mr for tcpm-web-archive@optimus.ietf.org; Thu, 06 May 2004 16:50: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 QAA18288 for ; Thu, 6 May 2004 16:49: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 1BLpoc-0007LL-Mu for tcpm-web-archive@ietf.org; Thu, 06 May 2004 16:49:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLpne-0006vU-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 16:48:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLpmb-0006Ku-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 16:47:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLpis-00075K-Q0; Thu, 06 May 2004 16: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 1BLpgv-0006HZ-8F for tcpm@optimus.ietf.org; Thu, 06 May 2004 16:42: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 QAA17912 for ; Thu, 6 May 2004 16:41: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 1BLpgt-0003uh-81 for tcpm@ietf.org; Thu, 06 May 2004 16:41:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLpfv-0003Vg-00 for tcpm@ietf.org; Thu, 06 May 2004 16:41:00 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BLpew-0002ij-00 for tcpm@ietf.org; Thu, 06 May 2004 16:39:58 -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 i46Kd3J17715; Thu, 6 May 2004 13:39:04 -0700 (PDT) Message-ID: <409AA2E2.1010100@isi.edu> Date: Thu, 06 May 2004 13:41:06 -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: Yogesh.Swami@nokia.com CC: huitema@windows.microsoft.com, tcpm@ietf.org Subject: Re: [tcpm] new internet draft - drafft-touch-anonsec References: <025E7DD4182874489CC2F61EE0FA19CE016E80F6@daebe004.americas.nokia.com> In-Reply-To: <025E7DD4182874489CC2F61EE0FA19CE016E80F6@daebe004.americas.nokia.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="------------enig5DF484056458398F11AA6F9E" 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) --------------enig5DF484056458398F11AA6F9E Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Yogesh.Swami@nokia.com wrote: > Joe- > > In one of my previous e-mail, I pointed out that without a CA or > long-term shared key between each host (which doesn't scale), it's sort > of impossible to protect transport layer by using IP layer security. I > wasn't very clear, but let me describe the problem. > > Let's say Alice and Bob are two BGP routers who follow anonsec (or > IPSec with a well-known shared key), and Trudy is an attacker who wants > to disrupt the connection. Let's also say, Trudy somehow knows the IP > address and TCP port numbers of the connection between Alice and Bob > (these conditions are essentially the prerequisite for any of these > attacks to be possible). > > Alice and Bob use anonsec to get a SPI1 and start communicating. > Trudy, sometime later, initiates Anonsec with Alice(or what ever) and > gets another SPI2 (In anonynsec there is no shared secret/CA that > prevents Trudy from establishing this security association, and that's > the main source of problem.) In most of the attack scenarios, "Trudy" is a remote spoofer who is not reachable via the reverse path, i.e., she cannot be reached by packets sent to "Trudy". This would prevent the ANONsec association from being established. As you observe, someone willing to commit resources - with a valid reverse path - can certainly connect. But this is a public server (I'm assuming), so this makes sense. > Graphically, this is how it looks: > > > SPI1 > ALICE <-----------------------> BOB > ^ > | SPI2 > +---------------------------> Trudy > > Now Trudy constructs packets as > > [IP-Trudy, IP-Alice, SPI2, next-hdr=AH/ES, next-hdr=IP [IP-Bob, ? IP-Alice, next-hdr=TCP, Flags=RST], ICV ] > > i.e., Trudy sends a packet with her SPI (SPI2) to Alice, but in the > inner packet she sends a packet which has IP address of Alice and Bob > and TCP ports of Alice and Bob. Please also note that Trudy can use just > one SPI2 to attack hundreds of TCP connection that might originate from > Alice. This shouldn't be possible - as I've loosely defined ANONsec, the idea of the SA is to authenticate the header. I.e., SPI1 is valid only for packets from Alice; SPI2 is valid only for packets from Trudy. In this case, the authentication should fail since the packet's source address doesn't match what SPI2 requires - regardless of the next-header. > Most IPSec policies will authenticate the packet based on SPI2 and > find it okay (with CA/secrets, getting this SPI2 would have been > impossible and that's why this attack would have failed in normal IPSec > operation). But in this case, the IPSec engine will give the inner IP > packet to the actual IP engine which will give the packet to TCP layer, > which will reset the connection :-) As above, I believe IPsec AH already covers this case sufficiently. A valid SPI is not permission to send packets with any source - only that which matches the previously negotiated source of that SPI. Joe > > BTW, It might seem like MITM attack, but it's not (I like to call it > Man in the Corner attack :-) ). Trudy, in this case, doesn't need to > intercept (actively or passively) any packets between Alice and Bob so > it's not an MITM. > > So, Anonysec will protect against an attacker who just wanted to > throw > some random RST packet, but if the attacker is even a little bit more > sophisticated, then TCP is on it's own. Also, the fact that Trudy's IP > address will be revealed in this attack is not of much solace, because > most such attacks are distributed anyways (and calling an ISP to block > some packets doesn't work fast enough). > > Without shared secrets (not known keys) or CAs, the only way (known > to > me) to protect transport layer is to modify the transport layer itself. > But I will let security experts comment on this. Of course other > solution is to have strict policies, but that might interfere with other > needs. > > Yogesh > > > >>-----Original Message----- >>From: tcpm-admin@ietf.org [mailto:tcpm-admin@ietf.org]On Behalf Of ext >>Christian Huitema >>Sent: Thursday, May 06, 2004 12:59 PM >>To: Joe Touch; tcpm@ietf.org >>Subject: RE: [tcpm] new internet draft - drafft-touch-anonsec >> >> >> >>>The following I-D is soon to appear in the drafts directory; until >> >>then, >> >>>here is the title and abstract, and it is available now at: >>> >>> http://www.isi.edu/touch/pubs/draft-touch-anonsec-00.txt >>> >>>At this time, I'm soliciting discussion and feedback on >> >>both TCPM and >> >>>IPsec mailing lists, where discussion of the issues of >> >>IPsec have been >> >>>ongoing. I track both lists; please do NOT cross-post. I'll >>>cross-summarize periodically if it proves necessary. >> >>Your draft starts with a description of the state of the art, which >>mentions how the BGP MD5 option can be used to protect the connection >>against some attacks (notably, data injection). However, this >>option is >>BGP specific, and there is no intention to generalize its >>usage to other >>applications of TCP. In the interest of clarity, you should >>mention the >>limits of applicability of this MD5 option, and you should mention the >>obvious alternative, use SSL or TLS. >> >>Now, on a practical note, I observe that your proposal requires a code >>change. There is an alternative, which is to use a well known secret. >>Yes, I know this is an oxymoron, but such well known secret would have >>exactly the same properties as "anonymous IPSEC", i.e. they >>will protect >>against random attacks by virtue of the initial DH exchange, but they >>will not protect from a man-in-the-middle attack against IKE. >> >>The advantage of the well known secret approach is that it does not >>require a code change or a protocol update. Many >>implementations of IKE >>support the use of a shared secret to secure an IPSEC connection when >>PKI certificates are not available. >> >>-- Christian Huitema >> >>_______________________________________________ >>tcpm mailing list >>tcpm@ietf.org >>https://www1.ietf.org/mailman/listinfo/tcpm >> --------------enig5DF484056458398F11AA6F9E 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 iD8DBQFAmqLnE5f5cImnZrsRAiTdAJ9vTY0QDJ6xQcev1rHpEJplVVQ9gwCgvxOH gZ/XSsCYqVCnhnwLJNetXyQ= =bdPa -----END PGP SIGNATURE----- --------------enig5DF484056458398F11AA6F9E-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 6 16:59: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 QAA18643 for ; Thu, 6 May 2004 16:59: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 1BLpvA-0002jJ-3Z for tcpm-archive@odin.ietf.org; Thu, 06 May 2004 16:56:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46KuiBD010482 for tcpm-archive@odin.ietf.org; Thu, 6 May 2004 16:56:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLptd-0002DY-1g for tcpm-web-archive@optimus.ietf.org; Thu, 06 May 2004 16:55: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 QAA18448 for ; Thu, 6 May 2004 16:55: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 1BLptb-0001br-0q for tcpm-web-archive@ietf.org; Thu, 06 May 2004 16:55:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLpsc-0001CX-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 16:54:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLps4-0000ne-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 16:53:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLpnh-0000Iz-2V; Thu, 06 May 2004 16:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLpit-00075O-Iu for tcpm@optimus.ietf.org; Thu, 06 May 2004 16:44: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 QAA17971 for ; Thu, 6 May 2004 16:44: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 1BLpir-0004nA-KN for tcpm@ietf.org; Thu, 06 May 2004 16:44:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLphq-0004Jr-00 for tcpm@ietf.org; Thu, 06 May 2004 16:42:58 -0400 Received: from mail4.microsoft.com ([131.107.3.122]) by ietf-mx with esmtp (Exim 4.12) id 1BLpgk-0003Wq-00 for tcpm@ietf.org; Thu, 06 May 2004 16:41:50 -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); Thu, 6 May 2004 13:40:34 -0700 Received: from 157.54.5.25 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 06 May 2004 13:41:18 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 6 May 2004 13:41:13 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 6 May 2004 13:41:18 -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); Thu, 6 May 2004 13:42:03 -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] new internet draft - drafft-touch-anonsec Date: Thu, 6 May 2004 13:41:15 -0700 Message-ID: Thread-Topic: [tcpm] new internet draft - drafft-touch-anonsec Thread-Index: AcQzjYj+LxCQB/P/RTurIz3M4iyFYwABPL/gAALwGYAAAwXxQA== From: "Christian Huitema" To: , , X-OriginalArrivalTime: 06 May 2004 20:42:03.0435 (UTC) FILETIME=[966C3FB0:01C433AA] 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 =20 > i.e., Trudy sends a packet with her SPI (SPI2) to Alice, but in the inner > packet she sends a packet which has IP address of Alice and Bob and TCP > ports of Alice and Bob. Please also note that Trudy can use just one SPI2 > to attack hundreds of TCP connection that might originate from Alice. What you are saying is that one cannot really protect TCP with tunnel-mode IPSEC. Duh. Use transport mode. -- Christian Huitema _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 6 17:08:16 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 RAA19284 for ; Thu, 6 May 2004 17:08: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 1BLq0P-0004wU-HA for tcpm-archive@odin.ietf.org; Thu, 06 May 2004 17:02:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46L295s018993 for tcpm-archive@odin.ietf.org; Thu, 6 May 2004 17:02:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLpvf-0002xx-HL for tcpm-web-archive@optimus.ietf.org; Thu, 06 May 2004 16:57: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 QAA18547 for ; Thu, 6 May 2004 16:57: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 1BLpvd-0002Ti-FD for tcpm-web-archive@ietf.org; Thu, 06 May 2004 16:57:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLpum-00023u-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 16:56:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLpu6-0001d0-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 16:55:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLpni-0000Jp-W6; Thu, 06 May 2004 16: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 1BLpku-0007lM-MQ for tcpm@optimus.ietf.org; Thu, 06 May 2004 16:46: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 QAA18146 for ; Thu, 6 May 2004 16:46:05 -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 1BLpks-0005fc-M2 for tcpm@ietf.org; Thu, 06 May 2004 16:46:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLpjx-0005Fx-00 for tcpm@ietf.org; Thu, 06 May 2004 16:45:10 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BLpjG-0004pO-00 for tcpm@ietf.org; Thu, 06 May 2004 16:44: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 i46KiNB20769; Thu, 6 May 2004 23:44:23 +0300 (EET DST) X-Scanned: Thu, 6 May 2004 23:43:53 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i46Khr8M004601; Thu, 6 May 2004 23:43:53 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00Dm0jlC; Thu, 06 May 2004 23:43:52 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 i46KhoH09575; Thu, 6 May 2004 23:43: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, 6 May 2004 15:43:50 -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 internet draft - drafft-touch-anonsec Date: Thu, 6 May 2004 15:43:50 -0500 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE028856BE@daebe004.americas.nokia.com> Thread-Topic: [tcpm] new internet draft - drafft-touch-anonsec Thread-Index: AcQzjYj+LxCQB/P/RTurIz3M4iyFYwABPL/gAALwGYAAAwXxQAAAJo/A To: , , X-OriginalArrivalTime: 06 May 2004 20:43:50.0294 (UTC) FILETIME=[D61DA360:01C433AA] 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 > -----Original Message----- > From: ext Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: Thursday, May 06, 2004 3:41 PM > To: Swami Yogesh (Nokia-NRC/Dallas); touch@ISI.EDU; tcpm@ietf.org > Subject: RE: [tcpm] new internet draft - drafft-touch-anonsec >=20 >=20 > =20 > > i.e., Trudy sends a packet with her SPI (SPI2) to Alice, but in the > inner > > packet she sends a packet which has IP address of Alice and Bob and > TCP > > ports of Alice and Bob. Please also note that Trudy can use just one > SPI2 > > to attack hundreds of TCP connection that might originate=20 > from Alice. >=20 > What you are saying is that one cannot really protect TCP with > tunnel-mode IPSEC. Duh. Use transport mode. >=20 But that's a very restrictive policy decision, isn't it? Yogesh _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 6 17:11: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 RAA19501 for ; Thu, 6 May 2004 17:11: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 1BLq5t-0006WI-CA for tcpm-archive@odin.ietf.org; Thu, 06 May 2004 17:07:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46L7nOs025058 for tcpm-archive@odin.ietf.org; Thu, 6 May 2004 17:07:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLpzJ-0004YZ-5N for tcpm-web-archive@optimus.ietf.org; Thu, 06 May 2004 17:01: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 RAA18698 for ; Thu, 6 May 2004 17:00: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 1BLpzH-00046V-3F for tcpm-web-archive@ietf.org; Thu, 06 May 2004 17:00:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLpyI-0003hB-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 16:59:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLpxE-00034S-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 16:58:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLpuT-0002ZX-Qj; Thu, 06 May 2004 16:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLpon-0000dE-V9 for tcpm@optimus.ietf.org; Thu, 06 May 2004 16:50: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 QAA18327 for ; Thu, 6 May 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 1BLpol-0007MP-UK for tcpm@ietf.org; Thu, 06 May 2004 16:50:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLpns-0006xR-00 for tcpm@ietf.org; Thu, 06 May 2004 16:49:12 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BLpnP-0006Wo-00 for tcpm@ietf.org; Thu, 06 May 2004 16:48:43 -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 i46KkLJ19598; Thu, 6 May 2004 13:46:21 -0700 (PDT) Message-ID: <409AA49D.90809@isi.edu> Date: Thu, 06 May 2004 13:48: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: Christian Huitema CC: Yogesh.Swami@nokia.com, tcpm@ietf.org Subject: Re: [tcpm] new internet draft - drafft-touch-anonsec 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="------------enigC10798EA51B5B26AA873718A" 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) --------------enigC10798EA51B5B26AA873718A Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Christian Huitema wrote: > > >>i.e., Trudy sends a packet with her SPI (SPI2) to Alice, but in the > inner >>packet she sends a packet which has IP address of Alice and Bob and > TCP >>ports of Alice and Bob. Please also note that Trudy can use just one > SPI2 >>to attack hundreds of TCP connection that might originate from Alice. > > What you are saying is that one cannot really protect TCP with > tunnel-mode IPSEC. Duh. Use transport mode. > > -- Christian Huitema Even tunnel mode is supposed to check the outer packet headers. IPsec AH authenticates the outer IP header regardless. Joe --------------enigC10798EA51B5B26AA873718A 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 iD8DBQFAmqSdE5f5cImnZrsRAuHfAJ9DVz+oL8+0dzvyZdaPoiLkUhCffwCfemGu rtbpx9NUWvL+pIMjgI4l5s0= =ZC2+ -----END PGP SIGNATURE----- --------------enigC10798EA51B5B26AA873718A-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 6 17:12: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 RAA19624 for ; Thu, 6 May 2004 17:12: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 1BLq5t-0006Wi-Kq for tcpm-archive@odin.ietf.org; Thu, 06 May 2004 17:07:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46L7nOx025083 for tcpm-archive@odin.ietf.org; Thu, 6 May 2004 17:07:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLq0J-0004vt-Gm for tcpm-web-archive@optimus.ietf.org; Thu, 06 May 2004 17:02: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 RAA18736 for ; Thu, 6 May 2004 17:02: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 1BLq0H-0004W1-Eb for tcpm-web-archive@ietf.org; Thu, 06 May 2004 17:02:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLpzL-000474-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 17:01:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLpyR-0003iY-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 17:00:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLpvQ-0002xV-TJ; Thu, 06 May 2004 16: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 1BLpsa-0001bh-8i for tcpm@optimus.ietf.org; Thu, 06 May 2004 16:54: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 QAA18402 for ; Thu, 6 May 2004 16:54: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 1BLpsX-0001Bs-Vz for tcpm@ietf.org; Thu, 06 May 2004 16:54:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLprf-0000nB-00 for tcpm@ietf.org; Thu, 06 May 2004 16:53:08 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BLpr9-0000Oa-00 for tcpm@ietf.org; Thu, 06 May 2004 16:52:36 -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 i46KqXH18284; Thu, 6 May 2004 23:52:33 +0300 (EET DST) X-Scanned: Thu, 6 May 2004 23:52:00 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i46Kq0PL020233; Thu, 6 May 2004 23:52:00 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00KXLa9m; Thu, 06 May 2004 23:51:59 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 i46KptH14796; Thu, 6 May 2004 23:51:56 +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, 6 May 2004 15:51:18 -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 internet draft - drafft-touch-anonsec Date: Thu, 6 May 2004 15:51:18 -0500 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE028856BF@daebe004.americas.nokia.com> Thread-Topic: [tcpm] new internet draft - drafft-touch-anonsec Thread-Index: AcQzjYj+LxCQB/P/RTurIz3M4iyFYwABPL/gAALwGYAAAwXxQAAAYJaQ To: , , X-OriginalArrivalTime: 06 May 2004 20:51:18.0635 (UTC) FILETIME=[E1590BB0:01C433AB] 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.e., Trudy sends a packet with her SPI (SPI2) to Alice, but in the > inner > > packet she sends a packet which has IP address of Alice and Bob and > TCP > > ports of Alice and Bob. Please also note that Trudy can use just one > SPI2 > > to attack hundreds of TCP connection that might originate=20 > from Alice. >=20 > What you are saying is that one cannot really protect TCP with > tunnel-mode IPSEC. Duh. Use transport mode. >=20 BTW, does transport mode allows IP in IP? If it does, then we are back = to the same attack. Of course one can have policies to stop IP in IP, = but this might not be acceptable for a general TCP security solution. Yogesh _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 6 17:12: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 RAA19785 for ; Thu, 6 May 2004 17:12: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 1BLq60-0006a7-O1 for tcpm-archive@odin.ietf.org; Thu, 06 May 2004 17:07:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46L7uFn025290 for tcpm-archive@odin.ietf.org; Thu, 6 May 2004 17:07:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLq1r-0004zc-V8 for tcpm-web-archive@optimus.ietf.org; Thu, 06 May 2004 17:03: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 RAA18847 for ; Thu, 6 May 2004 17:03: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 1BLq1p-00053p-Rf for tcpm-web-archive@ietf.org; Thu, 06 May 2004 17:03:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLq0X-0004Yt-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 17:02:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLpzu-00047n-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 17:01:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLpvR-0002xd-45; Thu, 06 May 2004 16:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLpsc-0001bv-EI for tcpm@optimus.ietf.org; Thu, 06 May 2004 16:54: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 QAA18408 for ; Thu, 6 May 2004 16:54: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 1BLpsa-0001CB-Cc for tcpm@ietf.org; Thu, 06 May 2004 16:54:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLprh-0000nS-00 for tcpm@ietf.org; Thu, 06 May 2004 16:53:10 -0400 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1BLprH-0000OX-00 for tcpm@ietf.org; Thu, 06 May 2004 16:52:43 -0400 Received: from mail6.microsoft.com ([157.54.6.196]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 6 May 2004 13:52:12 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 6 May 2004 13:55:13 -0700 Received: from 157.54.6.150 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 06 May 2004 13:52:13 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 6 May 2004 13:52:12 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 6 May 2004 13:52:11 -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); Thu, 6 May 2004 13:52:55 -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] new internet draft - drafft-touch-anonsec Date: Thu, 6 May 2004 13:52:07 -0700 Message-ID: Thread-Topic: [tcpm] new internet draft - drafft-touch-anonsec Thread-Index: AcQzjYj+LxCQB/P/RTurIz3M4iyFYwABPL/gAALwGYAAAwXxQAAAJo/AAAAn3HA= From: "Christian Huitema" To: , , X-OriginalArrivalTime: 06 May 2004 20:52:55.0353 (UTC) FILETIME=[1AFF0A90:01C433AC] 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.e., Trudy sends a packet with her SPI (SPI2) to Alice, but in the > > inner > > > packet she sends a packet which has IP address of Alice and Bob and > > TCP > > > ports of Alice and Bob. Please also note that Trudy can use just one > > SPI2 > > > to attack hundreds of TCP connection that might originate > > from Alice. > > > > What you are saying is that one cannot really protect TCP with > > tunnel-mode IPSEC. Duh. Use transport mode. >=20 > But that's a very restrictive policy decision, isn't it? Well, you are supposed to choose a policy that creates the adequate security result. So clearly, there is a restriction against inadequate policies... -- Christian Huitema _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 6 17:39: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 RAA21151 for ; Thu, 6 May 2004 17:39: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 1BLqVC-0007jN-1F for tcpm-archive@odin.ietf.org; Thu, 06 May 2004 17:33:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46LXw84029718 for tcpm-archive@odin.ietf.org; Thu, 6 May 2004 17:33:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLqGs-0002Q6-JP for tcpm-web-archive@optimus.ietf.org; Thu, 06 May 2004 17:19: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 RAA20326 for ; Thu, 6 May 2004 17:19: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 1BLqGq-0003nu-FA for tcpm-web-archive@ietf.org; Thu, 06 May 2004 17:19:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLqFv-0003NS-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 17:18:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLqEq-0002w0-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 17:17:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLq9x-0008S8-G6; Thu, 06 May 2004 17: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 1BLq4W-0005vc-Mr for tcpm@optimus.ietf.org; Thu, 06 May 2004 17:06: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 RAA19229 for ; Thu, 6 May 2004 17:06: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 1BLq4U-0006Rf-Hf for tcpm@ietf.org; Thu, 06 May 2004 17:06:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLq3o-000604-00 for tcpm@ietf.org; Thu, 06 May 2004 17:05:41 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BLq2r-0005U9-00 for tcpm@ietf.org; Thu, 06 May 2004 17:04:41 -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 i46L2vJ22845; Thu, 6 May 2004 14:02:57 -0700 (PDT) Message-ID: <409AA881.6070202@isi.edu> Date: Thu, 06 May 2004 14:05:05 -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: Yogesh.Swami@nokia.com CC: huitema@windows.microsoft.com, tcpm@ietf.org Subject: Re: [tcpm] new internet draft - drafft-touch-anonsec References: <025E7DD4182874489CC2F61EE0FA19CE028856BF@daebe004.americas.nokia.com> In-Reply-To: <025E7DD4182874489CC2F61EE0FA19CE028856BF@daebe004.americas.nokia.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="------------enigE418EE4817C750190134C7B7" 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) --------------enigE418EE4817C750190134C7B7 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Yogesh.Swami@nokia.com wrote: >> >> >>>i.e., Trudy sends a packet with her SPI (SPI2) to Alice, but in the >>inner >>>packet she sends a packet which has IP address of Alice and Bob and >>TCP >>>ports of Alice and Bob. Please also note that Trudy can use just one >>SPI2 >>>to attack hundreds of TCP connection that might originate >>from Alice. >> >>What you are saying is that one cannot really protect TCP with >>tunnel-mode IPSEC. Duh. Use transport mode. > > BTW, does transport mode allows IP in IP? If it does, then we are > back > to the same attack. Of course one can have policies to stop IP in IP, > but this might not be acceptable for a general TCP security solution. > > Yogesh I was perhaps not specific enough. It doesn't matter whether you use transport mode or tunnel mode IPsec. In either case, there is the possibility of spoofing IN THE ABSENCE OF ANY OTHER POLICIES. I.e., there is nothing to stop a server, running IPsec in either mode, of being attacked by packets: - in transport mode where protocol=ANY (and ports are thus undefined) - in tunnel mode where src=ANY in the encapsulated packet ANONsec weakens IPsec so that any third party can spoof when the policies are this open. However, current IPsec allows spoofing among the set of truly authenticated sources (e.g., with valid certs signed by known CAs). I.e., Alice and Trudy can spoof each other, regardless of whether they are signed, in the absence of realistic policies. It's worth mentioning this in the next version of the draft, certainly. This is not otherwise significant IMO since it constitutes running a "wide open" IPsec, which is like locking an open door. Joe --------------enigE418EE4817C750190134C7B7 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 iD8DBQFAmqiBE5f5cImnZrsRAgYgAJ9g4LfHOigIhZOp1YPIX8gXXOBFbgCdGDj+ OpZzl9cSgaUUCdK+grsKsV0= =YM6E -----END PGP SIGNATURE----- --------------enigE418EE4817C750190134C7B7-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 6 17:40: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 RAA21186 for ; Thu, 6 May 2004 17:40:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLqWv-00089E-MA for tcpm-archive@odin.ietf.org; Thu, 06 May 2004 17:35:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46LZjTP031309 for tcpm-archive@odin.ietf.org; Thu, 6 May 2004 17:35:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLqOe-0005Qd-Lv for tcpm-web-archive@optimus.ietf.org; Thu, 06 May 2004 17:27: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 RAA20654 for ; Thu, 6 May 2004 17:27: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 1BLqOc-0007B8-Av for tcpm-web-archive@ietf.org; Thu, 06 May 2004 17:27:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLqNb-0006lX-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 17:26:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLqMg-0006MB-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 17:25:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLqFk-0002D2-Gs; Thu, 06 May 2004 17: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 1BLq8X-0007W3-Nd for tcpm@optimus.ietf.org; Thu, 06 May 2004 17:10: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 RAA19340 for ; Thu, 6 May 2004 17:10: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 1BLq8V-0007cg-Hu for tcpm@ietf.org; Thu, 06 May 2004 17:10:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLq5K-0006sX-00 for tcpm@ietf.org; Thu, 06 May 2004 17:07:14 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BLq4A-0005ys-00 for tcpm@ietf.org; Thu, 06 May 2004 17:06: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 i46L5AJ23253; Thu, 6 May 2004 14:05:10 -0700 (PDT) Message-ID: <409AA906.8030207@isi.edu> Date: Thu, 06 May 2004 14:07:18 -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: Joe Touch CC: Christian Huitema , Yogesh.Swami@nokia.com, tcpm@ietf.org Subject: Re: [tcpm] new internet draft - drafft-touch-anonsec References: <409AA49D.90809@isi.edu> In-Reply-To: <409AA49D.90809@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="------------enigD109F99006A4BBD4D98B2963" 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) --------------enigD109F99006A4BBD4D98B2963 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Joe Touch wrote: > > > Christian Huitema wrote: > >> >> >>> i.e., Trudy sends a packet with her SPI (SPI2) to Alice, but in the >> >> inner >> >>> packet she sends a packet which has IP address of Alice and Bob and >> >> TCP >> >>> ports of Alice and Bob. Please also note that Trudy can use just one >> >> SPI2 >> >>> to attack hundreds of TCP connection that might originate from Alice. >> >> >> What you are saying is that one cannot really protect TCP with >> tunnel-mode IPSEC. Duh. Use transport mode. >> >> -- Christian Huitema > > > Even tunnel mode is supposed to check the outer packet headers. IPsec AH > authenticates the outer IP header regardless. ^^^^^ inner Presuming, as Christian also observes, reasonable policies. > > Joe --------------enigD109F99006A4BBD4D98B2963 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 iD8DBQFAmqkGE5f5cImnZrsRAoSCAKCWP0E+bLw/+njvik2IuG3mW50gjwCg0y9x tPEYuY+mjo8xxsI4CM+h+9I= =ubvf -----END PGP SIGNATURE----- --------------enigD109F99006A4BBD4D98B2963-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 6 17:49: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 RAA21627 for ; Thu, 6 May 2004 17:49: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 1BLqgO-0003S1-43 for tcpm-archive@odin.ietf.org; Thu, 06 May 2004 17:45:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46LjWUR013257 for tcpm-archive@odin.ietf.org; Thu, 6 May 2004 17:45:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLqaC-0000z0-Qc for tcpm-web-archive@optimus.ietf.org; Thu, 06 May 2004 17:39: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 RAA21129 for ; Thu, 6 May 2004 17:39: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 1BLqaA-0004MA-DP for tcpm-web-archive@ietf.org; Thu, 06 May 2004 17:39:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLqZA-0003w0-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 17:38:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLqY8-0003VB-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 17: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 1BLqTI-0006sg-SY; Thu, 06 May 2004 17:32:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLqFz-0002GW-Je for tcpm@optimus.ietf.org; Thu, 06 May 2004 17:18: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 RAA20280 for ; Thu, 6 May 2004 17:18:12 -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 1BLqFx-0003Ng-98 for tcpm@ietf.org; Thu, 06 May 2004 17:18:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLqEv-0002wk-00 for tcpm@ietf.org; Thu, 06 May 2004 17:17:09 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BLqE1-0002VV-00 for tcpm@ietf.org; Thu, 06 May 2004 17:16:13 -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 i46LGAB18969; Fri, 7 May 2004 00:16:10 +0300 (EET DST) X-Scanned: Fri, 7 May 2004 00:15:50 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i46LFo3I001856; Fri, 7 May 2004 00:15:50 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00JXrHHj; Fri, 07 May 2004 00:15:49 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 i46LFlH29463; Fri, 7 May 2004 00:15:47 +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); Thu, 6 May 2004 16:15:46 -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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] new internet draft - drafft-touch-anonsec Date: Thu, 6 May 2004 16:15:46 -0500 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE028856C0@daebe004.americas.nokia.com> Thread-Topic: [tcpm] new internet draft - drafft-touch-anonsec Thread-Index: AcQzriDxiAMJjrJ1SsK+FPyZnXBTbAAALG4g To: Cc: , X-OriginalArrivalTime: 06 May 2004 21:15:46.0265 (UTC) FILETIME=[4C1F9C90:01C433AF] 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 > >> > >> What you are saying is that one cannot really protect TCP with > >> tunnel-mode IPSEC. Duh. Use transport mode. > >> > >> -- Christian Huitema > >=20 > >=20 > > Even tunnel mode is supposed to check the outer packet=20 > headers. IPsec AH=20 > > authenticates the outer IP header regardless. > ^^^^^ > inner >=20 Which only means one more IP tunnel on part of Trudy. She has nothing to lose by putting 10 IP tunnels if that suits her needs. > Presuming, as Christian also observes, reasonable policies. >=20 I will wait to see the right policies in the next draft (I couldn't come up with any reasonable policy myself :-)). Yogesh _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 6 17:58: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 RAA22028 for ; Thu, 6 May 2004 17:58: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 1BLqmm-0005sl-TI for tcpm-archive@odin.ietf.org; Thu, 06 May 2004 17:52:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46Lq8WW022603 for tcpm-archive@odin.ietf.org; Thu, 6 May 2004 17:52:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLqhE-0003la-BK for tcpm-web-archive@optimus.ietf.org; Thu, 06 May 2004 17:46: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 RAA21513 for ; Thu, 6 May 2004 17:46: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 1BLqhB-0007LY-TK for tcpm-web-archive@ietf.org; Thu, 06 May 2004 17:46:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLqgM-0006u5-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 17:45:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLqfX-0006Si-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 17:44:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLqXF-0008GY-KN; Thu, 06 May 2004 17:36:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLqPe-0005jr-Va for tcpm@optimus.ietf.org; Thu, 06 May 2004 17:28: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 RAA20729 for ; Thu, 6 May 2004 17:28: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 1BLqPc-0007bl-Iy for tcpm@ietf.org; Thu, 06 May 2004 17:28:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLqOi-0007C9-00 for tcpm@ietf.org; Thu, 06 May 2004 17:27:17 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BLqO2-0006kz-00 for tcpm@ietf.org; Thu, 06 May 2004 17:26:34 -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 i46LOkJ27860; Thu, 6 May 2004 14:24:46 -0700 (PDT) Message-ID: <409AAD9D.9050104@isi.edu> Date: Thu, 06 May 2004 14:26:53 -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: Yogesh.Swami@nokia.com CC: huitema@windows.microsoft.com, tcpm@ietf.org Subject: Re: [tcpm] new internet draft - drafft-touch-anonsec References: <025E7DD4182874489CC2F61EE0FA19CE028856C0@daebe004.americas.nokia.com> In-Reply-To: <025E7DD4182874489CC2F61EE0FA19CE028856C0@daebe004.americas.nokia.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="------------enigF4FC0B9C2196162D9405B5CE" 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) --------------enigF4FC0B9C2196162D9405B5CE Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Yogesh.Swami@nokia.com wrote: >>>>What you are saying is that one cannot really protect TCP with >>>>tunnel-mode IPSEC. Duh. Use transport mode. >>>> >>>>-- Christian Huitema >>> >>> >>>Even tunnel mode is supposed to check the outer packet >> >>headers. IPsec AH >> >>>authenticates the outer IP header regardless. >> >> ^^^^^ >> inner > > Which only means one more IP tunnel on part of Trudy. She has nothing to > lose by putting 10 IP tunnels if that suits her needs. That presumes that Bob is willing to either 1. accept non-IPsec'd tunnel'ed packets which he should not, once IPsec is enabled, by the rules in RFC2401 anyway - DENY any packets not IPsec'd as a catchall rule or 2. accept new SAs in which the source address of the inner or outer header is Alice, from Trudy any inner source that isn't Trudy ought to be invalid for any packet from Trudy, or Bob is ASKING to be spoofed >>Presuming, as Christian also observes, reasonable policies. > > I will wait to see the right policies in the next draft (I couldn't come > up with any reasonable policy myself :-)). > > Yogesh As per my other post, the right policies are easy. DENY: 1) wildcards in the protocol field of transport-mode 2) wildcards in the source field of the encapsulated packets in tunnel mode 3) wildcards in the source field of the outer packet in either transport or tunnel mode 3) non-matching outer and inner source addresses I.e., if you want to deny spoofing, DENY spoofing ;-) Joe --------------enigF4FC0B9C2196162D9405B5CE 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 iD8DBQFAmq2eE5f5cImnZrsRArA/AJ9W6BHHq6MNDk7+Hvge/Rz08Kcx+QCgs2Ca Odm1UDdLqJiUtGSB7NiFcbM= =LvoT -----END PGP SIGNATURE----- --------------enigF4FC0B9C2196162D9405B5CE-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 6 18:39:25 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 SAA24950 for ; Thu, 6 May 2004 18:39: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 1BLrVQ-0002hK-M5 for tcpm-archive@odin.ietf.org; Thu, 06 May 2004 18:38:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46McGFw010362 for tcpm-archive@odin.ietf.org; Thu, 6 May 2004 18: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 1BLrQR-0000uc-4L for tcpm-web-archive@optimus.ietf.org; Thu, 06 May 2004 18: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 SAA24770 for ; Thu, 6 May 2004 18:33: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 1BLrQO-0003g3-9Z for tcpm-web-archive@ietf.org; Thu, 06 May 2004 18:33:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLrPP-0003Gr-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 18:32:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLrOZ-0002ro-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 18:31:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLrHe-0006cn-1U; Thu, 06 May 2004 18:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLrGr-0006Jz-TB for tcpm@optimus.ietf.org; Thu, 06 May 2004 18:23: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 SAA24340 for ; Thu, 6 May 2004 18:23:09 -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 1BLrGo-0007Iw-WD for tcpm@ietf.org; Thu, 06 May 2004 18:23:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLrFv-0006tf-00 for tcpm@ietf.org; Thu, 06 May 2004 18:22:15 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BLrFV-0006U2-00 for tcpm@ietf.org; Thu, 06 May 2004 18:21:49 -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 i46MLfB16449; Fri, 7 May 2004 01:21:41 +0300 (EET DST) X-Scanned: Fri, 7 May 2004 01:21:33 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i46MLXn5022712; Fri, 7 May 2004 01:21:33 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00ZYPemd; Fri, 07 May 2004 01:21:32 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 i46MLVH06090; Fri, 7 May 2004 01:21:31 +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, 6 May 2004 17:21:30 -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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] new internet draft - drafft-touch-anonsec Date: Thu, 6 May 2004 17:21:29 -0500 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE016E80F7@daebe004.americas.nokia.com> Thread-Topic: [tcpm] new internet draft - drafft-touch-anonsec Thread-Index: AcQzsMNWkBSQkRdsRHKe5qfFSxZTCwABHXbg To: Cc: X-OriginalArrivalTime: 06 May 2004 22:21:30.0378 (UTC) FILETIME=[7AFF7EA0:01C433B8] 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 > -----Original Message----- > From: ext Joe Touch [mailto:touch@ISI.EDU] > Sent: 06 May, 2004 4:27 PM > To: Swami Yogesh (Nokia-NRC/Dallas) > Cc: huitema@windows.microsoft.com; tcpm@ietf.org > Subject: Re: [tcpm] new internet draft - drafft-touch-anonsec >=20 >=20 >=20 > That presumes that Bob is willing to either >=20 > 1. accept non-IPsec'd tunnel'ed packets > which he should not, once IPsec is enabled, by the rules > in RFC2401 anyway - DENY any packets not IPsec'd as a > catchall rule > or >=20 Could you please elaborate a little bit... In my picture Bob doesn't even see anything happening.=20 > 2. accept new SAs in which the source address of the inner or outer=20 > header is Alice, from Trudy > any inner source that isn't Trudy ought to be invalid for > any packet from Trudy, or Bob is ASKING to be spoofed >=20 So if I understand this correctly, then what you are saying is that if Trudy sends a packet as follows, IPhdr1[AH-hdr[IPhdr1[IPhdr1[IPHdr1...[IPHdr-2, TCP ]]]]]...] (where IPHdr-1 is a valid IP header between Alice and Trudy, but only IPHdr-2 is the IP header between Alice and Bob) then IPSec engine should parse the headers all the way up to IPHdr-2 and then throw it! I haven't read the new AH draft, but this would mean a simple DoS on IPSec engine itself (especially when there are no keys/Certs to prevent SPI formation.) Also, what if one of the IPHdr-1 (lets say the third one from left) has a lot of repeated NOPs and a MF bit set in that IP header. How does the IPSec engine handle parsing of headers in this case? If it means only checking the first and second IPHdr-1 after the AH header, then the attack is not preventable without a policy that stops all IP in IP. The policy of preventing all IP in IP whenever the SPI is formed using AnonIke is too restrictive, IMO. It would mean that if I want to have some form of IP tunneling between two host and also use TCP over that tunnel, then I cannot have secure TCP! To me this is not a reasonable policy for a general TCP security solution. (I didn't understand the policies you pointed out, so I cannot comment on them now.) =20 Yogesh=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 6 18:52:13 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 SAA25339 for ; Thu, 6 May 2004 18:52: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 1BLrhu-0005tU-Bc for tcpm-archive@odin.ietf.org; Thu, 06 May 2004 18:51:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46MpA9N022651 for tcpm-archive@odin.ietf.org; Thu, 6 May 2004 18:51:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLrXI-00035A-9q for tcpm-web-archive@optimus.ietf.org; Thu, 06 May 2004 18:40: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 SAA24970 for ; Thu, 6 May 2004 18:40: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 1BLrXF-0006cE-6m for tcpm-web-archive@ietf.org; Thu, 06 May 2004 18:40:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLrWB-0006Bz-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 18:39:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLrV2-0005PL-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 18:37:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLrQN-0000uY-Uo; Thu, 06 May 2004 18:33:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLrNZ-0007kF-RU for tcpm@optimus.ietf.org; Thu, 06 May 2004 18:30: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 SAA24690 for ; Thu, 6 May 2004 18:30: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 1BLrNW-0002Rb-Qx for tcpm@ietf.org; Thu, 06 May 2004 18:30:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLrMb-00022B-00 for tcpm@ietf.org; Thu, 06 May 2004 18:29:10 -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 1BLrLy-0001M3-00 for tcpm@ietf.org; Thu, 06 May 2004 18:28: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 i46MRpWB015980; Thu, 6 May 2004 15:27:53 -0700 (PDT) Received: from cisco.com (rtp-dial-1-228.cisco.com [10.83.97.228]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATU48503; Thu, 6 May 2004 15:27:47 -0700 (PDT) Message-ID: <409ABB79.6070007@cisco.com> Date: Thu, 06 May 2004 18:26: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: Joe Touch CC: tcpm@ietf.org Subject: Re: [tcpm] new internet draft - drafft-touch-anonsec References: <409A5E6A.3070808@isi.edu> <409A8541.6090805@cisco.com> <409A88F6.9070003@isi.edu> In-Reply-To: <409A88F6.9070003@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: > > > Randall Stewart (cisco) wrote: > >> Joe: >> >> Two quick comments .. and then I will re-read the draft >> again and give you a more detailed appriasal... complete >> with nits and nats :-D >> >> 1) You mention somewhere in the document: >> " >> >> *[AUTH - DCCP may be removing cookies from the spec for the >> redundancies discussed above, because the use of cookies at the >> transport layer primarily supports connection mobility (a design goal >> of SCTP, but not DCCP) rather than security. >> >> >> " >> >> I take issue with the "a design goal of SCTP" if I read this statement >> correctly.. SCTP was NEVER designed with mobility in mind. There >> are some folks that have written a draft on this I think.. but this >> was NEVER the design goal. > > > Hi, Randall, > > Connection mobility != mobility. > > With this clarificiation, is this still something SCTP was not > designed for? If so, I'm confused about all the multihoming and > endpoint switching stuff which was around at the start of the SCTP > discussions... Hmm... I am not sure what you mean by connection mobility.. if you mean multi-homing where an association can use multiple paths.. then yes.. SCTP has that... but there is no endpoint switching in SCTP that I know of.. You open a socket on machine A .. and it may have IP-A/IP-B and IP-C ... your association may be across those 3 IP addresses .. i.e. you can send and receive on any of those address to your bound port .. but the endpoint/socket does not move off the machine or to some other socket.... > >> 2) Throughout the document you focus on BGP. And while I admit >> BGP is a primary concern of mine, I have others too. CallManger and >> other VoIP control systems do at times use TCP instead of SCTP. I >> know H.323 for example did not have SCTP to rely on like sigtran did. >> These types of applications are ALSO at risk and so I think you >> should >> possibly craft another wording then just "BGP".. I think you >> really mean >> applications that have long lived TCP connections and exchange >> some critical control information. Maybe a new term needs to be >> defined. > > > The document was certainly motivated by the recent attacks on BGP, and > (I thought) tried to focus on the more general case of spoofing > attacks throughout. I'd be glad to cite other examples of related > issues, and to clarify the document to focus on long-lived TCP in the > next revision. That would be great... I will be doing a detailed read and see if I can't figure out a way to suggest something... R > > >> I will work through your document later... on a second read and give >> you detailed comments... >> >> R >> >> >> >> Joe Touch wrote: >> >>> Hi, all, >>> >>> The following I-D is soon to appear in the drafts directory; until >>> then, here is the title and abstract, and it is available now at: >>> >>> http://www.isi.edu/touch/pubs/draft-touch-anonsec-00.txt >>> >>> At this time, I'm soliciting discussion and feedback on both TCPM >>> and IPsec mailing lists, where discussion of the issues of IPsec >>> have been ongoing. I track both lists; please do NOT cross-post. >>> I'll cross-summarize periodically if it proves necessary. >>> >>> I'd also like to solicit input on in which WG to proceed. >>> >>> Joe >>> >>> ---- >>> >>> ANONsec: Anonymous IPsec to Defend Against Spoofing Attacks >>> draft-touch-anonsec >>> >>> Recent attacks on core Internet infrastructure indicate an increased >>> vulnerability of TCP connections to spurious resets (RSTs). TCP has >>> always been susceptible to such RST spoof attacks, which were >>> indirectly protected by checking that the RST sequence number was >>> inside the current receive window, as well as via the obfuscation of >>> TCP endpoint and port numbers. For pairs of well-known endpoints >>> often over predictable port pairs, such as BGP, increases in the >>> path >>> bandwidth-delay product of a connection have sufficiently increased >>> the receive window space that off-path third parties can guess a >>> viable RST sequence number. This document addresses this >>> vulnerability, discussing proposed solutions at the transport level >>> and their inherent challenges, as well as existing network level >>> solutions and the feasibility of their deployment. Finally, it >>> proposes an extension to IPsec configuration called ANONsec that >>> intends to efficiently and scalably secure any transport protocol >>> from such off-path third-party spoofing attacks. >>> >>> ---- >> >> >> >> >> -- 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 May 6 18:58:14 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 SAA25644 for ; Thu, 6 May 2004 18:58: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 1BLrnN-0008J6-Rt for tcpm-archive@odin.ietf.org; Thu, 06 May 2004 18:56:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46MunMr031925 for tcpm-archive@odin.ietf.org; Thu, 6 May 2004 18:56:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLrmh-000806-Hy for tcpm-web-archive@optimus.ietf.org; Thu, 06 May 2004 18: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 SAA25500 for ; Thu, 6 May 2004 18:56: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 1BLrme-0005VX-C8 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 18:56:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLrlf-00054O-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 18:55:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLrkc-0004TX-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 18:53:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLrik-0006Ua-9p; Thu, 06 May 2004 18:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLraA-0003jz-Kj for tcpm@optimus.ietf.org; Thu, 06 May 2004 18:43: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 SAA25093 for ; Thu, 6 May 2004 18:43: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 1BLra7-00003u-J1 for tcpm@ietf.org; Thu, 06 May 2004 18:43:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLrZD-0007Sc-00 for tcpm@ietf.org; Thu, 06 May 2004 18:42:12 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BLrYq-00073k-00 for tcpm@ietf.org; Thu, 06 May 2004 18:41:48 -0400 Received: from isi.edu ([206.117.31.151]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i46MdgJ12934; Thu, 6 May 2004 15:39:42 -0700 (PDT) Message-ID: <409ABEA1.1010000@isi.edu> Date: Thu, 06 May 2004 15:39: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: tcpm@ietf.org Subject: Re: [tcpm] new internet draft - drafft-touch-anonsec References: <409A5E6A.3070808@isi.edu> <409A8541.6090805@cisco.com> <409A88F6.9070003@isi.edu> <409ABB79.6070007@cisco.com> In-Reply-To: <409ABB79.6070007@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="------------enigB5FA1ADC64DAFEEF338EB684" 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) --------------enigB5FA1ADC64DAFEEF338EB684 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Randall Stewart (cisco) wrote: > Joe Touch wrote: > >> >> >> Randall Stewart (cisco) wrote: >> >>> Joe: >>> >>> Two quick comments .. and then I will re-read the draft >>> again and give you a more detailed appriasal... complete >>> with nits and nats :-D >>> >>> 1) You mention somewhere in the document: >>> " >>> >>> *[AUTH - DCCP may be removing cookies from the spec for the >>> redundancies discussed above, because the use of cookies at the >>> transport layer primarily supports connection mobility (a design goal >>> of SCTP, but not DCCP) rather than security. >>> >>> >>> " >>> >>> I take issue with the "a design goal of SCTP" if I read this statement >>> correctly.. SCTP was NEVER designed with mobility in mind. There >>> are some folks that have written a draft on this I think.. but this >>> was NEVER the design goal. >> >> >> >> Hi, Randall, >> >> Connection mobility != mobility. >> >> With this clarificiation, is this still something SCTP was not >> designed for? If so, I'm confused about all the multihoming and >> endpoint switching stuff which was around at the start of the SCTP >> discussions... > > > > Hmm... I am not sure what you mean by connection mobility.. if you > mean multi-homing where an association can use multiple paths.. then > yes.. SCTP has that... That's what I meant. > but there is no endpoint switching in SCTP that > I know of.. You open a socket on machine A .. and it may have > IP-A/IP-B and IP-C ... your association may be across those > 3 IP addresses .. i.e. you can send and receive on any of those > address to your bound port .. but the endpoint/socket does not > move off the machine or to some other socket.... Well, that's not something that SCTP specs, but once you allow multiple IP addresses, that's not out of the question, IMO. I don't recall whether SCTP allowed 'renegotation' of the set of IP addresses, but if so, that becomes even more possible. I.e., I appreciate that this may be a raw nerve of sorts, but there's been a convergence of mobility, multihoming, transport mobility (moving machines), and connection 'agility' (perhaps a better term for SCTP's original design?). The point I was trying to make (let me know if there's a better way to rephrase in the revision) is that SCTP's cookies are to demux (in a way), not specifically to prohibit spoofers, IMO. --------------enigB5FA1ADC64DAFEEF338EB684 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 iD8DBQFAmr6rE5f5cImnZrsRAoE5AKDSWpbtRr0P97gRr90Nw1ToTcm8aQCdGL8E GcZeG7nA6G13zsphpQkNJXY= =LnX+ -----END PGP SIGNATURE----- --------------enigB5FA1ADC64DAFEEF338EB684-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 6 20:14: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 UAA29355 for ; Thu, 6 May 2004 20:14: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 1BLsze-0006f6-Pl for tcpm-archive@odin.ietf.org; Thu, 06 May 2004 20:13:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i470DYM0025603 for tcpm-archive@odin.ietf.org; Thu, 6 May 2004 20:13:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLssZ-0004BU-SS for tcpm-web-archive@optimus.ietf.org; Thu, 06 May 2004 20:06: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 UAA29067 for ; Thu, 6 May 2004 20:06: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 1BLssY-00045g-2M for tcpm-web-archive@ietf.org; Thu, 06 May 2004 20:06:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLsrm-0003gn-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 20:05:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLsr7-0003Gq-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 20:04:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLsoW-0002we-0R; Thu, 06 May 2004 20: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 1BLsmk-0002LP-4w for tcpm@optimus.ietf.org; Thu, 06 May 2004 20:00: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 UAA28717 for ; Thu, 6 May 2004 20:00: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 1BLsmi-0001XC-4M for tcpm@ietf.org; Thu, 06 May 2004 20:00:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLsls-000189-00 for tcpm@ietf.org; Thu, 06 May 2004 19:59:21 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BLsl0-0000M5-00 for tcpm@ietf.org; Thu, 06 May 2004 19:58:26 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 06 May 2004 16:58:00 -0700 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 i46Nvs0Q008419; Thu, 6 May 2004 16:57:55 -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 ASY81906; Thu, 6 May 2004 16:57:07 -0700 (PDT) Date: Thu, 6 May 2004 16:57:53 -0700 (PDT) From: Mitesh Dalal To: Joe Touch cc: Yogesh.Swami@nokia.com, huitema@windows.microsoft.com, tcpm@ietf.org Subject: Re: [tcpm] new internet draft - drafft-touch-anonsec In-Reply-To: <409AA881.6070202@isi.edu> Message-ID: References: <025E7DD4182874489CC2F61EE0FA19CE028856BF@daebe004.americas.nokia.com> <409AA881.6070202@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=AWL autolearn=no version=2.60 On Thu, 6 May 2004, Joe Touch wrote: > > Yogesh.Swami@nokia.com wrote: > > >> > >> > >>>i.e., Trudy sends a packet with her SPI (SPI2) to Alice, but in the > >>inner > >>>packet she sends a packet which has IP address of Alice and Bob and > >>TCP > >>>ports of Alice and Bob. Please also note that Trudy can use just one > >>SPI2 > >>>to attack hundreds of TCP connection that might originate > >>from Alice. > >> > >>What you are saying is that one cannot really protect TCP with > >>tunnel-mode IPSEC. Duh. Use transport mode. > > > > BTW, does transport mode allows IP in IP? If it does, then we are > > back > > to the same attack. Of course one can have policies to stop IP in IP, > > but this might not be acceptable for a general TCP security solution. > > > > Yogesh > > I was perhaps not specific enough. > > It doesn't matter whether you use transport mode or tunnel mode IPsec. > In either case, there is the possibility of spoofing IN THE ABSENCE OF > ANY OTHER POLICIES. > > I.e., there is nothing to stop a server, running IPsec in either mode, > of being attacked by packets: > - in transport mode where protocol=ANY > (and ports are thus undefined) > - in tunnel mode where src=ANY in the encapsulated packet > > ANONsec weakens IPsec so that any third party can spoof when the > policies are this open. However, current IPsec allows spoofing among the > set of truly authenticated sources (e.g., with valid certs signed by > known CAs). I.e., Alice and Trudy can spoof each other, regardless of > whether they are signed, in the absence of realistic policies. > > It's worth mentioning this in the next version of the draft, certainly. > This is not otherwise significant IMO since it constitutes running a > "wide open" IPsec, which is like locking an open door. Although the solution sound reasonable, I have couple of issues that I believe should be addressed. 1. Interop issues. In the proposed solutions, both ends need to support crypto, if they dont, what do you do ? 2. UDP and the relevant ports have to be allowed in the middleboxes. Any plan to address this problem. 3. Scalability. Are the current crypto solutions designed to handle thousands of connections ? 4. Configuration and cost issues. 5. The way I see the solution is only a recommendation to the end user to use the bear minimum of the crypto feature(if they have) to alleviate this attack. I would assume, that if an end-user did have crypto, he would be using it anyways depending on his requirement(AH or ESP, PKI or shared or whatever) 6. I disagree that this has less inertia than the changes that we are proposing in TCP :) Thanks Mitesh _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 6 20:26: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 UAA29859 for ; Thu, 6 May 2004 20:26: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 1BLtAx-0001im-Hy for tcpm-archive@odin.ietf.org; Thu, 06 May 2004 20:25:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i470PFee006608 for tcpm-archive@odin.ietf.org; Thu, 6 May 2004 20:25:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLt7z-000105-K8 for tcpm-web-archive@optimus.ietf.org; Thu, 06 May 2004 20:22: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 UAA29659 for ; Thu, 6 May 2004 20:22: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 1BLt7x-0002rx-Gt for tcpm-web-archive@ietf.org; Thu, 06 May 2004 20:22:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLt6y-0002SA-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 20:21:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLt5y-000239-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 20:20:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLt05-0006yg-Qh; Thu, 06 May 2004 20: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 1BLstS-0004Uy-7S for tcpm@optimus.ietf.org; Thu, 06 May 2004 20:07: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 UAA29070 for ; Thu, 6 May 2004 20:07: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 1BLstQ-0004U9-8r for tcpm@ietf.org; Thu, 06 May 2004 20:07:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLssQ-00044h-00 for tcpm@ietf.org; Thu, 06 May 2004 20:06:06 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BLsrJ-0003Ex-00 for tcpm@ietf.org; Thu, 06 May 2004 20:04:57 -0400 Received: from isi.edu ([206.117.31.151]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4703KJ29028; Thu, 6 May 2004 17:03:20 -0700 (PDT) Message-ID: <409AD246.1010503@isi.edu> Date: Thu, 06 May 2004 17:03:18 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yogesh.Swami@nokia.com CC: tcpm@ietf.org Subject: Re: [tcpm] new internet draft - drafft-touch-anonsec References: <025E7DD4182874489CC2F61EE0FA19CE016E80F7@daebe004.americas.nokia.com> In-Reply-To: <025E7DD4182874489CC2F61EE0FA19CE016E80F7@daebe004.americas.nokia.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="------------enig0763CA13EDAA45EEB68360E9" 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) --------------enig0763CA13EDAA45EEB68360E9 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Yogesh, Yogesh.Swami@nokia.com wrote: >>-----Original Message---- >>From: ext Joe Touch [mailto:touch@ISI.EDU] >>Sent: 06 May, 2004 4:27 PM >>To: Swami Yogesh (Nokia-NRC/Dallas) >>Cc: huitema@windows.microsoft.com; tcpm@ietf.org >>Subject: Re: [tcpm] new internet draft - drafft-touch-anonsec >> >>That presumes that Bob is willing to either >> >>1. accept non-IPsec'd tunnel'ed packets >> which he should not, once IPsec is enabled, by the rules >> in RFC2401 anyway - DENY any packets not IPsec'd as a >> catchall rule >>or > > Could you please elaborate a little bit... In my picture Bob doesn't > even see anything happening. Sorry - I got Bob and Alice mixed. The issue is that packet receivers should not accept non-IPsec'd packets once IPsec is on; just covering the bases. >>2. accept new SAs in which the source address of the inner or outer >>header is Alice, from Trudy >> any inner source that isn't Trudy ought to be invalid for >> any packet from Trudy, or Bob is ASKING to be spoofed > > So if I understand this correctly, then what you are saying is that if > Trudy sends a packet as follows, > > IPhdr1[AH-hdr[IPhdr1[IPhdr1[IPHdr1...[IPHdr-2, TCP ]]]]]...] > > (where IPHdr-1 is a valid IP header between Alice and Trudy, but only > IPHdr-2 is the IP header between Alice and Bob) then IPSec engine should > parse the headers all the way up to IPHdr-2 and then throw it! Yes. > I haven't > read the new AH draft, but this would mean a simple DoS on IPSec engine > itself (especially when there are no keys/Certs to prevent SPI > formation.) Yes. And that's not new at all. YuShun is right - tunnels are a problem for spoofing. Tunnel creation should be whitelisted - i.e., permit only those you know (which omits ALL ANONike) to create tunnels whose headers are in some range you permit (even for non-ANONike peers). Again, none of this is new. If you are concerned about spoofing you shouldn't allow it. > Also, what if one of the IPHdr-1 (lets say the third one > from left) has a lot of repeated NOPs and a MF bit set in that IP > header. How does the IPSec engine handle parsing of headers in this > case? IPsec is supposed to. > If it means only checking the first and second IPHdr-1 after the AH > header, then the attack is not preventable without a policy that stops > all IP in IP. Each decapsulated header pushes the packet back through IPsec. That means the endpoint needs to create N SPIs to make this work. So don't let parties create too many SPIs or to create tunnels that aren't whitelisted. > The policy of preventing all IP in IP whenever the SPI is formed using > AnonIke is too restrictive, IMO. It would mean that if I want to have > some form of IP tunneling between two host and also use TCP over that > tunnel, then I cannot have secure TCP! To me this is not a reasonable > policy for a general TCP security solution. > > (I didn't understand the policies you pointed out, so I cannot comment > on them now.) > > Yogesh Tunneling to a gateway then TCP to that same gateway is a bit odd; why not just use transport mode to that gateway? As Yushun pointed out, it may be sufficient to require whitelists for tunnels, which are probably required if you want to avoid spoofing through a tunnel gateway anyway. That would (by definition) kill all ANONsec requests for tunnels through that gateway (since you wouldn't whitelist 'from anyone' unless you want to be spoofed). Joe --------------enig0763CA13EDAA45EEB68360E9 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 iD8DBQFAmtJGE5f5cImnZrsRAvtqAKDwwBscuQTckU6mk9DU+YqfWZyI2gCgyMMK C97f5wP7VJlSCXqzK3W2HZc= =d16l -----END PGP SIGNATURE----- --------------enig0763CA13EDAA45EEB68360E9-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 6 20:27: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 UAA29892 for ; Thu, 6 May 2004 20:27: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 1BLtAy-0001j9-0a for tcpm-archive@odin.ietf.org; Thu, 06 May 2004 20:25:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i470PFgY006634 for tcpm-archive@odin.ietf.org; Thu, 6 May 2004 20:25:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLt8w-0001CQ-6L for tcpm-web-archive@optimus.ietf.org; Thu, 06 May 2004 20:23: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 UAA29682 for ; Thu, 6 May 2004 20:23: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 1BLt8u-0003JD-4R for tcpm-web-archive@ietf.org; Thu, 06 May 2004 20:23:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLt7v-0002rl-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 20:22:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLt6r-0002HD-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 20:21:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLt07-0006z4-7b; Thu, 06 May 2004 20:14:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLszF-0006d5-J2 for tcpm@optimus.ietf.org; Thu, 06 May 2004 20:13: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 UAA29228 for ; Thu, 6 May 2004 20:13: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 1BLszD-0006wc-Iv for tcpm@ietf.org; Thu, 06 May 2004 20:13:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLsyF-0006WU-00 for tcpm@ietf.org; Thu, 06 May 2004 20:12:07 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BLsxI-0005jY-00 for tcpm@ietf.org; Thu, 06 May 2004 20:11:09 -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 i4709XJ00091; Thu, 6 May 2004 17:09:33 -0700 (PDT) Message-ID: <409AD43D.8040108@isi.edu> Date: Thu, 06 May 2004 17:11:41 -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: Yogesh.Swami@nokia.com, huitema@windows.microsoft.com, tcpm@ietf.org Subject: Re: [tcpm] new internet draft - drafft-touch-anonsec References: <025E7DD4182874489CC2F61EE0FA19CE028856BF@daebe004.americas.nokia.com> <409AA881.6070202@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="------------enig215752BDD244D0B2EA5F9759" 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) --------------enig215752BDD244D0B2EA5F9759 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mitesh Dalal wrote: > On Thu, 6 May 2004, Joe Touch wrote: > >>Yogesh.Swami@nokia.com wrote: >> >> >>>> >>>>>i.e., Trudy sends a packet with her SPI (SPI2) to Alice, but in the >>>> >>>>inner >>>> >>>>>packet she sends a packet which has IP address of Alice and Bob and >>>> >>>>TCP >>>> >>>>>ports of Alice and Bob. Please also note that Trudy can use just one >>>> >>>>SPI2 >>>> >>>>>to attack hundreds of TCP connection that might originate >>> >>>>from Alice. >>> >>>>What you are saying is that one cannot really protect TCP with >>>>tunnel-mode IPSEC. Duh. Use transport mode. >>> >>>BTW, does transport mode allows IP in IP? If it does, then we are >>>back >>>to the same attack. Of course one can have policies to stop IP in IP, >>>but this might not be acceptable for a general TCP security solution. >>> >>>Yogesh >> >>I was perhaps not specific enough. >> >>It doesn't matter whether you use transport mode or tunnel mode IPsec. >>In either case, there is the possibility of spoofing IN THE ABSENCE OF >>ANY OTHER POLICIES. >> >>I.e., there is nothing to stop a server, running IPsec in either mode, >>of being attacked by packets: >> - in transport mode where protocol=ANY >> (and ports are thus undefined) >> - in tunnel mode where src=ANY in the encapsulated packet >> >>ANONsec weakens IPsec so that any third party can spoof when the >>policies are this open. However, current IPsec allows spoofing among the >>set of truly authenticated sources (e.g., with valid certs signed by >>known CAs). I.e., Alice and Trudy can spoof each other, regardless of >>whether they are signed, in the absence of realistic policies. >> >>It's worth mentioning this in the next version of the draft, certainly. >>This is not otherwise significant IMO since it constitutes running a >>"wide open" IPsec, which is like locking an open door. > > Although the solution sound reasonable, I have couple of issues that > I believe should be addressed. > > 1. Interop issues. In the proposed solutions, both ends need to > support crypto, if they dont, what do you do ? IMO, if you want to authenticate the source of packets, both ends need to support crypto. All other devices are basically some variant of crypto embedded in the (IMO) wrong place. > 2. UDP and the relevant ports have to be allowed in the middleboxes. > Any plan to address this problem. Middleboxes that end up looking like spoofers are correctly identified and defeated. Middleboxes that are proxies would work fine. > 3. Scalability. Are the current crypto solutions designed to handle > thousands of connections ? Yes. > 4. Configuration and cost issues. I'm trying to reduce configuration and computation overheads. Besides that, can you be more specific about costs? > 5. The way I see the solution is only a recommendation to the end > user to use the bear minimum of the crypto feature(if they have) > to alleviate this attack. I would assume, that if an end-user > did have crypto, he would be using it anyways depending on his > requirement(AH or ESP, PKI or shared or whatever) The IPsec community discussed this as I summarized; current IPsec tends to require CA agreement, which is considered prohibitive overhead. The whole point of ANONsec is to reduce that overhead, so the crypto that already exists actually gets used ;-) > 6. I disagree that this has less inertia than the changes that > we are proposing in TCP :) I would be glad to have you back this up with some analysis. Right now, TCP represents a ubiquitous installed base that largely defines the "Internet". Modifications to the state machines of TCP can - and have - tripped legacy implementations in the past, even given substantial pre-deployment analysis. The modifications proposed to IPsec do not modify the state machine of IKE (I would be equally hesitant to do that), which is at least one reason I think this has less inertia. Joe --------------enig215752BDD244D0B2EA5F9759 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 iD8DBQFAmtQ9E5f5cImnZrsRAmstAJ9mMx4geS8eonT831d11NeR/HkThQCgnpsF FfM3jQ2pB7wwxfXzvIlYB3s= =/fy2 -----END PGP SIGNATURE----- --------------enig215752BDD244D0B2EA5F9759-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 6 20:52:13 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01248 for ; Thu, 6 May 2004 20:52: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 1BLtXq-0000RU-R2 for tcpm-archive@odin.ietf.org; Thu, 06 May 2004 20:48:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i470msbr001694 for tcpm-archive@odin.ietf.org; Thu, 6 May 2004 20:48:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLtXA-00006R-LY for tcpm-web-archive@optimus.ietf.org; Thu, 06 May 2004 20:48: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 UAA00992 for ; Thu, 6 May 2004 20:48: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 1BLtX8-0005s2-9Q for tcpm-web-archive@ietf.org; Thu, 06 May 2004 20:48:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLtW8-0005Sm-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 20:47:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLtV6-0004ud-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 20:46:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLtS9-0007N6-OG; Thu, 06 May 2004 20: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 1BLtOT-0006Gz-LY for tcpm@optimus.ietf.org; Thu, 06 May 2004 20:39: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 UAA00492 for ; Thu, 6 May 2004 20:39: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 1BLtOR-00028G-D8 for tcpm@ietf.org; Thu, 06 May 2004 20:39:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLtNP-0001i6-00 for tcpm@ietf.org; Thu, 06 May 2004 20:38:08 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BLtMJ-0000v4-00 for tcpm@ietf.org; Thu, 06 May 2004 20:36:59 -0400 Received: from [128.9.168.57] (tnn.isi.edu [128.9.168.57]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i470a2J05261; Thu, 6 May 2004 17:36:02 -0700 (PDT) Message-ID: <409AD9F2.4060804@isi.edu> Date: Thu, 06 May 2004 17:36:02 -0700 From: Yu-Shun Wang User-Agent: Mozilla Thunderbird 0.6 (X11/20040504) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yogesh.Swami@nokia.com CC: tcpm@ietf.org Subject: Re: [tcpm] new internet draft - drafft-touch-anonsec References: <025E7DD4182874489CC2F61EE0FA19CE016E80F7@daebe004.americas.nokia.com> In-Reply-To: <025E7DD4182874489CC2F61EE0FA19CE016E80F7@daebe004.americas.nokia.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040301010502000604050602" X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: yushunwa@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=AWL autolearn=no version=2.60 This is a cryptographically signed message in MIME format. --------------ms040301010502000604050602 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, Comments inline... Yogesh.Swami@nokia.com wrote: >>-----Original Message----- >>From: ext Joe Touch [mailto:touch@ISI.EDU] ... >>2. accept new SAs in which the source address of the inner or outer >>header is Alice, from Trudy >> any inner source that isn't Trudy ought to be invalid for >> any packet from Trudy, or Bob is ASKING to be spoofed > So if I understand this correctly, then what you are saying is that if > Trudy sends a packet as follows, > > IPhdr1[AH-hdr[IPhdr1[IPhdr1[IPHdr1...[IPHdr-2, TCP ]]]]]...] No. I think tunnel mode (or transport mode with IP inside) from *unknown* peers should be prohibited in order to prevent tunneled spoofing attacks. And this should be the case for both AnonIKE and (real) IKE. I am not an IPsec/IKE Expert (IANAIE? :-), but I guess most policies start with white lists of all known IKE peers and what they are allowed to do. And at the end, you have rules like "block all from everything else" or something to that effect. The rule above (no tunnel mode or transport mode+IP from unknown peers) should be one of the catch-all rules at the end if there isn't already one. (This, of course, is assuming IKE policy processing is sorted like firewall rule matching.) So AnonIKE relaxes the requirement of CA in IKE and then some. But it does not relax how one should write the policy. Though as Joe said, the first version did not address that. > (where IPHdr-1 is a valid IP header between Alice and Trudy, but only > IPHdr-2 is the IP header between Alice and Bob) then IPSec engine should > parse the headers all the way up to IPHdr-2 and then throw it! I haven't > read the new AH draft, but this would mean a simple DoS on IPSec engine > itself (especially when there are no keys/Certs to prevent SPI > formation.) Also, what if one of the IPHdr-1 (lets say the third one > from left) has a lot of repeated NOPs and a MF bit set in that IP > header. How does the IPSec engine handle parsing of headers in this > case? See above. Just take out tunnel mode (or transport+IP) from unknown peers from the policy. > If it means only checking the first and second IPHdr-1 after the AH > header, then the attack is not preventable without a policy that stops > all IP in IP. > > The policy of preventing all IP in IP whenever the SPI is formed using > AnonIke is too restrictive, IMO. It would mean that if I want to have > some form of IP tunneling between two host and also use TCP over that > tunnel, then I cannot have secure TCP! To me this is not a reasonable > policy for a general TCP security solution. I had the same concern at first. But the firewall analogy changed my view. If one allows tunnel mode between any src & dest in the inner packets in regular IKE, having the CA requirement only authenticates where the attacks come from, but does not prevent the attacks. Same applies to AnonIKE. IMHO, the real question for AnonIKE is whether allowing anyone to negotiate transport mode (non-IP payload) SAs opens up new/serious holes in places we haven't thought of (such as DDoS against router IKE/IPsec processing, etc.) Regards, yushun > (I didn't understand the policies you pointed out, so I cannot comment > on them now.) > > Yogesh -- Yu-Shun Wang USC Information Sciences Institute --------------ms040301010502000604050602 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICAwuzTDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwMjEyMDcwNzM2WhcNMDUwMjExMDcwNzM2 WjB6MQ0wCwYDVQQEEwRXYW5nMRAwDgYDVQQqEwdZdS1TaHVuMRUwEwYDVQQDEwxZdS1TaHVu IFdhbmcxHzAdBgkqhkiG9w0BCQEWEHl1c2h1bndhQGlzaS5lZHUxHzAdBgkqhkiG9w0BCQEW EHl1c2h1bndhQHVzYy5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCc8n5U xhl7Ij0hjHYl8ZRZc0D9m/dX9elXEi+F4m8BjcrySYYNxiAUAxb6iB7aCskyxmYpxDRgC+up D9fxexuSRzhQeqv+EEmhjJ14IEx3JfGT0Mnuexef5UfOjf8t2zJLTMp2Z6ZJNZhm0d3OTX7H Gw6HoUbYnPuLFP8YRI3A72Gyjo9qlajq2Fv84ZpdRwt+plDk6czfawPMpptPw7RVNQTRhadQ DyM5visEsRhwR8LegLn8UqtwomeiauxNSbNrUJI3vm8Q8JZFKQWZlrod/I3Ud7P4zU6qQXoS HAV5OavL0zEO4mSug5bLSpfSoumBg6CvYbPEz4mUPJ3JGBnbAgMBAAGjPzA9MC0GA1UdEQQm MCSBEHl1c2h1bndhQGlzaS5lZHWBEHl1c2h1bndhQHVzYy5lZHUwDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQAUuycfrv876o8eccQGgl7AWxEottLDXHxL4W9XxL2rPMER88Vs ott5PU1mjm2Mnh4jgjhmqZaofReeTbLQaCbgqgdyR4ZESZjbmE7e8tWpe9blMjcCTpeVI99N yJJooUql3crtUKcfxCsukuh200E3Aaw8PW6KY5N3HG45ISpF8zCCAxcwggKAoAMCAQICAwuz TDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0EwHhcNMDQwMjEyMDcwNzM2WhcNMDUwMjExMDcwNzM2WjB6MQ0wCwYDVQQEEwRX YW5nMRAwDgYDVQQqEwdZdS1TaHVuMRUwEwYDVQQDEwxZdS1TaHVuIFdhbmcxHzAdBgkqhkiG 9w0BCQEWEHl1c2h1bndhQGlzaS5lZHUxHzAdBgkqhkiG9w0BCQEWEHl1c2h1bndhQHVzYy5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCc8n5Uxhl7Ij0hjHYl8ZRZc0D9 m/dX9elXEi+F4m8BjcrySYYNxiAUAxb6iB7aCskyxmYpxDRgC+upD9fxexuSRzhQeqv+EEmh jJ14IEx3JfGT0Mnuexef5UfOjf8t2zJLTMp2Z6ZJNZhm0d3OTX7HGw6HoUbYnPuLFP8YRI3A 72Gyjo9qlajq2Fv84ZpdRwt+plDk6czfawPMpptPw7RVNQTRhadQDyM5visEsRhwR8LegLn8 UqtwomeiauxNSbNrUJI3vm8Q8JZFKQWZlrod/I3Ud7P4zU6qQXoSHAV5OavL0zEO4mSug5bL SpfSoumBg6CvYbPEz4mUPJ3JGBnbAgMBAAGjPzA9MC0GA1UdEQQmMCSBEHl1c2h1bndhQGlz aS5lZHWBEHl1c2h1bndhQHVzYy5lZHUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQAUuycfrv876o8eccQGgl7AWxEottLDXHxL4W9XxL2rPMER88Vsott5PU1mjm2Mnh4jgjhm qZaofReeTbLQaCbgqgdyR4ZESZjbmE7e8tWpe9blMjcCTpeVI99NyJJooUql3crtUKcfxCsu kuh200E3Aaw8PW6KY5N3HG45ISpF8zCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggM7MIID NwIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQID C7NMMAkGBSsOAwIaBQCgggGnMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTA0MDUwNzAwMzYwMlowIwYJKoZIhvcNAQkEMRYEFNmVWEmUDl7nNmIUq8mBCtjQ XmcLMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMHgGCSsGAQQBgjcQBDFrMGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLs0wwegYLKoZI hvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIDC7NMMA0GCSqGSIb3DQEBAQUABIIBACCM78d9SjyWJRC4TunMy/pnDoTZ1l097ejT CD5DbEAqwao+dVUrqT5hVlGkH8GqzQOVv33vLqI4PU+naDfxuVprK7qIpDg1nFxrO6qEa+Te DW8QzoG11BiJKEBCvJ+NNJ/1eVWVKmJRFL72x/WYM7hoFETHf7lvEMocBxPyEoX8OXPpT4JB 7sAu4VGx/mam5d+rXNbXBRy/dAKGCVWmqZPZ+L+zGr8nMT2luUvzraiI/k6kL5W99JufcXr6 4GkAXLGg/H3zcrktlJW+Fxyib2EyPQmduGPnF7LS6uTI7kEa5+59OB+AM/daQzTwUfL7jdws nqV7ryD5c5erccVV4TUAAAAAAAA= --------------ms040301010502000604050602-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 6 22:50:16 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 WAA06167 for ; Thu, 6 May 2004 22:50: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 1BLvQ5-00007l-Ap for tcpm-archive@odin.ietf.org; Thu, 06 May 2004 22:49:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i472n1A9000478 for tcpm-archive@odin.ietf.org; Thu, 6 May 2004 22:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLvOU-00084Z-2Q for tcpm-web-archive@optimus.ietf.org; Thu, 06 May 2004 22: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 WAA06094 for ; Thu, 6 May 2004 22:47: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 1BLvOQ-0000rd-Pg for tcpm-web-archive@ietf.org; Thu, 06 May 2004 22:47:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLvNc-0000Rn-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 22:46:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLvMt-0007ms-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 22:45:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLvJI-0006V4-TX; Thu, 06 May 2004 22:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLvF0-0005Gf-9I for tcpm@optimus.ietf.org; Thu, 06 May 2004 22:37: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 WAA05725 for ; Thu, 6 May 2004 22:37: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 1BLvEw-0004TR-VM for tcpm@ietf.org; Thu, 06 May 2004 22:37:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLvDy-00042f-00 for tcpm@ietf.org; Thu, 06 May 2004 22:36:30 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BLvCp-0003DP-00 for tcpm@ietf.org; Thu, 06 May 2004 22:35:20 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 06 May 2004 19:34:54 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i472YlC1010092; Thu, 6 May 2004 19:34:48 -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 ATU73018; Thu, 6 May 2004 19:34:46 -0700 (PDT) Message-ID: <409AF5C6.B4DA4358@cisco.com> Date: Thu, 06 May 2004 19:34:46 -0700 From: Anantha Ramaiah Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Joe Touch CC: Mitesh Dalal , Yogesh.Swami@nokia.com, huitema@windows.microsoft.com, tcpm@ietf.org Subject: Re: [tcpm] new internet draft - drafft-touch-anonsec References: <025E7DD4182874489CC2F61EE0FA19CE028856BF@daebe004.americas.nokia.com> <409AA881.6070202@isi.edu> <409AD43D.8040108@isi.edu> 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > I would be glad to have you back this up with some analysis. Right now, > TCP represents a ubiquitous installed base that largely defines the > "Internet". Modifications to the state machines of TCP can - and have - Hmm.. Not sure I agree with this for ... - I guess we need quantify here. How much modifications are we talking about to TCP? Are they safe/unsafe? What is the worst case scenario? I think these arguments/thoughts has been going on from the time we thought about the TCP secure proposal. - The changes which is proposed (TCP secure draft) is to make TCP more robust. Agreed we need to address the corner cases and document some of those. [Esp the middlebox scenarios, which have been by far the most part of concern] - It appears that if we follow this logic of "no changes (not even minor) to TCP state machine, then I don't think we can ever make changes to TCP because almost any change for a mature protocol like TCP may interfere with the TCP state machine ( may be even marginally) and I think there is no need for any workgroup (TCP maintenance and minor extensions) as such :) My thinking on this is : - making TCP robust to benefit the "raw" users of the protocol. By "raw user" I mean any client who does not wish to use other "costly" methods like ipsec etc., due to deployment constraints. Irrespective of whether or not which solutions are going to be pursued I think efforts need to be made to enhance the robustness of the protocol. -Anantha > tripped legacy implementations in the past, even given substantial > pre-deployment analysis. The modifications proposed to IPsec do not > modify the state machine of IKE (I would be equally hesitant to do > that), which is at least one reason I think this has less inertia. > > Joe > > ------------------------------------------------------------------------------ > Name: signature.asc > signature.asc Type: application/pgp > Description: OpenPGP digital signature _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 6 23:02:10 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 XAA06620 for ; Thu, 6 May 2004 23:02: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 1BLvag-0002o1-6g for tcpm-archive@odin.ietf.org; Thu, 06 May 2004 22:59:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i472xwAC010785 for tcpm-archive@odin.ietf.org; Thu, 6 May 2004 22:59:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLvXE-0001Xy-Bw for tcpm-web-archive@optimus.ietf.org; Thu, 06 May 2004 22: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 WAA06352 for ; Thu, 6 May 2004 22: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 1BLvXA-0004Xd-R0 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 22:56:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLvWB-00048k-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 22:55:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLvVX-0003kQ-00 for tcpm-web-archive@ietf.org; Thu, 06 May 2004 22:54:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLvQ7-00008W-90; Thu, 06 May 2004 22:49:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLvLe-0007La-UQ for tcpm@optimus.ietf.org; Thu, 06 May 2004 22:44: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 WAA05969 for ; Thu, 6 May 2004 22:44: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 1BLvLb-0007MG-IP for tcpm@ietf.org; Thu, 06 May 2004 22:44:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLvKm-0006wr-00 for tcpm@ietf.org; Thu, 06 May 2004 22:43:33 -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 1BLvJx-0006R5-00 for tcpm@ietf.org; Thu, 06 May 2004 22:42:41 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 06 May 2004 18:47:11 +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 i472g9Su024398; Thu, 6 May 2004 19:42:09 -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 ASY91347; Thu, 6 May 2004 19:41:22 -0700 (PDT) Date: Thu, 6 May 2004 19:42:09 -0700 (PDT) From: Mitesh Dalal To: Joe Touch cc: Yogesh.Swami@nokia.com, huitema@windows.microsoft.com, tcpm@ietf.org Subject: Re: [tcpm] new internet draft - drafft-touch-anonsec In-Reply-To: <409AD43D.8040108@isi.edu> Message-ID: References: <025E7DD4182874489CC2F61EE0FA19CE028856BF@daebe004.americas.nokia.com> <409AA881.6070202@isi.edu> <409AD43D.8040108@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 Thu, 6 May 2004, Joe Touch wrote: > > 1. Interop issues. In the proposed solutions, both ends need to > > support crypto, if they dont, what do you do ? > > IMO, if you want to authenticate the source of packets, both ends need > to support crypto. All other devices are basically some variant of > crypto embedded in the (IMO) wrong place. > that what you and I would like it to be, but that is not how it is out there. > > 2. UDP and the relevant ports have to be allowed in the middleboxes. > > Any plan to address this problem. > > Middleboxes that end up looking like spoofers are correctly identified > and defeated. Middleboxes that are proxies would work fine. > I am not sure what you are talking about. What I was referring to is many organizations have strict UDP blocking in order to prevent udp attacks like snmp. In order to let ISAKMP through, they would have to allow yet another protocol and ports for the "handshake" to happen and without proper configuration, this may lead to more avenues for mischief. Morever IPSec and NAT are 2 well-known interop beasts in themself. > > 3. Scalability. Are the current crypto solutions designed to handle > > thousands of connections ? > > Yes. > Not the last time I checked. I used to work in the crypto group earlier and I am well aware of the issues that end users have seen in the past. This maybe implementation and h/w related, but the technology is not perfected yet. > > 4. Configuration and cost issues. > > I'm trying to reduce configuration and computation overheads. Besides > that, can you be more specific about costs? crypto s/w, h/w and the people who can maintain them cost more than their vanilla counterparts. > > > 5. The way I see the solution is only a recommendation to the end > > user to use the bear minimum of the crypto feature(if they have) > > to alleviate this attack. I would assume, that if an end-user > > did have crypto, he would be using it anyways depending on his > > requirement(AH or ESP, PKI or shared or whatever) > > The IPsec community discussed this as I summarized; current IPsec tends > to require CA agreement, which is considered prohibitive overhead. The > whole point of ANONsec is to reduce that overhead, so the crypto that > already exists actually gets used ;-) > > > 6. I disagree that this has less inertia than the changes that > > we are proposing in TCP :) > > I would be glad to have you back this up with some analysis. Right now, > TCP represents a ubiquitous installed base that largely defines the > "Internet". Modifications to the state machines of TCP can - and have - > tripped legacy implementations in the past, even given substantial > pre-deployment analysis. The modifications proposed to IPsec do not > modify the state machine of IKE (I would be equally hesitant to do > that), which is at least one reason I think this has less inertia. If TCP is such a thou-shall-touch-not technology, then it would seem so much ironical that we should have a WG called tcpm whose charter is to suggest changes :) Thanks Mitesh _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri May 7 00:25: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 AAA10073 for ; Fri, 7 May 2004 00:25: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 1BLwuY-0000Rm-6K for tcpm-archive@odin.ietf.org; Fri, 07 May 2004 00:24:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i474OY2N001714 for tcpm-archive@odin.ietf.org; Fri, 7 May 2004 00: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 1BLwrd-00089k-IC for tcpm-web-archive@optimus.ietf.org; Fri, 07 May 2004 00:21: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 AAA09937 for ; Fri, 7 May 2004 00:21: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 1BLwrb-0007IK-5v for tcpm-web-archive@ietf.org; Fri, 07 May 2004 00:21:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLwqe-0006tB-00 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 00:20:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLwq3-0006TP-00 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 00:19:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLwlL-0006OQ-0o; Fri, 07 May 2004 00:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLwis-00051j-He for tcpm@optimus.ietf.org; Fri, 07 May 2004 00:12: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 AAA09610 for ; Fri, 7 May 2004 00:12: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 1BLwiq-0003YL-51 for tcpm@ietf.org; Fri, 07 May 2004 00:12:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLwhr-00039b-00 for tcpm@ietf.org; Fri, 07 May 2004 00:11:28 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BLwhI-0002jl-00 for tcpm@ietf.org; Fri, 07 May 2004 00:10:52 -0400 Received: from isi.edu (lsanca1-ar42-4-61-165-108.lsanca1.dsl-verizon.net [4.61.165.108]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i47481J11945; Thu, 6 May 2004 21:08:01 -0700 (PDT) Message-ID: <409B0BA2.2080503@isi.edu> Date: Thu, 06 May 2004 21:08:02 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mitesh Dalal CC: Yogesh.Swami@nokia.com, huitema@windows.microsoft.com, tcpm@ietf.org Subject: Re: [tcpm] new internet draft - drafft-touch-anonsec References: <025E7DD4182874489CC2F61EE0FA19CE028856BF@daebe004.americas.nokia.com> <409AA881.6070202@isi.edu> <409AD43D.8040108@isi.edu> 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="------------enigCCA260522A0BDFEA639BBCEA" 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) --------------enigCCA260522A0BDFEA639BBCEA Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mitesh Dalal wrote: >>>2. UDP and the relevant ports have to be allowed in the middleboxes. >>>Any plan to address this problem. >> >>Middleboxes that end up looking like spoofers are correctly identified >>and defeated. Middleboxes that are proxies would work fine. > > I am not sure what you are talking about. What I was referring to is many > organizations have strict UDP blocking in order to prevent udp attacks > like snmp. In order to let ISAKMP through, they would have to allow yet > another protocol and ports for the "handshake" to happen and without > proper configuration, this may lead to more avenues for mischief. > Morever IPSec and NAT are 2 well-known interop beasts in themself. Agreed. But then any mod to TCP may not interoperate with middleboxes anyway. Middleboxes work in one of two modes: a) 'transparent' (NATs fall into this group) these ARE spoofers. some users may like them (I use them on occasion), but as far as 'defeating spoofing attacks' goes, any real spoofing solution will almost ensure failure to play nice with this kind b) proxies (explicit web proxies fall into this group) these should work fine i.e., some transparent proxies shoot RSTs to 'help' a connection by cleaning it up; as has been discussed on this list, such behavior can cause interoperation problems with any mods to RST processing. basically, such boxes represent legacy components that do worse than use a fixed protocol implementation - they usually make assumptions about protocol behavior based on current implementations, rather than protocol rules per se. any mods to existing behavior can - and usually will - trip at least some of them up. >>>3. Scalability. Are the current crypto solutions designed to handle >>>thousands of connections ? >> >>Yes. > > Not the last time I checked. I used to work in the crypto group earlier > and I am well aware of the issues that end users have seen in the past. > This maybe implementation and h/w related, but the technology is not > perfected yet. Handling thousands of connections is easy. Handling them fast is not. But fast demuxing based on SPI indexing is not substantially different from fast demuxing based on TCP port number - anything that has that many connections has to handle them fast anyway. >>>4. Configuration and cost issues. >> >>I'm trying to reduce configuration and computation overheads. Besides >>that, can you be more specific about costs? > > crypto s/w, h/w and the people who can maintain them cost more than > their vanilla counterparts. IPsec crypto comes with most modern routers and OS's. Again, the focus of the draft is to encourage cheaper use of existing crypto anyway. >>>5. The way I see the solution is only a recommendation to the end >>>user to use the bear minimum of the crypto feature(if they have) >>>to alleviate this attack. I would assume, that if an end-user >>>did have crypto, he would be using it anyways depending on his >>>requirement(AH or ESP, PKI or shared or whatever) >> >>The IPsec community discussed this as I summarized; current IPsec tends >>to require CA agreement, which is considered prohibitive overhead. The >>whole point of ANONsec is to reduce that overhead, so the crypto that >>already exists actually gets used ;-) >> >> >>>6. I disagree that this has less inertia than the changes that >>>we are proposing in TCP :) >> >>I would be glad to have you back this up with some analysis. Right now, >>TCP represents a ubiquitous installed base that largely defines the >>"Internet". Modifications to the state machines of TCP can - and have - >>tripped legacy implementations in the past, even given substantial >>pre-deployment analysis. The modifications proposed to IPsec do not >>modify the state machine of IKE (I would be equally hesitant to do >>that), which is at least one reason I think this has less inertia. > > If TCP is such a thou-shall-touch-not technology, then it would seem > so much ironical that we should have a WG called tcpm whose charter > is to suggest changes :) Having the TCPM WG is not - IMO - carte blanche to change TCP. The cost of the mod should be outweighed by the benefit, and take into consideration the overall effect. I.e., modifying TCP's initial windows didn't require mods to the state machine. There are other mods that can be negotiated at startup and don't operate unless both ends agree. The current proposal is a mod that is intended to be deployed unilaterally, makes changes to TCPs state machine (adds an arc or more), causes RSTs to generate responses, and causes valid RSTs from legacy sources to NOT reset a connection. These are different beasts. Joe --------------enigCCA260522A0BDFEA639BBCEA 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 iD8DBQFAmwuiE5f5cImnZrsRAk7RAJ0Yp+iHSg7TnZSdV/a+VE2bs03J/gCgh0nB Q0kBpd9ZbYBnJXOpYTeMIQM= =bduS -----END PGP SIGNATURE----- --------------enigCCA260522A0BDFEA639BBCEA-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri May 7 00:25: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 AAA10144 for ; Fri, 7 May 2004 00:25: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 1BLwuY-0000SG-Qk for tcpm-archive@odin.ietf.org; Fri, 07 May 2004 00:24:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i474OYOi001743 for tcpm-archive@odin.ietf.org; Fri, 7 May 2004 00: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 1BLwtX-0000CE-EL for tcpm-web-archive@optimus.ietf.org; Fri, 07 May 2004 00:23: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 AAA10005 for ; Fri, 7 May 2004 00:23: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 1BLwtV-0000LY-08 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 00:23:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLwsb-0007jZ-00 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 00:22:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLws5-0007Jv-00 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 00:22:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLwq9-0007rW-Mk; Fri, 07 May 2004 00: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 1BLwkh-000637-En for tcpm@optimus.ietf.org; Fri, 07 May 2004 00:14: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 AAA09645 for ; Fri, 7 May 2004 00:14: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 1BLwkf-0004Mc-3h for tcpm@ietf.org; Fri, 07 May 2004 00:14:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLwjh-0003xD-00 for tcpm@ietf.org; Fri, 07 May 2004 00:13:22 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BLwik-00039n-00 for tcpm@ietf.org; Fri, 07 May 2004 00:12:22 -0400 Received: from isi.edu (lsanca1-ar42-4-61-165-108.lsanca1.dsl-verizon.net [4.61.165.108]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4747kJ11930; Thu, 6 May 2004 21:07:46 -0700 (PDT) Message-ID: <409B0B8E.7080301@isi.edu> Date: Thu, 06 May 2004 21:07:42 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anantha Ramaiah CC: Mitesh Dalal , Yogesh.Swami@nokia.com, huitema@windows.microsoft.com, tcpm@ietf.org Subject: Re: [tcpm] new internet draft - drafft-touch-anonsec References: <025E7DD4182874489CC2F61EE0FA19CE028856BF@daebe004.americas.nokia.com> <409AA881.6070202@isi.edu> <409AD43D.8040108@isi.edu> <409AF5C6.B4DA4358@cisco.com> In-Reply-To: <409AF5C6.B4DA4358@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="------------enig481E1A9BEAF59B4A8A4F2814" 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) --------------enig481E1A9BEAF59B4A8A4F2814 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Anantha Ramaiah wrote: > > >>I would be glad to have you back this up with some analysis. Right now, >>TCP represents a ubiquitous installed base that largely defines the >>"Internet". Modifications to the state machines of TCP can - and have - > > Hmm.. Not sure I agree with this for ... > > - I guess we need quantify here. How much modifications are we talking > about to TCP? Are they safe/unsafe? What is the worst case scenario? > I think these arguments/thoughts has been going on from the time we > thought about the TCP secure proposal. > > - The changes which is proposed (TCP secure draft) is to make TCP more > robust. Agreed we need to address the corner cases and document some > of those. [Esp the middlebox scenarios, which have been by far the most > part of concern] The change makes TCP try to provide source identity authentication. In the process, TCP is less robust in the following way: - a valid RST from a legitimate legacy source received at an upgraded destination can be ignored (in the sense that the connection is NOT reset), and can generate response traffic (sending an ACK) That is not, IMO, robusness per se. That is a change in behavior that we've all been analyzing the effects of. > - It appears that if we follow this logic of "no changes (not even minor) > to TCP state machine, then I don't think we can ever make changes to TCP > because almost any change for a mature protocol like TCP may interfere > with the TCP state machine ( may be even marginally) and I think there is > no need for any workgroup (TCP maintenance and minor extensions) as such > :) TCPM is not carte blanche to modify TCP, IMO. The state machine is a place I'm particularly concerned about tinkering. There are lots of other places in TCP to 'play' - e.g., large initial windows, the windowing operation overall, timeouts, etc. > My thinking on this is : > > - making TCP robust to benefit the "raw" users of the protocol. By > "raw user" I mean any client who does not wish to use other "costly" > methods like ipsec etc., due to deployment constraints. Irrespective > of whether or not which solutions are going to be pursued I think efforts > need to be made to enhance the robustness of the protocol. > > -Anantha The good news is that TCP mods may help everyone. The bad news is that we'll all be taking that risk if we're wrong, in a sense. Joe --------------enig481E1A9BEAF59B4A8A4F2814 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 iD8DBQFAmwuUE5f5cImnZrsRAupaAJ41o64aCJGDWc64eLyL00RTtEEn5ACfSAtq wPS3r4CfhDTgce8HBnJQJig= =xg4/ -----END PGP SIGNATURE----- --------------enig481E1A9BEAF59B4A8A4F2814-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri May 7 13: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 NAA06469 for ; Fri, 7 May 2004 13:15: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 1BM8tX-0006aC-Gt for tcpm-archive@odin.ietf.org; Fri, 07 May 2004 13:12:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47HCJ5T025304 for tcpm-archive@odin.ietf.org; Fri, 7 May 2004 13:12:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM8lU-0003jX-If for tcpm-web-archive@optimus.ietf.org; Fri, 07 May 2004 13:04: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 NAA05800 for ; Fri, 7 May 2004 13:03: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 1BM8lS-000543-PD for tcpm-web-archive@ietf.org; Fri, 07 May 2004 13:03:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM8kY-0004d0-00 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 13:03:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BM8jk-0004CN-00 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 13:02:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM8bp-0000CE-V7; Fri, 07 May 2004 12:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM8Vv-0006pX-5H for tcpm@optimus.ietf.org; Fri, 07 May 2004 12:47: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 MAA04748 for ; Fri, 7 May 2004 12:47: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 1BM8Vt-0005c8-HH for tcpm@ietf.org; Fri, 07 May 2004 12:47:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM8Ut-0005Ay-00 for tcpm@ietf.org; Fri, 07 May 2004 12:46:51 -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 1BM8Tm-0004LM-00 for tcpm@ietf.org; Fri, 07 May 2004 12:45:43 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 07 May 2004 08:48: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 i47GjAW9013222; Fri, 7 May 2004 09:45:10 -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 ASZ27228; Fri, 7 May 2004 09:44:23 -0700 (PDT) Date: Fri, 7 May 2004 09:45:09 -0700 (PDT) From: Mitesh Dalal To: "Randall Stewart (cisco)" cc: Paul Goyette , tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt In-Reply-To: <409A5A29.1060702@cisco.com> Message-ID: References: <409A5A29.1060702@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=AWL autolearn=no version=2.60 On Thu, 6 May 2004, Randall Stewart (cisco) wrote: > Paul Goyette wrote: > > >Clarifying my own post from yesterday: > > > > > > > >>Perhaps "Don't send repeated challenges with the same ACK value" would > >>be adequate? Then you only need to keep track of one new state value, > >>the last value sent in a challenge ACK. This should eliminate the ACK > >>war scenario. > >> > >> > > > >At least one person took this to mean that I was suggesting we select a > >_new_ ACK value for repeated RST segments. That's not what I meant. > > > >The intent of this is "If the value in the challenge ACK would be the > >same as the value sent in the previous challenge ACK, don't send any > >ACK at all." > > > > > > Hmm.. that would surely prevent any ACK war from > occuring... > this might not work. For a long lived connection, your rcv.nxt wouldnt budge much in between data transfers. So if an attacker sends you 1 RST in window, it would effectively shut you down from sending any more challenges as long we are at the same rcv.nxt ? Did I read this correctly ? thanks Mitesh _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri May 7 13:17: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 NAA06738 for ; Fri, 7 May 2004 13:17: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 1BM8wX-0007Yo-FE for tcpm-archive@odin.ietf.org; Fri, 07 May 2004 13:15:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47HFPQR029057 for tcpm-archive@odin.ietf.org; Fri, 7 May 2004 13:15:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM8tH-0006Zh-LG for tcpm-web-archive@optimus.ietf.org; Fri, 07 May 2004 13:12: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 NAA06197 for ; Fri, 7 May 2004 13: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 1BM8tF-0000qv-Tl for tcpm-web-archive@ietf.org; Fri, 07 May 2004 13:12:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM8s8-0000OL-00 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 13:10:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BM8r6-0007dp-00 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 13:09:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM8ih-0002bs-7W; Fri, 07 May 2004 13:01:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM8bh-00009V-Fk for tcpm@optimus.ietf.org; Fri, 07 May 2004 12:53: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 MAA05212 for ; Fri, 7 May 2004 12:53: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 1BM8bf-0000XE-IV for tcpm@ietf.org; Fri, 07 May 2004 12:53:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM8ag-000036-00 for tcpm@ietf.org; Fri, 07 May 2004 12:52:51 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BM8ZY-0006wd-00 for tcpm@ietf.org; Fri, 07 May 2004 12:51:40 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 07 May 2004 09:50:40 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i47Gp4Yw023097; Fri, 7 May 2004 12:51:06 -0400 (EDT) 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 ASZ27874; Fri, 7 May 2004 09:50:16 -0700 (PDT) Date: Fri, 7 May 2004 09:51:02 -0700 (PDT) From: Mitesh Dalal To: "Randall Stewart (cisco)" cc: AClarke@attotech.com, tcpm@ietf.org, mallman@icir.org, Kacheong Poon , Joe Touch Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt In-Reply-To: <409A10FA.2090001@cisco.com> Message-ID: References: <409A10FA.2090001@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=AWL autolearn=no version=2.60 On Thu, 6 May 2004, Randall Stewart (cisco) wrote: > AClarke@attotech.com wrote: > > >>>Doesn't this mean you can defeat someone else's ability to RST a > >>>connection by flooding them with RSTs? > >>> > >>>Holding state for a long time in that case means one party can't > >>>reset a connection they want - or need to, doesn't it? > >>> > >>> > >>Oh, well another approach I'll throw out is not more than one RST > >>challenge per time period. E.g., no more than 1/second. That limits > >>the damage of an ACK war without allowing someone to deny the legitimate > >>ripping down of a connection for minutes. (At the expense of some > >>state.) > >> > >> > >Would a longer time period be better - reduce the probability of a > >successful attack? If a legitimate reset were lost > >when would you expect another? Can you guess based on RTT? > > > > It seems to me one could add at a minimum a dampening > so that you would respond to RST's/Ack wars with a slower > rate.. say start with RST_ACK_DELAY = 0 > > Then when you get a RST and respond with an ACK, add > the current RTT to the RST_ACK_DELAY. Next RST since > RST_ACK_DELAY is not 0, you start a timer and at expiration > send your ACK and add yet another RTT to the RST_ACK_DELAY. > > This gives you a kind of exponential backoff (not quite though).. and > one could even ignore all further RST's if the timer was running... It > would slow the RST process down a tad.. but you would have to be > real unlucky to get a real RST slowed down more than 1 or 2 RTTs... > > The bad side to this is it is no longer just a tweak to to the stack.. you > really must add a timer and quite a few more bytes to the TCB to > track this... > this might work, but as you have already pointed out this is adding more state which might not be palatable. ACKs, as I see it are supposed to be stateless. We do not need to remember that we have send an ACK. Although I do agree that we can make a note of this in the draft and recommend adding an incoming RST throttling mechanism for scenario where there is a perceived danger of an offending middlebox that might cause the RST/ACK war. Thanks Mitesh _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri May 7 14:26: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 OAA10440 for ; Fri, 7 May 2004 14:26: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 1BM9wi-0001YE-8i for tcpm-archive@odin.ietf.org; Fri, 07 May 2004 14:19:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47IJeGn005957 for tcpm-archive@odin.ietf.org; Fri, 7 May 2004 14:19:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM9u8-0000Zu-Kj for tcpm-web-archive@optimus.ietf.org; Fri, 07 May 2004 14: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 OAA09935 for ; Fri, 7 May 2004 14:16: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 1BM9u6-0006XF-54 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 14:16:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM9t6-00066T-00 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 14:15:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BM9s3-0005aw-00 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 14:14:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM9oN-0007MX-0T; Fri, 07 May 2004 14:11:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM9ii-0005Dp-J2 for tcpm@optimus.ietf.org; Fri, 07 May 2004 14: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 OAA09313 for ; Fri, 7 May 2004 14:05: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 1BM9ig-0001Fs-AU for tcpm@ietf.org; Fri, 07 May 2004 14:05:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM9hh-0000or-00 for tcpm@ietf.org; Fri, 07 May 2004 14:04:09 -0400 Received: from mail1.cray.com ([136.162.0.111]) by ietf-mx with esmtp (Exim 4.12) id 1BM9hB-0000JY-00 for tcpm@ietf.org; Fri, 07 May 2004 14:03:37 -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 i47I2vLl025224; Fri, 7 May 2004 13:02:58 -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 i47I2tgq007738; Fri, 7 May 2004 13:02:55 -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 i47I2tlN077302; Fri, 7 May 2004 13:02:55 -0500 (CDT) In-Reply-To: <40984E65.7090204@sun.com> References: <20040504161038.52F2577A71D@guns.icir.org> <40984E65.7090204@sun.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Kacheong Poon From: David Borman Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt Date: Fri, 7 May 2004 13:02:42 -0500 To: tcpm@ietf.org X-Mailer: Apple Mail (2.613) X-Cray-VirusStatus: clean 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 few thoughts. First, one should not think of this as the RST is getting ACKed. I think of it more as a potentially bogus RST has arrived, so we drop it, but then do a probe of the remote side by sending a current ACK, on the off chance that it was a valid RST. The ACK is not generated using any state from the RST packet, it is generated entirely from our current connection state. Second, aside from the ABORT case (RFC 793, pg 62), all RST packets are generated in direct response to an invalid packet being received, and the RST takes its seq or ack value directly from the RST packet. If the ACK bit was set in the offending packet, the RST is: And if the ACK bit is not set, the RST is: Any implementation that generates RST packets and does not take the seq/ack value from the offending packet is in violation of RFC793. If the spontaneous RST generated due to an ABORT is questionable (if data was sent and lost before the ABORT), then the ACK generated by the remote side will cause a new RST to be generated, and it should be acceptable since it takes its values from the ACK packet. Third, I think the conservative approach would be to limit the RST challenge to ESTABLISHED state, since that is the state at which the main problem lies. And while a misbehaving middle should not be ignored, they should not have undue influence on changes to TCP. By their very nature they get in the way of TCP. Any box can get into trouble when another host changes is some manner, causing the box to go down a processing path that it hasn't used before. The broken box needs to be fixed, the rest of the world shouldn't change to accommodate the broken box. Fourth, somthing that I haven't seen yet, RST packets that have the ACK bit set should probably always be ignored in ESTABLISHED and later states. Assuming we are sending proper packets, we should only get a RST-ACK in response to our SYN. About the only valid scenario that I can see for that is if we send a SYN, retransmit the SYN (or it gets duplicated in the network), then get a SYN-ACK in response to the first SYN, and we send our SYN-ACK and enter ESTABLISHED state. Meanwhile, the other side aborted the connection while in the SYN-RECEIVED state, before the second SYN arrives, and so when the retransmitted SYN arrives, a RST is generated with the ACK bit set. But we should also get a RST in response to our SYN-ACK, without the ACK bit set, so if we ignore the RST with the ACK bit, we'll still get the connection closed by the second RST. (Note: The RST generated due to the ABORT call will be , so that should also be acceptable and cause our side to be dropped.) -David Borman On May 4, 2004, at 9:16 PM, Kacheong Poon wrote: > Mark Allman wrote: > >> I agree that the proposed scheme is not rfc793 conformant. But, I >> don't >> see how the last sentence above follows from the previous few. We can >> evolve and change. RFC793 has been and will continue to be updated. >> (I'm not arguing that the proposed change is The Way To Go, just >> trying >> to understand your argument.) > > Having seen some ACK wars interacting with middlebox, I am not > comfortable with a change which responds to a RST, which is > supposed to tell the other side to stop sending. It is similar to > responding to an ACK with an ACK. As I mentioned before, I am > not against changing TCP. But I think we should be careful > in doing it. > > > -- > > 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 May 7 14:30: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 OAA10824 for ; Fri, 7 May 2004 14:30: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 1BMA5U-0003zE-Ka for tcpm-archive@odin.ietf.org; Fri, 07 May 2004 14:28:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47ISiEj015316 for tcpm-archive@odin.ietf.org; Fri, 7 May 2004 14:28:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMA3A-0003Ir-5B for tcpm-web-archive@optimus.ietf.org; Fri, 07 May 2004 14:26: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 OAA10387 for ; Fri, 7 May 2004 14:26: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 1BMA37-0002ju-J0 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 14:26:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMA1m-0001r8-00 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 14:24:55 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMA0K-0001N8-00 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 14:23:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM9w7-0001IT-92; Fri, 07 May 2004 14:19:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM9pg-0007fu-L9 for tcpm@optimus.ietf.org; Fri, 07 May 2004 14:12: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 OAA09667 for ; Fri, 7 May 2004 14:12: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 1BM9pe-0004PF-32 for tcpm@ietf.org; Fri, 07 May 2004 14:12:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM9oU-0003wd-00 for tcpm@ietf.org; Fri, 07 May 2004 14:11:11 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BM9nh-0003Kz-00 for tcpm@ietf.org; Fri, 07 May 2004 14:10:21 -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 i47I7vBm068720; Fri, 7 May 2004 11:07:57 -0700 (PDT) (envelope-from pgoyette@juniper.net) Received: from pgoyette600 ([172.24.236.19]) by merlot.juniper.net (8.11.3/8.11.3) with SMTP id i47I7vJ52645; Fri, 7 May 2004 11:07:57 -0700 (PDT) (envelope-from pgoyette@juniper.net) From: "Paul Goyette" To: "Mitesh Dalal" , "Randall Stewart \(cisco\)" Cc: Subject: RE: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt Date: Fri, 7 May 2004 11:07:57 -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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: 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 you read it right. But the effect of this is no different than if the RST gets lost. If an attacker sends us the RST, then the real peer tries to reset, we would ignore the real peer, and things would just have to time out. -----Original Message----- From: Mitesh Dalal [mailto:mdalal@cisco.com] Sent: Friday, May 07, 2004 9:45 AM To: Randall Stewart (cisco) Cc: Paul Goyette; tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt On Thu, 6 May 2004, Randall Stewart (cisco) wrote: > Paul Goyette wrote: > > >Clarifying my own post from yesterday: > > > > > > > >>Perhaps "Don't send repeated challenges with the same ACK value" would > >>be adequate? Then you only need to keep track of one new state value, > >>the last value sent in a challenge ACK. This should eliminate the ACK > >>war scenario. > >> > >> > > > >At least one person took this to mean that I was suggesting we select a > >_new_ ACK value for repeated RST segments. That's not what I meant. > > > >The intent of this is "If the value in the challenge ACK would be the > >same as the value sent in the previous challenge ACK, don't send any > >ACK at all." > > > > > > Hmm.. that would surely prevent any ACK war from > occuring... > this might not work. For a long lived connection, your rcv.nxt wouldnt budge much in between data transfers. So if an attacker sends you 1 RST in window, it would effectively shut you down from sending any more challenges as long we are at the same rcv.nxt ? Did I read this correctly ? thanks Mitesh _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri May 7 15:08:07 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 PAA13824 for ; Fri, 7 May 2004 15:08: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 1BMAWX-0003uW-7b for tcpm-archive@odin.ietf.org; Fri, 07 May 2004 14:56:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47Iufr0015027 for tcpm-archive@odin.ietf.org; Fri, 7 May 2004 14:56:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMAV1-000381-Sm for tcpm-web-archive@optimus.ietf.org; Fri, 07 May 2004 14:55: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 OAA12301 for ; Fri, 7 May 2004 14:55: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 1BMAUz-0000A0-24 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 14:55:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMAU8-0007Wx-00 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 14:54:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMATd-000762-00 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 14:53:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMAKJ-00005U-14; Fri, 07 May 2004 14:44:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMAFO-0006u0-S9 for tcpm@optimus.ietf.org; Fri, 07 May 2004 14:38: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 OAA11135 for ; Fri, 7 May 2004 14:38: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 1BMAFM-0000Ye-7I for tcpm@ietf.org; Fri, 07 May 2004 14:38:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMAEO-00007c-00 for tcpm@ietf.org; Fri, 07 May 2004 14:37:57 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BMADW-00074A-00 for tcpm@ietf.org; Fri, 07 May 2004 14:37: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 i47IZbJ25430; Fri, 7 May 2004 11:35:37 -0700 (PDT) Message-ID: <409BD6F9.60905@isi.edu> Date: Fri, 07 May 2004 11:35:37 -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: David Borman CC: tcpm@ietf.org, Kacheong Poon Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: <20040504161038.52F2577A71D@guns.icir.org> <40984E65.7090204@sun.com> 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="------------enig7743A5DA1FD8869FD6DA4451" 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) --------------enig7743A5DA1FD8869FD6DA4451 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit David Borman wrote: > A few thoughts. > > First, one should not think of this as the RST is getting ACKed. I > think of it more as a potentially bogus RST has arrived, so we drop it, > but then do a probe of the remote side by sending a current ACK, on the > off chance that it was a valid RST. The ACK is not generated using any > state from the RST packet, it is generated entirely from our current > connection state. This is confusing. The current connection state isn't what causes the ACK to occur - i.e., it's not a timeout, etc. The received RST is what causes the ACK. It may be interesting that the contents of the ACK are otherwise unrelated to the RST, except for the following fields: IP src/dst address TCP src/dst port numbers RST seq number (inside the window, but not at the end) That seems like the ACK is directly generated from the RST to me ;-) > Second, aside from the ABORT case (RFC 793, pg 62), all RST packets are > generated in direct response to an invalid packet being received, and > the RST takes its seq or ack value directly from the RST packet. If the ^^^^^^^^^^^^^^^^^^^^^ directly from the invalid packet, right? > ACK bit was set in the offending packet, the RST is: > > And if the ACK bit is not set, the RST is: > > Any implementation that generates RST packets and does not take the > seq/ack value from the offending packet is in violation of RFC793. > > If the spontaneous RST generated due to an ABORT is questionable (if > data was sent and lost before the ABORT), then the ACK generated by the > remote side will cause a new RST to be generated, and it should be > acceptable since it takes its values from the ACK packet. As already discussed, in the meantime new data can arrive at the receiver (out of order delivery), in which case it's possible that there are as many additional ACKs and RSTs flinged about as there were packets in the pipe. At least - more if data is lost. > Third, I think the conservative approach would be to limit the RST > challenge to ESTABLISHED state, since that is the state at which the > main problem lies. And while a misbehaving middle should not be > ignored, they should not have undue influence on changes to TCP. By > their very nature they get in the way of TCP. Any box can get into > trouble when another host changes is some manner, causing the box to go > down a processing path that it hasn't used before. The broken box needs > to be fixed, the rest of the world shouldn't change to accommodate the > broken box. > > Fourth, somthing that I haven't seen yet, RST packets that have the ACK > bit set should probably always be ignored in ESTABLISHED and later > states. I thought the RST-ACKs' being mentioned were really just ACKs, not RSTs with the ACK bit set. Setting the RST bit overrides the ACK bit anyway (it gets processed first), and will kill the other side ;-) > Assuming we are sending proper packets, we should only get a > RST-ACK in response to our SYN. About the only valid scenario that I > can see for that is if we send a SYN, retransmit the SYN (or it gets > duplicated in the network), then get a SYN-ACK in response to the first > SYN, and we send our SYN-ACK and enter ESTABLISHED state. Meanwhile, > the other side aborted the connection while in the SYN-RECEIVED state, > before the second SYN arrives, and so when the retransmitted SYN > arrives, a RST is generated with the ACK bit set. But we should also > get a RST in response to our SYN-ACK, without the ACK bit set, so if we > ignore the RST with the ACK bit, we'll still get the connection closed > by the second RST. (Note: The RST generated due to the ABORT call will > be , so that should also be acceptable and cause > our side to be dropped.) > > -David Borman > > > On May 4, 2004, at 9:16 PM, Kacheong Poon wrote: > >> Mark Allman wrote: >> >>> I agree that the proposed scheme is not rfc793 conformant. But, I don't >>> see how the last sentence above follows from the previous few. We can >>> evolve and change. RFC793 has been and will continue to be updated. >>> (I'm not arguing that the proposed change is The Way To Go, just trying >>> to understand your argument.) >> >> >> Having seen some ACK wars interacting with middlebox, I am not >> comfortable with a change which responds to a RST, which is >> supposed to tell the other side to stop sending. It is similar to >> responding to an ACK with an ACK. As I mentioned before, I am >> not against changing TCP. But I think we should be careful >> in doing it. >> >> >> -- >> >> K. Poon. >> kacheong.poon@sun.com > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm --------------enig7743A5DA1FD8869FD6DA4451 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 iD8DBQFAm9b5E5f5cImnZrsRAqAGAJ9wznaDgBq3kKDxG5+X4jZTk/QrtwCg0XEL xRI9bsbK+1YIqiET35qC8Uw= =Pv0e -----END PGP SIGNATURE----- --------------enig7743A5DA1FD8869FD6DA4451-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri May 7 15:53:48 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 PAA16703 for ; Fri, 7 May 2004 15:53: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 1BMBJu-00045h-Qn for tcpm-archive@odin.ietf.org; Fri, 07 May 2004 15:47:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47JlgZd015726 for tcpm-archive@odin.ietf.org; Fri, 7 May 2004 15:47:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMBJE-0003pB-GR for tcpm-web-archive@optimus.ietf.org; Fri, 07 May 2004 15:47: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 PAA16398 for ; Fri, 7 May 2004 15:46: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 1BMBJC-0007KC-S1 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 15:46:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMBID-0006u8-00 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 15:45:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMBH9-0006HR-00 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 15:44:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMBDU-0001Ka-Tr; Fri, 07 May 2004 15:41:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMBAc-0000N4-6e for tcpm@optimus.ietf.org; Fri, 07 May 2004 15:38: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 PAA16047 for ; Fri, 7 May 2004 15:38: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 1BMBAa-0003VI-MW for tcpm@ietf.org; Fri, 07 May 2004 15:38:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMB9f-00035A-00 for tcpm@ietf.org; Fri, 07 May 2004 15:37: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 1BMB8k-0002Ew-00 for tcpm@ietf.org; Fri, 07 May 2004 15:36:10 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 07 May 2004 11:39:10 +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 i47JZcC1011171; Fri, 7 May 2004 12:35:39 -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 ASZ47575; Fri, 7 May 2004 12:34:50 -0700 (PDT) Date: Fri, 7 May 2004 12:35:36 -0700 (PDT) From: Mitesh Dalal To: Joe Touch cc: David Borman , tcpm@ietf.org, Kacheong Poon Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt In-Reply-To: <409BD6F9.60905@isi.edu> Message-ID: References: <20040504161038.52F2577A71D@guns.icir.org> <40984E65.7090204@sun.com> <409BD6F9.60905@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=AWL autolearn=no version=2.60 On Fri, 7 May 2004, Joe Touch wrote: > > > David Borman wrote: > > > A few thoughts. > > > > First, one should not think of this as the RST is getting ACKed. I > > think of it more as a potentially bogus RST has arrived, so we drop it, > > but then do a probe of the remote side by sending a current ACK, on the > > off chance that it was a valid RST. The ACK is not generated using any > > state from the RST packet, it is generated entirely from our current > > connection state. > > This is confusing. The current connection state isn't what causes the > ACK to occur - i.e., it's not a timeout, etc. > > The received RST is what causes the ACK. It may be interesting that the > contents of the ACK are otherwise unrelated to the RST, except for the > following fields: > IP src/dst address > TCP src/dst port numbers > RST seq number (inside the window, but not at the end) > That seems like the ACK is directly generated from the RST to me ;-) > the point that David is trying to make, IMO, is that looking at the ACK there is no way you can tell that it was caused because of an RST. It might have been a valid ACK or caused by an out of seq segment, or an invalid ACK or out of window SYN coming in an ESTAB or other places that 793 tells you to send an ACK. > > Second, aside from the ABORT case (RFC 793, pg 62), all RST packets are > > generated in direct response to an invalid packet being received, and > > the RST takes its seq or ack value directly from the RST packet. If the > ^^^^^^^^^^^^^^^^^^^^^ > directly from the invalid packet, right? yes. > > > ACK bit was set in the offending packet, the RST is: > > > > And if the ACK bit is not set, the RST is: > > > > Any implementation that generates RST packets and does not take the > > seq/ack value from the offending packet is in violation of RFC793. > > > > If the spontaneous RST generated due to an ABORT is questionable (if > > data was sent and lost before the ABORT), then the ACK generated by the > > remote side will cause a new RST to be generated, and it should be > > acceptable since it takes its values from the ACK packet. > > As already discussed, in the meantime new data can arrive at the > receiver (out of order delivery), in which case it's possible that there > are as many additional ACKs and RSTs flinged about as there were packets > in the pipe. At least - more if data is lost. > but in this case, the ack/rst rtt will not be more than 2. (there might be more packets, but no more than 2 loops) thx Mitesh > > Third, I think the conservative approach would be to limit the RST > > challenge to ESTABLISHED state, since that is the state at which the > > main problem lies. And while a misbehaving middle should not be > > ignored, they should not have undue influence on changes to TCP. By > > their very nature they get in the way of TCP. Any box can get into > > trouble when another host changes is some manner, causing the box to go > > down a processing path that it hasn't used before. The broken box needs > > to be fixed, the rest of the world shouldn't change to accommodate the > > broken box. > > > > Fourth, somthing that I haven't seen yet, RST packets that have the ACK > > bit set should probably always be ignored in ESTABLISHED and later > > states. > > I thought the RST-ACKs' being mentioned were really just ACKs, not RSTs > with the ACK bit set. Setting the RST bit overrides the ACK bit anyway > (it gets processed first), and will kill the other side ;-) > > > Assuming we are sending proper packets, we should only get a > > RST-ACK in response to our SYN. About the only valid scenario that I > > can see for that is if we send a SYN, retransmit the SYN (or it gets > > duplicated in the network), then get a SYN-ACK in response to the first > > SYN, and we send our SYN-ACK and enter ESTABLISHED state. Meanwhile, > > the other side aborted the connection while in the SYN-RECEIVED state, > > before the second SYN arrives, and so when the retransmitted SYN > > arrives, a RST is generated with the ACK bit set. But we should also > > get a RST in response to our SYN-ACK, without the ACK bit set, so if we > > ignore the RST with the ACK bit, we'll still get the connection closed > > by the second RST. (Note: The RST generated due to the ABORT call will > > be , so that should also be acceptable and cause > > our side to be dropped.) > > > > -David Borman > > > > > > On May 4, 2004, at 9:16 PM, Kacheong Poon wrote: > > > >> Mark Allman wrote: > >> > >>> I agree that the proposed scheme is not rfc793 conformant. But, I don't > >>> see how the last sentence above follows from the previous few. We can > >>> evolve and change. RFC793 has been and will continue to be updated. > >>> (I'm not arguing that the proposed change is The Way To Go, just trying > >>> to understand your argument.) > >> > >> > >> Having seen some ACK wars interacting with middlebox, I am not > >> comfortable with a change which responds to a RST, which is > >> supposed to tell the other side to stop sending. It is similar to > >> responding to an ACK with an ACK. As I mentioned before, I am > >> not against changing TCP. But I think we should be careful > >> in doing it. > >> > >> > >> -- > >> > >> 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 Fri May 7 15:58:05 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 PAA16837 for ; Fri, 7 May 2004 15:58: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 1BMBPr-0005HR-F8 for tcpm-archive@odin.ietf.org; Fri, 07 May 2004 15:53:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47Jrpcr020289 for tcpm-archive@odin.ietf.org; Fri, 7 May 2004 15:53:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMBKG-00045w-AA for tcpm-web-archive@optimus.ietf.org; Fri, 07 May 2004 15:48: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 PAA16422 for ; Fri, 7 May 2004 15:48: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 1BMBKE-0007m6-Od for tcpm-web-archive@ietf.org; Fri, 07 May 2004 15:48:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMBJH-0007Kp-00 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 15:47:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMBIZ-0006v6-00 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 15:46:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMBEQ-0001aM-4f; Fri, 07 May 2004 15:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMBCY-00013q-6h for tcpm@optimus.ietf.org; Fri, 07 May 2004 15:40: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 PAA16135 for ; Fri, 7 May 2004 15:40: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 1BMBCW-0004N7-Lv for tcpm@ietf.org; Fri, 07 May 2004 15:40:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMBBe-0003x3-00 for tcpm@ietf.org; Fri, 07 May 2004 15:39:11 -0400 Received: from mail1.cray.com ([136.162.0.111]) by ietf-mx with esmtp (Exim 4.12) id 1BMBAk-00035m-00 for tcpm@ietf.org; Fri, 07 May 2004 15:38:14 -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 i47JbYLl027277; Fri, 7 May 2004 14:37:38 -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 i47JbXUw012779; Fri, 7 May 2004 14:37:33 -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 i47JbWlN080718; Fri, 7 May 2004 14:37:32 -0500 (CDT) In-Reply-To: <409BD6F9.60905@isi.edu> References: <20040504161038.52F2577A71D@guns.icir.org> <40984E65.7090204@sun.com> <409BD6F9.60905@isi.edu> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Joe Touch From: David Borman Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt Date: Fri, 7 May 2004 14:37:20 -0500 To: tcpm@ietf.org X-Mailer: Apple Mail (2.613) X-Cray-VirusStatus: clean 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 May 7, 2004, at 1:35 PM, Joe Touch wrote: > David Borman wrote: > >> A few thoughts. >> First, one should not think of this as the RST is getting ACKed. I >> think of it more as a potentially bogus RST has arrived, so we drop >> it, but then do a probe of the remote side by sending a current ACK, >> on the off chance that it was a valid RST. The ACK is not generated >> using any state from the RST packet, it is generated entirely from >> our current connection state. > > This is confusing. The current connection state isn't what causes the > ACK to occur - i.e., it's not a timeout, etc. > > The received RST is what causes the ACK. It may be interesting that > the contents of the ACK are otherwise unrelated to the RST, except for > the following fields: > IP src/dst address > TCP src/dst port numbers > RST seq number (inside the window, but not at the end) > That seems like the ACK is directly generated from the RST to me ;-) One can view a RST as an out-of-band mechanism to tell someone to abort a connection (FIN is the in-band mechanism). If I'm told to abort a connection, but I don't think the request came from the other side, then the smart thing to do is to explicitly ask the other side if they really want to close the connection. The ACK is generated using connection state, not the information in the RST packet. The fact that the src/dst addr/port are the same between the connection state and the RST packet is a red herring; if they weren't the same, the RST would never has been associated with this connection. What is important is that the SEG.SEQ SEG.ACK fields are filled in with information from the connection state, not from any information in the RST packet. > >> Second, aside from the ABORT case (RFC 793, pg 62), all RST packets >> are generated in direct response to an invalid packet being received, >> and the RST takes its seq or ack value directly from the RST packet. >> If the > ^^^^^^^^^^^^^^^^^^^^^ > directly from the invalid packet, right? Yes, that's what I meant to say. > >> ACK bit was set in the offending packet, the RST is: >> >> And if the ACK bit is not set, the RST is: >> >> Any implementation that generates RST packets and does not take the >> seq/ack value from the offending packet is in violation of RFC793. >> If the spontaneous RST generated due to an ABORT is questionable (if >> data was sent and lost before the ABORT), then the ACK generated by >> the remote side will cause a new RST to be generated, and it should >> be acceptable since it takes its values from the ACK packet. > > As already discussed, in the meantime new data can arrive at the > receiver (out of order delivery), in which case it's possible that > there are as many additional ACKs and RSTs flinged about as there were > packets in the pipe. At least - more if data is lost. Yes, I know, but it is still deterministic. Even with the way things are today, if you send a bunch of data (that gets reordered along the way), and then ABORT the connection, the receiver will still be generating ACKs for all the out-of-order packets, each of which will cause another RST to be sent back to us. The fact that we can construct scenarios where there is a flurry of packets while things converge doesn't bother me a lot, as long as things are deterministic and we don't get into infinite loops. And the only way I see getting into infinite loops is by a broken implementation. > >> Third, I think the conservative approach would be to limit the RST >> challenge to ESTABLISHED state, since that is the state at which the >> main problem lies. And while a misbehaving middle should not be >> ignored, they should not have undue influence on changes to TCP. By >> their very nature they get in the way of TCP. Any box can get into >> trouble when another host changes is some manner, causing the box to >> go down a processing path that it hasn't used before. The broken box >> needs to be fixed, the rest of the world shouldn't change to >> accommodate the broken box. >> Fourth, somthing that I haven't seen yet, RST packets that have the >> ACK bit set should probably always be ignored in ESTABLISHED and >> later states. > > I thought the RST-ACKs' being mentioned were really just ACKs, not > RSTs with the ACK bit set. Setting the RST bit overrides the ACK bit > anyway (it gets processed first), and will kill the other side ;-) Which could be a bad thing, because if you get a RST with the ACK bit set, the only thing you should use to verify the RST is the ack field, but the RST gets processed first, killing the connection even if the ack field was bogus. The SEG.SEQ value should be zero, so if the sequence number checks are applied even though it isn't valid, then it gets tossed early. (Another thought is that if you get an RST with the ACK bit set and SEG.SEQ != 0, that's a bogus RST and should be tossed. In all instances in 793 where the ACK bit is set when generating a RST, the SEG.SEQ is explicitly set to zero.) In SYN-SENT state 793 verifies SEG.ACK before checking the RST bit. In ESTABLISHED and later, SEG.SEQ is verified first, then the RST bit, then SEG.ACK is verified. But if both the RST and ACK bits are set, we shouldn't be doing SEG.SEQ checks, because SEG.SEQ is not valid, and we should be verifying SEG.ACK before accepting the RST. -David Borman _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri May 7 16:30:57 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18847 for ; Fri, 7 May 2004 16:30: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 1BMBvp-0006rY-ND for tcpm-archive@odin.ietf.org; Fri, 07 May 2004 16:26:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47KQr5i026380 for tcpm-archive@odin.ietf.org; Fri, 7 May 2004 16:26:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMBnO-00048l-4Y for tcpm-web-archive@optimus.ietf.org; Fri, 07 May 2004 16:18: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 QAA17784 for ; Fri, 7 May 2004 16:18: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 1BMBnM-00055S-EE for tcpm-web-archive@ietf.org; Fri, 07 May 2004 16:18:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMBmS-0004fF-00 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 16:17:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMBm2-0004Em-00 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 16:16:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMBhQ-00028F-Hl; Fri, 07 May 2004 16:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMBZp-0008D3-Kd for tcpm@optimus.ietf.org; Fri, 07 May 2004 16:04: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 QAA17169 for ; Fri, 7 May 2004 16:04: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 1BMBZo-0006je-0k for tcpm@ietf.org; Fri, 07 May 2004 16:04:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMBYu-0006Ju-00 for tcpm@ietf.org; Fri, 07 May 2004 16:03:12 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BMBY3-0005Vh-00 for tcpm@ietf.org; Fri, 07 May 2004 16:02:19 -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 i47K0eJ13954; Fri, 7 May 2004 13:00:40 -0700 (PDT) Message-ID: <409BEAE1.5080802@isi.edu> Date: Fri, 07 May 2004 13:00:33 -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: David Borman , tcpm@ietf.org, Kacheong Poon Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: <20040504161038.52F2577A71D@guns.icir.org> <40984E65.7090204@sun.com> <409BD6F9.60905@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="------------enigBF318E0BCA150C54E52BDCEC" 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) --------------enigBF318E0BCA150C54E52BDCEC Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mitesh Dalal wrote: > > On Fri, 7 May 2004, Joe Touch wrote: > > >> >>David Borman wrote: >> >> >>>A few thoughts. >>> >>>First, one should not think of this as the RST is getting ACKed. I >>>think of it more as a potentially bogus RST has arrived, so we drop it, >>>but then do a probe of the remote side by sending a current ACK, on the >>>off chance that it was a valid RST. The ACK is not generated using any >>>state from the RST packet, it is generated entirely from our current >>>connection state. >> >>This is confusing. The current connection state isn't what causes the >>ACK to occur - i.e., it's not a timeout, etc. >> >>The received RST is what causes the ACK. It may be interesting that the >>contents of the ACK are otherwise unrelated to the RST, except for the >>following fields: >> IP src/dst address >> TCP src/dst port numbers >> RST seq number (inside the window, but not at the end) >>That seems like the ACK is directly generated from the RST to me ;-) > > the point that David is trying to make, IMO, is that looking at the > ACK there is no way you can tell that it was caused because of an RST. > It might have been a valid ACK or caused by an out of seq segment, or > an invalid ACK or out of window SYN coming in an ESTAB or other places > that 793 tells you to send an ACK. Certainly; I took the point as relating to the RST/ACK wars issue, though. In that sense, they are directly related. .... >>>If the spontaneous RST generated due to an ABORT is questionable (if >>>data was sent and lost before the ABORT), then the ACK generated by the >>>remote side will cause a new RST to be generated, and it should be >>>acceptable since it takes its values from the ACK packet. >> >>As already discussed, in the meantime new data can arrive at the >>receiver (out of order delivery), in which case it's possible that there >>are as many additional ACKs and RSTs flinged about as there were packets >>in the pipe. At least - more if data is lost. > > > but in this case, the ack/rst rtt will not be more than 2. (there > might be more packets, but no more than 2 loops) Each data ACK, as you observe above, cannot be distinguished from a RST-triggered "here's my end of window" ACK. Which means EVERY ACK will generate a RST. I.e., there could be as many RST/ACKs as there are packets in the pipe. Joe --------------enigBF318E0BCA150C54E52BDCEC 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 iD8DBQFAm+rnE5f5cImnZrsRAmHOAJ9HRXfS/I6wfUtzlgitLAOVAs8psACfS/ik IO/JJDElkPbPIbYXv7ufVeY= =ill6 -----END PGP SIGNATURE----- --------------enigBF318E0BCA150C54E52BDCEC-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri May 7 16:36:27 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19167 for ; Fri, 7 May 2004 16:36: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 1BMByp-0007hf-Lm for tcpm-archive@odin.ietf.org; Fri, 07 May 2004 16:29:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47KTxMK029605 for tcpm-archive@odin.ietf.org; Fri, 7 May 2004 16:29:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMBuK-0006Cg-76 for tcpm-web-archive@optimus.ietf.org; Fri, 07 May 2004 16:25: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 QAA18321 for ; Fri, 7 May 2004 16: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 1BMBuI-0000Tx-Cj for tcpm-web-archive@ietf.org; Fri, 07 May 2004 16:25:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMBtJ-0007mV-00 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 16:24:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMBs8-0007FC-00 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 16:23:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMBmH-0003i1-DF; Fri, 07 May 2004 16: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 1BMBga-0001rs-FB for tcpm@optimus.ietf.org; Fri, 07 May 2004 16:11: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 QAA17541 for ; Fri, 7 May 2004 16:11: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 1BMBgY-00026L-Ou for tcpm@ietf.org; Fri, 07 May 2004 16:11:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMBfT-0001gD-00 for tcpm@ietf.org; Fri, 07 May 2004 16:10:00 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BMBeY-0000rI-00 for tcpm@ietf.org; Fri, 07 May 2004 16:09: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 i47K7aJ15870; Fri, 7 May 2004 13:07:36 -0700 (PDT) Message-ID: <409BEC88.1050105@isi.edu> Date: Fri, 07 May 2004 13:07:36 -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: David Borman CC: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: <20040504161038.52F2577A71D@guns.icir.org> <40984E65.7090204@sun.com> <409BD6F9.60905@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="------------enig953ACE377B64FEE1160AE3EE" 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) --------------enig953ACE377B64FEE1160AE3EE Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit David Borman wrote: > > On May 7, 2004, at 1:35 PM, Joe Touch wrote: > >> David Borman wrote: >> >>> A few thoughts. >>> First, one should not think of this as the RST is getting ACKed. I >>> think of it more as a potentially bogus RST has arrived, so we drop >>> it, but then do a probe of the remote side by sending a current ACK, >>> on the off chance that it was a valid RST. The ACK is not generated >>> using any state from the RST packet, it is generated entirely from >>> our current connection state. >> >> >> This is confusing. The current connection state isn't what causes the >> ACK to occur - i.e., it's not a timeout, etc. >> >> The received RST is what causes the ACK. It may be interesting that >> the contents of the ACK are otherwise unrelated to the RST, except for >> the following fields: >> IP src/dst address >> TCP src/dst port numbers >> RST seq number (inside the window, but not at the end) >> That seems like the ACK is directly generated from the RST to me ;-) > > One can view a RST as an out-of-band mechanism to tell someone to abort > a connection (FIN is the in-band mechanism). If I'm told to abort a > connection, but I don't think the request came from the other side, then > the smart thing to do is to explicitly ask the other side if they really > want to close the connection. The ACK is generated using connection > state, not the information in the RST packet. The fact that the src/dst > addr/port are the same between the connection state and the RST packet > is a red herring; if they weren't the same, the RST would never has been > associated with this connection. What is important is that the > SEG.SEQ SEG.ACK fields are filled in with information from the > connection state, not from any information in the RST packet. The event of the ACK is the reaction to the event of the RST (cause/effect). The contents of the ACK may not be directly related, but the events are, which is why the RST/ACK flurry can ensue. If they were completely decoupled (cause/effect), flurries couldn't occur. ... >> As already discussed, in the meantime new data can arrive at the >> receiver (out of order delivery), in which case it's possible that >> there are as many additional ACKs and RSTs flinged about as there were >> packets in the pipe. At least - more if data is lost. > > Yes, I know, but it is still deterministic. Even with the way things > are today, if you send a bunch of data (that gets reordered along the > way), and then ABORT the connection, the receiver will still be > generating ACKs for all the out-of-order packets, each of which will > cause another RST to be sent back to us. The fact that we can construct > scenarios where there is a flurry of packets while things converge > doesn't bother me a lot, as long as things are deterministic and we > don't get into infinite loops. And the only way I see getting into > infinite loops is by a broken implementation. Agreed - not a loop, but it can persist, during which a large number of RSTs go into the pipe. If any one of them wins, subsequent RSTs can abort further connection attempts - or possibly even kill new connections (consider a case where a RST goes by a long path and the path changes enough that the new short path enables a three-way handshake in the meantime). Maybe that's not critical, but worth considering. >>> Third, I think the conservative approach would be to limit the RST >>> challenge to ESTABLISHED state, since that is the state at which the >>> main problem lies. And while a misbehaving middle should not be >>> ignored, they should not have undue influence on changes to TCP. By >>> their very nature they get in the way of TCP. Any box can get into >>> trouble when another host changes is some manner, causing the box to >>> go down a processing path that it hasn't used before. The broken box >>> needs to be fixed, the rest of the world shouldn't change to >>> accommodate the broken box. >>> Fourth, somthing that I haven't seen yet, RST packets that have the >>> ACK bit set should probably always be ignored in ESTABLISHED and >>> later states. >> >> I thought the RST-ACKs' being mentioned were really just ACKs, not >> RSTs with the ACK bit set. Setting the RST bit overrides the ACK bit >> anyway (it gets processed first), and will kill the other side ;-) > > Which could be a bad thing, because if you get a RST with the ACK bit > set, the only thing you should use to verify the RST is the ack field, > but the RST gets processed first, killing the connection even if the ack > field was bogus. Even the current rules in 793 indicate checking that the segment is inside the window FIRST, before acting on the RST. (I'm not sure how the rest of this paragraph applies in that case). Joe > The SEG.SEQ value should be zero, so if the sequence > number checks are applied even though it isn't valid, then it gets > tossed early. (Another thought is that if you get an RST with the ACK > bit set and SEG.SEQ != 0, that's a bogus RST and should be tossed. In > all instances in 793 where the ACK bit is set when generating a RST, the > SEG.SEQ is explicitly set to zero.) In SYN-SENT state 793 verifies > SEG.ACK before checking the RST bit. In ESTABLISHED and later, SEG.SEQ > is verified first, then the RST bit, then SEG.ACK is verified. But if > both the RST and ACK bits are set, we shouldn't be doing SEG.SEQ checks, > because SEG.SEQ is not valid, and we should be verifying SEG.ACK before > accepting the RST. > > -David Borman --------------enig953ACE377B64FEE1160AE3EE 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 iD8DBQFAm+yIE5f5cImnZrsRAlNwAKCdWRGtzR0FqMJHldkE3ftG5l6gEgCfT+mx l1G6r7vufxx9wnpGl8fIsNA= =KAck -----END PGP SIGNATURE----- --------------enig953ACE377B64FEE1160AE3EE-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri May 7 16:55:24 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20085 for ; Fri, 7 May 2004 16:55: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 1BMCIv-0005Ic-Cn for tcpm-archive@odin.ietf.org; Fri, 07 May 2004 16:50:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47Kojhe020371 for tcpm-archive@odin.ietf.org; Fri, 7 May 2004 16:50:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMCBV-0002pN-E2 for tcpm-web-archive@optimus.ietf.org; Fri, 07 May 2004 16:43: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 QAA19445 for ; Fri, 7 May 2004 16:43: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 1BMCBT-0000cw-Gz for tcpm-web-archive@ietf.org; Fri, 07 May 2004 16:43:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMCAS-00009y-00 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 16:42:00 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMC9R-0007QV-00 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 16:40:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMC4f-0000Mk-8c; Fri, 07 May 2004 16:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMBwz-0007CM-NA for tcpm@optimus.ietf.org; Fri, 07 May 2004 16:28: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 QAA18497 for ; Fri, 7 May 2004 16:28: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 1BMBwx-0001qj-QX for tcpm@ietf.org; Fri, 07 May 2004 16:28:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMBvw-0001PL-00 for tcpm@ietf.org; Fri, 07 May 2004 16:27:01 -0400 Received: from mail1.cray.com ([136.162.0.111]) by ietf-mx with esmtp (Exim 4.12) id 1BMBuz-0000W2-00 for tcpm@ietf.org; Fri, 07 May 2004 16:26:02 -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 i47KPTLl028361; Fri, 7 May 2004 15:25:29 -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 i47KPRsd014812; Fri, 7 May 2004 15:25:28 -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 i47KPRlN086811; Fri, 7 May 2004 15:25:27 -0500 (CDT) In-Reply-To: <409BEC88.1050105@isi.edu> References: <20040504161038.52F2577A71D@guns.icir.org> <40984E65.7090204@sun.com> <409BD6F9.60905@isi.edu> <409BEC88.1050105@isi.edu> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org From: David Borman Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt Date: Fri, 7 May 2004 15:25:14 -0500 To: Joe Touch X-Mailer: Apple Mail (2.613) X-Cray-VirusStatus: clean 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 May 7, 2004, at 3:07 PM, Joe Touch wrote: >>> I thought the RST-ACKs' being mentioned were really just ACKs, not >>> RSTs with the ACK bit set. Setting the RST bit overrides the ACK bit >>> anyway (it gets processed first), and will kill the other side ;-) >> Which could be a bad thing, because if you get a RST with the ACK bit >> set, the only thing you should use to verify the RST is the ack >> field, but the RST gets processed first, killing the connection even >> if the ack field was bogus. > > Even the current rules in 793 indicate checking that the segment is > inside the window FIRST, before acting on the RST. (I'm not sure how > the rest of this paragraph applies in that case). That's checking that SEG.SEQ is inside the window. But if you get a RST packet with the ACK bit set, then SEG.SEQ is invalid (and should always be zero), so you should not be submitting it to the normal in-window SEG.SEQ number checks. RFC 793 does not address this situation. -David Borman _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri May 7 17:42: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 RAA22573 for ; Fri, 7 May 2004 17:42: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 1BMD4L-0002jk-8e for tcpm-archive@odin.ietf.org; Fri, 07 May 2004 17:39:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47Ldjwu010512 for tcpm-archive@odin.ietf.org; Fri, 7 May 2004 17:39:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMCw5-0000FK-5i for tcpm-web-archive@optimus.ietf.org; Fri, 07 May 2004 17:31: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 RAA22060 for ; Fri, 7 May 2004 17: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 1BMCw2-0005uU-Ti for tcpm-web-archive@ietf.org; Fri, 07 May 2004 17:31:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMCv3-0005Ta-00 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 17:30:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMCuH-00053k-00 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 17:29:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMCeo-0003TQ-0G; Fri, 07 May 2004 17:13:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMCb1-00029O-Te for tcpm@optimus.ietf.org; Fri, 07 May 2004 17:09: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 RAA20923 for ; Fri, 7 May 2004 17:09: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 1BMCaz-00048l-N1 for tcpm@ietf.org; Fri, 07 May 2004 17:09:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMCZg-0003GV-00 for tcpm@ietf.org; Fri, 07 May 2004 17:08:05 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BMCWm-00025E-00 for tcpm@ietf.org; Fri, 07 May 2004 17:05: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 i47L41J27313; Fri, 7 May 2004 14:04:01 -0700 (PDT) Message-ID: <409BF9B9.4090903@isi.edu> Date: Fri, 07 May 2004 14:03:53 -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: David Borman CC: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: <20040504161038.52F2577A71D@guns.icir.org> <40984E65.7090204@sun.com> <409BD6F9.60905@isi.edu> <409BEC88.1050105@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="------------enig124718060FA83051B178E214" 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) --------------enig124718060FA83051B178E214 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit David Borman wrote: > > On May 7, 2004, at 3:07 PM, Joe Touch wrote: > >>>> I thought the RST-ACKs' being mentioned were really just ACKs, not >>>> RSTs with the ACK bit set. Setting the RST bit overrides the ACK bit >>>> anyway (it gets processed first), and will kill the other side ;-) >>> >>> Which could be a bad thing, because if you get a RST with the ACK bit >>> set, the only thing you should use to verify the RST is the ack >>> field, but the RST gets processed first, killing the connection even >>> if the ack field was bogus. >> >> >> Even the current rules in 793 indicate checking that the segment is >> inside the window FIRST, before acting on the RST. (I'm not sure how >> the rest of this paragraph applies in that case). > > > That's checking that SEG.SEQ is inside the window. But if you get a RST > packet with the ACK bit set, then SEG.SEQ is invalid (and should always > be zero), so you should not be submitting it to the normal in-window > SEG.SEQ number checks. RFC 793 does not address this situation. > > -David Borman If you're in ESTABLISHED, there's a 4-case window check. (pg 79 rfc793) That happens before any RST or ACK processing. It seems like it's directly addressed, perhaps not in the way you suggest though. Joe --------------enig124718060FA83051B178E214 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 iD8DBQFAm/nBE5f5cImnZrsRAmdYAJ9Xe5MimUZ8bdWGNpLBa6Qg/Rs/5wCg/ayI KQVUUNpc+Hw8Q44fu5AfKFU= =dwvX -----END PGP SIGNATURE----- --------------enig124718060FA83051B178E214-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri May 7 18:07: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 SAA23895 for ; Fri, 7 May 2004 18:07: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 1BMDRK-00037F-7l for tcpm-archive@odin.ietf.org; Fri, 07 May 2004 18:03:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47M3UdZ011975 for tcpm-archive@odin.ietf.org; Fri, 7 May 2004 18:03:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMDKF-0007Uf-W8 for tcpm-web-archive@optimus.ietf.org; Fri, 07 May 2004 17:56: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 RAA23126 for ; Fri, 7 May 2004 17:56: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 1BMDKD-00017Y-Ev for tcpm-web-archive@ietf.org; Fri, 07 May 2004 17:56:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMDJJ-0000hj-00 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 17:55:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMDIa-0000Ho-00 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 17:54:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMDCL-0005Ab-4F; Fri, 07 May 2004 17: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 1BMD7c-0003vH-4d for tcpm@optimus.ietf.org; Fri, 07 May 2004 17:43: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 RAA22598 for ; Fri, 7 May 2004 17:43: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 1BMD7Z-0003IM-K1 for tcpm@ietf.org; Fri, 07 May 2004 17:43:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMD6a-0002rK-00 for tcpm@ietf.org; Fri, 07 May 2004 17:42:04 -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 1BMD5Z-00021q-00 for tcpm@ietf.org; Fri, 07 May 2004 17:41:01 -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 i47LeSSu013609; Fri, 7 May 2004 14:40:29 -0700 (PDT) Received: from cisco.com (rtp-dial-1-19.cisco.com [10.83.97.19]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATV64189; Fri, 7 May 2004 14:40:26 -0700 (PDT) Message-ID: <409C01DF.8030401@cisco.com> Date: Fri, 07 May 2004 17:38:39 -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: Paul Goyette CC: Mitesh Dalal , 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.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul: Then I must be reading something wrong :-0 I thought you meant that if I receive a RST(SEQ=X) then I would do the first time: send-ack(challege) store X in Last_RST_At The next time I receive a reset in window I would do if(Last_RST_At != Seq) { send-ack(challeng) store X in Last_RST_At } So you end up with one mark within the valid rcv-window that is "ignore this and send no challege"... So if A real guy happens to send a RST().. you would challenge as long as by chance the guy did not pick that 1 in your window value... R Paul Goyette wrote: >you read it right. > >But the effect of this is no different than if the RST gets lost. > >If an attacker sends us the RST, then the real peer tries to reset, >we would ignore the real peer, and things would just have to time >out. > >-----Original Message----- >From: Mitesh Dalal [mailto:mdalal@cisco.com] >Sent: Friday, May 07, 2004 9:45 AM >To: Randall Stewart (cisco) >Cc: Paul Goyette; tcpm@ietf.org >Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt > > >On Thu, 6 May 2004, Randall Stewart (cisco) wrote: > > > >>Paul Goyette wrote: >> >> >> >>>Clarifying my own post from yesterday: >>> >>> >>> >>> >>> >>>>Perhaps "Don't send repeated challenges with the same ACK value" would >>>>be adequate? Then you only need to keep track of one new state value, >>>>the last value sent in a challenge ACK. This should eliminate the ACK >>>>war scenario. >>>> >>>> >>>> >>>> >>>At least one person took this to mean that I was suggesting we select a >>>_new_ ACK value for repeated RST segments. That's not what I meant. >>> >>>The intent of this is "If the value in the challenge ACK would be the >>>same as the value sent in the previous challenge ACK, don't send any >>>ACK at all." >>> >>> >>> >>> >>Hmm.. that would surely prevent any ACK war from >>occuring... >> >> >> > >this might not work. For a long lived connection, your rcv.nxt wouldnt >budge much in between data transfers. So if an attacker sends you 1 >RST in window, it would effectively shut you down from sending any >more challenges as long we are at the same rcv.nxt ? Did I read this >correctly ? > > >thanks >Mitesh > > > >_______________________________________________ >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 May 7 18:09: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 SAA24149 for ; Fri, 7 May 2004 18:09:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMDS8-0003WV-2q for tcpm-archive@odin.ietf.org; Fri, 07 May 2004 18:04:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47M4Kfi013538 for tcpm-archive@odin.ietf.org; Fri, 7 May 2004 18:04:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMDLD-0007mU-QO for tcpm-web-archive@optimus.ietf.org; Fri, 07 May 2004 17:57: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 RAA23173 for ; Fri, 7 May 2004 17: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 1BMDLB-0001Xs-8F for tcpm-web-archive@ietf.org; Fri, 07 May 2004 17:57:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMDKD-00017d-00 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 17:56:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMDJg-0000hx-00 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 17:55:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMDCL-0005Aj-CT; Fri, 07 May 2004 17: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 1BMD7d-0003vJ-DX for tcpm@optimus.ietf.org; Fri, 07 May 2004 17:43: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 RAA22601 for ; Fri, 7 May 2004 17:43: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 1BMD7a-0003IW-UD for tcpm@ietf.org; Fri, 07 May 2004 17:43:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMD6e-0002ro-00 for tcpm@ietf.org; Fri, 07 May 2004 17:42:09 -0400 Received: from mail1.cray.com ([136.162.0.111]) by ietf-mx with esmtp (Exim 4.12) id 1BMD5o-00021t-00 for tcpm@ietf.org; Fri, 07 May 2004 17:41:16 -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 i47LeeLl029817; Fri, 7 May 2004 16:40:41 -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 i47LedX9017989; Fri, 7 May 2004 16:40:39 -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 i47LeYlN087198; Fri, 7 May 2004 16:40:34 -0500 (CDT) In-Reply-To: <409BF9B9.4090903@isi.edu> References: <20040504161038.52F2577A71D@guns.icir.org> <40984E65.7090204@sun.com> <409BD6F9.60905@isi.edu> <409BEC88.1050105@isi.edu> <409BF9B9.4090903@isi.edu> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <23EA427A-A06F-11D8-A68B-000A95D7D4C0@cray.com> Content-Transfer-Encoding: 7bit Cc: Joe Touch From: David Borman Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt Date: Fri, 7 May 2004 16:40:21 -0500 To: tcpm@ietf.org X-Mailer: Apple Mail (2.613) X-Cray-VirusStatus: clean 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 May 7, 2004, at 4:03 PM, Joe Touch wrote: > David Borman wrote: >> On May 7, 2004, at 3:07 PM, Joe Touch wrote: ... >>> Even the current rules in 793 indicate checking that the segment is >>> inside the window FIRST, before acting on the RST. (I'm not sure >>> how the rest of this paragraph applies in that case). >> That's checking that SEG.SEQ is inside the window. But if you get a >> RST packet with the ACK bit set, then SEG.SEQ is invalid (and should >> always be zero), so you should not be submitting it to the normal >> in-window SEG.SEQ number checks. RFC 793 does not address this >> situation. >> -David Borman > > If you're in ESTABLISHED, there's a 4-case window check. (pg 79 > rfc793) That happens before any RST or ACK processing. It seems like > it's directly addressed, perhaps not in the way you suggest though. No. That 4-case window check is all about verifying SEG.SEQ, and in the case of a RST with the ACK bit set, SEG.SEQ is invalid. It doesn't make sense to check something that is by definition invalid. -David Borman _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri May 7 18:11: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 SAA24452 for ; Fri, 7 May 2004 18:11: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 1BMDSz-0003w0-6z for tcpm-archive@odin.ietf.org; Fri, 07 May 2004 18:05:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47M5Dug015120 for tcpm-archive@odin.ietf.org; Fri, 7 May 2004 18:05:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMDQ6-000244-Nj for tcpm-web-archive@optimus.ietf.org; Fri, 07 May 2004 18:02: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 SAA23353 for ; Fri, 7 May 2004 18:02: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 1BMDQ4-0003fE-3r for tcpm-web-archive@ietf.org; Fri, 07 May 2004 18:02:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMDP5-0003FX-00 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 18:01:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMDOY-0002pl-00 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 18:00:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMDK5-0007Tf-Ku; Fri, 07 May 2004 17:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMDCQ-0005B5-RS for tcpm@optimus.ietf.org; Fri, 07 May 2004 17: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 RAA22753 for ; Fri, 7 May 2004 17:48: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 1BMDCO-0005PL-86 for tcpm@ietf.org; Fri, 07 May 2004 17:48:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMDBS-0004yo-00 for tcpm@ietf.org; Fri, 07 May 2004 17:47:07 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BMDAU-00049w-00 for tcpm@ietf.org; Fri, 07 May 2004 17:46:06 -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 i47Lj9J06132; Fri, 7 May 2004 14:45:09 -0700 (PDT) Message-ID: <409C0364.90403@isi.edu> Date: Fri, 07 May 2004 14:45:08 -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: David Borman CC: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: <20040504161038.52F2577A71D@guns.icir.org> <40984E65.7090204@sun.com> <409BD6F9.60905@isi.edu> <409BEC88.1050105@isi.edu> <409BF9B9.4090903@isi.edu> <23EA427A-A06F-11D8-A68B-000A95D7D4C0@cray.com> In-Reply-To: <23EA427A-A06F-11D8-A68B-000A95D7D4C0@cray.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="------------enig0AC9B69E4ACCA62BD0F14D2E" 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) --------------enig0AC9B69E4ACCA62BD0F14D2E Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit David Borman wrote: > > On May 7, 2004, at 4:03 PM, Joe Touch wrote: > >> David Borman wrote: >> >>> On May 7, 2004, at 3:07 PM, Joe Touch wrote: > > ... > >>>> Even the current rules in 793 indicate checking that the segment is >>>> inside the window FIRST, before acting on the RST. (I'm not sure >>>> how the rest of this paragraph applies in that case). >>> >>> That's checking that SEG.SEQ is inside the window. But if you get a >>> RST packet with the ACK bit set, then SEG.SEQ is invalid (and should >>> always be zero), so you should not be submitting it to the normal >>> in-window SEG.SEQ number checks. RFC 793 does not address this >>> situation. >>> -David Borman >> >> >> If you're in ESTABLISHED, there's a 4-case window check. (pg 79 >> rfc793) That happens before any RST or ACK processing. It seems like >> it's directly addressed, perhaps not in the way you suggest though. > > > No. That 4-case window check is all about verifying SEG.SEQ, and in the > case of a RST with the ACK bit set, SEG.SEQ is invalid. It doesn't make > sense to check something that is by definition invalid. > > -David Borman I agree, but it seems that RFC793 is fairly clear on doing the check anyway, isn't it? Joe --------------enig0AC9B69E4ACCA62BD0F14D2E 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 iD8DBQFAnANkE5f5cImnZrsRAqDRAKCYiGmfjhd0PruTg5N9c0/AouGmgQCfYOoM sM0ykn+CbvHm6p5LGVT/BKU= =zv8A -----END PGP SIGNATURE----- --------------enig0AC9B69E4ACCA62BD0F14D2E-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri May 7 18:29:08 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 SAA25506 for ; Fri, 7 May 2004 18:29: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 1BMDkL-0004iY-Pi for tcpm-archive@odin.ietf.org; Fri, 07 May 2004 18:23:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47MN9CW018127 for tcpm-archive@odin.ietf.org; Fri, 7 May 2004 18:23:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMDeh-0002U9-72 for tcpm-web-archive@optimus.ietf.org; Fri, 07 May 2004 18:17: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 SAA24946 for ; Fri, 7 May 2004 18:17: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 1BMDee-0002MV-5Y for tcpm-web-archive@ietf.org; Fri, 07 May 2004 18:17:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMDda-0001vx-00 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 18:16:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMDcb-0001Uy-00 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 18:15:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMDZb-000811-Op; Fri, 07 May 2004 18:12:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMDX4-0006Ez-Sq for tcpm@optimus.ietf.org; Fri, 07 May 2004 18:09: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 SAA24152 for ; Fri, 7 May 2004 18:09: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 1BMDX1-0006jW-SB for tcpm@ietf.org; Fri, 07 May 2004 18:09:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMDW7-0006I6-00 for tcpm@ietf.org; Fri, 07 May 2004 18:08:27 -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 1BMDVL-0005p4-00 for tcpm@ietf.org; Fri, 07 May 2004 18:07:40 -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-5) with ESMTP id i47M9YHS014332; Sat, 8 May 2004 01:09:34 +0300 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.11/8.12.11/Debian-5) id i47M9VNh014331; Sat, 8 May 2004 01:09:31 +0300 Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt From: Mika Liljeberg To: David Borman Cc: Joe Touch , tcpm@ietf.org In-Reply-To: References: <20040504161038.52F2577A71D@guns.icir.org> <40984E65.7090204@sun.com> <409BD6F9.60905@isi.edu> <409BEC88.1050105@isi.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1083967771.10143.8.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sat, 08 May 2004 01:09:31 +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-05-07 at 23:25, David Borman wrote: > That's checking that SEG.SEQ is inside the window. But if you get a > RST packet with the ACK bit set, then SEG.SEQ is invalid (and should > always be zero), so you should not be submitting it to the normal > in-window SEG.SEQ number checks. RFC 793 does not address this > situation. That's not entirely accurate. The reset generation rules in RFC 793 leave ack undefined for an RST generated in synchronised state in response to a segment with the ACK bit set: If the incoming segment has an ACK field, the reset takes its sequence number from the ACK field of the segment, otherwise the reset has sequence number zero and the ACK field is set to the sum of the sequence number and segment length of the incoming segment. The connection remains in the same state. Therefore an RST sent in synchronised state may or may not have the ACK bit set. The reset validation rules are consistent with this. Only the sequence number is checked, the ack is not. MikaL _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri May 7 23:18:36 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07258 for ; Fri, 7 May 2004 23:18: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 1BMIL8-00061C-8w for tcpm-archive@odin.ietf.org; Fri, 07 May 2004 23:17:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i483HQRQ023134 for tcpm-archive@odin.ietf.org; Fri, 7 May 2004 23:17:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMII4-0005Ks-Uc for tcpm-web-archive@optimus.ietf.org; Fri, 07 May 2004 23: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 XAA06990 for ; Fri, 7 May 2004 23:14: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 1BMII2-0003ze-7l for tcpm-web-archive@ietf.org; Fri, 07 May 2004 23:14:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMIGT-0003ML-00 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 23:12:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMIEV-0002oT-00 for tcpm-web-archive@ietf.org; Fri, 07 May 2004 23:10:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMIC1-0004Cv-0m; Fri, 07 May 2004 23:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMI8w-00032j-Cb for tcpm@optimus.ietf.org; Fri, 07 May 2004 23:04: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 XAA06625 for ; Fri, 7 May 2004 23: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 1BMI8q-0000iz-1D for tcpm@ietf.org; Fri, 07 May 2004 23:04:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMI7W-0000Ja-00 for tcpm@ietf.org; Fri, 07 May 2004 23:03:22 -0400 Received: from frantic-dmz.weston.borman.com ([206.196.54.22] helo=frantic.weston.borman.com) by ietf-mx with esmtp (Exim 4.12) id 1BMI6k-0007H9-00 for tcpm@ietf.org; Fri, 07 May 2004 23:02:34 -0400 Received: from [206.196.45.45] (weston-45.weston.borman.com [206.196.45.45]) by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id i4832Fha026656; Fri, 7 May 2004 22:02:15 -0500 (CDT) In-Reply-To: <409C0364.90403@isi.edu> References: <20040504161038.52F2577A71D@guns.icir.org> <40984E65.7090204@sun.com> <409BD6F9.60905@isi.edu> <409BEC88.1050105@isi.edu> <409BF9B9.4090903@isi.edu> <23EA427A-A06F-11D8-A68B-000A95D7D4C0@cray.com> <409C0364.90403@isi.edu> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Joe Touch From: David Borman Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt Date: Fri, 7 May 2004 22:00:44 -0500 To: tcpm@ietf.org X-Mailer: Apple Mail (2.613) 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 May 7, 2004, at 4:45 PM, Joe Touch wrote: > David Borman wrote: > >> On May 7, 2004, at 4:03 PM, Joe Touch wrote: >>>> If you're in ESTABLISHED, there's a 4-case window check. (pg 79 >>>> rfc793) That happens before any RST or ACK processing. It seems >>>> like it's directly addressed, perhaps not in the way you suggest >>>> though. >> No. That 4-case window check is all about verifying SEG.SEQ, and in >> the case of a RST with the ACK bit set, SEG.SEQ is invalid. It >> doesn't make sense to check something that is by definition invalid. >> -David Borman > > I agree, but it seems that RFC793 is fairly clear on doing the check > anyway, isn't it? Sure its clear, but that doesn't make it right. RFC 793 is not perfect, RFC 1122 is proof of that. -David Borman _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Sun May 9 23:47: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 XAA07129 for ; Sun, 9 May 2004 23:47: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 1BN1gJ-0003od-Vv for tcpm-archive@odin.ietf.org; Sun, 09 May 2004 23:42:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4A3gJPd014663 for tcpm-archive@odin.ietf.org; Sun, 9 May 2004 23:42:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN1Yc-0002QV-1G for tcpm-web-archive@optimus.ietf.org; Sun, 09 May 2004 23:34: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 XAA06511 for ; Sun, 9 May 2004 23:34: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 1BN1Ya-00061S-2p for tcpm-web-archive@ietf.org; Sun, 09 May 2004 23:34:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BN1Xa-0005kA-00 for tcpm-web-archive@ietf.org; Sun, 09 May 2004 23:33:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BN1X2-0005TI-00 for tcpm-web-archive@ietf.org; Sun, 09 May 2004 23:32:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN1Pa-0001O4-LZ; Sun, 09 May 2004 23: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 1BN1Lx-0000oD-6a for tcpm@optimus.ietf.org; Sun, 09 May 2004 23:21: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 XAA06064 for ; Sun, 9 May 2004 23:21: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 1BN1Lv-0002J0-AB for tcpm@ietf.org; Sun, 09 May 2004 23:21:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BN1Kz-00021u-00 for tcpm@ietf.org; Sun, 09 May 2004 23:20:17 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx with esmtp (Exim 4.12) id 1BN1K5-0001kQ-00 for tcpm@ietf.org; Sun, 09 May 2004 23:19:21 -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 i4A3JLhw071112 for ; Sun, 9 May 2004 20:19:21 -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 12A6677AC73 for ; Sun, 9 May 2004 23:19:19 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 4DA7B14A481 for ; Sat, 8 May 2004 09:46:29 -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: Eight Days a Week MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sat, 08 May 2004 09:46:29 -0400 Message-Id: <20040508134629.4DA7B14A481@lawyers.icir.org> Subject: [tcpm] new rev of f-rto 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 fyi, Title : F-RTO: An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and SCTP Author(s) : P. Sarolahti, M. Kojo Filename : draft-ietf-tcpm-frto-00.txt Pages : 22 Date : 2004-5-5 http://www.ietf.org/internet-drafts/draft-ietf-tcpm-frto-00.txt --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin) iD8DBQFAnOS1WyrrWs4yIs4RAgyhAJ44ezwbnyBQCw5+u5S7kGCW7/4dJgCffrT0 OXf38RsnYlVuNo4Zjizu9aU= =3WZC -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon May 10 10:57:51 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09311 for ; Mon, 10 May 2004 10:57: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 1BNC6S-0004rS-Lf for tcpm-archive@odin.ietf.org; Mon, 10 May 2004 10:50:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4AEo0Lt018672 for tcpm-archive@odin.ietf.org; Mon, 10 May 2004 10:50:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNByf-0004AF-UJ for tcpm-web-archive@optimus.ietf.org; Mon, 10 May 2004 10:41: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 KAA08721 for ; Mon, 10 May 2004 10:41: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 1BNByd-0003fS-K9 for tcpm-web-archive@ietf.org; Mon, 10 May 2004 10:41:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNBxh-0003Kz-00 for tcpm-web-archive@ietf.org; Mon, 10 May 2004 10:40:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNBxI-00030h-00 for tcpm-web-archive@ietf.org; Mon, 10 May 2004 10: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 1BNBmB-00026Q-In; Mon, 10 May 2004 10:29:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNBj3-00018T-2Z for tcpm@optimus.ietf.org; Mon, 10 May 2004 10:25: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 KAA07635 for ; Mon, 10 May 2004 10:25: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 1BNBj0-0005wF-JA for tcpm@ietf.org; Mon, 10 May 2004 10:25:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNBi3-0005bQ-00 for tcpm@ietf.org; Mon, 10 May 2004 10:24:47 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx with esmtp (Exim 4.12) id 1BNBh9-0005FW-00 for tcpm@ietf.org; Mon, 10 May 2004 10:23: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 i4AENchw078476; Mon, 10 May 2004 07:23:38 -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 C24DC77AC74; Mon, 10 May 2004 10:23:37 -0400 (EDT) To: Joe Touch From: Mark Allman Reply-To: mallman@icir.org Cc: Mitesh Dalal , Yogesh.Swami@nokia.com, huitema@windows.microsoft.com, tcpm@ietf.org Subject: Re: [tcpm] new internet draft - drafft-touch-anonsec In-Reply-To: <409B0BA2.2080503@isi.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Can't Get Enough MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 10 May 2004 10:23:37 -0400 Message-Id: <20040510142337.C24DC77AC74@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 > > If TCP is such a thou-shall-touch-not technology, then it would seem > > so much ironical that we should have a WG called tcpm whose charter > > is to suggest changes :) > > Having the TCPM WG is not - IMO - carte blanche to change TCP. Absolutely agree, FWIW. allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAn5BpWyrrWs4yIs4RArUnAKCUpAACFyxyM4ZeA72Tx3kpro7rdgCbBSlK H9vcvwGxEV1kJyfDzj0WI8o= =41R8 -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon May 10 11:55: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 LAA12519 for ; Mon, 10 May 2004 11:55: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 1BNCzI-0008Ga-QM for tcpm-archive@odin.ietf.org; Mon, 10 May 2004 11:46:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4AFkeTJ031772 for tcpm-archive@odin.ietf.org; Mon, 10 May 2004 11:46:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNCiK-0004dJ-Ed for tcpm-web-archive@optimus.ietf.org; Mon, 10 May 2004 11:29: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 LAA11223 for ; Mon, 10 May 2004 11:29: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 1BNCiJ-0004Ij-H5 for tcpm-web-archive@ietf.org; Mon, 10 May 2004 11:29:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNChC-0003vq-00 for tcpm-web-archive@ietf.org; Mon, 10 May 2004 11:27:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNCgb-0003bV-00 for tcpm-web-archive@ietf.org; Mon, 10 May 2004 11:27:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNCXZ-00020Z-BC; Mon, 10 May 2004 11:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNCNm-0008R1-Sd for tcpm@optimus.ietf.org; Mon, 10 May 2004 11:07: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 LAA09968 for ; Mon, 10 May 2004 11:07: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 1BNCNk-0004kg-AK for tcpm@ietf.org; Mon, 10 May 2004 11:07:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNCMm-0004QF-00 for tcpm@ietf.org; Mon, 10 May 2004 11:06:53 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx with esmtp (Exim 4.12) id 1BNCLw-00046V-00 for tcpm@ietf.org; Mon, 10 May 2004 11:06:00 -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 i4AF5xhw079042; Mon, 10 May 2004 08:05:59 -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 C522477AC74; Mon, 10 May 2004 11:05:58 -0400 (EDT) To: "Christian Huitema" From: Mark Allman Reply-To: mallman@icir.org Cc: "Joe Touch" , tcpm@ietf.org Subject: Re: [tcpm] new internet draft - drafft-touch-anonsec In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Can't Get Enough MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 10 May 2004 11:05:58 -0400 Message-Id: <20040510150558.C522477AC74@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 (catching up) > In the interest of clarity, you should mention the limits of > applicability of this MD5 option, and you should mention the obvious > alternative, use SSL or TLS. I don't follow why an obvious alternative to MD5 is SSL/TLS. SSL/TLS won't allow bogus data to be inserted into the stream, but does nothing about the ability of an attacker to rip down a connection (ala the MD5 option). Right? (And, FWIW, while the MD5 option is heavily cased in terms of BGP, I agree with Joe (? I think - I have lost track) that there is nothing that fundementally makes MD5 worthless for other traffic.) allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAn5pWWyrrWs4yIs4RAm9fAKCXW8+EQr0+TYLeDRAl0Do2rKaUFACfV4l3 B/zRIJVN1YAq9A7hulk8x/8= =Nhz5 -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon May 10 14:56:44 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 OAA24448 for ; Mon, 10 May 2004 14:56: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 1BNFq9-0001MK-KQ for tcpm-archive@odin.ietf.org; Mon, 10 May 2004 14:49:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4AInPE6005219 for tcpm-archive@odin.ietf.org; Mon, 10 May 2004 14:49:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNFk3-0000ak-5U for tcpm-web-archive@optimus.ietf.org; Mon, 10 May 2004 14: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 OAA23536 for ; Mon, 10 May 2004 14: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 1BNFk0-0001is-Jn for tcpm-web-archive@ietf.org; Mon, 10 May 2004 14:43:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNFj4-0001NL-00 for tcpm-web-archive@ietf.org; Mon, 10 May 2004 14:42:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNFiC-00011L-00 for tcpm-web-archive@ietf.org; Mon, 10 May 2004 14:41:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNFUd-0005XO-HN; Mon, 10 May 2004 14:27:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNFRt-0004lg-Af for tcpm@optimus.ietf.org; Mon, 10 May 2004 14: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 OAA21847 for ; Mon, 10 May 2004 14:24: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 1BNFRq-0002Yg-Gt for tcpm@ietf.org; Mon, 10 May 2004 14:24:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNFQj-0002BG-00 for tcpm@ietf.org; Mon, 10 May 2004 14:23:10 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BNFPz-0001k8-00 for tcpm@ietf.org; Mon, 10 May 2004 14:22:23 -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 i4AIKeJ20872; Mon, 10 May 2004 11:20:40 -0700 (PDT) Message-ID: <409FC7FA.8040100@isi.edu> Date: Mon, 10 May 2004 11:20:42 -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: David Borman CC: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt References: <20040504161038.52F2577A71D@guns.icir.org> <40984E65.7090204@sun.com> <409BD6F9.60905@isi.edu> <409BEC88.1050105@isi.edu> <409BF9B9.4090903@isi.edu> <23EA427A-A06F-11D8-A68B-000A95D7D4C0@cray.com> <409C0364.90403@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="------------enig45AB4C5EF6B9FDFD4779E410" 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) --------------enig45AB4C5EF6B9FDFD4779E410 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit David Borman wrote: > > On May 7, 2004, at 4:45 PM, Joe Touch wrote: > >> David Borman wrote: >> >>> On May 7, 2004, at 4:03 PM, Joe Touch wrote: >>> >>>>> If you're in ESTABLISHED, there's a 4-case window check. (pg 79 >>>>> rfc793) That happens before any RST or ACK processing. It seems >>>>> like it's directly addressed, perhaps not in the way you suggest >>>>> though. >>> >>> No. That 4-case window check is all about verifying SEG.SEQ, and in >>> the case of a RST with the ACK bit set, SEG.SEQ is invalid. It >>> doesn't make sense to check something that is by definition invalid. >>> -David Borman >> >> >> I agree, but it seems that RFC793 is fairly clear on doing the check >> anyway, isn't it? > > > Sure its clear, but that doesn't make it right. RFC 793 is not perfect, > RFC 1122 is proof of that. > > -David Borman Certainly; I didn't catch whether you were talking about what 793 said or should say. FWIW, Ian Heavens had a small group in 1997 that was looking into various mods to RSTs, which included adding 'types' and possibly ACKs. He also had a draft that looked at the probabilty of a number of kinds of RST attacks and failures in a 1997 I-D. ;-) Perhaps it's worth revisiting this sort of "RST Taxonomy", including proposed mods (to discuss them, rather than recommend any)? Joe --------------enig45AB4C5EF6B9FDFD4779E410 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 iD8DBQFAn8f6E5f5cImnZrsRArXuAJ9+V/gXuuJj645JEdBJawbRhK/5mQCeIYeS fu1SZpg4o8HXr/amILGYqZ8= =Zuqx -----END PGP SIGNATURE----- --------------enig45AB4C5EF6B9FDFD4779E410-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon May 10 22:56: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 WAA26290 for ; Mon, 10 May 2004 22:56: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 1BNNJ6-00079t-Af for tcpm-archive@odin.ietf.org; Mon, 10 May 2004 22:47:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4B2lm09027517 for tcpm-archive@odin.ietf.org; Mon, 10 May 2004 22:47:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNNDr-0006E4-Ed for tcpm-web-archive@optimus.ietf.org; Mon, 10 May 2004 22:42: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 WAA25698 for ; Mon, 10 May 2004 22:42: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 1BNNDo-0006Ow-0e for tcpm-web-archive@ietf.org; Mon, 10 May 2004 22:42:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNNCz-000616-00 for tcpm-web-archive@ietf.org; Mon, 10 May 2004 22:41:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNNBm-0005L6-00 for tcpm-web-archive@ietf.org; Mon, 10 May 2004 22:40:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNN4u-0004Ar-4y; Mon, 10 May 2004 22:33:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNN0P-0002ls-3G for tcpm@optimus.ietf.org; Mon, 10 May 2004 22:28: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 WAA24448 for ; Mon, 10 May 2004 22:28: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 1BNN0L-00010x-RL for tcpm@ietf.org; Mon, 10 May 2004 22:28:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNMzI-0000fq-00 for tcpm@ietf.org; Mon, 10 May 2004 22:27:21 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx with esmtp (Exim 4.12) id 1BNMyO-0000LA-00 for tcpm@ietf.org; Mon, 10 May 2004 22:26:24 -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 i4B2QOhw089079; Mon, 10 May 2004 19:26:25 -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 B8DD877AC74; Mon, 10 May 2004 22:26:22 -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: Can't Get Enough MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 10 May 2004 22:26:22 -0400 Message-Id: <20040511022622.B8DD877AC74@guns.icir.org> Subject: [tcpm] tcpsecure i-d IPR disclosure 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 Hi folks! Just a quick note to let everyone know that Cisco has filed an IPR disclosure with the IETF that claims ``one or more pending patent applications relating to the subject matter of "Transmission Control Protocol security considerations" ''. The disclosure can be retreived from: http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-tcpm-tcpsecure.txt A couple of notes ... * The disclosure was received soon after the tcpsecure i-d was published. (Which is when the WG Chairs & ADs found out about the patent applications.) Note that publishing an IPR disclosure after publishing an ID is OK according to the new IETF IPR guidelines. * Ted and I have engaged in discussions on this topic with the ADs (Allison and Jon) and Scott Bradner. The discussions have not yet led to any recommended course of action, but our discussions are ongoing about how to proceed. * Please wait to discuss the effects of the IPR claims on the draft until we've clarified what claims are in place. Thanks! Mark & Ted --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAoDnOWyrrWs4yIs4RAj14AKCDrlnkSQidgR591C0tKZaoZkOYlQCdFXBy satYeeEuAGMKCMRgBflGQAw= =bZ0v -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed May 12 15:59: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 PAA07498 for ; Wed, 12 May 2004 15:59: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 1BNzmd-00080r-8i for tcpm-archive@odin.ietf.org; Wed, 12 May 2004 15:52:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CJqpe4030801 for tcpm-archive@odin.ietf.org; Wed, 12 May 2004 15:52:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNzil-0006dJ-35 for tcpm-web-archive@optimus.ietf.org; Wed, 12 May 2004 15:48: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 PAA06765 for ; Wed, 12 May 2004 15:48: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 1BNzij-0004dA-Lr for tcpm-web-archive@ietf.org; Wed, 12 May 2004 15:48:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNzhh-00044W-00 for tcpm-web-archive@ietf.org; Wed, 12 May 2004 15:47:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNzgR-0003AP-00 for tcpm-web-archive@ietf.org; Wed, 12 May 2004 15:46:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNzYf-0003pw-4P; Wed, 12 May 2004 15:38:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNzQp-0000VV-Ly for tcpm@optimus.ietf.org; Wed, 12 May 2004 15: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 OAA02244 for ; Wed, 12 May 2004 14:43: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 1BNyhd-0002bj-Li for tcpm@ietf.org; Wed, 12 May 2004 14:43:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNyge-000273-00 for tcpm@ietf.org; Wed, 12 May 2004 14:42:37 -0400 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx with esmtp (Exim 4.12) id 1BNyfg-000199-00 for tcpm@ietf.org; Wed, 12 May 2004 14:41:36 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 543C23816C; Wed, 12 May 2004 20:41:05 +0200 (CEST) Received: from acorde.it.uc3m.es (acorde.it.uc3m.es [163.117.139.72]) by smtp01.uc3m.es (Postfix) with ESMTP id 3EB9638169; Wed, 12 May 2004 20:41:05 +0200 (CEST) Subject: Re: [tcpm] security draft input request From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: mallman@icir.org Cc: tcpm@ietf.org In-Reply-To: <20040430131701.9B74E1447D3@lawyers.icir.org> References: <20040430131701.9B74E1447D3@lawyers.icir.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-gwhvg0kvfEYwBI1xUzvX" Organization: Universidad Carlos III de Madrid Message-Id: <1084387264.1795.106.camel@acorde> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 12 May 2004 20:41:04 +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=AWL autolearn=no version=2.60 --=-gwhvg0kvfEYwBI1xUzvX Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Hi all, We're in favour of Option #3. We've just put into a draft some input (there were also some discussion about that on the list few time ago) about another problem similar (already well known) to the ones described in the draft, as well as some proposed changes to TCP in order to mitigate the threats. http://www.ietf.org/internet-drafts/draft-azcorra-tcpm-tcp-blind-ack-dos-00= .txt As always, comments are welcome. Kind regards, Carlos J. El vie, 30-04-2004 a las 15:16, Mark Allman escribi=F3: > Option #3: >=20 > 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). > Thanks! >=20 > Mark & Ted --=20 Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/ GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 --=-gwhvg0kvfEYwBI1xUzvX 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) iD8DBQBAom/A5vKyPtrWqkARAhDEAKDkWjXnSmz2c7VGwE3TmiUFD683UwCgkfQS bisNxM70vyb+tTH3v80Shw8= =XfTT -----END PGP SIGNATURE----- --=-gwhvg0kvfEYwBI1xUzvX-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed May 12 16:33: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 QAA09463 for ; Wed, 12 May 2004 16:33: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 1BO0Kt-0000C6-5I for tcpm-archive@odin.ietf.org; Wed, 12 May 2004 16:28:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CKSFWY000746 for tcpm-archive@odin.ietf.org; Wed, 12 May 2004 16:28:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO028-0003sa-Sa for tcpm-web-archive@optimus.ietf.org; Wed, 12 May 2004 16:08: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 QAA08082 for ; Wed, 12 May 2004 16:08: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 1BO027-0007Pv-8m for tcpm-web-archive@ietf.org; Wed, 12 May 2004 16:08:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO01E-0006uY-00 for tcpm-web-archive@ietf.org; Wed, 12 May 2004 16:07:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BO00c-0006PQ-00 for tcpm-web-archive@ietf.org; Wed, 12 May 2004 16:07:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNzwT-0002YM-AW; Wed, 12 May 2004 16:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNzn7-0008D3-SW for tcpm@optimus.ietf.org; Wed, 12 May 2004 15:53: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 PAA07050 for ; Wed, 12 May 2004 15:53: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 1BNzn6-0006lr-Bk for tcpm@ietf.org; Wed, 12 May 2004 15:53:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNzm1-0006Cg-00 for tcpm@ietf.org; Wed, 12 May 2004 15:52:14 -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 1BNzl8-0005Au-00 for tcpm@ietf.org; Wed, 12 May 2004 15:51:18 -0400 Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1BNzkW-0001nV-00; Wed, 12 May 2004 15:50:40 -0400 From: Tim Shepard To: mallman@icir.org cc: tcpm@ietf.org, "Ted Faber" Subject: draft-ietf-tcpm-tcpsecure-00.txt (was Re: [tcpm] tcpsecure i-d IPR disclosure ) In-reply-to: Your message of Mon, 10 May 2004 22:26:22 -0400. <20040511022622.B8DD877AC74@guns.icir.org> Date: Wed, 12 May 2004 15:50:40 -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 > * Please wait to discuss the effects of the IPR claims on the > draft until we've clarified what claims are in place. > > Thanks! You've asked us to wait, but can you give us any hint as to how long it will be until you have "clarified what claims are in place"? Given how this draft is being called a "CISCO/IETF recommendation" in the press accounts I've seen recently, I believe it was a mistake to take this draft in the form that it is in as a working group item without consulting the consensus of the working group. Nothing was achieved by placing the draft on the WG's agenda in secret before public disclosure. There would have been no harm in waiting until the next IETF meeting. I just re-read draft-ietf-tcpm-tcpsecure-00.txt and almost none of it belongs in a draft that is a working group item of TCPM. I believe that there is indeed a problem, and there is a possibility that it would be appropriate to address the problem in TCPM, but draft-ietf-tcpm-tcpsecure-00.txt fails even to explain well the nature of the problem, and as has been discussed previously on this mailing list, there are potential interoperability problems that make the "solutions" in the draft inadvisable in general situations. Perhaps some better-written or better-thought-through draft addressing this issue might belong on this working group's agenda, but not draft-ietf-tcpm-tcpsecure-00.txt . Perhaps the best solution lies outside the scope of TCPM (e.g. perhaps one should not make visible the port numbers used to carry critical long-lived TCP connections). Note that TCP as it is used in most cases does not suffer from the vulnerabilities -Tim Shepard shep@alum.mit.edu _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon May 17 13:33:42 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07251 for ; Mon, 17 May 2004 13:33: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 1BPloA-00068I-Kp for tcpm-archive@odin.ietf.org; Mon, 17 May 2004 13:21:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HHLkgX023574 for tcpm-archive@odin.ietf.org; Mon, 17 May 2004 13:21:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPlbC-0004Tr-12 for tcpm-web-archive@optimus.ietf.org; Mon, 17 May 2004 13:08: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 NAA05769 for ; Mon, 17 May 2004 13:08: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 1BPlbA-0004Zj-86 for tcpm-web-archive@ietf.org; Mon, 17 May 2004 13:08:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPla2-0004Dw-00 for tcpm-web-archive@ietf.org; Mon, 17 May 2004 13:07:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPlZ7-0003sV-00 for tcpm-web-archive@ietf.org; Mon, 17 May 2004 13:06:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPlKT-0001nm-Gw; Mon, 17 May 2004 12: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 1BPlAv-0000FQ-5m for tcpm@optimus.ietf.org; Mon, 17 May 2004 12:41: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 MAA03994 for ; Mon, 17 May 2004 12: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 1BPlAt-0002y5-Ja for tcpm@ietf.org; Mon, 17 May 2004 12:41:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPlA6-0002bV-00 for tcpm@ietf.org; Mon, 17 May 2004 12:40:22 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx with esmtp (Exim 4.12) id 1BPl95-0002D2-00 for tcpm@ietf.org; Mon, 17 May 2004 12:39:19 -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 i4HGdDXm015474 for ; Mon, 17 May 2004 09:39:13 -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 D502677AA5C for ; Mon, 17 May 2004 12:39:11 -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: Nobody Told Me MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 17 May 2004 12:39:11 -0400 Message-Id: <20040517163911.D502677AA5C@guns.icir.org> Subject: [tcpm] ATO i-d 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 Hi folks! Based on the postings on the list it seems to Ted and I that the consensus is for this WG to take on the ATO internet-draft (draft-eggert-tcpm-tcp-abort-timeout-option-00.txt). Please yell quickly if this goes against your read of the discussion. Thanks! allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAqOqvWyrrWs4yIs4RAtcbAJoCyGfH5gIK9v2qaHyCECSuxUs+SgCeNJLe Llb0WzdRuO6l4sdbdbQFcvg= =rsSL -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon May 17 13:35:10 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07380 for ; Mon, 17 May 2004 13:35: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 1BPlqo-0006cr-Qg for tcpm-archive@odin.ietf.org; Mon, 17 May 2004 13:24:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HHOUaP025465 for tcpm-archive@odin.ietf.org; Mon, 17 May 2004 13:24:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPle0-0004xq-Nd for tcpm-web-archive@optimus.ietf.org; Mon, 17 May 2004 13: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 NAA05946 for ; Mon, 17 May 2004 13:11: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 1BPldy-0005dT-Te for tcpm-web-archive@ietf.org; Mon, 17 May 2004 13:11:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPldD-0005JS-00 for tcpm-web-archive@ietf.org; Mon, 17 May 2004 13:10:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPlcc-0004y8-00 for tcpm-web-archive@ietf.org; Mon, 17 May 2004 13:09:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPlX1-0003Q7-8C; Mon, 17 May 2004 13:04:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPlIZ-0001Vi-Hu for tcpm@optimus.ietf.org; Mon, 17 May 2004 12:49: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 MAA04360 for ; Mon, 17 May 2004 12:49: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 1BPlIX-0005i2-So for tcpm@ietf.org; Mon, 17 May 2004 12:49:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPlHY-0005Lu-00 for tcpm@ietf.org; Mon, 17 May 2004 12:48:04 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx with esmtp (Exim 4.12) id 1BPlGZ-0004y5-00 for tcpm@ietf.org; Mon, 17 May 2004 12:47:03 -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 i4HGl2Xm015576 for ; Mon, 17 May 2004 09:47:02 -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 40DCF77AA5C for ; Mon, 17 May 2004 12:47: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: Nobody Told Me MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 17 May 2004 12:47:01 -0400 Message-Id: <20040517164701.40DCF77AA5C@guns.icir.org> Subject: [tcpm] wglc for frto draft 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 Hi folks! We'd like to start a WGLC on forwarding the F-RTO i-d to the IESG for publication as an experimental RFC. The i-d has been updated based on the recent dicsussion on this list. The i-d filename has also been changed to reflect that it is a TCPM work item and is now: draft-ietf-tcpm-frto-00.txt (And, remember that this is really probably the 7th or 8th rev of this draft, since it started life in the tsvwg working group.) Because there is a long holiday weekend (in the US at least) soon we'll give this 3 weeks rather than the standard 2 weeks. So, the last call will be over on Tuesday June 8. Please send comments to the list. Thanks! allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAqOyFWyrrWs4yIs4RAppaAKCHXfdnup2wh+DMYapRUBCHG6gDOQCffYBA FK7pGxTAOgO20+H0ae9h61k= =ywDu -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue May 18 18:56: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 SAA26281 for ; Tue, 18 May 2004 18:56: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 1BQDP8-0004P0-Qh for tcpm-archive@odin.ietf.org; Tue, 18 May 2004 18:49:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IMnkmc016922 for tcpm-archive@odin.ietf.org; Tue, 18 May 2004 18:49:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQDCz-0002A8-5A for tcpm-web-archive@optimus.ietf.org; Tue, 18 May 2004 18:37: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 SAA25642 for ; Tue, 18 May 2004 18:37: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 1BQDCw-0003Qg-5C for tcpm-web-archive@ietf.org; Tue, 18 May 2004 18:37:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQDC5-0003Ow-00 for tcpm-web-archive@ietf.org; Tue, 18 May 2004 18:36:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQDBo-0003Mk-00 for tcpm-web-archive@ietf.org; Tue, 18 May 2004 18:36:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQD36-0000WB-Gi; Tue, 18 May 2004 18: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 1BQCql-0003ul-2V for tcpm@optimus.ietf.org; Tue, 18 May 2004 18:14: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 SAA23774 for ; Tue, 18 May 2004 18: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 1BQCqi-0001bT-8X for tcpm@ietf.org; Tue, 18 May 2004 18:14:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQCps-0001Xw-00 for tcpm@ietf.org; Tue, 18 May 2004 18:13:21 -0400 Received: from relay1.mentorg.com ([192.94.38.131]) by ietf-mx with esmtp (Exim 4.12) id 1BQCpA-0001Ro-00 for tcpm@ietf.org; Tue, 18 May 2004 18:12:36 -0400 Received: from svr-orw-exc-01.wv.mentorg.com ([147.34.98.101]) by relay1.mentorg.com with esmtp id 1BQCoh-0002ex-00 from tammy_leino@mentor.com for tcpm@ietf.org; Tue, 18 May 2004 15:12:07 -0700 Received: by svr-orw-exc-01.wv.mentorg.com with Internet Mail Service (5.5.2657.72) id ; Tue, 18 May 2004 15:12:07 -0700 Received: from svr-alm-exc-01.alm.mentorg.com ([134.86.100.100]) by svr-orw-exc-01.wv.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id LDS7247X; Tue, 18 May 2004 15:12:04 -0700 Received: by svr-alm-exc-01.alm.mentorg.com with Internet Mail Service (5.5.2657.72) id ; Tue, 18 May 2004 17:12:03 -0500 From: "Leino, Tammy" To: "'tcpm@ietf.org'" X-Mailer: Internet Mail Service (5.5.2657.72) Message-ID: Date: Tue, 18 May 2004 17:11:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: [tcpm] Question regarding section 4.2 of draft-ietf-tcpm-tcpsecure-00.tx t 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 Network Working Group Members, I have been studying this Internet draft and have consulted RFC 793 to help resolve my lack of understanding of section 4.2, but my problem still persists. Section 4.2 gives the solution to add the following additional check to any incoming segment: ((SND.UNA - MAX.SND.WND) <= SEG.ACK < SND.NXT) It goes on to explain MAX.SND.WND and the relevance of this change. However, RFC 793 specifies that an acceptable ack falls into the following range: SND.UNA < SEG.ACK =< SND.NXT My question is why has the equality condition been removed from the SEG.ACK =< SND.NXT portion of the check as specified in RFC 793? Thank you for your help in this matter. Sincerely, Tammy Leino _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Tue May 18 19:23: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 TAA27403 for ; Tue, 18 May 2004 19:23: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 1BQDrm-00026v-9P for tcpm-archive@odin.ietf.org; Tue, 18 May 2004 19:19:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4INJM8B008105 for tcpm-archive@odin.ietf.org; Tue, 18 May 2004 19:19:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQDeC-0008HA-6Y for tcpm-web-archive@optimus.ietf.org; Tue, 18 May 2004 19:05: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 TAA26722 for ; Tue, 18 May 2004 19:05: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 1BQDe8-0005Cr-W0 for tcpm-web-archive@ietf.org; Tue, 18 May 2004 19:05:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQDdK-00059d-00 for tcpm-web-archive@ietf.org; Tue, 18 May 2004 19:04:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQDcN-00056U-00 for tcpm-web-archive@ietf.org; Tue, 18 May 2004 19:03:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQDVC-00069r-Qx; Tue, 18 May 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 1BQDI2-0003js-CA for tcpm@optimus.ietf.org; Tue, 18 May 2004 18:42: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 SAA25816 for ; Tue, 18 May 2004 18:42: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 1BQDHy-0003k4-5V for tcpm@ietf.org; Tue, 18 May 2004 18:42:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQDHB-0003fn-00 for tcpm@ietf.org; Tue, 18 May 2004 18:41:33 -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 1BQDGb-0003b7-00 for tcpm@ietf.org; Tue, 18 May 2004 18:40:57 -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 i4IMeNSw009946; Tue, 18 May 2004 15:40:25 -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 AUG19288; Tue, 18 May 2004 15:40:23 -0700 (PDT) Message-ID: <40AA90D7.3FA988B@cisco.com> Date: Tue, 18 May 2004 15:40:23 -0700 From: Anantha Ramaiah Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Leino, Tammy" CC: "'tcpm@ietf.org'" Subject: Re: [tcpm] Question regarding section 4.2 of draft-ietf-tcpm-tcpsecure-00.txt References: 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Leino, "Leino, Tammy" wrote: > > Network Working Group Members, > > I have been studying this Internet draft and have consulted RFC 793 to help > resolve my lack of understanding of section 4.2, but my problem still > persists. > > Section 4.2 gives the solution to add the following additional check to any > incoming segment: > > ((SND.UNA - MAX.SND.WND) <= SEG.ACK < SND.NXT) I think this looks like a typo. It should read as : ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT). We are not changing the existing RFC behaviour for the right side SND.UNA. Thanks for pointing it out. Randall, this needs to be added to the list of changes for rev 2... -Anantha > > It goes on to explain MAX.SND.WND and the relevance of this change. > However, RFC 793 specifies that an acceptable ack falls into the following > range: > > SND.UNA < SEG.ACK =< SND.NXT > > My question is why has the equality condition been removed from the SEG.ACK > =< SND.NXT portion of the check as specified in RFC 793? > > Thank you for your help in this matter. > > Sincerely, > Tammy Leino > > _______________________________________________ > 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 May 18 19:23: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 TAA27471 for ; Tue, 18 May 2004 19:23: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 1BQDrn-00027V-85 for tcpm-archive@odin.ietf.org; Tue, 18 May 2004 19:19:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4INJN4o008144 for tcpm-archive@odin.ietf.org; Tue, 18 May 2004 19: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 1BQDeH-0008HI-Ez for tcpm-web-archive@optimus.ietf.org; Tue, 18 May 2004 19:05: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 TAA26736 for ; Tue, 18 May 2004 19:05: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 1BQDeE-0005DC-5n for tcpm-web-archive@ietf.org; Tue, 18 May 2004 19:05:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQDdN-0005A9-00 for tcpm-web-archive@ietf.org; Tue, 18 May 2004 19:04:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQDcw-00056j-00 for tcpm-web-archive@ietf.org; Tue, 18 May 2004 19:04:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQDVE-0006AG-AS; Tue, 18 May 2004 18:56:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQDJx-0003wm-R9 for tcpm@optimus.ietf.org; Tue, 18 May 2004 18:44: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 SAA25922 for ; Tue, 18 May 2004 18:44: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 1BQDJu-0003tS-NW for tcpm@ietf.org; Tue, 18 May 2004 18:44:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQDJ1-0003pe-00 for tcpm@ietf.org; Tue, 18 May 2004 18:43:27 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BQDIG-0003iW-00 for tcpm@ietf.org; Tue, 18 May 2004 18:42:40 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i4IMgB956718; Tue, 18 May 2004 15:42:11 -0700 (PDT) (envelope-from pgoyette@juniper.net) Received: from pgoyette600 ([172.24.236.10]) by merlot.juniper.net (8.11.3/8.11.3) with SMTP id i4IMg6J87349; Tue, 18 May 2004 15:42:06 -0700 (PDT) (envelope-from pgoyette@juniper.net) From: "Paul Goyette" To: "Leino, Tammy" , Subject: RE: [tcpm] Question regarding section 4.2 of draft-ietf-tcpm-tcpsecure-00.tx t Date: Tue, 18 May 2004 15:42:06 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: 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.1 required=5.0 tests=AWL,LINES_OF_YELLING, LINES_OF_YELLING_2 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think it's an oversight/typo. -----Original Message----- From: tcpm-admin@ietf.org [mailto:tcpm-admin@ietf.org]On Behalf Of Leino, Tammy Sent: Tuesday, May 18, 2004 3:12 PM To: 'tcpm@ietf.org' Subject: [tcpm] Question regarding section 4.2 of draft-ietf-tcpm-tcpsecure-00.tx t Network Working Group Members, I have been studying this Internet draft and have consulted RFC 793 to help resolve my lack of understanding of section 4.2, but my problem still persists. Section 4.2 gives the solution to add the following additional check to any incoming segment: ((SND.UNA - MAX.SND.WND) <= SEG.ACK < SND.NXT) It goes on to explain MAX.SND.WND and the relevance of this change. However, RFC 793 specifies that an acceptable ack falls into the following range: SND.UNA < SEG.ACK =< SND.NXT My question is why has the equality condition been removed from the SEG.ACK =< SND.NXT portion of the check as specified in RFC 793? Thank you for your help in this matter. Sincerely, Tammy Leino _______________________________________________ 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 May 19 15:40:27 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06898 for ; Wed, 19 May 2004 15:40: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 1BQWl5-0007cN-CE for tcpm-archive@odin.ietf.org; Wed, 19 May 2004 15:29:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JJThL7029282 for tcpm-archive@odin.ietf.org; Wed, 19 May 2004 15:29:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQW6o-0002Y2-5j for tcpm-web-archive@optimus.ietf.org; Wed, 19 May 2004 14: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 OAA29971 for ; Wed, 19 May 2004 14:48: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 1BQW6l-0000Ef-9Z for tcpm-web-archive@ietf.org; Wed, 19 May 2004 14:48:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQW5r-00004I-00 for tcpm-web-archive@ietf.org; Wed, 19 May 2004 14:47:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQW5C-0007lv-00 for tcpm-web-archive@ietf.org; Wed, 19 May 2004 14:46:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQVmc-0006EC-Lm; Wed, 19 May 2004 14:27:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQSOV-0000QD-9d for tcpm@optimus.ietf.org; Wed, 19 May 2004 10:50: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 KAA16869 for ; Wed, 19 May 2004 10:50: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 1BQSOS-0002qP-NP for tcpm@ietf.org; Wed, 19 May 2004 10:50:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQSNN-0002lX-00 for tcpm@ietf.org; Wed, 19 May 2004 10:48:58 -0400 Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 1BQSMK-0002f6-00 for tcpm@ietf.org; Wed, 19 May 2004 10:47:52 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4JEjBKZ012185 for ; Wed, 19 May 2004 10:45:12 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAusaaGx; Wed, 19 May 04 10:43:57 -0400 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id i4JEjEcu028787; Wed, 19 May 2004 10:45:14 -0400 (EDT) Date: Wed, 19 May 2004 10:45:14 -0400 (EDT) From: Sandy Murphy Message-Id: <200405191445.i4JEjEcu028787@tislabs.com> To: tcpm@ietf.org Cc: sandy@tislabs.com Subject: [tcpm] SYN's in draft-ietf-tcpm-tcpsecure.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 There's been a lot of discussion about the modifications to the RST processing, but not much about the modifications to the SYN processing. NOTE: All of the following is predicated on an assumption of just what exactly is meant by "send an ACK segment to the peer but before sending the ACK segment subtract one from value being acknowledged." and "send an ACK segment to the peer." I'm presuming this means send and . If that's not correct, just stop reading right here. Oh, and by the way. The draft should really spell this out. The 793 SYN processing produces the desired result if a crashed host tries to re-connect to its previous partner - that is, the previous partner's half-open connection would close. But it produces an undesirable result if an old SYN arrives - that is, old delayed SYN's could blow away a perfectly healthy connection if the SEQ is in the window. The new processing produces the desirable result that old SYN's in the window do nothing to an ESTABLISHED connection. But it appears to me to have a less desirable result if a crashed host attempts to reconnect to its previous partner. If the receiver, A, is in state A.ESTABLISHED and gets a SYN with SEQ=A.RCV.NXT, then it sends a . If this is a current SYN, then the other end, B, is in state B.SYN-SENT and the SEQ on its SYN is equal to B.ISS. So ACK=A.RCV.NXT-1 is less than B.ISS. So B sends . A notices that this is out of its window. Ordinarily, this would make A send an ACK with SEQ=SND.NXT and ACK=RCV.NXT, but because the packet has the RST bit set, it just drops the packet. So B, the SYN-SENT side, will retransmit the SYN (causing repeats of this same behavior) until it times out. If the SYN's SEQ > A.RCV.NXT, then the ACK is sent with ACK=A.RCV.NXT and the RST is sent with SEQ=A.RCV.NXT which will cause the connection to close (baring data in the pipe advancing A.RCV.NXT, but eventually things should catch up). So this behavior only occurs when SEQ=A.RCV.NXT on the SYN. Could someone confirm that I'm interpreting this (both the 793 spec and the new draft) correctly? If I'm correct, does this behavior bother anyone? --Sandy P.S. I've always thought that the 793 behavior when an SYN in the window was received was potentially dangerous. If the SYN is a current SYN from a partner who has crashed and resumed, then resetting the connection is the right thing to do. But if this is an old duplicate SYN (in the window) from some previous connection attempt, then its arrival blows away a healthy connection. That did not seem like a good thing. Long ago, when I was studying this, it wasn't that big a deal. The most likely scenario was that one connection attempt failed, followed immediately by one that succeeded, and an old SYN from the first attempt arrived late. Given that ISS's at the time typically were chosen as increments over previous values, it would not be likely that the ISS of the old SYN would be within the receive window of the new connection. Unless the old SYN was delayed so long that the sequence number had wrapped - hardly likely. But now that the ISS's are randomly chosen, you've got a (windowsize/(2**32)) chance of the old SYN being within the window of the new connection (less chance if successive connection attempts are delayed by a long-ish time to let old SYN packets die). So I'm glad to see some modification of the SYN-in-the-window processing. I'm just not sure this is the best one. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed May 19 15:40:32 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07005 for ; Wed, 19 May 2004 15:40: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 1BQWlK-0007lV-CN for tcpm-archive@odin.ietf.org; Wed, 19 May 2004 15:29:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JJTwOC029841 for tcpm-archive@odin.ietf.org; Wed, 19 May 2004 15:29:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQW9s-0003NC-PK for tcpm-web-archive@optimus.ietf.org; Wed, 19 May 2004 14:51: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 OAA00357 for ; Wed, 19 May 2004 14:51: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 1BQW9p-0000jb-VR for tcpm-web-archive@ietf.org; Wed, 19 May 2004 14:51:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQW94-0000cP-00 for tcpm-web-archive@ietf.org; Wed, 19 May 2004 14:50:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQW8O-0000UL-00 for tcpm-web-archive@ietf.org; Wed, 19 May 2004 14:49:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQVn7-0006P3-Hd; Wed, 19 May 2004 14:27:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQSfq-0002zA-8N for tcpm@optimus.ietf.org; Wed, 19 May 2004 11:08: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 LAA18207 for ; Wed, 19 May 2004 11:07: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 1BQSfn-0004VE-Hm for tcpm@ietf.org; Wed, 19 May 2004 11:07:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQSf3-0004Qy-00 for tcpm@ietf.org; Wed, 19 May 2004 11:07:14 -0400 Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 1BQSeJ-0004Lw-00 for tcpm@ietf.org; Wed, 19 May 2004 11:06:28 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4JF35mj015091 for ; Wed, 19 May 2004 11:03:05 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAA_aqvD; Wed, 19 May 04 11:02:30 -0400 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id i4JF3kXZ029657; Wed, 19 May 2004 11:03:46 -0400 (EDT) Date: Wed, 19 May 2004 11:03:46 -0400 (EDT) From: Sandy Murphy Message-Id: <200405191503.i4JF3kXZ029657@tislabs.com> To: tcpm@ietf.org Cc: sandy@tislabs.com Subject: [tcpm] blind data injection 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 The tcpsecure draft notes that data can be accepted by the TCP implementation if any of the segment's bytes fall within the receive window, not just at the left edge of the window. But TCP does not require that out-of-order segments are buffered. I don't know how ubiquitous it is for implementations to do the buffering. (RFC1122 makes it a "should".) I can find no place where the TCP spec speaks of what to do if a later arriving segment overlaps a previously queued out-of-order segment. I can see the possibility that the later arriving data could overwrite the previously queued data. Unix tcp code I've looked at seems to let recently arrived segments overwrite succeeding queued out-of-order segments (but queued preceding segments overwrite the recently arrived segments). That would mean that the eventual delivery of bogus injected data to the application would depend on the spacing of the arrival of any real segments covering the same sequence number space as the bogus injected data. A blind attacker could not predict what if any of the bogus injected data would be delivered to the application. Furthermore, any application level framing could cause any bogus injected data that did manage to be delivered to fail the parse step in the application. So BGP, in particular, which has such framing, would be in much less danger of accepting the bogus data. It would be much more likely that any injected data that did manage to reach BGP would not pass the parsing and would cause the connection to abort. That's not a good result, but it's better than accepting bogus injected data. --Sandy _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed May 19 15:40:58 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07123 for ; Wed, 19 May 2004 15:40: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 1BQWlM-0007nB-3Y for tcpm-archive@odin.ietf.org; Wed, 19 May 2004 15:30:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JJU0O5029948 for tcpm-archive@odin.ietf.org; Wed, 19 May 2004 15:30:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQWAu-0003j2-MX for tcpm-web-archive@optimus.ietf.org; Wed, 19 May 2004 14: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 OAA00496 for ; Wed, 19 May 2004 14:52: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 1BQWAr-0000s4-PL for tcpm-web-archive@ietf.org; Wed, 19 May 2004 14:52:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQW9u-0000kQ-00 for tcpm-web-archive@ietf.org; Wed, 19 May 2004 14:51:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQW9I-0000co-00 for tcpm-web-archive@ietf.org; Wed, 19 May 2004 14:50:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQVn7-0006PC-RV; Wed, 19 May 2004 14:27:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQShW-0003V0-UE for tcpm@optimus.ietf.org; Wed, 19 May 2004 11:09: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 LAA18245 for ; Wed, 19 May 2004 11:09: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 1BQShU-0004cE-8i for tcpm@ietf.org; Wed, 19 May 2004 11:09:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQSgV-0004Xk-00 for tcpm@ietf.org; Wed, 19 May 2004 11:08:44 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BQSfY-0004R3-00 for tcpm@ietf.org; Wed, 19 May 2004 11:07:44 -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 i4JF65J18944; Wed, 19 May 2004 08:06:05 -0700 (PDT) Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.12.11/8.12.11) with ESMTP id i4JF6585037382; Wed, 19 May 2004 08:06:05 -0700 (PDT) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.12.11/8.12.11/Submit) id i4JF65xf037381; Wed, 19 May 2004 08:06:05 -0700 (PDT) (envelope-from faber) Date: Wed, 19 May 2004 08:06:05 -0700 From: Ted Faber To: Paul Goyette Cc: "Leino, Tammy" , tcpm@ietf.org Subject: Re: [tcpm] Question regarding section 4.2 of draft-ietf-tcpm-tcpsecure-00.tx t Message-ID: <20040519150605.GB36903@pun.isi.edu> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JYK4vJDZwFMowpUq" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-30-3-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 --JYK4vJDZwFMowpUq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, May 18, 2004 at 03:42:06PM -0700, Paul Goyette wrote: >> From: tcpm-admin@ietf.org [mailto:tcpm-admin@ietf.org]On Behalf Of Leino, Tammy >> >> My question is why has the equality condition been removed from the SEG.ACK >> =< SND.NXT portion of the check as specified in RFC 793? > > I think it's an oversight/typo. And a good catch, thanks. -- 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 --JYK4vJDZwFMowpUq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAq3fdaUz3f+Zf+XsRAigjAJ0Xl4P8AUX7V6LY+eXKrtVR4MIqDACePzQI QuFOFn2OWMOZM37FfaXcPlg= =CU9F -----END PGP SIGNATURE----- --JYK4vJDZwFMowpUq-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed May 19 17:45:06 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21272 for ; Wed, 19 May 2004 17:45: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 1BQYez-0002A7-2B for tcpm-archive@odin.ietf.org; Wed, 19 May 2004 17:31:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JLVWH2008294 for tcpm-archive@odin.ietf.org; Wed, 19 May 2004 17:31:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQYNd-00023c-NK for tcpm-web-archive@optimus.ietf.org; Wed, 19 May 2004 17:13: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 RAA17582 for ; Wed, 19 May 2004 17:13: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 1BQYNb-0000dZ-Db for tcpm-web-archive@ietf.org; Wed, 19 May 2004 17:13:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQYM7-0000NX-00 for tcpm-web-archive@ietf.org; Wed, 19 May 2004 17:12:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQYJq-0007hA-00 for tcpm-web-archive@ietf.org; Wed, 19 May 2004 17:09:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQXS7-00058H-DU; Wed, 19 May 2004 16:14:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQX1G-0004sq-Cy for tcpm@optimus.ietf.org; Wed, 19 May 2004 15:46: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 PAA08226 for ; Wed, 19 May 2004 15:46: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 1BQX1E-0001hT-RV for tcpm@ietf.org; Wed, 19 May 2004 15:46:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQWz0-0001HT-00 for tcpm@ietf.org; Wed, 19 May 2004 15:44:06 -0400 Received: from mentat.com ([192.88.122.129] helo=roll.mentat.com) by ietf-mx with esmtp (Exim 4.12) id 1BQWv2-0000SO-00 for tcpm@ietf.org; Wed, 19 May 2004 15:40:00 -0400 Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.11.7p1+Sun/8.11.7+Mentat) with ESMTP id i4JJeXt25553; Wed, 19 May 2004 12:40:33 -0700 (PDT) Received: from rock.mentat.com (rock [192.88.122.163]) by leo.mentat.com (8.11.7p1+Sun/8.11.7+Mentat) with SMTP id i4JJeYX13532; Wed, 19 May 2004 12:40:34 -0700 (PDT) Received: by rock.mentat.com (SMI-8.6/SMI-SVR4) id MAA03933; Wed, 19 May 2004 12:46:49 -0700 Date: Wed, 19 May 2004 12:46:49 -0700 From: jt@mentat.com (Jerry Toporek) Message-Id: <200405191946.MAA03933@rock.mentat.com> To: tcpm@ietf.org, sandy@tislabs.com Subject: Re: [tcpm] SYN's in draft-ietf-tcpm-tcpsecure.txt :-) X-Sun-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 > > But now that the ISS's are randomly chosen, you've got a > (windowsize/(2**32)) chance of the old SYN being within the window of > the new connection (less chance if successive connection attempts are > delayed by a long-ish time to let old SYN packets die). > When was it decreed that "ISS's are randomly chosen"? One of the strengths of the preferred mechanism for ISS selection (described in RFC 1948) is that it maintains exactly the same traditional time-based increase of ISS *on a per-source/dest-pair basis*, while hiding any useful information from a blind attacker. jt _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed May 19 18:08:25 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23601 for ; Wed, 19 May 2004 18:08: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 1BQZ4B-00033U-9u for tcpm-archive@odin.ietf.org; Wed, 19 May 2004 17:57:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JLvZ8M011745 for tcpm-archive@odin.ietf.org; Wed, 19 May 2004 17:57:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQYz6-0000j8-3k for tcpm-web-archive@optimus.ietf.org; Wed, 19 May 2004 17:52: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 RAA21960 for ; Wed, 19 May 2004 17:52: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 1BQYz3-0006wX-GZ for tcpm-web-archive@ietf.org; Wed, 19 May 2004 17:52:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQYyK-0006pI-00 for tcpm-web-archive@ietf.org; Wed, 19 May 2004 17:51:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQYxe-0006gL-00 for tcpm-web-archive@ietf.org; Wed, 19 May 2004 17:50:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQYgY-0003Hh-Dq; Wed, 19 May 2004 17:33:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQYYp-0005kU-P3 for tcpm@optimus.ietf.org; Wed, 19 May 2004 17:25: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 RAA18501 for ; Wed, 19 May 2004 17:25: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 1BQYYn-0002Dv-Bz for tcpm@ietf.org; Wed, 19 May 2004 17:25:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQYXw-00027O-00 for tcpm@ietf.org; Wed, 19 May 2004 17:24:17 -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 1BQYXX-0001zt-00 for tcpm@ietf.org; Wed, 19 May 2004 17:23:51 -0400 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 i4JLNnC1015673; Wed, 19 May 2004 14:23:49 -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 ATI27658; Wed, 19 May 2004 14:23:01 -0700 (PDT) Date: Wed, 19 May 2004 14:23:48 -0700 (PDT) From: Mitesh Dalal To: Jerry Toporek cc: tcpm@ietf.org, sandy@tislabs.com Subject: Re: [tcpm] SYN's in draft-ietf-tcpm-tcpsecure.txt :-) In-Reply-To: <200405191946.MAA03933@rock.mentat.com> Message-ID: References: <200405191946.MAA03933@rock.mentat.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=AWL autolearn=no version=2.60 On Wed, 19 May 2004, Jerry Toporek wrote: > > > > But now that the ISS's are randomly chosen, you've got a > > (windowsize/(2**32)) chance of the old SYN being within the window of > > the new connection (less chance if successive connection attempts are > > delayed by a long-ish time to let old SYN packets die). > > > > When was it decreed that "ISS's are randomly chosen"? I think its simply a standard practice. http://www.computerworld.com/securitytopics/security/story/0,10801,58542,00.html discussion came up couple of years back. Most vendors have good random ISN since then. There is a detailed analysis on the web about the randomness of different vendors ISNs but I dont have the link handy. Mitesh > One of the strengths of the preferred mechanism for ISS selection > (described in RFC 1948) is that it maintains exactly the same > traditional time-based increase of ISS *on a per-source/dest-pair > basis*, while hiding any useful information from a blind attacker. > > jt > > _______________________________________________ > 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 May 19 19:09:10 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 TAA27350 for ; Wed, 19 May 2004 19:09: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 1BQaAp-0004fQ-Sn for tcpm-archive@odin.ietf.org; Wed, 19 May 2004 19:08:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JN8VRB017901 for tcpm-archive@odin.ietf.org; Wed, 19 May 2004 19:08:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQZym-00020p-V2 for tcpm-web-archive@optimus.ietf.org; Wed, 19 May 2004 18:56: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 SAA26821 for ; Wed, 19 May 2004 18: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 1BQZyj-0006ds-N4 for tcpm-web-archive@ietf.org; Wed, 19 May 2004 18:56:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQZxl-0006Wl-00 for tcpm-web-archive@ietf.org; Wed, 19 May 2004 18:55:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQZws-0006QU-00 for tcpm-web-archive@ietf.org; Wed, 19 May 2004 18:54:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQZp5-0007gt-Pd; Wed, 19 May 2004 18:46:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQZjP-0005dH-5T for tcpm@optimus.ietf.org; Wed, 19 May 2004 18:40: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 SAA25838 for ; Wed, 19 May 2004 18:40: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 1BQZjM-0004hE-2g for tcpm@ietf.org; Wed, 19 May 2004 18:40:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQZiQ-0004bN-00 for tcpm@ietf.org; Wed, 19 May 2004 18:39:11 -0400 Received: from mentat.com ([192.88.122.129] helo=roll.mentat.com) by ietf-mx with esmtp (Exim 4.12) id 1BQZhz-0004UI-00 for tcpm@ietf.org; Wed, 19 May 2004 18:38:43 -0400 Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.11.7p1+Sun/8.11.7+Mentat) with ESMTP id i4JMd2t29476; Wed, 19 May 2004 15:39:03 -0700 (PDT) Received: from rock.mentat.com (rock [192.88.122.163]) by leo.mentat.com (8.11.7p1+Sun/8.11.7+Mentat) with SMTP id i4JMd3X27267; Wed, 19 May 2004 15:39:03 -0700 (PDT) Received: by rock.mentat.com (SMI-8.6/SMI-SVR4) id PAA03993; Wed, 19 May 2004 15:45:20 -0700 Date: Wed, 19 May 2004 15:45:20 -0700 From: jt@mentat.com (Jerry Toporek) Message-Id: <200405192245.PAA03993@rock.mentat.com> To: mdalal@cisco.com Subject: Re: [tcpm] SYN's in draft-ietf-tcpm-tcpsecure.txt :-) Cc: tcpm@ietf.org, sandy@tislabs.com X-Sun-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 > > > > When was it decreed that "ISS's are randomly chosen"? > > I think its simply a standard practice. > > http://www.computerworld.com/securitytopics/security/story/0,10801,58542,00.html Though not a "standard", I think that RFC 1948 is a better reference than Computerworld. > > discussion came up couple of years back. Most vendors have good random > ISN since then. There is a detailed analysis on the web about the randomness of > different vendors ISNs but I dont have the link handy. > Yes, I'm well aware of the discussion. For exactly the reason stated in the original posting, completely random ISN selection is not the best solution. jt _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed May 19 19:23:07 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 TAA28524 for ; Wed, 19 May 2004 19:23: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 1BQaML-00080s-I5 for tcpm-archive@odin.ietf.org; Wed, 19 May 2004 19:20:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JNKP5e030797 for tcpm-archive@odin.ietf.org; Wed, 19 May 2004 19:20:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQaL7-0007hU-Mt for tcpm-web-archive@optimus.ietf.org; Wed, 19 May 2004 19:19: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 TAA28082 for ; Wed, 19 May 2004 19:19: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 1BQaL6-0001o0-3R for tcpm-web-archive@ietf.org; Wed, 19 May 2004 19:19:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQaKB-0001hU-00 for tcpm-web-archive@ietf.org; Wed, 19 May 2004 19:18:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQaJg-0001be-00 for tcpm-web-archive@ietf.org; Wed, 19 May 2004 19:17:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQaH8-0006iw-6j; Wed, 19 May 2004 19:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQaCi-0005U0-TV for tcpm@optimus.ietf.org; Wed, 19 May 2004 19:10: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 TAA27458 for ; Wed, 19 May 2004 19:10: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 1BQaCf-0000Yh-Fk for tcpm@ietf.org; Wed, 19 May 2004 19:10:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQaBE-0000Ie-00 for tcpm@ietf.org; Wed, 19 May 2004 19:08:56 -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 1BQa9i-0007mn-00 for tcpm@ietf.org; Wed, 19 May 2004 19:07:22 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 19 May 2004 15:14:23 +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 i4JN6ofZ015656; Wed, 19 May 2004 16:06:50 -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 ATI37778; Wed, 19 May 2004 16:06:03 -0700 (PDT) Date: Wed, 19 May 2004 16:06:49 -0700 (PDT) From: Mitesh Dalal To: Jerry Toporek cc: tcpm@ietf.org, sandy@tislabs.com Subject: Re: [tcpm] SYN's in draft-ietf-tcpm-tcpsecure.txt :-) In-Reply-To: <200405192245.PAA03993@rock.mentat.com> Message-ID: References: <200405192245.PAA03993@rock.mentat.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=AWL autolearn=no version=2.60 On Wed, 19 May 2004, Jerry Toporek wrote: > > > > > > When was it decreed that "ISS's are randomly chosen"? > > > > I think its simply a standard practice. > > > > http://www.computerworld.com/securitytopics/security/story/0,10801,58542,00.html > > Though not a "standard", I think that RFC 1948 is a better reference > than Computerworld. > I wanted to point out the time when vendors especially cisco moved to a truly random ISN generation. 1948 predateds the article and references a different CERT adivsory. So atleast till that time nobody had thought of using 1948. > > > > discussion came up couple of years back. Most vendors have good random > > ISN since then. There is a detailed analysis on the web about the randomness of > > different vendors ISNs but I dont have the link handy. > > > > Yes, I'm well aware of the discussion. For exactly the reason stated in > the original posting, completely random ISN selection is not the best > solution. > here is the link I talked about earlier. http://lcamtuf.coredump.cx/newtcp/ most vendors either have good 32bit randomness or have either a flawed or acceptable 1948 implementation or none. I have nothing against 1948 nor do I have a clue why it was not standardized. But stating that most ISNs are randomly chosen does not sound like a misleading statement. thx Mitesh _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed May 19 20: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 UAA00746 for ; Wed, 19 May 2004 20:21: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 1BQbB2-0004i0-2S for tcpm-archive@odin.ietf.org; Wed, 19 May 2004 20:12:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4K0CmtW018096 for tcpm-archive@odin.ietf.org; Wed, 19 May 2004 20:12:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQb4i-0003Av-PC for tcpm-web-archive@optimus.ietf.org; Wed, 19 May 2004 20: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 UAA00305 for ; Wed, 19 May 2004 20:06: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 1BQb4g-0007Rb-On for tcpm-web-archive@ietf.org; Wed, 19 May 2004 20:06:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQb3h-0007Ky-00 for tcpm-web-archive@ietf.org; Wed, 19 May 2004 20:05:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQb3D-0007EH-00 for tcpm-web-archive@ietf.org; Wed, 19 May 2004 20:04:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQayi-0001cJ-Qf; Wed, 19 May 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 1BQavw-0008Dt-Po for tcpm@optimus.ietf.org; Wed, 19 May 2004 19: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 TAA29881 for ; Wed, 19 May 2004 19:57: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 1BQavu-0006Nu-Lp for tcpm@ietf.org; Wed, 19 May 2004 19:57:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQav0-0006GI-00 for tcpm@ietf.org; Wed, 19 May 2004 19:56:15 -0400 Received: from scmail.arc.com ([63.206.101.3]) by ietf-mx with esmtp (Exim 4.12) id 1BQauF-00062y-00 for tcpm@ietf.org; Wed, 19 May 2004 19:55:27 -0400 Received: from scexch01.arc.com (scexch01 [192.9.200.149]) by scmail.arc.com (8.12.8/8.12.5) with SMTP id i4JNahux024444 for ; Wed, 19 May 2004 16:36:43 -0700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Date: Wed, 19 May 2004 16:54:56 -0700 Importance: normal Priority: normal Message-ID: <2EFAFC388B9C4C48B581846AEC20A020016CA883@scexch01.arc.com> Thread-Topic: tcpsecure: request clarification on data injection solution Thread-Index: AcQ9/LATp/9CdJGGTdax+ywCM60+xA== From: "Charlet, Ricky" To: Content-Transfer-Encoding: 7bit Subject: [tcpm] tcpsecure: request clarification on data injection solution 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 Howdy, I'm attempting to implement draft-ietf-tcpm-tcpsecure-00.txt. I would appreciate a better description of how each (RST, SYN, data-injection) work in practice. The RST and SYN, I think I have pretty much figured out. But the data-injection solution is beyond my capacity to grok. The draft says: ----------------cut----------------- 4.2 Solution 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). ---------------paste------------------ How can we subtract a number of bytes from a sequence number and compare that to other expected sequence numbers? I assume it does work out, but I don't see why it does. And I deeply suspect that I would mess up the zero-wrap-around math sicne I don't really see why this 'solution' works. Also " This window is the scaled value i.e. the value may be larger than 65,535 bytes." Can someone shed more light on what you mean by 'scaled value' (as opposed to what other alternative)? Thanks in advance. --- Ricky Charlet Ricky.Charlet@arc.com USA 831.466.4968 0 ASCII Ribbon campaign - against HTML Email ^ - against auto-execute attachments --- Ricky Charlet Ricky.Charlet@arc.com USA 831.466.4968 ----------------------------------------------------------- Unless otherwise expressly stated, this message does not create or vary any contractual relationship between you and ARC International. The contents of this e-mail may be confidential and if you have received it in error, please delete it from your system, destroy any hard copies and telephone the above number. Incoming emails to ARC may be subject to monitoring other than by the addressee. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed May 19 20:24: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 UAA00851 for ; Wed, 19 May 2004 20:24: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 1BQbIn-0006BK-9q for tcpm-archive@odin.ietf.org; Wed, 19 May 2004 20:20:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4K0KnX1023758 for tcpm-archive@odin.ietf.org; Wed, 19 May 2004 20:20:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQb8P-0004Nr-7x for tcpm-web-archive@optimus.ietf.org; Wed, 19 May 2004 20:10: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 UAA00456 for ; Wed, 19 May 2004 20:10: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 1BQb8N-00004Q-6i for tcpm-web-archive@ietf.org; Wed, 19 May 2004 20:10:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQb7V-0007m5-00 for tcpm-web-archive@ietf.org; Wed, 19 May 2004 20:09:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQb6Z-0007gD-00 for tcpm-web-archive@ietf.org; Wed, 19 May 2004 20:08:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQb4T-00039o-EB; Wed, 19 May 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 1BQazo-0001rx-Er for tcpm@optimus.ietf.org; Wed, 19 May 2004 20:01: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 UAA00136 for ; Wed, 19 May 2004 20:01: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 1BQazm-0006qb-F7 for tcpm@ietf.org; Wed, 19 May 2004 20:01:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQayq-0006jU-00 for tcpm@ietf.org; Wed, 19 May 2004 20:00:12 -0400 Received: from scmail.arc.com ([63.206.101.3]) by ietf-mx with esmtp (Exim 4.12) id 1BQaxu-0006WC-00 for tcpm@ietf.org; Wed, 19 May 2004 19:59:14 -0400 Received: from scexch01.arc.com (scexch01 [192.9.200.149]) by scmail.arc.com (8.12.8/8.12.5) with SMTP id i4JNeVux024958 for ; Wed, 19 May 2004 16:40:31 -0700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Date: Wed, 19 May 2004 16:58:45 -0700 Importance: normal Priority: normal Message-ID: <2EFAFC388B9C4C48B581846AEC20A020016CA884@scexch01.arc.com> Thread-Topic: tcpsecure: when to expect draft-01? Thread-Index: AcQ9/ThGaLOIOwTCSRSsISwe8XtD5A== From: "Charlet, Ricky" To: Content-Transfer-Encoding: 7bit Subject: [tcpm] tcpsecure: when to expect draft-01? 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 Howdy, I'm trying to implement draft-ietf-tcpm-tcpsecure-00.txt. There have been criticism on the list and seemingly, the working group is taking some of them to heart. Also, there have been suggestions that a next draft is imminent. Can someone offer prognostications about when draft-01 will be published and at what points it may vary from draft-00? Thanks in advance --- Ricky Charlet Ricky.Charlet@arc.com USA 831.466.4968 ----------------------------------------------------------- Unless otherwise expressly stated, this message does not create or vary any contractual relationship between you and ARC International. The contents of this e-mail may be confidential and if you have received it in error, please delete it from your system, destroy any hard copies and telephone the above number. Incoming emails to ARC may be subject to monitoring other than by the addressee. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Wed May 19 21:56:12 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 VAA05046 for ; Wed, 19 May 2004 21:56: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 1BQchz-0001ot-Ki for tcpm-archive@odin.ietf.org; Wed, 19 May 2004 21:50:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4K1ott7006990 for tcpm-archive@odin.ietf.org; Wed, 19 May 2004 21:50:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQcWm-0007fb-E0 for tcpm-web-archive@optimus.ietf.org; Wed, 19 May 2004 21:39: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 VAA04456 for ; Wed, 19 May 2004 21:39: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 1BQcWj-0003n3-EK for tcpm-web-archive@ietf.org; Wed, 19 May 2004 21:39:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQcVo-0003fY-00 for tcpm-web-archive@ietf.org; Wed, 19 May 2004 21:38:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQcVD-0003XZ-00 for tcpm-web-archive@ietf.org; Wed, 19 May 2004 21:37:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQcRd-0006Qq-B8; Wed, 19 May 2004 21:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQcO6-0005dG-7Q for tcpm@optimus.ietf.org; Wed, 19 May 2004 21:30: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 VAA03913 for ; Wed, 19 May 2004 21:30: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 1BQcO3-0002Rd-De for tcpm@ietf.org; Wed, 19 May 2004 21:30:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQcN5-0002J7-00 for tcpm@ietf.org; Wed, 19 May 2004 21:29:19 -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 1BQcMM-00027T-00 for tcpm@ietf.org; Wed, 19 May 2004 21:28:35 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 19 May 2004 17:33:58 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i4K1S3De028153; Wed, 19 May 2004 18:28:03 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id AUH59753; Wed, 19 May 2004 18:28:02 -0700 (PDT) Message-ID: <40AC09A1.6090605@cisco.com> Date: Wed, 19 May 2004 21:28: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: Sandy Murphy CC: tcpm@ietf.org Subject: Re: [tcpm] blind data injection References: <200405191503.i4JF3kXZ029657@tislabs.com> In-Reply-To: <200405191503.i4JF3kXZ029657@tislabs.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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sandy: One thing we have found in our testing is that when data is injected and sits in a reassmebly buffer .. once the peer catches up and bridges the "injected" portion an ack war begins... For example A Z (rcv.nxt =200) Evil-guy-----Inject(2200 - 3200)------------> Now when A sends --------------------Data(200-2210)----------------------------------> Z sends (XX:) <---------------------------------ACK(3200) A says.. hey my peer is messed up and sends ------------------------ACK(x,2210)-------------------------_> Z says .. hey my peer is messed up and sends goto XX; This continues until the connection falls apart. Sometimes if A is sending lots of data it then gets past 3200 in my example and the injected data bubbles up.. but as you point out most apps will then get out of sync.. and depending on the app it may abort the connection... since it is usually reading a framed message size and the framing is now hosed and it does not know how to recover... of course mileage may vary .. R Sandy Murphy wrote: >The tcpsecure draft notes that data can be accepted by the TCP >implementation if any of the segment's bytes fall within the receive >window, not just at the left edge of the window. But TCP does not >require that out-of-order segments are buffered. I don't know how >ubiquitous it is for implementations to do the buffering. (RFC1122 >makes it a "should".) I can find no place where the TCP spec speaks >of what to do if a later arriving segment overlaps a previously queued >out-of-order segment. I can see the possibility that the later >arriving data could overwrite the previously queued data. Unix tcp >code I've looked at seems to let recently arrived segments overwrite >succeeding queued out-of-order segments (but queued preceding segments >overwrite the recently arrived segments). > >That would mean that the eventual delivery of bogus injected data to >the application would depend on the spacing of the arrival of any real >segments covering the same sequence number space as the bogus injected >data. A blind attacker could not predict what if any of the bogus >injected data would be delivered to the application. > >Furthermore, any application level framing could cause any bogus >injected data that did manage to be delivered to fail the parse step >in the application. So BGP, in particular, which has such framing, >would be in much less danger of accepting the bogus data. It would be >much more likely that any injected data that did manage to reach BGP >would not pass the parsing and would cause the connection to abort. >That's not a good result, but it's better than accepting bogus >injected data. > >--Sandy > >_______________________________________________ >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 May 19 22:01:21 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 WAA05296 for ; Wed, 19 May 2004 22:01:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQcmK-0002Pd-Fe for tcpm-archive@odin.ietf.org; Wed, 19 May 2004 21:55:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4K1tOKF009267 for tcpm-archive@odin.ietf.org; Wed, 19 May 2004 21:55:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQchT-0001Tb-Px for tcpm-web-archive@optimus.ietf.org; Wed, 19 May 2004 21:50: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 VAA04804 for ; Wed, 19 May 2004 21:50: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 1BQchQ-0005Fo-V6 for tcpm-web-archive@ietf.org; Wed, 19 May 2004 21:50:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQcgX-00057I-00 for tcpm-web-archive@ietf.org; Wed, 19 May 2004 21:49:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQcft-0004z9-00 for tcpm-web-archive@ietf.org; Wed, 19 May 2004 21:48:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQcUX-0006xO-9Z; Wed, 19 May 2004 21:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQcPw-00062m-Ua for tcpm@optimus.ietf.org; Wed, 19 May 2004 21:32: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 VAA04004 for ; Wed, 19 May 2004 21:32: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 1BQcPu-0002jt-00 for tcpm@ietf.org; Wed, 19 May 2004 21:32:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQcOq-0002Z8-00 for tcpm@ietf.org; Wed, 19 May 2004 21:31:09 -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 1BQcNt-0002K5-00 for tcpm@ietf.org; Wed, 19 May 2004 21:30:10 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 19 May 2004 17:37:13 +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 i4K1Tc8R019572; Wed, 19 May 2004 18:29:38 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id AUH59873; Wed, 19 May 2004 18:29:37 -0700 (PDT) Message-ID: <40AC0A00.2090609@cisco.com> Date: Wed, 19 May 2004 21:29:36 -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: Anantha Ramaiah CC: "Leino, Tammy" , "'tcpm@ietf.org'" Subject: Re: [tcpm] Question regarding section 4.2 of draft-ietf-tcpm-tcpsecure-00.txt References: <40AA90D7.3FA988B@cisco.com> In-Reply-To: <40AA90D7.3FA988B@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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Anantha Ramaiah wrote: >Leino, > >"Leino, Tammy" wrote: > > >>Network Working Group Members, >> >>I have been studying this Internet draft and have consulted RFC 793 to help >>resolve my lack of understanding of section 4.2, but my problem still >>persists. >> >>Section 4.2 gives the solution to add the following additional check to any >>incoming segment: >> >>((SND.UNA - MAX.SND.WND) <= SEG.ACK < SND.NXT) >> >> > >I think this looks like a typo. It should read as : >((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT). We are not changing >the existing RFC behaviour for the right side SND.UNA. >Thanks for pointing it out. > >Randall, this needs to be added to the list of changes for rev 2... > Will do.. still waiting for input from Mitesh and Amol too if I remember right.. R > >-Anantha > > >>It goes on to explain MAX.SND.WND and the relevance of this change. >>However, RFC 793 specifies that an acceptable ack falls into the following >>range: >> >>SND.UNA < SEG.ACK =< SND.NXT >> >>My question is why has the equality condition been removed from the SEG.ACK >>=< SND.NXT portion of the check as specified in RFC 793? >> >>Thank you for your help in this matter. >> >>Sincerely, >>Tammy Leino >> >>_______________________________________________ >>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 Wed May 19 22:03:09 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 WAA05397 for ; Wed, 19 May 2004 22:03: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 1BQcrd-0003wa-LS for tcpm-archive@odin.ietf.org; Wed, 19 May 2004 22:00:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4K20r1R015153 for tcpm-archive@odin.ietf.org; Wed, 19 May 2004 22:00:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQckA-0002BO-Fn for tcpm-web-archive@optimus.ietf.org; Wed, 19 May 2004 21:53: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 VAA04904 for ; Wed, 19 May 2004 21:53: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 1BQck7-0005ex-Hb for tcpm-web-archive@ietf.org; Wed, 19 May 2004 21:53:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQcj9-0005WU-00 for tcpm-web-archive@ietf.org; Wed, 19 May 2004 21:52:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQci8-0005Hv-00 for tcpm-web-archive@ietf.org; Wed, 19 May 2004 21:51:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQcXR-0007kK-2P; Wed, 19 May 2004 21:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQcTm-0006iZ-L0 for tcpm@optimus.ietf.org; Wed, 19 May 2004 21:36: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 VAA04324 for ; Wed, 19 May 2004 21:36: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 1BQcTj-0003OH-M8 for tcpm@ietf.org; Wed, 19 May 2004 21:36:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQcSu-0003Gz-00 for tcpm@ietf.org; Wed, 19 May 2004 21:35:21 -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 1BQcS2-0002zt-00 for tcpm@ietf.org; Wed, 19 May 2004 21:34:26 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i4K1XsDe004337; Wed, 19 May 2004 18:33:54 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id AUH60167; Wed, 19 May 2004 18:33:52 -0700 (PDT) Message-ID: <40AC0B00.4010205@cisco.com> Date: Wed, 19 May 2004 21:33:52 -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: "Charlet, Ricky" CC: tcpm@ietf.org Subject: Re: [tcpm] tcpsecure: when to expect draft-01? References: <2EFAFC388B9C4C48B581846AEC20A020016CA884@scexch01.arc.com> In-Reply-To: <2EFAFC388B9C4C48B581846AEC20A020016CA884@scexch01.arc.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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ricky: I can't give you an exact date... but I can give you a ball park... I am waiting on inputs from a couple of the co-authors.. and I just got one more to-do from the list (above)... Sooo... I would hope to get something out by the end of next week.. sigh.. R Charlet, Ricky wrote: >Howdy, > > I'm trying to implement draft-ietf-tcpm-tcpsecure-00.txt. There >have been criticism on the list and seemingly, the working group is >taking some of them to heart. Also, there have been suggestions that a >next draft is imminent. > > Can someone offer prognostications about when draft-01 will be >published and at what points it may vary from draft-00? > > >Thanks in advance > >--- >Ricky Charlet >Ricky.Charlet@arc.com >USA 831.466.4968 > >----------------------------------------------------------- >Unless otherwise expressly stated, this message does not >create or vary any contractual relationship between you and >ARC International. The contents of this e-mail may be >confidential and if you have received it in error, please >delete it from your system, destroy any hard copies and >telephone the above number. Incoming emails to ARC may be >subject to monitoring other than by the addressee. > >_______________________________________________ >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 May 19 23:35: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 XAA10155 for ; Wed, 19 May 2004 23:35: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 1BQeJa-00080s-5I for tcpm-archive@odin.ietf.org; Wed, 19 May 2004 23:33:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4K3XoYb030802 for tcpm-archive@odin.ietf.org; Wed, 19 May 2004 23:33:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQeGC-0007Mk-Ed for tcpm-web-archive@optimus.ietf.org; Wed, 19 May 2004 23:30: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 XAA09810 for ; Wed, 19 May 2004 23:30: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 1BQeGA-0004PQ-Fa for tcpm-web-archive@ietf.org; Wed, 19 May 2004 23:30:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQeFH-0004Fe-00 for tcpm-web-archive@ietf.org; Wed, 19 May 2004 23:29:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQeER-000476-00 for tcpm-web-archive@ietf.org; Wed, 19 May 2004 23:28:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQeAA-00064a-Nt; Wed, 19 May 2004 23:24:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQe5A-0004oQ-4K for tcpm@optimus.ietf.org; Wed, 19 May 2004 23:18: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 XAA09014 for ; Wed, 19 May 2004 23:18: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 1BQe58-0002SX-2x for tcpm@ietf.org; Wed, 19 May 2004 23:18:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQe3K-00024W-00 for tcpm@ietf.org; Wed, 19 May 2004 23:17:05 -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 1BQe1L-0001gQ-00 for tcpm@ietf.org; Wed, 19 May 2004 23:14:59 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 19 May 2004 19:22:03 +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 i4K3ER8R026720; Wed, 19 May 2004 20:14:28 -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 ATI53785; Wed, 19 May 2004 20:13:40 -0700 (PDT) Date: Wed, 19 May 2004 20:14:27 -0700 (PDT) From: Mitesh Dalal To: Sandy Murphy cc: tcpm@ietf.org Subject: Re: [tcpm] SYN's in draft-ietf-tcpm-tcpsecure.txt :-) In-Reply-To: <200405191445.i4JEjEcu028787@tislabs.com> Message-ID: References: <200405191445.i4JEjEcu028787@tislabs.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 Wed, 19 May 2004, Sandy Murphy wrote: > There's been a lot of discussion about the modifications to the RST > processing, but not much about the modifications to the SYN processing. > > NOTE: All of the following is predicated on an assumption of just what > exactly is meant by "send an ACK segment to the peer but before > sending the ACK segment subtract one from value being acknowledged." > and "send an ACK segment to the peer." I'm presuming this means send > and > . sorry for late reply. somehow missed it earlier. The suggestion is to only send rcv.nxt-1 and not 2 ACKs if that is what you are saying above. Similar points as below were brought to light on the first day of the draft itself (April 20 tcpm archive). > If that's not correct, just stop reading right here. > > Oh, and by the way. The draft should really spell this out. > > The 793 SYN processing produces the desired result if a crashed host > tries to re-connect to its previous partner - that is, the previous > partner's half-open connection would close. But it produces an > undesirable result if an old SYN arrives - that is, old delayed SYN's > could blow away a perfectly healthy connection if the SEQ is in the > window. > > The new processing produces the desirable result that old SYN's in the > window do nothing to an ESTABLISHED connection. But it appears to me > to have a less desirable result if a crashed host attempts to > reconnect to its previous partner. > > If the receiver, A, is in state A.ESTABLISHED and gets a SYN with > SEQ=A.RCV.NXT, then it sends a > . > If this is a current SYN, then the other end, B, is in state > B.SYN-SENT and the SEQ on its SYN is equal to B.ISS. So > ACK=A.RCV.NXT-1 is less than B.ISS. So B sends > . > A notices that this is out of its window. Ordinarily, this would make > A send an ACK with SEQ=SND.NXT and ACK=RCV.NXT, but because the packet > has the RST bit set, it just drops the packet. So B, the SYN-SENT > side, will retransmit the SYN (causing repeats of this same behavior) > until it times out. > > If the SYN's SEQ > A.RCV.NXT, then the ACK is sent with ACK=A.RCV.NXT > and the RST is sent with SEQ=A.RCV.NXT which will cause the connection > to close (baring data in the pipe advancing A.RCV.NXT, but eventually > things should catch up). So this behavior only occurs when > SEQ=A.RCV.NXT on the SYN. > as pointed out by Ananth (April 20), this should apply for SEQ=RCV.NXT-1 and not SEQ=RCV.NXT as said in draft. For the later case, you continue to use ACK=RCV.NXT. What we are trying to avoid is send an ACK which will be valid to the remote end. Hence if we send an ACK with value RCV.NXT in response to an ISN of RCV.NXT-1, this ACK will be acceptable which we are trying to avoid. Sending an ACK with RCV.NXT for a SYN of RCV.NXT should be fine and that is what we are proposing. Although as you have mentioned above, for the case where we send rcv.nxt-1 ack and the SYN side then sends us a RST with rcv.nxt-1 might not be acceptable in some implementations that do not have keepalive mechanism. So letting the remote end time out should be fine as this is a very rare occurence rather than clean up the TCB. However, if the WG votes for the later that should be fine too. Thx Mitesh > Could someone confirm that I'm interpreting this (both the 793 spec > and the new draft) correctly? > > If I'm correct, does this behavior bother anyone? > > --Sandy > > P.S. > > I've always thought that the 793 behavior when an SYN in the window > was received was potentially dangerous. > > If the SYN is a current SYN from a partner who has crashed and > resumed, then resetting the connection is the right thing to do. But > if this is an old duplicate SYN (in the window) from some previous > connection attempt, then its arrival blows away a healthy connection. > That did not seem like a good thing. > > Long ago, when I was studying this, it wasn't that big a deal. The > most likely scenario was that one connection attempt failed, followed > immediately by one that succeeded, and an old SYN from the first > attempt arrived late. Given that ISS's at the time typically were > chosen as increments over previous values, it would not be likely that > the ISS of the old SYN would be within the receive window of the new > connection. Unless the old SYN was delayed so long that the sequence > number had wrapped - hardly likely. > > But now that the ISS's are randomly chosen, you've got a > (windowsize/(2**32)) chance of the old SYN being within the window of > the new connection (less chance if successive connection attempts are > delayed by a long-ish time to let old SYN packets die). > > So I'm glad to see some modification of the SYN-in-the-window processing. > I'm just not sure this is the best one. > > _______________________________________________ > 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 May 20 00:11: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 AAA11239 for ; Thu, 20 May 2004 00:11: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 1BQenx-0006Y0-4s for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 00:05:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4K45DkE025169 for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 00:05:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQedO-00049X-6y for tcpm-web-archive@optimus.ietf.org; Wed, 19 May 2004 23:54: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 XAA10606 for ; Wed, 19 May 2004 23:54: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 1BQedM-0007hL-22 for tcpm-web-archive@ietf.org; Wed, 19 May 2004 23:54:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQecQ-0007ZG-00 for tcpm-web-archive@ietf.org; Wed, 19 May 2004 23:53:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQeby-0007RQ-00 for tcpm-web-archive@ietf.org; Wed, 19 May 2004 23: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 1BQeNe-0000ea-AV; Wed, 19 May 2004 23:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQeK0-00082c-E4 for tcpm@optimus.ietf.org; Wed, 19 May 2004 23:34: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 XAA10062 for ; Wed, 19 May 2004 23:34: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 1BQeJy-00052S-DD for tcpm@ietf.org; Wed, 19 May 2004 23:34:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQeJ2-0004tJ-00 for tcpm@ietf.org; Wed, 19 May 2004 23:33:17 -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 1BQeI8-0004bv-00 for tcpm@ietf.org; Wed, 19 May 2004 23:32:20 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 19 May 2004 19:39:24 +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 i4K3VnDe024597; Wed, 19 May 2004 20:31: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 ATI54426; Wed, 19 May 2004 20:31:02 -0700 (PDT) Date: Wed, 19 May 2004 20:31:48 -0700 (PDT) From: Mitesh Dalal To: "Randall Stewart (cisco)" cc: "Charlet, Ricky" , tcpm@ietf.org Subject: Re: [tcpm] tcpsecure: when to expect draft-01? In-Reply-To: <40AC0B00.4010205@cisco.com> Message-ID: References: <2EFAFC388B9C4C48B581846AEC20A020016CA884@scexch01.arc.com> <40AC0B00.4010205@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 sorry for the delay in the second draft. We are trying to find more information to put into the draft that should hopefully satisfy the WG. To answer the second part of your earlier question, the second draft should cover: 1. alternate solutions that are known today: MD5, IPSec, port randomization. This will only be quoted for purpose of reference and not to make a suggestion as such as some folks have pointed out that MD5 was intended for BGP and is not generic enough. 2. Correct typos. a. in the SYN section from RCV.NXT == SEG.SEQ to RCV.NXT -1 == SEG.SEQ b. in 4.2, a missing = as pointed yesterday. 3. An appendix describing scenarios where the proposal might not work. a. middleboxes that cache RST. b. middleboxes that compute RST to be at the higher end of the rcv.wnd. c. RST/ACK war for dropped/delayed packets. 4. More explanantion of scenarios that make the solution to likely happen with todays implementations. Anything else the WG would like to see being added to the draft ? thx Mitesh On Wed, 19 May 2004, Randall Stewart (cisco) wrote: > Ricky: > > I can't give you an exact date... but I can give > you a ball park... I am waiting on inputs from a > couple of the co-authors.. and I just got one more > to-do from the list (above)... > > Sooo... I would hope to get something out by > the end of next week.. sigh.. > > R > > Charlet, Ricky wrote: > > >Howdy, > > > > I'm trying to implement draft-ietf-tcpm-tcpsecure-00.txt. There > >have been criticism on the list and seemingly, the working group is > >taking some of them to heart. Also, there have been suggestions that a > >next draft is imminent. > > > > Can someone offer prognostications about when draft-01 will be > >published and at what points it may vary from draft-00? > > > > > >Thanks in advance > > > >--- > >Ricky Charlet > >Ricky.Charlet@arc.com > >USA 831.466.4968 > > > >----------------------------------------------------------- > >Unless otherwise expressly stated, this message does not > >create or vary any contractual relationship between you and > >ARC International. The contents of this e-mail may be > >confidential and if you have received it in error, please > >delete it from your system, destroy any hard copies and > >telephone the above number. Incoming emails to ARC may be > >subject to monitoring other than by the addressee. > > > >_______________________________________________ > >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 Thu May 20 00:12: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 AAA11274 for ; Thu, 20 May 2004 00:12: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 1BQeoT-0006jf-JN for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 00:05:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4K45j7f025886 for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 00:05:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQegM-0004fl-47 for tcpm-web-archive@optimus.ietf.org; Wed, 19 May 2004 23:57: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 XAA10679 for ; Wed, 19 May 2004 23:57: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 1BQegJ-0000Km-Sn for tcpm-web-archive@ietf.org; Wed, 19 May 2004 23:57:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQefO-0000Bo-00 for tcpm-web-archive@ietf.org; Wed, 19 May 2004 23:56:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQeeX-000037-00 for tcpm-web-archive@ietf.org; Wed, 19 May 2004 23:55:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQecB-0003EA-HO; Wed, 19 May 2004 23: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 1BQeO2-0000hn-Vn for tcpm@optimus.ietf.org; Wed, 19 May 2004 23:38: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 XAA10235 for ; Wed, 19 May 2004 23:38: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 1BQeNr-0005dW-IP for tcpm@ietf.org; Wed, 19 May 2004 23:38:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQeMt-0005Up-00 for tcpm@ietf.org; Wed, 19 May 2004 23:37:15 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BQeM1-0005EX-00 for tcpm@ietf.org; Wed, 19 May 2004 23:36:21 -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 i4K3ZIBm027352; Wed, 19 May 2004 20:35:18 -0700 (PDT) (envelope-from pgoyette@juniper.net) Received: from pgoyette600 ([172.24.236.4]) by merlot.juniper.net (8.11.3/8.11.3) with SMTP id i4K3ZIJ77017; Wed, 19 May 2004 20:35:18 -0700 (PDT) (envelope-from pgoyette@juniper.net) From: "Paul Goyette" To: "Mitesh Dalal" , "Sandy Murphy" Cc: Subject: RE: [tcpm] SYN's in draft-ietf-tcpm-tcpsecure.txt :-) Date: Wed, 19 May 2004 20:35:16 -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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: 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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mitesh, > > NOTE: All of the following is predicated on an assumption of just what > > exactly is meant by "send an ACK segment to the peer but before > > sending the ACK segment subtract one from value being acknowledged." > > and "send an ACK segment to the peer." I'm presuming this means send > > and > > . > > sorry for late reply. somehow missed it earlier. The > suggestion is to only send rcv.nxt-1 and not 2 ACKs if that > is what you are saying above. Similar points as below were > brought to light on the first day of the draft itself > (April 20 tcpm archive). If I remember correctly, step 3B is going to be changed to B) If the SYN bit is set and the sequence number is exactly one less than the next expected sequence (SEG.SEQ == (RCV.NXT - 1)) then send an ACK segment to the peer but before sending the ACK segment subtract one from the value being acknowledged i.e. the value being acknowledged should be (RCV.NXT - 2) or (SEG.SEQ - 1). -----Original Message----- From: tcpm-admin@ietf.org [mailto:tcpm-admin@ietf.org]On Behalf Of Mitesh Dalal Sent: Wednesday, May 19, 2004 8:14 PM To: Sandy Murphy Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN's in draft-ietf-tcpm-tcpsecure.txt :-) On Wed, 19 May 2004, Sandy Murphy wrote: _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 20 02:36:08 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 CAA00926 for ; Thu, 20 May 2004 02:36: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 1BQh9H-0006r2-HD for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 02:35:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4K6ZNPg026342 for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 02:35:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQh6N-0006Pp-Cd for tcpm-web-archive@optimus.ietf.org; Thu, 20 May 2004 02:32: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 CAA00655 for ; Thu, 20 May 2004 02: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 1BQh6J-0001S2-Nb for tcpm-web-archive@ietf.org; Thu, 20 May 2004 02:32:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQh5M-0001Ic-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 02:31:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQh4S-00019Y-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 02:30:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQh0D-0005Dn-Hs; Thu, 20 May 2004 02: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 1BQgxg-0003vL-6I for tcpm@optimus.ietf.org; Thu, 20 May 2004 02:23: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 CAA00279 for ; Thu, 20 May 2004 02:23: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 1BQgxc-0007lQ-N0 for tcpm@ietf.org; Thu, 20 May 2004 02:23:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQgwi-0007cf-00 for tcpm@ietf.org; Thu, 20 May 2004 02:22:25 -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 1BQgwX-0007Tp-00 for tcpm@ietf.org; Thu, 20 May 2004 02:22:13 -0400 Received: from ananth-u5.cisco.com (ananth-u5.cisco.com [128.107.162.225]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i4K6LgfA025657; Wed, 19 May 2004 23:21:42 -0700 (PDT) Date: Wed, 19 May 2004 23:21:42 -0700 (PDT) From: Anantha Ramaiah To: Mitesh Dalal cc: "Randall Stewart (cisco)" , "Charlet, Ricky" , tcpm@ietf.org Subject: Re: [tcpm] tcpsecure: when to expect draft-01? In-Reply-To: Message-ID: References: <2EFAFC388B9C4C48B581846AEC20A020016CA884@scexch01.arc.com> <40AC0B00.4010205@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.1 required=5.0 tests=AWL autolearn=no version=2.60 Mitesh, On Wed, 19 May 2004, Mitesh Dalal wrote: > sorry for the delay in the second draft. We are trying to > find more information to put into the draft that should > hopefully satisfy the WG. To answer the second part > of your earlier question, the second draft should cover: > > 1. alternate solutions that are known today: MD5, IPSec, > port randomization. This will only be quoted for purpose Do you want to tag some of these as "alternate solutions".? I would just mention these are alternate methods which can be used to alleviate these type of attacks with varying degrees, merits and demerits.. (briefly) All I am pointing out is the current proposal should be viewed as doing whatever possible with less changes for making TCP protocol robust to these type of attacks in a standalone manner. > of reference and not to make a suggestion as such as > some folks have pointed out that MD5 was intended for BGP > and is not generic enough. > > 2. Correct typos. > a. in the SYN section from RCV.NXT == SEG.SEQ to RCV.NXT -1 == SEG.SEQ > b. in 4.2, a missing = as pointed yesterday. > > 3. An appendix describing scenarios where the proposal > might not work. > a. middleboxes that cache RST. > b. middleboxes that compute RST to be at the higher > end of the rcv.wnd. > c. RST/ACK war for dropped/delayed packets. What is the general rule of thumb for any TCP extension written today? Should it strive for compliance with middle boxes? probably not. May be we can just mention some scenarios where the solution is likely to have some issues? -Anantha > > 4. More explanantion of scenarios that make the solution > to likely happen with todays implementations. > > Anything else the WG would like to see being added > to the draft ? > > thx > Mitesh > > On Wed, 19 May 2004, Randall Stewart (cisco) wrote: > > > Ricky: > > > > I can't give you an exact date... but I can give > > you a ball park... I am waiting on inputs from a > > couple of the co-authors.. and I just got one more > > to-do from the list (above)... > > > > Sooo... I would hope to get something out by > > the end of next week.. sigh.. > > > > R > > > > Charlet, Ricky wrote: > > > > >Howdy, > > > > > > I'm trying to implement draft-ietf-tcpm-tcpsecure-00.txt. There > > >have been criticism on the list and seemingly, the working group is > > >taking some of them to heart. Also, there have been suggestions that a > > >next draft is imminent. > > > > > > Can someone offer prognostications about when draft-01 will be > > >published and at what points it may vary from draft-00? > > > > > > > > >Thanks in advance > > > > > >--- > > >Ricky Charlet > > >Ricky.Charlet@arc.com > > >USA 831.466.4968 > > > > > >----------------------------------------------------------- > > >Unless otherwise expressly stated, this message does not > > >create or vary any contractual relationship between you and > > >ARC International. The contents of this e-mail may be > > >confidential and if you have received it in error, please > > >delete it from your system, destroy any hard copies and > > >telephone the above number. Incoming emails to ARC may be > > >subject to monitoring other than by the addressee. > > > > > >_______________________________________________ > > >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 > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 20 07:22:37 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 HAA12285 for ; Thu, 20 May 2004 07:22: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 1BQlY7-0005VR-OQ for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 07:17:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KBHJuL021163 for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 07:17:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQlWc-0005Cb-1T for tcpm-web-archive@optimus.ietf.org; Thu, 20 May 2004 07: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 HAA11800 for ; Thu, 20 May 2004 07:15: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 1BQlWb-0005YW-JK for tcpm-web-archive@ietf.org; Thu, 20 May 2004 07:15:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQlVi-0005LW-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 07:14:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQlV3-00059D-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 07: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 1BQlKa-0002TF-PA; Thu, 20 May 2004 07:03:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQkqw-0006FL-4d for tcpm@optimus.ietf.org; Thu, 20 May 2004 06:32: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 GAA10148 for ; Thu, 20 May 2004 06:32: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 1BQkqs-0004tk-4y for tcpm@ietf.org; Thu, 20 May 2004 06:32:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQkpw-0004hf-00 for tcpm@ietf.org; Thu, 20 May 2004 06:31:41 -0400 Received: from mail.enyo.de ([212.9.189.167]) by ietf-mx with esmtp (Exim 4.12) id 1BQkp3-0004VC-00 for tcpm@ietf.org; Thu, 20 May 2004 06:30: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 1BQkou-0005is-Vd; Thu, 20 May 2004 12:30:36 +0200 Received: from fw by deneb with local (Exim 4.34) id 1BQkot-00016E-VA; Thu, 20 May 2004 12:30:36 +0200 To: Mitesh Dalal Cc: "Randall Stewart (cisco)" , "Charlet, Ricky" , tcpm@ietf.org Subject: Re: [tcpm] tcpsecure: when to expect draft-01? References: <2EFAFC388B9C4C48B581846AEC20A020016CA884@scexch01.arc.com> <40AC0B00.4010205@cisco.com> From: Florian Weimer Date: Thu, 20 May 2004 12:30:35 +0200 In-Reply-To: (Mitesh Dalal's message of "Wed, 19 May 2004 20:31:48 -0700 (PDT)") Message-ID: <87n0439yr8.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: > 1. alternate solutions that are known today: MD5, IPSec, > port randomization. This will only be quoted for purpose > of reference and not to make a suggestion as such as > some folks have pointed out that MD5 was intended for BGP > and is not generic enough. IPsec without ISAKMP, please. ISAKMP is probably not robust enough (think of all the recent DoS attacks). > Anything else the WG would like to see being added > to the draft ? At the minimum, a rate limit for the new ACKs is required (i.e. MUST, not MAY). Mentioning this risk in some appendix isn't enough. However, I still believe that the proposal is fundamentally flawed because it does nothing to prevent other forms of blind injection attacks. For just one or two aspects of the issue, it's not really worth the trouble, IMHO. There were some proposals that the draft should not proceed as a WG draft. What has happened to that discussion? -- Current mail filters: many dial-up/DSL/cable modem hosts, and the following domains: bigpond.com, di-ve.com, hotmail.com, jumpy.it, libero.it, netscape.net, postino.it, simplesnet.pt, spymac.com, tatanova.com, tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr, yahoo.com. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 20 12:35:36 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 MAA29982 for ; Thu, 20 May 2004 12:35: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 1BQqAC-0002SK-QJ for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 12:12:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KGCutC009440 for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 12:12:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQpoF-0002Nu-3O for tcpm-web-archive@optimus.ietf.org; Thu, 20 May 2004 11: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 LAA26381 for ; Thu, 20 May 2004 11:50: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 1BQpoD-0007He-Uk for tcpm-web-archive@ietf.org; Thu, 20 May 2004 11:50:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQpmB-0006tv-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 11:48:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQpkS-0006WO-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 11:46:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQp87-0004l8-PW; Thu, 20 May 2004 11:06:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQp0Q-0003Gn-TU for tcpm@optimus.ietf.org; Thu, 20 May 2004 10:58: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 KAA21889 for ; Thu, 20 May 2004 10:58: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 1BQp0O-0005Le-9Z for tcpm@ietf.org; Thu, 20 May 2004 10:58:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQozP-00057y-00 for tcpm@ietf.org; Thu, 20 May 2004 10:57:43 -0400 Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 1BQoyN-0004lp-00 for tcpm@ietf.org; Thu, 20 May 2004 10:56:39 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4KEs7nY011777 for ; Thu, 20 May 2004 10:54:07 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAQWaG_w; Thu, 20 May 04 10:54:06 -0400 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id i4KEtQOD003867; Thu, 20 May 2004 10:55:26 -0400 (EDT) Date: Thu, 20 May 2004 10:55:26 -0400 (EDT) From: Sandy Murphy Message-Id: <200405201455.i4KEtQOD003867@tislabs.com> To: mdalal@cisco.com Subject: Re: [tcpm] SYN's in draft-ietf-tcpm-tcpsecure.txt :-) Cc: sandy@tislabs.com, tcpm@ietf.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 >> There's been a lot of discussion about the modifications to the RST >> processing, but not much about the modifications to the SYN processing. >> >> NOTE: All of the following is predicated on an assumption of just what >> exactly is meant by "send an ACK segment to the peer but before >> sending the ACK segment subtract one from value being acknowledged." >> and "send an ACK segment to the peer." I'm presuming this means send >> and >> . > >sorry for late reply. somehow missed it earlier. The >suggestion is to only send rcv.nxt-1 and not 2 ACKs if that >is what you are saying above. Similar points as below were >brought to light on the first day of the draft itself >(April 20 tcpm archive). Gack! Sorry, I did check the archive, honest. I obviously just did not go back far enough. I actually sat on my writeup for two weeks, thinking that surely someone was going to mention this. Sanjay's message of Apr 20 addresses exactly my concern of needing to rely on timeouts. And, no, of course I don't mean sending two ACK's at the same time. The paragraph mentions sending ACK's in two different situations without specifics, I was trying to be specific about what those two ACK's might be. [So any chance that the draft could spell out the packets exactly, as in RFC793: or whatever?] >Although as you have mentioned above, for the case where we send rcv.nxt-1 >ack and the SYN side then sends us a RST with rcv.nxt-1 might not be >acceptable in some implementations that do not have keepalive mechanism. Sending an ACK with a value less than RCV.NXT, whether prompted by a SYN or a SYN, means that any resultant RST will be dropped. If the SYN is an old duplicate, you don't really need to do anything. And if the SYN is a current SYN (with SEQ=RCV.NXT-1), then sending the ACK with RCV.NXT is undesirable (maybe - see my comment below) and sending the ACK with anything less than RCV.NXT results in a livelock until timeout. So here's a radical suggestion: how about doing nothing? And then there are the revised suggestions for dealing with the SEQ=RCV.NXT-1 case: From pgoyette@juniper.net: > B) If the SYN bit is set and the sequence number is exactly one less > than the next expected sequence (SEG.SEQ == (RCV.NXT - 1)) then > send an ACK segment to the peer but before sending the ACK segment > subtract one from the value being acknowledged i.e. the value > being acknowledged should be (RCV.NXT - 2) or (SEG.SEQ - 1). And from mdalal@cisco.com >What we are trying to avoid is send an ACK which will be valid to the >remote end. Hence if we send an ACK with value RCV.NXT in response to >an ISN of RCV.NXT-1, this ACK will be acceptable which we are trying >to avoid. Why not just rely on the "out of the window" mechanism of case A? I believe that the motivation for adjusting the ACK is to prevent a restarted peer in state SYN-SENT from believing that it's SYN was being ACK'd - and declaring the connection ESTABLISHED. But it seems to me that the behavior in state SYN-SENT will drop the segment if there is no SYN on the segment, even if the ACK is acceptable. So that's not really a problem. Right? Or maybe I've missed the point. --Sandy _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 20 14:10: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 OAA08049 for ; Thu, 20 May 2004 14:10: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 1BQrvr-0003OG-D0 for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 14:06:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KI6FHm013028 for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 14:06:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQrip-0008Ms-OC for tcpm-web-archive@optimus.ietf.org; Thu, 20 May 2004 13:52: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 NAA06741 for ; Thu, 20 May 2004 13:52: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 1BQrin-0004PB-Ga for tcpm-web-archive@ietf.org; Thu, 20 May 2004 13:52:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQrho-0004HL-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 13:51:45 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQrgq-0004Af-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 13:50:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQrdG-0006eE-28; Thu, 20 May 2004 13:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQrQz-0003YZ-A6 for tcpm@optimus.ietf.org; Thu, 20 May 2004 13:34: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 NAA05141 for ; Thu, 20 May 2004 13:34: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 1BQrQx-0002Ky-5C for tcpm@ietf.org; Thu, 20 May 2004 13:34:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQrOh-0001uD-00 for tcpm@ietf.org; Thu, 20 May 2004 13:32:00 -0400 Received: from scmail.arc.com ([63.206.101.3]) by ietf-mx with esmtp (Exim 4.12) id 1BQrLW-0001PG-00 for tcpm@ietf.org; Thu, 20 May 2004 13:28:42 -0400 Received: from scexch01.arc.com (scexch01 [192.9.200.149]) by scmail.arc.com (8.12.8/8.12.5) with SMTP id i4KH9pux014339 for ; Thu, 20 May 2004 10:09:51 -0700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Importance: normal Priority: normal Date: Thu, 20 May 2004 10:28:07 -0700 Message-ID: <2EFAFC388B9C4C48B581846AEC20A020016CA886@scexch01.arc.com> Thread-Topic: tcpsecure: what about FIN attacks? Thread-Index: AcQ+j9DaHXd+S9RRQumC9a9oCF1Fhw== From: "Charlet, Ricky" To: Content-Transfer-Encoding: 7bit Subject: [tcpm] tcpsecure: what about FIN attacks? 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 Howdy, draft-ietf-tcpm-tcpsecure-00.txt does not provide a discussion of defence against blind attackers sending FIN packets with good guesses for sequence numbers. Are FIN packets not a concern here? If not, why not? --- Ricky Charlet Ricky.Charlet@arc.com USA 831.466.4968 ----------------------------------------------------------- Unless otherwise expressly stated, this message does not create or vary any contractual relationship between you and ARC International. The contents of this e-mail may be confidential and if you have received it in error, please delete it from your system, destroy any hard copies and telephone the above number. Incoming emails to ARC may be subject to monitoring other than by the addressee. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 20 14:21: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 OAA08896 for ; Thu, 20 May 2004 14:21: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 1BQrzK-0004OK-C8 for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 14:09:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KI9oHD016871 for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 14:09:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQrqx-0001oS-Jm for tcpm-web-archive@optimus.ietf.org; Thu, 20 May 2004 14:01: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 OAA07563 for ; Thu, 20 May 2004 14:01: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 1BQrqv-0005LL-5p for tcpm-web-archive@ietf.org; Thu, 20 May 2004 14:01:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQrpt-0005FE-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 14:00:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQrpF-00059v-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 13:59:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQreM-000758-Lv; Thu, 20 May 2004 13:48:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQrU7-0004UY-PC for tcpm@optimus.ietf.org; Thu, 20 May 2004 13:37: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 NAA05667 for ; Thu, 20 May 2004 13:37: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 1BQrU5-0002qv-Jc for tcpm@ietf.org; Thu, 20 May 2004 13:37:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQrSc-0002bS-00 for tcpm@ietf.org; Thu, 20 May 2004 13:36:02 -0400 Received: from [170.210.17.130] (helo=libertad.frh.utn.edu.ar) by ietf-mx with esmtp (Exim 4.12) id 1BQrQk-00029w-00 for tcpm@ietf.org; Thu, 20 May 2004 13:34:07 -0400 Received: from fernando.gont.com.ar ([200.68.238.145]) by libertad.frh.utn.edu.ar (8.9.3/8.8.7) with ESMTP id PAA24092; Thu, 20 May 2004 15:04:33 -0400 Message-Id: <4.3.2.7.2.20040519175601.00c57e70@mail.daleclick.com> X-Sender: fgont@mail.daleclick.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 May 2004 14:05:46 -0300 To: mallman@icir.org, tcpm@ietf.org From: Fernando Gont Subject: Re: [tcpm] ATO i-d Cc: Ted Faber In-Reply-To: <20040517163911.D502677AA5C@guns.icir.org> 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:39 17/05/2004 -0400, you wrote: >Based on the postings on the list it seems to Ted and I that the >consensus is for this WG to take on the ATO internet-draft >(draft-eggert-tcpm-tcp-abort-timeout-option-00.txt). I think this statement does not make it clear we'll take on the issue of having TCP "negotiate" TCP User Timeouts, rather than on any specific proposal. 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 Thu May 20 14:21: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 OAA08914 for ; Thu, 20 May 2004 14:21: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 1BQrzL-0004Ox-Iy for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 14:09:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KI9pAE016914 for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 14:09:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQrri-00020K-N5 for tcpm-web-archive@optimus.ietf.org; Thu, 20 May 2004 14:01: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 OAA07635 for ; Thu, 20 May 2004 14: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 1BQrrg-0005Q7-EI for tcpm-web-archive@ietf.org; Thu, 20 May 2004 14:01:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQrql-0005KE-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 14:01:00 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQrpi-0005Dt-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 13:59:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQreN-00075o-OA; Thu, 20 May 2004 13:48:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQrUi-0004io-QJ for tcpm@optimus.ietf.org; Thu, 20 May 2004 13:38: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 NAA05744 for ; Thu, 20 May 2004 13:38: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 1BQrUg-0002xP-Hj for tcpm@ietf.org; Thu, 20 May 2004 13:38:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQrTd-0002mb-00 for tcpm@ietf.org; Thu, 20 May 2004 13:37:06 -0400 Received: from [170.210.17.130] (helo=libertad.frh.utn.edu.ar) by ietf-mx with esmtp (Exim 4.12) id 1BQrS7-0002RI-00 for tcpm@ietf.org; Thu, 20 May 2004 13:35:32 -0400 Received: from fernando.gont.com.ar ([200.68.238.145]) by libertad.frh.utn.edu.ar (8.9.3/8.8.7) with ESMTP id PAA24113 for ; Thu, 20 May 2004 15:09:28 -0400 Message-Id: <4.3.2.7.2.20040520140323.00de7810@mail.daleclick.com> X-Sender: fgont@mail.daleclick.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 May 2004 14:04:58 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [tcpm] I-D ACTION:draft-gont-tcpm-tcp-auto-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 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : TCP Adaptive User TimeOut (AUTO) Option Author(s) : F. Gont Filename : draft-gont-tcpm-tcp-auto-option-00.txt Pages : 8 Date : 2004-5-19 The original TCP specification (RFC 793) defines a "USER TIMEOUT" parameter that sets the policy as to when a user connection should be aborted. However, TCP provides no means of letting users suggest an abort policy to a remote peer dynamically. Even though a fixed policy may work well in many cases, there are a number of scenarios where a fixed USER TIMEOUT value may be inappropriate, and some means of setting the abort policy dynamically may be necessary for TCP to be used effectively in such scenarios. This document defines a new TCP option, which lets a TCP peer suggest a USER TIMEOUT value to a remote TCP during the connection-establishment phase, and modify it during the life of a connection, thus adapting TCP's connection-abort policy as necessary. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-gont-tcpm-tcp-auto-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-gont-tcpm-tcp-auto-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-gont-tcpm-tcp-auto-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. -- 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 Thu May 20 14:21: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 OAA08932 for ; Thu, 20 May 2004 14:21: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 1BQrzO-0004Q4-Ri for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 14:09:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KI9scu016984 for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 14:09:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQrsl-0002GO-2j for tcpm-web-archive@optimus.ietf.org; Thu, 20 May 2004 14:03: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 OAA07721 for ; Thu, 20 May 2004 14:03: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 1BQrsi-0005Vt-O0 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 14:03:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQrrq-0005RR-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 14:02:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQrrO-0005MO-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 14:01:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQrfB-0007I1-3N; Thu, 20 May 2004 13:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQrUv-0004lo-F3 for tcpm@optimus.ietf.org; Thu, 20 May 2004 13:38: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 NAA05765 for ; Thu, 20 May 2004 13:38: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 1BQrUt-0002yu-9n for tcpm@ietf.org; Thu, 20 May 2004 13:38:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQrTn-0002oR-00 for tcpm@ietf.org; Thu, 20 May 2004 13:37:15 -0400 Received: from [170.210.17.130] (helo=libertad.frh.utn.edu.ar) by ietf-mx with esmtp (Exim 4.12) id 1BQrSE-0002SH-00 for tcpm@ietf.org; Thu, 20 May 2004 13:35:39 -0400 Received: from fernando.gont.com.ar ([200.68.238.145]) by libertad.frh.utn.edu.ar (8.9.3/8.8.7) with ESMTP id PAA24116 for ; Thu, 20 May 2004 15:09:37 -0400 Message-Id: <4.3.2.7.2.20040520141222.00c77670@mail.daleclick.com> X-Sender: fgont@mail.daleclick.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 May 2004 14:22:20 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [tcpm] TCP Adaptive User TimeOut (AUTO) Option 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 Folks, I've submitted a draft entitled "TCP Adaptive User TimeOut (AUTO) Option". It's an alternative proposal on the issue of having TCP "negotiate" the USER TIMEOUT parameter. My proposal is to not really *negotiate* the USER TIMEOUT, but have TCPs "suggest" a value to be used for it. The option must sent during the connection-establishment phase in segments with the SYN control bit set (*only*), in a similar fashion to other TCP options (such as MSS). The option may also be used during the life of a connection, so that TCP peers can suggest a different USER TIMEOUT value to be used for the connection, adapting the USER TIMEOUT parameter to changing network conditions. I'd appreciate any comments on the draft. It can be found at: http://www.ietf.org/internet-drafts/draft-gont-tcpm-tcp-auto-option-00.txt -- 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 Thu May 20 14:22: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 OAA08999 for ; Thu, 20 May 2004 14:22: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 1BQrzu-0004Tu-0I for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 14:10:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KIAPUa017223 for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 14:10:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQrvW-0003Fa-QU for tcpm-web-archive@optimus.ietf.org; Thu, 20 May 2004 14: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 OAA07798 for ; Thu, 20 May 2004 14: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 1BQrvU-0005jf-Em for tcpm-web-archive@ietf.org; Thu, 20 May 2004 14:05:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQruX-0005eL-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 14:04:54 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQrtb-0005Zq-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 14:03:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQrfC-0007IX-Of; Thu, 20 May 2004 13: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 1BQrYG-0005Kv-UC for tcpm@optimus.ietf.org; Thu, 20 May 2004 13:41: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 NAA05939 for ; Thu, 20 May 2004 13:41: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 1BQrYE-0003Jc-OH for tcpm@ietf.org; Thu, 20 May 2004 13:41:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQrXL-0003Fg-00 for tcpm@ietf.org; Thu, 20 May 2004 13:40:55 -0400 Received: from [170.210.17.130] (helo=libertad.frh.utn.edu.ar) by ietf-mx with esmtp (Exim 4.12) id 1BQrWX-00037W-00 for tcpm@ietf.org; Thu, 20 May 2004 13:40:06 -0400 Received: from fernando.gont.com.ar ([200.68.238.145]) by libertad.frh.utn.edu.ar (8.9.3/8.8.7) with ESMTP id PAA24129; Thu, 20 May 2004 15:10:56 -0400 Message-Id: <4.3.2.7.2.20040520144059.00c458f0@mail.daleclick.com> X-Sender: fgont@mail.daleclick.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 May 2004 14:41:05 -0300 To: mallman@icir.org, tcpm@ietf.org From: Fernando Gont Subject: Re: [tcpm] ATO i-d Cc: Ted Faber 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:39 17/05/2004 -0400, you wrote: >Based on the postings on the list it seems to Ted and I that the >consensus is for this WG to take on the ATO internet-draft >(draft-eggert-tcpm-tcp-abort-timeout-option-00.txt). I think this statement does not make it clear we'll take on the issue of having TCP "negotiate" TCP User Timeouts, rather than on any specific proposal. 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 Thu May 20 14:22: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 OAA09016 for ; Thu, 20 May 2004 14:22: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 1BQrzu-0004UT-O5 for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 14:10:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KIAQEj017255 for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 14:10:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQrvm-0003Hh-T0 for tcpm-web-archive@optimus.ietf.org; Thu, 20 May 2004 14:06: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 OAA07839 for ; Thu, 20 May 2004 14:06: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 1BQrvk-0005l3-GW for tcpm-web-archive@ietf.org; Thu, 20 May 2004 14:06:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQruo-0005gd-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 14:05:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQruG-0005bV-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 14:04:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQrfD-0007If-0H; Thu, 20 May 2004 13:49:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQrYJ-0005Kx-Sn for tcpm@optimus.ietf.org; Thu, 20 May 2004 13:41: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 NAA05945 for ; Thu, 20 May 2004 13:41: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 1BQrYH-0003K2-M3 for tcpm@ietf.org; Thu, 20 May 2004 13:41:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQrXP-0003G9-00 for tcpm@ietf.org; Thu, 20 May 2004 13:41: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 1BQrWm-0003A6-00 for tcpm@ietf.org; Thu, 20 May 2004 13:40:20 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 20 May 2004 09:45:51 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i4KHdlDe028188; Thu, 20 May 2004 10:39:47 -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 AUI20465; Thu, 20 May 2004 10:39:46 -0700 (PDT) Message-ID: <40ACED62.4C8103E9@cisco.com> Date: Thu, 20 May 2004 10:39:46 -0700 From: Anantha Ramaiah Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Sandy Murphy CC: mdalal@cisco.com, tcpm@ietf.org Subject: Re: [tcpm] SYN's in draft-ietf-tcpm-tcpsecure.txt :-) References: <200405201455.i4KEtQOD003867@tislabs.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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sandy, See inline for my comments.. Sandy Murphy wrote: > > >> There's been a lot of discussion about the modifications to the RST > >> processing, but not much about the modifications to the SYN processing. > >> > >> NOTE: All of the following is predicated on an assumption of just what > >> exactly is meant by "send an ACK segment to the peer but before > >> sending the ACK segment subtract one from value being acknowledged." > >> and "send an ACK segment to the peer." I'm presuming this means send > >> and > >> . > > > >sorry for late reply. somehow missed it earlier. The > >suggestion is to only send rcv.nxt-1 and not 2 ACKs if that > >is what you are saying above. Similar points as below were > >brought to light on the first day of the draft itself > >(April 20 tcpm archive). > > Gack! > > Sorry, I did check the archive, honest. I obviously just did not go > back far enough. I actually sat on my writeup for two weeks, > thinking that surely someone was going to mention this. Sanjay's > message of Apr 20 addresses exactly my concern of needing to rely on > timeouts. You are encouraged to see my reply to that too :) Anyways, One of the corner cases is when the incoming sequence # ( ie ISN chosen happens to be RCVNXT -1 ) happens to be SEG.SEQ = SEG.RCVNXT - 1 which would imply that the ACK would contain the SEG.ACK = RCVNXT, which the other end would treat it as acceptable and drop it since it is in SYNSENT state expecting a SYN+ACK and not just ACK. For this the suggestion was, "To send the ACK with RCVNXT -1, which would generate the RST but only on some systems ( RST with RCVNXT -1 is treated as a RST of a keepalive packet) it is acceptable, but on others it is dropped" " worst case is do nothing. This will force the restarted peer to give up and the next time it tries to establish the connection the ISN chosen would be random and hence different from the older one ( which was RCVNXT -1)" But someone (Allwyn) pointed the case for packets (kamikaze like packets) where the SYN would contain the data, in which case I am not sure what would be the consequences of partial ACK's (which is again rare since why would anybody chose to do a partial ACK for SYN segment with data) and how they need to be processed. Are there any other issues which we should be considering? thanks, -Anantha > > And, no, of course I don't mean sending two ACK's at the same time. > The paragraph mentions sending ACK's in two different situations > without specifics, I was trying to be specific about what those two > ACK's might be. > > [So any chance that the draft could spell out the packets exactly, as > in RFC793: > > or whatever?] > > >Although as you have mentioned above, for the case where we send rcv.nxt-1 > >ack and the SYN side then sends us a RST with rcv.nxt-1 might not be > >acceptable in some implementations that do not have keepalive mechanism. > > Sending an ACK with a value less than RCV.NXT, whether prompted by > a SYN or a SYN, means that any resultant > RST will be dropped. > > If the SYN is an old duplicate, you don't really need to do anything. > And if the SYN is a current SYN (with SEQ=RCV.NXT-1), then sending the > ACK with RCV.NXT is undesirable (maybe - see my comment below) and > sending the ACK with anything less than RCV.NXT results in a livelock > until timeout. > > So here's a radical suggestion: how about doing nothing? > > And then there are the revised suggestions for dealing with the > SEQ=RCV.NXT-1 case: > > From pgoyette@juniper.net: > > B) If the SYN bit is set and the sequence number is exactly one less > > than the next expected sequence (SEG.SEQ == (RCV.NXT - 1)) then > > send an ACK segment to the peer but before sending the ACK segment > > subtract one from the value being acknowledged i.e. the value > > being acknowledged should be (RCV.NXT - 2) or (SEG.SEQ - 1). > > And from mdalal@cisco.com > >What we are trying to avoid is send an ACK which will be valid to the > >remote end. Hence if we send an ACK with value RCV.NXT in response to > >an ISN of RCV.NXT-1, this ACK will be acceptable which we are trying > >to avoid. > > Why not just rely on the "out of the window" mechanism of case A? > > I believe that the motivation for adjusting the ACK is to prevent a > restarted peer in state SYN-SENT from believing that it's SYN was > being ACK'd - and declaring the connection ESTABLISHED. But it seems > to me that the behavior in state SYN-SENT will drop the segment if > there is no SYN on the segment, even if the ACK is acceptable. So > that's not really a problem. Right? Or maybe I've missed the point. > > --Sandy > > _______________________________________________ > 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 May 20 14:24: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 OAA09229 for ; Thu, 20 May 2004 14:24: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 1BQs66-00064t-F5 for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 14:16:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KIGovl023358 for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 14:16:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQrwg-0003eM-22 for tcpm-web-archive@optimus.ietf.org; Thu, 20 May 2004 14:07: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 OAA07885 for ; Thu, 20 May 2004 14:07: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 1BQrwd-0005rJ-KF for tcpm-web-archive@ietf.org; Thu, 20 May 2004 14:07:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQrvu-0005mU-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 14:06:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQrvE-0005h4-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 14:05:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQrfD-0007In-8H; Thu, 20 May 2004 13:49:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQrYL-0005L0-Nv for tcpm@optimus.ietf.org; Thu, 20 May 2004 13:41: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 NAA05950 for ; Thu, 20 May 2004 13:41: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 1BQrYJ-0003KA-Hd for tcpm@ietf.org; Thu, 20 May 2004 13:41:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQrXR-0003GP-00 for tcpm@ietf.org; Thu, 20 May 2004 13:41:01 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx with esmtp (Exim 4.12) id 1BQrWy-0003CS-00 for tcpm@ietf.org; Thu, 20 May 2004 13:40:32 -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 i4KHeUim080213; Thu, 20 May 2004 10:40:30 -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 01B6E77A6D5; Thu, 20 May 2004 13:40:29 -0400 (EDT) To: Fernando Gont From: Mark Allman Reply-To: mallman@icir.org Cc: tcpm@ietf.org, Ted Faber Subject: Re: [tcpm] ATO i-d In-Reply-To: <4.3.2.7.2.20040519175601.00c57e70@mail.daleclick.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Ghost of a Texas Ladies Man MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 20 May 2004 13:40:28 -0400 Message-Id: <20040520174029.01B6E77A6D5@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 > >Based on the postings on the list it seems to Ted and I that the > >consensus is for this WG to take on the ATO internet-draft > >(draft-eggert-tcpm-tcp-abort-timeout-option-00.txt). > > I think this statement does not make it clear we'll take on the > issue of having TCP "negotiate" TCP User Timeouts, rather than on > any specific proposal. Right. So... I believe that when I made the first statement above I did not realize there was another proposal in the pipeline. That may be because I didn't receive your note or that may have been because I had not yet read it (I am usually *way* behind). So, let me re-phrase a little ... I think what we have consensus on - which is what Ted and I asked - is to undertake work to allow TCP endpoints to negotiate a connection timeout. If we have mis-read consensus on this point, please yell. At this point, we have two i-ds in this space. The first is the above mentioned document from Lars and has been discussed in some detail on the list. The second was recently announced and is: draft-gont-tcpm-tcp-auto-option-00.txt We can take up either of these, both of these or work the ideas together into a single document. Opinions on which path makes the most sense would be very welcome. Thanks! allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFArO2MWyrrWs4yIs4RAnQsAJ9+y9Yw1ktEHnt/Zd6eymxA4jdSaQCeLsRQ trXwukXeWeUgXCK5hPoQnkA= =FFQE -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 20 15:07:08 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 PAA12701 for ; Thu, 20 May 2004 15:07: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 1BQspg-0006y6-8F for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 15:03:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KJ3u5h026786 for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 15: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 1BQsfZ-0008Ol-MY for tcpm-web-archive@optimus.ietf.org; Thu, 20 May 2004 14:53: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 OAA11501 for ; Thu, 20 May 2004 14:53: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 1BQsfX-0002cN-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 14:53:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQset-0002al-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 14:52:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQseF-0002Xa-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 14:52:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQsUf-0005lQ-5K; Thu, 20 May 2004 14:42:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQsLa-0001FJ-R9 for tcpm@optimus.ietf.org; Thu, 20 May 2004 14:32: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 OAA09965 for ; Thu, 20 May 2004 14:32: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 1BQsLY-0000fv-2d for tcpm@ietf.org; Thu, 20 May 2004 14:32:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQsKY-0000aH-00 for tcpm@ietf.org; Thu, 20 May 2004 14:31:46 -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 1BQsJY-0000Pn-00 for tcpm@ietf.org; Thu, 20 May 2004 14:30:45 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 20 May 2004 10:37:55 +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 i4KIUCDe009557; Thu, 20 May 2004 11:30: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 ATJ03396; Thu, 20 May 2004 11:29:25 -0700 (PDT) Date: Thu, 20 May 2004 11:30:12 -0700 (PDT) From: Mitesh Dalal To: Paul Goyette cc: Sandy Murphy , tcpm@ietf.org Subject: RE: [tcpm] SYN's in draft-ietf-tcpm-tcpsecure.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=AWL autolearn=no version=2.60 On Wed, 19 May 2004, Paul Goyette wrote: > Mitesh, > > > > NOTE: All of the following is predicated on an assumption of just what > > > exactly is meant by "send an ACK segment to the peer but before > > > sending the ACK segment subtract one from value being acknowledged." > > > and "send an ACK segment to the peer." I'm presuming this means send > > > and > > > . > > > > sorry for late reply. somehow missed it earlier. The > > suggestion is to only send rcv.nxt-1 and not 2 ACKs if that > > is what you are saying above. Similar points as below were > > brought to light on the first day of the draft itself > > (April 20 tcpm archive). > > If I remember correctly, step 3B is going to be changed to > > B) If the SYN bit is set and the sequence number is exactly one less > than the next expected sequence (SEG.SEQ == (RCV.NXT - 1)) then > send an ACK segment to the peer but before sending the ACK segment > subtract one from the value being acknowledged i.e. the value > being acknowledged should be (RCV.NXT - 2) or (SEG.SEQ - 1). > Hi Paul, we have 2 situations that we are worried about. 1. when the SYN has an ISN of RCV.NXT and is within the window of our ESTAB connection, here we are proposing to send an ACK with value RCV.NXT. The remote end will then send a RST with rcv.nxt seq and we should be able to tear the connection. So things are fine here. 2. when the SYN has an ISN of RCV.NXT-1 and is within the window of our ESTAB connection, here we are proposing to send an ACK with value RCV.NXT-1 and not RCV.NXT-2. Sorry for the confusing wording. As Sandy suggested we will spell it out in the next version. The point why the RCV.NXT-1 approach will help is because many OS do have TCP keepalive mechanism and actually consider an RST with RCV.NXT-1 to be valid. So the actual range of RST in these implementation is (RCV.NXT-1 to RCV.NXT + RCV.WND). But again, we will appreciate feedback from the WG about how many implementations do have keepalive and will accept RCV.NXT-1 RST valid. If there isnt much support here, we can simply tear down the connection for this value. thx Mitesh > -----Original Message----- > From: tcpm-admin@ietf.org [mailto:tcpm-admin@ietf.org]On Behalf Of > Mitesh Dalal > Sent: Wednesday, May 19, 2004 8:14 PM > To: Sandy Murphy > Cc: tcpm@ietf.org > Subject: Re: [tcpm] SYN's in draft-ietf-tcpm-tcpsecure.txt :-) > > > On Wed, 19 May 2004, Sandy Murphy wrote: > > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 20 15:08:09 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 PAA12902 for ; Thu, 20 May 2004 15:08: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 1BQspj-00072y-Ik for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 15:03:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KJ3x2l027083 for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 15:03:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQslr-0001fk-1L for tcpm-web-archive@optimus.ietf.org; Thu, 20 May 2004 14:59: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 OAA11926 for ; Thu, 20 May 2004 14:59: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 1BQslo-0002wK-40 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 14:59:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQsko-0002u6-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 14:58:55 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQsjr-0002qX-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 14:57:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQsUm-0005nJ-G4; Thu, 20 May 2004 14:42:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQsSe-0004nN-4H for tcpm@optimus.ietf.org; Thu, 20 May 2004 14:40: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 OAA10508 for ; Thu, 20 May 2004 14:40: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 1BQsSb-0001KQ-3Z for tcpm@ietf.org; Thu, 20 May 2004 14:40:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQsS2-0001EK-00 for tcpm@ietf.org; Thu, 20 May 2004 14:39:31 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1BQsR3-00013P-00 for tcpm@ietf.org; Thu, 20 May 2004 14:38:29 -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 i4KIbpBm029776; Thu, 20 May 2004 11:37:51 -0700 (PDT) (envelope-from pgoyette@juniper.net) Received: from pgoyette600 (pgoyette-600.jnpr.net [172.24.0.78]) by merlot.juniper.net (8.11.3/8.11.3) with SMTP id i4KIbpJ63973; Thu, 20 May 2004 11:37:51 -0700 (PDT) (envelope-from pgoyette@juniper.net) From: "Paul Goyette" To: "Mitesh Dalal" Cc: "Sandy Murphy" , Subject: RE: [tcpm] SYN's in draft-ietf-tcpm-tcpsecure.txt :-) Date: Thu, 20 May 2004 11:37:48 -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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal In-Reply-To: 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 > 1. when the SYN has an ISN of RCV.NXT and is within the window > of our ESTAB connection, here we are proposing to send an ACK > with value RCV.NXT. The remote end will then send a RST with > rcv.nxt seq and we should be able to tear the connection. > So things are fine here. > > 2. when the SYN has an ISN of RCV.NXT-1 and is within the window > of our ESTAB connection, here we are proposing to send an ACK > with value RCV.NXT-1 and not RCV.NXT-2. Sorry for the confusing > wording. As Sandy suggested we will spell it out in the next > version. The point why the RCV.NXT-1 approach will help is > because many OS do have TCP keepalive mechanism and actually > consider an RST with RCV.NXT-1 to be valid. So the actual range > of RST in these implementation is (RCV.NXT-1 to RCV.NXT + RCV.WND). So, if this is the case, how does #1 differ from #2? In both cases, we will be sending back an Ack segment with ie we will be acknowledging with the same value as received in the SYN segment, whether SEG.ACK==RCV.NXT or SEG.ACK=(RCV.NXT-1). _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 20 15:25:16 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 PAA14589 for ; Thu, 20 May 2004 15:25: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 1BQt0w-0007Vy-CD for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 15:15:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KJFYbU028885 for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 15:15:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQsyM-0005oS-Qj for tcpm-web-archive@optimus.ietf.org; Thu, 20 May 2004 15:12: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 PAA13433 for ; Thu, 20 May 2004 15:12: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 1BQsyL-0003X8-Km for tcpm-web-archive@ietf.org; Thu, 20 May 2004 15:12:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQsxU-0003VB-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 15:12:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQswd-0003TC-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 15: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 1BQspz-0007C6-78; Thu, 20 May 2004 15:04:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQsk8-00018z-5Y for tcpm@optimus.ietf.org; Thu, 20 May 2004 14:58: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 OAA11873 for ; Thu, 20 May 2004 14:58: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 1BQsk5-0002s1-7U for tcpm@ietf.org; Thu, 20 May 2004 14:58:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQsjG-0002ot-00 for tcpm@ietf.org; Thu, 20 May 2004 14:57:18 -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 1BQsiJ-0002hg-00 for tcpm@ietf.org; Thu, 20 May 2004 14:56:19 -0400 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 i4KItlDe011521; Thu, 20 May 2004 11:55: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 ATJ06404; Thu, 20 May 2004 11:54:58 -0700 (PDT) Date: Thu, 20 May 2004 11:55:45 -0700 (PDT) From: Mitesh Dalal To: Florian Weimer cc: "Randall Stewart (cisco)" , "Charlet, Ricky" , tcpm@ietf.org Subject: Re: [tcpm] tcpsecure: when to expect draft-01? In-Reply-To: <87n0439yr8.fsf@deneb.enyo.de> Message-ID: References: <2EFAFC388B9C4C48B581846AEC20A020016CA884@scexch01.arc.com> <40AC0B00.4010205@cisco.com> <87n0439yr8.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=AWL autolearn=no version=2.60 On Thu, 20 May 2004, Florian Weimer wrote: > * Mitesh Dalal: > > > 1. alternate solutions that are known today: MD5, IPSec, > > port randomization. This will only be quoted for purpose > > of reference and not to make a suggestion as such as > > some folks have pointed out that MD5 was intended for BGP > > and is not generic enough. > > IPsec without ISAKMP, please. ISAKMP is probably not robust enough > (think of all the recent DoS attacks). > > > Anything else the WG would like to see being added > > to the draft ? > > At the minimum, a rate limit for the new ACKs is required (i.e. MUST, > not MAY). Mentioning this risk in some appendix isn't enough. this will depend on the implementors paranoia. Adding a rate limit simply introduces more state and logic into the code and is prone to error. As we have been saying, please bring forward a valid scenario where an ACK war might happen. All scenarios brought forward are simply offending middleboxes which need to be fixed. And from the mails on the WG, the WG itself seem to be divided on this issue. Some folks supporting to account for such a middlebox in the solution and the others supporting to fix the middlebox. So the right think to do it seems is to jot it down and let the implementor make a call. > However, I still believe that the proposal is fundamentally flawed > because it does nothing to prevent other forms of blind injection do you have specific attacks in mind that are on the lines of the problem in this draft ? > attacks. For just one or two aspects of the issue, it's not really > worth the trouble, IMHO. > changes are always incremental. It would be difficult to identify all holes in a single shot and fix them. But if anybody in the WG feels that there are more scenarios which can be included in the solution please bring it forward. thx Mitesh _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 20 16:02:21 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 QAA17199 for ; Thu, 20 May 2004 16:02:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQtba-0002Jr-SH for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 15:53:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KJrQFW008907 for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 15:53:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQtVI-00080G-VP for tcpm-web-archive@optimus.ietf.org; Thu, 20 May 2004 15:46: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 PAA15995 for ; Thu, 20 May 2004 15:46: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 1BQtVH-0005YY-Ft for tcpm-web-archive@ietf.org; Thu, 20 May 2004 15:46:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQtUR-0005WQ-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 15:46:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQtU5-0005Tr-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 15:45:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQtPe-0006hF-4m; Thu, 20 May 2004 15:41:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQtHr-00040l-KN for tcpm@optimus.ietf.org; Thu, 20 May 2004 15:33: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 PAA14871 for ; Thu, 20 May 2004 15:33: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 1BQtHq-0004Wm-93 for tcpm@ietf.org; Thu, 20 May 2004 15:33:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQtGw-0004Tr-00 for tcpm@ietf.org; Thu, 20 May 2004 15:32:06 -0400 Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 1BQtGM-0004Qm-00 for tcpm@ietf.org; Thu, 20 May 2004 15:31:30 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4KJSxCT013309 for ; Thu, 20 May 2004 15:28:59 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAKfaa_z; Thu, 20 May 04 15:28:58 -0400 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id i4KJUIll015440; Thu, 20 May 2004 15:30:18 -0400 (EDT) Date: Thu, 20 May 2004 15:30:18 -0400 (EDT) From: Sandy Murphy Message-Id: <200405201930.i4KJUIll015440@tislabs.com> To: mdalal@cisco.com, pgoyette@juniper.net Subject: RE: [tcpm] SYN's in draft-ietf-tcpm-tcpsecure.txt :-) Cc: sandy@tislabs.com, tcpm@ietf.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 >2. when the SYN has an ISN of RCV.NXT-1 and is within the window >of our ESTAB connection Did you mean this exactly as you have said? That a SEQ of RCV.NXT-1 is within the window? --Sandy _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 20 16:03:10 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 QAA17285 for ; Thu, 20 May 2004 16:03: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 1BQtbi-0002Rm-Kq for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 15:53:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KJrYql009398 for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 15:53:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQta7-0000iV-Is for tcpm-web-archive@optimus.ietf.org; Thu, 20 May 2004 15:51: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 PAA16197 for ; Thu, 20 May 2004 15: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 1BQta6-0005m5-4t for tcpm-web-archive@ietf.org; Thu, 20 May 2004 15:51:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQtZJ-0005jq-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 15:51:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQtYU-0005hg-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 15:50:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQtPf-0006ho-CL; Thu, 20 May 2004 15:41:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQtIl-0004Ku-3q for tcpm@optimus.ietf.org; Thu, 20 May 2004 15:33: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 PAA14954 for ; Thu, 20 May 2004 15:33: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 1BQtIj-0004aO-LO for tcpm@ietf.org; Thu, 20 May 2004 15:33:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQtHt-0004XK-00 for tcpm@ietf.org; Thu, 20 May 2004 15:33:06 -0400 Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 1BQtH4-0004UG-00 for tcpm@ietf.org; Thu, 20 May 2004 15:32:14 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4KJTi4W013381 for ; Thu, 20 May 2004 15:29:44 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAp_aqiA; Thu, 20 May 04 15:29:42 -0400 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id i4KJV3ZV015480; Thu, 20 May 2004 15:31:03 -0400 (EDT) Date: Thu, 20 May 2004 15:31:03 -0400 (EDT) From: Sandy Murphy Message-Id: <200405201931.i4KJV3ZV015480@tislabs.com> To: mdalal@cisco.com, pgoyette@juniper.net Subject: RE: [tcpm] SYN's in draft-ietf-tcpm-tcpsecure.txt :-) Cc: sandy@tislabs.com, tcpm@ietf.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 >So, if this is the case, how does #1 differ from #2? In both >cases, we will be sending back an Ack segment with ACK=SEG.ACK> ie we will be acknowledging with the same value >as received in the SYN segment, whether SEG.ACK==RCV.NXT or >SEG.ACK=(RCV.NXT-1). In all three cases, did you really mean SEG.ACK or perhaps you meant SEG.SEQ? --Sandy _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 20 17:08: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 RAA24243 for ; Thu, 20 May 2004 17:08: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 1BQtxW-00082U-Lh for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 16:16:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KKG6wL030903 for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 16:16:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQtmr-0005BV-Bf for tcpm-web-archive@optimus.ietf.org; Thu, 20 May 2004 16:05: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 QAA17501 for ; Thu, 20 May 2004 16:05: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 1BQtmp-0006Vr-Pr for tcpm-web-archive@ietf.org; Thu, 20 May 2004 16:05:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQtly-0006SX-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 16:04:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQtl4-0006P1-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 16:03:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQtcC-0002Vi-0H; Thu, 20 May 2004 15: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 1BQtXW-0008VK-QW for tcpm@optimus.ietf.org; Thu, 20 May 2004 15:49: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 PAA16089 for ; Thu, 20 May 2004 15:49: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 1BQtXV-0005eV-A5 for tcpm@ietf.org; Thu, 20 May 2004 15:49:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQtWW-0005ck-00 for tcpm@ietf.org; Thu, 20 May 2004 15:48:13 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BQtW4-0005Z1-00 for tcpm@ietf.org; Thu, 20 May 2004 15:47:44 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i4KJlA966222; Thu, 20 May 2004 12:47:10 -0700 (PDT) (envelope-from pgoyette@juniper.net) Received: from pgoyette600 (pgoyette-600.jnpr.net [172.24.0.78]) by merlot.juniper.net (8.11.3/8.11.3) with SMTP id i4KJl5J75680; Thu, 20 May 2004 12:47:05 -0700 (PDT) (envelope-from pgoyette@juniper.net) From: "Paul Goyette" To: "Sandy Murphy" , Cc: Subject: RE: [tcpm] SYN's in draft-ietf-tcpm-tcpsecure.txt :-) Date: Thu, 20 May 2004 12:47:02 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal In-Reply-To: <200405201931.i4KJV3ZV015480@tislabs.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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Argghhh, yes! In all 3 cases, ACK=SEG.SEQ -----Original Message----- From: Sandy Murphy [mailto:sandy@tislabs.com] Sent: Thursday, May 20, 2004 12:31 PM To: mdalal@cisco.com; pgoyette@juniper.net Cc: sandy@tislabs.com; tcpm@ietf.org Subject: RE: [tcpm] SYN's in draft-ietf-tcpm-tcpsecure.txt :-) >So, if this is the case, how does #1 differ from #2? In both >cases, we will be sending back an Ack segment with ACK=SEG.ACK> ie we will be acknowledging with the same value >as received in the SYN segment, whether SEG.ACK==RCV.NXT or >SEG.ACK=(RCV.NXT-1). In all three cases, did you really mean SEG.ACK or perhaps you meant SEG.SEQ? --Sandy _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 20 17:25: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 RAA26330 for ; Thu, 20 May 2004 17:25: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 1BQulL-0006Vh-Do for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 17:07:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KL7Zcf025021 for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 17:07:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQtxO-00081b-Vu for tcpm-web-archive@optimus.ietf.org; Thu, 20 May 2004 16:15: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 QAA18172 for ; Thu, 20 May 2004 16:15: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 1BQtxN-00071p-4w for tcpm-web-archive@ietf.org; Thu, 20 May 2004 16:15:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQtwR-0006zF-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 16:15:00 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQtvd-0006xP-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 16: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 1BQtlq-0004tZ-Cq; Thu, 20 May 2004 16:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQtcR-0002Wg-OR for tcpm@optimus.ietf.org; Thu, 20 May 2004 15:54: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 PAA16409 for ; Thu, 20 May 2004 15:54: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 1BQtcQ-0005yb-6d for tcpm@ietf.org; Thu, 20 May 2004 15:54:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQtbS-0005tm-00 for tcpm@ietf.org; Thu, 20 May 2004 15:53:19 -0400 Received: from jive.softhome.net ([66.54.152.27]) by ietf-mx with smtp (Exim 4.12) id 1BQtan-0005oP-00 for tcpm@ietf.org; Thu, 20 May 2004 15:52:37 -0400 Received: (qmail 4776 invoked by uid 417); 20 May 2004 19:52:37 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 20 May 2004 19:52:37 -0000 Received: from fernando.softhome.net ([200.59.164.77]) (AUTH: LOGIN fgont@softhome.net) by softhome.net with esmtp; Thu, 20 May 2004 13:52:33 -0600 Message-Id: <4.3.2.7.2.20040520164958.00b45860@mail.daleclick.com> X-Sender: fgont@pop.softhome.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 May 2004 16:57:35 -0300 To: tcpm@ietf.org From: Fernando Gont Subject: Re: [tcpm] ATO i-d Cc: mallman@icir.org In-Reply-To: <20040520174029.01B6E77A6D5@guns.icir.org> References: <4.3.2.7.2.20040519175601.00c57e70@mail.daleclick.com> Mime-Version: 1.0 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 At 13:40 20/05/2004 -0400, you wrote: > > I think this statement does not make it clear we'll take on the > > issue of having TCP "negotiate" TCP User Timeouts, rather than on > > any specific proposal. > >Right. > >So... I believe that when I made the first statement above I did not >realize there was another proposal in the pipeline. That may be because >I didn't receive your note or that may have been because I had not yet >read it (I am usually *way* behind). That's true: By the time you made the statement you were not aware of my proposal, yet. >At this point, we have two i-ds in this space. The first is the above >mentioned document from Lars and has been discussed in some detail on >the list. The second was recently announced and is: > > draft-gont-tcpm-tcp-auto-option-00.txt > >We can take up either of these, both of these or work the ideas together >into a single document. Opinions on which path makes the most sense >would be very welcome. IMHO, both drafts are *alternative* approaches to handle the issue of having TCP set the USER TIMEOUT parameter. However, in any case, I'd wait for a couple of weeks so that participants have enough time to take a look at the drafts. My proposal has been online for only two days, and I've "announced" it to the WG mailing-list *today*. -- 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 Thu May 20 17:51: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 RAA28731 for ; Thu, 20 May 2004 17:51: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 1BQvKN-0003kL-HF for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 17:43:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KLhlZ9014393 for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 17:43:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQv8W-0006zk-8h for tcpm-web-archive@optimus.ietf.org; Thu, 20 May 2004 17:31: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 RAA27233 for ; Thu, 20 May 2004 17:31: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 1BQv8T-0001dP-TU for tcpm-web-archive@ietf.org; Thu, 20 May 2004 17:31:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQv6G-0001F8-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 17:29:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQv2R-0000jg-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 17: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 1BQuln-0006fy-K5; Thu, 20 May 2004 17:08:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQtxT-00082D-7s for tcpm@optimus.ietf.org; Thu, 20 May 2004 16:16: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 QAA18187 for ; Thu, 20 May 2004 16:16: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 1BQtxR-00072K-Gt for tcpm@ietf.org; Thu, 20 May 2004 16:16:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQtwW-000701-00 for tcpm@ietf.org; Thu, 20 May 2004 16:15:05 -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 1BQtvt-0006w4-00 for tcpm@ietf.org; Thu, 20 May 2004 16:14:25 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 20 May 2004 12:21:37 +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 i4KKDofF001764; Thu, 20 May 2004 13:13:54 -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 ATJ14167; Thu, 20 May 2004 13:13:02 -0700 (PDT) Date: Thu, 20 May 2004 13:13:49 -0700 (PDT) From: Mitesh Dalal To: Sandy Murphy cc: pgoyette@juniper.net, tcpm@ietf.org Subject: RE: [tcpm] SYN's in draft-ietf-tcpm-tcpsecure.txt :-) In-Reply-To: <200405201930.i4KJUIll015440@tislabs.com> Message-ID: References: <200405201930.i4KJUIll015440@tislabs.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=AWL autolearn=no version=2.60 On Thu, 20 May 2004, Sandy Murphy wrote: > >2. when the SYN has an ISN of RCV.NXT-1 and is within the window > >of our ESTAB connection > > Did you mean this exactly as you have said? That a SEQ of RCV.NXT-1 > is within the window? > good catch Sandy. should have read as is not within the window. copy/paste error from point 1 :) thx Mitesh _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 20 18:00: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 SAA29297 for ; Thu, 20 May 2004 18:00: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 1BQvOu-0006Gb-F2 for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 17:48:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KLmSN9024081 for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 17:48:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQvDn-00013q-A8 for tcpm-web-archive@optimus.ietf.org; Thu, 20 May 2004 17:36: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 RAA27685 for ; Thu, 20 May 2004 17:36: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 1BQvDl-0002Bb-0H for tcpm-web-archive@ietf.org; Thu, 20 May 2004 17:36:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQvCr-00027x-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 17:36:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQvC1-00024N-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 17:35:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQuyU-0002Wh-SA; Thu, 20 May 2004 17:21:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQuNY-0003nw-Dh for tcpm@optimus.ietf.org; Thu, 20 May 2004 16:43: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 QAA20839 for ; Thu, 20 May 2004 16:42: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 1BQuNU-0002E3-Dk for tcpm@ietf.org; Thu, 20 May 2004 16:42:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQuMK-00021L-00 for tcpm@ietf.org; Thu, 20 May 2004 16:41:45 -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 1BQuL6-0001j4-00 for tcpm@ietf.org; Thu, 20 May 2004 16:40:28 -0400 Received: from catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id i4KKct7E026989; Thu, 20 May 2004 13:38:59 -0700 (PDT) (envelope-from dl-tcpm@catspoiler.org) Message-Id: <200405202038.i4KKct7E026989@gw.catspoiler.org> Date: Thu, 20 May 2004 13:38:55 -0700 (PDT) From: Don Lewis Subject: Re: [tcpm] SYN's in draft-ietf-tcpm-tcpsecure.txt :-) To: ananth@cisco.com cc: sandy@tislabs.com, mdalal@cisco.com, tcpm@ietf.org In-Reply-To: <40ACED62.4C8103E9@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 20 May, Anantha Ramaiah wrote: > But someone (Allwyn) pointed the case for packets (kamikaze like packets) > where the SYN would contain the data, > in which case I am not sure what would be the consequences of partial > ACK's (which is again rare since why would anybody chose to do a partial > ACK for SYN segment with data) and how they need to be processed. This particular case motivated me to move the SYN handling code from after the segment is trimmed to fit the window to before the segment is trimmed to fit the window in the vulnerability fix that I am proposing to implement in FreeBSD. If the SYN flag is set and either SEG.SEQ != IRS or SEG.SEQ >= RCV.NXT, the segment will get special handling. The last condition is meant to be a cheap way of detecting that sequence space must have wrapped and the SYN flag could be in the window. The normal case of a duplicate SYN will fall through and will be trimmed off when the segment is trimmed to fit the window. If the segment qualifies for special handling, there are five cases: The TIME-WAIT case, which is handled elsewhere in the FreeBSD implementation. RCV.NXT < SEG.SEQ || RCV.NXT >= SEG.SEQ+SEG.LEN Just send an ACK and drop the segment. If we received a legitimate SYN, the ACK will trigger a RST response. If this was a spoofed SYN, our peer will accept the ACK and not respond. RCV.NXT == SEG.SEQ && !ACK For simplicity, just drop the connection. An ACK challenge could be done to guard against the unlikely case of an attacker guessing just the right sequence number to tear down the connection. ACK flag is set Drop the segment since this must not be a legitimate request to set up a new connection. SEG.SEQ < RCV.NXT && SEG.SEQ+SEG.LEN > RCV.NXT Drop the segment. The segment includes a data payload and straddles RCV.NXT. There is no reason to send a normal ACK, since no response will be generated, no matter whether the segment was a legitimate new SYN or it was spoofed. It might be possible though to distinguish these two cases by doing something like a TCP keepalive test, which would cause an ESTABLISHED peer to respond. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 20 18:18: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 RAA26329 for ; Thu, 20 May 2004 17:25: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 1BQulL-0006VU-5J for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 17:07:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KL7ZrI025004 for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 17:07:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQtwI-0007mN-If for tcpm-web-archive@optimus.ietf.org; Thu, 20 May 2004 16:14: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 QAA18113 for ; Thu, 20 May 2004 16:14: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 1BQtwG-0006y1-U5 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 16:14:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQtvI-0006vE-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 16:13:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQtuN-0006rT-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 16:12:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQtlp-0004tR-Ko; Thu, 20 May 2004 16:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQtcK-0002WZ-T4 for tcpm@optimus.ietf.org; Thu, 20 May 2004 15:54: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 PAA16394 for ; Thu, 20 May 2004 15:54: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 1BQtcJ-0005xp-75 for tcpm@ietf.org; Thu, 20 May 2004 15:54:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQtbM-0005sg-00 for tcpm@ietf.org; Thu, 20 May 2004 15:53:12 -0400 Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 1BQtaT-0005oA-00 for tcpm@ietf.org; Thu, 20 May 2004 15:52:17 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4KJnjmW015883 for ; Thu, 20 May 2004 15:49:45 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAloaqaF; Thu, 20 May 04 15:49:43 -0400 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id i4KJp3qD016546; Thu, 20 May 2004 15:51:03 -0400 (EDT) Date: Thu, 20 May 2004 15:51:03 -0400 (EDT) From: Sandy Murphy Message-Id: <200405201951.i4KJp3qD016546@tislabs.com> To: ananth@cisco.com, sandy@tislabs.com Subject: Re: [tcpm] SYN's in draft-ietf-tcpm-tcpsecure.txt :-) Cc: mdalal@cisco.com, tcpm@ietf.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 >You are encouraged to see my reply to that too :) > >"To send the ACK with RCVNXT -1, which would generate the RST but > only on some systems ( RST with RCVNXT -1 is treated as a RST > of a keepalive packet) it is acceptable, but on others it is > dropped" Ah. I thought the "only on some systems" applied to the generating the RST or the "it is acceptable" applied to the ACK. I should not have been so literal. --Sandy _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 20 18: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 SAA02238 for ; Thu, 20 May 2004 18:27: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 1BQvqU-00041U-KW for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 18:16:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KMGw5e015456 for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 18:16:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQvin-0007nv-Px for tcpm-web-archive@optimus.ietf.org; Thu, 20 May 2004 18: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 SAA00486 for ; Thu, 20 May 2004 18: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 1BQvil-0004fp-1Z for tcpm-web-archive@ietf.org; Thu, 20 May 2004 18:08:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQvht-0004c8-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 18:08:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQvhH-0004ZI-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 18: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 1BQvbA-0002ZI-Qm; Thu, 20 May 2004 18: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 1BQvUA-0008AF-WB for tcpm@optimus.ietf.org; Thu, 20 May 2004 17:53: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 RAA28910 for ; Thu, 20 May 2004 17:53: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 1BQvU8-0003Xj-8q for tcpm@ietf.org; Thu, 20 May 2004 17:53:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQvT9-0003UG-00 for tcpm@ietf.org; Thu, 20 May 2004 17:52:52 -0400 Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 1BQvSB-0003PV-00 for tcpm@ietf.org; Thu, 20 May 2004 17:51:51 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4KLnKAn029213 for ; Thu, 20 May 2004 17:49:20 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA4_aid5; Thu, 20 May 04 17:49:19 -0400 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id i4KLocea021380; Thu, 20 May 2004 17:50:38 -0400 (EDT) Date: Thu, 20 May 2004 17:50:38 -0400 (EDT) From: Sandy Murphy Message-Id: <200405202150.i4KLocea021380@tislabs.com> To: dl-tcpm@catspoiler.org, tcpm@ietf.org Subject: Re: [tcpm] SYN's in draft-ietf-tcpm-tcpsecure.txt :-) Cc: sandy@tislabs.com 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 > RCV.NXT < SEG.SEQ || RCV.NXT >= SEG.SEQ+SEG.LEN > Just send an ACK and drop the segment. If we received a > legitimate SYN, the ACK will trigger a RST response. In the "corner case" that's the current topic of conversation, SEG.SEQ = RCV.NXT-1. That means that SEG.SEQ+SEG.LEN = RCV.NXT. Which means that the ACK would look to a SYN-SENT peer like an acceptable ACK, but with the SYN not set, the segment would be dropped and ignored. Leading to new SYN's until timeout. The adjustment of the ACK when SEG.SEQ = RCV.NXT-1 was intended to eliminate the livelock until timeout, but only in the case of implementations that support the SEG.SEQ = RCV.NXT-1 acceptability test for RST. From my reading of what's been said, of course. --Sandy _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 20 18:42: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 SAA03276 for ; Thu, 20 May 2004 18:42: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 1BQwAO-00021T-ND for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 18:37:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KMbWTL007776 for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 18:37:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQw3D-0000Dg-Kc for tcpm-web-archive@optimus.ietf.org; Thu, 20 May 2004 18:30: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 SAA02415 for ; Thu, 20 May 2004 18: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 1BQw3A-000629-MO for tcpm-web-archive@ietf.org; Thu, 20 May 2004 18:30:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQw2L-0005ys-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 18:29:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQw1s-0005v4-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 18:28:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQvxK-0006YP-2h; Thu, 20 May 2004 18:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQvl8-0000xT-9w for tcpm@optimus.ietf.org; Thu, 20 May 2004 18: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 SAA00895 for ; Thu, 20 May 2004 18:11: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 1BQvl5-0004tH-Dk for tcpm@ietf.org; Thu, 20 May 2004 18:11:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQvk2-0004no-00 for tcpm@ietf.org; Thu, 20 May 2004 18:10:19 -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 1BQvjU-0004hX-00 for tcpm@ietf.org; Thu, 20 May 2004 18:09:44 -0400 Received: from catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id i4KM977E027182; Thu, 20 May 2004 15:09:11 -0700 (PDT) (envelope-from dl-tcpm@catspoiler.org) Message-Id: <200405202209.i4KM977E027182@gw.catspoiler.org> Date: Thu, 20 May 2004 15:09:07 -0700 (PDT) From: Don Lewis Subject: Re: [tcpm] SYN's in draft-ietf-tcpm-tcpsecure.txt :-) To: sandy@tislabs.com cc: tcpm@ietf.org In-Reply-To: <200405202150.i4KLocea021380@tislabs.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 20 May, Sandy Murphy wrote: >> RCV.NXT < SEG.SEQ || RCV.NXT >= SEG.SEQ+SEG.LEN >> Just send an ACK and drop the segment. If we received a >> legitimate SYN, the ACK will trigger a RST response. > > In the "corner case" that's the current topic of conversation, > SEG.SEQ = RCV.NXT-1. That means that SEG.SEQ+SEG.LEN = RCV.NXT. > Which means that the ACK would look to a SYN-SENT peer like an > acceptable ACK, but with the SYN not set, the segment would be > dropped and ignored. Leading to new SYN's until timeout. > > The adjustment of the ACK when SEG.SEQ = RCV.NXT-1 was intended to > eliminate the livelock until timeout, but only in the case > of implementations that support the SEG.SEQ = RCV.NXT-1 acceptability > test for RST. Yeah, it looks like I've got an off by one problem in my proposal. Cases 2 and 3 should be: RCV.NXT <= SEG.SEQ || RCV.NXT > SEG.SEQ+SEG.LEN Just send an ACK and drop the segment. If we received a legitimate SYN, the ACK will trigger a RST response. If this was a spoofed SYN, our peer will accept the ACK and not respond. RCV.NXT == SEG.SEQ+1 && !ACK For simplicity, just drop the connection. An ACK challenge could be done to guard against the unlikely case of an attacker guessing just the right sequence number to tear down the connection. and the fifth case should be adjusted to match. From the point of view of the sender of the SYN, case 2 corresponds to (assuming only one segment is sent): 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) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 20 19: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 TAA04430 for ; Thu, 20 May 2004 19:10: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 1BQwcj-0000Nm-NT for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 19:06:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KN6nNi001466 for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 19:06:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQwU9-0006yM-HE for tcpm-web-archive@optimus.ietf.org; Thu, 20 May 2004 18:57: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 SAA04015 for ; Thu, 20 May 2004 18:57: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 1BQwU6-00009U-89 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 18:57:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQwT9-00004v-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 18:56:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQwSD-00001N-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 18:55:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQwPN-00066G-1V; Thu, 20 May 2004 18: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 1BQwNV-0005hf-Rr for tcpm@optimus.ietf.org; Thu, 20 May 2004 18:51: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 SAA03732 for ; Thu, 20 May 2004 18:51: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 1BQwNS-0007UH-N9 for tcpm@ietf.org; Thu, 20 May 2004 18:51:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQwMh-0007Ri-00 for tcpm@ietf.org; Thu, 20 May 2004 18:50:16 -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 1BQwMA-0007Li-00 for tcpm@ietf.org; Thu, 20 May 2004 18:49:42 -0400 Received: from catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id i4KMn57E027273; Thu, 20 May 2004 15:49:09 -0700 (PDT) (envelope-from dl-tcpm@catspoiler.org) Message-Id: <200405202249.i4KMn57E027273@gw.catspoiler.org> Date: Thu, 20 May 2004 15:49:05 -0700 (PDT) From: Don Lewis Subject: Re: [tcpm] SYN's in draft-ietf-tcpm-tcpsecure.txt :-) To: sandy@tislabs.com cc: tcpm@ietf.org In-Reply-To: <200405202150.i4KLocea021380@tislabs.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 20 May, Sandy Murphy wrote: >> RCV.NXT < SEG.SEQ || RCV.NXT >= SEG.SEQ+SEG.LEN >> Just send an ACK and drop the segment. If we received a >> legitimate SYN, the ACK will trigger a RST response. > > In the "corner case" that's the current topic of conversation, > SEG.SEQ = RCV.NXT-1. That means that SEG.SEQ+SEG.LEN = RCV.NXT. > Which means that the ACK would look to a SYN-SENT peer like an > acceptable ACK, but with the SYN not set, the segment would be > dropped and ignored. Leading to new SYN's until timeout. Hmn, that case won't be seen if segment processing is done in the order specified by RFC 793. The SYN flag will be trimmed off and SEG.SEQ will be incremented before the first step (page 69) before the SYN flag is examined in the fourth step (page 71). _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 20 19:33: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 TAA05816 for ; Thu, 20 May 2004 19:33: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 1BQwyx-0006E6-9r for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 19:29:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KNTlG1023934 for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 19:29:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQwlf-00036X-EO for tcpm-web-archive@optimus.ietf.org; Thu, 20 May 2004 19:16: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 TAA04812 for ; Thu, 20 May 2004 19:16: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 1BQwld-0001FK-Tx for tcpm-web-archive@ietf.org; Thu, 20 May 2004 19:16:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQwkc-000169-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 19:14:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQwjk-00010L-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 19:14:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQwcw-0000Xr-Ec; Thu, 20 May 2004 19:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQwVA-0007BN-Rh for tcpm@optimus.ietf.org; Thu, 20 May 2004 18:59: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 SAA04102 for ; Thu, 20 May 2004 18: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 1BQwV7-0000D6-Kk for tcpm@ietf.org; Thu, 20 May 2004 18:58:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQwUK-0000BA-00 for tcpm@ietf.org; Thu, 20 May 2004 18:58: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 1BQwTY-00003f-00 for tcpm@ietf.org; Thu, 20 May 2004 18:57:20 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 20 May 2004 15:02:54 +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 i4KMuk8T007705; Thu, 20 May 2004 15:56:48 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id AUI70283; Thu, 20 May 2004 15:56:46 -0700 (PDT) Message-ID: <40ACD3C8.7060900@cisco.com> Date: Thu, 20 May 2004 11:50:32 -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: "Charlet, Ricky" CC: tcpm@ietf.org Subject: Re: [tcpm] tcpsecure: request clarification on data injection solution References: <2EFAFC388B9C4C48B581846AEC20A020016CA883@scexch01.arc.com> In-Reply-To: <2EFAFC388B9C4C48B581846AEC20A020016CA883@scexch01.arc.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 Charlet, Ricky wrote: >Howdy, > > I'm attempting to implement draft-ietf-tcpm-tcpsecure-00.txt. I >would appreciate a better description of how each (RST, SYN, >data-injection) work in practice. The RST and SYN, I think I have pretty >much figured out. But the data-injection solution is beyond my capacity >to grok. > > The draft says: >----------------cut----------------- >4.2 Solution > > > 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). >---------------paste------------------ > Well for FreeBSD the fix I did simply does the following: *************************************** if(tlen && (thflags & TH_ACK) && (SEQ_LT(th->th_ack,(tp->snd_una - tp->max_sndwnd)))) { goto drop; } *************************************** max_sndwnd is a variable FreeBSD was already maintaining. We subtract snd_una - max_sndwnd... since it is all unsigned that places it somewhere behind SND_UNA by the largest window. We check to see if th_ack (what came in the segment) is behind this value with the SEQ_LT macro. If so we goto the fixed point that is in the BSD code to drop the segment... Pretty simple fix and it just takes advantage of the standard macros that are there (I would imagine most tcp stacks have this type of macro's laying around since they all have to deal with unsigned 32 bit arith.... Hope that helps.. R > > How can we subtract a number of bytes from a sequence number and >compare that to other expected sequence numbers? I assume it does work >out, but I don't see why it does. And I deeply suspect that I would mess >up the zero-wrap-around math sicne I don't really see why this >'solution' works. > > Also > >" This window is the scaled value i.e. the value may be larger than >65,535 bytes." > >Can someone shed more light on what you mean by 'scaled value' (as >opposed to what other alternative)? > > >Thanks in advance. > >--- >Ricky Charlet >Ricky.Charlet@arc.com >USA 831.466.4968 > >0 ASCII Ribbon campaign - against HTML Email >^ - against auto-execute attachments > > > > > > > > > >--- >Ricky Charlet >Ricky.Charlet@arc.com >USA 831.466.4968 > >----------------------------------------------------------- >Unless otherwise expressly stated, this message does not >create or vary any contractual relationship between you and >ARC International. The contents of this e-mail may be >confidential and if you have received it in error, please >delete it from your system, destroy any hard copies and >telephone the above number. Incoming emails to ARC may be >subject to monitoring other than by the addressee. > >_______________________________________________ >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 May 20 19: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 TAA05886 for ; Thu, 20 May 2004 19: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 1BQwz4-0006GL-Vh for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 19:29:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KNTsxL024065 for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 19:29:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQwlq-0003DC-9d for tcpm-web-archive@optimus.ietf.org; Thu, 20 May 2004 19:16: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 TAA04836 for ; Thu, 20 May 2004 19:16: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 1BQwlo-0001Gp-OX for tcpm-web-archive@ietf.org; Thu, 20 May 2004 19:16:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQwkx-00018a-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 19:15:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQwk0-000131-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 19:14:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQwdt-00019Q-K4; Thu, 20 May 2004 19:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQwZ3-0007ZJ-23 for tcpm@optimus.ietf.org; Thu, 20 May 2004 19:03: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 TAA04231 for ; Thu, 20 May 2004 19:02: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 1BQwYz-0000Qi-Qh for tcpm@ietf.org; Thu, 20 May 2004 19:02:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQwYD-0000O1-00 for tcpm@ietf.org; Thu, 20 May 2004 19:02:10 -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 1BQwXH-0000HG-00 for tcpm@ietf.org; Thu, 20 May 2004 19:01:11 -0400 Received: from catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id i4KN0S7E027306; Thu, 20 May 2004 16:00:32 -0700 (PDT) (envelope-from dl-tcpm@catspoiler.org) Message-Id: <200405202300.i4KN0S7E027306@gw.catspoiler.org> Date: Thu, 20 May 2004 16:00:28 -0700 (PDT) From: Don Lewis Subject: Re: [tcpm] tcpsecure: what about FIN attacks? To: Ricky.Charlet@arc.com cc: tcpm@ietf.org In-Reply-To: <2EFAFC388B9C4C48B581846AEC20A020016CA886@scexch01.arc.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 20 May, Charlet, Ricky wrote: > Howdy, > > draft-ietf-tcpm-tcpsecure-00.txt does not provide a discussion > of defence against blind attackers sending FIN packets with good guesses > for sequence numbers. Are FIN packets not a concern here? If not, why > not? That is essentially the same as a blind data injection attack. Checking the ACK value to prevent data from being injected would also prevent a FIN from being injected. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Thu May 20 20:11: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 UAA07713 for ; Thu, 20 May 2004 20:11: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 1BQxUl-0006GF-7l for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 20:02:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4L02d69024068 for tcpm-archive@odin.ietf.org; Thu, 20 May 2004 20:02:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQxTH-0005pv-MU for tcpm-web-archive@optimus.ietf.org; Thu, 20 May 2004 20:01: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 UAA07177 for ; Thu, 20 May 2004 20:01: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 1BQxTF-0004TK-Qs for tcpm-web-archive@ietf.org; Thu, 20 May 2004 20:01:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQxSQ-0004QT-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 20:00:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQxS0-0004MR-00 for tcpm-web-archive@ietf.org; Thu, 20 May 2004 19:59:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQxLS-0003Sx-J2; Thu, 20 May 2004 19:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQxGq-0002LA-EQ for tcpm@optimus.ietf.org; Thu, 20 May 2004 19:48: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 TAA06697 for ; Thu, 20 May 2004 19:48: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 1BQxGo-0003gB-KZ for tcpm@ietf.org; Thu, 20 May 2004 19:48:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQxFv-0003c4-00 for tcpm@ietf.org; Thu, 20 May 2004 19:47:20 -0400 Received: from sbcs.sunysb.edu ([130.245.1.15] helo=sbcs.cs.sunysb.edu) by ietf-mx with esmtp (Exim 4.12) id 1BQxF7-0003XP-00 for tcpm@ietf.org; Thu, 20 May 2004 19:46:29 -0400 Received: from compserv3 (compserv3 [130.245.1.116]) by sbcs.cs.sunysb.edu (8.12.3/8.12.3) with ESMTP id i4KNg9Y2000444 for ; Thu, 20 May 2004 19:42:09 -0400 (EDT) Date: Thu, 20 May 2004 19:42:11 -0400 (EDT) From: Kostas Pentikousis X-X-Sender: kostas@compserv3 To: tcpm@ietf.org In-Reply-To: <4.3.2.7.2.20040520141222.00c77670@mail.daleclick.com> Message-ID: References: <4.3.2.7.2.20040520141222.00c77670@mail.daleclick.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [tcpm] ATO & AUTO 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 folks, FWIW, I would prefer a single document addressing the problem. Both drafts have good points and seem quite complimentary. The initial request/negotiation in ATO and the "suggestion" in AUTO can be merged. A single bit can indicate whether this is a suggestion (AUTO) or a (strict) request (ATO). I like the idea of knowing whether one's request/suggestion will be in effect after connection setup. This is present in ATO but missing from AUTO. On the other hand, I like the "Granularity" bit proposed in AUTO (but missing from ATO). AUTO allows for announcing a different timeout value after connection establishment, while ATO leaves the issue open for a future refinement. Yet another point where they can be merged. Finally, while ATO has a more detailed Security section AUTO features an interoperability section. (I am no security expert, so take this with a couple of extra grains of salt :) There is simply too much common material to have two "competing" proposals dealing with the problem. Of course there are issues to be straightened out, but I see little reason to introduce alternative mechanisms, request different TCP option kind numbers etc. More comments and nits sent directly to the authors. Best regards, Kostas PS: Is there any reason for calling the same thing USER TIMEOUT in one document and abort timeout in the other? __________________________________________________________________ Kostas Pentikousis www.cs.stonybrook.edu/~kostas _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri May 21 00:59: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 AAA21439 for ; Fri, 21 May 2004 00:59: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 1BR26F-0002n2-Jq for tcpm-archive@odin.ietf.org; Fri, 21 May 2004 00:57:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4L4vdNw010724 for tcpm-archive@odin.ietf.org; Fri, 21 May 2004 00:57:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR22H-00022g-Tz for tcpm-web-archive@optimus.ietf.org; Fri, 21 May 2004 00:53: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 AAA20484 for ; Fri, 21 May 2004 00:53: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 1BR22E-0000rB-Vn for tcpm-web-archive@ietf.org; Fri, 21 May 2004 00:53:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR1yd-00008k-00 for tcpm-web-archive@ietf.org; Fri, 21 May 2004 00:49:47 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BR1x8-0007jK-03 for tcpm-web-archive@ietf.org; Fri, 21 May 2004 00:48:14 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BR1tm-0005Q8-Ey for tcpm-web-archive@ietf.org; Fri, 21 May 2004 00:44:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR1nH-0007GW-6Y; Fri, 21 May 2004 00:38:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR1id-00060N-5I for tcpm@optimus.ietf.org; Fri, 21 May 2004 00:33: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 AAA19878 for ; Fri, 21 May 2004 00:33: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 1BR1ia-0006Nu-HO for tcpm@ietf.org; Fri, 21 May 2004 00:33:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR1hd-0006Hg-00 for tcpm@ietf.org; Fri, 21 May 2004 00:32:14 -0400 Received: from jive.softhome.net ([66.54.152.27]) by ietf-mx with smtp (Exim 4.12) id 1BR1h3-0006C1-00 for tcpm@ietf.org; Fri, 21 May 2004 00:31:37 -0400 Received: (qmail 13821 invoked by uid 417); 21 May 2004 04:31:38 -0000 Received: from charleston-.softhome.net (HELO softhome.net) (172.16.2.12) by shunt-smtp-out-0 with SMTP; 21 May 2004 04:31:38 -0000 Received: from fernando.softhome.net ([200.70.172.46]) (AUTH: LOGIN fgont@softhome.net) by softhome.net with esmtp; Thu, 20 May 2004 22:31:34 -0600 Message-Id: <4.3.2.7.2.20040521002558.00c5ece0@mail.daleclick.com> X-Sender: fgont@pop.softhome.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 May 2004 01:37:43 -0300 To: Kostas Pentikousis , tcpm@ietf.org From: Fernando Gont Subject: Re: [tcpm] ATO & AUTO In-Reply-To: References: <4.3.2.7.2.20040520141222.00c77670@mail.daleclick.com> <4.3.2.7.2.20040520141222.00c77670@mail.daleclick.com> Mime-Version: 1.0 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 At 19:42 20/05/2004 -0400, you wrote: >The initial request/negotiation in ATO and the "suggestion" in >AUTO can be merged. A single bit can indicate whether this is a >suggestion (AUTO) or a (strict) request (ATO). Is there any good reason for a "strict" request? Say host A wants to communicate with host B. Say host A is a mobile host connected to the network by means of a wireless link, and host B is connected to the network by means of a DSL link. Say host A suggests B a USER TIMEOUT of 10 minutes. All host A wants to do is let host B know that it should be using a USER TIMEOUT of at least 10 minutes, or else it may end up aborting connections unnecessarily. It's up to B what it ends up doing. What's the reason for having host A know what USER TIMEOUT host B will use? OTOH, what's host A supposed to do if host B doesn't honor its suggestion? Close the connection? >I like the idea of knowing whether one's request/suggestion will >be in effect after connection setup. This is present in ATO but >missing from AUTO. It's *intentionally* "missing" in the AUTO option. >AUTO allows for announcing a different timeout value after >connection establishment, while ATO leaves the issue open for a >future refinement. Yet another point where they can be merged. Once again: what would you do if, while a connection is in the ESTABLISHED state, you suggest a USER TIMEOUT value to the remote TCP peer, and it does not honor it? >Finally, while ATO has a more detailed Security section AUTO >features an interoperability section. (I am no security expert, >so take this with a couple of extra grains of salt :) IMHO, it's not that the "Security Implications" section in the AUTO Option draft is less detailed: it's just that I considered that the option does not really raise any new "Security Implications". Note that TCP requires no message exchange for maintaining connections in the ESTABLISHED state. So you don't need the AUTO Option for performing this type of attack. You could just connect to any service, wait for their greeting message, and then throw away the connection. The server will keep resources for the connection, as it will wait for you to send data to it. Furthermore, there are protocols (for example, HTTP) which won't even send a greeting message... so you could just complete TCP's three-way handshake, and then throw away the connection immediately. So the AUTO option does not really raise any *new* type of attack. >PS: Is there any reason for calling the same thing USER TIMEOUT in >one document and abort timeout in the other? In the AUTO draft, I use "USER TIMEOUT" to refer to the timeout parameter defined in the original TCP specification (RFC 793). As for the option name, I sent a comment to Lars (and posted it to this list, too) on this issue. It's not the "abort" that times out, but the *user* (or the "connection", 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 Fri May 21 10:15:35 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 KAA03258 for ; Fri, 21 May 2004 10:15: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 1BRAbY-0008Fo-VJ for tcpm-archive@odin.ietf.org; Fri, 21 May 2004 10:02:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LE2W9v031712 for tcpm-archive@odin.ietf.org; Fri, 21 May 2004 10:02:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRAYo-0005xw-5y for tcpm-web-archive@optimus.ietf.org; Fri, 21 May 2004 09:59: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 JAA01943 for ; Fri, 21 May 2004 09:59: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 1BRAYm-0002an-87 for tcpm-web-archive@ietf.org; Fri, 21 May 2004 09:59:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRAXo-0002Ob-00 for tcpm-web-archive@ietf.org; Fri, 21 May 2004 09:58:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRAX9-0002Cp-00 for tcpm-web-archive@ietf.org; Fri, 21 May 2004 09:57:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRAEv-0001Z2-OM; Fri, 21 May 2004 09: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 1BRACV-0000TS-Cf for tcpm@optimus.ietf.org; Fri, 21 May 2004 09:36: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 JAA00823 for ; Fri, 21 May 2004 09:36: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 1BRACT-0005ST-HO for tcpm@ietf.org; Fri, 21 May 2004 09:36:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRABX-0005Gv-00 for tcpm@ietf.org; Fri, 21 May 2004 09:35:39 -0400 Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 1BRAAn-00055T-00 for tcpm@ietf.org; Fri, 21 May 2004 09:34:53 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4LDWLGN005364 for ; Fri, 21 May 2004 09:32:21 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAoLaqCk; Fri, 21 May 04 09:32:19 -0400 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id i4LDXdkG002261; Fri, 21 May 2004 09:33:39 -0400 (EDT) Date: Fri, 21 May 2004 09:33:39 -0400 (EDT) From: Sandy Murphy Message-Id: <200405211333.i4LDXdkG002261@tislabs.com> To: dl-tcpm@catspoiler.org Subject: Re: [tcpm] SYN's in draft-ietf-tcpm-tcpsecure.txt :-) Cc: sandy@tislabs.com, tcpm@ietf.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 >Hmn, that case won't be seen if segment processing is done in the order >specified by RFC 793. The SYN flag will be trimmed off and SEG.SEQ will >be incremented before the first step (page 69) before the SYN flag is >examined in the fourth step (page 71). Now I'm confused. In your first message you said: >This particular case motivated me to move the SYN handling code from >after the segment is trimmed to fit the window to before the segment is >trimmed to fit the window in the vulnerability fix that I am proposing >to implement in FreeBSD. So where does your new code fit? --Sandy _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri May 21 14:24: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 OAA19632 for ; Fri, 21 May 2004 14:24: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 1BREb2-0003Yc-9h for tcpm-archive@odin.ietf.org; Fri, 21 May 2004 14:18:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LIIG8B013674 for tcpm-archive@odin.ietf.org; Fri, 21 May 2004 14:18:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRESj-0001ew-DL for tcpm-web-archive@optimus.ietf.org; Fri, 21 May 2004 14:09: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 OAA18893 for ; Fri, 21 May 2004 14:09: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 1BRESh-0001Kz-1U for tcpm-web-archive@ietf.org; Fri, 21 May 2004 14:09:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRERf-0001GA-00 for tcpm-web-archive@ietf.org; Fri, 21 May 2004 14:08:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BREQk-0001CC-00 for tcpm-web-archive@ietf.org; Fri, 21 May 2004 14:07:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BREJZ-0007vP-Dz; Fri, 21 May 2004 14:00:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BREAM-0005sv-6s for tcpm@optimus.ietf.org; Fri, 21 May 2004 13:50: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 NAA17813 for ; Fri, 21 May 2004 13:50: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 1BREAJ-0007hS-U6 for tcpm@ietf.org; Fri, 21 May 2004 13:50:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRE9P-0007dD-00 for tcpm@ietf.org; Fri, 21 May 2004 13:49:44 -0400 Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 1BRE8P-0007Z2-00 for tcpm@ietf.org; Fri, 21 May 2004 13:48:41 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4LHk9YT007491 for ; Fri, 21 May 2004 13:46:09 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAbEaaOo; Fri, 21 May 04 13:46:08 -0400 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id i4LHlPFx013809; Fri, 21 May 2004 13:47:25 -0400 (EDT) Date: Fri, 21 May 2004 13:47:25 -0400 (EDT) From: Sandy Murphy Message-Id: <200405211747.i4LHlPFx013809@tislabs.com> To: ananth@cisco.com, dl-tcpm@catspoiler.org Subject: Re: [tcpm] SYN's in draft-ietf-tcpm-tcpsecure.txt :-) Cc: mdalal@cisco.com, sandy@tislabs.com, tcpm@ietf.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 Mitesh said: >2. when the SYN has an ISN of RCV.NXT-1 and is within the window >of our ESTAB connection, here we are proposing to send an ACK >with value RCV.NXT-1 and not RCV.NXT-2. As Allwyn and Don have pointed out, this is not sufficient if the SYN contains data. The restarted peer is going to test: SND.UNA < SEG.ACK =< SND.NXT (*) to see if the ACK is acceptable. That means that if SEG.SEQ < RCV.NXT and RCV.NXT <= SEG.SEQ+SEG.LEN , then no RST will be coming back and both sides will have to timeout. [(*) Actually, the RFC793 text says: "If SND.UNA =< SEG.ACK =< SND.NXT then the ACK is acceptable." but that's a typo (not addressed by rfc1122) since the = case was already treated a few lines above and doesn't make any sense to be acceptable anyway] So the suggested behavior, if it's purpose is to avoid the timeout in this "corner" case, should be: 2. when the SYN has an SEG.SEQ such that SEG.SEQ < RCV.NXT <= SEG.SEQ+SEG.LEN here we are proposing to send an ACK with value SEG.SEQ ... Another interesting point: Don's suggested cases don't attempt to avoid the timeout of the corner case half-open connections. He does attempt to avoid sending useless ACK's, but he doesn't adjust the ACK's to kill the half-open connections. --Sandy _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri May 21 14:32: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 OAA20158 for ; Fri, 21 May 2004 14:32: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 1BREmJ-0006Uo-Fi for tcpm-archive@odin.ietf.org; Fri, 21 May 2004 14:29:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LITtl3024971 for tcpm-archive@odin.ietf.org; Fri, 21 May 2004 14:29:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BREiG-0005Sm-ND for tcpm-web-archive@optimus.ietf.org; Fri, 21 May 2004 14:25: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 OAA19746 for ; Fri, 21 May 2004 14:25: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 1BREiE-0002dQ-9J for tcpm-web-archive@ietf.org; Fri, 21 May 2004 14:25:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BREhR-0002aP-00 for tcpm-web-archive@ietf.org; Fri, 21 May 2004 14:24:54 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BREh4-0002W9-00 for tcpm-web-archive@ietf.org; Fri, 21 May 2004 14:24:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BREef-0004X9-9e; Fri, 21 May 2004 14: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 1BRETu-0002An-Dt for tcpm@optimus.ietf.org; Fri, 21 May 2004 14:10: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 OAA18987 for ; Fri, 21 May 2004 14:10: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 1BRETr-0001SB-II for tcpm@ietf.org; Fri, 21 May 2004 14:10:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRESw-0001NB-00 for tcpm@ietf.org; Fri, 21 May 2004 14:09:55 -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 1BRES0-0001Dw-00 for tcpm@ietf.org; Fri, 21 May 2004 14:08:56 -0400 Received: from catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id i4LI7s7E029580; Fri, 21 May 2004 11:07:57 -0700 (PDT) (envelope-from dl-tcpm@catspoiler.org) Message-Id: <200405211807.i4LI7s7E029580@gw.catspoiler.org> Date: Fri, 21 May 2004 11:07:54 -0700 (PDT) From: Don Lewis Subject: Re: [tcpm] SYN's in draft-ietf-tcpm-tcpsecure.txt :-) To: sandy@tislabs.com cc: ananth@cisco.com, mdalal@cisco.com, tcpm@ietf.org In-Reply-To: <200405211747.i4LHlPFx013809@tislabs.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 May, Sandy Murphy wrote: > Mitesh said: > >>2. when the SYN has an ISN of RCV.NXT-1 and is within the window >>of our ESTAB connection, here we are proposing to send an ACK >>with value RCV.NXT-1 and not RCV.NXT-2. > > As Allwyn and Don have pointed out, this is not sufficient if > the SYN contains data. The restarted peer is going to test: > > SND.UNA < SEG.ACK =< SND.NXT (*) > > to see if the ACK is acceptable. That means that if SEG.SEQ < RCV.NXT > and RCV.NXT <= SEG.SEQ+SEG.LEN , then no RST will be coming back and > both sides will have to timeout. > > [(*) Actually, the RFC793 text says: > "If SND.UNA =< SEG.ACK =< SND.NXT then the ACK is acceptable." > but that's a typo (not addressed by rfc1122) since the = case > was already treated a few lines above and doesn't make any sense > to be acceptable anyway] > > So the suggested behavior, if it's purpose is to avoid the timeout in > this "corner" case, should be: > > 2. when the SYN has an SEG.SEQ such that > SEG.SEQ < RCV.NXT <= SEG.SEQ+SEG.LEN here we are proposing to send > an ACK with value SEG.SEQ ... > > > Another interesting point: Don's suggested cases don't attempt to > avoid the timeout of the corner case half-open connections. He does > attempt to avoid sending useless ACK's, but he doesn't adjust the > ACK's to kill the half-open connections. The biggest problem is the ACK value might have to be decreased by a large value (the maximum segment size) in order to provoke a RST response and that would cause the RST sequence number to be equally far outside the window. In order to detect the RST, we would either have to widen the window of acceptable RST sequence numbers, which makes the RST vulnerability worse, or add a bunch of connection state that keeps track of the acceptable RST sequence numbers. My plan is to punt on this case because it should be rare. Also the FreeBSD T/TCP implementation falls back to just sending a SYN with no data if it doesn't see a response after the first few SYN segments. A possible way to fix this problem is to trigger a keepalive sequence. If the expected keepalive response is not received, assume that the SYN is legitmate and drop the existing connection. BTW, there is also the possibility of a similar problem in the RCV.NXT > SEG.SEQ+SEG.LEN case if the peer has sent additional data segments along with the SYN, which seems to be legal, though probably a bad idea. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri May 21 14:50: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 OAA21226 for ; Fri, 21 May 2004 14:50: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 1BRF0n-0001CU-Rs for tcpm-archive@odin.ietf.org; Fri, 21 May 2004 14:44:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LIirXE004610 for tcpm-archive@odin.ietf.org; Fri, 21 May 2004 14:44:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BREuu-0008Fw-Du for tcpm-web-archive@optimus.ietf.org; Fri, 21 May 2004 14:38: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 OAA20739 for ; Fri, 21 May 2004 14:38: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 1BREur-0003cW-Iy for tcpm-web-archive@ietf.org; Fri, 21 May 2004 14:38:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BREtt-0003XX-00 for tcpm-web-archive@ietf.org; Fri, 21 May 2004 14:37:45 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BREt1-0003To-00 for tcpm-web-archive@ietf.org; Fri, 21 May 2004 14:36:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BREmV-0006Vs-6l; Fri, 21 May 2004 14:30:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BREgK-00059W-QB for tcpm@optimus.ietf.org; Fri, 21 May 2004 14:23: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 OAA19623 for ; Fri, 21 May 2004 14:23: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 1BREgI-0002UP-4x for tcpm@ietf.org; Fri, 21 May 2004 14:23:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BREfZ-0002Qd-00 for tcpm@ietf.org; Fri, 21 May 2004 14:22:58 -0400 Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 1BREej-0002MA-00 for tcpm@ietf.org; Fri, 21 May 2004 14:22:06 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4LIJYdN012090 for ; Fri, 21 May 2004 14:19:34 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAd4a4Lx; Fri, 21 May 04 14:19:28 -0400 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id i4LIKpa6015219; Fri, 21 May 2004 14:20:51 -0400 (EDT) Date: Fri, 21 May 2004 14:20:51 -0400 (EDT) From: Sandy Murphy Message-Id: <200405211820.i4LIKpa6015219@tislabs.com> To: tcpm@ietf.org Subject: Re: [tcpm] SYN's in draft-ietf-tcpm-tcpsecure.txt :-) Cc: sandy@tislabs.com 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 20 May, Don Lewis wrote: >On 20 May, Sandy Murphy wrote: >>> RCV.NXT < SEG.SEQ || RCV.NXT >= SEG.SEQ+SEG.LEN >>> Just send an ACK and drop the segment. If we received a >>> legitimate SYN, the ACK will trigger a RST response. >> >> In the "corner case" that's the current topic of conversation, >> SEG.SEQ = RCV.NXT-1. That means that SEG.SEQ+SEG.LEN = RCV.NXT. >> Which means that the ACK would look to a SYN-SENT peer like an >> acceptable ACK, but with the SYN not set, the segment would be >> dropped and ignored. Leading to new SYN's until timeout. > >Hmn, that case won't be seen if segment processing is done in the order >specified by RFC 793. The SYN flag will be trimmed off and SEG.SEQ will >be incremented before the first step (page 69) before the SYN flag is >examined in the fourth step (page 71). I think I see better now - you are talking about the current RFC793 processing of the corner case SYN, not your suggested improvement cases. The SYN could only be trimmed if the segment overlapped the window but the SYN itself would fall outside the window: i.e., if RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND but SEG.SEQ < RCV.NXT. Which would only happen if the length of the SYN was greater than 1. When the SYN has length 1, and SEG.SEQ=RCV.NXT-1, the segment is totally outside the window and an ACK is generated. But. That observation points out that a SYN that carries data that makes the segment overlap the window does not need to be considered in the corner case processing at all and my previous message was wrong. The SYN will disappear in the trimming process. It would be another case of blind data injection instead. --Sandy _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri May 21 15:57: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 PAA25826 for ; Fri, 21 May 2004 15:57: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 1BRG7W-0006uZ-N3 for tcpm-archive@odin.ietf.org; Fri, 21 May 2004 15:55:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LJtsiR026560 for tcpm-archive@odin.ietf.org; Fri, 21 May 2004 15:55:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRFz6-0005ai-D6 for tcpm-web-archive@optimus.ietf.org; Fri, 21 May 2004 15:47: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 PAA25010 for ; Fri, 21 May 2004 15: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 1BRFz4-0000xR-37 for tcpm-web-archive@ietf.org; Fri, 21 May 2004 15:47:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRFwU-0000T9-00 for tcpm-web-archive@ietf.org; Fri, 21 May 2004 15:44:31 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BRFue-00007n-02 for tcpm-web-archive@ietf.org; Fri, 21 May 2004 15:42: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 1BRFnO-0004Gk-22 for tcpm-web-archive@ietf.org; Fri, 21 May 2004 15:35:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRFec-0001dW-87; Fri, 21 May 2004 15:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRFYO-0008P0-AN for tcpm@optimus.ietf.org; Fri, 21 May 2004 15:19: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 PAA23738 for ; Fri, 21 May 2004 15:19: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 1BRFYM-0006cX-Nw for tcpm@ietf.org; Fri, 21 May 2004 15:19:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRFXT-0006Zq-00 for tcpm@ietf.org; Fri, 21 May 2004 15:18:39 -0400 Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 1BRFWU-0006WR-00 for tcpm@ietf.org; Fri, 21 May 2004 15:17:38 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4LJF7d5018001 for ; Fri, 21 May 2004 15:15:07 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAHTa4jJ; Fri, 21 May 04 15:15:06 -0400 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id i4LJGOQv017320; Fri, 21 May 2004 15:16:24 -0400 (EDT) Date: Fri, 21 May 2004 15:16:24 -0400 (EDT) From: Sandy Murphy Message-Id: <200405211916.i4LJGOQv017320@tislabs.com> To: mdalal@cisco.com, sandy@tislabs.com Subject: Re: [tcpm] SYN's in draft-ietf-tcpm-tcpsecure.txt :-) Cc: ananth@cisco.com, dl-tcpm@catspoiler.org, tcpm@ietf.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 >Irrespective of the sequence number of the incoming SYN, send an >ACK with ack of rcv.nxt. The corner cases of the SYN having data and >or being exactly equal to rcv.nxt-1 are both present in the base >spec and hence should exist even today.(i.e the timeout) and we are >better off leaving it untouched. the aim was to optimize it for the >corner case, but looks like it might not be worth it. I agree with this wholeheartedly! The choice between (a) rare timeouts (b) rare aborted connections and (c) new and unusual splinter case code added to implementations came down to (a), IMHO. --Sandy _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri May 21 15:57: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 PAA25880 for ; Fri, 21 May 2004 15:57: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 1BRG7Z-0006xN-G6 for tcpm-archive@odin.ietf.org; Fri, 21 May 2004 15:55:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LJtvQT026736 for tcpm-archive@odin.ietf.org; Fri, 21 May 2004 15:55:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRFzX-0005fI-GS for tcpm-web-archive@optimus.ietf.org; Fri, 21 May 2004 15:47: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 PAA25135 for ; Fri, 21 May 2004 15:47: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 1BRFzV-000136-TK for tcpm-web-archive@ietf.org; Fri, 21 May 2004 15:47:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRFx6-0000ap-00 for tcpm-web-archive@ietf.org; Fri, 21 May 2004 15:45:09 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BRFui-000080-00 for tcpm-web-archive@ietf.org; Fri, 21 May 2004 15:42:40 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BRFdS-00042q-7v for tcpm-web-archive@ietf.org; Fri, 21 May 2004 15:24:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRFQC-0007Pd-CN; Fri, 21 May 2004 15:11:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRFLv-00061C-EK for tcpm@optimus.ietf.org; Fri, 21 May 2004 15:06: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 PAA22470 for ; Fri, 21 May 2004 15:06: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 1BRFLs-0005pC-Dp for tcpm@ietf.org; Fri, 21 May 2004 15:06:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRFKx-0005lR-00 for tcpm@ietf.org; Fri, 21 May 2004 15:05:44 -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 1BRFK3-0005dS-00 for tcpm@ietf.org; Fri, 21 May 2004 15:04:47 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 21 May 2004 11:10:31 +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 i4LJ4FDe010052; Fri, 21 May 2004 12:04:16 -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 ATK00537; Fri, 21 May 2004 12:03:28 -0700 (PDT) Date: Fri, 21 May 2004 12:03:49 -0700 (PDT) From: Mitesh Dalal To: Sandy Murphy cc: ananth@cisco.com, dl-tcpm@catspoiler.org, tcpm@ietf.org Subject: Re: [tcpm] SYN's in draft-ietf-tcpm-tcpsecure.txt :-) In-Reply-To: <200405211747.i4LHlPFx013809@tislabs.com> Message-ID: References: <200405211747.i4LHlPFx013809@tislabs.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, 21 May 2004, Sandy Murphy wrote: > Mitesh said: > > >2. when the SYN has an ISN of RCV.NXT-1 and is within the window > >of our ESTAB connection, here we are proposing to send an ACK > >with value RCV.NXT-1 and not RCV.NXT-2. > > As Allwyn and Don have pointed out, this is not sufficient if > the SYN contains data. The restarted peer is going to test: > > SND.UNA < SEG.ACK =< SND.NXT (*) > > to see if the ACK is acceptable. That means that if SEG.SEQ < RCV.NXT > and RCV.NXT <= SEG.SEQ+SEG.LEN , then no RST will be coming back and > both sides will have to timeout. > > [(*) Actually, the RFC793 text says: > "If SND.UNA =< SEG.ACK =< SND.NXT then the ACK is acceptable." > but that's a typo (not addressed by rfc1122) since the = case > was already treated a few lines above and doesn't make any sense > to be acceptable anyway] > > So the suggested behavior, if it's purpose is to avoid the timeout in > this "corner" case, should be: > > 2. when the SYN has an SEG.SEQ such that > SEG.SEQ < RCV.NXT <= SEG.SEQ+SEG.LEN here we are proposing to send > an ACK with value SEG.SEQ ... > > > Another interesting point: Don's suggested cases don't attempt to > avoid the timeout of the corner case half-open connections. He does > attempt to avoid sending useless ACK's, but he doesn't adjust the > ACK's to kill the half-open connections. > the suggestion looks good, but we had some internal discussion and it seems that the best way forward is to simply do the following: Irrespective of the sequence number of the incoming SYN, send an ACK with ack of rcv.nxt. The corner cases of the SYN having data and or being exactly equal to rcv.nxt-1 are both present in the base spec and hence should exist even today.(i.e the timeout) and we are better off leaving it untouched. the aim was to optimize it for the corner case, but looks like it might not be worth it. thx Mitesh _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri May 21 17:22:00 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04760 for ; Fri, 21 May 2004 17:22: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 1BRHKa-0003Bz-Us for tcpm-archive@odin.ietf.org; Fri, 21 May 2004 17:13:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LLDSG2012271 for tcpm-archive@odin.ietf.org; Fri, 21 May 2004 17:13:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRH6e-0006Qq-G2 for tcpm-web-archive@optimus.ietf.org; Fri, 21 May 2004 16:59: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 QAA02823 for ; Fri, 21 May 2004 16:59: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 1BRH6b-0003Xa-Rl for tcpm-web-archive@ietf.org; Fri, 21 May 2004 16:59:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRH5O-0003IS-00 for tcpm-web-archive@ietf.org; Fri, 21 May 2004 16:57:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRH3p-0002zs-00 for tcpm-web-archive@ietf.org; Fri, 21 May 2004 16:56:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRGt5-0001CV-O8; Fri, 21 May 2004 16:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRGD3-0008J8-OB for tcpm@optimus.ietf.org; Fri, 21 May 2004 16:01: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 QAA26081 for ; Fri, 21 May 2004 16:01: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 1BRGD2-00029k-4Q for tcpm@ietf.org; Fri, 21 May 2004 16:01:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRGC4-00024Z-00 for tcpm@ietf.org; Fri, 21 May 2004 16:00:36 -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 1BRGB7-0001x9-00 for tcpm@ietf.org; Fri, 21 May 2004 15:59:37 -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 i4LJx4f9018417; Fri, 21 May 2004 12:59:04 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id AUK29885; Fri, 21 May 2004 12:59:04 -0700 (PDT) Message-ID: <40AE5F87.8070803@cisco.com> Date: Fri, 21 May 2004 15:59:03 -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: Sandy Murphy CC: mdalal@cisco.com, ananth@cisco.com, dl-tcpm@catspoiler.org, tcpm@ietf.org Subject: Re: [tcpm] SYN's in draft-ietf-tcpm-tcpsecure.txt :-) References: <200405211916.i4LJGOQv017320@tislabs.com> In-Reply-To: <200405211916.i4LJGOQv017320@tislabs.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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sandy/All: If there are NO other serious objections.. I will remove the corner case description and drop it completely.. Speak now if you object...otherwise I will massage some of Mitesh's wording into that section as appropriate for the -01 version :-D R Sandy Murphy wrote: >>Irrespective of the sequence number of the incoming SYN, send an >>ACK with ack of rcv.nxt. The corner cases of the SYN having data and >>or being exactly equal to rcv.nxt-1 are both present in the base >>spec and hence should exist even today.(i.e the timeout) and we are >>better off leaving it untouched. the aim was to optimize it for the >>corner case, but looks like it might not be worth it. >> >> > >I agree with this wholeheartedly! > >The choice between (a) rare timeouts (b) rare aborted connections >and (c) new and unusual splinter case code added to implementations >came down to (a), IMHO. > >--Sandy > >_______________________________________________ >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 May 21 17:22:01 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04785 for ; Fri, 21 May 2004 17:22: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 1BRHKc-0003Cr-97 for tcpm-archive@odin.ietf.org; Fri, 21 May 2004 17:13:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LLDUmW012317 for tcpm-archive@odin.ietf.org; Fri, 21 May 2004 17:13:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRH6v-0006Sz-5s for tcpm-web-archive@optimus.ietf.org; Fri, 21 May 2004 16:59: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 QAA02875 for ; Fri, 21 May 2004 16:59: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 1BRH6s-0003Zi-TH for tcpm-web-archive@ietf.org; Fri, 21 May 2004 16:59:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRH5n-0003Ms-00 for tcpm-web-archive@ietf.org; Fri, 21 May 2004 16:58:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRH4S-00036y-00 for tcpm-web-archive@ietf.org; Fri, 21 May 2004 16:56:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRGtQ-0001OU-Fd; Fri, 21 May 2004 16:45:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRGLr-0002c0-9x for tcpm@optimus.ietf.org; Fri, 21 May 2004 16:10: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 QAA26766 for ; Fri, 21 May 2004 16:10: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 1BRGLp-00039S-Fe for tcpm@ietf.org; Fri, 21 May 2004 16:10:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRGKr-00033m-00 for tcpm@ietf.org; Fri, 21 May 2004 16:09:41 -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 1BRGJx-0002vL-00 for tcpm@ietf.org; Fri, 21 May 2004 16:08:46 -0400 Received: from catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id i4LK7v7E029806; Fri, 21 May 2004 13:08:01 -0700 (PDT) (envelope-from dl-tcpm@catspoiler.org) Message-Id: <200405212008.i4LK7v7E029806@gw.catspoiler.org> Date: Fri, 21 May 2004 13:07:57 -0700 (PDT) From: Don Lewis Subject: Re: [tcpm] SYN's in draft-ietf-tcpm-tcpsecure.txt :-) To: rrs@cisco.com cc: sandy@tislabs.com, mdalal@cisco.com, ananth@cisco.com, tcpm@ietf.org In-Reply-To: <40AE5F87.8070803@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 May, Randall Stewart (cisco) wrote: > Sandy/All: > > If there are NO other serious objections.. I will remove > the corner case description and drop it completely.. I think the corner case should be mentioned along with the rationale for not treating it specially. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Fri May 21 17:22:24 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04845 for ; Fri, 21 May 2004 17:22: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 1BRHKf-0003F9-SS for tcpm-archive@odin.ietf.org; Fri, 21 May 2004 17:13:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LLDXYO012453 for tcpm-archive@odin.ietf.org; Fri, 21 May 2004 17:13:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRH8f-0007yk-23 for tcpm-web-archive@optimus.ietf.org; Fri, 21 May 2004 17:01: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 RAA03022 for ; Fri, 21 May 2004 17:01: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 1BRH8c-0003sy-SB for tcpm-web-archive@ietf.org; Fri, 21 May 2004 17:01:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRH7d-0003iq-00 for tcpm-web-archive@ietf.org; Fri, 21 May 2004 17:00:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRH6g-0003Y4-00 for tcpm-web-archive@ietf.org; Fri, 21 May 2004 16:59:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRGu5-0001g0-Nk; Fri, 21 May 2004 16:46:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRGU1-0005NI-1v for tcpm@optimus.ietf.org; Fri, 21 May 2004 16:19: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 QAA27524 for ; Fri, 21 May 2004 16: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 1BRGTz-0004KW-8j for tcpm@ietf.org; Fri, 21 May 2004 16:19:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRGSj-000451-00 for tcpm@ietf.org; Fri, 21 May 2004 16:17:49 -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 1BRGRK-0003qG-01 for tcpm@ietf.org; Fri, 21 May 2004 16:16:22 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 21 May 2004 12:22:11 +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 i4LKFsf9007358; Fri, 21 May 2004 13:15:55 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id AUK31936; Fri, 21 May 2004 13:15:54 -0700 (PDT) Message-ID: <40AE6379.5000108@cisco.com> Date: Fri, 21 May 2004 16:15:53 -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: Don Lewis CC: sandy@tislabs.com, mdalal@cisco.com, ananth@cisco.com, tcpm@ietf.org Subject: Re: [tcpm] SYN's in draft-ietf-tcpm-tcpsecure.txt :-) References: <200405212008.i4LK7v7E029806@gw.catspoiler.org> In-Reply-To: <200405212008.i4LK7v7E029806@gw.catspoiler.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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Don Lewis wrote: >On 21 May, Randall Stewart (cisco) wrote: > > >>Sandy/All: >> >>If there are NO other serious objections.. I will remove >>the corner case description and drop it completely.. >> >> > >I think the corner case should be mentioned along with the rationale for >not treating it specially. > > > > I believe that is what Mitesh's wording (or at least some of it) covers :-D 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 Fri May 21 21:31:50 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17855 for ; Fri, 21 May 2004 21:31: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 1BRLKh-0004H5-He for tcpm-archive@odin.ietf.org; Fri, 21 May 2004 21:29:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4M1TpM0016427 for tcpm-archive@odin.ietf.org; Fri, 21 May 2004 21:29:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRLE8-000324-5g for tcpm-web-archive@optimus.ietf.org; Fri, 21 May 2004 21: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 VAA17628 for ; Fri, 21 May 2004 21:23: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 1BRLE5-0005oh-DQ for tcpm-web-archive@ietf.org; Fri, 21 May 2004 21:23:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRLDE-0005jB-00 for tcpm-web-archive@ietf.org; Fri, 21 May 2004 21:22:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRLCa-0005c4-00 for tcpm-web-archive@ietf.org; Fri, 21 May 2004 21:21:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRLAD-00024K-LE; Fri, 21 May 2004 21: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 1BRL0N-0008Tv-Sa for tcpm@optimus.ietf.org; Fri, 21 May 2004 21:08: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 VAA16847 for ; Fri, 21 May 2004 21:08: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 1BRL0L-00046v-C2 for tcpm@ietf.org; Fri, 21 May 2004 21:08:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRKzR-00041q-00 for tcpm@ietf.org; Fri, 21 May 2004 21:07:54 -0400 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1BRKyw-0003wN-00 for tcpm@ietf.org; Fri, 21 May 2004 21:07:22 -0400 Received: from horh1.emsr.lucent.com (h135-17-1-40.lucent.com [135.17.1.40]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4M16lj24893; Fri, 21 May 2004 20:06:48 -0500 (CDT) Received: from new-wopr.eng.ascend.com ([135.140.53.19]) by horh1.emsr.lucent.com (8.11.7+Sun/EMS-1.5 Solaris/emsr) id i4M16kF07275 for ; Fri, 21 May 2004 20:06:46 -0500 (CDT) Received: from grigri.eng.ascend.com (grigri.eng.ascend.com [135.140.53.45]) by new-wopr.eng.ascend.com (8.11.6+Sun/8.10.2) with ESMTP id i4M16kB06696; Fri, 21 May 2004 18:06:46 -0700 (PDT) Received: from lucent.com (gauri.eng.ascend.com [135.140.26.53]) by grigri.eng.ascend.com (8.8.8+Sun/8.8.8) with ESMTP id SAA04558; Fri, 21 May 2004 18:06:45 -0700 (PDT) Message-ID: <40AEA7A5.A7748B26@lucent.com> Date: Fri, 21 May 2004 18:06:45 -0700 From: Allwyn Carvalho X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Randall Stewart (cisco)" CC: Sandy Murphy , tcpm@ietf.org Subject: Re: [tcpm] blind data injection References: <200405191503.i4JF3kXZ029657@tislabs.com> <40AC09A1.6090605@cisco.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 How about treating out-of-order packets that don't "line up" as suspect. In the case below, Z buffers out-of-order bytes 2200-3200 presuming that they are genuine out-of-order bytes. If it gets data 200-2199 from A, then it treats 2200-3200 as valid and forwards it to the application. If however it gets 200-2210 (as below), then it treats the buffered data 2200-3200 as suspect and drops it. Along with this is the implicit recommendation (should perhaps be made explicit) that new data overrides old data. So, bytes 2200-2210 should be taken from the new segment, not from the buffered segment. Chances are more likely than not that blind data injected bytes will not "line up", whereas genuine out-of-order bytes always will. Allwyn. "Randall Stewart (cisco)" wrote: > > Sandy: > > One thing we have found in our testing is that when > data is injected and sits in a reassmebly buffer .. once the > peer catches up and bridges the "injected" portion an > ack war begins... > > For example > > A Z (rcv.nxt =200) > > Evil-guy-----Inject(2200 - 3200)------------> > > Now when A sends > > > --------------------Data(200-2210)----------------------------------> > > Z sends (XX:) > <---------------------------------ACK(3200) > A says.. hey my peer is messed up and sends > ------------------------ACK(x,2210)-------------------------_> > Z says .. hey my peer is messed up and sends goto XX; > > This continues until the connection falls apart. Sometimes if A > is sending lots of data it then gets past 3200 in my example and > the injected data bubbles up.. but as you point out most apps > will then get out of sync.. and depending on the app it may > abort the connection... since it is usually reading a framed message > size and the framing is now hosed and it does not know how to > recover... of course mileage may vary .. > > R > > Sandy Murphy wrote: > > >The tcpsecure draft notes that data can be accepted by the TCP > >implementation if any of the segment's bytes fall within the receive > >window, not just at the left edge of the window. But TCP does not > >require that out-of-order segments are buffered. I don't know how > >ubiquitous it is for implementations to do the buffering. (RFC1122 > >makes it a "should".) I can find no place where the TCP spec speaks > >of what to do if a later arriving segment overlaps a previously queued > >out-of-order segment. I can see the possibility that the later > >arriving data could overwrite the previously queued data. Unix tcp > >code I've looked at seems to let recently arrived segments overwrite > >succeeding queued out-of-order segments (but queued preceding segments > >overwrite the recently arrived segments). > > > >That would mean that the eventual delivery of bogus injected data to > >the application would depend on the spacing of the arrival of any real > >segments covering the same sequence number space as the bogus injected > >data. A blind attacker could not predict what if any of the bogus > >injected data would be delivered to the application. > > > >Furthermore, any application level framing could cause any bogus > >injected data that did manage to be delivered to fail the parse step > >in the application. So BGP, in particular, which has such framing, > >would be in much less danger of accepting the bogus data. It would be > >much more likely that any injected data that did manage to reach BGP > >would not pass the parsing and would cause the connection to abort. > >That's not a good result, but it's better than accepting bogus > >injected data. > > > >--Sandy > > > >_______________________________________________ > >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 May 21 21:42:38 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18305 for ; Fri, 21 May 2004 21:42: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 1BRLLk-0004Ue-PC for tcpm-archive@odin.ietf.org; Fri, 21 May 2004 21:30:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4M1Uu5i017267 for tcpm-archive@odin.ietf.org; Fri, 21 May 2004 21:30:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRLGo-0003UR-6J for tcpm-web-archive@optimus.ietf.org; Fri, 21 May 2004 21:25: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 VAA17697 for ; Fri, 21 May 2004 21:25: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 1BRLGl-00066K-DN for tcpm-web-archive@ietf.org; Fri, 21 May 2004 21:25:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRLFm-00060K-00 for tcpm-web-archive@ietf.org; Fri, 21 May 2004 21:24:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRLEn-0005rh-00 for tcpm-web-archive@ietf.org; Fri, 21 May 2004 21:23:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRLBK-0002Qb-Ec; Fri, 21 May 2004 21:20:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRL5D-0000oz-EL for tcpm@optimus.ietf.org; Fri, 21 May 2004 21:13: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 VAA17260 for ; Fri, 21 May 2004 21:13: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 1BRL5A-0004vs-OS for tcpm@ietf.org; Fri, 21 May 2004 21:13:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRL4E-0004ou-00 for tcpm@ietf.org; Fri, 21 May 2004 21:12:51 -0400 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1BRL3L-0004Wb-00 for tcpm@ietf.org; Fri, 21 May 2004 21:11:55 -0400 Received: from horh1.emsr.lucent.com (h135-17-1-40.lucent.com [135.17.1.40]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4M1BJj28825; Fri, 21 May 2004 20:11:19 -0500 (CDT) Received: from new-wopr.eng.ascend.com ([135.140.53.19]) by horh1.emsr.lucent.com (8.11.7+Sun/EMS-1.5 Solaris/emsr) id i4M1BIF13553 for ; Fri, 21 May 2004 20:11:18 -0500 (CDT) Received: from grigri.eng.ascend.com (grigri.eng.ascend.com [135.140.53.45]) by new-wopr.eng.ascend.com (8.11.6+Sun/8.10.2) with ESMTP id i4M1BHB06810; Fri, 21 May 2004 18:11:17 -0700 (PDT) Received: from lucent.com (gauri.eng.ascend.com [135.140.26.53]) by grigri.eng.ascend.com (8.8.8+Sun/8.8.8) with ESMTP id SAA04657; Fri, 21 May 2004 18:11:17 -0700 (PDT) Message-ID: <40AEA8B5.5E79F175@lucent.com> Date: Fri, 21 May 2004 18:11:17 -0700 From: Allwyn Carvalho X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Randall Stewart (cisco)" CC: Sandy Murphy , mdalal@cisco.com, ananth@cisco.com, dl-tcpm@catspoiler.org, tcpm@ietf.org Subject: Re: [tcpm] SYN's in draft-ietf-tcpm-tcpsecure.txt :-) References: <200405211916.i4LJGOQv017320@tislabs.com> <40AE5F87.8070803@cisco.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 FWIW, I think this is okay. Allwyn. "Randall Stewart (cisco)" wrote: > > Sandy/All: > > If there are NO other serious objections.. I will remove > the corner case description and drop it completely.. > > Speak now if you object...otherwise I will massage some of Mitesh's > wording into that section as appropriate for the -01 version :-D > > R > > Sandy Murphy wrote: > > >>Irrespective of the sequence number of the incoming SYN, send an > >>ACK with ack of rcv.nxt. The corner cases of the SYN having data and > >>or being exactly equal to rcv.nxt-1 are both present in the base > >>spec and hence should exist even today.(i.e the timeout) and we are > >>better off leaving it untouched. the aim was to optimize it for the > >>corner case, but looks like it might not be worth it. > >> > >> > > > >I agree with this wholeheartedly! > > > >The choice between (a) rare timeouts (b) rare aborted connections > >and (c) new and unusual splinter case code added to implementations > >came down to (a), IMHO. > > > >--Sandy > > > >_______________________________________________ > >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 May 21 21:59:55 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19455 for ; Fri, 21 May 2004 21:59: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 1BRLlJ-0001LK-Vd for tcpm-archive@odin.ietf.org; Fri, 21 May 2004 21:57:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4M1vL1b005158 for tcpm-archive@odin.ietf.org; Fri, 21 May 2004 21:57:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRLhF-0000P3-Oi for tcpm-web-archive@optimus.ietf.org; Fri, 21 May 2004 21:53: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 VAA19169 for ; Fri, 21 May 2004 21:53: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 1BRLhC-0001Nu-Qt for tcpm-web-archive@ietf.org; Fri, 21 May 2004 21:53:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRLgJ-0001Gs-00 for tcpm-web-archive@ietf.org; Fri, 21 May 2004 21:52:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRLfY-00019V-00 for tcpm-web-archive@ietf.org; Fri, 21 May 2004 21:51:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRLYS-0007Hq-30; Fri, 21 May 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 1BRLVP-000668-0P for tcpm@optimus.ietf.org; Fri, 21 May 2004 21:40: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 VAA18214 for ; Fri, 21 May 2004 21:40: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 1BRLVM-0007cI-1A for tcpm@ietf.org; Fri, 21 May 2004 21:40:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRLUN-0007Vg-00 for tcpm@ietf.org; Fri, 21 May 2004 21:39:52 -0400 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1BRLTc-0007LL-00 for tcpm@ietf.org; Fri, 21 May 2004 21:39:04 -0400 Received: from horh1.emsr.lucent.com (h135-17-1-40.lucent.com [135.17.1.40]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4M1cPj23127; Fri, 21 May 2004 20:38:26 -0500 (CDT) Received: from new-wopr.eng.ascend.com ([135.140.53.19]) by horh1.emsr.lucent.com (8.11.7+Sun/EMS-1.5 Solaris/emsr) id i4M1cOF18966 for ; Fri, 21 May 2004 20:38:24 -0500 (CDT) Received: from grigri.eng.ascend.com (grigri.eng.ascend.com [135.140.53.45]) by new-wopr.eng.ascend.com (8.11.6+Sun/8.10.2) with ESMTP id i4M1cNB07615; Fri, 21 May 2004 18:38:23 -0700 (PDT) Received: from lucent.com (gauri.eng.ascend.com [135.140.26.53]) by grigri.eng.ascend.com (8.8.8+Sun/8.8.8) with ESMTP id SAA05081; Fri, 21 May 2004 18:38:23 -0700 (PDT) Message-ID: <40AEAF0F.6A485020@lucent.com> Date: Fri, 21 May 2004 18:38:23 -0700 From: Allwyn Carvalho X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Randall Stewart (cisco)" , Sandy Murphy , mdalal@cisco.com, ananth@cisco.com, dl-tcpm@catspoiler.org, tcpm@ietf.org Subject: Re: [tcpm] SYN's in draft-ietf-tcpm-tcpsecure.txt :-) References: <200405211916.i4LJGOQv017320@tislabs.com> <40AE5F87.8070803@cisco.com> <40AEA8B5.5E79F175@lucent.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 Thinking about this some more for the corner case. How about: if we are in SYN-SENT state and we receive a valid ACK without a SYN, then send RST? If both sides of the connection implement this fix, won't this solve the corner case problem? Allwyn. Allwyn Carvalho wrote: > > FWIW, I think this is okay. > Allwyn. > > "Randall Stewart (cisco)" wrote: > > > > Sandy/All: > > > > If there are NO other serious objections.. I will remove > > the corner case description and drop it completely.. > > > > Speak now if you object...otherwise I will massage some of Mitesh's > > wording into that section as appropriate for the -01 version :-D > > > > R > > > > Sandy Murphy wrote: > > > > >>Irrespective of the sequence number of the incoming SYN, send an > > >>ACK with ack of rcv.nxt. The corner cases of the SYN having data and > > >>or being exactly equal to rcv.nxt-1 are both present in the base > > >>spec and hence should exist even today.(i.e the timeout) and we are > > >>better off leaving it untouched. the aim was to optimize it for the > > >>corner case, but looks like it might not be worth it. > > >> > > >> > > > > > >I agree with this wholeheartedly! > > > > > >The choice between (a) rare timeouts (b) rare aborted connections > > >and (c) new and unusual splinter case code added to implementations > > >came down to (a), IMHO. > > > > > >--Sandy > > > > > >_______________________________________________ > > >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 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Sat May 22 07:39: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 HAA00772 for ; Sat, 22 May 2004 07:39: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 1BRUkB-0000NX-Ov for tcpm-archive@odin.ietf.org; Sat, 22 May 2004 07:32:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4MBWl0e001455 for tcpm-archive@odin.ietf.org; Sat, 22 May 2004 07:32:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRUc0-0007G2-UR for tcpm-web-archive@optimus.ietf.org; Sat, 22 May 2004 07:24: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 HAA29905 for ; Sat, 22 May 2004 07:24: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 1BRUc0-0007ez-8z for tcpm-web-archive@ietf.org; Sat, 22 May 2004 07:24:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRUb3-0007Vu-00 for tcpm-web-archive@ietf.org; Sat, 22 May 2004 07:23:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRUaX-0007Mm-00 for tcpm-web-archive@ietf.org; Sat, 22 May 2004 07:22:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRUR1-0004uX-LR; Sat, 22 May 2004 07:12:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRUEs-0002Bs-Su for tcpm@optimus.ietf.org; Sat, 22 May 2004 07:00: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 HAA28239 for ; Sat, 22 May 2004 07:00: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 1BRUEo-0003EM-II for tcpm@ietf.org; Sat, 22 May 2004 07:00:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRUDq-00031Q-00 for tcpm@ietf.org; Sat, 22 May 2004 06:59:22 -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 1BRUCt-0002i8-00 for tcpm@ietf.org; Sat, 22 May 2004 06:58:23 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 22 May 2004 03:04: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 i4MAvq8R011811; Sat, 22 May 2004 03:57:52 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id AUK85878; Sat, 22 May 2004 03:57:50 -0700 (PDT) Message-ID: <40AF322D.7040906@cisco.com> Date: Sat, 22 May 2004 06:57: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: Allwyn Carvalho CC: Sandy Murphy , mdalal@cisco.com, ananth@cisco.com, dl-tcpm@catspoiler.org, tcpm@ietf.org Subject: Re: [tcpm] SYN's in draft-ietf-tcpm-tcpsecure.txt :-) References: <200405211916.i4LJGOQv017320@tislabs.com> <40AE5F87.8070803@cisco.com> <40AEA8B5.5E79F175@lucent.com> <40AEAF0F.6A485020@lucent.com> In-Reply-To: <40AEAF0F.6A485020@lucent.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 Allwyn Carvalho wrote: >Thinking about this some more for the corner case. How about: if we are in SYN-SENT state and we receive a valid ACK without a SYN, then send RST? If both sides of the connection implement this fix, won't this solve the corner case problem? > >Allwyn. > > > Allwyn: hmm.. lets see SYN-SENT ------------SYN-------> hits corner case <-------------ACK() ---------------------RST-----------------> Now if the RST is exactly the seq number in the ACK and we send a normal ACK.. Yep.. that would work.. 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 Sat May 22 07:40: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 HAA00804 for ; Sat, 22 May 2004 07:40: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 1BRUkC-0000OM-S6 for tcpm-archive@odin.ietf.org; Sat, 22 May 2004 07:32:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4MBWmPA001501 for tcpm-archive@odin.ietf.org; Sat, 22 May 2004 07:32:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRUdv-0007at-9T for tcpm-web-archive@optimus.ietf.org; Sat, 22 May 2004 07:26: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 HAA29987 for ; Sat, 22 May 2004 07:26: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 1BRUdu-0000CN-IA for tcpm-web-archive@ietf.org; Sat, 22 May 2004 07:26:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRUd4-000026-00 for tcpm-web-archive@ietf.org; Sat, 22 May 2004 07:25:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRUcL-0007g9-00 for tcpm-web-archive@ietf.org; Sat, 22 May 2004 07:24:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRURA-0004x7-OY; Sat, 22 May 2004 07:13:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRUHI-0002fI-FA for tcpm@optimus.ietf.org; Sat, 22 May 2004 07:02: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 HAA28573 for ; Sat, 22 May 2004 07:02: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 1BRUHE-0003mG-70 for tcpm@ietf.org; Sat, 22 May 2004 07:02:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRUGQ-0003YD-00 for tcpm@ietf.org; Sat, 22 May 2004 07:02:03 -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 1BRUFQ-0003FO-00 for tcpm@ietf.org; Sat, 22 May 2004 07:01:00 -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 i4MB0T8R013242; Sat, 22 May 2004 04:00:29 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id AUK85935; Sat, 22 May 2004 04:00:27 -0700 (PDT) Message-ID: <40AF32CA.7020504@cisco.com> Date: Sat, 22 May 2004 07:00:26 -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: Allwyn Carvalho CC: Sandy Murphy , tcpm@ietf.org Subject: Re: [tcpm] blind data injection References: <200405191503.i4JF3kXZ029657@tislabs.com> <40AC09A1.6090605@cisco.com> <40AEA7A5.A7748B26@lucent.com> In-Reply-To: <40AEA7A5.A7748B26@lucent.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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Allwyn: So what you are proposing would be a filter based on segment boundrary alignment... That MAY work.. but one would have to do tricks with it since you never know if the sender had an interveneing PMTU message... so once something is IN the reassembly buffer.. if a new segment arrives that overlapps.. you would be discarding whats in the reasm buffer... This would of course require a bit more code but it could be done... Its a way (if you will) of ejecting things that slipped by your first test (the ack).. R Allwyn Carvalho wrote: >How about treating out-of-order packets that don't "line up" as suspect. In the case below, Z buffers out-of-order bytes 2200-3200 presuming that they are genuine out-of-order bytes. > >If it gets data 200-2199 from A, then it treats 2200-3200 as valid and forwards it to the application. If however it gets 200-2210 (as below), then it treats the buffered data 2200-3200 as suspect and drops it. > >Along with this is the implicit recommendation (should perhaps be made explicit) that new data overrides old data. So, bytes 2200-2210 should be taken from the new segment, not from the buffered segment. > >Chances are more likely than not that blind data injected bytes will not "line up", whereas genuine out-of-order bytes always will. > >Allwyn. > >"Randall Stewart (cisco)" wrote: > > >>Sandy: >> >>One thing we have found in our testing is that when >>data is injected and sits in a reassmebly buffer .. once the >>peer catches up and bridges the "injected" portion an >>ack war begins... >> >>For example >> >>A Z (rcv.nxt =200) >> >> Evil-guy-----Inject(2200 - 3200)------------> >> >>Now when A sends >> >> >>--------------------Data(200-2210)----------------------------------> >> >>Z sends (XX:) >><---------------------------------ACK(3200) >>A says.. hey my peer is messed up and sends >>------------------------ACK(x,2210)-------------------------_> >>Z says .. hey my peer is messed up and sends goto XX; >> >>This continues until the connection falls apart. Sometimes if A >>is sending lots of data it then gets past 3200 in my example and >>the injected data bubbles up.. but as you point out most apps >>will then get out of sync.. and depending on the app it may >>abort the connection... since it is usually reading a framed message >>size and the framing is now hosed and it does not know how to >>recover... of course mileage may vary .. >> >>R >> >>Sandy Murphy wrote: >> >> >> >>>The tcpsecure draft notes that data can be accepted by the TCP >>>implementation if any of the segment's bytes fall within the receive >>>window, not just at the left edge of the window. But TCP does not >>>require that out-of-order segments are buffered. I don't know how >>>ubiquitous it is for implementations to do the buffering. (RFC1122 >>>makes it a "should".) I can find no place where the TCP spec speaks >>>of what to do if a later arriving segment overlaps a previously queued >>>out-of-order segment. I can see the possibility that the later >>>arriving data could overwrite the previously queued data. Unix tcp >>>code I've looked at seems to let recently arrived segments overwrite >>>succeeding queued out-of-order segments (but queued preceding segments >>>overwrite the recently arrived segments). >>> >>>That would mean that the eventual delivery of bogus injected data to >>>the application would depend on the spacing of the arrival of any real >>>segments covering the same sequence number space as the bogus injected >>>data. A blind attacker could not predict what if any of the bogus >>>injected data would be delivered to the application. >>> >>>Furthermore, any application level framing could cause any bogus >>>injected data that did manage to be delivered to fail the parse step >>>in the application. So BGP, in particular, which has such framing, >>>would be in much less danger of accepting the bogus data. It would be >>>much more likely that any injected data that did manage to reach BGP >>>would not pass the parsing and would cause the connection to abort. >>>That's not a good result, but it's better than accepting bogus >>>injected data. >>> >>>--Sandy >>> >>>_______________________________________________ >>>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 >> >> > > > -- 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 Sun May 23 01:50:30 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 BAA16702 for ; Sun, 23 May 2004 01:50: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 1BRlpY-0005dd-F3 for tcpm-archive@odin.ietf.org; Sun, 23 May 2004 01:47:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4N5lS5I021658 for tcpm-archive@odin.ietf.org; Sun, 23 May 2004 01:47:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRlkQ-0004MT-7p for tcpm-web-archive@optimus.ietf.org; Sun, 23 May 2004 01:42: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 BAA16487 for ; Sun, 23 May 2004 01:42: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 1BRlkN-0001e5-0Y for tcpm-web-archive@ietf.org; Sun, 23 May 2004 01:42:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRljO-0001QE-00 for tcpm-web-archive@ietf.org; Sun, 23 May 2004 01:41:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRliw-0001CW-00 for tcpm-web-archive@ietf.org; Sun, 23 May 2004 01:40:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRlYe-00024P-Vt; Sun, 23 May 2004 01:30:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRlWj-0001h2-QH for tcpm@optimus.ietf.org; Sun, 23 May 2004 01:28: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 BAA16157 for ; Sun, 23 May 2004 01:28: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 1BRlWg-0006G1-Od for tcpm@ietf.org; Sun, 23 May 2004 01:27:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRlVo-00062i-00 for tcpm@ietf.org; Sun, 23 May 2004 01:27:05 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BRlVE-0005on-00 for tcpm@ietf.org; Sun, 23 May 2004 01:26:28 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 22 May 2004 22:23:28 -0700 Received: from ananth-u5.cisco.com (ananth-u5.cisco.com [128.107.162.225]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i4N5PufT002431; Sat, 22 May 2004 22:25:56 -0700 (PDT) Date: Sat, 22 May 2004 22:25:56 -0700 (PDT) From: Anantha Ramaiah To: "Randall Stewart (cisco)" cc: Allwyn Carvalho , Sandy Murphy , mdalal@cisco.com, dl-tcpm@catspoiler.org, tcpm@ietf.org Subject: Re: [tcpm] SYN's in draft-ietf-tcpm-tcpsecure.txt :-) In-Reply-To: <40AF322D.7040906@cisco.com> Message-ID: References: <200405211916.i4LJGOQv017320@tislabs.com> <40AE5F87.8070803@cisco.com> <40AEA8B5.5E79F175@lucent.com> <40AEAF0F.6A485020@lucent.com> <40AF322D.7040906@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.1 required=5.0 tests=AWL autolearn=no version=2.60 On Sat, 22 May 2004, Randall Stewart (cisco) wrote: > Allwyn Carvalho wrote: > > >Thinking about this some more for the corner case. How about: if we are in SYN-SENT state and we receive a valid ACK without a SYN, then send RST? If both sides of the connection implement this fix, won't this solve the corner case problem? > > > >Allwyn. > > > > > > > Allwyn: > > hmm.. lets see > > SYN-SENT ------------SYN-------> > > hits corner case > <-------------ACK() > ---------------------RST-----------------> > > Now if the RST is exactly the seq number in the > ACK and we send a normal ACK.. Yep.. that would work.. I thought about this before and this would mean change in the SYNSENT processing in the RFC but wasn't really sure if we would break some implementations and may be missing some corner cases... First of all the side which is in SYNSENT state cannot really know if the other side has hit the "corner case"?? TCP is always (mostly) a 3 way handhake like: SYN -------> SYN-ACK <----------- ACK ---------------> Except in case of simultaneous open both sides sending a SYN which is slightly different since both the sides has to transition from SYNSENT to SYNRCVD to ESTAB. But there is no such thing like a "4 way HS" SYN --------> [move to SYNSENT state ] <------------ACK ( Valid ACK would get dropped anyway and no state change) <-------------SYN --------------> ACK Because as per simultaneous open you have to transition to SYNRCVD state which means you should be sending SYN+ACK and not just the ACK. So I am wondering why we should we even honor a acceptable ACK in SYNSENT state, just reply with RST? In other words why would a RFC compliant host ever reply ACK an SYN seperately on receiving an incoming SYN? It is really useless because the other end will timeout waiting for a SYN+ACK and just a plain ACK? [ just in case you want to take time to send a SYN+ACK back] May be I am missing some cases? -Anantha > > 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 > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon May 24 02:23:46 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14247 for ; Mon, 24 May 2004 02:23: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 1BS8qb-0000va-K4 for tcpm-archive@odin.ietf.org; Mon, 24 May 2004 02:22:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4O6M5QJ003552 for tcpm-archive@odin.ietf.org; Mon, 24 May 2004 02:22:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS8lo-0008M6-Co for tcpm-web-archive@optimus.ietf.org; Mon, 24 May 2004 02:17: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 CAA13564 for ; Mon, 24 May 2004 02:17: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 1BS8lk-0006jj-JA for tcpm-web-archive@ietf.org; Mon, 24 May 2004 02:17:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS8kx-0006SB-00 for tcpm-web-archive@ietf.org; Mon, 24 May 2004 02:16:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BS8jP-000695-00 for tcpm-web-archive@ietf.org; Mon, 24 May 2004 02:14:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS8gv-0007IC-RX; Mon, 24 May 2004 02:12:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS8ZH-0005L3-0V for tcpm@optimus.ietf.org; Mon, 24 May 2004 02:04: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 CAA04123 for ; Mon, 24 May 2004 02:04: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 1BS8ZD-0003DD-Fz for tcpm@ietf.org; Mon, 24 May 2004 02:04:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS8YG-0002ul-00 for tcpm@ietf.org; Mon, 24 May 2004 02:03:09 -0400 Received: from baton.cs.ucdavis.edu ([169.237.6.6]) by ietf-mx with esmtp (Exim 4.12) id 1BS8XI-0002as-00 for tcpm@ietf.org; Mon, 24 May 2004 02:02:08 -0400 Received: from baton.cs.ucdavis.edu (localhost [127.0.0.1]) by baton.cs.ucdavis.edu (8.12.10/8.12.10) with ESMTP id i4O6232X024221 for ; Sun, 23 May 2004 23:02:03 -0700 (PDT) Received: from pc77.cs.ucdavis.edu (pc77.cs.ucdavis.edu [169.237.5.160]) by baton.cs.ucdavis.edu (8.12.10/8.12.10) with ESMTP id i4O623sx024217 for ; Sun, 23 May 2004 23:02:03 -0700 (PDT) Date: Sun, 23 May 2004 23:02:03 -0700 (PDT) From: Lynn Nguyen To: tcpm@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [tcpm] question regarding draft-ietf-tcpm-tcpsecure.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 Hi, everyone! I have been studying this draft and read some other articles as references. In one of the article I read, it stated OpenBSD creator Theo de Raadt pointed out the solutions proposed in the draft can cause a connection to be flooded potentially. I am just wondering whether you have taken his suggestion into consideration and whether you will propose any other solutions that will help solve the problem he pointed out. I am new to this newsgroup, so if I missed any discussion related to this topic, can someone please point out the references to me? Thanks in advance. Lynn _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon May 24 09:23: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 JAA04732 for ; Mon, 24 May 2004 09:23: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 1BSFFo-00062f-AE for tcpm-archive@odin.ietf.org; Mon, 24 May 2004 09:12:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ODCWC6023225 for tcpm-archive@odin.ietf.org; Mon, 24 May 2004 09:12:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSF69-00049V-1F for tcpm-web-archive@optimus.ietf.org; Mon, 24 May 2004 09: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 JAA03351 for ; Mon, 24 May 2004 09: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 1BSF67-0006Md-GS for tcpm-web-archive@ietf.org; Mon, 24 May 2004 09:02:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSF5H-00064J-00 for tcpm-web-archive@ietf.org; Mon, 24 May 2004 09:01:40 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BSF4o-0005lA-00 for tcpm-web-archive@ietf.org; Mon, 24 May 2004 09:01:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSEr6-0002ZB-GN; Mon, 24 May 2004 08:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSEmi-0001f9-Ig for tcpm@optimus.ietf.org; Mon, 24 May 2004 08:42: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 IAA02198 for ; Mon, 24 May 2004 08:42: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 1BSEmh-00003L-39 for tcpm@ietf.org; Mon, 24 May 2004 08:42:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSElc-0007Xp-00 for tcpm@ietf.org; Mon, 24 May 2004 08:41:21 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx with esmtp (Exim 4.12) id 1BSEkd-0007Dt-00 for tcpm@ietf.org; Mon, 24 May 2004 08:40:19 -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 i4OCeHim048413; Mon, 24 May 2004 05:40:18 -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 2D68277ACFC; Mon, 24 May 2004 08:40:17 -0400 (EDT) To: Allwyn Carvalho From: Mark Allman Reply-To: mallman@icir.org Cc: "Randall Stewart (cisco)" , Sandy Murphy , tcpm@ietf.org Subject: Re: [tcpm] blind data injection In-Reply-To: <40AEA7A5.A7748B26@lucent.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Lodi MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 24 May 2004 08:40:17 -0400 Message-Id: <20040524124017.2D68277ACFC@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 > How about treating out-of-order packets that don't "line up" as > suspect. In the case below, Z buffers out-of-order bytes 2200-3200 > presuming that they are genuine out-of-order bytes. > > If it gets data 200-2199 from A, then it treats 2200-3200 as valid and > forwards it to the application. If however it gets 200-2210 (as > below), then it treats the buffered data 2200-3200 as suspect and > drops it. This doesn't seem like a terribly good idea to me. Take an example the case where there is a short segment followed by an MSS-sized segment. So, say a 300 byte segment followed by a 1460 byte segment. If the first segment is dropped and retransmitted the sender is very likely to send MSS bytes -- i.e., covering the first segment and a bunch of the second segment. That fails your test and so the second segment would be chucked. But, I think this opens up a new security problem, too. If an attacker can just repeatedly send the same segment over and over then when the connection "catches up" to that point in the sequence space the attacker may be able to completely halt the connection right there (by causing all data to be discarded over-and-over). Right? (Or, am I missing something?) allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAse0xWyrrWs4yIs4RAlBFAJ93plKZyfxGDePQg18uDNKKaM9DGwCfbUDS GKwyJwwMxkrPJWGjcn7/luQ= =KhQb -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From exim@www1.ietf.org Mon May 24 09:42: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 JAA05691 for ; Mon, 24 May 2004 09:42: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 1BSFeF-0001AS-JQ for tcpm-archive@odin.ietf.org; Mon, 24 May 2004 09:37:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ODblMa004488 for tcpm-archive@odin.ietf.org; Mon, 24 May 2004 09:37:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSFUA-0008GK-RW for tcpm-web-archive@optimus.ietf.org; Mon, 24 May 2004 09:27: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 JAA04960 for ; Mon, 24 May 2004 09:27: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 1BSFU8-0004CV-UF for tcpm-web-archive@ietf.org; Mon, 24 May 2004 09:27:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSFTG-0004AL-00 for tcpm-web-archive@ietf.org; Mon, 24 May 2004 09:26:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BSFSg-00048o-00 for tcpm-web-archive@ietf.org; Mon, 24 May 2004 09:25:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSFO1-0007TO-6S; Mon, 24 May 2004 09: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 1BSFCB-0005Oh-5t for tcpm@optimus.ietf.org; Mon, 24 May 2004 09:08: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 JAA03660 for ; Mon, 24 May 2004 09:08: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 1BSFC9-0000O0-EH for tcpm@ietf.org; Mon, 24 May 2004 09:08:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSFB6-000053-00 for tcpm@ietf.org; Mon, 24 May 2004 09:07:41 -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 1BSFA5-0007ZL-00 for tcpm@ietf.org; Mon, 24 May 2004 09:06:38 -0400 Received: from [10.1.1.31] (scout.netlab.nec.de [195.37.70.100]) by ftp.ccrle.nec.de (Postfix) with ESMTP id 3F633F674; Mon, 24 May 2004 15:11:45 +0200 (CEST) Message-ID: <40B1F129.7090407@netlab.nec.de> Date: Mon, 24 May 2004 14:57:13 +0200 From: Lars Eggert User-Agent: Mozilla Thunderbird 0.6 (X11/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mallman@icir.org Cc: Fernando Gont , tcpm@ietf.org, Ted Faber Subject: Re: [tcpm] ATO i-d References: <20040520174029.01B6E77A6D5@guns.icir.org> In-Reply-To: <20040520174029.01B6E77A6D5@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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mark Allman wrote: > > I think what we have consensus on - which is what Ted and I asked - is > to undertake work to allow TCP endpoints to negotiate a connection > timeout. If we have mis-read consensus on this point, please yell. > > At this point, we have two i-ds in this space. The first is the above > mentioned document from Lars and has been discussed in some detail on > the list. The second was recently announced and is: > > draft-gont-tcpm-tcp-auto-option-00.txt > > We can take up either of these, both of these or work the ideas together > into a single document. Opinions on which path makes the most sense > would be very welcome. I have started to revise the ATO ID based on feedback from the WG and will submit -01 in a few days. The main changes are using fewer bytes for the ATO option, replacing the 3-way ATO negotiation with a 2-way handshake during the SYN/SYN+ACK, and various smaller fixes. These changes address feedback I've received from the WG (including Fernando) and the chairs, both on and off list. I've briefly read over draft-gont, but am unsure what it adds that the modified ATO draft does not already offer. A section in the new draft-gont comparing it to the existing ATO draft would have been helpful. After submission of -01 of the ATO draft, we should figure out whether there is any need to work on two different approaches. I'd personally much prefer a single document, especially since it is currently unclear whether the two approaches really differ much. Lars -- Lars Eggert NEC Network Laboratories _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm