From tcpm-bounces@ietf.org Tue May 01 22:04:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hj4Cg-0004Pq-En; Tue, 01 May 2007 22:04:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hj4Cf-0004LU-0P for tcpm@ietf.org; Tue, 01 May 2007 22:04:25 -0400 Received: from smtp107.sbc.mail.re2.yahoo.com ([68.142.229.98]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hj4Ca-0002bj-OO for tcpm@ietf.org; Tue, 01 May 2007 22:04:24 -0400 Received: (qmail 71209 invoked from network); 2 May 2007 02:04:20 -0000 Received: from unknown (HELO ?136.244.25.190?) (janaiyengar@sbcglobal.net@136.244.25.190 with plain) by smtp107.sbc.mail.re2.yahoo.com with SMTP; 2 May 2007 02:04:20 -0000 X-YMail-OSG: bEWj_7UVM1kyjwmQUQUPI5GAWhue9CpjEGBt2wniS_Zx8vScBNHR2mFiIzo.EVdHcgDx0aLoMRKZtwgQfUZTF3_7aG1bLa5ezxK8W6Ayo1Xp23tAUQ-- Message-ID: <4637F1A2.3050207@mail.eecis.udel.edu> Date: Tue, 01 May 2007 22:04:18 -0400 From: Janardhan Iyengar Organization: University of Delaware User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: "Armando L. Caro, Jr." Subject: Re: [tcpm] Adding Acknowledgement Congestion Control to TCP References: <07e0ad60d97a8cef94c214554aee0658@mac.com> <462FA142.5080904@bbn.com> In-Reply-To: <462FA142.5080904@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Janardhan Iyengar , David Ros , =?ISO-8859-1?Q?Andr=E9s_Arcia?= , tcpm 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 Hey Armando, (Sorry about the long delay!) > Have their been any studies that show that pure acks are a source of > congestion (that we should worry about)? I would expect them to be noise I don't think that matters really. If a link is congested, then all flows through it should respond to congestion signals. Even if the 'flow' is an ack flow. IMHO, that is the motivation for ack CC. > I'm concerned that reducing the number of acks when ack > losses occur is likely to make the problem worse. I would add this issue On the contrary, it seems to me that reducing the number of acks when the uplink is unable to handle as many acks is a GOOD thing. If the uplink is unable to handle the current ack rate, then ack CC will reduce the ack rate so that congestion on the ack path and ack loss will be reduced. > Re: Section 5.7. Appropriate byte counting allows the cwnd to be > increased by the number of bytes being acked, but there is a cap. Each > ack may increase the cwnd by at most 2*MSS. Thus, an ACK Ratio > 2 will > slow down cwnd growth during slow start. So the text should point to ABC > as guidance, but state that you are now proposing to break that cap and > use rate limiting to mitigate the bursts. Good catch. Thanks! > I like the list of possible complications. Except for the one I pointed > out above, I think you hit all the issues I thought of as I read the draft. Great! Thanks for the feedback! - 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 Wed May 02 08: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 1HjECs-0003xQ-Os; Wed, 02 May 2007 08:45:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjECr-0003v7-DH for tcpm@ietf.org; Wed, 02 May 2007 08:45:17 -0400 Received: from exchfenlb-2.cs.cornell.edu ([128.84.97.34] helo=exchfe2.cs.cornell.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjECq-0005PH-5C for tcpm@ietf.org; Wed, 02 May 2007 08:45:17 -0400 Received: from exchfe1.cs.cornell.edu ([128.84.97.33]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 May 2007 08:45:15 -0400 Received: from [172.23.16.21] ([172.23.16.21]) by exchfe1.cs.cornell.edu over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 May 2007 08:45:14 -0400 Subject: Re: [tcpm] WGLC: TCP's Reaction to Soft Errors From: Saikat Guha To: mallman@icir.org, 'Fernando Gont' In-Reply-To: <20070425034624.117871E18C7@lawyers.icir.org> References: <20070425034624.117871E18C7@lawyers.icir.org> Organization: Cornell University Date: Wed, 02 May 2007 08:45:23 -0400 Message-Id: <1178109923.25526.63.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) X-OriginalArrivalTime: 02 May 2007 12:45:15.0085 (UTC) FILETIME=[BB31B7D0:01C78CB7] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: 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="===============1221715871==" Errors-To: tcpm-bounces@ietf.org --===============1221715871== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Ii/XWJtLN2bpEvFkAGTk" --=-Ii/XWJtLN2bpEvFkAGTk Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2007-04-24 at 23:46 -0400, Mark Allman wrote: > > Title : TCP's Reaction to Soft Errors > > Author(s) : F. Gont > > Filename : draft-ietf-tcpm-tcp-soft-errors-05.txt I read the draft, and to the extent that the draft is informational and does not standardize treating soft-errors as hard I have no objections. The behavior described by the draft (that of considering soft errors as hard during SYN-SENT state after 0/n retransmissions), however, was a cause of concern for the NAT TCP Behavior document (draft-ietf-behave-tcp-07.txt), which is currently in the RFC editors queue. In that document, NATs are basically recommended to silently delay any ICMP errors by 6 seconds to avoid triggering any of the mechanism proposed in this document (proviso endpoints can coordinate to exchange SYN packets through that 6 second hole). IMHO it would help to point out in Section 3 (Problems that may arise from TCP's reaction to soft errors) and Section 6.2 (Possible drawbacks: Deterministic transient network failures) that stacks that treat ICMP soft errors as hard during connection initiation (at least in the first 6 seconds) make it difficult for applications attempting to initiate TCP Simultaneous-Open through a BEHAVE compliant NAT. cheers, --=20 Saikat --=-Ii/XWJtLN2bpEvFkAGTk Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBGOIfjnFltqi691/oRAhn7AJ4owsjMlHNkViCT0jSacF8IBMDEuwCfZQZH xdSap+Zn5IMwCcEb9NjQV1w= =VO2Q -----END PGP SIGNATURE----- --=-Ii/XWJtLN2bpEvFkAGTk-- --===============1221715871== 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 --===============1221715871==-- From tcpm-bounces@ietf.org Wed May 02 09:06: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 1HjEXq-0005Xe-OT; Wed, 02 May 2007 09:06:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjEXo-0005XO-MM; Wed, 02 May 2007 09:06:56 -0400 Received: from mx1.grc.nasa.gov ([128.156.11.68]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HjEXn-0003gJ-4a; Wed, 02 May 2007 09:06:56 -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 6075EC38B; Wed, 2 May 2007 09:06:53 -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 l42D6qdB007041; Wed, 2 May 2007 09:06:52 -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 l42D6pqx010554; Wed, 2 May 2007 09:06:52 -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 lO22qRWxPkOU; Wed, 2 May 2007 09:06:51 -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 l42D6nCi010527;Wed, 2 May 2007 09:06:49 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id 1ED4F4FE74; Wed, 2 May 2007 09:05:56 -0400 (EDT) Date: Wed, 2 May 2007 09:05:56 -0400 From: Wesley Eddy To: Pasi.Eronen@nokia.com Message-ID: <20070502130555.GA737@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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: tcpm-chairs@tools.ietf.org, secdir@mit.edu, tcpm@ietf.org, iesg@ietf.org Subject: [tcpm] Re: SecDir review of draft-ietf-tcpm-syn-flood-03 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 Wed, May 02, 2007 at 12:05:05PM +0300, Pasi.Eronen@nokia.com wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > Summary: Looks good! > > One possible suggestion: the draft talks about using MD5 to calculate > the cookies. Perhaps it would be a good idea to mention that other > algorithms can be used instead (since the cookie is interpreted by the > same host that generated it, using something else doesn't have to > be negotiated etc.). This is kinda obvious once you've read and > understood the whole document, but might be worth stating explicitly. > > Best regards, > Pasi Thanks for the review! How about if we change the sentence: "In practice, this hash has been generated using MD5." into: "In practice, this hash has been generated using MD5. Any similar one-way hash function could be used instead without impacting interoperability since the hash value is checked by the same host who generated it." Would that be better? -- 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 Wed May 02 13:10: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 1HjIL1-0003J3-VK; Wed, 02 May 2007 13:09:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjIL0-0003Ix-Og for tcpm@ietf.org; Wed, 02 May 2007 13:09:58 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjIKz-0007d0-9f for tcpm@ietf.org; Wed, 02 May 2007 13:09:58 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 1DDE6F0C461; Wed, 2 May 2007 14:09:56 -0300 (ART) Received: from fgont.gont.com.ar (237-176-231-201.fibertel.com.ar [201.231.176.237]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id l42H9nTm015825; Wed, 2 May 2007 14:09:51 -0300 Message-Id: <200705021709.l42H9nTm015825@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 02 May 2007 14:07:21 -0300 To: Saikat Guha , mallman@icir.org, "'Fernando Gont'" From: Fernando Gont Subject: Re: [tcpm] WGLC: TCP's Reaction to Soft Errors In-Reply-To: <1178109923.25526.63.camel@localhost.localdomain> References: <20070425034624.117871E18C7@lawyers.icir.org> <1178109923.25526.63.camel@localhost.localdomain> 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, 02 May 2007 14:09:55 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: 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: , Errors-To: tcpm-bounces@ietf.org At 09:45 a.m. 02/05/2007, Saikat Guha wrote: >IMHO it would help to point out in Section 3 (Problems that may arise > >from TCP's reaction to soft errors) and Section 6.2 (Possible drawbacks: >Deterministic transient network failures) that stacks that treat ICMP >soft errors as hard during connection initiation (at least in the first >6 seconds) make it difficult for applications attempting to initiate TCP >Simultaneous-Open through a BEHAVE compliant NAT. Could you clarify what is the reason for the 6-second delay? And, when you sent the ICMP error message after the 6 seconds, how are TCP stacks expected to react? (why do you send an ICMP error instead of a, say, RST segment?) 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 May 02 15:19: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 1HjKLx-0006bP-Fd; Wed, 02 May 2007 15:19:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjKLw-0006bK-KQ for tcpm@ietf.org; Wed, 02 May 2007 15:19:04 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjKLv-0007Mu-8S for tcpm@ietf.org; Wed, 02 May 2007 15:19:04 -0400 Received: from [127.0.0.1] (25.sub-75-215-133.myvzw.com [75.215.133.25]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l42JIfhk015893; Wed, 2 May 2007 12:18:43 -0700 (PDT) Message-ID: <4638E3FE.102@isi.edu> Date: Wed, 02 May 2007 12:18:22 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] WGLC: TCP's Reaction to Soft Errors References: <20070425034624.117871E18C7@lawyers.icir.org> <1178109923.25526.63.camel@localhost.localdomain> <200705021709.l42H9nTm015825@venus.xmundo.net> In-Reply-To: <200705021709.l42H9nTm015825@venus.xmundo.net> X-Enigmail-Version: 0.95.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: f60d0f7806b0c40781eee6b9cd0b2135 Cc: tcpm@ietf.org, Ted Faber , 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="===============0436179527==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0436179527== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDFFECADD779FF28656B1EA51" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDFFECADD779FF28656B1EA51 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > At 09:45 a.m. 02/05/2007, Saikat Guha wrote: >=20 >> IMHO it would help to point out in Section 3 (Problems that may arise >> >from TCP's reaction to soft errors) and Section 6.2 (Possible drawbac= ks: >> Deterministic transient network failures) that stacks that treat ICMP >> soft errors as hard during connection initiation (at least in the firs= t >> 6 seconds) make it difficult for applications attempting to initiate T= CP >> Simultaneous-Open through a BEHAVE compliant NAT. >=20 > Could you clarify what is the reason for the 6-second delay? I helped with this one in BEHAVE... It allows systems trying to allow two hosts behind NATs to handshake via SYNs. The outgoing SYNs are there to open the port in the reverse direction; if they aren't very tightly synchronized, one will show up coming into a NAT (from the public side) before its pair has a chance to open that port as it exits that NAT (from the private side). The delay allows the handshake to occur without ICMP processing shutting it down. It's valid because there's no timeliness requirement in ICMP responses (if there were, we'd have big problems everywhere). > And, when you sent the ICMP error message after the 6 seconds, how are > TCP stacks expected to react? (why do you send an ICMP error instead of= > a, say, RST segment?) They ought to react the same way they do now. :-) You send that error because you got a SYN for which the port wasn't yet opened, which is a policy violation not a TCP connection failure. Joe --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enigDFFECADD779FF28656B1EA51 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 iD8DBQFGOOP/E5f5cImnZrsRAvMRAKCAqS9ovOqOHbipd2XbDtMKyEcMowCfTWcd tdJnpwEw55mXfOUEUJoD/RM= =9GKd -----END PGP SIGNATURE----- --------------enigDFFECADD779FF28656B1EA51-- --===============0436179527== 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 --===============0436179527==-- From tcpm-bounces@ietf.org Wed May 02 16:31: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 1HjLTi-0003m8-HV; Wed, 02 May 2007 16:31:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjLTh-0003lu-FT for tcpm@ietf.org; Wed, 02 May 2007 16:31:09 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjLTf-0006Om-Hn for tcpm@ietf.org; Wed, 02 May 2007 16:31:09 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 2E8E1F0C454; Wed, 2 May 2007 17:31:09 -0300 (ART) Received: from fgont.gont.com.ar (237-176-231-201.fibertel.com.ar [201.231.176.237]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id l42KUVVI023241; Wed, 2 May 2007 17:31:00 -0300 Message-Id: <200705022031.l42KUVVI023241@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 02 May 2007 17:30:22 -0300 To: Joe Touch , Fernando Gont From: Fernando Gont Subject: Re: [tcpm] WGLC: TCP's Reaction to Soft Errors In-Reply-To: <4638E3FE.102@isi.edu> References: <20070425034624.117871E18C7@lawyers.icir.org> <1178109923.25526.63.camel@localhost.localdomain> <200705021709.l42H9nTm015825@venus.xmundo.net> <4638E3FE.102@isi.edu> 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, 02 May 2007 17:31:05 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: tcpm@ietf.org, Ted Faber , 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 At 04:18 p.m. 02/05/2007, Joe Touch wrote: >It allows systems trying to allow two hosts behind NATs to handshake via >SYNs. The outgoing SYNs are there to open the port in the reverse >direction; if they aren't very tightly synchronized, one will show up >coming into a NAT (from the public side) before its pair has a chance to >open that port as it exits that NAT (from the private side). The delay >allows the handshake to occur without ICMP processing shutting it down. Okay. But then, we're safe here... I mean, even if "soft errors" is implemented, the simultaneous open will succeed through the NAT (with the stuff you proposed) >It's valid because there's no timeliness requirement in ICMP responses >(if there were, we'd have big problems everywhere). If you have any specific concerns of the problems that would arise as a result of this, I'd like to know. (not to raise a discussion, but rather because I'm wondering what you are thinking of) > > And, when you sent the ICMP error message after the 6 seconds, how are > > TCP stacks expected to react? (why do you send an ICMP error instead of > > a, say, RST segment?) > >They ought to react the same way they do now. :-) abort the connection at once, abort it after 75 seconds (or so), or abort it only after a user timeout? :-) (all three are currently implemented) >You send that error because you got a SYN for which the port wasn't yet >opened, which is a policy violation not a TCP connection failure. Do you recall which type/code they send? 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 May 02 16:57: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 1HjLtH-0005QG-Jt; Wed, 02 May 2007 16:57:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjLtG-0005QA-Lg for tcpm@ietf.org; Wed, 02 May 2007 16:57:34 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjLtF-0007lL-9f for tcpm@ietf.org; Wed, 02 May 2007 16:57:34 -0400 Received: from [127.0.0.1] (25.sub-75-215-133.myvzw.com [75.215.133.25]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l42KvIVG007360; Wed, 2 May 2007 13:57:21 -0700 (PDT) Message-ID: <4638FB1B.1090407@isi.edu> Date: Wed, 02 May 2007 13:56:59 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] WGLC: TCP's Reaction to Soft Errors References: <20070425034624.117871E18C7@lawyers.icir.org> <1178109923.25526.63.camel@localhost.localdomain> <200705021709.l42H9nTm015825@venus.xmundo.net> <4638E3FE.102@isi.edu> <200705022031.l42KUVVI023241@venus.xmundo.net> In-Reply-To: <200705022031.l42KUVVI023241@venus.xmundo.net> X-Enigmail-Version: 0.95.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: fb6060cb60c0cea16e3f7219e40a0a81 Cc: tcpm@ietf.org, Ted Faber , 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="===============2038802902==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2038802902== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig91E98A9AC1B54F1243B5FC45" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig91E98A9AC1B54F1243B5FC45 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > At 04:18 p.m. 02/05/2007, Joe Touch wrote: =2E.. >> > And, when you sent the ICMP error message after the 6 seconds, how a= re >> > TCP stacks expected to react? (why do you send an ICMP error instead= of >> > a, say, RST segment?) >> >> They ought to react the same way they do now. :-) >=20 > abort the connection at once, abort it after 75 seconds (or so), or > abort it only after a user timeout? :-) (all three are currently > implemented) The ICMP would not get sent if the second SYN gets through; that aborts the pending ICMP which is held for 6 seconds. I.e., if the connection succeeds there is no ICMP to decipher. If the connection fails, you get an ICMP error to a pending SYN, which should only abort a pending connection (and should do so immediately, since it should be interpreted as if a RST anyway). >> You send that error because you got a SYN for which the port wasn't ye= t >> opened, which is a policy violation not a TCP connection failure. >=20 > Do you recall which type/code they send? REQ-4: A NAT MUST NOT respond to an unsolicited inbound SYN packet for at least 6 seconds after the packet is received. If during this interval the NAT receives and translates an outbound SYN for the connection the NAT MUST silently drop the original unsolicited inbound SYN packet. Otherwise the NAT SHOULD send an ICMP Port Unreachable error (Type 3, Code 3) for the original SYN, unless REQ-4a applies. i.e., port unreachable, which are supposed to be hard errors. I don't think this affects either of your docs (soft-errors or ICMP-attacks), since the ICMP is issued only if the connection has yet to be established (not covered in the latter) and it's a hard error (not covered by the former). Joe --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enig91E98A9AC1B54F1243B5FC45 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 iD8DBQFGOPsbE5f5cImnZrsRAtEVAJ9hawABTDggZUDuhy3wFlMHBsXVowCgqI1l 4HC3ePA0WatRIGKIJxA0imw= =btp4 -----END PGP SIGNATURE----- --------------enig91E98A9AC1B54F1243B5FC45-- --===============2038802902== 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 --===============2038802902==-- From tcpm-bounces@ietf.org Wed May 02 17:05: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 1HjM0b-000807-Ux; Wed, 02 May 2007 17:05:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjM0a-0007vz-Me for tcpm@ietf.org; Wed, 02 May 2007 17:05:08 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjM0a-0002fF-Ap for tcpm@ietf.org; Wed, 02 May 2007 17:05:08 -0400 Received: from [127.0.0.1] (25.sub-75-215-133.myvzw.com [75.215.133.25]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l42L4Ojl008643; Wed, 2 May 2007 14:04:26 -0700 (PDT) Message-ID: <4638FCC6.6030204@isi.edu> Date: Wed, 02 May 2007 14:04:06 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] WGLC: TCP's Reaction to Soft Errors References: <20070425034624.117871E18C7@lawyers.icir.org> <1178109923.25526.63.camel@localhost.localdomain> <200705021709.l42H9nTm015825@venus.xmundo.net> <4638E3FE.102@isi.edu> <200705022031.l42KUVVI023241@venus.xmundo.net> In-Reply-To: <200705022031.l42KUVVI023241@venus.xmundo.net> X-Enigmail-Version: 0.95.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, Ted Faber , 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="===============1690890585==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1690890585== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAD7A24E78A48C908374FC80A" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAD7A24E78A48C908374FC80A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > At 04:18 p.m. 02/05/2007, Joe Touch wrote: >=20 >> It allows systems trying to allow two hosts behind NATs to handshake v= ia >> SYNs. The outgoing SYNs are there to open the port in the reverse >> direction; if they aren't very tightly synchronized, one will show up >> coming into a NAT (from the public side) before its pair has a chance = to >> open that port as it exits that NAT (from the private side). The delay= >> allows the handshake to occur without ICMP processing shutting it down= =2E >=20 > Okay. But then, we're safe here... I mean, even if "soft errors" is > implemented, the simultaneous open will succeed through the NAT (with > the stuff you proposed) Agreed. >> It's valid because there's no timeliness requirement in ICMP responses= >> (if there were, we'd have big problems everywhere). >=20 > If you have any specific concerns of the problems that would arise as a= > result of this, I'd like to know. (not to raise a discussion, but rathe= r > because I'm wondering what you are thinking of) "big problems" refers to "if we needed ICMP to be timely" - since routers tend to do ICMP processing somewhat off-line. I.e., I don't want us to consider ICMPs that need to be timely, since that's never been a requirement. That issue also comes up if we talk about checking in-window of TCP segments inside ICMPs (your ICMP-attacks I-D? I don't recall for sure which doc, or whether it's currently still there), since there's no requirement that the ICMP be issued within one RTT, so the window therein has no meaning. I raised this issue several times before, most recently in San Diego if I recall correctly (except for dinners, IETFs tend to run together). Joe --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enigAD7A24E78A48C908374FC80A 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 iD8DBQFGOPzGE5f5cImnZrsRAp+MAKDkJpmXpaQYdWEWUQKXs6zCC/zeCwCgvpiC gG1GZLXxlH0aVbo3thQWjXI= =fm6U -----END PGP SIGNATURE----- --------------enigAD7A24E78A48C908374FC80A-- --===============1690890585== 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 --===============1690890585==-- From tcpm-bounces@ietf.org Wed May 02 17:35: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 1HjMTn-0006mW-6e; Wed, 02 May 2007 17:35:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjMTm-0006mA-PZ for tcpm@ietf.org; Wed, 02 May 2007 17:35:18 -0400 Received: from exchfenlb-2.cs.cornell.edu ([128.84.97.34] helo=exchfe2.cs.cornell.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjMTk-0006pf-Gn for tcpm@ietf.org; Wed, 02 May 2007 17:35:18 -0400 Received: from exchfe2.cs.cornell.edu ([128.84.97.28]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 May 2007 17:35:15 -0400 Received: from [192.168.11.3] ([24.59.192.172]) by exchfe2.cs.cornell.edu over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 May 2007 17:35:15 -0400 Subject: Re: [tcpm] WGLC: TCP's Reaction to Soft Errors From: Saikat Guha To: Fernando Gont In-Reply-To: <200705022031.l42KUVVI023241@venus.xmundo.net> References: <20070425034624.117871E18C7@lawyers.icir.org> <1178109923.25526.63.camel@localhost.localdomain> <200705021709.l42H9nTm015825@venus.xmundo.net> <4638E3FE.102@isi.edu> <200705022031.l42KUVVI023241@venus.xmundo.net> Organization: Cornell University Date: Wed, 02 May 2007 17:31:52 -0400 Message-Id: <1178141512.25526.83.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) X-OriginalArrivalTime: 02 May 2007 21:35:15.0461 (UTC) FILETIME=[C5B20350:01C78D01] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: tcpm@ietf.org, mallman@icir.org, Ted Faber , 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="===============1895566154==" Errors-To: tcpm-bounces@ietf.org --===============1895566154== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-4b3B9+EWZ3jak+Qbp5AQ" --=-4b3B9+EWZ3jak+Qbp5AQ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2007-05-02 at 17:30 -0300, Fernando Gont wrote: > Okay. But then, we're safe here... I mean, even if "soft errors" is=20 > implemented, the simultaneous open will succeed through the NAT (with=20 > the stuff you proposed) This is true assuming that 6 seconds is enough for the ends to coordinate the setup. 6 seconds was really a number out of a hat; enough for one SYN rexmit, and enough for vendors with embedded devices with CPUs that took coffee breaks to feel comfortable with it. In a rather contrived scenario where 6 seconds is not enough for coordinating the SYNs, a stack (such as Windows) that ignores the ICMP errors (hard errors even!) would succeed in traversing the NAT. In another scenario, yet-to-be-published BEHAVE recommendations notwithstanding, there exist deployed NATs today that instantly return ICMP host unreachables (soft error). I don't believe the approach proposed in your document needs to account for cases where BEHAVE assumptions are violated (6 seconds not enough / non BEHAVE compliant NAT) or the stack doesn't respect hard errors (Windows). However, IMHO this interaction between NAT ICMPs, stacks that process them, and its effect on NAT traversal is a potential pitfall / source of problems that should be documented. cheers, --=20 Saikat --=-4b3B9+EWZ3jak+Qbp5AQ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBGOQNHnFltqi691/oRAgQsAJ9XtVL2byLTBYQMs+8rhDuhCvJrNACdGjTh f6dv9isvG5a/dfmA0gda/sw= =eOnt -----END PGP SIGNATURE----- --=-4b3B9+EWZ3jak+Qbp5AQ-- --===============1895566154== 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 --===============1895566154==-- From tcpm-bounces@ietf.org Wed May 02 17:35: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 1HjMTs-0006uv-DZ; Wed, 02 May 2007 17:35:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjMTr-0006tr-Ff for tcpm@ietf.org; Wed, 02 May 2007 17:35:23 -0400 Received: from exchfenlb-2.cs.cornell.edu ([128.84.97.34] helo=exchfe2.cs.cornell.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjMTq-0006pk-7u for tcpm@ietf.org; Wed, 02 May 2007 17:35:23 -0400 Received: from exchfe2.cs.cornell.edu ([128.84.97.28]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 May 2007 17:35:21 -0400 Received: from [192.168.11.3] ([24.59.192.172]) by exchfe2.cs.cornell.edu over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 May 2007 17:35:21 -0400 Subject: Re: [tcpm] WGLC: TCP's Reaction to Soft Errors From: Saikat Guha To: Fernando Gont In-Reply-To: <200705022031.l42KUVVI023241@venus.xmundo.net> References: <20070425034624.117871E18C7@lawyers.icir.org> <1178109923.25526.63.camel@localhost.localdomain> <200705021709.l42H9nTm015825@venus.xmundo.net> <4638E3FE.102@isi.edu> <200705022031.l42KUVVI023241@venus.xmundo.net> Organization: Cornell University Date: Wed, 02 May 2007 17:31:52 -0400 Message-Id: <1178141512.25526.83.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) X-OriginalArrivalTime: 02 May 2007 21:35:21.0258 (UTC) FILETIME=[C92690A0:01C78D01] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: tcpm@ietf.org, mallman@icir.org, Ted Faber , 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="===============1329475691==" Errors-To: tcpm-bounces@ietf.org --===============1329475691== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-4b3B9+EWZ3jak+Qbp5AQ" --=-4b3B9+EWZ3jak+Qbp5AQ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2007-05-02 at 17:30 -0300, Fernando Gont wrote: > Okay. But then, we're safe here... I mean, even if "soft errors" is=20 > implemented, the simultaneous open will succeed through the NAT (with=20 > the stuff you proposed) This is true assuming that 6 seconds is enough for the ends to coordinate the setup. 6 seconds was really a number out of a hat; enough for one SYN rexmit, and enough for vendors with embedded devices with CPUs that took coffee breaks to feel comfortable with it. In a rather contrived scenario where 6 seconds is not enough for coordinating the SYNs, a stack (such as Windows) that ignores the ICMP errors (hard errors even!) would succeed in traversing the NAT. In another scenario, yet-to-be-published BEHAVE recommendations notwithstanding, there exist deployed NATs today that instantly return ICMP host unreachables (soft error). I don't believe the approach proposed in your document needs to account for cases where BEHAVE assumptions are violated (6 seconds not enough / non BEHAVE compliant NAT) or the stack doesn't respect hard errors (Windows). However, IMHO this interaction between NAT ICMPs, stacks that process them, and its effect on NAT traversal is a potential pitfall / source of problems that should be documented. cheers, --=20 Saikat --=-4b3B9+EWZ3jak+Qbp5AQ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBGOQNHnFltqi691/oRAgQsAJ9XtVL2byLTBYQMs+8rhDuhCvJrNACdGjTh f6dv9isvG5a/dfmA0gda/sw= =eOnt -----END PGP SIGNATURE----- --=-4b3B9+EWZ3jak+Qbp5AQ-- --===============1329475691== 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 --===============1329475691==-- From tcpm-bounces@ietf.org Wed May 02 19:12: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 1HjO01-0005kG-F0; Wed, 02 May 2007 19:12:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjO00-0005iN-9s for tcpm@ietf.org; Wed, 02 May 2007 19:12:40 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjNzx-0004QH-TU for tcpm@ietf.org; Wed, 02 May 2007 19:12:40 -0400 Received: from [127.0.0.1] (25.sub-75-215-133.myvzw.com [75.215.133.25]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l42NCCcM003258; Wed, 2 May 2007 16:12:15 -0700 (PDT) Message-ID: <46391AB9.8080808@isi.edu> Date: Wed, 02 May 2007 16:11:53 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Saikat Guha Subject: Re: [tcpm] WGLC: TCP's Reaction to Soft Errors References: <20070425034624.117871E18C7@lawyers.icir.org> <1178109923.25526.63.camel@localhost.localdomain> <200705021709.l42H9nTm015825@venus.xmundo.net> <4638E3FE.102@isi.edu> <200705022031.l42KUVVI023241@venus.xmundo.net> <1178141512.25526.83.camel@localhost.localdomain> In-Reply-To: <1178141512.25526.83.camel@localhost.localdomain> X-Enigmail-Version: 0.95.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: d8ae4fd88fcaf47c1a71c804d04f413d Cc: tcpm@ietf.org, Ted Faber , Fernando Gont , 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="===============1600798736==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1600798736== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEDD5C5ECBEE93ABEF9667825" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEDD5C5ECBEE93ABEF9667825 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Saikat Guha wrote: > On Wed, 2007-05-02 at 17:30 -0300, Fernando Gont wrote: >> Okay. But then, we're safe here... I mean, even if "soft errors" is=20 >> implemented, the simultaneous open will succeed through the NAT (with = >> the stuff you proposed) >=20 > This is true assuming that 6 seconds is enough for the ends to > coordinate the setup. 6 seconds was really a number out of a hat; enoug= h > for one SYN rexmit, and enough for vendors with embedded devices with > CPUs that took coffee breaks to feel comfortable with it. >=20 > In a rather contrived scenario where 6 seconds is not enough for > coordinating the SYNs, a stack (such as Windows) that ignores the ICMP > errors (hard errors even!) would succeed in traversing the NAT. In > another scenario, yet-to-be-published BEHAVE recommendations > notwithstanding, there exist deployed NATs today that instantly return > ICMP host unreachables (soft error). Nice. Presumably they respond that way to all packets to their public address? Otherwise, they're basically flaunting that they're flakey. > I don't believe the approach proposed in your document needs to account= > for cases where BEHAVE assumptions are violated (6 seconds not enough /= > non BEHAVE compliant NAT) or the stack doesn't respect hard errors > (Windows). However, IMHO this interaction between NAT ICMPs, stacks tha= t > process them, and its effect on NAT traversal is a potential pitfall / > source of problems that should be documented. The behavior of a non-BEHAVE NAT or improper hard error processing should be obvious, but we don't typically document such behavior except when it's a pervasive issue, and we have called them "implementation problems" (e.g., RFC 2525). The fact that NATs might return host unreachable might be worth noting, perhaps somewhere such as the "public side is a host; private side is a router" doc I'm currently thinking of drafting (i.e., this is a place where NATs violate that rule-of-thumb, and there are pitfalls). This gives me further reason to work on that doc... ;-) Joe --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enigEDD5C5ECBEE93ABEF9667825 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 iD8DBQFGORq5E5f5cImnZrsRAp48AJ9P4GrIWPTONcOs5Ts0FzQTdAIRYQCg93QP 1eyOEcvXbD61cg9+cYgGaNA= =qkq2 -----END PGP SIGNATURE----- --------------enigEDD5C5ECBEE93ABEF9667825-- --===============1600798736== 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 --===============1600798736==-- From tcpm-bounces@ietf.org Wed May 02 19:29: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 1HjOFu-0001KW-Ei; Wed, 02 May 2007 19:29:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjOFt-0001KR-1j for tcpm@ietf.org; Wed, 02 May 2007 19:29:05 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjOFs-0006JV-Ft for tcpm@ietf.org; Wed, 02 May 2007 19:29:05 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 032C6F0C4CE; Wed, 2 May 2007 20:29:08 -0300 (ART) Received: from fgont.gont.com.ar (237-176-231-201.fibertel.com.ar [201.231.176.237]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id l42NSmvv021949; Wed, 2 May 2007 20:29:02 -0300 Message-Id: <200705022329.l42NSmvv021949@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 02 May 2007 20:21:29 -0300 To: Saikat Guha From: Fernando Gont Subject: Re: [tcpm] WGLC: TCP's Reaction to Soft Errors In-Reply-To: <1178141512.25526.83.camel@localhost.localdomain> References: <20070425034624.117871E18C7@lawyers.icir.org> <1178109923.25526.63.camel@localhost.localdomain> <200705021709.l42H9nTm015825@venus.xmundo.net> <4638E3FE.102@isi.edu> <200705022031.l42KUVVI023241@venus.xmundo.net> <1178141512.25526.83.camel@localhost.localdomain> 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, 02 May 2007 20:29:07 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: tcpm@ietf.org, mallman@icir.org, Ted Faber , 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 At 06:31 p.m. 02/05/2007, Saikat Guha wrote: >In a rather contrived scenario where 6 seconds is not enough for >coordinating the SYNs, a stack (such as Windows) that ignores the ICMP >errors (hard errors even!) would succeed in traversing the NAT. Windows honors hard errors for established connections. Do they ignore them for non-synchronized connections??? >In >another scenario, yet-to-be-published BEHAVE recommendations >notwithstanding, there exist deployed NATs today that instantly return >ICMP host unreachables (soft error). Why do they send host unreachables instead of port unreachables? >I don't believe the approach proposed in your document needs to account >for cases where BEHAVE assumptions are violated (6 seconds not enough / >non BEHAVE compliant NAT) or the stack doesn't respect hard errors >(Windows). However, IMHO this interaction between NAT ICMPs, stacks that >process them, and its effect on NAT traversal is a potential pitfall / >source of problems that should be documented. Correct me if I am wrong: The current BEHAVE requirements for TCP are that if an incoming SYN is received, and after 6 seconds a SYN is not seen the other way, an ICMP port unreachable is sent. This message is a hard error, to be processed during the conenction-establishment phase. Therefore, it does not really affect neither the soft errors draft nor the icmp attacks draft. But there are some (non compliant) NATs out there that send icmp host(?) unreachables for the same scenario. In this case, if after 6 seconds of receiving an incoming SYN an outgoing SYN is not seen by the NAT, a host unreachable would be sent, and thus the connection would be aborted (?). This is the scenario that should be mentioned? Aside: Do implementations correctly handle simultaneous opens? Some time ago I read a paper with a proposal for dealing with SYN floods that I had played with a while ago: When you receive an incoming SYN, you send a SYN cookie *but* you don't set the ACK bit, and you don't keep state for this connection. The client will think that a simultaneous open took place, and thus retransmit its SYN (i.e., including all the same options as the original SYN). This way, you have SYN cookies, but you don't "lose" options. However, the author noted that many stacks did not handle "simultaneous opens" correctly. If anybody is interested, I can provide a pointer to the paper (would have to look on my HD) 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 Wed May 02 19:37:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjONx-00058o-2b; Wed, 02 May 2007 19:37:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjONv-00058g-IB for tcpm@ietf.org; Wed, 02 May 2007 19:37:23 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjONv-0007Ql-0p for tcpm@ietf.org; Wed, 02 May 2007 19:37:23 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 8EFF7F0C4CD; Wed, 2 May 2007 20:37:26 -0300 (ART) Received: from fgont.gont.com.ar (237-176-231-201.fibertel.com.ar [201.231.176.237]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id l42NbKkV031001; Wed, 2 May 2007 20:37:21 -0300 Message-Id: <200705022337.l42NbKkV031001@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 02 May 2007 20:36:52 -0300 To: Joe Touch From: Fernando Gont In-Reply-To: <4638FCC6.6030204@isi.edu> References: <20070425034624.117871E18C7@lawyers.icir.org> <1178109923.25526.63.camel@localhost.localdomain> <200705021709.l42H9nTm015825@venus.xmundo.net> <4638E3FE.102@isi.edu> <200705022031.l42KUVVI023241@venus.xmundo.net> <4638FCC6.6030204@isi.edu> 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, 02 May 2007 20:37:26 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: tcpm@ietf.org, Ted Faber , mallman@icir.org Subject: [tcpm] Timeliness requierments for ICMP 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:04 p.m. 02/05/2007, Joe Touch wrote: (subject changed to reflect current discussion) > >> It's valid because there's no timeliness requirement in ICMP responses > >> (if there were, we'd have big problems everywhere). > > > > If you have any specific concerns of the problems that would arise as a > > result of this, I'd like to know. (not to raise a discussion, but rather > > because I'm wondering what you are thinking of) > >"big problems" refers to "if we needed ICMP to be timely" - since >routers tend to do ICMP processing somewhat off-line. I.e., I don't want >us to consider ICMPs that need to be timely, since that's never been a >requirement. I understand. I was meaning if you could think of something that would "break" by adding this requirement. >That issue also comes up if we talk about checking in-window of TCP >segments inside ICMPs (your ICMP-attacks I-D? I don't recall for sure >which doc, or whether it's currently still there), Yes, icmp-attacks. (btw, I have asked the secretariat to repost the latest version, as the previous one expired) >since there's no >requirement that the ICMP be issued within one RTT, so the window >therein has no meaning. I raised this issue several times before, most >recently in San Diego if I recall correctly (except for dinners, IETFs >tend to run together). Yes. I understand that there's currently no requirement for timeliness in ICMP. I'm just thinking: if there were, would anything break? (In practice, it doesn't seem to break anything... as the sequence number check is implemented by virtually all implementations. However, I'm still interested in "what could theoretically break") 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 Wed May 02 19:41: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 1HjORx-0001gU-85; Wed, 02 May 2007 19:41:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjORv-0001gP-Q5 for tcpm@ietf.org; Wed, 02 May 2007 19:41:31 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjORu-0008A0-Eg for tcpm@ietf.org; Wed, 02 May 2007 19:41:31 -0400 Received: from [127.0.0.1] (25.sub-75-215-133.myvzw.com [75.215.133.25]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l42Nf4gn008108; Wed, 2 May 2007 16:41:07 -0700 (PDT) Message-ID: <4639217D.20307@isi.edu> Date: Wed, 02 May 2007 16:40:45 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Fernando Gont References: <20070425034624.117871E18C7@lawyers.icir.org> <1178109923.25526.63.camel@localhost.localdomain> <200705021709.l42H9nTm015825@venus.xmundo.net> <4638E3FE.102@isi.edu> <200705022031.l42KUVVI023241@venus.xmundo.net> <4638FCC6.6030204@isi.edu> <200705022337.l42NbKkV031001@venus.xmundo.net> In-Reply-To: <200705022337.l42NbKkV031001@venus.xmundo.net> X-Enigmail-Version: 0.95.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: tcpm@ietf.org, Ted Faber , mallman@icir.org Subject: [tcpm] Re: Timeliness requierments for ICMP 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="===============0121818702==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0121818702== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig38198509564D828AADFE8C55" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig38198509564D828AADFE8C55 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > At 06:04 p.m. 02/05/2007, Joe Touch wrote: >=20 > (subject changed to reflect current discussion) =2E.. >> since there's no >> requirement that the ICMP be issued within one RTT, so the window >> therein has no meaning. I raised this issue several times before, most= >> recently in San Diego if I recall correctly (except for dinners, IETFs= >> tend to run together). >=20 > Yes. I understand that there's currently no requirement for timeliness > in ICMP. I'm just thinking: if there were, would anything break? Except for existing implementations of routers and hosts that offload ICMP to outboard processors? I.e., it changes router design to have such a requirement. > (In practice, it doesn't seem to break anything... as the sequence > number check is implemented by virtually all implementations. However, > I'm still interested in "what could theoretically break") In practice, we don't stress the window much either. I.e., the reason things don't break isn't because they're not on the verge of doing so. Joe --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enig38198509564D828AADFE8C55 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 iD8DBQFGOSF9E5f5cImnZrsRApApAJwPcjX8cf+BgvBwYNUCFt2ALsEH5gCg9LGF qkpbybIMlgsjyGU1ZHvK93M= =vmG4 -----END PGP SIGNATURE----- --------------enig38198509564D828AADFE8C55-- --===============0121818702== 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 --===============0121818702==-- From tcpm-bounces@ietf.org Wed May 02 20:14: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 1HjOxU-0001kr-5M; Wed, 02 May 2007 20:14:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjOxT-0001km-7A for tcpm@ietf.org; Wed, 02 May 2007 20:14:07 -0400 Received: from exchfenlb-2.cs.cornell.edu ([128.84.97.34] helo=exchfe2.cs.cornell.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjOxR-0003D6-Ta for tcpm@ietf.org; Wed, 02 May 2007 20:14:07 -0400 Received: from exchfe1.cs.cornell.edu ([128.84.97.33]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 May 2007 20:14:00 -0400 Received: from [128.84.227.36] ([128.84.227.36]) by exchfe1.cs.cornell.edu over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 May 2007 20:13:55 -0400 Subject: Re: [tcpm] WGLC: TCP's Reaction to Soft Errors From: Saikat Guha To: Fernando Gont In-Reply-To: <200705022329.l42NSmvv021949@venus.xmundo.net> References: <20070425034624.117871E18C7@lawyers.icir.org> <1178109923.25526.63.camel@localhost.localdomain> <200705021709.l42H9nTm015825@venus.xmundo.net> <4638E3FE.102@isi.edu> <200705022031.l42KUVVI023241@venus.xmundo.net> <1178141512.25526.83.camel@localhost.localdomain> <200705022329.l42NSmvv021949@venus.xmundo.net> Date: Wed, 02 May 2007 20:13:55 -0400 Message-Id: <1178151235.26863.24.camel@sioux.systems.cs.cornell.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 (2.10.1-4.fc7) X-OriginalArrivalTime: 03 May 2007 00:13:55.0487 (UTC) FILETIME=[F012B2F0:01C78D17] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: tcpm@ietf.org, 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="===============1750637754==" Errors-To: tcpm-bounces@ietf.org --===============1750637754== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-DltkUUxygO+a7BCkam6b" --=-DltkUUxygO+a7BCkam6b Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2007-05-02 at 20:21 -0300, Fernando Gont wrote: > Windows honors hard errors for established connections. Do they=20 > ignore them for non-synchronized connections??? IIRC Windows XP (at least around March'05, pre-SP2) ignored ICMP errors for connections in SYN-SENT state (certainly soft errors, but also hard errors IIRC). That behavior may since have changed in SP2, which also added/fixed support for TCP Simultaneous-Open. > >In > >another scenario, yet-to-be-published BEHAVE recommendations > >notwithstanding, there exist deployed NATs today that instantly return > >ICMP host unreachables (soft error). >=20 > Why do they send host unreachables instead of port unreachables? I wish I knew; NATs in the wild do all sorts of crazy things.=20 > The current BEHAVE requirements for TCP are that if an incoming SYN=20 > is received, and after 6 seconds a SYN is not seen the other way, an=20 > ICMP port unreachable is sent. This message is a hard error, to be=20 > processed during the conenction-establishment phase. Therefore, it=20 > does not really affect neither the soft errors draft nor the icmp=20 > attacks draft. Correct. BEHAVE compliant NATs should not affect either of these documents one way or another.=20 > But there are some (non compliant) NATs out there that send icmp=20 > host(?) unreachables for the same scenario. In this case, if after 6=20 > seconds of receiving an incoming SYN an outgoing SYN is not seen by=20 > the NAT, a host unreachable would be sent, and thus the connection=20 > would be aborted (?). This is the scenario that should be mentioned? Non compliant NATs are not bound by the 6 second rule. Some existing non compliant NATs instantly send a soft error. As Joe mentioned, they may simply be classified as an implementation problem; or may be called out in the soft errors document if it is in scope. > Aside: Do implementations correctly handle simultaneous opens?=20 Windows XP pre-SP2 -- No Windows XP SP2, Linux, OpenBSD -- Yes Vista, MaxOS, others -- Not tested Aside from the host OS, many NATs (32%) do not support TCP S-O, although some firmwares have since been updated to add support for it. (https://www.guha.cc/saikat/stunt-results.php?sort=3D24 Incoming SYN after outgoing SYN column) --=20 Saikat --=-DltkUUxygO+a7BCkam6b Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBGOSlDnFltqi691/oRAk1AAJ9VqAnjnc07lmSeJWsLOMA+OA/lNACePPjl gygwdb7X/zi51kdnf5W8FNo= =8Mad -----END PGP SIGNATURE----- --=-DltkUUxygO+a7BCkam6b-- --===============1750637754== 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 --===============1750637754==-- From tcpm-bounces@ietf.org Thu May 03 08:25: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 1HjaMh-0006g7-Em; Thu, 03 May 2007 08:24:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjaMg-0006cT-Eg for tcpm@ietf.org; Thu, 03 May 2007 08:24:54 -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 1HjaMf-0000Qr-N6 for tcpm@ietf.org; Thu, 03 May 2007 08:24:54 -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 l43COUaw013140; Thu, 3 May 2007 15:24:48 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 May 2007 15:24:06 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 May 2007 15:24:06 +0300 Received: from [172.21.50.145] ([172.21.50.145]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 May 2007 15:24:06 +0300 Subject: Re: [tcpm] WGLC: TCP's Reaction to Soft Errors From: Pasi Sarolahti To: mallman@icir.org In-Reply-To: <20070425034624.117871E18C7@lawyers.icir.org> References: <20070425034624.117871E18C7@lawyers.icir.org> Organization: Nokia Research Center Date: Thu, 03 May 2007 15:24:05 +0300 Message-Id: <1178195045.25601.40.camel@siddha.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-1.fc6) X-OriginalArrivalTime: 03 May 2007 12:24:06.0136 (UTC) FILETIME=[F1413780:01C78D7D] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: 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="===============0439845582==" Errors-To: tcpm-bounces@ietf.org --===============0439845582== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Dyk75w1e5O86BMy14ceC" --=-Dyk75w1e5O86BMy14ceC Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2007-04-24 at 23:46 -0400, ext Mark Allman wrote: > > Mark and I would like to start a WG last call on the informational > > document on TCP's reaction to soft ICMP errors on connection set-up: I read the latest version of soft-errors-draft, and overall the draft looks ok to me. If I remember it correctly, earlier there were some concerns about the language being too strong for an informational document, but the current version seems ok also in this respect. The draft is in fact quite explicit that the documented behavior is in conflict with the standard TCP, and no change to the current standard is proposed. I also think this is a useful draft, because it describes a relevant problem in address resolution for dual-stack/multihomed hosts, and documents a widely implemented workaround. Some additional comments below. Many of them are stylish issues that can be ignored if you disagree about them. Abstract: > This document describes a non-standard, but widely implemented, > modification to TCP's handling of ICMP soft error messages received > in any of the non-synchronized states, that rejects connections > experiencing those errors immediately. This behavior reduces the The first sentence of abstract is a bit unclear. How about: "...that immediately rejects connections experiencing ICMP soft errors." Section 1., paragraph 4: > This document analyzes the fault recovery strategy of TCP [RFC0793], > and the problems that may arise due to TCP's reaction to ICMP soft > errors. Among others, it analyzes the problems that may arise in > scenarios where dual stack nodes that have IPv6 enabled by default > are deployed in IPv4 or mixed IPv4 and IPv6 environments. It could be useful to mention here that the same problem and the same workaround also applies in general for multihomed destinations that can be reached by multiple addresses. Section 2, paragraph 2: > The Host Requirements RFC [RFC1122] states, in Section 4.2.3.9., that > the ICMP messages that indicate soft errors are ICMP "Destination > Unreachable" codes 0 (network unreachable), 1 (host unreachable), and > 5 (source route failed), ICMP "Time Exceeded" codes 0 (time to live > exceeded in transit) and 1 (fragment reassembly time exceeded), and > ICMP "Parameter Problem". Even though ICMPv6 didn't exist when > [RFC1122] was written, one could extrapolate the concept of soft > errors to ICMPv6 "Destination Unreachable" codes 0 (no route to > destination) and 3 (address unreachable), ICMPv6 "Time Exceeded" > codes 0 (Hop limit exceeded in transit) and 1 (Fragment reassembly > time exceeded), and ICMPv6 "Parameter Problem" codes 0 (Erroneous > header field encountered), 1 (Unrecognized Next Header type > encountered) and 2 (Unrecognized IPv6 option encountered). Should have reference to ICMPv6. Section 2, paragraph 5: > TCP's reaction to ICMP messages will depend on the type of error > being signaled. This and the previous two paragraphs each consist of only one sentence each (and in fact, many other paragraphs in the draft). For example, I wonder if the two paragraphs before this one could be combined. Section 4., paragraph 1: > As discussed in Section 1, it may make sense for the fault recovery I would just leave out "As discussed in Section 1", since IMHO this is not so much discussed in the intro. Section 4., paragraph 5: > We note that the TCPM WG could not arrive at consensus on allowing > the above described behavior as part of the standard. Therefore, > treating soft errors as hard errors during connection establishment, > while widespread, is not part of standard TCP behavior and this > document does not change that state of affairs. I would reorganize Sections 4 and 5 to be subsections of one top-level section. The top-level section could be titled similarly than section 4 is now, except using "workarounds" instead of singular form. Section 4.1 could be something like "Simple workaround", and 4.2 would still keep "A More Conservative Approach". I would move the above note to the beginning of the top-level section, to immediately notify the reader that the draft just documents the known implementations, and does not propose these to be part of standard TCP. This also deserves a bit more explanation on why TCPM is not proposing this to be part of standard TCP. Maybe a forward reference to "Possible drawbacks" section would help here. Section 5., paragraph 5: > This approach would give the network more time to solve the > connectivity problem than simply aborting a connection attempt upon > reception of the first soft error. However, it should be noted that > depending on the values chosen for the MAXSYNREXMIT and MAXSOFTERROR > parameters, this approach could still lead to long delays between > connection establishment attempts, thus not solving the problem. For > example, BSD systems abort connections in the SYN-SENT or the SYN- > RECEIVED state when a second ICMP error is received, and the SYN > segment has been retransmitted more than three times. They also set > up a "connection-establishment timer" that imposes an upper limit on > the time the connection establishment attempt has to succeed, which > expires after 75 seconds [Stevens2] (pp. 828-829). Even when this > policy may be better than the three-minutes timeout policy specified > in [RFC1122], it may still be inappropriate for handling the > potential problems described in this document. This more > conservative approach has been implemented in BSD systems since, at > least, 1994 [Stevens2]. "since, at least, 1994." seems a little odd. Maybe just "for more than 10 years"? Section 6., paragraph 1: > The following subsections discuss some of the possible drawbacks > arising from the use of the non-standard modifications to TCP's > reaction to soft errors described in Section 4 and Section 5. The drawbacks section seems quite short compared to the amount of discussion TCPM had earlier on this draft, although I don't have much to add here off the top of my head. If this section appropriately summarizes the arguments against making this change to TCP, then I guess it is ok. One minor point could be added to 6.1 that in many cases you only get one address for a destination, in which case it might have been better to try that address persistently according to normal TCP rules, instead of just aborting the connection establishment. On normative references (section 10.1): This is a dumb question, not a comment... Is Informative RFC supposed to have Normative References? Or should all references be informative? - Pasi --=-Dyk75w1e5O86BMy14ceC Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBGOdRloNa7NH1G2csRAig4AKDQiyFih+YhhzzaQ5FfgH2q+4yHOwCg485t RtnlmuqwIZUUf+wO4mEURLE= =j/tp -----END PGP SIGNATURE----- --=-Dyk75w1e5O86BMy14ceC-- --===============0439845582== 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 --===============0439845582==-- From tcpm-bounces@ietf.org Thu May 03 12:44: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 1HjeQH-00064P-SL; Thu, 03 May 2007 12:44:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjeQG-00062o-8s for tcpm@ietf.org; Thu, 03 May 2007 12:44:52 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjeQE-0002wb-Su for tcpm@ietf.org; Thu, 03 May 2007 12:44:52 -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 l43GiCmO000533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 May 2007 09:44:12 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.14.1/8.14.1/Submit) id l43GiCBC068030; Thu, 3 May 2007 09:44:12 -0700 (PDT) (envelope-from faber) Date: Thu, 3 May 2007 09:44:12 -0700 From: Ted Faber To: Saikat Guha Subject: Re: [tcpm] WGLC: TCP's Reaction to Soft Errors Message-ID: <20070503164412.GG46833@hut.isi.edu> References: <20070425034624.117871E18C7@lawyers.icir.org> <1178109923.25526.63.camel@localhost.localdomain> Mime-Version: 1.0 In-Reply-To: <1178109923.25526.63.camel@localhost.localdomain> 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, 'Fernando Gont' , 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="===============1102746992==" Errors-To: tcpm-bounces@ietf.org --===============1102746992== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0z5c7mBtSy1wdr4F" Content-Disposition: inline --0z5c7mBtSy1wdr4F Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 02, 2007 at 08:45:23AM -0400, Saikat Guha wrote: > On Tue, 2007-04-24 at 23:46 -0400, Mark Allman wrote: > > > Title : TCP's Reaction to Soft Errors > > > Author(s) : F. Gont > > > Filename : draft-ietf-tcpm-tcp-soft-errors-05.txt >=20 > I read the draft, and to the extent that the draft is informational and > does not standardize treating soft-errors as hard I have no objections. >=20 > The behavior described by the draft (that of considering soft errors as > hard during SYN-SENT state after 0/n retransmissions), however, was a > cause of concern for the NAT TCP Behavior document > (draft-ietf-behave-tcp-07.txt), which is currently in the RFC editors > queue. This seems to have generated some discussion, and seems to me (with my chair hat) to be an interaction worth mentioning in the tcpm draft. I think that would be a lot easier to accomodate (i.e., easy to add without another WGLC round) if someone were to suggest a paragraph or 2 to be included in the tcpm draft and we hammered out a quick consensus. Any takers? (And if I'm reading the group's take wrong here, let me know that, too.) --=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 --0z5c7mBtSy1wdr4F Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGOhFcaUz3f+Zf+XsRAoQVAJ9W+m7PTFj/Pf0XwgA5ZM7fskYTmwCgn7QP b8tcl1SIradCbDGkk44OcX8= =GlYr -----END PGP SIGNATURE----- --0z5c7mBtSy1wdr4F-- --===============1102746992== 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 --===============1102746992==-- From tcpm-bounces@ietf.org Fri May 04 17:24: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 1Hk5Gf-0001XV-UD; Fri, 04 May 2007 17:24:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hk5Ge-0001VV-Av for tcpm@ietf.org; Fri, 04 May 2007 17:24:44 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hk5Gc-00036C-VL for tcpm@ietf.org; Fri, 04 May 2007 17:24:44 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 6CC63F0C417; Fri, 4 May 2007 18:24:10 -0300 (ART) Received: from fgont.gont.com.ar (200.123.88.242.static.techtelnet.net [200.123.88.242] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id l44LNSic018463; Fri, 4 May 2007 18:24:03 -0300 Message-Id: <7.0.1.0.0.20070504050029.0357d590@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 04 May 2007 05:12:35 -0300 To: Ted Faber , Saikat Guha From: Fernando Gont Subject: Re: [tcpm] WGLC: TCP's Reaction to Soft Errors In-Reply-To: <20070503164412.GG46833@hut.isi.edu> References: <20070425034624.117871E18C7@lawyers.icir.org> <1178109923.25526.63.camel@localhost.localdomain> <20070503164412.GG46833@hut.isi.edu> 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]); Fri, 04 May 2007 18:24:10 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 At 13:44 03/05/2007, Ted Faber wrote: >This seems to have generated some discussion, and seems to me (with >my chair hat) to be an interaction worth mentioning in the tcpm draft. >I think that would be a lot easier to accomodate (i.e., easy to add >without another WGLC round) if someone were to suggest a paragraph or 2 >to be included in the tcpm draft and we hammered out a quick consensus. > >Any takers? > >(And if I'm reading the group's take wrong here, let me know that, too.) So far Saikat is for documenting this, and Joe for not doing so. If the decision is to document this, then a possible text would be: Some NATs respond to an unsolicited inbound SYN packet with an ICMP soft error message. If the system sending the unsolicited SYN segment implements the workaround described in this document, it will abort the connection upon receipt of the ICMP soft error, thus preventing the connection establishment from succeeding. It should be stressed that those NATs implementing this behaviour are not BEHAVE-compliant, and should implement REQ-4 of [behave-tcp] instead. That's my two cents. Improvements to the text may probably be necessary. 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 Fri May 04 18:34: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 1Hk6MS-00046J-Rs; Fri, 04 May 2007 18:34:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hk6MQ-00046E-Ty for tcpm@ietf.org; Fri, 04 May 2007 18:34:46 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hk6MP-0002Ic-H9 for tcpm@ietf.org; Fri, 04 May 2007 18:34:46 -0400 Received: from [127.0.0.1] (137.sub-75-214-66.myvzw.com [75.214.66.137]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l44MYK1r020017; Fri, 4 May 2007 15:34:23 -0700 (PDT) Message-ID: <463BB4D9.8020801@isi.edu> Date: Fri, 04 May 2007 15:34:01 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] WGLC: TCP's Reaction to Soft Errors References: <20070425034624.117871E18C7@lawyers.icir.org> <1178109923.25526.63.camel@localhost.localdomain> <20070503164412.GG46833@hut.isi.edu> <7.0.1.0.0.20070504050029.0357d590@gont.com.ar> In-Reply-To: <7.0.1.0.0.20070504050029.0357d590@gont.com.ar> X-Enigmail-Version: 0.95.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: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: tcpm@ietf.org, Ted Faber , 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="===============0738701201==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0738701201== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCBCE9111A74F0CE6977ADBCC" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCBCE9111A74F0CE6977ADBCC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > At 13:44 03/05/2007, Ted Faber wrote: >=20 >> This seems to have generated some discussion, and seems to me (with >> my chair hat) to be an interaction worth mentioning in the tcpm draft.= >> I think that would be a lot easier to accomodate (i.e., easy to add >> without another WGLC round) if someone were to suggest a paragraph or = 2 >> to be included in the tcpm draft and we hammered out a quick consensus= =2E >> >> Any takers? >> >> (And if I'm reading the group's take wrong here, let me know that, too= =2E) >=20 > So far Saikat is for documenting this, and Joe for not doing so. Largely because it focuses on behavior that is not BEHAVE compliant; IMO, this sort of thing should be for a BEHAVE-based 'implementation problems' doc. If we want to add this, are we adding all other known ICMP implementation errors? > If the decision is to document this, then a possible text would be: >=20 > Some NATs respond to an unsolicited inbound SYN packet with an ICMP sof= t > error message. If the system sending the unsolicited SYN segment > implements the workaround described in this document, it will abort the= > connection upon receipt of the ICMP soft error, thus preventing the > connection establishment from succeeding. It should be stressed that > those NATs implementing this behaviour are not BEHAVE-compliant, and > should implement REQ-4 of [behave-tcp] instead. >=20 > That's my two cents. Improvements to the text may probably be necessary= =2E >=20 > Kindest regards, >=20 > --=20 > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 >=20 >=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 --------------enigCBCE9111A74F0CE6977ADBCC 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 iD8DBQFGO7TZE5f5cImnZrsRAlCYAKDqLw/c4nalbu9Q06PPDVUje38EmgCg4otm R8Mpg/MtzQy5skwW+D8SEWs= =IzU7 -----END PGP SIGNATURE----- --------------enigCBCE9111A74F0CE6977ADBCC-- --===============0738701201== 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 --===============0738701201==-- From tcpm-bounces@ietf.org Mon May 07 03:41: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 1Hkxqd-0006K4-3X; Mon, 07 May 2007 03:41:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hkxqb-0006Jo-Sc; Mon, 07 May 2007 03:41:29 -0400 Received: from wall.ikr.uni-stuttgart.de ([129.69.170.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hkxqa-0001uN-Fx; Mon, 07 May 2007 03:41:29 -0400 Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by wall.ikr.uni-stuttgart.de (Postfix) with ESMTP id 853FB56CC2; Mon, 7 May 2007 09:41:27 +0200 (CEST) Received: by netsrv1.ikr.uni-stuttgart.de (Postfix, from userid 539) id 78681BC080; Mon, 7 May 2007 09:41:27 +0200 (CEST) Received: from ikr.uni-stuttgart.de (inode21 [10.21.18.11]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with SMTP id 17A0DBC07E; Mon, 7 May 2007 09:41:27 +0200 (CEST) Received: by ikr.uni-stuttgart.de (sSMTP sendmail emulation); Mon, 7 May 2007 09:41:27 +0200 Date: Mon, 7 May 2007 09:41:27 +0200 From: Michael Scharf To: David Borman Subject: Re: [tcpm] Extending RFC 1323 window scaling? Message-ID: <20070507074127.GA8450@ikr.uni-stuttgart.de> References: <20070406211624.DF8781C8DBC@lawyers.icir.org> <31BB1FDE-1577-4069-BF40-5C3732FA1CF4@windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <31BB1FDE-1577-4069-BF40-5C3732FA1CF4@windriver.com> User-Agent: Mutt/1.4.2.2i X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: tcpm@ietf.org, tsvwg@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 On Mon, 30 Apr 2007 at 13:16:57, David Borman wrote: > An alternate way of dealing with this situation where the initial > window exceeds 64K would be to immediately follow the SYN,ACK with a > window update; send the two packets out back-to-back. (Has this > already been mentioned?) That would mean that Quick-start wouldn't > be able to fully act just on the SYN,ACK, but should immediately get > the window update with the right value, without having to wait for a > full RTT. The only down-side would be if the two packets got re- > ordered, and the ACK with the window update arrived before the > SYN,ACK. In that case, the window update would be (and should be) > dropped, because at a minimum, the scale factor that should be > applied to it would be unknown (it's in the SYN,ACK). So, a TCP > implementation might need to still send out another window update > when it got back the ACK completing the 3-way handshake, just to be > sure that the window update got through. Sending an additional ACK back-to-back with the is, of course, the obvious solution, and it has also been noticed that the robustness of this mechanism can be increased by sending more than one ACK. However, it must be emphasized that sending one (or several) additional 40 byte-ACKs is a little bit efficient, in order to transmit an information equivalent to 1 bit (window scaled or not scaled). BTW: At least the Linux 2.6.x TCP stack needs some minor modifications in order to correctly process additional ACKs with receive window updates within or immediately after the 3-way handshake. Thus, if the TCP stack needs to be changed anyway to allow a scaled window, one could also think of implementing some new TCP option. Michael _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon May 07 18:51: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 1HlC2k-00071F-Pc; Mon, 07 May 2007 18:50:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlC2N-0006HC-56; Mon, 07 May 2007 18:50:35 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HlC2M-0007kv-Lj; Mon, 07 May 2007 18:50:34 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id A25A517609; Mon, 7 May 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HlC1q-0001sl-Cl; Mon, 07 May 2007 18: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: Mon, 07 May 2007 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-icmp-attacks-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 : ICMP attacks against TCP Author(s) : F. Gont Filename : draft-ietf-tcpm-icmp-attacks-02.txt Pages : 40 Date : 2007-5-7 This document discusses the use of the Internet Control Message Protocol (ICMP) to perform a variety of attacks against the Transmission Control Protocol (TCP) and other similar protocols. It proposes several counter-measures to eliminate or minimize the impact of these attacks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-icmp-attacks-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-icmp-attacks-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-icmp-attacks-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-5-7160858.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-icmp-attacks-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-icmp-attacks-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-7160858.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 Tue May 08 14:58:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlUsp-0002UG-7w; Tue, 08 May 2007 14:57:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlUsn-0002UA-Oc for tcpm@ietf.org; Tue, 08 May 2007 14:57:57 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlUsm-0000Lz-BX for tcpm@ietf.org; Tue, 08 May 2007 14:57:57 -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 l48IvSEB001104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 May 2007 11:57:28 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.14.1/8.14.1/Submit) id l48IvSJd039604; Tue, 8 May 2007 11:57:28 -0700 (PDT) (envelope-from faber) Date: Tue, 8 May 2007 11:57:28 -0700 From: Ted Faber To: Joe Touch Subject: Re: [tcpm] WGLC: TCP's Reaction to Soft Errors Message-ID: <20070508185728.GE35315@hut.isi.edu> References: <20070425034624.117871E18C7@lawyers.icir.org> <1178109923.25526.63.camel@localhost.localdomain> <20070503164412.GG46833@hut.isi.edu> <7.0.1.0.0.20070504050029.0357d590@gont.com.ar> <463BB4D9.8020801@isi.edu> Mime-Version: 1.0 In-Reply-To: <463BB4D9.8020801@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: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: tcpm@ietf.org, Fernando Gont , 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="===============1695142242==" Errors-To: tcpm-bounces@ietf.org --===============1695142242== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UnaWdueM1EBWVRzC" Content-Disposition: inline --UnaWdueM1EBWVRzC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 04, 2007 at 03:34:01PM -0700, Joe Touch wrote: >=20 >=20 > Fernando Gont wrote: > > At 13:44 03/05/2007, Ted Faber wrote: > >=20 > >> This seems to have generated some discussion, and seems to me (with > >> my chair hat) to be an interaction worth mentioning in the tcpm draft. > >> I think that would be a lot easier to accomodate (i.e., easy to add > >> without another WGLC round) if someone were to suggest a paragraph or 2 > >> to be included in the tcpm draft and we hammered out a quick consensus. > >> > >> Any takers? > >> > >> (And if I'm reading the group's take wrong here, let me know that, too= .) > >=20 > > So far Saikat is for documenting this, and Joe for not doing so. >=20 > Largely because it focuses on behavior that is not BEHAVE compliant; > IMO, this sort of thing should be for a BEHAVE-based 'implementation > problems' doc. If we want to add this, are we adding all other known > ICMP implementation errors? It seems to me (hat's off) that a pitfall that this soft-errors response causes when combined with an IETF BCP is a more constrained and important case than an interaction between this response and a buggy system. I agree it needs to be flagged in the NAT literature as a pitfall for BEHAVE NAT implementers. I think it should also be flagged here for TCP implementers who want to understand the ramifications of this design choice (soft error =3D=3D hard error during connection setup). It's worth calling out against all the other potential design choices because it conflicts with a BCP - implementation advice - rather than just against observed behavior. In the same way the soft-errs doc points out that a TCP that treats soft errors as hard is out of step with ICMP and TCP standards, I think it should point out that the decision violates the assumptions of the BEHAVE BCP. Anyone else care? If it's just Saikat and me who think this warning needs to be added, I'm not opposed to having the draft go to RFC as-is. --=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 --UnaWdueM1EBWVRzC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGQMgYaUz3f+Zf+XsRAiSaAJ9tKhaHaaXLYciQMV1lUq+96HzLkQCeMy3/ pElGT1HccB3b7X+BuCUYCac= =u6z1 -----END PGP SIGNATURE----- --UnaWdueM1EBWVRzC-- --===============1695142242== 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 --===============1695142242==-- From tcpm-bounces@ietf.org Tue May 08 17:12: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 1HlWz7-0000bz-Bn; Tue, 08 May 2007 17:12:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlWz6-0000bt-Lp for tcpm@ietf.org; Tue, 08 May 2007 17:12:36 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlWz4-0000hJ-80 for tcpm@ietf.org; Tue, 08 May 2007 17:12:36 -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 l48LC4Sf006580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 May 2007 14:12:05 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.14.1/8.14.1/Submit) id l48LC493042152; Tue, 8 May 2007 14:12:04 -0700 (PDT) (envelope-from faber) Date: Tue, 8 May 2007 14:12:04 -0700 From: Ted Faber To: Mark Allman Subject: Re: [tcpm] WGLC: TCP's Reaction to Soft Errors Message-ID: <20070508211204.GJ35315@hut.isi.edu> References: <20070409151328.GB1285@hut.isi.edu> <20070425034624.117871E18C7@lawyers.icir.org> Mime-Version: 1.0 In-Reply-To: <20070425034624.117871E18C7@lawyers.icir.org> 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: f607d15ccc2bc4eaf3ade8ffa8af02a0 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="===============1176623060==" Errors-To: tcpm-bounces@ietf.org --===============1176623060== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/0U0QBNx7JIUZLHm" Content-Disposition: inline --/0U0QBNx7JIUZLHm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 24, 2007 at 11:46:24PM -0400, Mark Allman wrote: >=20 > > Mark and I would like to start a WG last call on the informational > > document on TCP's reaction to soft ICMP errors on connection set-up: > >=20 > > Title : TCP's Reaction to Soft Errors > > Author(s) : F. Gont > > Filename : draft-ietf-tcpm-tcp-soft-errors-05.txt > > Pages : 13 > > Date : 2007-4-4 > >=20 > > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-soft-errors-05.= txt > >=20 > > Our understanding is that all feedback to date is reflected in this > > version and that there are no known outstanding issues. Please send > > feedback (even if just of the form "yep, looks good"). > >=20 > > This WGLC will end on Monday 23 Apr 2007. >=20 > Folks- >=20 > We received nearly no feedback on this WGLC. Since this draft has been > contentious in the past we need some review before passing it along to > the IESG. We are therefore extending the WGLC until May 15. Please > take a few minutes and look over the draft and send comments. As Ted > notes above, even if you think the draft looks fine a one-sentence note > that says this would be very much appreciated. May 15 is a week away. If you have comments, please send 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 --/0U0QBNx7JIUZLHm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGQOekaUz3f+Zf+XsRAqDKAKDnozloBhErGh5i9Voc3C02tYWy6gCbBlaS Bqh3l+CAY1n5KaJKFlxHL7Y= =xevV -----END PGP SIGNATURE----- --/0U0QBNx7JIUZLHm-- --===============1176623060== 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 --===============1176623060==-- From tcpm-bounces@ietf.org Wed May 09 17:39: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 1Hltsm-0002RE-GM; Wed, 09 May 2007 17:39:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hltsl-0002R9-GZ for tcpm@ietf.org; Wed, 09 May 2007 17:39:35 -0400 Received: from exchfenlb-2.cs.cornell.edu ([128.84.97.34] helo=exchfe2.cs.cornell.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hltsi-0006eo-72 for tcpm@ietf.org; Wed, 09 May 2007 17:39:35 -0400 Received: from exchfe1.cs.cornell.edu ([128.84.97.33]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 17:39:27 -0400 Received: from [128.84.227.36] ([128.84.227.36]) by exchfe1.cs.cornell.edu over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 17:39:22 -0400 Subject: Re: [tcpm] WGLC: TCP's Reaction to Soft Errors From: Saikat Guha To: Ted Faber In-Reply-To: <20070508185728.GE35315@hut.isi.edu> References: <20070425034624.117871E18C7@lawyers.icir.org> <1178109923.25526.63.camel@localhost.localdomain> <20070503164412.GG46833@hut.isi.edu> <7.0.1.0.0.20070504050029.0357d590@gont.com.ar> <463BB4D9.8020801@isi.edu> <20070508185728.GE35315@hut.isi.edu> Date: Wed, 09 May 2007 17:39:21 -0400 Message-Id: <1178746761.30947.14.camel@sioux.systems.cs.cornell.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 (2.10.1-4.fc7) X-OriginalArrivalTime: 09 May 2007 21:39:22.0182 (UTC) FILETIME=[81A4E660:01C79282] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: tcpm@ietf.org, mallman@icir.org, Fernando Gont , 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="===============1737364559==" Errors-To: tcpm-bounces@ietf.org --===============1737364559== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-9D8o8yJjGGDi64Pfvury" --=-9D8o8yJjGGDi64Pfvury Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2007-05-08 at 11:57 -0700, Ted Faber wrote: > Anyone else care? If it's just Saikat and me who think this warning > needs to be added, I'm not opposed to having the draft go to RFC > as-is. Ditto. --=20 Saikat --=-9D8o8yJjGGDi64Pfvury Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBGQj+JnFltqi691/oRAsL3AJ9EeBkWD9wVMi7QeLx4JAXLI/zx+gCdEbt0 89XiV3H+sz/RNv4xgFnthsI= =WbgG -----END PGP SIGNATURE----- --=-9D8o8yJjGGDi64Pfvury-- --===============1737364559== 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 --===============1737364559==-- From tcpm-bounces@ietf.org Thu May 10 14:47: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 1HmDfm-00071L-Gy; Thu, 10 May 2007 14:47:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmDfk-0006zM-JS; Thu, 10 May 2007 14:47:28 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmDfj-0005UC-6U; Thu, 10 May 2007 14:47:28 -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 l4AIlP6w001831; Thu, 10 May 2007 11:47:25 -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 B64F9AAED17; Thu, 10 May 2007 14:47:20 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id CCBF71FA431; Thu, 10 May 2007 14:47:05 -0400 (EDT) To: David Borman From: Mark Allman Subject: Re: [tcpm] Extending RFC 1323 window scaling? In-Reply-To: <31BB1FDE-1577-4069-BF40-5C3732FA1CF4@windriver.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Ticket to Ride MIME-Version: 1.0 Date: Thu, 10 May 2007 14:47:05 -0400 Message-Id: <20070510184705.CCBF71FA431@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: tcpm@ietf.org, tsvwg@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="===============1141689218==" Errors-To: tcpm-bounces@ietf.org --===============1141689218== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > (Catching up on some old email...) likewise > > If I were going to take approach (2) I would suggest a two-byte option > > that indicates the value in the standard TCP header is to be scaled. > > Why add another 2 byte window value when one of them is going to be > > ignored? This fails safe because if a host doesn't understand the new > > ("the window is scaled") option it will think the advertised window is > > unscaled and so less than it really is and so there is no danger in > > running into problems. > > I'm not sure I agree. Yes, it's safe in that if you treat a scaled > window as unscaled, you will not send more data than they are > willing to receive. But if the shift value is large enough, and > the initial window small enough, you can get a tiny initial window. > E.g., an extreme case, if your initial window is 256K, but you have > a shift value of 14, that'll become a window of 16 bytes, not > enough to send much of anything until you get a window update. Ah - good point. So, perhaps the rule would then be if you were going to send such a "scale this window, please" option then you could make your window size suitable for both cases. I.e., the actual value in the window size would be at least 4380 bytes (current allowed upper bound on the initial cwnd). But, perhaps that is getting too complicated to save two bytes. And, like my original note said, I am not sure I eve think such an option is needed. > An alternate way of dealing with this situation where the initial > window exceeds 64K would be to immediately follow the SYN,ACK with a > window update; send the two packets out back-to-back. (Has this > already been mentioned?) Yep - that has been mentioned. I think that is a fine way to do this. I also think that we could make the rule that if QS and WS options are present then that means the SYN+ACK has a scaled window. (I.e., this is only a problem for things like QS that need a bigger advertised window *right away* and to support QS is going to take changes on the receiver anyway so let's just make it part of such proposals.) allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGQ2ipWyrrWs4yIs4RAiXcAJ0fqmvHSs/+bLGxspGtlK42vovauQCeKneC gS3B2EWZPDu8wUP3OLJsNIo= =xSwQ -----END PGP SIGNATURE----- --=_bOundary-- --===============1141689218== 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 --===============1141689218==-- From tcpm-bounces@ietf.org Mon May 14 07:50: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 1HnZ44-0003LV-Jm; Mon, 14 May 2007 07:50:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnZ43-0003LG-7W for tcpm@ietf.org; Mon, 14 May 2007 07:50:07 -0400 Received: from smtpout.mac.com ([17.250.248.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnZ40-0001tX-OO for tcpm@ietf.org; Mon, 14 May 2007 07:50:07 -0400 Received: from mac.com (smtpin04-en2 [10.13.10.149]) by smtpout.mac.com (Xserve/smtpout16/MantshX 4.0) with ESMTP id l4EBnlAp023293; Mon, 14 May 2007 04:49:47 -0700 (PDT) Received: from [193.250.151.121] (mix-orleans-110-3-121.w193-250.abo.wanadoo.fr [193.250.151.121]) (authenticated bits=0) by mac.com (Xserve/smtpin04/MantshX 4.0) with ESMTP id l4EBnbxk001930; Mon, 14 May 2007 04:49:39 -0700 (PDT) In-Reply-To: <462FA142.5080904@bbn.com> References: <07e0ad60d97a8cef94c214554aee0658@mac.com> <462FA142.5080904@bbn.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <200b83ded2594da2a723ecb6e09dd538@mac.com> Content-Transfer-Encoding: 7bit From: Sally Floyd Subject: Re: [tcpm] Adding Acknowledgement Congestion Control to TCP Date: Mon, 14 May 2007 04:49:39 -0700 To: "Armando L. Caro, Jr." X-Mailer: Apple Mail (2.624) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: tcpm , David Ros , =?ISO-8859-1?Q?Andr=E9s_Arcia?= , Janardhan Iyengar 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 Armando - > I like the idea of attempting to separate forward and reverse path > congestion. I've been thinking about this problem off and on for some > time now, but haven't worked out a detailed solution. In essence, I'd > like for ack losses to not affect throughput on the forward path. > However, I think the motivation of this draft is slightly different. It > seems to be purely motivated by doing proper congestion control in both > directions, right? (My apologies for the delayed response to this.) Yep, the draft is largely motivated by the desire to do proper congestion control in both directions. To the extent that proper congestion control can *reduce* packet drop rates for ack packets as well as for other traffic sharing the path, this should also help TCP performance over paths that have congestion on the return path. And one of the goals is to try to implement Ack Congestion Control (AckCC) in a way that has a minimal negative impact on the performance of that TCP connection even for the case where the AckCC doesn't make any change in the packet drop rates for the ack packets. > Have their been any studies that show that pure acks are a source of > congestion (that we should worry about)? I would expect them to be > noise > in the bigger scheme of things. Personally, I have never thought of > them > contributing to congestion too much, but have instead been more > concerned with them being affected by the congestion around them. I don't know of any studies off-hand, and I certainly don't think of congestion caused by pure ack packets as one of the pressing problems of the current Internet. But there are plenty of TCP connections where ack packets are dropped, and plenty of different kinds of congestion. E.g., on a congested link where the limitation is the bandwidth in bits per second, there could be a congested queue (either a Drop-Tail queue in units of packets, or Active Queue Management in packet mode) where small ack packets take as much space in the queue as large data packets, and where a third of the packets in the queue are small ack packets (as would be the case on a link carrying balanced bi-directional data traffic). And in this case, using AckCC *could* reduce packet drop rates in the congested queue even though it doesn't substantially reduce the load in terms of bytes per second. Or there could be paths where the limitation is in router CPU cycles in packets per second rather than in bandwidth in bits per second. In this case, AckCC could reduce the load on the congested router. > Asymmetric links (eg, DSL and cable) often see this problem: traffic on > an uncongested downlink gets a performance hit when the uplink becomes > congested. I'm concerned that reducing the number of acks when ack > losses occur is likely to make the problem worse. I would add this > issue > to the list of "possible complications". I agree that it would be good to add, as a "possible complication", the case where the packet drop rate for the ack traffic is relatively fixed (e.g., caused by competing UDP traffic), and the use of AckCC might make the performance of the TCP connection even worse that it would be without AckCC. Hopefully even in this case, the use of AckCC won't have a significant negative impact of the performance of the TCP connection. > I realize that this is a preliminary investigation, but has anyone > experimented with this proposal. I'd be interested in seeing the > results. > > Some other comments: > > Re: Section 5.7. Appropriate byte counting allows the cwnd to be > increased by the number of bytes being acked, but there is a cap. Each > ack may increase the cwnd by at most 2*MSS. Thus, an ACK Ratio > 2 will > slow down cwnd growth during slow start. So the text should point to > ABC > as guidance, but state that you are now proposing to break that cap and > use rate limiting to mitigate the bursts. Thanks, we will add this. > I like the list of possible complications. Except for the one I pointed > out above, I think you hit all the issues I thought of as I read the > draft. Many thanks for the feedback! - Sally http://www.icir.org/floyd/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon May 14 10:47: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 1Hnbq4-0007Fi-Gl; Mon, 14 May 2007 10:47:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnbq2-00079L-7C for tcpm@ietf.org; Mon, 14 May 2007 10:47:50 -0400 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnbq0-0004Fa-Ns for tcpm@ietf.org; Mon, 14 May 2007 10:47:50 -0400 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 2FE042000190 for ; Mon, 14 May 2007 17:06:56 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fP8382ypRns1 for ; Mon, 14 May 2007 17:06:56 +0200 (CEST) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 1E8592000189 for ; Mon, 14 May 2007 17:06:51 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 May 2007 16:47:42 +0200 Message-ID: <113091BD57179D4491C19DA7E10CD696EFD584@mx1.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Please comment: TCP Response to Lower-Layer Connectivity-Change Indications thread-index: AceWNtPGwQo2yN9iTIyRRT9xKnyFvw== From: "Simon Schuetz" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [tcpm] Please comment: TCP Response to Lower-Layer Connectivity-Change Indications 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, Before the last IETF we submitted an update to the draft below and = presented it at the TCPM meeting in Prag. We'd be happy to receive your comments for preparing the next update. Thanks, Simon A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. Title : TCP Response to Lower-Layer Connectivity-Change Indications Author(s) : S. Schuetz, et al. Filename : draft-schuetz-tcpm-tcp-rlci-01.txt Pages : 26 Date : 2007-3-7 =09 When the path characteristics between two hosts change abruptly, TCP can experience significant delays before resuming transmission in an efficient manner or TCP can behave unfairly to competing traffic. This document describes TCP extensions that improve transmission behavior in response to advisory, lower-layer connectivity-change indications. The proposed TCP extensions modify the local behavior of TCP and introduce a new TCP option to signal locally received connectivity-change indications to remote peers. Performance gains result from a more efficient transmission behavior and there is no difference in aggressiveness in comparison to a freshly-started connection. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-schuetz-tcpm-tcp-rlci-01.txt =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Simon Sch=FCtz NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221 4342-165 Fax: +49 6221 4342-155 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon May 14 15:51:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HngZR-0008Ff-1s; Mon, 14 May 2007 15:51:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HngYW-0006Xs-QO; Mon, 14 May 2007 15:50:04 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HngYW-00053S-8E; Mon, 14 May 2007 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 2FEC92AB69; Mon, 14 May 2007 19:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HngYU-0006TV-Fg; Mon, 14 May 2007 15: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: Mon, 14 May 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-syn-flood-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 SYN Flooding Attacks and Common Mitigations Author(s) : W. Eddy Filename : draft-ietf-tcpm-syn-flood-04.txt Pages : 23 Date : 2007-5-14 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-syn-flood-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-syn-flood-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-syn-flood-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-5-14134625.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-syn-flood-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-syn-flood-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-14134625.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 Tue May 15 23:11: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 1Ho9vQ-0004F8-Ba; Tue, 15 May 2007 23:11:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho9vO-0004F3-Ob for tcpm@ietf.org; Tue, 15 May 2007 23:11:38 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ho9vM-0001fP-BM for tcpm@ietf.org; Tue, 15 May 2007 23:11: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 l4G3BZBa006534 for ; Tue, 15 May 2007 20:11: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 73EA9ADA5D7 for ; Tue, 15 May 2007 23:11:30 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id A48851FF233 for ; Tue, 15 May 2007 23:11:09 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Authority Song MIME-Version: 1.0 Date: Tue, 15 May 2007 23:11:09 -0400 Message-Id: <20070516031109.A48851FF233@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [tcpm] early retransmit redux 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="===============1089245089==" Errors-To: tcpm-bounces@ietf.org --===============1089245089== 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- A long time ago a bunch of us wrote a draft on 'early retransmit', which is essentially allowing TCPs to trigger fast retransmit on one or two dupacks when the cwnd is small enough such that three dupacks could never be generated for a loss. We pushed this in TSVWG before TCPM was formed. We stopped pushing this I-D because some of our analysis of network traces seemed to indicate that ER was sort of a crapshoot, failing as much as succeeding. However, given that we never went beyond sort of a preliminary assessment and did not publish the results (/ let them stand against peer review) we no longer think we should stop the ER draft because of these results. Further, the results were from one particular network and it would seem useful to gain a broad understanding of how ER works in a variety of environments. My recollection is that once upon a time the TSVWG had some consensus to take on ER as a work item with the intention of publishing it as an experimental RFC. We have advertised a revision of the document and gotten no reaction within TSVWG. I wonder if this WG might have any thoughts on whether this should be worked up into an RFC or not. The draft is: http://www.icir.org/mallman/papers/draft-allman-tcp-early-rexmt-04.txt Comments, questions, etc. welcome. Thanks in advance! allman (Oh- all this with my co-chair hat off, of course.) --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGSnZNWyrrWs4yIs4RAtSSAJ9zfrRLsWRxb5762STNGQKUOG/ZdgCdEgYg aXD7hE/TDEzx8WrZ4b/uvj0= =IpYJ -----END PGP SIGNATURE----- --=_bOundary-- --===============1089245089== 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 --===============1089245089==-- From tcpm-bounces@ietf.org Fri May 18 10:00:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp306-0007FH-0P; Fri, 18 May 2007 10:00:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp304-0007Ey-PQ for tcpm@ietf.org; Fri, 18 May 2007 10:00:08 -0400 Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp304-0001ge-9R for tcpm@ietf.org; Fri, 18 May 2007 10:00:08 -0400 Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 15:00:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C79954.D70FD775" Date: Fri, 18 May 2007 15:00:10 +0100 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: TCP Secure Thread-Index: AceZVNkemAiLQ7iLRQKC0/WDRCqdNg== From: To: X-OriginalArrivalTime: 18 May 2007 14:00:07.0614 (UTC) FILETIME=[D78F3DE0:01C79954] X-Spam-Score: 0.3 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Subject: [tcpm] TCP Secure 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. ------_=_NextPart_001_01C79954.D70FD775 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C79954.D70FD775" ------_=_NextPart_002_01C79954.D70FD775 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I was just wanting a couple of bits of clarification about TCP Secure: Top of page 10: It isn't clear what happens to other segments after you drop the RST? Are they just processed as normal? This is what is implied but it would be useful if it were made explicitly clear. What happens if there is any re-ordering before a valid RST or SYN is sent? Can you clarify how your mitigations react to this. From my understanding, the reason for originally accepting any RST or SYN in the valid receive window was to allow for data reordering (as explicitly stated in RFC793) Finally: spotted three typos: Page 5 para 3) "...before succeeding in his mischieve." --> "... before succeeding in his mischief." Page 11 3rd para up from bottom "...would not have a TCB..." --> "...would not have a TCP..." Page 19, para 2. Initial "i" not capitalized Toby ________________________________________________________________________ ____ Toby Moncaster, Networks Research Centre, BT Research B54/70 Adastral Park, Martlesham Heath, Ipswich, IP53RE, UK. +44 1473 648734=20 ------_=_NextPart_002_01C79954.D70FD775 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable TCP Secure

Hi,

I was just wanting a couple of bits of = clarification about TCP Secure:

Top of page 10: It isn't clear what = happens to other segments after you drop the RST? Are they just = processed as normal? This is what is implied but it would be useful if = it were made explicitly clear.

What happens if there is any = re-ordering before a valid RST or SYN is sent? Can you clarify how your = mitigations react to this. From my understanding, the reason for = originally accepting any RST or SYN in the valid receive window was to = allow for data reordering (as explicitly stated in RFC793)

Finally: spotted three typos:

Page 5 para 3) "…before = succeeding in his mischieve." --> "… before = succeeding in his mischief."
Page 11 3rd para up from bottom = "…would not have a TCB…" --> "…would = not have a TCP…"
Page 19, para 2. Initial "i" = not capitalized

Toby

____________________________________________________________________= ________
Toby Moncaster, = <toby.moncaster@bt.com> Networks Research Centre, BT = Research
B54/70 Adastral Park, Martlesham = Heath, Ipswich, IP53RE, UK.  +44 1473 648734=20

------_=_NextPart_002_01C79954.D70FD775-- ------_=_NextPart_001_01C79954.D70FD775 Content-Type: text/x-vcard; name="Moncaster,T,Toby,CXR9 R.vcf" Content-Transfer-Encoding: base64 Content-Description: Moncaster,T,Toby,CXR9 R.vcf Content-Disposition: attachment; filename="Moncaster,T,Toby,CXR9 R.vcf" QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOk1vbmNhc3RlcjtUb2J5DQpGTjpNb25jYXN0ZXIs VCxUb2J5LENYUjkgUg0KT1JHOkJUIC0gUmVndWxhcjtDWFI5DQpUSVRMRTpCVCBSZSBGZWVkYmFj ayBQbGFjZW1lbnQNCk5PVEU6Q049VlM0U0cyREIyLENOPUUwM01WWjQtVUtEWS10Mm1zLTk5NS0t LQ0KVEVMO1dPUks7Vk9JQ0U6KzQ0IDE0NzM2NDg3MzQNCkFEUjtXT1JLO0VOQ09ESU5HPVFVT1RF RC1QUklOVEFCTEU6O0FOUy1NSDtwcCBCNTQvNzA9MEQ9MEFCVCBMYWJvcmF0b3JpZXM9MEQ9MEEz IEFuc29uIFJvYWQ9MEQ9MEFNYXJ0bGVzaGFtIEhlYT0NCnRoPTBEPTBBSXBzd2ljaCBJUDUgM1JF PTBEPTBBU3VmZm9saztBTlMtTUg7O0lQNSAzUkU7R0INCkxBQkVMO1dPUks7RU5DT0RJTkc9UVVP VEVELVBSSU5UQUJMRTpBTlMtTUg9MEQ9MEFwcCBCNTQvNzA9MEQ9MEFCVCBMYWJvcmF0b3JpZXM9 MEQ9MEEzIEFuc29uIFJvYWQ9MEQ9MEFNYXJ0bGVzaGFtPQ0KIEhlYXRoPTBEPTBBSXBzd2ljaCBJ UDUgM1JFPTBEPTBBU3VmZm9saz0wRD0wQUFOUy1NSCBJUDUgM1JFPTBEPTBBR0INCkVNQUlMO1BS RUY7SU5URVJORVQ6dG9ieS5tb25jYXN0ZXJAYnQuY29tDQpSRVY6MjAwNjEyMDVUMTM1NTE3Wg0K RU5EOlZDQVJEDQo= ------_=_NextPart_001_01C79954.D70FD775 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_001_01C79954.D70FD775-- From tcpm-bounces@ietf.org Wed May 23 06:16:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqnsk-0001CV-Tu; Wed, 23 May 2007 06:15:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqnsj-00019g-MH; Wed, 23 May 2007 06:15:49 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hqnsg-0006zZ-Ri; Wed, 23 May 2007 06:15:49 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 2F6481986A5; Wed, 23 May 2007 13:15:46 +0300 (EEST) Received: from www.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C292D1986A2; Wed, 23 May 2007 13:15:45 +0300 (EEST) Received: from 194.237.142.7 (SquirrelMail authenticated user chvogt) by www.piuha.net with HTTP; Wed, 23 May 2007 13:15:45 +0300 (EEST) Message-ID: <6575.194.237.142.7.1179915345.squirrel@www.piuha.net> Date: Wed, 23 May 2007 13:15:45 +0300 (EEST) From: "Christian Vogt" To: weddy@grc.nasa.gov User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: ClamAV using ClamSMTP Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: tcpm@ietf.org, gen-art@ietf.org, faber@isi.edu, mallman@icir.org Subject: [tcpm] Review of draft-ietf-tcpm-syn-flood-04 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 Wesley, I read your draft on "TCP SYN Flooding Attacks and Common Mitigations" as part of my work as a Gen-ART reviewer. Below some feedback. (For background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-tcpm-syn-flood-04.txt Reviewer: Christian Vogt Review Date: May 23, 2007 IESG Telechat date: -- Summary: The draft is certainly ready for publication. I found it very well-structured and easy to read. The introduction gives the unexperienced reader an excellent overview on the topic. I also think that the draft is a valuable contribution, finally providing a concise an= d well-citeable summary on SYN flooding prevention mechanisms. Comments: (1) Section 3.3 (Reducing SYN-RECEIVED Timer): Maybe you could state here /why/ this technique might prevent legitimate connections from becoming established. The reason obviously is that the RTT to a legitimate peer might be longer than a shortened connection establishment timeout, but this should be written down explicitly. Also, it might be good to add that RTTs can be quite long in some wireless access technologies, e.g., due to long buffering delays. (2) Section 3.4 (Recycling the Oldest Half-Open TCB): Again, this technique could again prevent legitimate connection establishments especially when the RTT is long. (3) Section 3.6 (SYN Cookies), 3rd paragraph: Referring to the example that SYN cookies might not interoperate with MSS encodings in initial sequence numbers: I am not an expert in this area, but I could imagine that the problem is due to the TCP responder not being able to store the = 2 MSS bits in the sequence number from the SYN, nor being able to reconstruct these bits in the sequence number from the ACK following the SYN-ACK. Reconstruction of the MSS bits from the ACK are not feasible because the SYN might have options, which, at the time the ACK is received, have been forgotten by the TCP responder. If this is what causes the problem, then it might be good to spend one or two more sentences explaining it. Editorial nits: (1) Section 1, 1st paragraph: s/denial of service method/denial-of-service method/ (2) Section 3.6, 2nd paragraph: s/implementation dependent/implementation-dependent/ (3) Section 3.6, 6th paragraph: s/never is/is never/ That's it. Excellent work, go ahead and publish! - Christian _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed May 23 13:46: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 1Hquuu-00063i-Sw; Wed, 23 May 2007 13:46:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hquut-00063d-Jb for tcpm@ietf.org; Wed, 23 May 2007 13:46:31 -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 1Hquut-0000z7-1J for tcpm@ietf.org; Wed, 23 May 2007 13:46:31 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 23 May 2007 10:46:30 -0700 X-IronPort-AV: i="4.14,570,1170662400"; d="scan'208,217"; a="487979213:sNHT295208744" 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 l4NHkUYq006264; Wed, 23 May 2007 10:46:30 -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 l4NHkB2Y020512; Wed, 23 May 2007 17:46:30 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); Wed, 23 May 2007 10:46:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] TCP Secure Date: Wed, 23 May 2007 10:46:26 -0700 Message-ID: <13D1EAB852BE194C94773A947138483D0380DD7E@xmb-sjc-21c.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] TCP Secure Thread-Index: AceZVNkemAiLQ7iLRQKC0/WDRCqdNgEDQeRw From: "Mitesh Dalal \(mdalal\)" To: , X-OriginalArrivalTime: 23 May 2007 17:46:26.0662 (UTC) FILETIME=[495E4860:01C79D62] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5998; t=1179942390; x=1180806390; c=relaxed/simple; s=sjdkim4002; 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]=20TCP=20Secure |Sender:=20; bh=+pJfYyZCKtzkaGRBU7ecQq1hZr0uJIQ0bZALGiNXWLk=; b=aUtKZsjwgdB4Lbwn1vAmZqPVW973qRNsH1KpMiy2FSH2i/Nt4Kunm23KESf3QsMHW2lV522f vVH+r08zHenQdxzYNEwkstXI8TtRb/LwU2ql+obF0kNMxrpNUyzk5vCY; Authentication-Results: sj-dkim-4; header.From=mdalal@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 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: , Content-Type: multipart/mixed; boundary="===============0716728146==" Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. --===============0716728146== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C79D62.493B4F78" This is a multi-part message in MIME format. ------_=_NextPart_001_01C79D62.493B4F78 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Toby, =20 Please see inline. ________________________________ From: toby.moncaster@bt.com [mailto:toby.moncaster@bt.com]=20 Sent: Friday, May 18, 2007 7:00 AM To: tcpm@ietf.org Subject: [tcpm] TCP Secure =09 =09 Hi,=20 I was just wanting a couple of bits of clarification about TCP Secure:=20 Top of page 10: It isn't clear what happens to other segments after you drop the RST? Are they just processed as normal? This is what is implied but it would be useful if it were made explicitly clear.=20 Mitesh: yes, they are processed as normal as if the RST didnt arrive.=20 What happens if there is any re-ordering before a valid RST or SYN is sent? Can you clarify how your mitigations react to this. From my understanding, the reason for originally accepting any RST or SYN in the valid receive window was to allow for data reordering (as explicitly stated in RFC793)=20 Mitesh: you mean the other side send bunch of data followed by a RST, however we received the RST followed by the data ? In that case, we send an ACK for the RST and process the following data and hopefully when we get the RST for the ACK that we had send, we will flush the connection. =20 Finally: spotted three typos:=20 Page 5 para 3) "...before succeeding in his mischieve." --> "... before succeeding in his mischief."=20 Page 11 3rd para up from bottom "...would not have a TCB..." --> "...would not have a TCP..."=20 Page 19, para 2. Initial "i" not capitalized =20 Thanks. We will get them in. Mitesh=20 ------_=_NextPart_001_01C79D62.493B4F78 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable TCP Secure
Hi Toby,
 
Please see inline.

From: toby.moncaster@bt.com=20 [mailto:toby.moncaster@bt.com]
Sent: Friday, May 18, 2007 = 7:00=20 AM
To: tcpm@ietf.org
Subject: [tcpm] TCP=20 Secure


Hi,

I was just wanting a couple of bits of=20 clarification about TCP Secure:

Top of page 10: It isn't clear = what happens=20 to other segments after you drop the RST? Are they just processed as = normal?=20 This is what is implied but it would be useful if it were made = explicitly=20 clear. 

Mitesh: yes, they are processed as normal as if the = RST didnt=20 arrive. 

What happens if there is any = re-ordering=20 before a valid RST or SYN is sent? Can you clarify how your = mitigations react=20 to this. From my understanding, the reason for originally accepting = any RST or=20 SYN in the valid receive window was to allow for data reordering (as=20 explicitly stated in RFC793) 

Mitesh: you mean the other side send bunch of data = followed by a=20 RST, however we received the RST followed by the data=20 ?

In that case, we send an ACK for the RST and process=20 the following data and hopefully when we get the RST for the = ACK=20 that

we had send, we will flush the connection.=20  

Finally: spotted three typos: =

Page 5 para 3) "…before = succeeding in his=20 mischieve." --> "… before succeeding in his mischief." =
Page 11 3rd para up from bottom "…would = not have a TCB…"=20 --> "…would not have a TCP…"
Page 19,=20 para 2. Initial "i" not capitalized  

Thanks. We will get them in.

Mitesh 

------_=_NextPart_001_01C79D62.493B4F78-- --===============0716728146== 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 --===============0716728146==-- From tcpm-bounces@ietf.org Fri May 25 14:09: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 1HreEV-0001tz-2K; Fri, 25 May 2007 14:09:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HreEU-0001tu-8L for tcpm@ietf.org; Fri, 25 May 2007 14:09:46 -0400 Received: from mail.windriver.com ([147.11.1.11] helo=mail.wrs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HreET-0005x4-J0 for tcpm@ietf.org; Fri, 25 May 2007 14:09:46 -0400 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id l4PI9i0U025640 for ; Fri, 25 May 2007 11:09:44 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 May 2007 11:09:44 -0700 Received: from [192.168.117.80] ([192.168.117.80]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 May 2007 11:09:44 -0700 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <018977E8-C9F4-42E2-A877-95330F65E7D3@windriver.com> References: <018977E8-C9F4-42E2-A877-95330F65E7D3@windriver.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David Borman Date: Fri, 25 May 2007 13:09:48 -0500 To: TCP Maintenance and Minor Extensions WG X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 25 May 2007 18:09:44.0286 (UTC) FILETIME=[DF3E47E0:01C79EF7] X-Spam-Score: 0.1 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Subject: [tcpm] Re: RFC 1323: Timestamps option 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've been having some off-line discussion about how to turn on Timestamps mid-stream, and I'm coming to a clearer picture. I'm now now leaning towards changing to allow this to happen in a standard way. I think I can now more clearly enumerate the specific issues about enumerating them mid-stream. First, do you or do you not include Timestamps in the SYN exchange, and how much do you care about interoperability with existing 1323 implementations? If you do not include Timestamps negotiation, then I would expect that mid-stream enabling of Timestamps would only work on modified hosts that understand the new rules. I've come up with a variation on Option #2 Option 2a: ---------- The Timestamps option is sent only in the SYN and SYN,ACK packet. If both sides understand deferred enabling of Timestamps, then the connection will continue without Timestamps until one of them initiates Timestamps by including it in a packet. Once Timestamps have been sent or received after the initial SYN,ACK, they are then sent in all packets for the duration of the connection. This has the advantage of knowing up front that the other side understands the Timestamps option, so when you later decide to enable them, you just turn them on and start sending them, you don't have to try to figure out midstream whether or not the other side understands Timestamps. When talking to an RFC-1323 implementation, since the other side will include Timestamps in all packets, the option will be enabled right away. However, my assumption is that if you have a deferred Timestamps implementation talking to an RFC-1323 implementation, that the desired behavior is that Timestamps will be enabled for the entire connection. If the preference is that talking to an RFC-1323 implementation will leave Timestamps disabled for the entire connection, then Timestamps shouldn't be negotiated in the SYN and SYN,ACK. But if you don't negotiate Timestamps in the SYN exchange, then when you try to enable them mid-stream you have to include a mechanism to determine that the other side doesn't support them, so that you can stop sending Timestamps to hosts that don't support them. The other issue is how to actually start using Timestamps mid- stream. The information in Timestamps are used for two purposes: calculating RTT and for PAWS. With PAWS, the main issue is to make sure that you are doing a valid check. But RFC 1323 already contains a requirement that TS.Recent be able to be invalidated when a connection is idle for more than 24 days. With deferred timestamps, you'd just need to ensure that when the first Timestamps option is received, that the code for dealing with an invalidated TS.Recent is executed. The other issue is of RTT calculation. RTT measurements can only be taken from ACKs that acknowledge new data. If the receiving side decides it wants to turn on Timestamps and includes one in an ACK that acknowledges new data, the TSecr value (which is used to calculate RTT) won't be valid, even though it acknowledges new data. Probably the simplest way to address this problem is to restrict the enabling of Timestamps mid stream to data packets. That makes a certain amount of sense since enabling Timestamps midstream will most likely be based on passing some threshold for the amount of data sent. However, I do have an idea for a deterministic way to know when Timestamps have been fully enabled. When you first start sending Timestamps (either initiating, or in response to receiving a Timestamps), you fill in the exact same value for TSval in every packet that you send, until you receive a packet with a TSecr equal to that value. At that point you know that Timestamps are now enabled on both sides, and you start sending new TSval values. You don't do any RTT calculations until you get a packet that acknowledges new data, and has a TSecr value that is beyond the initial TSval used. This should address all three scenarios: the data receiver initiating enabling Timestamps, the data sender initiating enabling Timestamps, and both the sender and receiver enabling Timestamps at the same time. PAWS will work just fine, because it doesn't require the clock to tick for each packet, just at least once for each sequence space. So, when a deferred Timestamps implementation connects to an RFC-1323 implementation, what should be the desired behavior? a) Timestamps are enabled for the entire connection b) Timestamps are disabled for the entire connection I think it should be "a". -David Borman On Jan 26, 2007, at 12:33 PM, Borman, David wrote: > One of the topics that has been discussed in the past for the > revision of RFC 1323 is to relax the requirement on when to send the > Timestamps option. I'd like to come to some resolution on this issue. > > Current: > The Timestamps option is negotiated during the initial SYN exchange. > If both sides support it, then every packet in the connection has to > have the Timestamps option. > > Option #1 > --------- > The proposed change is to relax the requirement that Timestamps have > to be negotiated in the initial SYN, and instead allow them to be > enabled later on in the connection. At the time 1323 was originally > written, there was a big concern for legacy TCP stacks that didn't > handle unknown options in the middle of the connection, but were able > to properly ignore unknown options during the SYN exchange. But that > was a long time ago, and unknown options in the middle of a TCP > connection *shouldn't* be as big of an issue anymore. > > The rules for enabling Timestamps mid-stream would be: > 1) If you receive a Timestamps option mid-stream, you can enable > Timestamps. From then on, every packet sent will need to contain a > Timestamps option. > 2) If you want to enable Timestamps mid-stream, you can only do so on > a data packet. You record the sequence number of that data packet, > and include the Timestamps option on every packet from then on, until > you receive an ACK for that sequence number. If at any time you > receive a packet with the Timestamps option, then they are enabled > for the rest of the connection. If you do not receive a packet with > a Timestamps option by the time you get the ACK for that initial > sequence number, then the other side has not enabled Timestamps and > you must stop sending Timestamps for the duration of the connection. > > The restriction on only being able to initiate Timestamps on a data > packet is that they are the only packets that are delivered reliably, > so determining whether or not the other side supports them is > deterministic by getting the ACK for that data. > > > Option #2 > --------- > This is similar to Option #1, but not quite the same. In this case, > the Timestamps would be negotiated in the initial SYN as before, but > then no additional packets would have Timestamps options. At any > point during the connection, either side can enable the use of > Timestamps just by starting to send them. Since we already know that > both sides support them, once you start sending them you never stop. > And if you every receive one, you are then required to also send them > for the duration of the connection. > > The question then is, how do you negotiate Timestamps without turning > them on? My suggestion would be to send a Timestamps option with the > special format TSval=0,TSecr=0. If you receive this in a SYN, then > the request is to negotiate knowledge of the Timestamps option. The > returning SYN,ACK would also need to contain TSval=0,TSecr=0 to > complete the negotiation. If you are connecting to a site that > doesn't support this feature but does support Timestamps, it would > respond with TSval=xxx,TSecr=0. At that point, Timestamps are now > enabled. The downside of this is that now the originator has started > their Timestamps values at 0, and must continue from there with their > timestamps; they can't just suddenly jump to some arbitrary value > because that could break PAWs. > > > Option #3 > --------- > Do nothing, and leave Timestamps alone as they are currently > defined. You negotiate them in the SYN, and then include them in > every packet from then on. > > One of the issues with Timestamps is that the TSecr value is defined > to be valid anytime the ACK bit is set. This works well with the > initial SYN negotiation, but when you enable Timestamps midstream, > the initiator has to send a Timestamps option with an invalid TSecr > value, but the ACK bit will be set. That's the case for both of the > previous options. > > So why should we change things? My recollection was that the primary > motivation was to conserve option space, to avoid having to put in > the extra 12 bytes of TCP options on every packet until we get to the > point where the sequence space might wrap, and then turn them on so > that we can get PAWS to protect the rest of the connection. But I'm > not sure I buy that argument. One of the things that you lose by > deferring enabling Timestamps is that you don't get the RTT > measurements that Timestamps provide. Without Timestamps, using the > typical BSD algorithm of timing one segment and waiting for an ACK, > and adding in the Karn algorithm that you have to invalidate any > measurements if you had to retransmit in that window, means that at > best, you'll get one measurement per RTT. At worst, you can get in a > state where you never get a valid RTT measurement. When you use the > Timestamps option, the worst case is that you'll only get one > measurement per RTT, and the best case is that you'll get multiple > valid samples, > > My viewpoint > ------------ > Right now, I'm inclined to leave the Timestamps option alone; you > negotiate it during the SYN exchange, and then include it on every > packet. I'm willing to be convinced otherwise, but now I've placed a > stake in the ground, and the mailing list will have to decide if > there is sufficient reason to change the behavior. > > -David Borman > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed May 30 03:32: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 1HtIfd-0002ye-Q7; Wed, 30 May 2007 03:32:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtIfR-0002td-DY for tcpm@ietf.org; Wed, 30 May 2007 03:32:26 -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 1HtIfP-00005A-Ip for tcpm@ietf.org; Wed, 30 May 2007 03:32:25 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4U7VpJN020407; Wed, 30 May 2007 10:32:07 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 10:32:00 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 10:32:00 +0300 Received: from [172.21.34.150] (esdhcp034150.research.nokia.com [172.21.34.150]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4U7VwEA023532; Wed, 30 May 2007 10:31:59 +0300 In-Reply-To: <200705291836.UAA04625@TR-Sys.de> References: <200705291836.UAA04625@TR-Sys.de> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <8F01E60D-5498-4A5A-A23C-03C615EC2A17@nokia.com> From: Lars Eggert Date: Wed, 30 May 2007 10:31:49 +0300 To: =?ISO-8859-1?Q?ext_Alfred_H=CEnes?= X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 30 May 2007 07:32:00.0282 (UTC) FILETIME=[9C2F5FA0:01C7A28C] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: tcpm@ietf.org, ext Fernando Gont Subject: [tcpm] Re: draft-ietf-tcpm-tcp-uto-05 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="===============0029511750==" Errors-To: tcpm-bounces@ietf.org --===============0029511750== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-17-339646653; protocol="application/pkcs7-signature" --Apple-Mail-17-339646653 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Hi, On 2007-5-29, at 21:36, ext Alfred H=CEnes wrote: > eventually, I have found some time to study your updated UTO > draft, draft-ietf-tcpm-tcp-uto-05, and would again like to > submit a few comments. we appreciate your comments! > (1) > > I appreciate the changes incorporated (including editorial > suggestions I had sent for -04). > > In particular, IMHO the newly introduced formalization of the > TCP behaviour, using the ENABLED and CHANGEABLE flags, has > clarified and simplified the presentation. > > Yet, as an aid to implementors, I suggest to use more specific > names that can be easily carried over unchanged into > implementations and/or APIs without danger of name collisions; > to be constructive, I suggest: > > ENABLED --> TCP_USE_UTO > > CHANGEABLE --> TCP_ACCEPT_UTO > > and, to achieve more generic naming, also: > > LOCAL_UTO --> TCP_LOCAL_UTO > > For the same reasons it might be useful to change the names of > the configuration variables in Section 3.1 as well, e.g.: > > U_LIMIT --> TCP_UTO_MAX > > L_LIMIT --> TCP_UTO_MIN This has been suggested before, but I think it was in an off-list email. Implementors are free to choose whatever variable names they like for =20= their implementation - there is no expectation that these names will =20 be used as-is. For example, RFC2581 and RFC2988 define similar state =20 variables, for which implementations also choose different names. For this reason I'm unconvinced that renaming the state variables is =20 necessary. (At the very least, I wouldn't want to add the "TCP_" =20 prefix. If the WG thinks some of the other name changes clarify =20 things, I could be convinced to go with it.) > W.r.t. the granularity of the UTO configuration (cf. second-to- > last paragraph of Section 3.1), I had suggested to mention the > possibility of configuration *per-interface* because knowledge > of the first-hop link technology and its characteristics might > perhaps be an incentive for implementations to adapt the UTO > defaults and limits in a very user-friendly way, without specific > manual configuration or knowledge (to be) built into applications. > I cannot imagine support of "per-host" (better: "per-peer" ?) > or "per-user" granularity without very specific (usually manual) > configuration. > > Has this proposal been overlooked, or are there arguments against it? Hm - we may have overlooked this suggestion. I'm fine with adding =20 "per-outgoing-interface" to the list in that paragraph: Note that these limits MAY be specified as system-wide constants or at other granularities, such as on per-host, per-user, per-outgoing- interface or even per-connection basis. > (2) > > The modified text uses the wording "UTO options" at several > places (in particular, repaetedly in Section 3, twice in > Section 3.2, and three times in Section 4.1). > IMHO, this is a bit confusing, as you define only a single > UTO option (i.e. option code and option format). > > I therefore propose to change "UTO options" in most places > to "the UTO option", e.g. (near the end of Section 3): > > A TCP implementation that does not support UTO options MUST =20 > silently > ignore them [RFC1122], thus ensuring interoperability. > --- > A TCP implementation that does not support the UTO option MUST > silently ignore it [RFC1122], thus ensuring interoperability. I think this is a very minor point. Yes, there is only one type of =20 UTO option, but during the lifetime of a connection, many UTO options =20= may be exchanged. > (4) > > The new wording at the end of 4.1 almost 'invites' middleboxes > to modify the UTO. This should be avoided! > Such changes are obstructions to end-to-end transparency and security. > If you leave this suggestion in the draft, you will have to deal > with various IAB concerns ! Good point. The "or the option contents" part is problematic. Suggest =20= to rephrase that paragraph to: Stateful firewalls usually time out connection state after a =20 period of inactivity. If such a firewall exists along the path, it may close or abort connections regardless of the use of the TCP User Timeout Option. In the future, such firewalls may learn to parse the TCP User Timeout Option and adapt connection state management =20 accordingly. > As usual, if it deems useful to you, please forward these notes (or > part of it) to the TCPM list, perhaps together with your comments. As usual, thanks for the comments! Highly appreciated. Lars PS: Fernando, since you have the editing token, will you incorporate =20 these changes? --Apple-Mail-17-339646653 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 MBwGCSqGSIb3DQEJBTEPFw0wNzA1MzAwNzMxNDlaMCMGCSqGSIb3DQEJBDEWBBRafnxygLJ612j1 gW0JcVOzM7ZsLzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAeqCFpsScRLKEpN3/bsZbvjYTBH4Sg3g8YVUP1U3q3Iz2SsEn/28z hiS0rBpGy0Q2wSB+FVf4gRKK528Um17giDpkSyZCfkQStAhHJC6kqTA9taIQvJ1yOdSn5Q6rKmgy +Ek2lbtP7wO7ppaH+cxZogKmadin1BFGc8uKRvSnuICwupkoMCrOGIFR8wNxonTj+KEpTcTqTNEr NGR2YfCt5rAH+a46sHbXTkNCT4TBdnaCiO8DW1tbxhmD7oB3Txspoh3ZGvarL5Mp0X6xoIb+GQEk ElqutoL4ez6sG4A21RpZC5DLEqDumquQGvsMlJIi8vY1pWNcknYjyNoJLGW8EQAAAAAAAA== --Apple-Mail-17-339646653-- --===============0029511750== 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 --===============0029511750==-- From tcpm-bounces@ietf.org Wed May 30 06:41: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 1HtLcK-00057m-Ms; Wed, 30 May 2007 06:41:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtLcI-00057D-3P for tcpm@ietf.org; Wed, 30 May 2007 06:41:22 -0400 Received: from s-utl02-dcpop.stsn.net ([72.255.0.202]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HtLcG-0008Pc-Jt for tcpm@ietf.org; Wed, 30 May 2007 06:41:22 -0400 Received: from s-utl02-dcpop.stsn.net ([127.0.0.1]) by s-utl02-dcpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2007053006411608571 ; Wed, 30 May 2007 06:41:16 -0400 X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.867,AWL: 0.099,BAYES_00: -1.665 X-Spam-Level: Received: from [127.0.0.1] ([10.24.135.59]) by s-utl02-dcpop.stsn.net; Wed, 30 May 2007 06:41:13 -0400 Message-ID: <465D54A8.9000100@isi.edu> Date: Wed, 30 May 2007 03:40:40 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: David Borman Subject: Re: [tcpm] Re: RFC 1323: Timestamps option References: <018977E8-C9F4-42E2-A877-95330F65E7D3@windriver.com> In-Reply-To: X-Enigmail-Version: 0.95.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 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="===============1265392090==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1265392090== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCAECE9F72A2A5387517862B7" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCAECE9F72A2A5387517862B7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, David, I had some questions below... David Borman wrote: > Hi, >=20 > I've been having some off-line discussion about how to turn on > Timestamps mid-stream, and I'm coming to a clearer picture. I'm now no= w > leaning towards changing to allow this to happen in a standard way. I > think I can now more clearly enumerate the specific issues about > enumerating them mid-stream. >=20 > First, do you or do you not include Timestamps in the SYN exchange, and= > how much do you care about interoperability with existing 1323 > implementations? If you do not include Timestamps negotiation, then I > would expect that mid-stream enabling of Timestamps would only work on > modified hosts that understand the new rules. >=20 > I've come up with a variation on Option #2 >=20 > Option 2a: > ---------- > The Timestamps option is sent only in the SYN and SYN,ACK packet. If > both sides understand deferred enabling of Timestamps, then the > connection will continue without Timestamps until one of them initiates= > Timestamps by including it in a packet. Once Timestamps have been sent= > or received after the initial SYN,ACK, they are then sent in all packet= s > for the duration of the connection. >=20 > This has the advantage of knowing up front that the other side > understands the Timestamps option, so when you later decide to enable > them, you just turn them on and start sending them, you don't have to > try to figure out midstream whether or not the other side understands > Timestamps. When talking to an RFC-1323 implementation, since the othe= r > side will include Timestamps in all packets, the option will be enabled= > right away How is reordering handled? I.e., all new packets may be stamped, but reordering could affect how that's seen at the receiver. (see below...) =2E.. > However, I do have an idea for a deterministic way to know when > Timestamps have been fully enabled. When you first start sending > Timestamps (either initiating, or in response to receiving a > Timestamps), you fill in the exact same value for TSval in every packet= > that you send, until you receive a packet with a TSecr equal to that > value. At that point you know that Timestamps are now enabled on both > sides, and you start sending new TSval values. You don't do any RTT > calculations until you get a packet that acknowledges new data, and has= > a TSecr value that is beyond the initial TSval used. This should > address all three scenarios: the data receiver initiating enabling > Timestamps, the data sender initiating enabling Timestamps, and both th= e > sender and receiver enabling Timestamps at the same time. PAWS will > work just fine, because it doesn't require the clock to tick for each > packet, just at least once for each sequence space. The problem with enabling options mid-stream is that you haven't cleared the packets from the system; this is not the case during SYN exchange. I'm wondering whether there's a case where you could have started sending new TSvals, and you get a new data ACK (and start calculating RTTs), and then a packet comes in out of order (e.g., duplicated or SACK). Could this corrupt the RTT? Could this ever happen? > So, when a deferred Timestamps implementation connects to an RFC-1323 > implementation, what should be the desired behavior? > a) Timestamps are enabled for the entire connection > b) Timestamps are disabled for the entire connection > I think it should be "a". This is asking whether deferred timestamps disables legacy 1323 use, IMO, and I agree that the only conclusion is (a). Joe > On Jan 26, 2007, at 12:33 PM, Borman, David wrote: >=20 >> One of the topics that has been discussed in the past for the >> revision of RFC 1323 is to relax the requirement on when to send the >> Timestamps option. I'd like to come to some resolution on this issue.= >> >> Current: >> The Timestamps option is negotiated during the initial SYN exchange. >> If both sides support it, then every packet in the connection has to >> have the Timestamps option. >> >> Option #1 >> --------- >> The proposed change is to relax the requirement that Timestamps have >> to be negotiated in the initial SYN, and instead allow them to be >> enabled later on in the connection. At the time 1323 was originally >> written, there was a big concern for legacy TCP stacks that didn't >> handle unknown options in the middle of the connection, but were able >> to properly ignore unknown options during the SYN exchange. But that >> was a long time ago, and unknown options in the middle of a TCP >> connection *shouldn't* be as big of an issue anymore. >> >> The rules for enabling Timestamps mid-stream would be: >> 1) If you receive a Timestamps option mid-stream, you can enable >> Timestamps. From then on, every packet sent will need to contain a >> Timestamps option. >> 2) If you want to enable Timestamps mid-stream, you can only do so on >> a data packet. You record the sequence number of that data packet, >> and include the Timestamps option on every packet from then on, until >> you receive an ACK for that sequence number. If at any time you >> receive a packet with the Timestamps option, then they are enabled >> for the rest of the connection. If you do not receive a packet with >> a Timestamps option by the time you get the ACK for that initial >> sequence number, then the other side has not enabled Timestamps and >> you must stop sending Timestamps for the duration of the connection. >> >> The restriction on only being able to initiate Timestamps on a data >> packet is that they are the only packets that are delivered reliably, >> so determining whether or not the other side supports them is >> deterministic by getting the ACK for that data. >> >> >> Option #2 >> --------- >> This is similar to Option #1, but not quite the same. In this case, >> the Timestamps would be negotiated in the initial SYN as before, but >> then no additional packets would have Timestamps options. At any >> point during the connection, either side can enable the use of >> Timestamps just by starting to send them. Since we already know that >> both sides support them, once you start sending them you never stop. >> And if you every receive one, you are then required to also send them >> for the duration of the connection. >> >> The question then is, how do you negotiate Timestamps without turning >> them on? My suggestion would be to send a Timestamps option with the >> special format TSval=3D0,TSecr=3D0. If you receive this in a SYN, the= n >> the request is to negotiate knowledge of the Timestamps option. The >> returning SYN,ACK would also need to contain TSval=3D0,TSecr=3D0 to >> complete the negotiation. If you are connecting to a site that >> doesn't support this feature but does support Timestamps, it would >> respond with TSval=3Dxxx,TSecr=3D0. At that point, Timestamps are now= >> enabled. The downside of this is that now the originator has started >> their Timestamps values at 0, and must continue from there with their >> timestamps; they can't just suddenly jump to some arbitrary value >> because that could break PAWs. >> >> >> Option #3 >> --------- >> Do nothing, and leave Timestamps alone as they are currently >> defined. You negotiate them in the SYN, and then include them in >> every packet from then on. >> >> One of the issues with Timestamps is that the TSecr value is defined >> to be valid anytime the ACK bit is set. This works well with the >> initial SYN negotiation, but when you enable Timestamps midstream, >> the initiator has to send a Timestamps option with an invalid TSecr >> value, but the ACK bit will be set. That's the case for both of the >> previous options. >> >> So why should we change things? My recollection was that the primary >> motivation was to conserve option space, to avoid having to put in >> the extra 12 bytes of TCP options on every packet until we get to the >> point where the sequence space might wrap, and then turn them on so >> that we can get PAWS to protect the rest of the connection. But I'm >> not sure I buy that argument. One of the things that you lose by >> deferring enabling Timestamps is that you don't get the RTT >> measurements that Timestamps provide. Without Timestamps, using the >> typical BSD algorithm of timing one segment and waiting for an ACK, >> and adding in the Karn algorithm that you have to invalidate any >> measurements if you had to retransmit in that window, means that at >> best, you'll get one measurement per RTT. At worst, you can get in a >> state where you never get a valid RTT measurement. When you use the >> Timestamps option, the worst case is that you'll only get one >> measurement per RTT, and the best case is that you'll get multiple >> valid samples, >> >> My viewpoint >> ------------ >> Right now, I'm inclined to leave the Timestamps option alone; you >> negotiate it during the SYN exchange, and then include it on every >> packet. I'm willing to be convinced otherwise, but now I've placed a >> stake in the ground, and the mailing list will have to decide if >> there is sufficient reason to change the behavior. >> >> -David Borman >> >> >=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 --------------enigCAECE9F72A2A5387517862B7 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 iD8DBQFGXVSoE5f5cImnZrsRAvIFAKDvIs+4/qh4dgtzA5F9u9mrSOUdQgCg/SYC 0QaMViB83imJFCWDajJCzOI= =qjEn -----END PGP SIGNATURE----- --------------enigCAECE9F72A2A5387517862B7-- --===============1265392090== 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 --===============1265392090==-- From tcpm-bounces@ietf.org Wed May 30 07:30: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 1HtMNn-0005MQ-6S; Wed, 30 May 2007 07:30:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtMNm-0005LU-Fy for tcpm@ietf.org; Wed, 30 May 2007 07:30:26 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtMNl-0007eO-TW for tcpm@ietf.org; Wed, 30 May 2007 07:30:26 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 86E5DF0C423; Wed, 30 May 2007 08:30:25 -0300 (ART) Received: from fgont.gont.com.ar (237-176-231-201.fibertel.com.ar [201.231.176.237]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id l4UBUJqN019465; Wed, 30 May 2007 08:30:23 -0300 Message-Id: <200705301130.l4UBUJqN019465@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 30 May 2007 08:22:00 -0300 To: Lars Eggert , ext Alfred =?iso-8859-1?Q?H=CEnes?= From: Fernando Gont Subject: Re: [tcpm] Re: draft-ietf-tcpm-tcp-uto-05 In-Reply-To: <8F01E60D-5498-4A5A-A23C-03C615EC2A17@nokia.com> References: <200705291836.UAA04625@TR-Sys.de> <8F01E60D-5498-4A5A-A23C-03C615EC2A17@nokia.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]); Wed, 30 May 2007 08:30:25 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: tcpm@ietf.org, ext 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 At 04:31 a.m. 30/05/2007, Lars Eggert wrote: >This has been suggested before, but I think it was in an off-list email. > >Implementors are free to choose whatever variable names they like for >their implementation - there is no expectation that these names will >be used as-is. For example, RFC2581 and RFC2988 define similar state >variables, for which implementations also choose different names. > >For this reason I'm unconvinced that renaming the state variables is >necessary. (At the very least, I wouldn't want to add the "TCP_" >prefix. If the WG thinks some of the other name changes clarify >things, I could be convinced to go with it.) I agree with Lars here. >>W.r.t. the granularity of the UTO configuration (cf. second-to- >>last paragraph of Section 3.1), I had suggested to mention the >>possibility of configuration *per-interface* because knowledge >>of the first-hop link technology and its characteristics might >>perhaps be an incentive for implementations to adapt the UTO >>defaults and limits in a very user-friendly way, without specific >>manual configuration or knowledge (to be) built into applications. >>I cannot imagine support of "per-host" (better: "per-peer" ?) >>or "per-user" granularity without very specific (usually manual) >>configuration. >> >>Has this proposal been overlooked, or are there arguments against it? > >Hm - we may have overlooked this suggestion. I'm fine with adding >"per-outgoing-interface" to the list in that paragraph: > > Note that these limits MAY be specified as system-wide constants or > at other granularities, such as on per-host, per-user, per-outgoing- > interface or even per-connection basis. Will commit this into the draft. >>(2) >> >>The modified text uses the wording "UTO options" at several >>places (in particular, repaetedly in Section 3, twice in >>Section 3.2, and three times in Section 4.1). >>IMHO, this is a bit confusing, as you define only a single >>UTO option (i.e. option code and option format). >> >>I therefore propose to change "UTO options" in most places >>to "the UTO option", e.g. (near the end of Section 3): >> >> A TCP implementation that does not support UTO options MUST >>silently >> ignore them [RFC1122], thus ensuring interoperability. >>--- >> A TCP implementation that does not support the UTO option MUST >> silently ignore it [RFC1122], thus ensuring interoperability. I agree that in a few instances the use of "UTO options" may be a little bit confusing. Will try to change the text as suggested. >>(4) >> >>The new wording at the end of 4.1 almost 'invites' middleboxes >>to modify the UTO. This should be avoided! >>Such changes are obstructions to end-to-end transparency and security. >>If you leave this suggestion in the draft, you will have to deal >>with various IAB concerns ! > >Good point. The "or the option contents" part is problematic. Suggest >to rephrase that paragraph to: > > Stateful firewalls usually time out connection state after a >period of > inactivity. If such a firewall exists along the path, it may close > or abort connections regardless of the use of the TCP User Timeout > Option. In the future, such firewalls may learn to parse the TCP > User Timeout Option and adapt connection state management >accordingly. Will commit this change. >PS: Fernando, since you have the editing token, will you incorporate >these changes? Yes. Alfred: Let us know if the text suggested by Lars addresses your comments. Once again, thanks so much for your thorough review! 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 Wed May 30 10:16: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 1HtOyP-0008Gw-II; Wed, 30 May 2007 10:16:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtOyO-0008Gq-Uu for tcpm@ietf.org; Wed, 30 May 2007 10:16:24 -0400 Received: from mail.windriver.com ([147.11.1.11] helo=mail.wrs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtOyO-0003Zl-7t for tcpm@ietf.org; Wed, 30 May 2007 10:16:24 -0400 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id l4UEGMN6028183; Wed, 30 May 2007 07:16:22 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 07:16:22 -0700 Received: from [192.168.117.80] ([192.168.117.80]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 07:16:22 -0700 In-Reply-To: <465D54A8.9000100@isi.edu> References: <018977E8-C9F4-42E2-A877-95330F65E7D3@windriver.com> <465D54A8.9000100@isi.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <811BD121-1A79-45F4-B4E2-173729655CA9@windriver.com> Content-Transfer-Encoding: 7bit From: David Borman Subject: Re: [tcpm] Re: RFC 1323: Timestamps option Date: Wed, 30 May 2007 09:16:18 -0500 To: Joe Touch X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 30 May 2007 14:16:22.0474 (UTC) FILETIME=[199412A0:01C7A2C5] X-Spam-Score: 0.1 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a 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 Hi Joe, On May 30, 2007, at 5:40 AM, Joe Touch wrote: > Hi, David, > > I had some questions below... > > David Borman wrote: >> Hi, >> >> I've been having some off-line discussion about how to turn on >> Timestamps mid-stream, and I'm coming to a clearer picture. I'm >> now now >> leaning towards changing to allow this to happen in a standard >> way. I >> think I can now more clearly enumerate the specific issues about >> enumerating them mid-stream. >> >> First, do you or do you not include Timestamps in the SYN >> exchange, and >> how much do you care about interoperability with existing 1323 >> implementations? If you do not include Timestamps negotiation, >> then I >> would expect that mid-stream enabling of Timestamps would only >> work on >> modified hosts that understand the new rules. >> >> I've come up with a variation on Option #2 >> >> Option 2a: >> ---------- >> The Timestamps option is sent only in the SYN and SYN,ACK packet. If >> both sides understand deferred enabling of Timestamps, then the >> connection will continue without Timestamps until one of them >> initiates >> Timestamps by including it in a packet. Once Timestamps have been >> sent >> or received after the initial SYN,ACK, they are then sent in all >> packets >> for the duration of the connection. >> >> This has the advantage of knowing up front that the other side >> understands the Timestamps option, so when you later decide to enable >> them, you just turn them on and start sending them, you don't have to >> try to figure out midstream whether or not the other side understands >> Timestamps. When talking to an RFC-1323 implementation, since the >> other >> side will include Timestamps in all packets, the option will be >> enabled >> right away > > How is reordering handled? I.e., all new packets may be stamped, but > reordering could affect how that's seen at the receiver. (see > below...) The receiver won't have fully turned on timestamp support until it has sent a TSval and received a TSecr with the same value. The only issue is if you turn on full PAWS support when you receive the first packet with a timestamp option, and then start dropping any packets that don't contain a timestamp option. So, you don't turn on PAWS until you've gotten a TSecr with your initial TSval. And even if you should happen to drop reordered packets without the timestamp option, TCP retransmissions should take care of any dropped data. > > ... >> However, I do have an idea for a deterministic way to know when >> Timestamps have been fully enabled. When you first start sending >> Timestamps (either initiating, or in response to receiving a >> Timestamps), you fill in the exact same value for TSval in every >> packet >> that you send, until you receive a packet with a TSecr equal to that >> value. At that point you know that Timestamps are now enabled on >> both >> sides, and you start sending new TSval values. You don't do any RTT >> calculations until you get a packet that acknowledges new data, >> and has >> a TSecr value that is beyond the initial TSval used. This should >> address all three scenarios: the data receiver initiating enabling >> Timestamps, the data sender initiating enabling Timestamps, and >> both the >> sender and receiver enabling Timestamps at the same time. PAWS will >> work just fine, because it doesn't require the clock to tick for each >> packet, just at least once for each sequence space. > > The problem with enabling options mid-stream is that you haven't > cleared > the packets from the system; this is not the case during SYN exchange. That why you keep sending the the same timestamp until you see it in at least one TSecr, and you don't use that timestamp for any RTT calculations. > > I'm wondering whether there's a case where you could have started > sending new TSvals, and you get a new data ACK (and start calculating > RTTs), and then a packet comes in out of order (e.g., duplicated or > SACK). Could this corrupt the RTT? Could this ever happen? Besides being an ACK for new data, it also has to have a TSecr beyond the initial timestamp you sent. By the time both of those things are true, you should be into normal RFC-1323 processing. > >> So, when a deferred Timestamps implementation connects to an RFC-1323 >> implementation, what should be the desired behavior? >> a) Timestamps are enabled for the entire connection >> b) Timestamps are disabled for the entire connection >> I think it should be "a". > > This is asking whether deferred timestamps disables legacy 1323 use, > IMO, and I agree that the only conclusion is (a). > > Joe > >> On Jan 26, 2007, at 12:33 PM, Borman, David wrote: >> >>> One of the topics that has been discussed in the past for the >>> revision of RFC 1323 is to relax the requirement on when to send the >>> Timestamps option. I'd like to come to some resolution on this >>> issue. >>> >>> Current: >>> The Timestamps option is negotiated during the initial SYN exchange. >>> If both sides support it, then every packet in the connection has to >>> have the Timestamps option. >>> >>> Option #1 >>> --------- >>> The proposed change is to relax the requirement that Timestamps have >>> to be negotiated in the initial SYN, and instead allow them to be >>> enabled later on in the connection. At the time 1323 was originally >>> written, there was a big concern for legacy TCP stacks that didn't >>> handle unknown options in the middle of the connection, but were >>> able >>> to properly ignore unknown options during the SYN exchange. But >>> that >>> was a long time ago, and unknown options in the middle of a TCP >>> connection *shouldn't* be as big of an issue anymore. >>> >>> The rules for enabling Timestamps mid-stream would be: >>> 1) If you receive a Timestamps option mid-stream, you can enable >>> Timestamps. From then on, every packet sent will need to contain a >>> Timestamps option. >>> 2) If you want to enable Timestamps mid-stream, you can only do >>> so on >>> a data packet. You record the sequence number of that data packet, >>> and include the Timestamps option on every packet from then on, >>> until >>> you receive an ACK for that sequence number. If at any time you >>> receive a packet with the Timestamps option, then they are enabled >>> for the rest of the connection. If you do not receive a packet with >>> a Timestamps option by the time you get the ACK for that initial >>> sequence number, then the other side has not enabled Timestamps and >>> you must stop sending Timestamps for the duration of the connection. >>> >>> The restriction on only being able to initiate Timestamps on a data >>> packet is that they are the only packets that are delivered >>> reliably, >>> so determining whether or not the other side supports them is >>> deterministic by getting the ACK for that data. >>> >>> >>> Option #2 >>> --------- >>> This is similar to Option #1, but not quite the same. In this case, >>> the Timestamps would be negotiated in the initial SYN as before, but >>> then no additional packets would have Timestamps options. At any >>> point during the connection, either side can enable the use of >>> Timestamps just by starting to send them. Since we already know >>> that >>> both sides support them, once you start sending them you never stop. >>> And if you every receive one, you are then required to also send >>> them >>> for the duration of the connection. >>> >>> The question then is, how do you negotiate Timestamps without >>> turning >>> them on? My suggestion would be to send a Timestamps option with >>> the >>> special format TSval=0,TSecr=0. If you receive this in a SYN, then >>> the request is to negotiate knowledge of the Timestamps option. The >>> returning SYN,ACK would also need to contain TSval=0,TSecr=0 to >>> complete the negotiation. If you are connecting to a site that >>> doesn't support this feature but does support Timestamps, it would >>> respond with TSval=xxx,TSecr=0. At that point, Timestamps are now >>> enabled. The downside of this is that now the originator has >>> started >>> their Timestamps values at 0, and must continue from there with >>> their >>> timestamps; they can't just suddenly jump to some arbitrary value >>> because that could break PAWs. >>> >>> >>> Option #3 >>> --------- >>> Do nothing, and leave Timestamps alone as they are currently >>> defined. You negotiate them in the SYN, and then include them in >>> every packet from then on. >>> >>> One of the issues with Timestamps is that the TSecr value is defined >>> to be valid anytime the ACK bit is set. This works well with the >>> initial SYN negotiation, but when you enable Timestamps midstream, >>> the initiator has to send a Timestamps option with an invalid TSecr >>> value, but the ACK bit will be set. That's the case for both of the >>> previous options. >>> >>> So why should we change things? My recollection was that the >>> primary >>> motivation was to conserve option space, to avoid having to put in >>> the extra 12 bytes of TCP options on every packet until we get to >>> the >>> point where the sequence space might wrap, and then turn them on so >>> that we can get PAWS to protect the rest of the connection. But I'm >>> not sure I buy that argument. One of the things that you lose by >>> deferring enabling Timestamps is that you don't get the RTT >>> measurements that Timestamps provide. Without Timestamps, using the >>> typical BSD algorithm of timing one segment and waiting for an ACK, >>> and adding in the Karn algorithm that you have to invalidate any >>> measurements if you had to retransmit in that window, means that at >>> best, you'll get one measurement per RTT. At worst, you can get >>> in a >>> state where you never get a valid RTT measurement. When you use the >>> Timestamps option, the worst case is that you'll only get one >>> measurement per RTT, and the best case is that you'll get multiple >>> valid samples, >>> >>> My viewpoint >>> ------------ >>> Right now, I'm inclined to leave the Timestamps option alone; you >>> negotiate it during the SYN exchange, and then include it on every >>> packet. I'm willing to be convinced otherwise, but now I've >>> placed a >>> stake in the ground, and the mailing list will have to decide if >>> there is sufficient reason to change the behavior. >>> >>> -David Borman >>> >>> >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www1.ietf.org/mailman/listinfo/tcpm > > -- > ---------------------------------------- > Joe Touch > Sr. Network Engineer, USAF TSAT Space Segment > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed May 30 11:59: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 1HtQaT-0005fz-M9; Wed, 30 May 2007 11:59:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtQaS-0005fu-3U for tcpm@ietf.org; Wed, 30 May 2007 11:59:48 -0400 Received: from [2001:5e8:2:42:2e0:81ff:fe30:e898] (helo=mailer2.psc.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtQaQ-0007eO-Hy for tcpm@ietf.org; Wed, 30 May 2007 11:59:48 -0400 Received: from tesla.psc.edu (tesla.psc.edu [128.182.58.233]) by mailer2.psc.edu (8.13.8/8.13.3) with ESMTP id l4UFxjs2011706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 May 2007 11:59:46 -0400 (EDT) Received: from localhost.psc.edu (localhost.psc.edu [127.0.0.1]) by tesla.psc.edu (8.13.1/8.13.1) with ESMTP id l4UFxjak003296; Wed, 30 May 2007 11:59:45 -0400 Date: Wed, 30 May 2007 11:59:45 -0400 (EDT) From: Matt Mathis To: David Borman Subject: Re: [tcpm] Re: RFC 1323: Timestamps option In-Reply-To: <811BD121-1A79-45F4-B4E2-173729655CA9@windriver.com> Message-ID: References: <018977E8-C9F4-42E2-A877-95330F65E7D3@windriver.com> <465D54A8.9000100@isi.edu> <811BD121-1A79-45F4-B4E2-173729655CA9@windriver.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -2.8 (--) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 Cc: TCP Maintenance and Minor Extensions WG , 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 I had assumed that you can "fake" paws as follows: once you receive a late timestamp negotiation (in either role), you treat any later untimestamped segments as though they bear the timstamp just before the earliest time stamp seen. I believe that this is optimal, given other assumptions. I think it also works well enough to treat any later untimestamped segments as though they bear the timestamp just before the the most recently received timestamp. This is actually the same if the timestamps do not advance during the negotiation RTT. (Well enough means that the failures are neither frequent nor serious). Thanks, --MM-- ------------------------------------------- Matt Mathis http://www.psc.edu/~mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- Evil is defined by mortals who think they know "The Truth" and use force to apply it to others. On Wed, 30 May 2007, David Borman wrote: > Hi Joe, > > On May 30, 2007, at 5:40 AM, Joe Touch wrote: > > > Hi, David, > > > > I had some questions below... > > > > David Borman wrote: > >> Hi, > >> > >> I've been having some off-line discussion about how to turn on > >> Timestamps mid-stream, and I'm coming to a clearer picture. I'm > >> now now > >> leaning towards changing to allow this to happen in a standard > >> way. I > >> think I can now more clearly enumerate the specific issues about > >> enumerating them mid-stream. > >> > >> First, do you or do you not include Timestamps in the SYN > >> exchange, and > >> how much do you care about interoperability with existing 1323 > >> implementations? If you do not include Timestamps negotiation, > >> then I > >> would expect that mid-stream enabling of Timestamps would only > >> work on > >> modified hosts that understand the new rules. > >> > >> I've come up with a variation on Option #2 > >> > >> Option 2a: > >> ---------- > >> The Timestamps option is sent only in the SYN and SYN,ACK packet. If > >> both sides understand deferred enabling of Timestamps, then the > >> connection will continue without Timestamps until one of them > >> initiates > >> Timestamps by including it in a packet. Once Timestamps have been > >> sent > >> or received after the initial SYN,ACK, they are then sent in all > >> packets > >> for the duration of the connection. > >> > >> This has the advantage of knowing up front that the other side > >> understands the Timestamps option, so when you later decide to enable > >> them, you just turn them on and start sending them, you don't have to > >> try to figure out midstream whether or not the other side understands > >> Timestamps. When talking to an RFC-1323 implementation, since the > >> other > >> side will include Timestamps in all packets, the option will be > >> enabled > >> right away > > > > How is reordering handled? I.e., all new packets may be stamped, but > > reordering could affect how that's seen at the receiver. (see > > below...) > > The receiver won't have fully turned on timestamp support until it > has sent a TSval and received a TSecr with the same value. The only > issue is if you turn on full PAWS support when you receive the first > packet with a timestamp option, and then start dropping any packets > that don't contain a timestamp option. So, you don't turn on PAWS > until you've gotten a TSecr with your initial TSval. And even if you > should happen to drop reordered packets without the timestamp option, > TCP retransmissions should take care of any dropped data. > > > > > ... > >> However, I do have an idea for a deterministic way to know when > >> Timestamps have been fully enabled. When you first start sending > >> Timestamps (either initiating, or in response to receiving a > >> Timestamps), you fill in the exact same value for TSval in every > >> packet > >> that you send, until you receive a packet with a TSecr equal to that > >> value. At that point you know that Timestamps are now enabled on > >> both > >> sides, and you start sending new TSval values. You don't do any RTT > >> calculations until you get a packet that acknowledges new data, > >> and has > >> a TSecr value that is beyond the initial TSval used. This should > >> address all three scenarios: the data receiver initiating enabling > >> Timestamps, the data sender initiating enabling Timestamps, and > >> both the > >> sender and receiver enabling Timestamps at the same time. PAWS will > >> work just fine, because it doesn't require the clock to tick for each > >> packet, just at least once for each sequence space. > > > > The problem with enabling options mid-stream is that you haven't > > cleared > > the packets from the system; this is not the case during SYN exchange. > > That why you keep sending the the same timestamp until you see it in > at least one TSecr, and you don't use that timestamp for any RTT > calculations. > > > > I'm wondering whether there's a case where you could have started > > sending new TSvals, and you get a new data ACK (and start calculating > > RTTs), and then a packet comes in out of order (e.g., duplicated or > > SACK). Could this corrupt the RTT? Could this ever happen? > > Besides being an ACK for new data, it also has to have a TSecr beyond > the initial timestamp you sent. By the time both of those things are > true, you should be into normal RFC-1323 processing. > > > > >> So, when a deferred Timestamps implementation connects to an RFC-1323 > >> implementation, what should be the desired behavior? > >> a) Timestamps are enabled for the entire connection > >> b) Timestamps are disabled for the entire connection > >> I think it should be "a". > > > > This is asking whether deferred timestamps disables legacy 1323 use, > > IMO, and I agree that the only conclusion is (a). > > > > Joe > > > >> On Jan 26, 2007, at 12:33 PM, Borman, David wrote: > >> > >>> One of the topics that has been discussed in the past for the > >>> revision of RFC 1323 is to relax the requirement on when to send the > >>> Timestamps option. I'd like to come to some resolution on this > >>> issue. > >>> > >>> Current: > >>> The Timestamps option is negotiated during the initial SYN exchange. > >>> If both sides support it, then every packet in the connection has to > >>> have the Timestamps option. > >>> > >>> Option #1 > >>> --------- > >>> The proposed change is to relax the requirement that Timestamps have > >>> to be negotiated in the initial SYN, and instead allow them to be > >>> enabled later on in the connection. At the time 1323 was originally > >>> written, there was a big concern for legacy TCP stacks that didn't > >>> handle unknown options in the middle of the connection, but were > >>> able > >>> to properly ignore unknown options during the SYN exchange. But > >>> that > >>> was a long time ago, and unknown options in the middle of a TCP > >>> connection *shouldn't* be as big of an issue anymore. > >>> > >>> The rules for enabling Timestamps mid-stream would be: > >>> 1) If you receive a Timestamps option mid-stream, you can enable > >>> Timestamps. From then on, every packet sent will need to contain a > >>> Timestamps option. > >>> 2) If you want to enable Timestamps mid-stream, you can only do > >>> so on > >>> a data packet. You record the sequence number of that data packet, > >>> and include the Timestamps option on every packet from then on, > >>> until > >>> you receive an ACK for that sequence number. If at any time you > >>> receive a packet with the Timestamps option, then they are enabled > >>> for the rest of the connection. If you do not receive a packet with > >>> a Timestamps option by the time you get the ACK for that initial > >>> sequence number, then the other side has not enabled Timestamps and > >>> you must stop sending Timestamps for the duration of the connection. > >>> > >>> The restriction on only being able to initiate Timestamps on a data > >>> packet is that they are the only packets that are delivered > >>> reliably, > >>> so determining whether or not the other side supports them is > >>> deterministic by getting the ACK for that data. > >>> > >>> > >>> Option #2 > >>> --------- > >>> This is similar to Option #1, but not quite the same. In this case, > >>> the Timestamps would be negotiated in the initial SYN as before, but > >>> then no additional packets would have Timestamps options. At any > >>> point during the connection, either side can enable the use of > >>> Timestamps just by starting to send them. Since we already know > >>> that > >>> both sides support them, once you start sending them you never stop. > >>> And if you every receive one, you are then required to also send > >>> them > >>> for the duration of the connection. > >>> > >>> The question then is, how do you negotiate Timestamps without > >>> turning > >>> them on? My suggestion would be to send a Timestamps option with > >>> the > >>> special format TSval=0,TSecr=0. If you receive this in a SYN, then > >>> the request is to negotiate knowledge of the Timestamps option. The > >>> returning SYN,ACK would also need to contain TSval=0,TSecr=0 to > >>> complete the negotiation. If you are connecting to a site that > >>> doesn't support this feature but does support Timestamps, it would > >>> respond with TSval=xxx,TSecr=0. At that point, Timestamps are now > >>> enabled. The downside of this is that now the originator has > >>> started > >>> their Timestamps values at 0, and must continue from there with > >>> their > >>> timestamps; they can't just suddenly jump to some arbitrary value > >>> because that could break PAWs. > >>> > >>> > >>> Option #3 > >>> --------- > >>> Do nothing, and leave Timestamps alone as they are currently > >>> defined. You negotiate them in the SYN, and then include them in > >>> every packet from then on. > >>> > >>> One of the issues with Timestamps is that the TSecr value is defined > >>> to be valid anytime the ACK bit is set. This works well with the > >>> initial SYN negotiation, but when you enable Timestamps midstream, > >>> the initiator has to send a Timestamps option with an invalid TSecr > >>> value, but the ACK bit will be set. That's the case for both of the > >>> previous options. > >>> > >>> So why should we change things? My recollection was that the > >>> primary > >>> motivation was to conserve option space, to avoid having to put in > >>> the extra 12 bytes of TCP options on every packet until we get to > >>> the > >>> point where the sequence space might wrap, and then turn them on so > >>> that we can get PAWS to protect the rest of the connection. But I'm > >>> not sure I buy that argument. One of the things that you lose by > >>> deferring enabling Timestamps is that you don't get the RTT > >>> measurements that Timestamps provide. Without Timestamps, using the > >>> typical BSD algorithm of timing one segment and waiting for an ACK, > >>> and adding in the Karn algorithm that you have to invalidate any > >>> measurements if you had to retransmit in that window, means that at > >>> best, you'll get one measurement per RTT. At worst, you can get > >>> in a > >>> state where you never get a valid RTT measurement. When you use the > >>> Timestamps option, the worst case is that you'll only get one > >>> measurement per RTT, and the best case is that you'll get multiple > >>> valid samples, > >>> > >>> My viewpoint > >>> ------------ > >>> Right now, I'm inclined to leave the Timestamps option alone; you > >>> negotiate it during the SYN exchange, and then include it on every > >>> packet. I'm willing to be convinced otherwise, but now I've > >>> placed a > >>> stake in the ground, and the mailing list will have to decide if > >>> there is sufficient reason to change the behavior. > >>> > >>> -David Borman > >>> > >>> > >> > >> > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> https://www1.ietf.org/mailman/listinfo/tcpm > > > > -- > > ---------------------------------------- > > Joe Touch > > Sr. Network Engineer, USAF TSAT Space Segment > > > > > _______________________________________________ > 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 Wed May 30 13: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 1HtSBy-0001PU-8Q; Wed, 30 May 2007 13:42:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtSBw-0001Gx-Ig for tcpm@ietf.org; Wed, 30 May 2007 13:42:36 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtSBv-0003we-79 for tcpm@ietf.org; Wed, 30 May 2007 13:42:36 -0400 Received: from [127.0.0.1] (70.sub-75-193-101.myvzw.com [75.193.101.70]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l4UHg52t023256; Wed, 30 May 2007 10:42:10 -0700 (PDT) Message-ID: <465DB752.80900@isi.edu> Date: Wed, 30 May 2007 10:41:38 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: David Borman Subject: Re: [tcpm] Re: RFC 1323: Timestamps option References: <018977E8-C9F4-42E2-A877-95330F65E7D3@windriver.com> <465D54A8.9000100@isi.edu> <811BD121-1A79-45F4-B4E2-173729655CA9@windriver.com> In-Reply-To: <811BD121-1A79-45F4-B4E2-173729655CA9@windriver.com> X-Enigmail-Version: 0.95.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: c1c65599517f9ac32519d043c37c5336 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="===============0254926524==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0254926524== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1DF81FF34FA68F7D638EAAED" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1DF81FF34FA68F7D638EAAED Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable David Borman wrote: =2E.. >> I'm wondering whether there's a case where you could have started >> sending new TSvals, and you get a new data ACK (and start calculating >> RTTs), and then a packet comes in out of order (e.g., duplicated or >> SACK). Could this corrupt the RTT? Could this ever happen? >=20 > Besides being an ACK for new data, it also has to have a TSecr beyond > the initial timestamp you sent. By the time both of those things are > true, you should be into normal RFC-1323 processing. So two checks for every incoming packet, not just during 'sync', right? (just checking; that's not obvious to me from the description) Thanks, BTW, Joe --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enig1DF81FF34FA68F7D638EAAED 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 iD8DBQFGXbdSE5f5cImnZrsRAsxqAJ4nFZWN5VEZM4ivYPlgxv3R9a1PngCg7ICg 7vSWM03jveRoNKdLPvKw6WY= =We/I -----END PGP SIGNATURE----- --------------enig1DF81FF34FA68F7D638EAAED-- --===============0254926524== 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 --===============0254926524==-- From tcpm-bounces@ietf.org Wed May 30 15:02: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 1HtTQu-0001pO-Bf; Wed, 30 May 2007 15:02:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtTQs-0001pJ-Tr for tcpm@ietf.org; Wed, 30 May 2007 15:02:06 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtTQs-0001AC-G6 for tcpm@ietf.org; Wed, 30 May 2007 15:02:06 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 30 May 2007 12:02:06 -0700 X-IronPort-AV: i="4.14,594,1170662400"; d="scan'208"; a="156501578:sNHT73823823" 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 l4UJ25xE009204; Wed, 30 May 2007 12:02:05 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l4UJ25tV016260; Wed, 30 May 2007 19:02:05 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 12:02:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] Re: draft-ietf-tcpm-tcp-uto-05 Date: Wed, 30 May 2007 12:02:02 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC58036BF0B6@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <8F01E60D-5498-4A5A-A23C-03C615EC2A17@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Re: draft-ietf-tcpm-tcp-uto-05 Thread-Index: AceijNNKDAfTg4o3SpeqTAltJJPoSgAVkbzQ From: "Anantha Ramaiah \(ananth\)" To: "Lars Eggert" , =?iso-8859-1?Q?ext_Alfred_H=CEnes?= X-OriginalArrivalTime: 30 May 2007 19:02:05.0450 (UTC) FILETIME=[03969EA0:01C7A2ED] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4219; t=1180551725; x=1181415725; 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]=20Re=3A=20draft-ietf-tcpm-tcp-uto-05 |Sender:=20; bh=+3Yd9mg00WW4pA8AJCqbJV0TX8VhDW9zvlIgXlnCFG4=; b=iKya3xXfT5e+pMiEFpXa/tKTG+0luDx5I4LtkOllHKCNX957MVARwv37eQ7BJ4T88khAFb5c djThsibArJX6G08S6t/TlguF/rMZMGAn0wKuraiIplPGILVPHxjK216I; 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: 825e642946eda55cd9bc654a36dab8c2 Cc: tcpm@ietf.org, ext 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 =20 > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com]=20 > Sent: Wednesday, May 30, 2007 12:32 AM > To: ext Alfred H=CEnes > Cc: tcpm@ietf.org; ext Fernando Gont > Subject: [tcpm] Re: draft-ietf-tcpm-tcp-uto-05 >=20 > > (1) > > > > Yet, as an aid to implementors, I suggest to use more=20 > specific names=20 > > that can be easily carried over unchanged into=20 > implementations and/or=20 > > APIs without danger of name collisions; to be constructive,=20 > I suggest: > > > > ENABLED --> TCP_USE_UTO > > > > CHANGEABLE --> TCP_ACCEPT_UTO > > > > and, to achieve more generic naming, also: > > > > LOCAL_UTO --> TCP_LOCAL_UTO > > > > For the same reasons it might be useful to change the names of the=20 > > configuration variables in Section 3.1 as well, e.g.: > > > > U_LIMIT --> TCP_UTO_MAX > > > > L_LIMIT --> TCP_UTO_MIN >=20 > This has been suggested before, but I think it was in an=20 > off-list email. Hmm.. The current email, (I don't see Alfred's original email on the = list) is off-list as well :-) Anyways, I suggested the same thing which Alfred is mentioning above, = here is the snippet of the email exchange (actually the last one, which = hopefully captures the crux) :- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D BEGIN EMAIL EXCH. = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -----Original Message----- From: Anantha Ramaiah (ananth)=20 Sent: Wednesday, May 16, 2007 5:23 PM To: 'Fernando Gont'; mallman@icir.org Cc: Lars Eggert; Ted Faber Subject: RE: UTO draft.=20 Fernando, No sweat. Just leave it as it is. From what I recall, the variable = names weren't that long.. Anyways, I see that when you are writing the = equations, it might tend to get split up into 2 lines. Also Lar's point about TCP_USER_TIMEOUT is well taken as well..=20 -Anantha =20 > -----Original Message----- > From: Fernando Gont [mailto:fernando@gont.com.ar] > Sent: Tuesday, May 15, 2007 11:56 PM > To: mallman@icir.org; Anantha Ramaiah (ananth) > Cc: Lars Eggert; Ted Faber > Subject: Re: UTO draft.=20 >=20 > Hi All, >=20 > One of Anantha's comments suggested to precede all variables with the=20 > prefix "UTO_". I was meaning to commit the change. > But it turns out that it results in the names of the variables being=20 > terribly long, the recommended formula spanning more than one row,=20 > etc. >=20 > So, unless anybody feels strong about committing this change (please=20 > speak up), I will not commit it. >=20 > As pointed out by Lars, implementations are free to do this type of=20 > thing internally. (And, after all, TCP's timeout is not named=20 > "TCP_USER_TIMEOUT"... and the same is true for the name of virtually=20 > all variables/constants). >=20 > Thanks, >=20 > -- > Fernando Gont =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D END EMAIL EXCH. = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >=20 > Implementors are free to choose whatever variable names they=20 > like for their implementation - there is no expectation that=20 > these names will be used as-is. For example, RFC2581 and=20 > RFC2988 define similar state variables, for which=20 > implementations also choose different names. True.. But the point is to try to use some intuitive names, you don't = want to chose something slike X Y Z etc., I am not saying that you have = done so, simply trying to be argumentative since, IMO the above argument = does seem to make sense. :-) But your other points are well taken. >=20 > For this reason I'm unconvinced that renaming the state=20 > variables is necessary. (At the very least, I wouldn't want=20 > to add the "TCP_" =20 > prefix. If the WG thinks some of the other name changes=20 > clarify things, I could be convinced to go with it.) Sure that is a good plan of action, leave it to the consensus of the WG. = Anyways it is a minor thing, so no big deal, really. -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed May 30 16:56: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 1HtVDX-0002gP-95; Wed, 30 May 2007 16:56:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtVDV-0002gK-R8 for tcpm@ietf.org; Wed, 30 May 2007 16:56:25 -0400 Received: from mail.windriver.com ([147.11.1.11] helo=mail.wrs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtVDU-0003QL-Aa for tcpm@ietf.org; Wed, 30 May 2007 16:56:25 -0400 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id l4UKuMQO011422; Wed, 30 May 2007 13:56:22 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 13:56:22 -0700 Received: from [192.168.117.80] ([192.168.117.80]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 13:56:21 -0700 In-Reply-To: <465DB752.80900@isi.edu> References: <018977E8-C9F4-42E2-A877-95330F65E7D3@windriver.com> <465D54A8.9000100@isi.edu> <811BD121-1A79-45F4-B4E2-173729655CA9@windriver.com> <465DB752.80900@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] Re: RFC 1323: Timestamps option Date: Wed, 30 May 2007 15:56:19 -0500 To: Joe Touch X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 30 May 2007 20:56:21.0941 (UTC) FILETIME=[FA601E50:01C7A2FC] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 Hi Joe, On May 30, 2007, at 12:41 PM, Joe Touch wrote: > David Borman wrote: > ... >>> I'm wondering whether there's a case where you could have started >>> sending new TSvals, and you get a new data ACK (and start >>> calculating >>> RTTs), and then a packet comes in out of order (e.g., duplicated or >>> SACK). Could this corrupt the RTT? Could this ever happen? >> >> Besides being an ACK for new data, it also has to have a TSecr beyond >> the initial timestamp you sent. By the time both of those things are >> true, you should be into normal RFC-1323 processing. > > So two checks for every incoming packet, not just during 'sync', > right? > (just checking; that's not obvious to me from the description) Good question. That'll be part of coming up with a good description. The blind way of doing this is to just believe the TSecr value whenever it arrives in a packet that ACKs new data. You'll get some bad samples during the transition when Timestamps are being enabled, but they should be averaged out after a little bit. That might work ok most of the time, but that's not a good way to design a protocol; I'm looking for a deterministic way to enable timestamps mid-stream, and not get erroneous RTT measurements. One way to simplify things is to restrict enabling timestamp mid- stream to data packets only, and go ahead and always put in the correct TSval value. That means that the receiver in a one-way data transfer can't start sending timestamps. This solves the problem of having to validate the TSecr values for RTT measurement for one-way transfers, but it still leaves ambiguity in the case of a bi- directional transfer, if both sides decide to enable Timestamps at the same time. In that case, you can still construct scenarios where you get ACK only packets that acknowledge new data, and don't have a valid TSecr value. So, you have the same problem, how to identify whether or not the TSecr is valid for RTT measurement. Hence, I didn't propose restricting starting timestamps to data-only packets, and came up with an alternate way to identify invalid TSecr values. But even with the TSecr validation, I'm sure there are clever ways of doing implementations to avoid doing extra checks once Timestamps are started. I can some up with a few ideas myself. :-) If anyone has a better idea of how to identify the invalid TSecr values, I'm open to all suggestions. -David _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed May 30 17:13: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 1HtVUG-0002Sa-QX; Wed, 30 May 2007 17:13:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtVUF-0002SU-BH for tcpm@ietf.org; Wed, 30 May 2007 17:13:43 -0400 Received: from mail.windriver.com ([147.11.1.11] helo=mail.wrs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtVUD-0007Nz-UH for tcpm@ietf.org; Wed, 30 May 2007 17:13:43 -0400 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id l4ULDfhE015421; Wed, 30 May 2007 14:13:41 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 14:13:41 -0700 Received: from [192.168.117.80] ([192.168.117.80]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 14:13:41 -0700 In-Reply-To: References: <018977E8-C9F4-42E2-A877-95330F65E7D3@windriver.com> <465D54A8.9000100@isi.edu> <811BD121-1A79-45F4-B4E2-173729655CA9@windriver.com> 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] Re: RFC 1323: Timestamps option Date: Wed, 30 May 2007 16:13:38 -0500 To: Matt Mathis X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 30 May 2007 21:13:41.0186 (UTC) FILETIME=[65D05220:01C7A2FF] X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: TCP Maintenance and Minor Extensions WG , 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 Hi Matt, On May 30, 2007, at 10:59 AM, Matt Mathis wrote: > I had assumed that you can "fake" paws as follows: once you receive > a late > timestamp negotiation (in either role), you treat any later > untimestamped > segments as though they bear the timstamp just before the earliest > time stamp > seen. I believe that this is optimal, given other assumptions. Yes, for PAWS you only need the clock to tick at least once per sequence wrap, so as long as Timestamps are enabled before the first wrap, PAWS should work just fine this way. > > I think it also works well enough to treat any later untimestamped > segments as though they bear the timestamp just before the the most > recently > received timestamp. This is actually the same if the timestamps do > not > advance during the negotiation RTT. (Well enough means that the > failures > are neither frequent nor serious). The problem is, how do you tell that it is a "later untimestamped" segment, and not an old segment from before we enabled timestamps? This would allow old packets from before we enabled timestamps to arrive after the sequence wrap and be treated as OK, the very thing that PAWS is trying to prevent. That's one of the reasons why once you enable timestamps, you have to then include them in every packet for the duration of the connection. -David Borman _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed May 30 18: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 1HtWZe-0007uS-3S; Wed, 30 May 2007 18:23:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtWZc-0007uA-4w for tcpm@ietf.org; Wed, 30 May 2007 18:23:20 -0400 Received: from [2001:5e8:2:42:2e0:81ff:fe30:e898] (helo=mailer2.psc.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtWZZ-0000ho-S8 for tcpm@ietf.org; Wed, 30 May 2007 18:23:20 -0400 Received: from tesla.psc.edu (tesla.psc.edu [128.182.58.233]) by mailer2.psc.edu (8.13.8/8.13.3) with ESMTP id l4UMNHY2000214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 May 2007 18:23:17 -0400 (EDT) Received: from localhost.psc.edu (localhost.psc.edu [127.0.0.1]) by tesla.psc.edu (8.13.1/8.13.1) with ESMTP id l4UMNG19011407; Wed, 30 May 2007 18:23:17 -0400 Date: Wed, 30 May 2007 18:23:16 -0400 (EDT) From: Matt Mathis To: David Borman Subject: Re: [tcpm] Re: RFC 1323: Timestamps option In-Reply-To: Message-ID: References: <018977E8-C9F4-42E2-A877-95330F65E7D3@windriver.com> <465D54A8.9000100@isi.edu> <811BD121-1A79-45F4-B4E2-173729655CA9@windriver.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -2.8 (--) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: TCP Maintenance and Minor Extensions WG , 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 You are being more conservative than necessary: If I start out w/o timestamps, then I am assuming that I will be at low rate (or perhaps a short flow), and I don't need PAWS. I just need to be sure that PAWS is fully enabled before I would send the same sequence number within one MSL. As long as I meet this criteria, all prior segments are protected by either the MSL or as the "minus first" clock tick. Which raises another point, if I start without timestamps and just a few seconds later I am already 25% through the sequence space (think 10 Gigabit Ethernet), and I then try to turn on timestamps and the other end balks, what do I do? One answer would be to force the window down to RTT*4294967296/MSL, but people might think that is just a bit draconian. Furthermore, this solution has the nasty marketing problem that a correct highspeed stack is vastly slower than an incorrect implementation in some situations. Other suggestions? Ignore the problem? What happens today if you fail to request timestamps, and the path turns out to be a much faster than 100 Mb/s? Although permitting "late timestamps" has been on my todo list for years, I have come to think that a safer solution is to unconditionally request timestamps as long as the route of choice does not point to a directly connected compressing modem on a voice grade line. There are now several secondary control algorithms (such as the receiver side autotuning in Linux) that require timestamps for optimal operation, and thus provide motivation for (almost) unconditionally turning them on. Thanks, --MM-- ------------------------------------------- Matt Mathis http://www.psc.edu/~mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- Evil is defined by mortals who think they know "The Truth" and use force to apply it to others. On Wed, 30 May 2007, David Borman wrote: > Hi Matt, > > On May 30, 2007, at 10:59 AM, Matt Mathis wrote: > > > I had assumed that you can "fake" paws as follows: once you receive > > a late > > timestamp negotiation (in either role), you treat any later > > untimestamped > > segments as though they bear the timstamp just before the earliest > > time stamp > > seen. I believe that this is optimal, given other assumptions. > > Yes, for PAWS you only need the clock to tick at least once per > sequence wrap, so as long as Timestamps are enabled before the first > wrap, PAWS should work just fine this way. > > > > > I think it also works well enough to treat any later untimestamped > > segments as though they bear the timestamp just before the the most > > recently > > received timestamp. This is actually the same if the timestamps do > > not > > advance during the negotiation RTT. (Well enough means that the > > failures > > are neither frequent nor serious). > > The problem is, how do you tell that it is a "later untimestamped" > segment, and not an old segment from before we enabled timestamps? > This would allow old packets from before we enabled timestamps to > arrive after the sequence wrap and be treated as OK, the very thing > that PAWS is trying to prevent. That's one of the reasons why once > you enable timestamps, you have to then include them in every packet > for the duration of the connection. > > -David Borman > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed May 30 18:50: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 1HtX02-0006H1-Uq; Wed, 30 May 2007 18:50:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtWzx-00067P-NM; Wed, 30 May 2007 18:50:33 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HtWzw-0007J8-Di; Wed, 30 May 2007 18:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 4872E2AC8F; Wed, 30 May 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HtWzS-0002Sv-1B; Wed, 30 May 2007 18: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: Wed, 30 May 2007 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-syn-flood-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 SYN Flooding Attacks and Common Mitigations Author(s) : W. Eddy Filename : draft-ietf-tcpm-syn-flood-05.txt Pages : 24 Date : 2007-5-30 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-syn-flood-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-syn-flood-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-syn-flood-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-5-30154540.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-syn-flood-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-syn-flood-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-30154540.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 May 31 10:07: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 1HtlIw-0001Cm-Vk; Thu, 31 May 2007 10:07:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtlIt-0001BY-NG; Thu, 31 May 2007 10:07:03 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtlIr-0005MP-1R; Thu, 31 May 2007 10:07:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 03D9F3289D; Thu, 31 May 2007 14:07:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HtlIq-0001bD-To; Thu, 31 May 2007 10:07:00 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Thu, 31 May 2007 10:07:00 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: tcpm chair , tcpm mailing list , Internet Architecture Board , RFC Editor Subject: [tcpm] Document Action: 'TCP SYN Flooding Attacks and Common Mitigations' to Informational RFC 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 IESG has approved the following document: - 'TCP SYN Flooding Attacks and Common Mitigations ' as an Informational RFC This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-syn-flood-05.txt Technical Summary 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. Working Group Summary The consensus within the TCPM WG to publish this document as an informational RFC is strong. Protocol Quality This document details several techniques that have been used in TCP implementations for many years. The technology discussed in this document is not new, but rather this document is helping the RFC-series "catch up" with common practice and details experience with several mechanisms. Personnel The document shepherd for this document is Mark Allman (TCPM co-chair). The responsible AD is Lars Eggert. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu May 31 10:51: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 1Htm0H-0001Xh-69; Thu, 31 May 2007 10:51:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htm0E-0001Wc-LX; Thu, 31 May 2007 10:51:50 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htm0C-0004nT-PY; Thu, 31 May 2007 10:51:49 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4VEpSH7006493; Thu, 31 May 2007 17:51:29 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 May 2007 17:51:16 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 May 2007 17:51:16 +0300 Received: from [172.21.36.45] (esdhcp03645.research.nokia.com [172.21.36.45]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4VEpE28015773; Thu, 31 May 2007 17:51:15 +0300 In-Reply-To: <200702111621.l1BGL6mw029875@venus.xmundo.net> References: <200702111621.l1BGL6mw029875@venus.xmundo.net> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <0E46EBE9-1C13-44B6-9C04-476D418F5A6D@nokia.com> From: Lars Eggert Subject: Re: [tcpm] Revision of draft-larsen-tsvwg-port-randomization Date: Thu, 31 May 2007 17:51:05 +0300 To: ext Fernando Gont X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 31 May 2007 14:51:16.0687 (UTC) FILETIME=[243D5DF0:01C7A393] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: tcpm@ietf.org, tsvwg 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="===============1257672907==" Errors-To: tcpm-bounces@ietf.org --===============1257672907== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-69-452402891; protocol="application/pkcs7-signature" --Apple-Mail-69-452402891 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-2-11, at 17:56, ext Fernando Gont wrote: > We have published a revision of the port randomization draft > (draft-larsen-tsvwg-port-randomization). This version addresses > feedback from Alfred Hoenes and Carlos Pignataro, and comments from > FreeBSD's Mike Silbersack. The draft is targetted at tsvwg because > the same stuff can be applied to other protocols. But most (all?) of > the work on this has been done mainly for TCP. The update is at http://tools.ietf.org/html/draft-larsen-tsvwg-port- randomization. The concepts in this draft are likely relevant to most of our transport protocols, and hence would be in scope for TSVWG. The TSVWG chairs are interested in comments on whether there is group interest in this draft - please comment on tsvwg@ietf.org. Lars --Apple-Mail-69-452402891 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 MBwGCSqGSIb3DQEJBTEPFw0wNzA1MzExNDUxMDZaMCMGCSqGSIb3DQEJBDEWBBR8pY/VfZqFA/f1 StGmQ5qGytIrRjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAmDETjA3GEhNvw+T8uUv4V1FM9wGhYinLXxLXuztZFh0I9/XBGJ2P fDcKN2tb0bHM9Q1AG01iNtV2b+iILcIE/uQp2L1iFhMnbY4S2rfK/n9PwnUpS+YxiRwJB/loDWDU uCt48HzRGLwN0sXu/N+KDTNJPl3vdePYEDG8chipUNgfioWqWeKr70dpvczNtLPGHoCL4LLogz2p h+DhYhtxeDbWZ6VSA4Xp9AhFBFS+isNujdh+j1yIqxRgxAFxY1J0I2Nu8MWQeZgHEwcCJvxln5Mw qECqG9SCaVMxp5EVxa5iuOTbxRMk2vhDYLWPQIY0M4vMk7wsOwGUE88b6gVF0QAAAAAAAA== --Apple-Mail-69-452402891-- --===============1257672907== 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 --===============1257672907==-- From tcpm-bounces@ietf.org Thu May 31 15:59: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 1HtqnV-0001gU-6E; Thu, 31 May 2007 15:59:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtqnU-0001gL-Lq for tcpm@ietf.org; Thu, 31 May 2007 15:59:00 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtqnS-0006l7-8r for tcpm@ietf.org; Thu, 31 May 2007 15:59:00 -0400 Received: from [127.0.0.1] (85.sub-70-198-147.myvzw.com [70.198.147.85]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l4VJwe2W017746; Thu, 31 May 2007 12:58:43 -0700 (PDT) Message-ID: <465F28D9.3060604@isi.edu> Date: Thu, 31 May 2007 12:58:17 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Matt Mathis Subject: Re: [tcpm] Re: RFC 1323: Timestamps option References: <018977E8-C9F4-42E2-A877-95330F65E7D3@windriver.com> <465D54A8.9000100@isi.edu> <811BD121-1A79-45F4-B4E2-173729655CA9@windriver.com> In-Reply-To: X-Enigmail-Version: 0.95.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: 21c69d3cfc2dd19218717dbe1d974352 Cc: TCP Maintenance and Minor Extensions WG , David Borman 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="===============0005124343==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0005124343== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7A1B3B8498C18E000DECA819" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7A1B3B8498C18E000DECA819 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Matt Mathis wrote: =2E.. > Although permitting "late timestamps" has been on my todo list for year= s, Not so much for me... > I > have come to think that a safer solution is to unconditionally request > timestamps as long as the route of choice does not point to a directly > connected compressing modem on a voice grade line.=20 I agree with this, though ;-) Joe --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enig7A1B3B8498C18E000DECA819 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 iD8DBQFGXyjZE5f5cImnZrsRAkqeAKDORiqFq9MMKgakEdsNc1oMNOK1uQCg/Z7p bYI0svnVdOpkgjVn7e29Ea4= =Pa38 -----END PGP SIGNATURE----- --------------enig7A1B3B8498C18E000DECA819-- --===============0005124343== 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 --===============0005124343==--