From tcpm-bounces@ietf.org Thu Aug 09 10:18: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 1IJ8oQ-00040b-QW; Thu, 09 Aug 2007 10:16:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ8oO-00040V-Pk for tcpm@ietf.org; Thu, 09 Aug 2007 10:16:28 -0400 Received: from lmr1.uibk.ac.at ([138.232.1.142] helo=smtp.uibk.ac.at) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJ8oO-0004Se-B0 for tcpm@ietf.org; Thu, 09 Aug 2007 10:16:28 -0400 Received: from [138.232.65.105] (pc105-c703.uibk.ac.at [138.232.65.105] michael.welzl@uibk.ac.at) (authenticated bits=0) by smtp.uibk.ac.at (8.13.8/8.13.8/F1) with ESMTP id l79EGQfm012636 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 9 Aug 2007 16:16:26 +0200 From: Michael Welzl To: tcpm@ietf.org Content-Type: text/plain Organization: University of Innsbruck Date: Thu, 09 Aug 2007 16:16:26 +0200 Message-Id: <1186668986.3730.131.camel@pc105-c703.uibk.ac.at> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-Spam-Score: () -9.4 ALL_TRUSTED,RCV_SMTP_AUTH,RCV_SMTP_UIBK X-Scanned-By: MIMEDefang 2.61 at uibk.ac.at on 138.232.1.140 X-Spam-Score: 0.8 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [tcpm] CTCP review process has begun in IRTF ICCRG 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 Dear all, This is to inform you that the review process (as outlined in http://www.ietf.org/IESG/content/ions/drafts/ion-tsv-alt-cc.txt ) for Compound TCP: http://www3.tools.ietf.org/group/irtf/trac/wiki/ICCRG_ctcp has now begun in the IRTF ICCRG (I announced that we solicit reviews). The relevance for TCPM is that it was requested that this draft would eventually become an item of this WG - the related email is here: http://www3.tools.ietf.org/group/irtf/trac/wiki/ICCRG_ctcp Cheers, Michael _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Aug 11 20: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 1IK1GO-0006WC-Py; Sat, 11 Aug 2007 20:25:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IK1GM-0006VT-KW; Sat, 11 Aug 2007 20:24:58 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IK1GM-0003Lr-4r; Sat, 11 Aug 2007 20:24:58 -0400 Received: from [128.9.176.38] (c1-vpn8.isi.edu [128.9.176.38]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l7C0OcQV009619; Sat, 11 Aug 2007 17:24:38 -0700 (PDT) Message-ID: <46BE533B.4020702@isi.edu> Date: Sat, 11 Aug 2007 17:24:27 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: [Tsvwg] Re: [tcpm] Revision ofdraft-larsen-tsvwg-port-randomization References: <0C53DCFB700D144284A584F54711EC5803B6C80C@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5803B6C80C@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.3 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: tcpm@ietf.org, tsvwg WG , DCCP mailing list , Fernando Gont , TSV Dir , ext@cisco.com, Murari Sridharan 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="===============0028738219==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0028738219== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8CAEC7343217B814B857CAAF" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8CAEC7343217B814B857CAAF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anantha Ramaiah (ananth) wrote: > Lars had sent an email to retain focus on the port randomization and > hence this is going to my last comment... Pl see inline.. > =20 >> >> Anantha Ramaiah (ananth) wrote: >>> Murari, >> ... >>> - or do it in piecemeal, first buy more TCP option space,=20 >> standardize=20 >>> any one of the proposals for extending the TCP option=20 >> space. Then have=20 >>> an extended port option like yu suggest below. Then think=20 >> about other=20 >>> TCP fields requiring extension. >> The problem is that buying more option space is equivalent to=20 >> requiring a whole new TCP header - it has the same problems=20 >> with backward compatibility. Previous attempts explored this=20 >=20 > New TCP header =3D=3D "Mountain" , IMO this is equivalent to using SCTP= in > some sense. >=20 > TCP option space =3D=3D "Molehill" , this is a "minimal" change with "s= ome" > backward compat issues which can be addressed. This was tried before and was shown to be a mountain of equivalent size to a new TCP header. The problem is that the space is needed in the SYN, and there's no backward-compatible way to change the options in the first packet sent. > If I take your above para seriously, then you are in a way implying tha= t > there is no new TCP options possible :-( or in other words users of TCP= > would be rationed to use only a few options in the initial SYN exchange= =2E I didn't mean to imply that; I meant to state that explcitly. Joe --------------enig8CAEC7343217B814B857CAAF 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 iD8DBQFGvlM7E5f5cImnZrsRApzjAJ9oE+JA9kXKbPWrrpqMLhwgWjnENwCfcVH1 fHoqvKLmBy4aaytGftOyI8k= =TkFZ -----END PGP SIGNATURE----- --------------enig8CAEC7343217B814B857CAAF-- --===============0028738219== 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 --===============0028738219==-- From tcpm-bounces@ietf.org Thu Aug 16 12:26: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 1ILi9e-0000En-Vs; Thu, 16 Aug 2007 12:25:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILi9e-0000Eh-2U for tcpm@ietf.org; Thu, 16 Aug 2007 12:25:02 -0400 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILi9c-00036O-Qs for tcpm@ietf.org; Thu, 16 Aug 2007 12:25:02 -0400 Received: from tk1-exhub-c102.redmond.corp.microsoft.com (157.56.116.113) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.177.2; Thu, 16 Aug 2007 09:25:00 -0700 Received: from NA-EXMSG-C110.redmond.corp.microsoft.com ([157.54.62.150]) by tk1-exhub-c102.redmond.corp.microsoft.com ([157.56.116.113]) with mapi; Thu, 16 Aug 2007 09:24:59 -0700 From: Murari Sridharan To: Michael Welzl , "tcpm@ietf.org" Date: Thu, 16 Aug 2007 09:24:07 -0700 Subject: RE: [tcpm] CTCP review process has begun in IRTF ICCRG Thread-Topic: [tcpm] CTCP review process has begun in IRTF ICCRG Thread-Index: AcfakAj8KXCIRG39TQSF7fHluyxnygFkdVNH Message-ID: References: <1186668986.3730.131.camel@pc105-c703.uibk.ac.at> In-Reply-To: <1186668986.3730.131.camel@pc105-c703.uibk.ac.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: -7.2 (-------) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 The IPR statement for CTCP is at https://datatracker.ietf.org/ipr/878/ This info has also been added to the Wiki link below. Thanks Murari ________________________________________ From: Michael Welzl [michael.welzl@uibk.ac.at] Sent: Thursday, August 09, 2007 7:16 AM To: tcpm@ietf.org Subject: [tcpm] CTCP review process has begun in IRTF ICCRG Dear all, This is to inform you that the review process (as outlined in http://www.ietf.org/IESG/content/ions/drafts/ion-tsv-alt-cc.txt ) for Compound TCP: http://www3.tools.ietf.org/group/irtf/trac/wiki/ICCRG_ctcp has now begun in the IRTF ICCRG (I announced that we solicit reviews). The relevance for TCPM is that it was requested that this draft would eventually become an item of this WG - the related email is here: http://www3.tools.ietf.org/group/irtf/trac/wiki/ICCRG_ctcp Cheers, Michael _______________________________________________ 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 Fri Aug 17 12:09: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 1IM4Lx-0004Or-5G; Fri, 17 Aug 2007 12:07:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM4Lv-0004Oi-TJ for tcpm@ietf.org; Fri, 17 Aug 2007 12:07:11 -0400 Received: from smtpout.mac.com ([17.250.248.185]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IM4Lv-0004Vv-G3 for tcpm@ietf.org; Fri, 17 Aug 2007 12:07:11 -0400 Received: from mac.com (smtpin01-en2 [10.13.10.146]) by smtpout.mac.com (Xserve/smtpout15/MantshX 4.0) with ESMTP id l7HG79xJ005509 for ; Fri, 17 Aug 2007 09:07:09 -0700 (PDT) Received: from [137.226.12.104] (informatik-4-137-226-12-104.una.rwth-aachen.de [137.226.12.104] (may be forged)) (authenticated bits=0) by mac.com (Xserve/smtpin01/MantshX 4.0) with ESMTP id l7HG73oV002210 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 17 Aug 2007 09:07:09 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <8B61F72F-2F75-4388-976F-9748F8784AB3@mac.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: tcpm@ietf.org From: Daniel Schaffrath Date: Fri, 17 Aug 2007 18:06:55 +0200 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [tcpm] Congestion control in face of ICMP unreachable messages 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 Dear Community, I was wondering if there are any recommendations regarding congestion control in face of ICMP (host/network) unreachable messages. If I am not mistaken there is nothing in the various TCPM documents... nor in any RFC. Maybe you have any pointers? Thank you, Daniel Schaffrath _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Aug 17 12:28: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 1IM4eU-0001lW-NO; Fri, 17 Aug 2007 12:26:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM4eU-0001kh-0W for tcpm@ietf.org; Fri, 17 Aug 2007 12:26:22 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IM4eT-0005Vj-F1 for tcpm@ietf.org; Fri, 17 Aug 2007 12:26: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 l7HGPhBW015106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 17 Aug 2007 09:25:43 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.14.1/8.14.1/Submit) id l7HGPgFl023915; Fri, 17 Aug 2007 09:25:42 -0700 (PDT) (envelope-from faber) Date: Fri, 17 Aug 2007 09:25:42 -0700 From: Ted Faber To: Daniel Schaffrath Subject: Re: [tcpm] Congestion control in face of ICMP unreachable messages Message-ID: <20070817162542.GA2511@hut.isi.edu> References: <8B61F72F-2F75-4388-976F-9748F8784AB3@mac.com> Mime-Version: 1.0 In-Reply-To: <8B61F72F-2F75-4388-976F-9748F8784AB3@mac.com> User-Agent: Mutt/1.4.2.3i 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 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="===============0187085590==" Errors-To: tcpm-bounces@ietf.org --===============0187085590== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u3/rZRmxL6MmkK24" Content-Disposition: inline --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 17, 2007 at 06:06:55PM +0200, Daniel Schaffrath wrote: > Dear Community, >=20 > I was wondering if there are any recommendations regarding congestion =20 > control in face of ICMP (host/network) unreachable messages. If I am =20 > not mistaken there is nothing in the various TCPM documents... nor in =20 > any RFC. >=20 > Maybe you have any pointers? Sure. If the code in the destination unreachable message is 2-4 abort the connection. Otherwise, don't. RFC 1122. I wouldn't use ICMP reachability information in congestion control, and I don't believe that any standard requires an implementer to do so. If packets aren't being delivered, the sending endpoint(s) will slow down pretty dramatically, pretty quickly without intervention. A retransmisson timeout puts the endpoint into slow start. You're still technically required to respond to an ICMP source quench, but I personally wouldn't. --=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 --u3/rZRmxL6MmkK24 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGxcwGaUz3f+Zf+XsRAlAUAJ9cOQf6moy0fl9hK0I+/n2TFB5DGgCdEdJG HJaKbYaweLIyWODGsltEOu0= =9HEM -----END PGP SIGNATURE----- --u3/rZRmxL6MmkK24-- --===============0187085590== 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 --===============0187085590==-- From tcpm-bounces@ietf.org Fri Aug 17 12:43: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 1IM4t4-0008SI-V6; Fri, 17 Aug 2007 12:41:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM4t3-0008SB-BU for tcpm@ietf.org; Fri, 17 Aug 2007 12:41:25 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IM4t2-00066g-S3 for tcpm@ietf.org; Fri, 17 Aug 2007 12:41:25 -0400 Received: from [192.168.1.42] (pool-71-105-86-112.lsanca.dsl-w.verizon.net [71.105.86.112]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l7HGfGmV026800; Fri, 17 Aug 2007 09:41:17 -0700 (PDT) Message-ID: <46C5CFA1.3090603@isi.edu> Date: Fri, 17 Aug 2007 09:41:05 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Daniel Schaffrath Subject: Re: [tcpm] Congestion control in face of ICMP unreachable messages References: <8B61F72F-2F75-4388-976F-9748F8784AB3@mac.com> In-Reply-To: <8B61F72F-2F75-4388-976F-9748F8784AB3@mac.com> X-Enigmail-Version: 0.95.3 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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="===============2108501203==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2108501203== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9AB6A9EEF2E0D4B31368B8CD" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9AB6A9EEF2E0D4B31368B8CD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Daniel, AFAIK, congestion control response to in-band messages (ACKs) and timeouts (implied loss, as TCP interprets it), as well as to some new fields (ECN, etc.) which are carried in the same packets. Reactions to external congestion signals - ICMP source quench (which has been informally deprecated a while ago, but has not been documented as such yet) or otherwise - would constitute another opportunity for a DOS attack, and seem like a bad idea to encourage. Joe Daniel Schaffrath wrote: > Dear Community, >=20 > I was wondering if there are any recommendations regarding congestion > control in face of ICMP (host/network) unreachable messages. If I am no= t > mistaken there is nothing in the various TCPM documents... nor in any R= FC. >=20 > Maybe you have any pointers? >=20 > Thank you, > Daniel Schaffrath >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm --------------enig9AB6A9EEF2E0D4B31368B8CD 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 iD8DBQFGxc+hE5f5cImnZrsRAo32AJ95mHAVqZdxsziW+IxiQhnQpEATmQCg0J83 qqbcmup6dU253VOxIRYNFWI= =H/FJ -----END PGP SIGNATURE----- --------------enig9AB6A9EEF2E0D4B31368B8CD-- --===============2108501203== 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 --===============2108501203==-- From tcpm-bounces@ietf.org Fri Aug 17 19:44: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 1IMBT3-000676-Fa; Fri, 17 Aug 2007 19:43:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMBT0-000667-LT; Fri, 17 Aug 2007 19:42:58 -0400 Received: from bosco.isi.edu ([128.9.168.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IMBT0-00088w-1B; Fri, 17 Aug 2007 19:42:58 -0400 Received: by bosco.isi.edu (Postfix, from userid 70) id 5B926DFB23; Fri, 17 Aug 2007 16:41:55 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20070817234155.5B926DFB23@bosco.isi.edu> Date: Fri, 17 Aug 2007 16:41:55 -0700 (PDT) X-Spam-Score: -15.0 (---------------) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: tcpm@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] RFC 4987 on TCP SYN Flooding Attacks and Common 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: , Errors-To: tcpm-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4987 Title: TCP SYN Flooding Attacks and Common Mitigations Author: W. Eddy Status: Informational Date: August 2007 Mailbox: weddy@grc.nasa.gov Pages: 19 Characters: 48753 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tcpm-syn-flood-05.txt URL: http://www.rfc-editor.org/rfc/rfc4987.txt 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, but does not make any standards-level recommendations. This memo provides information for the Internet community. This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Aug 24 16:27: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 1IOfix-00037t-2y; Fri, 24 Aug 2007 16:25:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOfiv-00037l-Bv for tcpm@ietf.org; Fri, 24 Aug 2007 16:25:41 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOfiu-0007Av-2F for tcpm@ietf.org; Fri, 24 Aug 2007 16:25:41 -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 l7OKPDiG002829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 24 Aug 2007 13:25:13 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.14.1/8.14.1/Submit) id l7OKPDHD003964 for tcpm@ietf.org; Fri, 24 Aug 2007 13:25:13 -0700 (PDT) (envelope-from faber) Date: Fri, 24 Aug 2007 13:25:13 -0700 From: Ted Faber To: tcpm@ietf.org Message-ID: <20070824202512.GF22684@hut.isi.edu> Mime-Version: 1.0 User-Agent: Mutt/1.4.2.3i 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: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [tcpm] TCPM minutes for July 2007 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="===============0081312300==" Errors-To: tcpm-bounces@ietf.org --===============0081312300== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HB4mHL4PVvkpZAgW" Content-Disposition: inline --HB4mHL4PVvkpZAgW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The initial minutes for the TCPM meeting in Chicago are posted at http://www3.ietf.org/proceedings/07jul/minutes/tcpm.txt Please review them. --=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 --HB4mHL4PVvkpZAgW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGzz6oaUz3f+Zf+XsRAnPPAKCj8M7oEy1AtfhRLalwcSi/v1tP7wCgoK4r tNX4BRVIjVoeySth1aOHerw= =RzGt -----END PGP SIGNATURE----- --HB4mHL4PVvkpZAgW-- --===============0081312300== 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 --===============0081312300==-- From tcpm-bounces@ietf.org Wed Aug 29 14:23: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 1IQSAG-0001Vk-45; Wed, 29 Aug 2007 14:21:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQSAC-0001Vd-Np for tcpm@ietf.org; Wed, 29 Aug 2007 14:21:12 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQSAC-0003Ly-AJ for tcpm@ietf.org; Wed, 29 Aug 2007 14:21:12 -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 l7TIKqtu018335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 29 Aug 2007 11:20:52 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.14.1/8.14.1/Submit) id l7TIKqBC016653 for tcpm@ietf.org; Wed, 29 Aug 2007 11:20:52 -0700 (PDT) (envelope-from faber) Date: Wed, 29 Aug 2007 11:20:52 -0700 From: Ted Faber To: tcpm@ietf.org Message-ID: <20070829182052.GF13100@hut.isi.edu> Mime-Version: 1.0 User-Agent: Mutt/1.4.2.3i 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: 97adf591118a232206bdb5a27b217034 Subject: [tcpm] Minutes 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="===============0698115120==" Errors-To: tcpm-bounces@ietf.org --===============0698115120== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1Ow488MNN9B9o/ov" Content-Disposition: inline --1Ow488MNN9B9o/ov Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable We've had a few corrections to the minutes, and I wouldn't be surprised to see a few more needed. Please take a look at http://www3.ietf.org/proceedings/07jul/minutes/tcpm.txt and send any comments or corrections to the chairs or this list. Corrections can be made until 12 Sep, but I may be out of town near then, so sooner is better. --=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 --1Ow488MNN9B9o/ov Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFG1bkDaUz3f+Zf+XsRArT3AKDooQMWnaHxfDl+jUR9um3svGOCqACfdWB3 /GoK7ikZcjCxHTY9o6wIBiE= =IdVU -----END PGP SIGNATURE----- --1Ow488MNN9B9o/ov-- --===============0698115120== 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 --===============0698115120==-- From tcpm-bounces@ietf.org Wed Aug 29 18:45: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 1IQWGS-0007wv-0B; Wed, 29 Aug 2007 18:43:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQWGO-0007tq-4q for tcpm@ietf.org; Wed, 29 Aug 2007 18:43:52 -0400 Received: from wa-out-1112.google.com ([209.85.146.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQWGM-00052c-3g for tcpm@ietf.org; Wed, 29 Aug 2007 18:43:51 -0400 Received: by wa-out-1112.google.com with SMTP id k40so445406wah for ; Wed, 29 Aug 2007 15:43:49 -0700 (PDT) Received: by 10.114.209.1 with SMTP id h1mr21054wag.1188427428868; Wed, 29 Aug 2007 15:43:48 -0700 (PDT) Received: by 10.114.196.9 with HTTP; Wed, 29 Aug 2007 15:43:48 -0700 (PDT) Message-ID: <5640c7e00708291543h58e73d2cj456eb248338988e9@mail.gmail.com> Date: Thu, 30 Aug 2007 10:43:48 +1200 From: "Ian McDonald" To: tcpm@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [tcpm] TCP retransmission timeouts (RFC 2988) 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 (Resent to tcpm list, instead of iccrg) After some discussion on the Linux networking list I thought I'd ask the question here. In RFC 2988 Section 2.4 says: (2.4) Whenever RTO is computed, if it is less than 1 second then the RTO SHOULD be rounded up to 1 second. Traditionally, TCP implementations use coarse grain clocks to measure the RTT and trigger the RTO, which imposes a large minimum value on the RTO. Research suggests that a large minimum RTO is needed to keep TCP conservative and avoid spurious retransmissions [AP99]. Therefore, this specification requires a large minimum RTO as a conservative approach, while at the same time acknowledging that at some future point, research may show that a smaller minimum RTO is acceptable or superior. Given that Linux, BSD etc use 200 milliseconds, not 1 second I am wondering whether there has in fact been any research done as mentioned in last sentence. It seems a very high timeout especially on two locally connected devices. Apologies if I'm asking on the wrong list. Regards, Ian -- Web1: http://wand.net.nz/~iam4/ Web2: http://www.jandi.co.nz Blog: http://iansblog.jandi.co.nz _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 30 03:36: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 1IQeYC-0007Sx-D6; Thu, 30 Aug 2007 03:34:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQeY8-0007He-KT for tcpm@ietf.org; Thu, 30 Aug 2007 03:34:46 -0400 Received: from lmr1.uibk.ac.at ([138.232.1.142] helo=smtp.uibk.ac.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQeY6-0001oE-Vj for tcpm@ietf.org; Thu, 30 Aug 2007 03:34:44 -0400 Received: from [138.232.65.105] (pc105-c703.uibk.ac.at [138.232.65.105] michael.welzl@uibk.ac.at) (authenticated bits=0) by smtp.uibk.ac.at (8.13.8/8.13.8/F1) with ESMTP id l7U7YaXm026492 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 30 Aug 2007 09:34:36 +0200 From: Michael Welzl To: tcpm@ietf.org Content-Type: text/plain Organization: University of Innsbruck Date: Thu, 30 Aug 2007 09:34:36 +0200 Message-Id: <1188459276.3723.63.camel@pc105-c703.uibk.ac.at> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-Spam-Score: () -9.4 ALL_TRUSTED,RCV_SMTP_AUTH,RCV_SMTP_UIBK X-Scanned-By: MIMEDefang 2.61 at uibk.ac.at on 138.232.1.140 X-Spam-Score: 0.8 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [tcpm] CUBIC review process has begun in IRTF ICCRG 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 Dear all, This is to inform you that the review process (as outlined in http://www.ietf.org/IESG/content/ions/drafts/ion-tsv-alt-cc.txt ) for CUBIC: http://www3.tools.ietf.org/group/irtf/trac/wiki/ICCRG_cubic has now begun in the IRTF ICCRG (I announced that we solicit reviews). The relevance for TCPM is that it was, I think (not 100% sure, but the title of the draft - draft-rhee-tcpm-cubic-00.txt - indicates that I'm right :-) ) once requested that this draf would eventually become an item of this WG. Cheers, Michael _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Aug 31 17:09: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 1IRDis-0004Rb-AT; Fri, 31 Aug 2007 17:08:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRDiq-0004RU-V0 for tcpm@ietf.org; Fri, 31 Aug 2007 17:08:08 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IRDip-00039Q-8e for tcpm@ietf.org; Fri, 31 Aug 2007 17:08:08 -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 l7VL85Td027174; Fri, 31 Aug 2007 14:08:06 -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 8BB00EDA3EE; Fri, 31 Aug 2007 17:08:00 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 8F8C9294D98; Fri, 31 Aug 2007 17:07:33 -0400 (EDT) To: "Ian McDonald" From: Mark Allman Subject: Re: [tcpm] TCP retransmission timeouts (RFC 2988) In-Reply-To: <5640c7e00708291543h58e73d2cj456eb248338988e9@mail.gmail.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Zombie MIME-Version: 1.0 Date: Fri, 31 Aug 2007 17:07:33 -0400 Message-Id: <20070831210733.8F8C9294D98@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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="===============0262109841==" Errors-To: tcpm-bounces@ietf.org --===============0262109841== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Ian- > After some discussion on the Linux networking list I thought I'd ask > the question here. > > In RFC 2988 Section 2.4 says: > (2.4) Whenever RTO is computed, if it is less than 1 second then the > RTO SHOULD be rounded up to 1 second. > > Traditionally, TCP implementations use coarse grain clocks to > measure the RTT and trigger the RTO, which imposes a large > minimum value on the RTO. Research suggests that a large > minimum RTO is needed to keep TCP conservative and avoid > spurious retransmissions [AP99]. Therefore, this > specification requires a large minimum RTO as a conservative > approach, while at the same time acknowledging that at some > future point, research may show that a smaller minimum RTO is > acceptable or superior. > > Given that Linux, BSD etc use 200 milliseconds, not 1 second I am > wondering whether there has in fact been any research done as > mentioned in last sentence. I am not aware of any. > It seems a very high timeout especially on two locally connected > devices. Well, a couple of things .... First, if the performance is driven by the magnitude of the RTO then that is a more general problem than with the min RTO, I think. We have devised much better loss recovery than relying on the RTO and so one would hope that RTOs are rare enough to not be driving performance. Second, while I don't know of any recent research, I think [AP99] shows that this is all a tradeoff and so one might want to be careful. The current algorithm (RFC 2988) does not often send spurious retransmits. So, it stands to reason that when simply reducing the min and calculating the time savings over the current min that things will in fact be better. I.e., you will not spend as much time waiting on timeouts you need to take. However, the flip side of the coin is that by reducing the minimum you are also increasing the chances of the RTO expiring needlessly. I.e., if you had waited longer for the ACK then you would not have needed the RTO at all. The impact of this is harder to gauge than simply computing the "wait time" because in this case the cwnd will be needlessly collapsed to 1 segment and the connection will have to build the window back up. As an example, from the paper if you simply reduce the min from 1sec to 250msec (as close as we come to the 200msec you cite above) you see that wait time is reduced by 36% and at the same time we experience 3.6 times the number of spurious retransmits. This is all a tradeoff it seems to me. We could not find a magic 'sweet spot' that seemed to be a win in terms of wait time and number of spurious timeouts. All that said, the data I am quoting is old. Perhaps on modern networks a smaller minimum would behave as 1sec did quite a while back. I have no idea. I think it would be nice if someone did a study to find out. I hope that helps in some way. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFG2IMVWyrrWs4yIs4RAvvAAJ9P8ZuLYqHyhQ1BTycM2ytLpU8PIQCfeNHm T4Gk+fH4VCv8V/k7txStqgw= =6EIM -----END PGP SIGNATURE----- --=_bOundary-- --===============0262109841== 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 --===============0262109841==--