From tcpm-bounces@ietf.org Mon Sep 05 09:35:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECH89-0006Y1-If; Mon, 05 Sep 2005 09:35:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECH88-0006Xa-3Z for tcpm@megatron.ietf.org; Mon, 05 Sep 2005 09:35:24 -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 JAA16556 for ; Mon, 5 Sep 2005 09:35:14 -0400 (EDT) Received: from [170.210.17.146] (helo=server.frh.utn.edu.ar ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECHAi-0006z2-4n for tcpm@ietf.org; Mon, 05 Sep 2005 09:38:08 -0400 Received: (qmail 22681 invoked from network); 4 Sep 2005 22:43:20 -0000 Received: from 200-70-144-54.mrse.com.ar (HELO fgont.gont.com.ar) (gont-fernando@200.70.144.54) by server.frh.utn.edu.ar with SMTP; 4 Sep 2005 22:43:20 -0000 Message-Id: <6.2.0.14.0.20050905101459.03e460e0@pop3.frh.utn.edu.ar> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Mon, 05 Sep 2005 10:17:09 -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.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [tcpm] Revised draft on "ICMP attacks against TCP" (draft-gont-tcpm-icmp-attacks-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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Folks, I have submitted to the IETF a revised version of my internet-draft on "ICMP attacks against TCP" (draft-gont-tcpm-icmp-attacks-04.txt). This version addresses the feedback I have received during the last eight months, and includes, among other things, pointers to existing implementations of the proposed fixes. It will soon be available from the internet-drafts public repository. In the mean time, you can access it through my web site: http://www.gont.com.ar/drafts/draft-gont-tcpm-icmp-attacks-04.txt (http://www.gont.com.ar/drafts/icmp-attacks-against-tcp.html) As always, feedback is more than welcome. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Sep 06 21:54:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECp9C-00055Q-NO; Tue, 06 Sep 2005 21:54:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECp9A-00054S-Kf for tcpm@megatron.ietf.org; Tue, 06 Sep 2005 21:54: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 VAA20272 for ; Tue, 6 Sep 2005 21:54:42 -0400 (EDT) Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECpCE-0004Ns-Lv for tcpm@ietf.org; Tue, 06 Sep 2005 21:57:56 -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 j871sdc2011647 for ; Tue, 6 Sep 2005 18:54:39 -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 CF9F277AA1F for ; Tue, 6 Sep 2005 21:54:36 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Drift Away MIME-Version: 1.0 Date: Tue, 06 Sep 2005 21:54:36 -0400 Message-Id: <20050907015436.CF9F277AA1F@guns.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [tcpm] rfc4015 in the tcp roadmap 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="===============2003794936==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============2003794936== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Folks- We believe that the WG consensus is to move the text about RFC4015 in the TCP roadmap from the "standard mechanisms" section to the "experimental extensions" section (i.e., from section 3 to section 4). This consensus was developed both on the mailing list and in the f2f meeting in Paris. We have asked the authors of the roadmap to move the text and add a small amount of text to justify the new placement. We expect there to be text for the WG to review quite soon. If anyone thinks our reading of consensus is wrong, please let us know ASAP. Thanks! Mark & Ted --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFDHkhcWyrrWs4yIs4RAnBbAJ9prtq4Ho+99VVw43KCgGmU4ZhfUQCfachC PppXwOlxcOlOg4hpe3woTGo= =Y4WY -----END PGP SIGNATURE----- --=_bOundary-- --===============2003794936== 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 --===============2003794936==-- From tcpm-bounces@ietf.org Wed Sep 07 05:56:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECwf8-0005q6-D0; Wed, 07 Sep 2005 05:56:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECwf5-0005pJ-WE for tcpm@megatron.ietf.org; Wed, 07 Sep 2005 05:56:12 -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 FAA07733 for ; Wed, 7 Sep 2005 05:56:10 -0400 (EDT) Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECwiE-00086M-Bd for tcpm@ietf.org; Wed, 07 Sep 2005 05:59:27 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j879tnwL013619; Wed, 7 Sep 2005 12:55:51 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Sep 2005 12:55:47 +0300 Received: from siddha.research.nokia.com ([172.21.50.145]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 7 Sep 2005 12:55:46 +0300 Subject: Re: [tcpm] a different scheme for reacting to spurious RTOs From: Pasi Sarolahti To: mallman@icir.org In-Reply-To: <20050826172926.EA16D77AA1D@guns.icir.org> References: <20050826172926.EA16D77AA1D@guns.icir.org> Organization: Nokia Research Center Date: Wed, 07 Sep 2005 12:55:47 +0300 Message-Id: <1126086947.29615.30.camel@siddha.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) X-OriginalArrivalTime: 07 Sep 2005 09:55:46.0699 (UTC) FILETIME=[51AFA5B0:01C5B392] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Ethan Blanton , tcpm@ietf.org, Josh Blanton 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="===============1277925332==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1277925332== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Jq6rAyRl4xDaLP2sOpW5" --=-Jq6rAyRl4xDaLP2sOpW5 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2005-08-26 at 13:29 -0400, ext Mark Allman wrote: > We'd very much appreciate comments on the draft, which > is: >=20 > 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 --=-Jq6rAyRl4xDaLP2sOpW5 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBDHrkjoNa7NH1G2csRAuQBAJ9IKnx1cs+Y6OvyC92IuJkvaWAyiACfd9mF LawkkZvnjvpUCVSM8hgxTYM= =7FN5 -----END PGP SIGNATURE----- --=-Jq6rAyRl4xDaLP2sOpW5-- --===============1277925332== 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 --===============1277925332==-- From tcpm-bounces@ietf.org Fri Sep 09 12:16:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDlYR-0006wZ-II; Fri, 09 Sep 2005 12:16:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDlYP-0006lp-8u for tcpm@megatron.ietf.org; Fri, 09 Sep 2005 12:16:41 -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 MAA12226 for ; Fri, 9 Sep 2005 12:16:38 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDlc0-0006UN-Bd for tcpm@ietf.org; Fri, 09 Sep 2005 12:20:25 -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 j89GFUk16486 for ; Fri, 9 Sep 2005 09:15:30 -0700 (PDT) Received: (from faber@localhost) by pun.isi.edu (8.13.4/8.13.4/Submit) id j89GFUiG080805 for tcpm@ietf.org; Fri, 9 Sep 2005 09:15:30 -0700 (PDT) (envelope-from faber) Date: Fri, 9 Sep 2005 09:15:30 -0700 From: Ted Faber To: tcpm@ietf.org Message-ID: <20050909161530.GC80052@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: 52e1467c2184c31006318542db5614d5 Subject: [tcpm] Last chance for proceedings corrections 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="===============1648674736==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1648674736== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0lnxQi9hkpPO77W3" Content-Disposition: inline --0lnxQi9hkpPO77W3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable And I really do mean last chance. The nice people at FORTEC have the preliminary proceedings up at https://datatracker.ietf.org/public/proceeding_interim.cgi?meeting_num=3D63 If you see something in the TCPM section that you believe is incorrect, please let me know. =20 Deadline for corrections is 19 Sept 2005. I don't really expect any corrections, but I'd rather be sure. --=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 --0lnxQi9hkpPO77W3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDIbUiaUz3f+Zf+XsRAuo4AJ9AFMyGklm+lY6XY58F5+YrVSmbxgCeKis2 2R/fJpzzwjTDAN2Sjg59NXo= =+ojw -----END PGP SIGNATURE----- --0lnxQi9hkpPO77W3-- --===============1648674736== 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 --===============1648674736==-- From tcpm-bounces@ietf.org Fri Sep 09 18:50:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDrhB-000881-T5; Fri, 09 Sep 2005 18:50:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDrh4-00085H-EA; Fri, 09 Sep 2005 18:50: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 SAA15116; Fri, 9 Sep 2005 18: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 1EDrkj-0003kx-Hb; Fri, 09 Sep 2005 18:53:50 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EDrh3-0002Y8-8G; Fri, 09 Sep 2005 18:50:01 -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: Fri, 09 Sep 2005 18:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-dcr-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 : Improving the Robustness of TCP to Non-Congestion Events Author(s) : S. Bhandarkar, et al. Filename : draft-ietf-tcpm-tcp-dcr-05.txt Pages : 17 Date : 2005-9-9 This document specifies Non-Congestion Robustness (NCR) for TCP. In the absence of explicit congestion notification from the network, TCP's loss recovery algorithms treat the receipt of three duplicate acknowledgments as an implicit indication of congestion in the network. This is not always correct, notably in the case when network paths reorder segments (for whatever reason), resulting in degraded performance. TCP-NCR is designed to mitigate this degraded performance by increasing the number of duplicate acknowledgments required to trigger loss recovery, based on the current state of the connection, in an effort to better disambiguate true segment loss from segment reordering. This document specifies the changes to TCP, as well as the costs and benefits of these modification A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-dcr-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-dcr-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-dcr-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-9-9160331.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-tcp-dcr-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-dcr-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-9160331.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 Sep 12 00:08:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEfcP-0004V1-LO; Mon, 12 Sep 2005 00:08:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEfcO-0004Uw-Aq for tcpm@megatron.ietf.org; Mon, 12 Sep 2005 00:08:32 -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 AAA09600 for ; Mon, 12 Sep 2005 00:08:28 -0400 (EDT) Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEfgT-0006Dy-MK for tcpm@ietf.org; Mon, 12 Sep 2005 00:12:48 -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 j8C48QBi082937 for ; Sun, 11 Sep 2005 21:08:26 -0700 (PDT) (envelope-from mallman@icir.org) Received: from lawyers.icir.org (guns.icir.org [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 9694377AAA8 for ; Mon, 12 Sep 2005 00:08:23 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 60B2C353522 for ; Mon, 12 Sep 2005 00:08:08 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Hammer to Fall MIME-Version: 1.0 Date: Mon, 12 Sep 2005 00:08:08 -0400 Message-Id: <20050912040808.60B2C353522@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [tcpm] new version of NCR i-d 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="===============0580560598==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0580560598== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Folks- We have revised the NCR i-d to incorporate some feedback we have received. The new version is: Title : Improving the Robustness of TCP to Non-Congestion Events Author(s) : S. Bhandarkar, et al. Filename : draft-ietf-tcpm-tcp-dcr-05.txt Pages : 17 Date : 2005-9-9 http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-dcr-05.txt It is not really so different from the last version. The algorithmic meat is still in-tact. We'd love to hear if folks have further comments on this document. Thanks! allman -- Mark Allman -- ICIR/ICSI -- http://www.icir.org/mallman/ --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFDJP8nWyrrWs4yIs4RAkyYAJ9SkwV4ryaiv5Gb4zh0/ELJab3XQgCeLLLj 519W79AgdF2D7pM7Lk7E2OM= =NQ9b -----END PGP SIGNATURE----- --=_bOundary-- --===============0580560598== 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 --===============0580560598==-- From tcpm-bounces@ietf.org Tue Sep 13 15:34:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGXi-0005P8-T1; Tue, 13 Sep 2005 15:34:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFDs6-0003cU-Bi for tcpm@megatron.ietf.org; Tue, 13 Sep 2005 12:43: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 MAA01261 for ; Tue, 13 Sep 2005 12:42:58 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFDwV-00074q-EE for tcpm@ietf.org; Tue, 13 Sep 2005 12:47:37 -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 j8DGgSk17599 for ; Tue, 13 Sep 2005 09:42:28 -0700 (PDT) Received: (from faber@localhost) by pun.isi.edu (8.13.4/8.13.4/Submit) id j8DGgSSk013978 for tcpm@ietf.org; Tue, 13 Sep 2005 09:42:28 -0700 (PDT) (envelope-from faber) Date: Tue, 13 Sep 2005 09:42:28 -0700 From: Ted Faber To: tcpm@ietf.org Message-ID: <20050913164227.GE12672@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: 4adaf050708fb13be3316a9eee889caa Subject: [tcpm] new NCR 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: , Content-Type: multipart/mixed; boundary="===============1960873383==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1960873383== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lteA1dqeVaWQ9QQl" Content-Disposition: inline --lteA1dqeVaWQ9QQl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable As I'm sure you all have noticed, Allman et al. have posted a new NCR draft for the group's approval. =46rom what I've seen so far, this spec has received generally good support and review, though there were a few people with questions. The authors and I think this is about ready to consider for a WGLC. The draft is intended to become an experimental RFC. If you've been critical of this draft, please have a look at the current state and see if your concerns have been addressed reasonably for experimental. If you've read the draft before, please have a look at it and see if the current version is ready for WGLC. I'm not interested in a full WGLC pass right now, just trying to see if there's consensus that the document is ready for one. If you have an opinion, pro or con, I need to hear it to gauge interest and consensus. Thanks. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --lteA1dqeVaWQ9QQl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDJwFzaUz3f+Zf+XsRAixSAKCtWNRBrutjebjmRqxVk6zvjbDJYACePOWM wu1v7TcgXVbRPZ/rc8YU+Ms= =vIhu -----END PGP SIGNATURE----- --lteA1dqeVaWQ9QQl-- --===============1960873383== 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 --===============1960873383==-- From tcpm-bounces@ietf.org Thu Sep 15 10:11:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFuSU-0002j7-F7; Thu, 15 Sep 2005 10:11:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFuSQ-0002it-J3 for tcpm@megatron.ietf.org; Thu, 15 Sep 2005 10:11:24 -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 KAA12837 for ; Thu, 15 Sep 2005 10:11:20 -0400 (EDT) Received: from server.frh.utn.edu.ar ([170.210.17.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFuXD-00023A-Jw for tcpm@ietf.org; Thu, 15 Sep 2005 10:16:21 -0400 Received: (qmail 23134 invoked from network); 15 Sep 2005 14:10:14 -0000 Received: from 200-70-144-197.mrse.com.ar (HELO fgont.gont.com.ar) (gont-fernando@200.70.144.197) by server.frh.utn.edu.ar with SMTP; 15 Sep 2005 14:10:14 -0000 Message-Id: <6.2.0.14.0.20050915105749.0812c8d0@pop.frh.utn.edu.ar> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 15 Sep 2005 11:07:27 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.2 (+) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [tcpm] ICMP attacks draft & IAB's "Architectural Implications of Link Indications" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Folks, FYI, there's a discussion of ICMP attacks against TCP in the "Architectural Implications of Link Indications" (http://www.ietf.org/internet-drafts/draft-iab-link-indications-03.txt) document of the IAB (Internet Architecture Board). It cites my work on ICMP attacks against TCP (http://www.ietf.org/internet-drafts/draft-gont-tcpm-icmp-attacks-04.txt), an includes a pretty similar discussion to that included in my internet-draft. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Sep 17 10:28:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGdff-00048T-UQ; Sat, 17 Sep 2005 10:28:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGdfe-00048L-GF for tcpm@megatron.ietf.org; Sat, 17 Sep 2005 10:28: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 KAA16369 for ; Sat, 17 Sep 2005 10:28:00 -0400 (EDT) Received: from ixe-nat1.juniper.net ([193.110.54.36] helo=up-smtp.jnpr.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGdko-0000oU-Rn for tcpm@ietf.org; Sat, 17 Sep 2005 10:33:27 -0400 Received: from emailemea1.jnpr.net ([172.26.192.140]) by up-smtp.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Sat, 17 Sep 2005 15:27:48 +0100 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by emailemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Sat, 17 Sep 2005 15:27:48 +0100 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Sat, 17 Sep 2005 10:27:47 -0400 Received: from [172.23.1.31] ([172.23.1.31]) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Sat, 17 Sep 2005 10:29:01 -0400 Message-ID: <432C27E2.1060409@juniper.net> Date: Sat, 17 Sep 2005 10:27:46 -0400 From: Ron Bonica 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.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Sep 2005 14:29:01.0656 (UTC) FILETIME=[25F90D80:01C5BB94] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Subject: [tcpm] draft-bonica-tcp-auth-00 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 Folks, Please consider the following draft as an individual submission: A New Internet-Draft is available from the on-line Internet-Drafts directories. ------------------------------------------------------------------- Title : Authentication for TCP-based Routing and Management Protocols Author(s) : R. Bonica, A. Heffernan Filename : draft-bonica-tcp-auth-00.txt Pages : 11 Date : 2005-9-16 This memo extends RFC 2385 to support time-based key rollover and multiple hashing algorithms. Operators can use the time-based key rollover feature to in order to periodically update the key that is used to create a message digest for each TCP segment. Operators may also wish to select the hashing algorithm used to create the message digest depending upon the perceived threat level and the computational capabilities of their hardware platforms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bonica-tcp-auth-00.txt _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Sep 19 09:27:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHLgK-0002gF-9R; Mon, 19 Sep 2005 09:27:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHLgI-0002be-Hy for tcpm@megatron.ietf.org; Mon, 19 Sep 2005 09:27:38 -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 JAA20851 for ; Mon, 19 Sep 2005 09:27:36 -0400 (EDT) Received: from mx1.grc.nasa.gov ([128.156.11.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHLlu-0007CL-IW for tcpm@ietf.org; Mon, 19 Sep 2005 09:33:27 -0400 Received: from lombok-fi.grc.nasa.gov (seraph1.grc.nasa.gov [128.156.10.10]) by mx1.grc.nasa.gov (Postfix) with ESMTP id 0F2FCC215 for ; Mon, 19 Sep 2005 09:27:26 -0400 (EDT) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id j8JDRPGT016046 for ; Mon, 19 Sep 2005 09:27:25 -0400 (EDT) Received: from apataki.grc.nasa.gov (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id j8JDRPfD027356 for ; Mon, 19 Sep 2005 09:27:25 -0400 (EDT) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id j8JDROJH027352 for ; Mon, 19 Sep 2005 09:27:24 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501) id E9F924FCE5; Mon, 19 Sep 2005 09:24:18 -0400 (EDT) Date: Mon, 19 Sep 2005 09:24:18 -0400 From: Wesley Eddy To: tcpm@ietf.org Message-ID: <20050919132418.GC21390@grc.nasa.gov> Mime-Version: 1.0 User-Agent: Mutt/1.5.5.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [tcpm] roadmap revisions X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1047648669==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1047648669== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ABTtc+pdwF7KHXCz" Content-Disposition: inline --ABTtc+pdwF7KHXCz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Based on the working group's recent discussions on RFC 4015, we have made some small changes to the TCP roadmap I-D. Scott Bradner has approved the language that is used in this update, with regards to IPR. Please see the diffs between 04 and the proposed 05 version at: http://roland.grc.nasa.gov/~weddy/shared/roadmap/rfcdiff.html and the full text at: http://roland.grc.nasa.gov/~weddy/shared/roadmap/draft-ietf-tcpm-tcp-roadma= p-05.txt -Wes --=20 Wesley M. Eddy Verizon Federal Network Systems http://roland.grc.nasa.gov/~weddy --ABTtc+pdwF7KHXCz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFDLrwCzBuYqbnj3IwRAqTTAJ9tSMprVX2SeLu0wgBPNoGM/CCXYQCeLhyH DniNpd3Ic0ydHXL1sdLL19g= =fZZr -----END PGP SIGNATURE----- --ABTtc+pdwF7KHXCz-- --===============1047648669== 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 --===============1047648669==-- From tcpm-bounces@ietf.org Mon Sep 19 13:41:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHPdi-0006EH-7j; Mon, 19 Sep 2005 13:41:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHPdf-0006Ds-Ih for tcpm@megatron.ietf.org; Mon, 19 Sep 2005 13:41: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 NAA09677 for ; Mon, 19 Sep 2005 13:41:10 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHPjH-0006yo-LJ for tcpm@ietf.org; Mon, 19 Sep 2005 13:47:03 -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 j8JHdmx18381; Mon, 19 Sep 2005 10:39:48 -0700 (PDT) Received: (from faber@localhost) by pun.isi.edu (8.13.4/8.13.4/Submit) id j8JHdmYt067633; Mon, 19 Sep 2005 10:39:48 -0700 (PDT) (envelope-from faber) Date: Mon, 19 Sep 2005 10:39:48 -0700 From: Ted Faber To: Ron Bonica Subject: Re: [tcpm] draft-bonica-tcp-auth-00 Message-ID: <20050919173948.GB66350@pun.isi.edu> References: <432C27E2.1060409@juniper.net> Mime-Version: 1.0 In-Reply-To: <432C27E2.1060409@juniper.net> 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: 538aad3a3c4f01d8b6a6477ca4248793 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2108639531==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============2108639531== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="H1spWtNR+x+ondvy" Content-Disposition: inline --H1spWtNR+x+ondvy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 17, 2005 at 10:27:46AM -0400, Ron Bonica wrote: > Please consider the following draft as an individual submission: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. [snip] > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bonica-tcp-auth-00.txt I skimmed this over, and (with my co-chair hat off) the only real concerns I have with this are: * It seems like a bit of a band-aid on the MD5 TCP stuff, without fixing the real problem that it requires configuration coordination. * I think that as specified you're free from problems cause dby any but the most ridiculous clock skew, but adding a paragraph indicating that's the case probably wouldn't hurt. Specifically you might want to address when an endpoint can discard authentication entities. You might also want to briefly explain that a host receiving a packet authenticated with an authentication element that the receiving endpoint does not believe has passed its start time is not an error because clocks may have skewed. Do others have deeper objections? --=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 --H1spWtNR+x+ondvy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDLvfjaUz3f+Zf+XsRAm4LAJ4ltYL8iOn9iG4OKC8V+1salzBFtQCfZs0N tx9c0uXW3yR3zs87lptnt60= =3Y7Q -----END PGP SIGNATURE----- --H1spWtNR+x+ondvy-- --===============2108639531== 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 --===============2108639531==-- From tcpm-bounces@ietf.org Thu Sep 22 11:16:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EISoP-0003eE-PD; Thu, 22 Sep 2005 11:16:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EISoO-0003cM-9m for tcpm@megatron.ietf.org; Thu, 22 Sep 2005 11:16:36 -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 LAA06165 for ; Thu, 22 Sep 2005 11:16:31 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EISub-0003ml-29 for tcpm@ietf.org; Thu, 22 Sep 2005 11:23:02 -0400 Received: from po2.bbn.com (po2.bbn.com [128.33.0.56]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j8MFGEDc017170; Thu, 22 Sep 2005 11:16:14 -0400 (EDT) Received: from [128.89.80.73] (lion.bbn.com [128.89.80.73]) by po2.bbn.com (8.11.6+Sun/8.10.2) with ESMTP id j8MFGE219482; Thu, 22 Sep 2005 11:16:14 -0400 (EDT) Message-ID: <4332CABD.5020904@bbn.com> Date: Thu, 22 Sep 2005 11:16:13 -0400 From: "Armando L. Caro, Jr." User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050819) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Faber Subject: Re: [tcpm] new NCR draft References: <20050913164227.GE12672@pun.isi.edu> In-Reply-To: <20050913164227.GE12672@pun.isi.edu> X-Enigmail-Version: 0.92.0.0 OpenPGP: id=A9CE816E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Ted Faber wrote: > As I'm sure you all have noticed, Allman et al. have posted a new NCR > draft for the group's approval. > I'm not interested in a full WGLC pass right now, just trying to see if > there's consensus that the document is ready for one. If you have an > opinion, pro or con, I need to hear it to gauge interest and consensus. I have just read over the draft for the first time. I think it is well written and in good state, but I have one concern in reference to the "Careful Limited Transmit" algorithm. This algorithm effectively halves the cwnd when dupacks are received, and reinstates the full cwnd if the sender determines that reordering caused the dupacks. The problem is that if/when the cwnd is reinstated, the sender may generate a burst of packets. I think a max burst limit should be applied in this case, and I think the initial cwnd is a good limit to use. -- Armando www.armandocaro.net _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Sep 22 11:31:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIT2e-0000Iz-UL; Thu, 22 Sep 2005 11:31:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIT2d-0000Io-EU for tcpm@megatron.ietf.org; Thu, 22 Sep 2005 11:31:19 -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 LAA06922 for ; Thu, 22 Sep 2005 11:31:17 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIT8s-0004Cj-HV for tcpm@ietf.org; Thu, 22 Sep 2005 11:37:47 -0400 Received: from [12.208.106.139] (helo=elb.elitists.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EIT2b-0008EF-3e; Thu, 22 Sep 2005 15:31:17 +0000 Received: by elb.elitists.net (Postfix, from userid 3000) id B8F941E89D; Thu, 22 Sep 2005 10:31:16 -0500 (EST) Date: Thu, 22 Sep 2005 10:31:16 -0500 From: Ethan Blanton To: "Armando L. Caro, Jr." Subject: Re: [tcpm] new NCR draft Message-ID: <20050922153116.GI11795@colt.internal> Mail-Followup-To: "Armando L. Caro, Jr." , Ted Faber , tcpm@ietf.org References: <20050913164227.GE12672@pun.isi.edu> <4332CABD.5020904@bbn.com> Mime-Version: 1.0 In-Reply-To: <4332CABD.5020904@bbn.com> User-Agent: Mutt/1.4.1i X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14 X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: tcpm@ietf.org, Ted Faber X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1170616407==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1170616407== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HuXIgs6JvY9hJs5C" Content-Disposition: inline --HuXIgs6JvY9hJs5C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Armando L. Caro, Jr. spake unto us the following wisdom: > Ted Faber wrote: > > As I'm sure you all have noticed, Allman et al. have posted a new NCR > > draft for the group's approval. > > > I'm not interested in a full WGLC pass right now, just trying to see if > > there's consensus that the document is ready for one. If you have an > > opinion, pro or con, I need to hear it to gauge interest and consensus. >=20 > I have just read over the draft for the first time. I think it is well > written and in good state, but I have one concern in reference to the > "Careful Limited Transmit" algorithm. This algorithm effectively halves > the cwnd when dupacks are received, and reinstates the full cwnd if the > sender determines that reordering caused the dupacks. The problem is > that if/when the cwnd is reinstated, the sender may generate a burst of > packets. I think a max burst limit should be applied in this case, and I > think the initial cwnd is a good limit to use. This precise scenario is considered in section 3.2: Upon the termination of Extended Limited Transmit, and especially when using the Careful variant, TCP-NCR may be in a situation where the entire cwnd is not being utilized and therefore TCP-NCR will be prone to transmitting a burst of segments into the network. The draft goes on to specify that cwnd is capped to (roughly) the currently outstanding data, and ssthresh and slow start are used to inflate the window to its previous value without bursting. (Details elided as they are a few dozen lines.) Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 --HuXIgs6JvY9hJs5C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDMs5Er9kA9Ig8HBQRAjaJAKCvFU1fk3DwJlukr22ZH/ak3PbTawCfRo+N r9RWUiDvfAr8WjrHW6gkxc0= =Xqmb -----END PGP SIGNATURE----- --HuXIgs6JvY9hJs5C-- --===============1170616407== 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 --===============1170616407==-- From tcpm-bounces@ietf.org Thu Sep 22 11:43:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EITEf-0003dp-Gd; Thu, 22 Sep 2005 11:43:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EITEd-0003dk-TH for tcpm@megatron.ietf.org; Thu, 22 Sep 2005 11:43: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 LAA07686 for ; Thu, 22 Sep 2005 11:43:41 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EITKt-0004Yf-5E for tcpm@ietf.org; Thu, 22 Sep 2005 11:50:12 -0400 Received: from po2.bbn.com (po2.bbn.com [128.33.0.56]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j8MFhVDc018941; Thu, 22 Sep 2005 11:43:31 -0400 (EDT) Received: from [128.89.80.73] (lion.bbn.com [128.89.80.73]) by po2.bbn.com (8.11.6+Sun/8.10.2) with ESMTP id j8MFhV224668; Thu, 22 Sep 2005 11:43:31 -0400 (EDT) Message-ID: <4332D123.5040904@bbn.com> Date: Thu, 22 Sep 2005 11:43:31 -0400 From: "Armando L. Caro, Jr." User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050819) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ethan Blanton Subject: Re: [tcpm] new NCR draft References: <20050913164227.GE12672@pun.isi.edu> <4332CABD.5020904@bbn.com> <20050922153116.GI11795@colt.internal> In-Reply-To: <20050922153116.GI11795@colt.internal> X-Enigmail-Version: 0.92.0.0 OpenPGP: id=A9CE816E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org, Ted Faber X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Oops... I guess I read through the draft too fast. I can't believe I missed that. Sorry about that. -Armando Ethan Blanton wrote: > Armando L. Caro, Jr. spake unto us the following wisdom: > >>Ted Faber wrote: >> >>>As I'm sure you all have noticed, Allman et al. have posted a new NCR >>>draft for the group's approval. >> >> >> >>>I'm not interested in a full WGLC pass right now, just trying to see if >>>there's consensus that the document is ready for one. If you have an >>>opinion, pro or con, I need to hear it to gauge interest and consensus. >> >>I have just read over the draft for the first time. I think it is well >>written and in good state, but I have one concern in reference to the >>"Careful Limited Transmit" algorithm. This algorithm effectively halves >>the cwnd when dupacks are received, and reinstates the full cwnd if the >>sender determines that reordering caused the dupacks. The problem is >>that if/when the cwnd is reinstated, the sender may generate a burst of >>packets. I think a max burst limit should be applied in this case, and I >>think the initial cwnd is a good limit to use. > > > This precise scenario is considered in section 3.2: > > Upon the termination of Extended Limited Transmit, and especially > when using the Careful variant, TCP-NCR may be in a situation where > the entire cwnd is not being utilized and therefore TCP-NCR will be > prone to transmitting a burst of segments into the network. > > The draft goes on to specify that cwnd is capped to (roughly) the > currently outstanding data, and ssthresh and slow start are used to > inflate the window to its previous value without bursting. (Details > elided as they are a few dozen lines.) > > Ethan _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Sep 22 12:24:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EITrn-0007Zu-Lu; Thu, 22 Sep 2005 12:24:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EITrm-0007ZS-Ce for tcpm@megatron.ietf.org; Thu, 22 Sep 2005 12:24:10 -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 MAA09795 for ; Thu, 22 Sep 2005 12:24:07 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EITy0-0005iZ-PS for tcpm@ietf.org; Thu, 22 Sep 2005 12:30:39 -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 j8MGNin22021 for ; Thu, 22 Sep 2005 09:23:44 -0700 (PDT) Received: (from faber@localhost) by pun.isi.edu (8.13.4/8.13.4/Submit) id j8MGNib6032982 for tcpm@ietf.org; Thu, 22 Sep 2005 09:23:44 -0700 (PDT) (envelope-from faber) Date: Thu, 22 Sep 2005 09:23:44 -0700 From: Ted Faber To: tcpm@ietf.org Message-ID: <20050922162344.GC31229@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: 9a2be21919e71dc6faef12b370c4ecf5 Subject: [tcpm] Feedback on draft-gont-tcpm-icmp-attacks-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: , Content-Type: multipart/mixed; boundary="===============1646970900==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1646970900== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vEao7xgI/oilGqZ+" Content-Disposition: inline --vEao7xgI/oilGqZ+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'd sent this to Fernando off-list, but he was willing to have to forwarded to tcpm to spur discussion of this draft. Fernando, I've made some minor edits to this - primarily correcting my tendency to type "teh" instead to "the." I also added a paragraph near the end adding to my argument that the behavior you're advocating might not even violate 1122. Everyone else, here are my *non-co-chair* thoughts on this draft, though my estimate of consensus in the following paragraph (and only in that paragraph) is made with co-chair hat on. As far as consensus, I didn't see any strong consensus after the last time Pekka presented the ideas in Minneapolis and I haven't seen any change. I do think there's an understanding in the group that there may be ICMP issues, but I really don't see support to do something about it, either in terms of your draft or another approach. I do see some support, but I don't see consensus that we should take this on yet. I think you need to make your case more persuasively. Below here is just my feedback on your document - this is not WG chair feedback. If you think it would help to stir up discussion, I'm happy to re-post these comments to the list. Let me know. The criticisms get more substantial as I go down. When you mention an RFC, say the number of the RFC. Something like "In [7] the authors update [10]" is needlessly opaque. The RFC editor prefers symbolic references anyway, so "In [RFC10101] the authors update [RFC10100]" is *much* clearer to the reader and much easier for the RFC editor to deal with. If you're using xml2rfc, this is an easy change, if you're not consider making it anyway. You're still calling these checks "security checks" rather than "sanity checks" or "correctness checks." Security is a loaded term to some people and I think these checks are weak enough that some people will object to the term. In section 3, you don't mention that an ICMP error message, even a v4 ICMP, MAY contain as many bytes of the packet as the ICMP initiator cares to include in the packet, subject to MTU constraints. This means that there may be enough information to erform more sophisticated checks like MD5 or IPsec. Furthermore, you seem to rule out the possibility of a partial packet IPSec decryption/authentication; I'm not sure that's accurate. If partial decryption is possible, it seems that matching the SPI for a valid IPSec decryption, and then having a partial decryption of the IPSec packet match the port pair for an active IPSec/TCP connection is already a much steeper hurdle than the sequence number check you propose. Make sure you're accurately representing the IPSec alternative here. In section 4, you leave out the most obvious choice. Firewall all ICMP messages (other than maybe ping). ICMP is unreliable; protocols have to work if they never get an ICMP message, so this seems like it must work. Now, you may not want to encourage people to do that, but it's an obvious choice, and I think you should make a case that seqno filtering is better. And importantly, you *never* point out that ICMP is unreliable. In fact, the only ICMP message that a router is required to generate (from a quick look at 1122) is ECHO. This is a really strong point in your favor. Even if you get the checks wrong; even if you discard ICMPs that you shouldn't; even if you discard *all* the ICMP messages, TCP will not fail. The only possible interaction with dropping extra ICMP messages is with PMTU, and that's something that does need to be addressed. But even PMTU should work in the face of extended bad luck (lots of dropped ICMP messages). Finally, there's no MUST in 1122 that says that TCP MUST abort connections on which it receives hard errors. 1122 says TCP SHOULD abort such connections. Again, IMHO, failing a reasonable sanity check could easily provide a reason to not follow the message. But you need to make that argument. You can build a good argument from these principle that your proposed checks are safe and reasonable - maybe even that implementing them breaks no existing standard. But since you never address the idea that TCP already deals with unreliable ICMP messages, you leave yourself open to every little nit pick about how individual checks work. Consider using that to bolster your case. --=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 --vEao7xgI/oilGqZ+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDMtqQaUz3f+Zf+XsRArw3AKD114JRXKPBYLZEIj+EQDFvNp51AACeOfvV KEzV+5Z0i5jdpXYdRSu3P5c= =ScEw -----END PGP SIGNATURE----- --vEao7xgI/oilGqZ+-- --===============1646970900== 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 --===============1646970900==-- From tcpm-bounces@ietf.org Thu Sep 22 13:49:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIVC4-0008P5-8S; Thu, 22 Sep 2005 13:49:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIVC2-0008P0-OV for tcpm@megatron.ietf.org; Thu, 22 Sep 2005 13:49:10 -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 NAA13691 for ; Thu, 22 Sep 2005 13:49:09 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIVIH-0007pP-Ub for tcpm@ietf.org; Thu, 22 Sep 2005 13:55:40 -0400 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8MHm1n23260; Thu, 22 Sep 2005 10:48:01 -0700 (PDT) Message-ID: <4332EDF4.4030600@isi.edu> Date: Thu, 22 Sep 2005 10:46:28 -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 Subject: Re: [tcpm] Feedback on draft-gont-tcpm-icmp-attacks-04.txt References: <20050922162344.GC31229@pun.isi.edu> In-Reply-To: <20050922162344.GC31229@pun.isi.edu> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 To add my own perspective on the doc: Previously, I was opposed to having TCP check any of the contents of an ICMP message. I have considered this in detail, and have come to the conclusion that it is probably not only appropriate but necessary to have TCP check the contents, e.g., the SEQNUM. HOWEVER, I remain opposed to the application of consistency and/or staleness checks (e.g., validation of port, validation of SEQNUM, respectively) as being referred to as "security". I would be in favor of a draft that focuses on the utility of using these checks for consistency and staleness (old packets); this would require substantial changes throughout the current doc, including to the title (though the ID name could remain as-is, e.g., for continuity). It would be useful to consider how these checks would defeat some attacks, _as an aside_ or in an appendix (and its utility depends on the size of the window as well), but not as the focus of the document, IMO. That said, there are a number of additional caveats that need to be put in place to make the checks appropriate, that were not considered, and are basically a detailed version of Ted's observation that there could be errors along the way, e.g., as noted below for TCP checksum validation. I.e., if you're going to validate the TCP header, start with the checksum, as TCP requires. I also agree with many of the other points Ted raised as an individual. Joe ADDITIONAL CHECKSUM ISSUES: - if the ICMP comes from the TCP endpoint (TCP dest matches ICMP source), then the TCP segment MAY?? (see below) be checked for consistency and staleness, including but not limited to the SEQNUM the ICMP checksum protects the payload on its return HOWEVER - this is what concerns me - it's NOT always clear whether the endpoint has validated the TCP checksum on receipt before this ICMP message is sent for errors for which the TCP checksum must have been validated at the receiver, then the above should be MAY for errors for which the TCP checksum may not have been or definitely was not validated, the above should, IMO, be MUST NOT e.g.: 1)) If the ICMP error indicates host or protocol not found, then the TCP checksum is NOT validated on receipt, so a partial segment ***MUST NOT*** be validated/checked 2)) if the ICMP error indicates port not found, then the TCP checksum ought to be validated before the port number is interpreted by the endpoint, so it was validated on receipt, and TCP ***MAY*** - if the TCP packet includes the MD5 option, however, the signature MUST be verified before checking the segments contents. If the entire segment is not included - i.e., where the signature cannot be validated - then the TCP segment MUST NOT be validated, because the intended security may have been violated (IMO - this is a close call, though) - if the ICMP comes from an intermediate endpoint, where TCP dest != ICMP src, then the TCP segment MAY be checked for consistency and staleness as above, ONLY IF the entire segment is included and the TCP checksum is valid - if only a partial segment is included, TCP MUST NOT interpret the contents, since they could have been corrupated on the way to that endpoint (e.g., router) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDMu30E5f5cImnZrsRAgDzAKDk2WjYst7MvzLd7LGKSHAM2iWm2QCfbGC0 GtHeEOvtCBYfrICbvUZ3V9g= =Xujh -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Sep 22 14:55:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIWDm-0002yk-AY; Thu, 22 Sep 2005 14:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIWDj-0002ya-DZ for tcpm@megatron.ietf.org; Thu, 22 Sep 2005 14:55:00 -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 OAA17466 for ; Thu, 22 Sep 2005 14:54:58 -0400 (EDT) Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIWK1-0001Cx-66 for tcpm@ietf.org; Thu, 22 Sep 2005 15:01:29 -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 j8MIstuD042667; Thu, 22 Sep 2005 11:54:56 -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 0DD8B77AAAA; Thu, 22 Sep 2005 14:54:54 -0400 (EDT) To: weddy@grc.nasa.gov From: Mark Allman Subject: Re: [tcpm] roadmap revisions In-Reply-To: <20050919132418.GC21390@grc.nasa.gov> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Werewolves of London MIME-Version: 1.0 Date: Thu, 22 Sep 2005 14:54:54 -0400 Message-Id: <20050922185454.0DD8B77AAAA@guns.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1490646922==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1490646922== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Folks- > Based on the working group's recent discussions on RFC 4015, we have > made some small changes to the TCP roadmap I-D. We would like to get this document wrapped up. The following are the specific changes that were made to the roadmap document by the authors: + Section 3 has been retitled from "Standard Enhancements" to "Recommended Enhancements". + The entry for the Eifel response (RFC 4015) has been moved from Section 3 (now "Recommended Enhancements") to Section 4 ("Experimental Extensions"). The following text was appended to the previous text: RFC 4015 is itself a Proposed Standard. The consensus of the TCPM working group was to place it in this section of the roadmap document due to three factors. 1. RFC 4015 operates on the output of a detection algorithm, for which there is currently no available mechanism on the standards track. 2. The working group was not aware of any wide deployment and use of RFC 4015. 3. The consensus of the working group, after a discussion of the known Intellectual Property Rights claims on the techniques described in RFC 4015, identified this section of the roadmap as an appropriate location.+} As Wes noted, point 3 was run by Scott Bradner - who is happy with the language. + Several minor typos were fixed. This document has been through WGLC once and passed with overwhelming support. We are, therefore, asking folks to review the above changes and send any comments to the list within the next week (by Sep/30). If you need more time to get to this and/or have other concerns, please do not hesitate to ping Ted and I. Our plan is to pass this back to the IESG soon after the 30th unless the WG yells (or, is in the midst of discussion, of course). Thanks! allman -- Mark Allman -- ICIR/ICSI -- http://www.icir.org/mallman/ --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFDMv3+WyrrWs4yIs4RArAvAJ9Ah2IW1WhuCEOuj8ck5ZfTGYngpQCglgqe 55tTD8RcwIpsfcEkqX4vgCc= =GgUb -----END PGP SIGNATURE----- --=_bOundary-- --===============1490646922== 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 --===============1490646922==-- From tcpm-bounces@ietf.org Fri Sep 23 02:03:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIgeK-0000xj-LL; Fri, 23 Sep 2005 02:03:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIgeI-0000wi-8L for tcpm@megatron.ietf.org; Fri, 23 Sep 2005 02:03:06 -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 CAA12277 for ; Fri, 23 Sep 2005 02:02:58 -0400 (EDT) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIgkV-0003dZ-SK for tcpm@ietf.org; Fri, 23 Sep 2005 02:09:34 -0400 Received: (qmail 14993 invoked from network); 23 Sep 2005 06:01:25 -0000 Received: from 200-70-144-118.mrse.com.ar (HELO fgont.gont.com.ar) (gont-fernando@200.70.144.118) by server.frh.utn.edu.ar with SMTP; 23 Sep 2005 06:01:25 -0000 Message-Id: <6.2.0.14.0.20050923012658.0753f008@pop.frh.utn.edu.ar> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 23 Sep 2005 01:45:37 -0300 To: Ted Faber , tcpm@ietf.org From: Fernando Gont Subject: Re: [tcpm] Feedback on draft-gont-tcpm-icmp-attacks-04.txt In-Reply-To: <20050922162344.GC31229@pun.isi.edu> References: <20050922162344.GC31229@pun.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 01:23 p.m. 22/09/2005, Ted Faber wrote: >When you mention an RFC, say the number of the RFC. Something like "In >[7] the authors update [10]" is needlessly opaque. The RFC editor >prefers symbolic references anyway, so "In [RFC10101] the authors update >[RFC10100]" is *much* clearer to the reader and much easier for the RFC >editor to deal with. If you're using xml2rfc, this is an easy change, >if you're not consider making it anyway. Yes, will do. >You're still calling these checks "security checks" rather than "sanity >checks" or "correctness checks." Security is a loaded term to some >people and I think these checks are weak enough that some people will >object to the term. Yes, there's still one instance of that. Will change it in the next revision of the draft. >In section 3, you don't mention that an ICMP error message, even a v4 >ICMP, MAY contain as many bytes of the packet as the ICMP initiator >cares to include in the packet, subject to MTU constraints. This means >that there may be enough information to erform more sophisticated checks >like MD5 or IPsec. I do mention this. However, the point is that including more bytes is not a requirement (i.e., it's a MAY), and therefore an attacker will not include more bytes in the packet just to be catched. >In section 4, you leave out the most obvious choice. Firewall all ICMP >messages (other than maybe ping). ICMP is unreliable; protocols have to >work if they never get an ICMP message, so this seems like it must work. >Now, you may not want to encourage people to do that, but it's an >obvious choice, and I think you should make a case that seqno filtering >is better. Will include this in the next revision. >And importantly, you *never* point out that ICMP is unreliable. In >fact, the only ICMP message that a router is required to generate (from >a quick look at 1122) is ECHO. This is a really strong point in your >favor. Even if you get the checks wrong; even if you discard ICMPs that >you shouldn't; even if you discard *all* the ICMP messages, TCP will not >fail. I did include this in the section about hard errors -> soft errors. But I agree there should be more stress on it. >You can build a good argument from these principle that your proposed >checks are safe and reasonable - maybe even that implementing them >breaks no existing standard. But since you never address the idea >that TCP already deals with unreliable ICMP messages, you leave yourself >open to every little nit pick about how individual checks work. > >Consider using that to bolster your case. Yes, I should put more stress on this. Thanks for your feedback! -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Sep 23 04:25:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIirm-0006Va-FP; Fri, 23 Sep 2005 04:25:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIirj-0006VP-Ob for tcpm@megatron.ietf.org; Fri, 23 Sep 2005 04:25: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 EAA00019 for ; Fri, 23 Sep 2005 04:25:06 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIiy7-0007SP-GJ for tcpm@ietf.org; Fri, 23 Sep 2005 04:31:45 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j8N8Olj06712; Fri, 23 Sep 2005 11:24:49 +0300 Date: Fri, 23 Sep 2005 11:24:47 +0300 (EEST) From: Pekka Savola To: Ted Faber Subject: Re: [tcpm] Feedback on draft-gont-tcpm-icmp-attacks-04.txt In-Reply-To: <20050922162344.GC31229@pun.isi.edu> Message-ID: References: <20050922162344.GC31229@pun.isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org I agree with most comments you're making, but I have to react to this one.. On Thu, 22 Sep 2005, Ted Faber wrote: > In section 4, you leave out the most obvious choice. Firewall all ICMP > messages (other than maybe ping). ICMP is unreliable; protocols have to > work if they never get an ICMP message, so this seems like it must work. Isn't there sufficient evidence that "filter all ICMP" breaks most (all?) transport protocols in obvious and/or subtle ways? (Just consider but there are probably other examples.) So, I fail to see how one could argue that "protocols have to work" -- but maybe this depends on the context and the definition of "work" (i.e., which kinds of functionality or performance degradations would be acceptable). If we were to want to *really* get away from the point that ICMP is required for the protocol to operate to satisfy the users' expectations, there seems to be a LOT to do. Hence, I think there is a strong practical argument that ICMP messages just can't be completely ignored -- and we've seen many stack developers react to that (by implementing verification mechanisms). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Sep 23 07:20:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIlbD-0005XG-Dr; Fri, 23 Sep 2005 07:20:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIlbA-0005SV-7c for tcpm@megatron.ietf.org; Fri, 23 Sep 2005 07:20:13 -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 HAA08336 for ; Fri, 23 Sep 2005 07:20:11 -0400 (EDT) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIlhX-0003Tv-5a for tcpm@ietf.org; Fri, 23 Sep 2005 07:26:50 -0400 Received: (qmail 31702 invoked from network); 23 Sep 2005 11:19:18 -0000 Received: from unknown (HELO fgont.gont.com.ar) (gont-fernando@200.70.176.40) by server.frh.utn.edu.ar with SMTP; 23 Sep 2005 11:19:18 -0000 Message-Id: <6.2.0.14.0.20050923075906.075a2fc8@pop.frh.utn.edu.ar> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 23 Sep 2005 08:02:40 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.9 (++) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [tcpm] ICMP attacks draft (issue 2): Ignore ICMP Source Quenches meant for TCP connections 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 Folks, Issue 2: The draft proposes to ignore ICMP messages meant for TCP connections. Use of ICMP Source Quench messages is already discouraged, so you shouldn't be receiving them. TCP also implements its own congestion control mechanisms. Again: ICMP messages are unreliable. OpenBSD, NetBSD, FreeBSD, and Linux (at least) have been doing this for several months. Comments? -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Sep 23 07:20:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIlbD-0005Xd-Pj; Fri, 23 Sep 2005 07:20:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIlbA-0005Sb-Qq for tcpm@megatron.ietf.org; Fri, 23 Sep 2005 07:20:13 -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 HAA08345 for ; Fri, 23 Sep 2005 07:20:12 -0400 (EDT) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIlhX-0003Tr-5H for tcpm@ietf.org; Fri, 23 Sep 2005 07:26:50 -0400 Received: (qmail 7341 invoked from network); 23 Sep 2005 11:19:13 -0000 Received: from unknown (HELO fgont.gont.com.ar) (gont-fernando@200.70.176.40) by server.frh.utn.edu.ar with SMTP; 23 Sep 2005 11:19:13 -0000 Message-Id: <6.2.0.14.0.20050923014610.0452a2d0@pop.frh.utn.edu.ar> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 23 Sep 2005 07:52:12 -0300 To: Joe Touch , tcpm@ietf.org From: Fernando Gont Subject: Re: [tcpm] Feedback on draft-gont-tcpm-icmp-attacks-04.txt In-Reply-To: <4332EDF4.4030600@isi.edu> References: <20050922162344.GC31229@pun.isi.edu> <4332EDF4.4030600@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.9 (++) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 02:46 p.m. 22/09/2005, Joe Touch wrote: >HOWEVER, I remain opposed to the application of consistency and/or >staleness checks (e.g., validation of port, validation of SEQNUM, >respectively) as being referred to as "security". > >I would be in favor of a draft that focuses on the utility of using >these checks for consistency and staleness (old packets); this would >require substantial changes throughout the current doc, including to the >title (though the ID name could remain as-is, e.g., for continuity). The TCP SEQ check does check for staleness, I agree. >It would be useful to consider how these checks would defeat some >attacks, _as an aside_ or in an appendix (and its utility depends on the >size of the window as well), but not as the focus of the document, IMO. There are other checks/proposals in addition to the TCP SEQ check. While validating ICMP messages is needed to keep TCP robust to "spurious" ICMP messages, the draft focuses on the use of ICMP to attack TCP. >ADDITIONAL CHECKSUM ISSUES: > > - if the ICMP comes from the TCP endpoint (TCP dest matches > ICMP source), then the TCP segment MAY?? (see below) be checked > for consistency and staleness, including but > not limited to the SEQNUM > > the ICMP checksum protects the payload on its return > > HOWEVER - this is what concerns me - it's NOT always clear > whether the endpoint has validated the TCP checksum on > receipt before this ICMP message is sent That depends on the message type. For example, in the case of a "protocol unreachable", there's no TCP on the end-system, so there's nobody that "speaks TCP" and can check it on the destination host. The general answer to this question would be "No". And is another good point for being more cautious about honoring ICMP messages. > for errors for which the TCP checksum must have been validated > at the receiver, then the above should be MAY > > for errors for which the TCP checksum may not have been > or definitely was not validated, the above should, IMO, > be MUST NOT MUST NOT and *still* honor them??? > e.g.: > 1)) If the ICMP error indicates host or protocol not found, > then the TCP checksum is NOT validated on receipt, so a partial > segment ***MUST NOT*** be validated/checked I think this is another point that shows why one should be cautious when processing ICMP messages. Let's suppose the IMCP message was elicited by a corrupted TCP segment. If it's a hard error, it must match an existing connection. It will then have to have a valid TCP SEQ. And even then, the message will be used only in case the connection times out. For Source Quenches, you simply ignore the message. As for "frag needed and DF bit set", the message must match an existing connection, the message must have a valid TCP SEQ, and a segment must timeout before the message is honored. (And, BTW, you need to process the ICMP payload even if you assume the TCP checksum has not been verified by the system that sent the ICMP error.... if not, how do you perform PMTUD?) > 2)) if the ICMP error indicates port not found, then > the TCP checksum ought to be validated before the port > number is interpreted by the endpoint, so it was validated > on receipt, and TCP ***MAY*** > > - if the TCP packet includes the MD5 option, however, > the signature MUST be verified before checking the > segments contents. If the entire segment is not > included - i.e., where the signature cannot be > validated - then the TCP segment MUST NOT be validated, > because the intended security may have been violated > (IMO - this is a close call, though) ? > - if the ICMP comes from an intermediate endpoint, where > TCP dest != ICMP src, then the TCP segment MAY be checked > for consistency and staleness as above, ONLY IF the entire > segment is included and the TCP checksum is valid > > - if only a partial segment is included, TCP MUST NOT > interpret the contents, since they could have been > corrupated on the way to that endpoint (e.g., router) What do you mean by "TCP MUST NOT interpret the contents"? Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Sep 23 07:20:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIlbE-0005Y4-5E; Fri, 23 Sep 2005 07:20:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIlbA-0005SW-7v for tcpm@megatron.ietf.org; Fri, 23 Sep 2005 07:20:13 -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 HAA08333 for ; Fri, 23 Sep 2005 07:20:11 -0400 (EDT) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIlhX-0003Ts-5R for tcpm@ietf.org; Fri, 23 Sep 2005 07:26:50 -0400 Received: (qmail 25342 invoked from network); 23 Sep 2005 11:19:20 -0000 Received: from unknown (HELO fgont.gont.com.ar) (gont-fernando@200.70.176.40) by server.frh.utn.edu.ar with SMTP; 23 Sep 2005 11:19:20 -0000 Message-Id: <6.2.0.14.0.20050923080242.0461d4a8@pop.frh.utn.edu.ar> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 23 Sep 2005 08:08:03 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.9 (++) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [tcpm] ICMP attacks draft (issue 3): TCP SEQ check 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 Folks, Issue 3: The draft proposes to check the TCP sequence number contained in the payload of the ICMP messages. The idea is that errors should be caused by segments that have been sent, but not yet acknowledged. This is a general check, which check for the staleness of the error messages. We are performing the same check for TCP segments, so why not perform the same check for errors that are supposed to have been elicited by the connection? If an error message does not pass tis check, it means that either the error is old (and thus it's okay to discard it), or that there's still a path to get to the destination system (and thus, for the sake of TCP's robustness, we should not honor the error message). Even then, ICMP is unreliable. Dropping a legitimate ICMP error message can't hurt you, anyway. Comments? Linux has been performing this check for years. OpenBSD has been performing this check for more than a year. FreeBSD and NetBSD have been performing this check for several months now. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Sep 23 07:20:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIlbE-0005Yf-Hp; Fri, 23 Sep 2005 07:20:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIlbA-0005SY-IV for tcpm@megatron.ietf.org; Fri, 23 Sep 2005 07:20:13 -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 HAA08338 for ; Fri, 23 Sep 2005 07:20:11 -0400 (EDT) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIlhX-0003Tq-6c for tcpm@ietf.org; Fri, 23 Sep 2005 07:26:50 -0400 Received: (qmail 25992 invoked from network); 23 Sep 2005 11:19:10 -0000 Received: from unknown (HELO fgont.gont.com.ar) (gont-fernando@200.70.176.40) by server.frh.utn.edu.ar with SMTP; 23 Sep 2005 11:19:10 -0000 Message-Id: <6.2.0.14.0.20050923073841.0497ec90@pop.frh.utn.edu.ar> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 23 Sep 2005 07:43:29 -0300 To: Pekka Savola , Ted Faber From: Fernando Gont Subject: Re: [tcpm] Feedback on draft-gont-tcpm-icmp-attacks-04.txt In-Reply-To: References: <20050922162344.GC31229@pun.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.9 (++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 05:24 a.m. 23/09/2005, Pekka Savola wrote: >Isn't there sufficient evidence that "filter all ICMP" breaks most (all?) >transport protocols in obvious and/or subtle ways? (Just consider but >there are probably other examples.) So, I fail to see how one could argue >that "protocols have to work" -- but maybe this depends on the context and >the definition of "work" (i.e., which kinds of functionality or >performance degradations would be acceptable). > >If we were to want to *really* get away from the point that ICMP is >required for the protocol to operate to satisfy the users' expectations, >there seems to be a LOT to do. > >Hence, I think there is a strong practical argument that ICMP messages >just can't be completely ignored -- and we've seen many stack developers >react to that (by implementing verification mechanisms). I think my draft is a good engineering solution for dealing with ICMP. Filtering all ICMP breaks, for example, PMTUD. ICMP can be useful both for solving problems (TCP soft errors thing) and for providing more specific information when you have problems. That's basically what my draft tries to achieve: Mitigating the security implications of ICMP, while still using it when useful. -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Sep 23 07:20:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIlbE-0005ZS-Vc; Fri, 23 Sep 2005 07:20:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIlbA-0005SX-AN for tcpm@megatron.ietf.org; Fri, 23 Sep 2005 07:20:13 -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 HAA08335 for ; Fri, 23 Sep 2005 07:20:11 -0400 (EDT) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIlhX-0003Tu-6A for tcpm@ietf.org; Fri, 23 Sep 2005 07:26:50 -0400 Received: (qmail 27710 invoked from network); 23 Sep 2005 11:19:23 -0000 Received: from unknown (HELO fgont.gont.com.ar) (gont-fernando@200.70.176.40) by server.frh.utn.edu.ar with SMTP; 23 Sep 2005 11:19:23 -0000 Message-Id: <6.2.0.14.0.20050923080806.03bb9ef8@pop.frh.utn.edu.ar> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 23 Sep 2005 08:14:08 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.9 (++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [tcpm] ICMP attacks draft (issue 4): Make the current PMTUD mechanism more cautious 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 Folks, Issue 4: While there's ongoing work for designing a *new* PMTUD, we are still dealing with the "old" (RFC1191) one, and will probably have to do so for a number of years. My draft basically proposes to wait for an RTO before honoring an ICMP "fragmentation needed and DF bit set". We basically want to check progress on the connection. If there's progress, the error message must be false. (The draft also includes a little workaround to avoid waiting several RTOs the first time you have to discover the Path-MTU). By no means this is an alternative for the PLPMTUD of the PMTUD WG. It's just an improvement to the *current* PMTUD, to mitigate it's security implications. OpenBSD and NetBSD (at least) are have been implementing this mechanism for the last few months. Comments? -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Sep 23 07:20:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIlbF-0005Zv-Bw; Fri, 23 Sep 2005 07:20:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIlbA-0005SZ-J0 for tcpm@megatron.ietf.org; Fri, 23 Sep 2005 07:20:13 -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 HAA08331 for ; Fri, 23 Sep 2005 07:20:11 -0400 (EDT) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIlhX-0003Tt-6X for tcpm@ietf.org; Fri, 23 Sep 2005 07:26:50 -0400 Received: (qmail 22667 invoked from network); 23 Sep 2005 11:19:16 -0000 Received: from unknown (HELO fgont.gont.com.ar) (gont-fernando@200.70.176.40) by server.frh.utn.edu.ar with SMTP; 23 Sep 2005 11:19:16 -0000 Message-Id: <6.2.0.14.0.20050923075214.0428faa8@pop.frh.utn.edu.ar> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 23 Sep 2005 07:58:58 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.9 (++) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [tcpm] ICMP attacks draft (issue 1): hard errors -> soft errors (in synchronized states) 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 Folks I will separate the discussion into different issues, so that it is easier to get consensus on the different parts of the draft. Issue 1 is: When a so-called ICMP "hard error" is received for a connection in any of the synchronized states (ESTABLISHED and so on), treat the error message as a soft error (i.e., do NOT abort the corresponding connection). This improves TCP's robustness. In the event the error condition does not disappear in the near term, the connection will time out, anyway. Note: ICMP is *unreliable*: you cannot depend on it, anyway. All BSD-derived and Mentat-derived implementations have been doing this for at least fifteen years. Comments? Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Sep 23 09:29:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIncj-0003f1-4K; Fri, 23 Sep 2005 09:29:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIncg-0003eo-Qq for tcpm@megatron.ietf.org; Fri, 23 Sep 2005 09:29:54 -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 JAA14346 for ; Fri, 23 Sep 2005 09:29:53 -0400 (EDT) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EInj6-0006hS-FJ for tcpm@ietf.org; Fri, 23 Sep 2005 09:36:34 -0400 Received: (qmail 4700 invoked from network); 23 Sep 2005 13:28:37 -0000 Received: from unknown (HELO fgont.gont.com.ar) (gont-fernando@200.70.176.72) by server.frh.utn.edu.ar with SMTP; 23 Sep 2005 13:28:37 -0000 Message-Id: <6.2.0.14.0.20050923094938.03e68a48@pop.frh.utn.edu.ar> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 23 Sep 2005 09:57:28 -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.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [tcpm] Revised draft on TCP's reaction to soft errors 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 Folks, At IETF 62 there was consensus to take my draft on "TCP's reaction to soft errors" as a WG document. I have produced a revision of the draft, in order o just described the mechanism implemented by many implementations, but not propose it (just document it). I'd like to hear comments on whether you think we can take this revision as a WG document. The draft will soon be available from the internet-drafts public repository. In the mean time, you can access it through my web site: http://www.gont.com.ar/drafts/draft-gont-tcpm-tcp-soft-errors-02.txt (http://www.gont.com.ar/drafts/tcp-soft-errors.html) Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Sep 23 10:30:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIoZI-0003Yp-Lq; Fri, 23 Sep 2005 10:30:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIoZF-0003YV-KE for tcpm@megatron.ietf.org; Fri, 23 Sep 2005 10:30: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 KAA18523 for ; Fri, 23 Sep 2005 10:30:23 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIofe-0008Fp-BJ for tcpm@ietf.org; Fri, 23 Sep 2005 10:37:05 -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 j8NEStn19198; Fri, 23 Sep 2005 07:28:55 -0700 (PDT) Message-ID: <43341121.6040907@isi.edu> Date: Fri, 23 Sep 2005 07:28:49 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] ICMP attacks draft (issue 3): TCP SEQ check References: <6.2.0.14.0.20050923080242.0461d4a8@pop.frh.utn.edu.ar> In-Reply-To: <6.2.0.14.0.20050923080242.0461d4a8@pop.frh.utn.edu.ar> 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: 8b431ad66d60be2d47c7bfeb879db82c 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="===============1652685630==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1652685630== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB544EDA06E85300FC0F6E900" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB544EDA06E85300FC0F6E900 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Fernando Gont wrote: > Folks, > > Issue 3: The draft proposes to check the TCP sequence number contained > in the payload of the ICMP messages. > The idea is that errors should be caused by segments that have been > sent, but not yet acknowledged. > > This is a general check, which check for the staleness of the error > messages. We are performing the same check for TCP segments, so why not > perform the same check for errors that are supposed to have been > elicited by the connection? TCP checks the checksum AND MD5 option (if the latter exists) first; if you do these checks first, then it is OK to check the SEQNUM. If not enough of the segment exists to do so, then it is incorrect to interpret any of the rest of the fields. > Linux has been performing this check for years. OpenBSD has been > performing this check for more than a year. FreeBSD and NetBSD have been > performing this check for several months now. The fact that many people implemented TCP bugs incorrectly warranted a document on why what they did was incorrect, not a document to validate it - regardless of the lack of noted errors. The statement above is not germane to this dicussion. Joe --------------enigB544EDA06E85300FC0F6E900 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 iD8DBQFDNBEhE5f5cImnZrsRAnqTAJ0TpGssqxKm3HgWkaVtTO9+ZcgkgACfRLsb c9eVoXt5DVEtgYYvrazvPMg= =95e+ -----END PGP SIGNATURE----- --------------enigB544EDA06E85300FC0F6E900-- --===============1652685630== 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 --===============1652685630==-- From tcpm-bounces@ietf.org Fri Sep 23 10:33:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIocR-0004Dj-Ek; Fri, 23 Sep 2005 10:33:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIocQ-0004Dd-Ex for tcpm@megatron.ietf.org; Fri, 23 Sep 2005 10:33:42 -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 KAA18695 for ; Fri, 23 Sep 2005 10:33:40 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIois-0008Jo-JG for tcpm@ietf.org; Fri, 23 Sep 2005 10:40:23 -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 j8NEW8n19874; Fri, 23 Sep 2005 07:32:08 -0700 (PDT) Message-ID: <433411E2.3020005@isi.edu> Date: Fri, 23 Sep 2005 07:32:02 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fernando Gont 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> In-Reply-To: <6.2.0.14.0.20050923075214.0428faa8@pop.frh.utn.edu.ar> 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: 7aafa0432175920a4b3e118e16c5cb64 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="===============0720111011==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0720111011== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5B29C2982489AB09913DDFBB" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5B29C2982489AB09913DDFBB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Fernando Gont wrote: > Folks > > I will separate the discussion into different issues, so that it is > easier to get consensus on the different parts of the draft. > > Issue 1 is: When a so-called ICMP "hard error" is received for a > connection in any of the synchronized states (ESTABLISHED and so on), > treat the error message as a soft error (i.e., do NOT abort the > corresponding connection). WHY? Such an error could occur due to a reboot. It is legitimate operation. > This improves TCP's robustness. In the event the error condition does > not disappear in the near term, the connection will time out, anyway. Now I'm confused. If a node were to have IPv4 and reboot with IPv6, you want it to timeout. But your other draft wants to kill the TCP attempt to connect *immediately* so you can retry. So which is it? is restarting TCP connections important or not? IMO, there is no reason to change TCP's behavior here, and it's sufficient to leave it alone. --- The whole tone of this doc is that there are attacks that need to be dealt with; it ignores cases where such messages are sent legitimately. Joe --------------enig5B29C2982489AB09913DDFBB 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 iD8DBQFDNBHiE5f5cImnZrsRAvbqAKDnHk4+zJLE/2BCjfBeYJULEzzAhgCfd2p3 zoEhedybNDC0rNnIoqbT3dI= =pn4d -----END PGP SIGNATURE----- --------------enig5B29C2982489AB09913DDFBB-- --===============0720111011== 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 --===============0720111011==-- From tcpm-bounces@ietf.org Fri Sep 23 10:35:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIoeA-0004fy-CG; Fri, 23 Sep 2005 10:35:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIoe8-0004fH-Af for tcpm@megatron.ietf.org; Fri, 23 Sep 2005 10:35:28 -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 KAA18752 for ; Fri, 23 Sep 2005 10:35:26 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIokZ-0008Lu-BA for tcpm@ietf.org; Fri, 23 Sep 2005 10:42:08 -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 j8NEYVn20680; Fri, 23 Sep 2005 07:34:31 -0700 (PDT) Message-ID: <43341271.8090001@isi.edu> Date: Fri, 23 Sep 2005 07:34: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: Fernando Gont Subject: Re: [tcpm] ICMP attacks draft (issue 4): Make the current PMTUD mechanism more cautious References: <6.2.0.14.0.20050923080806.03bb9ef8@pop.frh.utn.edu.ar> In-Reply-To: <6.2.0.14.0.20050923080806.03bb9ef8@pop.frh.utn.edu.ar> 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: 82c9bddb247d9ba4471160a9a865a5f3 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2074079827==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2074079827== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig835356A2B3D6DA34E3D475E8" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig835356A2B3D6DA34E3D475E8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Fernando Gont wrote: > Folks, > > Issue 4: > While there's ongoing work for designing a *new* PMTUD, we are still > dealing with the "old" (RFC1191) one, and will probably have to do so > for a number of years. > My draft basically proposes to wait for an RTO before honoring an ICMP > "fragmentation needed and DF bit set". We basically want to check > progress on the connection. If there's progress, the error message must > be false. Again, an assertion that ignores correct operation. In this case, there could be multiple alternate paths with different MTUs. IMO, changes to interpretation of ICMP that argue based on 'connection progress' should be made in the PMTUD document, and are not appropriate as a separate document. > (The draft also includes a little workaround to avoid waiting several > RTOs the first time you have to discover the Path-MTU). Further reason to take this idea to the PTMUD WG. > By no means this is an alternative for the PLPMTUD of the PMTUD WG. It's > just an improvement to the *current* PMTUD, to mitigate it's security > implications. Perhaps, but this isn't the best place to discuss it, IMO. Joe --------------enig835356A2B3D6DA34E3D475E8 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 iD8DBQFDNBJxE5f5cImnZrsRAndPAKD9bHGbbGLU1Fnaog7CXebZGAvw8wCeJ9Ky 1k4tWYH6qhzq9XGUgZZo8CM= =XUMi -----END PGP SIGNATURE----- --------------enig835356A2B3D6DA34E3D475E8-- --===============2074079827== 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 --===============2074079827==-- From tcpm-bounces@ietf.org Fri Sep 23 10:49:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIorr-0007hg-8Y; Fri, 23 Sep 2005 10:49:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIorp-0007gX-MP for tcpm@megatron.ietf.org; Fri, 23 Sep 2005 10:49:37 -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 KAA19457 for ; Fri, 23 Sep 2005 10:49:35 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIoyG-0000Ej-Qm for tcpm@ietf.org; Fri, 23 Sep 2005 10:56:18 -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 j8NEmEn24622; Fri, 23 Sep 2005 07:48:14 -0700 (PDT) Received: (from faber@localhost) by pun.isi.edu (8.13.4/8.13.4/Submit) id j8NEmEZ8011980; Fri, 23 Sep 2005 07:48:14 -0700 (PDT) (envelope-from faber) Date: Fri, 23 Sep 2005 07:48:14 -0700 From: Ted Faber To: Fernando Gont Subject: Re: [tcpm] Feedback on draft-gont-tcpm-icmp-attacks-04.txt Message-ID: <20050923144814.GB10959@pun.isi.edu> References: <20050922162344.GC31229@pun.isi.edu> <6.2.0.14.0.20050923012658.0753f008@pop.frh.utn.edu.ar> Mime-Version: 1.0 In-Reply-To: <6.2.0.14.0.20050923012658.0753f008@pop.frh.utn.edu.ar> 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: 769a46790fb42fbb0b0cc700c82f7081 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0064087707==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0064087707== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/NkBOFFp2J2Af1nK" Content-Disposition: inline --/NkBOFFp2J2Af1nK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 23, 2005 at 01:45:37AM -0300, Fernando Gont wrote: > At 01:23 p.m. 22/09/2005, Ted Faber wrote: > >In section 3, you don't mention that an ICMP error message, even a v4 > >ICMP, MAY contain as many bytes of the packet as the ICMP initiator > >cares to include in the packet, subject to MTU constraints. This means > >that there may be enough information to erform more sophisticated checks > >like MD5 or IPsec. >=20 > I do mention this. However, the point is that including more bytes is not= a=20 > requirement (i.e., it's a MAY), and therefore an attacker will not inclu= de=20 > more bytes in the packet just to be catched. That's a valid point, in that an attacker will probably provide the bare minimum data. In fact, only getting the minimum data may be a hint that this ICMP isn't so trustworthy. Still, sanity checks covers the ground where there is no attacker just corruption or misconfiguration. In those cases, you can expect and use more data. --=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 --/NkBOFFp2J2Af1nK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDNBWuaUz3f+Zf+XsRAsNXAJ9fLy3T67Dcp80Xtbyh03QwhPh7WQCgwJKx dAgnyvBmu0gKKYRp7xQWU7s= =XNS5 -----END PGP SIGNATURE----- --/NkBOFFp2J2Af1nK-- --===============0064087707== 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 --===============0064087707==-- From tcpm-bounces@ietf.org Fri Sep 23 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 1EIotw-0008Qr-95; Fri, 23 Sep 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 1EIott-0008Qf-ED for tcpm@megatron.ietf.org; Fri, 23 Sep 2005 10:51:45 -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 KAA19577 for ; Fri, 23 Sep 2005 10:51:43 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIp0J-0000J0-J4 for tcpm@ietf.org; Fri, 23 Sep 2005 10:58:26 -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 j8NEo8n25239; Fri, 23 Sep 2005 07:50:08 -0700 (PDT) Message-ID: <4334161A.2020604@isi.edu> Date: Fri, 23 Sep 2005 07:50:02 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] Feedback on draft-gont-tcpm-icmp-attacks-04.txt References: <20050922162344.GC31229@pun.isi.edu> <4332EDF4.4030600@isi.edu> <6.2.0.14.0.20050923014610.0452a2d0@pop.frh.utn.edu.ar> In-Reply-To: <6.2.0.14.0.20050923014610.0452a2d0@pop.frh.utn.edu.ar> 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: d890c9ddd0b0a61e8c597ad30c1c2176 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="===============0004357283==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0004357283== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig78E93A0C3221A1EB9E00DBF2" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig78E93A0C3221A1EB9E00DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Fernando Gont wrote: > At 02:46 p.m. 22/09/2005, Joe Touch wrote: > >> HOWEVER, I remain opposed to the application of consistency and/or >> staleness checks (e.g., validation of port, validation of SEQNUM, >> respectively) as being referred to as "security". >> >> I would be in favor of a draft that focuses on the utility of using >> these checks for consistency and staleness (old packets); this would >> require substantial changes throughout the current doc, including to the >> title (though the ID name could remain as-is, e.g., for continuity). > > The TCP SEQ check does check for staleness, I agree. > >> It would be useful to consider how these checks would defeat some >> attacks, _as an aside_ or in an appendix (and its utility depends on the >> size of the window as well), but not as the focus of the document, IMO. > > There are other checks/proposals in addition to the TCP SEQ check. > > While validating ICMP messages is needed to keep TCP robust to > "spurious" ICMP messages, the draft focuses on the use of ICMP to attack > TCP. TCP robustness is important; ICMP validity checks can help, but they are NOT security checks unless there are security mechanisms at play (e.g., signatures). >> ADDITIONAL CHECKSUM ISSUES: >> >> - if the ICMP comes from the TCP endpoint (TCP dest matches >> ICMP source), then the TCP segment MAY?? (see below) be checked >> for consistency and staleness, including but >> not limited to the SEQNUM >> >> the ICMP checksum protects the payload on its return >> >> HOWEVER - this is what concerns me - it's NOT always clear >> whether the endpoint has validated the TCP checksum on >> receipt before this ICMP message is sent > > > That depends on the message type. For example, in the case of a > "protocol unreachable", there's no TCP on the end-system, so there's > nobody that "speaks TCP" and can check it on the destination host. The > general answer to this question would be "No". And is another good point > for being more cautious about honoring ICMP messages. So you don't seem to care about getting an ICMP message back with what could have been a corrupted TCP partial segment back, but you DO care about whether the SEQNUM is valid? Yes - I would drop some ICMPs that are currently used. But my reasons are based on existing TCP header semantics - not incorrectly/inappropriately inferring security properties from them. >> for errors for which the TCP checksum must have been validated >> at the receiver, then the above should be MAY >> >> for errors for which the TCP checksum may not have been >> or definitely was not validated, the above should, IMO, >> be MUST NOT > > MUST NOT and *still* honor them??? No - they MUST NOT honor them. I would silently drop these, for the reason above. >> e.g.: >> 1)) If the ICMP error indicates host or protocol not found, >> then the TCP checksum is NOT validated on receipt, so a partial >> segment ***MUST NOT*** be validated/checked > > I think this is another point that shows why one should be cautious when > processing ICMP messages. But I'm being MORE cautious than you in these cases, and this doc is supposed to be about "security"? > Let's suppose the IMCP message was elicited by a corrupted TCP segment. > > If it's a hard error, it must match an existing connection. It will then > have to have a valid TCP SEQ. And even then, the message will be used > only in case the connection times out. Yes. And that rule should still apply - IF the segment is received in a validated fashion. For hard errors received from the endpoint, the connection would reset quickly. For hard errors NOT received from the endpoint but received in total, this would reset after the timeout. For hard errors NOT received from the endpoint and received in part, this would never reset. But that's OK - TCP never intends to cleanup state on old connections to save space, but rather when it interferes with what would be a new connection. > For Source Quenches, you simply ignore the message. Agreed, but that's just documenting long-recommended practice. I had thought that was noted already in an RFC. > As for "frag needed and DF bit set", the message must match an existing > connection, the message must have a valid TCP SEQ, and a segment must > timeout before the message is honored. (And, BTW, you need to process > the ICMP payload even if you assume the TCP checksum has not been > verified by the system that sent the ICMP error.... if not, how do you > perform PMTUD?) That's an interesting question - it might be the case that you don't, or it might be the case that you decided that since MTU adjustments are very soft (don't kill a connection) you are willing to relax the need to check the checksum in that case. Again, foremost in the discussion is the issue that non-malicious corruption is all you can check - including bit errors, stale packets, etc. You cannot check _security_ unless things are signed. Nothing here should be confused for a security check. >> 2)) if the ICMP error indicates port not found, then >> the TCP checksum ought to be validated before the port >> number is interpreted by the endpoint, so it was validated >> on receipt, and TCP ***MAY*** >> >> - if the TCP packet includes the MD5 option, however, >> the signature MUST be verified before checking the >> segments contents. If the entire segment is not >> included - i.e., where the signature cannot be >> validated - then the TCP segment MUST NOT be validated, >> because the intended security may have been violated >> (IMO - this is a close call, though) > > ? Thinking further, it's not so close. It MUST be checked just like the checksum if it exists. >> - if the ICMP comes from an intermediate endpoint, where >> TCP dest != ICMP src, then the TCP segment MAY be checked >> for consistency and staleness as above, ONLY IF the entire >> segment is included and the TCP checksum is valid >> >> - if only a partial segment is included, TCP MUST NOT >> interpret the contents, since they could have been >> corrupated on the way to that endpoint (e.g., router) > > What do you mean by "TCP MUST NOT interpret the contents"? More specifically "the contents of the segment are meaningless" if the checksum fails, so interpreting the contents "as a TCP segment" is inappropriate in those cases. Joe --------------enig78E93A0C3221A1EB9E00DBF2 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 iD8DBQFDNBYaE5f5cImnZrsRAj6FAJ0YVjFsi9TI4eWk2jqbN+VBPYO6QwCfTgKl 3dEblsrYD57yzgMH82CxZRk= =f4DK -----END PGP SIGNATURE----- --------------enig78E93A0C3221A1EB9E00DBF2-- --===============0004357283== 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 --===============0004357283==-- From tcpm-bounces@ietf.org Fri Sep 23 10:53:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIovH-0000Ts-V2; Fri, 23 Sep 2005 10:53:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIovG-0000So-22 for tcpm@megatron.ietf.org; Fri, 23 Sep 2005 10:53:10 -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 KAA19630 for ; Fri, 23 Sep 2005 10:53:08 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIp1i-0000L0-A7 for tcpm@ietf.org; Fri, 23 Sep 2005 10:59:50 -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 j8NEqAn25697; Fri, 23 Sep 2005 07:52:10 -0700 (PDT) Received: (from faber@localhost) by pun.isi.edu (8.13.4/8.13.4/Submit) id j8NEqAZB012010; Fri, 23 Sep 2005 07:52:10 -0700 (PDT) (envelope-from faber) Date: Fri, 23 Sep 2005 07:52:10 -0700 From: Ted Faber To: Pekka Savola Subject: Re: [tcpm] Feedback on draft-gont-tcpm-icmp-attacks-04.txt Message-ID: <20050923145210.GC10959@pun.isi.edu> References: <20050922162344.GC31229@pun.isi.edu> Mime-Version: 1.0 In-Reply-To: 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: 7aafa0432175920a4b3e118e16c5cb64 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="===============1582277421==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1582277421== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3siQDZowHQqNOShm" Content-Disposition: inline --3siQDZowHQqNOShm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 23, 2005 at 11:24:47AM +0300, Pekka Savola wrote: > I agree with most comments you're making, but I have to react to this=20 > one.. >=20 > On Thu, 22 Sep 2005, Ted Faber wrote: > >In section 4, you leave out the most obvious choice. Firewall all ICMP > >messages (other than maybe ping). ICMP is unreliable; protocols have to > >work if they never get an ICMP message, so this seems like it must work. >=20 > Isn't there sufficient evidence that "filter all ICMP" breaks most=20 > (all?) transport protocols in obvious and/or subtle ways? (Just=20 > consider but there are probably other examples.) So, I fail to see how=20 > one could argue that "protocols have to work" -- but maybe this=20 > depends on the context and the definition of "work" (i.e., which kinds=20 > of functionality or performance degradations would be acceptable). ? ICMP's unreliably delivered, and optional (though strongly encouraged) to generate. If protocols rely on it, they're in some amount of trouble. I understand that some protocol may rely on it, but it's IMHO misdesgigned. I can't think of any way (outside maybe PMTU, which I don't know much about) that TCP might be broken here. Give me an example of breakage. --=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 --3siQDZowHQqNOShm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDNBaaaUz3f+Zf+XsRAvfnAJ9uJZUKjoxDZO6+p+XYoFGAHN1yHQCgukqx ew1QC7BM+Tjz/hJVZ8LEt3w= =28rG -----END PGP SIGNATURE----- --3siQDZowHQqNOShm-- --===============1582277421== 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 --===============1582277421==-- From tcpm-bounces@ietf.org Fri Sep 23 12:25:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIqMu-0006p8-Kb; Fri, 23 Sep 2005 12:25:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIqMs-0006ol-JV for tcpm@megatron.ietf.org; Fri, 23 Sep 2005 12:25:46 -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 MAA23740 for ; Fri, 23 Sep 2005 12:25:44 -0400 (EDT) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIqTJ-0002TC-OO for tcpm@ietf.org; Fri, 23 Sep 2005 12:32:28 -0400 Received: (qmail 24153 invoked from network); 23 Sep 2005 16:24:50 -0000 Received: from 200-70-176-194.mrse.com.ar (HELO fgont.gont.com.ar) (gont-fernando@200.70.176.194) by server.frh.utn.edu.ar with SMTP; 23 Sep 2005 16:24:50 -0000 Message-Id: <6.2.0.14.0.20050923125830.04310d00@pop.frh.utn.edu.ar> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 23 Sep 2005 12:59:58 -0300 To: Joe Touch From: Fernando Gont Subject: Re: [tcpm] ICMP attacks draft (issue 3): TCP SEQ check In-Reply-To: <43341121.6040907@isi.edu> References: <6.2.0.14.0.20050923080242.0461d4a8@pop.frh.utn.edu.ar> <43341121.6040907@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.9 (++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 11:28 a.m. 23/09/2005, Joe Touch wrote: > > This is a general check, which check for the staleness of the error > > messages. We are performing the same check for TCP segments, so why not > > perform the same check for errors that are supposed to have been > > elicited by the connection? > >TCP checks the checksum AND MD5 option (if the latter exists) first; if >you do these checks first, then it is OK to check the SEQNUM. If not >enough of the segment exists to do so, then it is incorrect to interpret >any of the rest of the fields. Then why would you abort a connection, then??? You don't want to perform checks, but do want to abort your connections, anyway? That doesn't make sense to me.... -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Sep 23 12:25:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIqMv-0006pa-2j; Fri, 23 Sep 2005 12:25:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIqMt-0006oy-JA for tcpm@megatron.ietf.org; Fri, 23 Sep 2005 12:25:47 -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 MAA23749 for ; Fri, 23 Sep 2005 12:25:45 -0400 (EDT) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIqTJ-0002TB-ON for tcpm@ietf.org; Fri, 23 Sep 2005 12:32:28 -0400 Received: (qmail 7831 invoked from network); 23 Sep 2005 16:24:46 -0000 Received: from 200-70-176-194.mrse.com.ar (HELO fgont.gont.com.ar) (gont-fernando@200.70.176.194) by server.frh.utn.edu.ar with SMTP; 23 Sep 2005 16:24:46 -0000 Message-Id: <6.2.0.14.0.20050923125332.04320008@pop.frh.utn.edu.ar> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 23 Sep 2005 12:57:40 -0300 To: Joe Touch From: Fernando Gont Subject: Re: [tcpm] ICMP attacks draft (issue 1): hard errors -> soft errors (in synchronized states) In-Reply-To: <433411E2.3020005@isi.edu> References: <6.2.0.14.0.20050923075214.0428faa8@pop.frh.utn.edu.ar> <433411E2.3020005@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.9 (++) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 11:32 a.m. 23/09/2005, Joe Touch wrote: > > Issue 1 is: When a so-called ICMP "hard error" is received for a > > connection in any of the synchronized states (ESTABLISHED and so on), > > treat the error message as a soft error (i.e., do NOT abort the > > corresponding connection). > >WHY? Such an error could occur due to a reboot. It is legitimate operation. In that case you should receive an RST, not an ICMP message. > > This improves TCP's robustness. In the event the error condition does > > not disappear in the near term, the connection will time out, anyway. > >Now I'm confused. If a node were to have IPv4 and reboot with IPv6, you >want it to timeout. But your other draft wants to kill the TCP attempt >to connect *immediately* so you can retry. In one case (soft errors draft), an ICMP error message is received during connection-establishment. In this case, (ICMP attacks draft), I'm talking about ICMP error messages received during the life of a connection. An ICMP error message is just a hint. As per D. Clark's paper, depending on the time you receive the message, the meaning may be different. -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Sep 23 12:25:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIqMv-0006pz-Hl; Fri, 23 Sep 2005 12:25:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIqMt-0006p3-PY for tcpm@megatron.ietf.org; Fri, 23 Sep 2005 12:25:47 -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 MAA23752 for ; Fri, 23 Sep 2005 12:25:45 -0400 (EDT) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIqTJ-0002TA-ON for tcpm@ietf.org; Fri, 23 Sep 2005 12:32:29 -0400 Received: (qmail 25250 invoked from network); 23 Sep 2005 16:24:54 -0000 Received: from 200-70-176-194.mrse.com.ar (HELO fgont.gont.com.ar) (gont-fernando@200.70.176.194) by server.frh.utn.edu.ar with SMTP; 23 Sep 2005 16:24:54 -0000 Message-Id: <6.2.0.14.0.20050923130302.043109e8@pop.frh.utn.edu.ar> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 23 Sep 2005 13:19:50 -0300 To: Joe Touch From: Fernando Gont Subject: Re: [tcpm] Feedback on draft-gont-tcpm-icmp-attacks-04.txt In-Reply-To: <4334161A.2020604@isi.edu> References: <20050922162344.GC31229@pun.isi.edu> <4332EDF4.4030600@isi.edu> <6.2.0.14.0.20050923014610.0452a2d0@pop.frh.utn.edu.ar> <4334161A.2020604@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.9 (++) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 11:50 a.m. 23/09/2005, Joe Touch wrote: > > There are other checks/proposals in addition to the TCP SEQ check. > > > > While validating ICMP messages is needed to keep TCP robust to > > "spurious" ICMP messages, the draft focuses on the use of ICMP to attack > > TCP. > >TCP robustness is important; ICMP validity checks can help, but they are >NOT security checks unless there are security mechanisms at play (e.g., >signatures). I've already stated that I will change the only remaining instance of "security check" to "validation check", "sanity check", or whatever. > >> HOWEVER - this is what concerns me - it's NOT always clear > >> whether the endpoint has validated the TCP checksum on > >> receipt before this ICMP message is sent > > > > That depends on the message type. For example, in the case of a > > "protocol unreachable", there's no TCP on the end-system, so there's > > nobody that "speaks TCP" and can check it on the destination host. The > > general answer to this question would be "No". And is another good point > > for being more cautious about honoring ICMP messages. > >So you don't seem to care about getting an ICMP message back with what >could have been a corrupted TCP partial segment back, but you DO care >about whether the SEQNUM is valid? The specs do not require you to get a full TCP segment (in the ICMP payload), but want you to process them. In most cases, you won't receive a full TCP segment (let's assume the segment was PMTU-sized, so the intermmediate router must now waste at least 20+8 bytes in IP+ICMP headers). If you don't want to process ICMP messages that do not contain full TCP segments, you are sort of asking to disable ICMP. I'm saying, let's make some checks. Those checks will catch many (if any) corroputed messages. But let's also be conservative in what we do with the messages. For example, do not abort conections. Let's just record the message. If it times out, that recorded message will certainly provide someting better than a "timeout" error. The same kind of rationale applies for "frag needed and DF bit set".... > >> for errors for which the TCP checksum must have been validated > >> at the receiver, then the above should be MAY > >> > >> for errors for which the TCP checksum may not have been > >> or definitely was not validated, the above should, IMO, > >> be MUST NOT > > > > MUST NOT and *still* honor them??? > >No - they MUST NOT honor them. I would silently drop these, for the >reason above. Your proposed behavior violates RFC1122. The Host Requirements states that a TCP MUST act on an ICMP error message passed up from the IP layer, directing it to the connection that elicited the error. > > For Source Quenches, you simply ignore the message. > >Agreed, but that's just documenting long-recommended practice. I had >thought that was noted already in an RFC. No, it is not. TCP is still required to act on ICMP Source Quenches. > >> - if the ICMP comes from an intermediate endpoint, where > >> TCP dest != ICMP src, then the TCP segment MAY be checked > >> for consistency and staleness as above, ONLY IF the entire > >> segment is included and the TCP checksum is valid > >> > >> - if only a partial segment is included, TCP MUST NOT > >> interpret the contents, since they could have been > >> corrupated on the way to that endpoint (e.g., router) > > > > What do you mean by "TCP MUST NOT interpret the contents"? > >More specifically "the contents of the segment are meaningless" if the >checksum fails, so interpreting the contents "as a TCP segment" is >inappropriate in those cases. RFC1122 is already asking you to do this. -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Sep 23 12:51:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIqld-00049l-5Z; Fri, 23 Sep 2005 12:51:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIqlb-000496-94 for tcpm@megatron.ietf.org; Fri, 23 Sep 2005 12:51:19 -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 MAA24876 for ; Fri, 23 Sep 2005 12:51:16 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIqs2-00034u-JD for tcpm@ietf.org; Fri, 23 Sep 2005 12:58:01 -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 j8NGoHn03284; Fri, 23 Sep 2005 09:50:17 -0700 (PDT) Received: (from faber@localhost) by pun.isi.edu (8.13.4/8.13.4/Submit) id j8NGoHKt014413; Fri, 23 Sep 2005 09:50:17 -0700 (PDT) (envelope-from faber) Date: Fri, 23 Sep 2005 09:50:17 -0700 From: Ted Faber To: Fernando Gont Subject: Re: [tcpm] ICMP attacks draft (issue 1): hard errors -> soft errors (in synchronized states) Message-ID: <20050923165017.GD10959@pun.isi.edu> 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> Mime-Version: 1.0 In-Reply-To: <6.2.0.14.0.20050923125332.04320008@pop.frh.utn.edu.ar> 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: f60d0f7806b0c40781eee6b9cd0b2135 Cc: tcpm@ietf.org, Joe Touch X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0992464299==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0992464299== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XvKFcGCOAo53UbWW" Content-Disposition: inline --XvKFcGCOAo53UbWW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 23, 2005 at 12:57:40PM -0300, Fernando Gont wrote: > At 11:32 a.m. 23/09/2005, Joe Touch wrote: >=20 > >> Issue 1 is: When a so-called ICMP "hard error" is received for a > >> connection in any of the synchronized states (ESTABLISHED and so on), > >> treat the error message as a soft error (i.e., do NOT abort the > >> corresponding connection). > > > >WHY? Such an error could occur due to a reboot. It is legitimate operati= on. >=20 > In that case you should receive an RST, not an ICMP message. Joe's not laying out his case completely. Let me try to fill in the blanks and he can tell me where I've misinterpreted what he's suggesting. Imagine a host that speaks IPv4 and TCP. You connect to it. The host goes down and reboots (fairly quickly), but it's flag day, and the host now no longer supports IPv4 at all, or no longer supports TCP at all. You can work your imagination for other reasons that TCP might fail to come up - a firewall (mis-?)configured to send the ICMP for application protocols that have been outlawed, an embedded TCP stack with an initialization/configuration error, TCP in an LKM with the wrong kernel version... There are a few whack-O cases out there that are unlikely but well within the range of the possible. None of those behaviors (with the possible exception of the firewall) breaks a spec that I can think of. The point is that for whatever reason, all the host can do is send a Protocol Not Supported ICMP, because the TCP stack will not be reached (the postulate is that the host has stopped speaking either TCP or IPv4). Because the packet can't get to the TCP stack (which may not be running at all), the host can't generate an RST. Of course, if no ICMP is generated or gets through, the ESTABLISHED TCP will eventually have a UTO and abort the connection. Yes, this is a pretty bizarre case, but it is a valid hard error in an ESTABLISHED state, and one where aborting the connection is the most sensible thing to do. --=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 --XvKFcGCOAo53UbWW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDNDJJaUz3f+Zf+XsRArHLAJ9DvDQNDtUJoVMKIkxmgQxkn5dn1gCgkDEW lgoV9AmMbe6pP3oNwpfZvs8= =Etnf -----END PGP SIGNATURE----- --XvKFcGCOAo53UbWW-- --===============0992464299== 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 --===============0992464299==-- From tcpm-bounces@ietf.org Fri Sep 23 13:02:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIqwM-0007oU-Ro; Fri, 23 Sep 2005 13:02:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIqwK-0007oM-KZ for tcpm@megatron.ietf.org; Fri, 23 Sep 2005 13:02:24 -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 NAA25546 for ; Fri, 23 Sep 2005 13:02:22 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIr2h-0003Q6-FQ for tcpm@ietf.org; Fri, 23 Sep 2005 13:09:06 -0400 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8NH1Cn06414; Fri, 23 Sep 2005 10:01:12 -0700 (PDT) Message-ID: <4334345F.2060301@isi.edu> Date: Fri, 23 Sep 2005 09:59:11 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fernando Gont 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> In-Reply-To: <6.2.0.14.0.20050923125332.04320008@pop.frh.utn.edu.ar> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: > At 11:32 a.m. 23/09/2005, Joe Touch wrote: > >> > Issue 1 is: When a so-called ICMP "hard error" is received for a >> > connection in any of the synchronized states (ESTABLISHED and so on), >> > treat the error message as a soft error (i.e., do NOT abort the >> > corresponding connection). >> >> WHY? Such an error could occur due to a reboot. It is legitimate >> operation. > > > In that case you should receive an RST, not an ICMP message. Not if there is no TCP running, or none over IPv4 (i.e., convert to IPv6). >> > This improves TCP's robustness. In the event the error condition does >> > not disappear in the near term, the connection will time out, anyway. >> >> Now I'm confused. If a node were to have IPv4 and reboot with IPv6, you >> want it to timeout. But your other draft wants to kill the TCP attempt >> to connect *immediately* so you can retry. > > In one case (soft errors draft), an ICMP error message is received > during connection-establishment. > In this case, (ICMP attacks draft), I'm talking about ICMP error > messages received during the life of a connection. But why should one be considered less hard, and one more hard? It's basically reaction to the _inferred_ cause of such a message - in the first case you assume it's benign and use it to fail-over, and in the second you assume it's an attack and want to ignore it. I don't agree with inferring things this way, esp. since such inferences are based on a snapshot of typical use at the time the ID is published. > An ICMP error message is just a hint. As per D. Clark's paper, depending > on the time you receive the message, the meaning may be different. Agreed - but the meaning should always be considered benign before it is considered an attack. If a benign cause _could_ have resulted in the message, it seems inappropriate to react as if it's an attack. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDNDRfE5f5cImnZrsRAsgBAJ0UlC+1dFNnANK6CvkrWu9WhHqx5wCdGhsK EDwapZY+MrZ8b5d48WS2Lq0= =w6Ob -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Sep 23 13:04:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIqyL-00084q-2S; Fri, 23 Sep 2005 13:04:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIqyJ-00084i-0C for tcpm@megatron.ietf.org; Fri, 23 Sep 2005 13:04:27 -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 NAA25594 for ; Fri, 23 Sep 2005 13:04:24 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIr3l-0003RO-3B for tcpm@ietf.org; Fri, 23 Sep 2005 13:11:08 -0400 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8NH2ln07114; Fri, 23 Sep 2005 10:02:47 -0700 (PDT) Message-ID: <433434BD.5060606@isi.edu> Date: Fri, 23 Sep 2005 10:00:45 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] ICMP attacks draft (issue 3): TCP SEQ check References: <6.2.0.14.0.20050923080242.0461d4a8@pop.frh.utn.edu.ar> <43341121.6040907@isi.edu> <6.2.0.14.0.20050923125830.04310d00@pop.frh.utn.edu.ar> In-Reply-To: <6.2.0.14.0.20050923125830.04310d00@pop.frh.utn.edu.ar> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: > At 11:28 a.m. 23/09/2005, Joe Touch wrote: > >> > This is a general check, which check for the staleness of the error >> > messages. We are performing the same check for TCP segments, so why not >> > perform the same check for errors that are supposed to have been >> > elicited by the connection? >> >> TCP checks the checksum AND MD5 option (if the latter exists) first; if >> you do these checks first, then it is OK to check the SEQNUM. If not >> enough of the segment exists to do so, then it is incorrect to interpret >> any of the rest of the fields. > > Then why would you abort a connection, then??? I don't see where I would have. I would have silently dropped the ICMP in those cases where the checksum or MD5 fail. > You don't want to perform checks, but do want to abort your connections, > anyway? No, I do want to perform checks- for validity and staleness, but not to infer anything about an attack from those. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDNDS9E5f5cImnZrsRAnhQAKCAVOxkRNA6Wd0v0FIj4MSm6BSxWwCfReRY H2hzcjmRWEc6HMOk6P8LK5k= =xX1L -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Sep 23 13:13:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIr7V-0001vp-7Z; Fri, 23 Sep 2005 13:13:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIr7T-0001vk-EW for tcpm@megatron.ietf.org; Fri, 23 Sep 2005 13:13:55 -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 NAA25838 for ; Fri, 23 Sep 2005 13:13:52 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIrDs-0003eG-1n for tcpm@ietf.org; Fri, 23 Sep 2005 13:20:37 -0400 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8NHCTn10272; Fri, 23 Sep 2005 10:12:29 -0700 (PDT) Message-ID: <43343703.4090608@isi.edu> Date: Fri, 23 Sep 2005 10:10:27 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] Feedback on draft-gont-tcpm-icmp-attacks-04.txt References: <20050922162344.GC31229@pun.isi.edu> <4332EDF4.4030600@isi.edu> <6.2.0.14.0.20050923014610.0452a2d0@pop.frh.utn.edu.ar> <4334161A.2020604@isi.edu> <6.2.0.14.0.20050923130302.043109e8@pop.frh.utn.edu.ar> In-Reply-To: <6.2.0.14.0.20050923130302.043109e8@pop.frh.utn.edu.ar> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: 7bit 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: > At 11:50 a.m. 23/09/2005, Joe Touch wrote: ... >> >> HOWEVER - this is what concerns me - it's NOT always clear >> >> whether the endpoint has validated the TCP checksum on >> >> receipt before this ICMP message is sent >> > >> > That depends on the message type. For example, in the case of a >> > "protocol unreachable", there's no TCP on the end-system, so there's >> > nobody that "speaks TCP" and can check it on the destination host. The >> > general answer to this question would be "No". And is another good >> point >> > for being more cautious about honoring ICMP messages. >> >> So you don't seem to care about getting an ICMP message back with what >> could have been a corrupted TCP partial segment back, but you DO care >> about whether the SEQNUM is valid? > > The specs do not require you to get a full TCP segment (in the ICMP > payload), but want you to process them. *IF* you do validity checks, then the first part of validity to check is the checksum. Jumping over that to check what you _want_ to check seems inappropriate. > In most cases, you won't receive a full TCP segment (let's assume the > segment was PMTU-sized, so the intermmediate router must now waste at > least 20+8 bytes in IP+ICMP headers). Agreed. > If you don't want to process ICMP messages that do not contain full TCP > segments, you are sort of asking to disable ICMP. No - I'm suggesting that if you don't check the checksums, you have no business deciding that other fields are "correct" or not. You can decide to take the packet as a signal on faith - which is what is currently done. But the instant you start 'checking' the packet, you have an obligation to check what it _means_, not just what is convenient. > I'm saying, let's make some checks. Those checks will catch many (if > any) corroputed messages. But let's also be conservative in what we do > with the messages. For example, do not abort conections. Let's just > record the message. If it times out, that recorded message will > certainly provide someting better than a "timeout" error. If this is true, then why do you want to be aggresive in processing TCP soft errors? Doesn't the same logic apply? And why are erroneous messages more informative than a 'timeout' if it's the timeout that ends up ultimately killing the connection? > The same kind of rationale applies for "frag needed and DF bit set".... What do I learn if I get these and they're erroneous? >> >> for errors for which the TCP checksum must have been validated >> >> at the receiver, then the above should be MAY >> >> >> >> for errors for which the TCP checksum may not have been >> >> or definitely was not validated, the above should, IMO, >> >> be MUST NOT >> > >> > MUST NOT and *still* honor them??? >> >> No - they MUST NOT honor them. I would silently drop these, for the >> reason above. > > Your proposed behavior violates RFC1122. The Host Requirements states > that a TCP MUST act on an ICMP error message passed up from the IP > layer, directing it to the connection that elicited the error. Doesn't that go for your check as well? I.e., either TCP must honor them, or the process of honoring them involves validity checks and those failing such checks must be silently dropped. That goes for checksum checks, SEQNUM checks, etc. >> > For Source Quenches, you simply ignore the message. >> >> Agreed, but that's just documenting long-recommended practice. I had >> thought that was noted already in an RFC. > > No, it is not. TCP is still required to act on ICMP Source Quenches. It's not in an RFC - I checked my notes - but it was agreed upon a while ago. It's long-recommended practice that just hasn't been documented in an RFC yet. >> >> - if the ICMP comes from an intermediate endpoint, where >> >> TCP dest != ICMP src, then the TCP segment MAY be checked >> >> for consistency and staleness as above, ONLY IF the entire >> >> segment is included and the TCP checksum is valid >> >> >> >> - if only a partial segment is included, TCP MUST NOT >> >> interpret the contents, since they could have been >> >> corrupated on the way to that endpoint (e.g., router) >> > >> > What do you mean by "TCP MUST NOT interpret the contents"? >> >> More specifically "the contents of the segment are meaningless" if the >> checksum fails, so interpreting the contents "as a TCP segment" is >> inappropriate in those cases. > > RFC1122 is already asking you to do this. See above; you can't "eat your cake and have it too". Either TCP MUST act on all ICMPs received, or it's OK to do validity checks that involve parsing the header. If the latter, then TCP semantics demand that the checksum be checked first - see RFC793. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDNDcDE5f5cImnZrsRAthoAKDu7OTIbHah7+LBozh32471P02hkACgyKP1 1pNQ9Nek87umz6cksPI8Q1M= =Rmto -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Sep 23 14:22:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIsC4-0000Az-Pp; Fri, 23 Sep 2005 14:22:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIsC2-00009D-Ai for tcpm@megatron.ietf.org; Fri, 23 Sep 2005 14:22:42 -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 OAA28389 for ; Fri, 23 Sep 2005 14:22:34 -0400 (EDT) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIsIO-0005C0-JG for tcpm@ietf.org; Fri, 23 Sep 2005 14:29:18 -0400 Received: (qmail 1864 invoked from network); 23 Sep 2005 18:21:30 -0000 Received: from unknown (HELO fgont.gont.com.ar) (gont-fernando@10.0.10.7) by server.frh.utn.edu.ar with SMTP; 23 Sep 2005 18:21:30 -0000 Message-Id: <6.2.0.14.0.20050923145840.04700660@pop.frh.utn.edu.ar> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 23 Sep 2005 15:16:21 -0300 To: Joe Touch From: Fernando Gont Subject: Re: [tcpm] Feedback on draft-gont-tcpm-icmp-attacks-04.txt In-Reply-To: <43343703.4090608@isi.edu> References: <20050922162344.GC31229@pun.isi.edu> <4332EDF4.4030600@isi.edu> <6.2.0.14.0.20050923014610.0452a2d0@pop.frh.utn.edu.ar> <4334161A.2020604@isi.edu> <6.2.0.14.0.20050923130302.043109e8@pop.frh.utn.edu.ar> <43343703.4090608@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 02:10 p.m. 23/09/2005, Joe Touch wrote: > >> So you don't seem to care about getting an ICMP message back with what > >> could have been a corrupted TCP partial segment back, but you DO care > >> about whether the SEQNUM is valid? > > > > The specs do not require you to get a full TCP segment (in the ICMP > > payload), but want you to process them. > >*IF* you do validity checks, then the first part of validity to check is >the checksum. Jumping over that to check what you _want_ to check seems >inappropriate. Agreed. I just want to "jump over" if I simply cannot check the checksum (i.e., if there's no full TCP segment). > > I'm saying, let's make some checks. Those checks will catch many (if > > any) corroputed messages. But let's also be conservative in what we do > > with the messages. For example, do not abort conections. Let's just > > record the message. If it times out, that recorded message will > > certainly provide someting better than a "timeout" error. > >If this is true, then why do you want to be aggresive in processing TCP >soft errors? Doesn't the same logic apply? Not necessarily. In the soft errors draft case, there's no previous knowledge of the TCP connection working OK. So my take is "take the error as a hint, and try the next possible IP address". As I have noted since this issue was first raised here, this is probably not the ideal solution (the ideal solution is, IMHO, applications using a Higher-Level API), but is an engineering approach to the problem. D. Clark's paper contains a similar rationale. >And why are erroneous messages more informative than a 'timeout' if it's >the timeout that ends up ultimately killing the connection? You don't know for sure they are erroneous. And that's all the current specifications are providing. > > The same kind of rationale applies for "frag needed and DF bit set".... > >What do I learn if I get these and they're erroneous? In the worst case (the IP addresses and port numbers were corrupted, along with the TCP SEQ), you reduce the MTU for the connection. Sometime later you will increase it again. Anyway, the mechanism proposed in my draft won't likely suffer this during the life of a connection, and you still wait for at least one RTO before honoring the error message. > >> >> for errors for which the TCP checksum must have been validated > >> >> at the receiver, then the above should be MAY > >> >> > >> >> for errors for which the TCP checksum may not have been > >> >> or definitely was not validated, the above should, IMO, > >> >> be MUST NOT > >> > > >> > MUST NOT and *still* honor them??? > >> > >> No - they MUST NOT honor them. I would silently drop these, for the > >> reason above. > > > > Your proposed behavior violates RFC1122. The Host Requirements states > > that a TCP MUST act on an ICMP error message passed up from the IP > > layer, directing it to the connection that elicited the error. > >Doesn't that go for your check as well? I.e., either TCP must honor >them, or the process of honoring them involves validity checks and those >failing such checks must be silently dropped. That goes for checksum >checks, SEQNUM checks, etc. You don't direct the messages to the corresponding conenction. I do do it. > >> > For Source Quenches, you simply ignore the message. > >> > >> Agreed, but that's just documenting long-recommended practice. I had > >> thought that was noted already in an RFC. > > > > No, it is not. TCP is still required to act on ICMP Source Quenches. > >It's not in an RFC - I checked my notes - but it was agreed upon a while >ago. It's long-recommended practice that just hasn't been documented in >an RFC yet. Good we have come to an agreement. :-) > >> > What do you mean by "TCP MUST NOT interpret the contents"? > >> > >> More specifically "the contents of the segment are meaningless" if the > >> checksum fails, so interpreting the contents "as a TCP segment" is > >> inappropriate in those cases. > > > > RFC1122 is already asking you to do this. > >See above; you can't "eat your cake and have it too". Either TCP MUST >act on all ICMPs received, or it's OK to do validity checks that involve >parsing the header. If the latter, then TCP semantics demand that the >checksum be checked first - see RFC793. I agree that if you can check the checksum, you must do it. I'm just considering the case in which you can't -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Sep 23 14:32:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIsLq-00033a-Ax; Fri, 23 Sep 2005 14:32:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIsLo-00033O-84 for tcpm@megatron.ietf.org; Fri, 23 Sep 2005 14:32:48 -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 OAA28760 for ; Fri, 23 Sep 2005 14:32:46 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIsSH-0005Ps-3x for tcpm@ietf.org; Fri, 23 Sep 2005 14:39:30 -0400 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8NIVgn02837; Fri, 23 Sep 2005 11:31:42 -0700 (PDT) Message-ID: <43344994.8050805@isi.edu> Date: Fri, 23 Sep 2005 11:29:40 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] Feedback on draft-gont-tcpm-icmp-attacks-04.txt References: <20050922162344.GC31229@pun.isi.edu> <4332EDF4.4030600@isi.edu> <6.2.0.14.0.20050923014610.0452a2d0@pop.frh.utn.edu.ar> <4334161A.2020604@isi.edu> <6.2.0.14.0.20050923130302.043109e8@pop.frh.utn.edu.ar> <43343703.4090608@isi.edu> <6.2.0.14.0.20050923145840.04700660@pop.frh.utn.edu.ar> In-Reply-To: <6.2.0.14.0.20050923145840.04700660@pop.frh.utn.edu.ar> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: > At 02:10 p.m. 23/09/2005, Joe Touch wrote: ... >> See above; you can't "eat your cake and have it too". Either TCP MUST >> act on all ICMPs received, or it's OK to do validity checks that involve >> parsing the header. If the latter, then TCP semantics demand that the >> checksum be checked first - see RFC793. > > > I agree that if you can check the checksum, you must do it. I'm just > considering the case in which you can't IMO, if you can't interpret the checksum, you should not check the SEQNUM - unless ICMPsrc=TCPdst, in which case you expect that the other end already did the check. There are cases where it's not feasible to check the checksum (PMTU, among others), in which case I don't think it's appropriate to check the SEQNUM either, though. I.e., both or neither. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDNEmUE5f5cImnZrsRAk6HAJ0b/OZ2v6pCr+TVFuhIMCT9QM2IHACgnSTp Q2/HIOYm3PHbD7ctUEzMO18= =KZrj -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Sep 23 14:35:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIsOf-0003P6-Lo; Fri, 23 Sep 2005 14:35:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIsOe-0003P1-ST for tcpm@megatron.ietf.org; Fri, 23 Sep 2005 14:35: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 OAA28985 for ; Fri, 23 Sep 2005 14:35:43 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIsV7-0005Sz-Uf for tcpm@ietf.org; Fri, 23 Sep 2005 14:42:27 -0400 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8NIYgn04242; Fri, 23 Sep 2005 11:34:42 -0700 (PDT) Message-ID: <43344A48.7050206@isi.edu> Date: Fri, 23 Sep 2005 11:32:40 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] Feedback on draft-gont-tcpm-icmp-attacks-04.txt References: <20050922162344.GC31229@pun.isi.edu> <4332EDF4.4030600@isi.edu> <6.2.0.14.0.20050923014610.0452a2d0@pop.frh.utn.edu.ar> <4334161A.2020604@isi.edu> <6.2.0.14.0.20050923130302.043109e8@pop.frh.utn.edu.ar> <43343703.4090608@isi.edu> <6.2.0.14.0.20050923145840.04700660@pop.frh.utn.edu.ar> In-Reply-To: <6.2.0.14.0.20050923145840.04700660@pop.frh.utn.edu.ar> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As a more high level comment regarding some of our points of agreement: I do agree that a document addressing when and whether to check the SEQNUM would be useful, as well as noting some of the other checks - e.g., to drop source quench. I don't agree that we can get there with incremental modification of the current document, however. The focus needs to be on why the checks are appropriate - even if there are notes as to how this can incidentally help protect against some types of attacks (e.g., in the security considerations section, or a separate section). Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDNEpIE5f5cImnZrsRAnYyAJ9nj/J8W89VNZhH2N3MOneoxVk29QCfSJLs bBWa189a2GnNpQgCI6CzFnM= =T1XA -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Sep 27 02:22:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK8qm-0005u4-2u; Tue, 27 Sep 2005 02:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK8qj-0005tn-TC for tcpm@megatron.ietf.org; Tue, 27 Sep 2005 02:21:58 -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 CAA16867 for ; Tue, 27 Sep 2005 02:21:56 -0400 (EDT) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EK8xg-0002aW-FX for tcpm@ietf.org; Tue, 27 Sep 2005 02:29:23 -0400 Received: (qmail 24156 invoked from network); 27 Sep 2005 06:20:56 -0000 Received: from unknown (HELO fgont.gont.com.ar) (gont-fernando@200.70.146.149) by server.frh.utn.edu.ar with SMTP; 27 Sep 2005 06:20:56 -0000 Message-Id: <6.2.0.14.0.20050927015438.07c2a418@pop.frh.utn.edu.ar> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 27 Sep 2005 02:09:48 -0300 To: Ted Faber From: Fernando Gont Subject: Re: [tcpm] ICMP attacks draft (issue 1): hard errors -> soft errors (in synchronized states) In-Reply-To: <20050923165017.GD10959@pun.isi.edu> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: tcpm@ietf.org, Joe Touch X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 01:50 p.m. 23/09/2005, Ted Faber wrote: >The point is that for whatever reason, all the host can do is send a >Protocol Not Supported ICMP, because the TCP stack will not be reached >(the postulate is that the host has stopped speaking either TCP or >IPv4). Because the packet can't get to the TCP stack (which may not be >running at all), the host can't generate an RST. > >Of course, if no ICMP is generated or gets through, the ESTABLISHED TCP >will eventually have a UTO and abort the connection. > >Yes, this is a pretty bizarre case, but it is a valid hard error in an >ESTABLISHED state, and one where aborting the connection is the most >sensible thing to do. So we would keep connections vulnerable to reset attacks for that 1 in 1000000th chance in which this scenario might take place? (And, btw, in the event that happened, why would ignoring the ICMP message hurt you? For instance, the proposed policy does not prevent the application layer from being notified of the received ICMP error message! So this means you still let the application shoot itself, if it wants to! :-) ) Also, if there's consensus on the side of "not doing anything about this", then my next question/comment would be "Does it make sense to modify TCP's state transition diagram (as we currently are) to address TCP-based reset attacks, then? An attacker will use ICMP-based ones, because they are much easier to perform!" Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Sep 27 02:22:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK8qm-0005uI-GS; Tue, 27 Sep 2005 02:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK8qj-0005tm-TC for tcpm@megatron.ietf.org; Tue, 27 Sep 2005 02:21:58 -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 CAA16866 for ; Tue, 27 Sep 2005 02:21:56 -0400 (EDT) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EK8xg-0002aX-FY for tcpm@ietf.org; Tue, 27 Sep 2005 02:29:23 -0400 Received: (qmail 13637 invoked from network); 27 Sep 2005 06:20:52 -0000 Received: from unknown (HELO fgont.gont.com.ar) (gont-fernando@200.70.146.149) by server.frh.utn.edu.ar with SMTP; 27 Sep 2005 06:20:52 -0000 Message-Id: <6.2.0.14.0.20050927013116.03fedc70@pop.frh.utn.edu.ar> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 27 Sep 2005 01:54:24 -0300 To: Joe Touch From: Fernando Gont Subject: Re: [tcpm] ICMP attacks draft (issue 1): hard errors -> soft errors (in synchronized states) In-Reply-To: <4334345F.2060301@isi.edu> 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> <4334345F.2060301@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 01:59 p.m. 23/09/2005, you wrote: > >> > Issue 1 is: When a so-called ICMP "hard error" is received for a > >> > connection in any of the synchronized states (ESTABLISHED and so on), > >> > treat the error message as a soft error (i.e., do NOT abort the > >> > corresponding connection). > >> > >> WHY? Such an error could occur due to a reboot. It is legitimate > >> operation. > > > > > > In that case you should receive an RST, not an ICMP message. > >Not if there is no TCP running, or none over IPv4 (i.e., convert to IPv6). Despite how likely or unlikely you consider this scenario to happen (if you are thinking about IDSes/firewalls, then there are other more-specific codes to use), why, if TCP was disabled during the life of a connection, couldn't it be re-enabled again? > > In one case (soft errors draft), an ICMP error message is received > > during connection-establishment. > > In this case, (ICMP attacks draft), I'm talking about ICMP error > > messages received during the life of a connection. > >But why should one be considered less hard, and one more hard? It's >basically reaction to the _inferred_ cause of such a message - in the >first case you assume it's benign and use it to fail-over, and in the >second you assume it's an attack and want to ignore it. It's a matter of mechanism / policy separation. The fact that the mechanism is the same does not mean the *policy* has to be the same. There's a rationale on this very same issue in D. Clark's paper, which is cited in my draft. There are other works on mechanism/policy separation. I have not invented anything. >I don't agree with inferring things this way, esp. since such inferences >are based on a snapshot of typical use at the time the ID is published. Do not infer things... i.e., do not infer attack. Just infer the message indicates it's a *soft* error. (Yes, maybe the draft could be tweaked a *bit* on this) BTW, I don't think this reflects "typical use at the time the ID is published", unless you are thinking of a time frame of at least fifteen years. > > An ICMP error message is just a hint. As per D. Clark's paper, depending > > on the time you receive the message, the meaning may be different. > >Agreed - but the meaning should always be considered benign before it is >considered an attack. If a benign cause _could_ have resulted in the >message, it seems inappropriate to react as if it's an attack. I disagree. First, a spurious message is not benign. Unless you would also call "benign" a spurious message that resets your connections every other second, for example. Other than that, the current environment is *not* benign. There's a chance someone can break the door of my house, the window of my house or even the wall of my house to save me from a fire, or whatever (maybe it's just someone that just fell over them!). However, it seems to be fair to think that if someone does break my window, door, or wall, there are much more likely reasons for doing this, than "benign" ones. Anyway, again: the draft describes possible attacks, and possible ways to address them. No need to "infer": Implement this if it's one of the described attacks that is taking place, it will protect you. If it's not, it won't hurt you. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Sep 27 02:34:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK935-00009o-Iu; Tue, 27 Sep 2005 02:34:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK933-00009b-98 for tcpm@megatron.ietf.org; Tue, 27 Sep 2005 02:34:41 -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 CAA17780 for ; Tue, 27 Sep 2005 02:34:40 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EK9AC-0002pK-Kw for tcpm@ietf.org; Tue, 27 Sep 2005 02:42:08 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j8R6YBR23425; Tue, 27 Sep 2005 09:34:11 +0300 Date: Tue, 27 Sep 2005 09:34:11 +0300 (EEST) From: Pekka Savola To: Ted Faber Subject: Re: [tcpm] Feedback on draft-gont-tcpm-icmp-attacks-04.txt In-Reply-To: <20050923145210.GC10959@pun.isi.edu> Message-ID: References: <20050922162344.GC31229@pun.isi.edu> <20050923145210.GC10959@pun.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 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, 23 Sep 2005, Ted Faber wrote: >> Isn't there sufficient evidence that "filter all ICMP" breaks most >> (all?) transport protocols in obvious and/or subtle ways? (Just >> consider but there are probably other examples.) So, I fail to see how >> one could argue that "protocols have to work" -- but maybe this >> depends on the context and the definition of "work" (i.e., which kinds >> of functionality or performance degradations would be acceptable). > > ICMP's unreliably delivered, and optional (though strongly encouraged) > to generate. If protocols rely on it, they're in some amount of > trouble. I understand that some protocol may rely on it, but it's IMHO > misdesgigned. I can't think of any way (outside maybe PMTU, which I > don't know much about) that TCP might be broken here. > > Give me an example of breakage. PMTUD alone should be sufficient example :). Note that in the case of PMTUD (and many other ICMP errors in general), if the ICMP error gets lost, the sending host will try to send again -- which will trigger another ICMP error, and another, and another.. While single ICMP errors are unreliable, in practice it seems they will be resent as many times as necessary (or until the original TCP/UDP/... sender gives up in any case). (Sending ICMP errors is usually subject to some rate-limiting, but some are bound to be sent again sooner or later.) -- 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 Tue Sep 27 10:15:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKGFO-00039X-7y; Tue, 27 Sep 2005 10:15:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKGFM-00038k-Aw for tcpm@megatron.ietf.org; Tue, 27 Sep 2005 10:15:52 -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 KAA11129 for ; Tue, 27 Sep 2005 10:15:50 -0400 (EDT) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKGMa-0006Xy-B8 for tcpm@ietf.org; Tue, 27 Sep 2005 10:23:22 -0400 Received: (qmail 29737 invoked from network); 27 Sep 2005 14:15:06 -0000 Received: from 200-70-144-105.mrse.com.ar (HELO fgont.gont.com.ar) (gont-fernando@200.70.144.105) by server.frh.utn.edu.ar with SMTP; 27 Sep 2005 14:15:06 -0000 Message-Id: <6.2.0.14.0.20050927110513.04010528@pop.frh.utn.edu.ar> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 27 Sep 2005 11:13:06 -0300 To: Ted Faber From: Fernando Gont Subject: Re: [tcpm] ICMP attacks draft (issue 1): hard errors -> soft errors (in synchronized states) In-Reply-To: <20050923165017.GD10959@pun.isi.edu> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 3.5 (+++) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: tcpm@ietf.org, Joe Touch X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 01:50 p.m. 23/09/2005, you wrote: >Imagine a host that speaks IPv4 and TCP. You connect to it. The host >goes down and reboots (fairly quickly), but it's flag day, and the host >now no longer supports IPv4 at all, or no longer supports TCP at all. [....] >The point is that for whatever reason, all the host can do is send a >Protocol Not Supported ICMP, because the TCP stack will not be reached >(the postulate is that the host has stopped speaking either TCP or >IPv4). Because the packet can't get to the TCP stack (which may not be >running at all), the host can't generate an RST. Imagine that your connection is operating over a long fat pipe (large bandwidth delay product), and assume you are implementing RFC1323 for PAWS. The ICMP message may contain just the first 64 bits of the original IP datagram that elicited the error (i.e., no timestamps). You might end-up aborting a connection in response to an error message caused by an old segment. Just another scenario in which the same mechanism/feature protects you both from incidental (stale error message, in this case) and intentional (as in the ICMP-based reset attack). So my take is that aborting the connection could probably be not the most sensible thing to do in this case, either. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Sep 27 11:11:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKH7X-0000Mt-Sp; Tue, 27 Sep 2005 11:11:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKH7W-0000Mi-Sx for tcpm@megatron.ietf.org; Tue, 27 Sep 2005 11:11:50 -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 LAA16789 for ; Tue, 27 Sep 2005 11:11:48 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKHEm-0008Ga-P6 for tcpm@ietf.org; Tue, 27 Sep 2005 11:19:22 -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 j8RFAGY19516; Tue, 27 Sep 2005 08:10:17 -0700 (PDT) Message-ID: <433960D2.4040702@isi.edu> Date: Tue, 27 Sep 2005 08:10:10 -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] Feedback on draft-gont-tcpm-icmp-attacks-04.txt References: <20050922162344.GC31229@pun.isi.edu> <20050923145210.GC10959@pun.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: 4d87d2aa806f79fed918a62e834505ca Cc: tcpm@ietf.org, Ted Faber X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0753389342==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0753389342== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFF71B703F704CF893FDF6594" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFF71B703F704CF893FDF6594 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Pekka Savola wrote: > On Fri, 23 Sep 2005, Ted Faber wrote: > >>> Isn't there sufficient evidence that "filter all ICMP" breaks most >>> (all?) transport protocols in obvious and/or subtle ways? (Just >>> consider but there are probably other examples.) So, I fail to see how >>> one could argue that "protocols have to work" -- but maybe this >>> depends on the context and the definition of "work" (i.e., which kinds >>> of functionality or performance degradations would be acceptable). >> >> >> ICMP's unreliably delivered, and optional (though strongly encouraged) >> to generate. If protocols rely on it, they're in some amount of >> trouble. I understand that some protocol may rely on it, but it's IMHO >> misdesgigned. I can't think of any way (outside maybe PMTU, which I >> don't know much about) that TCP might be broken here. >> >> Give me an example of breakage. > > > PMTUD alone should be sufficient example :). Note that in the case of > PMTUD (and many other ICMP errors in general), if the ICMP error gets > lost, the sending host will try to send again -- which will trigger > another ICMP error, and another, and another.. Until it times out. Which is what already happens for blackholes and more than a few firewalls anyway, so this isn't a new situation. Joe --------------enigFF71B703F704CF893FDF6594 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 iD8DBQFDOWDSE5f5cImnZrsRAhAKAJ0SNghk9gy76xLPXWCFge+ea9/CKQCgxBH/ 8rUFUs4eLP0uqm6ZzV3v2rE= =Krhw -----END PGP SIGNATURE----- --------------enigFF71B703F704CF893FDF6594-- --===============0753389342== 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 --===============0753389342==-- From tcpm-bounces@ietf.org Tue Sep 27 15:16:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKKwX-0005DG-Bh; Tue, 27 Sep 2005 15:16:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKKwW-0005DB-5o for tcpm@megatron.ietf.org; Tue, 27 Sep 2005 15:16: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 PAA03044 for ; Tue, 27 Sep 2005 15:16:42 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKL3o-0006mr-1N for tcpm@ietf.org; Tue, 27 Sep 2005 15:24:17 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j8RJGLW06043; Tue, 27 Sep 2005 22:16:21 +0300 Date: Tue, 27 Sep 2005 22:16:21 +0300 (EEST) From: Pekka Savola To: Joe Touch Subject: Re: [tcpm] Feedback on draft-gont-tcpm-icmp-attacks-04.txt In-Reply-To: <433960D2.4040702@isi.edu> Message-ID: References: <20050922162344.GC31229@pun.isi.edu> <20050923145210.GC10959@pun.isi.edu> <433960D2.4040702@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: tcpm@ietf.org, Ted Faber X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Tue, 27 Sep 2005, Joe Touch wrote: >> PMTUD alone should be sufficient example :). Note that in the case of >> PMTUD (and many other ICMP errors in general), if the ICMP error gets >> lost, the sending host will try to send again -- which will trigger >> another ICMP error, and another, and another.. > > Until it times out. Which is what already happens for blackholes and > more than a few firewalls anyway, so this isn't a new situation. Sure.. but it's an unrecoverable condition: no matter how many times the application would try to retry the TCP transmission, it's going to fail the identically same manner. I'd call that 'broken TCP'. But that aside, the main point was not that this happens but whether the document could just recommend filtering out all ICMPs. IMHO, TCP breaks too badly for us to recommend that. -- 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 Tue Sep 27 15:51:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKLU7-0005dG-7X; Tue, 27 Sep 2005 15:51:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKLU6-0005d6-Jz for tcpm@megatron.ietf.org; Tue, 27 Sep 2005 15:51:26 -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 PAA05364 for ; Tue, 27 Sep 2005 15:51:25 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKLbN-0007hq-0j for tcpm@ietf.org; Tue, 27 Sep 2005 15:59:00 -0400 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8RJo5Y21282; Tue, 27 Sep 2005 12:50:05 -0700 (PDT) Message-ID: <4339A1F7.2000904@isi.edu> Date: Tue, 27 Sep 2005 12:48:07 -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] Feedback on draft-gont-tcpm-icmp-attacks-04.txt References: <20050922162344.GC31229@pun.isi.edu> <20050923145210.GC10959@pun.isi.edu> <433960D2.4040702@isi.edu> In-Reply-To: X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org, Ted Faber X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pekka Savola wrote: > On Tue, 27 Sep 2005, Joe Touch wrote: > >>> PMTUD alone should be sufficient example :). Note that in the case of >>> PMTUD (and many other ICMP errors in general), if the ICMP error gets >>> lost, the sending host will try to send again -- which will trigger >>> another ICMP error, and another, and another.. >> >> >> Until it times out. Which is what already happens for blackholes and >> more than a few firewalls anyway, so this isn't a new situation. > > > Sure.. but it's an unrecoverable condition: no matter how many times the > application would try to retry the TCP transmission, it's going to fail > the identically same manner. I'd call that 'broken TCP'. > > But that aside, the main point was not that this happens but whether the > document could just recommend filtering out all ICMPs. IMHO, TCP breaks > too badly for us to recommend that. In general, I agree - but there seems to be a spirit these days of saying "but people do it". If that spirit exists elsewhere in the doc, it's warranted here. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDOaH3E5f5cImnZrsRAjVbAKDnk5s4CnWpa+85onvOvPxYNurUBQCfRwca c+o9WIxJri3kzTOegp0PPmM= =xT0j -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Sep 27 16:08:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKLkO-0003Je-1L; Tue, 27 Sep 2005 16:08:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKLkM-0003FJ-Ix for tcpm@megatron.ietf.org; Tue, 27 Sep 2005 16:08: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 QAA09624 for ; Tue, 27 Sep 2005 16:08:13 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKLre-00014T-4b for tcpm@ietf.org; Tue, 27 Sep 2005 16:15:48 -0400 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8RK6qY25977; Tue, 27 Sep 2005 13:06:52 -0700 (PDT) Message-ID: <4339A5E6.8000906@isi.edu> Date: Tue, 27 Sep 2005 13:04:54 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fernando Gont 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.20050927110513.04010528@pop.frh.utn.edu.ar> In-Reply-To: <6.2.0.14.0.20050927110513.04010528@pop.frh.utn.edu.ar> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org, Ted Faber X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: > At 01:50 p.m. 23/09/2005, you wrote: > >> Imagine a host that speaks IPv4 and TCP. You connect to it. The host >> goes down and reboots (fairly quickly), but it's flag day, and the host >> now no longer supports IPv4 at all, or no longer supports TCP at all. > > [....] > >> The point is that for whatever reason, all the host can do is send a >> Protocol Not Supported ICMP, because the TCP stack will not be reached >> (the postulate is that the host has stopped speaking either TCP or >> IPv4). Because the packet can't get to the TCP stack (which may not be >> running at all), the host can't generate an RST. > > Imagine that your connection is operating over a long fat pipe (large > bandwidth delay product), and assume you are implementing RFC1323 for PAWS. > > The ICMP message may contain just the first 64 bits of the original IP > datagram that elicited the error (i.e., no timestamps). > > You might end-up aborting a connection in response to an error message > caused by an old segment. Yes, since you didn't know it was an old segment - which you would do only if you heck the SEQNUM and not the PAWS. But this is a good reason to parse the header properly - if there are TCP options which are not included in the ICMP, it may not be appropriate to interpret parts of the header that are affected by possible options - such as SEQNUM. > Just another scenario in which the same mechanism/feature protects you > both from incidental (stale error message, in this case) and intentional > (as in the ICMP-based reset attack). This is backwards; the mechanism doesn't protect you, notably because yuo would abort the connection. Checking the SEQNUM in the absence of the PAWS is just as bad as checking the SEQNUM in the absence of the checksum. > So my take is that aborting the connection could probably be not the > most sensible thing to do in this case, either. IF you're arguing that 'checks are useful for protection' - regardless of the protection - then you have to do the checks. ALL the checks that affect the semantics of what you're checking. Not just the ones that protect from what you think are attacks, IMO. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDOaXmE5f5cImnZrsRAlXVAJsGpm3vBjxzw3JMUu/eK8yC4o67WQCeIu+r uAI3IsOsNu451PR4Qshg3Kw= =IrYK -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Sep 27 16:29:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKM4s-0006s6-2D; Tue, 27 Sep 2005 16:29:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKM4q-0006q9-CA for tcpm@megatron.ietf.org; Tue, 27 Sep 2005 16:29:24 -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 QAA18377 for ; Tue, 27 Sep 2005 16:29:21 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKMC8-0004Oz-VW for tcpm@ietf.org; Tue, 27 Sep 2005 16:36:57 -0400 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8RKSlY04396; Tue, 27 Sep 2005 13:28:47 -0700 (PDT) Message-ID: <4339AB09.70501@isi.edu> Date: Tue, 27 Sep 2005 13:26:49 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fernando Gont 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> <4334345F.2060301@isi.edu> <6.2.0.14.0.20050927013116.03fedc70@pop.frh.utn.edu.ar> In-Reply-To: <6.2.0.14.0.20050927013116.03fedc70@pop.frh.utn.edu.ar> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: 7bit 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: > At 01:59 p.m. 23/09/2005, you wrote: > >> >> > Issue 1 is: When a so-called ICMP "hard error" is received for a >> >> > connection in any of the synchronized states (ESTABLISHED and so >> on), >> >> > treat the error message as a soft error (i.e., do NOT abort the >> >> > corresponding connection). >> >> >> >> WHY? Such an error could occur due to a reboot. It is legitimate >> >> operation. >> > >> > >> > In that case you should receive an RST, not an ICMP message. >> >> Not if there is no TCP running, or none over IPv4 (i.e., convert to >> IPv6). > > Despite how likely or unlikely you consider this scenario to happen (if > you are thinking about IDSes/firewalls, then there are other > more-specific codes to use), why, if TCP was disabled during the life of > a connection, couldn't it be re-enabled again? It could. But if it doesn't, again you would receive only an ICMP. >> > In one case (soft errors draft), an ICMP error message is received >> > during connection-establishment. >> > In this case, (ICMP attacks draft), I'm talking about ICMP error >> > messages received during the life of a connection. >> >> But why should one be considered less hard, and one more hard? It's >> basically reaction to the _inferred_ cause of such a message - in the >> first case you assume it's benign and use it to fail-over, and in the >> second you assume it's an attack and want to ignore it. > > It's a matter of mechanism / policy separation. > > The fact that the mechanism is the same does not mean the *policy* has > to be the same. > > There's a rationale on this very same issue in D. Clark's paper, which > is cited in my draft. There are other works on mechanism/policy separation. > > I have not invented anything. You're application of the existing principle is based on your inference that everything you don't expect MUST be an attack, or at least MUST be treated as such. IMO, 'be liberal in what you receive' (Postel's rationale) warrants that IF there is a legitimate or benign reason that the same packet could have arrived, then it MUST NOT be treated as an attack. >> I don't agree with inferring things this way, esp. since such inferences >> are based on a snapshot of typical use at the time the ID is published. > > Do not infer things... i.e., do not infer attack. Just infer the message > indicates it's a *soft* error. (Yes, maybe the draft could be tweaked a > *bit* on this) I don't understand why the message indicates it's a soft error; it's clear that some of these messages are hard errors and intended as such (e.g., the case where TCPv4 disappears). > BTW, I don't think this reflects "typical use at the time the ID is > published", unless you are thinking of a time frame of at least fifteen > years. > > > >> > An ICMP error message is just a hint. As per D. Clark's paper, >> depending >> > on the time you receive the message, the meaning may be different. >> >> Agreed - but the meaning should always be considered benign before it is >> considered an attack. If a benign cause _could_ have resulted in the >> message, it seems inappropriate to react as if it's an attack. > > I disagree. First, a spurious message is not benign. Unless you would > also call "benign" a spurious message that resets your connections every > other second, for example. > > Other than that, the current environment is *not* benign. > > There's a chance someone can break the door of my house, the window of > my house or even the wall of my house to save me from a fire, or > whatever (maybe it's just someone that just fell over them!). However, > it seems to be fair to think that if someone does break my window, door, > or wall, there are much more likely reasons for doing this, than > "benign" ones. > > Anyway, again: the draft describes possible attacks, and possible ways > to address them. No need to "infer": Implement this if it's one of the > described attacks that is taking place, it will protect you. If it's > not, it won't hurt you. It will protect you from the firemen too (e.g., ICMPs for TCPv4 that disappears, as one example). Which DOES hurt you. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDOasJE5f5cImnZrsRAmWfAKDNolzOILsIacjEbeGVuyQiZ6jZJwCfT4Eo 21aZUOPpjPEMiCDMLVQTjoA= =oUJO -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Sep 27 21:19:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKQbT-0007en-Js; Tue, 27 Sep 2005 21:19:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKQbS-0007ei-Fv for tcpm@megatron.ietf.org; Tue, 27 Sep 2005 21:19:22 -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 VAA05037 for ; Tue, 27 Sep 2005 21:19:21 -0400 (EDT) Received: from ixe-nat1.juniper.net ([193.110.54.36] helo=up-smtp.jnpr.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKQio-0003av-00 for tcpm@ietf.org; Tue, 27 Sep 2005 21:26:59 -0400 Received: from emailemea1.jnpr.net ([172.26.192.140]) by up-smtp.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 28 Sep 2005 02:19:03 +0100 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by emailemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 28 Sep 2005 02:19:03 +0100 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 27 Sep 2005 21:19:02 -0400 Received: from [172.23.1.20] ([172.23.1.20] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Sep 2005 21:20:20 -0400 Message-ID: <4339EF82.1030000@juniper.net> Date: Tue, 27 Sep 2005 21:18:58 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Faber Subject: Re: [tcpm] draft-bonica-tcp-auth-00 References: <432C27E2.1060409@juniper.net> <20050919173948.GB66350@pun.isi.edu> In-Reply-To: <20050919173948.GB66350@pun.isi.edu> X-Enigmail-Version: 0.92.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Sep 2005 01:20:20.0718 (UTC) FILETIME=[CB0A30E0:01C5C3CA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Ted, Thanks for these comments. I have worked them into the next version of the document and will post it shortly. Ron Ted Faber wrote: > On Sat, Sep 17, 2005 at 10:27:46AM -0400, Ron Bonica wrote: > >>Please consider the following draft as an individual submission: >> >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. > > [snip] > >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-bonica-tcp-auth-00.txt > > > I skimmed this over, and (with my co-chair hat off) the only real > concerns I have with this are: > > * It seems like a bit of a band-aid on the MD5 TCP stuff, > without fixing the real problem that it requires configuration > coordination. > * I think that as specified you're free from problems cause dby > any but the most ridiculous clock skew, but adding a paragraph > indicating that's the case probably wouldn't hurt. > Specifically you might want to address when an endpoint can > discard authentication entities. You might also want to > briefly explain that a host receiving a packet authenticated > with an authentication element that the receiving endpoint > does not believe has passed its start time is not an error > because clocks may have skewed. > > Do others have deeper objections? > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Sep 28 05:15:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKY1r-0003RP-Vf; Wed, 28 Sep 2005 05:15:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKY1m-0003Oy-P7 for tcpm@megatron.ietf.org; Wed, 28 Sep 2005 05:15: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 FAA24155 for ; Wed, 28 Sep 2005 05:15:00 -0400 (EDT) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKY91-0006xX-QS for tcpm@ietf.org; Wed, 28 Sep 2005 05:22:43 -0400 Received: (qmail 17507 invoked from network); 28 Sep 2005 09:13:53 -0000 Received: from unknown (HELO fgont.gont.com.ar) (gont-fernando@200.70.144.8) by server.frh.utn.edu.ar with SMTP; 28 Sep 2005 09:13:53 -0000 Message-Id: <6.2.0.14.0.20050928034642.08012bf0@pop.frh.utn.edu.ar> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 28 Sep 2005 04:35:33 -0300 To: Joe Touch From: Fernando Gont Subject: Re: [tcpm] ICMP attacks draft (issue 1): hard errors -> soft errors (in synchronized states) In-Reply-To: <4339AB09.70501@isi.edu> 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> <4334345F.2060301@isi.edu> <6.2.0.14.0.20050927013116.03fedc70@pop.frh.utn.edu.ar> <4339AB09.70501@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 05:26 p.m. 27/09/2005, Joe Touch wrote: > >> > In that case you should receive an RST, not an ICMP message. > >> > >> Not if there is no TCP running, or none over IPv4 (i.e., convert to > >> IPv6). > > > > Despite how likely or unlikely you consider this scenario to happen (if > > you are thinking about IDSes/firewalls, then there are other > > more-specific codes to use), why, if TCP was disabled during the life of > > a connection, couldn't it be re-enabled again? > >It could. But if it doesn't, again you would receive only an ICMP. Exactly. But this means the so-called ICMP hard errors do not necessarily indicate "hard errors". Treating had errors as soft errors (in the synchronized states) improves TCP's robustness. > > It's a matter of mechanism / policy separation. > > > > The fact that the mechanism is the same does not mean the *policy* has > > to be the same. > > > > There's a rationale on this very same issue in D. Clark's paper, which > > is cited in my draft. There are other works on mechanism/policy separation. > > > > I have not invented anything. > >You're application of the existing principle is based on your inference >that everything you don't expect MUST be an attack, or at least MUST be >treated as such. No. I'm just saying that one needs to be more cautious when processing ICMP messages. The ICMP messages could be part of an attack, or could be stale. In any of these two cases, honoring them would be ill advice. The same policies that protect you from attack also protect you from stale error messages. >IMO, 'be liberal in what you receive' (Postel's rationale) warrants that >IF there is a legitimate or benign reason that the same packet could >have arrived, then it MUST NOT be treated as an attack. I disagree. That's just an interpretation. I take it as "even something you don't expect should not break your system" i.e. "you should be albe to deal with unexpected packets nicely". > >> I don't agree with inferring things this way, esp. since such inferences > >> are based on a snapshot of typical use at the time the ID is published. > > > > Do not infer things... i.e., do not infer attack. Just infer the message > > indicates it's a *soft* error. (Yes, maybe the draft could be tweaked a > > *bit* on this) > >I don't understand why the message indicates it's a soft error; it's >clear that some of these messages are hard errors and intended as such >(e.g., the case where TCPv4 disappears). Yes, *some*, and in *certain* circumstances/scenarios. The more conservative way to go is to not break connections. > > There's a chance someone can break the door of my house, the window of > > my house or even the wall of my house to save me from a fire, or > > whatever (maybe it's just someone that just fell over them!). However, > > it seems to be fair to think that if someone does break my window, door, > > or wall, there are much more likely reasons for doing this, than > > "benign" ones. > > > > Anyway, again: the draft describes possible attacks, and possible ways > > to address them. No need to "infer": Implement this if it's one of the > > described attacks that is taking place, it will protect you. If it's > > not, it won't hurt you. > >It will protect you from the firemen too (e.g., ICMPs for TCPv4 that >disappears, as one example). Which DOES hurt you. I does not hurt. Remember: ICMP is unreliable. The ICMP error message may be corrupted, may be subject to rate limitation, etc. And again, processing of protocol unreachables is a SHOULD, not a MUST. If you really think my proposal hurts, you should submit a proposal entitled "Tunnelling ICMP over TCP", or the like. -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Sep 29 08:37:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKxfK-0002zw-1Q; Thu, 29 Sep 2005 08:37:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKxfI-0002w7-5s for tcpm@megatron.ietf.org; Thu, 29 Sep 2005 08:37:32 -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 IAA08283 for ; Thu, 29 Sep 2005 08:37:30 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKxmx-0000mC-1l for tcpm@ietf.org; Thu, 29 Sep 2005 08:45:27 -0400 Received: from [128.30.5.112] (30-5-112.wireless.csail.mit.edu [128.30.5.112]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8TCaAY07292; Thu, 29 Sep 2005 05:36:10 -0700 (PDT) Message-ID: <433BDFB8.4090407@isi.edu> Date: Thu, 29 Sep 2005 05:36:08 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fernando Gont 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> <4334345F.2060301@isi.edu> <6.2.0.14.0.20050927013116.03fedc70@pop.frh.utn.edu.ar> <4339AB09.70501@isi.edu> <6.2.0.14.0.20050928034642.08012bf0@pop.frh.utn.edu.ar> In-Reply-To: <6.2.0.14.0.20050928034642.08012bf0@pop.frh.utn.edu.ar> 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: 87a3f533bb300b99e2a18357f3c1563d 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="===============1962660869==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1962660869== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0879F9EBF0C15D4B6EB38BFF" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0879F9EBF0C15D4B6EB38BFF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Fernando Gont wrote: > At 05:26 p.m. 27/09/2005, Joe Touch wrote: > >> >> > In that case you should receive an RST, not an ICMP message. >> >> >> >> Not if there is no TCP running, or none over IPv4 (i.e., convert to >> >> IPv6). >> > >> > Despite how likely or unlikely you consider this scenario to happen (if >> > you are thinking about IDSes/firewalls, then there are other >> > more-specific codes to use), why, if TCP was disabled during the >> life of >> > a connection, couldn't it be re-enabled again? >> >> It could. But if it doesn't, again you would receive only an ICMP. > > Exactly. But this means the so-called ICMP hard errors do not > necessarily indicate "hard errors". > Treating had errors as soft errors (in the synchronized states) improves > TCP's robustness. Not to recovery, but that's the issue with another draft. ;-) >> > It's a matter of mechanism / policy separation. >> > >> > The fact that the mechanism is the same does not mean the *policy* has >> > to be the same. >> > >> > There's a rationale on this very same issue in D. Clark's paper, which >> > is cited in my draft. There are other works on mechanism/policy >> separation. >> > >> > I have not invented anything. >> >> You're application of the existing principle is based on your inference >> that everything you don't expect MUST be an attack, or at least MUST be >> treated as such. > > No. I'm just saying that one needs to be more cautious when processing > ICMP messages. > The ICMP messages could be part of an attack, or could be stale. In any > of these two cases, honoring them would be ill advice. That's true. The question is when/whether you can determine either. If you can't, then NOT honoring them is ill advice. The principle of 'be generous in what you receive' means it's more useful in general to assume the best, not the worst, of things you don't have other indications about. > The same policies that protect you from attack also protect you from > stale error messages. > >> IMO, 'be liberal in what you receive' (Postel's rationale) warrants that >> IF there is a legitimate or benign reason that the same packet could >> have arrived, then it MUST NOT be treated as an attack. > > I disagree. That's just an interpretation. I take it as "even something > you don't expect should not break your system" i.e. "you should be albe > to deal with unexpected packets nicely". Yeah - and these could be unexpected, but legitimate. So you interpret them as attacks and ignore them? >> >> I don't agree with inferring things this way, esp. since such >> inferences >> >> are based on a snapshot of typical use at the time the ID is >> published. >> > >> > Do not infer things... i.e., do not infer attack. Just infer the >> message >> > indicates it's a *soft* error. (Yes, maybe the draft could be tweaked a >> > *bit* on this) >> >> I don't understand why the message indicates it's a soft error; it's >> clear that some of these messages are hard errors and intended as such >> (e.g., the case where TCPv4 disappears). > > Yes, *some*, and in *certain* circumstances/scenarios. The more > conservative way to go is to not break connections. Or break connections that are in the process of being established either. So which ID do you want to withdraw, this or the TCP soft-errors one? ;-) And conservative in this forum also includes "don't change the spec unless absolutely necessary". Near as I can tell, this is motivated solely by security, which it does not provide. >> > There's a chance someone can break the door of my house, the window of >> > my house or even the wall of my house to save me from a fire, or >> > whatever (maybe it's just someone that just fell over them!). However, >> > it seems to be fair to think that if someone does break my window, >> door, >> > or wall, there are much more likely reasons for doing this, than >> > "benign" ones. >> > >> > Anyway, again: the draft describes possible attacks, and possible ways >> > to address them. No need to "infer": Implement this if it's one of the >> > described attacks that is taking place, it will protect you. If it's >> > not, it won't hurt you. >> >> It will protect you from the firemen too (e.g., ICMPs for TCPv4 that >> disappears, as one example). Which DOES hurt you. > > I does not hurt. Remember: ICMP is unreliable. The ICMP error message > may be corrupted, may be subject to rate limitation, etc. > And again, processing of protocol unreachables is a SHOULD, not a MUST. And this changes it to a MUST NOT. Which I disagree with. > If you really think my proposal hurts, you should submit a proposal > entitled "Tunnelling ICMP over TCP", or the like. You've repeatedly suggested that if I don't like your drafts, I should write alternative drafts. Here's my perspective on this: not all IDs *SHOULD* go to RFC Sometimes the solution is to not write anything, and leave things as-is. Joe --------------enig0879F9EBF0C15D4B6EB38BFF 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 iD8DBQFDO9+4E5f5cImnZrsRAhivAKCh6N4q+vPtF/Gbd1gB2MHqxAMxAACfQ6Um Ee2hc+nZWesvDVS4u/ilnrA= =9bX4 -----END PGP SIGNATURE----- --------------enig0879F9EBF0C15D4B6EB38BFF-- --===============1962660869== 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 --===============1962660869==-- From tcpm-bounces@ietf.org Thu Sep 29 11:34:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL0QH-0003A3-Un; Thu, 29 Sep 2005 11:34:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL0QG-00039y-Do for tcpm@megatron.ietf.org; Thu, 29 Sep 2005 11:34:12 -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 LAA18929 for ; Thu, 29 Sep 2005 11:34:09 -0400 (EDT) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL0Xu-0005Og-60 for tcpm@ietf.org; Thu, 29 Sep 2005 11:42:09 -0400 Received: (qmail 13931 invoked from network); 29 Sep 2005 15:33:16 -0000 Received: from 200-70-144-11.mrse.com.ar (HELO fgont.gont.com.ar) (gont-fernando@200.70.144.11) by server.frh.utn.edu.ar with SMTP; 29 Sep 2005 15:33:16 -0000 Message-Id: <6.2.0.14.0.20050929120406.03d79008@pop.frh.utn.edu.ar> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 29 Sep 2005 12:15:26 -0300 To: Joe Touch From: Fernando Gont Subject: Re: [tcpm] ICMP attacks draft (issue 1): hard errors -> soft errors (in synchronized states) In-Reply-To: <433BDFB8.4090407@isi.edu> 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> <4334345F.2060301@isi.edu> <6.2.0.14.0.20050927013116.03fedc70@pop.frh.utn.edu.ar> <4339AB09.70501@isi.edu> <6.2.0.14.0.20050928034642.08012bf0@pop.frh.utn.edu.ar> <433BDFB8.4090407@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 09:36 a.m. 29/09/2005, Joe Touch wrote: > >> You're application of the existing principle is based on your inference > >> that everything you don't expect MUST be an attack, or at least MUST be > >> treated as such. > > > > No. I'm just saying that one needs to be more cautious when processing > > ICMP messages. > > The ICMP messages could be part of an attack, or could be stale. In any > > of these two cases, honoring them would be ill advice. > >That's true. The question is when/whether you can determine either. If >you can't, then NOT honoring them is ill advice. The principle of 'be >generous in what you receive' means it's more useful in general to >assume the best, not the worst, of things you don't have other >indications about. It's not useful to open the door to attack. For instance, we are also working on spoofing attacks. If you want to be generous, then take all spoofed packets as legitimate. > > The same policies that protect you from attack also protect you from > > stale error messages. > > > >> IMO, 'be liberal in what you receive' (Postel's rationale) warrants that > >> IF there is a legitimate or benign reason that the same packet could > >> have arrived, then it MUST NOT be treated as an attack. > > > > I disagree. That's just an interpretation. I take it as "even something > > you don't expect should not break your system" i.e. "you should be albe > > to deal with unexpected packets nicely". > >Yeah - and these could be unexpected, but legitimate. So you interpret >them as attacks and ignore them? I don't necessarily take them as attack. And I disagree with your interpretation of the robustness principle, in 2005 (and up) it's fair to assume the environmnent is hostile. That's why there's a mandatory "Security Considerations" section in today's documents. > >> I don't understand why the message indicates it's a soft error; it's > >> clear that some of these messages are hard errors and intended as such > >> (e.g., the case where TCPv4 disappears). > > > > Yes, *some*, and in *certain* circumstances/scenarios. The more > > conservative way to go is to not break connections. > >Or break connections that are in the process of being established >either. So which ID do you want to withdraw, this or the TCP soft-errors >one? ;-) The soft errors one is not for the Standards track, anymore. And, as I said before, assuming that the same mechanism always implies the same policy is short-sighted. >And conservative in this forum also includes "don't change the spec >unless absolutely necessary". Near as I can tell, this is motivated >solely by security, which it does not provide. That's "rehashing the past", rather than "being conservative". > >> > Anyway, again: the draft describes possible attacks, and possible ways > >> > to address them. No need to "infer": Implement this if it's one of the > >> > described attacks that is taking place, it will protect you. If it's > >> > not, it won't hurt you. > >> > >> It will protect you from the firemen too (e.g., ICMPs for TCPv4 that > >> disappears, as one example). Which DOES hurt you. > > > > I does not hurt. Remember: ICMP is unreliable. The ICMP error message > > may be corrupted, may be subject to rate limitation, etc. > > And again, processing of protocol unreachables is a SHOULD, not a MUST. > >And this changes it to a MUST NOT. Which I disagree with. The app can still shoot itself, as my draft does not say the hard errors should not be signaled to the user application. > > If you really think my proposal hurts, you should submit a proposal > > entitled "Tunnelling ICMP over TCP", or the like. > >You've repeatedly suggested that if I don't like your drafts, I should >write alternative drafts. Here's my perspective on this: No, what I'm meaning is that if you think that treating hard errors as soft errors is ill-adviced, you should also arge that running ICMP over IP is ill-adviced. > not all IDs *SHOULD* go to RFC > >Sometimes the solution is to not write anything, and leave things as-is. Me, a number of people here, the industry, and the IAB seem to have a different view on this draft. I respect yours, anyway. -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Sep 29 11:47:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL0dG-0006jU-OL; Thu, 29 Sep 2005 11:47:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL0dG-0006j0-0p for tcpm@megatron.ietf.org; Thu, 29 Sep 2005 11:47:38 -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 LAA19589 for ; Thu, 29 Sep 2005 11:47:35 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL0kw-0005j3-I3 for tcpm@ietf.org; Thu, 29 Sep 2005 11:55:35 -0400 Received: from [128.30.5.112] (30-5-112.wireless.csail.mit.edu [128.30.5.112]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8TFkHY00328; Thu, 29 Sep 2005 08:46:17 -0700 (PDT) Message-ID: <433C0C47.3080207@isi.edu> Date: Thu, 29 Sep 2005 08:46:15 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fernando Gont 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> <4334345F.2060301@isi.edu> <6.2.0.14.0.20050927013116.03fedc70@pop.frh.utn.edu.ar> <4339AB09.70501@isi.edu> <6.2.0.14.0.20050928034642.08012bf0@pop.frh.utn.edu.ar> <433BDFB8.4090407@isi.edu> <6.2.0.14.0.20050929120406.03d79008@pop.frh.utn.edu.ar> In-Reply-To: <6.2.0.14.0.20050929120406.03d79008@pop.frh.utn.edu.ar> 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: 225414c974e0d6437992164e91287a51 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="===============0821935474==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0821935474== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA2FF1C5666AC64D333B538C6" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA2FF1C5666AC64D333B538C6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Fernando Gont wrote: > At 09:36 a.m. 29/09/2005, Joe Touch wrote: > >> >> You're application of the existing principle is based on your >> inference >> >> that everything you don't expect MUST be an attack, or at least >> MUST be >> >> treated as such. >> > >> > No. I'm just saying that one needs to be more cautious when processing >> > ICMP messages. >> > The ICMP messages could be part of an attack, or could be stale. In any >> > of these two cases, honoring them would be ill advice. >> >> That's true. The question is when/whether you can determine either. If >> you can't, then NOT honoring them is ill advice. The principle of 'be >> generous in what you receive' means it's more useful in general to >> assume the best, not the worst, of things you don't have other >> indications about. > > It's not useful to open the door to attack. We're not opening anything. It's already open, at least as spec'd. > For instance, we are also > working on spoofing attacks. If you want to be generous, then take all > spoofed packets as legitimate. Which is what I have proposed - except where we can assert they are spoofed with some level of confidence, rather than just a wild guess, i.e., with TCP/MD5 or IPsec. >> > The same policies that protect you from attack also protect you from >> > stale error messages. >> > >> >> IMO, 'be liberal in what you receive' (Postel's rationale) warrants >> that >> >> IF there is a legitimate or benign reason that the same packet could >> >> have arrived, then it MUST NOT be treated as an attack. >> > >> > I disagree. That's just an interpretation. I take it as "even something >> > you don't expect should not break your system" i.e. "you should be albe >> > to deal with unexpected packets nicely". >> >> Yeah - and these could be unexpected, but legitimate. So you interpret >> them as attacks and ignore them? > > I don't necessarily take them as attack. And I disagree with your > interpretation of the robustness principle, in 2005 (and up) it's fair > to assume the environmnent is hostile. That's why there's a mandatory > "Security Considerations" section in today's documents. Security considerations doesn't assume everything is an attack, but rather whether things we do introduce new vunerabilities - which isn't an issue here. >> >> I don't understand why the message indicates it's a soft error; it's >> >> clear that some of these messages are hard errors and intended as such >> >> (e.g., the case where TCPv4 disappears). >> > >> > Yes, *some*, and in *certain* circumstances/scenarios. The more >> > conservative way to go is to not break connections. >> >> Or break connections that are in the process of being established >> either. So which ID do you want to withdraw, this or the TCP soft-errors >> one? ;-) > > The soft errors one is not for the Standards track, anymore. > > And, as I said before, assuming that the same mechanism always implies > the same policy is short-sighted. While I agree with that, assuming that we can infer different policies just based on whether a connection has been established is equally short-sighted. >> And conservative in this forum also includes "don't change the spec >> unless absolutely necessary". Near as I can tell, this is motivated >> solely by security, which it does not provide. > > That's "rehashing the past", rather than "being conservative". I'm not rehashing it; I think the reasons for the past spec still apply. >> >> > Anyway, again: the draft describes possible attacks, and possible >> ways >> >> > to address them. No need to "infer": Implement this if it's one >> of the >> >> > described attacks that is taking place, it will protect you. If it's >> >> > not, it won't hurt you. >> >> >> >> It will protect you from the firemen too (e.g., ICMPs for TCPv4 that >> >> disappears, as one example). Which DOES hurt you. >> > >> > I does not hurt. Remember: ICMP is unreliable. The ICMP error message >> > may be corrupted, may be subject to rate limitation, etc. >> > And again, processing of protocol unreachables is a SHOULD, not a MUST. >> >> And this changes it to a MUST NOT. Which I disagree with. > > The app can still shoot itself, as my draft does not say the hard errors > should not be signaled to the user application. What would THAT do? You want to NOT act on them at the TCP level, but pass them to the app anyway? Why? >> > If you really think my proposal hurts, you should submit a proposal >> > entitled "Tunnelling ICMP over TCP", or the like. >> >> You've repeatedly suggested that if I don't like your drafts, I should >> write alternative drafts. Here's my perspective on this: > > No, what I'm meaning is that if you think that treating hard errors as > soft errors is ill-adviced, you should also arge that running ICMP over > IP is ill-adviced. That presumes I think that there is a viable way to secure ICMP, which I don't so far. If you don't think it's secure, discard all ICMPs. Otherwise, act on what you get, because there's no way to distinguish one ICMP from another just based on the content of the ICMP per se. This goes back to your policy issue - I do agree that we should act on different ones differently, just not that these cases (legitimate ICMPs vs spoofed) are distinguishable. >> not all IDs *SHOULD* go to RFC >> >> Sometimes the solution is to not write anything, and leave things as-is. > > Me, a number of people here, the industry, and the IAB seem to have a > different view on this draft. I respect yours, anyway. Well, FWIW, the IAB/IESG also approved a number of drafts to go to RFC standards-track that violate RFC791 on the use of IP ID (ROHC), and a recent one we discussed in this group that depended normatively on a mechanism that was an ID. I.e., they make mistakes too (as do we all). Joe --------------enigA2FF1C5666AC64D333B538C6 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 iD8DBQFDPAxHE5f5cImnZrsRAogsAKCUOMH5WMo6drtLicf5/WJ3ae7KYgCg1yDP PeV7UXwr24MsZlLTqaf4mVw= =jiKg -----END PGP SIGNATURE----- --------------enigA2FF1C5666AC64D333B538C6-- --===============0821935474== 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 --===============0821935474==-- From tcpm-bounces@ietf.org Thu Sep 29 12:05:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL0uK-0001vt-L8; Thu, 29 Sep 2005 12:05:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL0uJ-0001vo-0v for tcpm@megatron.ietf.org; Thu, 29 Sep 2005 12:05: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 MAA20274 for ; Thu, 29 Sep 2005 12:05:11 -0400 (EDT) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL11y-00068F-7a for tcpm@ietf.org; Thu, 29 Sep 2005 12:13:12 -0400 Received: (qmail 2320 invoked from network); 29 Sep 2005 16:04:37 -0000 Received: from 200-70-144-124.mrse.com.ar (HELO fgont.gont.com.ar) (gont-fernando@200.70.144.124) by server.frh.utn.edu.ar with SMTP; 29 Sep 2005 16:04:37 -0000 Message-Id: <6.2.0.14.0.20050929125335.03d67e90@pop.frh.utn.edu.ar> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 29 Sep 2005 13:02:28 -0300 To: Joe Touch From: Fernando Gont Subject: Re: [tcpm] ICMP attacks draft (issue 1): hard errors -> soft errors (in synchronized states) In-Reply-To: <433C0C47.3080207@isi.edu> 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> <4334345F.2060301@isi.edu> <6.2.0.14.0.20050927013116.03fedc70@pop.frh.utn.edu.ar> <4339AB09.70501@isi.edu> <6.2.0.14.0.20050928034642.08012bf0@pop.frh.utn.edu.ar> <433BDFB8.4090407@isi.edu> <6.2.0.14.0.20050929120406.03d79008@pop.frh.utn.edu.ar> <433C0C47.3080207@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.9 (++) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 12:46 p.m. 29/09/2005, Joe Touch wrote: > > It's not useful to open the door to attack. > >We're not opening anything. It's already open, at least as spec'd. Yes, and that's not good. > >> And this changes it to a MUST NOT. Which I disagree with. > > > > The app can still shoot itself, as my draft does not say the hard errors > > should not be signaled to the user application. > >What would THAT do? You want to NOT act on them at the TCP level, but >pass them to the app anyway? Why? Because, if anything, I'd leave the apps the choice to make something stupid, intentionally, rather than keeping TCP vulnerable to trivial ICMP-based connection-reset attacks. > >> > If you really think my proposal hurts, you should submit a proposal > >> > entitled "Tunnelling ICMP over TCP", or the like. > >> > >> You've repeatedly suggested that if I don't like your drafts, I should > >> write alternative drafts. Here's my perspective on this: > > > > No, what I'm meaning is that if you think that treating hard errors as > > soft errors is ill-adviced, you should also arge that running ICMP over > > IP is ill-adviced. > >That presumes I think that there is a viable way to secure ICMP, which I >don't so far. No. That means you are making an argument for a protocol which is already unreliable. >Otherwise, act on what you get, because there's no way to distinguish >one ICMP from another just based on the content of the ICMP per se. This >goes back to your policy issue - I do agree that we should act on >different ones differently, just not that these cases (legitimate ICMPs >vs spoofed) are distinguishable. I don't think their are distinguishable, either. I just mean that making as many checks as possible reduces the chance of being hit by spoofed. And that being more conservative on the ones that would cause more harm is a good thing. > > Me, a number of people here, the industry, and the IAB seem to have a > > different view on this draft. I respect yours, anyway. > >Well, FWIW, the IAB/IESG also approved a number of drafts to go to RFC >standards-track that violate RFC791 on the use of IP ID (ROHC), and a >recent one we discussed in this group that depended normatively on a >mechanism that was an ID. I.e., they make mistakes too (as do we all). That's more of an administrative/procedural than a technical error. Was their technical rationale broken? -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Sep 29 12:13:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL12h-0003qE-65; Thu, 29 Sep 2005 12:13:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL12e-0003mP-NQ for tcpm@megatron.ietf.org; Thu, 29 Sep 2005 12:13:52 -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 MAA20668 for ; Thu, 29 Sep 2005 12:13:49 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL1AK-0006Lr-9p for tcpm@ietf.org; Thu, 29 Sep 2005 12:21:49 -0400 Received: from [128.30.5.112] (30-5-112.wireless.csail.mit.edu [128.30.5.112]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8TGCXY08659; Thu, 29 Sep 2005 09:12:33 -0700 (PDT) Message-ID: <433C126F.5010400@isi.edu> Date: Thu, 29 Sep 2005 09:12:31 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fernando Gont 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> <4334345F.2060301@isi.edu> <6.2.0.14.0.20050927013116.03fedc70@pop.frh.utn.edu.ar> <4339AB09.70501@isi.edu> <6.2.0.14.0.20050928034642.08012bf0@pop.frh.utn.edu.ar> <433BDFB8.4090407@isi.edu> <6.2.0.14.0.20050929120406.03d79008@pop.frh.utn.edu.ar> <433C0C47.3080207@isi.edu> <6.2.0.14.0.20050929125335.03d67e90@pop.frh.utn.edu.ar> In-Reply-To: <6.2.0.14.0.20050929125335.03d67e90@pop.frh.utn.edu.ar> 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: 0ddefe323dd869ab027dbfff7eff0465 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0735114449==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0735114449== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA483F6982DB2464D6251E925" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA483F6982DB2464D6251E925 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Fernando Gont wrote: > At 12:46 p.m. 29/09/2005, Joe Touch wrote: ... >> That presumes I think that there is a viable way to secure ICMP, which I >> don't so far. > > No. That means you are making an argument for a protocol which is > already unreliable. Yes, I am. Or have you disabled all non-IPsec'd connections to your site? ... >> > Me, a number of people here, the industry, and the IAB seem to have a >> > different view on this draft. I respect yours, anyway. >> >> Well, FWIW, the IAB/IESG also approved a number of drafts to go to RFC >> standards-track that violate RFC791 on the use of IP ID (ROHC), and a >> recent one we discussed in this group that depended normatively on a >> mechanism that was an ID. I.e., they make mistakes too (as do we all). > > That's more of an administrative/procedural than a technical error. Was > their technical rationale broken? No technical rational for overriding spec or process was given in either case. They appear to have just slipped through - i.e., an error. Joe --------------enigA483F6982DB2464D6251E925 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 iD8DBQFDPBJvE5f5cImnZrsRAjyIAJ4oFAX9AWXEQ3rhkaIZM2P8UUC13wCgjmOb xHqrjZHRPSygmruYEkVtRFA= =2Yf6 -----END PGP SIGNATURE----- --------------enigA483F6982DB2464D6251E925-- --===============0735114449== 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 --===============0735114449==-- From tcpm-bounces@ietf.org Thu Sep 29 12:21:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL19h-0007tP-MB; Thu, 29 Sep 2005 12:21:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL19f-0007tH-Ch for tcpm@megatron.ietf.org; Thu, 29 Sep 2005 12:21: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 MAA21077 for ; Thu, 29 Sep 2005 12:21:03 -0400 (EDT) Received: from prue.eim.surrey.ac.uk ([131.227.76.5] ident=exim) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL1HL-0006YX-4I for tcpm@ietf.org; Thu, 29 Sep 2005 12:29:04 -0400 Received: from argos.ee.surrey.ac.uk ([131.227.89.15] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 1EL191-0002tt-00; Thu, 29 Sep 2005 17:20:27 +0100 Date: Thu, 29 Sep 2005 17:20:19 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@argos.ee.surrey.ac.uk To: Joe Touch Subject: Re: [tcpm] ICMP attacks draft (issue 1): hard errors -> soft errors (in synchronized states) In-Reply-To: <433C126F.5010400@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> <4334345F.2060301@isi.edu> <6.2.0.14.0.20050927013116.03fedc70@pop.frh.utn.edu.ar> <4339AB09.70501@isi.edu> <6.2.0.14.0.20050928034642.08012bf0@pop.frh.utn.edu.ar> <433BDFB8.4090407@isi.edu> <6.2.0.14.0.20050929120406.03d79008@pop.frh.utn.edu.ar> <433C0C47.3080207@isi.edu> <6.2.0.14.0.20050929125335.03d67e90@pop.frh.utn.edu.ar> <433C126F.5010400@isi.edu> Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-102.5 required=7.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_PINE,USER_IN_WHITELIST autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanner: exiscan *1EL191-0002tt-00*nNojZvUAkrA* (SECM, UniS) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 Thu, 29 Sep 2005, Joe Touch wrote: > Fernando Gont wrote: > > At 12:46 p.m. 29/09/2005, Joe Touch wrote: > ... > >> That presumes I think that there is a viable way to secure ICMP, which I > >> don't so far. > > > > No. That means you are making an argument for a protocol which is > > already unreliable. > > Yes, I am. Or have you disabled all non-IPsec'd connections to your site? How, exactly, does one go and equate unreliable with insecure? Entirely different things. > No technical rational for overriding spec or process was given in either > case. They appear to have just slipped through - i.e., an error. I would argue that the formation of the ROHC workgroup was the error. L. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Sep 29 13:39:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL2N9-000394-As; Thu, 29 Sep 2005 13:39:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL2N7-00038u-QY for tcpm@megatron.ietf.org; Thu, 29 Sep 2005 13:39: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 NAA24459 for ; Thu, 29 Sep 2005 13:39:04 -0400 (EDT) Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL2Uo-00005D-E3 for tcpm@ietf.org; Thu, 29 Sep 2005 13:47:03 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 777FB68B0B4 for ; Thu, 29 Sep 2005 10:38:46 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19868-06 for ; Thu, 29 Sep 2005 10:38:46 -0700 (PDT) Received: from [127.0.0.1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 2A24968B0B1 for ; Thu, 29 Sep 2005 10:38:46 -0700 (PDT) Message-ID: <433C2573.40904@redback.com> Date: Thu, 29 Sep 2005 10:33:39 -0700 From: Jakob Heitz Organization: Redback Networks, Software Development User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tcpm@ietf.org 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> <4334345F.2060301@isi.edu> <6.2.0.14.0.20050927013116.03fedc70@pop.frh.utn.edu.ar> <4339AB09.70501@isi.edu> <6.2.0.14.0.20050928034642.08012bf0@pop.frh.utn.edu.ar> <433BDFB8.4090407@isi.edu> <6.2.0.14.0.20050929120406.03d79008@pop.frh.utn.edu.ar> <433C0C47.3080207@isi.edu> <6.2.0.14.0.20050929125335.03d67e90@pop.frh.utn.edu.ar> In-Reply-To: <6.2.0.14.0.20050929125335.03d67e90@pop.frh.utn.edu.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit 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 Fernando Gont wrote: > At 12:46 p.m. 29/09/2005, Joe Touch wrote: >> That presumes I think that there is a viable way to secure ICMP, which I >> don't so far. > > > No. That means you are making an argument for a protocol which is > already unreliable. ...but it's useful. IP and UDP are unreliable too, but they're useful. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Sep 29 14:09:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL2qm-00038P-W4; Thu, 29 Sep 2005 14:09:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL2ql-00038H-DL for tcpm@megatron.ietf.org; Thu, 29 Sep 2005 14:09:43 -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 OAA26068 for ; Thu, 29 Sep 2005 14:09:41 -0400 (EDT) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL2yQ-0000oE-Hm for tcpm@ietf.org; Thu, 29 Sep 2005 14:17:41 -0400 Received: (qmail 13832 invoked from network); 29 Sep 2005 18:09:01 -0000 Received: from 200-70-177-2.mrse.com.ar (HELO fgont.gont.com.ar) (gont-fernando@200.70.177.2) by server.frh.utn.edu.ar with SMTP; 29 Sep 2005 18:09:01 -0000 Message-Id: <6.2.0.14.0.20050929150021.0428acc8@pop.frh.utn.edu.ar> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 29 Sep 2005 15:01:41 -0300 To: Jakob Heitz , tcpm@ietf.org From: Fernando Gont Subject: Re: [tcpm] ICMP attacks draft (issue 1): hard errors -> soft errors (in synchronized states) In-Reply-To: <433C2573.40904@redback.com> 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> <4334345F.2060301@isi.edu> <6.2.0.14.0.20050927013116.03fedc70@pop.frh.utn.edu.ar> <4339AB09.70501@isi.edu> <6.2.0.14.0.20050928034642.08012bf0@pop.frh.utn.edu.ar> <433BDFB8.4090407@isi.edu> <6.2.0.14.0.20050929120406.03d79008@pop.frh.utn.edu.ar> <433C0C47.3080207@isi.edu> <6.2.0.14.0.20050929125335.03d67e90@pop.frh.utn.edu.ar> <433C2573.40904@redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 02:33 p.m. 29/09/2005, Jakob Heitz wrote: >>At 12:46 p.m. 29/09/2005, Joe Touch wrote: >>>That presumes I think that there is a viable way to secure ICMP, which I >>>don't so far. >> >>No. That means you are making an argument for a protocol which is already >>unreliable. > >...but it's useful. >IP and UDP are unreliable too, but they're useful. Of course. That's why I don't propose to "drop all ICMP", or simply drop the so-called "ICMP hard errors:. Perform checks, and if you are to fail, fail for the sake of robustness/security. -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Sep 30 13:30:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELOht-0004Bf-Ai; Fri, 30 Sep 2005 13:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELOhr-0004BW-6p for tcpm@megatron.ietf.org; Fri, 30 Sep 2005 13:29: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 NAA22112 for ; Fri, 30 Sep 2005 13:29:56 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELOpl-0002oH-BR for tcpm@ietf.org; Fri, 30 Sep 2005 13:38:09 -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 j8UHSVL24385; Fri, 30 Sep 2005 10:28:31 -0700 (PDT) Received: (from faber@localhost) by pun.isi.edu (8.13.4/8.13.4/Submit) id j8UHSVRu052292; Fri, 30 Sep 2005 10:28:31 -0700 (PDT) (envelope-from faber) Date: Fri, 30 Sep 2005 10:28:31 -0700 From: Ted Faber To: Pekka Savola Subject: Re: [tcpm] Feedback on draft-gont-tcpm-icmp-attacks-04.txt Message-ID: <20050930172830.GJ999@pun.isi.edu> References: <20050922162344.GC31229@pun.isi.edu> <20050923145210.GC10959@pun.isi.edu> Mime-Version: 1.0 In-Reply-To: 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: 52f7a77164458f8c7b36b66787c853da 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="===============0270413934==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0270413934== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2fjX3cMESU3XgGmZ" Content-Disposition: inline --2fjX3cMESU3XgGmZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 27, 2005 at 09:34:11AM +0300, Pekka Savola wrote: > On Fri, 23 Sep 2005, Ted Faber wrote: > >>Isn't there sufficient evidence that "filter all ICMP" breaks most > >>(all?) transport protocols in obvious and/or subtle ways? (Just > >>consider but there are probably other examples.) So, I fail to see how > >>one could argue that "protocols have to work" -- but maybe this > >>depends on the context and the definition of "work" (i.e., which kinds > >>of functionality or performance degradations would be acceptable). > > > >ICMP's unreliably delivered, and optional (though strongly encouraged) > >to generate. If protocols rely on it, they're in some amount of > >trouble. I understand that some protocol may rely on it, but it's IMHO > >misdesgigned. I can't think of any way (outside maybe PMTU, which I > >don't know much about) that TCP might be broken here. > > > >Give me an example of breakage. >=20 > PMTUD alone should be sufficient example :). Well, I don't know that it breaks, I just don't know enough about that spec and I'm being conservative based on Matt Mathis's statements. I'll rectify this anon. > PMTUD alone should be sufficient example :). Note that in the case of=20 > PMTUD (and many other ICMP errors in general), if the ICMP error gets=20 > lost, the sending host will try to send again -- which will trigger=20 > another ICMP error, and another, and another.. Yeah if the ICMP generator decides that's an appropriate implementation of the 1122 SHOULD for ICMP messages. But I need to read the PMTU stuff before I can have this discussion rationally. > (Sending ICMP errors is usually subject to some rate-limiting, but=20 > some are bound to be sent again sooner or later.) Optimist. :-) :-) :-) --=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 --2fjX3cMESU3XgGmZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDPXW+aUz3f+Zf+XsRAmwZAKDYtReoIzjf+jLlAFxVKiB0qi5yGgCg5Rmh kG+LjxlbJ/IXwdQZpEClL0E= =auV1 -----END PGP SIGNATURE----- --2fjX3cMESU3XgGmZ-- --===============0270413934== 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 --===============0270413934==-- From tcpm-bounces@ietf.org Fri Sep 30 13:41:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELOsj-0006a7-Fp; Fri, 30 Sep 2005 13:41:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELOsi-0006a1-AS for tcpm@megatron.ietf.org; Fri, 30 Sep 2005 13:41:12 -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 NAA22502 for ; Fri, 30 Sep 2005 13:41:11 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELP0c-00033R-FW for tcpm@ietf.org; Fri, 30 Sep 2005 13:49:22 -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 j8UHeCL28525; Fri, 30 Sep 2005 10:40:12 -0700 (PDT) Received: (from faber@localhost) by pun.isi.edu (8.13.4/8.13.4/Submit) id j8UHeCYd064030; Fri, 30 Sep 2005 10:40:12 -0700 (PDT) (envelope-from faber) Date: Fri, 30 Sep 2005 10:40:12 -0700 From: Ted Faber To: Fernando Gont Subject: Re: [tcpm] ICMP attacks draft (issue 1): hard errors -> soft errors (in synchronized states) Message-ID: <20050930174011.GK999@pun.isi.edu> 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> Mime-Version: 1.0 In-Reply-To: <6.2.0.14.0.20050927015438.07c2a418@pop.frh.utn.edu.ar> 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: c3a18ef96977fc9bcc21a621cbf1174b Cc: tcpm@ietf.org, Joe Touch X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0093900955==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0093900955== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="F55Y67F01HNW3AgB" Content-Disposition: inline --F55Y67F01HNW3AgB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 27, 2005 at 02:09:48AM -0300, Fernando Gont wrote: > At 01:50 p.m. 23/09/2005, Ted Faber wrote: >=20 > >The point is that for whatever reason, all the host can do is send a > >Protocol Not Supported ICMP, because the TCP stack will not be reached > >(the postulate is that the host has stopped speaking either TCP or > >IPv4). Because the packet can't get to the TCP stack (which may not be > >running at all), the host can't generate an RST. > > > >Of course, if no ICMP is generated or gets through, the ESTABLISHED TCP > >will eventually have a UTO and abort the connection. > > > >Yes, this is a pretty bizarre case, but it is a valid hard error in an > >ESTABLISHED state, and one where aborting the connection is the most > >sensible thing to do. >=20 > So we would keep connections vulnerable to reset attacks for that 1 in=20 > 1000000th chance in which this scenario might take place? That's a decision for the community, of course. But my opinion is that you need to address the issue in the draft, not implicitly assume that tradeoff is obvious. Even if the community adopts it, it's wise to indicate that we thought about it.=20 > (And, btw, in the event that happened, why would ignoring the ICMP messag= e=20 > hurt you? For instance, the proposed policy does not prevent the=20 > application layer from being notified of the received ICMP error message!= =20 > So this means you still let the application shoot itself, if it wants to!= =20 > :-) ) Hey, I generally believe that ignoring ICMP doesn't hurt you. What's at issue is whether responding to this ICMP can help you. I believe that the document asserts that once the connection is ESTABLISHED, this ICMP is never a valid reason to terminate the connection. Joe's described a situation (that consists of many different possible causes) where listening to that ICMP is perfectly reasonable. An application's always welcome to shoot itself from TCP's perspective. >=20 > Also, if there's consensus on the side of "not doing anything about this"= ,=20 > then my next question/comment would be "Does it make sense to modify TCP'= s=20 > state transition diagram (as we currently are) to address TCP-based reset= =20 > attacks, then? An attacker will use ICMP-based ones, because they are muc= h=20 > easier to perform!" If you've got questions about the motivations for and support of tcpsecure, there's no need to be coy - no need to make such comments conditionally. :-)=20 Right now, it sounds like the answer to your question is "yes, the WG supports the tcp secure changes, independently of the changes proposed here."=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 --F55Y67F01HNW3AgB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDPXh7aUz3f+Zf+XsRAg4wAKC31YUYd2dpW1Ul2QHx3gKJk/K82gCeP75n hj2qwOi/+ZVtHS4ldA+QrBU= =6khD -----END PGP SIGNATURE----- --F55Y67F01HNW3AgB-- --===============0093900955== 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 --===============0093900955==-- From tcpm-bounces@ietf.org Fri Sep 30 14:20:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELPV6-0003cZ-3V; Fri, 30 Sep 2005 14:20:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELPV4-0003cQ-Eq for tcpm@megatron.ietf.org; Fri, 30 Sep 2005 14:20:50 -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 OAA25154 for ; Fri, 30 Sep 2005 14:20:48 -0400 (EDT) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELPcv-0004JD-Hr for tcpm@ietf.org; Fri, 30 Sep 2005 14:29:00 -0400 Received: (qmail 21885 invoked from network); 30 Sep 2005 18:19:39 -0000 Received: from unknown (HELO fgont.gont.com.ar) (gont-fernando@10.0.10.7) by server.frh.utn.edu.ar with SMTP; 30 Sep 2005 18:19:39 -0000 Message-Id: <6.2.0.14.0.20050930150854.0592eee0@pop.frh.utn.edu.ar> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 30 Sep 2005 15:18:30 -0300 To: Ted Faber From: Fernando Gont Subject: Re: [tcpm] ICMP attacks draft (issue 1): hard errors -> soft errors (in synchronized states) In-Reply-To: <20050930174011.GK999@pun.isi.edu> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: tcpm@ietf.org, Joe Touch X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 02:40 p.m. 30/09/2005, Ted Faber wrote: > > >Yes, this is a pretty bizarre case, but it is a valid hard error in an > > >ESTABLISHED state, and one where aborting the connection is the most > > >sensible thing to do. > > > > So we would keep connections vulnerable to reset attacks for that 1 in > > 1000000th chance in which this scenario might take place? > >That's a decision for the community, of course. But my opinion is that >you need to address the issue in the draft, not implicitly assume that >tradeoff is obvious. Even if the community adopts it, it's wise to >indicate that we thought about it. Good point. Will do. > > (And, btw, in the event that happened, why would ignoring the ICMP message > > hurt you? For instance, the proposed policy does not prevent the > > application layer from being notified of the received ICMP error message! > > So this means you still let the application shoot itself, if it wants to! > > :-) ) > >Hey, I generally believe that ignoring ICMP doesn't hurt you. Yep, sorry. >What's at >issue is whether responding to this ICMP can help you. I believe that >the document asserts that once the connection is ESTABLISHED, this ICMP >is never a valid reason to terminate the connection. You will always find something that does not fit. The point is that the benefits of treating hard errors as soft errors outweighs those of aborting the corresponding connection upon receipt of one of them. >Joe's described a >situation (that consists of many different possible causes) where >listening to that ICMP is perfectly reasonable. >An application's always welcome to shoot itself from TCP's perspective. I mean that even when you treat the hard error as soft error, you still notify it to the application. The application can, upon this notification, cause the connection to be aborted. > > Also, if there's consensus on the side of "not doing anything about this", > > then my next question/comment would be "Does it make sense to modify TCP's > > state transition diagram (as we currently are) to address TCP-based reset > > attacks, then? An attacker will use ICMP-based ones, because they are much > > easier to perform!" > >If you've got questions about the motivations for and support of >tcpsecure, there's no need to be coy - no need to make such comments >conditionally. :-) > >Right now, it sounds like the answer to your question is "yes, the WG >supports the tcp secure changes, independently of the changes proposed >here." My argument is: Why would an attacker bother to guess a TCP sequence number, when it can reset a conenction much more trivially by means of ICMP? "The strength of a chain is that of the weakest link", I mean. -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Sep 30 14:37:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELPlY-00007Z-P1; Fri, 30 Sep 2005 14:37:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELPlX-00007T-GM for tcpm@megatron.ietf.org; Fri, 30 Sep 2005 14:37:51 -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 OAA27178 for ; Fri, 30 Sep 2005 14:37:50 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELPtR-0005PP-6O for tcpm@ietf.org; Fri, 30 Sep 2005 14:46:02 -0400 Received: from [128.9.176.136] (ras36.isi.edu [128.9.176.136]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8UIamL16166; Fri, 30 Sep 2005 11:36:48 -0700 (PDT) Message-ID: <433D85BD.4020204@isi.edu> Date: Fri, 30 Sep 2005 11:36:45 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fernando Gont 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> In-Reply-To: <6.2.0.14.0.20050930150854.0592eee0@pop.frh.utn.edu.ar> 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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: tcpm@ietf.org, Ted Faber X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1974680600==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1974680600== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1BCCEF8E8C35C03B60617F74" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1BCCEF8E8C35C03B60617F74 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Fernando Gont wrote: ... >> Joe's described a >> situation (that consists of many different possible causes) where >> listening to that ICMP is perfectly reasonable. >> An application's always welcome to shoot itself from TCP's perspective. > > I mean that even when you treat the hard error as soft error, you still > notify it to the application. The application can, upon this > notification, cause the connection to be aborted. FWIW, the application can't do much with ICMPs it didn't expect to be notified about. So this change requires not only a change to TCP, but a change to every application that might be affected. That's worth noting (if not reconsidering the implications of). >> If you've got questions about the motivations for and support of >> tcpsecure, there's no need to be coy - no need to make such comments >> conditionally. :-) >> >> Right now, it sounds like the answer to your question is "yes, the WG >> supports the tcp secure changes, independently of the changes proposed >> here." > > My argument is: Why would an attacker bother to guess a TCP sequence > number, when it can reset a conenction much more trivially by means of > ICMP? > > "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. Joe --------------enig1BCCEF8E8C35C03B60617F74 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 iD8DBQFDPYW9E5f5cImnZrsRAvqNAJ4xQJwfVb+RGObNbw9t7WzP7w9quQCeNTzK /Kole+2/djDKxich3IxPNPA= =WVMC -----END PGP SIGNATURE----- --------------enig1BCCEF8E8C35C03B60617F74-- --===============1974680600== 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 --===============1974680600==-- From tcpm-bounces@ietf.org Fri Sep 30 15:01:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELQ8q-00089T-Pm; Fri, 30 Sep 2005 15:01:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELQ8p-00087j-5C for tcpm@megatron.ietf.org; Fri, 30 Sep 2005 15:01:55 -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 PAA29520 for ; Fri, 30 Sep 2005 15:01:53 -0400 (EDT) Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELQGi-0006Wc-4D for tcpm@ietf.org; Fri, 30 Sep 2005 15:10:06 -0400 Received: (qmail 6799 invoked from network); 30 Sep 2005 19:01:03 -0000 Received: from unknown (HELO fgont.gont.com.ar) (gont-fernando@10.0.10.7) by server.frh.utn.edu.ar with SMTP; 30 Sep 2005 19:01:03 -0000 Message-Id: <6.2.0.14.0.20050930155718.05963118@pop.frh.utn.edu.ar> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 30 Sep 2005 16:01:31 -0300 To: Joe Touch From: Fernando Gont Subject: Re: [tcpm] ICMP attacks draft (issue 1): hard errors -> soft errors (in synchronized states) In-Reply-To: <433D85BD.4020204@isi.edu> 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: 538aad3a3c4f01d8b6a6477ca4248793 Cc: tcpm@ietf.org, Ted Faber X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 03:36 p.m. 30/09/2005, Joe Touch wrote: > >> Joe's described a > >> situation (that consists of many different possible causes) where > >> listening to that ICMP is perfectly reasonable. > >> An application's always welcome to shoot itself from TCP's perspective. > > > > I mean that even when you treat the hard error as soft error, you still > > notify it to the application. The application can, upon this > > notification, cause the connection to be aborted. > >FWIW, the application can't do much with ICMPs it didn't expect to be >notified about. So this change requires not only a change to TCP, but a >change to every application that might be affected. That's worth noting >(if not reconsidering the implications of). Strictly speaking, here should be a way to notify applications of the received ICMP messages (as per RFC1122). Yes, in practice this would mean that applications should be modified. What I mean is that, in the event you still want to abort a connection upon receipt of an ICMP message, you can do so at the application layer, when you are notified (if you have decided to) of the received ICMP messages. > >> If you've got questions about the motivations for and support of > >> tcpsecure, there's no need to be coy - no need to make such comments > >> conditionally. :-) > >> > >> Right now, it sounds like the answer to your question is "yes, the WG > >> supports the tcp secure changes, independently of the changes proposed > >> here." > > > > My argument is: Why would an attacker bother to guess a TCP sequence > > number, when it can reset a conenction much more trivially by means of > > ICMP? > > > > "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. -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Sep 30 15:49:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELQt8-0005mG-QV; Fri, 30 Sep 2005 15:49:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELQt7-0005mB-C6 for tcpm@megatron.ietf.org; Fri, 30 Sep 2005 15:49:45 -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 PAA03515 for ; Fri, 30 Sep 2005 15:49:43 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELR11-0008DQ-Gr for tcpm@ietf.org; Fri, 30 Sep 2005 15:57:56 -0400 Received: from [128.9.176.136] (ras36.isi.edu [128.9.176.136]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8UJmOL07192; Fri, 30 Sep 2005 12:48:25 -0700 (PDT) Message-ID: <433D9685.5080501@isi.edu> Date: Fri, 30 Sep 2005 12:48:21 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fernando Gont 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> In-Reply-To: <6.2.0.14.0.20050930155718.05963118@pop.frh.utn.edu.ar> 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: tcpm@ietf.org, Ted Faber X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2045539502==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2045539502== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig43A475D0467E7A4B7A35A230" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig43A475D0467E7A4B7A35A230 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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)? Joe --------------enig43A475D0467E7A4B7A35A230 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 iD8DBQFDPZaGE5f5cImnZrsRArKnAJ4v9nAB5O06QMHiaSrE01cn42CQxgCgnlEM OwtvlRRaeZfWsQQV7uX2KKc= =odmi -----END PGP SIGNATURE----- --------------enig43A475D0467E7A4B7A35A230-- --===============2045539502== 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 --===============2045539502==-- From tcpm-bounces@ietf.org Fri Sep 30 16:26:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELRSj-0001ii-KP; Fri, 30 Sep 2005 16:26:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELRSh-0001cQ-Jq for tcpm@megatron.ietf.org; Fri, 30 Sep 2005 16:26:31 -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 QAA15962 for ; Fri, 30 Sep 2005 16:26:29 -0400 (EDT) Received: from prue.eim.surrey.ac.uk ([131.227.76.5] ident=exim) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELRaZ-0004ng-VM for tcpm@ietf.org; Fri, 30 Sep 2005 16:34:43 -0400 Received: from argos.ee.surrey.ac.uk ([131.227.89.15] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 1ELRRf-0003ZR-00; Fri, 30 Sep 2005 21:25:27 +0100 Date: Fri, 30 Sep 2005 21:25:17 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@argos.ee.surrey.ac.uk To: Joe Touch Subject: Re: [tcpm] ICMP attacks draft (issue 1): hard errors -> soft errors (in synchronized states) In-Reply-To: <433D9685.5080501@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> <6.2.0.14.0.20050930155718.05963118@pop.frh.utn.edu.ar> <433D9685.5080501@isi.edu> Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-102.5 required=7.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_PINE,USER_IN_WHITELIST autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanner: exiscan *1ELRRf-0003ZR-00*NHUNGf.I0tQ* (SECM, UniS) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org 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. Strengthening ICMP and TCP where reasonable and possible seem entirely sensible to me and in line with the mandate of this workgroup. Joe - you don't have to kill -everything- you hadn't thought of first, and some of us would respect you more if you didn't. L. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Sep 30 18:47:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELTeo-000860-7A; Fri, 30 Sep 2005 18:47:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELTem-00085v-39 for tcpm@megatron.ietf.org; Fri, 30 Sep 2005 18:47: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 SAA24252 for ; Fri, 30 Sep 2005 18:47:05 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELTmh-0000bA-W8 for tcpm@ietf.org; Fri, 30 Sep 2005 18:55:21 -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 j8UMkDL24400; Fri, 30 Sep 2005 15:46:13 -0700 (PDT) Received: (from faber@localhost) by pun.isi.edu (8.13.4/8.13.4/Submit) id j8UMkCDr026516; Fri, 30 Sep 2005 15:46:12 -0700 (PDT) (envelope-from faber) Date: Fri, 30 Sep 2005 15:46:12 -0700 From: Ted Faber To: Lloyd Wood Subject: Re: [tcpm] ICMP attacks draft (issue 1): hard errors -> soft errors (in synchronized states) Message-ID: <20050930224612.GC25715@pun.isi.edu> References: <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> Mime-Version: 1.0 In-Reply-To: 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: 8abaac9e10c826e8252866cbe6766464 Cc: tcpm@ietf.org, Fernando Gont , Joe Touch X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1806221457==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1806221457== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="z6Eq5LdranGa6ru8" Content-Disposition: inline --z6Eq5LdranGa6ru8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 30, 2005 at 09:25:17PM +0100, Lloyd Wood wrote: > Joe - you don't have to kill -everything- you hadn't thought of first, > and some of us would respect you more if you didn't. Let's try to stay civil, please. --=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 --z6Eq5LdranGa6ru8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDPcA0aUz3f+Zf+XsRAm8LAKCQu+RnPnAFNwWuE7TAduqpNaA2qACdEDr4 roauQ6FRsmPG9DNVGsxQ9Xo= =nBUe -----END PGP SIGNATURE----- --z6Eq5LdranGa6ru8-- --===============1806221457== 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 --===============1806221457==-- From tcpm-bounces@ietf.org Fri Sep 30 19:08:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELTzb-0008Ne-5B; Fri, 30 Sep 2005 19:08:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELTzZ-0008Lu-K2 for tcpm@megatron.ietf.org; Fri, 30 Sep 2005 19:08:37 -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 TAA25349 for ; Fri, 30 Sep 2005 19:08:34 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELU7W-0001C5-J9 for tcpm@ietf.org; Fri, 30 Sep 2005 19:16:51 -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 j8UN81L00069; Fri, 30 Sep 2005 16:08:01 -0700 (PDT) Received: (from faber@localhost) by pun.isi.edu (8.13.4/8.13.4/Submit) id j8UN81KD026887; Fri, 30 Sep 2005 16:08:01 -0700 (PDT) (envelope-from faber) Date: Fri, 30 Sep 2005 16:08:01 -0700 From: Ted Faber To: Fernando Gont Subject: Re: [tcpm] ICMP attacks draft (issue 1): hard errors -> soft errors (in synchronized states) Message-ID: <20050930230801.GD25715@pun.isi.edu> 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> Mime-Version: 1.0 In-Reply-To: <6.2.0.14.0.20050930150854.0592eee0@pop.frh.utn.edu.ar> 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: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: tcpm@ietf.org, Joe Touch X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0206209580==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0206209580== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="L6iaP+gRLNZHKoI4" Content-Disposition: inline --L6iaP+gRLNZHKoI4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 30, 2005 at 03:18:30PM -0300, Fernando Gont wrote: > At 02:40 p.m. 30/09/2005, Ted Faber wrote: > >Joe's described a > >situation (that consists of many different possible causes) where > >listening to that ICMP is perfectly reasonable. > >An application's always welcome to shoot itself from TCP's perspective. >=20 > I mean that even when you treat the hard error as soft error, you still= =20 > notify it to the application. The application can, upon this notification= ,=20 > cause the connection to be aborted. That's actually a pretty reasonable course of action, IMHO. Again, I think that the clearer you can be about this in the doc, the better. 1122 says that all ICMPs must trigger an asynchronous notification to the application and your argument that the application can reasonably distinguish between ICMP messages is a pretty good one. One could even imagine arguing for a "compatibility mode" response set that existing applications can use by default to react as previously. ("Compatibility mode" is clearly very speculative, and I wouldn't expect to see it.) I didn't really see this set out clearly in your document, but that may be reader error. > >Right now, it sounds like the answer to your question is "yes, the WG > >supports the tcp secure changes, independently of the changes proposed > >here." >=20 > My argument is: Why would an attacker bother to guess a TCP sequence=20 > number, when it can reset a conenction much more trivially by means of IC= MP? >=20 > "The strength of a chain is that of the weakest link", I mean. I understand what you're saying. Again without my chair hat on: I'm not sure that either off-path spoofed RSTs or off-path spoofed ICMP messages are really attractive DoS vectors, and on-path spoofers can generate packets that will defeat either tcpsecure or these ICMP checks. One of the attractions of tcpsecure - for me with my chair hat off - is the relative simplicity of the mechanism: ACK suspect RSTs with the strong assurance that a real RST will be validated. The ICMP error draft has more complicated checks - one muct potentially parse much of a TCP header and its options - and the attack is somewhat less promising - ICMP messages are commonly filtered and unreliable.=20 That said, I do see some merit in addressing the ICMP weakness. The sanity checks are somewhat perilous to get right, but it's reasonable to say that any attack packet you intercept is one connection saved and any valid error message you discard could have been lost anyway. While it's still good to get these right, I think that equation makes the cost of getting a check wrong less apocalyptic than some may think. I think you've made me at least a lukewarm believer here. I'm going to try to be quiet for a while and see what others think. (That's my idea of a subtle hint that others' opinions would be very welcome.) --=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 --L6iaP+gRLNZHKoI4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDPcVRaUz3f+Zf+XsRAtWJAJ9e4BVzA5b3w7Hkq/A0xXTrDMJsdwCg37bp 2L/KOBEwIf5uH17USHk/0bA= =mo8j -----END PGP SIGNATURE----- --L6iaP+gRLNZHKoI4-- --===============0206209580== 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 --===============0206209580==-- From tcpm-bounces@ietf.org Fri Sep 30 20:04:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELUrH-00052c-S6; Fri, 30 Sep 2005 20:04:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELUrG-00052X-AM for tcpm@megatron.ietf.org; Fri, 30 Sep 2005 20:04:06 -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 UAA29167 for ; Fri, 30 Sep 2005 20:04:05 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELUzC-0003Ar-VE for tcpm@ietf.org; Fri, 30 Sep 2005 20:12:20 -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 j91031L16514 for ; Fri, 30 Sep 2005 17:03:01 -0700 (PDT) Received: (from faber@localhost) by pun.isi.edu (8.13.4/8.13.4/Submit) id j91031S5027830 for tcpm@ietf.org; Fri, 30 Sep 2005 17:03:01 -0700 (PDT) (envelope-from faber) Date: Fri, 30 Sep 2005 17:03:00 -0700 From: Ted Faber To: tcpm@ietf.org Subject: Re: [tcpm] ICMP attacks draft (issue 1): hard errors -> soft errors (in synchronized states) Message-ID: <20051001000300.GG25715@pun.isi.edu> References: <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> <20050930224612.GC25715@pun.isi.edu> Mime-Version: 1.0 In-Reply-To: <20050930224612.GC25715@pun.isi.edu> 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: 7aafa0432175920a4b3e118e16c5cb64 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="===============0005560839==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0005560839== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9ADF8FXzFeE7X4jE" Content-Disposition: inline --9ADF8FXzFeE7X4jE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 30, 2005 at 03:46:12PM -0700, Ted Faber wrote: > On Fri, Sep 30, 2005 at 09:25:17PM +0100, Lloyd Wood wrote: > > Joe - you don't have to kill -everything- you hadn't thought of first, > > and some of us would respect you more if you didn't. >=20 > Let's try to stay civil, please. Let me be clear here, since it may sound like I'm singling Lloyd out unfairly or that I'm endorsing Joe's line of argumentation. I'm doing neither. I'm (perhaps vainly) hoping to prevent a flame up. This discussion, while heated technically, has remained personally civil. I understand that both participants and readers may be getting a little frustrated at this point. But, I think that the above comment isn't technically helpful. I'm not trying to squelch good discussion. Despite the heat in some of this thread, I think I've come away with a better understanding of Fernando's thinking here, though I've mostly been paying attention to his replies to me. In any case this is all coming from only my jet-lagged brain. Mark will tell me if he disagrees. Thanks. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --9ADF8FXzFeE7X4jE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDPdI0aUz3f+Zf+XsRAhnkAKDMYTubWTQGyi07z+r8+BmDwwQMjQCdEsR2 WPViGBnyLuc8fV3SfXkE5hc= =NHst -----END PGP SIGNATURE----- --9ADF8FXzFeE7X4jE-- --===============0005560839== 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 --===============0005560839==--