From tcpm-bounces@ietf.org Thu Mar 01 06:18:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMjHo-0000fa-62; Thu, 01 Mar 2007 06:17:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMjHm-0000f1-Vi; Thu, 01 Mar 2007 06:17:22 -0500 Received: from wall.ikr.uni-stuttgart.de ([129.69.170.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMjHk-0008BF-GM; Thu, 01 Mar 2007 06:17:22 -0500 Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by wall.ikr.uni-stuttgart.de (Postfix) with ESMTP id 7FCB556CC6; Thu, 1 Mar 2007 12:17:13 +0100 (CET) Received: by netsrv1.ikr.uni-stuttgart.de (Postfix, from userid 539) id 71B61BC080; Thu, 1 Mar 2007 12:17:13 +0100 (CET) Received: from ikr.uni-stuttgart.de (inode21 [10.21.18.11]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with SMTP id 14B60BC07E; Thu, 1 Mar 2007 12:17:13 +0100 (CET) Received: by ikr.uni-stuttgart.de (sSMTP sendmail emulation); Thu, 1 Mar 2007 12:17:13 +0100 Date: Thu, 1 Mar 2007 12:17:13 +0100 From: Michael Scharf To: tsvwg@ietf.org, tcpm@ietf.org Message-ID: <20070301111713.GA9619@ikr.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.4.2.2i X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Subject: [tcpm] New I-D posted: draft-scharf-tsvwg-quick-start-flow-control-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Hi, I have written a new I-D on some issues that have been noticed during implementation efforts of the experimental Quick-Start extension (RFC 4782). I'd be very interested in feedback. I am cross-posting both to tsvwg and tcpm, since it might be of interest to both communities. Michael ----- Forwarded message from Internet-Drafts@ietf.org ----- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Avoiding Interactions of Quick-Start TCP and Flow Control Author(s) : M. Scharf, et al. Filename : draft-scharf-tsvwg-quick-start-flow-control-00.txt Pages : 12 Date : 2007-2-27 This document describes methods to avoid interactions between the flow control of the Transmission Control Protocol (TCP) and the Quick-Start TCP extension. Quick-Start is an optional TCP congestion control mechanism that allows hosts to determine an allowed sending rate from feedback of routers along the path. With Quick-Start, data transfers can start with a potentially large congestion window. In order to fully utilize the data rate determined by Quick-Start, the sending host must not be limited by the TCP flow control, i. e., the amount of free buffer space advertised by the receive window. There are two potential interactions between Quick-Start and the TCP flow control: First, receivers might not provide sufficiently large buffer space after connection setup, or they may implement buffer allocation strategies that implicitly assume the slow-start behavior on the sender side. This document therefore provides guidelines for buffer allocation in hosts supporting the Quick-Start extension. Second, the TCP receive window scaling mechanism interferes with Quick-Start when being used in the initial three-way handshake connection setup. This document describes a simple solution to overcome this problem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-scharf-tsvwg-quick-start-flow-control-00.txt ----- End forwarded message ----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Mar 02 13:11:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNCDA-0002lj-DO; Fri, 02 Mar 2007 13:10:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNCD9-0002kg-Ub for tcpm@ietf.org; Fri, 02 Mar 2007 13:10:31 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNCD7-0005Cp-K6 for tcpm@ietf.org; Fri, 02 Mar 2007 13:10:31 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l22IASD3027487; Fri, 2 Mar 2007 10:10:29 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 606D585BE2B; Fri, 2 Mar 2007 13:10:23 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 22CE218BAF0; Fri, 2 Mar 2007 13:09:45 -0500 (EST) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Dance the Night Away MIME-Version: 1.0 Date: Fri, 02 Mar 2007 13:09:45 -0500 Message-Id: <20070302180945.22CE218BAF0@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Ted Faber Subject: [tcpm] call for agenda items X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1626125621==" Errors-To: tcpm-bounces@ietf.org --===============1626125621== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Folks- Ted and I need to start filling out the TCPM dance card for Prague. If you have some new moves you want to show off please drop us a note. Thanks, allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFF6GhoWyrrWs4yIs4RAmYzAJ9f590tROoyMknk6z/fqLls+vfi8gCgnlFG KWjQfn6FOPDhiYUpFvw9ac4= =D76G -----END PGP SIGNATURE----- --=_bOundary-- --===============1626125621== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1626125621==-- From tcpm-bounces@ietf.org Fri Mar 02 18:02:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNGlL-0003Ps-My; Fri, 02 Mar 2007 18:02:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNFKh-0008Nz-2G for tcpm@ietf.org; Fri, 02 Mar 2007 16:30:31 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNFAf-0005Og-CP for tcpm@ietf.org; Fri, 02 Mar 2007 16:20:26 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l22LK437029945; Fri, 2 Mar 2007 13:20:04 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 1B5FC85D89D; Fri, 2 Mar 2007 16:19:59 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id BCA8018C1C5; Fri, 2 Mar 2007 16:19:20 -0500 (EST) To: tcpm@ietf.org From: Mark Allman Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-tcp-antispoof-05.txt (Ends 2 Feb 2007) In-Reply-To: <45DFE808.9080502@isi.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Dance the Night Away MIME-Version: 1.0 Date: Fri, 02 Mar 2007 16:19:20 -0500 Message-Id: <20070302211920.BCA8018C1C5@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Ted Faber , Joe Touch X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1135053696==" Errors-To: tcpm-bounces@ietf.org --===============1135053696== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Folks- The chairs believe that the antispoof document has passed WGLC and our intention is to get the PROTO writeup done and pass it along to the IESG for publication. Anyone who thinks we are mis-reading consensus can of course let us know. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFF6JTYWyrrWs4yIs4RAghcAJ9/6D9vbjsqAJNw/Oz0d2Jtzzz7HwCfY+c0 BVa6zh/4Gp49Z3eJtEShSgI= =Qyru -----END PGP SIGNATURE----- --=_bOundary-- --===============1135053696== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1135053696==-- From tcpm-bounces@ietf.org Fri Mar 02 21:01:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNJYC-0004ce-Oh; Fri, 02 Mar 2007 21:00:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNJXE-0007ZY-A3 for tcpm@ietf.org; Fri, 02 Mar 2007 20:59:44 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNJJP-0004ac-U2 for tcpm@ietf.org; Fri, 02 Mar 2007 20:45:29 -0500 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l231jLso023809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 2 Mar 2007 17:45:21 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.8/8.13.8/Submit) id l231jLiY008618 for tcpm@ietf.org; Fri, 2 Mar 2007 17:45:21 -0800 (PST) (envelope-from faber) Date: Fri, 2 Mar 2007 17:45:21 -0800 From: Ted Faber To: tcpm@ietf.org Message-ID: <20070303014521.GB8428@hut.isi.edu> Mime-Version: 1.0 User-Agent: Mutt/1.4.2.2i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [tcpm] TCPM Design Team: TCP MD5 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0207813988==" Errors-To: tcpm-bounces@ietf.org --===============0207813988== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XF85m9dhOBO43t/C" Content-Disposition: inline --XF85m9dhOBO43t/C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable As we discussed at the IETF in San Diego in November, TCPM has commissioned= a design team to address the TCP issues in extending the MD5 transport encryp= tion described in RFC 2385. That team is headed by Steve Bellovin and includes authors of both competing drafts as well as others from the security and transport communities. It has recently begun work that will result in a draft to be considered in TCPM. We expect this work to be done before the Chicago IETF. --=20 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 --XF85m9dhOBO43t/C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.2 (FreeBSD) iD8DBQFF6NMxaUz3f+Zf+XsRAiIIAJ95QEITWBO8JAeJRnIJ6yE0L0ug2ACgqT9O qcZ6DTHrcmi2IMFil0w+0M4= =OUv6 -----END PGP SIGNATURE----- --XF85m9dhOBO43t/C-- --===============0207813988== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0207813988==-- From tcpm-bounces@ietf.org Fri Mar 02 21:25:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNJwV-00050P-Ng; Fri, 02 Mar 2007 21:25:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNJwU-0004zr-Py for tcpm@ietf.org; Fri, 02 Mar 2007 21:25:50 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNJwT-0008Jm-Ep for tcpm@ietf.org; Fri, 02 Mar 2007 21:25:50 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 02 Mar 2007 18:25:49 -0800 X-IronPort-AV: i="4.14,244,1170662400"; d="scan'208"; a="44766674:sNHT45218934" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l232Pmwn013237; Fri, 2 Mar 2007 18:25:48 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l232OvEC024823; Fri, 2 Mar 2007 18:25:48 -0800 (PST) Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Mar 2007 18:25:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] TCPM Design Team: TCP MD5 Date: Fri, 2 Mar 2007 18:25:31 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC5802F2FEEE@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <20070303014521.GB8428@hut.isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] TCPM Design Team: TCP MD5 Thread-Index: AcddOB6IoGqVuNc4T8eb7NQKm5+m0AAAd1Rw From: "Anantha Ramaiah \(ananth\)" To: "Ted Faber" , X-OriginalArrivalTime: 03 Mar 2007 02:25:32.0569 (UTC) FILETIME=[37E70890:01C75D3B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1427; t=1172888748; x=1173752748; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20\(ananth\)=22=20 |Subject:=20RE=3A=20[tcpm]=20TCPM=20Design=20Team=3A=20TCP=20MD5 |Sender:=20; bh=eVmaFP9Mqamhv2sj2ARC+VqlPBJAxi4lgJ+kOMFD0yo=; b=HCGk3z2F135QW4ybXVbnsmvmID5UcqY4qmheCi9K4R8xkYE9fZrfCzjqJjd/WbCUXcZBPlOu KnHt2MWChnN2wDEABZJ/+8ZQ5Fcfy2UktoH8ISskuVUaas9gih0HY39n; Authentication-Results: sj-dkim-2; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: "Steven M. Bellovin" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Ted, Like I mentioned to you last time I am one of the "stakeholders" in this effort. I have been a active contributor in this area and I am in the co-author/contributor position in some of the drafts (some drafts have expired). I have also spoken to Steve and we exchanged some notes, although I haven't actively followed after that.=20 Is there an mailing alias formed for this effort, I would like to be part of that and contribute my experiences in this area. Thanks, Anantha > -----Original Message----- > From: Ted Faber [mailto:faber@ISI.EDU]=20 > Sent: Friday, March 02, 2007 5:45 PM > To: tcpm@ietf.org > Subject: [tcpm] TCPM Design Team: TCP MD5 >=20 >=20 > As we discussed at the IETF in San Diego in November, TCPM=20 > has commissioned a design team to address the TCP issues in=20 > extending the MD5 transport encryption described in RFC 2385. >=20 > That team is headed by Steve Bellovin and includes authors of=20 > both competing drafts as well as others from the security and=20 > transport communities. >=20 > It has recently begun work that will result in a draft to be=20 > considered in TCPM. We expect this work to be done before=20 > the Chicago IETF. >=20 >=20 > -- > Ted Faber > http://www.isi.edu/~faber PGP:=20 > http://www.isi.edu/~faber/pubkeys.asc > Unexpected attachment on this mail? See=20 > http://www.isi.edu/~faber/FAQ.html#SIG >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Mar 05 09:44:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOEPV-0008EH-U5; Mon, 05 Mar 2007 09:43:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOEPU-0008CV-8M for tcpm@ietf.org; Mon, 05 Mar 2007 09:43:32 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HOEPQ-0007J4-VC for tcpm@ietf.org; Mon, 05 Mar 2007 09:43:32 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l25EhKEB029642; Mon, 5 Mar 2007 06:43:20 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id CF444877388; Mon, 5 Mar 2007 09:43:14 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 6AD3C18F4D1; Mon, 5 Mar 2007 09:43:13 -0500 (EST) To: tcpm@ietf.org From: Mark Allman Subject: Re: [tcpm] TCPM Design Team: TCP MD5 In-Reply-To: <0C53DCFB700D144284A584F54711EC5802F2FEEE@xmb-sjc-21c.amer.cisco.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Dance the Night Away MIME-Version: 1.0 Date: Mon, 05 Mar 2007 09:43:13 -0500 Message-Id: <20070305144313.6AD3C18F4D1@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: "Steven M. Bellovin" , "Anantha Ramaiah \(ananth\)" , Ted Faber X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1583473098==" Errors-To: tcpm-bounces@ietf.org --===============1583473098== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Anantha and I iterated off-list. But, just so there is no confusion.... > Is there an mailing alias formed for this effort, The team has a mailing list. The mailing list is not public and we are not accepting new members for the team. There are many many people who would have been very good choices for this team, but we tried to keep the team small such that work could proceed easily. To be very clear, we believe the community's consensus is that TCPM should take on this tcp-auth task. There are two different competing drafts in this space. Despite everyone's best efforts we could not find a path to merge these easily. So, as discussed at the last IETF meeting, we have formed this design team to develop a -00 draft for the WG to consider. After that, the process will run in an open fashion on the main WG mailing list, as all other WG business is conducted. The design team is developing a **starting point** not the **final version** of the spec. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFF7CyBWyrrWs4yIs4RAiQPAJ40NwugxuEGol9jKtFFcQlLcIR4nACeKfVg XpJt/j9gkEM2OAovCU7kzVc= =6THl -----END PGP SIGNATURE----- --=_bOundary-- --===============1583473098== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1583473098==-- From tcpm-bounces@ietf.org Wed Mar 07 19:11:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP6Dm-0005it-2q; Wed, 07 Mar 2007 19:11:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP533-0006Po-4G for tcpm@ietf.org; Wed, 07 Mar 2007 17:55:53 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP43P-0001wd-Pt for tcpm@ietf.org; Wed, 07 Mar 2007 16:52:14 -0500 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l27LpTGc005024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 7 Mar 2007 13:51:29 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.8/8.13.8/Submit) id l27LpTFv045149 for tcpm@ietf.org; Wed, 7 Mar 2007 13:51:29 -0800 (PST) (envelope-from faber) Date: Wed, 7 Mar 2007 13:51:29 -0800 From: Ted Faber To: tcpm@ietf.org Message-ID: <20070307215129.GU17635@hut.isi.edu> Mime-Version: 1.0 User-Agent: Mutt/1.4.2.2i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Subject: [tcpm] agenda X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1239474742==" Errors-To: tcpm-bounces@ietf.org --===============1239474742== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uFO8jlCBh1yRPqfb" Content-Disposition: inline --uFO8jlCBh1yRPqfb Content-Type: multipart/mixed; boundary="Chn8nxio6L/4biUD" Content-Disposition: inline --Chn8nxio6L/4biUD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable A preliminary TCPM agenda is available from: http://www3.ietf.org/proceedings/07mar/agenda/tcpm.txt A text copy is attached to this message. We expect a few more additions before the end of the week, but that it will be fairly stable from there out. Thanks --=20 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 --Chn8nxio6L/4biUD Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="agenda.txt" Content-Transfer-Encoding: quoted-printable TCPM agenda WG Business =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D WG Status - 10-15 minutes Dave Borman =09 User Timeout (10 minutes) Lars Eggert http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-uto-05.txt draft-ietf-tcpm-tcp-uto-05.txt TCP-secure (10 minutes) ?? Non-WG =3D=3D=3D=3D=3D=3D Identifying Cheating Receivers (15-20 minutes) Toby Moncaster http://www.ietf.org/internet-drafts/draft-moncaster-tcpm-rcv-cheat-00.txt draft-moncaster-tcpm-rcv-cheat-00.txt --Chn8nxio6L/4biUD-- --uFO8jlCBh1yRPqfb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.2 (FreeBSD) iD8DBQFF7zPhaUz3f+Zf+XsRAgeTAKDapCO5AmKkS6DX4wI4jL2myOpvPACfRyvJ j4JgV1+WzcIQK5O262GWrN4= =WX51 -----END PGP SIGNATURE----- --uFO8jlCBh1yRPqfb-- --===============1239474742== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1239474742==-- From tcpm-bounces@ietf.org Thu Mar 08 15:51:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPPZ2-0006xB-Hd; Thu, 08 Mar 2007 15:50:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPPYp-0006lP-6l; Thu, 08 Mar 2007 15:50:03 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPPYo-0007af-T4; Thu, 08 Mar 2007 15:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id D3E2A3293A; Thu, 8 Mar 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HPPYo-0007FR-Nw; Thu, 08 Mar 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 08 Mar 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-syn-flood-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org --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 : TCP SYN Flooding Attacks and Common Mitigations Author(s) : W. Eddy Filename : draft-ietf-tcpm-syn-flood-02.txt Pages : 23 Date : 2007-3-8 This document describes TCP SYN flooding attacks, which have been well-known to the community for several years. Various countermeasures against these attacks, and the trade-offs of each, are described. This document archives explanations of the attack and common defense techniques for the benefit of TCP implementers and administrators of TCP servers or networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-syn-flood-02.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-syn-flood-02.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-syn-flood-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-3-8112336.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-syn-flood-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-syn-flood-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-8112336.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --NextPart-- From tcpm-bounces@ietf.org Fri Mar 09 04:06:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPb2W-0002S2-DH; Fri, 09 Mar 2007 04:05:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPQP5-0007tn-Nn for tcpm@ietf.org; Thu, 08 Mar 2007 16:44:03 -0500 Received: from mx1.grc.nasa.gov ([128.156.11.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPQP3-0005mK-Ab for tcpm@ietf.org; Thu, 08 Mar 2007 16:44:03 -0500 Received: from lombok-fi.grc.nasa.gov (seraph.grc.nasa.gov [128.156.10.10]) by mx1.grc.nasa.gov (Postfix) with ESMTP id 2D79EC2AD for ; Thu, 8 Mar 2007 16:43:56 -0500 (EST) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l28Lht40018322 for ; Thu, 8 Mar 2007 16:43:55 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l28Lhtd6011078 for ; Thu, 8 Mar 2007 16:43:55 -0500 (EST) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id E-ndW3d5YKJQ for ; Thu, 8 Mar 2007 16:43:55 -0500 (EST) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l28Lhsrg011071for ; Thu, 8 Mar 2007 16:43:54 -0500 (EST) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id 876CC4FE76; Thu, 8 Mar 2007 16:40:27 -0500 (EST) Date: Thu, 8 Mar 2007 16:40:26 -0500 From: Wesley Eddy To: tcpm@ietf.org Subject: Re: [tcpm] I-D ACTION:draft-ietf-tcpm-syn-flood-02.txt Message-ID: <20070308214023.GE6361@grc.nasa.gov> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1i X-imss-version: 2.046 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Thu, Mar 08, 2007 at 03:50:02PM -0500, Internet-Drafts@ietf.org wrote: > 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 : TCP SYN Flooding Attacks and Common Mitigations > Author(s) : W. Eddy > Filename : draft-ietf-tcpm-syn-flood-02.txt > Pages : 23 > Date : 2007-3-8 > > This document describes TCP SYN flooding attacks, which have been > well-known to the community for several years. Various > countermeasures against these attacks, and the trade-offs of each, > are described. This document archives explanations of the attack and > common defense techniques for the benefit of TCP implementers and > administrators of TCP servers or networks. > This update includes a number of fairly minor grammatical tweaks and wording clarifications suggested by Alfred Hoenes, Mark Allman, and Ted Faber. A paragraph on SYNs that carry data (e.g. as used in T/TCP) was added with some measurment data showing how uncommon this is. There is a colorized diff online at: http://tools.ietf.org/wg/tcpm/draft-ietf-tcpm-syn-flood/draft-ietf-tcpm-syn-flood-02-from-01.wdiff.html I noticed that I need to fix the entry for [All07] in the references, but that can be done after the WGLC that I think it's ready for since all the diffs were quite minor and the reviews have been largely positive. -- Wesley M. Eddy Verizon Federal Network Systems _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Mar 09 04:06:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPb25-00020p-3b; Fri, 09 Mar 2007 04:05:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPPZK-0007Ar-33; Thu, 08 Mar 2007 15:50:34 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HPPZI-000253-Nw; Thu, 08 Mar 2007 15:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id A6152176B1; Thu, 8 Mar 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HPPYo-0007Ek-Dy; Thu, 08 Mar 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 08 Mar 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-uto-05.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org --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 : TCP User Timeout Option Author(s) : L. Eggert, F. Gont Filename : draft-ietf-tcpm-tcp-uto-05.txt Pages : 16 Date : 2007-3-8 The TCP user timeout controls how long transmitted data may remain unacknowledged before a connection is forcefully closed. It is a local, per-connection parameter. This document specifies a new TCP option - the TCP User Timeout Option - that allows one end of a TCP connection to advertise its current user timeout value. This information allows the other end to adapt its user timeout accordingly. Increasing the user timeouts on both ends of a TCP connection allows it to survive extended periods without end-to-end connectivity. Decreasing the user timeouts allows busy servers to explicitly notify their clients that they will maintain the connection state only for a short time without connectivity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-uto-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tcpm-tcp-uto-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tcpm-tcp-uto-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-3-8110250.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-tcp-uto-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-uto-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-8110250.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --NextPart-- From tcpm-bounces@ietf.org Fri Mar 09 04:26:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPbN9-0002Cj-7X; Fri, 09 Mar 2007 04:26:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPWqC-00022m-Td for tcpm@ietf.org; Thu, 08 Mar 2007 23:36:30 -0500 Received: from [2001:fa8::25] (helo=mail.nttv6.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPWq9-0002JT-4B for tcpm@ietf.org; Thu, 08 Mar 2007 23:36:28 -0500 Received: from [192.47.163.196] (dhcp-3-196.nttv6.com [192.47.163.196]) by mail.nttv6.net (8.14.0/8.13.8) with ESMTP id l294a2tj066313 for ; Fri, 9 Mar 2007 13:36:03 +0900 (JST) (envelope-from arifumi@nttv6.net) Message-ID: <45F0E432.5040401@nttv6.net> Date: Fri, 09 Mar 2007 13:36:02 +0900 From: Arifumi Matsumoto User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [tcpm] ICMPv6 Error Handling at TCP draft-fujisaki-tcpm-icmpv6-reaction-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Hi all, we've posted an I-D that defines TCP reactions(soft/hard) to ICMPv6 error messages. This document translates ICMPv4 codes and into ICMPv6 codes in order to define soft error / hard error classification for ICMPv6 codes. I'd like to have a time slot for this item at Prague. Best regards. Title : TCP Reaction to ICMPv6 Error Messages Author(s) : T. Fujisaki, A. Matsumoto Filename : draft-fujisaki-tcpm-icmpv6-reaction-00.txt Pages : 7 Date : 2007-2-27 RFC1122 defines nodes TCP stack behavior for ICMPv4 error messages, but does not for ICMPv6. This document defines ICMPv6 message classification and node's TCP stack behavior for ICMPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-fujisaki-tcpm-icmpv6-reaction-00.txt Best regards. -- Arifumi Matsumoto IP Technology Expert Team Secure Communication Project NTT Information Sharing Platform Laboratories E-mail: arifumi@nttv6.net _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Mar 09 15:13:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPlSA-0004uw-AI; Fri, 09 Mar 2007 15:12:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPlS8-0004uK-QF for tcpm@ietf.org; Fri, 09 Mar 2007 15:12:36 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPlS7-0001zv-G6 for tcpm@ietf.org; Fri, 09 Mar 2007 15:12:36 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l29KCXx4018964; Fri, 9 Mar 2007 12:12:33 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id B88868A586E; Fri, 9 Mar 2007 15:12:27 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id C004519CE1E; Fri, 9 Mar 2007 15:12:24 -0500 (EST) To: tcpm@ietf.org From: Mark Allman Subject: Re: [tcpm] I-D ACTION:draft-ietf-tcpm-syn-flood-02.txt In-Reply-To: <20070308214023.GE6361@grc.nasa.gov> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Tom Sawyer MIME-Version: 1.0 Date: Fri, 09 Mar 2007 15:12:24 -0500 Message-Id: <20070309201224.C004519CE1E@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: weddy@grc.nasa.gov X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0841990041==" Errors-To: tcpm-bounces@ietf.org --===============0841990041== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > > Title : TCP SYN Flooding Attacks and Common Mitigations > > Author(s) : W. Eddy > > Filename : draft-ietf-tcpm-syn-flood-02.txt > > Pages : 23 > > Date : 2007-3-8 Folks- Our intention is to WGLC this document immediately after the Prague IETF. If you have comments or think we are mistaken in believing this is the right next step please yell. Thanks, allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFF8b+oWyrrWs4yIs4RAjyRAJ0aivrSk3ub47gJnO7n4gBoaPBTOQCgg/NM F9mTlNelqfyh5XjJXHnt29I= =7253 -----END PGP SIGNATURE----- --=_bOundary-- --===============0841990041== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0841990041==-- From tcpm-bounces@ietf.org Fri Mar 09 17:28:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPnYi-00024t-W1; Fri, 09 Mar 2007 17:27:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPnYg-0001xh-R8 for tcpm@ietf.org; Fri, 09 Mar 2007 17:27:31 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPnYe-0003AN-HB for tcpm@ietf.org; Fri, 09 Mar 2007 17:27:30 -0500 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l29MRF3K008289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 9 Mar 2007 14:27:15 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.8/8.13.8/Submit) id l29MRFK1089068 for tcpm@ietf.org; Fri, 9 Mar 2007 14:27:15 -0800 (PST) (envelope-from faber) Date: Fri, 9 Mar 2007 14:27:15 -0800 From: Ted Faber To: tcpm@ietf.org Message-ID: <20070309222714.GP81409@hut.isi.edu> Mime-Version: 1.0 User-Agent: Mutt/1.4.2.2i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 1.6 (+) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Subject: [tcpm] (no subject) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1122089406==" Errors-To: tcpm-bounces@ietf.org --===============1122089406== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GPT5DIEyVHz5yXBV" Content-Disposition: inline --GPT5DIEyVHz5yXBV Content-Type: multipart/mixed; boundary="e7jIye1Ygp5H0AIi" Content-Disposition: inline --e7jIye1Ygp5H0AIi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In accordance with draft-ietf-proto-wgchair-doc-shepherding-09.txt, the TCPM working group has requested publication of draft-ietf-tcpm-tcp-antispoof-06.txt as an informational RFC. This is a copy of the information sent to the AD and the IESG as requested by the document above. The proto writeup and document announcement write-up are attached, --=20 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 --e7jIye1Ygp5H0AIi Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=proto 1 a. Ted Faber 1 b. The document has had adequate review 1 c. The document has had adequate review 1 d. I don't believe that there are outstanding issues regarding the acceptability of teh document to the WG or any spoilers to be found in advancing it. 1 e. WG consensus seems to be solid. There were 2 WGLCs, one of which raised substantive unaddressed issues. Those issues were addressed and the second WGLC completed with those problems resolved to the satisfaction of those involved and the WG. 1 f. No extreme discontent. Pekka Savola expresses concerns that he said he would raise at an IETF last call at one point, but I believe those concerns have been addressed during WGLC. Pekka's concerns centered on the effectiveness of ingress filtering on addressing the problems with spoofing. 1 g. I've done the check. The only issue is that two referenced drafts have had their version numbers bumped since this version was handed to us. They are: draft-ietf-tcpm-syn-flood-01 draft-ietf-tcpm-tcpsecure-06 1 h. No normative refs. Informational RFC. 1 i. No substantive IANA section. Informational RFC. 1 j. No such sections. 1 k. Attached. --e7jIye1Ygp5H0AIi Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=announce Content-Transfer-Encoding: quoted-printable Technical Summary This document is a description fo the sorts of off-path spoofing attacks that TCP is vulnerable to and the various existing ane proposed mitigations of those attacks. It is a fairly detailed discussion of the attacks and forms a good basis for sddressing the problems in TCP as well as starting the discussion for other protocols. More practically, it can be used by designers and implementors to decide which of these strategies are appropriate for their situation. Working Group Summary The draft came in to being primarily becayse the author was concerned that a new draft addressing these vulnerabilities did not adeqyately address prior work or present alternatives to that draft's solutions. Eventaully those concerns were separated into this draft, which the group believes has pedagogical and practical value. Document Quality =09 The document has been endorsed by the working group as being complete and well written pretty universally. Personnel Document Shepherd: Ted Faber Responsible AD: Lars Eggert --e7jIye1Ygp5H0AIi-- --GPT5DIEyVHz5yXBV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.2 (FreeBSD) iD8DBQFF8d9CaUz3f+Zf+XsRAiSSAJ49DLoPVmyCC2dsaVpxi6XzOFF3NgCeMTIT cMa1VqJPOwFXKAIXk/Q60Ig= =Qfom -----END PGP SIGNATURE----- --GPT5DIEyVHz5yXBV-- --===============1122089406== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1122089406==-- From tcpm-bounces@ietf.org Mon Mar 12 10:59:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQlzi-0001af-A0; Mon, 12 Mar 2007 10:59:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQlzf-0001Wo-3E; Mon, 12 Mar 2007 10:59:23 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HQlzd-000676-RR; Mon, 12 Mar 2007 10:59:23 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id C5F8A2AC3A; Mon, 12 Mar 2007 14:58:51 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HQlz9-0006nw-I9; Mon, 12 Mar 2007 10:58:51 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 12 Mar 2007 10:58:51 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: tcpm@ietf.org Subject: [tcpm] Last Call: draft-ietf-tcpm-tcp-antispoof (Defending TCP Against Spoofing Attacks) to Informational RFC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'Defending TCP Against Spoofing Attacks ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-04-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-antispoof-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12884&rfc_flag=0 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Mar 12 18:11:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQsiT-0007jd-4m; Mon, 12 Mar 2007 18:10:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQsiR-0007ip-NQ for tcpm@ietf.org; Mon, 12 Mar 2007 18:10:03 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQsiP-00071Z-On for tcpm@ietf.org; Mon, 12 Mar 2007 18:10:03 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 12 Mar 2007 15:10:01 -0700 X-IronPort-AV: i="4.14,275,1170662400"; d="txt'?scan'208"; a="766301970:sNHT90278892" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2CMA17J026618 for ; Mon, 12 Mar 2007 15:10:01 -0700 Received: from [171.69.75.39] ([171.69.75.39]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2CMA11T022136 for ; Mon, 12 Mar 2007 22:10:01 GMT Message-ID: <45F5CFB9.1010109@cisco.com> Date: Mon, 12 Mar 2007 15:10:01 -0700 From: Mahesh Jethanandani User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: multipart/mixed; boundary="------------000209010709030707070904" DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=19468; t=1173737401; x=1174601401; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mahesh@cisco.com; z=From:=20Mahesh=20Jethanandani=20 |Subject:=20Updated=20I-D=3A=20draft-mahesh-persist-timeout-01.txt |Sender:=20; bh=V7kO88Ny84bV2S5MpIS5wAKWcrPzBGCMa8cR9vpwxh0=; b=BjkM5DHYPRTAk/g5iao3EbgCC8HZRtpwHcWJ5wIGdHQCEY4biMBcN6aEs6nCaQn0KXHbla6d TrkBBahbf3/3ApdOl98TRBgfAnkZAx/Vyk0lVTBaD41qUTiJTOiNLotUe0rBzu3XmG1OuEIV+I bn9xYdbfQsazGbMwwQC6fVhJs=; Authentication-Results: sj-dkim-1; header.From=mahesh@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c4a3535d1556ada67f8703d3d31591 Subject: [tcpm] Updated I-D: draft-mahesh-persist-timeout-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. --------------000209010709030707070904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I am attaching an updated version of the draft. It incorporates all the comments we have received till date. The draft now has a DoS section and talks about some of the methods that can be used under DoS. It also expands on the role of what applications can do. --------------000209010709030707070904 Content-Type: text/plain; name="draft-mahesh-persist-timeout-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-mahesh-persist-timeout-01.txt" TCP Maintenance and Minor M. Jethanandani Extensions Cisco Systems Internet-Draft M. Bashyam Intended status: Informational Ocarina Systems, Inc Expires: September 8, 2007 March 7, 2007 draft-mahesh-persist-timeout-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 8, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document describes how a connection can remain infinitely in persist state and its Denial of Service (DoS) implication on the system if there is no mechanism to recover from this anomaly. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Jethanandani & Bashyam Expires September 8, 2007 [Page 1] Internet-Draft Improving TCP robustness in persist state March 2007 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Denial of Service . . . . . . . . . . . . . . . . . . . . . . . 4 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Role of Application . . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 Appendix A. An Appendix . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Jethanandani & Bashyam Expires September 8, 2007 [Page 2] Internet-Draft Improving TCP robustness in persist state March 2007 1. Introduction RFC 1122 [RFC1122] Section 4.2.2.17, page 92 says that: A TCP MAY keep its offered receive window closed indefinitely. As long as the receiving TCP continues to send acknowledgments in response to the probe segments, the sending TCP MUST allow the connection to stay open. The RFC goes on to say that it is important to remember that ACK (acknowledgement) segments that contain no data are not reliably transmitted by TCP. Therefore zero window probing SHOULD be supported to prevent a connection from hanging forever if ACK segments that re-opens the window is lost. While it is clear why the sender needs to continue to probe the receiver, it is not clear why this process needs to be indefinite, particularly if the receiver reliably responds with a ACK and a window of zero. The particular situation we ran into was with a gaming client that would receive regular updates of the ensuing game from the server. At some point the client decided to pause the game, effectively telling the application to stop reading data from the TCP connection. Another example of such a setup is a HTTP based Web conferencing. The problem is applicable to TCP and TCP derived transport protocol like SCTP. The effect of the client that stops reading data is that the server continues to send data till the advertised window goes down to zero at which time the connection enters persist state. Since the server has more buffers with data for the client, it will continue to probe the receiver. However, it is not clear what the sender is supposed to do if the receiver never exits this state. It is quite possible that the receiving end continues to advertise a zero window for an extended period of time which could result in the sender holding on to large number of buffers/data. If the sender is servicing several such clients the effect compounds itself to the extent that the system runs out of buffers and or connection resources. The sender at this point cannot service new legitimate connections and even the existing connections start seeing degraded service. It is not possible to enforce application control to recover from this scenario as will be described in the following sections of the document. Jethanandani & Bashyam Expires September 8, 2007 [Page 3] Internet-Draft Improving TCP robustness in persist state March 2007 For TCP to persist indefinitely makes the end point vulnerable to a DoS attack. We therefore suggest that TCP end point SHOULD NOT persist for an indefinite amount of time. 2. Denial of Service One instance of a DoS that is possible is for clients to open a large number of connections that will ultimately enter persist state causing TCP to run out of resources. It is also possible for the client to open its receive window briefly and with a small value, enough to make the server take the connection out of persist state. To prevent this, and only when the administrator has opted to use the solution described below, we would apply a threshold check on the receive window to be at least one Maximum Segment Size (MSS) before taking the connection out of persist state. 3. Solution The current behavior of the connection in persist state SHALL continue to exist as the default behavior. We are proposing an option to enable an upper bound to the persist state with an absolute time limit or via a set number of retries. To enable an upper bound to the persist state, the administrator MAY configure an option. The option SHOULD be configured as a time or number of retries. If both the options are configured, whichever option kicks in first will take effect. If the configured option is time then that implies how long the connection will be allowed to stay in persist state. The configured option is called persist-state-expiry-time. When the connection enters persist state, i.e. the receiver advertises a window of zero, the value of current time is saved in the connection entry. This entry is called persist-entry-time. Thereafter every time the persist timer expires, and before it is set, or when an ACK is received that continues to advertise zero window, a check is done to make sure that the difference between current time and persist-entry- time is not more than persist-state-expiry-time. If it is then the connection is reset and the connection resources are reclaimed by TCP. Any time after the connection has gone into persist state and before reset of the connection, if the receiver advertises a non-zero window, the persist-entry-time is cleared. If the configured option is number of retries it implies the number Jethanandani & Bashyam Expires September 8, 2007 [Page 4] Internet-Draft Improving TCP robustness in persist state March 2007 of retries that will be made before the connection is aborted. The configured option is called persist-state-expiry-retries. When the connection enters persist state, i.e. the receiver advertises a window of zero, the count of retries called persist-state-retry-count in the connection entry is cleared. Thereafter every time the persist timer expires, and before it is set, or when and ACK is received that continues to advertise zero window, a check is done to make sure that persist-state-retry-count does not exceed persist- state-expiry-retries. If it does, the connection is reset and the connection resources are reclaimed by TCP. Any time after the connection has gone into persist state and before reset of the connection, if the receiver advertises a non-zero window, the persist-state-expiry-retries is cleared. If the difference between the current retry count and persist-entry-expiry-count is less than the persist-state-expiry-retries, the current retry count is incremented by one. This configuration option of persist-state- expiry-retries is more coarse grained compared to the persist-state- expiry-time option. Application can suggest a persist-state-expiry-time or the persist- state-expiry-retries to TCP. The application suggested values will override the default values that TCP will use. These values will apply to only the application and the connections on which the values have been suggested and not to all TCP connections. The default values should allow for the sender to send probes a few times. More experimentation is required to come up with the default values. However, TCP may find that in spite of implementing the above suggested solution it is still running out of resources because there are too many connections in persist state. A smaller value of the persist-state-expiry-time or the persist-state-retry-count would help clear some of these connections sooner. Alternatively, the schemes that TCP can use to decide which connections to clear is to look at connections that are holding the maximum number of buffers for the longest amount of time. An ordered list of the TCP send queue size times delta of the current stamp and the time when the connection entered persist state will give TCP an idea of which connections are holding the maximum number of resources. 4. Role of Application In order to understand if application can play a role in solving this problem, one needs to understand the current behavior of application vis-a-vis TCP. Jethanandani & Bashyam Expires September 8, 2007 [Page 5] Internet-Draft Improving TCP robustness in persist state March 2007 Applications today do not know if a connection is stuck in persist state. Application in most cases is even unaware why TCP is not sending any more data. It cannot distinguish between segments getting dropped because of network issues or send window not advancing because the other end has closed the window. Trying to keep the application appraised of what is causing the problem only takes care of that particular connection and that particular application. It does not take care of all applications and all connections that might be in persist state. TCP in most cases will not signal that a connection is blocked. This is particularly true if there are buffers available or application has no more data to send. If the application were to poll TCP to get the information, it is not clear how often it would need to poll. As described before TCP MAY not send more data because of several reasons and in most cases the polling will show that the connection MAY not even be in persist state. It is also possible for applications to write data and exit before the data is sent. An example of this application is HTTP server. When a HTTP server receives a HTTP request like a GET, the server will respond with data and go ahead and close the socket even before TCP has finished sending all the data. In that case, TCP has no application it can inform to take action on a connection stuck in persist state. There are cases where the system is application agnostic. A classic case of this is a TCP proxy. In that particular case, there is no end application that can be informed of the state of the connection for the application to take action. Resources like TCP buffers are system wide resources and are not tied to any particular application. TCP needs to be able to monitor buffer usage on a per connection basis for it to detect and drop packets on connections that are taking up a lot of buffers. TCP cannot rely on an application to perform the task of looking at buffers system wide. Applications have a role to play in solving this problem. They can register for an asynchronous notification when the TCP connection enters or exits persist state. They can use the notification mechanism to implement their own scheme of deciding which persist connections to clear. They can also suggest timeout or retry values to TCP. It is quite possible that the application that is encountering the problem may not have implemented the above mentioned scheme. Since the impact of a connection in persist state is system wide all Jethanandani & Bashyam Expires September 8, 2007 [Page 6] Internet-Draft Improving TCP robustness in persist state March 2007 applications have to have implemented the option for the solution to be effective. Even one application that has not implemented the option can cause the entire system to be impacted. It is also not possible to get every application to implement detection of persist state and have it clear the connection. However TCP can look at the persist state system wide. TCP already keeps track of connections in persist state. The advantage of doing this in TCP is that once enabled, the entire system including all the applications benefit. Moreover, resources like buffers which are system wide can be monitored by TCP to determine when to reset a connection and reclaim the resources. 5. IANA Considerations This document makes no request of IANA. 6. Security Considerations This document discusses one security consideration. That is the possible DoS attacks discussed in Section 2. 7. Acknowledgements Thanks to Anantha Ramaiah who spent countless hours reviewing, commenting and proposing changes the draft. Thanks also to Fred Baker for providing his feedback on the draft. 8. References 8.1. Normative References [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References Appendix A. An Appendix Jethanandani & Bashyam Expires September 8, 2007 [Page 7] Internet-Draft Improving TCP robustness in persist state March 2007 Authors' Addresses Mahesh Jethanandani Cisco Systems 170 West Tasman Drive San Jose, California 95134 USA Phone: +1-408-527-8230 Fax: +1-408-527-0147 Email: mahesh@cisco.com URI: www.cisco.com Murali Bashyam Ocarina Systems, Inc Fremont, CA USA Phone: Fax: Email: mbashyam@ocarinatech.com URI: Jethanandani & Bashyam Expires September 8, 2007 [Page 8] Internet-Draft Improving TCP robustness in persist state March 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Jethanandani & Bashyam Expires September 8, 2007 [Page 9] --------------000209010709030707070904 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --------------000209010709030707070904-- From tcpm-bounces@ietf.org Tue Mar 13 03:56:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR1qx-0006jp-52; Tue, 13 Mar 2007 03:55:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR1qv-0006jZ-5w for tcpm@ietf.org; Tue, 13 Mar 2007 03:55:25 -0400 Received: from diotima.switch.ch ([2001:620:0:4:203:baff:fe4c:d751]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR1qt-0002S9-GZ for tcpm@ietf.org; Tue, 13 Mar 2007 03:55:25 -0400 Received: from diotima.switch.ch (localhost [127.0.0.1]) by diotima.switch.ch (8.13.8+Sun/8.13.8) with ESMTP id l2D7q70A026958; Tue, 13 Mar 2007 08:52:07 +0100 (CET) Received: (from leinen@localhost) by diotima.switch.ch (8.13.8+Sun/8.13.8/Submit) id l2D7q7J5026957; Tue, 13 Mar 2007 08:52:07 +0100 (CET) X-Authentication-Warning: diotima.switch.ch: leinen set sender to simon@limmat.switch.ch using -f From: Simon Leinen To: Mahesh Jethanandani Subject: Re: [tcpm] Updated I-D: draft-mahesh-persist-timeout-01.txt In-Reply-To: <45F5CFB9.1010109@cisco.com> (Mahesh Jethanandani's message of "Mon, 12 Mar 2007 15:10:01 -0700") References: <45F5CFB9.1010109@cisco.com> X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7, F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z, @ttmwYVO7l`6OXXYR` Date: Tue, 13 Mar 2007 08:52:07 +0100 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.95 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.8 (--) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org I know this sounds like a stupid question, but: What is the title of this draft? -- Simon. Mahesh Jethanandani writes: > I am attaching an updated version of the draft. It incorporates all > the comments we have received till date. [...] > TCP Maintenance and Minor M. Jethanandani > Extensions Cisco Systems > Internet-Draft M. Bashyam > Intended status: Informational Ocarina Systems, Inc > Expires: September 8, 2007 March 7, 2007 > draft-mahesh-persist-timeout-01 > Status of this Memo [...] _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Mar 13 11:53:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR9Hy-0006n2-B5; Tue, 13 Mar 2007 11:51:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR9Hv-0006mq-Pu for tcpm@ietf.org; Tue, 13 Mar 2007 11:51:47 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR9Hu-0001KT-6b for tcpm@ietf.org; Tue, 13 Mar 2007 11:51:47 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 13 Mar 2007 08:51:42 -0700 X-IronPort-AV: i="4.14,280,1170662400"; d="gif'147?scan'147,208,217,147"; a="400685597:sNHT135997264" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l2DFpf8N003539; Tue, 13 Mar 2007 08:51:41 -0700 Received: from [10.21.104.126] (sjc-vpnasa1-126.cisco.com [10.21.104.126]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l2DFpca3026605; Tue, 13 Mar 2007 15:51:41 GMT Message-ID: <45F6C889.8060201@cisco.com> Date: Tue, 13 Mar 2007 08:51:37 -0700 From: Mahesh Jethanandani Organization: Cisco Systems Inc. User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Simon Leinen Subject: Re: [tcpm] Updated I-D: draft-mahesh-persist-timeout-01.txt References: <45F5CFB9.1010109@cisco.com> In-Reply-To: DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6294; t=1173801101; x=1174665101; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mahesh@cisco.com; z=From:=20Mahesh=20Jethanandani=20 |Subject:=20Re=3A=20[tcpm]=20Updated=20I-D=3A=20draft-mahesh-persist-time out-01.txt |Sender:=20; bh=D8WdclywXnw6Xe2Os1jOTRqlX/3E8VTBvffe2E3+fdw=; b=xUlt9ViKtf64UHEMe3/MfrEnvhtYnMBF/1+k6fUtTlalzaOOsNABOM4o1wQnJaIhUgQswnkL YLUlyJn+Ht/db0pDSxiCN55/sKqlS3cnfOCc8er0cwsBtcNnzSTW4fxI; Authentication-Results: sj-dkim-5; header.From=mahesh@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0164824312==" Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. --===============0164824312== Content-Type: multipart/alternative; boundary="------------070901000802040308080007" This is a multi-part message in MIME format. --------------070901000802040308080007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Improving TCP Robustness in Persist State. Simon Leinen wrote: > I know this sounds like a stupid question, but: > What is the title of this draft? > -- *Mahesh Jethanandani* *Technical Leader* **Corporate Development* * mahesh@cisco.com Phone :*+1 408 527-8230* Fax :*+1 408 527-6351* ** 170 West Tasman Drive San Jose, CA 95070 United States www.cisco.com This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message. --------------070901000802040308080007 Content-Type: multipart/related; boundary="------------020607010305040504020803" --------------020607010305040504020803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Improving TCP Robustness in Persist State.

Simon Leinen wrote: 
I know this sounds like a stupid question, but:
What is the title of this draft?

--

Mahesh Jethanandani
Technical Leader
Corporate Development

mahesh@cisco.com
Phone :+1 408 527-8230
Fax :+1 408 527-6351


170 West Tasman Drive
San Jose, CA 95070
United States
www.cisco.com

  
This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message.


--------------020607010305040504020803 Content-Type: image/gif; name="spacer.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="spacer.gif" R0lGODlhBQAFAJEAAAAAAP///////wAAACH5BAEAAAIALAAAAAAFAAUAAAIElI+pWAA7 --------------020607010305040504020803 Content-Type: image/gif; name="footerHead.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="footerHead.gif" R0lGODlhHwIBAJEAAAAAAP///9bY2v///yH5BAEAAAMALAAAAAAfAgEAAAIVlI+py+0Po5y0 2ouz3rz7D4biSE4FADs= --------------020607010305040504020803 Content-Type: image/gif; name="footer.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="footer.gif" R0lGODlhHwIRAMQAAAAAAP////f3+PX19vHx8u7u7+jp6+Tl59/g4tze4Nvd39ja3NfZ29bY 2vHy8+3u7+vs7eTl5ufp6uTm597g4dze3/j5+fHy8v7+/v39/fv7+/n5+f///wAAAAAAAAAA ACH5BAEAABwALAAAAAAfAhEAAAXY4JIFZGmeaKqubOu+cCzPdG3feK7vfO//wKCwlVkkNsOk cslsOp/QqHRKFW4SE0J1y+16v+CweJwkZCfktHrNbrvf7yymMoDb7/i8fp8fKDABFweAfIWG h4iJijIYBxclBhIai5SVlpeYXhoSBicQDA+ZoqOkpaYuBQwQKRsIERcCp7KztLV2Ag4RCBYs DgcUDcHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3twUEQ625OXm5+jp6uvs7e7v8PHy 8/T19vf4+fr7/P3+/wADChxIUEYIADs= --------------020607010305040504020803-- --------------070901000802040308080007-- --===============0164824312== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0164824312==-- From tcpm-bounces@ietf.org Wed Mar 14 12:40:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRWUR-0001yV-8y; Wed, 14 Mar 2007 12:38:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRWRn-0000x8-Ho for tcpm@ietf.org; Wed, 14 Mar 2007 12:35:31 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRWMi-0000gS-Mc for tcpm@ietf.org; Wed, 14 Mar 2007 12:30:18 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2EGU35G029254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 14 Mar 2007 09:30:03 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.8/8.13.8/Submit) id l2EGU3jo079000 for tcpm@ietf.org; Wed, 14 Mar 2007 09:30:03 -0700 (PDT) (envelope-from faber) Date: Wed, 14 Mar 2007 09:30:03 -0700 From: Ted Faber To: tcpm@ietf.org Message-ID: <20070314163003.GC1365@hut.isi.edu> Mime-Version: 1.0 User-Agent: Mutt/1.4.2.2i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Subject: [tcpm] modified TCPM agenda X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0982029542==" Errors-To: tcpm-bounces@ietf.org --===============0982029542== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NklN7DEeGtkPCoo3" Content-Disposition: inline --NklN7DEeGtkPCoo3 Content-Type: multipart/mixed; boundary="OBd5C1Lgu00Gd/Tn" Content-Disposition: inline --OBd5C1Lgu00Gd/Tn Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Mark and I have added a final talk to the TCPM agenda: TCP Response to Lower-Layer Connectivity-Change Indications Simon Sch=FCtz http://www.ietf.org/internet-drafts/draft-schuetz-tcpm-tcp-rlci-01.txt draft-schuetz-tcpm-tcp-rlci-01.txt The full agenda is at http://www3.ietf.org/proceedings/07mar/agenda/tcpm.txt A text copy is attached for Aaron. --=20 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 --OBd5C1Lgu00Gd/Tn Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: attachment; filename="agenda.txt" Content-Transfer-Encoding: quoted-printable TCPM agenda WG Business =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D WG Status - 10-15 minutes Dave Borman =09 User Timeout (10 minutes) Lars Eggert http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-uto-05.txt draft-ietf-tcpm-tcp-uto-05.txt TCP-secure (10 minutes) ?? Non-WG =3D=3D=3D=3D=3D=3D Identifying Cheating Receivers (15-20 minutes) Toby Moncaster http://www.ietf.org/internet-drafts/draft-moncaster-tcpm-rcv-cheat-00.txt draft-moncaster-tcpm-rcv-cheat-00.txt TCP Response to Lower-Layer Connectivity-Change Indications Simon Sch=FCtz http://www.ietf.org/internet-drafts/draft-schuetz-tcpm-tcp-rlci-01.txt draft-schuetz-tcpm-tcp-rlci-01.txt --OBd5C1Lgu00Gd/Tn-- --NklN7DEeGtkPCoo3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (FreeBSD) iD8DBQFF+CMLaUz3f+Zf+XsRAv+SAKCYK08kRpmdIMbYD83LvmbGGzJNqwCdG0UN TtA3b4AW995JMeSx8CxHenc= =peCd -----END PGP SIGNATURE----- --NklN7DEeGtkPCoo3-- --===============0982029542== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0982029542==-- From tcpm-bounces@ietf.org Wed Mar 14 16:52:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRaQA-00078B-Gb; Wed, 14 Mar 2007 16:50:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRaQ9-000783-On for tcpm@ietf.org; Wed, 14 Mar 2007 16:50:05 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRaQ6-0001uT-DL for tcpm@ietf.org; Wed, 14 Mar 2007 16:50:05 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l2EKnxPE028864 for ; Wed, 14 Mar 2007 13:49:59 -0700 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 184D98D4104 for ; Wed, 14 Mar 2007 16:49:54 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id EB9851A907A for ; Wed, 14 Mar 2007 16:49:53 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Back in the USSR MIME-Version: 1.0 Date: Wed, 14 Mar 2007 16:49:53 -0400 Message-Id: <20070314204953.EB9851A907A@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [tcpm] soft errors X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2008598048==" Errors-To: tcpm-bounces@ietf.org --===============2008598048== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Folks- The chairs have been iterating with Fernando about the soft errors draft. The current version is draft-ietf-tcpm-tcp-soft-errors-03.txt. We think all the substantive issues that have been raised have been taken care of at this point. Our intention is to WGLC this starting on Apr/2 (to avoid completely over-lapping with the previously announced WGLC for syn-flooding). If you think we have mis-judged things you are of course free to raise issues on the list. Thanks, allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFF+F/xWyrrWs4yIs4RAtLoAJ4jLtYtNDaPUls56FWOEcysYb8h7QCeM6v7 IORgw1Vtq+mK/RAyoemKOUY= =McqM -----END PGP SIGNATURE----- --=_bOundary-- --===============2008598048== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============2008598048==-- From tcpm-bounces@ietf.org Thu Mar 15 20:47:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HS0ZA-0007Rk-DP; Thu, 15 Mar 2007 20:45:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HS0Z9-0007Rd-HU for tcpm@ietf.org; Thu, 15 Mar 2007 20:45:07 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HS0Z7-00079y-3H for tcpm@ietf.org; Thu, 15 Mar 2007 20:45:07 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2G0id05013101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 15 Mar 2007 17:44:39 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.8/8.13.8/Submit) id l2G0idRJ014911 for tcpm@ietf.org; Thu, 15 Mar 2007 17:44:39 -0700 (PDT) (envelope-from faber) Date: Thu, 15 Mar 2007 17:44:39 -0700 From: Ted Faber To: tcpm@ietf.org Subject: Re: [tcpm] modified TCPM agenda Message-ID: <20070316004439.GC12512@hut.isi.edu> References: <20070314163003.GC1365@hut.isi.edu> Mime-Version: 1.0 In-Reply-To: <20070314163003.GC1365@hut.isi.edu> User-Agent: Mutt/1.4.2.2i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0643023265==" Errors-To: tcpm-bounces@ietf.org --===============0643023265== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1sNVjLsmu1MXqwQ/" Content-Disposition: inline --1sNVjLsmu1MXqwQ/ Content-Type: multipart/mixed; boundary="2JFBq9zoW8cOFH7v" Content-Disposition: inline --2JFBq9zoW8cOFH7v Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I firmly believe that this is the final TCPM agenda: http://www3.ietf.org/proceedings/07mar/agenda/tcpm.txt The additions are the tcpsecure information and the FRTO time slot. Sorry for the late modifications. =3D=3D=3D TCPM agenda WG Business =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D WG Status - 10 minutes David Borman =09 User Timeout (10 minutes) Lars Eggert http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-uto-05.txt draft-ietf-tcpm-tcp-uto-05.txt TCP-secure (10 minutes) Anantha Ramaiah http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-07.txt draft-ietf-tcpm-tcpsecure-07.txt FRTO update to proposed standard (10 minutes) Markku Kojo http://www.cs.helsinki.fi/u/sarolaht/frto/ Non-WG =3D=3D=3D=3D=3D=3D Identifying Cheating Receivers (10 minutes) Toby Moncaster http://www.ietf.org/internet-drafts/draft-moncaster-tcpm-rcv-cheat-00.txt draft-moncaster-tcpm-rcv-cheat-00.txt TCP Response to Lower-Layer Connectivity-Change Indications (10 minutes) Simon Sch=FCtz http://www.ietf.org/internet-drafts/draft-schuetz-tcpm-tcp-rlci-01.txt draft-schuetz-tcpm-tcp-rlci-01.txt --=20 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 --2JFBq9zoW8cOFH7v Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: attachment; filename="agenda.txt" Content-Transfer-Encoding: quoted-printable TCPM agenda WG Business =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D WG Status - 10 minutes David Borman =09 User Timeout (10 minutes) Lars Eggert http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-uto-05.txt draft-ietf-tcpm-tcp-uto-05.txt TCP-secure (10 minutes) Anantha Ramaiah http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-07.txt draft-ietf-tcpm-tcpsecure-07.txt FRTO update to proposed standard (10 minutes) Markku Kojo http://www.cs.helsinki.fi/u/sarolaht/frto/ Non-WG =3D=3D=3D=3D=3D=3D Identifying Cheating Receivers (10 minutes) Toby Moncaster http://www.ietf.org/internet-drafts/draft-moncaster-tcpm-rcv-cheat-00.txt draft-moncaster-tcpm-rcv-cheat-00.txt TCP Response to Lower-Layer Connectivity-Change Indications (10 minutes) Simon Sch=FCtz http://www.ietf.org/internet-drafts/draft-schuetz-tcpm-tcp-rlci-01.txt draft-schuetz-tcpm-tcp-rlci-01.txt --2JFBq9zoW8cOFH7v-- --1sNVjLsmu1MXqwQ/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (FreeBSD) iD8DBQFF+eh3aUz3f+Zf+XsRAkXQAJ0bef2lnI691uATFk+yZaoTlCRKagCg/5Sl 35Vurf1HzBtVLk36B2tTskA= =GJ3H -----END PGP SIGNATURE----- --1sNVjLsmu1MXqwQ/-- --===============0643023265== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0643023265==-- From tcpm-bounces@ietf.org Thu Mar 15 21:19:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HS15b-0004Tp-3l; Thu, 15 Mar 2007 21:18:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HS15Z-0004SR-S8 for tcpm@ietf.org; Thu, 15 Mar 2007 21:18:37 -0400 Received: from darkstar.isi.edu ([128.9.128.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HS15Y-0003lg-FE for tcpm@ietf.org; Thu, 15 Mar 2007 21:18:37 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id l2G1IMIC026942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 15 Mar 2007 18:18:22 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.8/8.13.8/Submit) id l2G1IM26015496 for tcpm@ietf.org; Thu, 15 Mar 2007 18:18:22 -0700 (PDT) (envelope-from faber) Date: Thu, 15 Mar 2007 18:18:22 -0700 From: Ted Faber To: tcpm@ietf.org Message-ID: <20070316011822.GG12512@hut.isi.edu> Mime-Version: 1.0 User-Agent: Mutt/1.4.2.2i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Subject: [tcpm] Hat off: tcpsecure mitigations X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0221567540==" Errors-To: tcpm-bounces@ietf.org --===============0221567540== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qVHblb/y9DPlgkHs" Content-Disposition: inline --qVHblb/y9DPlgkHs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi. I recently did a read-through of the tcpsecure draft to see how close it was to a WGLC, and came across an issue I'd like to put before the group. I'm doing this without a chair hat on, just as a private individual. Looking over the 3 mitigations proposed in that draft, I think that the first two, the SYN and RST mitigations, are clean and elegant. I'm perfectly happy to publish a draft saying that TCP implementations SHOULD implement them. The data injection mitigation doesn't have the same cleanness to it, and I'd like to make that mitigation a MAY. Here's my thinking: =09 The SYN and RST changes are simple and clear and require minimal new code to implement. A host simply accepts the segment if its SEG.SEQ is the same as RCV.NXT and ACKs it otherwise. No extra space in the control block, minimal places to go astray and a significant improvement in the protection afforded against malicious and misbehaving stacks - the spoofable range of seqnos drops from the size of the receive window to 1. The data mitigation is more complex - there's an extra state variable defined to check the ACK value of each received segment - and there's some room to go astray in the implementation of that state variable. I don't begrudge an implementation the extra word in the data structure, but it's an indication that this mitigation doesn't have the same simplicity as the RST and SYN mitigations. Furthermore, the mitigation is less effective. If there is significant bi-directional traffic on the connection there will be basically no mitigation. My understanding is that the connections most vulnerable to these attacks are long-standing connections that have large windows - exactly the ones that will receive the least effect from this mitigation. I'm not suggesting we discard the mitigation, but because a developer might think, IMHO rightly, that the additional complexity is not worth the additional protection, I think we should give that developer an out by making this mitigation OPTIONAL. I've talked to the authors about this, so I'm not trying to surprise them while they're on the plane. I'm sure they'll jump in and discuss. I'm hoping to get a discussion going here and possibly in Prague about how strongly we want to recommend the data mitigation. I believe their presentation will raise some of these points and their responses. Thanks. --=20 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 --qVHblb/y9DPlgkHs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (FreeBSD) iD8DBQFF+fBeaUz3f+Zf+XsRAmyWAKDyHHWkMLuViNFJsPi+8Qm2SttgEwCeOp/s QQqSVwl/4wyXiJcibU8JT1o= =kFmO -----END PGP SIGNATURE----- --qVHblb/y9DPlgkHs-- --===============0221567540== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0221567540==-- From tcpm-bounces@ietf.org Fri Mar 16 15:06:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSHjP-000736-K2; Fri, 16 Mar 2007 15:04:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSHhP-0006Nm-Jh for tcpm@ietf.org; Fri, 16 Mar 2007 15:02:47 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSHdf-0003Us-3v for tcpm@ietf.org; Fri, 16 Mar 2007 14:58:57 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-3.cisco.com with ESMTP; 16 Mar 2007 11:58:54 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l2GIwsXs003450; Fri, 16 Mar 2007 11:58:54 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l2GIwswt019100; Fri, 16 Mar 2007 18:58:54 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Mar 2007 11:58:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Hat off: tcpsecure mitigations Date: Fri, 16 Mar 2007 11:58:50 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5803050080@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <20070316011822.GG12512@hut.isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Hat off: tcpsecure mitigations Thread-Index: AcdnaUeRVSsxkny7RGilIq/wnlVZ9AAchy8Q From: "Anantha Ramaiah \(ananth\)" To: "Ted Faber" , X-OriginalArrivalTime: 16 Mar 2007 18:58:51.0052 (UTC) FILETIME=[22BC96C0:01C767FD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4463; t=1174071534; x=1174935534; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20\(ananth\)=22=20 |Subject:=20RE=3A=20[tcpm]=20Hat=20off=3A=20tcpsecure=20mitigations |Sender:=20; bh=mXc5RiKtuCvUeccQ7pMw50AO7+z0zJitW5/tqV4RSj8=; b=bVr9rVDoDQdLRqmmE5BKlPX7L3n5nxnC6kHMHpEZpxJc1NZITIFEZlNcJNsnmBKLDq0SRRqz WEEWGDO6Ubl3ctTHZv2frPWlWAl5mOWHyC4T8YBHNMZ3o/r8uDFC751z; Authentication-Results: sj-dkim-7; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Ted, Thanks for the note. Comments inline.. > Hi. >=20 > I recently did a read-through of the tcpsecure draft to see=20 > how close it was to a WGLC, and came across an issue I'd like=20 > to put before the group. I'm doing this without a chair hat=20 > on, just as a private individual. >=20 > Looking over the 3 mitigations proposed in that draft, I=20 > think that the first two, the SYN and RST mitigations, are=20 > clean and elegant. I'm perfectly happy to publish a draft=20 > saying that TCP implementations SHOULD implement them. I would like to add more context to the discussion. Lets start from here.. All these mitigations were tagged with a MUST clause until recently, but since you had raised a valid point to say something like "we don't want the TCP stacks to become all of a sudden non-compliant after this goes out as an RFC", we changed all the mitigations to SHOULD. >=20 > The data injection mitigation doesn't have the same cleanness=20 > to it, and I'd like to make that mitigation a MAY. - By making it a SHOULD we have already given leeway to the implementers. Implementere who care for security/robustness of their systems would treat it as important and will use it. =20 >=20 > Here's my thinking: > =09 > The SYN and RST changes are simple and clear and require minimal > new code to implement. A host simply accepts the segment if its > SEG.SEQ is the same as RCV.NXT and ACKs it otherwise. No extra > space in the control block, minimal places to go astray and a > significant improvement in the protection afforded against > malicious and misbehaving stacks - the spoofable range of seqnos > drops from the size of the receive window to 1. >=20 > The data mitigation is more complex - there's an extra state > variable defined to check the ACK value of each=20 > received segment - > and there's some room to go astray in the implementation of that > state variable. I don't begrudge an implementation the extra > word in the data structure, but it's an indication that this > mitigation doesn't have the same simplicity as the RST and SYN > mitigations. Well, not all solutions to all problems are necessarily simple and the degree of complexity varies. Well, if I read your comments more seriously, one can imagine there would mostly be MAYs in many RFC's since the solution isn't simple enough. :-) In the current case it is about having one variable, namely MAX.SNDWND. Just to give an example on how simple and effective this is : Implementations can chose to hardcode this value to 65535 for a connection ( assuming no window scaling in place) The ACK check would simply become : (SND.UNA - 65535) <=3D SEG.ACK <=3D SND.NXT). =20 >=20 > Furthermore, the mitigation is less effective. If there is > significant bi-directional traffic on the connection there will > be basically no mitigation. My understanding is that the > connections most vulnerable to these attacks are long-standing > connections that have large windows - exactly the ones that will > receive the least effect from this mitigation. The mitigation is direction independent by the virtue of the fact the way ACK checking is, as existing, today. Only thing is we are putting a sensible limit on the acceptable ACK value rather than accept anything and everything. if you are saying the above to mean " the attack would be difficult to perform in case of bi-directional", maybe. As a generalisation, if the TCP connection is idle, any attacks described in the document is easier to perform compared to uni-directional compared to bi-directional.... Another important thing is this mitigation also raises the bar on malicious (bad) FIN's that can be injected [ the Ack checking helps] During the initial stages (about couple of years back ) when this was discussed somebody in the list someone did ask about the "FIN attacks" and how this mitigation can come handy in dealing with the same. > I've talked to the authors about this, so I'm not trying to=20 > surprise them while they're on the plane. I'm sure they'll=20 > jump in and discuss. > I'm hoping to get a discussion going here and possibly in=20 > Prague about how strongly we want to recommend the data=20 > mitigation. I believe their presentation will raise some of=20 > these points and their responses. Sure, sounds like a plan.=20 -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Mar 18 04:54:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSr7t-0005c7-I3; Sun, 18 Mar 2007 04:52:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSr7s-0005c2-Sf for tcpm@ietf.org; Sun, 18 Mar 2007 04:52:28 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSr7r-0005Ny-Ay for tcpm@ietf.org; Sun, 18 Mar 2007 04:52:28 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id A3EE1F0C44B; Sun, 18 Mar 2007 05:52:26 -0300 (ART) Received: from fgont.gont.com.ar (113-165-231-201.fibertel.com.ar [201.231.165.113]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.12.11) with ESMTP id l2I8q0ZF028138; Sun, 18 Mar 2007 05:52:12 -0300 Message-Id: <7.0.1.0.0.20070318041131.07eb4868@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 18 Mar 2007 05:00:37 -0300 To: Arifumi Matsumoto , tcpm@ietf.org From: Fernando Gont Subject: Re: [tcpm] ICMPv6 Error Handling at TCP draft-fujisaki-tcpm-icmpv6-reaction-00.txt In-Reply-To: <45F0E432.5040401@nttv6.net> References: <45F0E432.5040401@nttv6.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Sun, 18 Mar 2007 05:52:19 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 01:36 09/03/2007, Arifumi Matsumoto wrote: >we've posted an I-D that defines TCP reactions(soft/hard) to ICMPv6 >error messages. >This document translates ICMPv4 codes and into ICMPv6 codes in order to define >soft error / hard error classification for ICMPv6 codes. We have been talking about ICMP errors on this list for about three years now. The direction the industry has taken is to get away from tying a specific reaction (basically "abort the connection" or "do nothing") to each error message type/code, regardless of e.g., connection state. By translating ICMPv4 codes into ICMPv6 codes you'd basically be moving ICMPv6 a number of years back in time. The ICMPv6 spec already includes text that gives you freedom in how to respond to ICMPv6 error messages (e.g., abort a connection in a non-synchronized state in response to an ICMP error message, or not abort the connection in response to an error message when the connection is in any of the synchronized states, or whatever). This freedom already lets you implement the soft errors behaviour if you want to address the problem of long delays between connection establishment attempts in v6 scenarios, as described in the soft errors draft of this WG. If you translate the ICMPv4 codes into ICMPv6 codes, then: * For those scenarios in which the lack of v6 connectivity is signaled by a so-called "soft error", you won't have solved anything (as RFC1122 tells you not to abort the connection attempt). * For conenctions in the synchronized states, the hard errors would open the door to connection-reset attacks, as discussed in the icmp attacks draft of this WG. Implementations have been moving away from the strict type/code -> {hard, soft} error classification since more than ten years ago. And I honestly think it would be quite a challenge to get the industry implement an ICMP error processing policy it has already decided not to implement for ICMPv4. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Mar 18 10:17:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSw8T-0005UD-Jw; Sun, 18 Mar 2007 10:13:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSw8R-0005OK-HD for tcpm@ietf.org; Sun, 18 Mar 2007 10:13:23 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSw8P-0007Vd-4h for tcpm@ietf.org; Sun, 18 Mar 2007 10:13:23 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 9B22BF0C410 for ; Sun, 18 Mar 2007 11:13:21 -0300 (ART) Received: from fgont.gont.com.ar (113-165-231-201.fibertel.com.ar [201.231.165.113]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id l2IECuTg004209 for ; Sun, 18 Mar 2007 11:13:07 -0300 Message-Id: <200703181413.l2IECuTg004209@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 18 Mar 2007 11:11:52 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Sun, 18 Mar 2007 11:13:17 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [tcpm] Revision of the soft errors draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Folks, I have submitted a revision of the soft errors draft, which hopefully addresses the latest feedback sent (off-list) by Ted Faber and Gorry Fairhurst. The draft will show up in the usual places soon. In the mean time, it is available from: http://www.gont.com.ar/drafts/tcp-soft-errors/draft-ietf-tcpm-tcp-soft-errors-04.txt . You can find the same doc in HTML and PDF format, and the previous versions of the doc, at http://www.gont.com.ar/drafts/tcp-soft-errors/ . Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Mar 19 08:37:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTH6N-0005l7-NW; Mon, 19 Mar 2007 08:36:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTH6M-0005kx-AX for tcpm@ietf.org; Mon, 19 Mar 2007 08:36:38 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTH6K-0003pI-0E for tcpm@ietf.org; Mon, 19 Mar 2007 08:36:38 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l2JCaTYf001330; Mon, 19 Mar 2007 05:36:30 -0700 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 53A13900A92; Mon, 19 Mar 2007 08:36:24 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 84A481AE4AA; Mon, 19 Mar 2007 08:36:16 -0400 (EDT) To: Fernando Gont From: Mark Allman Subject: Re: [tcpm] Revision of the soft errors draft In-Reply-To: <200703181413.l2IECuTg004209@venus.xmundo.net> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Back in the USSR MIME-Version: 1.0 Date: Mon, 19 Mar 2007 08:36:16 -0400 Message-Id: <20070319123616.84A481AE4AA@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0801561014==" Errors-To: tcpm-bounces@ietf.org --===============0801561014== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I know everyone is busy this week, but just a reminder that our plan is still to WGLC this on 4/2 unless issues arise between now and then. I encourage folks to take a final pass at this document. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFF/oPAWyrrWs4yIs4RAqR8AJ0a/B2PAEi52ZdWnpw6zuE97FylIwCeOK0s MdQjzV4i0pwZRXWwmsiY3bM= =aCX2 -----END PGP SIGNATURE----- --=_bOundary-- --===============0801561014== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0801561014==-- From tcpm-bounces@ietf.org Mon Mar 19 14:35:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTMgx-0004rk-Mc; Mon, 19 Mar 2007 14:34:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTMgv-0004oQ-4R for tcpm@ietf.org; Mon, 19 Mar 2007 14:34:45 -0400 Received: from mail.syce.net ([192.16.178.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTMgc-0004dl-Fd for tcpm@ietf.org; Mon, 19 Mar 2007 14:34:45 -0400 Received: from localhost (localhost.syce.net [IPv6:::1]) by mail.syce.net (8.13.1/8.13.1) with ESMTP/inet6 id l2JIY1g9030904; Tue, 20 Mar 2007 03:34:02 +0900 (JST) (envelope-from fujisaki@syce.net) Date: Tue, 20 Mar 2007 03:33:45 +0900 (JST) Message-Id: <20070320.033345.189731342.fujisaki@syce.net> To: fernando@gont.com.ar Subject: Re: [tcpm] ICMPv6 Error Handling at TCP draft-fujisaki-tcpm-icmpv6-reaction-00.txt From: (Tomohiro -INSTALLER- =?iso-2022-jp?B?RnVqaXNha2kvGyRCRiM6ahsoQiAbJEJDUjkoGyhC?=) In-Reply-To: <7.0.1.0.0.20070318041131.07eb4868@gont.com.ar> References: <45F0E432.5040401@nttv6.net> <7.0.1.0.0.20070318041131.07eb4868@gont.com.ar> X-Mailer: Mew version 5.2 on XEmacs 21.4.20 (Double Solitaire) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Hi Fernando, Thank you very much for your detailed explanation. | By translating ICMPv4 codes into ICMPv6 codes you'd basically be | moving ICMPv6 a number of years back in time. The ICMPv6 spec already | includes text that gives you freedom in how to respond to ICMPv6 | error messages (e.g., abort a connection in a non-synchronized state | in response to an ICMP error message, or not abort the connection in | response to an error message when the connection is in any of the | synchronized states, or whatever). This freedom already lets you | implement the soft errors behaviour if you want to address the | problem of long delays between connection establishment attempts in | v6 scenarios, as described in the soft errors draft of this WG. We know this text is in ICMPv6 spec, however, as you know, few IPv6 implementations respond to ICMP error messages currently. (The 9th slide of below material include the ICMPv6 reaction of current nodes.) http://www.nttv6.net/~fujisaki/fallback.pdf We asked some vendors to implement as you suggested, however, they said they did not because there were no clear definition for that. | If you translate the ICMPv4 codes into ICMPv6 codes, then: | | * For those scenarios in which the lack of v6 connectivity is | signaled by a so-called "soft error", you won't have solved anything | (as RFC1122 tells you not to abort the connection attempt). Yes, but in the case that administrators know that, it is possible to signal some type of so-called "hard error" ICMP, such as admin prohibit. This can be used in the case that a site uses ULA in their network. | Implementations have been moving away from the strict type/code -> | {hard, soft} error classification since more than ten years ago. And | I honestly think it would be quite a challenge to get the industry | implement an ICMP error processing policy it has already decided not | to implement for ICMPv4. It looks that some recent OSes still implement ICMPv4 reaction. We think we need clear definition of ICMPv6 reaction to ask developers to implement ICMPv6 error processing. -- Tomohiro Fujisaki _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Mar 19 15:37:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTNeV-0008M6-9m; Mon, 19 Mar 2007 15:36:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTNeU-0008Lv-1E for tcpm@ietf.org; Mon, 19 Mar 2007 15:36:18 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTNeO-00029P-6C for tcpm@ietf.org; Mon, 19 Mar 2007 15:36:18 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 06C49F0C46C; Mon, 19 Mar 2007 16:35:44 -0300 (ART) Received: from fgont.gont.com.ar (113-165-231-201.fibertel.com.ar [201.231.165.113]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id l2JJZL2i013753; Mon, 19 Mar 2007 16:35:37 -0300 Message-Id: <200703191935.l2JJZL2i013753@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 19 Mar 2007 16:35:05 -0300 To: (Tomohiro -INSTALLER- =?iso-2022-jp?B?RnVqaXNha2kvGyRCRiM6ahsoQiAbJEJDUjkoGyhC?=) From: Fernando Gont Subject: Re: [tcpm] ICMPv6 Error Handling at TCP draft-fujisaki-tcpm-icmpv6-reaction-00.txt In-Reply-To: <20070320.033345.189731342.fujisaki@syce.net> References: <45F0E432.5040401@nttv6.net> <7.0.1.0.0.20070318041131.07eb4868@gont.com.ar> <20070320.033345.189731342.fujisaki@syce.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Mon, 19 Mar 2007 16:35:43 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 03:33 p.m. 19/03/2007, Tomohiro -INSTALLER- wrote: >We asked some vendors to implement as you suggested, however, they >said they did not because there were no clear definition for that. Well, I think the soft errors draft provides a clear explanation of the problem, and describes very clearly how the alternative handling of ICMP soft errors can help in those scenarios. We have been talking on this list about this stuff for three years now. IMO, if they decide not to implement the described change, it's because they think that the solution doesn't fit their needs, or because they simply don't want to. (IIRC, from some talk at San Diego, one vendor that said they didn't implement this because "it is not a standard" was Microsoft. Yet they were just about (or actually did?) to include alternative congestion control algorithms for TCP in Vista that were not even documented by the IETF. So....) > | If you translate the ICMPv4 codes into ICMPv6 codes, then: > | > | * For those scenarios in which the lack of v6 connectivity is > | signaled by a so-called "soft error", you won't have solved anything > | (as RFC1122 tells you not to abort the connection attempt). > >Yes, but in the case that administrators know that, it is possible to >signal some type of so-called "hard error" ICMP, such as admin >prohibit. This can be used in the case that a site uses ULA in their >network. So you are saying that we need a better definition of ICMPv6 codes, and yet the first thing you plan to do is to forget that definition, and use some other error code (that was meant for some other thing) to get the result you expect? > | Implementations have been moving away from the strict type/code -> > | {hard, soft} error classification since more than ten years ago. And > | I honestly think it would be quite a challenge to get the industry > | implement an ICMP error processing policy it has already decided not > | to implement for ICMPv4. > >It looks that some recent OSes still implement ICMPv4 reaction. I don't know of any implementation out there that implements the ICMP "hard error" reaction specified in RFC1122. As a matter of fact, this has been the case for more than ten years. And in the last few years, those implementations that were aborting connections in response to the so-called ICMP hard errors changed their reaction to the one described in the ICMP attacks draft. If you mean that some recent OSes still implement RFC1122's reaction to *soft* errors, that may be the case. But it's a completely different thing from translating ICMPv6 codes into ICMPv4 codes. Mapping ICMPv6 codes into ICMPv4 codes is moving ICMPv6 eighteen years backwards, and is certainly a bad idea. As I said in my other e-mail: 1) The scenarios you are trying to address usually lead to *soft* errors. As a result, the connection will not be aborted, and you will not have solved the problem you are trying to solve. 2) Defining ICMP messages that indicate hard errors (as in RFC 1122) would open the door to connection reset attacks against TCP. I can assure nobody is going to do this. >We think we need clear definition of ICMPv6 reaction to ask developers >to implement ICMPv6 error processing. A standards-track document does not alleviate the need for a competent developer that is able to understand the problem he is facing, and analyze the possible solutions to it. I think the soft errors draft describes the problem very clearly, and describes an alternative handling for ICMP error messages that can help to overcome that problem. In practice, if the developer in question has any clue, he will implement the decribed handling (or not) based on the technical properties, rather on whether there is RFC2119 wording in it. In the last couple of years, developers from NetBSD, FreeBSD, OpenBSD and Linux (at least) have worked on ICMP implementing some of the stuff in the ICMP attacks draft. I can guarantee that if you contact any of their developers, they will implement the soft errors behavior if they think it makes sense (that is, they will analyze what's in the document, and implement it if they think it makes sense and solves some problem they are having). Cisco has done it, too. If there's any vendor that will simply not implement something only because he does not see the words "should" or "must" in caps, I think it's a problem at some layer higher than the 7th... which I really doubt the IETF could fix. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Mar 19 16:00:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTO1H-0004Nk-VN; Mon, 19 Mar 2007 15:59:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTO1G-0004Ne-PX for tcpm@ietf.org; Mon, 19 Mar 2007 15:59:50 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTO0v-0007GK-1Q for tcpm@ietf.org; Mon, 19 Mar 2007 15:59:50 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2JJweON005464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 19 Mar 2007 12:58:41 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.8/8.13.8/Submit) id l2JJwekZ064807 for tcpm@ietf.org; Mon, 19 Mar 2007 12:58:40 -0700 (PDT) (envelope-from faber) Date: Mon, 19 Mar 2007 12:58:40 -0700 From: Ted Faber To: tcpm@ietf.org Message-ID: <20070319195840.GP25608@hut.isi.edu> Mime-Version: 1.0 User-Agent: Mutt/1.4.2.2i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [tcpm] Current agenda and slides X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1225783421==" Errors-To: tcpm-bounces@ietf.org --===============1225783421== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FRaepaAnLTQkJ4tS" Content-Disposition: inline --FRaepaAnLTQkJ4tS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The current copy of the agenda and most recent copies of the slides are available at http://tools.ietf.org/wg/tcpm/agenda The most recent info I have will continue to be there. --=20 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 --FRaepaAnLTQkJ4tS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (FreeBSD) iD8DBQFF/utwaUz3f+Zf+XsRAl1CAJ9LuGDpBXb20UscUbqFGtycCfsUiwCeLvMR 4wmux9UfgQ/MVEK1G8Kcioo= =AARG -----END PGP SIGNATURE----- --FRaepaAnLTQkJ4tS-- --===============1225783421== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1225783421==-- From tcpm-bounces@ietf.org Mon Mar 19 17:04:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTP0k-0000wf-Dk; Mon, 19 Mar 2007 17:03:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTP0j-0000wU-W5 for tcpm@ietf.org; Mon, 19 Mar 2007 17:03:21 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTP0h-0007s7-GZ for tcpm@ietf.org; Mon, 19 Mar 2007 17:03:21 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2JL0c06022941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Mar 2007 14:00:38 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.8/8.13.8/Submit) id l2JL0cg3002294; Mon, 19 Mar 2007 14:00:38 -0700 (PDT) (envelope-from faber) Date: Mon, 19 Mar 2007 14:00:38 -0700 From: Ted Faber To: "Anantha Ramaiah (ananth)" Subject: Re: [tcpm] Hat off: tcpsecure mitigations Message-ID: <20070319210038.GB1503@hut.isi.edu> References: <20070316011822.GG12512@hut.isi.edu> <0C53DCFB700D144284A584F54711EC5803050080@xmb-sjc-21c.amer.cisco.com> Mime-Version: 1.0 In-Reply-To: <0C53DCFB700D144284A584F54711EC5803050080@xmb-sjc-21c.amer.cisco.com> User-Agent: Mutt/1.4.2.2i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1210566541==" Errors-To: tcpm-bounces@ietf.org --===============1210566541== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3lcZGd9BuhuYXNfi" Content-Disposition: inline --3lcZGd9BuhuYXNfi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 16, 2007 at 11:58:50AM -0700, Anantha Ramaiah (ananth) wrote: > > The data injection mitigation doesn't have the same cleanness=20 > > to it, and I'd like to make that mitigation a MAY. >=20 > - By making it a SHOULD we have already given leeway to the > implementers. Implementere who care for security/robustness of their > systems would treat it as important and will use it. =20 SHOULD implies that an implementor should have a good reason not to do something. I think the data mitigation is enough extra work for little enough extra protection that an implementor should implement it if they feel it's necessary - they MAY implement it if they choose. I realize I may be alone in this belief and that's fine. >=20 > >=20 > > Here's my thinking: > > =09 > > The SYN and RST changes are simple and clear and require minimal > > new code to implement. A host simply accepts the segment if its > > SEG.SEQ is the same as RCV.NXT and ACKs it otherwise. No extra > > space in the control block, minimal places to go astray and a > > significant improvement in the protection afforded against > > malicious and misbehaving stacks - the spoofable range of seqnos > > drops from the size of the receive window to 1. > >=20 > > The data mitigation is more complex - there's an extra state > > variable defined to check the ACK value of each=20 > > received segment - > > and there's some room to go astray in the implementation of that > > state variable. I don't begrudge an implementation the extra > > word in the data structure, but it's an indication that this > > mitigation doesn't have the same simplicity as the RST and SYN > > mitigations. >=20 > Well, not all solutions to all problems are necessarily simple and the > degree of complexity varies. Well, if I read your comments more > seriously, one can imagine there would mostly be MAYs in many RFC's > since the solution isn't simple enough. :-) Ha ha. > In the current case it is about having one variable, namely MAX.SNDWND. > Just to give an example on how simple and effective this is : > Implementations can chose to hardcode this value to 65535 for a > connection ( assuming no window scaling in place) The ACK check would > simply become : >=20 > (SND.UNA - 65535) <=3D SEG.ACK <=3D SND.NXT).=20 We talked a little about this off-line, but I'm not sure where that 64K number comes from. The draft talks about this check already being part of the TCP spec in Section 5.1, or I'm misunderstanding that section, but I don't see any basis for that. Skimming the FreeBSD code (because it's right here) I don't see any such check. I do realize that there ought to be a lower bound on what an acceptable ACK is (because the ACK space wraps and you'll seventually come around to SND.NXT from the bottom) but I don't see this number in the specs. Is the existing specification actually clear on this? Are you modifying an existing limit or introducing a new check? >=20 > >=20 > > Furthermore, the mitigation is less effective. If there is > > significant bi-directional traffic on the connection there will > > be basically no mitigation. My understanding is that the > > connections most vulnerable to these attacks are long-standing > > connections that have large windows - exactly the ones that will > > receive the least effect from this mitigation. >=20 > The mitigation is direction independent by the virtue of the fact the > way ACK checking is, as existing, today. Only thing is we are putting a > sensible limit on the acceptable ACK value rather than accept anything > and everything. if you are saying the above to mean " the attack would > be difficult to perform in case of bi-directional", maybe. As a > generalisation, if the TCP connection is idle, any attacks described in > the document is easier to perform compared to uni-directional compared > to bi-directional.... If you put the mitigation in place, an endpoint that is primarily going to send traffic can set its receive window to be very small from the initial SYN - 1 byte to allow the FIN - and this mitigation will be its most effective. The set of acceptable ACK values goes down from whatever the default is to 1 acceptable ACK value. Unidirectional traffic is your best reasonable case in the sense of greatest protection. (Optimal would be both sides with a 1 byte window, but that's obviously pathological.) Conversely, bidirectional traffic with sizable windows is the worst case for the mitigation, because both endpoints will advertise large windows at some point (and you use the maximum advertised window in your calculations) so your mitigation will provide the least protection in the sense that the largest number of spoofed ACK values will pass the test. >=20 > Another important thing is this mitigation also raises the bar on > malicious (bad) FIN's that can be injected [ the Ack checking helps] > During the initial stages (about couple of years back ) when this was > discussed somebody in the list someone did ask about the "FIN attacks" > and how this mitigation can come handy in dealing with the same. I'd add text to the draft to that effect. --=20 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 --3lcZGd9BuhuYXNfi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (FreeBSD) iD8DBQFF/vn2aUz3f+Zf+XsRAq1fAKCrCpVSLfH27jm0Hq/aBEqv2+29+gCdFzwu wLbyVzqaRKsQvH8RaSLyQXw= =fBl/ -----END PGP SIGNATURE----- --3lcZGd9BuhuYXNfi-- --===============1210566541== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1210566541==-- From tcpm-bounces@ietf.org Mon Mar 19 23:33:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTV3S-00012G-Hw; Mon, 19 Mar 2007 23:30:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTV3R-0000ze-AR for tcpm@ietf.org; Mon, 19 Mar 2007 23:30:33 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTV3P-0004Ie-Ux for tcpm@ietf.org; Mon, 19 Mar 2007 23:30:33 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l2K3UQdh016402; Mon, 19 Mar 2007 20:30:27 -0700 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 7FE1C906F98; Mon, 19 Mar 2007 23:30:21 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 996DA1B05FB; Mon, 19 Mar 2007 23:30:11 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Subject: Re: [tcpm] Current agenda and slides In-Reply-To: <20070319195840.GP25608@hut.isi.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Back in the USSR MIME-Version: 1.0 Date: Mon, 19 Mar 2007 23:30:11 -0400 Message-Id: <20070320033011.996DA1B05FB@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Ted Faber X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0730880649==" Errors-To: tcpm-bounces@ietf.org --===============0730880649== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > http://tools.ietf.org/wg/tcpm/agenda In addition, a couple of other pointers that folks might find useful... (1) Instructions for IETF jabber rooms: http://www3.ietf.org/meetings/text_conf.html (2) Instructions for receiving streaming audio of IETF meetings: http://videolab.uoregon.edu/events/ietf/ allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFF/1VDWyrrWs4yIs4RAjzrAKCdx118EtoH+6/Uqfih9talCD9FAQCeJOmI s2r4IxDFb6u2X1DYHvTgfjY= =GHyb -----END PGP SIGNATURE----- --=_bOundary-- --===============0730880649== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0730880649==-- From tcpm-bounces@ietf.org Tue Mar 20 01:15:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTWg0-00050u-Dw; Tue, 20 Mar 2007 01:14:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTWfx-0004zs-MI for tcpm@ietf.org; Tue, 20 Mar 2007 01:14:25 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTWfv-00066Y-Rn for tcpm@ietf.org; Tue, 20 Mar 2007 01:14:25 -0400 Received: from [127.0.0.1] (c2-vpn03.isi.edu [128.9.176.212]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l2K5EA6E006834; Mon, 19 Mar 2007 22:14:12 -0700 (PDT) Message-ID: <45FF6D98.8090405@isi.edu> Date: Mon, 19 Mar 2007 22:14:00 -0700 From: Joe Touch User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Ted Faber Subject: Re: [tcpm] Hat off: tcpsecure mitigations References: <20070316011822.GG12512@hut.isi.edu> <0C53DCFB700D144284A584F54711EC5803050080@xmb-sjc-21c.amer.cisco.com> <20070319210038.GB1503@hut.isi.edu> In-Reply-To: <20070319210038.GB1503@hut.isi.edu> X-Enigmail-Version: 0.94.1.2.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0359930079==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0359930079== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0610469602187959DC5E6791" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0610469602187959DC5E6791 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ted Faber wrote: > On Fri, Mar 16, 2007 at 11:58:50AM -0700, Anantha Ramaiah (ananth) wrot= e: >>> The data injection mitigation doesn't have the same cleanness=20 >>> to it, and I'd like to make that mitigation a MAY. >> - By making it a SHOULD we have already given leeway to the >> implementers. Implementere who care for security/robustness of their >> systems would treat it as important and will use it. =20 >=20 > SHOULD implies that an implementor should have a good reason not to do > something.=20 I agree with MAY for these recommendations as-is. SHOULD, in many cases (not just this) needs to come with the conditions, as noted above. In this particular case: routers and proxy systems SHOULD implement these mods for their host-based TCP (orgination/termination) all other hosts MAY implement them > I think the data mitigation is enough extra work for little > enough extra protection that an implementor should implement it if they= > feel it's necessary - they MAY implement it if they choose. I realize = I > may be alone in this belief and that's fine. I agree with MAY for those. That's also why I think 'all other hosts' (sans routers/proxy systems) should have a MAY too; there's far too little additional protection for typical hosts, and we really don't need to make the required constellation of TCP more complex than absolutely necessary. However, I think this doc also needs a strong "if you're really concerned about protection, or have seen repeated attempts at attacks, you really ought to use real security" too. (sorry if it does already say that; I haven't gone through it in detail).= Joe --------------enig0610469602187959DC5E6791 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.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF/22YE5f5cImnZrsRAqqUAJ9oWA+x6PNTz9zTqLCkl/6/tPD8qACgnBBS 4HhZHovkDe6OwJ8PAU/DLoQ= =qvEp -----END PGP SIGNATURE----- --------------enig0610469602187959DC5E6791-- --===============0359930079== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0359930079==-- From tcpm-bounces@ietf.org Tue Mar 20 09:06:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTe0m-000335-NN; Tue, 20 Mar 2007 09:04:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTe0l-00032M-Qg for tcpm@ietf.org; Tue, 20 Mar 2007 09:04:23 -0400 Received: from nf-out-0910.google.com ([64.233.182.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTe0a-00072M-SR for tcpm@ietf.org; Tue, 20 Mar 2007 09:04:23 -0400 Received: by nf-out-0910.google.com with SMTP id l36so336330nfa for ; Tue, 20 Mar 2007 06:04:00 -0700 (PDT) Received: by 10.78.200.3 with SMTP id x3mr3068591huf.1174395839688; Tue, 20 Mar 2007 06:03:59 -0700 (PDT) Received: by 10.78.26.20 with HTTP; Tue, 20 Mar 2007 06:03:59 -0700 (PDT) Message-ID: <7b1e7a950703200603x5ca6cacbxe049d04879aae79c@mail.gmail.com> Date: Tue, 20 Mar 2007 22:03:59 +0900 From: "Arifumi Matsumoto" To: "Fernando Gont" Subject: Re: [tcpm] ICMPv6 Error Handling at TCP draft-fujisaki-tcpm-icmpv6-reaction-00.txt In-Reply-To: <200703191935.l2JJZL2i013753@venus.xmundo.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45F0E432.5040401@nttv6.net> <7.0.1.0.0.20070318041131.07eb4868@gont.com.ar> <20070320.033345.189731342.fujisaki@syce.net> <200703191935.l2JJZL2i013753@venus.xmundo.net> X-Google-Sender-Auth: 1a47f18ab1278427 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Hi Fernando. Let me comment as a co-auther. 2007/3/20, Fernando Gont : > At 03:33 p.m. 19/03/2007, Tomohiro -INSTALLER- wrote: > > >We asked some vendors to implement as you suggested, however, they > >said they did not because there were no clear definition for that. > > Well, I think the soft errors draft provides a clear explanation of > the problem, and describes very clearly how the alternative handling > of ICMP soft errors can help in those scenarios. We have been talking > on this list about this stuff for three years now. soft-error draft explains which ICMP error codes can map to which ICMPv6 error code. However, it isn't for every existing ICMPv6 error codes. So, I cannot determine any other existing ICMPv6 error code falls into soft or hard. The "Requirements for Internet Hosts -- Communication Layers" RFC [RFC1122] states, in section 4.2.3.9., that the ICMP "Destination Unreachable" messages that indicate soft errors are ICMP codes 0 (network unreachable), 1 (host unreachable), and 5 (source route failed). Even though ICMPv6 didn't exist when [RFC1122] was written, one could extrapolate the concept of soft errors to ICMPv6 Type 1 Codes 0 (no route to destination) and 3 (address unreachable). If you say you provides a clear explanation, please write like the following: no route to destination : soft address unreachable : soft port unreachable : hard ... > IMO, if they decide not to implement the described change, it's > because they think that the solution doesn't fit their needs, or > because they simply don't want to. > > (IIRC, from some talk at San Diego, one vendor that said they didn't > implement this because "it is not a standard" was Microsoft. Yet they > were just about (or actually did?) to include alternative congestion > control algorithms for TCP in Vista that were not even documented by > the IETF. So....) Please let me know how they handle ICMP(v6) errors in such a congestion control algorithm. > > | If you translate the ICMPv4 codes into ICMPv6 codes, then: > > | > > | * For those scenarios in which the lack of v6 connectivity is > > | signaled by a so-called "soft error", you won't have solved anything > > | (as RFC1122 tells you not to abort the connection attempt). > > > >Yes, but in the case that administrators know that, it is possible to > >signal some type of so-called "hard error" ICMP, such as admin > >prohibit. This can be used in the case that a site uses ULA in their > >network. > > So you are saying that we need a better definition of ICMPv6 codes, > and yet the first thing you plan to do is to forget that definition, > and use some other error code (that was meant for some other thing) > to get the result you expect? I cannot get how you lead to that understanding. What he said was "if admin prohibit is defined as a hard error, TCP session in *3-way handshake state* can be aborted if the host receives admin prohibit". We don't care about TCP session in *establieshed state*. IMO, as there is potential threat here, hard error should not abort established TCP session. > > | Implementations have been moving away from the strict type/code -> > > | {hard, soft} error classification since more than ten years ago. And > > | I honestly think it would be quite a challenge to get the industry > > | implement an ICMP error processing policy it has already decided not > > | to implement for ICMPv4. > > > >It looks that some recent OSes still implement ICMPv4 reaction. > > I don't know of any implementation out there that implements the ICMP > "hard error" reaction specified in RFC1122. As a matter of fact, this > has been the case for more than ten years. And in the last few years, > those implementations that were aborting connections in response to > the so-called ICMP hard errors changed their reaction to the one > described in the ICMP attacks draft. About ICMPv4 hard error implementation, at least FreeBSD and MacOSX implements RFC1122 reaction. i.e. For port unreachable message, TCP connections in 3-way handshake state is dropped. For established state connection, connection is not dropped by port unreachable. This is owing to your soft-error draft. So, soft-error draft proposes two things, one is for handshake state and the other is for established state. The first one isn't implemented while the second one is implemented. What we care is rather about the first one. > If you mean that some recent OSes still implement RFC1122's reaction > to *soft* errors, that may be the case. But it's a completely > different thing from translating ICMPv6 codes into ICMPv4 codes. > Mapping ICMPv6 codes into ICMPv4 codes is moving ICMPv6 eighteen > years backwards, and is certainly a bad idea. As I said in my other e-mail: > > 1) The scenarios you are trying to address usually lead to *soft* > errors. As a result, the connection will not be aborted, and you will > not have solved the problem you are trying to solve. > 2) Defining ICMP messages that indicate hard errors (as in RFC 1122) > would open the door to connection reset attacks against TCP. I can > assure nobody is going to do this. What we want is to abort a connection when a host receives ICMPv6 hard error message if the connection is in 3-way handshake state. IMO, the problem is that we don't have definition of ICMPv6 hard error message, so no vendor can implement this behavior for ICMPv6 messages. For established connection, we agree that there is potential security hole when RFC1122 behavior is implemented. This problem should be covered by your soft-error draft. Our proposal have no suggestion about this problem. > In the last couple of years, developers from NetBSD, FreeBSD, OpenBSD > and Linux (at least) have worked on ICMP implementing some of the > stuff in the ICMP attacks draft. I can guarantee that if you contact > any of their developers, they will implement the soft errors behavior > if they think it makes sense (that is, they will analyze what's in > the document, and implement it if they think it makes sense and > solves some problem they are having). Cisco has done it, too. I examined source codes and confirmed that for established state, they already implemented what you said. What I care is about 3-way handshake state connection. -- a@arifumi.net _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Mar 20 09:51:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTejZ-0006oq-2Y; Tue, 20 Mar 2007 09:50:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTejX-0006ZO-Pf for tcpm@ietf.org; Tue, 20 Mar 2007 09:50:39 -0400 Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTej5-0001EI-KM for tcpm@ietf.org; Tue, 20 Mar 2007 09:50:35 -0400 Received: from I2KF03BV-UKBR.domain1.systemhost.net ([193.113.197.43]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 13:50:07 +0000 Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.65]) by I2KF03BV-UKBR.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Mar 2007 13:50:07 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Current agenda and slides Date: Tue, 20 Mar 2007 13:50:06 -0000 Message-ID: In-Reply-To: <20070320033011.996DA1B05FB@lawyers.icir.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Current agenda and slides Thread-Index: AcdqoNM8olEDZsrZQdW5dlqNj7EyUAAVX/iA From: To: , X-OriginalArrivalTime: 20 Mar 2007 13:50:07.0185 (UTC) FILETIME=[AB4DCC10:01C76AF6] X-Spam-Score: 0.2 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: faber@ISI.EDU X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Just noticed that my presentation seems to have been uploaded in the place of the presentation on TCP Response to Lower-Layer Connectivity-Change Indications. Toby -----Original Message----- From: Mark Allman [mailto:mallman@icir.org]=20 Sent: 20 March 2007 03:30 To: tcpm@ietf.org Cc: Ted Faber Subject: Re: [tcpm] Current agenda and slides=20 > http://tools.ietf.org/wg/tcpm/agenda In addition, a couple of other pointers that folks might find useful... (1) Instructions for IETF jabber rooms: http://www3.ietf.org/meetings/text_conf.html (2) Instructions for receiving streaming audio of IETF meetings: http://videolab.uoregon.edu/events/ietf/ allman _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Mar 20 10:50:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTfex-0006H9-VA; Tue, 20 Mar 2007 10:49:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTfew-0006Ch-TX for tcpm@ietf.org; Tue, 20 Mar 2007 10:49:58 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTfev-0007wB-AZ for tcpm@ietf.org; Tue, 20 Mar 2007 10:49:58 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 20 Mar 2007 07:49:57 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l2KEnu78014028; Tue, 20 Mar 2007 07:49:56 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2KEnuZX007947; Tue, 20 Mar 2007 14:49:56 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 07:49:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Hat off: tcpsecure mitigations Date: Tue, 20 Mar 2007 07:49:40 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC58030A8D7C@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <20070319210038.GB1503@hut.isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Hat off: tcpsecure mitigations Thread-Index: AcdqaghQ/aJHDkEWTaClh2zcVz7FYwAcwE8A From: "Anantha Ramaiah \(ananth\)" To: "Ted Faber" X-OriginalArrivalTime: 20 Mar 2007 14:49:43.0086 (UTC) FILETIME=[FEB4FCE0:01C76AFE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6758; t=1174402196; x=1175266196; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20\(ananth\)=22=20 |Subject:=20RE=3A=20[tcpm]=20Hat=20off=3A=20tcpsecure=20mitigations |Sender:=20; bh=zr6nQtbs+ey4euS1txWEud2ZePw7V+sN7okXqQrXTPs=; b=tg79VVUbySLSVg9qd/HAn2CVbR2jWxQEDeykldhQASp5LGN9aEGu54Wb+Y+5JiJqMFcpkYIy MoUX/IeAtMDnr8Y90CxeQ3tbgzuK4QLnDS80+X2IjpygOAJDjs7JSbSK; Authentication-Results: sj-dkim-4; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org =20 > >=20 > > - By making it a SHOULD we have already given leeway to the=20 > > implementers. Implementere who care for security/robustness=20 > of their=20 > > systems would treat it as important and will use it. >=20 > SHOULD implies that an implementor should have a good reason=20 > not to do something. I think the data mitigation is enough=20 "good reason", Let me try :-), if someone says "hey I don't care about extra robustness which offers additional protection in some cases than what it is existing today ", they can chose to not follow this recommendation or any other recommendations in the draft. My experience suggests that these days "people" are concerned about "extra robustness a.k.a security" in most of the cases. That said, YMMV. > extra work for little enough extra protection that an=20 "enough extra work" is a relative term. Data mitigation requires that :- #1 Keep an extra variable in the TCB in it's strictest form, in a slightly stricter version one can avoid this step and simply use a hardcoded value. So minimal OR no changes to the TCB. #2 The check for acceptability of ACK segments has been made more "stricter" Now the real extra work seems to be is #2.=20 > implementor should implement it if they feel it's necessary -=20 > they MAY implement it if they choose. I realize I may be=20 > alone in this belief and that's fine. Well these arguments are true for any mitigation irrespective of its complexity involved in implementation and that is my point. Just because one mitigation requires some extra state to be maintained doesn't necessarily mean it needs to fall under the "MAY" umbrella. >=20 > > In the current case it is about having one variable, namely=20 > MAX.SNDWND. > > Just to give an example on how simple and effective this is : > > Implementations can chose to hardcode this value to 65535 for a=20 > > connection ( assuming no window scaling in place) The ACK=20 > check would=20 > > simply become : > >=20 > > (SND.UNA - 65535) <=3D SEG.ACK <=3D SND.NXT).=20 >=20 > We talked a little about this off-line, but I'm not sure=20 > where that 64K number comes from. The draft talks about this=20 64K is a simplified example I gave in response to the "memory concerns" which you raised for maintaining the extra variable MAX.SNDWND in the TCB.=20 > check already being part of the TCP spec in Section 5.1, or=20 Pl see below. > I'm misunderstanding that section, but I don't see any basis=20 > for that. Skimming the FreeBSD code (because it's right=20 > here) I don't see any such check. I do realize that there=20 > ought to be a lower bound on what an acceptable ACK is=20 > (because the ACK space wraps and you'll seventually come=20 > around to SND.NXT from the > bottom) but I don't see this number in the specs. >=20 > Is the existing specification actually clear on this? Are=20 It is implicit. First let me quote this section : Sec 3.2: [sequence numbers] " It is essential to remember that the actual sequence number space is finite, though very large. This space ranges from 0 to 2**32 - 1. Since the space is finite, all arithmetic dealing with sequence numbers must be performed modulo 2**32. This unsigned arithmetic preserves the relationship of sequence numbers as they cycle from 2**32 - 1 to 0 again. There are some subtleties to computer modulo arithmetic, so great care should be taken in programming the comparison of such values. The symbol "=3D<" means "less than or = equal" (modulo 2**32)." ------------------------------- (1) Now the event processing section (3.9) says : If the ACK is a duplicate (SEG.ACK < SND.UNA), it can be ignored. If the ACK acks something not yet sent (SEG.ACK > SND.NXT) then send an ACK, drop the segment, and return. (This check holds good for ESTAB state onwards). So the RFC is *explicit* about the SEG.ACK < SND.UNA, just ignore it, now using modulo arithmetic (1) this means that any number in the seq space ie., (SND.UNA - 2^^31 -1) would pass this ACK test. This is what sec 5.1 in TCP secure mentions.=20 May be it is a good idea to elaborate this fact? > you modifying an existing limit or introducing a new check? Modiying the existing limit, pl see above. > > The mitigation is direction independent by the virtue of=20 > the fact the=20 > > way ACK checking is, as existing, today. Only thing is we=20 > are putting=20 > > a sensible limit on the acceptable ACK value rather than accept=20 > > anything and everything. if you are saying the above to mean " the=20 > > attack would be difficult to perform in case of bi-directional",=20 > > maybe. As a generalisation, if the TCP connection is idle,=20 > any attacks=20 > > described in the document is easier to perform compared to=20 > > uni-directional compared to bi-directional.... >=20 > If you put the mitigation in place, an endpoint that is=20 > primarily going to send traffic can set its receive window to=20 > be very small from the initial SYN - 1 byte to allow the FIN=20 > - and this mitigation will be its most effective. The set of=20 > acceptable ACK values goes down from whatever the default is=20 > to 1 acceptable ACK value. Unidirectional traffic is your=20 > best reasonable case in the sense of greatest protection. =20 > (Optimal would be both sides with a 1 byte window, but that's=20 > obviously pathological.) Well, agreed. >=20 > Conversely, bidirectional traffic with sizable windows is the=20 > worst case for the mitigation, because both endpoints will=20 > advertise large windows at some point (and you use the=20 > maximum advertised window in your > calculations) so your mitigation will provide the least=20 > protection in the sense that the largest number of spoofed=20 > ACK values will pass the test. Yep, but better than what it is today :-) See above. >=20 > >=20 > > Another important thing is this mitigation also raises the bar on=20 > > malicious (bad) FIN's that can be injected [ the Ack=20 > checking helps]=20 > > During the initial stages (about couple of years back )=20 > when this was=20 > > discussed somebody in the list someone did ask about the=20 > "FIN attacks" > > and how this mitigation can come handy in dealing with the same. >=20 > I'd add text to the draft to that effect. Sure will do. Actually thinking more about it is indeed important since this kind of raises the bar on FIN attacks. Will mention that. I had this in mind but somehow this missed the earlier versions but glad that we are able to correct that. Thanks, -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Mar 20 12:41:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HThNi-0005Wb-SC; Tue, 20 Mar 2007 12:40:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HThNh-0005Oy-CC for tcpm@ietf.org; Tue, 20 Mar 2007 12:40:17 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HThNH-0007Mr-4s for tcpm@ietf.org; Tue, 20 Mar 2007 12:40:17 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 20 Mar 2007 09:39:45 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2KGdjYn005544; Tue, 20 Mar 2007 09:39:45 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l2KGdjEi016217; Tue, 20 Mar 2007 16:39:45 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 09:39:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Hat off: tcpsecure mitigations Date: Tue, 20 Mar 2007 09:39:32 -0700 Message-ID: <13D1EAB852BE194C94773A947138483D0334AD40@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <45FF6D98.8090405@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Hat off: tcpsecure mitigations Thread-Index: Acdqry0A4T/1uW05RF2ESIV01I7VkQAXkzWA From: "Mitesh Dalal \(mdalal\)" To: "Joe Touch" , "Ted Faber" X-OriginalArrivalTime: 20 Mar 2007 16:39:45.0079 (UTC) FILETIME=[5DCD2C70:01C76B0E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2555; t=1174408785; x=1175272785; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mdalal@cisco.com; z=From:=20=22Mitesh=20Dalal=20\(mdalal\)=22=20 |Subject:=20RE=3A=20[tcpm]=20Hat=20off=3A=20tcpsecure=20mitigations |Sender:=20; bh=tXG7v1S7Xe8QP7iIkCef6rEUHTAPxSvD2fp/DwFoYRc=; b=pN7u24mnPapZOeQJe5K+c69gE2BM+btwdAaTPDW/mssPMdfN0Uprg8VlaX3ncrNxwMIJ7C7+ udmX9KFqJa3jLkGAUXBKZYWOaQ6XI3tiTGWJS8c0Y3ds8N6XVTBijuZG; Authentication-Results: sj-dkim-2; header.From=mdalal@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org please see inline. > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU]=20 > Sent: Monday, March 19, 2007 10:14 PM > To: Ted Faber > Cc: tcpm@ietf.org; Anantha Ramaiah (ananth) > Subject: Re: [tcpm] Hat off: tcpsecure mitigations >=20 >=20 >=20 > Ted Faber wrote: > > On Fri, Mar 16, 2007 at 11:58:50AM -0700, Anantha Ramaiah=20 > (ananth) wrote: > >>> The data injection mitigation doesn't have the same=20 > cleanness to it,=20 > >>> and I'd like to make that mitigation a MAY. > >> - By making it a SHOULD we have already given leeway to the=20 > >> implementers. Implementere who care for=20 > security/robustness of their=20 > >> systems would treat it as important and will use it. > >=20 > > SHOULD implies that an implementor should have a good=20 > reason not to do=20 > > something. >=20 > I agree with MAY for these recommendations as-is. >=20 > SHOULD, in many cases (not just this) needs to come with the=20 > conditions, as noted above. In this particular case: >=20 > routers and proxy systems SHOULD implement these mods for > their host-based TCP > (orgination/termination) >=20 > all other hosts MAY implement them >=20 I would tend to avoid recommendations based on system role to=20 determine MAY/SHOULD language. Since the weakness lies in the protocol we should make a recommendation one way or the other. If we are confident that this draft will help routers and proxies, leaving end hosts behind does not buy us much. (not that a SHOULD recommendation not implemented by endhost vendors will cause them to be out of spec) Mitesh > > I think the data mitigation is enough extra work for little enough=20 > > extra protection that an implementor should implement it if=20 > they feel=20 > > it's necessary - they MAY implement it if they choose. I realize I=20 > > may be alone in this belief and that's fine. >=20 > I agree with MAY for those. That's also why I think 'all other hosts' > (sans routers/proxy systems) should have a MAY too; there's=20 > far too little additional protection for typical hosts, and=20 > we really don't need to make the required constellation of=20 > TCP more complex than absolutely necessary. >=20 > However, I think this doc also needs a strong "if you're=20 > really concerned about protection, or have seen repeated=20 > attempts at attacks, you really ought to use real security" too. >=20 > (sorry if it does already say that; I haven't gone through it=20 > in detail). >=20 > Joe >=20 >=20 >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Mar 20 12:50:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HThXO-0004rX-Dp; Tue, 20 Mar 2007 12:50:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HThXN-0004rR-IJ for tcpm@ietf.org; Tue, 20 Mar 2007 12:50:17 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HThX6-000183-Rb for tcpm@ietf.org; Tue, 20 Mar 2007 12:50:17 -0400 Received: from [127.0.0.1] ([128.9.176.73]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l2KGnJ5t008475; Tue, 20 Mar 2007 09:49:22 -0700 (PDT) Message-ID: <46001081.90005@isi.edu> Date: Tue, 20 Mar 2007 09:49:05 -0700 From: Joe Touch User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: "Mitesh Dalal (mdalal)" Subject: Re: [tcpm] Hat off: tcpsecure mitigations References: <13D1EAB852BE194C94773A947138483D0334AD40@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <13D1EAB852BE194C94773A947138483D0334AD40@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.94.1.2.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: "Anantha Ramaiah \(ananth\)" , tcpm@ietf.org, Ted Faber X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1573859478==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1573859478== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF699EAF5CE88FB6DA586B65B" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF699EAF5CE88FB6DA586B65B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mitesh Dalal (mdalal) wrote: >> SHOULD, in many cases (not just this) needs to come with the=20 >> conditions, as noted above. In this particular case: >> >> routers and proxy systems SHOULD implement these mods for >> their host-based TCP >> (orgination/termination) >> >> all other hosts MAY implement them >=20 > I would tend to avoid recommendations based on system role to=20 > determine MAY/SHOULD language. Since the weakness lies in the > protocol we should make a recommendation one way or the other. The weakness lies in the combination of the protocol, the context of its use, and the fact that real authentication isn't being used. > If we are confident that this draft will help routers and > proxies, leaving end hosts behind does not buy us much. It allows them not to need unnecessarily complexity. > (not that a SHOULD recommendation not implemented by endhost > vendors will cause them to be out of spec) If that's really your position, then it needs to be stated. SHOULD, by itself, doesn't carry that sort of information. As Ted(hat-off) noted, SHOULD needs to indicate where it's allowed to be waived, and that indication needs to be explicit. By stating this as MUST for routers/proxy-systems and MAY for hosts, we'd be doing exactly what's needed for that to happen. Joe --------------enigF699EAF5CE88FB6DA586B65B 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.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGABCFE5f5cImnZrsRAgPTAKDplPFg874NUJtZycr7jlcGt5raPACfeGym gzcM7tIN0Mf8JGZqmRlxwhY= =VD8t -----END PGP SIGNATURE----- --------------enigF699EAF5CE88FB6DA586B65B-- --===============1573859478== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1573859478==-- From tcpm-bounces@ietf.org Tue Mar 20 13:14:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HThud-0006qc-1f; Tue, 20 Mar 2007 13:14:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HThuc-0006qP-2d for tcpm@ietf.org; Tue, 20 Mar 2007 13:14:18 -0400 Received: from mx1.grc.nasa.gov ([128.156.11.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HThuR-0006ac-HV for tcpm@ietf.org; Tue, 20 Mar 2007 13:14:18 -0400 Received: from lombok-fi.grc.nasa.gov (seraph.grc.nasa.gov [128.156.10.10]) by mx1.grc.nasa.gov (Postfix) with ESMTP id EC1DEC25A for ; Tue, 20 Mar 2007 13:14:01 -0400 (EDT) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l2KHE0UL023260; Tue, 20 Mar 2007 13:14:00 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l2KHE0v1000767; Tue, 20 Mar 2007 13:14:00 -0400 (EDT) Received: from apataki.grc.nasa.gov ([127.0.0.1]) by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2n7DnYcpIAvT; Tue, 20 Mar 2007 13:14:00 -0400 (EDT) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l2KHE0VA000761; Tue, 20 Mar 2007 13:14:00 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501) id 5F4754FE65; Tue, 20 Mar 2007 13:10:18 -0400 (EDT) Date: Tue, 20 Mar 2007 13:10:18 -0400 From: Wesley Eddy To: Joe Touch Subject: Re: [tcpm] Hat off: tcpsecure mitigations Message-ID: <20070320171018.GD28012@grc.nasa.gov> References: <20070316011822.GG12512@hut.isi.edu> <0C53DCFB700D144284A584F54711EC5803050080@xmb-sjc-21c.amer.cisco.com> <20070319210038.GB1503@hut.isi.edu> <45FF6D98.8090405@isi.edu> Mime-Version: 1.0 In-Reply-To: <45FF6D98.8090405@isi.edu> User-Agent: Mutt/1.5.5.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: "Anantha Ramaiah \(ananth\)" , tcpm@ietf.org, Ted Faber X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1958335109==" Errors-To: tcpm-bounces@ietf.org --===============1958335109== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZoaI/ZTpAVc4A5k6" Content-Disposition: inline --ZoaI/ZTpAVc4A5k6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 19, 2007 at 10:14:00PM -0700, Joe Touch wrote: >=20 > However, I think this doc also needs a strong "if you're really > concerned about protection, or have seen repeated attempts at attacks, > you really ought to use real security" too. >=20 > (sorry if it does already say that; I haven't gone through it in detail). >=20 I share this general concern, but I think that version 07 of the document is _probably_ alright in this respect. It at least minimally contains a reference to the antispoof draft at the end of the introduction section and some recognition in the security considerations that there are other attacks that the tcpsecure document doesn't address. The only (very small) change I would suggest to help in this regard is that the "abbreviated title" that appears on the top of each page shouldn't be "TCP Security", as this is WAY more general than what the draft actually discusses. I think this might have been overlooked when the actual title of the draft changed. (If using xml2rfc, this is as easy as tweaking the abbrev attribute in the title tag.) --=20 Wesley M. Eddy Verizon Federal Network Systems --ZoaI/ZTpAVc4A5k6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGABV5zBuYqbnj3IwRAr/GAJ0Z6fQ1KY97Un6L602dZP/cvmmtyQCgiI2l UI+uO5gAU4s6g3JWk2PpDJY= =Z6cz -----END PGP SIGNATURE----- --ZoaI/ZTpAVc4A5k6-- --===============1958335109== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1958335109==-- From tcpm-bounces@ietf.org Tue Mar 20 13:27:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTi77-000073-N4; Tue, 20 Mar 2007 13:27:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTi76-000051-Bm for tcpm@ietf.org; Tue, 20 Mar 2007 13:27:12 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTi6i-0000Nt-0D for tcpm@ietf.org; Tue, 20 Mar 2007 13:27:12 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l2KHQlCI031841 for ; Tue, 20 Mar 2007 10:26:47 -0700 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 8589490E2F3 for ; Tue, 20 Mar 2007 13:26:41 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id AA6291B1073 for ; Tue, 20 Mar 2007 13:26:31 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Subject: Re: [tcpm] Hat off: tcpsecure mitigations In-Reply-To: <20070319210038.GB1503@hut.isi.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Thunderstruck MIME-Version: 1.0 Date: Tue, 20 Mar 2007 13:26:31 -0400 Message-Id: <20070320172631.AA6291B1073@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1401351251==" Errors-To: tcpm-bounces@ietf.org --===============1401351251== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Folks- I wanted to clarify my point on IPR that was relayed to the meeting today. Lars brought up IPR in the context of tcpsecure in the meeting after a side jabber between us. Anantha noted that we have had the IPR discussion. I do not want to open up the IPR discussion as we have certainly decided to work on this and standardize in the face of the IPR statement from Cisco. That said, IPR can influence how strongly we say hosts should use this technique. For instance, my personal feeling (WG chair hat off) is that we should not standardize something as a MUST in the face of an IPR statement (no matter how benign we believe the IPR statement is). That is, I do not think someone should be considered non-compliant because they choose to not use IPRed techniques. So, I do not want to open the entire discussion about IPR again. That said, I do not want it to completely fall off our radar, either. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGABlHWyrrWs4yIs4RAnh6AKCIcdhhpez4oBQOhjI+Sy1v57+7rgCghjR+ JGpObY9d0+EGLCJrYaOr83E= =F2s6 -----END PGP SIGNATURE----- --=_bOundary-- --===============1401351251== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1401351251==-- From tcpm-bounces@ietf.org Tue Mar 20 13:57:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTiYH-0001Fn-Kh; Tue, 20 Mar 2007 13:55:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTiYF-0001DD-Uo for tcpm@ietf.org; Tue, 20 Mar 2007 13:55:15 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTiYE-00059J-IZ for tcpm@ietf.org; Tue, 20 Mar 2007 13:55:15 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l2KHtBWq032456 for ; Tue, 20 Mar 2007 10:55:11 -0700 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id DC70090E767 for ; Tue, 20 Mar 2007 13:55:05 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id B852F1B1172 for ; Tue, 20 Mar 2007 13:54:40 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Thunderstruck MIME-Version: 1.0 Date: Tue, 20 Mar 2007 13:54:40 -0400 Message-Id: <20070320175440.B852F1B1172@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [tcpm] tcpm meeting X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0102965386==" Errors-To: tcpm-bounces@ietf.org --===============0102965386== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Thanks for all the comments folks! Special thanks to David Borman for filling in for Ted and I. We very much appreciate it. Mark --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGAB/gWyrrWs4yIs4RAoZUAJ9qLG3gDBEMJoOI0NS9BSFvMXRJbQCgjlLp i2vt8ep+jQr8n9hm/ka6V4U= =yrvg -----END PGP SIGNATURE----- --=_bOundary-- --===============0102965386== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0102965386==-- From tcpm-bounces@ietf.org Tue Mar 20 14:33:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTj8S-0001Lv-Fo; Tue, 20 Mar 2007 14:32:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTj8Q-0001Ko-UC for tcpm@ietf.org; Tue, 20 Mar 2007 14:32:38 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTj8N-00032e-SY for tcpm@ietf.org; Tue, 20 Mar 2007 14:32:38 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 17C0AF0C590; Tue, 20 Mar 2007 15:32:02 -0300 (ART) Received: from fgont.gont.com.ar (113-165-231-201.fibertel.com.ar [201.231.165.113]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id l2KIVkl8012269; Tue, 20 Mar 2007 15:31:52 -0300 Message-Id: <200703201831.l2KIVkl8012269@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 20 Mar 2007 15:26:41 -0300 To: "Arifumi Matsumoto" From: Fernando Gont Subject: Re: [tcpm] ICMPv6 Error Handling at TCP draft-fujisaki-tcpm-icmpv6-reaction-00.txt In-Reply-To: <7b1e7a950703200603x5ca6cacbxe049d04879aae79c@mail.gmail.co m> References: <45F0E432.5040401@nttv6.net> <7.0.1.0.0.20070318041131.07eb4868@gont.com.ar> <20070320.033345.189731342.fujisaki@syce.net> <200703191935.l2JJZL2i013753@venus.xmundo.net> <7b1e7a950703200603x5ca6cacbxe049d04879aae79c@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Tue, 20 Mar 2007 15:32:01 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 10:03 a.m. 20/03/2007, Arifumi Matsumoto wrote: > The "Requirements for Internet Hosts -- Communication Layers" RFC > [RFC1122] states, in section 4.2.3.9., that the ICMP "Destination > Unreachable" messages that indicate soft errors are ICMP codes 0 > (network unreachable), 1 (host unreachable), and 5 (source route > failed). Even though ICMPv6 didn't exist when [RFC1122] was written, > one could extrapolate the concept of soft errors to ICMPv6 Type 1 > Codes 0 (no route to destination) and 3 (address unreachable). > >If you say you provides a clear explanation, please write like the following: > >no route to destination : soft >address unreachable : soft >port unreachable : hard >... Well, it only identifies soft errors, as it is assumed that the other errors are hard (if they aren't soft, they are hard), and thus they would lead to a connection abortion anyway. However, I would personally have no problem with including the other codes, if you think that would be of help. >>(IIRC, from some talk at San Diego, one vendor that said they didn't >>implement this because "it is not a standard" was Microsoft. Yet they >>were just about (or actually did?) to include alternative congestion >>control algorithms for TCP in Vista that were not even documented by >>the IETF. So....) > >Please let me know how they handle ICMP(v6) errors in such a congestion >control algorithm. The point was that with congestion control they didn't mind that what they were implementing was not even documented by the IETF. >> > | If you translate the ICMPv4 codes into ICMPv6 codes, then: >> > | >> > | * For those scenarios in which the lack of v6 connectivity is >> > | signaled by a so-called "soft error", you won't have solved anything >> > | (as RFC1122 tells you not to abort the connection attempt). >> > >> >Yes, but in the case that administrators know that, it is possible to >> >signal some type of so-called "hard error" ICMP, such as admin >> >prohibit. This can be used in the case that a site uses ULA in their >> >network. >> >>So you are saying that we need a better definition of ICMPv6 codes, >>and yet the first thing you plan to do is to forget that definition, >>and use some other error code (that was meant for some other thing) >>to get the result you expect? > >I cannot get how you lead to that understanding. >What he said was "if admin prohibit is defined as a hard error, TCP session >in *3-way handshake state* can be aborted if the host receives admin >prohibit". Why would you define "admin prohibit" as a "hard error"?. Let's just say that a packet that belongs to my connection gets misdirected (due to a transient network problem) to some router which does not allow my traffic to pass. Why should I abort my connection? Same thing if I am getting an ICMP admin prohibit simply because an IPS triggered some rule at a firewall *temporarily* (as is usually the case). This would kill TCP's robustness. >We don't care about TCP session in *establieshed state*. IMO, as there is >potential threat here, hard error should not abort established TCP session. But if you map ICMPv6 codes into ICMPv4 codes, you map them for all states. That is exactly my point. That of "reacting to ICMP error messages based on type/code and connection state" is not considered in RFC1122 (the concept is introduced by the soft errors and the icmp attacks draft). If you want to map ICMPv6 codes into ICMPv4 codes, you map them for all states. When I sent text on this matter for the ICMPv6 spec, the point was exactly this: give implementors the freedom to react to ICMPv6 error messages as it suits their needs. You can implement both the soft errors and the attacks draft without actually violating any v6 spec. And that is exactly why I say that doing the mapping from ICMPv6 codes into ICMPv4 codes simply moves us backwards, because you'd tie ICMPv6 to RFC1122. Once you do that, get prepared for another three years of discussion on the subject. (check the archives of this list from 2004 and on) >> >It looks that some recent OSes still implement ICMPv4 reaction. >> >>I don't know of any implementation out there that implements the ICMP >>"hard error" reaction specified in RFC1122. As a matter of fact, this >>has been the case for more than ten years. And in the last few years, >>those implementations that were aborting connections in response to >>the so-called ICMP hard errors changed their reaction to the one >>described in the ICMP attacks draft. > >About ICMPv4 hard error implementation, at least FreeBSD and MacOSX >implements RFC1122 reaction. No. RFC 1122 reaction is that hard errors abort connection in *any* state. Nobody does this. >i.e. For port unreachable message, >TCP connections in 3-way handshake state is dropped. For established >state connection, connection is not dropped by port unreachable. This is >owing to your soft-error draft. This is due to the *attacks* draft. Well, as a matter of fact, I talked with Kirk McKusick and others about this. And they didn't follow RFC1122 in that respect because they thought that would affect TCP's robustness negatively. Same thing with Mentat-derived implementations. Other (newer) implementations have switched to this behavior due to the icmp attacks draft, though. >So, soft-error draft proposes two things, one >is for handshake state and the other is for established state. No. The soft errors drafts just described a modification of the handling of soft errors in the connection establishment phase. As for the established states, RFC1122 already tells you that you should not abort connections upon receiving one of them. Neither the soft errors draft nor the icmp attacks draft change anything in that respect. >>If you mean that some recent OSes still implement RFC1122's reaction >>to *soft* errors, that may be the case. But it's a completely >>different thing from translating ICMPv6 codes into ICMPv4 codes. >>Mapping ICMPv6 codes into ICMPv4 codes is moving ICMPv6 eighteen >>years backwards, and is certainly a bad idea. As I said in my other e-mail: >> >>1) The scenarios you are trying to address usually lead to *soft* >>errors. As a result, the connection will not be aborted, and you will >>not have solved the problem you are trying to solve. >>2) Defining ICMP messages that indicate hard errors (as in RFC 1122) >>would open the door to connection reset attacks against TCP. I can >>assure nobody is going to do this. > >What we want is to abort a connection when a host receives ICMPv6 >hard error message if the connection is in 3-way handshake state. As I said, in the scenarios you are trying to address, you will get *soft* errors, rather than hard errors. (Unless you define as "hard" some error which should actually be defined as soft... ). >IMO, the problem is that we don't have definition of ICMPv6 hard error >message, so no vendor can implement this behavior for ICMPv6 messages. The soft errors draft is even referenced in the v6fix site of the WIDE project. IMO, if a vendor does not implement it, then it's because they simply don't like the solution. Again, this looks like a problem at some layer higher than the 7th. >For established connection, we agree that there is potential security hole >when RFC1122 behavior is implemented. This problem should be covered >by your soft-error draft. Our proposal have no suggestion about this problem. Your proposal implicitly introduces this problem. RFC1122 "hard errors" abort connections irrespective of the connection state. >>In the last couple of years, developers from NetBSD, FreeBSD, OpenBSD >>and Linux (at least) have worked on ICMP implementing some of the >>stuff in the ICMP attacks draft. I can guarantee that if you contact >>any of their developers, they will implement the soft errors behavior >>if they think it makes sense (that is, they will analyze what's in >>the document, and implement it if they think it makes sense and >>solves some problem they are having). Cisco has done it, too. > >I examined source codes and confirmed that for established state, >they already implemented what you said. What I care is about >3-way handshake state connection. Send them the soft errors draft (probably together with the v6fix document). And if they think it makes sense, they will implement it. I have had conversations on the subject (icmp attaks, in particular) with developers of all of the above open source OSes, and with Cisco and Sun. Nobody ever argued as to whether there was a "should" or "must" in caps, but rather analyzed the relevant draft, and implemented what they thought was convenient and made sense to them. If you send them the soft errors doc, most likely they will have the same attitude (which does not necessarily mean they will implement it). I don't understand why Microsoft should be a special case here. Particularly, if they enabled IPv6 by default, and their customers are experiencing delays of dozens of seconds, they should have enough motivations to do something about it. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Mar 20 15:40:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTkAc-0005dl-Pn; Tue, 20 Mar 2007 15:38:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTkAb-0004Hw-2z for tcpm@ietf.org; Tue, 20 Mar 2007 15:38:57 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTk9X-00084P-S0 for tcpm@ietf.org; Tue, 20 Mar 2007 15:38:27 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id C99F8F0C447; Tue, 20 Mar 2007 16:37:22 -0300 (ART) Received: from fgont.gont.com.ar (113-165-231-201.fibertel.com.ar [201.231.165.113]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id l2KJbBlu007535; Tue, 20 Mar 2007 16:37:14 -0300 Message-Id: <200703201937.l2KJbBlu007535@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 20 Mar 2007 16:36:50 -0300 To: weddy@grc.nasa.gov, Joe Touch From: Fernando Gont Subject: Re: [tcpm] Hat off: tcpsecure mitigations In-Reply-To: <20070320171018.GD28012@grc.nasa.gov> References: <20070316011822.GG12512@hut.isi.edu> <0C53DCFB700D144284A584F54711EC5803050080@xmb-sjc-21c.amer.cisco.com> <20070319210038.GB1503@hut.isi.edu> <45FF6D98.8090405@isi.edu> <20070320171018.GD28012@grc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Tue, 20 Mar 2007 16:37:22 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Ted Faber , tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 02:10 p.m. 20/03/2007, Wesley Eddy wrote: > > However, I think this doc also needs a strong "if you're really > > concerned about protection, or have seen repeated attempts at attacks, > > you really ought to use real security" too. > > > > (sorry if it does already say that; I haven't gone through it in detail). > > > >I share this general concern, but I think that version 07 of the >document is _probably_ alright in this respect. It at least minimally >contains a reference to the antispoof draft at the end of the >introduction section and some recognition in the security considerations >that there are other attacks that the tcpsecure document doesn't >address. I think a reference to the icmp attacks draft is missing (as Joe pointed out some months ago). Also, it would probably be a good idea to link draft-larsen-tsvwg-port-randomization, as it requires more work on the side of the attacker for performing any "blind" attack against TCP. -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Mar 20 15:49:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTkKR-0002o0-FF; Tue, 20 Mar 2007 15:49:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTkKQ-0002ns-7B for tcpm@ietf.org; Tue, 20 Mar 2007 15:49:06 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTkK0-0001oE-0n for tcpm@ietf.org; Tue, 20 Mar 2007 15:49:06 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l2KJmcxX002136 for ; Tue, 20 Mar 2007 12:48:39 -0700 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 3149590F7D6 for ; Tue, 20 Mar 2007 15:48:33 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 34FCF1B1504 for ; Tue, 20 Mar 2007 15:48:23 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Thunderstruck MIME-Version: 1.0 Date: Tue, 20 Mar 2007 15:48:23 -0400 Message-Id: <20070320194823.34FCF1B1504@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Subject: [tcpm] thoughts on draft-moncaster-tcpm-rcv-cheat-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0778092680==" Errors-To: tcpm-bounces@ietf.org --===============0778092680== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Folks- I have a few thoughts on draft-moncaster-tcpm-rcv-cheat-00. These are said without my co-chair hat. They are my own thoughts and nobody else would want them no doubt. (1) On Threats. The draft says that as opposed to Sherwood's work that posits that (0wned) receiver's will optimistically ACK to hose the network, "a more likely motivation is simple self-interest---a receiver can hugely improve its own download speed, without any need for the sender to be a willing accomplice." This latter is also the underlying theme of Savage's work. I don't think I buy this self-interest motivation for optimistic ACKing. (As a matter of fact I don't exactly buy Sherwood's motivation either. But, I buy it **a ton** more than the self interest motivation.) The problem here is that if optimistic ACKing goes wrong it hoses an application that is trying to be self-interested. If a TCP connection ACKs a packet that has been actually lost then recovering is not easy. Certainly, we can use HTTP range requests and FTP restarts and such application mechanisms to start again. But, at that point it seems to me at best a crapshoot whether you're going to end up with better performance than simply playing by the rules. Bottom line here is that it is a gamble to optimistically ACK to gain performance if you care about the data, IMO. [[ Note: Savage had two other items that I could see being used for self interest: sending tons of dupacks and dividing ACKs. These do not have near the downside of ACKing something that has been lost and so there may be incentive to actually use these things. On the other hand, there are straightforward mitigations to these, as well. (See RFC3465, RFC2581 and the 2581bis I-D.) ]] In section 3.1 of the draft there is a discussion that says if the application can tolerate missing data then the above argument that it is hard to recover doesn't apply because we can just move on without the data. Um. Yeah, but .... Err, TCP provides a *reliable* byte stream. How would one actually hook up arbitrary apps to this model? Do we really think that Microsoft is going to include a setsockopt called ABUSE_THE_SENDER and then change all the APIs such that out of order data can be passed up (with some notion of where it belongs in the stream) when the app wants to goose the sender? Or, do we think applications are going to start writing their own TCPs that read and write raw packets to get around the pesky OS notions of how things ought to work? Maybe I am just blinded by laziness here, but I don't understand this point *at all*. I understand how optimistic ACKs might be used to abuse the network--because nobody cares about the data. But, I cannot conjure the intuition about how lost segments in a reliable protocol can be masked in the name of self interest. (2) Who Do We Trust? In some sense this all comes down to whether we want to continue to trust receivers. We certainly trust senders to do the right thing. The network should probably do something about this state of affairs. But, wouldn't that also help with the problem of receivers coaxing the sender to transmit faster than appropriate? Fate sharing and all. If we trust the senders then why not trust the receivers are likely to be doing the right thing? How paranoid do we want to be for what sort of benefit? This is my main question... I would argue that up until this point we have seen no big problems with the current trust model. So, what is the benefit of deciding we no longer generally trust receivers (for congestion control purposes) and what is the cost? (3) New Options. It seems odd to me that in some places in the document the authors admit that a cooperative option could be incentivized and in others they ignore this. I.e., a general transport nonce could be required by the sender to send quite fast. So, a receiver cannot just ignore it and expect good service. Seems reasonable to me. (Exact policy and how to phase this in seems like a detail.) (4) Reordering. A number of people have measured reordering. Paxson, Partridge, Savage, etc. It is probably worth it to check into more than just [Piratla]. My general feeling from these works is that the probability that an arbitrary packet will be reordered is very slight. However, on some paths reordering is quite heavy. I think it is sort of dubious to suggest that just because a sender sees no reordering reported that this should be suspicious. (5) RTTs. It is not clear to me why we need to assess the RTT during the test period. Just leave things alone and it'll be fine. What am I missing here? (6) Sherwood Redux. It seems to me that this whole solution is really the same as Rob's. You guys have chosen different parameters for the same process. And, you have broken it into two pieces to try to mitigate the negative impacts. But, fundamentally these things are pretty much the same, I think. (7) An Alternate Scheme. There is another scheme that has been floated that you did not mention. In "DoS vulnerability of TCP by acknowledging not received segments" (draft-azcorra-tcpm-tcp-blind-ack-dos-01.txt; expired, but I am sure you can all find it) the authors propose essentially using the sequence space for a singular nonce. That is, vary the packet size a bit (randomly) and watching for ACKs that do not land on the right segment boundaries. At the very least this should be mentioned. (This was presented to the TCPM WG a while back (and, TSVWG too, I think). It gained no traction. My main question is (2). The rest of this is really minor stuff. (Although, if one wanted to seriously look at the solution space I think (7) is pretty important.) allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGADqGWyrrWs4yIs4RAr8qAJwKLUdZy1X9fchcLel7GlNZXTFP5wCeK1mj op1+yHD2U0P406viLp+nJho= =WzdR -----END PGP SIGNATURE----- --=_bOundary-- --===============0778092680== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0778092680==-- From tcpm-bounces@ietf.org Tue Mar 20 18:52:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTnA2-0000fc-7U; Tue, 20 Mar 2007 18:50:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTnA1-0000fW-2z for tcpm@ietf.org; Tue, 20 Mar 2007 18:50:33 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTn9w-0004MM-LX for tcpm@ietf.org; Tue, 20 Mar 2007 18:50:33 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2KMo9TF028484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Mar 2007 15:50:09 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.8/8.13.8/Submit) id l2KMo981034387; Tue, 20 Mar 2007 15:50:09 -0700 (PDT) (envelope-from faber) Date: Tue, 20 Mar 2007 15:50:09 -0700 From: Ted Faber To: "Mitesh Dalal (mdalal)" Subject: Re: [tcpm] Hat off: tcpsecure mitigations Message-ID: <20070320225009.GF31461@hut.isi.edu> References: <45FF6D98.8090405@isi.edu> <13D1EAB852BE194C94773A947138483D0334AD40@xmb-sjc-21c.amer.cisco.com> Mime-Version: 1.0 In-Reply-To: <13D1EAB852BE194C94773A947138483D0334AD40@xmb-sjc-21c.amer.cisco.com> User-Agent: Mutt/1.4.2.2i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , Joe Touch X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0195304735==" Errors-To: tcpm-bounces@ietf.org --===============0195304735== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="z+pzSjdB7cqptWpS" Content-Disposition: inline --z+pzSjdB7cqptWpS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 20, 2007 at 09:39:32AM -0700, Mitesh Dalal (mdalal) wrote: > > From: Joe Touch [mailto:touch@ISI.EDU]=20 > > SHOULD, in many cases (not just this) needs to come with the=20 > > conditions, as noted above. In this particular case: > >=20 > > routers and proxy systems SHOULD implement these mods for > > their host-based TCP > > (orgination/termination) > >=20 > > all other hosts MAY implement them > >=20 >=20 > I would tend to avoid recommendations based on system role to=20 > determine MAY/SHOULD language.=20 I agree with Mitesh here. I don't want to split that hair. =20 > Since the weakness lies in the > protocol we should make a recommendation one way or the other. > If we are confident that this draft will help routers and > proxies, leaving end hosts behind does not buy us much. > (not that a SHOULD recommendation not implemented by endhost > vendors will cause them to be out of spec) I'm not sure what that means. --=20 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 --z+pzSjdB7cqptWpS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (FreeBSD) iD8DBQFGAGUhaUz3f+Zf+XsRAt7gAKDiGSsz6HoJIZQTg306Qvs/3T6EHQCg5p0g l3EP8UTNhePDkVVUION1pS0= =e6+s -----END PGP SIGNATURE----- --z+pzSjdB7cqptWpS-- --===============0195304735== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0195304735==-- From tcpm-bounces@ietf.org Tue Mar 20 19:32:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTnnz-0000Ug-Py; Tue, 20 Mar 2007 19:31:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTnny-0000Ua-Td for tcpm@ietf.org; Tue, 20 Mar 2007 19:31:50 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTnnx-00026r-9p for tcpm@ietf.org; Tue, 20 Mar 2007 19:31:50 -0400 Received: from [127.0.0.1] (c1-vpn9.isi.edu [128.9.176.39]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l2KNVaku029846; Tue, 20 Mar 2007 16:31:39 -0700 (PDT) Message-ID: <46006ECE.7080206@isi.edu> Date: Tue, 20 Mar 2007 16:31:26 -0700 From: Joe Touch User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Ted Faber Subject: Re: [tcpm] Hat off: tcpsecure mitigations References: <45FF6D98.8090405@isi.edu> <13D1EAB852BE194C94773A947138483D0334AD40@xmb-sjc-21c.amer.cisco.com> <20070320225009.GF31461@hut.isi.edu> In-Reply-To: <20070320225009.GF31461@hut.isi.edu> X-Enigmail-Version: 0.94.1.2.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: tcpm@ietf.org, "Mitesh Dalal \(mdalal\)" , "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0446331390==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0446331390== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBB8EE1B24C09211BDD3C1EAA" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBB8EE1B24C09211BDD3C1EAA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ted Faber wrote: > On Tue, Mar 20, 2007 at 09:39:32AM -0700, Mitesh Dalal (mdalal) wrote: >>> From: Joe Touch [mailto:touch@ISI.EDU]=20 >>> SHOULD, in many cases (not just this) needs to come with the=20 >>> conditions, as noted above. In this particular case: >>> >>> routers and proxy systems SHOULD implement these mods for >>> their host-based TCP >>> (orgination/termination) >>> >>> all other hosts MAY implement them >>> >> I would tend to avoid recommendations based on system role to=20 >> determine MAY/SHOULD language.=20 >=20 > I agree with Mitesh here. I don't want to split that hair. Either SHOULD should be qualified somehow - when running a well-known service where both ends are likely to be known, e.g., BGP, or MAY is more appropriate. Otherwise you're recommending a SHOULD to protect everyone from an attack only a subset of Internet hosts are susceptible to. The threat isn't large enough to warrant that, and this is not required for correct operation. Short of widescale necessity or required correctness, MAY seems the most appropriate choice. IMO, this is further underscored by the intellectual property issue. >> Since the weakness lies in the >> protocol we should make a recommendation one way or the other. >> If we are confident that this draft will help routers and >> proxies, leaving end hosts behind does not buy us much. >> (not that a SHOULD recommendation not implemented by endhost >> vendors will cause them to be out of spec) >=20 > I'm not sure what that means. This is the problem.SHOULD not implemented needs to come with a reason. If we know that reason now - e.g., a host that isn't running a well-known service with both endpoints likely known - then we ought to state it as a known exception. Joe --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enigBB8EE1B24C09211BDD3C1EAA 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.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGAG7OE5f5cImnZrsRAr0iAJ0RtJqEt0qPFcEBhb/l9byEYECVOACgkMcp XEjY8gvpfUnHe37GlXYUHgI= =THEt -----END PGP SIGNATURE----- --------------enigBB8EE1B24C09211BDD3C1EAA-- --===============0446331390== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0446331390==-- From tcpm-bounces@ietf.org Tue Mar 20 20:04:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HToIT-0007lC-NY; Tue, 20 Mar 2007 20:03:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HToIS-0007l4-Il for tcpm@ietf.org; Tue, 20 Mar 2007 20:03:20 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HToIQ-0000TU-C5 for tcpm@ietf.org; Tue, 20 Mar 2007 20:03:20 -0400 Received: from [127.0.0.1] (c1-vpn9.isi.edu [128.9.176.39]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l2L02j9Y007617; Tue, 20 Mar 2007 17:02:47 -0700 (PDT) Message-ID: <4600761A.9050107@isi.edu> Date: Tue, 20 Mar 2007 17:02:34 -0700 From: Joe Touch User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Joe Touch Subject: Re: [tcpm] Hat off: tcpsecure mitigations References: <45FF6D98.8090405@isi.edu> <13D1EAB852BE194C94773A947138483D0334AD40@xmb-sjc-21c.amer.cisco.com> <20070320225009.GF31461@hut.isi.edu> <46006ECE.7080206@isi.edu> In-Reply-To: <46006ECE.7080206@isi.edu> X-Enigmail-Version: 0.94.1.2.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: "Anantha Ramaiah \(ananth\)" , tcpm@ietf.org, "Mitesh Dalal \(mdalal\)" , Ted Faber X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1306760768==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1306760768== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig147325CF047BBE2FA39F961C" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig147325CF047BBE2FA39F961C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Joe Touch wrote: =2E.. > This is the problem.SHOULD not implemented needs to come with a reason.= > If we know that reason now - e.g., a host that isn't running a > well-known service with both endpoints likely known - then we ought to > state it as a known exception. PS - let me give a more specific equivalent: All TCP implementations SHOULD implement TCP/MD5. There's a cost, and not all TCPs are under threat, so we don't require that. The cost of this is lower, but still there in terms of specification complexity, and the impact on additional messages on correctly operating TCPs that issue RSTs during a data transfer. It needs a similar MAY or "SHOULD IF" clause, but not an unrestricted SHOULD= =2E Joe --------------enig147325CF047BBE2FA39F961C 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.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGAHYaE5f5cImnZrsRAhgdAKCFQEVqqUFOPNw3VZa4/hP2eszUOgCgkUX3 3FQuf05Lm5TF13OLGlrPzNg= =J2qW -----END PGP SIGNATURE----- --------------enig147325CF047BBE2FA39F961C-- --===============1306760768== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1306760768==-- From tcpm-bounces@ietf.org Tue Mar 20 21:32:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTpf7-0002Eh-7F; Tue, 20 Mar 2007 21:30:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTpf5-0002Eb-HQ for tcpm@ietf.org; Tue, 20 Mar 2007 21:30:47 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTpf2-00033p-Qk for tcpm@ietf.org; Tue, 20 Mar 2007 21:30:47 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2L1U5e3010017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Mar 2007 18:30:05 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.8/8.13.8/Submit) id l2L1U50F037828; Tue, 20 Mar 2007 18:30:05 -0700 (PDT) (envelope-from faber) Date: Tue, 20 Mar 2007 18:30:05 -0700 From: Ted Faber To: Joe Touch Subject: Re: [tcpm] Hat off: tcpsecure mitigations Message-ID: <20070321013005.GQ35849@hut.isi.edu> References: <45FF6D98.8090405@isi.edu> <13D1EAB852BE194C94773A947138483D0334AD40@xmb-sjc-21c.amer.cisco.com> <20070320225009.GF31461@hut.isi.edu> <46006ECE.7080206@isi.edu> Mime-Version: 1.0 In-Reply-To: <46006ECE.7080206@isi.edu> User-Agent: Mutt/1.4.2.2i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: tcpm@ietf.org, "Mitesh Dalal \(mdalal\)" , "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1786958995==" Errors-To: tcpm-bounces@ietf.org --===============1786958995== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5KxTQ9fdN6Op3ksq" Content-Disposition: inline --5KxTQ9fdN6Op3ksq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 20, 2007 at 04:31:26PM -0700, Joe Touch wrote: > Either SHOULD should be qualified somehow - when running a well-known > service where both ends are likely to be known, e.g., BGP, or MAY is > more appropriate. >=20 > Otherwise you're recommending a SHOULD to protect everyone from an > attack only a subset of Internet hosts are susceptible to. The threat > isn't large enough to warrant that, and this is not required for correct > operation. Short of widescale necessity or required correctness, MAY > seems the most appropriate choice. We simply disagree. To me, the RST/SYN mitigations are a small enough change with no significant downside. I don't think that the problem that they're defending against is earth-shattering, but a significant mitigation is so simple and and cheap that I'm quite comfortable with a SHOULD. I'm curious what others think. --=20 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 --5KxTQ9fdN6Op3ksq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (FreeBSD) iD8DBQFGAIqdaUz3f+Zf+XsRAvzAAJ0YtjsQMEpszlXVCqvs3iWW4IP21wCg1WdA NRbz1DgDceBBWNrA+u8Ksyw= =GdtM -----END PGP SIGNATURE----- --5KxTQ9fdN6Op3ksq-- --===============1786958995== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1786958995==-- From tcpm-bounces@ietf.org Tue Mar 20 21:38:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTpmO-00019q-RI; Tue, 20 Mar 2007 21:38:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTpmN-00019l-46 for tcpm@ietf.org; Tue, 20 Mar 2007 21:38:19 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTpmL-0004km-Nn for tcpm@ietf.org; Tue, 20 Mar 2007 21:38:19 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2L1bdbc012263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Mar 2007 18:37:39 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.8/8.13.8/Submit) id l2L1bd7a037920; Tue, 20 Mar 2007 18:37:39 -0700 (PDT) (envelope-from faber) Date: Tue, 20 Mar 2007 18:37:39 -0700 From: Ted Faber To: Joe Touch Subject: Re: [tcpm] Hat off: tcpsecure mitigations Message-ID: <20070321013739.GR35849@hut.isi.edu> References: <45FF6D98.8090405@isi.edu> <13D1EAB852BE194C94773A947138483D0334AD40@xmb-sjc-21c.amer.cisco.com> <20070320225009.GF31461@hut.isi.edu> <46006ECE.7080206@isi.edu> <4600761A.9050107@isi.edu> Mime-Version: 1.0 In-Reply-To: <4600761A.9050107@isi.edu> User-Agent: Mutt/1.4.2.2i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: tcpm@ietf.org, "Mitesh Dalal \(mdalal\)" , "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0412508288==" Errors-To: tcpm-bounces@ietf.org --===============0412508288== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3XZQkxCYp0f/VEFS" Content-Disposition: inline --3XZQkxCYp0f/VEFS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 20, 2007 at 05:02:34PM -0700, Joe Touch wrote: >=20 >=20 > Joe Touch wrote: > ... > > This is the problem.SHOULD not implemented needs to come with a reason. > > If we know that reason now - e.g., a host that isn't running a > > well-known service with both endpoints likely known - then we ought to > > state it as a known exception. >=20 > PS - let me give a more specific equivalent: >=20 > All TCP implementations SHOULD implement TCP/MD5. I would argue against such a suggestion on the basis that the complexity and overhead of TCP/MD5 are significant and most hosts are not menaced by the attacks this heavy-weight protection prevents. The off-path RST and SYN mitigations are so simple and inexpensive that I'm comfortable with a SHOULD. Most hosts don't need TIME-WAIT, either, but for most hosts it's inexpensive. --=20 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 --3XZQkxCYp0f/VEFS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (FreeBSD) iD8DBQFGAIxjaUz3f+Zf+XsRArpCAKDgNQIxh5VBcau5uxE7+psuvafQUgCdEYG5 6DcfAHyPHhGggT931J6wHQw= =wz+n -----END PGP SIGNATURE----- --3XZQkxCYp0f/VEFS-- --===============0412508288== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0412508288==-- From tcpm-bounces@ietf.org Wed Mar 21 02:51:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTudG-0004Yw-5T; Wed, 21 Mar 2007 02:49:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTudE-0004Yi-K5 for tcpm@ietf.org; Wed, 21 Mar 2007 02:49:12 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTudD-0003l5-8f for tcpm@ietf.org; Wed, 21 Mar 2007 02:49:12 -0400 Received: from [127.0.0.1] (c2-vpn06.isi.edu [128.9.176.218]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l2L6mjr7013173; Tue, 20 Mar 2007 23:48:47 -0700 (PDT) Message-ID: <4600D542.5000207@isi.edu> Date: Tue, 20 Mar 2007 23:48:34 -0700 From: Joe Touch User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Ted Faber Subject: Re: [tcpm] Hat off: tcpsecure mitigations References: <45FF6D98.8090405@isi.edu> <13D1EAB852BE194C94773A947138483D0334AD40@xmb-sjc-21c.amer.cisco.com> <20070320225009.GF31461@hut.isi.edu> <46006ECE.7080206@isi.edu> <4600761A.9050107@isi.edu> <20070321013739.GR35849@hut.isi.edu> In-Reply-To: <20070321013739.GR35849@hut.isi.edu> X-Enigmail-Version: 0.94.1.2.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: tcpm@ietf.org, "Mitesh Dalal \(mdalal\)" , "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0826971700==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0826971700== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig042971A35FE41478E38DC2BB" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig042971A35FE41478E38DC2BB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ted Faber wrote: > On Tue, Mar 20, 2007 at 05:02:34PM -0700, Joe Touch wrote: >> >> Joe Touch wrote: >> ... >>> This is the problem.SHOULD not implemented needs to come with a reaso= n. >>> If we know that reason now - e.g., a host that isn't running a >>> well-known service with both endpoints likely known - then we ought t= o >>> state it as a known exception. >> PS - let me give a more specific equivalent: >> >> All TCP implementations SHOULD implement TCP/MD5. >=20 > I would argue against such a suggestion on the basis that the complexit= y > and overhead of TCP/MD5 are significant and most hosts are not menaced = by > the attacks this heavy-weight protection prevents. The off-path RST an= d > SYN mitigations are so simple and inexpensive that I'm comfortable with= > a SHOULD. >=20 > Most hosts don't need TIME-WAIT, either, but for most hosts it's > inexpensive. TIME-WAIT is required for correct, safe operation between two endpoints. This solution sacrifices good protocol design (never respond to a RST, in specific, and 'keep it simple' in general) in an attempt to provide protection from deliberate attacks, protection that is already sufficient unless both endpoint addresses and a port number is known, and protection that's insufficient against data injection in-window, as well as ICMP attacks that can shut a connection just as easily (and CANNOT need to be in-window, since there are no timing requirements for ICMP responses). It's not required for correct operation, and it's not sufficient for safe operation. And its encumbered. A SHOULD would burden implementers with needing to justify why their TCPs did not support this requirement, and avoiding encumberence may not be sufficient. This may be simple, but its expense is in the eye of the implementer. For all these reasons, a MAY is appropriate, but a SHOULD is not. Joe --------------enig042971A35FE41478E38DC2BB 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.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGANVDE5f5cImnZrsRAvqzAKDXGAxJwfBBa6H5UEGc9jrXSgdsWACg/G35 6lX+ZmTskyn22xhmtLbXNCs= =UCa6 -----END PGP SIGNATURE----- --------------enig042971A35FE41478E38DC2BB-- --===============0826971700== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0826971700==-- From tcpm-bounces@ietf.org Wed Mar 21 04:42:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTwOH-0002jF-Ct; Wed, 21 Mar 2007 04:41:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTwOF-0002iQ-Iy for tcpm@ietf.org; Wed, 21 Mar 2007 04:41:51 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTwO8-0005YU-My for tcpm@ietf.org; Wed, 21 Mar 2007 04:41:51 -0400 Received: from [127.0.0.1] (c1-vpn2.isi.edu [128.9.176.28]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l2L8fTAB010640; Wed, 21 Mar 2007 01:41:31 -0700 (PDT) Message-ID: <4600EFAE.3090902@isi.edu> Date: Wed, 21 Mar 2007 01:41:18 -0700 From: Joe Touch User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: mallman@icir.org Subject: Re: [tcpm] thoughts on draft-moncaster-tcpm-rcv-cheat-00 References: <20070320194823.34FCF1B1504@lawyers.icir.org> In-Reply-To: <20070320194823.34FCF1B1504@lawyers.icir.org> X-Enigmail-Version: 0.94.1.2.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0992401885==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0992401885== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB905E81D4DFE1973DAF5A5C1" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB905E81D4DFE1973DAF5A5C1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mark Allman wrote: > =20 > Folks- >=20 > I have a few thoughts on draft-moncaster-tcpm-rcv-cheat-00. These are > said without my co-chair hat. They are my own thoughts and nobody else= > would want them no doubt. I had a few at the meeting as well as a few new ideas; here's a capture of them on-list (they're mostly clarification or suggestion), as well as comments on Mark's: - Nagle I wonder whether the algorithm should prohibit stalling partial segments when Nagle is enabled, to avoid unintended interactions with Nagle. - tcp-secure It would be useful to address interactions with tcp-secure, esp whether delaying segments could affect a correctly-behaving receiver RST-ing a connection. - malicious vs. unexpected (not noted at the meeting) Receivers MUST ack at least once every two received segments, but can ack every one. There's a bit of play in there - a correctly-behaving receiver could ACK every segment. Nothing in the 1-2 range should be considered an error - including changes during a connection. It might be useful to indicate this as "odd" or "unexpected", but not "bad" per se; some choices could be considered "unfortunate" even if not malicious (ACK every 1.5 segments). > (2) Who Do We Trust? >=20 > In some sense this all comes down to whether we want to continue to= > trust receivers. We certainly trust senders to do the right thing.= > The network should probably do something about this state of > affairs. But, wouldn't that also help with the problem of receiver= s > coaxing the sender to transmit faster than appropriate? Fate > sharing and all. If we trust the senders then why not trust the > receivers are likely to be doing the right thing? How paranoid do > we want to be for what sort of benefit? FWIW, I didn't see this as being paranoid, but as a test system. You decide whether the behavior is malicious separate from whether it's in-spec, in-spec but ill-advised, or out-of-spec. Malicious is intent; let's leave that out. > (6) Sherwood Redux. >=20 > It seems to me that this whole solution is really the same as > Rob's. You guys have chosen different parameters for the same > process. And, you have broken it into two pieces to try to mitigat= e > the negative impacts. But, fundamentally these things are pretty > much the same, I think. >=20 > (7) An Alternate Scheme. >=20 > There is another scheme that has been floated that you did not > mention. In "DoS vulnerability of TCP by acknowledging not receive= d > segments" (draft-azcorra-tcpm-tcp-blind-ack-dos-01.txt; expired, bu= t > I am sure you can all find it) the authors propose essentially usin= g > the sequence space for a singular nonce. That is, vary the packet > size a bit (randomly) and watching for ACKs that do not land on the= > right segment boundaries. At the very least this should be > mentioned. ACKs that don't land on segment boundaries could be hard to figure out, esp. with Nagle on. And receivers need not ACK every byte received; some optimized implementations (variants of RDDP) try to resynch boundaries at the segment layer to provide inferred alignment to data boundaries. The point is that not ACKing on a boundary isn't malicious, but it can be reported as "odd" or "unexpected". Joe --------------enigB905E81D4DFE1973DAF5A5C1 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.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGAO+uE5f5cImnZrsRAi5qAKC6X2Bw01bV7UGa61ic8WT+eQ1jxACcDAGE I3Ap2fb1ClmCz1MrVy0K5ZQ= =CMOE -----END PGP SIGNATURE----- --------------enigB905E81D4DFE1973DAF5A5C1-- --===============0992401885== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0992401885==-- From tcpm-bounces@ietf.org Wed Mar 21 05:33:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTxBH-00058Q-Ci; Wed, 21 Mar 2007 05:32:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTxBF-00057A-3z for tcpm@ietf.org; Wed, 21 Mar 2007 05:32:29 -0400 Received: from [2001:fa8::25] (helo=mail.nttv6.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTxB9-0004Ip-PU for tcpm@ietf.org; Wed, 21 Mar 2007 05:32:29 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.nttv6.net (8.14.0/8.13.8) with ESMTP id l2L9ViKL055490; Wed, 21 Mar 2007 18:31:45 +0900 (JST) (envelope-from arifumi@nttv6.net) Message-ID: <4600FB7E.7030700@nttv6.net> Date: Wed, 21 Mar 2007 18:31:42 +0900 From: Arifumi Matsumoto User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] ICMPv6 Error Handling at TCP draft-fujisaki-tcpm-icmpv6-reaction-00.txt References: <45F0E432.5040401@nttv6.net> <7.0.1.0.0.20070318041131.07eb4868@gont.com.ar> <20070320.033345.189731342.fujisaki@syce.net> <200703191935.l2JJZL2i013753@venus.xmundo.net> <7b1e7a950703200603x5ca6cacbxe049d04879aae79c@mail.gmail.com> <200703201831.l2KIVkl8012269@venus.xmundo.net> In-Reply-To: <200703201831.l2KIVkl8012269@venus.xmundo.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.8 (--) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Hi, Fernando Gont wrote: > At 10:03 a.m. 20/03/2007, Arifumi Matsumoto wrote: > >> The "Requirements for Internet Hosts -- Communication Layers" RFC >> [RFC1122] states, in section 4.2.3.9., that the ICMP "Destination >> Unreachable" messages that indicate soft errors are ICMP codes 0 >> (network unreachable), 1 (host unreachable), and 5 (source route >> failed). Even though ICMPv6 didn't exist when [RFC1122] was written, >> one could extrapolate the concept of soft errors to ICMPv6 Type 1 >> Codes 0 (no route to destination) and 3 (address unreachable). >> >> If you say you provides a clear explanation, please write like the >> following: >> >> no route to destination : soft >> address unreachable : soft >> port unreachable : hard >> ... > > Well, it only identifies soft errors, as it is assumed that the other > errors are hard (if they aren't soft, they are hard), and thus they > would lead to a connection abortion anyway. However, I would personally > have no problem with including the other codes, if you think that would > be of help. At least you should not say or imply "others are hard errors" here. Because the number of ICMP error codes can increase in the future. > Why would you define "admin prohibit" as a "hard error"?. Let's just say > that a packet that belongs to my connection gets misdirected (due to a > transient network problem) to some router which does not allow my > traffic to pass. Why should I abort my connection? You did mention that other ICMPv6 error codes can be treated as hard, so admin prohibit is also hard, right ? Anyway, it doesn't matter which specific ICMPv6 code falls into hard or soft here. >> We don't care about TCP session in *establieshed state*. IMO, as there is >> potential threat here, hard error should not abort established TCP >> session. > > But if you map ICMPv6 codes into ICMPv4 codes, you map them for all > states. That is exactly my point. That of "reacting to ICMP error > messages based on type/code and connection state" is not considered in > RFC1122 (the concept is introduced by the soft errors and the icmp > attacks draft). If you want to map ICMPv6 codes into ICMPv4 codes, you > map them for all states. IMO soft-error draft doesn't obsolete RFC1122 but it supplements RFC1122. It depends on a vendor whether he implements RFC1122 and also soft-error RFC. Especially soft-error RFC will be informational, so it is more vendor-dependent whether he implements it or not. Just like this, RFC1122-revision(what we propose) doesn't obsolete soft-error RFC or soft-error RFC doesn't obsolete RFC1122-revision. soft-error RFC should supplement RFC1122-revision in the same way. If a vendor implements and RFC1122 and not soft-error RFC for some reason, he should think about implementing RFC1122-revision instead of RFC1122 when RFC1122-revision is ready. If another vendor implements RFC1122 and also soft-error RFC, he should think about implementing RFC1122-revision and also soft-error RFC. This is my opinion about RFC1122-revision and soft-error RFC relationship. As soft-error RFC will be informational in the immediate future, IMO all the vendors that implements RFC1122 may not even notice or take a look at it. > When I sent text on this matter for the ICMPv6 spec, the point was > exactly this: give implementors the freedom to react to ICMPv6 error > messages as it suits their needs. You can implement both the soft errors > and the attacks draft without actually violating any v6 spec. And that > is exactly why I say that doing the mapping from ICMPv6 codes into > ICMPv4 codes simply moves us backwards, because you'd tie ICMPv6 to > RFC1122. Once you do that, get prepared for another three years of > discussion on the subject. (check the archives of this list from 2004 > and on) ICMPv6 gave freedom of its error message handling. Then, every protocol has its own way of error message handling. So TCP does. TCP's error message handling should be standardized and should not be vendor dependent. The following is about implementation status. >>> >It looks that some recent OSes still implement ICMPv4 reaction. >>> >>> I don't know of any implementation out there that implements the ICMP >>> "hard error" reaction specified in RFC1122. As a matter of fact, this >>> has been the case for more than ten years. And in the last few years, >>> those implementations that were aborting connections in response to >>> the so-called ICMP hard errors changed their reaction to the one >>> described in the ICMP attacks draft. >> >> About ICMPv4 hard error implementation, at least FreeBSD and MacOSX >> implements RFC1122 reaction. > > No. RFC 1122 reaction is that hard errors abort connection in *any* > state. Nobody does this. > > >> i.e. For port unreachable message, >> TCP connections in 3-way handshake state is dropped. For established >> state connection, connection is not dropped by port unreachable. This is >> owing to your soft-error draft. > > This is due to the *attacks* draft. Well, as a matter of fact, I talked > with Kirk McKusick and others about this. And they didn't follow RFC1122 > in that respect because they thought that would affect TCP's robustness > negatively. Same thing with Mentat-derived implementations. Other > (newer) implementations have switched to this behavior due to the icmp > attacks draft, though. I'm sorry for mis-understanding about two drafts. So, for a summary, FreeBSD and MacOSX implements RFC1122 and for established connection they implemented icmp-attacks draft. Kindest regards. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Mar 21 08:43:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU08c-0000Fp-9z; Wed, 21 Mar 2007 08:41:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU08a-0000C1-8b for tcpm@ietf.org; Wed, 21 Mar 2007 08:41:56 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU08V-00038s-Pc for tcpm@ietf.org; Wed, 21 Mar 2007 08:41:56 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l2LCfkTe021236; Wed, 21 Mar 2007 05:41:46 -0700 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 34E589179CB; Wed, 21 Mar 2007 08:41:41 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id B71F21B23E3; Wed, 21 Mar 2007 08:41:29 -0400 (EDT) To: Joe Touch From: Mark Allman Subject: Re: [tcpm] thoughts on draft-moncaster-tcpm-rcv-cheat-00 In-Reply-To: <4600EFAE.3090902@isi.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Thunderstruck MIME-Version: 1.0 Date: Wed, 21 Mar 2007 08:41:29 -0400 Message-Id: <20070321124129.B71F21B23E3@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1700188603==" Errors-To: tcpm-bounces@ietf.org --===============1700188603== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Joe- > > (2) Who Do We Trust? > > > > In some sense this all comes down to whether we want to continue > > to trust receivers. We certainly trust senders to do the right > > thing. The network should probably do something about this > > state of affairs. But, wouldn't that also help with the problem > > of receivers coaxing the sender to transmit faster than > > appropriate? Fate sharing and all. If we trust the senders > > then why not trust the receivers are likely to be doing the > > right thing? How paranoid do we want to be for what sort of > > benefit? > > FWIW, I didn't see this as being paranoid, but as a test system. You > decide whether the behavior is malicious separate from whether it's > in-spec, in-spec but ill-advised, or out-of-spec. > > Malicious is intent; let's leave that out. OK, well then make the case that I should care without worrying about the intent. How do we improve the state of the world by figuring out if the receiver is in or out of spec with regards to ACKing data that has not arrived. If this is a simple implementation mistake that causes a receiver to ACK data that has not arrived then it seems pretty clear that it'll be found and fixed pretty readily because things just won't work. Do we want to add something to every implementation to test for such a bug? Or, for a bazillion other possible bugs? This work is advertised as for combating malicious receivers who are not in-spec in an attempt to either (1) gain an advantage for themselves or (2) to coax the sender to transmit at an inappropriate rate to hose the network. In that context, I think the question of how well we should trust the receivers is well within bounds. If you have another important and practical reason that we should be doing such a test that does not involve maliciousness then I'd love to hear it. If you have one I'd then be more inclined to agree with your much broader notion that we need not worry about intent. > > (7) An Alternate Scheme. > > > > There is another scheme that has been floated that you did not > > mention. In "DoS vulnerability of TCP by acknowledging not received > > segments" (draft-azcorra-tcpm-tcp-blind-ack-dos-01.txt; expired, but > > I am sure you can all find it) the authors propose essentially using > > the sequence space for a singular nonce. That is, vary the packet > > size a bit (randomly) and watching for ACKs that do not land on the > > right segment boundaries. At the very least this should be > > mentioned. > > ACKs that don't land on segment boundaries could be hard to figure > out, esp. with Nagle on. And receivers need not ACK every byte > received; some optimized implementations (variants of RDDP) try to > resynch boundaries at the segment layer to provide inferred alignment > to data boundaries. > > The point is that not ACKing on a boundary isn't malicious, but it can > be reported as "odd" or "unexpected". Just to be clear.... I was not advocating this scheme and if my words above come off that way, I screwed up. I was noting that someone wrote down a scheme to combat this optimistic ACKing business that draft-moncaster-tcpm-rcv-cheat-00 did not consider as related work. You and I often don't see eye-to-eye, but surely we agree that related work should be discussed as such. (And, in fact, we also agree that randomizing the segment boundaries for finding optimistic ACKers can be problematic. I.e., I agree with the technical points above.) allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGASf5WyrrWs4yIs4RAqD5AJ9itAKYNg5Mfc3PzT7CMXPTLlVTcgCgmVe2 oMHz3I68xrCa7sXKfGwQZ84= =VC7P -----END PGP SIGNATURE----- --=_bOundary-- --===============1700188603== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1700188603==-- From tcpm-bounces@ietf.org Wed Mar 21 09:37:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU10E-0003Z0-4z; Wed, 21 Mar 2007 09:37:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU10D-0003Ys-6Q for tcpm@ietf.org; Wed, 21 Mar 2007 09:37:21 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU0zw-0004sL-53 for tcpm@ietf.org; Wed, 21 Mar 2007 09:37:21 -0400 Received: from [127.0.0.1] ([128.9.176.76]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l2LDaODZ027883; Wed, 21 Mar 2007 06:36:26 -0700 (PDT) Message-ID: <460134CE.7070702@isi.edu> Date: Wed, 21 Mar 2007 06:36:14 -0700 From: Joe Touch User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: mallman@icir.org Subject: Re: [tcpm] thoughts on draft-moncaster-tcpm-rcv-cheat-00 References: <20070321124129.B71F21B23E3@lawyers.icir.org> In-Reply-To: <20070321124129.B71F21B23E3@lawyers.icir.org> X-Enigmail-Version: 0.94.1.2.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0854554242==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0854554242== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig82191259A161826E6E145F39" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig82191259A161826E6E145F39 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mark Allman wrote: > Joe- >=20 >>> (2) Who Do We Trust? >>> >>> In some sense this all comes down to whether we want to continue >>> to trust receivers. We certainly trust senders to do the right >>> thing. The network should probably do something about this >>> state of affairs. But, wouldn't that also help with the problem >>> of receivers coaxing the sender to transmit faster than >>> appropriate? Fate sharing and all. If we trust the senders >>> then why not trust the receivers are likely to be doing the >>> right thing? How paranoid do we want to be for what sort of >>> benefit? >> FWIW, I didn't see this as being paranoid, but as a test system. You >> decide whether the behavior is malicious separate from whether it's >> in-spec, in-spec but ill-advised, or out-of-spec. >> >> Malicious is intent; let's leave that out. >=20 > OK, well then make the case that I should care without worrying about > the intent. It might be useful for test purposes. After re-reading the doc, I still don't presume that it requires that all TCPs deploy this. I'd prefer if it were more explicit, but my read was that it was intended as a way to test - when testing is what you want to do. Testing could be added to an operational TCP, or could be just part of a test TCP. The former might be running to do ongoing monitoring, to alert a human to look into possible anomalies. The latter would be just for test purposes. Now, as to whether all TCPs -should- do this test, I'll point out the irony in thinking this is incorrect when TCP-secure is. My point there was that such errors aren't attacks per se (just as here), and that these sorts of tests are useful to monitor things and escalate, but not as a required part of any implementation. I agree with you that TCP assumes that endpoints behave generally well, and that the only things it MUST (or even SHOULD, IMO) include are those REQUIRED for correct operation. Security and detecting malicious endpoints is not required, and must be optional. > How do we improve the state of the world by figuring out if the receive= r > is in or out of spec with regards to ACKing data that has not arrived. > If this is a simple implementation mistake that causes a receiver to AC= K > data that has not arrived then it seems pretty clear that it'll be foun= d > and fixed pretty readily because things just won't work. Do we want to= > add something to every implementation to test for such a bug? Or, for = a > bazillion other possible bugs? Definitely not. I like this as a test suite, but not as a requirement. > This work is advertised as for combating malicious receivers who are no= t > in-spec in an attempt to either (1) gain an advantage for themselves or= > (2) to coax the sender to transmit at an inappropriate rate to hose the= > network. In that context, I think the question of how well we should > trust the receivers is well within bounds. If you have another > important and practical reason that we should be doing such a test that= > does not involve maliciousness then I'd love to hear it. If you have > one I'd then be more inclined to agree with your much broader notion > that we need not worry about intent. I think we're agreeing; I agree this shouldn't be part of regular operations, but still think the tests described could be useful for informational purposes only. >>> (7) An Alternate Scheme. >>> >>> There is another scheme that has been floated that you did not >>> mention. In "DoS vulnerability of TCP by acknowledging not recei= ved >>> segments" (draft-azcorra-tcpm-tcp-blind-ack-dos-01.txt; expired, = but >>> I am sure you can all find it) the authors propose essentially us= ing >>> the sequence space for a singular nonce. That is, vary the packe= t >>> size a bit (randomly) and watching for ACKs that do not land on t= he >>> right segment boundaries. At the very least this should be >>> mentioned. >> ACKs that don't land on segment boundaries could be hard to figure >> out, esp. with Nagle on. And receivers need not ACK every byte >> received; some optimized implementations (variants of RDDP) try to >> resynch boundaries at the segment layer to provide inferred alignment >> to data boundaries. >> >> The point is that not ACKing on a boundary isn't malicious, but it can= >> be reported as "odd" or "unexpected". >=20 > Just to be clear.... I was not advocating this scheme and if my words > above come off that way, I screwed up. I was noting that someone wrote= > down a scheme to combat this optimistic ACKing business that > draft-moncaster-tcpm-rcv-cheat-00 did not consider as related work. > You and I often don't see eye-to-eye, but surely we agree that related > work should be discussed as such. Oh - I agree about the related work stuff... > (And, in fact, we also agree that randomizing the segment boundaries fo= r > finding optimistic ACKers can be problematic. I.e., I agree with the > technical points above.) Right, then we agree on both points. Here are some others: MUST/SHOULD/MAY - these are not appropriate in the requirements section; they usually refer to a protocol solution, not a requirement, IMO. i.e., it's ON in sections 6.2.4 and 6.3.3, but not in section 4 JOe --------------enig82191259A161826E6E145F39 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.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD4DBQFGATTOE5f5cImnZrsRAsGKAJ48nA+QscraCHjy7RbrrANxKeDGMwCYlCAC N+khZc4wV8iY3e9dQGXz2A== =B9dz -----END PGP SIGNATURE----- --------------enig82191259A161826E6E145F39-- --===============0854554242== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0854554242==-- From tcpm-bounces@ietf.org Wed Mar 21 10:08:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU1TY-0004R7-2Y; Wed, 21 Mar 2007 10:07:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU1TX-0004Qs-Ca for tcpm@ietf.org; Wed, 21 Mar 2007 10:07:39 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU1TU-0003o6-JD for tcpm@ietf.org; Wed, 21 Mar 2007 10:07:39 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l2LE7ZTt022808; Wed, 21 Mar 2007 07:07:35 -0700 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 197CD91819C; Wed, 21 Mar 2007 10:07:30 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 756021B27FF; Wed, 21 Mar 2007 10:07:18 -0400 (EDT) To: Joe Touch From: Mark Allman Subject: Re: [tcpm] thoughts on draft-moncaster-tcpm-rcv-cheat-00 In-Reply-To: <460134CE.7070702@isi.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Thunderstruck MIME-Version: 1.0 Date: Wed, 21 Mar 2007 10:07:18 -0400 Message-Id: <20070321140718.756021B27FF@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1101148513==" Errors-To: tcpm-bounces@ietf.org --===============1101148513== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > It might be useful for test purposes. After re-reading the doc, I still > don't presume that it requires that all TCPs deploy this. I'd prefer if > it were more explicit, but my read was that it was intended as a way to > test - when testing is what you want to do. My read was much much different. My read of this document is that they are proposing a technique that normal everyday TCP senders should use to detect receivers that are attempting to fool the senders into transmitting faster than normal CC would allow. > I think we're agreeing; I agree this shouldn't be part of regular > operations, but still think the tests described could be useful for > informational purposes only. OK. If someone wrote an i-d that said this was a testing technique only and not meant for general use then I'd respond to that i-d differently, I bet. I am responding to what I believe this document is proposing ... and, that is a technique to vet receivers on-the-fly during normal operations to combat maliciousness. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGATwWWyrrWs4yIs4RAlHvAJ9FTyxjqX4KqEg/hyvnD0WsfID5dwCZAePH qqUh0OGTlkKobj7P3wLx/Uk= =dfto -----END PGP SIGNATURE----- --=_bOundary-- --===============1101148513== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1101148513==-- From tcpm-bounces@ietf.org Wed Mar 21 12:07:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU3Jr-0005lv-1r; Wed, 21 Mar 2007 12:05:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU3Jq-0005kx-59 for tcpm@ietf.org; Wed, 21 Mar 2007 12:05:46 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU1eD-0006Ux-Is for tcpm@ietf.org; Wed, 21 Mar 2007 10:18:43 -0400 Received: from [127.0.0.1] (c3-vpn6.isi.edu [128.9.176.244]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l2LEIJh8010308; Wed, 21 Mar 2007 07:18:22 -0700 (PDT) Message-ID: <46013EA0.1020302@isi.edu> Date: Wed, 21 Mar 2007 07:18:08 -0700 From: Joe Touch User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: mallman@icir.org Subject: Re: [tcpm] thoughts on draft-moncaster-tcpm-rcv-cheat-00 References: <20070321140718.756021B27FF@lawyers.icir.org> In-Reply-To: <20070321140718.756021B27FF@lawyers.icir.org> X-Enigmail-Version: 0.94.1.2.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1704649027==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1704649027== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1ECA70EFD1FD34CDF883EA0D" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1ECA70EFD1FD34CDF883EA0D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mark Allman wrote: =2E.. > OK. If someone wrote an i-d that said this was a testing technique onl= y > and not meant for general use then I'd respond to that i-d differently,= > I bet. I am responding to what I believe this document is proposing > ... and, that is a technique to vet receivers on-the-fly during normal > operations to combat maliciousness. I'll propose that this could be a change/clarification to the current document. Thoughts from others on the list? Joe --------------enig1ECA70EFD1FD34CDF883EA0D 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.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGAT6gE5f5cImnZrsRAiqEAKCpHRUIH/GKmjE4BekTS92Dt25u9QCfQXCr WlwYp+5pF6jo5TmO+q0bJ/Y= =BKrr -----END PGP SIGNATURE----- --------------enig1ECA70EFD1FD34CDF883EA0D-- --===============1704649027== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1704649027==-- From tcpm-bounces@ietf.org Wed Mar 21 12:23:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU3ag-0002Qt-L6; Wed, 21 Mar 2007 12:23:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU3af-0002Qa-Ao for tcpm@ietf.org; Wed, 21 Mar 2007 12:23:09 -0400 Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU3ac-0002vx-CV for tcpm@ietf.org; Wed, 21 Mar 2007 12:23:09 -0400 Received: from [10.10.64.154] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Wed, 21 Mar 2007 09:22:51 -0700 X-Server-Uuid: 20144BB6-FB76-4F11-80B6-E6B2900CA0D7 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id D33812B0; Wed, 21 Mar 2007 09:22:51 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id BFFA02AF for ; Wed, 21 Mar 2007 09:22:51 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FCB54461; Wed, 21 Mar 2007 09:22:51 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 8CD9169CA3 for ; Wed, 21 Mar 2007 09:22:51 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] thoughts on draft-moncaster-tcpm-rcv-cheat-00 Date: Wed, 21 Mar 2007 09:22:50 -0700 Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D032DE4C0@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <46013EA0.1020302@isi.edu> Thread-Topic: [tcpm] thoughts on draft-moncaster-tcpm-rcv-cheat-00 Thread-Index: Acdr0yNJi6Lj4bWUQN+Ho5YCI41kKgAAGbMw From: "Caitlin Bestler" To: tcpm@ietf.org X-WSS-ID: 6A1F845138G6649637-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Joe Touch wrote: > Mark Allman wrote: > ... >> OK. If someone wrote an i-d that said this was a testing technique >> only and not meant for general use then I'd respond to that i-d >> differently, I bet. I am responding to what I believe this document >> is proposing ... and, that is a technique to vet receivers on-the-fly >> during normal operations to combat maliciousness. >=20 > I'll propose that this could be a change/clarification to the > current document. Thoughts from others on the list? >=20 > Joe I fully agree with Mark's sentiments on this. The techniques proposed are not suitable for default deployment, especially not with anything even approach a SHOULD. In fact I would say that the test SHOULD NOT be used by anyone who has not considered it's potential adverse impacts.=20 The most important adverse impact is that any receiver has a finite capability for tracking gaps in the TCP sequence. Every gap that it tracks requires some resources. Not much, but it doesn't have to be when this is a per connection cost. There has already been an calculation made as to the optimal amount of resources to have available to minimize resource allocations while minimizing the risk of having to drop a=20 packet due to lack of resources to track one more gap. Since the receiver has no way of knowing which of its connections will be tested, it must make these extra resources available to all connections. If the specific receiver pre-allocates resources to each established connection then this could be a problem. The proposed test eats at that safety margins and/or requires that more safety margin be allocated. Neither should be forced onto receivers because some servers are incapable of protecting themselve with simple application layer defenses (like not transmitting more than X to an anonymous client). Doing the proposed test as part of network monitoring and/or diagnostics is completely reasonable. As is injecting noise to test network robustness. But neither is something that should be done routinely by a production stack. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Mar 21 12:52:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU428-0000Oz-Qs; Wed, 21 Mar 2007 12:51:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU428-0000Oj-0Y for tcpm@ietf.org; Wed, 21 Mar 2007 12:51:32 -0400 Received: from circular.cs.umd.edu ([128.8.128.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU41z-0005AK-HE for tcpm@ietf.org; Wed, 21 Mar 2007 12:51:31 -0400 Received: from loompa.cs.umd.edu (loompa.cs.umd.edu [128.8.128.63]) by circular.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id l2LGpHFq021503; Wed, 21 Mar 2007 12:51:17 -0400 Received: (from capveg@localhost) by loompa.cs.umd.edu (8.12.10/8.12.5) id l2LGpHI3004494; Wed, 21 Mar 2007 12:51:17 -0400 (EDT) Date: Wed, 21 Mar 2007 12:51:17 -0400 From: Rob Sherwood To: Mark Allman Subject: Re: [tcpm] thoughts on draft-moncaster-tcpm-rcv-cheat-00 Message-ID: <20070321165116.GR13202@loompa.cs.umd.edu> References: <20070320194823.34FCF1B1504@lawyers.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070320194823.34FCF1B1504@lawyers.icir.org> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Tue, Mar 20, 2007 at 03:48:23PM -0400, Mark Allman wrote: > (2) Who Do We Trust? > > In some sense this all comes down to whether we want to continue to > trust receivers. We certainly trust senders to do the right thing. > The network should probably do something about this state of > affairs. But, wouldn't that also help with the problem of receivers > coaxing the sender to transmit faster than appropriate? Fate > sharing and all. If we trust the senders then why not trust the > receivers are likely to be doing the right thing? How paranoid do > we want to be for what sort of benefit? > > This is my main question... I would argue that up until this point > we have seen no big problems with the current trust model. So, what > is the benefit of deciding we no longer generally trust receivers > (for congestion control purposes) and what is the cost? I would argue that we don't, or at least *shouldn't*, trust senders either. You say there have been no big problems with the current trust model, but DDoS attacks are a serious issue for many operators, and the heart of the problem is that those senders are not trusted to send useful data. The difference is that there is no clear solution to the malicious sender problem (to be fair, researchers are working on this), but I don't see this as a good reason to not solve the untrusted receiver end of the problem. > (3) New Options. > > It seems odd to me that in some places in the document the authors > admit that a cooperative option could be incentivized and in others > they ignore this. I.e., a general transport nonce could be required > by the sender to send quite fast. So, a receiver cannot just ignore > it and expect good service. Seems reasonable to me. (Exact policy > and how to phase this in seems like a detail.) As per previous mails, I don't believe this style differentiated-service solution would solve the general DoS problem. If nodes that do not negotiate the nonce have service reduced to some smallish maximum rate, e.g., 5 KB/s, then a malicious attacker needs to just connect to many more servers to obtain the same amount of malicious traffic. Hundreds of thousands of servers, all sending at 5KB/s, is still a significant/dangerous amount of traffic. The high level concern is that it is not possible for servers to coordinate among themselve to rate limit the total amount of traffic caused by a single malicious receiver. > (7) An Alternate Scheme. > > There is another scheme that has been floated that you did not > mention. In "DoS vulnerability of TCP by acknowledging not received > segments" (draft-azcorra-tcpm-tcp-blind-ack-dos-01.txt; expired, but > I am sure you can all find it) the authors propose essentially using > the sequence space for a singular nonce. That is, vary the packet > size a bit (randomly) and watching for ACKs that do not land on the > right segment boundaries. At the very least this should be > mentioned. > > (This was presented to the TCPM WG a while back (and, TSVWG too, I > think). It gained no traction. Before I knew of this draft, I came up with and discarded this solution, as described in the extended version of my CCS paper (http://www.cs.umd.edu/~capveg/optack/optack-extended.pdf). It's two faults are that the ACKs are not cummulative, allowing the lazy version of the attack to persist, and the concern that network middleboxes (NATs,proxies,etc.) could be repacking packet sizes, breaking the correctness of this scheme. The extended version of the paper also covers a litany of other possible solutions and how they compare to the skipped segments solution. Also, relative to Joe's comments: I too read this draft as a amendment to the "standard,everyone's,everywhere's" TCP, and not just for testing purposes. - Rob . _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Mar 21 13:26:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU4YV-0006lu-Ia; Wed, 21 Mar 2007 13:24:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU4XF-00042E-BT for tcpm@ietf.org; Wed, 21 Mar 2007 13:23:41 -0400 Received: from circular.cs.umd.edu ([128.8.128.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU4V6-00047s-CP for tcpm@ietf.org; Wed, 21 Mar 2007 13:21:29 -0400 Received: from loompa.cs.umd.edu (loompa.cs.umd.edu [128.8.128.63]) by circular.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id l2LHLPl0021457; Wed, 21 Mar 2007 13:21:25 -0400 Received: (from capveg@localhost) by loompa.cs.umd.edu (8.12.10/8.12.5) id l2LHLPVd005320; Wed, 21 Mar 2007 13:21:25 -0400 (EDT) Date: Wed, 21 Mar 2007 13:21:25 -0400 From: Rob Sherwood To: Caitlin Bestler Subject: Re: [tcpm] thoughts on draft-moncaster-tcpm-rcv-cheat-00 Message-ID: <20070321172125.GT13202@loompa.cs.umd.edu> References: <46013EA0.1020302@isi.edu> <1EF1E44200D82B47BD5BA61171E8CE9D032DE4C0@NT-IRVA-0750.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1EF1E44200D82B47BD5BA61171E8CE9D032DE4C0@NT-IRVA-0750.brcm.ad.broadcom.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Wed, Mar 21, 2007 at 09:22:50AM -0700, Caitlin Bestler wrote: > The most important adverse impact is that any receiver has a > finite capability for tracking gaps in the TCP sequence. Every > gap that it tracks requires some resources. Not much, but it > doesn't have to be when this is a per connection cost. I don't understand this concern -- each the receiver's rcvbuf is advertised with each packet, no? A receiver should not advertise more then it can actually buffer, so as long as the TCP test respects the window, is this really a concern? - Rob . _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Mar 21 13:48:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU4vR-0006Pg-G5; Wed, 21 Mar 2007 13:48:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU4vP-0006PQ-IX for tcpm@ietf.org; Wed, 21 Mar 2007 13:48:39 -0400 Received: from mms1.broadcom.com ([216.31.210.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU4vO-0002NU-6r for tcpm@ietf.org; Wed, 21 Mar 2007 13:48:39 -0400 Received: from [10.10.64.154] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Wed, 21 Mar 2007 10:48:25 -0700 X-Server-Uuid: 6B5CFB92-F616-4477-B110-55F967A57302 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 48AE12AE; Wed, 21 Mar 2007 10:48:25 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 22B282AF; Wed, 21 Mar 2007 10:48:25 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FCB79963; Wed, 21 Mar 2007 10:48:24 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 26E9769CA3; Wed, 21 Mar 2007 10:48:23 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] thoughts on draft-moncaster-tcpm-rcv-cheat-00 Date: Wed, 21 Mar 2007 10:48:20 -0700 Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D032DE572@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <20070321172125.GT13202@loompa.cs.umd.edu> Thread-Topic: [tcpm] thoughts on draft-moncaster-tcpm-rcv-cheat-00 Thread-Index: Acdr3W9exYXunlMSRJKb7NC4o0cWsAAAue/Q From: "Caitlin Bestler" To: "Rob Sherwood" X-WSS-ID: 6A1FB0633706625679-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Rob Sherwood wrote: > On Wed, Mar 21, 2007 at 09:22:50AM -0700, Caitlin Bestler wrote: >> The most important adverse impact is that any receiver has a finite >> capability for tracking gaps in the TCP sequence. Every gap that it >> tracks requires some resources. Not much, but it doesn't have to be >> when this is a per connection cost. >=20 > I don't understand this concern -- each the receiver's rcvbuf > is advertised with each packet, no? A receiver should not > advertise more then it can actually buffer, so as long as the > TCP test respects the window, is this really a concern? >=20 > - Rob > . It is not the buffer space that is in question. It is remembering the number of disjoint sequences that have been received. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Mar 21 13:50:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU4xL-0007o7-87; Wed, 21 Mar 2007 13:50:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU4xK-0007o0-PM for tcpm@ietf.org; Wed, 21 Mar 2007 13:50:38 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU4xD-0002mI-Uh for tcpm@ietf.org; Wed, 21 Mar 2007 13:50:38 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id AC31FF0C46F; Wed, 21 Mar 2007 14:50:01 -0300 (ART) Received: from fgont.gont.com.ar (113-165-231-201.fibertel.com.ar [201.231.165.113]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id l2LHnmls014912; Wed, 21 Mar 2007 14:49:59 -0300 Message-Id: <200703211749.l2LHnmls014912@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 21 Mar 2007 12:22:54 -0300 To: Arifumi Matsumoto From: Fernando Gont Subject: Re: [tcpm] ICMPv6 Error Handling at TCP draft-fujisaki-tcpm-icmpv6-reaction-00.txt In-Reply-To: <4600FB7E.7030700@nttv6.net> References: <45F0E432.5040401@nttv6.net> <7.0.1.0.0.20070318041131.07eb4868@gont.com.ar> <20070320.033345.189731342.fujisaki@syce.net> <200703191935.l2JJZL2i013753@venus.xmundo.net> <7b1e7a950703200603x5ca6cacbxe049d04879aae79c@mail.gmail.com> <200703201831.l2KIVkl8012269@venus.xmundo.net> <4600FB7E.7030700@nttv6.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Wed, 21 Mar 2007 14:50:01 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 06:31 a.m. 21/03/2007, Arifumi Matsumoto wrote: >Anyway, it doesn't matter which specific ICMPv6 code falls into hard >or soft here. Exactly. That's why it doesn't make sense to do the mapping from ICMPv6 to ICMPv4. The point is that there's no clear definition of what is a hard error or a soft error. There's no such thing as soft or hard by itself. It depends *when* you receive the error message. Defining ICMP admin prohibited as soft or hard is IMHO pointless. >This is my opinion about RFC1122-revision and soft-error RFC >relationship. As soft-error RFC will be informational in the immediate >future, IMO all the vendors that implements RFC1122 may not even >notice or take a look at it. We have had this discussion of Informational vs. Std track for one or two *years*, more than one year ago. And the WG agreed on Informational. As for vendors not looking at Informational docs.... I don't buy that at all. Let's be clear: Any vendor with a clue will (or what's the purpose of Informational docs, after all?). As a matter of fact, many vendors already look at internet drafts. The ICMP attacks draft is aiming at Informational, too. Yet virtually all vendors have implemented most of it. Nobody ever bothered whether it was Std track or Informational. If your specific problem arises from use of IPv6, then you can send the vendor (Microsoft?) the soft errors draft, and even direct them to the v6fix site. If that's not enough, I guess the only thing left is to have their clients tell them that it really sucks to have to wait dozens of seconds to browse a web page. -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Mar 21 14:11:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU5Gl-0006LY-6G; Wed, 21 Mar 2007 14:10:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU5GY-00063P-3T for tcpm@ietf.org; Wed, 21 Mar 2007 14:10:30 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU5CV-00017p-Fr for tcpm@ietf.org; Wed, 21 Mar 2007 14:06:20 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l2LI6DT6027716; Wed, 21 Mar 2007 11:06:13 -0700 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 5EB6E91A252; Wed, 21 Mar 2007 14:06:07 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 3D3381B2FDC; Wed, 21 Mar 2007 14:04:12 -0400 (EDT) To: Rob Sherwood From: Mark Allman Subject: Re: [tcpm] thoughts on draft-moncaster-tcpm-rcv-cheat-00 In-Reply-To: <20070321165116.GR13202@loompa.cs.umd.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Thunderstruck MIME-Version: 1.0 Date: Wed, 21 Mar 2007 14:04:12 -0400 Message-Id: <20070321180412.3D3381B2FDC@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1684244914==" Errors-To: tcpm-bounces@ietf.org --===============1684244914== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > On Tue, Mar 20, 2007 at 03:48:23PM -0400, Mark Allman wrote: > > (2) Who Do We Trust? > > > > In some sense this all comes down to whether we want to continue to > > trust receivers. We certainly trust senders to do the right thing. > > The network should probably do something about this state of > > affairs. But, wouldn't that also help with the problem of receivers > > coaxing the sender to transmit faster than appropriate? Fate > > sharing and all. If we trust the senders then why not trust the > > receivers are likely to be doing the right thing? How paranoid do > > we want to be for what sort of benefit? > > > > This is my main question... I would argue that up until this point > > we have seen no big problems with the current trust model. So, what > > is the benefit of deciding we no longer generally trust receivers > > (for congestion control purposes) and what is the cost? > > I would argue that we don't, or at least *shouldn't*, trust senders > either. You say there have been no big problems with the current > trust model, but DDoS attacks are a serious issue for many operators, > and the heart of the problem is that those senders are not trusted to > send useful data. The difference is that there is no clear solution > to the malicious sender problem (to be fair, researchers are working > on this), but I don't see this as a good reason to not solve the > untrusted receiver end of the problem. I was not clear. Trusting senders to control their own rates is stupid. I do not want to get into a discussion about congestion control theory. But, even in a world that looks like the one we have now where we do have reliance on the senders to do roughly the right thing we should still be able to check that and verify it in some way. At the end of the day the network needs to protect itself. Further, my ambiguous writing above about not having big problems with the current trust model was in reference to the trust we have in the receivers. Certainly we have had problems with the trust we place in senders. Is the delta of trusting the receivers a big enough deal to worry about separately or should that just fall under the concept of fate sharing and we should just let something hammer on the sender that is spewing inappropriately? Is the threat posed by receivers lying big enough to add a bunch of goop to implementations? If I could ever so briefly put my co-chair hat back on ... I'm interested in people's thoughts on this issue and document. I know what the people with solutions think. I know what I have been saying for a good long while. I'd like to know what other people think. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGAXObWyrrWs4yIs4RAoA+AJ46MPedF7lYSBCOdgRkMxPuhroPaQCcCrlP AOC2uq52W6qNRs7Nd11AmEE= =vMPU -----END PGP SIGNATURE----- --=_bOundary-- --===============1684244914== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1684244914==-- From tcpm-bounces@ietf.org Wed Mar 21 14:16:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU5MY-0000SE-LZ; Wed, 21 Mar 2007 14:16:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU5MX-0000S6-Bk for tcpm@ietf.org; Wed, 21 Mar 2007 14:16:41 -0400 Received: from [2001:fa8::25] (helo=mail.nttv6.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU5MS-0004N3-PL for tcpm@ietf.org; Wed, 21 Mar 2007 14:16:41 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.nttv6.net (8.14.0/8.13.8) with ESMTP id l2LIG1R4059477; Thu, 22 Mar 2007 03:16:02 +0900 (JST) (envelope-from arifumi@nttv6.net) Message-ID: <46017660.6060704@nttv6.net> Date: Thu, 22 Mar 2007 03:16:00 +0900 From: Arifumi Matsumoto User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] ICMPv6 Error Handling at TCP draft-fujisaki-tcpm-icmpv6-reaction-00.txt References: <45F0E432.5040401@nttv6.net> <7.0.1.0.0.20070318041131.07eb4868@gont.com.ar> <20070320.033345.189731342.fujisaki@syce.net> <200703191935.l2JJZL2i013753@venus.xmundo.net> <7b1e7a950703200603x5ca6cacbxe049d04879aae79c@mail.gmail.com> <200703201831.l2KIVkl8012269@venus.xmundo.net> <4600FB7E.7030700@nttv6.net> <200703211749.l2LHnmls014912@venus.xmundo.net> In-Reply-To: <200703211749.l2LHnmls014912@venus.xmundo.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.8 (--) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Fernando Gont wrote: > At 06:31 a.m. 21/03/2007, Arifumi Matsumoto wrote: > >> Anyway, it doesn't matter which specific ICMPv6 code falls into hard >> or soft here. > > Exactly. That's why it doesn't make sense to do the mapping from ICMPv6 > to ICMPv4. The point is that there's no clear definition of what is a > hard error or a soft error. There's no such thing as soft or hard by > itself. It depends *when* you receive the error message. Defining ICMP > admin prohibited as soft or hard is IMHO pointless. No. I mean it doesn't matter in this example admin prohibit is hard or soft as far as there is hard error. >> This is my opinion about RFC1122-revision and soft-error RFC >> relationship. As soft-error RFC will be informational in the immediate >> future, IMO all the vendors that implements RFC1122 may not even >> notice or take a look at it. > > We have had this discussion of Informational vs. Std track for one or > two *years*, more than one year ago. And the WG agreed on Informational. > > As for vendors not looking at Informational docs.... I don't buy that at > all. Let's be clear: Any vendor with a clue will (or what's the purpose > of Informational docs, after all?). As a matter of fact, many vendors > already look at internet drafts. > > The ICMP attacks draft is aiming at Informational, too. Yet virtually > all vendors have implemented most of it. Nobody ever bothered whether it > was Std track or Informational. IMO, ICMP attack draft addresses a security problem, so it may be easier to make people move. > If your specific problem arises from use of IPv6, then you can send the > vendor (Microsoft?) the soft errors draft, and even direct them to the > v6fix site. If that's not enough, I guess the only thing left is to have > their clients tell them that it really sucks to have to wait dozens of > seconds to browse a web page. It may work for my specific problem. For the benefit of every people using the Internet, which way should we take ? I'd like to know everybody's opnion in this wg. I'm glad if you could drop me a line on-list or off-list. Kindest regards. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Mar 21 14:38:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU5gy-0006KB-7l; Wed, 21 Mar 2007 14:37:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU5gw-0006Ji-Mc for tcpm@ietf.org; Wed, 21 Mar 2007 14:37:46 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU5gv-0001au-7V for tcpm@ietf.org; Wed, 21 Mar 2007 14:37:46 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2LIbOxZ027215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Mar 2007 11:37:24 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.8/8.13.8/Submit) id l2LIbOAC055046; Wed, 21 Mar 2007 11:37:24 -0700 (PDT) (envelope-from faber) Date: Wed, 21 Mar 2007 11:37:24 -0700 From: Ted Faber To: Joe Touch Subject: Re: [tcpm] Hat off: tcpsecure mitigations Message-ID: <20070321183724.GQ49963@hut.isi.edu> References: <45FF6D98.8090405@isi.edu> <13D1EAB852BE194C94773A947138483D0334AD40@xmb-sjc-21c.amer.cisco.com> <20070320225009.GF31461@hut.isi.edu> <46006ECE.7080206@isi.edu> <4600761A.9050107@isi.edu> <20070321013739.GR35849@hut.isi.edu> <4600D542.5000207@isi.edu> Mime-Version: 1.0 In-Reply-To: <4600D542.5000207@isi.edu> User-Agent: Mutt/1.4.2.2i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: tcpm@ietf.org, "Mitesh Dalal \(mdalal\)" , "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1687434043==" Errors-To: tcpm-bounces@ietf.org --===============1687434043== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3wfpuDtTLg8/Vq6g" Content-Disposition: inline --3wfpuDtTLg8/Vq6g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 20, 2007 at 11:48:34PM -0700, Joe Touch wrote: >=20 >=20 > Ted Faber wrote: > > On Tue, Mar 20, 2007 at 05:02:34PM -0700, Joe Touch wrote: > >> > >> Joe Touch wrote: > >> ... > >>> This is the problem.SHOULD not implemented needs to come with a reaso= n. > >>> If we know that reason now - e.g., a host that isn't running a > >>> well-known service with both endpoints likely known - then we ought to > >>> state it as a known exception. > >> PS - let me give a more specific equivalent: > >> > >> All TCP implementations SHOULD implement TCP/MD5. > >=20 > > I would argue against such a suggestion on the basis that the complexity > > and overhead of TCP/MD5 are significant and most hosts are not menaced = by > > the attacks this heavy-weight protection prevents. The off-path RST and > > SYN mitigations are so simple and inexpensive that I'm comfortable with > > a SHOULD. > >=20 > > Most hosts don't need TIME-WAIT, either, but for most hosts it's > > inexpensive. >=20 > TIME-WAIT is required for correct, safe operation between two endpoints. Are *we* really going to argue about TIME-WAIT? You know that the "correct operation" "guaranteed" by TIME-WAIT is only exercised upon the occurrance of a very unlikely set of events (delayed packets from an old connection arriving at a new connection between the same TCP socket (4-tuple) in an overlapping sequence number window) and that the "guarantee" entirely depends on an MSL parameter that's unenforced by the network and set at the whim of sysadmins. I know you know that because we've beaten it to death and then published about it. TIME-WAIT guards against an unlikely occurance by assertation of correctness. >=20 > This solution sacrifices good protocol design (never respond to a RST, > in specific, and 'keep it simple' in general) in an attempt to provide > protection from deliberate attacks It also defends against a delayed RST in the same case TIME-WAIT protects against in the event that TIME-WAIT's "guarantee" wasn't met because of a misconfigured local value for MSL. > protection that is already > sufficient unless both endpoint addresses and a port number is known, > and protection that's insufficient against data injection in-window, as > well as ICMP attacks that can shut a connection just as easily (and > CANNOT need to be in-window, since there are no timing requirements for > ICMP responses). And it costs about 6 machine instructions to implement without breaking any existing TCP implementations. I'm quite delighted to SHOULD it based on technical merit. >=20 > It's not required for correct operation, and it's not sufficient for > safe operation. And its encumbered. Now encumberance is a better argument. > A SHOULD would burden implementers with needing to justify why their > TCPs did not support this requirement, and avoiding encumberence may not > be sufficient. >=20 > This may be simple, but its expense is in the eye of the implementer. >=20 > For all these reasons, a MAY is appropriate, but a SHOULD is not. I disagree with "all," but I may be swayable based on IPR. Can we get a ruling from the non-arguing chair about whether IPR is on the table for the discussion of the SHOULD/MAY issue? --=20 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 --3wfpuDtTLg8/Vq6g Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (FreeBSD) iD8DBQFGAXtkaUz3f+Zf+XsRAsv7AKCKx/br6vOhLVHbEhmqLd27WSxIPQCeJgpF cnypm5bMH9mMX0qCyTIpEp0= =+ik8 -----END PGP SIGNATURE----- --3wfpuDtTLg8/Vq6g-- --===============1687434043== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1687434043==-- From tcpm-bounces@ietf.org Wed Mar 21 14:44:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU5n7-0005Tf-GM; Wed, 21 Mar 2007 14:44:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU5n6-0005T3-SA for tcpm@ietf.org; Wed, 21 Mar 2007 14:44:08 -0400 Received: from mail.syce.net ([2001:218:4fd::25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU5n4-0003JZ-SQ for tcpm@ietf.org; Wed, 21 Mar 2007 14:44:08 -0400 Received: from localhost (localhost.syce.net [IPv6:::1]) by mail.syce.net (8.13.1/8.13.1) with ESMTP/inet6 id l2LIhII3054409; Thu, 22 Mar 2007 03:43:19 +0900 (JST) (envelope-from fujisaki@syce.net) Date: Thu, 22 Mar 2007 03:41:43 +0900 (JST) Message-Id: <20070322.034143.783370888.fujisaki@syce.net> To: fernando@gont.com.ar Subject: Re: [tcpm] ICMPv6 Error Handling at TCP draft-fujisaki-tcpm-icmpv6-reaction-00.txt From: (Tomohiro -INSTALLER- =?iso-2022-jp?B?RnVqaXNha2kvGyRCRiM6ahsoQiAbJEJDUjkoGyhC?=) In-Reply-To: <200703211749.l2LHnmls014912@venus.xmundo.net> References: <200703201831.l2KIVkl8012269@venus.xmundo.net> <4600FB7E.7030700@nttv6.net> <200703211749.l2LHnmls014912@venus.xmundo.net> X-Mailer: Mew version 5.2 on XEmacs 21.4.20 (Double Solitaire) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: -2.8 (--) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Hi, | >Anyway, it doesn't matter which specific ICMPv6 code falls into hard | >or soft here. | | Exactly. That's why it doesn't make sense to do the mapping from | ICMPv6 to ICMPv4. What he want to say is the classification of ICMPv6 is further discussion. He did not say the mapping does not make sense. RFC1122 is valid spec, and some systems implement RFC1122 TCP reaction in SYN-SENT state. We want IPv6 nodes to react similarly. | The ICMP attacks draft is aiming at Informational, too. Yet virtually | all vendors have implemented most of it. Nobody ever bothered whether | it was Std track or Informational. Is it in reverse order, isn't it? Many vendors implement not to disconnect established TCP session because it would have security risks. And then ICMP attacks draft was written, as far as I read ML archives. | If your specific problem arises from use of IPv6, then you can send | the vendor (Microsoft?) the soft errors draft, and even direct them | to the v6fix site. If that's not enough, I guess the only thing left | is to have their clients tell them that it really sucks to have to | wait dozens of seconds to browse a web page. Sorry for repeatedly, but we think soft errors draft does not provide enough information to implement the TCP reaction. We are afraid every system react differently when it receives ICMP errors. Yours Sincerely, -- Tomohiro Fujisaki _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Mar 21 14:50:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU5tC-0006kI-Jy; Wed, 21 Mar 2007 14:50:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU5tB-0006k7-Kd for tcpm@ietf.org; Wed, 21 Mar 2007 14:50:25 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU5t7-0004wl-JR for tcpm@ietf.org; Wed, 21 Mar 2007 14:50:25 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id BE207F0C573; Wed, 21 Mar 2007 15:49:40 -0300 (ART) Received: from fgont.gont.com.ar (113-165-231-201.fibertel.com.ar [201.231.165.113]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id l2LInXvY007519; Wed, 21 Mar 2007 15:49:33 -0300 Message-Id: <200703211849.l2LInXvY007519@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 21 Mar 2007 15:40:36 -0300 To: Arifumi Matsumoto From: Fernando Gont Subject: Re: [tcpm] ICMPv6 Error Handling at TCP draft-fujisaki-tcpm-icmpv6-reaction-00.txt In-Reply-To: <46017660.6060704@nttv6.net> References: <45F0E432.5040401@nttv6.net> <7.0.1.0.0.20070318041131.07eb4868@gont.com.ar> <20070320.033345.189731342.fujisaki@syce.net> <200703191935.l2JJZL2i013753@venus.xmundo.net> <7b1e7a950703200603x5ca6cacbxe049d04879aae79c@mail.gmail.com> <200703201831.l2KIVkl8012269@venus.xmundo.net> <4600FB7E.7030700@nttv6.net> <200703211749.l2LHnmls014912@venus.xmundo.net> <46017660.6060704@nttv6.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Wed, 21 Mar 2007 15:49:40 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 03:16 p.m. 21/03/2007, Arifumi Matsumoto wrote: >>>Anyway, it doesn't matter which specific ICMPv6 code falls into hard >>>or soft here. >>Exactly. That's why it doesn't make sense to do the mapping from >>ICMPv6 to ICMPv4. The point is that there's no clear definition of >>what is a hard error or a soft error. There's no such thing as soft >>or hard by itself. It depends *when* you receive the error message. >>Defining ICMP admin prohibited as soft or hard is IMHO pointless. > >No. I mean it doesn't matter in this example admin prohibit is hard >or soft as far as there is hard error. You have RSTs. >>>This is my opinion about RFC1122-revision and soft-error RFC >>>relationship. As soft-error RFC will be informational in the immediate >>>future, IMO all the vendors that implements RFC1122 may not even >>>notice or take a look at it. >>We have had this discussion of Informational vs. Std track for one >>or two *years*, more than one year ago. And the WG agreed on Informational. >>As for vendors not looking at Informational docs.... I don't buy >>that at all. Let's be clear: Any vendor with a clue will (or what's >>the purpose of Informational docs, after all?). As a matter of >>fact, many vendors already look at internet drafts. >>The ICMP attacks draft is aiming at Informational, too. Yet >>virtually all vendors have implemented most of it. Nobody ever >>bothered whether it was Std track or Informational. > >IMO, ICMP attack draft addresses a security problem, so it may be easier >to make people move. Then the issue you are raising is political, not technical. >>If your specific problem arises from use of IPv6, then you can send >>the vendor (Microsoft?) the soft errors draft, and even direct them >>to the v6fix site. If that's not enough, I guess the only thing >>left is to have their clients tell them that it really sucks to >>have to wait dozens of seconds to browse a web page. > >It may work for my specific problem. For the benefit of every >people using the Internet, which way should we take ? I don't see the difference. You have a document that describes a problem, and a workaround. If an implementation suffers the described problem, send them the doc. After that, is up to them to do something, or not. -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Mar 21 15:26:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU6RL-00058V-Sh; Wed, 21 Mar 2007 15:25:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU6RK-0004u4-MP for tcpm@ietf.org; Wed, 21 Mar 2007 15:25:42 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU6Ql-00064g-NE for tcpm@ietf.org; Wed, 21 Mar 2007 15:25:12 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 5D716F0C5B9; Wed, 21 Mar 2007 16:14:50 -0300 (ART) Received: from fgont.gont.com.ar (113-165-231-201.fibertel.com.ar [201.231.165.113]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id l2LJEkxN000499; Wed, 21 Mar 2007 16:14:47 -0300 Message-Id: <200703211914.l2LJEkxN000499@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 21 Mar 2007 16:12:17 -0300 To: (Tomohiro -INSTALLER- =?iso-2022-jp?B?RnVqaXNha2kvGyRCRiM6ahsoQiAbJEJDUjkoGyhC?=) From: Fernando Gont Subject: Re: [tcpm] ICMPv6 Error Handling at TCP draft-fujisaki-tcpm-icmpv6-reaction-00.txt In-Reply-To: <20070322.034143.783370888.fujisaki@syce.net> References: <200703201831.l2KIVkl8012269@venus.xmundo.net> <4600FB7E.7030700@nttv6.net> <200703211749.l2LHnmls014912@venus.xmundo.net> <20070322.034143.783370888.fujisaki@syce.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Wed, 21 Mar 2007 16:14:50 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 03:41 p.m. 21/03/2007, Tomohiro -INSTALLER- wrote: > | The ICMP attacks draft is aiming at Informational, too. Yet virtually > | all vendors have implemented most of it. Nobody ever bothered whether > | it was Std track or Informational. > >Is it in reverse order, isn't it? Many vendors implement not to >disconnect established TCP session because it would have security >risks. And then ICMP attacks draft was written, as far as I read ML >archives. BSD systems do not abort established connection in response to ICMP messages because the developers thought that that would negatively affect robustness. Those implementations that implemented this behavior in the last three years or so did that in response to the ICMP attacks draft. > | If your specific problem arises from use of IPv6, then you can send > | the vendor (Microsoft?) the soft errors draft, and even direct them > | to the v6fix site. If that's not enough, I guess the only thing left > | is to have their clients tell them that it really sucks to have to > | wait dozens of seconds to browse a web page. > >Sorry for repeatedly, but we think soft errors draft does not provide >enough information to implement the TCP reaction. We are afraid every >system react differently when it receives ICMP errors. Perfect. Do you have any specific suggestion on how to improve the draft, so it addresses your concerns? Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Mar 21 15:51:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU6pK-0004od-Vb; Wed, 21 Mar 2007 15:50:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU6pK-0004oT-67 for tcpm@ietf.org; Wed, 21 Mar 2007 15:50:30 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU6pH-0005oy-2n for tcpm@ietf.org; Wed, 21 Mar 2007 15:50:30 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l2LJoPfc029909; Wed, 21 Mar 2007 12:50:26 -0700 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 0CABA91B425; Wed, 21 Mar 2007 15:50:20 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 0F06B1B3331; Wed, 21 Mar 2007 15:50:20 -0400 (EDT) To: Ted Faber From: Mark Allman Subject: Re: [tcpm] Hat off: tcpsecure mitigations In-Reply-To: <20070321183724.GQ49963@hut.isi.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Thunderstruck MIME-Version: 1.0 Date: Wed, 21 Mar 2007 15:50:19 -0400 Message-Id: <20070321195020.0F06B1B3331@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , "Mitesh Dalal \(mdalal\)" , Joe Touch X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0784077161==" Errors-To: tcpm-bounces@ietf.org --===============0784077161== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The subject still contains 'hat off', but I am wearing my co-chair hat for this note. > Can we get a ruling from the non-arguing chair about whether IPR is on > the table for the discussion of the SHOULD/MAY issue? I will just re-iterate what I said yesterday. The presence of an IPR statement can absolutely be used to inform decisions of the WG. In particular, the WG is well within its rights to use Cisco's IPR statement on tcpsecure as part of the process of deciding that the mechanisms contained in that draft ought to be MAY, SHOULD or MUSTs. The IPR statement is *one* piece of information that can be used in the decision process. There are other factors that can also be brought to bear on the decision: importance of the mitigation, completeness of solution, complexity of the solution, etc. Finally, we do not need one answer for the entire draft, but can have an answer for each mechanism in the draft. I would also invite other people to weigh in on this topic. How strongly should we specify these mechanisms? MUST? SHOULD? MAY? I don't yet feel like I really have a sense of the WG's feelings on this matter, so please send your opinions. Thanks, allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGAYx7WyrrWs4yIs4RAhvNAKCfY9M6LoIHV0qgtLGPteQSdghYawCdEiHx AmnW3JkXDm/Z4bW4htXuwo0= =s8kp -----END PGP SIGNATURE----- --=_bOundary-- --===============0784077161== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0784077161==-- From tcpm-bounces@ietf.org Thu Mar 22 06:57:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUKx1-0007r0-8p; Thu, 22 Mar 2007 06:55:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUKx0-0007ql-B6 for tcpm@ietf.org; Thu, 22 Mar 2007 06:55:22 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUKwx-0001f2-0l for tcpm@ietf.org; Thu, 22 Mar 2007 06:55:22 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 22 Mar 2007 03:55:19 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2MAtItP008357; Thu, 22 Mar 2007 03:55:18 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2MAtIMF000323; Thu, 22 Mar 2007 10:55:18 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 03:55:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] thoughts on draft-moncaster-tcpm-rcv-cheat-00 Date: Thu, 22 Mar 2007 03:55:17 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5803115052@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <1EF1E44200D82B47BD5BA61171E8CE9D032DE572@NT-IRVA-0750.brcm.ad.broadcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] thoughts on draft-moncaster-tcpm-rcv-cheat-00 Thread-Index: Acdr3W9exYXunlMSRJKb7NC4o0cWsAAAue/QACPv7CA= From: "Anantha Ramaiah \(ananth\)" To: "Caitlin Bestler" , "Rob Sherwood" X-OriginalArrivalTime: 22 Mar 2007 10:55:18.0083 (UTC) FILETIME=[94235930:01C76C70] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=686; t=1174560918; x=1175424918; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20\(ananth\)=22=20 |Subject:=20RE=3A=20[tcpm]=20thoughts=20on=20draft-moncaster-tcpm-rcv-che at-00 |Sender:=20; bh=V1evaTpMS3nPCjs0jq0hRAWR/vaUHsu+bOrds3duVpQ=; b=eQy43WHNnZItTCyLWJM5uQkVRW2GWC9x4BMVaKfLj/ZKixJrSEaLgBu029slrrfwIi7p9+pf On+yiO9U+tOjnYweqeCcHiolMMxnW9Xznly1VgZmfEvCJ90PYZ14scjj; Authentication-Results: sj-dkim-2; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org =20 > >=20 > > I don't understand this concern -- each the receiver's rcvbuf is=20 > > advertised with each packet, no? A receiver should not=20 > advertise more=20 > > then it can actually buffer, so as long as the TCP test=20 > respects the=20 > > window, is this really a concern? > >=20 > > - Rob > > . >=20 > It is not the buffer space that is in question. It is=20 > remembering the number of disjoint sequences that have been received. FWIW, almost all TCP stacks have the counters maintained on a per TCP connection basis for out-of-order bytes/data received, # of times fast-retransmissions etc., not sure to what degree these would help here. -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Mar 22 07:05:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUL6O-0002Xq-AV; Thu, 22 Mar 2007 07:05:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUL6N-0002Xg-A8 for tcpm@ietf.org; Thu, 22 Mar 2007 07:05:03 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HUL6I-0006nG-7V for tcpm@ietf.org; Thu, 22 Mar 2007 07:05:03 -0400 Received: from [127.0.0.1] (c1-vpn2.isi.edu [128.9.176.28]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l2MB4Pxe000528; Thu, 22 Mar 2007 04:04:27 -0700 (PDT) Message-ID: <460262AE.6050807@isi.edu> Date: Thu, 22 Mar 2007 04:04:14 -0700 From: Joe Touch User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: [tcpm] thoughts on draft-moncaster-tcpm-rcv-cheat-00 References: <0C53DCFB700D144284A584F54711EC5803115052@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5803115052@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.94.1.2.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0825798965==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0825798965== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig26150101EAE0989758488D74" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig26150101EAE0989758488D74 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anantha Ramaiah (ananth) wrote: > =20 >>> I don't understand this concern -- each the receiver's rcvbuf is=20 >>> advertised with each packet, no? A receiver should not=20 >> advertise more=20 >>> then it can actually buffer, so as long as the TCP test=20 >> respects the=20 >>> window, is this really a concern? >>> >>> - Rob >>> . >> It is not the buffer space that is in question. It is=20 >> remembering the number of disjoint sequences that have been received. >=20 > FWIW, almost all TCP stacks have the counters maintained on a per TCP > connection basis for out-of-order bytes/data received, # of times > fast-retransmissions etc., not sure to what degree these would help > here. High-speed, high-performance (large number of connections) systems may not have all these counters, and shouldn't be required to. Joe --------------enig26150101EAE0989758488D74 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.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGAmKuE5f5cImnZrsRAk+BAJ9eq1zKIn87fis9MENzZvTedPDoRwCgx1tb 93ciREnXm9G1ZnoMDo2wF44= =54gM -----END PGP SIGNATURE----- --------------enig26150101EAE0989758488D74-- --===============0825798965== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0825798965==-- From tcpm-bounces@ietf.org Thu Mar 22 07:12:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HULDh-00074b-OI; Thu, 22 Mar 2007 07:12:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HULDf-00074O-QM for tcpm@ietf.org; Thu, 22 Mar 2007 07:12:35 -0400 Received: from [2001:770:68:ff::1] (helo=kac.cnri.dit.ie) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HULDe-0007Ii-9Y for tcpm@ietf.org; Thu, 22 Mar 2007 07:12:35 -0400 Received: from kac.cnri.dit.ie (localhost.cnri.dit.ie [127.0.0.1]) by kac.cnri.dit.ie (8.13.4/8.13.4) with ESMTP id l2MBA2Cs073351; Thu, 22 Mar 2007 11:10:03 GMT (envelope-from dwmalone@kac.cnri.dit.ie) Message-Id: <200703221110.l2MBA2Cs073351@kac.cnri.dit.ie> To: mallman@icir.org Subject: Re: [tcpm] thoughts on draft-moncaster-tcpm-rcv-cheat-00 In-Reply-To: Your message of "Wed, 21 Mar 2007 14:04:12 -0400." <20070321180412.3D3381B2FDC@lawyers.icir.org> From: David Malone Date: Thu, 22 Mar 2007 11:10:02 +0000 X-Spam-Score: -2.8 (--) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org > Is the delta of trusting the receivers a big enough deal to worry about > separately or should that just fall under the concept of fate sharing > and we should just let something hammer on the sender that is spewing > inappropriately? I've been trying to sort this out in my head. To some extent, it may depend on who congestion control is a service to. It seems fairly clear that the network benefits from congestion control. The sender may also benefit, because it can prevent the sender sending many packets which will probably be dropped, which is a waste of effort on the sender's part. OTOH, I don't think congestion control has ever been a service to the receivers for two reasons. First, a receiver controls the advertised window, and so had a mechanism for keeping (honest) senders under control even before cwnd came along. Second, it seems to me that congestion control probably works against receivers that want to get bulk data quickly (as demonstrated by apps that open multiple connections, but also a receiver with SACK could do quite well if they could disable a sender's cwnd and just manage the retransmissions themselves). Based on this, it seems that the congestion control part of TCP should trust the receiver less than it trusts the sender or the network. > Is the threat posed by receivers lying big enough to > add a bunch of goop to implementations? I guess this is probably the crux of the matter. TCP implementations have already grown quite a lot of goop in response to problems, but usually after they're seen in practice rather than before. Until someone builds a download accelerator using dishonest TCP receivers and HTTP range requests, it may not be worth fixing. David. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Mar 22 10:52:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUOdU-0006Cu-Bz; Thu, 22 Mar 2007 10:51:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUOcd-0004OX-16; Thu, 22 Mar 2007 10:50:35 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HUOca-0005az-M9; Thu, 22 Mar 2007 10:50:34 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 9768117607; Thu, 22 Mar 2007 14:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HUOc6-00089G-CI; Thu, 22 Mar 2007 10:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 22 Mar 2007 10:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-soft-errors-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org --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 : TCP's Reaction to Soft Errors Author(s) : F. Gont Filename : draft-ietf-tcpm-tcp-soft-errors-04.txt Pages : 13 Date : 2007-3-22 This document describes a non-standard, but widely implemented, modification to TCP's handling of ICMP soft error messages that rejects connections experiencing those errors immediately. This behavior reduces the likelihood of long delays between connection establishment attempts that may arise in a number of scenarios, including one in which dual stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-soft-errors-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tcpm-tcp-soft-errors-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tcpm-tcp-soft-errors-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-3-22034530.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-tcp-soft-errors-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-soft-errors-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-22034530.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --NextPart-- From tcpm-bounces@ietf.org Thu Mar 22 11:40:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUPO3-000339-VU; Thu, 22 Mar 2007 11:39:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUPO2-000316-MP for tcpm@ietf.org; Thu, 22 Mar 2007 11:39:34 -0400 Received: from mms2.broadcom.com ([216.31.210.18]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HUPNV-0000bP-Pm for tcpm@ietf.org; Thu, 22 Mar 2007 11:39:34 -0400 Received: from [10.10.64.154] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Thu, 22 Mar 2007 08:38:48 -0700 X-Server-Uuid: A6C4E0AE-A7F0-449F-BAE7-7FA0D737AC76 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 834D62B0; Thu, 22 Mar 2007 08:38:48 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 6E7E62AE; Thu, 22 Mar 2007 08:38:48 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FCE56232; Thu, 22 Mar 2007 08:38:43 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 77F7869CA3; Thu, 22 Mar 2007 08:38:43 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] thoughts on draft-moncaster-tcpm-rcv-cheat-00 Date: Thu, 22 Mar 2007 08:38:42 -0700 Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D032DE8CE@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <460262AE.6050807@isi.edu> Thread-Topic: [tcpm] thoughts on draft-moncaster-tcpm-rcv-cheat-00 Thread-Index: Acdsce9cj08AcWXgQAK+EFhM5rBGEAAJbKCQ From: "Caitlin Bestler" To: "Joe Touch" , "Anantha Ramaiah (ananth)" X-WSS-ID: 6A1C7C823A46968067-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org =20 > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU]=20 > Sent: Thursday, March 22, 2007 4:04 AM > To: Anantha Ramaiah (ananth) > Cc: Caitlin Bestler; Rob Sherwood; tcpm@ietf.org > Subject: Re: [tcpm] thoughts on draft-moncaster-tcpm-rcv-cheat-00 >=20 >=20 >=20 > Anantha Ramaiah (ananth) wrote: > > =20 > >>> I don't understand this concern -- each the receiver's rcvbuf is=20 > >>> advertised with each packet, no? A receiver should not > >> advertise more > >>> then it can actually buffer, so as long as the TCP test > >> respects the > >>> window, is this really a concern? > >>> > >>> - Rob > >>> . > >> It is not the buffer space that is in question. It is=20 > remembering the=20 > >> number of disjoint sequences that have been received. > >=20 > > FWIW, almost all TCP stacks have the counters maintained on=20 > a per TCP=20 > > connection basis for out-of-order bytes/data received, # of times=20 > > fast-retransmissions etc., not sure to what degree these would help=20 > > here. >=20 > High-speed, high-performance (large number of connections)=20 > systems may not have all these counters, and shouldn't be required to. >=20 > Joe >=20 >=20 I would hope that they could deal with at least one gap. The point is that receivers like this need to do some serious tradeoffs to determine what they track on a per connection basis. The resources available to each high speed connection are engineered to cover the expected number of gaps with a safety margin. The proposed test eats at that safety=20 margin, and hence is not benign. High speed receivers should not be forced to increase those margins because the IETF encouraged deployment of this testing strategy. =20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Mar 22 13:08:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUQka-0003wE-3B; Thu, 22 Mar 2007 13:06:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUQkY-0003w7-Ir for tcpm@ietf.org; Thu, 22 Mar 2007 13:06:54 -0400 Received: from gateway.insightbb.com ([74.128.0.19] helo=asav12.insightbb.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HUQkX-0007nl-81 for tcpm@ietf.org; Thu, 22 Mar 2007 13:06:54 -0400 Received: from 74-140-122-125.dhcp.insightbb.com (HELO elb.elitists.net) ([74.140.122.125]) by asav12.insightbb.com with ESMTP; 22 Mar 2007 13:06:47 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnoUAJNUAkZKjHp9UGdsb2JhbACHL4dtAQEq Received: from colt.internal (colt [192.168.33.1]) by elb.elitists.net (Postfix) with ESMTP id AA9B52BE21 for ; Thu, 22 Mar 2007 13:06:46 -0400 (EDT) Received: by colt.internal (Postfix, from userid 3000) id 21B8328269; Thu, 22 Mar 2007 13:06:46 -0400 (EDT) Date: Thu, 22 Mar 2007 13:06:46 -0400 From: Ethan Blanton To: tcpm@ietf.org Subject: IPR and conforming implementations (Was: Re: [tcpm] Hat off: tcpsecure mitigations) Message-ID: <20070322170645.GA30501@elb.elitists.net> Mail-Followup-To: tcpm@ietf.org References: <20070321183724.GQ49963@hut.isi.edu> <20070321195020.0F06B1B3331@lawyers.icir.org> MIME-Version: 1.0 In-Reply-To: <20070321195020.0F06B1B3331@lawyers.icir.org> X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14 User-Agent: Mutt/1.5.12-2006-07-14 X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0808186908==" Errors-To: tcpm-bounces@ietf.org --===============0808186908== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fdj2RfSjLxBAspz7" Content-Disposition: inline --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Mark Allman spake unto us the following wisdom: > The subject still contains 'hat off', but I am wearing my co-chair hat > for this note. >=20 > > Can we get a ruling from the non-arguing chair about whether IPR is on > > the table for the discussion of the SHOULD/MAY issue? >=20 > I will just re-iterate what I said yesterday. The presence of an IPR > statement can absolutely be used to inform decisions of the WG. [snip] > I would also invite other people to weigh in on this topic. How > strongly should we specify these mechanisms? MUST? SHOULD? MAY? I > don't yet feel like I really have a sense of the WG's feelings on this > matter, so please send your opinions. I feel strongly that IPR-encumbered algorithms MUST NOT be specified with a MUST. Furthermore, I feel that they SHOULD NOT be specified with a SHOULD. I would be more inclined to support the standardization of a new protocol with IPR-encumbered portions as SHOULD, than to introduce IPR-encumbered mechanisms to an established and absolutely essential protocol such as TCP and categorize them as SHOULD. In this specific instance, I do not believe that any of these mitigations are sufficiently criticial to justify an IPR-encumbered SHOULD for the TCP protocol. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 --fdj2RfSjLxBAspz7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFGArelr9kA9Ig8HBQRAr10AKC9mEGaiOiCoasWrRYf3ee5+YCZdQCfbRn9 cLQRlT2x+LLcmjd6TRZFEyg= =FX1V -----END PGP SIGNATURE----- --fdj2RfSjLxBAspz7-- --===============0808186908== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0808186908==-- From tcpm-bounces@ietf.org Thu Mar 22 13:28:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUR5Q-0000ZS-Mj; Thu, 22 Mar 2007 13:28:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUR5P-0000ZL-OZ for tcpm@ietf.org; Thu, 22 Mar 2007 13:28:27 -0400 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUR5M-0003Yg-MB for tcpm@ietf.org; Thu, 22 Mar 2007 13:28:27 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id l2MHSAdJ005225; Thu, 22 Mar 2007 19:28:11 +0200 Date: Thu, 22 Mar 2007 19:28:10 +0200 (EET) From: Pekka Savola To: Mark Allman Subject: Re: [tcpm] Hat off: tcpsecure mitigations In-Reply-To: <20070321195020.0F06B1B3331@lawyers.icir.org> Message-ID: References: <20070321195020.0F06B1B3331@lawyers.icir.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.90.1/2896/Thu Mar 22 03:43:21 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, NO_RELAYS autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: "Anantha Ramaiah \(ananth\)" , tcpm@ietf.org, Ted Faber , "Mitesh Dalal \(mdalal\)" , Joe Touch X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Wed, 21 Mar 2007, Mark Allman wrote: > I would also invite other people to weigh in on this topic. How > strongly should we specify these mechanisms? MUST? SHOULD? MAY? I > don't yet feel like I really have a sense of the WG's feelings on this > matter, so please send your opinions. There are two different ways to use uppercase keywords. 1) a compliant TCP implementation MUST/SHOULD/MAY ... 2) a TCP implementation complying to this specification MUST/SHOULD/MAY .. IMHO, a document cannot do 1) unless it also Updates or Obsoletes RFC793, RFC1122, and/or RFC1812 (as applicable). Tcpsecure currently does not. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Mar 22 13:49:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUROt-0000Es-VP; Thu, 22 Mar 2007 13:48:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUROs-0000DQ-Oi for tcpm@ietf.org; Thu, 22 Mar 2007 13:48:34 -0400 Received: from mx2.grc.nasa.gov ([128.156.11.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUROl-0007yu-6s for tcpm@ietf.org; Thu, 22 Mar 2007 13:48:34 -0400 Received: from lombok-fi.grc.nasa.gov (seraph.grc.nasa.gov [128.156.10.10]) by mx2.grc.nasa.gov (Postfix) with ESMTP id 19616C2EC for ; Thu, 22 Mar 2007 13:48:24 -0400 (EDT) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l2MHmMYp010821; Thu, 22 Mar 2007 13:48:22 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l2MHmMXx024470; Thu, 22 Mar 2007 13:48:22 -0400 (EDT) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id nfHduZ4g4xd9; Thu, 22 Mar 2007 13:48:22 -0400 (EDT) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l2MHmMgL024464;Thu, 22 Mar 2007 13:48:22 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id C3FE84FE7A; Thu, 22 Mar 2007 13:44:37 -0400 (EDT) Date: Thu, 22 Mar 2007 13:44:37 -0400 From: Wesley Eddy To: Pekka Savola Subject: Re: [tcpm] Hat off: tcpsecure mitigations Message-ID: <20070322174437.GD13613@grc.nasa.gov> References: <20070321195020.0F06B1B3331@lawyers.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1i X-imss-version: 2.046 X-imss-result: Passed X-imss-scores: Clean:86.74357 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: tcpm@ietf.org, Joe Touch , "Anantha Ramaiah \(ananth\)" , Ted Faber , Mark Allman , "Mitesh Dalal \(mdalal\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Thu, Mar 22, 2007 at 07:28:10PM +0200, Pekka Savola wrote: > > IMHO, a document cannot do 1) unless it also Updates or Obsoletes > RFC793, RFC1122, and/or RFC1812 (as applicable). Tcpsecure currently > does not. Should it? It does alter the state machine in 793, doesn't it? _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Mar 22 15:16:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUSkq-0001bv-1r; Thu, 22 Mar 2007 15:15:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUSko-0001bp-MR for tcpm@ietf.org; Thu, 22 Mar 2007 15:15:18 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUSka-0008LU-GX for tcpm@ietf.org; Thu, 22 Mar 2007 15:15:18 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l2MJEw2K025395; Thu, 22 Mar 2007 12:14:58 -0700 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 91B25925042; Thu, 22 Mar 2007 15:14:52 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 90FC41B430B; Thu, 22 Mar 2007 15:14:50 -0400 (EDT) To: weddy@grc.nasa.gov From: Mark Allman Subject: Re: [tcpm] Hat off: tcpsecure mitigations In-Reply-To: <20070322174437.GD13613@grc.nasa.gov> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Thunderstruck MIME-Version: 1.0 Date: Thu, 22 Mar 2007 15:14:50 -0400 Message-Id: <20070322191450.90FC41B430B@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: tcpm@ietf.org, Joe Touch , "Anantha Ramaiah \(ananth\)" , Ted Faber , "Mitesh Dalal \(mdalal\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1249208361==" Errors-To: tcpm-bounces@ietf.org --===============1249208361== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > On Thu, Mar 22, 2007 at 07:28:10PM +0200, Pekka Savola wrote: > > > > IMHO, a document cannot do 1) unless it also Updates or Obsoletes > > RFC793, RFC1122, and/or RFC1812 (as applicable). Tcpsecure > > currently does not. > > Should it? It does alter the state machine in 793, doesn't it? I have assumed the WG is OK with an 'update' because I assumed that was a foregone conclusion of putting this on the standards track. So, if this is going to be a bone of contention somehow then please discuss. (The comment that "tcpsecure currently does not [update previous RFCs]" is pretty mysterious to me.) allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGAtWqWyrrWs4yIs4RAiSMAJ0dN/9r48GSm02Sm/p4iKYRHBQFlACfU7FS 6ZkIByt2082oHxFYhTPYLdQ= =1ahU -----END PGP SIGNATURE----- --=_bOundary-- --===============1249208361== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1249208361==-- From tcpm-bounces@ietf.org Thu Mar 22 15:45:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUTDn-0006DG-CF; Thu, 22 Mar 2007 15:45:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUTDm-0006DA-6t for tcpm@ietf.org; Thu, 22 Mar 2007 15:45:14 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HUTDk-0007IR-OZ for tcpm@ietf.org; Thu, 22 Mar 2007 15:45:14 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 104D7F0C4F2; Thu, 22 Mar 2007 16:45:00 -0300 (ART) Received: from fgont.gont.com.ar (113-165-231-201.fibertel.com.ar [201.231.165.113]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id l2MJeaiV003503; Thu, 22 Mar 2007 16:44:50 -0300 Message-Id: <200703221944.l2MJeaiV003503@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 22 Mar 2007 16:39:58 -0300 To: Ethan Blanton , tcpm@ietf.org From: Fernando Gont Subject: Re: IPR and conforming implementations (Was: Re: [tcpm] Hat off: tcpsecure mitigations) In-Reply-To: <20070322170645.GA30501@elb.elitists.net> References: <20070321183724.GQ49963@hut.isi.edu> <20070321195020.0F06B1B3331@lawyers.icir.org> <20070322170645.GA30501@elb.elitists.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Thu, 22 Mar 2007 16:44:58 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 02:06 p.m. 22/03/2007, Ethan Blanton wrote: > > I would also invite other people to weigh in on this topic. How > > strongly should we specify these mechanisms? MUST? SHOULD? MAY? I > > don't yet feel like I really have a sense of the WG's feelings on this > > matter, so please send your opinions. > >I feel strongly that IPR-encumbered algorithms MUST NOT be specified >with a MUST. Furthermore, I feel that they SHOULD NOT be specified >with a SHOULD. I would be more inclined to support the >standardization of a new protocol with IPR-encumbered portions as >SHOULD, than to introduce IPR-encumbered mechanisms to an established >and absolutely essential protocol such as TCP and categorize them as >SHOULD. > >In this specific instance, I do not believe that any of these >mitigations are sufficiently criticial to justify an IPR-encumbered >SHOULD for the TCP protocol. FWIW, I fully agree with Ethan's view. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Mar 22 19:40:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUWr9-00042e-3O; Thu, 22 Mar 2007 19:38:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUWr8-00042Z-5e for tcpm@ietf.org; Thu, 22 Mar 2007 19:38:06 -0400 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUWr4-00012n-B5 for tcpm@ietf.org; Thu, 22 Mar 2007 19:38:06 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id l2MNbtLI014710; Fri, 23 Mar 2007 01:37:55 +0200 Date: Fri, 23 Mar 2007 01:37:55 +0200 (EET) From: Pekka Savola To: Mark Allman In-Reply-To: <20070322191450.90FC41B430B@lawyers.icir.org> Message-ID: References: <20070322191450.90FC41B430B@lawyers.icir.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.90.1/2896/Thu Mar 22 03:43:21 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, NO_RELAYS autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: tcpm@ietf.org Subject: [tcpm] 'Updates' vs an extension X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Thu, 22 Mar 2007, Mark Allman wrote: > (The comment that "tcpsecure currently does not [update previous RFCs]" > is pretty mysterious to me.) What a compliant TCP implementation must implement is AFAICS defined by RFCs 793, 1122 and 1812 *). Even though there have been dozens of TCP-related RFCs published, I do not think they change what is required of a 'compliant TCP implementation' and should be treated as TCP extensions, not required for TCP compliance. *) as potentially modified by RFCs that Update any of these RFCs, as shown from the RFC index. ... Now, If you want to formally announce that this document updates the TCP state diagram in a normative fashion and that every TCP implementor should implement it, it needs to be clearly marked in the document. Procedurally such a marking has been "Updates: xxxx' in the draft header as well as a statement like 'This document updates RFC xxxx' in the abstract and the implementation. (This will also result in adding forward references under RFC 793 or similar to this draft in the RFC index.) If such marking is not is not employed, this document should IMHO be treated as specifying TCP-secure ("a new variant of TCP") rather than modifying TCP (and what a compliant TCP implementation should do). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Mar 22 19:54:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUX6M-0005vU-KJ; Thu, 22 Mar 2007 19:53:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUX6L-0005vP-Px for tcpm@ietf.org; Thu, 22 Mar 2007 19:53:49 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUX6H-00041h-NC for tcpm@ietf.org; Thu, 22 Mar 2007 19:53:49 -0400 Received: from [127.0.0.1] (c2-vpn07.isi.edu [128.9.176.224]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l2MNrA2h005690; Thu, 22 Mar 2007 16:53:12 -0700 (PDT) Message-ID: <460316DB.60700@isi.edu> Date: Thu, 22 Mar 2007 16:52:59 -0700 From: Joe Touch User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Pekka Savola Subject: Re: [tcpm] 'Updates' vs an extension References: <20070322191450.90FC41B430B@lawyers.icir.org> In-Reply-To: X-Enigmail-Version: 0.94.1.2.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: tcpm@ietf.org, Mark Allman X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0235271343==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0235271343== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig709CAEE6603CBB3B3585CD79" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig709CAEE6603CBB3B3585CD79 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pekka Savola wrote: > On Thu, 22 Mar 2007, Mark Allman wrote: >> (The comment that "tcpsecure currently does not [update previous RFCs]= " >> is pretty mysterious to me.) >=20 > What a compliant TCP implementation must implement is AFAICS defined by= > RFCs 793, 1122 and 1812 *). Even though there have been dozens of > TCP-related RFCs published, I do not think they change what is required= > of a 'compliant TCP implementation' and should be treated as TCP > extensions, not required for TCP compliance. The TCP roadmap says otherwise (RFC4614). That requires, for IPv4: 793 1122 2581 (cong ctl) 2873 (precedence bit redefinition) 2988 (rexmit timer) and recommends (which I don't see as extensions, but rather strong SHOULD= s): 1323 (high perf) 3168 (ECN) 3042 (limited rexmit) 3390 (big init win) 3782 (newreno recovery) 2018 (SACK) 2883 (SACK extensions) 3517 (conservative SACK loss recovery) Also, 1948 (ISN randomization) is described as mostly deployed, even though it's informational, and 2385 (TCP/MD5) is described as used mostly in routers. IMO, that's precisely where this draft belongs by analogy - as either an informational that's described as deployed in many places, or as a standards track that has a **context** in which it should be deployed for safety. > *) as potentially modified by RFCs that Update any of these RFCs, as > shown from the RFC index. >=20 > ... >=20 > Now, >=20 > If you want to formally announce that this document updates the TCP > state diagram in a normative fashion and that every TCP implementor > should implement it, it needs to be clearly marked in the document. Of the above, ONLY RFC3168 (ECN) is listed as such in its header OR in rfc-index.txt > Procedurally such a marking has been "Updates: xxxx' in the draft heade= r > as well as a statement like 'This document updates RFC xxxx' in the > abstract and the implementation. (This will also result in adding > forward references under RFC 793 or similar to this draft in the RFC > index.) >=20 > If such marking is not is not employed, this document should IMHO be > treated as specifying TCP-secure ("a new variant of TCP") rather than > modifying TCP (and what a compliant TCP implementation should do). The two are not necessarily linked strongly, at least as far as the difference between the recommendations in RFC4614 and rfc-index suggests.= Joe --------------enig709CAEE6603CBB3B3585CD79 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.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGAxbbE5f5cImnZrsRAv1KAKDHi5D3Z9X0sCL4g+H5qeFRj53fXACgyt2d oLMOhArnvsildJ9C9dQjjEE= =dXKZ -----END PGP SIGNATURE----- --------------enig709CAEE6603CBB3B3585CD79-- --===============0235271343== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0235271343==-- From tcpm-bounces@ietf.org Thu Mar 22 21:42:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUYmI-0002PV-FY; Thu, 22 Mar 2007 21:41:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUYmH-0002PG-3H for tcpm@ietf.org; Thu, 22 Mar 2007 21:41:13 -0400 Received: from cypress.conncoll.edu ([136.244.1.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUYmE-0002WP-Qw for tcpm@ietf.org; Thu, 22 Mar 2007 21:41:13 -0400 Received: from [136.244.25.134] ([136.244.25.134]) by cypress.conncoll.edu with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 21:41:08 -0400 Message-ID: <4603302D.1010209@mail.eecis.udel.edu> Date: Thu, 22 Mar 2007 21:41:01 -0400 From: Janardhan Iyengar Organization: University of Delaware User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: David Malone Subject: Re: [tcpm] thoughts on draft-moncaster-tcpm-rcv-cheat-00 References: <200703221110.l2MBA2Cs073351@kac.cnri.dit.ie> In-Reply-To: <200703221110.l2MBA2Cs073351@kac.cnri.dit.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Mar 2007 01:41:08.0352 (UTC) FILETIME=[542AC800:01C76CEC] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: tcpm@ietf.org, mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iyengar@cis.udel.edu List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org > OTOH, I don't think congestion control has ever been a service to > the receivers for two reasons. First, a receiver controls the > advertised window, and so had a mechanism for keeping (honest) > senders under control even before cwnd came along. Second, it seems > to me that congestion control probably works against receivers that > want to get bulk data quickly (as demonstrated by apps that open > multiple connections, but also a receiver with SACK could do quite > well if they could disable a sender's cwnd and just manage the > retransmissions themselves). > > Based on this, it seems that the congestion control part of TCP > should trust the receiver less than it trusts the sender or the > network. I don't buy this. A receiver that is interested in actually receiving data will want fewer losses. A receiver that is interested in receiving data asap will want fewer losses and fewer loss recovery periods. By trying to get around congestion control *completely*, it will cause losses for itself, and shoot itself in the foot. My 2c at a late hour. - jana -- Janardhan R. Iyengar Visiting Assistant Professor Connecticut College http://cs.conncoll.edu/iyengar/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Mar 22 23:21:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUaJM-0002kw-Qv; Thu, 22 Mar 2007 23:19:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUaIN-0001s1-FJ for tcpm@ietf.org; Thu, 22 Mar 2007 23:18:27 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUaFd-0007RE-F3 for tcpm@ietf.org; Thu, 22 Mar 2007 23:15:38 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l2N3Fa2w001488; Thu, 22 Mar 2007 20:15:36 -0700 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 62146927CAE; Thu, 22 Mar 2007 23:15:29 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 6B1451B4957; Thu, 22 Mar 2007 23:15:26 -0400 (EDT) To: Pekka Savola From: Mark Allman In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Thunderstruck MIME-Version: 1.0 Date: Thu, 22 Mar 2007 23:15:26 -0400 Message-Id: <20070323031526.6B1451B4957@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: tcpm@ietf.org Subject: [tcpm] Re: 'Updates' vs an extension X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0428358554==" Errors-To: tcpm-bounces@ietf.org --===============0428358554== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > What a compliant TCP implementation must implement is AFAICS defined > by RFCs 793, 1122 and 1812 *). Even though there have been dozens > of TCP-related RFCs published, I do not think they change what is > required of a 'compliant TCP implementation' and should be treated > as TCP extensions, not required for TCP compliance. My reading is actually quite different. My reading is that we do a lousy job of tracking what updates (etc.) older RFCs. E.g., 2581 and 2988, IMO, are *the* way to do congestion control and RTO timers respectively, rather than the older documents. Yet, these documents are not listed as updating or obsoleting anything [*]. I think the roadmap makes this sort of thing clear, even though we have done a pretty lousy job of codifying it in the RFC index. (And, in fact, something like the roadmap map is probably the way to keep all of this straight because simply giving some quick blurb like 'XXXX updates 1122' can border on useless. I.e., without saying *what* is updated in something like 1122 the notion that something is updating it is kind of pointless. The bottom line to me is that if we put the tcpsecure mods (or anything else) on the standards track and call them MUSTs or SHOULDs then it is my opinion that we have updated the previous document's advice / mandates. allman [*] RFC 2581 does obsolete RFC 2001. But, that was just a previous rev of the document. RFC 2001 does not update/obsolete anything. --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGA0ZOWyrrWs4yIs4RAuMnAJ9mVO/88WKihM/hARV92bW7IU4KXgCfUgfg Qut3cbrc6Eh++t2Wp7MQQVI= =ziyu -----END PGP SIGNATURE----- --=_bOundary-- --===============0428358554== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0428358554==-- From tcpm-bounces@ietf.org Fri Mar 23 04:24:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUf2O-0004Yg-Pi; Fri, 23 Mar 2007 04:22:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUf2M-0004YU-Vu for tcpm@ietf.org; Fri, 23 Mar 2007 04:22:14 -0400 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUf2G-000198-Kz for tcpm@ietf.org; Fri, 23 Mar 2007 04:22:14 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id l2N8LsJL024787; Fri, 23 Mar 2007 10:21:55 +0200 Date: Fri, 23 Mar 2007 10:21:54 +0200 (EET) From: Pekka Savola To: Joe Touch Subject: Re: [tcpm] 'Updates' vs an extension In-Reply-To: <460316DB.60700@isi.edu> Message-ID: References: <20070322191450.90FC41B430B@lawyers.icir.org> <460316DB.60700@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.90.1/2898/Thu Mar 22 05:57:27 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, NO_RELAYS autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: tcpm@ietf.org, Mark Allman X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Thu, 22 Mar 2007, Joe Touch wrote: > The TCP roadmap says otherwise (RFC4614). That requires, for IPv4: Whether the TCP roadmap says anything on this may or may not apply; it's an _Informative_ RFC, providing a non-normative context to the dozens of TCP-related RFCs out there. A reading list in a way. But I don't think an Informative document can specify what a compliant TCP implementation is or isn't. If the roadmap had been on Standards Track, properly vetted by the rest of the IETF, etc. I would agree with you that it could normatively specificy what a compliant TCP implementation must or must not implement. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Mar 23 04:28:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUf8k-0007NP-7I; Fri, 23 Mar 2007 04:28:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUf8j-0007Mi-N2 for tcpm@ietf.org; Fri, 23 Mar 2007 04:28:49 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUf8i-0002sa-CB for tcpm@ietf.org; Fri, 23 Mar 2007 04:28:49 -0400 Received: from [127.0.0.1] (c1-vpn1.isi.edu [128.9.176.27]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l2N8S1kR006620; Fri, 23 Mar 2007 01:28:03 -0700 (PDT) Message-ID: <46038F85.8050901@isi.edu> Date: Fri, 23 Mar 2007 01:27:49 -0700 From: Joe Touch User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Pekka Savola Subject: Re: [tcpm] 'Updates' vs an extension References: <20070322191450.90FC41B430B@lawyers.icir.org> <460316DB.60700@isi.edu> In-Reply-To: X-Enigmail-Version: 0.94.1.2.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: tcpm@ietf.org, Mark Allman X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1056539159==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1056539159== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF3D9247B3C58D51D7D657FF1" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF3D9247B3C58D51D7D657FF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pekka Savola wrote: > On Thu, 22 Mar 2007, Joe Touch wrote: >> The TCP roadmap says otherwise (RFC4614). That requires, for IPv4: >=20 > Whether the TCP roadmap says anything on this may or may not apply; it'= s > an _Informative_ RFC, providing a non-normative context to the dozens o= f > TCP-related RFCs out there. A reading list in a way. But I don't thin= k > an Informative document can specify what a compliant TCP implementation= > is or isn't. >=20 > If the roadmap had been on Standards Track, properly vetted by the rest= > of the IETF, etc. I would agree with you that it could normatively > specificy what a compliant TCP implementation must or must not implemen= t. The docs therein are standards track. I don't know exactly what it means to be standards track as a *change* to TCP's operation and be optional. IMO, it can only mean that these mods have an odd meaning to MUST/SHOULD - they are MUST only as far as "if you do this doc, then you MUST do the MUSTs, you SHOULD do the SHOULDs, etc." - but the entire set, standards track or not, is take-it-or-leave-it. That's very strange w.r.t. RFC2119; it would be better to be explicit about this issue in the doc itself. Joe --------------enigF3D9247B3C58D51D7D657FF1 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.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGA4+GE5f5cImnZrsRAm5bAKCemcjTTyzCz3+qRHr1BclT03N3qQCg3qYb M1nTSZwChwi3hIjhdZbA6YM= =IlWR -----END PGP SIGNATURE----- --------------enigF3D9247B3C58D51D7D657FF1-- --===============1056539159== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1056539159==-- From tcpm-bounces@ietf.org Fri Mar 23 04:33:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUfDB-0007xk-W6; Fri, 23 Mar 2007 04:33:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUfDA-0007qQ-MY for tcpm@ietf.org; Fri, 23 Mar 2007 04:33:24 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUfD8-0003RY-8G for tcpm@ietf.org; Fri, 23 Mar 2007 04:33:24 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2N8XD2d009978; Fri, 23 Mar 2007 10:33:16 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Mar 2007 10:33:05 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Mar 2007 10:33:05 +0200 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Mar 2007 10:33:05 +0200 Received: from [130.129.23.111] (essapo-nirac252220.europe.nokia.com [10.162.252.220]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2N8X3fV011023; Fri, 23 Mar 2007 10:33:03 +0200 In-Reply-To: References: <20070322191450.90FC41B430B@lawyers.icir.org> <460316DB.60700@isi.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <972BF69F-5849-4288-850E-8F0348C152DF@nokia.com> From: Lars Eggert Subject: Re: [tcpm] 'Updates' vs an extension Date: Fri, 23 Mar 2007 09:33:00 +0100 To: "ext Pekka Savola" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 23 Mar 2007 08:33:05.0051 (UTC) FILETIME=[E077BEB0:01C76D25] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070323103316-26507BB0-1A5AD205/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: tcpm@ietf.org, Mark Allman , Joe Touch X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0892361888==" Errors-To: tcpm-bounces@ietf.org --===============0892361888== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5-910568923; protocol="application/pkcs7-signature" --Apple-Mail-5-910568923 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-3-23, at 9:21, ext Pekka Savola wrote: > On Thu, 22 Mar 2007, Joe Touch wrote: >> The TCP roadmap says otherwise (RFC4614). That requires, for IPv4: > > Whether the TCP roadmap says anything on this may or may not apply; > it's an _Informative_ RFC, providing a non-normative context to the > dozens of TCP-related RFCs out there. A reading list in a way. > But I don't think an Informative document can specify what a > compliant TCP implementation is or isn't. I was going to make the same comment. A standards-level recommendation is the only thing that can define what subset of RFCs TCP implementors MUST implement. Now that we have the roadmap, the WG could discuss publishing a brief standards-level document that codifies the MUSTs and SHOULDs and informatively points to RFC4614 for the rationale of the standards- level recommendations. Lars --Apple-Mail-5-910568923 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAzMjMwODMzMDFaMCMGCSqGSIb3DQEJBDEWBBTVsBZdinm/FVfs CSY7ufCPv3d0ZzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAsNGFWmLilEFb+rb9PbG0+IV+RemODscHkMqVmtV4MLWaOt5x3daY IAcvOhZWhcDzymGqr+WFe/M0NZLSELtTCG9sswYVoumeE+hi0JoNIRD6OpapBdfClQUJQujgTN9u Hc4BorrwMzNxk2Fy1TDk5fMF41lTCDrvmLpKcCvYW+oXZ/wSt2QQG/kN6XZLTE9PsPZ3f7qdX+Gn v342CM6HG/XgBzvlposDe6oj2jsnoQrhWt/wdhAF8yxmb6aGkgB/SzzAgI1q6i+tCNpOwFIxdV1P TPRldPXbOSS7m3ST2qvshPsZcRQn53oJ5qOi/0gqiB3Q0SDPl1FmOQfPJpOQ+gAAAAAAAA== --Apple-Mail-5-910568923-- --===============0892361888== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0892361888==-- From tcpm-bounces@ietf.org Fri Mar 23 05:08:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUfl5-0006AF-5x; Fri, 23 Mar 2007 05:08:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUfl4-0006A0-21 for tcpm@ietf.org; Fri, 23 Mar 2007 05:08:26 -0400 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUfku-000430-N8 for tcpm@ietf.org; Fri, 23 Mar 2007 05:08:26 -0400 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Mar 2007 09:08:16 +0000 Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.65]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Mar 2007 09:08:04 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] thoughts on draft-moncaster-tcpm-rcv-cheat-00 Date: Fri, 23 Mar 2007 09:07:57 -0000 Message-ID: In-Reply-To: <46013EA0.1020302@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] thoughts on draft-moncaster-tcpm-rcv-cheat-00 Thread-Index: Acdr6k1Jt4zFh2hpTKmRPRepa/8+WwApN/5w From: To: , X-OriginalArrivalTime: 23 Mar 2007 09:08:04.0678 (UTC) FILETIME=[C3F16660:01C76D2A] X-Spam-Score: 0.2 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Just to confirm, we certainly aren't intending that this should be added as a requirement to all TCP stacks. Rather, the intention is to create a safe standard mechanism by which senders can go about testing the behaviour of receivers if they feel they are under pressure. The test also has possible application as a means of network characterisation, perhaps as a part of a TCP test stack. We feel that it is essential that the test is appropriately specified with due consideration for any interactions with other mechanisms within TCP as well as taking into account any unintended state exhaustion affect that it might cause as well as any effect on congestion control. Toby ________________________________________________________________________ ____ Toby Moncaster, Networks Research Centre, BT Research B54/70 Adastral Park, Martlesham Heath, Ipswich, IP53RE, UK. +44 1473 648734=20 -----Original Message----- From: Joe Touch [mailto:touch@ISI.EDU]=20 Sent: 21 March 2007 14:18 To: mallman@icir.org Cc: tcpm@ietf.org Subject: Re: [tcpm] thoughts on draft-moncaster-tcpm-rcv-cheat-00 Mark Allman wrote: ... > OK. If someone wrote an i-d that said this was a testing technique=20 > only and not meant for general use then I'd respond to that i-d=20 > differently, I bet. I am responding to what I believe this document=20 > is proposing ... and, that is a technique to vet receivers on-the-fly=20 > during normal operations to combat maliciousness. I'll propose that this could be a change/clarification to the current document. Thoughts from others on the list? Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Mar 23 05:45:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUgJQ-0005ab-Nn; Fri, 23 Mar 2007 05:43:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUgJP-0005UA-E2 for tcpm@ietf.org; Fri, 23 Mar 2007 05:43:55 -0400 Received: from [2001:770:68:ff::1] (helo=kac.cnri.dit.ie) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUgJG-0005wi-WF for tcpm@ietf.org; Fri, 23 Mar 2007 05:43:48 -0400 Received: from kac.cnri.dit.ie (localhost.cnri.dit.ie [127.0.0.1]) by kac.cnri.dit.ie (8.13.4/8.13.4) with ESMTP id l2N9hKbP099540; Fri, 23 Mar 2007 09:43:20 GMT (envelope-from dwmalone@kac.cnri.dit.ie) Message-Id: <200703230943.l2N9hKbP099540@kac.cnri.dit.ie> To: iyengar@cis.udel.edu Subject: Re: [tcpm] thoughts on draft-moncaster-tcpm-rcv-cheat-00 In-Reply-To: Your message of "Thu, 22 Mar 2007 21:41:01 -0400." <4603302D.1010209@mail.eecis.udel.edu> From: David Malone Date: Fri, 23 Mar 2007 09:43:20 +0000 X-Spam-Score: -2.8 (--) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: tcpm@ietf.org, mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org > A receiver that is interested in actually receiving data will want fewer > losses. A receiver that is interested in receiving data asap will want > fewer losses and fewer loss recovery periods. By trying to get around > congestion control *completely*, it will cause losses for itself, and > shoot itself in the foot. I don't think losses are a problem for a bulk receiver. Let me try to explain why; please tell me if I'm talking nonsense. Imagine the following scheme: 1) The sender sends as fast as possible, beginning from the start of the data. 2) The receiver lets the sender know about gaps once it is fairly sure it is a gap and not a reordering. 3) The sender resends gaps when it first hears about them. Otherwise it retransmits any un-transmitted data or, if there is no un-transmitted data, it goes back to the beginning of the list of unacked data and works its way through that. On a bulk transfer, the receiver will receive data at the rate available on the tightest link and will not receive any data twice until we get down to there being less than a few RTTs worth of data left to send. The sender is never idle until the the receiver has all the data. Unless I've missed something, this means the receiver is getting new data at the largest rate it can for most of the data transfer. This scheme is relatively close to what happens if you disable cwnd at the sender, have SACK and have a big receiver advertised window. I'm not sure how a receiver could get substantially better long-term throughput. The situation is different if the receiver wants the data with some sort of control on delay. If we have multiple competing receivers, then we have some complicated game where it may not pay for everyone to do this. However, when asking "who should we trust" you can't depend on the game to keep everyone honest (cf spam?). David. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Mar 24 07:26:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HV4Lt-0007Qr-B1; Sat, 24 Mar 2007 07:24:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HV4Ls-0007Qm-22 for tcpm@ietf.org; Sat, 24 Mar 2007 07:24:04 -0400 Received: from wr-out-0506.google.com ([64.233.184.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HV4Lp-0008SJ-1V for tcpm@ietf.org; Sat, 24 Mar 2007 07:24:04 -0400 Received: by wr-out-0506.google.com with SMTP id 37so1279982wra for ; Sat, 24 Mar 2007 04:24:00 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=mWdKb+h8NDGyq/HwBV98uivAShTjg519wukDs8H0aA0iLe6g5ip/FMMOlfCECToqs0f/8yB8fL3/jpsz68EIDINLfkkt5nFudwttyWqFx0aHclUyxiXf7KfAHGCAfWu+oM98OHdzDPKdHhypP/Ult2k4V73mXZWySTBopAab6jI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=ny9qFlcYq+kHVjq6u5qgXhp4oYNRW18BlwDpvWSwbf6CmkOPeXaYNAdrvB7X5TpHJZ9/hOuqYbfk7Si8L1GBZ1typhmIYxw1racZXR4/ypPExPTt6ktYTrYU/Rqq4bHAJQbdgMO0SYxA11odXw354wKWjXiQ0k+k7AXRvPhKufQ= Received: by 10.115.89.1 with SMTP id r1mr1654232wal.1174735440118; Sat, 24 Mar 2007 04:24:00 -0700 (PDT) Received: by 10.114.254.9 with HTTP; Sat, 24 Mar 2007 04:24:00 -0700 (PDT) Message-ID: Date: Sat, 24 Mar 2007 04:24:00 -0700 From: "Vishal Study" To: tcpm@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [tcpm] RST drop and session closure X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Hi: Need some inputs on following scenario: Scenario: - Host A and B have a TCP session established. - The data traffic is one-way from A to B. - Host A sends RST to B. - RST gets dropped somewhere in the path. - Host A has closed and freed resources tied to TCP session on its end. It won't transmit RST. - Host B doesn't know the other end is gone Since the traffic is one way, B will never know that its peer A has closed the session. How does B recover from this? Is Keepalive the only option that could let B know that its peer has closed the session? Thanks, Vishal. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Mar 24 07:31:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HV4SJ-000060-2J; Sat, 24 Mar 2007 07:30:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HV4SI-0008VN-Hb for tcpm@ietf.org; Sat, 24 Mar 2007 07:30:42 -0400 Received: from wx-out-0506.google.com ([66.249.82.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HV4SF-0000xl-Ar for tcpm@ietf.org; Sat, 24 Mar 2007 07:30:42 -0400 Received: by wx-out-0506.google.com with SMTP id h31so1612584wxd for ; Sat, 24 Mar 2007 04:30:37 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=B3ezY+xaKw3NuQPBJOPQcsEiUc9v/l4vvWI6niFnqR6cV+UKh+jtiziLgnMhfcf/k16LNazf4SUw2w4z/pS4p4ytJaCn5facvPyKTBVgKEB07u+n3Tmc0toycOh1Bl5VLIxlhHdVwN+vnMm7Tb2jyN2WmXZ6S2lNtdOzbL5xZ+M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=e3C2i7+p1xdCkPtCV+sdTY7BWdnONBKbve6qg23Vl69SLavty8OwE8Gf+dS6eGiJvGEJGtpWx2dwjI5HoajB72O5QVx+u/eXrAmTrYBSDGQL5ROnZ4htIA2K91WK3u9gUfe/H6hoC8H+AFoF1gDKxt6ojQ6Q1tuNbupvKLFRP28= Received: by 10.114.179.1 with SMTP id b1mr1670207waf.1174735835723; Sat, 24 Mar 2007 04:30:35 -0700 (PDT) Received: by 10.114.254.9 with HTTP; Sat, 24 Mar 2007 04:30:35 -0700 (PDT) Message-ID: Date: Sat, 24 Mar 2007 04:30:35 -0700 From: "Vishal Study" To: tcpm@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [tcpm] TCP Reassembly: Advertising TCP rcv window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Hi: If a host has out of sequence packets in its RX_Q, how does it advertise its rcv_window? Is it supposed to consider out of sequence pkts and advertise only the "real" available space. For e.g. RX_Q size: 10,000 bytes Out of sequence pkts: From seqnum 100 to 400 and then 500 to 100000 Should the host advertise rcv_window of 200 or 0? Thanks, Vishal. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Mar 24 07:33:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HV4VM-0004sB-RC; Sat, 24 Mar 2007 07:33:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HV4VK-0004s5-W9 for tcpm@ietf.org; Sat, 24 Mar 2007 07:33:51 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HV4VJ-0001Ic-Nz for tcpm@ietf.org; Sat, 24 Mar 2007 07:33:50 -0400 Received: by ug-out-1314.google.com with SMTP id 72so1214934ugd for ; Sat, 24 Mar 2007 04:33:49 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=pEVfyrQFEFLpuJxfWzRX4wdZhatXPs68OT+mxRFtkLr2n+UQ84YSlJehwf7BJ/RXHza74wQf78lqKAVK7704/LxcIwYkeCUhNBS2a2gNqR1gfDMoYX//Yed85iKN8lwraoFoqi8fLpIMntDwleT6BZrehVBkt0KW9Mub3IkatqA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=PePbQBNXJVnwScm/copfBZg/WmT1HHhIt+dQTScayyRq5cI2ZanmlXbigiFYxBXtPzZRjaxlZErz/35ub2lFgwCUMIMKd+Wn1artt4RPQFKvIAtThTHwOisJU8YaqFUq++OMXABxFM2YZUh4miEA2kb3jdh2+teaL4XevqIJlKQ= Received: by 10.114.72.1 with SMTP id u1mr1667759waa.1174736027408; Sat, 24 Mar 2007 04:33:47 -0700 (PDT) Received: by 10.114.254.9 with HTTP; Sat, 24 Mar 2007 04:33:47 -0700 (PDT) Message-ID: Date: Sat, 24 Mar 2007 04:33:47 -0700 From: "Vishal Study" To: tcpm@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [tcpm] Restarting Keepalive timer X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Hi again: Consider a one-way traffic scenario between host A and B (data traffic from A to B). Should host-A restart its Keepalive timer if it gets an ACK for its data from host-B? Or Keepalive timer can only be reset if host-A gets some data from host-B? Thanks, Vishal. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Mar 24 09:25:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HV6DE-0004qr-P7; Sat, 24 Mar 2007 09:23:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HV6DC-0004qj-T6 for tcpm@ietf.org; Sat, 24 Mar 2007 09:23:14 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HV6DB-0001AO-Hn for tcpm@ietf.org; Sat, 24 Mar 2007 09:23:14 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id A57C8F0C42B; Sat, 24 Mar 2007 10:23:03 -0300 (ART) Received: from fgont.gont.com.ar (113-165-231-201.fibertel.com.ar [201.231.165.113]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id l2ODMoZC017392; Sat, 24 Mar 2007 10:22:54 -0300 Message-Id: <200703241322.l2ODMoZC017392@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 24 Mar 2007 10:21:19 -0300 To: "Vishal Study" , tcpm@ietf.org From: Fernando Gont Subject: Re: [tcpm] RST drop and session closure In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Sat, 24 Mar 2007 10:22:59 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 08:24 a.m. 24/03/2007, Vishal Study wrote: >Since the traffic is one way, B will never know that its peer A has >closed the session. > >How does B recover from this? >Is Keepalive the only option that could let B know that its peer has >closed the session? In the scenario you describe, yes. If B happens to be a server (i.e., it was the side that performed the passive open), then if some other client tries to establish a new connection with the same four-tuple, the half open connection would be discovered, too. (The client's SYN would likely trigger an ACK from B, which would elicit a RST from the client. This RST would signal B that the connection was aborted by the other end). -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Mar 24 12:17:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HV8uG-0000gP-4o; Sat, 24 Mar 2007 12:15:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HV8uF-0000gF-K5 for tcpm@ietf.org; Sat, 24 Mar 2007 12:15:51 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HV8uE-0005YH-8c for tcpm@ietf.org; Sat, 24 Mar 2007 12:15:51 -0400 X-VirusChecked: Checked X-Env-Sender: anuraga@motorola.com X-Msg-Ref: server-4.tower-153.messagelabs.com!1174752949!2622902!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 1581 invoked from network); 24 Mar 2007 16:15:49 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-4.tower-153.messagelabs.com with SMTP; 24 Mar 2007 16:15:49 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l2OGFma9028538 for ; Sat, 24 Mar 2007 09:15:48 -0700 (MST) Received: from ZMY16EXM67.ds.mot.com (zmy16exm67.ap.mot.com [10.179.4.27]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l2OGFliI001630 for ; Sat, 24 Mar 2007 11:15:48 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 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] TCP Reassembly: Advertising TCP rcv window Date: Sun, 25 Mar 2007 00:15:42 +0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] TCP Reassembly: Advertising TCP rcv window Thread-Index: AcduB/uFeg3Yd9kQT4yiueNsu03UGQAJugyw From: "Agarwal Anurag-A20729" To: "Vishal Study" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org The missing seq. nos. should be in-flight on the network. Now assuming that no ACK has=20 been generated by the receiver as yet, the sender has utlized the adv. window fully. So=20 I think receiver should advertize a window of size 0. Regards, Anurag -----Original Message----- From: Vishal Study [mailto:vishal.study@gmail.com]=20 Sent: Saturday, March 24, 2007 5:01 PM To: tcpm@ietf.org Subject: [tcpm] TCP Reassembly: Advertising TCP rcv window Hi: If a host has out of sequence packets in its RX_Q, how does it advertise its rcv_window? Is it supposed to consider out of sequence pkts and advertise only the "real" available space. For e.g. RX_Q size: 10,000 bytes Out of sequence pkts: From seqnum 100 to 400 and then 500 to 100000 Should the host advertise rcv_window of 200 or 0? Thanks, Vishal. _______________________________________________ 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 tcpm-bounces@ietf.org Sat Mar 24 12:19:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HV8yA-0002oj-Ek; Sat, 24 Mar 2007 12:19:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HV8y8-0002gE-Rv for tcpm@ietf.org; Sat, 24 Mar 2007 12:19:52 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HV8y7-00069R-FF for tcpm@ietf.org; Sat, 24 Mar 2007 12:19:52 -0400 X-VirusChecked: Checked X-Env-Sender: anuraga@motorola.com X-Msg-Ref: server-4.tower-128.messagelabs.com!1174753189!19342901!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 20558 invoked from network); 24 Mar 2007 16:19:49 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-4.tower-128.messagelabs.com with SMTP; 24 Mar 2007 16:19:49 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l2OGJo1U029022 for ; Sat, 24 Mar 2007 09:19:50 -0700 (MST) Received: from ZMY16EXM67.ds.mot.com (zmy16exm67.ap.mot.com [10.179.4.27]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l2OGJmmp008718 for ; Sat, 24 Mar 2007 11:19:49 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Restarting Keepalive timer Date: Sun, 25 Mar 2007 00:19:44 +0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Restarting Keepalive timer Thread-Index: AcduCGTQEqx+7/CyTvyMsoFaSA087AAJ3rCA From: "Agarwal Anurag-A20729" To: "Vishal Study" X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Keep Alive is to detect 'Half-Open' connections, which basically means whether the other end is still alive. Other end might just be a passive listener and just generate ACKs for the data it receives. ACKs alone should be good enough to=20 restart the TCP Keep Alive timer. Regards, Anurag -----Original Message----- From: Vishal Study [mailto:vishal.study@gmail.com]=20 Sent: Saturday, March 24, 2007 5:04 PM To: tcpm@ietf.org Subject: [tcpm] Restarting Keepalive timer Hi again: Consider a one-way traffic scenario between host A and B (data traffic from A to B). Should host-A restart its Keepalive timer if it gets an ACK for its data from host-B? Or Keepalive timer can only be reset if host-A gets some data from host-B? Thanks, Vishal. _______________________________________________ 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 tcpm-bounces@ietf.org Sat Mar 24 13:35:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVA7V-0006bg-1Z; Sat, 24 Mar 2007 13:33:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVA7U-0006bb-DV for tcpm@ietf.org; Sat, 24 Mar 2007 13:33:36 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVA7R-0002MD-2e for tcpm@ietf.org; Sat, 24 Mar 2007 13:33:36 -0400 Received: by ug-out-1314.google.com with SMTP id 72so1263581ugd for ; Sat, 24 Mar 2007 10:33:32 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=louejpUH+lqojpBR5ZYRDnBrM4wETewFXzhXgzJwioKvUtsW5xWp2p2spfzh/sW9+Dhf45ghG93zNzHGrHhB1aFbsXNwCjJcjbEONZ73XTwnUdjU2JG7pv5v6WMPKn2d10a8DdhJ4YFnsB+qAK+39y7IiPXlu7IawrBl/P3Id7U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=uoXJu02Te9nJL1uBg7QEJT9pIwZNSGvtHnGzL/bParLUgbukghHAjTAEMd7mGiveVN6TvLyvwww1n5PCHSkFTPNehGlb4dAS/lmKSWsalE1JAlaf3FoPhkEocfDsfe1n6NjktJVtTexCSgnNKtVLzfiGcn77iuRHaSTUa1yVo8M= Received: by 10.114.111.1 with SMTP id j1mr1768716wac.1174757611514; Sat, 24 Mar 2007 10:33:31 -0700 (PDT) Received: by 10.114.254.9 with HTTP; Sat, 24 Mar 2007 10:33:31 -0700 (PDT) Message-ID: Date: Sat, 24 Mar 2007 10:33:31 -0700 From: "Vishal Study" To: "Agarwal Anurag-A20729" Subject: Re: [tcpm] TCP Reassembly: Advertising TCP rcv window In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org What happens if the missing seq nos were dropped by the network? Can the sender still reTransmit the dropped pkts given that the rcv_window has become 0 now. Am I missing something? Thanks, Vishal. On 3/24/07, Agarwal Anurag-A20729 wrote: > The missing seq. nos. should be in-flight on the network. Now assuming > that no ACK has > been generated by the receiver as yet, the sender has utlized the adv. > window fully. So > I think receiver should advertize a window of size 0. > > Regards, > Anurag > > -----Original Message----- > From: Vishal Study [mailto:vishal.study@gmail.com] > Sent: Saturday, March 24, 2007 5:01 PM > To: tcpm@ietf.org > Subject: [tcpm] TCP Reassembly: Advertising TCP rcv window > > Hi: > > If a host has out of sequence packets in its RX_Q, how does it advertise > its rcv_window? > Is it supposed to consider out of sequence pkts and advertise only the > "real" available space. > > For e.g. > RX_Q size: 10,000 bytes > Out of sequence pkts: From seqnum 100 to 400 and then 500 to 100000 > > Should the host advertise rcv_window of 200 or 0? > > Thanks, > Vishal. > > _______________________________________________ > 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 tcpm-bounces@ietf.org Sat Mar 24 14:20:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVAqF-0000T1-1Y; Sat, 24 Mar 2007 14:19:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVAqD-0000HA-P5 for tcpm@ietf.org; Sat, 24 Mar 2007 14:19:49 -0400 Received: from ns.cdt.cz ([81.19.33.2] helo=ns1.cdt.cz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVAqB-0002Hq-7d for tcpm@ietf.org; Sat, 24 Mar 2007 14:19:49 -0400 Received: from [127.0.0.1] ([81.19.44.195]) by ns1.cdt.cz (8.13.8/8.13.8/SuSE Linux 0.8) with ESMTP id l2OIJUMF013764; Sat, 24 Mar 2007 19:19:31 +0100 Message-ID: <46056BA8.8050306@isi.edu> Date: Sat, 24 Mar 2007 11:19:20 -0700 From: Joe Touch User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Vishal Study Subject: Re: [tcpm] RST drop and session closure References: In-Reply-To: X-Enigmail-Version: 0.94.1.2.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1928048290==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1928048290== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7D6ECA5C2402B9D04A4AEC53" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7D6ECA5C2402B9D04A4AEC53 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Vishal Study wrote: > Hi: >=20 > Need some inputs on following scenario: >=20 > Scenario: > - Host A and B have a TCP session established. > - The data traffic is one-way from A to B. > - Host A sends RST to B. > - RST gets dropped somewhere in the path. > - Host A has closed and freed resources tied to TCP session on its > end. It won't transmit RST. > - Host B doesn't know the other end is gone B doesn't care until B tries to send data to A. TCP doesn't - as a rule - clean up state UNTIL it interferes with other things. > Since the traffic is one way, B will never know that its peer A has > closed the session. >=20 > How does B recover from this? > Is Keepalive the only option that could let B know that its peer has > closed the session? If B cares to know within a certain timeframe, even if no data is sent, then B can use keepalive. Otherwise, B will find out when it sends data; A will return with a RST at that point, since the connection is gone. Joe --------------enig7D6ECA5C2402B9D04A4AEC53 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.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGBWuoE5f5cImnZrsRAtjGAKDLybx995Jpgwcrm3csBCDTBSqADQCghPyA Sr5xXzqi8HaO/ZWyZ0mf4CQ= =YUdw -----END PGP SIGNATURE----- --------------enig7D6ECA5C2402B9D04A4AEC53-- --===============1928048290== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1928048290==-- From tcpm-bounces@ietf.org Sat Mar 24 16:11:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVCY7-0000mf-Om; Sat, 24 Mar 2007 16:09:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVCY6-0000mR-9I for tcpm@ietf.org; Sat, 24 Mar 2007 16:09:14 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HVCY4-0005jc-Sd for tcpm@ietf.org; Sat, 24 Mar 2007 16:09:14 -0400 X-VirusChecked: Checked X-Env-Sender: anuraga@motorola.com X-Msg-Ref: server-12.tower-153.messagelabs.com!1174766951!5600921!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 22295 invoked from network); 24 Mar 2007 20:09:11 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-12.tower-153.messagelabs.com with SMTP; 24 Mar 2007 20:09:11 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l2OK97lR005819 for ; Sat, 24 Mar 2007 13:09:11 -0700 (MST) Received: from ZMY16EXM67.ds.mot.com (zmy16exm67.ap.mot.com [10.179.4.27]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l2OK9538027047 for ; Sat, 24 Mar 2007 15:09:06 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 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] TCP Reassembly: Advertising TCP rcv window Date: Sun, 25 Mar 2007 04:08:58 +0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] TCP Reassembly: Advertising TCP rcv window Thread-Index: AcduOo11mjtf6s8QSku/lfE55MGv4QAFRmLg From: "Agarwal Anurag-A20729" To: "Vishal Study" X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Receive Window dropping to zero limits the sender from sending fresh data. It wouldn't limit retransmissions. Retransmissions are for 'in-window' data which receiver should always be ready to accept. If the receiver already received that data and it is a spurious retransmission it shall be simply acknowledged. Else if it didn't already arrive at the receiver, there would be a missing sequence and hence memory space to handle this retransmitted missing sequence in the receiver. Best Regards, Anurag -----Original Message----- From: Vishal Study [mailto:vishal.study@gmail.com]=20 Sent: Saturday, March 24, 2007 11:04 PM To: Agarwal Anurag-A20729 Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP Reassembly: Advertising TCP rcv window What happens if the missing seq nos were dropped by the network? Can the sender still reTransmit the dropped pkts given that the rcv_window has become 0 now. Am I missing something? Thanks, Vishal. On 3/24/07, Agarwal Anurag-A20729 wrote: > The missing seq. nos. should be in-flight on the network. Now assuming > that no ACK has been generated by the receiver as yet, the sender has=20 > utlized the adv. > window fully. So > I think receiver should advertize a window of size 0. > > Regards, > Anurag > > -----Original Message----- > From: Vishal Study [mailto:vishal.study@gmail.com] > Sent: Saturday, March 24, 2007 5:01 PM > To: tcpm@ietf.org > Subject: [tcpm] TCP Reassembly: Advertising TCP rcv window > > Hi: > > If a host has out of sequence packets in its RX_Q, how does it=20 > advertise its rcv_window? > Is it supposed to consider out of sequence pkts and advertise only the > "real" available space. > > For e.g. > RX_Q size: 10,000 bytes > Out of sequence pkts: From seqnum 100 to 400 and then 500 to 100000 > > Should the host advertise rcv_window of 200 or 0? > > Thanks, > Vishal. > > _______________________________________________ > 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 tcpm-bounces@ietf.org Sat Mar 24 18:41:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVEt1-0003ry-BD; Sat, 24 Mar 2007 18:38:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVEt0-0003gN-1P for tcpm@ietf.org; Sat, 24 Mar 2007 18:38:58 -0400 Received: from wr-out-0506.google.com ([64.233.184.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVEsy-0007XG-O1 for tcpm@ietf.org; Sat, 24 Mar 2007 18:38:58 -0400 Received: by wr-out-0506.google.com with SMTP id 71so1117192wri for ; Sat, 24 Mar 2007 15:38:56 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=uggLjyfU9il8JGqBjXvyAjh0/iKFTreSmEzRJsKPvyJOQP5Zfa0pyTCOBDg3sabmcOrB9jLsWD9HwGXbONSj/Pk/qEpSo2a6t0F69nVYJRnSLZchma261NgwXU5lB05MFG9v0lLRww3DjXUpdn/xocfoVrq38svh3MRtmfhbiiU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=np5EFQTuhBoQ/m6CHmKmu/B8lH62xD5LiHoS/24cbtn98SvYplGoUEEk3flXB86P1dSrD6LqgI4K/yq2tUEWllv7JRRKUTK49VBCRKChWxycXBYqQVRK9fbq4CpwD2qiAucC2V4sIl9AzhHSR8Gl+XJ+5zQbauPr30cFqI89z68= Received: by 10.114.72.1 with SMTP id u1mr1869347waa.1174775935657; Sat, 24 Mar 2007 15:38:55 -0700 (PDT) Received: by 10.114.254.9 with HTTP; Sat, 24 Mar 2007 15:38:55 -0700 (PDT) Message-ID: Date: Sat, 24 Mar 2007 15:38:55 -0700 From: "Vishal Study" To: "Agarwal Anurag-A20729" Subject: Re: [tcpm] TCP Reassembly: Advertising TCP rcv window In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Hi: Does ir mean that a sender can (or should) reTx data even if receiver's rcv_win is 0. thanks, Vishal. On 3/24/07, Agarwal Anurag-A20729 wrote: > Receive Window dropping to zero limits the sender from sending fresh > data. > It wouldn't limit retransmissions. > > Retransmissions are for 'in-window' data which receiver should always be > ready to accept. > If the receiver already received that data and it is a spurious > retransmission it shall be simply acknowledged. > Else if it didn't already arrive at the receiver, there would be a > missing sequence and hence memory space to handle > this retransmitted missing sequence in the receiver. > > Best Regards, > Anurag > > -----Original Message----- > From: Vishal Study [mailto:vishal.study@gmail.com] > Sent: Saturday, March 24, 2007 11:04 PM > To: Agarwal Anurag-A20729 > Cc: tcpm@ietf.org > Subject: Re: [tcpm] TCP Reassembly: Advertising TCP rcv window > > What happens if the missing seq nos were dropped by the network? > > Can the sender still reTransmit the dropped pkts given that the > rcv_window has become 0 now. > > Am I missing something? > > Thanks, > Vishal. > > On 3/24/07, Agarwal Anurag-A20729 wrote: > > The missing seq. nos. should be in-flight on the network. Now assuming > > > that no ACK has been generated by the receiver as yet, the sender has > > utlized the adv. > > window fully. So > > I think receiver should advertize a window of size 0. > > > > Regards, > > Anurag > > > > -----Original Message----- > > From: Vishal Study [mailto:vishal.study@gmail.com] > > Sent: Saturday, March 24, 2007 5:01 PM > > To: tcpm@ietf.org > > Subject: [tcpm] TCP Reassembly: Advertising TCP rcv window > > > > Hi: > > > > If a host has out of sequence packets in its RX_Q, how does it > > advertise its rcv_window? > > Is it supposed to consider out of sequence pkts and advertise only the > > > "real" available space. > > > > For e.g. > > RX_Q size: 10,000 bytes > > Out of sequence pkts: From seqnum 100 to 400 and then 500 to 100000 > > > > Should the host advertise rcv_window of 200 or 0? > > > > Thanks, > > Vishal. > > > > _______________________________________________ > > 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 tcpm-bounces@ietf.org Sat Mar 24 20:07:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVGEP-0003sJ-Tf; Sat, 24 Mar 2007 20:05:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVGEO-0003ri-0F for tcpm@ietf.org; Sat, 24 Mar 2007 20:05:08 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVGBg-00062d-13 for tcpm@ietf.org; Sat, 24 Mar 2007 20:02:21 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 81399F0C40A; Sat, 24 Mar 2007 21:02:21 -0300 (ART) Received: from fgont.gont.com.ar (113-165-231-201.fibertel.com.ar [201.231.165.113]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id l2P01qw6011468; Sat, 24 Mar 2007 21:01:58 -0300 Message-Id: <200703250001.l2P01qw6011468@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 24 Mar 2007 21:01:38 -0300 To: "Vishal Study" , "Agarwal Anurag-A20729" From: Fernando Gont Subject: Re: [tcpm] TCP Reassembly: Advertising TCP rcv window In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Sat, 24 Mar 2007 21:02:17 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 07:38 p.m. 24/03/2007, Vishal Study wrote: >Does ir mean that a sender can (or should) reTx data even if >receiver's rcv_win is 0. No. Out-of-order data is not considered in the advertised window. (The advertised window is the amount of data that TCP is willing to accept starting from the sequence number contained in the Acknowlegement field of the same segment.) -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Mar 25 04:32:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVO77-0007zA-Du; Sun, 25 Mar 2007 04:30:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVO76-0007y0-Cz for tcpm@ietf.org; Sun, 25 Mar 2007 04:30:08 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVO75-0007YC-4K for tcpm@ietf.org; Sun, 25 Mar 2007 04:30:08 -0400 Received: by ug-out-1314.google.com with SMTP id 72so1356624ugd for ; Sun, 25 Mar 2007 01:30:06 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=i6bUFarqXIXsoOKA2NR6sGeh0WdyUr2KrkPzLe7z8t5r0x7V/xcc+xtPBd5+tEV7xjcu0UYj7XbSphmg8xMxy3Nud7460qbDZC5zkPtHLzcz2Grzk+7frE82c32Bi1F4gg7mOt7IoKcGDXBO+ql7pgyHGA7q6NtHZYg8CFXbVuQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=d3gQfXpOc4Yo97QFbvVrE0Hb07GNGhN+btGLHwMM3ZP2nrL2PStYKW++BPpudXtd8ExjhgwfJAbu7cm6w0Pr5AgMEM24wVpdSW0qV2vWLSwEkMrACck8X/gh6mzlRBKHIElPXThsq+DrGVlox/ELU9IeMBIeWGkHQTJFwdwng5c= Received: by 10.114.89.1 with SMTP id m1mr2053337wab.1174811405540; Sun, 25 Mar 2007 01:30:05 -0700 (PDT) Received: by 10.114.254.9 with HTTP; Sun, 25 Mar 2007 01:30:05 -0700 (PDT) Message-ID: Date: Sun, 25 Mar 2007 01:30:05 -0700 From: "Vishal Study" To: "Fernando Gont" Subject: Re: [tcpm] TCP Reassembly: Advertising TCP rcv window In-Reply-To: <200703250001.l2P01qw6011468@venus.xmundo.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200703250001.l2P01qw6011468@venus.xmundo.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Hi Fernando: I guess you meant "Yes" below...i.e. if out of order data is not considered in adv window, sender can reTx data even if receiver's rcv_window is 0. Is that correct? Thanks, Vishal. On 3/24/07, Fernando Gont wrote: > At 07:38 p.m. 24/03/2007, Vishal Study wrote: > > >Does ir mean that a sender can (or should) reTx data even if > >receiver's rcv_win is 0. > > No. Out-of-order data is not considered in the advertised window. > > (The advertised window is the amount of data that TCP is willing to > accept starting from the sequence number contained in the > Acknowlegement field of the same segment.) > > > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Mar 25 15:38:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVYVQ-00035l-Dt; Sun, 25 Mar 2007 15:35:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVYVM-0002zf-Pf for tcpm@ietf.org; Sun, 25 Mar 2007 15:35:53 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVYVL-0002g9-Fh for tcpm@ietf.org; Sun, 25 Mar 2007 15:35:52 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 25 Mar 2007 12:35:47 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l2PJZkJd013752; Sun, 25 Mar 2007 12:35:46 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2PJZgMF015913; Sun, 25 Mar 2007 19:35:42 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Mar 2007 12:35:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] TCP Reassembly: Advertising TCP rcv window Date: Sun, 25 Mar 2007 12:35:39 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC58031159D2@xmb-sjc-21c.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] TCP Reassembly: Advertising TCP rcv window Thread-Index: AcduuB48+vWDRg4MRl+zyeOkvX5AUwAW9L+g From: "Anantha Ramaiah \(ananth\)" To: "Vishal Study" , "Fernando Gont" X-OriginalArrivalTime: 25 Mar 2007 19:35:42.0398 (UTC) FILETIME=[C684F5E0:01C76F14] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=432; t=1174851346; x=1175715346; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20\(ananth\)=22=20 |Subject:=20RE=3A=20[tcpm]=20TCP=20Reassembly=3A=20Advertising=20TCP=20rc v=20window |Sender:=20; bh=1CIQNk7rIDUMDEpHOwBiCk25Wrrj7GqUXsYU7vGB8bk=; b=fH8JLCYLsg1lXg0YsrebHGJJ0BXkGHehkjnNg39SnPaS30wfQ/okH5aEvv7M3LSegXz5NB6x hFzahCua4BHwvJA/h4m9TOFk+sgFYsd2R8riUKGZcyjx+bh1SVFnuc6+; Authentication-Results: sj-dkim-4; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org =20 > sender can reTx data even if receiver's rcv_window is 0. >=20 > Is that correct? Nope. If the receiver's receive window becomes zero, the sender goes to persist state which means the only thing it can send are zero window probes, until atleast a +ve window advertisement occurs.=20 So the basic TCP flow control rule applies : sender cannot (re)-transmit data when receiver's rcv_win becomes 0.=20 -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Mar 25 19:20:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVbyM-0007Bl-El; Sun, 25 Mar 2007 19:18:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVbyL-0007Bg-Gp for tcpm@ietf.org; Sun, 25 Mar 2007 19:18:01 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVbyK-0000ai-5V for tcpm@ietf.org; Sun, 25 Mar 2007 19:18:01 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 5B870F0C416; Sun, 25 Mar 2007 20:17:37 -0300 (ART) Received: from fgont.gont.com.ar (113-165-231-201.fibertel.com.ar [201.231.165.113]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id l2PNHSCc020320; Sun, 25 Mar 2007 20:17:29 -0300 Message-Id: <200703252317.l2PNHSCc020320@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 25 Mar 2007 07:44:32 -0300 To: "Vishal Study" From: Fernando Gont Subject: Re: [tcpm] TCP Reassembly: Advertising TCP rcv window In-Reply-To: References: <200703250001.l2P01qw6011468@venus.xmundo.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Sun, 25 Mar 2007 20:17:35 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 05:30 a.m. 25/03/2007, you wrote: >I guess you meant "Yes" below...i.e. if out of order data is not >considered in adv window, sender can reTx data even if receiver's >rcv_window is 0. The out of order data do not affect the advertised window. If some data were lost then, unless the TCP receiver has shrunk its receive window, the advertised window will not be zero. -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Mar 26 04:06:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVkCX-00072A-KN; Mon, 26 Mar 2007 04:05:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVkCW-00071P-B8 for tcpm@ietf.org; Mon, 26 Mar 2007 04:05:12 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVkCU-00060X-9U for tcpm@ietf.org; Mon, 26 Mar 2007 04:05:12 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2Q852gs000525; Mon, 26 Mar 2007 11:05:03 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Mar 2007 11:04:57 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Mar 2007 11:04:56 +0300 Received: from [172.21.35.191] (esdhcp035191.research.nokia.com [172.21.35.191]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2Q84s5I003401; Mon, 26 Mar 2007 11:04:54 +0300 In-Reply-To: <46038F85.8050901@isi.edu> References: <20070322191450.90FC41B430B@lawyers.icir.org> <460316DB.60700@isi.edu> <46038F85.8050901@isi.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Lars Eggert Subject: Re: [tcpm] 'Updates' vs an extension Date: Mon, 26 Mar 2007 10:04:54 +0200 To: ext Joe Touch X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 26 Mar 2007 08:04:56.0878 (UTC) FILETIME=[717A3CE0:01C76F7D] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070326110503-7F72DBB0-3FAA1AC0/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: tcpm@ietf.org, Mark Allman X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0448860067==" Errors-To: tcpm-bounces@ietf.org --===============0448860067== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7--979401220; protocol="application/pkcs7-signature" --Apple-Mail-7--979401220 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-3-23, at 9:27, ext Joe Touch wrote: > The docs therein are standards track. I don't know exactly what it > means > to be standards track as a *change* to TCP's operation and be > optional. A TCP extension can be on the standards track but OPTIONAL to implement, for example. The levels of the standards track express a level of technical maturity, but don't correlate to which protocol mechanisms are REQUIRED/RECOMMENDED/OPTIONAL to implement. For example, RFC793, which is a full standard, contains MAYs and SHOULDs that implementations need not implement. RFC2581, which is at PS, likewise contains MUSTs, SHOULDs, and MAYs. Just because we publish something on the standards track doesn't mean all TCPs need to implement all the MUSTs. Documents need to come with a clause that states whether they are a must-implement for a standards-compliant TCP or not. (Example: If we were to publish UTO as PS - which we aren't - it would probably need to say: "the UTO mechanism is OPTIONAL to implement for a standards-compliant TCP.") You can view the classification in the roadmap as making such statements about existing TCP RFCs retroactively, because many don't include such clauses. This is all a big mess. The roadmap tells implementors of which RFCs they must implement the MUSTs, should implement the SHOULDs, etc., to implement "the TCP standards", but the RFCs that contain these mechanisms are all at different levels of the standards track. Because the roadmap is informational, that is OK, but we should ideally have a standards-level document that describes what feature set is currently needed to "implement TCP", and that document would be full of DOWNREFs. The pragmatic way forward is to use the roadmap as it it were a standards-level document, and shelve this issue until the process reform attempts leave us with a simplified standards track, so that we can upgrade it from info to standards-track without needing to deal with a DOWNREF nightmare. Lars --Apple-Mail-7--979401220 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAzMjYwODA0NTRaMCMGCSqGSIb3DQEJBDEWBBR21G2+kTicN/et Azr30sEJ17RWGDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAhgSQ8nY4Ji6Woy27Tn2HbH9VoIZ0SprkM5QKoU0Ls9zc1MizLgm8 QV79yQmCQuE6+pPdKCyjST2kU8EaxPnN261Voloc6i4Eba6RbWc1W+JGrGCY2nxbsAoNik0rx030 b7xHrF0D6v4RPTtbddmw59kQwJLq9KBl8BM2aL5pyjpvZAe3ygHW0DNkQ4Ivcf50IiLkTDxGwPBu B3G/KbNlHeATLNIx7rUBQ0QLmDkqdV8uVa3vo7Fd9CqXiui0MB7F241R+9IPRSz+2fkIBVS4s7DM y2/Ox87OkU5ZqzSwmgBGwr2JLrtaqsOr3OchRyPC+ufNhv5NtIQ+4MXald4bKwAAAAAAAA== --Apple-Mail-7--979401220-- --===============0448860067== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0448860067==-- From tcpm-bounces@ietf.org Mon Mar 26 04:17:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVkOR-00032P-J7; Mon, 26 Mar 2007 04:17:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVkOQ-00030t-Ai for tcpm@ietf.org; Mon, 26 Mar 2007 04:17:30 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVkOO-0002bk-4S for tcpm@ietf.org; Mon, 26 Mar 2007 04:17:30 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2Q8GsuP015667; Mon, 26 Mar 2007 11:17:23 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Mar 2007 11:17:18 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Mar 2007 11:17:18 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Mar 2007 11:17:17 +0300 Received: from [172.21.35.191] (esdhcp035191.research.nokia.com [172.21.35.191]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2Q8HGIK014574; Mon, 26 Mar 2007 11:17:16 +0300 In-Reply-To: References: <20070322191450.90FC41B430B@lawyers.icir.org> <460316DB.60700@isi.edu> <46038F85.8050901@isi.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Lars Eggert Subject: Re: [tcpm] 'Updates' vs an extension Date: Mon, 26 Mar 2007 10:17:15 +0200 To: ext Lars Eggert X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 26 Mar 2007 08:17:18.0018 (UTC) FILETIME=[2B3B3A20:01C76F7F] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070326111724-3C042BB0-7E73E6AE/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: tcpm@ietf.org, Mark Allman , ext Joe Touch X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0316889468==" Errors-To: tcpm-bounces@ietf.org --===============0316889468== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-9--978659502; protocol="application/pkcs7-signature" --Apple-Mail-9--978659502 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-3-26, at 10:04, ext Lars Eggert wrote: > On 2007-3-23, at 9:27, ext Joe Touch wrote: >> The docs therein are standards track. I don't know exactly what it >> means >> to be standards track as a *change* to TCP's operation and be >> optional. > > A TCP extension can be on the standards track but OPTIONAL to > implement, for example. The levels of the standards track express a > level of technical maturity, but don't correlate to which protocol > mechanisms are REQUIRED/RECOMMENDED/OPTIONAL to implement. For > example, RFC793, which is a full standard, contains MAYs and > SHOULDs that implementations need not implement. RFC2581, which is > at PS, likewise contains MUSTs, SHOULDs, and MAYs. > > Just because we publish something on the standards track doesn't > mean all TCPs need to implement all the MUSTs. Documents need to > come with a clause that states whether they are a must-implement > for a standards-compliant TCP or not. (Example: If we were to > publish UTO as PS - which we aren't - it would probably need to > say: "the UTO mechanism is OPTIONAL to implement for a standards- > compliant TCP.") You can view the classification in the roadmap as > making such statements about existing TCP RFCs retroactively, > because many don't include such clauses. I realized I'm missing a piece of the argument here: These statements are needed, because the TCP specification spans multiple documents. For protocols that are specified in a single document, it is implicitly clear that the single document has the MUSTs that implementations need to implement. This is not clear for more complex cases like TCP. > This is all a big mess. The roadmap tells implementors of which > RFCs they must implement the MUSTs, should implement the SHOULDs, > etc., to implement "the TCP standards", but the RFCs that contain > these mechanisms are all at different levels of the standards > track. Because the roadmap is informational, that is OK, but we > should ideally have a standards-level document that describes what > feature set is currently needed to "implement TCP", and that > document would be full of DOWNREFs. > > The pragmatic way forward is to use the roadmap as it it were a > standards-level document, and shelve this issue until the process > reform attempts leave us with a simplified standards track, so that > we can upgrade it from info to standards-track without needing to > deal with a DOWNREF nightmare. Lars --Apple-Mail-9--978659502 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAzMjYwODE3MTZaMCMGCSqGSIb3DQEJBDEWBBTYpeaYTIjRVmDc GiXkE0mcsDG/tzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAhvGF+mQ9OXrVe8ulVfLb39b1VF1pLqZaDZFamzW1nBR9d4MfWaQO moFKRBJKICHaYvdqSS/2mPaFfJiUhQ9DJXSJPuocuiJTIrPknvf9DEuwQcnh1URmJh5Hb7DFyA/e qsHXylRGaoHl//nnRb8pP9Vz75Dsdv2NGMTOxcZ3EeStSgy9xrftesq0C7s6AZdna4geXuxx2WDu Z1EbA1dbY4lKSmEKRtnNjKt8La9PIRxDSRQJIg/NxgqVzxiXVHAwab9/BtRklg++1j73S7hYbgJj QZS+J21nd59d+6msjLdDe/QOWimYBmsq+LEc1hgDhXMiWWGopSiqsWAkdcApHwAAAAAAAA== --Apple-Mail-9--978659502-- --===============0316889468== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0316889468==-- From tcpm-bounces@ietf.org Mon Mar 26 06:01:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVm0F-0007Yb-0p; Mon, 26 Mar 2007 06:00:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVm0D-0007YW-LZ for tcpm@ietf.org; Mon, 26 Mar 2007 06:00:37 -0400 Received: from ns.cdt.cz ([81.19.33.2] helo=ns1.cdt.cz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVm09-00027w-7F for tcpm@ietf.org; Mon, 26 Mar 2007 06:00:37 -0400 Received: from [127.0.0.1] ([81.19.44.195]) by ns1.cdt.cz (8.13.8/8.13.8/SuSE Linux 0.8) with ESMTP id l2QA06xs024518; Mon, 26 Mar 2007 12:00:07 +0200 Message-ID: <4607999B.7020501@isi.edu> Date: Mon, 26 Mar 2007 02:59:55 -0700 From: Joe Touch User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Lars Eggert Subject: Re: [tcpm] 'Updates' vs an extension References: <20070322191450.90FC41B430B@lawyers.icir.org> <460316DB.60700@isi.edu> <46038F85.8050901@isi.edu> In-Reply-To: X-Enigmail-Version: 0.94.1.2.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: tcpm@ietf.org, Mark Allman X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1405582639==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1405582639== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD6C43715050A2E1791F216C4" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD6C43715050A2E1791F216C4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Lars Eggert wrote: > On 2007-3-23, at 9:27, ext Joe Touch wrote: >> The docs therein are standards track. I don't know exactly what it mea= ns >> to be standards track as a *change* to TCP's operation and be optional= =2E >=20 > A TCP extension can be on the standards track but OPTIONAL to implement= , Extensions don't *change* operation, they augment it ;-) I'm talking more about things that really change (i.e., replace) TCP behavior. > for example. The levels of the standards track express a level of > technical maturity, but don't correlate to which protocol mechanisms ar= e > REQUIRED/RECOMMENDED/OPTIONAL to implement. For example, RFC793, which > is a full standard, contains MAYs and SHOULDs that implementations need= > not implement. RFC2581, which is at PS, likewise contains MUSTs, > SHOULDs, and MAYs. E.g., 2581 isn't an extension, whereas 1351 is. > Just because we publish something on the standards track doesn't mean > all TCPs need to implement all the MUSTs. Documents need to come with a= > clause that states whether they are a must-implement for a > standards-compliant TCP or not. (Example: If we were to publish UTO as > PS - which we aren't - it would probably need to say: "the UTO mechanis= m > is OPTIONAL to implement for a standards-compliant TCP.") You can view > the classification in the roadmap as making such statements about > existing TCP RFCs retroactively, because many don't include such clause= s. Such statements would render the roadmap as standards-track; as informational, it doesn't carry any weight in making such assertions. > This is all a big mess. The roadmap tells implementors of which RFCs > they must implement the MUSTs, should implement the SHOULDs, etc., to > implement "the TCP standards", but the RFCs that contain these > mechanisms are all at different levels of the standards track. Because > the roadmap is informational, that is OK, but we should ideally have a > standards-level document that describes what feature set is currently > needed to "implement TCP", and that document would be full of DOWNREFs.= Right. > The pragmatic way forward is to use the roadmap as it it were a > standards-level document, and shelve this issue until the process refor= m > attempts leave us with a simplified standards track, so that we can > upgrade it from info to standards-track without needing to deal with a > DOWNREF nightmare. Although I agree with this, this isn't what I see happening (now or moving forward). Also, some could argue that the roadmap might have had different conclusions if it were intended to be treated as standards-track, so even using it informally as such seems unlikely. Joe --------------enigD6C43715050A2E1791F216C4 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.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGB5mbE5f5cImnZrsRAon1AKCIOR87WgxvG2q1cNEH7af6e3PXjACeM5Pm 7apLLtYEo2IsX+8FiFD77Sk= =c563 -----END PGP SIGNATURE----- --------------enigD6C43715050A2E1791F216C4-- --===============1405582639== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1405582639==-- From tcpm-bounces@ietf.org Mon Mar 26 10:21:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVq2o-0007RV-Ew; Mon, 26 Mar 2007 10:19:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVq2m-0007RQ-Hk for tcpm@ietf.org; Mon, 26 Mar 2007 10:19:32 -0400 Received: from frantic-dmz.weston.borman.com ([206.196.54.22] helo=frantic.weston.borman.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVq2i-0005qq-O8 for tcpm@ietf.org; Mon, 26 Mar 2007 10:19:32 -0400 Received: from [127.0.0.1] (frantic.weston.borman.com [206.196.45.33]) by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id l2QEJDt0026743; Mon, 26 Mar 2007 08:19:14 -0600 (CST) In-Reply-To: References: <200703250001.l2P01qw6011468@venus.xmundo.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David Borman Subject: Re: [tcpm] TCP Reassembly: Advertising TCP rcv window Date: Mon, 26 Mar 2007 09:19:17 -0500 To: "Vishal Study" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: tcpm@ietf.org, Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Vishal, The advertised window is an offset relative to the ACK field. When the receiver gets out of order data, it has to buffer that data until the missing segment arrives, and will continue to send an ACK with the same sequence number of the last in-order data that was received. The out-of-order data is considered part of the window. If the receiver continues to put in the same value for the window, the right edge of the window will not advance since the ACK is not advancing. Fernando is wrong below, the out of order data is, and must be, within the receivers advertised window, or it would be dropped by the receiver. Retracting the window, e.g. by decreasing the window field and not advancing the ACK, is strongly discouraged. See RFC 1122, section 4.2.2.16. If the ACK field isn't moving, the window field should not be decreasing. The only way that the window field should ever go to zero is by the ACK field increasing, and the window field decreasing by the same amount, leaving the right edge of the window fixed; when the ACK reaches the right edge of the window, the window field in the packet will then be zero. In summary, the window field communicates how much data the receiver is willing to receive relative to the ACK field, so adding the window to the ACK field gives the right edged of the window, or the largest sequence number that the receiver is willing to receiveAll data, whether in order or out of order, must be within the window (i.e, between the last ACK and ACK + window), or it will be dropped by the receiver. -David Borman On Mar 25, 2007, at 3:30 AM, Vishal Study wrote: > Hi Fernando: > > I guess you meant "Yes" below...i.e. if out of order data is not > considered in adv window, sender can reTx data even if receiver's > rcv_window is 0. > > Is that correct? > > Thanks, > Vishal. > > On 3/24/07, Fernando Gont wrote: >> At 07:38 p.m. 24/03/2007, Vishal Study wrote: >> >> >Does ir mean that a sender can (or should) reTx data even if >> >receiver's rcv_win is 0. >> >> No. Out-of-order data is not considered in the advertised window. >> >> (The advertised window is the amount of data that TCP is willing to >> accept starting from the sequence number contained in the >> Acknowlegement field of the same segment.) >> >> >> -- >> Fernando Gont >> e-mail: fernando@gont.com.ar || fgont@acm.org >> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >> >> >> >> >> > > _______________________________________________ > 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 tcpm-bounces@ietf.org Mon Mar 26 10:28:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVqBi-0000o5-39; Mon, 26 Mar 2007 10:28:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVqBh-0000o0-Au for tcpm@ietf.org; Mon, 26 Mar 2007 10:28:45 -0400 Received: from frantic-dmz.weston.borman.com ([206.196.54.22] helo=frantic.weston.borman.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVqBf-0007Zk-TL for tcpm@ietf.org; Mon, 26 Mar 2007 10:28:45 -0400 Received: from [127.0.0.1] (frantic.weston.borman.com [206.196.45.33]) by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id l2QESft0026762; Mon, 26 Mar 2007 08:28:41 -0600 (CST) In-Reply-To: <46056BA8.8050306@isi.edu> References: <46056BA8.8050306@isi.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David Borman Subject: Re: [tcpm] RST drop and session closure Date: Mon, 26 Mar 2007 09:28:45 -0500 To: Vishal Study X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: TCP Maintenance and Minor Extensions WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org B would care if it was expecting data from A and was hung on a read. But that doesn't change anything, B would still need to have some mechanism for discovering that A had gone away; in addition to sending a keep-alive, two other methods could be generating data traffic (probably not if you are hung in the read), or having a user- level timeout that aborts the read attempt. -David Borman On Mar 24, 2007, at 1:19 PM, Joe Touch wrote: > > > Vishal Study wrote: >> Hi: >> >> Need some inputs on following scenario: >> >> Scenario: >> - Host A and B have a TCP session established. >> - The data traffic is one-way from A to B. >> - Host A sends RST to B. >> - RST gets dropped somewhere in the path. >> - Host A has closed and freed resources tied to TCP session on its >> end. It won't transmit RST. >> - Host B doesn't know the other end is gone > > B doesn't care until B tries to send data to A. TCP doesn't - as a > rule > - clean up state UNTIL it interferes with other things. > >> Since the traffic is one way, B will never know that its peer A has >> closed the session. >> >> How does B recover from this? >> Is Keepalive the only option that could let B know that its peer has >> closed the session? > > If B cares to know within a certain timeframe, even if no data is > sent, > then B can use keepalive. > > Otherwise, B will find out when it sends data; A will return with a > RST > at that point, since the connection is gone. > > Joe > > _______________________________________________ > 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 tcpm-bounces@ietf.org Mon Mar 26 10:46:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVqTH-0006oI-JD; Mon, 26 Mar 2007 10:46:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVqTF-0006o8-Gx for tcpm@ietf.org; Mon, 26 Mar 2007 10:46:53 -0400 Received: from ns.cdt.cz ([81.19.33.2] helo=ns1.cdt.cz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVqTD-0003Gf-TJ for tcpm@ietf.org; Mon, 26 Mar 2007 10:46:53 -0400 Received: from [127.0.0.1] ([81.19.44.195]) by ns1.cdt.cz (8.13.8/8.13.8/SuSE Linux 0.8) with ESMTP id l2QEkfrR002522; Mon, 26 Mar 2007 16:46:43 +0200 Message-ID: <4607DCC6.90904@isi.edu> Date: Mon, 26 Mar 2007 07:46:30 -0700 From: Joe Touch User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: David Borman Subject: Re: [tcpm] RST drop and session closure References: <46056BA8.8050306@isi.edu> In-Reply-To: X-Enigmail-Version: 0.94.1.2.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: TCP Maintenance and Minor Extensions WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0559218259==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0559218259== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD0242FEB4FC433704F5DE330" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD0242FEB4FC433704F5DE330 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable David Borman wrote: > B would care if it was expecting data from A and was hung on a read.=20 B's TCP doesn't care about whether a read is pending or not; it doesn't behave differently. The app at B would care, but, as you note, would either timeout (if configured appropriately) or not. Neither behavior is dictated by this scenario, since B can't tell the difference between A sending a lost RST and just not having any data to send. > But that doesn't change anything, B would still need to have some > mechanism for discovering that A had gone away; in addition to sending = a > keep-alive, two other methods could be generating data traffic (probabl= y > not if you are hung in the read), or having a user-level timeout that > aborts the read attempt. It seems like you'd need either the keep-alive at the TCP layer, or the equivalent at the app layer. The latter would require both generating constant background traffic AND having timeouts to abort reads. In that case, though, you'd be using application semantics (expectation of a continuous stream of sent data) to provide meaning to the timeout. Joe >=20 > -David Borman >=20 > On Mar 24, 2007, at 1:19 PM, Joe Touch wrote: >=20 >> >> >> Vishal Study wrote: >>> Hi: >>> >>> Need some inputs on following scenario: >>> >>> Scenario: >>> - Host A and B have a TCP session established. >>> - The data traffic is one-way from A to B. >>> - Host A sends RST to B. >>> - RST gets dropped somewhere in the path. >>> - Host A has closed and freed resources tied to TCP session on its >>> end. It won't transmit RST. >>> - Host B doesn't know the other end is gone >> >> B doesn't care until B tries to send data to A. TCP doesn't - as a rul= e >> - clean up state UNTIL it interferes with other things. >> >>> Since the traffic is one way, B will never know that its peer A has >>> closed the session. >>> >>> How does B recover from this? >>> Is Keepalive the only option that could let B know that its peer has >>> closed the session? >> >> If B cares to know within a certain timeframe, even if no data is sent= , >> then B can use keepalive. >> >> Otherwise, B will find out when it sends data; A will return with a RS= T >> at that point, since the connection is gone. >> >> Joe >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www1.ietf.org/mailman/listinfo/tcpm >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enigD0242FEB4FC433704F5DE330 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.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGB9zGE5f5cImnZrsRAqTZAJ45DQzcQxPHSif+Xx+8suBK63BzyACeI9BK Sh2I3Tmwrd+C53e0c4o6HQM= =oSZ6 -----END PGP SIGNATURE----- --------------enigD0242FEB4FC433704F5DE330-- --===============0559218259== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0559218259==-- From tcpm-bounces@ietf.org Tue Mar 27 17:30:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWJDz-0007U9-96; Tue, 27 Mar 2007 17:29:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWJDx-0007Ty-Dh for tcpm@ietf.org; Tue, 27 Mar 2007 17:29:01 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWJDu-00078B-VW for tcpm@ietf.org; Tue, 27 Mar 2007 17:29:01 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l2RLSRQE023094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 27 Mar 2007 14:28:27 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.8/8.13.8/Submit) id l2RLSRni029263 for tcpm@ietf.org; Tue, 27 Mar 2007 14:28:27 -0700 (PDT) (envelope-from faber) Date: Tue, 27 Mar 2007 14:28:27 -0700 From: Ted Faber To: tcpm@ietf.org Message-ID: <20070327212827.GE26658@hut.isi.edu> Mime-Version: 1.0 User-Agent: Mutt/1.4.2.2i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [tcpm] WGLC for SYN flooding X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0237135867==" Errors-To: tcpm-bounces@ietf.org --===============0237135867== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="imjhCm/Pyz7Rq5F2" Content-Disposition: inline --imjhCm/Pyz7Rq5F2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Mark and I would like to start a WG last call on the SYN flooding and countermeasures document: Title : TCP SYN Flooding Attacks and Common Mitigations Author(s) : W. Eddy Filename : draft-ietf-tcpm-syn-flood-02.txt Pages : 23 Date : February 2007 http://www.ietf.org/internet-drafts/draft-ietf-tcpm-syn-flood-02.txt which is slated for informational. Our understanding is that all feedback to date is reflected in this version and that there are no known outstanding issues. But, it'd be great if folks can verify that and in general give this one more look. Please send feedback (even if just of the form "yep, looks good").=20 Despite the fact we're starting this a day later than we intended, we're planning on wrapping up comments on 13 Apr 2007. Yes, that's a Friday. Again, please send comments, especially of the form "I read it and think it's fine." --=20 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 --imjhCm/Pyz7Rq5F2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (FreeBSD) iD8DBQFGCYx7aUz3f+Zf+XsRAhWZAJ0RlXBI7xM81T6wUHnWTule+aexTACg2gNU 3yoJjam32NKK1KLBBvl0TI0= =4SqA -----END PGP SIGNATURE----- --imjhCm/Pyz7Rq5F2-- --===============0237135867== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0237135867==-- From tcpm-bounces@ietf.org Wed Mar 28 04:16:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWTJG-0001Pv-3a; Wed, 28 Mar 2007 04:15:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWTJD-0001PK-No for tcpm@ietf.org; Wed, 28 Mar 2007 04:15:07 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWTJ7-0005x5-AK for tcpm@ietf.org; Wed, 28 Mar 2007 04:15:07 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2S8EWnE002613; Wed, 28 Mar 2007 11:14:55 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Mar 2007 11:14:37 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Mar 2007 11:14:37 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Mar 2007 11:14:37 +0300 Received: from [172.21.35.25] (esdhcp03525.research.nokia.com [172.21.35.25]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2S8EZan016775; Wed, 28 Mar 2007 11:14:36 +0300 In-Reply-To: <20070327212827.GE26658@hut.isi.edu> References: <20070327212827.GE26658@hut.isi.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Lars Eggert Date: Wed, 28 Mar 2007 11:14:32 +0300 To: tcpm@ietf.org X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 28 Mar 2007 08:14:37.0702 (UTC) FILETIME=[20807260:01C77111] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070328111455-08304BB0-14F59DC0/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: tcpm-chairs@tools.ietf.org, Wesley Eddy Subject: [tcpm] AD review: draft-ietf-tcpm-syn-flood-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0582138516==" Errors-To: tcpm-bounces@ietf.org --===============0582138516== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-18--806022823; protocol="application/pkcs7-signature" --Apple-Mail-18--806022823 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Summary: Basically good to go. --- COMMENTS ------------------------------------------------ INTRODUCTION, paragraph 13: > This document archives explanations of the attack and > common defense techniques for the benefit of TCP implementers and > administrators of TCP servers or networks. Suggest to add "but does not make any standards-level recommendations." Section 2.1., paragraph 4: > Some of these techniques have > become important pieces of the TCP implementations in certain > operating systems, although some significantly diverge from the TCP > specification and have not yet been standardized or sanctioned by the > IETF process. s/and have not yet been/and none of these techniques have been/ Section 2.2., paragraph 6: > The goal is to send > a quick barrage of SYN segments from spoofed IP addresses that will "from spoofed IP addresses" - not necessarily spoofed; think botnets (you discuss this below) Section 4., paragraph 0: > 4. Analysis Part of this section discusses history - move those parts into Section 2.1? --- NITS --------------------------------------------------- Section 2.2., paragraph 15: > network. The attack also attepts to prevent only the establishment Nit: s/attepts/attempts/ Section 2.2., paragraph 17: > case, each host utilized in the attack would have to supress its Nit: s/supress/suppress/ Section 3.2., paragraph 1: > An obvious attempt at defense is for end hosts to use a larger Nit: s/at defense/at a defense/ Section 3.4., paragraph 3: > Measurments at one site's border router [All07] logged 2,545,785 SYN Nit: s/Measurments/Measurements/ Section 3.5., paragraph 3: > attack, or via adminstrative action. Nit: s/adminstrative/administrative/ Section 7.0, paragraph 0: > way that it is from the sequence number / acknowledgedment in a basic Nit: s/acknowledgedment/acknowledgment/ Section 7.0, paragraph 1: > compromises inherrent in SYN cookies is unique to the FreeBSD Nit: s/inherrent/inherent/ Section 7.0, paragraph 4: > the passive side side's application-layer never is notified of the Nit: s/side side's/side's/ Appendix A., paragraph 2: > number, MSS, a time counter, and the relevent addresses and port Nit: s/relevent/relevant/ --Apple-Mail-18--806022823 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAzMjgwODE0MzNaMCMGCSqGSIb3DQEJBDEWBBSBg9lBrykNILcw 5YoJPKcaGRQGjDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAxjv9g9zsflZBPlcvxICoK8HmV4dTCSsX7Hm+Ya6HmQ6XGqwYOsDv TfogZI4jOrNNtTSrt3FhUHnNLtSfbJSk/1bUq0SKX5mxS8k9Iboeklc+BVta3CIn85k6cW/ntgtb zjh05zHN8bb4r9b3x2+QBJsrS0wSyvn+qnOd896vOUqEYeMLXUjCSaY2qO2gw1BD34rysEqMypsz CT8eKwySRfVYvurWiTzrAaV8lyBh1YeWZ7AIG7AMxH9tFP/Rnk4oe2MR7b3E62jNFutrm+qwVs3v 0OwG5MVUS8J22NjVx6/J/0zcLyB6NNhcFEqwHzzYZ4/H+od1VmJAlRvfPgL11wAAAAAAAA== --Apple-Mail-18--806022823-- --===============0582138516== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0582138516==-- From tcpm-bounces@ietf.org Wed Mar 28 06:32:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWVR8-0007oo-0t; Wed, 28 Mar 2007 06:31:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWVR6-0007oh-S9 for tcpm@ietf.org; Wed, 28 Mar 2007 06:31:25 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWVR4-0003Za-3G for tcpm@ietf.org; Wed, 28 Mar 2007 06:31:24 -0400 Received: from [139.133.207.156] (dhcp-207-156.erg.abdn.ac.uk [139.133.207.156]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id l2SAUrqA003634; Wed, 28 Mar 2007 11:30:53 +0100 (BST) Message-ID: <460A43DD.1040004@erg.abdn.ac.uk> Date: Wed, 28 Mar 2007 11:30:53 +0100 From: Gorry Fairhurst Organization: University of Aberdeen, UK User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gf@erg.abdn.ac.uk X-Spam-Status: No X-Spam-Score: -2.8 (--) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: Gorry Fairhurst Subject: [tcpm] Toby Moncaster I-D: draft-moncaster-tcpm-rcv-cheat-00 (a late comment) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org I meant to send this much earlier, but it kind-of got stuck in my laptop, and delayed (sorry folks for it being out of order - and that may be it overlaps with some of what has now been said). Gorry ---- draft-moncaster-tcpm-rcv-cheat-00 Dear Toby, I enjoyed reading this draft, thanks for taking the effort to do this. One of the attractive sides to this approach is that it can interact with TCP stacks to determine whether they are behaving in ways one could judge as acceptable. I'm not sure I quite hold with the statement in the abstract that this "does not modify the TCP protocol" - that may be true of the state-machine, but it could arguably be said to change the wire-line protocol. This has some side effects: 1) It makes debugging TCP harder 2) It will create oddities in decoding traces 3) It changes the properties of tcp (to some extent - e.g. some eduction of the robustness to re-ordering). 4) It creates dependencies on sets of features that would need to be implemented in future TCP. 5) It also talks about sender-side changes that may be needed to enhance security. I am yet to be convinced that oppotunistic ACKs are "beneficial", except when you ahve a TCP-performance-enhancing-proxy, that buffers data, and they do a whole lot more than this (up to a split-tcp:-) ). One thing that strikes me is that the protocol uses a side-effect of TCP - i.e. DupAck Threshold. This value has remained fixed for a long time, although it could change, and we have debated this in the past - there was previous work on this topic (making the DupAck threshold vary under re-ordering). Be aware also of the rules for sending ACKs - which allow one ACK per segment, one each two full-sized MSS's worth of data, and things in-between, and that such rules have already been "stretched" in end hosts and network middleboxes as per RFC3449, (although these shouldn't impact DupACKs) Requirements Section 4, requirement 3. Not sure this is a requirement? - of course the receiver must NOT be able to easily cheat. Reordering The idea of using re-ordering capability to detect non-conformance suggests the scheme makes a receiver less robust to reordering (as the draft says). This concerns me - I suggest ordering is bimodal - sometimes you get a lot, sometimes you get little. ECN-N 6.2.2 & 5.2 - You have noted the difference between ECN-N and this behaviour during congestion, however I thought that there was also a difference for the initial part of a flow / short-lived flows. It was my understanding that ECN-N was active during normal feedback - and therefore was a continuous monitoring of the state of the receiver / forward router path - whereas, my understanding was that the test decsribed was a discrete test for established flows, and was run at specific times. Is this so? 6.2.3 TCP Timestamp during testing Does this really invalidate the TS option? ---- So... My opinions (thoughts) 1) My current thoughts are that this seems to present a potential stand-alone tool for detecting "correct" behaviour of a receiver. This could be helpful in working out whether a (remote) client implementation is doing the correct thing. I like such tools, and think they are good to develop, and we may wish to examine how safe they are (is it OK to expect this behaviour, etc) and what their characteristics are (what they measure, what they can not measure) in an IETF context? 2) The issue raised seems to apply to various protocols (not all transport protocols). This method is dependent on the transport, compared to ECN-Nonce that offers a method that is independent. 3) However, I **DO** doubt this should be a "feature" of a compliant TCP User Stack. If we need this feature, is this the correct thing to do? TCP behaviour has changed many times, and IMHO it would seem right to allow this continued evolution. "Finger-printing" TCP behaviour to provide evidence of cheating seems to me to provide strong features that allow working with existing stacks, but could lead to stagnation of the protocol spec, and extra cycles in a receiver (a big deal, where this matters). On the other hand, adding a new feature provides limited (no?) backwards support for existing stacks, but has good benefits when it comes to evolution of the spec. That's a trade-off, I'd advocate that we allow TCP to continue to evolve! Best wishes, Gorry _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Mar 29 18:14:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX2qu-0003Lm-RW; Thu, 29 Mar 2007 18:12:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX2qt-0003Lh-TC for tcpm@ietf.org; Thu, 29 Mar 2007 18:12:15 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX2b4-00063j-8L for tcpm@ietf.org; Thu, 29 Mar 2007 17:55:55 -0400 Received: from [127.0.0.1] (45.sub-75-215-189.myvzw.com [75.215.189.45]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l2TLtWj4016712; Thu, 29 Mar 2007 14:55:38 -0700 (PDT) Message-ID: <460C35C8.4080605@isi.edu> Date: Thu, 29 Mar 2007 14:55:20 -0700 From: Joe Touch User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: toby.moncaster@bt.com Subject: Re: [tcpm] thoughts on draft-moncaster-tcpm-rcv-cheat-00 References: In-Reply-To: X-Enigmail-Version: 0.94.1.2.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: tcpm@ietf.org, mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0105457628==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0105457628== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF85BB8032FEF96D9993093E5" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF85BB8032FEF96D9993093E5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Toby, The doc should state this explicitly and early (and imply it in the title and in the abstract). It would be useful to couch it as "intended to be reasonably safe when deployed for test purposes and used sparingly so"; I think there are reasonable concerns about what would happen if everyone's receiver implemented this on a wide scale, and there ought to be a section describing these concerns. Joe toby.moncaster@bt.com wrote: > Just to confirm, we certainly aren't intending that this should be adde= d > as a requirement to all TCP stacks. Rather, the intention is to create = a > safe standard mechanism by which senders can go about testing the > behaviour of receivers if they feel they are under pressure. The test > also has possible application as a means of network characterisation, > perhaps as a part of a TCP test stack. >=20 > We feel that it is essential that the test is appropriately specified > with due consideration for any interactions with other mechanisms withi= n > TCP as well as taking into account any unintended state exhaustion > affect that it might cause as well as any effect on congestion control.= >=20 > Toby >=20 > _______________________________________________________________________= _ > ____ > Toby Moncaster, Networks Research Centre, BT > Research > B54/70 Adastral Park, Martlesham Heath, Ipswich, IP53RE, UK. +44 1473 > 648734=20 >=20 >=20 > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU]=20 > Sent: 21 March 2007 14:18 > To: mallman@icir.org > Cc: tcpm@ietf.org > Subject: Re: [tcpm] thoughts on draft-moncaster-tcpm-rcv-cheat-00 >=20 >=20 >=20 > Mark Allman wrote: > ... >> OK. If someone wrote an i-d that said this was a testing technique=20 >> only and not meant for general use then I'd respond to that i-d=20 >> differently, I bet. I am responding to what I believe this document=20 >> is proposing ... and, that is a technique to vet receivers on-the-fly = >> during normal operations to combat maliciousness. >=20 > I'll propose that this could be a change/clarification to the current > document. Thoughts from others on the list? >=20 > Joe >=20 --------------enigF85BB8032FEF96D9993093E5 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.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGDDXIE5f5cImnZrsRAgu8AKCCANnjt3H5C91DX8Qz11CO7zyt9gCcCk2b nbkkCz5jB7m2keADhRUxILI= =2wOE -----END PGP SIGNATURE----- --------------enigF85BB8032FEF96D9993093E5-- --===============0105457628== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0105457628==-- From tcpm-bounces@ietf.org Sat Mar 31 07:17:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXbZG-0002lm-Ex; Sat, 31 Mar 2007 07:16:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXbZF-0002le-9t; Sat, 31 Mar 2007 07:16:21 -0400 Received: from wall.ikr.uni-stuttgart.de ([129.69.170.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXbZE-0006Xk-Qz; Sat, 31 Mar 2007 07:16:21 -0400 Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by wall.ikr.uni-stuttgart.de (Postfix) with ESMTP id D55AD56CC2; Sat, 31 Mar 2007 13:16:15 +0200 (CEST) Received: by netsrv1.ikr.uni-stuttgart.de (Postfix, from userid 539) id CDA4ABC07E; Sat, 31 Mar 2007 13:16:15 +0200 (CEST) Received: from ikr.uni-stuttgart.de (inode21 [10.21.18.11]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with SMTP id 9FC5ABC07E; Sat, 31 Mar 2007 13:16:15 +0200 (CEST) Received: by ikr.uni-stuttgart.de (sSMTP sendmail emulation); Sat, 31 Mar 2007 13:16:15 +0200 Date: Sat, 31 Mar 2007 13:16:15 +0200 From: Michael Scharf To: tcpm@ietf.org Message-ID: <20070331111615.GA29580@ikr.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.4.2.2i X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: tsvwg@ietf.org Subject: [tcpm] Extending RFC 1323 window scaling? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Hi all, I'd like to put for discussion an idea for a new TCP option that would extend RFX 1323. Some background information why this option might be useful can be found in later sections. I would appreciate very much any comments, suggestions, or objections concerning this idea. The new TCP option would offer a slight extension of the window scaling mechanism according of RFC 1323. The sole purpose is to allow a scaled receive window in segments, which RFC 1323 forbids. This could be realized by a new TCP option that may be added to segments that already include an RFC 1323 WSopt option. The format of the option could be: +---------+---------+------------------+ | Kind |Length=4 |SSEG.WND (shifted)| +---------+---------+------------------+ The SSEG.WND field includes the receive window, shifted by the scale factor announced in the WSopt option. The usage of this new option would be very simple (using the nomenclature of RFC 1323): - If a host decides to announce a receive window larger than 64 KB in a , it may add this new TCP option. The SSEG.WND field is scaled by the scale factor in WSopt, in the same way as the receiver window in the TCP header is scaled in non- segments: SSEG.WND = RCV.WND >> Rcv.Wind.Scale The receive window SEG.WND field in the TCP header should be set to SEG.WND=min(RCV.WND,64 KB). - If a host receives this option in a segment, it determines the receiver's advertised window as SND.WND = max(SEG.WND, SSEG.WND << Snd.Wind.Scale) This means that a larger receive window included in the new option should overwrite the unscaled receive window in the TCP header, which can be at most 64 KB. The option is backward-compatible and therefore should not create interoperability problems: If a host does not understand this option, it just uses the receive window SEG.WND in the TCP header. It may thus underestimate the amount of available buffer space at the other host, but this is not critical. The implementation of this new TCP option would be straightforward, given that it is only a slight modification of the window scaling according to RFC 1323. Motivation and background information: The motivation for proposing this new TCP option is the experimental Quick-Start TCP extension (RFC 4782). As described in the draft "draft-scharf-tsvwg-quick-start-flow-control-00.txt", in one usage scenario Quick-Start may only be effective if the other host announces a large amount of free buffer space in the segment. According to RFC 1323, the receive window in a or is never scaled, even if the connection endpoints successfully negotiate window scaling. One reason seems to be backward compatibility to non-RFC 1323 capable hosts. As a consequence, the maximum amount of free buffer space that a host can announce in a or segment is 64 KB. However, when a Quick-Start request is included in the segment, and a corresponding response is in the , a host may want to announce a receive window larger than 64 KB in this , in order to allow the other TCP host to fully use the approved Quick-Start rate. As workaround, "draft-scharf-tsvwg-quick-start-flow-control-00.txt" proposes to send an additional empty segment after the , which includes the true amount of available buffer space. This is a simple solution that probably does not cause significant deployment problems. However, this proposal results in an overhead of an additional (empty) segment and is sensitive to packet reordering. As a consequence, it would make sense to have a mechanism that is able to announce a receive window larger than 64 KB in the segment itself (there is no need to do this in segments). There are two basic possibilities: (1) The semantics of the SEG.WND field in the TCP header could be changed, i. e., the receive window is scaled in segments under some constraints. Whether or not the receive window is scaled could be announced explicitly by a flag, or implicitly, e. g., due to the presence of Quick-Start options or other options. However, changing the semantics of the receive window header field creates interoperation issues with hosts that do not implement such a modification. (2) The true amount of free buffer space is announced somehow, and overwrites the (unscaled) value in the TCP header, which remains unscaled in order to be compatible with hosts that do not implement this mechanism. This requires some new mechanism to signal a scaled receive window in segments. The proposed new TCP option is a straightforward realization of approach (2). Currently, only hosts supporting the experimental Quick-Start extension could benefit from this new option, since announcing large receive windows during a standard TCP slow-start does not make sense. Still, the new option could also be useful for other future experimental TCP congestion control modifications (e. g., XCP?), if they cause a behavior that is much more aggressive than today's TCP standard slow start. Any comments? Opinions? Michael _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm