From tcpm-bounces@ietf.org Sat Oct 01 00:35:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELZ5j-0001fs-1Y; Sat, 01 Oct 2005 00:35:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELZ5h-0001fn-4c for tcpm@megatron.ietf.org; Sat, 01 Oct 2005 00:35:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09884 for ; Sat, 1 Oct 2005 00:35:14 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELZDf-0000rM-RO for tcpm@ietf.org; Sat, 01 Oct 2005 00:43:33 -0400 Received: from [128.9.176.133] (ras33.isi.edu [128.9.176.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j914XlL03373; Fri, 30 Sep 2005 21:33:47 -0700 (PDT) Message-ID: <433E11AA.5010109@isi.edu> Date: Fri, 30 Sep 2005 21:33:46 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lloyd Wood Subject: Re: [tcpm] ICMP attacks draft (issue 1): hard errors -> soft errors (in synchronized states) References: <6.2.0.14.0.20050923075214.0428faa8@pop.frh.utn.edu.ar> <433411E2.3020005@isi.edu> <6.2.0.14.0.20050923125332.04320008@pop.frh.utn.edu.ar> <20050923165017.GD10959@pun.isi.edu> <6.2.0.14.0.20050927015438.07c2a418@pop.frh.utn.edu.ar> <20050930174011.GK999@pun.isi.edu> <6.2.0.14.0.20050930150854.0592eee0@pop.frh.utn.edu.ar> <433D85BD.4020204@isi.edu> <6.2.0.14.0.20050930155718.05963118@pop.frh.utn.edu.ar> <433D9685.5080501@isi.edu> In-Reply-To: X-Enigmail-Version: 0.92.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: 4b800b1eab964a31702fa68f1ff0e955 Cc: tcpm@ietf.org, Ted Faber , Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1658467355==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1658467355== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0AAC02F820BE123A4BAE3250" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0AAC02F820BE123A4BAE3250 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Lloyd Wood wrote: > On Fri, 30 Sep 2005, Joe Touch wrote: > >>Fernando Gont wrote: >> >>>At 03:36 p.m. 30/09/2005, Joe Touch wrote: >> >>... >> >>>>>"The strength of a chain is that of the weakest link", I mean. >>>> >>>>But TCP-antispoof explains that the chain is already sufficiently weak >>>>in many cases even if you try to fix ICMP. >>> >>>It's weak. But we are making it weaker unnecessarily. >> >>What's weaker than weak enough? (and why would we need to modify a core >>Internet protocol if it's still weak enough)? > > Using bad rhetoric and word games against someone with English as a > second language is bad form. My reply wasn't intended as either, and although it still doesn't seem that way upon re-reading, offense is in the eye of the beholder, so my apologies to you both if it was taken that way. TCP is - and will remain - weak enough for attacks to happen for two reasons: 1) attackers need to guess the ports as well as endpoints this is viable for long-lived connections with that persist for long times among widely-known systems 2) 'widely known' implies infrastructure, which is usually connected at fairly high bandwidth, which means they are susceptible, for other reasons in #1 a well, to "in window" attacks (either ICMP or data injection) > Strengthening ICMP and TCP where reasonable and possible seem entirely > sensible to me and in line with the mandate of this workgroup. If it were, we'd be in the security area, or at least cross-area. "Strength" means security to me, as does the title of this and some other drafts, and validity checks don't make a solution solution "secure" or even "more secure". Joe --------------enig0AAC02F820BE123A4BAE3250 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.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDPhGqE5f5cImnZrsRAsf6AKCTO5KesaqM4hDUPWxDazEMdfcOzACgvFe4 IMcPMzxLrtLRb3RBYa7LBrc= =bb2i -----END PGP SIGNATURE----- --------------enig0AAC02F820BE123A4BAE3250-- --===============1658467355== 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 --===============1658467355==-- From tcpm-bounces@ietf.org Sat Oct 01 01:34:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELa1R-0003jk-Fq; Sat, 01 Oct 2005 01:34:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELa1P-0003iw-WF for tcpm@megatron.ietf.org; Sat, 01 Oct 2005 01:34:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11610 for ; Sat, 1 Oct 2005 01:34:54 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELa9O-00025I-6f for tcpm@ietf.org; Sat, 01 Oct 2005 01:43:12 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j915YIr31801; Sat, 1 Oct 2005 08:34:18 +0300 Date: Sat, 1 Oct 2005 08:34:18 +0300 (EEST) From: Pekka Savola To: Joe Touch Subject: tcpm-antispoof and TCP's weakness [Re: [tcpm] ICMP attacks draft (issue 1): hard errors -> soft errors (in synchronized states)] In-Reply-To: <433D85BD.4020204@isi.edu> Message-ID: References: <6.2.0.14.0.20050923075214.0428faa8@pop.frh.utn.edu.ar> <433411E2.3020005@isi.edu> <6.2.0.14.0.20050923125332.04320008@pop.frh.utn.edu.ar> <20050923165017.GD10959@pun.isi.edu> <6.2.0.14.0.20050927015438.07c2a418@pop.frh.utn.edu.ar> <20050930174011.GK999@pun.isi.edu> <6.2.0.14.0.20050930150854.0592eee0@pop.frh.utn.edu.ar> <433D85BD.4020204@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: tcpm@ietf.org, Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Fri, 30 Sep 2005, Joe Touch wrote: >> "The strength of a chain is that of the weakest link", I mean. > > But TCP-antispoof explains that the chain is already sufficiently weak > in many cases even if you try to fix ICMP. While you as an editor of a WG document may have such an individual opinion, I didn't get that impression from the draft, and I'd like to see the draft changed if that was the intended tone. While the TCP's security (not considering ICMPs) is not very strong, I do not think it can be classified as "weak" either, especially in scenarios where certain insecurities of IP (e.g., source address spoofing) can be eliminated. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Oct 01 23:53:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELuuQ-0002vj-PB; Sat, 01 Oct 2005 23:53:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELuuH-0002tl-1G for tcpm@megatron.ietf.org; Sat, 01 Oct 2005 23:53:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11932 for ; Sat, 1 Oct 2005 23:52:53 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELv2S-00080H-AO for tcpm@ietf.org; Sun, 02 Oct 2005 00:01:25 -0400 Received: from [128.9.176.133] (ras33.isi.edu [128.9.176.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j923psL21815; Sat, 1 Oct 2005 20:51:54 -0700 (PDT) Message-ID: <433F5958.5070408@isi.edu> Date: Sat, 01 Oct 2005 20:51:52 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola Subject: Re: tcpm-antispoof and TCP's weakness [Re: [tcpm] ICMP attacks draft (issue 1): hard errors -> soft errors (in synchronized states)] References: <6.2.0.14.0.20050923075214.0428faa8@pop.frh.utn.edu.ar> <433411E2.3020005@isi.edu> <6.2.0.14.0.20050923125332.04320008@pop.frh.utn.edu.ar> <20050923165017.GD10959@pun.isi.edu> <6.2.0.14.0.20050927015438.07c2a418@pop.frh.utn.edu.ar> <20050930174011.GK999@pun.isi.edu> <6.2.0.14.0.20050930150854.0592eee0@pop.frh.utn.edu.ar> <433D85BD.4020204@isi.edu> In-Reply-To: X-Enigmail-Version: 0.92.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: 0a7aa2e6e558383d84476dc338324fab Cc: tcpm@ietf.org, Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1094329119==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1094329119== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB7E47C8859BEF939155BEA48" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB7E47C8859BEF939155BEA48 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Pekka Savola wrote: > On Fri, 30 Sep 2005, Joe Touch wrote: > >>> "The strength of a chain is that of the weakest link", I mean. >> >> >> But TCP-antispoof explains that the chain is already sufficiently weak >> in many cases even if you try to fix ICMP. > > > While you as an editor of a WG document may have such an individual > opinion, I didn't get that impression from the draft, and I'd like to > see the draft changed if that was the intended tone. My sentence above should have implied "whether you fix ICMP or not". I do feel that's the case, but I agree that the doc didn't address that - mostly because this issue wasn't the focus of that doc. If it is agreed, I'd be glad to add that or something to that effect. > While the TCP's security (not considering ICMPs) is not very strong, I > do not think it can be classified as "weak" either, especially in > scenarios where certain insecurities of IP (e.g., source address > spoofing) can be eliminated. Cases where source address spoofing can be eliminated amount to real security, either by signatures or by trusted edge filtering. I would conclude that TCP doesn't have security (because it doesn't), and that this weakness can be made strong by using real security (TCP/MD5, IPsec). These help ICMP only where the entire payload is included in the ICMP reply - which goes back to the point I made earlier about validation needing to do the same thing, BTW. Joe --------------enigB7E47C8859BEF939155BEA48 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.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDP1lZE5f5cImnZrsRAoeAAJ47gRozkyqudiRvmTJSMq8DpMuh8gCg90ZR PplCOLAPpBVJaf0oVze0kRo= =1NhW -----END PGP SIGNATURE----- --------------enigB7E47C8859BEF939155BEA48-- --===============1094329119== 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 --===============1094329119==-- From tcpm-bounces@ietf.org Mon Oct 03 06:26:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMNWR-0008Ls-7i; Mon, 03 Oct 2005 06:26:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMNWQ-0008Ln-Cn for tcpm@megatron.ietf.org; Mon, 03 Oct 2005 06:26:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18686 for ; Mon, 3 Oct 2005 06:26:12 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMNeq-0002VB-UF for tcpm@ietf.org; Mon, 03 Oct 2005 06:34:59 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j93APSj24594; Mon, 3 Oct 2005 13:25:29 +0300 Date: Mon, 3 Oct 2005 13:25:28 +0300 (EEST) From: Pekka Savola To: Joe Touch Subject: Re: tcpm-antispoof and TCP's weakness [Re: [tcpm] ICMP attacks draft (issue 1): hard errors -> soft errors (in synchronized states)] In-Reply-To: <433F5958.5070408@isi.edu> Message-ID: References: <6.2.0.14.0.20050923075214.0428faa8@pop.frh.utn.edu.ar> <433411E2.3020005@isi.edu> <6.2.0.14.0.20050923125332.04320008@pop.frh.utn.edu.ar> <20050923165017.GD10959@pun.isi.edu> <6.2.0.14.0.20050927015438.07c2a418@pop.frh.utn.edu.ar> <20050930174011.GK999@pun.isi.edu> <6.2.0.14.0.20050930150854.0592eee0@pop.frh.utn.edu.ar> <433D85BD.4020204@isi.edu> <433F5958.5070408@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: tcpm@ietf.org, Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Sat, 1 Oct 2005, Joe Touch wrote: > Cases where source address spoofing can be eliminated amount to real > security, either by signatures or by trusted edge filtering. > > I would conclude that TCP doesn't have security (because it doesn't), > and that this weakness can be made strong by using real security > (TCP/MD5, IPsec). Ack/seq may not be exactly 'strong', but it's still something. Regardless of that 'real security' are generic solutions, and may not be needed in all the cases. > These help ICMP only where the entire payload is > included in the ICMP reply - which goes back to the point I made earlier > about validation needing to do the same thing, BTW. Trusted edge filtering is good security. An ISP or an enterprise could (and in fact _do_) perform that. Spoofed TCP attacks inside such a network are prevented -- but ICMP offers a gaping hole. Ergo, if the IETF believes this scenario is sufficiently common and/or convincing, this needs to be fixed (and it may make sense to fix it in any case). It should be obvious, but IMHO this scenario calls for a specific solution, not just 'use IPsec'. A majority of networks have prevented spoofing already [http://spoofer.csail.mit.edu/], and internal protection from ICMP attacks is required. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Oct 03 15:50:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMWKs-0002ZJ-EB; Mon, 03 Oct 2005 15:50:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMWK5-0002Kn-Dt; Mon, 03 Oct 2005 15:50:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27919; Mon, 3 Oct 2005 15:50:03 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMWSa-00023C-Oi; Mon, 03 Oct 2005 15:58:53 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EMWK2-0006Lh-Ia; Mon, 03 Oct 2005 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, 03 Oct 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-roadmap-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: , Sender: tcpm-bounces@ietf.org 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 : A Roadmap for TCP Specification Documents Author(s) : M. Duke, et al. Filename : draft-ietf-tcpm-tcp-roadmap-05.txt Pages : 41 Date : 2005-10-3 This document contains a "roadmap" to the Requests for Comments (RFC) documents relating to the Internet's Transmission Control Protocol (TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-roadmap-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-roadmap-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-roadmap-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: <2005-10-3133128.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-tcp-roadmap-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-roadmap-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-3133128.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --NextPart-- From tcpm-bounces@ietf.org Tue Oct 04 11:00:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMoHe-0001Ca-3Q; Tue, 04 Oct 2005 11:00:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMoHc-0001C9-RM for tcpm@megatron.ietf.org; Tue, 04 Oct 2005 11:00:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26334 for ; Tue, 4 Oct 2005 11:00:42 -0400 (EDT) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMoQG-0003oI-VG for tcpm@ietf.org; Tue, 04 Oct 2005 11:09:44 -0400 Received: from venus.office (chiba.netlab.nec.de [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 5C0E814FEB for ; Tue, 4 Oct 2005 17:00:23 +0200 (CEST) Received: from n-eggert.office ([10.1.1.112]) by venus.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Oct 2005 17:00:23 +0200 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n-eggert.office (Postfix) with ESMTP id 9CB0F2BB2BA for ; Tue, 4 Oct 2005 17:00:23 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v734) To: tcpm@ietf.org Message-Id: <8D9932F9-7F89-4AB0-AB92-4C54527A15A7@netlab.nec.de> From: Lars Eggert Date: Tue, 4 Oct 2005 17:00:21 +0200 X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 04 Oct 2005 15:00:23.0277 (UTC) FILETIME=[588761D0:01C5C8F4] X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Subject: [tcpm] Abolade Gbadegesin's UTO comments at the Paris IETF mtg 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="===============1265332955==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1265332955== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8--193033257; protocol="application/pkcs7-signature" --Apple-Mail-8--193033257 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hi, (was trying to clarify this with Abolade off-list, but I can't track an email address down for him; I hope he's lurking or someone can forward it to him. I'm interested in other people's feedback on this as well, and may send some more messages as I go through the remaining UTO issues from Paris.) Abolade: I'm sorry it has taken me a while to get back to working on the UTO draft. You had some interesting comments at the Paris meeting that I never responded to. This bit below is from the meeting minutes: > AG: How does knowing the other end's timeout help me cope with > events? All that matters is my own timer. > > Knowing the other end's timeout is of no use if I don't know that > the other end has begun trying to send something to me. Typically, > the only way to know the other end has begun trying to send > something is if there's an upper layer protocol which gives me that > information. But if I'm relying on an upper layer protocol to tell > me when I should be expecting something from the other end, I may > as well rely on that upper layer protocol to tell me the timeout as > well. And in that case, I don't need UTO in the TCP layer. Does this accurately summarize your comment? If so, you seem to be concerned about the receive timeout (SO_RCVTIMEO sockopt on some stacks). This isn't the point of the UTO draft, because AFAIK the TCP spec doesn't include this sockopt at all. The UTO drafts is solely about the transmit user timout (SO_SNDTIMEO sockopt on some stacks). The next update will clarify that and also explain that if the stack implements something like SO_RCVTIMEO, it also needs adaptation. But since that timer is not in the TCP spec (or I am unable to locate it), I'm not sure we can change its behavior. Or am I completely misunderstanding you? Thanks, Lars -- Lars Eggert NEC Network Laboratories --Apple-Mail-8--193033257 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKgzCCAyAw ggKJoAMCAQICAw9TWTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE4MTAyOTU2WhcNMDYwODE4MTAyOTU2WjBgMQ8wDQYDVQQE EwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA2gsuG8tAmM6U2ESsQjhcijJSq6oDG2c+KvvXJ/xcJXbSIOY8IInezIP0DP41H0gxwHNv AyOuwM6nh0r2wOhzdr77GlKXiij0LoFOpurScPKsC9KTykGAfZtAuCnWIRdDo67Urcw1e306yYgK xF1UzYwGamLalPjejQTRcjLPIbzM4c7fUN/sxmpkpzT2p6OCJDyPhBfSaZWtv3UEoKF+xssNYzOF DRCTHcLc3iXgF7z7J0ud8maUAadfb/25Gm7tJHzBOEonMPkHx2N8Ci0qNce0MMH/LVOVQlNO5kYJ vUJiT0du7LAo/hf8tq3luZrh/Cwc/313x6oKYVuHDBllrQIDAQABo2IwYDAqBgUrZQEEAQQhMB8C AQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCQGA1UdEQQdMBuBGWxhcnMuZWdnZXJ0QG5l dGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAovojiq8758E/78nMS vNvD4359F8XAICzWbhz6cXJaGzv1FJoQcV/RY1x6CQZDt9PqiPiqyQX+xLvqicmEURbGU5+aiWj2 usovQXd+Ts8Doj3tbjk35nD7Etc8a2+Y9fQRUS6spzgJr0fcq2FMYbDnOtf71Bn77KgckoUbIszu mTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl ZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNa LIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1Ud HwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVs Mi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa 9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggQYMIIDgaADAgECAgEAMA0G CSqGSIb3DQEBBQUAMIG/MQswCQYDVQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVy ZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsT FE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkq hkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGUwHhcNMDQwNjE4MTE1MzA4WhcNMDkw NjE3MTE1MzA4WjCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcx EzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExRO ZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZI hvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQC0OQwsE86Rrt0Zs0GOCsYmkGpPwcCFvVpOijIPv1dGolr5a8+7hXSAgRlUyoclq9xfhsUT wlU1qkvVRD3/QOfQyPUxQktxba2ksfsPAKUHovInWydC6rvLU89jtYGEdnRCyA+cEB/XcSADbd2z 9/XK4A2cxmMQiYpXIphYQAxIBwIDAQABo4IBIDCCARwwHQYDVR0OBBYEFOh7L9eqGHnAhbJdO4PY LYzxCaNNMIHsBgNVHSMEgeQwgeGAFOh7L9eqGHnAhbJdO4PYLYzxCaNNoYHFpIHCMIG/MQswCQYD VQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVy ZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVz MRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0 QG5ldGxhYi5uZWMuZGWCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQCX6Ipd3AF9 3FDzBaw3ZVvQzzCv/kGPBBzzrJ3n5u+4eQppmOifhuWHZfb8h8S++jqcoPHGVjjlP5PaFb+wL0NR piBalRclikD3xIY/hFoxJ1AHCO0AzfFxEflO10b4+smMrBYJtk5d9EAhr5hEgoGCM7QijBtnCwZB KLI9pFgW1zGCA6UwggOhAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMPU1kwCQYFKw4DAhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDUxMDA0MTUwMDIyWjAjBgkqhkiG9w0BCQQxFgQUSqiw3aM7AYNgwEFJEdpE uAK7KZ8wgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA BIIBAB0EtYqmaHhxEQ7RGL7byJ/MVnSLc58WcXwED0DT4BOc82PnQrTmHr55PTCY9iMiNR+rUpCQ ejhWQ2jgfv7oXG9ihX2mCxTZtKqbEAFIL8HDZRYGeZpyoyBQMcI9HjBWxFKc7MyZVuAdwvwT+wrp vOBFVVKeeS1USFPIV3uA90yh6vKkkrt2GQrRmYYXdTnMPdQ6ElwGkXx4yAioacbWBIF7CZVUpXOc TX3qUtqkpNTpdZo5AgNQyIvD0DkleuMYLEW6kQAUMDXnIriDUUjmG60PbcDnkSBGYGVX+5ZNO0j4 0JRZ+k1S+AK2/dYwiUeWi6ShhQ7JkKWr5Q8YegA2xnwAAAAAAAA= --Apple-Mail-8--193033257-- --===============1265332955== 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 --===============1265332955==-- From tcpm-bounces@ietf.org Wed Oct 05 16:11:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENFc2-0000ok-B0; Wed, 05 Oct 2005 16:11:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENCM4-0004qY-UE for tcpm@megatron.ietf.org; Wed, 05 Oct 2005 12:42:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03402 for ; Wed, 5 Oct 2005 12:42:53 -0400 (EDT) Received: from mole.icir.org ([192.150.187.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENCUy-0000dX-F8 for tcpm@ietf.org; Wed, 05 Oct 2005 12:52:10 -0400 Received: from lawyers.icir.org (mole.icir.org [192.150.187.34]) by mole.icir.org (8.12.11/8.12.11) with ESMTP id j95Ggn2m050321 for ; Wed, 5 Oct 2005 09:42:50 -0700 (PDT) (envelope-from mallman@icir.org) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 6D61C362C03 for ; Wed, 5 Oct 2005 12:42:26 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Moondance MIME-Version: 1.0 Date: Wed, 05 Oct 2005 12:42:26 -0400 Message-Id: <20051005164226.6D61C362C03@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [tcpm] updated reaction to spurious timeouts 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="===============1155134631==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1155134631== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Folks- Based on some feedback from this group and some further thinking we have revised our i-d on tweaking the RTO in response to spurious RTOs. The new version is: Title : Using Spurious Retransmissions to Adapt the Retransmission Timeout Author(s) : M. Allman, et al. Filename : draft-allman-rto-backoff-01.txt Pages : 7 Date : 2005-10-4 http://www.ietf.org/internet-drafts/draft-allman-rto-backoff-01.txt The biggest technical change is that we recommend using the standard RTO and not using the adapted RTO when the cwnd is <= 4 segments. The motivation for this is that (a) this is the regime where RTOs are "expected" when loss occurs and so delaying RTOs in this area may be more likely to delay needed retransmits and (b) RTOs that happen in this region have little downside, even if they are spurious (i.e., the cwnd is not reduced all that much and there isn't all that much needless go-back-n going on since the window is small). We'd be interested in hearing what people think about this i-d. And, in particular, we'd like to make it a WG item and see about publishing it as an RFC. (My co-chair hat is, of course, off in asserting this.) Thanks! allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFDRAJxWyrrWs4yIs4RAkR3AJ9sOS7xxCyVwjVDXRu0PMwSoqJv4QCcDVbF u7KOmwOCpXShNwacDdWvEyU= =0pBG -----END PGP SIGNATURE----- --=_bOundary-- --===============1155134631== 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 --===============1155134631==-- From tcpm-bounces@ietf.org Sat Oct 08 20:00:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOOcL-00017Y-1j; Sat, 08 Oct 2005 20:00:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOOcJ-00017P-Nq for tcpm@megatron.ietf.org; Sat, 08 Oct 2005 20:00:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20917 for ; Sat, 8 Oct 2005 20:00:38 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOOlr-00062v-AK for tcpm@ietf.org; Sat, 08 Oct 2005 20:10:34 -0400 Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net [71.106.130.244]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j98NxWL26564; Sat, 8 Oct 2005 16:59:32 -0700 (PDT) Message-ID: <43485D5D.7040208@isi.edu> Date: Sat, 08 Oct 2005 16:59:25 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola References: <4210B534.1010302@isi.edu> <426ED950.2010404@isi.edu> In-Reply-To: X-Enigmail-Version: 0.92.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: 52f7a77164458f8c7b36b66787c853da Cc: tcpm@ietf.org Subject: [tcpm] Re: draft-ietf-tcpm-tcp-antispoof-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: , Content-Type: multipart/mixed; boundary="===============0765061763==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0765061763== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig596E338B7CEB4BD42B81E247" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig596E338B7CEB4BD42B81E247 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit In advance of submitting an update, some notes below. All others have been incorporated (to the best of my ability, at least): Pekka Savola wrote: ... > [on GTSM] > This restricts traffic > to one hop upstream of the receiver, but those hops could include > other user programs at those nodes or any traffic those nodes accept > via tunnels - because tunnels need not decrement TTLs [26]. > > ==> I assume _those nodes_ in "those nodes accept via tunnels" refers to > your peers. If so, this doesn't seem 100% correct, because IP tunneling > solutions do decrement the hop limit when they forward traffic out from the > tunnel. (There is extensive discussion of this in the security > considerations of the GTSM spec.) The GTSM spec also notes cases where this fails, which are the ones I'm referring to (end sec 5.1), and which I'll cite more directly. > 8.1. Normative References > > As this is not a standards document, this section has no meaning. > > ==> Normative means more than just what's what's MUST or MUST not for a > standard document. It also means 1) "documents which should be read and > understood by the reader of this document in order to understand this > document" and 2) "documents which should be published as stable references > before this document gets published as RFC". > > I think there are a number of references in category 1). There are also a > couple of others in category 2),e.g., tcpmd5app-01, ikev2/AH, dccp. Although I personally agree with you (esp. w.r.t. #1) I've had this debate before, and my understanding is that "normative" in the IETF means "refers to a standard to enable a a specificiation". Since this isn't a spec (standards track), there can be no normative refs. If that's not the case, however, somebody in authority holler. ;-) My original wording was a bit sarcastic in response to that understanding, so it has been downgraded to 'None.' Joe --------------enig596E338B7CEB4BD42B81E247 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.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDSF1dE5f5cImnZrsRAsm9AJwI8/nKydutle1Wr6y+Hgz2ZYZ4dgCfb0dw 6zNn2vPq8ximvLMJXhjGQ0I= =TtGW -----END PGP SIGNATURE----- --------------enig596E338B7CEB4BD42B81E247-- --===============0765061763== 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 --===============0765061763==-- From tcpm-bounces@ietf.org Sat Oct 08 20:21:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOOwQ-0004ua-Ou; Sat, 08 Oct 2005 20:21:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOOwP-0004uR-Qp for tcpm@megatron.ietf.org; Sat, 08 Oct 2005 20:21:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21611 for ; Sat, 8 Oct 2005 20:21:24 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOP60-0006Ve-K3 for tcpm@ietf.org; Sat, 08 Oct 2005 20:31:21 -0400 Received: from [128.9.176.132] (ras32.isi.edu [128.9.176.132]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j990KML01293; Sat, 8 Oct 2005 17:20:22 -0700 (PDT) Message-ID: <43486246.2000400@isi.edu> Date: Sat, 08 Oct 2005 17:20:22 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'tcpm@ietf.org'" X-Enigmail-Version: 0.92.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: b19722fc8d3865b147c75ae2495625f2 Subject: [tcpm] update to draft-ietf-tcpm-tcp-antispoof-02.txt available 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="===============1292049654==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1292049654== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4C5FC8563FFAD7C1714593FA" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4C5FC8563FFAD7C1714593FA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Until it reaches the usual places, it can be accessed at: http://www.isi.edu/touch/pubs/draft-ietf-tcpm-tcp-antispoof-02.txt All known feedback incorporated, including Pekka's recent suggestion about addressing ICMP briefly (let me know if that's a keeper or not). I'd like to get any significant feedback ASAP, so I can adjust in time for the I-D deadline, since this should be ready to wrap up very soon. Joe --------------enig4C5FC8563FFAD7C1714593FA 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.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDSGJGE5f5cImnZrsRAqG8AKCDWdJczwVeqc+/jBm/VmTkrhCVZwCglIpj j97NuvszA+njtbkg6vWleOA= =U0h1 -----END PGP SIGNATURE----- --------------enig4C5FC8563FFAD7C1714593FA-- --===============1292049654== 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 --===============1292049654==-- From tcpm-bounces@ietf.org Mon Oct 10 10:51:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOyzb-0007EW-H4; Mon, 10 Oct 2005 10:51:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOyyc-0006wK-K1; Mon, 10 Oct 2005 10:50:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15445; Mon, 10 Oct 2005 10:50:04 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOz8U-0007J1-Gl; Mon, 10 Oct 2005 11:00:19 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EOyyY-0005jf-8y; Mon, 10 Oct 2005 10:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 10 Oct 2005 10:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-antispoof-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: , Sender: tcpm-bounces@ietf.org 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-02.txt Pages : 25 Date : 2005-10-10 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 guess a viable RST sequence number. The susceptibility to attack increases as 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-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-antispoof-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-antispoof-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: <2005-10-10100624.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-tcp-antispoof-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-antispoof-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-10100624.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 20 07:13:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESYM0-0007kv-Nf; Thu, 20 Oct 2005 07:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESYLz-0007kq-EQ for tcpm@megatron.ietf.org; Thu, 20 Oct 2005 07:12:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02691 for ; Thu, 20 Oct 2005 07:12:47 -0400 (EDT) Received: from net.infocom.uniroma1.it ([151.100.37.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESYXp-00044n-6w for tcpm@ietf.org; Thu, 20 Oct 2005 07:25:17 -0400 Received: from [151.100.37.109] (unknown [151.100.37.109]) by net.infocom.uniroma1.it (Postfix) with ESMTP id 0474437FF3; Thu, 20 Oct 2005 13:19:39 +0200 (CEST) Message-ID: <43577F13.8090207@net.infocom.uniroma1.it> Date: Thu, 20 Oct 2005 13:27:15 +0200 From: Francesco Vacirca User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tcpm@ietf.org Subject: Re: [tcpm] a different scheme for reacting to spurious RTOs References: <20050826172926.EA16D77AA1D@guns.icir.org> <1126086947.29615.30.camel@siddha.research.nokia.com> In-Reply-To: <1126086947.29615.30.camel@siddha.research.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Cc: weddy@grc.nasa.gov 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Maybe you are interested in this technical report: TCP Spurious Timeout estimation in an operational GPRS/UMTS network http://userver.ftw.at/~ziegler/FTW-TR-2005-008.pdf We deployed an algorithm to estimate spurious timeout retransmissions by passive monitoring that it is based on similar assumptions of F-RTO and reported the results on several day traces. The report is based on measurements made in the UMTS and GPRS networks of Mobilkom Austria, EU. regards, Francesco Pasi Sarolahti wrote: > On Fri, 2005-08-26 at 13:29 -0400, ext Mark Allman wrote: > >>We'd very much appreciate comments on the draft, which >>is: >> >> Mark Allman, Ethan Blanton, Josh Blanton. Using Spurious >> Retransmissions to Adapt the Retransmission Timeout. August >> 2005. Internet-Draft draft-allman-rto-backoff-00.txt (work in >> progress). >> http://www.icir.org/mallman/papers/draft-allman-rto-backoff-00.txt > > > Thanks for writing this draft. I think it's good to have more > alternatives for the response algorithm (at least until the WG can find > a consensus on a standard way of doing the response), as implementors > might have different criteria for selecting a suitable algorithm. Some > comments and thoughts below. > > I think there is one remarkable difference between the methods in RFC > 4015 and this draft that needs to be emphasized more clearly in the > introduction: In addition to restoring the sending rate, RFC 4015 also > tries to avoid unnecessary go-back-N retransmissions after spurious > timeout. This draft, on the other hand, does not change the > retransmission sequence, and hence does not avoid unnecessary > retransmissions in case a spurious timeout occurs. Actually, this > might be something that could also be mentioned in the disadvantages > section. It is not a disadvantage relative to the standard TCP, but it > is a disadvantage when comparing this algorithm for example to RFC > 4015. > > How about considering possibility of bounding K somehow, rather than > letting it increase indefinitely? While sometimes the blocked state > can be really long, there also are occasions where RTO is really > needed to recover from a bursty data loss, even with SACK in use ([1] > is a nice paper describing observed behavior in GPRS network). So if > there happened to be an exceptionally long delay spike, but also RTOs > caused by packet losses, the total performance (from the sender's > perspective) could be worse with this response than with TCP that does > not detect spurious timeouts, even in environment that has motivated > much of the spurious RTO work. I don't know what could be appropriate > way to limit K: just a fixed, configurable value, or by some adaptive > method. > > Btw, there is an empty "[]" in the end of Section 1. I believe you > have forgot to add a citation ref. there. > > - Pasi > > > [1] A. Gurtov, M. Passoja, O. Aalto, and M. Raitola. "Multi-Layer > Protocol Tracing in a GPRS Network", In Proceedings of the IEEE > Vehicular Technology Conference (Fall VTC2002), Vancouver, Canada, > Sepember 2002. > http://www.cs.helsinki.fi/u/gurtov/papers/vtc02.html > > > > ------------------------------------------------------------------------ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Oct 20 12:15:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESd4P-0007zg-HK; Thu, 20 Oct 2005 12:15:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESd4N-0007za-J8 for tcpm@megatron.ietf.org; Thu, 20 Oct 2005 12:15:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26364 for ; Thu, 20 Oct 2005 12:14:58 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESdGK-0007P5-Pc for tcpm@ietf.org; Thu, 20 Oct 2005 12:27:30 -0400 Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9KGE8L25463 for ; Thu, 20 Oct 2005 09:14:09 -0700 (PDT) Received: (from faber@localhost) by pun.isi.edu (8.13.4/8.13.4/Submit) id j9KGE8x6036852 for tcpm@ietf.org; Thu, 20 Oct 2005 09:14:08 -0700 (PDT) (envelope-from faber) Date: Thu, 20 Oct 2005 09:14:08 -0700 From: Ted Faber To: tcpm@ietf.org Message-ID: <20051020161408.GD35202@pun.isi.edu> Mime-Version: 1.0 User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@pun.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [tcpm] agenda requests 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="===============1620886401==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1620886401== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cQXOx3fnlpmgJsTP" Content-Disposition: inline --cQXOx3fnlpmgJsTP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Mark ana I are putting together the TCPM agenda for Vancouver, assuming we can work the new load-it-yourself agenda interface. Please send us a note if you're interested in getting some time on teh agenda in Vancouver. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --cQXOx3fnlpmgJsTP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDV8JQaUz3f+Zf+XsRAo4CAKDqe8cp14tLuh85REVlSahA25HNXgCgpK3O xsBs1quj6yPMKWW8LBKpE88= =PGWf -----END PGP SIGNATURE----- --cQXOx3fnlpmgJsTP-- --===============1620886401== 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 --===============1620886401==-- From tcpm-bounces@ietf.org Sun Oct 23 09:51:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETgFk-0001qr-Ll; Sun, 23 Oct 2005 09:51:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETgFj-0001qj-Ts; Sun, 23 Oct 2005 09:51:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05482; Sun, 23 Oct 2005 09:50:59 -0400 (EDT) Received: from f112.brocade.com ([66.243.153.112] helo=blasphemy.brocade.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETgSH-0002FT-E9; Sun, 23 Oct 2005 10:04:10 -0400 Received: from hq-e2k3-1.corp.brocade.com (hq-e2k3-1 [192.168.38.39]) by blasphemy.brocade.com (Postfix) with ESMTP id 581E8142C7; Sun, 23 Oct 2005 06:50:54 -0700 (PDT) Received: from hq-ex-6.corp.brocade.com ([192.168.38.36]) by hq-e2k3-1.corp.brocade.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 23 Oct 2005 06:50:54 -0700 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 23 Oct 2005 06:50:53 -0700 Message-ID: <447BB19E14004A4388CB9A864D2BA7630DB0FB@hq-ex-6.brocade.com> Thread-Topic: [tcpm] a different scheme for reacting to spurious RTOs Thread-Index: AcXVZ6JRUuw9jOOQTFqwq3wB5nxqtQCb9Ycg From: "Indraneel Ghosh" To: X-OriginalArrivalTime: 23 Oct 2005 13:50:54.0233 (UTC) FILETIME=[C96F0090:01C5D7D8] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Cc: tcpm-bounces@ietf.org, Indraneel Ghosh Subject: [tcpm] Sequence number checking for incoming RST segments 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Hi, I had a question regarding the sequence-number check for acceptance of = incoming RST segments. It seems that some TCP stacks (e.g. the Linux = stack shown below) apply a different sequence number check to RST = segments, than what is specified in RFC793 i.e. the {RCV.NXT, = RCV.NXT+RCV.WND} check=20 If someone is familiar with this, could you pls send me an email = mentioning what RCV.WUP means exactly (I was guessing that it was the = last ACK sent by the local i.e. receiving device). Also, what is the commonly-accepted sequence-number check for incoming = RST segments, in case the check in RFC793 is seen as inappropriate for = RST segments (is there any RFC/other-doc that discusses this) ? Sorry for asking this question here, in case this is not the = appropriate forum. Thanks in advance for any help, Indraneel=20 http://www.cs.purdue.edu/homes/fahmy/software/flowmate/tcp_input.c =20 /* Check segment sequence number for validity. * * Segment controls are considered valid, if the segment * fits to the window after truncation to the window. Acceptability * of data (and SYN, FIN, of course) is checked separately. * See tcp_data_queue(), for example. * * Also, controls (RST is main one) are accepted using RCV.WUP instead * of RCV.NXT. Peer still did not advance his SND.UNA when we * delayed ACK, so that hisSND.UNA<=3DourRCV.WUP. * (borrowed from freebsd) */ static inline int tcp_sequence(struct tcp_opt *tp, u32 seq, u32 end_seq) { return !before(end_seq, tp->rcv_wup) && !after(seq, tp->rcv_nxt + tcp_receive_window(tp)); } _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Oct 24 12:43:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU5Q9-00053U-3X; Mon, 24 Oct 2005 12:43:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU5Q7-00053P-Dh for tcpm@megatron.ietf.org; Mon, 24 Oct 2005 12:43:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19724 for ; Mon, 24 Oct 2005 12:43:22 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU5ct-0001dw-Db for tcpm@ietf.org; Mon, 24 Oct 2005 12:56:48 -0400 Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9OGgiL20954; Mon, 24 Oct 2005 09:42:45 -0700 (PDT) Received: (from faber@localhost) by pun.isi.edu (8.13.4/8.13.4/Submit) id j9OGgiOw056946; Mon, 24 Oct 2005 09:42:44 -0700 (PDT) (envelope-from faber) Date: Mon, 24 Oct 2005 09:42:44 -0700 From: Ted Faber To: Indraneel Ghosh Subject: Re: [tcpm] Sequence number checking for incoming RST segments Message-ID: <20051024164244.GE54696@pun.isi.edu> References: <447BB19E14004A4388CB9A864D2BA7630DB0FB@hq-ex-6.brocade.com> Mime-Version: 1.0 In-Reply-To: <447BB19E14004A4388CB9A864D2BA7630DB0FB@hq-ex-6.brocade.com> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@pun.isi.edu X-Spam-Score: 0.0 (/) 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: , Content-Type: multipart/mixed; boundary="===============1300985899==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1300985899== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VUDLurXRWRKrGuMn" Content-Disposition: inline --VUDLurXRWRKrGuMn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 23, 2005 at 06:50:53AM -0700, Indraneel Ghosh wrote: >=20 > Hi, >=20 > I had a question regarding the sequence-number check for acceptance > of incoming RST segments. It seems that some TCP stacks (e.g. the > Linux stack shown below) apply a different sequence number check to > RST segments, than what is specified in RFC793 i.e. the {RCV.NXT, > RCV.NXT+RCV.WND} check=20 I'd start here:=20 http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-03.txt Then I'd check the tcpm archives for discussion on that topic. there's been a bit. Those are here: http://www1.ietf.org/mail-archive/web/tcpm/current/index.html That won't answer your variable name question, but should get you the ideas behind what's going on. More or less. =20 --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --VUDLurXRWRKrGuMn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDXQ8EaUz3f+Zf+XsRAoy1AJ9qLd3NHKOzun6Jgj8w7eC5ACjIjACeNZVt AAUdWO83LGZcSRhGYgsK2Es= =OHmW -----END PGP SIGNATURE----- --VUDLurXRWRKrGuMn-- --===============1300985899== 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 --===============1300985899==-- From tcpm-bounces@ietf.org Thu Oct 27 10:51:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV96a-00049Q-Ii; Thu, 27 Oct 2005 10:51:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV955-0003WO-S0; Thu, 27 Oct 2005 10:50:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04022; Thu, 27 Oct 2005 10:49:59 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV9IH-0004X9-S8; Thu, 27 Oct 2005 11:03:56 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EV94s-0000JU-St; Thu, 27 Oct 2005 10:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 27 Oct 2005 10:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-uto-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: , Sender: tcpm-bounces@ietf.org 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-02.txt Pages : 17 Date : 2005-10-27 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. The advisory TCP User Timeout Option allows conforming TCP implementations to exchange their local user timeouts. This is an in-protocol mechanism to allow a host to modify its local user timeout for a connection based on knowledge of the peer's user timeout. Increasing the user timeouts allows established TCP connections to survive extended periods of disconnection. Decreasing 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-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-uto-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-uto-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: <2005-10-27100946.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-tcp-uto-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-uto-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-27100946.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--