From tcpm-bounces@ietf.org Wed Oct 04 11:40:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV8qr-0008KU-To; Wed, 04 Oct 2006 11:40:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV8qq-0008GJ-Ep; Wed, 04 Oct 2006 11:40:04 -0400 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV8qp-0000A7-3P; Wed, 04 Oct 2006 11:40:04 -0400 Received: from localhost (localhost.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 459FE200C93F; Wed, 4 Oct 2006 17:40:29 +0200 (CEST) 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 19521-02; Wed, 4 Oct 2006 17:40:29 +0200 (CEST) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 3343B20031EF; Wed, 4 Oct 2006 17:40:29 +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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Oct 2006 17:39:59 +0200 Message-ID: <113091BD57179D4491C19DA7E10CD6962293BA@mx1.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-schuetz-tcpm-tcp-rlci-00.txt Thread-Index: AcaFvwCjLyPg7NxXR2yqaMhwRUPAXAEV7gyQF2zayrA= From: "Simon Schuetz" To: , , X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [tcpm] FW: I-D ACTION:draft-schuetz-tcpm-tcp-rlci-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org > Title: TCP Response to Lower-Layer Connectivity-Change Indications > Author(s) : S. Schuetz, et al. > Filename : draft-schuetz-tcpm-tcp-rlci-00.txt Hi, The above mentioned draft was presented to TCPM WG at the last IETF meeting. We haven't received feedback yet and would like to ask the working groups to review and comment on the current version. http://www.ietf.org/internet-drafts/draft-schuetz-tcpm-tcp-rlci-00.txt Although posted to multiple working groups, we'd like to keep the main discussion on the tcpm mailing list. Thanks, Simon _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Oct 07 08:46:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWBYT-0003HF-68; Sat, 07 Oct 2006 08:45:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWBYR-0003Fr-Ch for tcpm@ietf.org; Sat, 07 Oct 2006 08:45:23 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWBYO-00082K-U0 for tcpm@ietf.org; Sat, 07 Oct 2006 08:45:23 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id EDF1FF0C49E for ; Sat, 7 Oct 2006 09:50:50 -0300 (ART) Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k97CiAYt016615 for ; Sat, 7 Oct 2006 09:45:01 -0300 Message-Id: <7.0.1.0.0.20061007035411.04dc8780@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 07 Oct 2006 04:02:49 -0300 To: tcpm@ietf.org From: Fernando Gont Subject: Sally Floyd: Fwd: Re: [tcpm] TCP soft errors draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Folks, FYI, it seems this one did not appear on the list. >X-ClientAddr: 17.250.248.171 >Cc: tcpm@ietf.org >From: Sally Floyd >Subject: Re: [tcpm] TCP soft errors draft >Date: Tue, 3 Oct 2006 10:17:03 -0700 >To: Fernando Gont >X-Mailer: Apple Mail (2.624) > >>Last month I posted a revision of the "TCP's reaction to soft >>errors" draft. The revised draft addresses the feedback from Ron >>Bonica (which had agreed at the 65th IETF to review the draft). >> >>I'd appreciate any input on this last revision. > >I don't have any feedback on the response to ICMP "Destination >Unreachable" messages discussed in this draft, but I do have >some other small feedback. > >In Section 2.1 on "Reaction to Hard Errors", the draft says the following: > > "When receiving a segment with the RST bit set, or an ICMP error > message indicating a hard error condition, TCP will simply abort the > corresponding connection, regardless of the state the connection is > in." > >However, it can be more complicated than that. For example, >Section 6.1.1.1 of RFC 3168 (ECN) says the following: > > "To provide robust connectivity even in the presence of such faulty > equipment, a host that receives a RST in response to the transmission > of an ECN-setup SYN packet MAY resend a SYN with CWR and ECE cleared. > This could result in a TCP connection being established without using > ECN." > > "A host that receives no reply to an ECN-setup SYN within the normal > SYN retransmission timeout interval MAY resend the SYN and any > subsequent SYN retransmissions with CWR and ECE cleared." > >This is explained further in RFC 3360 on "Inappropriate TCP Resets Considered >Harmful". Thus, even "hard errors" are not always straightforward these days. > >- Sally >http://www.icir.org/floyd/ -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Oct 07 08:46:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWBYR-0003G1-R3; Sat, 07 Oct 2006 08:45:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWBYQ-0003Fc-Cy for tcpm@ietf.org; Sat, 07 Oct 2006 08:45:22 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWBYO-00082d-U0 for tcpm@ietf.org; Sat, 07 Oct 2006 08:45:22 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 5C8CEF0C494; Sat, 7 Oct 2006 09:50:54 -0300 (ART) Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k97CiAYx016615; Sat, 7 Oct 2006 09:45:04 -0300 Message-Id: <7.0.1.0.0.20061007042611.04dc8780@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 07 Oct 2006 04:36:54 -0300 To: gorry@erg.abdn.ac.uk From: Fernando Gont Subject: Re: [tcpm] draft-ietf-tcpm-tcp-uto-02 In-Reply-To: <451C36FF.3000801@erg.abdn.ac.uk> References: <6.2.0.14.0.20051201035418.0323fc48@localhost> <4390569C.6050004@erg.abdn.ac.uk> <6.2.0.14.0.20051202201002.048b5de8@localhost> <20051208222808.GB22920@hut.isi.edu> <6.2.0.14.0.20051208164304.041ead70@localhost> <20051209182531.GC1177@hut.isi.edu> <439D7400.20902@erg.abdn.ac.uk> <20051212235603.GB1156@hut.isi.edu> <6.2.0.14.0.20051213012758.048ed298@localhost> <43A02978.4020809@erg.abdn.ac.uk> <45116707.9050301@erg.abdn.ac.uk> <7.0.1.0.0.20060920170030.05da7c80@gont.com.ar> <4519586D.1080509@erg.abdn.ac.uk> <7.0.1.0.0.20060927230203.08077e98@gont.com.ar> <451C36FF.3000801@erg.abdn.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Lars Eggert , tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 17:56 28/09/2006, Gorry Fairhurst wrote: >So... just to backtrack to an earlier discussion on this: Using the >recommended algorithm you say" Consequently, the lower limit >(L_LIMIT) SHOULD be set to at least 100 seconds." Is there a reason >why we don't specify a required minimum UTO value for all cases? A >value of 100 seconds seems big for an RTO, over a normal Internet path. How about this modification to the last paragraph of page 6: " To protect against these effects, implementations MUST impose limits on the user timeout values they accept and use. In particular, the adopted user timeout MUST be larger than the last measured retransmission timeout (RTO) at the time of adoption, and SHOULD NOT be smaller than 100 seconds." 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 Sat Oct 07 08:46:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWBYT-0003Go-0T; Sat, 07 Oct 2006 08:45:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWBYR-0003Fm-Ak for tcpm@ietf.org; Sat, 07 Oct 2006 08:45:23 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWBYP-00082M-TW for tcpm@ietf.org; Sat, 07 Oct 2006 08:45:23 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id D5FBEF0C4A6; Sat, 7 Oct 2006 09:50:51 -0300 (ART) Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k97CiAYv016615; Sat, 7 Oct 2006 09:45:02 -0300 Message-Id: <7.0.1.0.0.20061007035908.06278c28@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 07 Oct 2006 04:13:23 -0300 To: Sally Floyd From: Fernando Gont Subject: Re: [tcpm] TCP soft errors draft In-Reply-To: <4cbdcb4bd7a0a8b8b71df57c293f0f27@mac.com> References: <7.0.1.0.0.20060922095541.07838cf8@gont.com.ar> <4cbdcb4bd7a0a8b8b71df57c293f0f27@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 14:17 03/10/2006, Sally Floyd wrote: >However, it can be more complicated than that. For example, >Section 6.1.1.1 of RFC 3168 (ECN) says the following: > > "To provide robust connectivity even in the presence of such faulty > equipment, a host that receives a RST in response to the transmission > of an ECN-setup SYN packet MAY resend a SYN with CWR and ECE cleared. > This could result in a TCP connection being established without using > ECN." > > "A host that receives no reply to an ECN-setup SYN within the normal > SYN retransmission timeout interval MAY resend the SYN and any > subsequent SYN retransmissions with CWR and ECE cleared." > >This is explained further in RFC 3360 on "Inappropriate TCP Resets Considered >Harmful". Thus, even "hard errors" are not always straightforward these days. Do you suggest to address this in the draft? Or maybe the draft could just limit to handling of ICMP error messages? Originally, the draft did not mention the handling of RST segments. However, in some later revision the RST-related text (less than a line) was included "for completeness sake", I guess. My take is that removing that line (rather than adding text on other ways an RST could be handled) will keep the draft simple. (One could also add that there are some systems that do not abort (not yet established) connections upon receipt of RSTs, as they could be an indication of a listening queue being full, rather than a TCP port being closed or some other hard error condition) Thoughts? 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 Sat Oct 07 08:46:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWBYR-0003Fw-M0; Sat, 07 Oct 2006 08:45:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWBYQ-0003Fd-Cy for tcpm@ietf.org; Sat, 07 Oct 2006 08:45:22 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWBYO-00082y-Tz for tcpm@ietf.org; Sat, 07 Oct 2006 08:45:22 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 87D85F0C493; Sat, 7 Oct 2006 09:50:55 -0300 (ART) Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k97CiAZ1016615; Sat, 7 Oct 2006 09:45:06 -0300 Message-Id: <7.0.1.0.0.20061007051245.06116328@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 07 Oct 2006 05:15:15 -0300 To: "Caitlin Bestler" , gorry@erg.abdn.ac.uk From: Fernando Gont Subject: RE: [tcpm] UTO: SHOULD send option in first segment after the SYN? In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F1A315F2@NT-SJCA-0751.brcm.a d.broadcom.com> References: <451C347D.3030200@erg.abdn.ac.uk> <54AD0F12E08D1541B826BE97C98F99F1A315F2@NT-SJCA-0751.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 18:10 28/09/2006, Caitlin Bestler wrote: > > A host that supports the TCP User Timeout Option SHOULD include one > > in each packet that carries a SYN flag, but need not. [MEDINA] has > > shown that unknown options are correctly handled by the vast [....] >Given that there is no need to pre-validate support for UTO, and that >the suggestion UTO value may be ignored on a SYN, I think placing the >initial UTO value on the first data carrying packet makes more sense. Do you suggest to replace the "SHOULD include one in each packet that carries a SYN flag", or rather suggest to include an *additional* "SHOULD" for including the option in the first data 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 Sat Oct 07 08:46:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWBYT-0003Go-0T; Sat, 07 Oct 2006 08:45:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWBYR-0003Fm-Ak for tcpm@ietf.org; Sat, 07 Oct 2006 08:45:23 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWBYP-00082M-TW for tcpm@ietf.org; Sat, 07 Oct 2006 08:45:23 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id D5FBEF0C4A6; Sat, 7 Oct 2006 09:50:51 -0300 (ART) Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k97CiAYv016615; Sat, 7 Oct 2006 09:45:02 -0300 Message-Id: <7.0.1.0.0.20061007035908.06278c28@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 07 Oct 2006 04:13:23 -0300 To: Sally Floyd From: Fernando Gont Subject: Re: [tcpm] TCP soft errors draft In-Reply-To: <4cbdcb4bd7a0a8b8b71df57c293f0f27@mac.com> References: <7.0.1.0.0.20060922095541.07838cf8@gont.com.ar> <4cbdcb4bd7a0a8b8b71df57c293f0f27@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 14:17 03/10/2006, Sally Floyd wrote: >However, it can be more complicated than that. For example, >Section 6.1.1.1 of RFC 3168 (ECN) says the following: > > "To provide robust connectivity even in the presence of such faulty > equipment, a host that receives a RST in response to the transmission > of an ECN-setup SYN packet MAY resend a SYN with CWR and ECE cleared. > This could result in a TCP connection being established without using > ECN." > > "A host that receives no reply to an ECN-setup SYN within the normal > SYN retransmission timeout interval MAY resend the SYN and any > subsequent SYN retransmissions with CWR and ECE cleared." > >This is explained further in RFC 3360 on "Inappropriate TCP Resets Considered >Harmful". Thus, even "hard errors" are not always straightforward these days. Do you suggest to address this in the draft? Or maybe the draft could just limit to handling of ICMP error messages? Originally, the draft did not mention the handling of RST segments. However, in some later revision the RST-related text (less than a line) was included "for completeness sake", I guess. My take is that removing that line (rather than adding text on other ways an RST could be handled) will keep the draft simple. (One could also add that there are some systems that do not abort (not yet established) connections upon receipt of RSTs, as they could be an indication of a listening queue being full, rather than a TCP port being closed or some other hard error condition) Thoughts? 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 Sat Oct 07 08:46:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWBYR-0003Fw-M0; Sat, 07 Oct 2006 08:45:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWBYQ-0003Fd-Cy for tcpm@ietf.org; Sat, 07 Oct 2006 08:45:22 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWBYO-00082y-Tz for tcpm@ietf.org; Sat, 07 Oct 2006 08:45:22 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 87D85F0C493; Sat, 7 Oct 2006 09:50:55 -0300 (ART) Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k97CiAZ1016615; Sat, 7 Oct 2006 09:45:06 -0300 Message-Id: <7.0.1.0.0.20061007051245.06116328@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 07 Oct 2006 05:15:15 -0300 To: "Caitlin Bestler" , gorry@erg.abdn.ac.uk From: Fernando Gont Subject: RE: [tcpm] UTO: SHOULD send option in first segment after the SYN? In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F1A315F2@NT-SJCA-0751.brcm.a d.broadcom.com> References: <451C347D.3030200@erg.abdn.ac.uk> <54AD0F12E08D1541B826BE97C98F99F1A315F2@NT-SJCA-0751.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 18:10 28/09/2006, Caitlin Bestler wrote: > > A host that supports the TCP User Timeout Option SHOULD include one > > in each packet that carries a SYN flag, but need not. [MEDINA] has > > shown that unknown options are correctly handled by the vast [....] >Given that there is no need to pre-validate support for UTO, and that >the suggestion UTO value may be ignored on a SYN, I think placing the >initial UTO value on the first data carrying packet makes more sense. Do you suggest to replace the "SHOULD include one in each packet that carries a SYN flag", or rather suggest to include an *additional* "SHOULD" for including the option in the first data 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 Mon Oct 09 02:49:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWowB-0001Ff-3r; Mon, 09 Oct 2006 02:48:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWow9-00019t-UO for tcpm@ietf.org; Mon, 09 Oct 2006 02:48:29 -0400 Received: from s-utl01-ffpop.stsn.net ([62.50.216.201]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GWow7-0007vC-LX for tcpm@ietf.org; Mon, 09 Oct 2006 02:48:29 -0400 Received: from s-utl01-ffpop.stsn.net ([127.0.0.1]) by s-utl01-ffpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2006100908481114047 ; Mon, 09 Oct 2006 08:48:11 +0200 X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.4 X-Spam-Level: Received: from [10.105.227.18] ([10.105.227.18]) by s-utl01-ffpop.stsn.net; Mon, 9 Oct 2006 08:48:10 +0200 In-Reply-To: <7.0.1.0.0.20061007035908.06278c28@gont.com.ar> References: <7.0.1.0.0.20060922095541.07838cf8@gont.com.ar> <4cbdcb4bd7a0a8b8b71df57c293f0f27@mac.com> <7.0.1.0.0.20061007035908.06278c28@gont.com.ar> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8aa3fbdb056528087e44884cc39615fb@mac.com> Content-Transfer-Encoding: 7bit From: Sally Floyd Subject: Re: [tcpm] TCP soft errors draft Date: Sun, 8 Oct 2006 23:48:03 -0700 To: Fernando Gont X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org > Do you suggest to address this in the draft? Or maybe the draft could > just limit to handling of ICMP error messages? Sorry, I wasn't suggesting that you add this to the draft. Just that you delete or rephrase the sentences that say that hard errors like Resets are simple and merit a simple response from TCP... - 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 Oct 09 09:01:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWukm-0008BA-2z; Mon, 09 Oct 2006 09:01:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWukk-0008B4-Ml for tcpm@ietf.org; Mon, 09 Oct 2006 09:01:06 -0400 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWukj-0007c5-3t for tcpm@ietf.org; Mon, 09 Oct 2006 09:01:06 -0400 Received: from localhost (localhost.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 1846B200C974; Mon, 9 Oct 2006 15:01:34 +0200 (CEST) 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 16033-10; Mon, 9 Oct 2006 15:01:33 +0200 (CEST) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id BAE90200C96F; Mon, 9 Oct 2006 15:01:33 +0200 (CEST) Received: from n-eggert.office ([10.1.1.112]) by mx1.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Oct 2006 15:01:04 +0200 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n-eggert.office (Postfix) with ESMTP id 23B742472D1; Mon, 9 Oct 2006 15:01:03 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.2) References: <026F8EEDAD2C4342A993203088C1FC0503A1058E@esealmw109.eemea.ericsson.se> Message-Id: <29813233-229C-457F-96B3-834BFC7A4D8B@netlab.nec.de> From: Lars Eggert Date: Mon, 9 Oct 2006 15:01:01 +0200 To: tcpm@ietf.org X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 09 Oct 2006 13:01:04.0104 (UTC) FILETIME=[FA2BC680:01C6EBA2] X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: "Lars-Erik Jonsson \(LU/EAB\)" Subject: [tcpm] Fwd: [rohc] Second WG last-call on ROHC TCP and ROHC Formal Notation 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="===============1330522534==" Errors-To: tcpm-bounces@ietf.org --===============1330522534== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-28--444448171; protocol="application/pkcs7-signature" --Apple-Mail-28--444448171 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Earlier versions of this draft have gotten review in TCPM; it would be good if TCPM could take a final look at the current version during its WGLC in ROHC. Begin forwarded message: > From: "Lars-Erik Jonsson (LU/EAB)" > Date: October 9, 2006 12:37:41 PM GMT+02:00 > To: > Subject: [rohc] Second WG last-call on ROHC TCP and ROHC Formal > Notation > > ROHCers, > > The first WG last-call on these documents ended on August 26, 2005. > There were several comments and questions received, and although > not very technically complex, these comments led to significant > reformulations of both the Formal Notation and the TCP compression > scheme itself. This work has been given time to mature, and now we > believe these drafts are ready for publication. Therefore, we are > now last-calling: > > draft-ietf-rohc-tcp-13.txt > draft-ietf-rohc-formal-notation-11.txt > (for publication as Proposed Standard) > > This will be the usual two-week WG last-call as suggested in > RFC2418, so please direct last-call comments to the ROHC mailing > list rohc@ietf.org before Mon, 2006-10-23, 18:00 UTC. > > /L-E > > -------------------------------------- > Lars-Erik Jonsson > IETF ROHC WG Chair > E-mail: lars-erik.jonsson@ericsson.com > Phone: +46 8 404 29 61 > > My opinions are my personal opinions and should not be considered > as the opinions of my employer, if not explicitly stated. > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc Lars -- Lars Eggert NEC Network Laboratories --Apple-Mail-28--444448171 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKZDCCAwEw ggJqoAMCAQICEBCR/semQl5bz/x3jtiU02YwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgxNjA5MTU0NloXDTA3MDgxNjA5MTU0 NlowYDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAL/+LXyqufw8ApYnCU24cnZ/H9S7ro4zZYeCqcyFqhwJpTcM8/yX 6Ms+16d2EtIceQS8Bas3GAUR+xfq0QI5dt8uIKM1Uy4trk8AAO0dh23+QTLw7toloArVngGIhUhC OTpVRR1bYfJTwPVpSAY43mbGhSGhwiu5035yKdYJezNWOXmuIO+lvXcD36hc5cU6AzRJkj0LYaFd WHjbfwzGmT7MO60p/7hT+aTv5xvTl/mcwslvm+KhKmJjoMYfSOF99xvuJE/rB7Ho3g6wDoeB2Tip 44Qq8CPmOHtCXzh/tF/bYo+OHStkPTzgPfOuNDMxa0/gAPEyELNL0Eh1/hC2TeMCAwEAAaM2MDQw JAYDVR0RBB0wG4EZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAHdaTI5TM5wV+LG2WW+CMEmxEyNhaRu3oca9T31HjbfHzvhVJe2fzKt1xBSo +hhCg0qKVFuE7yKxDH975Csq9jVvJJj3oL29RQjPnc3CgQqlMFJKHdJgterPQ+ZiCp05S9rbMhRl 1zxB/x+GvnDFHsXu19gA2dlynrdWN/G1BVWJMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBU b3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSsw KQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAw MFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7s vc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV 84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGR MBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCk HjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oL LswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoL gnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzCCBBgwggOBoAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwgb8xCzAJBgNVBAYTAkRFMRww GgYDVQQIFBNCYWRlbi1Xw3VlcnR0ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQK Ew5ORUMgRXVyb3BlIEx0ZDEdMBsGA1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMT EmtvYmUubmV0bGFiLm5lYy5kZTEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5l Yy5kZTAeFw0wNDA2MTgxMTUzMDhaFw0wOTA2MTcxMTUzMDhaMIG/MQswCQYDVQQGEwJERTEcMBoG A1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMO TkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJr b2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMu ZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALQ5DCwTzpGu3RmzQY4KxiaQak/BwIW9Wk6K Mg+/V0aiWvlrz7uFdICBGVTKhyWr3F+GxRPCVTWqS9VEPf9A59DI9TFCS3FtraSx+w8ApQei8idb J0Lqu8tTz2O1gYR2dELID5wQH9dxIANt3bP39crgDZzGYxCJilcimFhADEgHAgMBAAGjggEgMIIB HDAdBgNVHQ4EFgQU6Hsv16oYecCFsl07g9gtjPEJo00wgewGA1UdIwSB5DCB4YAU6Hsv16oYecCF sl07g9gtjPEJo02hgcWkgcIwgb8xCzAJBgNVBAYTAkRFMRwwGgYDVQQIFBNCYWRlbi1Xw3VlcnR0 ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQKEw5ORUMgRXVyb3BlIEx0ZDEdMBsG A1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMTEmtvYmUubmV0bGFiLm5lYy5kZTEo MCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZYIBADAMBgNVHRMEBTADAQH/ MA0GCSqGSIb3DQEBBQUAA4GBAJfoil3cAX3cUPMFrDdlW9DPMK/+QY8EHPOsnefm77h5CmmY6J+G 5Ydl9vyHxL76Opyg8cZWOOU/k9oVv7AvQ1GmIFqVFyWKQPfEhj+EWjEnUAcI7QDN8XER+U7XRvj6 yYysFgm2Tl30QCGvmESCgYIztCKMG2cLBkEosj2kWBbXMYIDsjCCA64CAQEwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBCR/semQl5bz/x3jtiU02YwCQYFKw4D AhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMDA5 MTMwMTAyWjAjBgkqhkiG9w0BCQQxFgQU/y2xwA/g3KwOBeag/ynK6D4DMOIwgdYGCSsGAQQBgjcQ BDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzAR BgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3 b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsqhkiG9w0BCRACCzGByKCBxTCB vzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhl aWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9y YXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJz LmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUABIIBAKvyT831E8vnxwSxsHRI KLUWZ9A7PxozI1xuROdrcOgbf8f9RHWsEHvEW3i+Det28XtPE252Ah6no62oa/tHcZuuLC1MJOYI GWWsZYJ+kTz6uXmyKvbJnD7FtiGb+/BknqkCkAbPvXHFN4500U7FpL4wcHRZwpZb2Q4rnrmNW6iF LWDUeKWI81uCOIDf7qW2AMLbhzln+xaPJdVwhczXhR7hqArGvKSJn5Vb3eUeRiKcZ7gn2efWPLrg /m7nJizd4hOFosL6+yb3vAZ+b0QIWUb4aySDjVnzf1Ve2s4hpw9e/svuVmna6OPKwJey+2Oxlf2h atLreVMkEhaObDwrhH4AAAAAAAA= --Apple-Mail-28--444448171-- --===============1330522534== 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 --===============1330522534==-- From tcpm-bounces@ietf.org Mon Oct 09 12:16:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWxn9-0008NP-4u; Mon, 09 Oct 2006 12:15:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWxkP-0006Zo-6w for tcpm@ietf.org; Mon, 09 Oct 2006 12:12:57 -0400 Received: from mms2.broadcom.com ([216.31.210.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWxXk-0007K5-UV for tcpm@ietf.org; Mon, 09 Oct 2006 11:59:55 -0400 Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.2)); Mon, 09 Oct 2006 08:59:42 -0700 X-Server-Uuid: 79DB55DB-3CB4-423E-BEDB-D0F268247E63 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 9D9762B0; Mon, 9 Oct 2006 08:59:42 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 5E74E2AE; Mon, 9 Oct 2006 08:59:42 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EHB65206; Mon, 9 Oct 2006 08:59:35 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id E68FE20503; Mon, 9 Oct 2006 08:59:34 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] UTO: SHOULD send option in first segment after the SYN? Date: Mon, 9 Oct 2006 08:59:26 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1A31DF8@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <7.0.1.0.0.20061007051245.06116328@gont.com.ar> Thread-Topic: [tcpm] UTO: SHOULD send option in first segment after the SYN? Thread-Index: AcbqDnEMtdN4KQUlS8KRuIn55m1W2ABrI2Ew From: "Caitlin Bestler" To: "Fernando Gont" , gorry@erg.abdn.ac.uk X-TMWD-Spam-Summary: TS=20061009155943; SEV=2.0.2; DFV=A2006100906; IFV=2.0.4,4.0-8; RPD=4.00.0004; ENG=IBF; RPDID=303030312E30413031303230322E34353241373138422E303038442D412D; CAT=NONE; CON=NONE X-MMS-Spam-Filter-ID: A2006100906_4.00.0004_4.0-8 X-WSS-ID: 6934AE642I02715066-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Fernando Gont wrote: > At 18:10 28/09/2006, Caitlin Bestler wrote: >=20 >>> A host that supports the TCP User Timeout Option SHOULD include >>> one in each packet that carries a SYN flag, but need not. >>> [MEDINA] has shown that unknown options are correctly handled by >>> the vast [....]=20 >=20 >> Given that there is no need to pre-validate support for UTO, and that >> the suggestion UTO value may be ignored on a SYN, I think placing the >> initial UTO value on the first data carrying packet makes more sense. >=20 > Do you suggest to replace the "SHOULD include one in each > packet that carries a SYN flag", or rather suggest to include > an *additional* "SHOULD" for including the option in the first data > segment?=20 >=20 > Kindest regards, Many SYN-Cookie or similar strategies are only activated when the passive side suspects that it might be under attack. Such systems might do initial allocations based on the SYN alone. Therefore including the initial UTO on *both* the SYN and the next segment makes sense. I can't think of any real harm in sending both. Assuming that the connection is actually going to be open long enough to have justified sending a UTO the "wasted" bandwidth is miniscule. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Oct 09 15:52:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX1A8-0002Cr-Kv; Mon, 09 Oct 2006 15:51:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX19U-00011Y-UM; Mon, 09 Oct 2006 15:51:04 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX19U-0005oy-Qw; Mon, 09 Oct 2006 15:51:04 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GX19U-0004Tb-HJ; Mon, 09 Oct 2006 15:51:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id DD2512AC76; Mon, 9 Oct 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GX18U-0007Rm-L2; Mon, 09 Oct 2006 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, 09 Oct 2006 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-tcp-soft-errors-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : TCP's Reaction to Soft Errors Author(s) : F. Gont Filename : draft-ietf-tcpm-tcp-soft-errors-02.txt Pages : 14 Date : 2006-10-9 This document discusses the problem of long delays between connection establishment attempts that may arise in a number of scenarios, including one in which dual stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments. Additionally, this document describes a modification to TCP's reaction to soft errors that has been implemented in a variety of TCP/IP stacks to help overcome this problem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-soft-errors-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-tcp-soft-errors-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-tcp-soft-errors-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: <2006-10-9123750.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-tcp-soft-errors-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-soft-errors-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-9123750.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 Wed Oct 11 02:18:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXXOl-0003ys-0y; Wed, 11 Oct 2006 02:16:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXXOj-0003sl-LN for tcpm@ietf.org; Wed, 11 Oct 2006 02:16:57 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXXOg-0004uZ-7m for tcpm@ietf.org; Wed, 11 Oct 2006 02:16:57 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 2E5C8F0C49D; Wed, 11 Oct 2006 03:22:25 -0300 (ART) Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k9B6G4S6019761; Wed, 11 Oct 2006 03:16:12 -0300 Message-Id: <7.0.1.0.0.20061011004834.07a84710@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 11 Oct 2006 00:51:54 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Sally Floyd Subject: [tcpm] New revision of the TCP soft errors drafts X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Folks, I have submitted a revision of the draft "TCP's reaction to soft errors". This last revision addresses the feedback posted by Sally Floyd a week ago or so. The draft has been pretty stable during the last few revisions, with basically only minor editorial changes. Any comments on the current version will be more than welcome. Thanks! Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Oct 12 06:16:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXxbr-0006JR-Nh; Thu, 12 Oct 2006 06:16:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXxbq-0006Hq-If for tcpm@ietf.org; Thu, 12 Oct 2006 06:16:14 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXxbp-0008Uu-0S for tcpm@ietf.org; Thu, 12 Oct 2006 06:16:14 -0400 Received: from [139.133.207.156] (dhcp-207-156.erg.abdn.ac.uk [139.133.207.156]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k9CAFZpK026226; Thu, 12 Oct 2006 11:15:35 +0100 (BST) Message-ID: <452E15C7.6050604@erg.abdn.ac.uk> Date: Thu, 12 Oct 2006 11:15:35 +0100 From: Gorry Fairhurst Organization: University of Aberdeen, UK User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Caitlin Bestler Subject: Re: [tcpm] UTO: SHOULD send option in first segment after the SYN? References: <54AD0F12E08D1541B826BE97C98F99F1A31DF8@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F1A31DF8@NT-SJCA-0751.brcm.ad.broadcom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-Spam-Status: No X-Spam-Score: -2.8 (--) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: tcpm@ietf.org, Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Seems fine to me, sorry I didn't respond back to the last posting. So this says, if a host thinks it may use UTO, then it would need to be included in the SYN. Some TCP implementations also "like" to know what options could be used at connection establishment, rather than introducing "random" options as the connection progresses. Including these in the SYN exchange simplifies processing of later segments and also provides an element of "protection" from spurious options being inserted that were not intended by the sender. Gorry Caitlin Bestler wrote: > Fernando Gont wrote: > >>At 18:10 28/09/2006, Caitlin Bestler wrote: >> >> >>>> A host that supports the TCP User Timeout Option SHOULD include >>>> one in each packet that carries a SYN flag, but need not. >>>> [MEDINA] has shown that unknown options are correctly handled by >>>>the vast [....] >> >>>Given that there is no need to pre-validate support for UTO, and that >>>the suggestion UTO value may be ignored on a SYN, I think placing the >>>initial UTO value on the first data carrying packet makes more sense. >> >>Do you suggest to replace the "SHOULD include one in each >>packet that carries a SYN flag", or rather suggest to include >>an *additional* "SHOULD" for including the option in the first data >>segment? >> >>Kindest regards, > > > Many SYN-Cookie or similar strategies are only activated > when the passive side suspects that it might be under attack. > Such systems might do initial allocations based on the SYN > alone. Therefore including the initial UTO on *both* the SYN > and the next segment makes sense. I can't think of any real > harm in sending both. Assuming that the connection is actually > going to be open long enough to have justified sending a UTO > the "wasted" bandwidth is miniscule. > > > > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Oct 14 03:12:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYdg3-0000AA-FJ; Sat, 14 Oct 2006 03:11:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYdg1-00006F-OK for tcpm@ietf.org; Sat, 14 Oct 2006 03:11:21 -0400 Received: from whisker.bluecoat.com ([216.52.23.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYdXi-0006M8-Sh for tcpm@ietf.org; Sat, 14 Oct 2006 03:02:49 -0400 Received: from bcs-mail2.internal.cacheflow.com (bcs-mail2.internal.cacheflow.com [10.2.2.59]) by whisker.bluecoat.com (8.13.8/8.13.8) with ESMTP id k9E72fZg021091 for ; Sat, 14 Oct 2006 00:02:41 -0700 (PDT) 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: [tcpm] Re: UTO: SHOULD send option in first segment after the SYN? Date: Sat, 14 Oct 2006 00:02:36 -0700 Message-ID: <305C539CA2F86249BF51CDCE8996AFF41CD6C7@bcs-mail2.internal.cacheflow.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Re: UTO: SHOULD send option in first segment after the SYN? Thread-Index: AcbvXCerKgK3l6jYQTSn6KhU3IHXsg== From: "Mahdavi, Jamshid" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Fernando asked that I send my comments on this text back to the list. > A host that supports the TCP User Timeout Option SHOULD include one > in each packet that carries a SYN flag, but need not. [MEDINA] has > shown that unknown options are correctly handled by the vast majority > of modern TCP stacks. It is thus not necessary to require > negotiation of the use of the TCP User Timeout Option during the > three-way handshake of a connection. However, including a TCP User > Timeout Option in each segment that has the SYN flag set will result > in TCP being able to adopt a user timeout with knowledge of that used > by the peer TCP, since the beginning of the data transfer phase. I think this paragraph is somewhat misleading. I read the MEDINA = reference, and it says that 0.2% of connections fail with unknown = options on the SYN, while 3% of connections fail with unknown options = (or unnegotiated timestamps) later in the connection. While it technically correct to say "the vast majority", failing 3% of = connections is pretty severe. Furthermore, should an application choose = to use a UTO in midconnection, and the connection fails, there is not = much that the application can do about this. MEDINA does not provide analysis as to the root cause of the 3% = failures. One could hypothesize that 3% of host operating systems = exhibit the problem, or that 3% of routers / firewalls do, etc. Should = applications start choosing to use this option, it seems quite possible = that users who experience failure would be unable to really do anything = about the problem, short of switching from that application to a = different one. My original suggestion to Fernando was simply to clarify the risk in the = text. After discussing a bit I came to the conclusion that we probably = should do more than just acknowledge the risk and instead try to reduce = it. The way to do this would be to do a SYN option negotiation, just = like other features such as timestamps and SACK. MEDINA has shown that = this is an order of magnitude safer, and it allows for further remedies = in the form of backing off of the option negotiation (within the stack) = should there be a failure. Together these would make such a solution = significantly more robust. It strikes me that one could draw an analogy between this and the Path = MTU Black Hole problem. That has ended up being a very annoying = problem. It seems to me (based on MEDINA) that this option could turn = into a similar situation where connections mysteriously fail; doing our = best to prevent that seems like a good idea.=20 --J _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Oct 16 03:21:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZMm5-0002Rl-Ln; Mon, 16 Oct 2006 03:20:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZMm4-0002Re-Qy for tcpm@ietf.org; Mon, 16 Oct 2006 03:20:36 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZMm2-0004WA-8b for tcpm@ietf.org; Mon, 16 Oct 2006 03:20:36 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 9D8B3F0C51E; Mon, 16 Oct 2006 04:27:13 -0300 (ART) Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k9G7Jskk000543; Mon, 16 Oct 2006 04:20:14 -0300 Message-Id: <7.0.1.0.0.20061016041031.04d037b0@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 16 Oct 2006 04:16:39 -0300 To: "Mahdavi, Jamshid" , From: Fernando Gont Subject: Re: [tcpm] Re: UTO: SHOULD send option in first segment after the SYN? In-Reply-To: <305C539CA2F86249BF51CDCE8996AFF41CD6C7@bcs-mail2.internal. cacheflow.com> References: <305C539CA2F86249BF51CDCE8996AFF41CD6C7@bcs-mail2.internal.cacheflow.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Lars Eggert 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 Jamshid, >My original suggestion to Fernando was simply to clarify the risk in >the text. After discussing a bit I came to the conclusion that we >probably should do more than just acknowledge the risk and instead >try to reduce it. The way to do this would be to do a SYN option >negotiation, just like other features such as timestamps and >SACK. MEDINA has shown that this is an order of magnitude safer, >and it allows for further remedies in the form of backing off of the >option negotiation (within the stack) should there be a >failure. Together these would make such a solution significantly more robust. Given that there has been discussion about this issue on this mailing list, and the consensus had been to *not* require the option in the 3WHS, my take take is: * We will try to clarify this in the document (if you want to suggest text, that'll be more than welcome) * I will keep an eye on the list to sense if there's consensus to change the document to require the option in the 3WHS (that was the original proposal, but there was consensus to change the draft as it currently is). Of course, if there's consensus to do so, we'll make the change. Thanks for your feedback, and also for posting this on the mailing list! Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Oct 16 12:18:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZVAO-0007Ec-2b; Mon, 16 Oct 2006 12:18:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZVAM-0007ES-Sv for tcpm@ietf.org; Mon, 16 Oct 2006 12:18:14 -0400 Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZVAI-0000eV-FA for tcpm@ietf.org; Mon, 16 Oct 2006 12:18:14 -0400 Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.2)); Mon, 16 Oct 2006 09:17:59 -0700 X-Server-Uuid: 450F6D01-B290-425C-84F8-E170B39A25C9 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 800742AF; Mon, 16 Oct 2006 09:17:59 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 59F6B2AE; Mon, 16 Oct 2006 09:17:59 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EHU04154; Mon, 16 Oct 2006 09:15:15 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id BF1F020502; Mon, 16 Oct 2006 09:15:15 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] Re: UTO: SHOULD send option in first segment after the SYN? Date: Mon, 16 Oct 2006 09:15:14 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1AFFCE1@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <305C539CA2F86249BF51CDCE8996AFF41CD6C7@bcs-mail2.internal.cacheflow.com> Thread-Topic: [tcpm] Re: UTO: SHOULD send option in first segment after the SYN? Thread-Index: AcbvXCerKgK3l6jYQTSn6KhU3IHXsgB4V7qA From: "Caitlin Bestler" To: "Mahdavi, Jamshid" , tcpm@ietf.org X-WSS-ID: 692D6F3D3AK1936512-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Mahdavi, Jamshid wrote: > Fernando asked that I send my comments on this text back to the list. >=20 >> A host that supports the TCP User Timeout Option SHOULD include one >> in each packet that carries a SYN flag, but need not. [MEDINA] has >> shown that unknown options are correctly handled by the vast >> majority of modern TCP stacks. It is thus not necessary to require >> negotiation of the use of the TCP User Timeout Option during the >> three-way handshake of a connection. However, including a TCP User >> Timeout Option in each segment that has the SYN flag set will result >> in TCP being able to adopt a user timeout with knowledge of that >> used by the peer TCP, since the beginning of the data transfer phase. >=20 > I think this paragraph is somewhat misleading. I read the > MEDINA reference, and it says that 0.2% of connections fail > with unknown options on the SYN, while 3% of connections fail > with unknown options (or unnegotiated timestamps) later in > the connection. >=20 > While it technically correct to say "the vast majority", > failing 3% of connections is pretty severe. Furthermore, > should an application choose to use a UTO in midconnection, > and the connection fails, there is not much that the > application can do about this. >=20 > MEDINA does not provide analysis as to the root cause of the > 3% failures. One could hypothesize that 3% of host operating > systems exhibit the problem, or that 3% of routers / > firewalls do, etc. Should applications start choosing to use > this option, it seems quite possible that users who > experience failure would be unable to really do anything > about the problem, short of switching from that application > to a different one. >=20 > My original suggestion to Fernando was simply to clarify the > risk in the text. After discussing a bit I came to the > conclusion that we probably should do more than just > acknowledge the risk and instead try to reduce it. The way > to do this would be to do a SYN option negotiation, just like > other features such as timestamps and SACK. MEDINA has shown > that this is an order of magnitude safer, and it allows for > further remedies in the form of backing off of the option > negotiation (within the stack) should there be a failure. > Together these would make such a solution significantly more robust. >=20 > It strikes me that one could draw an analogy between this and > the Path MTU Black Hole problem. That has ended up being a > very annoying problem. It seems to me (based on MEDINA) that > this option could turn into a similar situation where > connections mysteriously fail; doing our best to prevent that > seems like a good idea. >=20 > --J >=20 As currently proposed an implementation is always free to simply ignore a UTO suggestion for any number of reasons, including not having a convenient place to store the information due to internal state issues. We should not lose that. Your logic almost suggests that the passive side MUST reject a connection with the UTO option if it does not intend to honor it. In my opinion that wouuld be a mistake. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Oct 16 12:29:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZVKc-0006ia-4w; Mon, 16 Oct 2006 12:28:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZVKb-0006iV-Ai for tcpm@ietf.org; Mon, 16 Oct 2006 12:28:49 -0400 Received: from whisker.bluecoat.com ([216.52.23.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZVKW-0002H0-SS for tcpm@ietf.org; Mon, 16 Oct 2006 12:28:49 -0400 Received: from bcs-mail2.internal.cacheflow.com (bcs-mail2.internal.cacheflow.com [10.2.2.59]) by whisker.bluecoat.com (8.13.8/8.13.8) with ESMTP id k9GGSh8W000491; Mon, 16 Oct 2006 09:28:43 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] Re: UTO: SHOULD send option in first segment after the SYN? Date: Mon, 16 Oct 2006 09:28:37 -0700 Message-ID: <305C539CA2F86249BF51CDCE8996AFF4BB9D7C@bcs-mail2.internal.cacheflow.com> In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F1AFFCE1@NT-SJCA-0751.brcm.ad.broadcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Re: UTO: SHOULD send option in first segment after the SYN? Thread-Index: AcbvXCerKgK3l6jYQTSn6KhU3IHXsgB4V7qAAABhlHA= From: "Mahdavi, Jamshid" To: "Caitlin Bestler" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org You are arguing that the option should be advisory, meaning that it can be ignored if the stack chooses to. I wasn't trying to suggest otherwise on that account. I think there are two cases to consider: (1) Both stacks are UTO capable, but one side chooses not to use it. In that case, if we were to use a SYN negotiation, the stacks would agree they are capable, and then the applications can choose whether or not to use the option with no unexpected results. (2) A UTO capable stack is trying to use the option when talking to a stack which is not UTO capable (or there is some middlebox which is not UTO capable). In this case, I was observing that, according to the reference cited in the draft, 3% of such connections could mysteriously die in the middle with no explanation and no way to recover. I thought this seemed pretty severe and desirable to avoid. --Jamshid -----Original Message----- From: Caitlin Bestler [mailto:caitlinb@broadcom.com]=20 Sent: Monday, October 16, 2006 9:15 AM To: Mahdavi, Jamshid; tcpm@ietf.org Subject: RE: [tcpm] Re: UTO: SHOULD send option in first segment after the SYN? Mahdavi, Jamshid wrote: > Fernando asked that I send my comments on this text back to the list. >=20 >> A host that supports the TCP User Timeout Option SHOULD include one >> in each packet that carries a SYN flag, but need not. [MEDINA] has >> shown that unknown options are correctly handled by the vast >> majority of modern TCP stacks. It is thus not necessary to require >> negotiation of the use of the TCP User Timeout Option during the >> three-way handshake of a connection. However, including a TCP User >> Timeout Option in each segment that has the SYN flag set will result >> in TCP being able to adopt a user timeout with knowledge of that >> used by the peer TCP, since the beginning of the data transfer phase. >=20 > I think this paragraph is somewhat misleading. I read the > MEDINA reference, and it says that 0.2% of connections fail > with unknown options on the SYN, while 3% of connections fail > with unknown options (or unnegotiated timestamps) later in > the connection. >=20 > While it technically correct to say "the vast majority", > failing 3% of connections is pretty severe. Furthermore, > should an application choose to use a UTO in midconnection, > and the connection fails, there is not much that the > application can do about this. >=20 > MEDINA does not provide analysis as to the root cause of the > 3% failures. One could hypothesize that 3% of host operating > systems exhibit the problem, or that 3% of routers / > firewalls do, etc. Should applications start choosing to use > this option, it seems quite possible that users who > experience failure would be unable to really do anything > about the problem, short of switching from that application > to a different one. >=20 > My original suggestion to Fernando was simply to clarify the > risk in the text. After discussing a bit I came to the > conclusion that we probably should do more than just > acknowledge the risk and instead try to reduce it. The way > to do this would be to do a SYN option negotiation, just like > other features such as timestamps and SACK. MEDINA has shown > that this is an order of magnitude safer, and it allows for > further remedies in the form of backing off of the option > negotiation (within the stack) should there be a failure. > Together these would make such a solution significantly more robust. >=20 > It strikes me that one could draw an analogy between this and > the Path MTU Black Hole problem. That has ended up being a > very annoying problem. It seems to me (based on MEDINA) that > this option could turn into a similar situation where > connections mysteriously fail; doing our best to prevent that > seems like a good idea. >=20 > --J >=20 As currently proposed an implementation is always free to simply ignore a UTO suggestion for any number of reasons, including not having a convenient place to store the information due to internal state issues. We should not lose that. Your logic almost suggests that the passive side MUST reject a connection with the UTO option if it does not intend to honor it. In my opinion that wouuld be a mistake. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Oct 16 12:42:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZVXA-00043s-Dx; Mon, 16 Oct 2006 12:41:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZVX8-00043n-VW for tcpm@ietf.org; Mon, 16 Oct 2006 12:41:46 -0400 Received: from mms2.broadcom.com ([216.31.210.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZVX7-0004PL-Jp for tcpm@ietf.org; Mon, 16 Oct 2006 12:41:46 -0400 Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.2)); Mon, 16 Oct 2006 09:41:33 -0700 X-Server-Uuid: 79DB55DB-3CB4-423E-BEDB-D0F268247E63 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 673D72B0; Mon, 16 Oct 2006 09:41:33 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 385482AF; Mon, 16 Oct 2006 09:41:33 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EHU10507; Mon, 16 Oct 2006 09:41:28 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 882B120502; Mon, 16 Oct 2006 09:41:28 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] Re: UTO: SHOULD send option in first segment after the SYN? Date: Mon, 16 Oct 2006 09:41:27 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1AFFCE3@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <305C539CA2F86249BF51CDCE8996AFF4BB9D7C@bcs-mail2.internal.cacheflow.com> Thread-Topic: [tcpm] Re: UTO: SHOULD send option in first segment after the SYN? Thread-Index: AcbvXCerKgK3l6jYQTSn6KhU3IHXsgB4V7qAAABhlHAAAHBf4A== From: "Caitlin Bestler" To: "Mahdavi, Jamshid" , tcpm@ietf.org X-WSS-ID: 692D69B72I05165763-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Mahdavi, Jamshid wrote: > You are arguing that the option should be advisory, meaning > that it can be ignored if the stack chooses to. I wasn't > trying to suggest otherwise on that account. >=20 > I think there are two cases to consider: >=20 > (1) Both stacks are UTO capable, but one side chooses not to > use it. In that case, if we were to use a SYN negotiation, > the stacks would agree they are capable, and then the > applications can choose whether or not to use the option with no > unexpected results.=20 >=20 > (2) A UTO capable stack is trying to use the option when > talking to a stack which is not UTO capable (or there is some > middlebox which is not UTO capable). In this case, I was > observing that, according to the reference cited in the > draft, 3% of such connections could mysteriously die in the > middle with no explanation and no way to recover. I thought > this seemed pretty severe and desirable to avoid. >=20 The failure of existing implementations to properly handle old requirements is hardly a justification for creating a new one. If we are going to design around faulty handling of options we would do so by limiting new options for truly emergency level problems that could be solved no other way. UTO clearly does not meeet that. But as an *advisory* signal from peer to peer it may be worthwhile. I am particularly concerned with adding any requirement for retention of more stateful data in a response to an unconfirmed SYN. And I don't believe that rejecting all connection requests that include a UTO is much of an option, since any stack could easily support the extra data *after* the existence of the remote peer is confirmed. Increasing the amount of data kept about a alledged peer is not a good idea. If you want to require that anyone who intends to ever use a UTO MUST send it in the SYN, I would not have an objection. But if you intend to require that a later UTO MUST be rejected if it was not negotiated at connection setup then you are increasing the amount of stateful data that must be kept from the receipt of the first SYN. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Oct 16 12:52:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZVh3-00014s-IL; Mon, 16 Oct 2006 12:52:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZVh2-00014i-Fd for tcpm@ietf.org; Mon, 16 Oct 2006 12:52:00 -0400 Received: from whisker.bluecoat.com ([216.52.23.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZVh1-00074n-1D for tcpm@ietf.org; Mon, 16 Oct 2006 12:52:00 -0400 Received: from bcs-mail2.internal.cacheflow.com (bcs-mail2.internal.cacheflow.com [10.2.2.59]) by whisker.bluecoat.com (8.13.8/8.13.8) with ESMTP id k9GGpv1A002588; Mon, 16 Oct 2006 09:51:57 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] Re: UTO: SHOULD send option in first segment after the SYN? Date: Mon, 16 Oct 2006 09:51:51 -0700 Message-ID: <305C539CA2F86249BF51CDCE8996AFF4BB9DF0@bcs-mail2.internal.cacheflow.com> In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F1AFFCE3@NT-SJCA-0751.brcm.ad.broadcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Re: UTO: SHOULD send option in first segment after the SYN? Thread-Index: AcbvXCerKgK3l6jYQTSn6KhU3IHXsgB4V7qAAABhlHAAAHBf4AAAZ5AA From: "Mahdavi, Jamshid" To: "Caitlin Bestler" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org =20 Caitlin Bester wrote: > If you want to require that anyone who intends to ever > use a UTO MUST send it in the SYN, I would not have > an objection. But if you intend to require that a later > UTO MUST be rejected if it was not negotiated at connection > setup then you are increasing the amount of stateful data > that must be kept from the receipt of the first SYN. I was thinking more the former than the latter, but even that may have implementation problems if you are trying to do it without remembering anything. (The goal being that one SHOULD NOT send a UTO if the peer did not say he supports it on the handshake.) I'm not deeply attached to making a substantive change here; my main point is that the text as currently written claims pretty strongly that it is safe to do this in mid-connection, and I think that is inaccurate and misinterprets the data in MEDINA. It would certainly fair to say something like, "while research has shown that 3% of such connections can fail, these failures do not follow existing requirements and don't warrant taking special measures to ensure perfect robustness." --J _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Oct 19 16:25:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaeRZ-00089c-M1; Thu, 19 Oct 2006 16:24:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaeRZ-00089H-5E for tcpm@ietf.org; Thu, 19 Oct 2006 16:24:45 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaeRX-0004B8-8D for tcpm@ietf.org; Thu, 19 Oct 2006 16:24:45 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k9JK9Omp062675; Thu, 19 Oct 2006 13:09:24 -0700 (PDT) (envelope-from mallman@icir.org) 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 C8689393F3A; Thu, 19 Oct 2006 16:10:29 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 966734A70F2; Thu, 19 Oct 2006 16:07:49 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Won't Get Fooled Again MIME-Version: 1.0 Date: Thu, 19 Oct 2006 16:07:49 -0400 Message-Id: <20061019200749.966734A70F2@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Ted Faber Subject: [tcpm] agenda items? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0354072780==" Errors-To: tcpm-bounces@ietf.org --===============0354072780== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Folks- If you would like agenda time for something at the upcoming IETF please send Ted and I a brief note with the name of the draft, the amount of time you are requesting and a brief idea of how you intend to use the f2f time. Thanks! allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFFN9sUWyrrWs4yIs4RArqZAJ0XV13KyKHGOL1LtKnSqOe1VQfEQACeICwt YqygEgT2z0BIg2DNzJZqoOM= =M0o0 -----END PGP SIGNATURE----- --=_bOundary-- --===============0354072780== 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 --===============0354072780==-- From tcpm-bounces@ietf.org Fri Oct 20 11:39:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GawRn-0006xe-6o; Fri, 20 Oct 2006 11:38:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GawRm-0006p6-99 for tcpm@ietf.org; Fri, 20 Oct 2006 11:38:10 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GawRh-0004FR-J0 for tcpm@ietf.org; Fri, 20 Oct 2006 11:38:10 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 9E5D9F0C6BE; Fri, 20 Oct 2006 12:45:20 -0300 (ART) Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k9KFbq1M001175; Fri, 20 Oct 2006 12:37:57 -0300 Message-Id: <7.0.1.0.0.20061020121102.078944a0@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 20 Oct 2006 12:37:20 -0300 To: "Mahdavi, Jamshid" , "Caitlin Bestler" , From: Fernando Gont Subject: RE: [tcpm] Re: UTO: SHOULD send option in first segment after the SYN? In-Reply-To: <305C539CA2F86249BF51CDCE8996AFF4BB9DF0@bcs-mail2.internal. cacheflow.com> References: <54AD0F12E08D1541B826BE97C98F99F1AFFCE3@NT-SJCA-0751.brcm.ad.broadcom.com> <305C539CA2F86249BF51CDCE8996AFF4BB9DF0@bcs-mail2.internal.cacheflow.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Jamshid, Thanks again for your comments. Please let me know if the changes bellow address your comments.... >I'm not deeply attached to making a substantive change here; my main >point is that the text as currently written claims pretty strongly that >it is safe to do this in mid-connection, and I think that is inaccurate >and misinterprets the data in MEDINA. It would certainly fair to say >something like, "while research has shown that 3% of such connections >can fail, these failures do not follow existing requirements and don't >warrant taking special measures to ensure perfect robustness." The third paragraph of Section 3 would change to: "A host that supports the TCP User Timeout Option SHOULD include one in each packet that carries a SYN flag, but need not. [MEDINA] has shown that unknown options are correctly handled by the vast majority of modern TCP stacks. while research has shown that 3% of such connections can fail, these failures do not follow existing requirements and don't warrant taking special measures to ensure perfect robustness. Therefore, negotiation of the use of the TCP User Timeout Option during the three-way handshake is not required. However, including a TCP User Timeout Option in each segment that has the SYN flag set will result in TCP being able to adopt a user timeout with knowledge of that used by the peer TCP, since the beginning of the data transfer phase." And the first paragraph of Section 4.1 would change to: " The large number of middleboxes (firewalls, proxies, protocol scrubbers, etc.) currently present in the Internet pose some difficulty for deploying new TCP options. Some firewalls may block segments that carry unknown options, preventing connection establishment when the SYN or SYN-ACK segment contain a TCP User Timeout Option, or causing established connections to fail when an unknown option is transmitted during the life of a connection. Some recent results, however, indicate that for new TCP options, this may not be a significant threat, with only 0.2% of web requests failing when carrying an unknown option, and only 3% of established connections failing when an unknown TCP option is transmitted during the life of a connection [MEDINA]." Please let me know if this addresses your feedback. 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 Oct 20 12:00:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GawnK-00079Y-NH; Fri, 20 Oct 2006 12:00:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GawnJ-00079L-SM for tcpm@ietf.org; Fri, 20 Oct 2006 12:00:25 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GawnG-00083B-9z for tcpm@ietf.org; Fri, 20 Oct 2006 12:00:25 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 70FFFF0C64E; Fri, 20 Oct 2006 13:07:52 -0300 (ART) Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k9KG0Ofm020838; Fri, 20 Oct 2006 13:00:27 -0300 Message-Id: <7.0.1.0.0.20061020125533.078bfe80@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 20 Oct 2006 12:58:37 -0300 To: "Caitlin Bestler" , "Mahdavi, Jamshid" , tcpm@ietf.org From: Fernando Gont Subject: RE: [tcpm] Re: UTO: SHOULD send option in first segment after the SYN? In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F1AFFCE3@NT-SJCA-0751.brcm.a d.broadcom.com> References: <305C539CA2F86249BF51CDCE8996AFF4BB9D7C@bcs-mail2.internal.cacheflow.com> <54AD0F12E08D1541B826BE97C98F99F1AFFCE3@NT-SJCA-0751.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Caitlin, In response to your feedback I added a new paragraph to Section 3 of the document: " A host that supports the TCP User Timeout Option SHOULD include one in each packet that carries a SYN flag, but need not. [MEDINA] has shown that unknown options are correctly handled by the vast majority of modern TCP stacks. It is thus not necessary to require negotiation of the use of the TCP User Timeout Option during the three-way handshake of a connection. However, including a TCP User Timeout Option in each segment that has the SYN flag set will result in TCP being able to adopt a user timeout with knowledge of that used by the peer TCP, since the beginning of the data transfer phase. Aditionally, a hosts that supports the TCP User Timeout option SHOULD include one in the first packet that does not have the SYN flag set. This helps to minimize the amount of state information a TCP must keep for connections in non-synchronized states, and is particularly useful when mechanisms such as "SYN cookies" [Bernstein] are implemented, allowing a newly-established TCP conenction to benefit from the information advertised by UTO option, even if the UTO contained in the initial SYN segment was not recorded. A host that supports the TCP User Timeout Option SHOULD include it in the next possible segment to its peer whenever it starts using a new user timeout for the connection. This allows the peer to adapt its local user timeout for the connection accordingly." (The first and last paragraph are included for reference. Only the second one has been added). Please let me know if you think this change addresses your feedback. If it doesn't, you may suggest some text. Thanks! 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 Sat Oct 21 12:29:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbJhx-0002EP-KX; Sat, 21 Oct 2006 12:28:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbJhw-0002EJ-82 for tcpm@ietf.org; Sat, 21 Oct 2006 12:28:24 -0400 Received: from whisker.bluecoat.com ([216.52.23.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbJhu-0003XZ-Qv for tcpm@ietf.org; Sat, 21 Oct 2006 12:28:24 -0400 Received: from bcs-mail2.internal.cacheflow.com (bcs-mail2.internal.cacheflow.com [10.2.2.59]) by whisker.bluecoat.com (8.13.8/8.13.8) with ESMTP id k9LGSEow016987; Sat, 21 Oct 2006 09:28:14 -0700 (PDT) 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: UTO: SHOULD send option in first segment after the SYN? Date: Sat, 21 Oct 2006 09:28:08 -0700 Message-ID: <305C539CA2F86249BF51CDCE8996AFF41CD6E7@bcs-mail2.internal.cacheflow.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Re: UTO: SHOULD send option in first segment after the SYN? Thread-Index: Acb0XbqMYJNCPRQqS7m8GYFV6trReAAywpZE References: <54AD0F12E08D1541B826BE97C98F99F1AFFCE3@NT-SJCA-0751.brcm.ad.broadcom.com> <305C539CA2F86249BF51CDCE8996AFF4BB9DF0@bcs-mail2.internal.cacheflow.com> <7.0.1.0.0.20061020121102.078944a0@gont.com.ar> From: "Mahdavi, Jamshid" To: "Fernando Gont" , "Caitlin Bestler" , X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Some tweaks: - "but need not" seems contradictory. SHOULD has a=20 meaning which is clear. - I hate using references as parts of speech, so I=20 reworked the sentences about the Medina reference some. - I separated the paragraph into two, one covering the concept=20 of getting an early value, and a second discussing why we=20 don't do negotiation and including the Medina reference. Looking at the whole flow of this section, we could move this second paragraph down into the paragraph that already=20 references RFC1122 since I think these naturally fit together. Here are the two rewritten paragraphs: A host that supports the TCP User Timeout Option SHOULD include one in each packet that carries a SYN flag. The presence of this option is not a negotiation of the capability, but simply an advisory message specifying the currently preferred user timeout value. This allows TCP to adopt a user timeout with knowledge of that used by the peer TCP=20 from the very beginning of the data transfer phase. ... A TCP implementation that does not support the TCP User Timeout Option MUST silently ignore it [RFC1122], thus ensuring interoperability. In a study of the effects of middleboxes on transport protocols, Medina=20 has shown that unknown TCP options are correctly handled by the vast=20 majority of modern TCP stacks [MEDINA]. In this study 3% of=20 connections failed when an unknown TCP option appeared in the middle of=20 a connection. Because these failures violate existing requirements to=20 ignore unknown options, they do not warrant taking special measures to=20 handle these cases. In particular, we do not define a separate = mechanism=20 to negotiate support of the TCP User Timeout Option on the=20 three-way handshake. -----Original Message----- From: Fernando Gont [mailto:fernando@gont.com.ar] Sent: Fri 10/20/2006 8:37 AM To: Mahdavi, Jamshid; Caitlin Bestler; tcpm@ietf.org Subject: RE: [tcpm] Re: UTO: SHOULD send option in first segment after = the SYN? =20 Jamshid, Thanks again for your comments. Please let me know if the changes=20 bellow address your comments.... >I'm not deeply attached to making a substantive change here; my main >point is that the text as currently written claims pretty strongly that >it is safe to do this in mid-connection, and I think that is inaccurate >and misinterprets the data in MEDINA. It would certainly fair to say >something like, "while research has shown that 3% of such connections >can fail, these failures do not follow existing requirements and don't >warrant taking special measures to ensure perfect robustness." The third paragraph of Section 3 would change to: "A host that supports the TCP User Timeout Option SHOULD include one in each packet that carries a SYN flag, but need not. [MEDINA] has shown that unknown options are correctly handled by the vast majority of modern TCP stacks. while research has shown that 3% of such = connections can fail, these failures do not follow existing requirements and don't warrant taking special measures to ensure perfect robustness. Therefore, negotiation of the use of the TCP User Timeout Option during the = three-way handshake is not required. However, including a TCP User Timeout Option in each segment that has the SYN flag set will result in TCP being=20 able to adopt a user timeout with knowledge of that used by the peer TCP, since the beginning of the data transfer phase." And the first paragraph of Section 4.1 would change to: " The large number of middleboxes (firewalls, proxies, protocol scrubbers, etc.) currently present in the Internet pose some difficulty for deploying new TCP options. Some firewalls may block segments that carry unknown options, preventing connection establishment when the SYN or SYN-ACK segment contain a TCP User Timeout Option, or causing established connections to fail when an unknown option is transmitted during the life of a connection. Some recent results, however, indicate that for new TCP options, this may not be a significant threat, with only 0.2% of web requests failing when carrying an unknown option, and only 3% of established connections failing when an unknown TCP option is transmitted during the life of a connection [MEDINA]." Please let me know if this addresses your feedback. 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 Sun Oct 22 16:34:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbk0y-0002Rd-8T; Sun, 22 Oct 2006 16:33:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbk0x-0002Mk-C0 for tcpm@ietf.org; Sun, 22 Oct 2006 16:33:47 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gbk0t-00034m-V3 for tcpm@ietf.org; Sun, 22 Oct 2006 16:33:47 -0400 Received: from [128.9.176.73] ([128.9.176.73]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id k9MKX3el028012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 22 Oct 2006 13:33:03 -0700 (PDT) Message-ID: <453BD57C.1000807@isi.edu> Date: Sun, 22 Oct 2006 13:33:00 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: tcpm@ietf.org X-Enigmail-Version: 0.94.0.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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [tcpm] new draft-ietf-tcpm-antispoof-05 just submitted 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="===============0833959754==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0833959754== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig610C5CA9789590DEA8DC7B19" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig610C5CA9789590DEA8DC7B19 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, all, In response to the WGLC, an new version of the antispoof document has been submitted. There are three areas of change: - minor wordsmithing - updated 3.2.1 to address discussions on solution context and TTL - updated 4 to address discussions on solution context and filtering It should appear in the usual places very shortly; in the meantime, a copy is available at: http://www.isi.edu/touch/pubs/draft-ietf-tcpm-tcp-antispoof-04.txt --------------enig610C5CA9789590DEA8DC7B19 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 iD8DBQFFO9V8E5f5cImnZrsRAnDiAKD2GNrXKfmjGE3xwJuUj/ZKZQFl/ACfdjzz UcQkXRHTqjin9dERUjDKC8M= =kCOp -----END PGP SIGNATURE----- --------------enig610C5CA9789590DEA8DC7B19-- --===============0833959754== 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 --===============0833959754==-- From tcpm-bounces@ietf.org Mon Oct 23 06:22:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbwwt-0008UL-9L; Mon, 23 Oct 2006 06:22:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbwwr-0008Tv-IL for tcpm@ietf.org; Mon, 23 Oct 2006 06:22:25 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gbwwp-0000HZ-22 for tcpm@ietf.org; Mon, 23 Oct 2006 06:22:25 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id CBCB5F0C432; Mon, 23 Oct 2006 07:29:50 -0300 (ART) Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k9NALafh002199; Mon, 23 Oct 2006 07:21:40 -0300 Message-Id: <7.0.1.0.0.20061023042137.0742b900@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 23 Oct 2006 04:22:45 -0300 To: Joe Touch , tcpm@ietf.org From: Fernando Gont Subject: Re: [tcpm] new draft-ietf-tcpm-antispoof-05 just submitted In-Reply-To: <453BD57C.1000807@isi.edu> References: <453BD57C.1000807@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 17:33 22/10/2006, Joe Touch wrote: There's a typo in the URL. The URL should be: http://www.isi.edu/touch/pubs/draft-ietf-tcpm-tcp-antispoof-05.txt Kindest regards, Fernando Gont >Hi, all, > >In response to the WGLC, an new version of the antispoof document has >been submitted. > >There are three areas of change: > >- minor wordsmithing >- updated 3.2.1 to address discussions on solution context and TTL >- updated 4 to address discussions on solution context and filtering > >It should appear in the usual places very shortly; in the meantime, a >copy is available at: > >http://www.isi.edu/touch/pubs/draft-ietf-tcpm-tcp-antispoof-04.txt > > > >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www1.ietf.org/mailman/listinfo/tcpm -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Oct 23 09:33:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbzup-0003oY-EP; Mon, 23 Oct 2006 09:32:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbzuo-0003kI-13 for tcpm@ietf.org; Mon, 23 Oct 2006 09:32:30 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gbzuk-0001lm-Js for tcpm@ietf.org; Mon, 23 Oct 2006 09:32:30 -0400 Received: from [192.168.1.42] (pool-71-106-94-15.lsanca.dsl-w.verizon.net [71.106.94.15]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id k9NDVl6S007838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 23 Oct 2006 06:31:51 -0700 (PDT) Message-ID: <453CC436.8010604@isi.edu> Date: Mon, 23 Oct 2006 06:31:34 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] new draft-ietf-tcpm-antispoof-05 just submitted References: <453BD57C.1000807@isi.edu> <7.0.1.0.0.20061023042137.0742b900@gont.com.ar> In-Reply-To: <7.0.1.0.0.20061023042137.0742b900@gont.com.ar> X-Enigmail-Version: 0.94.0.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: 41c17b4b16d1eedaa8395c26e9a251c4 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="===============1132306775==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1132306775== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig165816FCD7D1B2539396B2A2" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig165816FCD7D1B2539396B2A2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes; I forwarded the URL from the previous version. Please use the one Fernando provides below. Fernando Gont wrote: > At 17:33 22/10/2006, Joe Touch wrote: >=20 > There's a typo in the URL. The URL should be: >=20 > http://www.isi.edu/touch/pubs/draft-ietf-tcpm-tcp-antispoof-05.txt >=20 > Kindest regards, > Fernando Gont >=20 >=20 >=20 >=20 >> Hi, all, >> >> In response to the WGLC, an new version of the antispoof document has >> been submitted. >> >> There are three areas of change: >> >> - minor wordsmithing >> - updated 3.2.1 to address discussions on solution context and TTL >> - updated 4 to address discussions on solution context and filtering >> >> It should appear in the usual places very shortly; in the meantime, a >> copy is available at: >> >> http://www.isi.edu/touch/pubs/draft-ietf-tcpm-tcp-antispoof-04.txt >> >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www1.ietf.org/mailman/listinfo/tcpm >=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 --------------enig165816FCD7D1B2539396B2A2 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 iD8DBQFFPMRAE5f5cImnZrsRAjT2AKCkhsP7HbP0CbTD46l016+13oLDZwCfdCaV KuOKMoc30hfYgQCQM3PYhh0= =qSJF -----END PGP SIGNATURE----- --------------enig165816FCD7D1B2539396B2A2-- --===============1132306775== 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 --===============1132306775==-- From tcpm-bounces@ietf.org Mon Oct 23 10:45:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc12x-0001pF-Ki; Mon, 23 Oct 2006 10:44:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc12s-0008W6-Fk for tcpm@ietf.org; Mon, 23 Oct 2006 10:44:54 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc0tl-0006DJ-HP for tcpm@ietf.org; Mon, 23 Oct 2006 10:35:33 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 40BCFF0C420 for ; Mon, 23 Oct 2006 11:43:17 -0300 (ART) Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k9NEZLtN031999 for ; Mon, 23 Oct 2006 11:35:25 -0300 Message-Id: <7.0.1.0.0.20061023112238.075008f8@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 23 Oct 2006 11:24:51 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [tcpm] New revision of the ICMP attacks draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Hi, all, I have submitted a new revision of the ICMP attacks draft. It hopefully addresses the big bunch of comments posted on the list by many of you. It will soon show up in the usual places. In the mean time, you can access it at: http://www.gont.com.ar/drafts/icmp-attacks/draft-ietf-tcpm-icmp-attacks-01.txt Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Oct 23 10:45:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc13J-00021L-BX; Mon, 23 Oct 2006 10:45:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc13H-0001OC-6X for tcpm@ietf.org; Mon, 23 Oct 2006 10:45:19 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc0qw-0005nN-Lo for tcpm@ietf.org; Mon, 23 Oct 2006 10:32:38 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 5D635F0C432; Mon, 23 Oct 2006 11:40:27 -0300 (ART) Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k9NEWUEK031014; Mon, 23 Oct 2006 11:32:34 -0300 Message-Id: <7.0.1.0.0.20061023111845.07504850@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 23 Oct 2006 11:21:59 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: "Mahdavi, Jamshid" Subject: [tcpm] Revision of the UTO draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , ; Mon, 23 Oct 2006 11:43:17 -0300 (ART) Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k9NEZLtN031999 for ; Mon, 23 Oct 2006 11:35:25 -0300 Message-Id: <7.0.1.0.0.20061023112238.075008f8@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 23 Oct 2006 11:24:51 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [tcpm] New revision of the ICMP attacks draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Hi, all, I have submitted a new revision of the ICMP attacks draft. It hopefully addresses the big bunch of comments posted on the list by many of you. It will soon show up in the usual places. In the mean time, you can access it at: http://www.gont.com.ar/drafts/icmp-attacks/draft-ietf-tcpm-icmp-attacks-01.txt Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Oct 23 10:45:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc13J-00021L-BX; Mon, 23 Oct 2006 10:45:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc13H-0001OC-6X for tcpm@ietf.org; Mon, 23 Oct 2006 10:45:19 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc0qw-0005nN-Lo for tcpm@ietf.org; Mon, 23 Oct 2006 10:32:38 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 5D635F0C432; Mon, 23 Oct 2006 11:40:27 -0300 (ART) Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k9NEWUEK031014; Mon, 23 Oct 2006 11:32:34 -0300 Message-Id: <7.0.1.0.0.20061023111845.07504850@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 23 Oct 2006 11:21:59 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: "Mahdavi, Jamshid" Subject: [tcpm] Revision of the UTO draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Hi, all, We have submitted a revision of the UTO draft. It addresses the feedback posted by Jamshid and Caitllin on the mailing-list. It will soon show up in the usual places. In the mean time, you can access it at: http://www.gont.com.ar/drafts/tcp-user-timeout-option/draft-ietf-tcpm-tcp-uto-04.txt 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 .org?subject=unsubscribe> List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Hi, all, We have submitted a revision of the UTO draft. It addresses the feedback posted by Jamshid and Caitllin on the mailing-list. It will soon show up in the usual places. In the mean time, you can access it at: http://www.gont.com.ar/drafts/tcp-user-timeout-option/draft-ietf-tcpm-tcp-uto-04.txt Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Oct 23 13:50:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc3vI-0001Ua-DV; Mon, 23 Oct 2006 13:49:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc3vH-0001UV-0j for tcpm@ietf.org; Mon, 23 Oct 2006 13:49:15 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc3vD-0003yo-Fi for tcpm@ietf.org; Mon, 23 Oct 2006 13:49:14 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k9NHn8do085724 for ; Mon, 23 Oct 2006 10:49:08 -0700 (PDT) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 5A7173B756F for ; Mon, 23 Oct 2006 13:50:08 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Imagine MIME-Version: 1.0 Date: Mon, 23 Oct 2006 13:50:08 -0400 Message-Id: <20061023175008.5A7173B756F@guns.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Subject: [tcpm] soft errors comments 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="===============0604331694==" Errors-To: tcpm-bounces@ietf.org --===============0604331694== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline [chair hat sitting on the auction block ... anyone? ... anyone? ... well, regardless, I am not wearing it ...] Fernando- I read through soft errors this morning. The following are some comments: - All-in-all I think this document is coming along. I don't think it is quite the TCP-modification-neutral document the WG decided to write. I.e., I think that after reading the document one could certainly get the impression that changing soft errors to hard errors in SYN states is the intent of the document. - E.g., in the abstract you talk about the document "describ[ing] a modification" to TCP. While one could argue that the text is not wrong or that the text does not say a change is being made, I think this sort of language is suggestive. I think it would be more clear to say that the document "does not change TCP's standard response to ICMP messages, but sketches a non-standard, but widely-used change to TCP". This more explicit language could help things everywhere you discuss a "modification". - In addition, when you spell out the change in section 4 I think it would be nice if you could add a small blurb that notes this change is widely implemented, but that the IETF could not come to consensus on changing the standard behavior. Basically, reasonable people disagreed. - I'd like to see the enumeration of "soft errors" in the intro. You have it buried in section 4, which makes the reader wonder for a few pages what you are actually talking about. - In the intro you might note that "fault isolation" is done using methods besides ICMP messages (rexmt count, time). I.e., ICMPs are not the only way. - Intro: "it documents a modification" --> "it documents a non-standard, but widely-used modification" - It is weird that you quote RFC2119 for the meaning of MUST, etc., but the only place you use those terms is in paraphrasing of RFC1122---which came out before the definitions. - I found this sentence confusing: In case the connection times out before the segment is acknowledged, TCP won't be able to provide more information than the timeout condition. What do you mean? - "TCP will use this information" --> "TCP may use this information" (In general, statements of fact from [Stevens] should probably be tempered. I.e., [Stevens] is not a standard and while it certainly describes implemented and known behavior it does not describe absolute requirements.) - "attempts would be inappropriate" --> "attempts may be inappropriate" That is, if a SYN gets lost in the network we all just eat that now without wailing on the reload button. If a SYN gets lost many times then we are less patient, of course. - I also found [Shneiderman], [Thadani] and [Guynes] to be sort of tenuous references, although I would not necessarily suggest getting rid of them. In 3.1 these seem to be connected to "the web", but they are not about the web. I think you can probably find some words to say these studies are suggestive of people's behavior without making it too concrete. - Section 4: "It must be noted that this behavior" ... what behavior? I do know you mean the "workaround", but better words could be used here. - I found 5 to be suboptimal. In particular, you are bringing up alternatives and yet not in a neutral way. You are basically arguing them all down---and, using some pretty hand wavy stuff. E.g., the last paragraph of 5.1 is a big hand-wave. Probably non-interactive connections just don't care about any of this stuff. And, then you are trying to make judgments about the user's "likely" satisfaction. This paragraph is unneeded. You did the general discussion earlier as to the drawbacks of waiting. If you want to put something in the intro of section 5 that reminds us of that main drawback then OK. - Of course, "the workaround" weakens security. Saying that it does not is dis-ingenuous, I think. The workaround sets up a case whereby a connection can be aborted more quickly than it could using standard TCP. That is a *security consideration*. It doesn't matter if it is slight or you have a fix for the general ICMP attack problem or whatever. It ought to be noted. And, the document surely should not say that TCP is not weakened. - I am not sure nsynrexmt is new, as you note. There is likely a retransmit counter already in most stacks. (And, while you're in the 3WHS it doesn't seem like you'll be counting anything by the SYN.) - "not solving the problem" --> "not entirely solving the problems" (surely, it helps) - In A.2 you note "all" apps need changed. It's not clear to me that all apps would care about this problem. - In A.3 you note that parallel SYNs would make it hard to distinguish normal connection from DoS. Exactly how many IP addresses do you think a name is going to have? I think either your IP address count is way too high or your notion of a DoS attack is not high enough. That is, a DoS attack is going to send more than a handful of SYNs or it isn't going to DoS. I suggest just removing this. I hope those are somehow helpful. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFPQDQWyrrWs4yIs4RAiCcAJ4qwaYTfWCNfxGobEN6Heg/2ziSkwCdHpBS Rjg9AO+mWmSqR8dwy5BeBok= =mgOX -----END PGP SIGNATURE----- --=_bOundary-- --===============0604331694== 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 --===============0604331694==-- From tcpm-bounces@ietf.org Mon Oct 23 16:43:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc6cq-0001Pd-0n; Mon, 23 Oct 2006 16:42:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc6cR-0000lZ-8H; Mon, 23 Oct 2006 16:41:59 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc6cQ-0003pe-6A; Mon, 23 Oct 2006 16:41:58 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gc6cP-0002TX-G9; Mon, 23 Oct 2006 16:41:58 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id B6F43175E9; Mon, 23 Oct 2006 19:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gc5oB-0008Qe-Aj; Mon, 23 Oct 2006 15:50:03 -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, 23 Oct 2006 15:50:03 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-antispoof-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 : Defending TCP Against Spoofing Attacks Author(s) : J. Touch Filename : draft-ietf-tcpm-tcp-antispoof-05.txt Pages : 28 Date : 2006-10-23 Recent analysis of potential attacks on core Internet infrastructure indicates an increased vulnerability of TCP connections to spurious resets (RSTs), sent with forged IP source addresses (spoofing). TCP has always been susceptible to such RST spoofing attacks, which were indirectly protected by checking that the RST sequence number was inside the current receive window, as well as via the obfuscation of TCP endpoint and port numbers. For pairs of well-known endpoints often over predictable port pairs, such as BGP or between web servers and well-known large-scale caches, increases in the path bandwidth- delay product of a connection have sufficiently increased the receive window space that off-path third parties can brute-force generate a viable RST sequence number. The susceptibility to attack increases with the square of the bandwidth, thus presents a significant vulnerability for recent high-speed networks. This document addresses this vulnerability, discussing proposed solutions at the transport level and their inherent challenges, as well as existing network level solutions and the feasibility of their deployment. This document focuses on vulnerabilities due to spoofed TCP segments, and includes a discussion of related ICMP spoofing attacks on TCP connections. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-antispoof-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tcpm-tcp-antispoof-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tcpm-tcp-antispoof-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: <2006-10-23143246.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-tcp-antispoof-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-antispoof-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-23143246.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 Mon Oct 23 18:51:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc8dL-00060c-3u; Mon, 23 Oct 2006 18:51:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc8cr-0004VI-B5; Mon, 23 Oct 2006 18:50:33 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc8cr-0000WX-5C; Mon, 23 Oct 2006 18:50:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gc8cq-0000zj-R4; Mon, 23 Oct 2006 18:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 866E6175C0; Mon, 23 Oct 2006 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gc8cM-0004PJ-3w; Mon, 23 Oct 2006 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, 23 Oct 2006 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-ecnsyn-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org --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 : Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets Author(s) : A. Kuzmanovic, et al. Filename : draft-ietf-tcpm-ecnsyn-01.txt,.ps Pages : 16 Date : 2006-10-23 This draft specifies a modification to RFC 3168 to allow TCP SYN/ACK packets to be ECN-Capable. For TCP, RFC 3168 only specified setting an ECN-Capable codepoint on data packets, and not on SYN and SYN/ACK packets. However, because of the high cost to the TCP transfer of having a SYN/ACK packet dropped, with the resulting retransmit timeout, this document is specifying the use of ECN for the SYN/ACK packet itself, when sent in response to a SYN packet with the two ECN flags set in the TCP header, indicating a willingness to use ECN. Setting TCP SYN/ACK packets as ECN-Capable can be of great benefit to the TCP connection, avoiding the severe penalty of a retransmit timeout for a connection that has not yet started placing a load on the network. The sender of the SYN/ACK packet must respond to an ECN mark by reducing its initial congestion window from two, three, or four segments to one segment, reducing the subsequent load from that connection on the network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-ecnsyn-01.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-ecnsyn-01.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-ecnsyn-01.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: <2006-10-23160424.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-ecnsyn-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-ecnsyn-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-23160424.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 Wed Oct 25 15:53:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcon9-0006bG-0D; Wed, 25 Oct 2006 15:51:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcolJ-0003ov-PN; Wed, 25 Oct 2006 15:50:05 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcolH-0007pM-OX; Wed, 25 Oct 2006 15:50:05 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 7E60A328BD; Wed, 25 Oct 2006 19:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GcolH-0004qR-9k; Wed, 25 Oct 2006 15:50:03 -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, 25 Oct 2006 15:50:03 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-uto-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 User Timeout Option Author(s) : L. Eggert, F. Gont Filename : draft-ietf-tcpm-tcp-uto-04.txt Pages : 17 Date : 2006-10-25 This document specifies a new TCP option - the TCP User Timeout Option - that allows a TCP to advertise its current user timeout for a connection. Thus, the remote TCP may modify its local user timeout based on knowledge of the peer's user timeout. The TCP user timeout controls how long transmitted data may remain unacknowledged before a connection is forcefully closed. It is a local, per-connection parameter. Increasing the user timeouts allows established TCP connections to survive extended periods of disconnection. Decreasing the user timeouts allows busy servers to explicitly notify their clients that they will maintain the connection state only across short periods of disconnection. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-uto-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tcpm-tcp-uto-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tcpm-tcp-uto-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: <2006-10-25120628.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-tcp-uto-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-uto-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-25120628.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 Wed Oct 25 16:22:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcpG8-0008KU-9W; Wed, 25 Oct 2006 16:21:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcolK-0003qD-3C; Wed, 25 Oct 2006 15:50:06 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcolI-0007pp-JK; Wed, 25 Oct 2006 15:50:06 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 51AEC328C9; Wed, 25 Oct 2006 19:50:04 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GcolI-0004s9-6a; Wed, 25 Oct 2006 15:50:04 -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, 25 Oct 2006 15:50:04 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-icmp-attacks-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org --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-01.txt Pages : 39 Date : 2006-10-25 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-01.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-01.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-01.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: <2006-10-25133745.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-icmp-attacks-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-icmp-attacks-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-25133745.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 Oct 26 12:43:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd8Ji-0005IY-EL; Thu, 26 Oct 2006 12:42:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd8Jh-0005IT-6y for tcpm@ietf.org; Thu, 26 Oct 2006 12:42:53 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd8Jf-0004qr-SP for tcpm@ietf.org; Thu, 26 Oct 2006 12:42:53 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k9QGgoP5098486 for ; Thu, 26 Oct 2006 09:42:51 -0700 (PDT) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 4F12E3D56CF for ; Thu, 26 Oct 2006 12:43:47 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Ticket to Ride MIME-Version: 1.0 Date: Thu, 26 Oct 2006 12:43:47 -0400 Message-Id: <20061026164347.4F12E3D56CF@guns.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [tcpm] agenda for tcpm at ietf67 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="===============1967211848==" Errors-To: tcpm-bounces@ietf.org --===============1967211848== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Below is the preliminary agenda for the San Diego TCPM meeting. allman TCPM WG Agenda IETF 67 - San Diego, CA 1. Agenda bashing (2min) chairs 2. TCP Authentication draft-bellovin-tcpsec-00.txt Steve Bellovin 3. WG Status (10-15min) chairs 4. UTO (10-15min) draft-ietf-tcpm-tcp-uto-04.txt Fernando Gont or Lars Eggert 5. ICMP Attacks (10-15min) draft-ietf-tcpm-icmp-attacks-01.txt Fernando Gont --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFQOXDWyrrWs4yIs4RAgBPAJ4hLiidBuBhdc+f33kmeNrD7Npu+ACfVnxh bnpgmu4JU1gFIIkGuODXoMc= =+TSv -----END PGP SIGNATURE----- --=_bOundary-- --===============1967211848== 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 --===============1967211848==-- From tcpm-bounces@ietf.org Thu Oct 26 12:50:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd8Qv-0008Kv-7a; Thu, 26 Oct 2006 12:50:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd8Qt-0008KR-Fe for tcpm@ietf.org; Thu, 26 Oct 2006 12:50:19 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd8Qs-0006LQ-3O for tcpm@ietf.org; Thu, 26 Oct 2006 12:50:19 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k9QGoFCn098867 for ; Thu, 26 Oct 2006 09:50:17 -0700 (PDT) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id CBC283D5788 for ; Thu, 26 Oct 2006 12:51:11 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Ticket to Ride MIME-Version: 1.0 Date: Thu, 26 Oct 2006 12:51:11 -0400 Message-Id: <20061026165111.CBC283D5788@guns.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Subject: [tcpm] Re: agenda for tcpm at ietf67 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="===============0987452860==" Errors-To: tcpm-bounces@ietf.org --===============0987452860== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Now some annotations for the agenda to help frame the discussions better. > 1. Agenda bashing (2min) > chairs > > 2. TCP Authentication > draft-bellovin-tcpsec-00.txt > Steve Bellovin The real question we need to answer here is whether we want to / need to do authentication in TCP. There are a couple of concrete proposals on the table for actually doing tcp-auth, but we want this discussion to be at a higher-level: *should* we do it? Steve has done a very short I-D on the topic. (If the answer is that the WG wants to do this work, Ted and I have hammered out a process, that the ADs agreed with, that involves using a design team to produce a WG document that will start the WG's work on tcp-auth. This document may or may not draw from the concrete proposals. But, this is getting ahead of ourselves....we first need to figure out if this is something the WG thinks is valuable and has energy to work on.) > 3. WG Status (10-15min) > chairs This is after the first discussion because Steve needs to get to another WG meeting. > 4. UTO (10-15min) > draft-ietf-tcpm-tcp-uto-04.txt > Fernando Gont or Lars Eggert This seems to be closing in on WGLC time. We just want to allow anyone with comments a chance to voice them. The hope is that this will be the last chance for that in a f2f setting. > 5. ICMP Attacks (10-15min) > draft-ietf-tcpm-icmp-attacks-01.txt > Fernando Gont Key question on the table here is whether this should be an informational document or whether it should be standards track. Please read the documents and come prepared to discuss. (Or, throw thoughts onto the list, of course.) allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFQOd/WyrrWs4yIs4RAqJTAKCLaC56d5cQkxQcFqf9DpHCILq9SACdF27R z21tkRxF/l597O0Oy61/AKs= =9SPD -----END PGP SIGNATURE----- --=_bOundary-- --===============0987452860== 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 --===============0987452860==--