From tcpm-bounces@ietf.org Mon May 01 16:27:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Faeza-0000SE-DN; Mon, 01 May 2006 16:27:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaezZ-0000S2-ER for tcpm@ietf.org; Mon, 01 May 2006 16:27:37 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaezY-0003fx-1e for tcpm@ietf.org; Mon, 01 May 2006 16:27:37 -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 k41KRYH5030279 for ; Mon, 1 May 2006 13:27:34 -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 6FA6777AF00 for ; Mon, 1 May 2006 16:27:32 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Money MIME-Version: 1.0 Date: Mon, 01 May 2006 16:27:32 -0400 Message-Id: <20060501202732.6FA6777AF00@guns.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [tcpm] ietf survey 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="===============0201776768==" Errors-To: tcpm-bounces@ietf.org --===============0201776768== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Folks- The IETF's Administrative Director has asked us to ask you to take a moment and fill out a survey that focuses on (but is not entirely about) your experiences in Dallas. The input will be useful in organizing future meetings. If you have a few spare moments: http://www.surveymonkey.com/s.asp?u=649182049947 Thanks, allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEVm80WyrrWs4yIs4RAqsWAJsFFKWhya7V/0rDGs2XZxyIbsLJigCfTNYo BoAxgumP3LAT97ilbIcRKnc= =4H3L -----END PGP SIGNATURE----- --=_bOundary-- --===============0201776768== 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 --===============0201776768==-- From tcpm-bounces@ietf.org Mon May 01 17:49:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FagGH-00025L-6a; Mon, 01 May 2006 17:48:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FagGF-00025A-T1; Mon, 01 May 2006 17:48:55 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FagGF-0006dz-Kb; Mon, 01 May 2006 17:48:55 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k41Lmp9W004907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 May 2006 21:48:51 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FagGB-0005nG-RV; Mon, 01 May 2006 17:48:51 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 01 May 2006 17:48:51 -0400 X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: tcpm mailing list , Internet Architecture Board , tcpm chair , tcpm chair , RFC Editor Subject: [tcpm] Document Action: 'Improving the Robustness of TCP to Non-Congestion Events' to Experimental RFC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org The IESG has approved the following document: - 'Improving the Robustness of TCP to Non-Congestion Events ' as an Experimental RFC This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-dcr-07.txt Technical Summary This document specifies Non-Congestion Robustness (NCR) for TCP. One of the ways TCP detects loss is using the arrival of three duplicate acknowledgments. However, this heuristic is not always correct, notably in the case when network paths reorder segments. 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. Working Group Summary This draft has attracted considerable interest in the WG, with many different people commenting on reviewing various iterations. The consensus was that although the specific benefits of the NCR extensions remain to be investigated, the mechanism itself is suitably ready for publication as an Experimental RFC. Protocol Quality PROTO Shepherd: Ted Faber (faber@isi.edu) The Gen-ART reviewer (Eric Gray, eric.gray@marconi.com) has found this ready for publication as an Experimental RFC. Chris Lonvick (clonvick@cisco.com) has reviewed this draft for the Security Directorate. Lars Eggert has reviewed this spec for the IESG. Note to RFC Editor Section 7, the only paragraph OLD: We do not believe there are security implications involved with TCP- NCR over and above those for general TCP congestion control [RFC2581]. In particular, the Extended Limited Transmit algorithms specified in this document have been specifically designed not to be susceptible to the sorts of ACK splitting attacks TCP's general TCP congestion control is vulnerable to (as discussed in [RFC3465]). NEW: General attacks against the congestion control of TCP are described in [RFC2581]. SACK-based loss recovery for TCP [RFC3517] mitigates some of the duplicate ACK attacks against TCP's congestion control. This document builds upon that work, and the Extended Limited Transmit algorithms specified in this document have been designed to thwart the ACK division problems that are described in [RFC3465]. (I.e., just replace the entire paragraph.) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon May 08 12:06:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd8Ej-0002hI-Uu; Mon, 08 May 2006 12:05:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd8Ej-0002hD-EH for tcpm@ietf.org; Mon, 08 May 2006 12:05:29 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd8Ei-0000OS-37 for tcpm@ietf.org; Mon, 08 May 2006 12:05: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 k48G5RKV095975 for ; Mon, 8 May 2006 09:05:27 -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 2450D77AC74 for ; Mon, 8 May 2006 12:05:26 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Peaches MIME-Version: 1.0 Date: Mon, 08 May 2006 12:05:26 -0400 Message-Id: <20060508160526.2450D77AC74@guns.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [tcpm] TCPx2 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="===============0808951068==" Errors-To: tcpm-bounces@ietf.org --===============0808951068== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Hi folks! I jotted out an i-d on an idea that has been rolling around my head for a while. I submitted it, but until it pops out in the archive you can slurp a copy here: http://www.icir.org/mallman/draft-allman-tcpx2-hack-00.txt. The general idea of this hack is to increase TCP's header size once to deal with these field-foo-is-not-big-enough issues rather than trying to design a solution for each of these. (As the document says, this is not a proposal for a TCPng.) So, crack open an adult beverage, take a look and let me know what you think ... or, at least enjoy the read! :) allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEX2xGWyrrWs4yIs4RAu8jAKCNNx5h5IDZlKz4AxZLAU4vOPD2yQCfTqda gSnHQrMhoveBgTw0PSi30qE= =hWLc -----END PGP SIGNATURE----- --=_bOundary-- --===============0808951068== 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 --===============0808951068==-- From tcpm-bounces@ietf.org Mon May 08 13:29:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd9XQ-0007Oa-8Z; Mon, 08 May 2006 13:28:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd9XP-0007OM-NN for tcpm@ietf.org; Mon, 08 May 2006 13:28:51 -0400 Received: from mx2.grc.nasa.gov ([128.156.11.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd9XO-0005Fi-FS for tcpm@ietf.org; Mon, 08 May 2006 13:28:51 -0400 Received: from lombok-fi.grc.nasa.gov (seraph4.grc.nasa.gov [128.156.10.13]) by mx2.grc.nasa.gov (Postfix) with ESMTP id 0745EC24E for ; Mon, 8 May 2006 13:28:48 -0400 (EDT) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.13.6/8.13.6) with ESMTP id k48HSlJ4011415; Mon, 8 May 2006 13:28:47 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.6/8.13.1) with ESMTP id k48HSlvP029001; Mon, 8 May 2006 13:28:47 -0400 (EDT) Received: from apataki.grc.nasa.gov ([127.0.0.1]) by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24927-21; Mon, 8 May 2006 13:28:44 -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.6/8.13.1) with ESMTP id k48HSiUf028971; Mon, 8 May 2006 13:28:44 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501) id 04DB04FCA8; Mon, 8 May 2006 13:28:53 -0400 (EDT) Date: Mon, 8 May 2006 13:28:52 -0400 From: Wesley Eddy To: Mark Allman Subject: Re: [tcpm] TCPx2 Message-ID: <20060508172852.GB26444@grc.nasa.gov> References: <20060508160526.2450D77AC74@guns.icir.org> Mime-Version: 1.0 In-Reply-To: <20060508160526.2450D77AC74@guns.icir.org> User-Agent: Mutt/1.5.5.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: tcpm@ietf.org 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="===============0770050712==" Errors-To: tcpm-bounces@ietf.org --===============0770050712== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OBd5C1Lgu00Gd/Tn" Content-Disposition: inline --OBd5C1Lgu00Gd/Tn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 08, 2006 at 12:05:26PM -0400, Mark Allman wrote: > =20 > (As the document says, this is not a proposal for a TCPng.) >=20 > So, crack open an adult beverage, take a look and let me know what you > think ... or, at least enjoy the read! :) > What would the NAT considerations be for either this or a TCPng? Or, what would be the most appropriate goals with regard to the installed base of NATs? IMHO, this is the primary consideration before examining any modified header format. --=20 Wesley M. Eddy Verizon Federal Network Systems --OBd5C1Lgu00Gd/Tn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFEX3/UzBuYqbnj3IwRAoDfAJ45RHHhBPffPtXNKWU1lyxTO5LOawCfXRTr aHPjp/X8pDpgWs/4OtQ7hLY= =Ztpm -----END PGP SIGNATURE----- --OBd5C1Lgu00Gd/Tn-- --===============0770050712== 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 --===============0770050712==-- From tcpm-bounces@ietf.org Mon May 08 13:51:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd9t5-0007Iv-MK; Mon, 08 May 2006 13:51:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd9t4-0007Iq-Dw for tcpm@ietf.org; Mon, 08 May 2006 13:51:14 -0400 Received: from mail3.microsoft.com ([131.107.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd9t4-0006qN-3V for tcpm@ietf.org; Mon, 08 May 2006 13:51:14 -0400 Received: from mailout5.microsoft.com ([157.54.69.148]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 May 2006 10:50:00 -0700 Received: from tuk-hub-02.redmond.corp.microsoft.com ([157.54.70.28]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 May 2006 10:49:59 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by tuk-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 May 2006 10:49:59 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.26]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 May 2006 10:49:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] TCPx2 Date: Mon, 8 May 2006 10:49:14 -0700 Message-ID: <70C6EFCDFC8AAD418EF7063CD132D06493C528@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <20060508172852.GB26444@grc.nasa.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] TCPx2 thread-index: AcZyxRNhLGr2fPjZTDyRMj6qPiCaJgAADCwQ From: "Christian Huitema" To: , "Mark Allman" X-OriginalArrivalTime: 08 May 2006 17:49:58.0747 (UTC) FILETIME=[D2CEE2B0:01C672C7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Increase size fields is definitely a good reason for looking at TCPx2. After all, the current land-speed record is about 8 Gbps, and we have to support distances of at least 1/2 grand circle of the earth, i.e. 20,000 km, i.e. about 100 ms one way, 200 ms RTT. At that speed, there are 200MB of data in transit. Allow a few revs of Moore's law, and pretty soon bandwidth delay products exceed 4GB, i.e. have a serious problem with 32 bit sequence numbers. But there are other reasons as well, e.g.: 1) To get rid of the SYN flooding attack, it would be nice to start with a 4 ways handshake rather than the current 3-ways handshake. 2) It would be nice to make TCPx2 sessions independent of IP addresses, so the session can survive if the host moves to a new address, or if a multi-homed host starts using a new address. 3) It would be nice if TCPx2 allowed an initial exchange over a secondary channel (e.g. in a SIP payload), so as to facilitate NAT and firewall traversal. 4) If would be nice if the initial exchange included the negotiation of a session key, so the traffic could be encrypted and/or authenticated, much like with the current MD5 option. -- Christian Huitema=20 > -----Original Message----- > From: Wesley Eddy [mailto:weddy@grc.nasa.gov] > Sent: Monday, May 08, 2006 10:29 AM > To: Mark Allman > Cc: tcpm@ietf.org > Subject: Re: [tcpm] TCPx2 >=20 > On Mon, May 08, 2006 at 12:05:26PM -0400, Mark Allman wrote: > > > > (As the document says, this is not a proposal for a TCPng.) > > > > So, crack open an adult beverage, take a look and let me know what you > > think ... or, at least enjoy the read! :) > > >=20 > What would the NAT considerations be for either this or a TCPng? Or, what > would be the most appropriate goals with regard to the installed base of > NATs? >=20 > IMHO, this is the primary consideration before examining any modified > header format. >=20 > -- > Wesley M. Eddy > Verizon Federal Network Systems _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon May 08 14:05:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdA6J-0003pQ-W8; Mon, 08 May 2006 14:04:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdA6J-0003pL-EO for tcpm@ietf.org; Mon, 08 May 2006 14:04:55 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdA6H-0007VL-68 for tcpm@ietf.org; Mon, 08 May 2006 14:04:55 -0400 Received: from lion.bbn.com ([128.89.80.73]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FdA6E-0004Nx-5q; Mon, 08 May 2006 14:04:50 -0400 Message-ID: <445F8842.9080100@bbn.com> Date: Mon, 08 May 2006 14:04:50 -0400 From: "Armando L. Caro, Jr." User-Agent: Mail/News 1.5 (X11/20060210) MIME-Version: 1.0 To: mallman@icir.org Subject: Re: [tcpm] TCPx2 References: <20060508160526.2450D77AC74@guns.icir.org> In-Reply-To: <20060508160526.2450D77AC74@guns.icir.org> X-Enigmail-Version: 0.94.0.0 OpenPGP: id=A9CE816E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Mark, I have one initial thought in reference to the transition section of the draft. Instead of sending TCPx2 and TCP syn packets sequentially, sending them in parallel would reduce handshake latency for legacy TCP systems. If the receiver only supports TCP or TCPx2, only a single syn is acked. If the receiver supports TCPx2, then it interprets both syns as the same connection setup request and merges the two (I'll explain below). The underlying assumption is that the 32-bit port number has to be mappable to a 16-bit port number, but this is already implicitly assumed in the draft's transition solution. A true 32-bit port number (ie, larger than 2^16-1) can only be used when the client knows that the server supports TCPx2. The parallel SYN idea is as follows. Client C and Server S support TCPx2 (and TCP). Scenario A 1. C sends a TCPx2 and TCP syn packet in parallel to S 2. S receives TCPx2 syn packet first, and it is syn/acked immediately. 3. S receives TCP syn packet, and recognizes that it maps to the TCPx2 syn received, so the TCP syn is silently discarded. 4. TCPx2 connection setup continues as normal. Scenario B 1. C sends a TCPx2 and TCP syn packet in parallel to S 2. S receives TCP syn packet first, and it is syn/acked immediately. 3. S receives TCPx2 syn packet, and recognizes that it maps to the TCP syn received. S syn/acks the TCPx2 packet, essentially tell C that S does support TCPx2, so migrate connection from TCP to TCPx2. 4. C receives TCP syn/ack, and proceeds as normal. 5. C receives TCPx2 syn/ack, and realizes that S does support TCPx2. It basically upgrades the TCP conection to a TCPx2 connection, and sends an TCPx2 ack to complete the TCPx2 3-way handshake. Since the only difference between TCP and TCPx2 are the header fields, upgrading should be easy for an endpoint. 6. S receives TCPx2 ack to complete the TCPx2 3-way handshake, which triggers it to upgrade its end of the TCP connection to TCPx2. Note: If the TCPx2 syn/ack from S to C gets lost, S will retransmit it after a timeout. Also, each TCP packet received by S from C can trigger a new TCPx2 connection establishment for migrating the existing TCP connection to the upgraded version. -- Armando www.armandocaro.net _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon May 08 14:15:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdAGV-0006bc-3S; Mon, 08 May 2006 14:15:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdAGT-0006bQ-CT for tcpm@ietf.org; Mon, 08 May 2006 14:15:25 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdAGQ-0007uu-UN for tcpm@ietf.org; Mon, 08 May 2006 14:15:25 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k48IFLX76652; Mon, 8 May 2006 11:15:21 -0700 (PDT) (envelope-from fkastenholz@juniper.net) Received: from fkastenholzpc1.juniper.net (fkastenholzpc1.jnpr.net [172.28.36.185]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k48IFG588839; Mon, 8 May 2006 11:15:16 -0700 (PDT) (envelope-from fkastenholz@juniper.net) Message-Id: <6.2.1.2.2.20060508141240.0316bfd8@antipi> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 08 May 2006 14:15:09 -0400 To: "Christian Huitema" , , "Mark Allman" From: Frank Kastenholz Subject: RE: [tcpm] TCPx2 In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D06493C528@WIN-MSG-21.wingroup .windeploy.ntdev.microsoft.com> References: <20060508172852.GB26444@grc.nasa.gov> <70C6EFCDFC8AAD418EF7063CD132D06493C528@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Christian there are probably a couple of other things that one might wish to do in tcp if one were to allow the protocol (in the sense of algorithms, functions, and so on) to be changed. I can think of one or two myself (how about a different checksum, especially for jumbograms?) f At 01:49 PM 5/8/2006, Christian Huitema wrote: >Increase size fields is definitely a good reason for looking at TCPx2. >After all, the current land-speed record is about 8 Gbps, and we have to >support distances of at least 1/2 grand circle of the earth, i.e. 20,000 >km, i.e. about 100 ms one way, 200 ms RTT. At that speed, there are >200MB of data in transit. Allow a few revs of Moore's law, and pretty >soon bandwidth delay products exceed 4GB, i.e. have a serious problem >with 32 bit sequence numbers. > >But there are other reasons as well, e.g.: > >1) To get rid of the SYN flooding attack, it would be nice to start with >a 4 ways handshake rather than the current 3-ways handshake. > >2) It would be nice to make TCPx2 sessions independent of IP addresses, >so the session can survive if the host moves to a new address, or if a >multi-homed host starts using a new address. > >3) It would be nice if TCPx2 allowed an initial exchange over a >secondary channel (e.g. in a SIP payload), so as to facilitate NAT and >firewall traversal. > >4) If would be nice if the initial exchange included the negotiation of >a session key, so the traffic could be encrypted and/or authenticated, >much like with the current MD5 option. > >-- Christian Huitema > >> -----Original Message----- >> From: Wesley Eddy [mailto:weddy@grc.nasa.gov] >> Sent: Monday, May 08, 2006 10:29 AM >> To: Mark Allman >> Cc: tcpm@ietf.org >> Subject: Re: [tcpm] TCPx2 >> >> On Mon, May 08, 2006 at 12:05:26PM -0400, Mark Allman wrote: >> > >> > (As the document says, this is not a proposal for a TCPng.) >> > >> > So, crack open an adult beverage, take a look and let me know what >you >> > think ... or, at least enjoy the read! :) >> > >> >> What would the NAT considerations be for either this or a TCPng? Or, >what >> would be the most appropriate goals with regard to the installed base >of >> NATs? >> >> IMHO, this is the primary consideration before examining any modified >> header format. >> >> -- >> Wesley M. Eddy >> Verizon Federal Network Systems > >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www1.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon May 08 14:24:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdAPF-0008Ie-MU; Mon, 08 May 2006 14:24:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdAPE-0008IS-0R for tcpm@ietf.org; Mon, 08 May 2006 14:24:28 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdAPC-0008DS-IN for tcpm@ietf.org; Mon, 08 May 2006 14:24:27 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k48IOQX76774; Mon, 8 May 2006 11:24:26 -0700 (PDT) (envelope-from fkastenholz@juniper.net) Received: from fkastenholzpc1.juniper.net (fkastenholzpc1.jnpr.net [172.28.36.185]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k48IOK590906; Mon, 8 May 2006 11:24:20 -0700 (PDT) (envelope-from fkastenholz@juniper.net) Message-Id: <6.2.1.2.2.20060508142310.0316edd0@antipi> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 08 May 2006 14:24:04 -0400 To: "Armando L. Caro, Jr." , mallman@icir.org From: Frank Kastenholz Subject: Re: [tcpm] TCPx2 In-Reply-To: <445F8842.9080100@bbn.com> References: <20060508160526.2450D77AC74@guns.icir.org> <445F8842.9080100@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org why build the state? why not just put an option in the tcp syn that says 'answer back in tcpx2, if you'd like' f At 02:04 PM 5/8/2006, Armando L. Caro, Jr. wrote: >Mark, > >I have one initial thought in reference to the transition section of the >draft. Instead of sending TCPx2 and TCP syn packets sequentially, >sending them in parallel would reduce handshake latency for legacy TCP >systems. If the receiver only supports TCP or TCPx2, only a single syn >is acked. If the receiver supports TCPx2, then it interprets both syns >as the same connection setup request and merges the two (I'll explain >below). The underlying assumption is that the 32-bit port number has to >be mappable to a 16-bit port number, but this is already implicitly >assumed in the draft's transition solution. A true 32-bit port number >(ie, larger than 2^16-1) can only be used when the client knows that the >server supports TCPx2. > >The parallel SYN idea is as follows. > >Client C and Server S support TCPx2 (and TCP). > >Scenario A >1. C sends a TCPx2 and TCP syn packet in parallel to S > >2. S receives TCPx2 syn packet first, and it is syn/acked immediately. > >3. S receives TCP syn packet, and recognizes that it maps to the TCPx2 > syn received, so the TCP syn is silently discarded. > >4. TCPx2 connection setup continues as normal. > > >Scenario B >1. C sends a TCPx2 and TCP syn packet in parallel to S > >2. S receives TCP syn packet first, and it is syn/acked immediately. > >3. S receives TCPx2 syn packet, and recognizes that it maps to the TCP >syn received. S syn/acks the TCPx2 packet, essentially tell C that S >does support TCPx2, so migrate connection from TCP to TCPx2. > >4. C receives TCP syn/ack, and proceeds as normal. > >5. C receives TCPx2 syn/ack, and realizes that S does support TCPx2. It >basically upgrades the TCP conection to a TCPx2 connection, and sends an >TCPx2 ack to complete the TCPx2 3-way handshake. Since the only >difference between TCP and TCPx2 are the header fields, upgrading should >be easy for an endpoint. > >6. S receives TCPx2 ack to complete the TCPx2 3-way handshake, which >triggers it to upgrade its end of the TCP connection to TCPx2. > >Note: If the TCPx2 syn/ack from S to C gets lost, S will retransmit it >after a timeout. Also, each TCP packet received by S from C can trigger >a new TCPx2 connection establishment for migrating the existing TCP >connection to the upgraded version. > > >-- >Armando >www.armandocaro.net > >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www1.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon May 08 14:28:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdASa-0003Tc-Mp; Mon, 08 May 2006 14:27:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdASZ-0003TL-9P for tcpm@ietf.org; Mon, 08 May 2006 14:27:55 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdASW-0000G2-Vd for tcpm@ietf.org; Mon, 08 May 2006 14:27:55 -0400 Received: from lion.bbn.com ([128.89.80.73]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FdASW-0003ba-5O; Mon, 08 May 2006 14:27:52 -0400 Message-ID: <445F8DA8.10609@bbn.com> Date: Mon, 08 May 2006 14:27:52 -0400 From: "Armando L. Caro, Jr." User-Agent: Mail/News 1.5 (X11/20060210) MIME-Version: 1.0 To: Frank Kastenholz Subject: Re: [tcpm] TCPx2 References: <20060508172852.GB26444@grc.nasa.gov> <70C6EFCDFC8AAD418EF7063CD132D06493C528@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <6.2.1.2.2.20060508141240.0316bfd8@antipi> In-Reply-To: <6.2.1.2.2.20060508141240.0316bfd8@antipi> X-Enigmail-Version: 0.94.0.0 OpenPGP: id=A9CE816E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Ah, but now we are going down the path of an entirely different protocol. Mark's intention was to keep the protocol semantics the same, but just get more header space. -- Armando www.armandocaro.net Frank Kastenholz wrote: > Christian > there are probably a couple of other things that > one might wish to do in tcp if one were to allow > the protocol (in the sense of algorithms, functions, > and so on) to be changed. I can think of one or two > myself (how about a different checksum, especially > for jumbograms?) > > f > > At 01:49 PM 5/8/2006, Christian Huitema wrote: >> Increase size fields is definitely a good reason for looking at TCPx2. >> After all, the current land-speed record is about 8 Gbps, and we have to >> support distances of at least 1/2 grand circle of the earth, i.e. 20,000 >> km, i.e. about 100 ms one way, 200 ms RTT. At that speed, there are >> 200MB of data in transit. Allow a few revs of Moore's law, and pretty >> soon bandwidth delay products exceed 4GB, i.e. have a serious problem >> with 32 bit sequence numbers. >> >> But there are other reasons as well, e.g.: >> >> 1) To get rid of the SYN flooding attack, it would be nice to start with >> a 4 ways handshake rather than the current 3-ways handshake. >> >> 2) It would be nice to make TCPx2 sessions independent of IP addresses, >> so the session can survive if the host moves to a new address, or if a >> multi-homed host starts using a new address. >> >> 3) It would be nice if TCPx2 allowed an initial exchange over a >> secondary channel (e.g. in a SIP payload), so as to facilitate NAT and >> firewall traversal. >> >> 4) If would be nice if the initial exchange included the negotiation of >> a session key, so the traffic could be encrypted and/or authenticated, >> much like with the current MD5 option. >> >> -- Christian Huitema >> >>> -----Original Message----- >>> From: Wesley Eddy [mailto:weddy@grc.nasa.gov] >>> Sent: Monday, May 08, 2006 10:29 AM >>> To: Mark Allman >>> Cc: tcpm@ietf.org >>> Subject: Re: [tcpm] TCPx2 >>> >>> On Mon, May 08, 2006 at 12:05:26PM -0400, Mark Allman wrote: >>>> (As the document says, this is not a proposal for a TCPng.) >>>> >>>> So, crack open an adult beverage, take a look and let me know what >> you >>>> think ... or, at least enjoy the read! :) >>>> >>> What would the NAT considerations be for either this or a TCPng? Or, >> what >>> would be the most appropriate goals with regard to the installed base >> of >>> NATs? >>> >>> IMHO, this is the primary consideration before examining any modified >>> header format. >>> >>> -- >>> Wesley M. Eddy >>> Verizon Federal Network Systems >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www1.ietf.org/mailman/listinfo/tcpm > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon May 08 14:28:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdASl-0003aO-68; Mon, 08 May 2006 14:28:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdASj-0003ZS-Me for tcpm@ietf.org; Mon, 08 May 2006 14:28:05 -0400 Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdASi-0000Ge-BZ for tcpm@ietf.org; Mon, 08 May 2006 14:28:05 -0400 Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Mon, 08 May 2006 11:27:55 -0700 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 1B41D2B0; Mon, 8 May 2006 11:27:55 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id EDCFB2AF; Mon, 8 May 2006 11:27:54 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5-GA) with ESMTP id DLZ07585; Mon, 8 May 2006 11:27:54 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 3B53320501; Mon, 8 May 2006 11:27:54 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] TCPx2 Date: Mon, 8 May 2006 11:27:53 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F149ECB1@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [tcpm] TCPx2 Thread-Index: AcZyuXRcRdwz/3QQSlmZYV98i2EX3wAEsxeA From: "Caitlin Bestler" To: mallman@icir.org, tcpm@ietf.org X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006050806; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230342E34343546384242322E303036412D412D; ENG=IBF; TS=20060508182757; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006050806_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 684152213NG13961197-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Mark Allman wrote: > Hi folks! >=20 > I jotted out an i-d on an idea that has been rolling around > my head for a while. I submitted it, but until it pops out > in the archive you can slurp a copy here: > http://www.icir.org/mallman/draft-allman-tcpx2-hack-00.txt. > The general idea of this hack is to increase TCP's header > size once to deal with these field-foo-is-not-big-enough > issues rather than trying to design a solution for each of these. >=20 > (As the document says, this is not a proposal for a TCPng.) >=20 > So, crack open an adult beverage, take a look and let me know > what you think ... or, at least enjoy the read! :) >=20 > allman In any sort of "let's really fix TCP" discussion I think the starting point should be SCTP. There are some very fine features in SCTP, (just as the 4-way handshake, multistreaming and multihoming) and one very big limitation -- lazy middleboxes that should be working at L3 are all too often L4-aware and thereby fail to properly support SCTP. We can be purists and say that the middleboxes should be updated to conform to the specs. In that case, why don't we just come up with a profile of SCTP that's optimized for SOCK_STREAM? It's much easier than defining a new transport protocol. Or we can start with the assumption that any new solution MUST be transparent to existing middleboxes. That suggests that the way to get more space for connection setup and other data is to somehow get both sides to agree that the first N bytes of the data stream aren't for the application but carry this additional data. Is something that would be a new transport protocol even properly belong under the label "Modifications"? _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon May 08 14:34:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdAYE-0006VK-BS; Mon, 08 May 2006 14:33:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdAYD-0006Ue-4e for tcpm@ietf.org; Mon, 08 May 2006 14:33:45 -0400 Received: from mms2.broadcom.com ([216.31.210.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdAYB-0000g8-Qt for tcpm@ietf.org; Mon, 08 May 2006 14:33:45 -0400 Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Mon, 08 May 2006 11:33:27 -0700 X-Server-Uuid: D9EB6F12-1469-4C1C-87A2-5E4C0D6F9D06 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 533BA2AF; Mon, 8 May 2006 11:33:27 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 201F72AE; Mon, 8 May 2006 11:33:27 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5-GA) with ESMTP id DLZ09830; Mon, 8 May 2006 11:33:24 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 411DA20502; Mon, 8 May 2006 11:33:24 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] TCPx2 Date: Mon, 8 May 2006 11:33:23 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F149ECB6@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [tcpm] TCPx2 Thread-Index: AcZyzTc5Tim2+BHnT3Cb07mpWmXOOwAACmmg From: "Caitlin Bestler" To: "Armando L. Caro, Jr." , "Frank Kastenholz" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006050806; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230352E34343546384430312E303031372D412D; ENG=IBF; TS=20060508183331; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006050806_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 6841517D4I87347919-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Armando L. Caro, Jr. wrote: > Ah, but now we are going down the path of an entirely > different protocol. Mark's intention was to keep the protocol > semantics the same, but just get more header space. >=20 >=20 To me what is frozen are those pesky L4-aware network elements and the SOCK_STREAM payload semantics. It would be worthwhile to consider proposals, even with new semantics, that enhance connection setup and provide for more option space, as long as it did not disrupt either network elements or the basic listen()/connect()/accept()/sendmsg()/recvmsg() application layer interactions. Of course there may be new options associated with the listen()/connect() and accept(), as long as they stay options. After that, you're talking applications having to rethink, in which case why not use SCTP? _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon May 08 14:39:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdAdt-0006m1-By; Mon, 08 May 2006 14:39:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdAds-0006lw-Mf for tcpm@ietf.org; Mon, 08 May 2006 14:39:36 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdAdr-000100-Bh for tcpm@ietf.org; Mon, 08 May 2006 14:39:36 -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 k48IdVch098825; Mon, 8 May 2006 11:39:31 -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 0F80377AC74; Mon, 8 May 2006 14:39:30 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 40F4940A0E7; Mon, 8 May 2006 14:38:35 -0400 (EDT) To: "Caitlin Bestler" From: Mark Allman Subject: Re: [tcpm] TCPx2 In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F149ECB1@NT-SJCA-0751.brcm.ad.broadcom.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Peaches MIME-Version: 1.0 Date: Mon, 08 May 2006 14:38:34 -0400 Message-Id: <20060508183835.40F4940A0E7@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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="===============1252476066==" Errors-To: tcpm-bounces@ietf.org --===============1252476066== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Christian: > Increase size fields is definitely a good reason for looking at TCPx2. > [...] > But there are other reasons as well, e.g.: Caitlyn: > In any sort of "let's really fix TCP" discussion I think > the starting point should be SCTP. Allow me to call attention to this bit from the draft: This document is not about specifying a "TCPng". The functionality (or lack thereof) of TCP is not changed. The intention is to simply give TCP some possibly breathing room. The proposal is for pragmatic evolution, rather than principled engineering. This draft is not about adding functionality. I believe everyone in the transport community has their own vision of what a TCPng looks like. If you do, please write it down and take it from there. This proposal is a (probably cracked out) wondering about whether simply bumping the size and leaving the functionality is a reasonable path. (And, pragmatically, this leaves more option space and more reserved bits in the header for people to tinker with.) allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEX5AqWyrrWs4yIs4RAkvrAKCHYIw+AA9GL6iTPThNXby+2IlqdQCdGUZg e3BwZgDk7rExrK/+MyFkNB8= =kdwV -----END PGP SIGNATURE----- --=_bOundary-- --===============1252476066== 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 --===============1252476066==-- From tcpm-bounces@ietf.org Mon May 08 14:44:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdAiZ-000749-7F; Mon, 08 May 2006 14:44:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdAiX-000741-9y for tcpm@ietf.org; Mon, 08 May 2006 14:44:25 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdAiS-0001A5-U3 for tcpm@ietf.org; Mon, 08 May 2006 14:44:25 -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 k48IiJmk098914; Mon, 8 May 2006 11:44:19 -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 763DE77AC74; Mon, 8 May 2006 14:44:17 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id CA61640A116; Mon, 8 May 2006 14:43:22 -0400 (EDT) To: weddy@grc.nasa.gov From: Mark Allman Subject: Re: [tcpm] TCPx2 In-Reply-To: <20060508172852.GB26444@grc.nasa.gov> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Peaches MIME-Version: 1.0 Date: Mon, 08 May 2006 14:43:22 -0400 Message-Id: <20060508184322.CA61640A116@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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="===============0506872283==" Errors-To: tcpm-bounces@ietf.org --===============0506872283== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > On Mon, May 08, 2006 at 12:05:26PM -0400, Mark Allman wrote: > > > > (As the document says, this is not a proposal for a TCPng.) > > > > So, crack open an adult beverage, take a look and let me know what you > > think ... or, at least enjoy the read! :) > > > > What would the NAT considerations be for either this or a TCPng? Or, > what would be the most appropriate goals with regard to the installed > base of NATs? > > IMHO, this is the primary consideration before examining any modified > header format. I think NATs are going to kill any new TCPng or TCPx2. I don't think there is any question about it. I also envision that in either case the changes to make NATs grok the new protocols will be pretty easy. And, the transition issues in the current draft are aimed at just this sort of thing. I.e., a TCPx2 can fall back to TCP. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEX5FKWyrrWs4yIs4RAgBfAJ0c/oAjigRBa3chez9bpslRonTdbwCfW2oV lR1r9DsXKJeilSRFeDbXH9U= =X30J -----END PGP SIGNATURE----- --=_bOundary-- --===============0506872283== 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 --===============0506872283==-- From tcpm-bounces@ietf.org Mon May 08 14:53:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdAqk-0001hi-DJ; Mon, 08 May 2006 14:52:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdAqj-0001hc-8p for tcpm@ietf.org; Mon, 08 May 2006 14:52:53 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdAqh-0001QI-UZ for tcpm@ietf.org; Mon, 08 May 2006 14:52:53 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k48Iqo39099048; Mon, 8 May 2006 11:52:51 -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 891B577AC74; Mon, 8 May 2006 14:52:49 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id B1F3C40A16B; Mon, 8 May 2006 14:51:54 -0400 (EDT) To: "Caitlin Bestler" From: Mark Allman Subject: Re: [tcpm] TCPx2 In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F149ECBD@NT-SJCA-0751.brcm.ad.broadcom.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Peaches MIME-Version: 1.0 Date: Mon, 08 May 2006 14:51:54 -0400 Message-Id: <20060508185154.B1F3C40A16B@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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="===============1692212114==" Errors-To: tcpm-bounces@ietf.org --===============1692212114== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > Agreed, but as I read the proposal it has the same impediments > to deployment as SCTP without any of the additional features. > > Is there any reason why the network elements that do not > support SCTP will support TCPx2? People use TCP? allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEX5NKWyrrWs4yIs4RAg+iAJ9wNRNQ9VAa8DOjty4bnKuK+S9NVwCfRNgf s24qJscNyrrAC0RCh4hj/RE= =+RPy -----END PGP SIGNATURE----- --=_bOundary-- --===============1692212114== 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 --===============1692212114==-- From tcpm-bounces@ietf.org Mon May 08 14:57:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdAuw-0005kN-66; Mon, 08 May 2006 14:57:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdAuu-0005dp-SD for tcpm@ietf.org; Mon, 08 May 2006 14:57:12 -0400 Received: from mms2.broadcom.com ([216.31.210.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdAuu-0001jN-IX for tcpm@ietf.org; Mon, 08 May 2006 14:57:12 -0400 Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Mon, 08 May 2006 11:57:04 -0700 X-Server-Uuid: D9EB6F12-1469-4C1C-87A2-5E4C0D6F9D06 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 9A8752AF; Mon, 8 May 2006 11:57:04 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 78EFA2AE; Mon, 8 May 2006 11:57:04 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5-GA) with ESMTP id DLZ19097; Mon, 8 May 2006 11:57:04 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 0F8DD20501; Mon, 8 May 2006 11:57:04 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] TCPx2 Date: Mon, 8 May 2006 11:57:03 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F149ECC2@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [tcpm] TCPx2 Thread-Index: AcZy0KH5D53TMLsSTY6juFW+PH11TQAAC8Hg From: "Caitlin Bestler" To: mallman@icir.org X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006050806; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230392E34343546393238412E303031312D412D; ENG=IBF; TS=20060508185708; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006050806_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 68414B0A4I87352403-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org mallman@icir.org wrote: >> Agreed, but as I read the proposal it has the same impediments to >> deployment as SCTP without any of the additional features. >>=20 >> Is there any reason why the network elements that do not support SCTP >> will support TCPx2? >=20 > People use TCP? >=20 > allman But they don't use TCPx2. Any middlebox firmware developer can still refuse to add a single line of firmware to support TCPx2 and they cite the fact that nobody is using it as justification. Applying the *same* PNAT logic used for TCP and UDP for SCTP would be also be a very similar change. But it doesn't make the cut because nobody uses it, and nobody uses it because... _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon May 08 15:07:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdB4g-0000NS-9h; Mon, 08 May 2006 15:07:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdB4e-0000NN-DH for tcpm@ietf.org; Mon, 08 May 2006 15:07:16 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdB4d-00025O-7N for tcpm@ietf.org; Mon, 08 May 2006 15:07:16 -0400 Received: from lion.bbn.com ([128.89.80.73]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FdB4d-000494-3L; Mon, 08 May 2006 15:07:15 -0400 Message-ID: <445F96E2.8010609@bbn.com> Date: Mon, 08 May 2006 15:07:14 -0400 From: "Armando L. Caro, Jr." User-Agent: Mail/News 1.5 (X11/20060210) MIME-Version: 1.0 To: Frank Kastenholz Subject: Re: [tcpm] TCPx2 References: <20060508160526.2450D77AC74@guns.icir.org> <445F8842.9080100@bbn.com> <6.2.1.2.2.20060508142310.0316edd0@antipi> In-Reply-To: <6.2.1.2.2.20060508142310.0316edd0@antipi> X-Enigmail-Version: 0.94.0.0 OpenPGP: id=A9CE816E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Frank Kastenholz wrote: > why build the state? > why not just put an option in the tcp syn that says > 'answer back in tcpx2, if you'd like' Good point. That makes more sense. -- Armando www.armandocaro.net _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon May 08 15:10:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdB7Z-0000YP-Jb; Mon, 08 May 2006 15:10:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdB7X-0000Y2-R0 for tcpm@ietf.org; Mon, 08 May 2006 15:10:15 -0400 Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdB7W-00029W-Jx for tcpm@ietf.org; Mon, 08 May 2006 15:10:15 -0400 Received: from horh1.emsr.lucent.com (h135-112-138-211.lucent.com [135.112.138.211]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k48JA0NC007525; Mon, 8 May 2006 14:10:00 -0500 (CDT) Received: from new-wopr.eng.ascend.com (new-wopr.eng.ascend.com [135.140.53.19]) by horh1.emsr.lucent.com (8.12.11/8.12.11) with ESMTP id k48J9x7x023488; Mon, 8 May 2006 14:09:59 -0500 (CDT) Received: from cliff.eng.ascend.com (cliff.eng.ascend.com [135.140.53.169]) by new-wopr.eng.ascend.com (8.11.6+Sun/8.10.2) with ESMTP id k48J9wo14958; Mon, 8 May 2006 12:09:58 -0700 (PDT) Received: from igoyret-t23 (dhcp-135-140-27-162 [135.140.27.162]) by cliff.eng.ascend.com (8.13.1/8.13.1) with SMTP id k48J9wBV027870; Mon, 8 May 2006 12:09:58 -0700 Message-Id: <200605081909.k48J9wBV027870@cliff.eng.ascend.com> X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Mon, 08 May 2006 12:09:38 -0700 To: "Armando L. Caro, Jr." From: Ignacio Goyret Subject: Re: [tcpm] TCPx2 In-Reply-To: <445F96E2.8010609@bbn.com> References: <6.2.1.2.2.20060508142310.0316edd0@antipi> <20060508160526.2450D77AC74@guns.icir.org> <445F8842.9080100@bbn.com> <6.2.1.2.2.20060508142310.0316edd0@antipi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 15:07 5/8/2006 -0400, Armando L. Caro, Jr. wrote: >Frank Kastenholz wrote: >> why build the state? >> why not just put an option in the tcp syn that says >> 'answer back in tcpx2, if you'd like' > >Good point. That makes more sense. Except you would lose access to the 32-bit source port number. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon May 08 15:11:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdB8y-0000db-Av; Mon, 08 May 2006 15:11:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdB8x-0000dV-1G for tcpm@ietf.org; Mon, 08 May 2006 15:11:43 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdB8v-0002Az-Lz for tcpm@ietf.org; Mon, 08 May 2006 15:11:43 -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 k48JBeWR099366; Mon, 8 May 2006 12:11:40 -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 01B9777AC74; Mon, 8 May 2006 15:11:39 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 5A63640A1C4; Mon, 8 May 2006 15:10:44 -0400 (EDT) To: "Caitlin Bestler" From: Mark Allman Subject: Re: [tcpm] TCPx2 In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F149ECC2@NT-SJCA-0751.brcm.ad.broadcom.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Peaches MIME-Version: 1.0 Date: Mon, 08 May 2006 15:10:44 -0400 Message-Id: <20060508191044.5A63640A1C4@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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="===============1503998166==" Errors-To: tcpm-bounces@ietf.org --===============1503998166== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > mallman@icir.org wrote: > >> Agreed, but as I read the proposal it has the same impediments to > >> deployment as SCTP without any of the additional features. > >>=20 > >> Is there any reason why the network elements that do not support SCTP > >> will support TCPx2? > >=20 > > People use TCP? > >=20 > > allman >=20 > But they don't use TCPx2. >=20 > Any middlebox firmware developer can still refuse to add a single line > of firmware to support TCPx2 and they cite the fact that nobody is > using it as justification. >=20 > Applying the *same* PNAT logic used for TCP and UDP for SCTP would be > also be a very similar change. But it doesn't make the cut because > nobody uses it, and nobody uses it because... First, you're missing the (admittedly pithy) point. It's an easy change to NATs to make x2, DCCP, SCTP, whatever work. TCP is widely used. SCTP is not. If we standardized x2 then we'd be migrating, not building From=20zero. You asked if there was a reason and my own opinion is that the difference is in the massive use of TCP that could be a base for x2. SCTP does not have the base. (And, note, that I am not trying to disparage SCTP here. I am just noting what I see as a practical difference.)=20 Second, I think this entire line of wondering is sort of ridiculous. If we block on what some network element (or even all current "network elements") will block then we'll never do anything. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEX5e0WyrrWs4yIs4RAnszAJ9Ka5S2BhqtA88sj9pFeW4DvWsTyQCdHo/W yt0lfrvIO2QguwYE4ppAr5w= =nWPN -----END PGP SIGNATURE----- --=_bOundary-- --===============1503998166== 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 --===============1503998166==-- From tcpm-bounces@ietf.org Mon May 08 15:14:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdBBt-0000vH-Im; Mon, 08 May 2006 15:14:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdBBr-0000v7-JU for tcpm@ietf.org; Mon, 08 May 2006 15:14:43 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdBBr-0002EK-9J for tcpm@ietf.org; Mon, 08 May 2006 15:14:43 -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 k48JEUd1099409; Mon, 8 May 2006 12:14:30 -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 1F7C777AC74; Mon, 8 May 2006 15:14:29 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 760DA40A20A; Mon, 8 May 2006 15:13:34 -0400 (EDT) To: Ignacio Goyret From: Mark Allman Subject: Re: [tcpm] TCPx2 In-Reply-To: <200605081909.k48J9wBV027870@cliff.eng.ascend.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Peaches MIME-Version: 1.0 Date: Mon, 08 May 2006 15:13:34 -0400 Message-Id: <20060508191334.760DA40A20A@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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="===============0060162242==" Errors-To: tcpm-bounces@ietf.org --===============0060162242== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > At 15:07 5/8/2006 -0400, Armando L. Caro, Jr. wrote: > >Frank Kastenholz wrote: > >> why build the state? > >> why not just put an option in the tcp syn that says > >> 'answer back in tcpx2, if you'd like' > > > >Good point. That makes more sense. > > Except you would lose access to the 32-bit source port number. Right. Not to mention the larger option space on the SYN - which is when it most crowded (if you buy that it's crowded at all). I had thought of the parallel thing (but, not worked it out as much as Armando did - I'll have to think on it a bit more). Doing it in parallel does not offend me on the surface. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEX5heWyrrWs4yIs4RAulBAJ97A/gaHpeXHLZ9xnelwSWuwVMCgACfcj9l 2TVOeP/T/C/ye1gpW4FEB4c= =GlDT -----END PGP SIGNATURE----- --=_bOundary-- --===============0060162242== 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 --===============0060162242==-- From tcpm-bounces@ietf.org Mon May 08 15:25:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdBLe-0007HW-3z; Mon, 08 May 2006 15:24:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdBLd-0007HR-44 for tcpm@ietf.org; Mon, 08 May 2006 15:24:49 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdBLa-0002iy-OC for tcpm@ietf.org; Mon, 08 May 2006 15:24:49 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k48JOj1Z064517; Mon, 8 May 2006 12:24:46 -0700 (PDT) (envelope-from fkastenholz@juniper.net) Received: from fkastenholzpc1.juniper.net (fkastenholzpc1.jnpr.net [172.28.36.185]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k48JOj503911; Mon, 8 May 2006 12:24:45 -0700 (PDT) (envelope-from fkastenholz@juniper.net) Message-Id: <6.2.1.2.2.20060508152014.030bf1d8@antipi> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 08 May 2006 15:24:42 -0400 To: mallman@icir.org, Ignacio Goyret From: Frank Kastenholz Subject: Re: [tcpm] TCPx2 In-Reply-To: <20060508191334.760DA40A20A@lawyers.icir.org> References: <200605081909.k48J9wBV027870@cliff.eng.ascend.com> <20060508191334.760DA40A20A@lawyers.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 03:13 PM 5/8/2006, Mark Allman wrote: >> At 15:07 5/8/2006 -0400, Armando L. Caro, Jr. wrote: >> >Frank Kastenholz wrote: >> >> why build the state? >> >> why not just put an option in the tcp syn that says >> >> 'answer back in tcpx2, if you'd like' >> > >> >Good point. That makes more sense. >> >> Except you would lose access to the 32-bit source port number. > >Right. carry the appropriate header fields in the option. you could do it with 64 bits -- 32 for each of the sport and dport. (requires defining that when synning a connection, all 64bit sequence numbers start with the high32 bits 0.) f > Not to mention the larger option space on the SYN - which is >when it most crowded (if you buy that it's crowded at all). > >I had thought of the parallel thing (but, not worked it out as much as >Armando did - I'll have to think on it a bit more). Doing it in >parallel does not offend me on the surface. > >allman > > > > > >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www1.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon May 08 15:25:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdBMN-0007Jn-Cb; Mon, 08 May 2006 15:25:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdBMM-0007Ji-TW for tcpm@ietf.org; Mon, 08 May 2006 15:25:34 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdBMK-0002kV-Mn for tcpm@ietf.org; Mon, 08 May 2006 15:25:34 -0400 Received: from lion.bbn.com ([128.89.80.73]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FdBMI-0005KY-4e; Mon, 08 May 2006 15:25:30 -0400 Message-ID: <445F9B2A.4030001@bbn.com> Date: Mon, 08 May 2006 15:25:30 -0400 From: "Armando L. Caro, Jr." User-Agent: Mail/News 1.5 (X11/20060210) MIME-Version: 1.0 To: Ignacio Goyret Subject: Re: [tcpm] TCPx2 References: <6.2.1.2.2.20060508142310.0316edd0@antipi> <20060508160526.2450D77AC74@guns.icir.org> <445F8842.9080100@bbn.com> <6.2.1.2.2.20060508142310.0316edd0@antipi> <200605081909.k48J9wBV027870@cliff.eng.ascend.com> In-Reply-To: <200605081909.k48J9wBV027870@cliff.eng.ascend.com> X-Enigmail-Version: 0.94.0.0 OpenPGP: id=A9CE816E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Ignacio Goyret wrote: > At 15:07 5/8/2006 -0400, Armando L. Caro, Jr. wrote: >> Frank Kastenholz wrote: >>> why build the state? >>> why not just put an option in the tcp syn that says >>> 'answer back in tcpx2, if you'd like' >> Good point. That makes more sense. > > Except you would lose access to the 32-bit source port number. It could be part of the option field, but also as I pointed out... if a client wants to use a port number larger than 2^16-1, then the client has to KNOW that the server supports TCPx2. You can't map 32-bits into 16. ...so when the 32-bit port number is needed, the client will start off by talking TCPx2. Legacy TCP cannot be used. -- Armando www.armandocaro.net _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon May 08 15:32:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdBSj-0007gj-OL; Mon, 08 May 2006 15:32:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdBSi-0007gb-72 for tcpm@ietf.org; Mon, 08 May 2006 15:32:08 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdBSg-00033D-Qc for tcpm@ietf.org; Mon, 08 May 2006 15:32:08 -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 k48JW1b8099701; Mon, 8 May 2006 12:32:01 -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 577D477B398; Mon, 8 May 2006 15:32:00 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id AFA9A40A25F; Mon, 8 May 2006 15:31:05 -0400 (EDT) To: Frank Kastenholz From: Mark Allman Subject: Re: [tcpm] TCPx2 In-Reply-To: <6.2.1.2.2.20060508152014.030bf1d8@antipi> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Peaches MIME-Version: 1.0 Date: Mon, 08 May 2006 15:31:05 -0400 Message-Id: <20060508193105.AFA9A40A25F@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: tcpm@ietf.org, Ignacio Goyret 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="===============1363856220==" Errors-To: tcpm-bounces@ietf.org --===============1363856220== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > carry the appropriate header fields > in the option. you could do it with > 64 bits -- 32 for each of the sport and dport. > > (requires defining that when synning a connection, > all 64bit sequence numbers start with the high32 > bits 0.) You're making more crud than you're saving here. * You'd now have to shove all options for TCP and TCPx2 into the option space of TCP (40 bytes). I.e., you better advertise a WS and a TS in case you can't use x2. And, you better advertise bigger ports and alternate checksum and ... whatever else we invent in case the peer does not support x2. Things may get tight quick. * Your testing the path at least as much as the end host with the x2 SYN. The end hosts may support x2 just fine, but if the firewall or the NAT doesn't then you're hosed and then you're going to negotiate x2 and then have to somehow fall back to TCP---which is the exact problem you're trying to avoid by sending only one SYN. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEX5x5WyrrWs4yIs4RAoEZAJ9kl+XgFS6qm2i213qp1VwCybaxKgCdEez8 sWtga3aW0kB9NVWj0jWug3g= =wz+3 -----END PGP SIGNATURE----- --=_bOundary-- --===============1363856220== 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 --===============1363856220==-- From tcpm-bounces@ietf.org Mon May 08 16:34:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdCQi-0002iM-0u; Mon, 08 May 2006 16:34:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdCQh-0002iH-Ej for tcpm@ietf.org; Mon, 08 May 2006 16:34:07 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdAqy-0001NW-Qf for tcpm@ietf.org; Mon, 08 May 2006 14:53:08 -0400 Received: from mms2.broadcom.com ([216.31.210.18]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FdAi3-0001or-OJ for tcpm@ietf.org; Mon, 08 May 2006 14:43:56 -0400 Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Mon, 08 May 2006 11:43:40 -0700 X-Server-Uuid: D9EB6F12-1469-4C1C-87A2-5E4C0D6F9D06 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 8AB902B0; Mon, 8 May 2006 11:43:40 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 591202AE; Mon, 8 May 2006 11:43:40 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5-GA) with ESMTP id DLZ13829; Mon, 8 May 2006 11:43:40 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id E894F20501; Mon, 8 May 2006 11:43:39 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] TCPx2 Date: Mon, 8 May 2006 11:43:39 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F149ECBD@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [tcpm] TCPx2 Thread-Index: AcZyzsVaPDz6TKfzScu5ymrnCqlV3QAAGeIw From: "Caitlin Bestler" To: mallman@icir.org X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006050806; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230342E34343546384636362E303031412D412D; ENG=IBF; TS=20060508184344; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006050806_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 68414ED64I87349880-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.1 (-) 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: , Errors-To: tcpm-bounces@ietf.org mallman@icir.org wrote: > Christian: >> Increase size fields is definitely a good reason for looking at >> TCPx2. [...] But there are other reasons as well, e.g.: >=20 > Caitlyn: >> In any sort of "let's really fix TCP" discussion I think the starting >> point should be SCTP. >=20 > Allow me to call attention to this bit from the draft: >=20 > This document is not about specifying a "TCPng". The > functionality (or lack thereof) of TCP is not changed. The > intention=20 > is to simply > give TCP some possibly breathing room. The proposal is for > pragmatic evolution, rather than principled engineering. >=20 > This draft is not about adding functionality. I believe > everyone in the transport community has their own vision of > what a TCPng looks like. If you do, please write it down and > take it from there. This proposal is a (probably cracked > out) wondering about whether simply bumping the size and > leaving the functionality is a reasonable path. >=20 > (And, pragmatically, this leaves more option space and more > reserved bits in the header for people to tinker with.) >=20 > allman Agreed, but as I read the proposal it has the same impediments to deployment as SCTP without any of the additional features. Is there any reason why the network elements that do not=20 support SCTP will support TCPx2? _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon May 08 18:04:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdDpo-000533-KZ; Mon, 08 May 2006 18:04:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdDpn-00052y-Dt for tcpm@ietf.org; Mon, 08 May 2006 18:04:07 -0400 Received: from dsl092-066-146.bos1.dsl.speakeasy.net ([66.92.66.146] helo=alva.home) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdDpm-0004TA-4F for tcpm@ietf.org; Mon, 08 May 2006 18:04:07 -0400 Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1FdDpL-0000IZ-00; Mon, 08 May 2006 18:03:39 -0400 From: Tim Shepard To: Frank Kastenholz Subject: Re: [tcpm] TCPx2 In-reply-to: Your message of Mon, 08 May 2006 14:24:04 -0400. <6.2.1.2.2.20060508142310.0316edd0@antipi> Date: Mon, 08 May 2006 18:03:39 -0400 Message-Id: X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: tcpm@ietf.org, mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org > why not just put an option in the tcp syn that says > 'answer back in tcpx2, if you'd like' While some Firewall/Nat/Middlebox may have let the tcp SYN with I-can-do-tcpx2-also option through, a tcpx2 SYN ACK packet going back might not make it (because some firewall or NAT is unaware of tcpx2). Middleboxes sure do make things fun. -Tim Shepard shep@alum.mit.edu _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon May 08 23:23:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdIoA-0000XW-90; Mon, 08 May 2006 23:22:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdIo9-0000XR-1V for tcpm@ietf.org; Mon, 08 May 2006 23:22:45 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdIo7-0004CE-ND for tcpm@ietf.org; Mon, 08 May 2006 23:22:45 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k493MGr7008937; Mon, 8 May 2006 20:22:16 -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 B963377AC74; Mon, 8 May 2006 23:22:13 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id AB0A040A749; Mon, 8 May 2006 23:21:19 -0400 (EDT) To: Tim Shepard From: Mark Allman Subject: Re: [tcpm] TCPx2 In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Peaches MIME-Version: 1.0 Date: Mon, 08 May 2006 23:21:19 -0400 Message-Id: <20060509032119.AB0A040A749@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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="===============1134270566==" Errors-To: tcpm-bounces@ietf.org --===============1134270566== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > While some Firewall/Nat/Middlebox may have let the tcp SYN with > I-can-do-tcpx2-also option through, a tcpx2 SYN ACK packet going back > might not make it (because some firewall or NAT is unaware of tcpx2). > > Middleboxes sure do make things fun. I'd put it this way .... In 2006 it is just as important to probe the network to see whether the path supports some new protocol as it is to assess whether the remote peer supports the given protocol. For me, that means you just have to bite the bullet and send a real x2 packet. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEYAqvWyrrWs4yIs4RAsJ4AJ9EyNhYgEUU4BJ4q94zcSEfBQUHLACgmM6M SAbG2Bs4v/iC4UnWXpY7b10= =f/Ch -----END PGP SIGNATURE----- --=_bOundary-- --===============1134270566== 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 --===============1134270566==-- From tcpm-bounces@ietf.org Tue May 09 01:01:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdKL3-0007sg-Q6; Tue, 09 May 2006 01:00:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdKL3-0007sb-0z for tcpm@ietf.org; Tue, 09 May 2006 01:00:49 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdKL1-0000vz-GE for tcpm@ietf.org; Tue, 09 May 2006 01:00:49 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060308/8.12.11) with ESMTP id k4950jKq009756 for ; Tue, 9 May 2006 08:00:45 +0300 Date: Tue, 9 May 2006 08:00:45 +0300 (EEST) From: Pekka Savola To: tcpm@ietf.org Subject: Re: [tcpm] TCPx2 -- useful enough to be worth doing? In-Reply-To: <20060508183835.40F4940A0E7@lawyers.icir.org> Message-ID: References: <20060508183835.40F4940A0E7@lawyers.icir.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1451/Tue May 9 02:27:49 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-0.0 required=5.0 tests=NO_RELAYS autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Mon, 8 May 2006, Mark Allman wrote: > Allow me to call attention to this bit from the draft: > > This document is not about specifying a "TCPng". The functionality > (or lack thereof) of TCP is not changed. The intention is to simply > give TCP some possibly breathing room. The proposal is for > pragmatic evolution, rather than principled engineering. > > This draft is not about adding functionality. I believe everyone in > the transport community has their own vision of what a TCPng looks > like. If you do, please write it down and take it from there. This > proposal is a (probably cracked out) wondering about whether simply > bumping the size and leaving the functionality is a reasonable path. I guess the most important point we'd have to figure out at some point (not necessarily here, as this group isn't even chartered to do TCPx2) is, "is TCPx2 [or some similar "bigger is better" proposal] useful enough on its own to be worth doing?" I.e., if there's going to be significant deployment pain (implementation should be rather straightforward), maybe addressing some other TCP shortcomings would also be called for. Or maybe not, it depends on your perspective and how well you think other protocols like SCTP or DCCP address your scenarios. I think we learned from the IPv6 experience that while Bigger is Better, many folks would actually have wanted to get a feature upgrade (e.g., identifier/locator split) as well... -- 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 May 09 08:46:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdRb3-0003x0-H8; Tue, 09 May 2006 08:45:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdRb3-0003vu-2k for tcpm@ietf.org; Tue, 09 May 2006 08:45:49 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdRb0-0006wY-Mz for tcpm@ietf.org; Tue, 09 May 2006 08:45:49 -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 k49CjSld032740; Tue, 9 May 2006 05:45:32 -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 AC33777AB77; Tue, 9 May 2006 08:45:27 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 30DCB40A904; Tue, 9 May 2006 08:44:32 -0400 (EDT) To: "Armando L. Caro, Jr." From: Mark Allman Subject: Re: [tcpm] TCPx2 In-Reply-To: <445F8842.9080100@bbn.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Peaches MIME-Version: 1.0 Date: Tue, 09 May 2006 08:44:31 -0400 Message-Id: <20060509124432.30DCB40A904@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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="===============0187244387==" Errors-To: tcpm-bounces@ietf.org --===============0187244387== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > The parallel SYN idea is as follows. I understand your idea. I am not sure if I am ready to head quite down the path you are suggesting, however. First, it feels a bit gratuitous to fire two SYNs at once. At least we could caveat it by saying that a host should cache the peers ability to do TCPx2. But, even so, it sort of feels gratuitous to me. But, > 6. S receives TCPx2 ack to complete the TCPx2 3-way handshake, which > triggers it to upgrade its end of the TCP connection to TCPx2. This upgrading business is not sitting right in my head, I guess. Let me try an example. Let's say that TCPx2 has enough option space that we use some sort of spiffy authentication system for the connection [%]. But, TCP doesn't have enough option space and/or we don't want to burn a huge fraction of it on authentication because that will push out other options. So, we send TCP and TCPx2 SYNs as appropriate, get back a TCP SYN+ACK and fire an initial window of data. Now, we get the TCPx2 SYN+ACK and want to "upgrade". But, now we have already sent the first bits of the data unauthenticated. It seems like the stream ought to either be authenticated or not. Let me try this way of putting it .... I am not sure that your scheme always leaves the two ends of the connection "synchronized". If you added a small SYN+ACK collection delay (in the case when the TCP SYN+ACK arrives before the TCPx2 SYN+ACK arrives) then we could maybe just forget upgrades. But, it seems to me that this is roughly similar to just sending an x2 SYN first and then a bit later sending TCP SYN. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEYI6vWyrrWs4yIs4RAnWWAJ4s7vwSLa8f01NPnVRlfwCCk+vwIACfX9Sb Ei4BLAg0N5kevjRxn2hsqF8= =utWy -----END PGP SIGNATURE----- --=_bOundary-- --===============0187244387== 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 --===============0187244387==-- From tcpm-bounces@ietf.org Tue May 09 16:23:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdYjM-0001uC-RQ; Tue, 09 May 2006 16:22:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdYjL-0001u7-IW for tcpm@ietf.org; Tue, 09 May 2006 16:22:51 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdYjJ-0003hb-TF for tcpm@ietf.org; Tue, 09 May 2006 16:22:51 -0400 Received: from fgont ([201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k49KLxCG030531; Tue, 9 May 2006 17:22:09 -0300 Message-Id: <7.0.1.0.0.20060509013738.065e08a0@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 09 May 2006 01:42:52 -0300 To: mallman@icir.org, tcpm@ietf.org From: Fernando Gont Subject: Re: [tcpm] syn flooding draft In-Reply-To: <20060426195349.154653FBF1A@lawyers.icir.org> References: <20060413194810.GB2145@grc.nasa.gov> <20060426195349.154653FBF1A@lawyers.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Ted Faber , weddy@grc.nasa.gov X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 16:53 26/04/2006, Mark Allman wrote: >has been discussed a bit on the list. The vibe Ted and I have picked up >is that folks think its a good document to have around (even though >several folks have identified possible areas for improvement). So, >we're asking if folks think that TCPM should take on this document as a >WG item. As the document states, it's targeted as informational and a >guess at a timeframe (a WAG between Wes, Ted and I) is 6 months. > >If you think this ought to be on our plate (or not), please say so. >(Lack of positive response will meet with the same decision as an >overwhelmingly negative response.) SYN-flooding attacks have not yet been addressed in any RFC, so it would be interesting to have a document that describes the problem, the possible counter-measures, and their pros and cons. I think this draft should be adopted as a WG document. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue May 09 16:36:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdYwm-00075H-37; Tue, 09 May 2006 16:36:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdYwl-00075C-3K for tcpm@ietf.org; Tue, 09 May 2006 16:36:43 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdYwh-0004wa-Hv for tcpm@ietf.org; Tue, 09 May 2006 16:36:43 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060308/8.12.11) with ESMTP id k49Ka3rG007513; Tue, 9 May 2006 23:36:03 +0300 Date: Tue, 9 May 2006 23:36:03 +0300 (EEST) From: Pekka Savola To: Fernando Gont Subject: Re: [tcpm] syn flooding draft In-Reply-To: <7.0.1.0.0.20060509013738.065e08a0@gont.com.ar> Message-ID: References: <20060413194810.GB2145@grc.nasa.gov> <20060426195349.154653FBF1A@lawyers.icir.org> <7.0.1.0.0.20060509013738.065e08a0@gont.com.ar> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1451/Tue May 9 02:27:49 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: weddy@grc.nasa.gov, tcpm@ietf.org, Ted Faber , mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Tue, 9 May 2006, Fernando Gont wrote: > At 16:53 26/04/2006, Mark Allman wrote: >> has been discussed a bit on the list. The vibe Ted and I have picked up >> is that folks think its a good document to have around (even though >> several folks have identified possible areas for improvement). So, >> we're asking if folks think that TCPM should take on this document as a >> WG item. As the document states, it's targeted as informational and a >> guess at a timeframe (a WAG between Wes, Ted and I) is 6 months. >> >> If you think this ought to be on our plate (or not), please say so. >> (Lack of positive response will meet with the same decision as an >> overwhelmingly negative response.) > > SYN-flooding attacks have not yet been addressed in any RFC, so it would be > interesting to have a document that describes the problem, the possible > counter-measures, and their pros and cons. > > I think this draft should be adopted as a WG document. FWIW, I agree with this reasoning, and support the document going forward, as I said in last June: http://www1.ietf.org/mail-archive/web/tcpm/current/msg01331.html (I haven't re-checked since -00 whether the comments were addressed..) -- 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 May 09 17:00:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdZJj-0003Po-EQ; Tue, 09 May 2006 17:00:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdZJi-0003Pj-Gs for tcpm@ietf.org; Tue, 09 May 2006 17:00:26 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdZJh-0006D9-53 for tcpm@ietf.org; Tue, 09 May 2006 17:00:26 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k49L0OX11827; Tue, 9 May 2006 14:00:24 -0700 (PDT) (envelope-from fkastenholz@juniper.net) Received: from fkastenholzpc1.juniper.net (fkastenholzpc1.jnpr.net [172.28.36.185]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k49L0B595039; Tue, 9 May 2006 14:00:11 -0700 (PDT) (envelope-from fkastenholz@juniper.net) Message-Id: <6.2.1.2.2.20060509164415.0316e3c0@antipi> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 09 May 2006 16:59:34 -0400 To: mallman@icir.org, "Armando L. Caro, Jr." From: Frank Kastenholz Subject: middleboxes and Re: [tcpm] TCPx2 In-Reply-To: <20060509124432.30DCB40A904@lawyers.icir.org> References: <445F8842.9080100@bbn.com> <20060509124432.30DCB40A904@lawyers.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.1 (/) 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: , Errors-To: tcpm-bounces@ietf.org so i was thinking more about the tcpx2 idea and trying to make my notion of putting an option in the tcp(x1?) packet to make connection setup and x2-detection faster, etc etc. but it seems to me that the real problem is middleboxes _and_ the fact that routes can change in the network. suppose that, through any of the methods discussed, a tcp-x2 connection has been set up between A and B. For the sake of argument, suppose that the connection goes through some middlebox, M1 and that box understands tcpx2 and Does The Right Thing. Then the routes in the network change. the connection now goes through middlebox M2 (either instead of, or in addition to M1, it doesn't matter). And M2 is tcp-x2-challenged, so it zorches the tcpx2 packets... in other words, tcpx2 connections could suddenly go-away if/when it pleases the routing-and-middle-box-gods... (since tcpx2 calls itself a hack, here's a hack of a hack, cary tcpx2 in udp... it ought to be less likely to hit a middlebox that gets upset...) f _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue May 09 19:45:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdbsR-0007Ye-8D; Tue, 09 May 2006 19:44:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdbsP-0007YY-Qo for tcpm@ietf.org; Tue, 09 May 2006 19:44:25 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdbsN-0004zA-EJ for tcpm@ietf.org; Tue, 09 May 2006 19:44:25 -0400 Received: from [128.9.160.144] (nib.isi.edu [128.9.160.144]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k49NhbV11006; Tue, 9 May 2006 16:43:37 -0700 (PDT) Message-ID: <44612923.6030601@isi.edu> Date: Tue, 09 May 2006 16:43:31 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: mallman@icir.org Subject: Re: [tcpm] TCPx2 References: <20060508160526.2450D77AC74@guns.icir.org> In-Reply-To: <20060508160526.2450D77AC74@guns.icir.org> X-Enigmail-Version: 0.94.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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org I generally like this idea. I would like to REQUIRE a version number somewhere in here (preferably up front!), so that *when* we redefine the TCP header we don't need yet another protocol ID at the IP layer to indicate it. Joe Mark Allman wrote: > > Hi folks! > > I jotted out an i-d on an idea that has been rolling around my head for > a while. I submitted it, but until it pops out in the archive you can > slurp a copy here: > http://www.icir.org/mallman/draft-allman-tcpx2-hack-00.txt. The general > idea of this hack is to increase TCP's header size once to deal with > these field-foo-is-not-big-enough issues rather than trying to design > a solution for each of these. > > (As the document says, this is not a proposal for a TCPng.) > > So, crack open an adult beverage, take a look and let me know what you > think ... or, at least enjoy the read! :) > > allman > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue May 09 21:56:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FddvU-0001Mw-1d; Tue, 09 May 2006 21:55:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FddvT-0001LI-0e for tcpm@ietf.org; Tue, 09 May 2006 21:55:43 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FddvR-0001nT-Kp for tcpm@ietf.org; Tue, 09 May 2006 21:55:42 -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 k4A1tMBV046603; Tue, 9 May 2006 18:55:27 -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 AB3D077AC21; Tue, 9 May 2006 21:55:20 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id AD47F40AE1E; Tue, 9 May 2006 21:54:25 -0400 (EDT) To: Frank Kastenholz From: Mark Allman Subject: Re: middleboxes and Re: [tcpm] TCPx2 In-Reply-To: <6.2.1.2.2.20060509164415.0316e3c0@antipi> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: It's Still Rock and Roll to Me MIME-Version: 1.0 Date: Tue, 09 May 2006 21:54:25 -0400 Message-Id: <20060510015425.AD47F40AE1E@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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="===============1632602510==" Errors-To: tcpm-bounces@ietf.org --===============1632602510== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > so i was thinking more about the tcpx2 idea > and trying to make my notion of putting an option > in the tcp(x1?) packet to make connection setup and > x2-detection faster, etc etc. > > but it seems to me that the real problem is middleboxes > _and_ the fact that routes can change in the network. > > suppose that, through any of the methods discussed, a > tcp-x2 connection has been set up between A and B. > For the sake of argument, suppose that the connection goes > through some middlebox, M1 and that box understands tcpx2 > and Does The Right Thing. Then the routes in the network > change. the connection now goes through middlebox M2 > (either instead of, or in addition to M1, it doesn't matter). > And M2 is tcp-x2-challenged, so it zorches the tcpx2 packets... > in other words, tcpx2 connections could suddenly go-away > if/when it pleases the routing-and-middle-box-gods... Maybe I don't quite understand what I am supposed to take away from this thinking. I agree that this could happen. But, it's not like TCP(x1) is somehow invulnerable to this. If M1 and M2 are firewalls with different policies or they are stateful then a TCP(x1) connection could just as easily get zorched [*]. My mental model (for whatever that is worth) is that the sorts of middleboxes that would kill TCPx2 would be pretty close to the edge and not really particularly susceptible to routing changes. I.e., all the packets go through the enterprise firewall, no matter which path they arrived on. Or, all packets go through some NAT. Or, whatever. If AT&T has a route change and my packets go a different way they still end up at the firewall or the NAT. So, while I agree that the scenario you played out can happen, I am not sure I am all that compelled that it's a big deal. Should I be? > (since tcpx2 calls itself a hack, here's a hack of a hack, > cary tcpx2 in udp... it ought to be less likely to hit > a middlebox that gets upset...) I don't see how this helps. allman [*] Nice word! --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEYUfRWyrrWs4yIs4RAlyJAJwIGY07Tlb5BMhiV64Fdi+LAAE+swCfRiJZ mW92+e2YnzF5OC4V1O7WDBc= =vOoS -----END PGP SIGNATURE----- --=_bOundary-- --===============1632602510== 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 --===============1632602510==-- From tcpm-bounces@ietf.org Wed May 10 09:42:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdox0-0007jc-R1; Wed, 10 May 2006 09:42:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdowz-0007jX-Jt for tcpm@ietf.org; Wed, 10 May 2006 09:42:01 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdowz-0006Kf-7T for tcpm@ietf.org; Wed, 10 May 2006 09:42:01 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k4ADg0X38470; Wed, 10 May 2006 06:42:00 -0700 (PDT) (envelope-from fkastenholz@juniper.net) Received: from fkastenholzpc1.juniper.net (fkastenholzpc1.jnpr.net [172.28.36.185]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k4ADfs585864; Wed, 10 May 2006 06:41:55 -0700 (PDT) (envelope-from fkastenholz@juniper.net) Message-Id: <6.2.1.2.2.20060510091927.0344eca0@antipi> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 10 May 2006 09:37:12 -0400 To: mallman@icir.org From: Frank Kastenholz Subject: Re: middleboxes and Re: [tcpm] TCPx2 In-Reply-To: <20060510015425.AD47F40AE1E@lawyers.icir.org> References: <6.2.1.2.2.20060509164415.0316e3c0@antipi> <20060510015425.AD47F40AE1E@lawyers.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.1 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 09:54 PM 5/9/2006, Mark Allman wrote: >> so i was thinking more about the tcpx2 idea >> and trying to make my notion of putting an option >> in the tcp(x1?) packet to make connection setup and >> x2-detection faster, etc etc. >> >> but it seems to me that the real problem is middleboxes >> _and_ the fact that routes can change in the network. >> >> suppose that, through any of the methods discussed, a >> tcp-x2 connection has been set up between A and B. >> For the sake of argument, suppose that the connection goes >> through some middlebox, M1 and that box understands tcpx2 >> and Does The Right Thing. Then the routes in the network >> change. the connection now goes through middlebox M2 >> (either instead of, or in addition to M1, it doesn't matter). >> And M2 is tcp-x2-challenged, so it zorches the tcpx2 packets... >> in other words, tcpx2 connections could suddenly go-away >> if/when it pleases the routing-and-middle-box-gods... > >Maybe I don't quite understand what I am supposed to take away from this >thinking. I agree that this could happen. But, it's not like TCP(x1) >is somehow invulnerable to this. If M1 and M2 are firewalls with >different policies or they are stateful then a TCP(x1) connection could >just as easily get zorched [*]. I'm not sure either. That said, I do think that the odds of losing a connection because of a routing change would be much higher if the connection was using TCPx2 than if using x1 (though I can't prove it). Obviously, if M1/M2 are stateful middleboxes, there would be a probelm, even if M1 and M2 support the tcp-flavor-du-jour (assuming that the state is not soft or that M1 and M2 are not conspiring in some way). I think that the most likely failure mode would be that the routes change, the packets go through a new AS, and that new AS has different policies as to what they do and do not let into/through their network. This is most likely not a problem with TCPx1 -- ISPs, etc, do not usually filter transit/etc traffic based on TCP port numbers or the like -- but they might/do filter based on IP protocol number... (hence, my "stick it in UDP" comment). Policies, software revisions, and so on at the edges of the ultimate destination are probably less of an issue. Yes, many companies, etc, are multihomed for reliability, but often what happens is that both of their net-facing connections come in to an "unprotected" net which is connected to the internal nets via firewall/nat/... >So, while I agree that the scenario you >played out can happen, I am not sure I am all that compelled that it's a >big deal. Should I be? If TCPx2 is a good idea/etc, then I think that this really comes down to a deployment/migration/transition issue, the same as with IPv4/6. I would suggest that (again, if this goes forward) that there be some documentation that says "these are the issues that could occur in deployment/migration... be aware, etc, etc" I do _not_ think it's a reason to give up on tcpx2. >> (since tcpx2 calls itself a hack, here's a hack of a hack, >> cary tcpx2 in udp... it ought to be less likely to hit >> a middlebox that gets upset...) > >I don't see how this helps. One of the filter-terms that occurs is something along the lines of switch (ip-protocol) case tcp: allow case udp: allow case some-other-known-ip-protocols: allow default: drop the idea is that if the administrators of the network do not know what the ip-protocol is, it must be an attack or security problem, etc, so it should be dropped... so _if_ tcpx2 was carried in udp, it would more likely be allowed through (the assumption is that the udp case in the example does not further go and look at port numbers... which it may well do... sigh) >[*] Nice word! i wish i could take credit :-) f _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed May 10 09:51:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdp6J-00039B-AS; Wed, 10 May 2006 09:51:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdp6H-00038o-Qq for tcpm@ietf.org; Wed, 10 May 2006 09:51:37 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdp6G-0006kf-JK for tcpm@ietf.org; Wed, 10 May 2006 09:51:37 -0400 Received: from lion.bbn.com ([128.89.80.73]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Fdp6E-0006s8-3t; Wed, 10 May 2006 09:51:34 -0400 Message-ID: <4461EFE6.1080508@bbn.com> Date: Wed, 10 May 2006 09:51:34 -0400 From: "Armando L. Caro, Jr." User-Agent: Mail/News 1.5 (X11/20060210) MIME-Version: 1.0 To: mallman@icir.org Subject: Re: [tcpm] TCPx2 References: <20060509124432.30DCB40A904@lawyers.icir.org> In-Reply-To: <20060509124432.30DCB40A904@lawyers.icir.org> X-Enigmail-Version: 0.94.0.0 OpenPGP: id=A9CE816E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Mark Allman wrote: >> The parallel SYN idea is as follows. > > I understand your idea. I am not sure if I am ready to head quite down > the path you are suggesting, however. > This upgrading business is not sitting right in my head, I guess. Let > me try an example. Let's say that TCPx2 has enough option space that we > use some sort of spiffy authentication system for the connection [%]. > But, TCP doesn't have enough option space and/or we don't want to burn a > huge fraction of it on authentication because that will push out other > options. So, we send TCP and TCPx2 SYNs as appropriate, get back a TCP > SYN+ACK and fire an initial window of data. Now, we get the TCPx2 > SYN+ACK and want to "upgrade". But, now we have already sent the first > bits of the data unauthenticated. It seems like the stream ought to > either be authenticated or not. > > Let me try this way of putting it .... I am not sure that your scheme > always leaves the two ends of the connection "synchronized". Well the TCPx2 endpoints would require more state. The initial window of data will be acked as TCP (not TCPx2) data. Even the though the sender has upgraded to TCPx2, it knows that the first window of data was sent with TCP, and thus accepts the acks for the initial window only. I admit it seems to be getting messy, but I don't think it's all that bad. The main problem I see is security. It may become easy to hijack a connection. > If you added a small SYN+ACK collection delay (in the case when the TCP > SYN+ACK arrives before the TCPx2 SYN+ACK arrives) then we could maybe > just forget upgrades. Yes, that might be a useful enough solution. > But, it seems to me that this is roughly similar > to just sending an x2 SYN first and then a bit later sending TCP SYN. Yes, similar... but not the same as waiting for the TCPx2 syn to timeout before sending a TCP syn. -- Armando www.armandocaro.net _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed May 10 10:12:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdpQZ-0002CI-34; Wed, 10 May 2006 10:12:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdpQW-0002Au-Db for tcpm@ietf.org; Wed, 10 May 2006 10:12:32 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdpQW-0007R1-C8 for tcpm@ietf.org; Wed, 10 May 2006 10:12:32 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FdpPo-0004dj-HT for tcpm@ietf.org; Wed, 10 May 2006 10:11:51 -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 k4AEBkul061544; Wed, 10 May 2006 07:11:47 -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 9DB9577AC74; Wed, 10 May 2006 10:11:45 -0400 (EDT) To: Frank Kastenholz From: Mark Allman Subject: Re: middleboxes and Re: [tcpm] TCPx2 In-Reply-To: <6.2.1.2.2.20060510091927.0344eca0@antipi> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: It's Good to Be King MIME-Version: 1.0 Date: Wed, 10 May 2006 10:11:45 -0400 Message-Id: <20060510141145.9DB9577AC74@guns.icir.org> X-Spam-Score: -2.6 (--) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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="===============0001918625==" Errors-To: tcpm-bounces@ietf.org --===============0001918625== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > I think that the most likely failure mode would be > that the routes change, the packets go through a new AS, and > that new AS has different policies as to what they do and > do not let into/through their network. This is most likely > not a problem with TCPx1 -- ISPs, etc, do not usually > filter transit/etc traffic based on TCP port numbers or > the like -- but they might/do filter based on IP protocol > number... (hence, my "stick it in UDP" comment). I guess my mental model is that transit traffic is not filtered like this. So, my intuition is that this is all theoretical. But, I have no data. I wonder if any of the SCTP or DCCP folk have experience with running tests across the Internet that were impacted by filtering that was not near the edge. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEYfShWyrrWs4yIs4RAvnuAJ49BKibGxtpcqAlyXpzzps5r4rODwCdHDBw /cKAWjr9odw7d4qcyyWUjUk= =4cfd -----END PGP SIGNATURE----- --=_bOundary-- --===============0001918625== 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 --===============0001918625==-- From tcpm-bounces@ietf.org Wed May 10 10:35:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdpmS-0003oM-Bk; Wed, 10 May 2006 10:35:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdpmR-0003oH-3i for tcpm@ietf.org; Wed, 10 May 2006 10:35:11 -0400 Received: from nz-out-0102.google.com ([64.233.162.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdpmP-0000Nh-SE for tcpm@ietf.org; Wed, 10 May 2006 10:35:11 -0400 Received: by nz-out-0102.google.com with SMTP id i28so1774173nzi for ; Wed, 10 May 2006 07:35:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IzPNiveJn6Y7xBjorgTwrgCf8G1fclci43ZEYHnd1QbTcZ1e/AuczY1+0EEdHbkl+iUfSq4c3Fz7thxR8n9tGHR4LsdIWnQJgQgEglLmomRVk8WGk2r71OdrtluUJUSAI76LegMe4VNXrknHg4x9l9VamKr9DVTeJtz1VE21k9Q= Received: by 10.36.135.7 with SMTP id i7mr724049nzd; Wed, 10 May 2006 07:35:08 -0700 (PDT) Received: by 10.36.34.10 with HTTP; Wed, 10 May 2006 07:35:08 -0700 (PDT) Message-ID: <530c5af60605100735m419f9ff1n5e7129bb2e4a166c@mail.gmail.com> Date: Wed, 10 May 2006 16:35:08 +0200 From: "Andrew Yourtchenko" To: "Frank Kastenholz" Subject: Re: middleboxes and Re: [tcpm] TCPx2 In-Reply-To: <6.2.1.2.2.20060510091927.0344eca0@antipi> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <6.2.1.2.2.20060509164415.0316e3c0@antipi> <20060510015425.AD47F40AE1E@lawyers.icir.org> <6.2.1.2.2.20060510091927.0344eca0@antipi> X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: tcpm@ietf.org, mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org > so _if_ tcpx2 was carried in udp, it would more likely > be allowed through (the assumption is that the > udp case in the example does not further go and > look at port numbers... which it may well do... sigh) ...And then you have the NAT middleboxes coming into the picture and it will become quite a fun to make this work reliably, taking into the account the simultaneous open scenario as well. (Essentially you'd be creating an overlay - but then why not simply create an overlay and do IPv6 over it - that's something that is already there) Now I put my aluminium hat on (just in case) and continue writing... If going the road of hacks, why not just grab the special case of srcport=3Ddstport=3D0 from the TCPx1 (32 bits wasted - tunneling over UDP wastes 64 bits, right ?), and reuse the remaining fields in the TCP header, keeping some of the data (TCP flags) in the same place, and adding the other ones ? This would provide a very clear special-case for the middleboxes and the end hosts, and allow some of the existing features (e.g. ACLs with TCP flags) to immediately work on a rudimentary scale (controlling the inbound/outboud x2 overall access). Since there's technically no new protocol being defined, to me this kind of hack looks like something possible - it looks like the most evolutionary hack of the ones at hand. (But I still keep my aluminium hat on for a while :-) thanks, andrew _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed May 10 11:17:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdqQf-0002fq-4Z; Wed, 10 May 2006 11:16:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdqQd-0002fg-S2 for tcpm@ietf.org; Wed, 10 May 2006 11:16:43 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdqQa-00024w-Fa for tcpm@ietf.org; Wed, 10 May 2006 11:16:43 -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 k4AFGXh6063500; Wed, 10 May 2006 08:16:33 -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 778FA77AC74; Wed, 10 May 2006 11:16:32 -0400 (EDT) To: "Andrew Yourtchenko" From: Mark Allman Subject: Re: middleboxes and Re: [tcpm] TCPx2 In-Reply-To: <530c5af60605100735m419f9ff1n5e7129bb2e4a166c@mail.gmail.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: It's Good to Be King MIME-Version: 1.0 Date: Wed, 10 May 2006 11:16:32 -0400 Message-Id: <20060510151632.778FA77AC74@guns.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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="===============1558401478==" Errors-To: tcpm-bounces@ietf.org --===============1558401478== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > ...And then you have the NAT middleboxes coming into the picture and > it will become quite a fun to make this work reliably, I doubt it. But, let's step back for a moment... (1) This problem is for routing changes in the middle of a connection causing a connection to be lost. That's a very narrow box. (a) Routing is stable on the timescales of most connections. I.e., it would be quite rare that packets would even travel along two paths, let alone be impacted by that change. (b) It's not clear that a change in routing in the middle of the network is going to represent a change in policy with regards to which IP protocol numbers are passed and which are not. The middleboxes that matter are highly likely to be near the endpoints. (2) Are we really saying that in 2006 that one of our engineering constraints is that the IP protocol number must be 6 or 17 in order to sneak by the middleboxes? (3) It's not like this hack of srcport=dstport=0 solves the problem of middleboxes with regards to TCPx2. NATs still have to understand the structure of the header such that all connections aren't muxed together into a big mess. Firewalls still have to figure out where the port number is to enforce policy (I somehow doubt they'll just pass all port 0 traffic). (4) TCP connections can get toasted today. The network can go down. The routing can start looping. The remote host can crash or the application go away. I am fine with saying that TCPx2 + routing changes + policy changes can be another way that a TCP connection can get toasted. But, let's not make it a bigger deal than it is. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEYgPQWyrrWs4yIs4RAnBSAJ9cxLBf/oQA0whMMUf3DEWTC0JMIACeK2hL F+DXsp5tZfQLa56DsJ5FPNc= =XJwJ -----END PGP SIGNATURE----- --=_bOundary-- --===============1558401478== 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 --===============1558401478==-- From tcpm-bounces@ietf.org Wed May 10 11:48:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdqvF-0002yr-UW; Wed, 10 May 2006 11:48:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdqvF-0002ym-Mj for tcpm@ietf.org; Wed, 10 May 2006 11:48:21 -0400 Received: from dsl092-066-146.bos1.dsl.speakeasy.net ([66.92.66.146] helo=alva.home) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdqvE-00034b-CL for tcpm@ietf.org; Wed, 10 May 2006 11:48:21 -0400 Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1FdqvA-0001j6-00; Wed, 10 May 2006 11:48:16 -0400 From: Tim Shepard To: mallman@icir.org Subject: alternatives for the future (was Re: middleboxes and Re: [tcpm] TCPx2 ) In-reply-to: Your message of Wed, 10 May 2006 10:11:45 -0400. <20060510141145.9DB9577AC74@guns.icir.org> Date: Wed, 10 May 2006 11:48:16 -0400 Message-Id: X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org It seems to me that perhaps keeping the initial connection setup the same with TCP is a good plan. To give us breathing room, there are two things that I like: One would be a "I am modern and clueful, and hope you are too (IAMACAHYAT)." option that can be sent on the initial SYN and the SYN/ACK. Once this option has been exchanged (with the SackOK and Timestamp and windowscale which also go on the initial SYN, then more interesting and elaborate things can be negotiated on the fly with TCP options in later round trips. Whenever I go looking for space in the TCP header, I keep noticing the 16 bits of urgent pointer. And in my fantasies for using contact names instead of port numbers, I want to find some way to pass an argv-like array of strings in the initial SYN. I've also at various times wanted an option on the initial TCP SYN that says: 1. "I can migrate this TCP connection to SCTP if you like." 2. "I would like to establish shim6 state for this." 3. "I'd like to do HIP with you, can you do HIP?" (which would be an implied HIP I1 message) What would be the general mechanism that we can squeeze into the exiting remaining TCP option space that will enable us to do the right thing 5 to 10 years from now when we figure out what the right thing is, and then when we figure out what the next right thing is 15 to 20 years from now, do that too, all without running out of space in the option space on the initial TCP SYN? I also wonder if we should be thinking about an SCTP migration plan (where applications that think they are doing TCP are actually being carried by SCTP in TCP-emulation mode). I can imagine that getting to a future (in say 20 years) in which TCP was strictly legacy might be a good thing. -Tim Shepard shep@alum.mit.edu _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed May 10 12:06:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdrCm-0005F0-RE; Wed, 10 May 2006 12:06:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdrCl-0005Ev-He for tcpm@ietf.org; Wed, 10 May 2006 12:06:27 -0400 Received: from dsl092-066-146.bos1.dsl.speakeasy.net ([66.92.66.146] helo=alva.home) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdrCk-0003ps-9S for tcpm@ietf.org; Wed, 10 May 2006 12:06:27 -0400 Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1FdrCb-0001k0-00; Wed, 10 May 2006 12:06:17 -0400 From: Tim Shepard To: "Andrew Yourtchenko" Subject: Re: middleboxes and Re: [tcpm] TCPx2 In-reply-to: Your message of Wed, 10 May 2006 16:35:08 +0200. <530c5af60605100735m419f9ff1n5e7129bb2e4a166c@mail.gmail.com> Date: Wed, 10 May 2006 12:06:17 -0400 Message-Id: X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: tcpm@ietf.org, mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org > If going the road of hacks, why not just grab the special case of > srcport=dstport=0 from the TCPx1 (32 bits wasted - tunneling over I've been thinking that dstport==0 should mean something special, where the receiver of such a packet looks in the data for the information about what service is being contacted, and assigns a port number and the SYN/ACK comes back with the srcport filled in by whatever the responder wishes to have in there for demultiplexing purposes. If there's a "Full cone NAT" or a "Restricted cone NAT" in the middle it should work just fine (since the packet coming back has a dstport that the NAT assigned). dstport==0 could also convey an implied "I am modern and clueful and hope you are too. (IAMACAHYAT)" option. -Tim Shepard shep@alum.mit.edu _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed May 10 12:12:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdrIr-0008I3-Tn; Wed, 10 May 2006 12:12:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdrIr-0008HC-Bc for tcpm@ietf.org; Wed, 10 May 2006 12:12:45 -0400 Received: from nz-out-0102.google.com ([64.233.162.198]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdrIo-00044v-3G for tcpm@ietf.org; Wed, 10 May 2006 12:12:45 -0400 Received: by nz-out-0102.google.com with SMTP id i28so1800154nzi for ; Wed, 10 May 2006 09:12:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Y1TaEY0UUjQuaKOjnb2zvPd7v1bJ+RwDqxWSa8Fdl/l3v4ZEpAH+jghwBGGhStyg5LidPt+bleWtuztzzV37DhbO5TTbH7Yfq31z3ZDvTA2u3RfN+TZ43nBS43quI/niERqqoBZDGQJ+fxjmrC/GcXk1CnQfnT7ukuQOFTEKcdE= Received: by 10.36.34.3 with SMTP id h3mr286019nzh; Wed, 10 May 2006 09:12:41 -0700 (PDT) Received: by 10.36.34.10 with HTTP; Wed, 10 May 2006 09:12:41 -0700 (PDT) Message-ID: <530c5af60605100912k77d3ddd9kd1ffd1a9fc3d516e@mail.gmail.com> Date: Wed, 10 May 2006 18:12:41 +0200 From: "Andrew Yourtchenko" To: mallman@icir.org Subject: Re: middleboxes and Re: [tcpm] TCPx2 In-Reply-To: <20060510151632.778FA77AC74@guns.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <530c5af60605100735m419f9ff1n5e7129bb2e4a166c@mail.gmail.com> <20060510151632.778FA77AC74@guns.icir.org> 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: , Errors-To: tcpm-bounces@ietf.org > > (1) This problem is for routing changes in the middle of a connection > causing a connection to be lost. That's a very narrow box. > > (a) Routing is stable on the timescales of most connections. I.e., > it would be quite rare that packets would even travel along two > paths, let alone be impacted by that change. > > (b) It's not clear that a change in routing in the middle of the > network is going to represent a change in policy with regards to > which IP protocol numbers are passed and which are not. The > middleboxes that matter are highly likely to be near the > endpoints. ....And in the end of the day it is the responsibility of those designing that part of the network where the routing change would occur - I'd expect it to be within the same administrative domain. If a routing flip causes the alteration of the active security policy applied to the traffic - there's very probably something to fix even without the x2. > > (2) Are we really saying that in 2006 that one of our engineering > constraints is that the IP protocol number must be 6 or 17 in order > to sneak by the middleboxes? No. I just enclosed this hack to oppose the tunneling over UDP :-) > > (3) It's not like this hack of srcport=3Ddstport=3D0 solves the problem o= f > middleboxes with regards to TCPx2. NATs still have to understand > the structure of the header such that all connections aren't muxed > together into a big mess. Firewalls still have to figure out where > the port number is to enforce policy (I somehow doubt they'll just > pass all port 0 traffic). Absolutely. But again it was mostly just a counter-example vs. tunneling over UDP - both approaches share pretty much the same drawbacks. If we were to do the sneaky tunneling, I think that sneakily tunneling IPv6 and doing all the rest cleanly on top of it is a better approach. Or do it "openly" within the new protocol as you suggest. I was not against the new protocol number - but rather was sceptical about doing the tunneling over the UDP. Sorry I did not state it clearer. thanks, andrew _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed May 10 12:17:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdrMk-0003KQ-7z; Wed, 10 May 2006 12:16:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdrMi-0003KC-Rh for tcpm@ietf.org; Wed, 10 May 2006 12:16:44 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdqVs-0002Ab-A3 for tcpm@ietf.org; Wed, 10 May 2006 11:22:08 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FdqKx-0005J2-95 for tcpm@ietf.org; Wed, 10 May 2006 11:10:52 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4AFAFV06159; Wed, 10 May 2006 08:10:15 -0700 (PDT) Message-ID: <44620251.9000704@isi.edu> Date: Wed, 10 May 2006 08:10:09 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Andrew Yourtchenko Subject: Re: middleboxes and Re: [tcpm] TCPx2 References: <6.2.1.2.2.20060509164415.0316e3c0@antipi> <20060510015425.AD47F40AE1E@lawyers.icir.org> <6.2.1.2.2.20060510091927.0344eca0@antipi> <530c5af60605100735m419f9ff1n5e7129bb2e4a166c@mail.gmail.com> In-Reply-To: <530c5af60605100735m419f9ff1n5e7129bb2e4a166c@mail.gmail.com> X-Enigmail-Version: 0.94.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: -2.6 (--) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: tcpm@ietf.org, mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Andrew Yourtchenko wrote: ... > If going the road of hacks, why not just grab the special case of > srcport=dstport=0 from the TCPx1 (32 bits wasted - tunneling over > UDP wastes 64 bits, right ?), and reuse the remaining fields in the > TCP header, keeping some of the data (TCP flags) in the same place, > and adding the other ones ? Port numbers are reserved by IANA only insofar as they have global, shared meaning. Between any two hosts - which is ultimately the only place they really mean anything - they can be defined in any way mutually agreed. First, srcport=0 is consistent with IANA use anyway, so that's not needed. But dstport=0 is just not reserved; it can be used by existing services at the discretion of the endpoints anyway. Redefining the ports redefines the service within TCP; it cannot redefine the header. That would take a version field - as I suggested yesterday - which has (sadly) always been lacking in TCP (and UDP). Finally, any flag or field that redefines the behavior of middleboxes is equivalent from a deployment perspective; they require middlebox reprogramming to work. Once reprogramming is required, we're debating lines of code, and I don't think it matters much whether we're parsing the header for oddly placed fields or double-length fields at that point. There may be easier ways to extend the TCP header if all we want is option space. The need for more portspace isn't convincingly motiviated yet - if for security, it's thin at best. If for increased numbers of concurrent connections, showing a need would be useful. In summary, this seems like a fine experiment, but so would a simpler mod that just extended the option space. The latter might end up being preferable w.r.t. middleboxes, aren't options are typically ignored by middleboxes anyway? Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed May 10 12:20:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdrPz-0005Wk-8O; Wed, 10 May 2006 12:20:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdrPx-0005Wf-UO for tcpm@ietf.org; Wed, 10 May 2006 12:20:05 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdrPv-0004Pw-M8 for tcpm@ietf.org; Wed, 10 May 2006 12:20:05 -0400 Received: from lion.bbn.com ([128.89.80.73]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FdrPt-0000PK-4L; Wed, 10 May 2006 12:20:01 -0400 Message-ID: <446212B1.10209@bbn.com> Date: Wed, 10 May 2006 12:20:01 -0400 From: "Armando L. Caro, Jr." User-Agent: Mail/News 1.5 (X11/20060210) MIME-Version: 1.0 To: Tim Shepard Subject: Re: alternatives for the future (was Re: middleboxes and Re: [tcpm] TCPx2 ) References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 OpenPGP: id=A9CE816E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Tim Shepard wrote: > What would be the general mechanism that we can squeeze into the > exiting remaining TCP option space that will enable us to do the > right thing 5 to 10 years from now when we figure out what the > right thing is, and then when we figure out what the next right > thing is 15 to 20 years from now, do that too, all without > running out of space in the option space on the initial TCP SYN? I think you are proposing a good problem to be solved... I think you're initial idea is basically that TCP eventually evolves into a protocol to negotiate which protocol to use. Right? > I also wonder if we should be thinking about an SCTP migration > plan (where applications that think they are doing TCP are > actually being carried by SCTP in TCP-emulation mode). Ryan Bickhart developed a shim that does do this, but it doesn't negotiate options... it does basically the same thing Mark originally suggested for TCPx2. Start by trying to initiate a SCTP connection, if no response, then try TCP. The shim allows the endpoints to use SCTP even if the app only knows TCP. No app code modification required. http://www.cis.udel.edu/~amer/PEL/poc/pdf/BickhartMSthesis.pdf > I can > imagine that getting to a future (in say 20 years) in which TCP > was strictly legacy might be a good thing. But I think you're initial idea is basically that TCP eventually evolves into a protocol that is only used to negotiate which protocol to actually use for data transfer. -- Armando www.armandocaro.net _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed May 10 13:07:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fds9k-0000eJ-Mg; Wed, 10 May 2006 13:07:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fds9g-0000ZF-UR for tcpm@ietf.org; Wed, 10 May 2006 13:07:20 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdrxe-0006mj-Bk for tcpm@ietf.org; Wed, 10 May 2006 12:54:54 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4AGrjV02842; Wed, 10 May 2006 09:53:45 -0700 (PDT) Message-ID: <44621A94.8000103@isi.edu> Date: Wed, 10 May 2006 09:53:40 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Tim Shepard Subject: Re: middleboxes and Re: [tcpm] TCPx2 References: In-Reply-To: X-Enigmail-Version: 0.94.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: b19722fc8d3865b147c75ae2495625f2 Cc: tcpm@ietf.org, mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Tim Shepard wrote: >> If going the road of hacks, why not just grab the special case of >> srcport=dstport=0 from the TCPx1 (32 bits wasted - tunneling over > > I've been thinking that dstport==0 should mean something special, > where the receiver of such a packet looks in the data for the > information about what service is being contacted, and assigns a port > number and the SYN/ACK comes back with the srcport filled in by > whatever the responder wishes to have in there for demultiplexing > purposes. TCPMUX (on dstport==1) puts the service name in the data portion; the trouble with that is described in the portname doc. That doc also discusses the utility of late-binding, which seems more trouble than it's worth (sec 4.4). > If there's a "Full cone NAT" or a "Restricted cone NAT" in the > middle it should work just fine (since the packet coming back has a > dstport that the NAT assigned). It may work for the NAT (though I'm still not clear on that), but the endpoint then needs to match the SYN/ACK to the original SYN too. > dstport==0 could also convey an implied "I am modern and clueful and > hope you are too. (IAMACAHYAT)" option. All it says is that dstport==0. If you want a clue-bit, use one of the reserved header bits, please. It indicates clue in the protocol _and_ the designer, IMO ;-)) Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed May 10 13:43:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdsi9-0007o6-1t; Wed, 10 May 2006 13:42:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdsi7-0007nt-K9 for tcpm@ietf.org; Wed, 10 May 2006 13:42:55 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdrxH-0006k4-R4 for tcpm@ietf.org; Wed, 10 May 2006 12:54:31 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FdrYD-0006KW-6B for tcpm@ietf.org; Wed, 10 May 2006 12:28:38 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4AGRTV25835; Wed, 10 May 2006 09:27:29 -0700 (PDT) Message-ID: <4462146C.6020007@isi.edu> Date: Wed, 10 May 2006 09:27:24 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Tim Shepard Subject: Re: alternatives for the future (was Re: middleboxes and Re: [tcpm] TCPx2 ) References: In-Reply-To: X-Enigmail-Version: 0.94.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: -2.6 (--) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: tcpm@ietf.org, mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Tim Shepard wrote: > It seems to me that perhaps keeping the initial connection setup > the same with TCP is a good plan. > > To give us breathing room, there are two things that I like: > > One would be a "I am modern and clueful, and hope you are too > (IAMACAHYAT)." option that can be sent on the initial SYN and > the SYN/ACK. Once this option has been exchanged (with the > SackOK and Timestamp and windowscale which also go on the initial > SYN, then more interesting and elaborate things can be negotiated > on the fly with TCP options in later round trips. That's the problem - there are too many options that want to be in the first RTT, including (e.g.) authentication, SACK, timestamp, and windowscale (at a minimum) - not to mention portnames ;-) Having a larger option space would be useful to that end. The constraints of a new, larger option space would be like that designed in portnames - positive ACK, with the suggestion that if it fails, a backoff to the smaller option space is used. > Whenever I go looking for space in the TCP header, I keep > noticing the 16 bits of urgent pointer. There's the rub - a feature you think is largely unused that can be used for your purposes. Those tables turn fast, where your definition will be redefined out from under you. Let's not do that, please. ;-) > And in my fantasies for using contact names instead of port > numbers, I want to find some way to pass an argv-like array of > strings in the initial SYN. See portnames ;-) Once you have a string, you can parse them however you want. > I've also at various times wanted an option on the initial TCP > SYN that says: > > 1. "I can migrate this TCP connection to SCTP if you like." Er, there's NO reason to use one protocol to negotiate another. Send two SYNs and move on. > 2. "I would like to establish shim6 state for this." Seems like you need shim6 before the SYN can reach its dest. You're trying to fold network state establishment with transport establishment. While that's admirable from a latency viewpoint, it's a bit nonsensical IMO. > 3. "I'd like to do HIP with you, can you do HIP?" > (which would be an implied HIP I1 message) See #2, or at least that's what it seems like. > What would be the general mechanism that we can squeeze into the > exiting remaining TCP option space that will enable us to do the > right thing 5 to 10 years from now when we figure out what the > right thing is, and then when we figure out what the next right > thing is 15 to 20 years from now, do that too, all without > running out of space in the option space on the initial TCP SYN? > > I also wonder if we should be thinking about an SCTP migration > plan (where applications that think they are doing TCP are > actually being carried by SCTP in TCP-emulation mode). I can > imagine that getting to a future (in say 20 years) in which TCP > was strictly legacy might be a good thing. There's no reason to migrate to SCTP any more than there is to migrate to DCCP (since many TCP apps don't actually need reliability). The application gets to decide that. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed May 10 14:11:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdt9h-0002fI-GQ; Wed, 10 May 2006 14:11:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdt9g-0002fD-9r for tcpm@ietf.org; Wed, 10 May 2006 14:11:24 -0400 Received: from dsl092-066-146.bos1.dsl.speakeasy.net ([66.92.66.146] helo=alva.home) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdt9d-0001Xm-Pd for tcpm@ietf.org; Wed, 10 May 2006 14:11:24 -0400 Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1Fdt9R-0001pn-00; Wed, 10 May 2006 14:11:09 -0400 From: Tim Shepard To: "Armando L. Caro, Jr." Subject: Re: alternatives for the future (was Re: middleboxes and Re: [tcpm] TCPx2 ) In-reply-to: Your message of Wed, 10 May 2006 12:20:01 -0400. <446212B1.10209@bbn.com> Date: Wed, 10 May 2006 14:11:09 -0400 Message-Id: X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org > I think you are proposing a good problem to be solved... > I think you're initial idea is basically that TCP eventually evolves > into a protocol to negotiate which protocol to use. Right? Sure, I think that's an OK way to think about it, with emphasis on the word *eventually*. > Ryan Bickhart developed a shim that does do this, but it doesn't > negotiate options... it does basically the same thing Mark originally > suggested for TCPx2. Start by trying to initiate a SCTP connection, if > no response, then try TCP. The shim allows the endpoints to use SCTP > even if the app only knows TCP. No app code modification required. Fine. But it'd be nice to eliminate needless round-trip latencies. Sending an old-TCP SYN and a new-fangled-TCP SYN in parallel seems messy to me. It'd be nice to find a way to succinctly say everything that needs to be said in the first half of the first round trip time in a single packet, and have the second half of the first round trip time involve a single return packet. Schemes involving DOS resistance often turn the original exchange around so that the responder can be stateless. (I first learned of this sort of scheme in HIP, but there are other examples.) So something which is both a plain old TCP SYN with an option saying "If you do the more-modern-and-better thing, please initiate that with me." might be the right thing. The problem is that we've got a long list of candidates for what the more-modern-and-better thing might be: BTNS, MOBIKE, SHIM6, HIP, SCTP, etc... (and I apologize if I forgot to include your favorite new-fangled end-to-end protocol). I expect that for many years we will have a list of contenders with more than one entry. So maybe the initial option on the SYN should carry a bit vector or a list of bytes indicating which new-fangled protocols are supported by the initiator. But I don't like how complicated this is getting. -Tim Shepard shep@alum.mit.edu _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed May 10 14:26:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdtOB-0005vh-Sn; Wed, 10 May 2006 14:26:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdtOA-0005vc-O2 for tcpm@ietf.org; Wed, 10 May 2006 14:26:22 -0400 Received: from dsl092-066-146.bos1.dsl.speakeasy.net ([66.92.66.146] helo=alva.home) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdtOA-0002RQ-EF for tcpm@ietf.org; Wed, 10 May 2006 14:26:22 -0400 Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1FdtO2-0001qr-00; Wed, 10 May 2006 14:26:14 -0400 From: Tim Shepard To: Joe Touch Subject: Re: alternatives for the future (was Re: middleboxes and Re: [tcpm] TCPx2 ) In-reply-to: Your message of Wed, 10 May 2006 09:27:24 -0700. <4462146C.6020007@isi.edu> Date: Wed, 10 May 2006 14:26:14 -0400 Message-Id: X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: tcpm@ietf.org, mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org > > And in my fantasies for using contact names instead of port > > numbers, I want to find some way to pass an argv-like array of > > strings in the initial SYN. > > See portnames ;-) Once you have a string, you can parse them however you > want. > I liked the portnames draft, except for the fact that the strings would be constrained to be way too short. (In the version of the portnames draft that I read, you neglected the SackOK option which reduces the possible length of the strings by another two bytes.) > > I've also at various times wanted an option on the initial TCP > > SYN that says: > > > > 1. "I can migrate this TCP connection to SCTP if you like." > > Er, there's NO reason to use one protocol to negotiate another. Send two > SYNs and move on. It may be simpler to send a single packet (with an advertisement of willingness to do something else instead). Off list someone proposed to me that a returning RST with options carrying the beginnings of a turned-around 3-way handshake might be done. This avoids extra packets, avoids extra round trips, and avoids extra state for connections that will be abandoned. > > 2. "I would like to establish shim6 state for this." > > Seems like you need shim6 before the SYN can reach its dest. Uh, no. Have a look at how shim6 works. > You're > trying to fold network state establishment with transport establishment. > While that's admirable from a latency viewpoint, it's a bit nonsensical IMO. I'm no layerist, and I'm unlikely ever to be converted to the layerist faith. Latency matters. Layerism is just dogma. > > 3. "I'd like to do HIP with you, can you do HIP?" > > (which would be an implied HIP I1 message) > > See #2, or at least that's what it seems like. Yep, it's similar to #2. > There's no reason to migrate to SCTP any more than there is to migrate > to DCCP (since many TCP apps don't actually need reliability). The > application gets to decide that. OK, maybe we still want a migrate-to-SCTP plan, even if it has to be per-application protocol. Which should we do first? ssh over sctp? XMPP over sctp? http over SCTP? -Tim Shepard shep@alum.mit.edu _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed May 10 14:46:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdthI-0000K8-OX; Wed, 10 May 2006 14:46:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdthG-0000K2-TC for tcpm@ietf.org; Wed, 10 May 2006 14:46:06 -0400 Received: from dsl092-066-146.bos1.dsl.speakeasy.net ([66.92.66.146] helo=alva.home) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdthG-0003di-JW for tcpm@ietf.org; Wed, 10 May 2006 14:46:06 -0400 Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1FdthD-0001rn-00; Wed, 10 May 2006 14:46:03 -0400 From: Tim Shepard To: Joe Touch Subject: Re: middleboxes and Re: [tcpm] TCPx2 In-reply-to: Your message of Wed, 10 May 2006 09:53:40 -0700. <44621A94.8000103@isi.edu> Date: Wed, 10 May 2006 14:46:03 -0400 Message-Id: X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: tcpm@ietf.org, mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org > TCPMUX (on dstport==1) puts the service name in the data portion; the > trouble with that is described in the portname doc. That doc also > discusses the utility of late-binding, which seems more trouble than > it's worth (sec 4.4). Some troubles with TCPMUX (RFC1078) are described in your portnames draft. But I'm not proposing TCPMUX. I'm proposing that the initial SYN carry a string in the data portion of that SYN packet with dstport==0. The reply can come back with a port number filled in (which will work with cone NATs). So now you don't have the TCPMUX problems of a single port and all connections succeeding. (A RST could be returned if the contact name had nothing listening.) > > If there's a "Full cone NAT" or a "Restricted cone NAT" in the > > middle it should work just fine (since the packet coming back has a > > dstport that the NAT assigned). > > It may work for the NAT (though I'm still not clear on that), but the > endpoint then needs to match the SYN/ACK to the original SYN too. > With its original port number, and the ACK of its initial SYN (+ contact name string) and the IP addresses involved, it won't be ambiguous). If you're opening two different connections to the same contact name at the same destination, you'll have to use different srcport numbers. That results in exactly the same limitation we have today for how many concurrent connection establishments to the same destination port that we can have today. > > dstport==0 could also convey an implied "I am modern and clueful and > > hope you are too. (IAMACAHYAT)" option. > > All it says is that dstport==0. If you want a clue-bit, use one of the > reserved header bits, please. It indicates clue in the protocol _and_ > the designer, IMO ;-)) Actually, I prefer putting the IAMACAHYAT in a new 2-byte option that goes with the SYNs. A succesful exchange of IAMACAHYAT would mean that the two TCP implementations both support a well-defined list of future-proofing extensions/behaviors and need not fear knocking the other end over with some weird option or odd combination of lit-up control bits. So maybe we should do that. If we then *also* do a dstport==0 thing to allow for the initial SYN to carry a contact name in the data portion of the packet, then perhaps we could reclaim the space 2-byte option would use by saying that IAMACAHYAT is implied if dstport==0 on the initial SYN. (And these two ideas can be considered seperately.) -Tim Shepard shep@alum.mit.edu _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed May 10 16:00:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fduqu-0001EV-LG; Wed, 10 May 2006 16:00:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fduqt-0001EN-Cl for tcpm@ietf.org; Wed, 10 May 2006 16:00:07 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fduqt-0006g4-0d for tcpm@ietf.org; Wed, 10 May 2006 16:00:07 -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 k4AK01uM068361; Wed, 10 May 2006 13:00:02 -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 3FE0D77B0BA; Wed, 10 May 2006 16:00:00 -0400 (EDT) To: Joe Touch From: Mark Allman Subject: Re: middleboxes and Re: [tcpm] TCPx2 In-Reply-To: <44620251.9000704@isi.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: It's Good to Be King MIME-Version: 1.0 Date: Wed, 10 May 2006 16:00:00 -0400 Message-Id: <20060510200000.3FE0D77B0BA@guns.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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="===============0156785890==" Errors-To: tcpm-bounces@ietf.org --===============0156785890== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > In summary, this seems like a fine experiment, but so would a simpler > mod that just extended the option space. I am going to pop up a level here. This is some can I opened, isn't it? Migrating from TCP to SCTP, using options echoed in RSTs as part of a handshake, riding TCP on UDP, ..., man... I thought my hack was sleazy---you guys have really outdone yourselves! :-) In any case, about the above.... The way I look at it is this.... + If the crystal ball says that for the forseeable future we're just going to add functionality to TCP (e.g., UTO or portnames or quick-start or a new authentication scheme or whatever) then maybe we just bite the bullet and extend the option space with some hack (and, all the proposals are) and leave the rest of the header alone. + If, on the other hand, the crystal ball says that in addition to *extensions* we're likely to need to augment the standard stuff (more port space, more sequence space, more reserved bits, even more window space, etc.) the we should either: (1) bite the bullet and say we have outgrown TCP and either: (1a) go about deprecating it in favor of SCTP/DCCP, or (1b) start the process of coming up with a next-generation byte-stream transport that includes more space and all the features a modern transport should have (whatever those are) or (2) decide that TCP is still a reasonable (if not optimal) general-purpose protocol and enact one hack to give it a bigger header such that it can accommodate today's networks and future expansion more readily. I personally feel like I have heard enough noise about the smallness of standard fields (and corresponding suggestions for how to fix each issue independently) that I think the changes ought to be broader than simply more option space. I admit that this is more of a vibe than a collection of hard evidence. I am personally not in favor of replacing standard fields with options that simply hold bigger values. That seems to me like it will just be a haphazard collection of hacks that will make implementations more difficult, could cause NAT and firewalls to be more complex (or, get confused and drop traffic), will complicate IDS systems, etc. I feel like a new byte-stream transport is probably overkill and it'd take years to develop and even more years to transition to. So, for me, TCPx2 is really a quite pragmatic and straightforward approach. We increase TCP's belt size a bit, but pretty much retain the logic of the protocol such that TCPx2 is straightforward to implement and the transition path isn't too onerous. (That is not to say that all the TCPx2 details are right... just that I think the approach seems about right.) allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEYkZAWyrrWs4yIs4RArh4AJ95og1QOSbIcDDjLu7GAQhgdRVd0wCgm13z 8e79iC0mXwbERfTvngGBpe8= =mtxE -----END PGP SIGNATURE----- --=_bOundary-- --===============0156785890== 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 --===============0156785890==-- From tcpm-bounces@ietf.org Wed May 10 16:12:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdv2N-0006lD-No; Wed, 10 May 2006 16:11:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdv2M-0006hu-E5 for tcpm@ietf.org; Wed, 10 May 2006 16:11:58 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdv2I-0007PJ-1E for tcpm@ietf.org; Wed, 10 May 2006 16:11:58 -0400 Received: from [128.9.160.144] (nib.isi.edu [128.9.160.144]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4AKB8V24330; Wed, 10 May 2006 13:11:08 -0700 (PDT) Message-ID: <446248D6.9080803@isi.edu> Date: Wed, 10 May 2006 13:11:02 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: mallman@icir.org Subject: Re: middleboxes and Re: [tcpm] TCPx2 References: <20060510200000.3FE0D77B0BA@guns.icir.org> In-Reply-To: <20060510200000.3FE0D77B0BA@guns.icir.org> X-Enigmail-Version: 0.94.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: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Mark Allman wrote: >> In summary, this seems like a fine experiment, but so would a simpler >> mod that just extended the option space. > > I am going to pop up a level here. This is some can I opened, isn't it? > Migrating from TCP to SCTP, using options echoed in RSTs as part of a > handshake, riding TCP on UDP, ..., man... I thought my hack was > sleazy---you guys have really outdone yourselves! :-) > > In any case, about the above.... The way I look at it is this.... > > + If the crystal ball says that for the forseeable future we're just > going to add functionality to TCP (e.g., UTO or portnames or > quick-start or a new authentication scheme or whatever) then maybe > we just bite the bullet and extend the option space with some hack > (and, all the proposals are) and leave the rest of the header alone. > > + If, on the other hand, the crystal ball says that in addition to > *extensions* we're likely to need to augment the standard stuff > (more port space, more sequence space, more reserved bits, even more > window space, etc.) But the window scale option isn't more window space; it's a different way of defining that field. Doubling the size of the field doesn't accomplish the same thing; the shift count is 8-bits, which would require a 255+16 bit field to be similar. There isn't a good reason to expand the port number space per se; the issue with port numbers is primarily one of mis-applied security. We'll always benefit from more reserved bits, but the option space accomplishes that. IMO, the main issue is the lack of option space; we could use one reserved bit to indicate the use of extended option space (I haven't seen a proposal that does that, though). Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed May 10 16:12:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdv32-0007HA-8T; Wed, 10 May 2006 16:12:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdv31-0007EC-23 for tcpm@ietf.org; Wed, 10 May 2006 16:12:39 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdv2y-0007QT-LU for tcpm@ietf.org; Wed, 10 May 2006 16:12:39 -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 k4AKCDHg068579; Wed, 10 May 2006 13:12:13 -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 AD4CF77B0BA; Wed, 10 May 2006 16:12:11 -0400 (EDT) To: Tim Shepard From: Mark Allman Subject: Re: alternatives for the future (was Re: middleboxes and Re: [tcpm] TCPx2 ) In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: It's Good to Be King MIME-Version: 1.0 Date: Wed, 10 May 2006 16:12:11 -0400 Message-Id: <20060510201211.AD4CF77B0BA@guns.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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="===============1910317286==" Errors-To: tcpm-bounces@ietf.org --===============1910317286== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > Sending an old-TCP SYN and a new-fangled-TCP SYN in parallel seems > messy to me. It is. > It'd be nice to find a way to succinctly say everything that needs to > be said in the first half of the first round trip time in a single > packet, and have the second half of the first round trip time involve > a single return packet. Yes, that's be nice. Trouble is, I don't think it can be done. Like I have said before, we're not just testing the peer's abilities here. We're also testing the path's abilities. If you send an old-TCP SYN and the peers agree to something new there are absolutely no guarantees you can get the new-fangled thing through the network. If you send a new-style SYN and it makes it to the peer and the peer doesn't understand then you're going to have to retransmit with an old-style SYN. Maybe I am missing something here, but it seems to me that hanging onto this notion that we can negotiate some new header format (not just a new option) using the old format is not going to work. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEYkkbWyrrWs4yIs4RAhTyAJsHU0M1reUmahzJ/qcJnLOLpI1e6wCffdQn rMiKPTP4SVDHsuhrFyOIC6w= =/lcj -----END PGP SIGNATURE----- --=_bOundary-- --===============1910317286== 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 --===============1910317286==-- From tcpm-bounces@ietf.org Wed May 10 16:27:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdvH8-0002jP-Jw; Wed, 10 May 2006 16:27:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdvH7-0002jK-FW for tcpm@ietf.org; Wed, 10 May 2006 16:27:13 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdvH7-00080m-41 for tcpm@ietf.org; Wed, 10 May 2006 16:27:13 -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 k4AKRBaY068788; Wed, 10 May 2006 13:27:11 -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 6191E77B0BA; Wed, 10 May 2006 16:27:09 -0400 (EDT) To: Joe Touch From: Mark Allman Subject: Re: middleboxes and Re: [tcpm] TCPx2 In-Reply-To: <446248D6.9080803@isi.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: It's Good to Be King MIME-Version: 1.0 Date: Wed, 10 May 2006 16:27:09 -0400 Message-Id: <20060510202709.6191E77B0BA@guns.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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="===============0650346643==" Errors-To: tcpm-bounces@ietf.org --===============0650346643== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > But the window scale option isn't more window space; it's a different > way of defining that field. Doubling the size of the field doesn't > accomplish the same thing; the shift count is 8-bits, which would > require a 255+16 bit field to be similar. I have no idea what any of this means. Of course WS is more window space. I just looked at RFC1323 to make sure I remembered it correctly and it says that the maximum shift count is to be 14 -- which gives a window of 2^30 bytes (1 GB). Doubling the original 16-bit field to 32 bits gives a possible window size of 2^32 bytes (4 GB). (And, as the TCPx2 draft notes, someone suggested to me that a failed of the simple *=2 rule on all fields is that it really isn't a doubling of the window given the WS option and so maybe the advertised window field should be more than doubled. It's a reasonable point, I think.) > There isn't a good reason to expand the port number space per se; the > issue with port numbers is primarily one of mis-applied security. Not according to the IETF thread from a while back -- in which some were claiming they had situations of the port size limiting things. (And, then I saw a private chat amongst a group of folks trying to figure out if this was something to fix or not.) > IMO, the main issue is the lack of option space; we could use one > reserved bit to indicate the use of extended option space (I haven't > seen a proposal that does that, though). So, you're in one of the camps I sketched. I.e., you think the standard fields are fine and all we need is room to grow new functionality. That's fine. (I am not in that spot, but when you said yesterday that you generally supported the TCPx2 I was worried that we might be agreeing too much again! :-) To me this is a little about crystal balls and it's not easy to rationalize about some of these things, as I have noted before.) allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEYkydWyrrWs4yIs4RAnwfAJ9LtvhN+rg7XS/H+aF+V8Hi+/WeFwCfTJEI tRuwYCBhP+WWotAu32axdNs= =PCV6 -----END PGP SIGNATURE----- --=_bOundary-- --===============0650346643== 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 --===============0650346643==-- From tcpm-bounces@ietf.org Wed May 10 16:39:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdvT3-0006aq-0r; Wed, 10 May 2006 16:39:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdvT1-0006aZ-8G for tcpm@ietf.org; Wed, 10 May 2006 16:39:31 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdvT0-0000Hw-TF for tcpm@ietf.org; Wed, 10 May 2006 16:39:31 -0400 Received: from [128.9.160.144] (nib.isi.edu [128.9.160.144]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4AKcwV01624; Wed, 10 May 2006 13:38:58 -0700 (PDT) Message-ID: <44624F5D.5000001@isi.edu> Date: Wed, 10 May 2006 13:38:53 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: mallman@icir.org Subject: Re: middleboxes and Re: [tcpm] TCPx2 References: <20060510202709.6191E77B0BA@guns.icir.org> In-Reply-To: <20060510202709.6191E77B0BA@guns.icir.org> X-Enigmail-Version: 0.94.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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Mark Allman wrote: >> But the window scale option isn't more window space; it's a different >> way of defining that field. Doubling the size of the field doesn't >> accomplish the same thing; the shift count is 8-bits, which would >> require a 255+16 bit field to be similar. > > I have no idea what any of this means. Of course WS is more window > space. I just looked at RFC1323 to make sure I remembered it correctly > and it says that the maximum shift count is to be 14 -- which gives a > window of 2^30 bytes (1 GB). Yup - sorry; I just saw 8 bits and extrapolated to even larger windows from there. You're right - 32-bits is max. >> There isn't a good reason to expand the port number space per se; the >> issue with port numbers is primarily one of mis-applied security. > > Not according to the IETF thread from a while back -- in which some were > claiming they had situations of the port size limiting things. (And, > then I saw a private chat amongst a group of folks trying to figure out > if this was something to fix or not.) There are different issues: 1. limitations of the reserved port numbers 2. the need for more port numbers in general The thread I saw focused on #1; that's a function of the number of reserved ports, and whether there's a separation of system vs. user reserved ports. Increasing the port space isn't the solution; having a registry of sorts that decouples the connection identifier from the application service identifier is, and that's what the portname doc focuses on. If you just want larger port spaces (and don't care about string names), just use 4-byte portnames and treat them as numbers. >> IMO, the main issue is the lack of option space; we could use one >> reserved bit to indicate the use of extended option space (I haven't >> seen a proposal that does that, though). > > So, you're in one of the camps I sketched. I.e., you think the standard > fields are fine and all we need is room to grow new functionality. > That's fine. > > (I am not in that spot, but when you said yesterday that you generally > supported the TCPx2 I was worried that we might be agreeing too much > again! :-) To me this is a little about crystal balls and it's not easy > to rationalize about some of these things, as I have noted before.) Agreed - like I said, I like this in general as an experiment, but think that the thing we really _need_ (if we're going minimal) is more option space. If we're fixing anything else, we're opening a can of worms. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed May 10 17:15:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdw1Z-00064P-0P; Wed, 10 May 2006 17:15:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdw1X-00064K-0U for tcpm@ietf.org; Wed, 10 May 2006 17:15:11 -0400 Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdw1W-0001cT-Kc for tcpm@ietf.org; Wed, 10 May 2006 17:15:10 -0400 Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Wed, 10 May 2006 14:15:00 -0700 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id CD4D52B2; Wed, 10 May 2006 14:14:59 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 945982B0; Wed, 10 May 2006 14:14:59 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5-GA) with ESMTP id DMJ64595; Wed, 10 May 2006 14:14:49 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 5079B20502; Wed, 10 May 2006 14:14:49 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: middleboxes and Re: [tcpm] TCPx2 Date: Wed, 10 May 2006 14:14:48 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F149EF58@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: middleboxes and Re: [tcpm] TCPx2 Thread-Index: AcZ0bITqnpct/Up7Qv2mLbUiZgPyPQACJThg From: "Caitlin Bestler" To: mallman@icir.org, "Joe Touch" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006051006; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230322E34343632353543442E303030412D412D; ENG=IBF; TS=20060510211502; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006051006_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 687C885E3NG14493144-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Mark Allman wrote: >> In summary, this seems like a fine experiment, but so would a simpler >> mod that just extended the option space. >=20 > I am going to pop up a level here. This is some can I > opened, isn't it? > Migrating from TCP to SCTP, using options echoed in RSTs as > part of a handshake, riding TCP on UDP, ..., man... I thought > my hack was sleazy---you guys have really outdone yourselves! :-) >=20 > In any case, about the above.... The way I look at it is this.... >=20 > + If the crystal ball says that for the forseeable future we're just > going to add functionality to TCP (e.g., UTO or portnames or > quick-start or a new authentication scheme or whatever) then maybe > we just bite the bullet and extend the option space with some hack > (and, all the proposals are) and leave the rest of the > header alone. >=20 > + If, on the other hand, the crystal ball says that in addition to > *extensions* we're likely to need to augment the standard stuff > (more port space, more sequence space, more reserved > bits, even more > window space, etc.) the we should either: >=20 > (1) bite the bullet and say we have outgrown TCP and either: >=20 > (1a) go about deprecating it in favor of SCTP/DCCP, or > (1b) start the process of coming up with a next-generation > byte-stream transport that includes more space and all the > features a modern transport should have (whatever > those are) >=20 > or >=20 > (2) decide that TCP is still a reasonable (if not optimal) > general-purpose protocol and enact one hack to give > it a bigger > header such that it can accommodate today's networks > and future > expansion more readily. >=20 To me the critical issue is maintaining critical compatability and interoperability. If you are going to lose those, then it is no longer a minor modification. Further, it won't matter how useful it is, it won't get deployed anytime soon. And I don't=20 think that calling it "TCPx2" or whatever will make it get required support anytime sooner. That suggests that any "minor" enhancement should a) be totally compatbile with current standards, and merely=20 define an extra option that will be properly understood as "an option I don't understand but can ignore" by all current stacks or network elements. b) not use much of the remaining option space. c) enable a much larger exchange of connection setup information, when a basic connection is established using the simple option described in a and b. For example, this new option could say something as simple as "if we both agree to use the 'extended connection' feature then the first TCP segment we each send will be a special TCP segment that does not contain ULP payload but rather special option negotiations. (That's first TCP segment as sent, obviously the message should document its length in the first two bytes and the receiver should rely upon that length rather than on the actual segmentation). If both sides do not speak the enhanced version then they simply go straight to the ULP payloads without enhancements. As far as any existing network element is concerned everything looks like a standard TCP connection, albeit one with some new-fangled option that is irrelevant to the network element. That would allow a very large option space, but restrict it to options that make sense *after* a nominal connection is established. But that could include redirecting within a host a virtual host, jumpstarting the window sizes, etc. An enhanced INETD, or equivalent, could even launch the daemon instance *after* doing the special-options exchange. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed May 10 21:58:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe0RB-0003iu-O8; Wed, 10 May 2006 21:57:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe0RA-0003ip-M3 for tcpm@ietf.org; Wed, 10 May 2006 21:57:56 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fe0R9-0004lk-Cn for tcpm@ietf.org; Wed, 10 May 2006 21:57:56 -0400 Received: from [12.208.123.114] (helo=elb.elitists.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fe0R4-000GcD-EX for tcpm@ietf.org; Thu, 11 May 2006 01:57:50 +0000 Received: from elitists.net (colt [192.168.33.1]) by elb.elitists.net (Postfix) with ESMTP id 8E58C2BE1F for ; Wed, 10 May 2006 20:57:44 -0500 (EST) Received: by elitists.net (Postfix, from userid 3000) id 7EA68F452; Wed, 10 May 2006 20:57:43 -0500 (EST) Date: Wed, 10 May 2006 21:57:42 -0400 From: Ethan Blanton To: tcpm@ietf.org Subject: Re: middleboxes and Re: [tcpm] TCPx2 Message-ID: <20060511015742.GO1153@localhost.localdomain> Mail-Followup-To: tcpm@ietf.org References: <54AD0F12E08D1541B826BE97C98F99F149EF58@NT-SJCA-0751.brcm.ad.broadcom.com> Mime-Version: 1.0 In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F149EF58@NT-SJCA-0751.brcm.ad.broadcom.com> X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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="===============1493134522==" Errors-To: tcpm-bounces@ietf.org --===============1493134522== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RCJLo13VlymhPcEi" Content-Disposition: inline --RCJLo13VlymhPcEi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Caitlin Bestler spake unto us the following wisdom: [snip...] > For example, this new option could say something as simple > as "if we both agree to use the 'extended connection' feature > then the first TCP segment we each send will be a special > TCP segment that does not contain ULP payload but rather > special option negotiations. (That's first TCP segment as > sent, obviously the message should document its length > in the first two bytes and the receiver should rely upon > that length rather than on the actual segmentation). >=20 > If both sides do not speak the enhanced version then they > simply go straight to the ULP payloads without enhancements. > As far as any existing network element is concerned everything > looks like a standard TCP connection, albeit one with some > new-fangled option that is irrelevant to the network element. As long as we're on the "but NATs really do suck!" bandwagon ... this isn't really true. Try inserting some random goop between byte 0 and the first data of an HTTP exchange, and see how many middle boxes you break -- I bet it will be a nontrivial number. 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 --RCJLo13VlymhPcEi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEYpoWr9kA9Ig8HBQRAmfCAJsH1wXfEbMp4Wpbw/3TRgKn/ix/FgCff/NX s+a8Jp3BHu9HffNJbkeKgRM= =XIjI -----END PGP SIGNATURE----- --RCJLo13VlymhPcEi-- --===============1493134522== 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 --===============1493134522==-- From tcpm-bounces@ietf.org Wed May 10 23:25:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe1ny-0006Mg-No; Wed, 10 May 2006 23:25:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe1ny-0006MW-1e for tcpm@ietf.org; Wed, 10 May 2006 23:25:34 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fe1nw-0008K2-MK for tcpm@ietf.org; Wed, 10 May 2006 23:25:34 -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 k4B3PSQi078378; Wed, 10 May 2006 20:25:28 -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 9CD2D77B3B4; Wed, 10 May 2006 23:25:25 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 7FBBA40B939; Wed, 10 May 2006 22:49:53 -0400 (EDT) To: Joe Touch From: Mark Allman Subject: Re: middleboxes and Re: [tcpm] TCPx2 In-Reply-To: <44624F5D.5000001@isi.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: It's Good to Be King MIME-Version: 1.0 Date: Wed, 10 May 2006 22:49:53 -0400 Message-Id: <20060511024953.7FBBA40B939@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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="===============0755925106==" Errors-To: tcpm-bounces@ietf.org --===============0755925106== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > There are different issues: > > 1. limitations of the reserved port numbers > 2. the need for more port numbers in general > > The thread I saw focused on #1; that's a function of the number of > reserved ports, and whether there's a separation of system vs. user > reserved ports. What I have seen is "the lack of more than 16 bits is an issue" ... i.e., #2. This is in the context of a big proxy of some sort. I need to crystalize this a bit more, I understand. I will. > If you just want larger port spaces (and don't care about string > names), just use 4-byte portnames and treat them as numbers. So, that's the sort of hack I am trying to avoid with TCPx2. And, does that even work? The portnames are just initial, right? They still have to map into two 16-bit ports. (But, we do open it up a bit by not requiring one of them to be fixed, of course.) > Agreed - like I said, I like this in general as an experiment, but > think that the thing we really _need_ (if we're going minimal) is more > option space. If we're fixing anything else, we're opening a can of > worms. I understand what you're saying. I actually don't know that we *need* anything. As I have said before, we don't standardize new options at an alarming rate. TCPx2 is not about a clear and present *need*. What it is about is trying to plan a little bit. If we *need* one field to be extended and we think there could well be more than we should do something more general than an "I need this now" hack, IMO. If we think there are likely to be a bunch of fields we need to extend, even if we don't this instant, then we should try a general approach, IMO. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEYqZQWyrrWs4yIs4RAmsiAJ42p15ROQKtu1xHtO2YJMzpxIqaowCdG05/ sCeGWSPwLYRrtbVioQOoAiw= =b1GJ -----END PGP SIGNATURE----- --=_bOundary-- --===============0755925106== 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 --===============0755925106==-- From tcpm-bounces@ietf.org Wed May 10 23:26:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe1ny-0006Mb-I4; Wed, 10 May 2006 23:25:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe1nx-0006MR-Lo for tcpm@ietf.org; Wed, 10 May 2006 23:25:33 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fe1nx-0008K3-9v for tcpm@ietf.org; Wed, 10 May 2006 23:25:33 -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 k4B3PREA078377; Wed, 10 May 2006 20:25:32 -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 8610E77B3B3; Wed, 10 May 2006 23:25:25 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 4DA7D40B977; Wed, 10 May 2006 23:05:17 -0400 (EDT) To: "Caitlin Bestler" From: Mark Allman Subject: Re: middleboxes and Re: [tcpm] TCPx2 In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F149EF58@NT-SJCA-0751.brcm.ad.broadcom.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: It's Good to Be King MIME-Version: 1.0 Date: Wed, 10 May 2006 23:05:17 -0400 Message-Id: <20060511030517.4DA7D40B977@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: tcpm@ietf.org, Joe Touch 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="===============1994149462==" Errors-To: tcpm-bounces@ietf.org --===============1994149462== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > To me the critical issue is maintaining critical compatability > and interoperability. If you are going to lose those, then it > is no longer a minor modification. Further, it won't matter how > useful it is, it won't get deployed anytime soon. And I don't > think that calling it "TCPx2" or whatever will make it get > required support anytime sooner. I read the above as indicating that you do not believe that TCPx2 "maintains critical compatibility and interoperability". Is that a correct interpretation? If so, I'd like to hear the logic behind the statement, because from my seat compatibility and interoperability are maintained with the fallback to RFC793 TCP sketched in the i-d. (The clear case when that would break is when a stack supported TCPx2 and not TCPx1. But, since *it's (basically) the same protocol* it would seem stupid to go to x2 and not continue to grok x1.) > That suggests that any "minor" enhancement should > > a) be totally compatbile with current standards, and merely > define an extra option that will be properly understood > as "an option I don't understand but can ignore" by all > current stacks or network elements. > > b) not use much of the remaining option space. > > c) enable a much larger exchange of connection setup information, > when a basic connection is established using the simple > option described in a and b. So, it's fine if you are in favor of arbitrary extension via options. As I have sketched previously, I don't think that is the right path, personally. But, we can differ. I will note that while I am practical enough to understand that middleboxes need to be dealt with, I am sure glad that the IETF does not take the position that only transports 6 and 17 are blessed to initiate connections (e.g., DCCP) (e.g., SCTP). I think it is fundamentally wrong to constrain our engineering in that way. I do not mean to disparage RFCs 791 and 793, but they were not handed down from a deity and I do not think we are duty-bound to use them for eternity. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEYqnsWyrrWs4yIs4RAnknAJ4rVLDDQX4FGmG2d0suLr43/tD3vACfSBQi +MNHnaAQiXUeO88aUOFqDKs= =Ju96 -----END PGP SIGNATURE----- --=_bOundary-- --===============1994149462== 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 --===============1994149462==-- From tcpm-bounces@ietf.org Thu May 11 10:41:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCLN-0004gP-HD; Thu, 11 May 2006 10:40:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCLM-0004gK-Io for tcpm@ietf.org; Thu, 11 May 2006 10:40:44 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeCLI-0004t4-7D for tcpm@ietf.org; Thu, 11 May 2006 10:40:44 -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 k4BEeZHE011832; Thu, 11 May 2006 07:40:35 -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 3DDA177AC21; Thu, 11 May 2006 10:40:34 -0400 (EDT) To: Joe Touch , Andrew Yourtchenko , Frank Kastenholz , tcpm@ietf.org From: Mark Allman Subject: Re: middleboxes and Re: [tcpm] TCPx2 In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Lightning Crashes MIME-Version: 1.0 Date: Thu, 11 May 2006 10:40:34 -0400 Message-Id: <20060511144034.3DDA177AC21@guns.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: 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="===============0717156361==" Errors-To: tcpm-bounces@ietf.org --===============0717156361== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Joe: > > There are different issues: > > > > 1. limitations of the reserved port numbers > > 2. the need for more port numbers in general > > > > The thread I saw focused on #1; that's a function of the number of > > reserved ports, and whether there's a separation of system vs. user > > reserved ports. Mark: > What I have seen is "the lack of more than 16 bits is an issue" > ... i.e., #2. This is in the context of a big proxy of some sort. I > need to crystalize this a bit more, I understand. I will. The message below and more generally the thread it goes with indicates that for some places the 16 bits is the problem, not the limitation of reserved port numbers. http://www.mhonarc.org/archive/html/ietf/2005-07/msg00340.html allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEY0ziWyrrWs4yIs4RAuwqAJ4vpTXSdXVOxHTdBN+H8aiTuGrJXACeNI3n cRfzqqYXNWyw7IWxO+BX0vU= =cJXS -----END PGP SIGNATURE----- --=_bOundary-- --===============0717156361== 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 --===============0717156361==-- From tcpm-bounces@ietf.org Thu May 11 11:05:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCiw-0007mu-3a; Thu, 11 May 2006 11:05:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCiu-0007mp-AX for tcpm@ietf.org; Thu, 11 May 2006 11:05:04 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeCir-0005jg-Tp for tcpm@ietf.org; Thu, 11 May 2006 11:05:04 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4BF4NV21152; Thu, 11 May 2006 08:04:23 -0700 (PDT) Message-ID: <44635271.30307@isi.edu> Date: Thu, 11 May 2006 08:04:17 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: mallman@icir.org Subject: Re: middleboxes and Re: [tcpm] TCPx2 References: <20060511024953.7FBBA40B939@lawyers.icir.org> In-Reply-To: <20060511024953.7FBBA40B939@lawyers.icir.org> X-Enigmail-Version: 0.94.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: 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: , Errors-To: tcpm-bounces@ietf.org Mark Allman wrote: >> There are different issues: >> >> 1. limitations of the reserved port numbers >> 2. the need for more port numbers in general >> >> The thread I saw focused on #1; that's a function of the number of >> reserved ports, and whether there's a separation of system vs. user >> reserved ports. > > What I have seen is "the lack of more than 16 bits is an issue" > ... i.e., #2. This is in the context of a big proxy of some sort. I > need to crystalize this a bit more, I understand. I will. Making TCP's header bigger to support NATs is a mistake. As I said, they create their own problems; they will continue to do so, regardless of anything we do to help. >> If you just want larger port spaces (and don't care about string >> names), just use 4-byte portnames and treat them as numbers. > > So, that's the sort of hack I am trying to avoid with TCPx2. And, does > that even work? The portnames are just initial, right? They still have > to map into two 16-bit ports. (But, we do open it up a bit by not > requiring one of them to be fixed, of course.) Port pairs - combined with IP addresses - determine the service endpoints, and are still the connection ID. Portnames determine the protocol. The portname is needed only to hand the connection off to the service. >> Agreed - like I said, I like this in general as an experiment, but >> think that the thing we really _need_ (if we're going minimal) is more >> option space. If we're fixing anything else, we're opening a can of >> worms. > > I understand what you're saying. I actually don't know that we *need* > anything. As I have said before, we don't standardize new options at an > alarming rate. > > TCPx2 is not about a clear and present *need*. What it is about is > trying to plan a little bit. If we *need* one field to be extended and > we think there could well be more than we should do something more > general than an "I need this now" hack, IMO. If we think there are > likely to be a bunch of fields we need to extend, even if we don't this > instant, then we should try a general approach, IMO. But a general approach opens a can of other worms too. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu May 11 11:05:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCio-0007VR-SK; Thu, 11 May 2006 11:04:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCin-0007Q0-MW for tcpm@ietf.org; Thu, 11 May 2006 11:04:57 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeCim-0005jH-AC for tcpm@ietf.org; Thu, 11 May 2006 11:04:57 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4BF4KV21126; Thu, 11 May 2006 08:04:20 -0700 (PDT) Message-ID: <4463526E.9020304@isi.edu> Date: Thu, 11 May 2006 08:04:14 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: mallman@icir.org Subject: Re: middleboxes and Re: [tcpm] TCPx2 References: <20060511144034.3DDA177AC21@guns.icir.org> In-Reply-To: <20060511144034.3DDA177AC21@guns.icir.org> X-Enigmail-Version: 0.94.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: 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: , Errors-To: tcpm-bounces@ietf.org Mark Allman wrote: > Joe: >>> There are different issues: >>> >>> 1. limitations of the reserved port numbers >>> 2. the need for more port numbers in general >>> >>> The thread I saw focused on #1; that's a function of the number of >>> reserved ports, and whether there's a separation of system vs. user >>> reserved ports. > > Mark: >> What I have seen is "the lack of more than 16 bits is an issue" >> ... i.e., #2. This is in the context of a big proxy of some sort. I >> need to crystalize this a bit more, I understand. I will. > > The message below and more generally the thread it goes with indicates > that for some places the 16 bits is the problem, not the limitation of > reserved port numbers. > > http://www.mhonarc.org/archive/html/ietf/2005-07/msg00340.html > > allman Yes - 65,000 is too small, whether between proxies, between hops in SMTP, or for (gasp) NATs. That's a reason to decouple service from port number, or a reason to increase the number of source ports, but not to increase them all. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu May 11 11:05:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCiw-0007mu-3a; Thu, 11 May 2006 11:05:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCiu-0007mp-AX for tcpm@ietf.org; Thu, 11 May 2006 11:05:04 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeCir-0005jg-Tp for tcpm@ietf.org; Thu, 11 May 2006 11:05:04 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4BF4NV21152; Thu, 11 May 2006 08:04:23 -0700 (PDT) Message-ID: <44635271.30307@isi.edu> Date: Thu, 11 May 2006 08:04:17 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: mallman@icir.org Subject: Re: middleboxes and Re: [tcpm] TCPx2 References: <20060511024953.7FBBA40B939@lawyers.icir.org> In-Reply-To: <20060511024953.7FBBA40B939@lawyers.icir.org> X-Enigmail-Version: 0.94.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: 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: , Errors-To: tcpm-bounces@ietf.org Mark Allman wrote: >> There are different issues: >> >> 1. limitations of the reserved port numbers >> 2. the need for more port numbers in general >> >> The thread I saw focused on #1; that's a function of the number of >> reserved ports, and whether there's a separation of system vs. user >> reserved ports. > > What I have seen is "the lack of more than 16 bits is an issue" > ... i.e., #2. This is in the context of a big proxy of some sort. I > need to crystalize this a bit more, I understand. I will. Making TCP's header bigger to support NATs is a mistake. As I said, they create their own problems; they will continue to do so, regardless of anything we do to help. >> If you just want larger port spaces (and don't care about string >> names), just use 4-byte portnames and treat them as numbers. > > So, that's the sort of hack I am trying to avoid with TCPx2. And, does > that even work? The portnames are just initial, right? They still have > to map into two 16-bit ports. (But, we do open it up a bit by not > requiring one of them to be fixed, of course.) Port pairs - combined with IP addresses - determine the service endpoints, and are still the connection ID. Portnames determine the protocol. The portname is needed only to hand the connection off to the service. >> Agreed - like I said, I like this in general as an experiment, but >> think that the thing we really _need_ (if we're going minimal) is more >> option space. If we're fixing anything else, we're opening a can of >> worms. > > I understand what you're saying. I actually don't know that we *need* > anything. As I have said before, we don't standardize new options at an > alarming rate. > > TCPx2 is not about a clear and present *need*. What it is about is > trying to plan a little bit. If we *need* one field to be extended and > we think there could well be more than we should do something more > general than an "I need this now" hack, IMO. If we think there are > likely to be a bunch of fields we need to extend, even if we don't this > instant, then we should try a general approach, IMO. But a general approach opens a can of other worms too. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu May 11 11:05:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCio-0007VR-SK; Thu, 11 May 2006 11:04:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCin-0007Q0-MW for tcpm@ietf.org; Thu, 11 May 2006 11:04:57 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeCim-0005jH-AC for tcpm@ietf.org; Thu, 11 May 2006 11:04:57 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4BF4KV21126; Thu, 11 May 2006 08:04:20 -0700 (PDT) Message-ID: <4463526E.9020304@isi.edu> Date: Thu, 11 May 2006 08:04:14 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: mallman@icir.org Subject: Re: middleboxes and Re: [tcpm] TCPx2 References: <20060511144034.3DDA177AC21@guns.icir.org> In-Reply-To: <20060511144034.3DDA177AC21@guns.icir.org> X-Enigmail-Version: 0.94.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: 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: , Errors-To: tcpm-bounces@ietf.org Mark Allman wrote: > Joe: >>> There are different issues: >>> >>> 1. limitations of the reserved port numbers >>> 2. the need for more port numbers in general >>> >>> The thread I saw focused on #1; that's a function of the number of >>> reserved ports, and whether there's a separation of system vs. user >>> reserved ports. > > Mark: >> What I have seen is "the lack of more than 16 bits is an issue" >> ... i.e., #2. This is in the context of a big proxy of some sort. I >> need to crystalize this a bit more, I understand. I will. > > The message below and more generally the thread it goes with indicates > that for some places the 16 bits is the problem, not the limitation of > reserved port numbers. > > http://www.mhonarc.org/archive/html/ietf/2005-07/msg00340.html > > allman Yes - 65,000 is too small, whether between proxies, between hops in SMTP, or for (gasp) NATs. That's a reason to decouple service from port number, or a reason to increase the number of source ports, but not to increase them all. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu May 11 11:06:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCk2-0000cg-Hp; Thu, 11 May 2006 11:06:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCk1-0000ca-HK for tcpm@ietf.org; Thu, 11 May 2006 11:06:13 -0400 Received: from dsl092-066-146.bos1.dsl.speakeasy.net ([66.92.66.146] helo=alva.home) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeCk0-0005lx-7J for tcpm@ietf.org; Thu, 11 May 2006 11:06:13 -0400 Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1FeCjk-0002aI-00; Thu, 11 May 2006 11:05:56 -0400 From: Tim Shepard To: mallman@icir.org Subject: Re: middleboxes and Re: [tcpm] TCPx2 In-reply-to: Your message of Thu, 11 May 2006 10:40:34 -0400. <20060511144034.3DDA177AC21@guns.icir.org> Date: Thu, 11 May 2006 11:05:56 -0400 Message-Id: X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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: , Errors-To: tcpm-bounces@ietf.org > The message below and more generally the thread it goes with indicates > that for some places the 16 bits is the problem, not the limitation of > reserved port numbers. > > http://www.mhonarc.org/archive/html/ietf/2005-07/msg00340.html > If I understand that correctly, the things that are running out of port numbers are proxies that have to have many simultaneous connections open to particular (server, port) on behalf of their clients. Wouldn't it be simpler to give such boxes a few different IP addresses that it can use to open connections from? That'd work just fine. Each additional IPv4 address you assign to the proxy box gives allows an additional 65 thousand clients that can simultaneously have connections open to some particular (server, port). And with IPv6 the proxy could give itself additional addresses as needed, a la rfc3041. (And you can do IPv6 even if your ISP is not offereing IPv6 by using rfc3056.) -Tim Shepard shep@alum.mit.edu _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu May 11 11:11:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCon-0002cp-8P; Thu, 11 May 2006 11:11:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCol-0002ck-P3 for tcpm@ietf.org; Thu, 11 May 2006 11:11:07 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeCol-00064k-E2 for tcpm@ietf.org; Thu, 11 May 2006 11:11:07 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4BFA5V23047; Thu, 11 May 2006 08:10:05 -0700 (PDT) Message-ID: <446353C7.3030606@isi.edu> Date: Thu, 11 May 2006 08:09:59 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Tim Shepard Subject: Re: middleboxes and Re: [tcpm] TCPx2 References: In-Reply-To: X-Enigmail-Version: 0.94.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: 7655788c23eb79e336f5f8ba8bce7906 Cc: tcpm@ietf.org, mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Tim Shepard wrote: >> The message below and more generally the thread it goes with indicates >> that for some places the 16 bits is the problem, not the limitation of >> reserved port numbers. >> >> http://www.mhonarc.org/archive/html/ietf/2005-07/msg00340.html >> > > If I understand that correctly, the things that are running out of > port numbers are proxies that have to have many simultaneous > connections open to particular (server, port) on behalf of their > clients. > > Wouldn't it be simpler to give such boxes a few different IP addresses > that it can use to open connections from? Simpler - and much more efficient, both in terms of packet and congestion control - to fix the protocol that needs to open a connection per exchange to keep the connection open and reuse it. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu May 11 11:35:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeDCC-0005py-N5; Thu, 11 May 2006 11:35:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeDCB-0005pt-Be for tcpm@ietf.org; Thu, 11 May 2006 11:35:19 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeDCA-0007Ku-0D for tcpm@ietf.org; Thu, 11 May 2006 11:35:19 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k4BFZHLs012800; Thu, 11 May 2006 08:35:17 -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 D768077AC21; Thu, 11 May 2006 11:35:15 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 05F7C40C159; Thu, 11 May 2006 11:34:19 -0400 (EDT) To: Joe Touch From: Mark Allman Subject: Re: middleboxes and Re: [tcpm] TCPx2 In-Reply-To: <44635271.30307@isi.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Lightning Crashes MIME-Version: 1.0 Date: Thu, 11 May 2006 11:34:19 -0400 Message-Id: <20060511153419.05F7C40C159@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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="===============1828580257==" Errors-To: tcpm-bounces@ietf.org --===============1828580257== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > Mark Allman wrote: > >> There are different issues: > >> > >> 1. limitations of the reserved port numbers > >> 2. the need for more port numbers in general > >> > >> The thread I saw focused on #1; that's a function of the number of > >> reserved ports, and whether there's a separation of system vs. user > >> reserved ports. > > > > What I have seen is "the lack of more than 16 bits is an issue" > > ... i.e., #2. This is in the context of a big proxy of some sort. I > > need to crystalize this a bit more, I understand. I will. > > Making TCP's header bigger to support NATs is a mistake. As I said, > they create their own problems; they will continue to do so, > regardless of anything we do to help. Joe- don't make this just a religious NAT issue. As you indicated in you other email, you understand that is not the case. > > TCPx2 is not about a clear and present *need*. What it is about is > > trying to plan a little bit. If we *need* one field to be extended > > and we think there could well be more than we should do something > > more general than an "I need this now" hack, IMO. If we think there > > are likely to be a bunch of fields we need to extend, even if we > > don't this instant, then we should try a general approach, IMO. > > But a general approach opens a can of other worms too. Please enumerate. I am not saying x2 is without issue, but the can is fairly scoped and small from my perspective. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEY1l7WyrrWs4yIs4RAoSXAJ9aHiBJTfvFMFSD87NWsXvsuauyVACfWb3e Qly6T+njjknKHnRIKzOdBSM= =PZ1h -----END PGP SIGNATURE----- --=_bOundary-- --===============1828580257== 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 --===============1828580257==-- From tcpm-bounces@ietf.org Thu May 11 11:36:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeDDU-0006Li-J0; Thu, 11 May 2006 11:36:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeDDS-0006Ld-U9 for tcpm@ietf.org; Thu, 11 May 2006 11:36:38 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeDDR-0007Lu-JK for tcpm@ietf.org; Thu, 11 May 2006 11:36:38 -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 k4BFaOd4012827; Thu, 11 May 2006 08:36:24 -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 89E1877AC21; Thu, 11 May 2006 11:36:22 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id D419C40C16B; Thu, 11 May 2006 11:35:26 -0400 (EDT) To: Tim Shepard From: Mark Allman Subject: Re: middleboxes and Re: [tcpm] TCPx2 In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Lightning Crashes MIME-Version: 1.0 Date: Thu, 11 May 2006 11:35:26 -0400 Message-Id: <20060511153526.D419C40C16B@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: tcpm@ietf.org, Joe Touch 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="===============1953247232==" Errors-To: tcpm-bounces@ietf.org --===============1953247232== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > Wouldn't it be simpler to give such boxes a few different IP addresses > that it can use to open connections from? That is a "solution" discussed in that thread. I am not sure what "simpler" is relative to in the above. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEY1m+WyrrWs4yIs4RAhxnAJ915RTpI+JXktd7VzWto/c5Ai+BTgCgl0mE 0V1GgwrC9OW6kzPY/NDXhCs= =Ktru -----END PGP SIGNATURE----- --=_bOundary-- --===============1953247232== 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 --===============1953247232==-- From tcpm-bounces@ietf.org Thu May 11 11:46:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeDM8-00021X-Oy; Thu, 11 May 2006 11:45:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeDM7-00021S-9J for tcpm@ietf.org; Thu, 11 May 2006 11:45:35 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeDM5-0007nH-Uo for tcpm@ietf.org; Thu, 11 May 2006 11:45:35 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4BFjDV02529; Thu, 11 May 2006 08:45:13 -0700 (PDT) Message-ID: <44635C03.6090400@isi.edu> Date: Thu, 11 May 2006 08:45:07 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: mallman@icir.org Subject: Re: middleboxes and Re: [tcpm] TCPx2 References: <20060511153419.05F7C40C159@lawyers.icir.org> In-Reply-To: <20060511153419.05F7C40C159@lawyers.icir.org> X-Enigmail-Version: 0.94.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: 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: , Errors-To: tcpm-bounces@ietf.org Mark Allman wrote: ... > Joe- don't make this just a religious NAT issue. As you indicated in > you other email, you understand that is not the case. > Your message was rejected Between cooperating proxies, the solution to a lack of source port numbers is to use persistent connections, i.e., fix the protocol. ... >> But a general approach opens a can of other worms too. > > Please enumerate. I am not saying x2 is without issue, but the can is > fairly scoped and small from my perspective. 1. is a double congestion window sufficient, or should it be 4x, i.e., to double what scaled windows already support? 2. how are the extra unused bits treated on receipt? if ignore, it's impossible to add a required flag (i.e., this is why 'required' is a flag on IPv6 options) 3. where is the version number? I don't support _any_ new protocol that doesn't start with at least a few bits so it can be changed without encumbering the layer above's demuxing space. 4. if the option space is larger, and the header is larger, are the option fields larger as well? or redefined? -- The only reason to redo the entire header in one motion is that we hope we won't come back to redo it; otherwise, we need to be backward compatible (which admittedly this is not). And what then about backward compatibility? ---- As an experimental protocol, this sounds fine. Let the market/public decide. I guess I'm just arguing that it's premature to jump forward with anything stronger than experimental - or was that what you were going for? Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu May 11 12:22:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeDvS-0002mT-Ua; Thu, 11 May 2006 12:22:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeDvR-0002lH-Np for tcpm@ietf.org; Thu, 11 May 2006 12:22:05 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeDvO-0000mJ-9v for tcpm@ietf.org; Thu, 11 May 2006 12:22:05 -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 k4BGLw6S013678; Thu, 11 May 2006 09:21:59 -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 5DE0D77AC21; Thu, 11 May 2006 12:21:57 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id B1CE540C201; Thu, 11 May 2006 12:21:01 -0400 (EDT) To: Joe Touch From: Mark Allman Subject: Re: middleboxes and Re: [tcpm] TCPx2 In-Reply-To: <44635C03.6090400@isi.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Lightning Crashes MIME-Version: 1.0 Date: Thu, 11 May 2006 12:21:01 -0400 Message-Id: <20060511162101.B1CE540C201@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 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="===============0055814301==" Errors-To: tcpm-bounces@ietf.org --===============0055814301== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > 1. is a double congestion window sufficient, or should it be 4x, i.e., > to double what scaled windows already support? A detail to be worked out, as noted in the i-d and on the list. > 2. how are the extra unused bits treated on receipt? > if ignore, it's impossible to add a required flag > (i.e., this is why 'required' is a flag on IPv6 options) They are the same as the remaining TCP bits today. > 3. where is the version number? > I don't support _any_ new protocol that doesn't start with at least a > few bits so it can be changed without encumbering the layer above's > demuxing space. This is the one bit of new logic that I am wondering about. In general I don't want to add any, but this bit of future proofing seems like it could be useful and certainly in the spirit of "let's fix this in a general way and not with N hacks". > 4. if the option space is larger, and the header is larger, are the > option fields larger as well? or redefined? As proposed? No change. It's a valid question, however. The above is a followon of this statement: >> But a general approach opens a can of other worms too. As far as I can tell, none of the above are worms caused by a general approach. They are all fine questions. The draft is completely preliminary and the IETF is for working through just these kinds of questions. But, just because something is not fully baked doesn't make the trajectory wrong. > The only reason to redo the entire header in one motion is that we > hope we won't come back to redo it; otherwise, The reason for me is that we can do it pretty cleanly and easily and not have to do N kludges to keep muddling by. > we need to be backward compatible (which admittedly this is not). > > And what then about backward compatibility? I don't even understand this comment. What are you asking? There is a straightforward fallback. > As an experimental protocol, this sounds fine. Let the market/public > decide. I guess I'm just arguing that it's premature to jump forward > with anything stronger than experimental - or was that what you were > going for? To tell you the truth this question never even crossed my mind. This started as a rockheaded idea and I figured it was not going to go anywhere. The more everyone on this list talks (about why we can work around things without something like TCPx2) the more I think TCPx2 embodies the right approach. But, since you asked ... For me there is no experiment in something like this. It is scoped so tightly that what would we learn from an experiment? Experimentals are specifically not really to be used in the wild. So, what experiment would you have a student perform in a lab? I'm not saying you can't come up with something (e.g., something having to do with the performance of a stack that supports multiple protocol header types or something). But, I don't think there is anything much that we could come back to in 2 or 3 years and say "yeah, it worked" or "no, it didn't". So, for me, I'd throw it out at PS as the way to extend TCP and that as people need "more" this is the way they get it and that we're not going to give you more window space in another "extended window scale" option or redefine the unused offset code points to give you more option space or whatever. And, then, as you note let the market decide. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEY2RtWyrrWs4yIs4RAoP7AKCULC/cOQBzNThcb4EMmg5De3bo1wCfcql8 yBCK/qjwMuIMvfz0ukLfJl0= =oxM+ -----END PGP SIGNATURE----- --=_bOundary-- --===============0055814301== 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 --===============0055814301==-- From tcpm-bounces@ietf.org Thu May 11 12:52:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeEO2-0006Ur-Cd; Thu, 11 May 2006 12:51:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeEO0-0006Um-Nz for tcpm@ietf.org; Thu, 11 May 2006 12:51:36 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeEO0-0002Mp-CA for tcpm@ietf.org; Thu, 11 May 2006 12:51:36 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4BGodV17281; Thu, 11 May 2006 09:50:39 -0700 (PDT) Message-ID: <44636B59.5080000@isi.edu> Date: Thu, 11 May 2006 09:50:33 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: mallman@icir.org Subject: Re: middleboxes and Re: [tcpm] TCPx2 References: <20060511162101.B1CE540C201@lawyers.icir.org> In-Reply-To: <20060511162101.B1CE540C201@lawyers.icir.org> X-Enigmail-Version: 0.94.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: 4b800b1eab964a31702fa68f1ff0e955 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Mark Allman wrote: ... > As far as I can tell, none of the above are worms caused by a general > approach. They are all fine questions. The draft is completely > preliminary and the IETF is for working through just these kinds of > questions. But, just because something is not fully baked doesn't make > the trajectory wrong. Agreed, completely. As I said in the beginning, I'm generally in favor of going down this path... with the caveat below. >> The only reason to redo the entire header in one motion is that we >> hope we won't come back to redo it; otherwise, > > The reason for me is that we can do it pretty cleanly and easily and not > have to do N kludges to keep muddling by. > >> we need to be backward compatible (which admittedly this is not). >> >> And what then about backward compatibility? > > I don't even understand this comment. What are you asking? There is a > straightforward fallback. The fallback is dual-stack, isn't it? That's fine, but not quite what I would expect for standards-track. >> As an experimental protocol, this sounds fine. Let the market/public >> decide. I guess I'm just arguing that it's premature to jump forward >> with anything stronger than experimental - or was that what you were >> going for? > > To tell you the truth this question never even crossed my mind. This > started as a rockheaded idea and I figured it was not going to go > anywhere. The more everyone on this list talks (about why we can work > around things without something like TCPx2) the more I think TCPx2 > embodies the right approach. > > But, since you asked ... For me there is no experiment in something like > this. It is scoped so tightly that what would we learn from an > experiment? Experimentals are specifically not really to be used in the > wild. Not IMO. They're to gain more experience too. They're an indication that we don't know yet whether this is the way to fix TCP. > So, what experiment would you have a student perform in a lab? First, let me know whether sending all 32 bits of the window space did anything different from sending the shifted 16 top bits thereof ;-) (I don't know congestion control as well as some on this list; it seems like there might be an interaction lurking there, though). > I'm not saying you can't come up with something (e.g., something having > to do with the performance of a stack that supports multiple protocol > header types or something). But, I don't think there is anything much > that we could come back to in 2 or 3 years and say "yeah, it worked" or > "no, it didn't". So, for me, I'd throw it out at PS as the way to > extend TCP and that as people need "more" this is the way they get it > and that we're not going to give you more window space in another > "extended window scale" option or redefine the unused offset code points > to give you more option space or whatever. And, then, as you note let > the market decide. > > allman > > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu May 11 13:24:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeEtE-0007kN-0s; Thu, 11 May 2006 13:23:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeEtB-0007kH-V2 for tcpm@ietf.org; Thu, 11 May 2006 13:23:49 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeEtA-0003iC-KM for tcpm@ietf.org; Thu, 11 May 2006 13:23:49 -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 k4BHNjRU014666; Thu, 11 May 2006 10:23:45 -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 E890677AC21; Thu, 11 May 2006 13:23:43 -0400 (EDT) To: Joe Touch From: Mark Allman Subject: Re: middleboxes and Re: [tcpm] TCPx2 In-Reply-To: <44636B59.5080000@isi.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Lightning Crashes MIME-Version: 1.0 Date: Thu, 11 May 2006 13:23:43 -0400 Message-Id: <20060511172343.E890677AC21@guns.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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="===============0287671169==" Errors-To: tcpm-bounces@ietf.org --===============0287671169== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline I am purposely not addressing the experimental stuff. Really way to early to get into all that. > >> we need to be backward compatible (which admittedly this is not). > >> > >> And what then about backward compatibility? > > > > I don't even understand this comment. What are you asking? There > > is a straightforward fallback. > > The fallback is dual-stack, isn't it? That's fine, but not quite what > I would expect for standards-track. Yes, the fallback is "dual" stack. Except that it isn't very dual. I.e., except for the header construction / parsing it's pretty much the same. Don't read too much into that. I don't mean to be overly glib. But, it is very much the same protocol. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEY3MfWyrrWs4yIs4RAvjZAJ9Ouh5QlWFmtdwUd5Q1Xrrvv70IYgCfUD1O isorn831tCVTMNWsiBwVjzI= =+zIc -----END PGP SIGNATURE----- --=_bOundary-- --===============0287671169== 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 --===============0287671169==-- From tcpm-bounces@ietf.org Thu May 11 13:28:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeExF-0000kB-DZ; Thu, 11 May 2006 13:28:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeExE-0000k6-Ju for tcpm@ietf.org; Thu, 11 May 2006 13:28:00 -0400 Received: from mms2.broadcom.com ([216.31.210.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeExD-0003t5-9Q for tcpm@ietf.org; Thu, 11 May 2006 13:28:00 -0400 Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Thu, 11 May 2006 10:27:50 -0700 X-Server-Uuid: D9EB6F12-1469-4C1C-87A2-5E4C0D6F9D06 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id EAF372B0; Thu, 11 May 2006 10:27:49 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id B52572AE; Thu, 11 May 2006 10:27:49 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5-GA) with ESMTP id DMO06442; Thu, 11 May 2006 10:27:42 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id E6CB920501; Thu, 11 May 2006 10:27:41 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: middleboxes and Re: [tcpm] TCPx2 Date: Thu, 11 May 2006 10:27:43 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F149F039@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: middleboxes and Re: [tcpm] TCPx2 Thread-Index: AcZ0nsz5ne7XTONmTA+uy5n86YW/fQAgRvFQ From: "Caitlin Bestler" To: "Ethan Blanton" , tcpm@ietf.org X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006051105; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230322E34343633373230352E303034362D412D; ENG=IBF; TS=20060511172751; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006051105_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 687DAB9C4I88211438-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Ethan Blanton wrote: > Caitlin Bestler spake unto us the following wisdom: > [snip...] >> For example, this new option could say something as simple as "if we >> both agree to use the 'extended connection' feature then the first >> TCP segment we each send will be a special TCP segment that does not >> contain ULP payload but rather special option negotiations. (That's >> first TCP segment as sent, obviously the message should document its >> length in the first two bytes and the receiver should rely upon that >> length rather than on the actual segmentation). >>=20 >> If both sides do not speak the enhanced version then they simply go >> straight to the ULP payloads without enhancements. >> As far as any existing network element is concerned everything looks >> like a standard TCP connection, albeit one with some new-fangled >> option that is irrelevant to the network element. >=20 > As long as we're on the "but NATs really do suck!" bandwagon > ... this isn't really true. Try inserting some random goop > between byte 0 and the first data of an HTTP exchange, and > see how many middle boxes you break -- I bet it will be a nontrivial > number.=20 >=20 > Ethan Good point. The solution I suggested will deal with middleboxes that snoop up to L4 while pretending to provide an L3 service. But those that snoop all the way up to L7 are probably hopeless. Fortunately those tend to be deployed at the server end and are more frequently updated. The vast hordes of D-Link and Linksys wireless routers found in millions of homes only cheat up to L4. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu May 11 13:48:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeFGt-0000PD-8p; Thu, 11 May 2006 13:48:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeFGs-0000P8-5A for tcpm@ietf.org; Thu, 11 May 2006 13:48:18 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeFGq-0004k7-Nq for tcpm@ietf.org; Thu, 11 May 2006 13:48:18 -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 k4BHmFwG015085; Thu, 11 May 2006 10:48:15 -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 2FA9677AC21; Thu, 11 May 2006 13:48:14 -0400 (EDT) To: "Caitlin Bestler" From: Mark Allman Subject: Re: middleboxes and Re: [tcpm] TCPx2 In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F149F03C@NT-SJCA-0751.brcm.ad.broadcom.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Lightning Crashes MIME-Version: 1.0 Date: Thu, 11 May 2006 13:48:14 -0400 Message-Id: <20060511174814.2FA9677AC21@guns.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: tcpm@ietf.org, Joe Touch 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="===============0990517966==" Errors-To: tcpm-bounces@ietf.org --===============0990517966== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > mallman@icir.org wrote: > >> To me the critical issue is maintaining critical compatability and > >> interoperability. If you are going to lose those, then it is no > >> longer a minor modification. Further, it won't matter how useful it > >> is, it won't get deployed anytime soon. And I don't think that > >> calling it "TCPx2" or whatever will make it get required support > >> anytime sooner. > > > > I read the above as indicating that you do not believe that > > TCPx2 "maintains critical compatibility and > > interoperability". Is that a correct interpretation? If so, > > I'd like to hear the logic behind the statement, because from > > my seat compatibility and interoperability are maintained > > with the fallback to RFC793 TCP sketched in the i-d. (The > > clear case when that would break is when a stack supported > > TCPx2 and not TCPx1. But, since *it's (basically) the same > > protocol* it would seem stupid to go to x2 and not continue > > to grok x1.) > > > > If fallback is required it adds either to the latency of the > connection setup or places additional packets on the wire. Absolutely, no question. Latency and network traffic don't add up to "critical compatibility and interoperability" issues. *That* is my point. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEY3jeWyrrWs4yIs4RApAYAJ480smqT6/CiqMrYIlmsMNdJgoizQCghU5T Xt8BcRSYlh7TSElqTRv3K7E= =kPVQ -----END PGP SIGNATURE----- --=_bOundary-- --===============0990517966== 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 --===============0990517966==-- From tcpm-bounces@ietf.org Thu May 11 14:00:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeFRw-0007R5-PA; Thu, 11 May 2006 13:59:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeFRv-0007R0-IW for tcpm@ietf.org; Thu, 11 May 2006 13:59:43 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeFRu-0005DT-7M for tcpm@ietf.org; Thu, 11 May 2006 13:59:43 -0400 Received: from [128.9.160.144] (nib.isi.edu [128.9.160.144]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4BHwrV03391; Thu, 11 May 2006 10:58:53 -0700 (PDT) Message-ID: <44637B57.7080007@isi.edu> Date: Thu, 11 May 2006 10:58:47 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: mallman@icir.org Subject: Re: middleboxes and Re: [tcpm] TCPx2 References: <20060511174814.2FA9677AC21@guns.icir.org> In-Reply-To: <20060511174814.2FA9677AC21@guns.icir.org> X-Enigmail-Version: 0.94.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: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Mark Allman wrote: ... >> If fallback is required it adds either to the latency of the >> connection setup or places additional packets on the wire. > > Absolutely, no question. Latency and network traffic don't add up to > "critical compatibility and interoperability" issues. *That* is my > point. Er, isn't that why nobody is using IPv6 right now? The lack of a fallback that doesn't require dual-stack with parallel tests? That seems like _the_ critical interoperability issue that will affect deployment - as it already has. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu May 11 14:06:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeFYg-0004Vm-Si; Thu, 11 May 2006 14:06:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeFYg-0004Vh-Hi for tcpm@ietf.org; Thu, 11 May 2006 14:06:42 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeFYf-0005Sk-6n for tcpm@ietf.org; Thu, 11 May 2006 14:06:42 -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 k4BI6eaQ015450; Thu, 11 May 2006 11:06:40 -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 9BA4E77AC21; Thu, 11 May 2006 14:06:38 -0400 (EDT) To: Joe Touch From: Mark Allman Subject: Re: middleboxes and Re: [tcpm] TCPx2 In-Reply-To: <44637B57.7080007@isi.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Lightning Crashes MIME-Version: 1.0 Date: Thu, 11 May 2006 14:06:38 -0400 Message-Id: <20060511180638.9BA4E77AC21@guns.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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="===============0629434306==" Errors-To: tcpm-bounces@ietf.org --===============0629434306== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > Mark Allman wrote: > ... > >> If fallback is required it adds either to the latency of the > >> connection setup or places additional packets on the wire. > > > > Absolutely, no question. Latency and network traffic don't add up to > > "critical compatibility and interoperability" issues. *That* is my > > point. > > Er, isn't that why nobody is using IPv6 right now? The lack of a > fallback that doesn't require dual-stack with parallel tests? > > That seems like _the_ critical interoperability issue that will affect > deployment - as it already has. You're beyond my reading level again. I can't parse this at all. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEY30uWyrrWs4yIs4RAhPrAJ9LsNbIPLz9Ec3NE797tUNvV3Vd2QCfT7dJ dmUi+/A2aT+c+zO7HweobiI= =smZ+ -----END PGP SIGNATURE----- --=_bOundary-- --===============0629434306== 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 --===============0629434306==-- From tcpm-bounces@ietf.org Thu May 11 14:34:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeFyw-0000Oj-1r; Thu, 11 May 2006 14:33:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeFyu-0000Oe-8M for tcpm@ietf.org; Thu, 11 May 2006 14:33:48 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeFDy-0004Zk-SL for tcpm@ietf.org; Thu, 11 May 2006 13:45:18 -0400 Received: from mms1.broadcom.com ([216.31.210.17]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FeF0X-00034R-Eb for tcpm@ietf.org; Thu, 11 May 2006 13:31:30 -0400 Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Thu, 11 May 2006 10:31:16 -0700 X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 79C312B0; Thu, 11 May 2006 10:31:16 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 50DE62AF; Thu, 11 May 2006 10:31:16 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5-GA) with ESMTP id DMO08095; Thu, 11 May 2006 10:31:10 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id D3DF920501; Thu, 11 May 2006 10:31:10 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: middleboxes and Re: [tcpm] TCPx2 Date: Thu, 11 May 2006 10:31:10 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F149F03C@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: middleboxes and Re: [tcpm] TCPx2 Thread-Index: AcZ0qpTF5sY8x0SpQMO71FadK7N+0QAdc72A From: "Caitlin Bestler" To: mallman@icir.org X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006051105; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230312E34343633373244342E303036302D412D; ENG=IBF; TS=20060511173117; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006051105_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 687DAB6E0HW15427099-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.8 (-) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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: , Errors-To: tcpm-bounces@ietf.org mallman@icir.org wrote: >> To me the critical issue is maintaining critical compatability and >> interoperability. If you are going to lose those, then it is no >> longer a minor modification. Further, it won't matter how useful it >> is, it won't get deployed anytime soon. And I don't think that >> calling it "TCPx2" or whatever will make it get required support >> anytime sooner.=20 >=20 > I read the above as indicating that you do not believe that > TCPx2 "maintains critical compatibility and > interoperability". Is that a correct interpretation? If so, > I'd like to hear the logic behind the statement, because from > my seat compatibility and interoperability are maintained > with the fallback to RFC793 TCP sketched in the i-d. (The > clear case when that would break is when a stack supported > TCPx2 and not TCPx1. But, since *it's (basically) the same > protocol* it would seem stupid to go to x2 and not continue > to grok x1.) >=20 If fallback is required it adds either to the latency of the connection setup or places additional packets on the wire. What I was suggesting was a packet that would pass through=20 "TCPx1"-only network elements unmolested but uninterpreted. Then we only have to deal with the question of whether the two endpoints understand the upgrade option. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu May 11 15:01:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeGP9-0003TW-It; Thu, 11 May 2006 15:00:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeGP8-0003J1-Bv for tcpm@ietf.org; Thu, 11 May 2006 15:00:54 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeGP7-00089Z-1E for tcpm@ietf.org; Thu, 11 May 2006 15:00:54 -0400 Received: from [128.9.160.144] (nib.isi.edu [128.9.160.144]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4BJ0JV19791; Thu, 11 May 2006 12:00:19 -0700 (PDT) Message-ID: <446389BC.5060603@isi.edu> Date: Thu, 11 May 2006 12:00:12 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: mallman@icir.org Subject: Re: middleboxes and Re: [tcpm] TCPx2 References: <20060511180638.9BA4E77AC21@guns.icir.org> In-Reply-To: <20060511180638.9BA4E77AC21@guns.icir.org> X-Enigmail-Version: 0.94.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: b19722fc8d3865b147c75ae2495625f2 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Mark Allman wrote: >> Mark Allman wrote: >> ... >>>> If fallback is required it adds either to the latency of the >>>> connection setup or places additional packets on the wire. >>> Absolutely, no question. Latency and network traffic don't add up to >>> "critical compatibility and interoperability" issues. *That* is my >>> point. >> Er, isn't that why nobody is using IPv6 right now? The lack of a >> fallback that doesn't require dual-stack with parallel tests? >> >> That seems like _the_ critical interoperability issue that will affect >> deployment - as it already has. > > You're beyond my reading level again. I can't parse this at all. Sorry - I need that second cup of coffee. In full sentences: IMO, "critical compatibility and interoperability" are defeated by dual-stack. That's what has killed IPv6 - even those of us who want to transition are hit by the dual-stack problem. Once I enable IPv6, my apps need to try both versions in parallel to work; since they don't, things silently fail when IPv6 isn't available. I.e., simple, default backward compatibility is exactly what is needed to get something out there right now. We tried dual-stack as a solution, and IMO it ended up killing deployment. We don't need to try it again. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu May 11 15:08:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeGW4-0002Ag-JI; Thu, 11 May 2006 15:08:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeGW2-0002Ab-Vj for tcpm@ietf.org; Thu, 11 May 2006 15:08:02 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeGW1-0008OV-Kq for tcpm@ietf.org; Thu, 11 May 2006 15:08:02 -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 k4BJ7wXN016588; Thu, 11 May 2006 12:07:58 -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 D62F977AC21; Thu, 11 May 2006 15:07:56 -0400 (EDT) To: Joe Touch From: Mark Allman Subject: Re: middleboxes and Re: [tcpm] TCPx2 In-Reply-To: <446389BC.5060603@isi.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Lightning Crashes MIME-Version: 1.0 Date: Thu, 11 May 2006 15:07:56 -0400 Message-Id: <20060511190756.D62F977AC21@guns.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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="===============0216287836==" Errors-To: tcpm-bounces@ietf.org --===============0216287836== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > Sorry - I need that second cup of coffee. Heh. > In full sentences: > > IMO, "critical compatibility and interoperability" are defeated by > dual-stack. That's what has killed IPv6 - even those of us who want to > transition are hit by the dual-stack problem. Once I enable IPv6, my > apps need to try both versions in parallel to work; since they don't, > things silently fail when IPv6 isn't available. > > I.e., simple, default backward compatibility is exactly what is needed > to get something out there right now. We tried dual-stack as a > solution, and IMO it ended up killing deployment. We don't need to try > it again. This is not as dual-stack as IP. It's the same protocol. Why even bother to get the apps involved in TCPx1 vs. TCPx2 unless they want to be inserted for whatever reason and do something explicit? The service provided to the app is the same. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEY4uMWyrrWs4yIs4RAsFeAJ9QqSIHi/yn+w0/X4rc4F6Rfe7i8gCbBTTn VTp7F9mTQSKwNwK/Uu+ZPWA= =3pIB -----END PGP SIGNATURE----- --=_bOundary-- --===============0216287836== 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 --===============0216287836==-- From tcpm-bounces@ietf.org Thu May 11 17:18:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeIXl-0006dw-P9; Thu, 11 May 2006 17:17:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeIXk-0006bT-Kc for tcpm@ietf.org; Thu, 11 May 2006 17:17:56 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeIXj-0006tp-CJ for tcpm@ietf.org; Thu, 11 May 2006 17:17:56 -0400 Received: from [12.208.123.114] (helo=elb.elitists.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FeIXi-000MSh-TC for tcpm@ietf.org; Thu, 11 May 2006 21:17:55 +0000 Received: from elitists.net (colt [192.168.33.1]) by elb.elitists.net (Postfix) with ESMTP id 5AF8E2BE1F for ; Thu, 11 May 2006 16:17:54 -0500 (EST) Received: by elitists.net (Postfix, from userid 3000) id 894A3F452; Thu, 11 May 2006 16:17:53 -0500 (EST) Date: Thu, 11 May 2006 17:17:53 -0400 From: Ethan Blanton To: tcpm@ietf.org Subject: Re: middleboxes and Re: [tcpm] TCPx2 Message-ID: <20060511211753.GR1153@localhost.localdomain> Mail-Followup-To: tcpm@ietf.org References: <20060511174814.2FA9677AC21@guns.icir.org> <44637B57.7080007@isi.edu> Mime-Version: 1.0 In-Reply-To: <44637B57.7080007@isi.edu> X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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="===============1888538832==" Errors-To: tcpm-bounces@ietf.org --===============1888538832== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MUnXZt0Uv08c1hBe" Content-Disposition: inline --MUnXZt0Uv08c1hBe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Joe Touch spake unto us the following wisdom: > Mark Allman wrote: > ... > >> If fallback is required it adds either to the latency of the > >> connection setup or places additional packets on the wire. > >=20 > > Absolutely, no question. Latency and network traffic don't add up to > > "critical compatibility and interoperability" issues. *That* is my > > point. >=20 > Er, isn't that why nobody is using IPv6 right now? The lack of a > fallback that doesn't require dual-stack with parallel tests? Well, that and the fact that nobody else has an IPv6 address, either. 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 --MUnXZt0Uv08c1hBe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEY6oBr9kA9Ig8HBQRAnfJAKDDYJYcnF4IMwiFpsUmNrNWsfjmcwCgreFf aOWrisOYrYRfn3Xd0r41OmQ= =Lykj -----END PGP SIGNATURE----- --MUnXZt0Uv08c1hBe-- --===============1888538832== 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 --===============1888538832==-- From tcpm-bounces@ietf.org Thu May 11 18:03:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeJFP-0004wE-BY; Thu, 11 May 2006 18:03:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeJFP-0004w9-0M for tcpm@ietf.org; Thu, 11 May 2006 18:03:03 -0400 Received: from dsl092-066-146.bos1.dsl.speakeasy.net ([66.92.66.146] helo=alva.home) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeJF3-00008n-Mj for tcpm@ietf.org; Thu, 11 May 2006 18:03:02 -0400 Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1FeJEp-0002s5-00; Thu, 11 May 2006 18:02:27 -0400 From: Tim Shepard To: Ethan Blanton Subject: Re: middleboxes and Re: [tcpm] TCPx2 In-reply-to: Your message of Thu, 11 May 2006 17:17:53 -0400. <20060511211753.GR1153@localhost.localdomain> Date: Thu, 11 May 2006 18:02:27 -0400 Message-Id: X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org > Well, that and the fact that nobody else has an IPv6 address, either. > Anyone who has a single globally routable IPv4 address has 2^80 IPv6 addresses. Read rfc3056.txt and rfc3068.txt and be enlightened. Someone pointed those out rfc3068 to me when I was at the IETF in Yokohama (4 years ago). I already mostly understood rfc3056.txt. Soon after I got home from that IETF I used this new found enlightenment to get myself IPv6 service at home without the cooperation of my ISP. I typed a few lines on my Debian/Linux machine and then had a look at http://www.kame.net/ in my web browser and the turtle was dancing. I then added an IPv6 address for a small web server I have running at home to the DNS entry for it (maintained by zoneedit.com) and that has been working fine ever since (over 3.5 years). What's nice about this is it neatly solves the "My ISP will only give me one routable address, but I have multiple machines on my LAN at home that I want to be able to open ssh connections to."-problem. I've also noticed that outside the US, people seem to be much more aware of the reality of IPv6. I would agree that in the US there's not yet any pressing need to go IPv6 live. But given how easy it is to do, if the slightest need to be IPv6 live should surface, we could find that IPv6 is turned on most everywhere almost overnight. IPv4 is so 20th century. -Tim Shepard shep@alum.mit.edu _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu May 11 18:13:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeJPL-0006R1-Ei; Thu, 11 May 2006 18:13:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeJPK-0006Qv-25 for tcpm@ietf.org; Thu, 11 May 2006 18:13:18 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeJPI-0000lD-GC for tcpm@ietf.org; Thu, 11 May 2006 18:13:18 -0400 Received: from fgont.gont.com.ar ([201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4BMCsaN031862; Thu, 11 May 2006 19:13:00 -0300 Message-Id: <7.0.1.0.0.20060511190644.04add798@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 11 May 2006 19:11:44 -0300 To: rbonica@juniper.net, 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: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [tcpm] Some feedback on draft-bonica-tcp-auth-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Ron, Going through draft-bonica-tcp-auth-04.txt, I see that the issue of ICMP-based attacks is left open (as is the case with the TCP MD5 option). I'd suggest to either completely ignore ICMP error messages when your strategy is implemented, or make the implementation of the counter-measures described in the ICMP attacks draft mandatory. If not, even when you would be protecting TCP from TCP-based reset attacks, for example, ICMP-based ones might still work. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu May 11 18:16:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeJRs-0000bm-9C; Thu, 11 May 2006 18:15:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeJRq-0000bg-NM for tcpm@ietf.org; Thu, 11 May 2006 18:15:54 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeJRp-0000we-Ee for tcpm@ietf.org; Thu, 11 May 2006 18:15:54 -0400 Received: from [12.208.123.114] (helo=elb.elitists.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FeJRo-0000K6-PY for tcpm@ietf.org; Thu, 11 May 2006 22:15:53 +0000 Received: from elitists.net (colt [192.168.33.1]) by elb.elitists.net (Postfix) with ESMTP id 359AB2BE1F for ; Thu, 11 May 2006 17:15:52 -0500 (EST) Received: by elitists.net (Postfix, from userid 3000) id 64799F452; Thu, 11 May 2006 17:15:51 -0500 (EST) Date: Thu, 11 May 2006 18:15:51 -0400 From: Ethan Blanton To: tcpm@ietf.org Subject: Re: middleboxes and Re: [tcpm] TCPx2 Message-ID: <20060511221551.GA26808@localhost.localdomain> Mail-Followup-To: tcpm@ietf.org References: <20060511211753.GR1153@localhost.localdomain> Mime-Version: 1.0 In-Reply-To: X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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="===============1377334026==" Errors-To: tcpm-bounces@ietf.org --===============1377334026== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J/dobhs11T7y2rNN" Content-Disposition: inline --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Tim Shepard spake unto us the following wisdom: > > Well, that and the fact that nobody else has an IPv6 address, either. >=20 > Anyone who has a single globally routable IPv4 address has 2^80 IPv6 addr= esses. >=20 > Read rfc3056.txt and rfc3068.txt and be enlightened.=20 I have read them, I have 6to4 addresses and have had them for some years (and a dedicated tunnel before that). That makes me one of the few. Now I can unreliably communicate with those few others via tunnels through God-knows-where with horrible latency and loss ratio compared to direct IPv4 connection, and with a much greater chance of something systematically eating my packets along the way. I can also look forward to connections failing due to sites advertising IPv6 addresses which they toyed with at some point when they thought IPv6 might be going somewhere, and have subsequently abandoned. Add to this a half dozen other pitfalls, and... But I suppose this is off-topic, aside from underscoring the unfortunate difficulty of rolling out any sort of new protocol into the entrenched Internet. 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 --J/dobhs11T7y2rNN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEY7eXr9kA9Ig8HBQRAgelAKCkWCe1ztZwmjVEn+2+SsykLPfgNwCgilk8 He8kbDWx5xIWe9T1qFSXMZA= =3aed -----END PGP SIGNATURE----- --J/dobhs11T7y2rNN-- --===============1377334026== 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 --===============1377334026==-- From tcpm-bounces@ietf.org Thu May 11 20:08:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeLC7-0001IR-8T; Thu, 11 May 2006 20:07:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeLC6-0001IM-14 for tcpm@ietf.org; Thu, 11 May 2006 20:07:46 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeLC4-0005sJ-Md for tcpm@ietf.org; Thu, 11 May 2006 20:07:46 -0400 Received: from [128.9.160.144] (nib.isi.edu [128.9.160.144]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4C06cV01446; Thu, 11 May 2006 17:06:38 -0700 (PDT) Message-ID: <4463D188.1070400@isi.edu> Date: Thu, 11 May 2006 17:06:32 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] Some feedback on draft-bonica-tcp-auth-04.txt References: <7.0.1.0.0.20060511190644.04add798@gont.com.ar> In-Reply-To: <7.0.1.0.0.20060511190644.04add798@gont.com.ar> X-Enigmail-Version: 0.94.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: 93238566e09e6e262849b4f805833007 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Fernando Gont wrote: > Ron, > > Going through draft-bonica-tcp-auth-04.txt, I see that the issue of > ICMP-based attacks is left open (as is the case with the TCP MD5 option). > > I'd suggest to either completely ignore ICMP error messages when your > strategy is implemented, or make the implementation of the > counter-measures described in the ICMP attacks draft mandatory. > > If not, even when you would be protecting TCP from TCP-based reset > attacks, for example, ICMP-based ones might still work. It's worth noting that TCP and IPsec protection don't address ICMP issues, except that IPsec recommends dropping certain kinds of ICMP messages. It'd be useful to cite 4301 in that regard, IMO. (FWIW, the ICMP attacks draft is very weak on its citation of 2401/4301 in this regard; those docs, as Kent points out, already note that certain ICMP messages should be dropped in an IPsec'd environment). Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu May 11 23:32:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeONJ-0004Fz-Ji; Thu, 11 May 2006 23:31:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeONH-0004Fu-Sp for tcpm@ietf.org; Thu, 11 May 2006 23:31:31 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeOND-0007Kh-9H for tcpm@ietf.org; Thu, 11 May 2006 23:31:31 -0400 Received: from fgont.gont.com.ar ([201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4C3VOdr004218; Fri, 12 May 2006 00:31:27 -0300 Message-Id: <7.0.1.0.0.20060511235829.04b15d30@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 12 May 2006 00:03:42 -0300 To: Joe Touch From: Fernando Gont Subject: Re: [tcpm] Some feedback on draft-bonica-tcp-auth-04.txt In-Reply-To: <4463D188.1070400@isi.edu> References: <7.0.1.0.0.20060511190644.04add798@gont.com.ar> <4463D188.1070400@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: , Errors-To: tcpm-bounces@ietf.org At 21:06 11/05/2006, Joe Touch wrote: >(FWIW, the ICMP attacks draft is very weak on its citation of 2401/4301 >in this regard; those docs, as Kent points out, already note that >certain ICMP messages should be dropped in an IPsec'd environment). IIRC, at least 2401 was not specific on which messages to drop. And even 4301 says that there should be a system toggle to define what to do. For instance, I think the spec does not say what this toggle should default to. As mentioned by Pekka in RFC 4459, IPSec protection from ICMP attacks, if any, is based on a number of assumptions from the reader. Anyway, will go through 4301, and try to make its citation better, if possible. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri May 12 11:24:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeZUa-0006V3-OY; Fri, 12 May 2006 11:23:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeZUZ-0006Uy-Rb for tcpm@ietf.org; Fri, 12 May 2006 11:23:47 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeZUX-0001Ge-FH for tcpm@ietf.org; Fri, 12 May 2006 11:23:47 -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 k4CFNQUO036945; Fri, 12 May 2006 08:23:31 -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 AE91A77B3C1; Fri, 12 May 2006 11:23:25 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 205D240CAF6; Fri, 12 May 2006 10:35:26 -0400 (EDT) To: "Armando L. Caro, Jr." From: Mark Allman Subject: Re: [tcpm] TCPx2 In-Reply-To: <4461EFE6.1080508@bbn.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Lightning Crashes MIME-Version: 1.0 Date: Fri, 12 May 2006 10:35:25 -0400 Message-Id: <20060512143526.205D240CAF6@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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="===============1571150822==" Errors-To: tcpm-bounces@ietf.org --===============1571150822== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > Well the TCPx2 endpoints would require more state. The initial window > of data will be acked as TCP (not TCPx2) data. Even the though the > sender has upgraded to TCPx2, it knows that the first window of data > was sent with TCP, and thus accepts the acks for the initial window > only. > > I admit it seems to be getting messy, but I don't think it's all that > bad. The main problem I see is security. It may become easy to hijack > a connection. But, how do you deal with the application? If the connection asks for some option that can only be done in TCPx2 and we fall into this weird "we didn't use it at first but now we do" sort of state then how is that communicated? I guess I just keep coming back to the fact that we're not in a synchronized state if two SYNs are in play. > > But, it seems to me that this is roughly similar to just sending an > > x2 SYN first and then a bit later sending TCP SYN. > > Yes, similar... but not the same as waiting for the TCPx2 syn to > timeout before sending a TCP syn. I think it's all very similar, but you're right that there are tradeoffs. Two cases: (1) Send a TCPx2 SYN, X msec later send a TCPx1 SYN if SYN+ACK has not come back. (2) Send TCPx2 and TCPx1 SYNs together. If the TCPx1 SYN+ACK comes in first, wait X msec before the connection continues to ensure the TCPx2 SYN+ACK will not come in. These are not the same, but similar. Basically, we delay for fallback in both cases. I don't have much preference for (1) or (2), but I'd like to "synchronize" before we start sending data because I think any other case is messy. (And, I also like the idea of suggestion that hosts try to cache peer's x1 vs. x2 abilities. So, e.g., on subsequent HTTP connections this dance is not needed.) allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEZJ0tWyrrWs4yIs4RAhJYAJ9b8PLhLLqz8R4rBNHH+myd05zOmwCeNprD 4jQQF5ljIUS3n+/VRKupvBo= =dZEk -----END PGP SIGNATURE----- --=_bOundary-- --===============1571150822== 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 --===============1571150822==-- From tcpm-bounces@ietf.org Fri May 12 14:22:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FecHO-0005hb-W0; Fri, 12 May 2006 14:22:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FecHN-0005hV-Mh for tcpm@ietf.org; Fri, 12 May 2006 14:22:21 -0400 Received: from palrel11.hp.com ([156.153.255.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FecHI-0002Gf-DQ for tcpm@ietf.org; Fri, 12 May 2006 14:22:21 -0400 Received: from smtp2.ptp.hp.com (hpda.cup.hp.com [15.1.28.240]) by palrel11.hp.com (Postfix) with ESMTP id 76C02387CD for ; Fri, 12 May 2006 11:22:13 -0700 (PDT) Received: from [16.89.245.39] (unknown [16.89.245.39]) by smtp2.ptp.hp.com (Postfix) with ESMTP id 5A0D4252BC5 for ; Fri, 12 May 2006 18:22:13 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v623) Content-Transfer-Encoding: 7bit Message-Id: <72ac70ec93cffc1f6c5af924a9cbb0af@cup.hp.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: tcpm@ietf.org From: William Gilliam Date: Fri, 12 May 2006 11:22:12 -0700 X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [tcpm] Can we advance F-RTO from Experimental? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org TCPM folks, At the Vancouver (IETF 64) meeting, during the discussion about possibly advancing some RFCs, I suggested that it may be time to consider moving F-RTO (RFC 4138) from Experimental to Standards-Track. I'd now like to pass this suggestion on to the folks on the mailing-list. In the Paris meeting (IETF 63), Kazunori Yamamoto presented the positive results of field testing F-RTO. (The presentation slides are available at http://www3.ietf.org/proceedings/05aug/slides/tcpm-4/sld1.htm.) Implementations of F-RTO are currently deployed in Linux and HP-UX, and it seems that an implementation is part of Microsoft Windows Vista and Longhorn (according to http://www.microsoft.com/technet/community/columns/cableguy/ cg1105.mspx). Have there been any reports of F-RTO hurting the network? Personally, I haven't heard any, but I'd be interested in hearing whatever relevant reports are available. Thanks. WG _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon May 15 09:14:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffcsz-00012s-K8; Mon, 15 May 2006 09:13:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffcsy-00012m-9l for tcpm@ietf.org; Mon, 15 May 2006 09:13:20 -0400 Received: from web33309.mail.mud.yahoo.com ([68.142.206.124]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ffcsx-00036Q-0L for tcpm@ietf.org; Mon, 15 May 2006 09:13:20 -0400 Received: (qmail 2576 invoked by uid 60001); 15 May 2006 13:13:18 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=KScGsswbNuH4PAWStd2mbFT7TrESV1gtBfl2YKevcE9DCWwz6quIgYfTV50e/7SsahpeRUBCyLXdW3rPYFCzCqQoUQKlOlLirH05YPrq3nH6TWfLEyZSLGVL9pTG6B07UqTr7fpa8kcbsHAnLslbGuRcCQll3TLmc5B35ti2CmM= ; Message-ID: <20060515131318.2574.qmail@web33309.mail.mud.yahoo.com> Received: from [69.236.76.106] by web33309.mail.mud.yahoo.com via HTTP; Mon, 15 May 2006 06:13:18 PDT Date: Mon, 15 May 2006 06:13:18 -0700 (PDT) From: Pyda Srisuresh To: tcpm@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: fernando@gont.com.ar Subject: [tcpm] Comments on draft-ietf-tcpm-icmp-attacks-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Fernando, Nice job overall on the draft. The draft is focussed as a laser beam on both the vulnerabilities and the counter measures. I found the document easy to read and understand. It is apparant, the document is well thought out. Thank you. Below are my comments. 1. Section 4.3 - Filtering ICMP error messages based on the ICMP payload Below is text from section 4.3. "However, a more advanced packet filtering could be implemented in firewalls as a counter-measure. Firewalls implementing such advanced filtering would look at the payload of the ICMP error messages, and would perform ingress and egress packet filtering based on the source IP address of the IP header contained in the payload of the ICMP error message." I would suggest replacing the term "firewalls" with "middlebox devices such as Firewalls and NATs" in the above text. I believe, the text is directly applicable to NATs, because NATs are also intermediate stateful devices. NATs can also lookup the ICMP error payload and determine if it has prior mapping (i.e, NAT Session) for the payload and drop the packet when there is no prior mapping. 2. Appendix C - This is useful information. Why not move this to the main body in section 4? Thanks. regards, suresh _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue May 16 10:35:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg0e1-0007dy-S7; Tue, 16 May 2006 10:35:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg0dz-0007Zo-T6 for tcpm@ietf.org; Tue, 16 May 2006 10:35:27 -0400 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg0dz-0000zk-Ez for tcpm@ietf.org; Tue, 16 May 2006 10:35:27 -0400 Received: from pc6 (1Cust30.tnt14.lnd4.gbr.da.uu.net [62.188.143.30]) by astro.systems.pipex.net (Postfix) with SMTP id 1EF6DE0001A1; Tue, 16 May 2006 15:35:18 +0100 (BST) Message-ID: <034301c678ed$24757ea0$0601a8c0@pc6> From: "Tom Petch" To: , References: <20060418135453.DAC3C77AF38@guns.icir.org> Subject: Re: Lars Eggert: [tcpm] draft-ietf-behave-tcp-00 Date: Tue, 16 May 2006 15:32:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org I looked, took a few Paracetamol, looked some more and still think this is not fit to advance; it is or is likely to be incomprehensible to many intended readers. Not surprisingly, then, I find it hard to give specific, tcp-technical reasons why - eg REQ-3 is wrong because it does not take cognizance of para x in RFCyyyy; rather, it is the 'first impressions count', the look and feel that convinces me that this I-D is not fit. First page and there are too many editors for the RFC Editor's liking. Move on to 'Applicability' and it is very clear: 'Application and OS aspects of TCP NAT traversal are out-of-scope'; but wait for section 6, "6. Application Level Gateways FIXME OPEN ISSUE: Is this out-of-scope? Do we need to specify all TCP ALGs should be off by default? What about FTP?" (good questions). The document is written in an unfamiliar (to me) language of NAT-specific technical terms, for which the reader is referred to FIXME-BEHAVE-UDP (sic) which is in fact draft-ietf-behave-nat-udp-06 (the subject of recent criticism on the main IETF list). This has a poorly laid out section on Terminology which urges the reader "to refer to RFC 2263 [8] for information on NAT taxonomy and terminology" (in passing, RFC2263 is SNMP Applications from one of the abortive starts on SNMPv3) and ends with comments that the terminology from RFC3489 {STUN} "has been the source of much confusion as it has proven inadequate..." (yes, feels about right). In between, this section makes no mention of several of the terms in use (eg Address and Port Dependent Mapping) so the reader of behave-tcp must read and digest behave-udp (and RFC2263) before starting. A simple example on terminology; these I-D take terms like internal and external for granted; well yes, I can deduce what they mean but what is internal to an ISP is not internal to an ISP's customer and vice versa; it would be so easy to make the meaning clear (like, a diagram). This I-D has normative references to NUTSS and NATBLASTER in the shape of SIGCOMM Proceedings which suggests to me that the intended audience is rather esoteric. As I said, none of this is hard, tcp-related reasons why I regard this I-D as unfit to advance but I think it does give the flavour. I note that the only reference to TCP is to RFC793, which, great as it is, is not the TCP used in most sessions today (are the editors aware of this?). The I-D should at least reference the recent Roadmap and say whether or not the many later additions to TCP are relevant to NATs or not. Overall, I think that behave is on the wrong track; this I-D reads like an afterthought tacked onto UDP-related work by someone keen on gaming. Rather, they should first produce an update to RFC2263 on NAT in general, with clear concepts and related terminology, and then produce separate I-D for UDP and TCP (and DCCP and STCP and etc etc) which refer back to this common work. The idea that someone concerned with TCP should first become a master of UDP and NUTSS is, well nuts:-) Tom Petch ----- Original Message ----- From: "Mark Allman" To: Sent: Tuesday, April 18, 2006 3:54 PM Subject: Lars Eggert: [tcpm] draft-ietf-behave-tcp-00 > > Folks- > > Lars sent the attached request a few weeks back and we haven't heard > anything. Could a couple of folks volunteer to take a look at this > document in the next week or two (it's pretty short)? > > (And, send along a note to me indicating that you intend to do so, else > I'll have to try to poll people specifically.) > > Thanks! > > allman > > > > -------------------------------------------------------------------------------- > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue May 16 12:12:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg29m-0001am-E6; Tue, 16 May 2006 12:12:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg29l-0001a5-R3 for tcpm@ietf.org; Tue, 16 May 2006 12:12:21 -0400 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg29l-00082G-8e for tcpm@ietf.org; Tue, 16 May 2006 12:12:21 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id B9F1B2007D5F; Tue, 16 May 2006 18:12:36 +0200 (CEST) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25774-10; Tue, 16 May 2006 18:12:36 +0200 (CEST) Received: from venus.office (europa.netlab.nec.de [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 981A220001B5; Tue, 16 May 2006 18:12:36 +0200 (CEST) Received: from n-eggert.office ([10.1.1.112]) by venus.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 18:12:20 +0200 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n-eggert.office (Postfix) with ESMTP id AAB4CC4639; Tue, 16 May 2006 18:12:19 +0200 (CEST) In-Reply-To: <034301c678ed$24757ea0$0601a8c0@pc6> References: <20060418135453.DAC3C77AF38@guns.icir.org> <034301c678ed$24757ea0$0601a8c0@pc6> Mime-Version: 1.0 (Apple Message framework v750) X-Priority: 3 Message-Id: From: Lars Eggert Subject: Re: Lars Eggert: [tcpm] draft-ietf-behave-tcp-00 Date: Tue, 16 May 2006 18:12:18 +0200 To: Tom Petch X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 16 May 2006 16:12:20.0332 (UTC) FILETIME=[8239B2C0:01C67903] X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) X-Spam-Score: 0.1 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Cc: tcpm@ietf.org, mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1132210330==" Errors-To: tcpm-bounces@ietf.org --===============1132210330== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-84--162469202; protocol="application/pkcs7-signature" --Apple-Mail-84--162469202 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Tom, thanks for the review! I forwarded your review to the behave list, where any follow-on discussion should take place (in case other TCPM folks would like to participate). Lars On May 16, 2006, at 15:32, Tom Petch wrote: > I looked, took a few Paracetamol, looked some more and still think > this is not > fit to advance; it is or is likely to be incomprehensible to many > intended > readers. > > Not surprisingly, then, I find it hard to give specific, tcp- > technical reasons > why - eg REQ-3 is wrong because it does not take cognizance of > para x in > RFCyyyy; rather, it is the 'first impressions count', the look and > feel that > convinces me that this I-D is not fit. > > First page and there are too many editors for the RFC Editor's > liking. Move on > to 'Applicability' and it is very clear: 'Application and OS > aspects of TCP > NAT traversal are out-of-scope'; but wait for section 6, > "6. Application Level Gateways > FIXME OPEN ISSUE: Is this out-of-scope? Do we need to specify all > TCP ALGs should be off by default? What about FTP?" > (good questions). > > The document is written in an unfamiliar (to me) language of NAT- > specific > technical terms, for which the reader is referred to FIXME-BEHAVE- > UDP (sic) > which is in fact draft-ietf-behave-nat-udp-06 (the subject of > recent criticism > on the main IETF list). This has a poorly laid out section on > Terminology which > urges the reader > "to refer to RFC 2263 [8] for information on NAT taxonomy and > terminology" > (in passing, RFC2263 is SNMP Applications from one of the abortive > starts on > SNMPv3) and ends with comments that the terminology from RFC3489 > {STUN} > "has been the source of much confusion as it has proven inadequate..." > (yes, feels about right). In between, this section makes no > mention of several > of the terms in use (eg Address and Port Dependent Mapping) so the > reader of > behave-tcp must read and digest behave-udp (and RFC2263) before > starting. > > A simple example on terminology; these I-D take terms like internal > and external > for granted; well yes, I can deduce what they mean but what is > internal to an > ISP is not internal to an ISP's customer and vice versa; it would > be so easy to > make the meaning clear (like, a diagram). > > This I-D has normative references to NUTSS and NATBLASTER in the > shape of > SIGCOMM Proceedings which suggests to me that the intended > audience is rather > esoteric. > > As I said, none of this is hard, tcp-related reasons why I regard > this I-D as > unfit to advance but I think it does give the flavour. > > I note that the only reference to TCP is to RFC793, which, great as > it is, is > not the TCP used in most sessions today (are the editors aware of > this?). The > I-D should at least reference the recent Roadmap and say whether or > not the many > later additions to TCP are relevant to NATs or not. > > Overall, I think that behave is on the wrong track; this I-D reads > like an > afterthought tacked onto UDP-related work by someone keen on > gaming. Rather, > they should first produce an update to RFC2263 on NAT in general, > with clear > concepts and related terminology, and then produce separate I-D for > UDP and TCP > (and DCCP and STCP and etc etc) which refer back to this common > work. The idea > that someone concerned with TCP should first become a master of UDP > and NUTSS > is, well nuts:-) > > Tom Petch > > ----- Original Message ----- > From: "Mark Allman" > To: > Sent: Tuesday, April 18, 2006 3:54 PM > Subject: Lars Eggert: [tcpm] draft-ietf-behave-tcp-00 > > >> >> Folks- >> >> Lars sent the attached request a few weeks back and we haven't heard >> anything. Could a couple of folks volunteer to take a look at this >> document in the next week or two (it's pretty short)? >> >> (And, send along a note to me indicating that you intend to do so, >> else >> I'll have to try to poll people specifically.) >> >> Thanks! >> >> allman -- Lars Eggert NEC Network Laboratories --Apple-Mail-84--162469202 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKgzCCAyAw ggKJoAMCAQICAw9TWTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE4MTAyOTU2WhcNMDYwODE4MTAyOTU2WjBgMQ8wDQYDVQQE EwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA2gsuG8tAmM6U2ESsQjhcijJSq6oDG2c+KvvXJ/xcJXbSIOY8IInezIP0DP41H0gxwHNv AyOuwM6nh0r2wOhzdr77GlKXiij0LoFOpurScPKsC9KTykGAfZtAuCnWIRdDo67Urcw1e306yYgK xF1UzYwGamLalPjejQTRcjLPIbzM4c7fUN/sxmpkpzT2p6OCJDyPhBfSaZWtv3UEoKF+xssNYzOF DRCTHcLc3iXgF7z7J0ud8maUAadfb/25Gm7tJHzBOEonMPkHx2N8Ci0qNce0MMH/LVOVQlNO5kYJ vUJiT0du7LAo/hf8tq3luZrh/Cwc/313x6oKYVuHDBllrQIDAQABo2IwYDAqBgUrZQEEAQQhMB8C AQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCQGA1UdEQQdMBuBGWxhcnMuZWdnZXJ0QG5l dGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAovojiq8758E/78nMS vNvD4359F8XAICzWbhz6cXJaGzv1FJoQcV/RY1x6CQZDt9PqiPiqyQX+xLvqicmEURbGU5+aiWj2 usovQXd+Ts8Doj3tbjk35nD7Etc8a2+Y9fQRUS6spzgJr0fcq2FMYbDnOtf71Bn77KgckoUbIszu mTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl ZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNa LIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1Ud HwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVs Mi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa 9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggQYMIIDgaADAgECAgEAMA0G CSqGSIb3DQEBBQUAMIG/MQswCQYDVQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVy ZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsT FE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkq hkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGUwHhcNMDQwNjE4MTE1MzA4WhcNMDkw NjE3MTE1MzA4WjCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcx EzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExRO ZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZI hvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQC0OQwsE86Rrt0Zs0GOCsYmkGpPwcCFvVpOijIPv1dGolr5a8+7hXSAgRlUyoclq9xfhsUT wlU1qkvVRD3/QOfQyPUxQktxba2ksfsPAKUHovInWydC6rvLU89jtYGEdnRCyA+cEB/XcSADbd2z 9/XK4A2cxmMQiYpXIphYQAxIBwIDAQABo4IBIDCCARwwHQYDVR0OBBYEFOh7L9eqGHnAhbJdO4PY LYzxCaNNMIHsBgNVHSMEgeQwgeGAFOh7L9eqGHnAhbJdO4PYLYzxCaNNoYHFpIHCMIG/MQswCQYD VQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVy ZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVz MRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0 QG5ldGxhYi5uZWMuZGWCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQCX6Ipd3AF9 3FDzBaw3ZVvQzzCv/kGPBBzzrJ3n5u+4eQppmOifhuWHZfb8h8S++jqcoPHGVjjlP5PaFb+wL0NR piBalRclikD3xIY/hFoxJ1AHCO0AzfFxEflO10b4+smMrBYJtk5d9EAhr5hEgoGCM7QijBtnCwZB KLI9pFgW1zGCA6UwggOhAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMPU1kwCQYFKw4DAhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDYwNTE2MTYxMjE5WjAjBgkqhkiG9w0BCQQxFgQUP+Ichn+akUqJhiAGzd5b b/z/NpYwgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA BIIBAJU5Onq4KY1xwgI/Qfwx+brIdVAC9Wx1YYjv95y99tOf4PLpeEUPbgMvXwzja/LvAPo0sBpl I2jwtIigk1JDAcrw1rughLfvuirMc3GmL22eC5arWdyWPqeZS9jF0a9AG30nPGcN8L3jg48ZsITA 3FlWFDMOnWbtGf4ZDh3vs4jRaaPZef7uB++fcPF2mxM/27MJ5CS/MdzjQq9lsxkdWJaDkuEb/m4F uTY+81WLUl/abNGUk5cJmDPnJN1usJrsWSmpzahhjJjx4v4f46lsO6ummjRTXHxncSpzYibb+59k 0KFkcJIHgSq76aywRxZeRSl1Zwh3/56tqg/QqxwvzVwAAAAAAAA= --Apple-Mail-84--162469202-- --===============1132210330== 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 --===============1132210330==-- From tcpm-bounces@ietf.org Tue May 16 15:50:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg5Yc-0007wr-Iv; Tue, 16 May 2006 15:50:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg5YQ-0007ov-Uf; Tue, 16 May 2006 15:50:02 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg5YP-0002R3-Lr; Tue, 16 May 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k4GJo1et013892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 May 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fg5YP-0007kG-GP; Tue, 16 May 2006 15: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: Tue, 16 May 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-antispoof-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Defending TCP Against Spoofing Attacks Author(s) : J. Touch Filename : draft-ietf-tcpm-tcp-antispoof-04.txt Pages : 28 Date : 2006-5-16 Recent analysis of potential attacks on core Internet infrastructure indicates an increased vulnerability of TCP connections to spurious resets (RSTs), sent with forged IP source addresses (spoofing). TCP has always been susceptible to such RST spoofing attacks, which were indirectly protected by checking that the RST sequence number was inside the current receive window, as well as via the obfuscation of TCP endpoint and port numbers. For pairs of well-known endpoints often over predictable port pairs, such as BGP or between web servers and well-known large-scale caches, increases in the path bandwidth- delay product of a connection have sufficiently increased the receive window space that off-path third parties can brute-force generate a viable RST sequence number. The susceptibility to attack increases as the square of the bandwidth, thus presents a significant vulnerability for recent high-speed networks. This document addresses this vulnerability, discussing proposed solutions at the transport level and their inherent challenges, as well as existing network level solutions and the feasibility of their deployment. This document focuses on vulnerabilities due to spoofed TCP segments, and includes a discussion of related ICMP spoofing attacks on TCP connections. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-antispoof-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tcpm-tcp-antispoof-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tcpm-tcp-antispoof-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-5-16131221.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-tcp-antispoof-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-antispoof-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-16131221.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --NextPart-- From tcpm-bounces@ietf.org Tue May 16 23:45:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgCxx-0004CI-9V; Tue, 16 May 2006 23:44:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgCxw-0004CD-1M for tcpm@ietf.org; Tue, 16 May 2006 23:44:52 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgCxu-0003Vz-M0 for tcpm@ietf.org; Tue, 16 May 2006 23:44:52 -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 k4H3ilOr052088; Tue, 16 May 2006 20:44:47 -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 E0D3077AC21; Tue, 16 May 2006 23:44:44 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id BE52C40F5AE; Tue, 16 May 2006 23:43:49 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Lights MIME-Version: 1.0 Date: Tue, 16 May 2006 23:43:49 -0400 Message-Id: <20060517034349.BE52C40F5AE@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Ted Faber , touch@isi.edu Subject: [tcpm] WGLC on antispoof 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="===============1828502990==" Errors-To: tcpm-bounces@ietf.org --===============1828502990== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Folks- Per the discussion in Dallas, we are kicking off a WGLC on the anitspoof document. Joe has just posted a new rev of the document which is available in the archives: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-antispoof-04.txt As I understand them, there are no major changes from the last revision. Please give it a read in the next couple of weeks and let us know what you think. On-list feedback is best. Input to the author and chairs is OK. If you find the document just fine, a quick one sentence email to that effect would be very useful. We will have a 2 week last call period, ending on May/24. Thanks, allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEapv1WyrrWs4yIs4RAt3LAJ95Ar0AgC9OonLUzpM16GSQfhmvLwCfZ0m8 wyRPO0KLltTJMGH2xksEu/U= =b+0q -----END PGP SIGNATURE----- --=_bOundary-- --===============1828502990== 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 --===============1828502990==-- From tcpm-bounces@ietf.org Wed May 17 01:08:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgEFi-0006tG-FY; Wed, 17 May 2006 01:07:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgEFh-0006pc-NV for tcpm@ietf.org; Wed, 17 May 2006 01:07:17 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgEFf-00088C-Bf for tcpm@ietf.org; Wed, 17 May 2006 01:07:17 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4H56iV12880; Tue, 16 May 2006 22:06:45 -0700 (PDT) Message-ID: <446AAF5D.4010508@isi.edu> Date: Tue, 16 May 2006 22:06:37 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: mallman@icir.org References: <20060517034349.BE52C40F5AE@lawyers.icir.org> In-Reply-To: <20060517034349.BE52C40F5AE@lawyers.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 7655788c23eb79e336f5f8ba8bce7906 Cc: tcpm@ietf.org, Ted Faber Subject: [tcpm] Re: WGLC on antispoof X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Mark Allman wrote: > > Folks- > > Per the discussion in Dallas, we are kicking off a WGLC on the anitspoof > document. Joe has just posted a new rev of the document which is > available in the archives: > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-antispoof-04.txt > > As I understand them, there are no major changes from the last revision. > Please give it a read in the next couple of weeks and let us know what > you think. On-list feedback is best. Input to the author and chairs is > OK. If you find the document just fine, a quick one sentence email to > that effect would be very useful. > > We will have a 2 week last call period, ending on May/24. 2 weeks would end on May 30, right? ;-) Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed May 17 08:24:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgL4X-0004rS-5K; Wed, 17 May 2006 08:24:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgL4W-0004qF-0S for tcpm@ietf.org; Wed, 17 May 2006 08:24:12 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgL4U-0005jn-DB for tcpm@ietf.org; Wed, 17 May 2006 08:24:11 -0400 Received: from fgont.gont.com.ar ([201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4HCN89e005585; Wed, 17 May 2006 09:23:52 -0300 Message-Id: <7.0.1.0.0.20060517064022.05ea1e48@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 17 May 2006 06:49:12 -0300 To: Pyda Srisuresh , tcpm@ietf.org From: Fernando Gont Subject: Re: [tcpm] Comments on draft-ietf-tcpm-icmp-attacks-00.txt In-Reply-To: <20060515131318.2574.qmail@web33309.mail.mud.yahoo.com> References: <20060515131318.2574.qmail@web33309.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Pyda, Thanks so much for your feedback! You'll find my responses inline.... >1. Section 4.3 - Filtering ICMP error messages based on the ICMP payload > >Below is text from section 4.3. > > "However, a more > advanced packet filtering could be implemented in firewalls as a > counter-measure. Firewalls implementing such advanced filtering > would look at the payload of the ICMP error messages, and would > perform ingress and egress packet filtering based on the source IP > address of the IP header contained in the payload of the ICMP error > message." > >I would suggest replacing the term "firewalls" with "middlebox devices such as >Firewalls and NATs" in the above text. I believe, the text is directly >applicable to NATs, because NATs are also intermediate stateful devices. NATs >can also lookup the ICMP error payload and determine if it has prior mapping >(i.e, NAT Session) for the payload and drop the packet when there is no prior >mapping. Agreed. Will do. >2. Appendix C - This is useful information. Why not move this to the main body >in section 4? The idea of putting that text in an appendix was not because of it being "not that useful", but rather because of the fact that, given the current specifications, only the full IP header and the first 64 bits of its payload are required in the payload of ICMP error messages. Considering that it's not a requirement to have that information present, and attacker would not include it to perform the attacks. Thanks! Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed May 17 08:42:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgLMR-000238-EU; Wed, 17 May 2006 08:42:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgLMQ-00022v-0S for tcpm@ietf.org; Wed, 17 May 2006 08:42:42 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgKLd-0003SZ-8p for tcpm@ietf.org; Wed, 17 May 2006 07:37:49 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FgK7m-0003cT-JV for tcpm@ietf.org; Wed, 17 May 2006 07:23:35 -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 k4HBNSaG060678; Wed, 17 May 2006 04:23:29 -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 E960B77AC74; Wed, 17 May 2006 07:23:27 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id E70D640F747; Wed, 17 May 2006 07:22:30 -0400 (EDT) To: Joe Touch From: Mark Allman In-Reply-To: <446AAF5D.4010508@isi.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Lights MIME-Version: 1.0 Date: Wed, 17 May 2006 07:22:29 -0400 Message-Id: <20060517112230.E70D640F747@lawyers.icir.org> X-Spam-Score: -2.6 (--) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tcpm@ietf.org, Ted Faber Subject: [tcpm] Re: WGLC on antispoof 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="===============0482037887==" Errors-To: tcpm-bounces@ietf.org --===============0482037887== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > 2 weeks would end on May 30, right? ;-) OK, fine, we'll go with your math on this one. :-) So we're clear (or, is it too late for that?), the WGLC on antispoof: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-antispoof-04.txt will run through May/30. Sorry for the confusion. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEawd1WyrrWs4yIs4RAkOvAJ4jCAp+1NNrBpWDOdONW3RAFG43BACePX7I RGpEbyNbIBVFuRT+9cdEn0o= =Q5Mz -----END PGP SIGNATURE----- --=_bOundary-- --===============0482037887== 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 --===============0482037887==-- From tcpm-bounces@ietf.org Wed May 17 17:27:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgTY3-0002sD-9s; Wed, 17 May 2006 17:27:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgTY2-0002s8-Ul for tcpm@ietf.org; Wed, 17 May 2006 17:27:14 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgTY2-0003LW-GR for tcpm@ietf.org; Wed, 17 May 2006 17:27:14 -0400 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4HLQGV00478; Wed, 17 May 2006 14:26:16 -0700 (PDT) Message-ID: <446B94F8.3020008@isi.edu> Date: Wed, 17 May 2006 14:26:16 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: tcpm@ietf.org Subject: Re: Lars Eggert: [tcpm] draft-ietf-behave-tcp-00 References: <20060418135453.DAC3C77AF38@guns.icir.org> <034301c678ed$24757ea0$0601a8c0@pc6> In-Reply-To: <034301c678ed$24757ea0$0601a8c0@pc6> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org I took a look as well. I agree with Tom's assessment: it doesn't stand as a readable document. I also agree with Tom that: 1. this doc should start with the TCP roadmap as a reference, and should address items in there specifically (at least the basic ones, if not the recommended ones). 2. this doc should be more stand-alone regarding terminology --- I'll be more specific than Tom as to TCP-technical errors: - some of the scope declarations in section 1 are inappropriate. this document must declare the limit to which TCP headers can be interpreted in their entirety. declaring that anything not related to translation of TCP is out of scope begs the question of what's related to that translation - options? modification of the number of segments (e.g., splitting)? these are all definitely in-scope. I agree with the doc that above-TCP, below-TCP, and signalling beyond IP and TCP can be declared out of scope. - REQ-2 is overstated; a NAT MUST support translation of any packet valid in a pending TCP session, where "pending TCP session" is initiated by an outbound TCP SYN that means a NAT MUST accept incoming TCP SYNs which match current pending sessions. this supports simultaneous open *if* after the session is initiated by an internal host - REQ-3 is incorrect TCP defines sessions, sessions are defined by socket pairs, and sockets are defined by IP address/port pairs. Period. TCP port numbers do NOT identify hosts; they identify session demultiplexing points on hosts. To that end, the NAT is an early, remapping point for that demuxing, where everything behind a NAT (assuming it has only one external IP address) functions _exactly_ as if it were on a single host with that address. That also means that transmissions that differ in any of source IP, destination IP, source port, and destination port are unrelated from TCP's point of view. It is inappropriate for this document to suggest otherwise, or to suggest use of a NAT for that purpose. While other documents can refer to such 'NAT tricks', this document, from TCP's perspective, should recommend against such tricks, IMO. - REQ-4 is incorrect First, the ways in which a NAT would respond to a TCP SYN not matching a pending session should be listed, e.g., ICMP dest unreachable (3 port unreach, 10 host admin unreach) or TCP RST. The document is written assuming the desire to support simultaneous opens, but ignores the desire to know more rapidly when a port is not available. In particular, when an ICMP dest unreach/3 port unreach is issued, that would be a hard error that would cause the external TCP to quickly abort. Not sending the error would impact those hosts and cause them to respond less quickly to connection failure. While I agree that simultaneous open MUST be supported for pending sessions, I disagree that external SYNs should always be silently discarded just to support simultaneous open. While simultaneous open is OK when it works, the whole notion of a NAT is counter to incoming, unsolicited connections. I would recommend that incoming SYNs that do not match pending sessions MAY be signalled by an ICMP or RST error. I would NOT recommend that silence be required. - regarding ALGs FTP is not a relevant issue; FTP is already supported through NATs by passive mode; there is no requirement to translate the body of an FTP session to support NATs. There are other ALG issues, but they are - as noted in Sec 1 - above TCP, and not relevant to TCP. - session refresh This section is too messy. TCP can be open and silent if neither side has pending data; this must be addressed. Discarding state might allow subsequent sessions from other hosts to inadvertently receive data from other hosts' connections; this is a hazard that MUST be discussed. NATs may typically send keepalive TCPs, but *this* document should recommend that such behavior be restricted to endpoints. This document should be VERY clear on when such state should be kept, for how long, and when it can be cleared. The NAT must keep state in TIME_WAIT just like any end host to avoid reuse of connections and crossed-data. This section is the most critical of this document, and currently is both too disorganized and incorrect to proceed. - IPsec is missing since IPsec examines TCP headers, it would be useful to address IPsec/TCP combined issues here (e.g., transport mode issues) I didn't bother with addressing the security considerations, given the errors above. I'm presuming that a thorough revision of that section would be needed, since the doc missed some very obvious issues IMO (above). Minor nit: 6 authors? from a WG? pick a subset who are editors, please Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed May 17 17:36:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgTgn-00060j-K6; Wed, 17 May 2006 17:36:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgTgl-00060e-Th for tcpm@ietf.org; Wed, 17 May 2006 17:36:15 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgTgl-0004OA-IQ for tcpm@ietf.org; Wed, 17 May 2006 17:36:15 -0400 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4HLZ6V02540; Wed, 17 May 2006 14:35:06 -0700 (PDT) Message-ID: <446B970B.109@isi.edu> Date: Wed, 17 May 2006 14:35:07 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Joe Touch Subject: Re: Lars Eggert: [tcpm] draft-ietf-behave-tcp-00 References: <20060418135453.DAC3C77AF38@guns.icir.org> <034301c678ed$24757ea0$0601a8c0@pc6> <446B94F8.3020008@isi.edu> In-Reply-To: <446B94F8.3020008@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: cf4fa59384e76e63313391b70cd0dd25 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Joe Touch wrote: > - REQ-2 is overstated; a NAT MUST support translation of any > packet valid in a pending TCP session, where "pending TCP > session" is initiated by an outbound TCP SYN > > that means a NAT MUST accept incoming TCP SYNs which match > current pending sessions. this supports simultaneous open > *if* after the session is initiated by an internal host Sorry - minor typo. This should read "*if* (and only after) the session... Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed May 17 18:50:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgUqf-0004Ig-6n; Wed, 17 May 2006 18:50:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgUqd-0004IZ-TP for tcpm@ietf.org; Wed, 17 May 2006 18:50:31 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgUqd-0008Tm-L2 for tcpm@ietf.org; Wed, 17 May 2006 18:50:31 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id RAA28678; Wed, 17 May 2006 17:50:23 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k4HMoMr10992; Wed, 17 May 2006 15:50:22 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 May 2006 15:50:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Re: [tcpm] Comments on draft-ietf-tcpm-icmp-attacks-00.txt Date: Wed, 17 May 2006 15:50:21 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1818C2F@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <446B94F8.3020008@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Comments on draft-ietf-tcpm-icmp-attacks-00.txt Thread-Index: AcZ5+gApi78JVQ85QoSyJGIZxvsc2AAA5rQQ From: "Templin, Fred L" To: X-OriginalArrivalTime: 17 May 2006 22:50:22.0279 (UTC) FILETIME=[47635D70:01C67A04] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: "Templin, Fred L" , Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Fernando, This is a very useful and well-written document. I worked through all of the attack scenarios and recommended mitigations in detail and found no major problems. The citations of fielded deployments in major operating systems added further strength to the recommendations. Below are the observations I found. They are mostly minor in nature, and could go as AUTH48 if the document has already advanced to that stage. I believe this document is ready for advancement as an RFC. Fred fred.l.templin@boeing.com 1) Section 1, first reference to the term "blind", perhaps add a few words by way of definition so that the term is clearly understood throughout the rest of the document, e.g., "which include blind (i.e., ...) connection-reset". 2) Section 2.1, second paragraph, first sentence. The term "source host" may be too limiting because the source could also be an in-the-network tunnel encapsulator at a router. Suggest changing to "source system" or simply "source". Check also for other occurences of "source host" or "sending host" throughout the document. 3) Section 2.1, second paragraph, last sentence. Change: "handled to" to: "handed to". 4) Section 2.1.2, first sentence. Change RFC2463 to RFC4443 here and elsewhere throughout the document. 5) Section 2.2, fourth paragraph, first occurrence of the term "four-tuple" should be expanded to tell exactly what is meant by "four-tuple", i.e., (src, dst, sport, dport). 6) Section 3, fourth paragraph, possibly change: "signing its segments by means of the TCP MD5" to: "signing its segments, e.g., by means of the TCP MD5". I leave this one up to your judgement. 7) Section 3, sixth paragraph, change: "Current levels of deployment of protocols" to "Current levels of protocol deployment". 8) Section 4.1, first paragraph, change: "to destination" to: "to the destination". 9) Section 5.1, first paragraph, change: "is handled" to: "is handed", or: "handles". 10) Section 5.1, second paragraph, change: "[RFC1122]" to: "([RFC1122], Section 4.2.3.9)". Also change other critical RFC citations to cite specific sections throughout the document to give readers clear direction. 11) Section 5.2.1, under "ICMPv6 type 1...", change: "Therefore, TCP should" to: "Therefore, TCPs in synchronized states should". 12) Section 5.2.1, last sentence, change to: "The Linux kernel has also implemented this policy for more than ten years [Linux]." 13) Section 7.1, end of first paragraph, strike the citation of [RFC1191], and join paragraphs 1 and 2 together to make for a more unified introduction to path MTU discovery. 14) Appendix A, Section A.2, need to tell what MAXSEGRTO is set to for the purpose of the example. 15) Appendix B, under "maxsizeacked" and "maxsizesent", change: "so for" to: "so far" in both places. 16) Appendix B, under "MINIMUM_MTU", add close-paren ")" to end of sentence. 17) Appendix B, end of pseudo-code under "Notes:", add paragraph break after: "...sequence number arithmetic." =20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu May 18 03:53:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgdK0-00059l-5T; Thu, 18 May 2006 03:53:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgdJz-00059H-1P for tcpm@ietf.org; Thu, 18 May 2006 03:53:23 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgdJx-0006Vl-Et for tcpm@ietf.org; Thu, 18 May 2006 03:53:23 -0400 Received: from fgont.gont.com.ar ([201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4I7oor6001339; Thu, 18 May 2006 04:53:16 -0300 Message-Id: <7.0.1.0.0.20060518035047.06d3d718@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 18 May 2006 04:01:23 -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: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Joe Touch Subject: [tcpm] Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Joe, In section 4 ("ICMP") of the document, in my opinion there are some issues that are missing. In the case of the ICMP-based connection reset attack, the main counter-measure is to change TCP's reaction to hard errors. The rationale for this is included in the ICMP attacks draft. If the counter-measure was just to check the TCP seq number, then, as long as the RFCs are concerned, that would give us the same level of "protection" TCP already has for TCP-based reset attacks (i.e., require the forged packet to be "in window"). Thus, ICMP would still be "the weakest link in the chain". As for the filtering of ICMP messages, it is interesting to note that while ICMP messages can be inserted anywhere in the network (without even needing to spoof the source IP address), address spoofing *is* needed in the ICMP payload, and thus ingress/egress filtering can be performed based on the ICMP payload. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu May 18 05:01:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgeNF-0003Df-Ru; Thu, 18 May 2006 05:00:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgeND-00037F-OA for tcpm@ietf.org; Thu, 18 May 2006 05:00:47 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgeNA-0001e2-7x for tcpm@ietf.org; Thu, 18 May 2006 05:00:47 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060308/8.12.11) with ESMTP id k4I90WmT019638; Thu, 18 May 2006 12:00:33 +0300 Date: Thu, 18 May 2006 12:00:32 +0300 (EEST) From: Pekka Savola To: Fernando Gont Subject: Re: [tcpm] Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt In-Reply-To: <7.0.1.0.0.20060518035047.06d3d718@gont.com.ar> Message-ID: References: <7.0.1.0.0.20060518035047.06d3d718@gont.com.ar> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1467/Wed May 17 00:21:47 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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: , Errors-To: tcpm-bounces@ietf.org On Thu, 18 May 2006, Fernando Gont wrote: > As for the filtering of ICMP messages, it is interesting to note that while > ICMP messages can be inserted anywhere in the network (without even needing > to spoof the source IP address), address spoofing *is* needed in the ICMP > payload, and thus ingress/egress filtering can be performed based on the ICMP > payload. I hope you're not suggesting that implementations (e.g., routers) would need to verify the payload of ICMP error messages they're transiting for this to be effective.. -- 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 Thu May 18 06:00:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgfIn-0007gW-GC; Thu, 18 May 2006 06:00:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgfIm-0007gR-IY for tcpm@ietf.org; Thu, 18 May 2006 06:00:16 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgfIk-0004Na-W6 for tcpm@ietf.org; Thu, 18 May 2006 06:00:16 -0400 Received: from fgont.gont.com.ar ([201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4IA09jh004601; Thu, 18 May 2006 07:00:11 -0300 Message-Id: <7.0.1.0.0.20060518063832.020b9300@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 18 May 2006 06:39:59 -0300 To: Pekka Savola From: Fernando Gont Subject: Re: [tcpm] Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt In-Reply-To: References: <7.0.1.0.0.20060518035047.06d3d718@gont.com.ar> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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: , Errors-To: tcpm-bounces@ietf.org At 06:00 18/05/2006, Pekka Savola wrote: >>As for the filtering of ICMP messages, it is interesting to note >>that while ICMP messages can be inserted anywhere in the network >>(without even needing to spoof the source IP address), address >>spoofing *is* needed in the ICMP payload, and thus ingress/egress >>filtering can be performed based on the ICMP payload. > >I hope you're not suggesting that implementations (e.g., routers) >would need to verify the payload of ICMP error messages they're >transiting for this to be effective.. This filtering could be implemented in firewalls, for example. My point was that the draft says " As a result, many networks filter all ICMP packets because validation may not be possible, especially because they can be injected from anywhere in a network, and so cannot be selectively address filtered." ICMP messages can be filtered with the same selectiveness than IP datagrams. Whether or not it's convenience from a performance point of view is a different issue. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu May 18 06:15:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgfXF-0003rb-Ff; Thu, 18 May 2006 06:15:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgfXD-0003rT-Rq for tcpm@ietf.org; Thu, 18 May 2006 06:15:12 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgfXC-00059M-CQ for tcpm@ietf.org; Thu, 18 May 2006 06:15:11 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060308/8.12.11) with ESMTP id k4IAF5cY021576; Thu, 18 May 2006 13:15:05 +0300 Date: Thu, 18 May 2006 13:15:05 +0300 (EEST) From: Pekka Savola To: Fernando Gont Subject: Re: [tcpm] Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt In-Reply-To: <7.0.1.0.0.20060518063832.020b9300@gont.com.ar> Message-ID: References: <7.0.1.0.0.20060518035047.06d3d718@gont.com.ar> <7.0.1.0.0.20060518063832.020b9300@gont.com.ar> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1467/Wed May 17 00:21:47 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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: , Errors-To: tcpm-bounces@ietf.org On Thu, 18 May 2006, Fernando Gont wrote: > My point was that the draft says > " As a result, > many networks filter all ICMP packets because validation may not be > possible, especially because they can be injected from anywhere in a > network, and so cannot be selectively address filtered." > > ICMP messages can be filtered with the same selectiveness than IP datagrams. > > Whether or not it's convenience from a performance point of view is a > different issue. Agreed to certain extent. Firewalls could block "external payload spoofing" from interfering with internal sessions, but as such ICMP payload filtering is not possible (in practice) in the same (or roughly same) places where ingress filtering is performed, it is not as useful for more generic protection. -- 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 Thu May 18 10:26:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgjSP-00080N-Qn; Thu, 18 May 2006 10:26:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgjSO-00080I-MP for tcpm@ietf.org; Thu, 18 May 2006 10:26:28 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgjSN-0004ue-A2 for tcpm@ietf.org; Thu, 18 May 2006 10:26:28 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4IEPnV12052; Thu, 18 May 2006 07:25:49 -0700 (PDT) Message-ID: <446C83E6.4030901@isi.edu> Date: Thu, 18 May 2006 07:25:42 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Fernando Gont References: <7.0.1.0.0.20060518035047.06d3d718@gont.com.ar> In-Reply-To: <7.0.1.0.0.20060518035047.06d3d718@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: e1e48a527f609d1be2bc8d8a70eb76cb Cc: tcpm@ietf.org Subject: [tcpm] Re: Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Fernando Gont wrote: > Joe, > > In section 4 ("ICMP") of the document, in my opinion there are some > issues that are missing. > > In the case of the ICMP-based connection reset attack, the main > counter-measure is to change TCP's reaction to hard errors. The primary countermeasure is already deployed - to block ICMPs. This does not require a modification to TCP. This allows the filtering to determine the level of protection afforded, rather than wiring all TCPs to include such filtering natively. The latter essentially deprecates the capabilities afforded by hard errors in trusted environments - e.g., behind firewalls, inside VPNs, etc., and seems overkill. The document already cites that draft (I can issue a quick update to fix the ref to the Feb 06 TCPM version, if that matters). > The > rationale for this is included in the ICMP attacks draft. If the > counter-measure was just to check the TCP seq number, then, as long as > the RFCs are concerned, that would give us the same level of > "protection" TCP already has for TCP-based reset attacks (i.e., require > the forged packet to be "in window"). Thus, ICMP would still be "the > weakest link in the chain". > > As for the filtering of ICMP messages, it is interesting to note that > while ICMP messages can be inserted anywhere in the network (without > even needing to spoof the source IP address), address spoofing *is* > needed in the ICMP payload, and thus ingress/egress filtering can be > performed based on the ICMP payload. Filtering on the payload is less useful than filtering on the source address; the ICMP packet may be allowed to take a path that the source address is not, so it's not necessarily appropriate to make filtering decisions on the payload. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu May 18 12:08:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgl35-0004NV-Af; Thu, 18 May 2006 12:08:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgl34-0004NQ-Fy for tcpm@ietf.org; Thu, 18 May 2006 12:08:26 -0400 Received: from mms1.broadcom.com ([216.31.210.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgl32-0003Hg-5u for tcpm@ietf.org; Thu, 18 May 2006 12:08:26 -0400 Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Thu, 18 May 2006 09:08:07 -0700 X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 124692AF; Thu, 18 May 2006 09:08:07 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id E35D22AE for ; Thu, 18 May 2006 09:08:06 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id DOB08179; Thu, 18 May 2006 09:08:06 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 673ED20501 for ; Thu, 18 May 2006 09:08:06 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] Comments on draft-ietf-tcpm-icmp-attacks-00.txt Date: Thu, 18 May 2006 09:08:07 -0700 Message-ID: <03235919BBDE634289BB6A0758A20B365EAFB8@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [tcpm] Comments on draft-ietf-tcpm-icmp-attacks-00.txt Thread-Index: AcZ5+gApi78JVQ85QoSyJGIZxvsc2AAA5rQQACXduiA= From: "Bora Akyol" To: tcpm@ietf.org X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006051805; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230392E34343643393941332E303032422D412D; ENG=IBF; TS=20060518160810; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006051805_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 6872446D0HW20142495-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org =20 Hi I have one question regarding section 4.3 in this document. Since the attacker needs to guess both ends of the TCP connection including IP addresses and TCP ports, I am not sure what the benefit of ICMP payload parsing is in this case. I am sure I missed something here. Thanks Bora _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu May 18 12:27:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FglLb-0004iY-Fk; Thu, 18 May 2006 12:27:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FglLZ-0004iN-R2 for tcpm@ietf.org; Thu, 18 May 2006 12:27:33 -0400 Received: from mms2.broadcom.com ([216.31.210.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FglLY-0004AF-Gy for tcpm@ietf.org; Thu, 18 May 2006 12:27:33 -0400 Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Thu, 18 May 2006 09:27:21 -0700 X-Server-Uuid: D9EB6F12-1469-4C1C-87A2-5E4C0D6F9D06 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 885A82AF; Thu, 18 May 2006 09:27:21 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 60EBD2AE; Thu, 18 May 2006 09:27:21 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id DOB15087; Thu, 18 May 2006 09:27:17 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id E37E220501; Thu, 18 May 2006 09:27:16 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt Date: Thu, 18 May 2006 09:27:16 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F149F676@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [tcpm] Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt Thread-Index: AcZ6UGVO8kBEA/ByS7S4//C502RTzwARzMFQ From: "Caitlin Bestler" To: "Fernando Gont" , tcpm@ietf.org X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006051805; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230332E34343643394532332E303033452D412D; ENG=IBF; TS=20060518162723; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006051805_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 68727FE34I812783733-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Joe Touch X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Fernando Gont wrote: >=20 > As for the filtering of ICMP messages, it is interesting to > note that while ICMP messages can be inserted anywhere in the > network (without even needing to spoof the source IP > address), address spoofing *is* needed in the ICMP payload, > and thus ingress/egress filtering can be performed based on the ICMP > payload.=20 >=20 I thought we were trying to encourage deployment of ingress/egress filtering, not make it more difficult and provide more excuses=20 not to do it. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu May 18 13:50:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgmdG-00029v-TN; Thu, 18 May 2006 13:49:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgmdF-00029l-Th for tcpm@ietf.org; Thu, 18 May 2006 13:49:53 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgmdB-0008Vc-HM for tcpm@ietf.org; Thu, 18 May 2006 13:49:53 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4IHmhB23611 for ; Thu, 18 May 2006 10:48:43 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.6/8.13.6/Submit) id k4IHmh5w044856 for tcpm@ietf.org; Thu, 18 May 2006 10:48:43 -0700 (PDT) (envelope-from faber) Date: Thu, 18 May 2006 10:48:43 -0700 From: Ted Faber To: tcpm@ietf.org Message-ID: <20060518174843.GK40285@hut.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@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [tcpm] draft-ietf-rddp-mpa-03.txt review request 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="===============0473924473==" Errors-To: tcpm-bounces@ietf.org --===============0473924473== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LQ77YLfPrO/qF/pM" Content-Disposition: inline --LQ77YLfPrO/qF/pM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, The draft draft-ietf-rddp-mpa-03.txt is up for review as a Proposed Standard, and Lars thinks that TCPM review is essential. Mark and I agree. Here's the abstract: MPA (Marker Protocol data unit Aligned framing) is designed to work as an "adaptation layer" between TCP and the Direct Data Placement [DDP] protocol, preserving the reliable, in-order delivery of TCP, while adding the preservation of higher-level protocol record boundaries that DDP requires. MPA is fully compliant with applicable TCP RFCs and can be utilized with existing TCP implementations. MPA also supports integrated implementations that combine TCP, MPA and DDP to reduce buffering requirements in the implementation and improve performance at the system level. I'd like to get a couple reviewers now who are committed to providing reviews by the end of the month or so. David Black, the RDDP chair, is interested in our feedback and in working out issues that arise. Lars has read this and claims that though it's long, it is very readable. I don't think it'll be another ROHC or behave multi-draft scavenger hunt. If you're interested in this and willing to provide a review, please let me and Mark know. If we don't get volunteers, we'll start calling on people. A cool thing that Lars has subtlely pointed out to me is that an easy way to reach Mark and me, or our eventual replacements, is tcpm-chairs@ietf.org. That would be a great address to test by volunteering to review this draft. 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 --LQ77YLfPrO/qF/pM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEbLN7aUz3f+Zf+XsRAsjLAJ0Wp+mfVDqv/tXY1pOhtTAKTqKpcACeOxiA NolgYfqJxwqQFfp/6jKWkbM= =QJa2 -----END PGP SIGNATURE----- --LQ77YLfPrO/qF/pM-- --===============0473924473== 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 --===============0473924473==-- From tcpm-bounces@ietf.org Thu May 18 14:32:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgnIQ-0008Ja-2s; Thu, 18 May 2006 14:32:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgnIP-0008JV-Fj for tcpm@ietf.org; Thu, 18 May 2006 14:32:25 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgnIN-0002WH-36 for tcpm@ietf.org; Thu, 18 May 2006 14:32:25 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4IIVOV16262; Thu, 18 May 2006 11:31:24 -0700 (PDT) Message-ID: <446CBD74.4000609@isi.edu> Date: Thu, 18 May 2006 11:31:16 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Ted Faber Subject: Re: [tcpm] draft-ietf-rddp-mpa-03.txt review request References: <20060518174843.GK40285@hut.isi.edu> In-Reply-To: <20060518174843.GK40285@hut.isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: cab78e1e39c4b328567edb48482b6a69 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Ted Faber wrote: > Hi, > > The draft draft-ietf-rddp-mpa-03.txt is up for review as a Proposed > Standard, and Lars thinks that TCPM review is essential. Mark and I > agree. Here's the abstract: ... > Lars has read this and claims that though it's long, it is very > readable. I don't think it'll be another ROHC or behave multi-draft > scavenger hunt. Really? (I do)... ;-( TCP senders and receivers can be MPA-aware, but this is completely and utterly outside the scope of the interface between TCP and its application layer. Some other things came up in a _very_ quick scan: The requirement in 3.1 is already a requirement of TCP (793, top page 75); that sort of thing is inappropriate to respecify. 3.1.1 incorrectly assumes that turning Nagle off will correlate sends with segment boundaries; TCP is under _no_ obligation to do this. possible changes in pmtu would definitely change that behavior TCP should never assume 1500-byte segments; 576 is the assumption _unless other information is specifically available_. --- I _really_ don't want to burn time on _yet another_ round of explaining to MP-folks why boundary alignment in TCP is a bad thing, and how badly it interacts with TCP's mechanisms even if they wanted to add it. This is a case where I'll ask that they use SCTP and please leave TCPM alone. At the very least, modifying TCP to be MPA-aware redefines the TCP interface; that needs to happen __before and separately__ from the use of MPA of that interface. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu May 18 16:17:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgovp-0005EZ-UT; Thu, 18 May 2006 16:17:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgovp-0005EP-8p for tcpm@ietf.org; Thu, 18 May 2006 16:17:13 -0400 Received: from mms2.broadcom.com ([216.31.210.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgovn-0002nJ-Ui for tcpm@ietf.org; Thu, 18 May 2006 16:17:13 -0400 Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Thu, 18 May 2006 13:17:01 -0700 X-Server-Uuid: D9EB6F12-1469-4C1C-87A2-5E4C0D6F9D06 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id C84C12B1; Thu, 18 May 2006 13:17:00 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id A6B502AF; Thu, 18 May 2006 13:17:00 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id DOC12995; Thu, 18 May 2006 13:16:50 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 21B2820501; Thu, 18 May 2006 13:16:50 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] draft-ietf-rddp-mpa-03.txt review request Date: Thu, 18 May 2006 13:16:49 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F149F6D2@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [tcpm] draft-ietf-rddp-mpa-03.txt review request Thread-Index: AcZ6qY3UaTZpXU7eQQ+92Rs8h3bGeQADR6Ww From: "Caitlin Bestler" To: "Joe Touch" , "Ted Faber" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006051807; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230382E34343643443346382E303033452D412D; ENG=IBF; TS=20060518201703; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006051807_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 687209B64I812875093-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) 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: , Errors-To: tcpm-bounces@ietf.org Joe Touch wrote: =20 > 3.1.1 incorrectly assumes that turning Nagle off will > correlate sends with segment boundaries; TCP is under _no_ obligation > to do this. possible changes in pmtu would definitely change that > behavior=20 >=20 To be precise, 3.1.1 suggest that when MPA works above TCP it might want to use TCP_NODELAY because it "will usually result in many of the segments starting with an FPDU". Do you dispute that this is an accurate comment on the *probable* behavior, and that in fact using TCP_NODELAY is likely to increase the correlation between MPA FPDUs and TCP Segments? Certainly enabling Nagle would decrease the frequency of aligned MPA FPDUs, so I don't see how a suggestion on how a user of TCP picks already defined TCP options is in anyway wrong unless the advice being given is in fact counter-productive. In the worst case setting TCP_NODELAY will be ineffective. I believe the draft is already clear on that point, do you disagree? > TCP should never assume 1500-byte segments; 576 is the > assumption _unless other information is specifically available_. >=20 Technically it is the MPA layer doing the assuming, but you are correct that MPA assumptions should be based on IETF standards and not common deployment plans. For the common deployment situations the EMSS will be available anyway, so 576 would be a better default. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu May 18 16:28:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgp6e-0003Kl-BL; Thu, 18 May 2006 16:28:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgp6d-0003Kg-L4 for tcpm@ietf.org; Thu, 18 May 2006 16:28:23 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgp6c-0003f8-9Q for tcpm@ietf.org; Thu, 18 May 2006 16:28:23 -0400 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4IKS8V15707; Thu, 18 May 2006 13:28:08 -0700 (PDT) Message-ID: <446CD8D9.90006@isi.edu> Date: Thu, 18 May 2006 13:28:09 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Caitlin Bestler Subject: Re: [tcpm] draft-ietf-rddp-mpa-03.txt review request References: <54AD0F12E08D1541B826BE97C98F99F149F6D2@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F149F6D2@NT-SJCA-0751.brcm.ad.broadcom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 082a9cbf4d599f360ac7f815372a6a15 Cc: tcpm@ietf.org, Ted Faber X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Caitlin Bestler wrote: > Joe Touch wrote: > > >> 3.1.1 incorrectly assumes that turning Nagle off will >> correlate sends with segment boundaries; TCP is under _no_ obligation >> to do this. possible changes in pmtu would definitely change that >> behavior >> > > To be precise, 3.1.1 suggest that when MPA works above TCP it might > want to use TCP_NODELAY because it "will usually result in many of > the segments starting with an FPDU". > > Do you dispute that this is an accurate comment on the *probable* > behavior, and that in fact using TCP_NODELAY is likely to increase > the correlation between MPA FPDUs and TCP Segments? Yes. With retransmission alone all bets are off. This is the Nth time this dog has been dragged around the block. It also assumes that the sends match the PDUs; if they're ever larger, that and all subsequent segments will be misaligned in those implementations. How do you know when the path changes? There are no signals in TCP's API to tell the app when the MTU changes, or - more importantly - to tell them that it changed and all the queued data will be segmented differently. This is just a bad idea. > Certainly enabling Nagle would decrease the frequency of aligned > MPA FPDUs, so I don't see how a suggestion on how a user of TCP > picks already defined TCP options is in anyway wrong unless the > advice being given is in fact counter-productive. In the worst > case setting TCP_NODELAY will be ineffective. > > I believe the draft is already clear on that point, do you disagree? I don't see the point in endorsing this approach. It sets up the expectation that TCP does something; when it doesn't they'll complain that the TCP isn't MPA-friendly. IMO, MPA isn't TCP-friendly to expect *any* correlation between sends and segments, period. Again, this dog has been dragged around the block (kicking and screaming) before. >> TCP should never assume 1500-byte segments; 576 is the >> assumption _unless other information is specifically available_. > > Technically it is the MPA layer doing the assuming, Agreed. > but you are > correct that MPA assumptions should be based on IETF standards > and not common deployment plans. For the common deployment situations > the EMSS will be available anyway, so 576 would be a better default. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu May 18 17:09:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgpkH-0005Yo-Bo; Thu, 18 May 2006 17:09:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgpkF-0005Yj-Vu for tcpm@ietf.org; Thu, 18 May 2006 17:09:19 -0400 Received: from mms1.broadcom.com ([216.31.210.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgpkD-0006gz-Ja for tcpm@ietf.org; Thu, 18 May 2006 17:09:19 -0400 Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Thu, 18 May 2006 14:09:07 -0700 X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id F3DC92B1; Thu, 18 May 2006 14:09:06 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id D246D2AF; Thu, 18 May 2006 14:09:06 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id DOC40765; Thu, 18 May 2006 14:09:03 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id C686620501; Thu, 18 May 2006 14:09:03 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] draft-ietf-rddp-mpa-03.txt review request Date: Thu, 18 May 2006 14:09:02 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F149F6E4@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [tcpm] draft-ietf-rddp-mpa-03.txt review request Thread-Index: AcZ6u+AzqXlelgEHTDmqVE2xi+YOXgAAbTiQ From: "Caitlin Bestler" To: "Joe Touch" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006051807; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230332E34343643453032452E303031302D412D; ENG=IBF; TS=20060518210909; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006051807_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 68723DF90HW20306106-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: tcpm@ietf.org, Ted Faber X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Joe Touch wrote: > Caitlin Bestler wrote: >> Joe Touch wrote: >>=20 >>=20 >>> 3.1.1 incorrectly assumes that turning Nagle off will correlate >>> sends with segment boundaries; TCP is under _no_ obligation to do >>> this. possible changes in pmtu would definitely change that behavior >>>=20 >>=20 >> To be precise, 3.1.1 suggest that when MPA works above TCP it might >> want to use TCP_NODELAY because it "will usually result in many of >> the segments starting with an FPDU". >>=20 >> Do you dispute that this is an accurate comment on the *probable* >> behavior, and that in fact using TCP_NODELAY is likely to increase >> the correlation between MPA FPDUs and TCP Segments? >=20 > Yes. With retransmission alone all bets are off. >=20 > This is the Nth time this dog has been dragged around the block. >=20 > It also assumes that the sends match the PDUs; if they're > ever larger, that and all subsequent segments will be > misaligned in those implementations. How do you know when the > path changes? There are no signals in TCP's API to tell the > app when the MTU changes, or - more importantly - to tell > them that it changed and all the queued data will be > segmented differently. >=20 > This is just a bad idea. >=20 >> Certainly enabling Nagle would decrease the frequency of aligned MPA >> FPDUs, so I don't see how a suggestion on how a user of TCP picks >> already defined TCP options is in anyway wrong unless the advice >> being given is in fact counter-productive. In the worst case setting >> TCP_NODELAY will be ineffective. >>=20 >> I believe the draft is already clear on that point, do you disagree? >=20 > I don't see the point in endorsing this approach. It sets up > the expectation that TCP does something; when it doesn't > they'll complain that the TCP isn't MPA-friendly. IMO, MPA isn't > TCP-friendly to expect *any* correlation between sends and segments, > period.=20 >=20 > Again, this dog has been dragged around the block (kicking and > screaming) before.=20 > MPA does not do anything over TCP that any low level daemon could not do. And the optimization strategies it suggests are valid.=20 Retransmission alone can and will break MPA alignment, but if retransmission represents the norm there are some severe problems with the network. MPA is a ULP to TCP that has a strategy to increase the probability that a received TCP Segment will contain a complete MPA FULPDU. I think it is clear that the strategy specified is in fact effective, but I do not think that is relevant for the TCPM discussion. As I see it the relevant question here is if MPA is recommending a pattern of TCP usage that would somehow be disruptive of TCP's on an end-to-end global basis. For example, if someone were to write a spec for "XYZ" that said that an "XYZ friendly" TCP sender would not bother to constrain itself based on congestion then the XYZ draft would definitely be guilty of undermining TCP. An "MPA Friendly" TCP sender does not do anything that an existing TCP sender might already do to implement TCP_NODELAY. Further, the number of TCP Segments where that is relevant is exceedingly small, since most MPA FULPDUs will fill an entire TCP segment. =20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu May 18 18:23:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgqty-0006FU-QI; Thu, 18 May 2006 18:23:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgqty-0006FP-0X for tcpm@ietf.org; Thu, 18 May 2006 18:23:26 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgqtw-0002r0-L7 for tcpm@ietf.org; Thu, 18 May 2006 18:23:25 -0400 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4IMNCV12614; Thu, 18 May 2006 15:23:12 -0700 (PDT) Message-ID: <446CF3D1.6070603@isi.edu> Date: Thu, 18 May 2006 15:23:13 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Caitlin Bestler Subject: Re: [tcpm] draft-ietf-rddp-mpa-03.txt review request References: <54AD0F12E08D1541B826BE97C98F99F149F6E4@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F149F6E4@NT-SJCA-0751.brcm.ad.broadcom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: d6b246023072368de71562c0ab503126 Cc: tcpm@ietf.org, Ted Faber X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Caitlin Bestler wrote: ... > MPA does not do anything over TCP that any low level daemon could > not do. And the optimization strategies it suggests are valid. > Retransmission alone can and will break MPA alignment, but if > retransmission represents the norm there are some severe problems > with the network. ... > As I see it the relevant question here is if MPA is recommending a > pattern of TCP usage that would somehow be disruptive of TCP's > on an end-to-end global basis. Not assuming retransmission would fall into that category, IMO. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu May 18 18:39:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgr9D-0003nd-Vt; Thu, 18 May 2006 18:39:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgr9C-0003nY-Of for tcpm@ietf.org; Thu, 18 May 2006 18:39:10 -0400 Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgr9B-00043W-E9 for tcpm@ietf.org; Thu, 18 May 2006 18:39:10 -0400 Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Thu, 18 May 2006 15:38:59 -0700 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 308FD2B0; Thu, 18 May 2006 15:38:59 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id ED3842AF; Thu, 18 May 2006 15:38:58 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id DOC71683; Thu, 18 May 2006 15:38:56 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 4E21D20503; Thu, 18 May 2006 15:38:56 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] draft-ietf-rddp-mpa-03.txt review request Date: Thu, 18 May 2006 15:38:55 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F149F702@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [tcpm] draft-ietf-rddp-mpa-03.txt review request Thread-Index: AcZ6ybQnsK7thPtqRqe6k79Uzm74+gAAaJdA From: "Caitlin Bestler" To: "Joe Touch" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006051807; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230382E34343643463533452E303031312D412D; ENG=IBF; TS=20060518223901; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006051807_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 687228093NG18126922-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: tcpm@ietf.org, Ted Faber X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Joe Touch wrote: > Caitlin Bestler wrote: > ... >> MPA does not do anything over TCP that any low level daemon could not >> do. And the optimization strategies it suggests are valid. >> Retransmission alone can and will break MPA alignment, but if >> retransmission represents the norm there are some severe problems >> with the network. >=20 > ... >> As I see it the relevant question here is if MPA is recommending a >> pattern of TCP usage that would somehow be disruptive of TCP's on an >> end-to-end global basis. >=20 > Not assuming retransmission would fall into that category, IMO. >=20 > Joe MPA does allow for retransmission. It merely assumes that retransmission is the exception and focuses it's attempt at achieving aligned reception on the initial transmit. If MPA had required that retransmissions maintain the same boundaries as the initial transmissions it would have indeed been specifying a modification to TCP. But there is no such requirement. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu May 18 18:40:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgrA8-00045x-TC; Thu, 18 May 2006 18:40:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgrA7-00045s-KQ for tcpm@ietf.org; Thu, 18 May 2006 18:40:07 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgrA5-00046H-8n for tcpm@ietf.org; Thu, 18 May 2006 18:40:07 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4IMcpB15570; Thu, 18 May 2006 15:38:51 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.6/8.13.6/Submit) id k4IMcpD1049514; Thu, 18 May 2006 15:38:51 -0700 (PDT) (envelope-from faber) Date: Thu, 18 May 2006 15:38:51 -0700 From: Ted Faber To: Joe Touch Subject: Re: [tcpm] draft-ietf-rddp-mpa-03.txt review request Message-ID: <20060518223851.GN40285@hut.isi.edu> References: <54AD0F12E08D1541B826BE97C98F99F149F6E4@NT-SJCA-0751.brcm.ad.broadcom.com> <446CF3D1.6070603@isi.edu> Mime-Version: 1.0 In-Reply-To: <446CF3D1.6070603@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@hut.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="===============1473583198==" Errors-To: tcpm-bounces@ietf.org --===============1473583198== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+cfQkLQGU7KOA/8T" Content-Disposition: inline --+cfQkLQGU7KOA/8T Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 18, 2006 at 03:23:13PM -0700, Joe Touch wrote: >=20 >=20 > Caitlin Bestler wrote: > ... > >MPA does not do anything over TCP that any low level daemon could > >not do. And the optimization strategies it suggests are valid.=20 > >Retransmission alone can and will break MPA alignment, but if > >retransmission represents the norm there are some severe problems > >with the network. >=20 > ... > >As I see it the relevant question here is if MPA is recommending a > >pattern of TCP usage that would somehow be disruptive of TCP's > >on an end-to-end global basis. >=20 > Not assuming retransmission would fall into that category, IMO. Ummmm, how so? Unless I misunderstood Caitlin, the only entity suffering from problems if TCP retransmissions are common is the MPA. It won't cause congestion collapse or any harm to the network, will it? Am I missing a danger to other TCP connections? --=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 --+cfQkLQGU7KOA/8T Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEbPd7aUz3f+Zf+XsRArDZAKCi+MS9c0PAJgw0InrVWu0VDOpU2ACfbkX+ +QWySm8gcF4wgY2OGMiP2OQ= =A9Wt -----END PGP SIGNATURE----- --+cfQkLQGU7KOA/8T-- --===============1473583198== 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 --===============1473583198==-- From tcpm-bounces@ietf.org Thu May 18 18:50:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgrJo-0000yy-26; Thu, 18 May 2006 18:50:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgrJn-0000yt-2Q for tcpm@ietf.org; Thu, 18 May 2006 18:50:07 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgrJj-0004Wu-I7 for tcpm@ietf.org; Thu, 18 May 2006 18:50:07 -0400 Received: from lars.local (ip-80-226-11-146.vodafone-net.de [80.226.11.146]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 945E91BAC4D; Fri, 19 May 2006 00:42:08 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by lars.local (Postfix) with ESMTP id 23B28C8660; Fri, 19 May 2006 00:50:00 +0200 (CEST) In-Reply-To: <20060518174843.GK40285@hut.isi.edu> References: <20060518174843.GK40285@hut.isi.edu> Mime-Version: 1.0 (Apple Message framework v750) Message-Id: <6A9A15AD-C6D5-4A02-8067-08B3D8836ED4@netlab.nec.de> From: Lars Eggert Subject: Re: [tcpm] draft-ietf-rddp-mpa-03.txt review request Date: Fri, 19 May 2006 00:49:57 +0200 To: Ted Faber X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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="===============0094592931==" Errors-To: tcpm-bounces@ietf.org --===============0094592931== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3-34189990; protocol="application/pkcs7-signature" --Apple-Mail-3-34189990 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On May 18, 2006, at 19:48, Ted Faber wrote: > an easy way to reach Mark and me, or our eventual replacements, is > tcpm-chairs@ietf.org. FWIW, it's tcpm-chairs@tools.ietf.org. (All cool things happen under tools these days.) Works for all other WGs, too. Lars -- Lars Eggert NEC Network Laboratories --Apple-Mail-3-34189990 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKgzCCAyAw ggKJoAMCAQICAw9TWTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE4MTAyOTU2WhcNMDYwODE4MTAyOTU2WjBgMQ8wDQYDVQQE EwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA2gsuG8tAmM6U2ESsQjhcijJSq6oDG2c+KvvXJ/xcJXbSIOY8IInezIP0DP41H0gxwHNv AyOuwM6nh0r2wOhzdr77GlKXiij0LoFOpurScPKsC9KTykGAfZtAuCnWIRdDo67Urcw1e306yYgK xF1UzYwGamLalPjejQTRcjLPIbzM4c7fUN/sxmpkpzT2p6OCJDyPhBfSaZWtv3UEoKF+xssNYzOF DRCTHcLc3iXgF7z7J0ud8maUAadfb/25Gm7tJHzBOEonMPkHx2N8Ci0qNce0MMH/LVOVQlNO5kYJ vUJiT0du7LAo/hf8tq3luZrh/Cwc/313x6oKYVuHDBllrQIDAQABo2IwYDAqBgUrZQEEAQQhMB8C AQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCQGA1UdEQQdMBuBGWxhcnMuZWdnZXJ0QG5l dGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAovojiq8758E/78nMS vNvD4359F8XAICzWbhz6cXJaGzv1FJoQcV/RY1x6CQZDt9PqiPiqyQX+xLvqicmEURbGU5+aiWj2 usovQXd+Ts8Doj3tbjk35nD7Etc8a2+Y9fQRUS6spzgJr0fcq2FMYbDnOtf71Bn77KgckoUbIszu mTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl ZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNa LIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1Ud HwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVs Mi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa 9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggQYMIIDgaADAgECAgEAMA0G CSqGSIb3DQEBBQUAMIG/MQswCQYDVQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVy ZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsT FE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkq hkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGUwHhcNMDQwNjE4MTE1MzA4WhcNMDkw NjE3MTE1MzA4WjCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcx EzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExRO ZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZI hvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQC0OQwsE86Rrt0Zs0GOCsYmkGpPwcCFvVpOijIPv1dGolr5a8+7hXSAgRlUyoclq9xfhsUT wlU1qkvVRD3/QOfQyPUxQktxba2ksfsPAKUHovInWydC6rvLU89jtYGEdnRCyA+cEB/XcSADbd2z 9/XK4A2cxmMQiYpXIphYQAxIBwIDAQABo4IBIDCCARwwHQYDVR0OBBYEFOh7L9eqGHnAhbJdO4PY LYzxCaNNMIHsBgNVHSMEgeQwgeGAFOh7L9eqGHnAhbJdO4PYLYzxCaNNoYHFpIHCMIG/MQswCQYD VQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVy ZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVz MRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0 QG5ldGxhYi5uZWMuZGWCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQCX6Ipd3AF9 3FDzBaw3ZVvQzzCv/kGPBBzzrJ3n5u+4eQppmOifhuWHZfb8h8S++jqcoPHGVjjlP5PaFb+wL0NR piBalRclikD3xIY/hFoxJ1AHCO0AzfFxEflO10b4+smMrBYJtk5d9EAhr5hEgoGCM7QijBtnCwZB KLI9pFgW1zGCA6UwggOhAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMPU1kwCQYFKw4DAhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDYwNTE4MjI0OTU4WjAjBgkqhkiG9w0BCQQxFgQUpo3XY2VcosYsZl0s1JaN /7Xhxy0wgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA BIIBAKCgvi731B7H5oOUDijRFV099P+p4CY2UeIx0/cbsmN1/d3Zx56h14G5f3+uWRZREiRxNAnr LFiNl2boIvup8tWIf0Xt2rtOqfhc6zm5R7OmDJqxIuJJDjA/6jnjck0B8Ysje3YAbnZwQZQHYcuQ jGG4DWfIbZvVyIPzO1JeOlAPpFdcApKyb1xhW+YJUx6WxDX86Tcuq2Hizh1WGMFk+/vbNojCeHp0 MnUd0e8zMNIEEnRPdx7oyXEs5uaOznbKP7k9loKw1NGmIhvcpPySOnc4qPLXncfsKCOlK/Vh8Omu MJXUMUuDRuM4yGpsWYfsF6RK7EapAG+8cFqbcWFhtUsAAAAAAAA= --Apple-Mail-3-34189990-- --===============0094592931== 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 --===============0094592931==-- From tcpm-bounces@ietf.org Thu May 18 19:00:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgrTx-0004dh-K8; Thu, 18 May 2006 19:00:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgrTw-0004dc-1V for tcpm@ietf.org; Thu, 18 May 2006 19:00:36 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgrTt-00053v-M1 for tcpm@ietf.org; Thu, 18 May 2006 19:00:36 -0400 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4IMxYV20686; Thu, 18 May 2006 15:59:34 -0700 (PDT) Message-ID: <446CFC57.9090706@isi.edu> Date: Thu, 18 May 2006 15:59:35 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Ted Faber Subject: Re: [tcpm] draft-ietf-rddp-mpa-03.txt review request References: <54AD0F12E08D1541B826BE97C98F99F149F6E4@NT-SJCA-0751.brcm.ad.broadcom.com> <446CF3D1.6070603@isi.edu> <20060518223851.GN40285@hut.isi.edu> In-Reply-To: <20060518223851.GN40285@hut.isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Ted Faber wrote: > On Thu, May 18, 2006 at 03:23:13PM -0700, Joe Touch wrote: >> >> Caitlin Bestler wrote: >> ... >>> MPA does not do anything over TCP that any low level daemon could >>> not do. And the optimization strategies it suggests are valid. >>> Retransmission alone can and will break MPA alignment, but if >>> retransmission represents the norm there are some severe problems >>> with the network. >> ... >>> As I see it the relevant question here is if MPA is recommending a >>> pattern of TCP usage that would somehow be disruptive of TCP's >>> on an end-to-end global basis. > >> Not assuming retransmission would fall into that category, IMO. > > Ummmm, how so? > > Unless I misunderstood Caitlin, the only entity suffering from problems > if TCP retransmissions are common is the MPA. It won't cause congestion > collapse or any harm to the network, will it? Am I missing a danger to > other TCP connections? What I'm suggesting is having MPA spec a use of TCP that works only when TCP doesn't happen to do retransmissions. You're right that this wouldn't disrupt other TCPs, but IMO it's a waste of time. TCP is designed for retransmission; if you have an application protocol that works best or only if there aren't any, then you ought to be using a different transport protocol. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu May 18 19:01:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgrUo-0004n5-5U; Thu, 18 May 2006 19:01:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgrUn-0004n0-M6 for tcpm@ietf.org; Thu, 18 May 2006 19:01:29 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgrUm-00058r-BN for tcpm@ietf.org; Thu, 18 May 2006 19:01:29 -0400 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4IN12V21384; Thu, 18 May 2006 16:01:02 -0700 (PDT) Message-ID: <446CFCAF.8080605@isi.edu> Date: Thu, 18 May 2006 16:01:03 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Caitlin Bestler Subject: Re: [tcpm] draft-ietf-rddp-mpa-03.txt review request References: <54AD0F12E08D1541B826BE97C98F99F149F702@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F149F702@NT-SJCA-0751.brcm.ad.broadcom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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 Cc: tcpm@ietf.org, Ted Faber X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Caitlin Bestler wrote: > Joe Touch wrote: >> Caitlin Bestler wrote: >> ... >>> MPA does not do anything over TCP that any low level daemon could not >>> do. And the optimization strategies it suggests are valid. >>> Retransmission alone can and will break MPA alignment, but if >>> retransmission represents the norm there are some severe problems >>> with the network. >> ... >>> As I see it the relevant question here is if MPA is recommending a >>> pattern of TCP usage that would somehow be disruptive of TCP's on an >>> end-to-end global basis. >> Not assuming retransmission would fall into that category, IMO. >> >> Joe > > MPA does allow for retransmission. It merely assumes that retransmission > is the exception and focuses it's attempt at achieving aligned reception > on the initial transmit. In TCP retransmission is the rule, not the exception. Any design that optimizes for the non-retransmission case is wasting its time by using TCP. > If MPA had required that retransmissions maintain the same boundaries > as the initial transmissions it would have indeed been specifying a > modification to TCP. But there is no such requirement. Understood, but once any retransmission occurs it's a waste of time to even talk about such alignment. All text that assumes alignment between an application send and a TCP segment is not only erroneous, it's a waste of time at that point. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu May 18 21:09:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgtUI-0007WP-8z; Thu, 18 May 2006 21:09:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgtUG-0007WK-PA for tcpm@ietf.org; Thu, 18 May 2006 21:09:04 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgtUE-0004I3-Dg for tcpm@ietf.org; Thu, 18 May 2006 21:09:04 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4J17fB01748; Thu, 18 May 2006 18:07:41 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.6/8.13.6/Submit) id k4J17fxn051739; Thu, 18 May 2006 18:07:41 -0700 (PDT) (envelope-from faber) Date: Thu, 18 May 2006 18:07:40 -0700 From: Ted Faber To: Lars Eggert Subject: Re: [tcpm] draft-ietf-rddp-mpa-03.txt review request Message-ID: <20060519010740.GQ40285@hut.isi.edu> References: <20060518174843.GK40285@hut.isi.edu> <6A9A15AD-C6D5-4A02-8067-08B3D8836ED4@netlab.nec.de> Mime-Version: 1.0 In-Reply-To: <6A9A15AD-C6D5-4A02-8067-08B3D8836ED4@netlab.nec.de> 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@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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="===============0271015510==" Errors-To: tcpm-bounces@ietf.org --===============0271015510== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="glwmnIOgU1tcuP7N" Content-Disposition: inline --glwmnIOgU1tcuP7N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 19, 2006 at 12:49:57AM +0200, Lars Eggert wrote: > On May 18, 2006, at 19:48, Ted Faber wrote: > >an easy way to reach Mark and me, or our eventual replacements, is > >tcpm-chairs@ietf.org. >=20 > FWIW, it's tcpm-chairs@tools.ietf.org. (All cool things happen under =20 > tools these days.) Works for all other WGs, too. That must be why all those review volunteer messages haven't been coming in. 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 --glwmnIOgU1tcuP7N Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEbRpcaUz3f+Zf+XsRAk16AJ4wIAB4fNDhOItu+cAlsdxi+6RTrgCghC4e eup0Hu+R39tzohMPHO7cZ6Q= =sQtB -----END PGP SIGNATURE----- --glwmnIOgU1tcuP7N-- --===============0271015510== 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 --===============0271015510==-- From tcpm-bounces@ietf.org Fri May 19 01:10:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgxF6-0003Vz-1B; Fri, 19 May 2006 01:09:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgxF5-0003Ue-DZ for tcpm@ietf.org; Fri, 19 May 2006 01:09:39 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgxF4-0001W6-2l for tcpm@ietf.org; Fri, 19 May 2006 01:09:39 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4J58cV06372; Thu, 18 May 2006 22:08:38 -0700 (PDT) Message-ID: <446D52CF.9090709@isi.edu> Date: Thu, 18 May 2006 22:08:31 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Caitlin Bestler Subject: Re: [tcpm] Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt References: <54AD0F12E08D1541B826BE97C98F99F149F676@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F149F676@NT-SJCA-0751.brcm.ad.broadcom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 7d33c50f3756db14428398e2bdedd581 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: , Errors-To: tcpm-bounces@ietf.org Caitlin Bestler wrote: > Fernando Gont wrote: > >> As for the filtering of ICMP messages, it is interesting to >> note that while ICMP messages can be inserted anywhere in the >> network (without even needing to spoof the source IP >> address), address spoofing *is* needed in the ICMP payload, >> and thus ingress/egress filtering can be performed based on the ICMP >> payload. > > I thought we were trying to encourage deployment of ingress/egress > filtering, I can't say we are. While it may be useful in some circumstances, it's a hefty local penalty to pay for a global benefit that's largely defeated when any leaf fails to participate; that's not the kind of system that encourages early adoption. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri May 19 01:28:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgxWr-0002nT-Um; Fri, 19 May 2006 01:28:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgxWq-0002nF-PJ for tcpm@ietf.org; Fri, 19 May 2006 01:28:00 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgxWq-0002FM-7C for tcpm@ietf.org; Fri, 19 May 2006 01:28:00 -0400 Received: from fgont.gont.com.ar ([201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4J5Rcef007027; Fri, 19 May 2006 02:28:00 -0300 Message-Id: <7.0.1.0.0.20060519014730.06a6b2d0@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 19 May 2006 01:57:58 -0300 To: "Bora Akyol" , tcpm@ietf.org From: Fernando Gont Subject: RE: [tcpm] Comments on draft-ietf-tcpm-icmp-attacks-00.txt In-Reply-To: <03235919BBDE634289BB6A0758A20B365EAFB8@NT-SJCA-0751.brcm.a d.broadcom.com> References: <03235919BBDE634289BB6A0758A20B365EAFB8@NT-SJCA-0751.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 13:08 18/05/2006, Bora Akyol wrote: >I have one question regarding section 4.3 in this document. > >Since the attacker needs to guess both ends of the TCP connection >including IP addresses and TCP ports, I am not sure what the benefit >of ICMP payload parsing is in this case. > >I am sure I missed something here. The "benefit" is being a good network citizen. When you perform egress-filtering, you preventyour own users from performing ICMP-based attacks against systems that belong to other networks. Regarding that of having to guess the two-endpoints of the TCP connection, the answer is simple: Even TCP-based attacks, in which you have to guess not only both endpoints, but *also* the TCP sequence number, are of concern nowadays. Have a look at Paul Watson's presentation at CanSecWest 2004, and at the tcp-secure document of this WG. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri May 19 01:28:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgxWr-0002nO-PP; Fri, 19 May 2006 01:28:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgxWq-0002n9-NY for tcpm@ietf.org; Fri, 19 May 2006 01:28:00 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgxWo-0002Cq-4z for tcpm@ietf.org; Fri, 19 May 2006 01:28:00 -0400 Received: from fgont.gont.com.ar ([201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4J5Rceb007027; Fri, 19 May 2006 02:27:52 -0300 Message-Id: <7.0.1.0.0.20060519013953.06a78c28@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 19 May 2006 01:41:28 -0300 To: "Caitlin Bestler" , tcpm@ietf.org From: Fernando Gont Subject: RE: [tcpm] Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt In-Reply-To: <54AD0F12E08D1541B8From tcpm-bounces@ietf.org Fri May 19 01:28:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgxWr-0002nT-Um; Fri, 19 May 2006 01:28:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgxWq-0002nF-PJ for tcpm@ietf.org; Fri, 19 May 2006 01:28:00 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgxWq-0002FM-7C for tcpm@ietf.org; Fri, 19 May 2006 01:28:00 -0400 Received: from fgont.gont.com.ar ([201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4J5Rcef007027; Fri, 19 May 2006 02:28:00 -0300 Message-Id: <7.0.1.0.0.20060519014730.06a6b2d0@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 19 May 2006 01:57:58 -0300 To: "Bora Akyol" , tcpm@ietf.org From: Fernando Gont Subject: RE: [tcpm] Comments on draft-ietf-tcpm-icmp-attacks-00.txt In-Reply-To: <03235919BBDE634289BB6A0758A20B365EAFB8@NT-SJCA-0751.brcm.a d.broadcom.com> References: <03235919BBDE634289BB6A0758A20B365EAFB8@NT-SJCA-0751.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 13:08 18/05/2006, Bora Akyol wrote: >I have one question regarding section 4.3 in this document. > >Since the attacker needs to guess both ends of the TCP connection >including IP addresses and TCP ports, I am not sure what the benefit >of ICMP payload parsing is in this case. > >I am sure I missed something here. The "benefit" is being a good network citizen. When you perform egress-filtering, you preventyour own users from performing ICMP-based attacks against systems that belong to other networks. Regarding that of having to guess the two-endpoints of the TCP connection, the answer is simple: Even TCP-based attacks, in which you have to guess not only both endpoints, but *also* the TCP sequence number, are of concern nowadays. Have a look at Paul Watson's presentation at CanSecWest 2004, and at the tcp-secure document of this WG. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri May 19 01:28:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgxWr-0002nO-PP; Fri, 19 May 2006 01:28:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgxWq-0002n9-NY for tcpm@ietf.org; Fri, 19 May 2006 01:28:00 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgxWo-0002Cq-4z for tcpm@ietf.org; Fri, 19 May 2006 01:28:00 -0400 Received: from fgont.gont.com.ar ([201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4J5Rceb007027; Fri, 19 May 2006 02:27:52 -0300 Message-Id: <7.0.1.0.0.20060519013953.06a78c28@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 19 May 2006 01:41:28 -0300 To: "Caitlin Bestler" , tcpm@ietf.org From: Fernando Gont Subject: RE: [tcpm] Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F149F676@NT-SJCA-0751.brcm.a d.broadcom.com> References: <54AD0F12E08D1541B826BE97C98F99F149F676@NT-SJCA-0751.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Joe Touch X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 13:27 18/05/2006, Caitlin Bestler wrote: > > As for the filtering of ICMP messages, it is interesting to > > note that while ICMP messages can be inserted anywhere in the > > network (without even needing to spoof the source IP > > address), address spoofing *is* needed in the ICMP payload, > > and thus ingress/egress filtering can be performed based on the ICMP > > payload. > > > >I thought we were trying to encourage deployment of ingress/egress >filtering, not make it more difficult and provide more excuses >not to do it. This is by no means providing more excuses. It is simply stating that it can be done, in addition to that performed on the source/destination IP addresses of the IP packet. For instance, many firewalls already implement this type of filtering. Kidnest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm 26BE97C98F99F149F676@NT-SJCA-0751.brcm.a d.broadcom.com> References: <54AD0F12E08D1541B826BE97C98F99F149F676@NT-SJCA-0751.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Joe Touch X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 13:27 18/05/2006, Caitlin Bestler wrote: > > As for the filtering of ICMP messages, it is interesting to > > note that while ICMP messages can be inserted anywhere in the > > network (without even needing to spoof the source IP > > address), address spoofing *is* needed in the ICMP payload, > > and thus ingress/egress filtering can be performed based on the ICMP > > payload. > > > >I thought we were trying to encourage deployment of ingress/egress >filtering, not make it more difficult and provide more excuses >not to do it. This is by no means providing more excuses. It is simply stating that it can be done, in addition to that performed on the source/destination IP addresses of the IP packet. For instance, many firewalls already implement this type of filtering. Kidnest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri May 19 01:28:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgxWu-0002or-IC; Fri, 19 May 2006 01:28:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgxWt-0002oc-9m for tcpm@ietf.org; Fri, 19 May 2006 01:28:03 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgxWs-0002FX-Np for tcpm@ietf.org; Fri, 19 May 2006 01:28:03 -0400 Received: from fgont.gont.com.ar ([201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4J5Rceh007027; Fri, 19 May 2006 02:28:03 -0300 Message-Id: <7.0.1.0.0.20060519020027.06a860e8@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 19 May 2006 02:24:52 -0300 To: "Templin, Fred L" , From: Fernando Gont Subject: Re: [tcpm] Comments on draft-ietf-tcpm-icmp-attacks-00.txt In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1818C2F@XCH-NW-7V2.nw.nos.b oeing.com> References: <446B94F8.3020008@isi.edu> <39C363776A4E8C4A94691D2BD9D1C9A1818C2F@XCH-NW-7V2.nw.nos.boeing.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: "Templin, Fred L" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 19:50 17/05/2006, Templin, Fred L wrote: >This is a very useful and well-written document. I worked >through all of the attack scenarios and recommended >mitigations in detail and found no major problems. The >citations of fielded deployments in major operating >systems added further strength to the recommendations. Thanks! You'll find my comments inline (I skipped some,that I will also adress in teh next revision of the draft). >1) Section 1, first reference to the term "blind", perhaps > add a few words by way of definition so that the term > is clearly understood throughout the rest of the document, > e.g., "which include blind (i.e., ...) connection-reset". Okay. Will do. >2) Section 2.1, second paragraph, first sentence. The term > "source host" may be too limiting because the source > could also be an in-the-network tunnel encapsulator at > a router. Suggest changing to "source system" or simply > "source". Check also for other occurences of "source host" > or "sending host" throughout the document. Good point. Will do. [....] >4) Section 2.1.2, first sentence. Change RFC2463 to RFC4443 > here and elsewhere throughout the document. Yep. Found about this revision not that long ago. Will do. >5) Section 2.2, fourth paragraph, first occurrence of the > term "four-tuple" should be expanded to tell exactly what > is meant by "four-tuple", i.e., (src, dst, sport, dport). Okay. Will do. >6) Section 3, fourth paragraph, possibly change: "signing > its segments by means of the TCP MD5" to: "signing its > segments, e.g., by means of the TCP MD5". I leave this > one up to your judgement. Very good point. For instance, a few weeks ago I posted some feedback on Ron Bonica's draft regarding this issue. The same idea applies even if the actual algorithm to sign the segment is different from MD5. >10) Section 5.1, second paragraph, change: "[RFC1122]" to: > "([RFC1122], Section 4.2.3.9)". Also change other > critical RFC citations to cite specific sections > throughout the document to give readers clear direction. Good point. Will do. >11) Section 5.2.1, under "ICMPv6 type 1...", change: > "Therefore, TCP should" to: "Therefore, TCPs in > synchronized states should". Good grief! Will do. >14) Appendix A, Section A.2, need to tell what MAXSEGRTO > is set to for the purpose of the example. See the introduction of Appendix A. It says that for all the following examples, MAXSEGRTO is set to 1. >15) Appendix B, under "maxsizeacked" and "maxsizesent", > change: "so for" to: "so far" in both places. Oops!. Will do. >17) Appendix B, end of pseudo-code under "Notes:", add > paragraph break after: "...sequence number arithmetic." Will do. Thanks so much for your very *very* detailed feedback! Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri May 19 01:28:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgxWt-0002oD-5F; Fri, 19 May 2006 01:28:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgxWq-0002nE-Oa for tcpm@ietf.org; Fri, 19 May 2006 01:28:00 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgxWo-0002Cc-4z for tcpm@ietf.org; Fri, 19 May 2006 01:28:00 -0400 Received: from fgont.gont.com.ar ([201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4J5RceZ007027; Fri, 19 May 2006 02:27:49 -0300 Message-Id: <7.0.1.0.0.20060519013043.06a4ef68@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 19 May 2006 01:39:10 -0300 To: Joe Touch From: Fernando Gont In-Reply-To: <446C83E6.4030901@isi.edu> References: <7.0.1.0.0.20060518035047.06d3d718@gont.com.ar> <446C83E6.4030901@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: tcpm@ietf.org Subject: [tcpm] Re: Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 11:25 18/05/2006, Joe Touch wrote: >>In section 4 ("ICMP") of the document, in my opinion there are some >>issues that are missing. >>In the case of the ICMP-based connection reset attack, the main >>counter-measure is to change TCP's reaction to hard errors. > >The primary countermeasure is already deployed - to block ICMPs. >This does not require a modification to TCP. This allows the >filtering to determine the level of protection afforded, rather than >wiring all TCPs to include such filtering natively. The latter >essentially deprecates the capabilities afforded by hard errors in >trusted environments - e.g., behind firewalls, inside VPNs, etc., >and seems overkill. I strongly disagree. And so do existing implementations. All BSD-derived and Mentat-derived TCP/IP stacks treat the so-called "hard errors" as "soft errors". I don't know what Microsoft Windows' stack is derived from. But they published an advisory on this issue, and their patch is supposed to treat "hard errors" as "soft errors", too. Cisco treats the "so called" hard errors as "soft errors", too, IIRC. On the other hand, I disagree that "blocking ICMPs" is already deployed. Try traceroute. Try ping. They still work. PMTUD works to a large extent, too. >The document already cites that draft (I can issue a quick update to >fix the ref to the Feb 06 TCPM version, if that matters). My point is that the antispoof draft is not citing the ICMP attacks draft properly. You just mention the TCP seq checking, when that's less than 10% of the draft. >>The rationale for this is included in the ICMP attacks draft. If >>the counter-measure was just to check the TCP seq number, then, as >>long as the RFCs are concerned, that would give us the same level >>of "protection" TCP already has for TCP-based reset attacks (i.e., >>require the forged packet to be "in window"). Thus, ICMP would >>still be "the weakest link in the chain". >>As for the filtering of ICMP messages, it is interesting to note >>that while ICMP messages can be inserted anywhere in the network >>(without even needing to spoof the source IP address), address >>spoofing *is* needed in the ICMP payload, and thus ingress/egress >>filtering can be performed based on the ICMP payload. > >Filtering on the payload is less useful than filtering on the source >address; the ICMP packet may be allowed to take a path that the >source address is not, so it's not necessarily appropriate to make >filtering decisions on the payload. I don't get your point. I don;t see the difference between ingress/egress filtering based on the outer IP datagram (for IP packets), and based on the inner IP datagrams (for ICMP error messages). Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri May 19 01:28:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgxWu-0002or-IC; Fri, 19 May 2006 01:28:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgxWt-0002oc-9m for tcpm@ietf.org; Fri, 19 May 2006 01:28:03 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgxWs-0002FX-Np for tcpm@ietf.org; Fri, 19 May 2006 01:28:03 -0400 Received: from fgont.gont.com.ar ([201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4J5Rceh007027; Fri, 19 May 2006 02:28:03 -0300 Message-Id: <7.0.1.0.0.20060519020027.06a860e8@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 19 May 2006 02:24:52 -0300 To: "Templin, Fred L" , From: Fernando Gont Subject: Re: [tcpm] Comments on draft-ietf-tcpm-icmp-attacks-00.txt In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1818C2F@XCH-NW-7V2.nw.nos.b oeing.com> References: <446B94F8.3020008@isi.edu> <39C363776A4E8C4A94691D2BD9D1C9A1818C2F@XCH-NW-7V2.nw.nos.boeing.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: "Templin, Fred L" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 19:50 17/05/2006, Templin, Fred L wrote: >This is a very useful and well-written document. I worked >through all of the attack scenarios and recommended >mitigations in detail and found no major problems. The >citations of fielded deployments in major operating >systems added further strength to the recommendations. Thanks! You'll find my comments inline (I skipped some,that I will also adress in teh next revision of the draft). >1) Section 1, first reference to the term "blind", perhaps > add a few words by way of definition so that the term > is clearly understood throughout the rest of the document, > e.g., "which include blind (i.e., ...) connection-reset". Okay. Will do. >2) Section 2.1, second paragraph, first sentence. The term > "source host" may be too limiting because the source > could also be an in-the-network tunnel encapsulator at > a router. Suggest changing to "source system" or simply > "source". Check also for other occurences of "source host" > or "sending host" throughout the document. Good point. Will do. [....] >4) Section 2.1.2, first sentence. Change RFC2463 to RFC4443 > here and elsewhere throughout the document. Yep. Found about this revision not that long ago. Will do. >5) Section 2.2, fourth paragraph, first occurrence of the > term "four-tuple" should be expanded to tell exactly what > is meant by "four-tuple", i.e., (src, dst, sport, dport). Okay. Will do. >6) Section 3, fourth paragraph, possibly change: "signing > its segments by means of the TCP MD5" to: "signing its > segments, e.g., by means of the TCP MD5". I leave this > one up to your judgement. Very good point. For instance, a few weeks ago I posted some feedback on Ron Bonica's draft regarding this issue. The same idea applies even if the actual algorithm to sign the segment is different from MD5. >10) Section 5.1, second paragraph, change: "[RFC1122]" to: > "([RFC1122], Section 4.2.3.9)". Also change other > critical RFC citations to cite specific sections > throughout the document to give readers clear direction. Good point. Will do. >11) Section 5.2.1, under "ICMPv6 type 1...", change: > "Therefore, TCP should" to: "Therefore, TCPs in > synchronized states should". Good grief! Will do. >14) Appendix A, Section A.2, need to tell what MAXSEGRTO > is set to for the purpose of the example. See the introduction of Appendix A. It says that for all the following examples, MAXSEGRTO is set to 1. >15) Appendix B, under "maxsizeacked" and "maxsizesent", > change: "so for" to: "so far" in both places. Oops!. Will do. >17) Appendix B, end of pseudo-code under "Notes:", add > paragraph break after: "...sequence number arithmetic." Will do. Thanks so much for your very *very* detailed feedback! Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri May 19 01:28:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgxWt-0002oD-5F; Fri, 19 May 2006 01:28:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgxWq-0002nE-Oa for tcpm@ietf.org; Fri, 19 May 2006 01:28:00 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgxWo-0002Cc-4z for tcpm@ietf.org; Fri, 19 May 2006 01:28:00 -0400 Received: from fgont.gont.com.ar ([201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4J5RceZ007027; Fri, 19 May 2006 02:27:49 -0300 Message-Id: <7.0.1.0.0.20060519013043.06a4ef68@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 19 May 2006 01:39:10 -0300 To: Joe Touch From: Fernando Gont In-Reply-To: <446C83E6.4030901@isi.edu> References: <7.0.1.0.0.20060518035047.06d3d718@gont.com.ar> <446C83E6.4030901@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: tcpm@ietf.org Subject: [tcpm] Re: Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 11:25 18/05/2006, Joe Touch wrote: >>In section 4 ("ICMP") of the document, in my opinion there are some >>issues that are missing. >>In the case of the ICMP-based connection reset attack, the main >>counter-measure is to change TCP's reaction to hard errors. > >The primary countermeasure is already deployed - to block ICMPs. >This does not require a modification to TCP. This allows the >filtering to determine the level of protection afforded, rather than >wiring all TCPs to include such filtering natively. The latter >essentially deprecates the capabilities afforded by hard errors in >trusted environments - e.g., behind firewalls, inside VPNs, etc., >and seems overkill. I strongly disagree. And so do existing implementations. All BSD-derived and Mentat-derived TCP/IP stacks treat the so-called "hard errors" as "soft errors". I don't know what Microsoft Windows' stack is derived from. But they published an advisory on this issue, and their patch is supposed to treat "hard errors" as "soft errors", too. Cisco treats the "so called" hard errors as "soft errors", too, IIRC. On the other hand, I disagree that "blocking ICMPs" is already deployed. Try traceroute. Try ping. They still work. PMTUD works to a large extent, too. >The document already cites that draft (I can issue a quick update to >fix the ref to the Feb 06 TCPM version, if that matters). My point is that the antispoof draft is not citing the ICMP attacks draft properly. You just mention the TCP seq checking, when that's less than 10% of the draft. >>The rationale for this is included in the ICMP attacks draft. If >>the counter-measure was just to check the TCP seq number, then, as >>long as the RFCs are concerned, that would give us the same level >>of "protection" TCP already has for TCP-based reset attacks (i.e., >>require the forged packet to be "in window"). Thus, ICMP would >>still be "the weakest link in the chain". >>As for the filtering of ICMP messages, it is interesting to note >>that while ICMP messages can be inserted anywhere in the network >>(without even needing to spoof the source IP address), address >>spoofing *is* needed in the ICMP payload, and thus ingress/egress >>filtering can be performed based on the ICMP payload. > >Filtering on the payload is less useful than filtering on the source >address; the ICMP packet may be allowed to take a path that the >source address is not, so it's not necessarily appropriate to make >filtering decisions on the payload. I don't get your point. I don;t see the difference between ingress/egress filtering based on the outer IP datagram (for IP packets), and based on the inner IP datagrams (for ICMP error messages). Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri May 19 01:54:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgxw1-00057E-Os; Fri, 19 May 2006 01:54:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgxw1-00056f-3v for tcpm@ietf.org; Fri, 19 May 2006 01:54:01 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgxqa-0003Uu-Hn for tcpm@ietf.org; Fri, 19 May 2006 01:48:26 -0400 Received: from [128.9.176.38] (c1-vpn8.isi.edu [128.9.176.38]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4J5lFV14170; Thu, 18 May 2006 22:47:15 -0700 (PDT) Message-ID: <446D5BDB.9050002@isi.edu> Date: Thu, 18 May 2006 22:47:07 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] Comments on draft-ietf-tcpm-icmp-attacks-00.txt References: <03235919BBDE634289BB6A0758A20B365EAFB8@NT-SJCA-0751.brcm.ad.broadcom.com> <7.0.1.0.0.20060519014730.06a6b2d0@gont.com.ar> In-Reply-To: <7.0.1.0.0.20060519014730.06a6b2d0@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 9182cfff02fae4f1b6e9349e01d62f32 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Fernando Gont wrote: > At 13:08 18/05/2006, Bora Akyol wrote: > >> I have one question regarding section 4.3 in this document. >> >> Since the attacker needs to guess both ends of the TCP connection >> including IP addresses and TCP ports, I am not sure what the benefit >> of ICMP payload parsing is in this case. >> >> I am sure I missed something here. > > The "benefit" is being a good network citizen. When you perform > egress-filtering, you preventyour own users from performing ICMP-based > attacks against systems that belong to other networks. What about errors based on loose source routes, or just misdirected traffic? I.e., how do you know that it's not appropriate to indicate that a host (especially) isn't in your net when asked; that would cause certain ICMPs never to be issued (net unreachable, host unreachable) if they reach a forwarding point in your net that isn't a valid address for your net (which is entirely reasonable). Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri May 19 01:54:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgxw0-00056D-IL; Fri, 19 May 2006 01:54:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgxvz-00055k-1S for tcpm@ietf.org; Fri, 19 May 2006 01:53:59 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgxtb-0003fU-9P for tcpm@ietf.org; Fri, 19 May 2006 01:51:33 -0400 Received: from [128.9.176.38] (c1-vpn8.isi.edu [128.9.176.38]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4J5ouV14987; Thu, 18 May 2006 22:50:56 -0700 (PDT) Message-ID: <446D5CB9.70403@isi.edu> Date: Thu, 18 May 2006 22:50:49 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] Comments on draft-ietf-tcpm-icmp-attacks-00.txt References: <03235919BBDE634289BB6A0758A20B365From tcpm-bounces@ietf.org Fri May 19 01:54:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgxw1-00057E-Os; Fri, 19 May 2006 01:54:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgxw1-00056f-3v for tcpm@ietf.org; Fri, 19 May 2006 01:54:01 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgxqa-0003Uu-Hn for tcpm@ietf.org; Fri, 19 May 2006 01:48:26 -0400 Received: from [128.9.176.38] (c1-vpn8.isi.edu [128.9.176.38]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4J5lFV14170; Thu, 18 May 2006 22:47:15 -0700 (PDT) Message-ID: <446D5BDB.9050002@isi.edu> Date: Thu, 18 May 2006 22:47:07 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] Comments on draft-ietf-tcpm-icmp-attacks-00.txt References: <03235919BBDE634289BB6A0758A20B365EAFB8@NT-SJCA-0751.brcm.ad.broadcom.com> <7.0.1.0.0.20060519014730.06a6b2d0@gont.com.ar> In-Reply-To: <7.0.1.0.0.20060519014730.06a6b2d0@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 9182cfff02fae4f1b6e9349e01d62f32 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Fernando Gont wrote: > At 13:08 18/05/2006, Bora Akyol wrote: > >> I have one question regarding section 4.3 in this document. >> >> Since the attacker needs to guess both ends of the TCP connection >> including IP addresses and TCP ports, I am not sure what the benefit >> of ICMP payload parsing is in this case. >> >> I am sure I missed something here. > > The "benefit" is being a good network citizen. When you perform > egress-filtering, you preventyour own users from performing ICMP-based > attacks against systems that belong to other networks. What about errors based on loose source routes, or just misdirected traffic? I.e., how do you know that it's not appropriate to indicate that a host (especially) isn't in your net when asked; that would cause certain ICMPs never to be issued (net unreachable, host unreachable) if they reach a forwarding point in your net that isn't a valid address for your net (which is entirely reasonable). Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri May 19 01:54:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgxw0-00056D-IL; Fri, 19 May 2006 01:54:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgxvz-00055k-1S for tcpm@ietf.org; Fri, 19 May 2006 01:53:59 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgxtb-0003fU-9P for tcpm@ietf.org; Fri, 19 May 2006 01:51:33 -0400 Received: from [128.9.176.38] (c1-vpn8.isi.edu [128.9.176.38]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4J5ouV14987; Thu, 18 May 2006 22:50:56 -0700 (PDT) Message-ID: <446D5CB9.70403@isi.edu> Date: Thu, 18 May 2006 22:50:49 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] Comments on draft-ietf-tcpm-icmp-attacks-00.txt References: <03235919BBDE634289BB6A0758A20B365EAFB8@NT-SJCA-0751.brcm.ad.broadcom.com> <7.0.1.0.0.20060519014730.06a6b2d0@gont.com.ar> In-Reply-To: <7.0.1.0.0.20060519014730.06a6b2d0@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Fernando Gont wrote: ... > Have a look at Paul Watson's presentation at CanSecWest 2004, and at the > tcp-secure document of this WG. FWIW, the citations in tcp-antispoof are more complete (include a URL, e.g., for Paul's presentation, as well as a number of other citations) on this issue. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm EAFB8@NT-SJCA-0751.brcm.ad.broadcom.com> <7.0.1.0.0.20060519014730.06a6b2d0@gont.com.ar> In-Reply-To: <7.0.1.0.0.20060519014730.06a6b2d0@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Fernando Gont wrote: ... > Have a look at Paul Watson's presentation at CanSecWest 2004, and at the > tcp-secure document of this WG. FWIW, the citations in tcp-antispoof are more complete (include a URL, e.g., for Paul's presentation, as well as a number of other citations) on this issue. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri May 19 01:54:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgxwN-0005EN-GO; Fri, 19 May 2006 01:54:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgxwM-00059g-Su for tcpm@ietf.org; Fri, 19 May 2006 01:54:22 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgxiu-00031Z-1K for tcpm@ietf.org; Fri, 19 May 2006 01:40:30 -0400 Received: from [128.9.176.38] (c1-vpn8.isi.edu [128.9.176.38]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4J5eBV12612; Thu, 18 May 2006 22:40:11 -0700 (PDT) Message-ID: <446D5A33.8020202@isi.edu> Date: Thu, 18 May 2006 22:40:03 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Fernando Gont References: <7.0.1.0.0.20060518035047.06d3d718@gont.com.ar> <446C83E6.4030901@isi.edu> <7.0.1.0.0.20060519013043.06a4ef68@gont.com.ar> In-Reply-To: <7.0.1.0.0.20060519013043.06a4ef68@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: tcpm@ietf.org Subject: [tcpm] Re: Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Fernando Gont wrote: > At 11:25 18/05/2006, Joe Touch wrote: > >>> In section 4 ("ICMP") of the document, in my opinion there are some >>> issues that are missing. >>> In the case of the ICMP-based connection reset attack, the main >>> counter-measure is to change TCP's reaction to hard errors. >> >> The primary countermeasure is already deployed - to block ICMPs. This >> does not require a modification to TCP. This allows the filtering to >> determine the level of protection afforded, rather than wiring all >> TCPs to include such filtering natively. The latter essentially >> deprecates the capabilities afforded by hard errors in trusted >> environments - e.g., behind firewalls, inside VPNs, etc., and seems >> overkill. > > I strongly disagree. And so do existing implementations. > > All BSD-derived and Mentat-derived TCP/IP stacks treat the so-called > "hard errors" as "soft errors". > I don't know what Microsoft Windows' stack is derived from. But they > published an advisory on this issue, and their patch is supposed to > treat "hard errors" as "soft errors", too. > > Cisco treats the "so called" hard errors as "soft errors", too, IIRC. > > On the other hand, I disagree that "blocking ICMPs" is already deployed. > Try traceroute. Try ping. They still work. PMTUD works to a large > extent, too. In environments where security is an issue, where connections are vulnerable to ICMP attacks, ICMP is blocked. Try pinging hosts behind firewalls or NATs. To the extent that existing implementations violate RFC1122, they do. This isn't the first case of such errors; an RFC was written documenting a number of TCP bugs a while back. ;-) >> The document already cites that draft (I can issue a quick update to >> fix the ref to the Feb 06 TCPM version, if that matters). > > My point is that the antispoof draft is not citing the ICMP attacks > draft properly. You just mention the TCP seq checking, when that's less > than 10% of the draft. I can add the fact that the ICMP attacks draft proposes modifications to TCP that reduce the impact of hard errors the same way that blocking such ICMPs would. >>> The rationale for this is included in the ICMP attacks draft. If the >>> counter-measure was just to check the TCP seq number, then, as long >>> as the RFCs are concerned, that would give us the same level of >>> "protection" TCP already has for TCP-based reset attacks (i.e., >>> require the forged packet to be "in window"). Thus, ICMP would still >>> be "the weakest link in the chain". >>> As for the filtering of ICMP messages, it is interesting to note that >>> while ICMP messages can be inserted anywhere in the network (without >>> even needing to spoof the source IP address), address spoofing *is* >>> needed in the ICMP payload, and thus ingress/egress filtering can be >>> performed based on the ICMP payload. >> >> Filtering on the payload is less useful than filtering on the source >> address; the ICMP packet may be allowed to take a path that the source >> address is not, so it's not necessarily appropriate to make filtering >> decisions on the payload. > > I don't get your point. I don;t see the difference between > ingress/egress filtering based on the outer IP datagram (for IP > packets), and based on the inner IP datagrams (for ICMP error messages). The outer packet can go along paths that are not necessarily valid for the inner packet. There's no reason to enforce filtering on the signalling packet's contents in that case. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri May 19 03:00:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgyyS-00072Q-WA; Fri, 19 May 2006 03:00:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgyyR-00071q-98 for tcpm@ietf.org; Fri, 19 May 2006 03:00:35 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgyyO-0000N9-KI for tcpm@ietf.org; Fri, 19 May 2006 03:00:35 -0400 Received: from fgont.gont.com.ar ([201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4J70FTX000443; Fri, 19 May 2006 04:00:27 -0300 Message-Id: <7.0.1.0.0.20060519031314.06a79038@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 19 May 2006 03:26:03 -0300 To: Joe Touch From: Fernando Gont In-Reply-To: <446D5A33.8020202@isi.edu> References: <7.0.1.0.0.20060518035047.06d3d718@gont.com.ar> <446C83E6.4030901@isi.edu> <7.0.1.0.0.20060519013043.06a4ef68@gont.com.ar> <446D5A33.8020202@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: tcpm@ietf.org Subject: [tcpm] Re: Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 02:40 19/05/2006, Joe Touch wrote: >>All BSD-derived and Mentat-derived TCP/IP stacks treat the >>so-called "hard errors" as "soft errors". >>I don't know what Microsoft Windows' stack is derived from. But >>they published an advisory on this issue, and their patch is >>supposed to treat "hard errors" as "soft errors", too. >>Cisco treats the "so called" hard errors as "soft errors", too, IIRC. >>On the other hand, I disagree that "blocking ICMPs" is already >>deployed. Try traceroute. Try ping. They still work. PMTUD works to >>a large extent, too. > >In environments where security is an issue, where connections are >vulnerable to ICMP attacks, ICMP is blocked. Try pinging hosts >behind firewalls or NATs. In the case of firewalls, ICMP will be filtered when access to the actual system is forbidden. In the case of NAT, the fact that you cannot ping systems usually have to do with the fact that there are many systems in the private address space, rather than because of "ICMP filtering". >To the extent that existing implementations violate RFC1122, they >do. This isn't the first case of such errors; an RFC was written >documenting a number of TCP bugs a while back. ;-) Reacting to protocol unreachables (as RFC 1122 mandates) means that you may reset a connection upon receipt of an ICMP error message that might have been elicited by a corrupted segment. Do you think that's correct? NetBSD, FreeBSD, OpenBSD, Linux, Cisco, Microsoft Windows, Solaris, et al, are all wrong, right? C'mon, Joe. >>>The document already cites that draft (I can issue a quick update >>>to fix the ref to the Feb 06 TCPM version, if that matters). >>My point is that the antispoof draft is not citing the ICMP attacks >>draft properly. You just mention the TCP seq checking, when that's >>less than 10% of the draft. > >I can add the fact that the ICMP attacks draft proposes >modifications to TCP that reduce the impact of hard errors the same >way that blocking such ICMPs would. Treating "hard errors" as "soft errors" is an error, but blocking ICMP is not? C'mon Joe, we have already been over this. >>>>The rationale for this is included in the ICMP attacks draft. If >>>>the counter-measure was just to check the TCP seq number, then, >>>>as long as the RFCs are concerned, that would give us the same >>>>level of "protection" TCP already has for TCP-based reset attacks >>>>(i.e., require the forged packet to be "in window"). Thus, ICMP >>>>would still be "the weakest link in the chain". >>>>As for the filtering of ICMP messages, it is interesting to note >>>>that while ICMP messages can be inserted anywhere in the network >>>>(without even needing to spoof the source IP address), address >>>>spoofing *is* needed in the ICMP payload, and thus ingress/egress >>>>filtering can be performed based on the ICMP payload. >>> >>>Filtering on the payload is less useful than filtering on the >>>source address; the ICMP packet may be allowed to take a path that >>>the source address is not, so it's not necessarily appropriate to >>>make filtering decisions on the payload. >>I don't get your point. I don;t see the difference between >>ingress/egress filtering based on the outer IP datagram (for IP >>packets), and based on the inner IP datagrams (for ICMP error messages). > >The outer packet can go along paths that are not necessarily valid >for the inner packet. There's no reason to enforce filtering on the >signalling packet's contents in that case. I wrote this for a friend: http://www.gont.com.ar/papers/icmp-errors . Again, if we're talking about "performance", that's a different issue. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri May 19 12:00:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh7Ol-0008QV-DG; Fri, 19 May 2006 12:00:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh7Od-0008KK-86 for tcpm@ietf.org; Fri, 19 May 2006 12:00:11 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh7Ob-0000j5-WC for tcpm@ietf.org; Fri, 19 May 2006 12:00:11 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id IAB06479; Fri, 19 May 2006 08:59:58 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k4JG00G09677; Fri, 19 May 2006 11:00:00 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 May 2006 08:59:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] Comments on draft-ietf-tcpm-icmp-attacks-00.txt Date: Fri, 19 May 2006 08:59:51 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1818C37@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <7.0.1.0.0.20060519020027.06a860e8@gont.com.ar> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Comments on draft-ietf-tcpm-icmp-attacks-00.txt Thread-Index: AcZ7BP9vKdJ1E80zQJSdAYd87+2g1wAWAqqQ From: "Templin, Fred L" To: "Fernando Gont" , X-OriginalArrivalTime: 19 May 2006 15:59:52.0808 (UTC) FILETIME=[43E7D680:01C67B5D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Fernando, >> 14) Appendix A, Section A.2, need to tell what MAXSEGRTO >> is set to for the purpose of the example. > > See the introduction of Appendix A. It says that for all the=20 > following examples, MAXSEGRTO is set to 1. OK, I see it there now; looks fine. Fred fred.l.templin@boeing.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri May 19 12:45:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh85f-0007ua-9d; Fri, 19 May 2006 12:44:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh85d-0007uQ-Nb for tcpm@ietf.org; Fri, 19 May 2006 12:44:37 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh85b-0003Yv-BJ for tcpm@ietf.org; Fri, 19 May 2006 12:44:37 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4JGhKV23806; Fri, 19 May 2006 09:43:20 -0700 (PDT) Message-ID: <446DF5A0.3040607@isi.edu> Date: Fri, 19 May 2006 09:43:12 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Fernando Gont References: <7.0.1.0.0.20060518035047.06d3d718@gont.com.ar> <446C83E6.4030901@isi.edu> <7.0.1.0.0.20060519013043.06a4ef68@gont.com.ar> <446D5A33.8020202@isi.edu> <7.0.1.0.0.20060519031314.06a79038@gont.com.ar> In-Reply-To: <7.0.1.0.0.20060519031314.06a79038@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 97adf591118a232206bdb5a27b217034 Cc: tcpm@ietf.org Subject: [tcpm] Re: Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Fernando Gont wrote: > NetBSD, FreeBSD, OpenBSD, Linux, Cisco, Microsoft Windows, Solaris, et > al, are all wrong, right? Screaming 'fire' in a crowded marketplace is a great way to get vendors to jump (off a cliff) - consider the RST stuff, which is NOT needed by end hosts, but has made it into virtually every OS as well. Lemmings are lemmings; they're not always right. >> I can add the fact that the ICMP attacks draft proposes modifications >> to TCP that reduce the impact of hard errors the same way that >> blocking such ICMPs would. > > Treating "hard errors" as "soft errors" is an error, but blocking ICMP > is not? Where in the above proposed text is either solution described as an error? ... >> The outer packet can go along paths that are not necessarily valid for >> the inner packet. There's no reason to enforce filtering on the >> signalling packet's contents in that case. > > I wrote this for a friend: http://www.gont.com.ar/papers/icmp-errors . Your analysis (and some of the work of many throughout this WG, as well) tends to assume that everything unexpected is a deliberate attack, and thus must be quenched. What if the unexpected is legitimate? What capability are you disabling as a result? Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri May 19 13:43:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh90U-0008TQ-Eu; Fri, 19 May 2006 13:43:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh90S-0008TL-W3 for tcpm@ietf.org; Fri, 19 May 2006 13:43:20 -0400 Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh90S-0008Bx-LB for tcpm@ietf.org; Fri, 19 May 2006 13:43:20 -0400 Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Fri, 19 May 2006 10:43:09 -0700 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 06C982B0; Fri, 19 May 2006 10:43:09 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id CDA872AF; Fri, 19 May 2006 10:43:08 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id DOG32413; Fri, 19 May 2006 10:43:07 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 2206320501; Fri, 19 May 2006 10:43:07 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] Comments on draft-ietf-tcpm-icmp-attacks-00.txt Date: Fri, 19 May 2006 10:43:06 -0700 Message-ID: <03235919BBDE634289BB6A0758A20B365EB185@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [tcpm] Comments on draft-ietf-tcpm-icmp-attacks-00.txt Thread-Index: AcZ7BQLJnCmVSZ7VTNaqYpQw0sOguwAZfSMw From: "Bora Akyol" To: "Fernando Gont" , tcpm@ietf.org X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006051907; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230312E34343645303136302E303030462D412D; ENG=IBF; TS=20060519174310; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006051907_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 6870DC273NG18304996-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org No This is wrong. I have read the tcp secure document and seen the presentation as well. I am not contesting that you need to guess the sequence number to succeed, this is obvious. I also know that it is easier than initially thought to guess the sequence number even when the attacker is off-path. My point is that you assume that a firewall somewhere in the network has the information to decide what packets can originate from where and filter it.=20 The benefit of implementing this feature is minimal IMHO at a considerable complexity to hardware implementations. Can you also document how this works with mobile IP and other protocols that use a care of address (I believe some of the Wireless LAN tunneling does this too). Bora =20 > -----Original Message----- > From: Fernando Gont [mailto:fernando@gont.com.ar]=20 > Sent: Thursday, May 18, 2006 9:58 PM > To: Bora Akyol; tcpm@ietf.org > Subject: RE: [tcpm] Comments on draft-ietf-tcpm-icmp-attacks-00.txt >=20 > At 13:08 18/05/2006, Bora Akyol wrote: >=20 > >I have one question regarding section 4.3 in this document. > > > >Since the attacker needs to guess both ends of the TCP connection=20 > >including IP addresses and TCP ports, I am not sure what the=20 > benefit of=20 > >ICMP payload parsing is in this case. > > > >I am sure I missed something here. >=20 > The "benefit" is being a good network citizen. When you=20 > perform egress-filtering, you preventyour own users from=20 > performing ICMP-based attacks against systems that belong to=20 > other networks. >=20 > Regarding that of having to guess the two-endpoints of the=20 > TCP connection, the answer is simple: Even TCP-based attacks,=20 > in which you have to guess not only both endpoints, but=20 > *also* the TCP sequence number, are of concern nowadays. >=20 > Have a look at Paul Watson's presentation at CanSecWest 2004,=20 > and at the tcp-secure document of this WG. >=20 > Kindest regards, >=20 > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org PGP=20 > Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 >=20 >=20 >=20 >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri May 19 13:49:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh95u-0003AJ-Dy; Fri, 19 May 2006 13:48:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh95t-00038B-9Z for tcpm@ietf.org; Fri, 19 May 2006 13:48:57 -0400 Received: from mms1.broadcom.com ([216.31.210.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh95r-0008PE-VG for tcpm@ietf.org; Fri, 19 May 2006 13:48:57 -0400 Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Fri, 19 May 2006 10:48:48 -0700 X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 4F60E2B1; Fri, 19 May 2006 10:48:48 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 1C45C2AE for ; Fri, 19 May 2006 10:48:48 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id DOG35203; Fri, 19 May 2006 10:48:47 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id B7E4B20501 for ; Fri, 19 May 2006 10:48:47 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 19 May 2006 10:48:47 -0700 Message-ID: <03235919BBDE634289BB6A0758A20B365EB188@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: ICMP and TCP Thread-Index: AcZ7bHqa3+qYS/iSRyqcxUjgqgbfpw== From: "Bora Akyol" To: tcpm@ietf.org X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006051907; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230382E34343645303242322E303037302D412D; ENG=IBF; TS=20060519174850; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006051907_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 6870DA8A0HW20525553-01-01 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: [tcpm] ICMP and TCP 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="===============0165097510==" Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. --===============0165097510== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C67B6C.7AE95A1D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C67B6C.7AE95A1D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Should we stop beating around the bush and cut the cord between these two altogether? Even PMTU discovery is really an L3 function. =20 What the icmp/tcp draft proposes turns all hard errors to soft anyway, why not just cut the cord and let TCP react to only the other peer TCP. =20 Bora =20 ------_=_NextPart_001_01C67B6C.7AE95A1D Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable
Should = we stop=20 beating around the bush and cut the cord between these two altogether?=20 Even
PMTU = discovery is=20 really an L3 function.
 
What = the icmp/tcp=20 draft proposes turns all hard errors to soft anyway, why not just cut = the cord=20 and
let = TCP react to=20 only the other peer TCP.
 
Bora
 
------_=_NextPart_001_01C67B6C.7AE95A1D-- --===============0165097510== 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 --===============0165097510==-- From tcpm-bounces@ietf.org Fri May 19 13:54:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9BG-0004zJ-Di; Fri, 19 May 2006 13:54:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9BF-0004zE-11 for tcpm@ietf.org; Fri, 19 May 2006 13:54:29 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh9BC-0000PS-OI for tcpm@ietf.org; Fri, 19 May 2006 13:54:28 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id MAA00382; Fri, 19 May 2006 12:54:23 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k4JHsNr29587; Fri, 19 May 2006 10:54:23 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 May 2006 10:54:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] ICMP and TCP Date: Fri, 19 May 2006 10:54:19 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1818C3C@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <03235919BBDE634289BB6A0758A20B365EB188@NT-SJCA-0751.brcm.ad.broadcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] ICMP and TCP Thread-Index: AcZ7bHqa3+qYS/iSRyqcxUjgqgbfpwAAFQkg From: "Templin, Fred L" To: "Bora Akyol" , X-OriginalArrivalTime: 19 May 2006 17:54:22.0092 (UTC) FILETIME=[425164C0:01C67B6D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1070534588==" Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. --===============1070534588== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C67B6D.40D7D368" This is a multi-part message in MIME format. ------_=_NextPart_001_01C67B6D.40D7D368 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bora - are you suggesting that TCP should ignore all ICMPs? I think I can understand the motivation, but some might object. =20 Fred fred.l.templin@boeing.com ________________________________ From: Bora Akyol [mailto:bora@broadcom.com]=20 Sent: Friday, May 19, 2006 10:49 AM To: tcpm@ietf.org Subject: [tcpm] ICMP and TCP Should we stop beating around the bush and cut the cord between these two altogether? Even PMTU discovery is really an L3 function. =20 What the icmp/tcp draft proposes turns all hard errors to soft anyway, why not just cut the cord and let TCP react to only the other peer TCP. =20 Bora =20 ------_=_NextPart_001_01C67B6D.40D7D368 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Bora - are you suggesting that TCP should ignore all ICMPs? = I
think I can understand the motivation, but some might=20 object.
 
Fred
fred.l.templin@boeing.com

From: Bora Akyol = [mailto:bora@broadcom.com]=20
Sent: Friday, May 19, 2006 10:49 AM
To:=20 tcpm@ietf.org
Subject: [tcpm] ICMP and = TCP

Should = we stop=20 beating around the bush and cut the cord between these two altogether?=20 Even
PMTU = discovery is=20 really an L3 function.
 
What = the icmp/tcp=20 draft proposes turns all hard errors to soft anyway, why not just cut = the cord=20 and
let = TCP react to=20 only the other peer TCP.
 
Bora
 
------_=_NextPart_001_01C67B6D.40D7D368-- --===============1070534588== 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 --===============1070534588==-- From tcpm-bounces@ietf.org Fri May 19 13:56:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9DF-0005Q0-8f; Fri, 19 May 2006 13:56:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9DE-0005Pv-Cc for tcpm@ietf.org; Fri, 19 May 2006 13:56:32 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh9DD-0000X0-2H for tcpm@ietf.org; Fri, 19 May 2006 13:56:32 -0400 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4JHsXV12516; Fri, 19 May 2006 10:54:33 -0700 (PDT) Message-ID: <446E065B.6020105@isi.edu> Date: Fri, 19 May 2006 10:54:35 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Bora Akyol Subject: Re: [tcpm] ICMP and TCP References: <03235919BBDE634289BB6A0758A20B365EB188@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <03235919BBDE634289BB6A0758A20B365EB188@NT-SJCA-0751.brcm.ad.broadcom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 7655788c23eb79e336f5f8ba8bce7906 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Bora Akyol wrote: > Should we stop beating around the bush and cut the cord between these > two altogether? Even > PMTU discovery is really an L3 function. > > What the icmp/tcp draft proposes turns all hard errors to soft anyway, > why not just cut the cord and > let TCP react to only the other peer TCP. That won't help find out when the other peer isn't there (host unreachable), TCP isn't there (protocol unreachable), or network isn't there (net unreachable). Those turn out to be useful; if we care about short-circuiting IPv6 attempts to fall-back on IPv4 attempts, then we ought to care as much about these errors, which are equivalently important. (and when a host or net decides they're a security risk, the host or net can disable them) Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri May 19 14:05:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9M0-0005m8-Fr; Fri, 19 May 2006 14:05:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9Lz-0005m3-1C for tcpm@ietf.org; Fri, 19 May 2006 14:05:35 -0400 Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh9Lw-00012P-M3 for tcpm@ietf.org; Fri, 19 May 2006 14:05:35 -0400 Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Fri, 19 May 2006 11:05:18 -0700 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 63AF52AF; Fri, 19 May 2006 11:05:18 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 421892AE; Fri, 19 May 2006 11:05:18 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id DOG42550; Fri, 19 May 2006 11:05:17 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 884CF20501; Fri, 19 May 2006 11:05:17 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] ICMP and TCP Date: Fri, 19 May 2006 11:05:16 -0700 Message-ID: <03235919BBDE634289BB6A0758A20B365EB195@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [tcpm] ICMP and TCP Thread-Index: AcZ7bHqa3+qYS/iSRyqcxUjgqgbfpwAAFQkgAAA67bA= From: "Bora Akyol" To: "Templin, Fred L" , tcpm@ietf.org X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006051907; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230332E34343645303639332E303037332D412D; ENG=IBF; TS=20060519180522; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006051907_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 6870D7543NG18309513-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org After reading the tcp/icmp draft, this is what I am suggesting. =20 The logic for what constitutes a hard error vs what constitutes a soft error is getting convoluted.=20 =20 Error X is hard when TCP is in Y state, but not Z state, and it is ignore when TCP is in Q state but not when in X state. Otherwise, it is a soft error. =20 Yep, as a software engineer, I believe anything can be made to work given enough time and devtest, but at what cost. What if we unplugged TCP from ICMP altogether. What exactly do we lose? 1) Path MTU, this is an IP layer functionality. TCP is just a bystander. 2) Port unreachable, host unreachable etc type messages. This can be fixed within TCP itself=20 by reclaiming resources are generalizing some of the optimizations presented in draft-eddy-syn-flood. 3) Source quench. Yawn, who cares ;-) So what else do we lose if we lose ICMP altogether? Sorry, not trying to be controversial here, just trying to take a different approach. Thanks Bora ________________________________ From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 Sent: Friday, May 19, 2006 10:54 AM To: Bora Akyol; tcpm@ietf.org Subject: RE: [tcpm] ICMP and TCP =09 =09 Bora - are you suggesting that TCP should ignore all ICMPs? I think I can understand the motivation, but some might object. =20 Fred fred.l.templin@boeing.com ________________________________ From: Bora Akyol [mailto:bora@broadcom.com]=20 Sent: Friday, May 19, 2006 10:49 AM To: tcpm@ietf.org Subject: [tcpm] ICMP and TCP =09 =09 Should we stop beating around the bush and cut the cord between these two altogether? Even PMTU discovery is really an L3 function. =20 What the icmp/tcp draft proposes turns all hard errors to soft anyway, why not just cut the cord and let TCP react to only the other peer TCP. =20 Bora _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri May 19 14:08:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9Oc-0006MB-6E; Fri, 19 May 2006 14:08:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9Oa-0006M6-1Y for tcpm@ietf.org; Fri, 19 May 2006 14:08:16 -0400 Received: from mms2.broadcom.com ([216.31.210.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh9OZ-0001E2-NW for tcpm@ietf.org; Fri, 19 May 2006 14:08:16 -0400 Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Fri, 19 May 2006 11:08:06 -0700 X-Server-Uuid: D9EB6F12-1469-4C1C-87A2-5E4C0D6F9D06 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id E4BDD2B0; Fri, 19 May 2006 11:08:05 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id C1B142AF; Fri, 19 May 2006 11:08:05 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id DOG44028; Fri, 19 May 2006 11:08:05 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 1276B20502; Fri, 19 May 2006 11:08:05 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] ICMP and TCP Date: Fri, 19 May 2006 11:08:04 -0700 Message-ID: <03235919BBDE634289BB6A0758A20B365EB198@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [tcpm] ICMP and TCP Thread-Index: AcZ7bZlPjXfRXCXsSxaQatVrd3KlfgAATRww From: "Bora Akyol" To: "Joe Touch" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006051907; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230362E34343645303733352E303031442D412D; ENG=IBF; TS=20060519180806; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006051907_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 6870D60C4I813180172-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Joe Please see my other email, I think it was wrong for TCP to rely on these in the first place. The logic was that all L4 protocols can share the same control protocol in ICMP, but how does this help when L4 protocols are so divergent in their nature? How does this help, when the security of one protocol is so tightly coupled with another. How does it help, when responses to hard errors now become dependent on the state we're in ;-) I think lack of all the *+unreachable messages can be handled within TCP. Thanks Bora > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU]=20 > Sent: Friday, May 19, 2006 10:55 AM > To: Bora Akyol > Cc: tcpm@ietf.org > Subject: Re: [tcpm] ICMP and TCP >=20 >=20 >=20 > Bora Akyol wrote: > > Should we stop beating around the bush and cut the cord=20 > between these=20 > > two altogether? Even PMTU discovery is really an L3 function. > > =20 > > What the icmp/tcp draft proposes turns all hard errors to=20 > soft anyway,=20 > > why not just cut the cord and let TCP react to only the other peer=20 > > TCP. >=20 > That won't help find out when the other peer isn't there=20 > (host unreachable), TCP isn't there (protocol unreachable),=20 > or network isn't there (net unreachable). >=20 > Those turn out to be useful; if we care about=20 > short-circuiting IPv6 attempts to fall-back on IPv4 attempts,=20 > then we ought to care as much about these errors, which are=20 > equivalently important. >=20 > (and when a host or net decides they're a security risk, the=20 > host or net can disable them) >=20 > Joe >=20 >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri May 19 14:08:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9PH-0006gj-L2; Fri, 19 May 2006 14:08:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9PG-0006fw-2f for tcpm@ietf.org; Fri, 19 May 2006 14:08:58 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh9PD-0001Fh-If for tcpm@ietf.org; Fri, 19 May 2006 14:08:58 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060308/8.12.11) with ESMTP id k4JI8hh8000479; Fri, 19 May 2006 21:08:43 +0300 Date: Fri, 19 May 2006 21:08:43 +0300 (EEST) From: Pekka Savola To: Joe Touch Subject: Re: [tcpm] Re: Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt In-Reply-To: <446DF5A0.3040607@isi.edu> Message-ID: References: <7.0.1.0.0.20060518035047.06d3d718@gont.com.ar> <446C83E6.4030901@isi.edu> <7.0.1.0.0.20060519013043.06a4ef68@gont.com.ar> <446D5A33.8020202@isi.edu> <7.0.1.0.0.20060519031314.06a79038@gont.com.ar> <446DF5A0.3040607@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1469/Thu May 18 23:27:11 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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: , Errors-To: tcpm-bounces@ietf.org On Fri, 19 May 2006, Joe Touch wrote: >> I wrote this for a friend: http://www.gont.com.ar/papers/icmp-errors . > > Your analysis (and some of the work of many throughout this WG, as well) > tends to assume that everything unexpected is a deliberate attack, and thus > must be quenched. What if the unexpected is legitimate? What capability are > you disabling as a result? Joe, That's exactly the questions I'd like you to answer regarding your suggestion that ignoring ICMP error messages (wrt. IPsec for instance) is good thing to do. -- 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 May 19 14:27:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9hL-0003dT-BM; Fri, 19 May 2006 14:27:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9hK-0003dO-De for tcpm@ietf.org; Fri, 19 May 2006 14:27:38 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh9hI-00029I-2C for tcpm@ietf.org; Fri, 19 May 2006 14:27:38 -0400 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4JIQXV20846; Fri, 19 May 2006 11:26:33 -0700 (PDT) Message-ID: <446E0DDB.3040404@isi.edu> Date: Fri, 19 May 2006 11:26:35 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Pekka Savola Subject: Re: [tcpm] Re: Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt References: <7.0.1.0.0.20060518035047.06d3d718@gont.com.ar> <446C83E6.4030901@isi.edu> <7.0.1.0.0.20060519013043.06a4ef68@gont.com.ar> <446D5A33.8020202@isi.edu> <7.0.1.0.0.20060519031314.06a79038@gont.com.ar> <446DF5A0.3040607@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 2409bba43e9c8d580670fda8b695204a 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: , Errors-To: tcpm-bounces@ietf.org Pekka Savola wrote: > On Fri, 19 May 2006, Joe Touch wrote: >>> I wrote this for a friend: http://www.gont.com.ar/papers/icmp-errors . >> >> Your analysis (and some of the work of many throughout this WG, as >> well) tends to assume that everything unexpected is a deliberate >> attack, and thus must be quenched. What if the unexpected is >> legitimate? What capability are you disabling as a result? > > Joe, > > That's exactly the questions I'd like you to answer regarding your > suggestion that ignoring ICMP error messages (wrt. IPsec for instance) > is good thing to do I don't think it is in general. I think that IF you have a security concern, then you can decide to turn them off FOR YOURSELF (or at your firewall). But that's no different from blocking certain ports or protocols due to security concerns. I don't want to dictate that sort of behavior for the protocol as a rule exactly because it turns off a capability for those not under attack. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri May 19 14:31:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9kb-00056C-VM; Fri, 19 May 2006 14:31:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9ka-000562-Sq for tcpm@ietf.org; Fri, 19 May 2006 14:31:00 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh9kY-0002Kb-Ki for tcpm@ietf.org; Fri, 19 May 2006 14:31:00 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id NAA20198; Fri, 19 May 2006 13:30:57 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k4JIUvG16464; Fri, 19 May 2006 13:30:57 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 May 2006 11:30:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] ICMP and TCP Date: Fri, 19 May 2006 11:30:50 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1818C3D@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <03235919BBDE634289BB6A0758A20B365EB195@NT-SJCA-0751.brcm.ad.broadcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] ICMP and TCP Thread-Index: AcZ7bHqa3+qYS/iSRyqcxUjgqgbfpwAAFQkgAAA67bAAAQ4GoA== From: "Templin, Fred L" To: "Bora Akyol" , X-OriginalArrivalTime: 19 May 2006 18:30:51.0012 (UTC) FILETIME=[5B041440:01C67B72] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Bora, > 1) Path MTU, this is an IP layer functionality. TCP is just a bystander. How can you expect the IP layer to implement robust Path MTU when ICMP "packet too big" messages may be forgeries or missing altogether? See: http://www.ietf.org/html.charters/pmtud-charter.html Fred fred.l.templin@boeing.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri May 19 14:54:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhA6M-0007Ek-Fm; Fri, 19 May 2006 14:53:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhA6L-0007Ef-7D for tcpm@ietf.org; Fri, 19 May 2006 14:53:29 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhA6I-0004Y2-P1 for tcpm@ietf.org; Fri, 19 May 2006 14:53:29 -0400 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4JIqaV26948; Fri, 19 May 2006 11:52:36 -0700 (PDT) Message-ID: <446E13F6.6000800@isi.edu> Date: Fri, 19 May 2006 11:52:38 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Ted Faber Subject: Re: [tcpm] draft-ietf-rddp-mpa-03.txt review request References: <20060518174843.GK40285@hut.isi.edu> In-Reply-To: <20060518174843.GK40285@hut.isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 67c1ea29f88502ef6a32ccec927970f0 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Ted Faber wrote: > Hi, > > The draft draft-ietf-rddp-mpa-03.txt is up for review as a Proposed > Standard, and Lars thinks that TCPM review is essential. Mark and I > agree. OK, so I gave this a quick (very quick) look yesterday for some deeper feedback. Here are the two primary points. For those of you in a rush, jump to item #2. It's sufficient, IMO. Joe ---- #1 First, I'm not in favor of a protocol spec that passively depends on implementation-specific behavior of another protocol. IMO, there are two valid options: a) discover the behavior explicitly, e.g., by trying sends with offsets of garbage, and see when your PDU aligns with TCPs segment (i.e., how buffer offset tuning works, e.g., where using buffers slightly offset from page boundaries tends to have higher performance) b) negotiate the desired behavior via an API, e.g., a socket parameter This document does neither; it presents a mechanism for exploiting implementation artifacts. I'm very worried about a spec that has that basis; it will tend to encourage defacto-standardization of those artifacts, which would be a bad thing. ---- #2 However, second - and probably more important is that this document redefines TCP ("MPA-aware TCP"); that's not in the purvue of RDDP, and I would expect this change to be _the_ impediment to this document going forward. Here are some examples: Page 14, section 3.1.2 makes SHOULD recommendations that TCP deliver out-of-order segments to the application layer (i.e., the layer above TCP) even when there are gaps. Let's call that data 'partly received', i.e., SACK-able and stored by the receiver but _prohibited_ from being passed to the app. It requires that TCP MUST NOT overwrite partly-received data; this is allowed by TCP. I.e., the received stream of MPA-enabled TCP and TCP would be different. ---- #3 FURTHER, MPA-enabled is indicated by a port or service locator protocol (see page 31, sec 6.1); this suggests that a _change to TCP semantics_ is governed by an application layer signal alone, rather than by a socket option. I do not believe that RDDP should be designing variants of TCP regardless (that should occur in TCPM or TSVWG). When such variants are designed, IMO they MUST be signalled by a socket option (from app to TCP) and/or TCP flag/option (between TCP endpoints). It is inappropriate to rely solely on the combination application layer signals and TCP's parsing of the data stream for this operation (e.g., checking for MPA payloads). ---- IMO, MPA is using TCP where it really should be using one of RDP or SCTP. I see no reason to modify the semantics of TCP - even as an option - to support capabilities already present in these other protocols. Joe Here's the abstract: > > MPA (Marker Protocol data unit Aligned framing) is designed to work > as an "adaptation layer" between TCP and the Direct Data Placement > [DDP] protocol, preserving the reliable, in-order delivery of TCP, > while adding the preservation of higher-level protocol record > boundaries that DDP requires. MPA is fully compliant with applicable > TCP RFCs and can be utilized with existing TCP implementations. MPA > also supports integrated implementations that combine TCP, MPA and > DDP to reduce buffering requirements in the implementation and > improve performance at the system level. > > I'd like to get a couple reviewers now who are committed to providing > reviews by the end of the month or so. David Black, the RDDP chair, is > interested in our feedback and in working out issues that arise. > > Lars has read this and claims that though it's long, it is very > readable. I don't think it'll be another ROHC or behave multi-draft > scavenger hunt. > > If you're interested in this and willing to provide a review, please let > me and Mark know. If we don't get volunteers, we'll start calling on > people. > > A cool thing that Lars has subtlely pointed out to me is that an easy > way to reach Mark and me, or our eventual replacements, is > tcpm-chairs@ietf.org. That would be a great address to test by > volunteering to review this draft. > > Thanks! > > > > ------------------------------------------------------------------------ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri May 19 15:33:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhAjK-0007rY-DJ; Fri, 19 May 2006 15:33:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhAjK-0007rT-2J for tcpm@ietf.org; Fri, 19 May 2006 15:33:46 -0400 Received: from mail2.microsoft.com ([131.107.1.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhAjI-0006NG-P5 for tcpm@ietf.org; Fri, 19 May 2006 15:33:46 -0400 Received: from mailout5.microsoft.com ([157.54.69.148]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 May 2006 12:33:43 -0700 Received: from tuk-hub-04.redmond.corp.microsoft.com ([157.54.70.30]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 May 2006 12:33:43 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by tuk-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 May 2006 12:33:43 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.26]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 May 2006 12:33:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] Re: Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt Date: Fri, 19 May 2006 12:33:40 -0700 Message-ID: <70C6EFCDFC8AAD418EF7063CD132D064B1980C@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <446E0DDB.3040404@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Re: Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt thread-index: AcZ7cipJWHV5qvVTSneU0DDediWpmQACFeZQ From: "Christian Huitema" To: "Joe Touch" , "Pekka Savola" X-OriginalArrivalTime: 19 May 2006 19:33:43.0037 (UTC) FILETIME=[23516AD0:01C67B7B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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: , Errors-To: tcpm-bounces@ietf.org > > That's exactly the questions I'd like you to answer regarding your > > suggestion that ignoring ICMP error messages (wrt. IPsec for instance) > > is good thing to do >=20 > I don't think it is in general. I think that IF you have a security > concern, then you can decide to turn them off FOR YOURSELF (or at your > firewall). But that's no different from blocking certain ports or > protocols due to security concerns. So, Joe, you agree that at least some systems will simply ignore ICMP, e.g. because a firewall is programmed to drop all ICMP messages. It seems then that TCPM should be concerned with the behavior of TCP in such environments. It would be nice to have ICMP-less alternatives for the problems that you mention, starting with PMTU discovery, v6/v4 fall back, etc. -- Christian Huitema _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri May 19 15:47:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhAwP-0005lj-RJ; Fri, 19 May 2006 15:47:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhAwO-0005le-De for tcpm@ietf.org; Fri, 19 May 2006 15:47:16 -0400 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhAwN-0007eo-62 for tcpm@ietf.org; Fri, 19 May 2006 15:47:16 -0400 Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id E6AB647C97 for ; Fri, 19 May 2006 15:47:14 -0400 (EDT) Received: from basie.internet2.edu ([127.0.0.1]) by localhost (basie.internet2.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18206-08 for ; Fri, 19 May 2006 15:47:14 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id CB2A447C85 for ; Fri, 19 May 2006 15:47:14 -0400 (EDT) Date: Fri, 19 May 2006 15:47:01 -0400 From: Matthew J Zekauskas To: tcpm@ietf.org Subject: RE: [tcpm] Re: Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt Message-ID: <0A6D76B6DA377E517F2C9950@DCFF15AFC1F6764BA3927E50> In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D064B1980C@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> References: <70C6EFCDFC8AAD418EF7063CD132D064B1980C@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.co m> X-Mailer: Mulberry/4.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by mail.internet2.edu virus scanner X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org pmtud is currently working on an ICMP-less PMTU discovery method (at least, one where you may ignore ICMP if you choose); We think the next rev of the method draft will be ready for WGLC. The next rev should be out within a week or so (fingers crossed). I invite interested folks to read and comment on the PMTUD list (pmtud@ietf.org). --Matt (pmtud co-chair) --On Friday, May 19, 2006 12:33 PM -0700 Christian Huitema wrote [exerpted]: > such environments. It would be nice to have ICMP-less alternatives for > the problems that you mention, starting with PMTU discovery, v6/v4 fall _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri May 19 16:17:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhBOv-0001Mb-PG; Fri, 19 May 2006 16:16:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhBOu-0001MW-Nf for tcpm@ietf.org; Fri, 19 May 2006 16:16:44 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhBOt-0001zL-Cy for tcpm@ietf.org; Fri, 19 May 2006 16:16:44 -0400 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4JKG4V16214; Fri, 19 May 2006 13:16:04 -0700 (PDT) Message-ID: <446E2786.2020704@isi.edu> Date: Fri, 19 May 2006 13:16:06 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Christian Huitema Subject: Re: [tcpm] Re: Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt References: <70C6EFCDFC8AAD418EF7063CD132D064B1980C@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D064B1980C@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 93238566e09e6e262849b4f805833007 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: , Errors-To: tcpm-bounces@ietf.org Christian Huitema wrote: >>> That's exactly the questions I'd like you to answer regarding your >>> suggestion that ignoring ICMP error messages (wrt. IPsec for > instance) >>> is good thing to do >> I don't think it is in general. I think that IF you have a security >> concern, then you can decide to turn them off FOR YOURSELF (or at your >> firewall). But that's no different from blocking certain ports or >> protocols due to security concerns. > > So, Joe, you agree that at least some systems will simply ignore ICMP, > e.g. because a firewall is programmed to drop all ICMP messages. It > seems then that TCPM should be concerned with the behavior of TCP in > such environments. It would be nice to have ICMP-less alternatives for > the problems that you mention, starting with PMTU discovery, v6/v4 fall > back, etc. ICMP-less solutions to PMTUD are being developed already. v4/v6 failover is an application issue; IMO, opening two connections in parallel is sufficient (and ICMP-less). Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri May 19 16:53:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhByL-0001GR-NC; Fri, 19 May 2006 16:53:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhByK-0001GK-IL for tcpm@ietf.org; Fri, 19 May 2006 16:53:20 -0400 Received: from mms2.broadcom.com ([216.31.210.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhByJ-00053y-7E for tcpm@ietf.org; Fri, 19 May 2006 16:53:20 -0400 Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Fri, 19 May 2006 13:53:06 -0700 X-Server-Uuid: D9EB6F12-1469-4C1C-87A2-5E4C0D6F9D06 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 86FDC2AF; Fri, 19 May 2006 13:53:06 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 607902AE; Fri, 19 May 2006 13:53:06 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id DOH09193; Fri, 19 May 2006 13:53:05 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id C10AE20501; Fri, 19 May 2006 13:53:05 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] ICMP and TCP Date: Fri, 19 May 2006 13:53:04 -0700 Message-ID: <03235919BBDE634289BB6A0758A20B365EB1D4@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [tcpm] ICMP and TCP Thread-Index: AcZ7bHqa3+qYS/iSRyqcxUjgqgbfpwAAFQkgAAA67bAAAQ4GoAAFDcaQ From: "Bora Akyol" To: "Templin, Fred L" , tcpm@ietf.org X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006051908; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230342E34343645324445342E303032312D452D5046786C33494E497A33445631553653544639524F673D3D; ENG=IBF; TS=20060519205307; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006051908_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 6870EFB84I813215012-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org This is why security of PMTU should be solved at the IP layer, don't you think? > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 > Sent: Friday, May 19, 2006 11:31 AM > To: Bora Akyol; tcpm@ietf.org > Subject: RE: [tcpm] ICMP and TCP >=20 > Bora, >=20 > > 1) Path MTU, this is an IP layer functionality. TCP is just a > bystander. >=20 > How can you expect the IP layer to implement robust Path MTU=20 > when ICMP "packet too big" messages may be forgeries or=20 > missing altogether? See: >=20 > http://www.ietf.org/html.charters/pmtud-charter.html >=20 > Fred > fred.l.templin@boeing.com >=20 >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri May 19 17:08:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhCCl-0007YL-09; Fri, 19 May 2006 17:08:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhCCj-0007YD-K8 for tcpm@ietf.org; Fri, 19 May 2006 17:08:13 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhCCh-0005xV-9i for tcpm@ietf.org; Fri, 19 May 2006 17:08:13 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id OAA21351; Fri, 19 May 2006 14:08:08 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k4JL87G09315; Fri, 19 May 2006 16:08:07 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 May 2006 14:08:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] ICMP and TCP Date: Fri, 19 May 2006 14:08:06 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1818C40@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <03235919BBDE634289BB6A0758A20B365EB1D4@NT-SJCA-0751.brcm.ad.broadcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] ICMP and TCP Thread-Index: AcZ7bHqa3+qYS/iSRyqcxUjgqgbfpwAAFQkgAAA67bAAAQ4GoAAFDcaQAAAduPA= From: "Templin, Fred L" To: "Bora Akyol" , X-OriginalArrivalTime: 19 May 2006 21:08:06.0744 (UTC) FILETIME=[53268580:01C67B88] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org > This is why security of PMTU should be solved at the IP layer, > don't you think? No; that would require the source system to have a security association with every router on the path - unless you want to ignore all "packet too bigs" that come from intermediate nodes in which case you would black-hole. As Matt Zekauskas said (and, as the icmp-attacks draft says), if you want PMTU w/o ICMPs, you can get it using: But, that method requires support from a packetization layer (e.g., TCP). Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 > Sent: Friday, May 19, 2006 11:31 AM > To: Bora Akyol; tcpm@ietf.org > Subject: RE: [tcpm] ICMP and TCP >=20 > Bora, >=20 > > 1) Path MTU, this is an IP layer functionality. TCP is just a > bystander. >=20 > How can you expect the IP layer to implement robust Path MTU=20 > when ICMP "packet too big" messages may be forgeries or=20 > missing altogether? See: >=20 > http://www.ietf.org/html.charters/pmtud-charter.html >=20 > Fred > fred.l.templin@boeing.com >=20 >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri May 19 17:20:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhCNy-0004rP-2z; Fri, 19 May 2006 17:19:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhCNw-0004qt-6h for tcpm@ietf.org; Fri, 19 May 2006 17:19:48 -0400 Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhCNt-0006RI-SB for tcpm@ietf.org; Fri, 19 May 2006 17:19:48 -0400 Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Fri, 19 May 2006 14:19:38 -0700 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 62DD52B0; Fri, 19 May 2006 14:19:38 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 414662AF; Fri, 19 May 2006 14:19:38 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id DOH18786; Fri, 19 May 2006 14:19:37 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id A1B7420501; Fri, 19 May 2006 14:19:37 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] ICMP and TCP Date: Fri, 19 May 2006 14:19:36 -0700 Message-ID: <03235919BBDE634289BB6A0758A20B365EB1E6@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [tcpm] ICMP and TCP Thread-Index: AcZ7bHqa3+qYS/iSRyqcxUjgqgbfpwAAFQkgAAA67bAAAQ4GoAAFDcaQAAAduPAAAMKmIA== From: "Bora Akyol" To: "Templin, Fred L" , tcpm@ietf.org X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006051908; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230342E34343645333431452E303035312D412D; ENG=IBF; TS=20060519211941; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006051908_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 6870E9E03NG18344745-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org =20 > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 > Sent: Friday, May 19, 2006 2:08 PM > To: Bora Akyol; tcpm@ietf.org > Subject: RE: [tcpm] ICMP and TCP >=20 > > This is why security of PMTU should be solved at the IP=20 > layer, don't=20 > > you think? >=20 > No; that would require the source system to have a security=20 > association with every router on the path - unless you want=20 > to ignore all "packet too bigs" that come from intermediate=20 > nodes in which case you would black-hole. >=20 Only if you use IPSEC. The point is that TCP IMHO is powerless to secure ICMP messages. By making changes to TCP to declare ICMP errors as soft errors depending on the state and ignoring some errors altogether, we are trying to create a workaround for a problem with another layer in the protocol stack. This is all and well to solve a short term goal, but what is the long term answer? Thanks _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat May 20 01:25:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhJwp-0002FJ-7t; Sat, 20 May 2006 01:24:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhJwk-0002BG-0Q for tcpm@ietf.org; Sat, 20 May 2006 01:24:14 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhJsj-0004oy-Sr for tcpm@ietf.org; Sat, 20 May 2006 01:20:06 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4K5K2EH013711; Sat, 20 May 2006 02:20:11 -0300 Message-Id: <7.0.1.0.0.20060520020629.06a886f8@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 20 May 2006 02:09:57 -0300 To: Joe Touch , Pekka Savola From: Fernando Gont Subject: Re: [tcpm] Re: Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt In-Reply-To: <446E0DDB.3040404@isi.edu> References: <7.0.1.0.0.20060518035047.06d3d718@gont.com.ar> <446C83E6.4030901@isi.edu> <7.0.1.0.0.20060519013043.06a4ef68@gont.com.ar> <446D5A33.8020202@isi.edu> <7.0.1.0.0.20060519031314.06a79038@gont.com.ar> <446DF5A0.3040607@isi.edu> <446E0DDB.3040404@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 15:26 19/05/2006, Joe Touch wrote: >>>Your analysis (and some of the work of many throughout this WG, as >>>well) tends to assume that everything unexpected is a deliberate >>>attack, and thus must be quenched. What if the unexpected is >>>legitimate? What capability are you disabling as a result? >>Joe, >>That's exactly the questions I'd like you to answer regarding your >>suggestion that ignoring ICMP error messages (wrt. IPsec for >>instance) is good thing to do > >I don't think it is in general. I think that IF you have a security >concern, then you can decide to turn them off FOR YOURSELF (or at your >firewall). But that's no different from blocking certain ports or >protocols due to security concerns. "If you have a security concern"????? Who doesn't have a security concern? Even if the only thing I did with the Internet was to download pirated music and porn, as a user I would still be concerned about my downloads being interrupted by some idiot firing ICMP messages. >I don't want to dictate that sort of behavior for the protocol as a >rule exactly because it turns off a capability for those not under attack. Yea... And the door you have in your house turns off a capability in those cases in which there are no thieves out there. C'mon Joe. There's a point in which what is supposed to be religion turns into something else.... Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat May 20 01:25:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhJwn-0002EE-Vj; Sat, 20 May 2006 01:24:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhJwj-00From tcpm-bounces@ietf.org Sat May 20 01:25:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhJwp-0002FJ-7t; Sat, 20 May 2006 01:24:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhJwk-0002BG-0Q for tcpm@ietf.org; Sat, 20 May 2006 01:24:14 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhJsj-0004oy-Sr for tcpm@ietf.org; Sat, 20 May 2006 01:20:06 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4K5K2EH013711; Sat, 20 May 2006 02:20:11 -0300 Message-Id: <7.0.1.0.0.20060520020629.06a886f8@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 20 May 2006 02:09:57 -0300 To: Joe Touch , Pekka Savola From: Fernando Gont Subject: Re: [tcpm] Re: Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt In-Reply-To: <446E0DDB.3040404@isi.edu> References: <7.0.1.0.0.20060518035047.06d3d718@gont.com.ar> <446C83E6.4030901@isi.edu> <7.0.1.0.0.20060519013043.06a4ef68@gont.com.ar> <446D5A33.8020202@isi.edu> <7.0.1.0.0.20060519031314.06a79038@gont.com.ar> <446DF5A0.3040607@isi.edu> <446E0DDB.3040404@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 15:26 19/05/2006, Joe Touch wrote: >>>Your analysis (and some of the work of many throughout this WG, as >>>well) tends to assume that everything unexpected is a deliberate >>>attack, and thus must be quenched. What if the unexpected is >>>legitimate? What capability are you disabling as a result? >>Joe, >>That's exactly the questions I'd like you to answer regarding your >>suggestion that ignoring ICMP error messages (wrt. IPsec for >>instance) is good thing to do > >I don't think it is in general. I think that IF you have a security >concern, then you can decide to turn them off FOR YOURSELF (or at your >firewall). But that's no different from blocking certain ports or >protocols due to security concerns. "If you have a security concern"????? Who doesn't have a security concern? Even if the only thing I did with the Internet was to download pirated music and porn, as a user I would still be concerned about my downloads being interrupted by some idiot firing ICMP messages. >I don't want to dictate that sort of behavior for the protocol as a >rule exactly because it turns off a capability for those not under attack. Yea... And the door you have in your house turns off a capability in those cases in which there are no thieves out there. C'mon Joe. There's a point in which what is supposed to be religion turns into something else.... Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat May 20 01:25:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhJwn-0002EE-Vj; Sat, 20 May 2006 01:24:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhJwj-0002BG-LH for tcpm@ietf.org; Sat, 20 May 2006 01:24:13 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhJsq-0004pT-QX for tcpm@ietf.org; Sat, 20 May 2006 01:20:13 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4K5K2EN013711; Sat, 20 May 2006 02:20:13 -0300 Message-Id: <7.0.1.0.0.20060520021553.05218388@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 20 May 2006 02:19:00 -0300 To: "Bora Akyol" , "Templin, Fred L" , tcpm@ietf.org From: Fernando Gont Subject: RE: [tcpm] ICMP and TCP In-Reply-To: <03235919BBDE634289BB6A0758A20B365EB1E6@NT-SJCA-0751.brcm.a d.broadcom.com> References: <03235919BBDE634289BB6A0758A20B365EB1E6@NT-SJCA-0751.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 18:19 19/05/2006, Bora Akyol wrote: >The point is that TCP IMHO is powerless to secure ICMP messages. >By making changes to TCP to declare ICMP errors as soft errors >depending on the state and ignoring some errors altogether, >we are trying to create a workaround for a problem with another layer >in the protocol stack. Engineering, maybe? >This is all and well to solve a short term goal, but what is the long >term answer? Well, you are probably getting into "architecture" issues. You would end up asking other questions such as: Shouldn't multihoming be a network layer thing, rather than a transport protocol thing? Where should we really be doing congestion control? etc. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat May 20 01:25:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhJwq-0002I1-4f; Sat, 20 May 2006 01:24:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhJwk-0002BH-5A for tcpm@ietf.org; Sat, 20 May 2006 01:24:14 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhJsi-0004oh-R4 for tcpm@ietf.org; Sat, 20 May 2006 01:20:06 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4K5K2E3013711; Sat, 20 May 2006 02:20:04 -0300 Message-Id: <7.0.1.0.0.20060519091815.04901498@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 20 May 2006 01:29:08 -0300 To: Joe Touch From: Fernando Gont Subject: Re: [tcpm] Comments on draft-ietf-tcpm-icmp-attacks-00.txt In-Reply-To: <446D5BDB.9050002@isi.edu> References: <03235919BBDE634289BB6A0758A20B365EAFB8@NT-SJCA-0751.brcm.ad.broadcom.com> <7.0.1.0.0.20060519014730.06a6b2d0@gont.com.ar> <446D5BDB.9050002@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor EFrom tcpm-bounces@ietf.org Sat May 20 01:25:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhJwp-0002FJ-7t; Sat, 20 May 2006 01:24:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhJwk-0002BG-0Q for tcpm@ietf.org; Sat, 20 May 2006 01:24:14 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhJsj-0004oy-Sr for tcpm@ietf.org; Sat, 20 May 2006 01:20:06 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4K5K2EH013711; Sat, 20 May 2006 02:20:11 -0300 Message-Id: <7.0.1.0.0.20060520020629.06a886f8@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 20 May 2006 02:09:57 -0300 To: Joe Touch , Pekka Savola From: Fernando Gont Subject: Re: [tcpm] Re: Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt In-Reply-To: <446E0DDB.3040404@isi.edu> References: <7.0.1.0.0.20060518035047.06d3d718@gont.com.ar> <446C83E6.4030901@isi.edu> <7.0.1.0.0.20060519013043.06a4ef68@gont.com.ar> <446D5A33.8020202@isi.edu> <7.0.1.0.0.20060519031314.06a79038@gont.com.ar> <446DF5A0.3040607@isi.edu> <446E0DDB.3040404@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 15:26 19/05/2006, Joe Touch wrote: >>>Your analysis (and some of the work of many throughout this WG, as >>>well) tends to assume that everything unexpected is a deliberate >>>attack, and thus must be quenched. What if the unexpected is >>>legitimate? What capability are you disabling as a result? >>Joe, >>That's exactly the questions I'd like you to answer regarding your >>suggestion that ignoring ICMP error messages (wrt. IPsec for >>instance) is good thing to do > >I don't think it is in general. I think that IF you have a security >concern, then you can decide to turn them off FOR YOURSELF (or at your >firewall). But that's no different from blocking certain ports or >protocols due to security concerns. "If you have a security concern"????? Who doesn't have a security concern? Even if the only thing I did with the Internet was to download pirated music and porn, as a user I would still be concerned about my downloads being interrupted by some idiot firing ICMP messages. >I don't want to dictate that sort of behavior for the protocol as a >rule exactly because it turns off a capability for those not under attack. Yea... And the door you have in your house turns off a capability in those cases in which there are no thieves out there. C'mon Joe. There's a point in which what is supposed to be religion turns into something else.... Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat May 20 01:25:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhJwn-0002EE-Vj; Sat, 20 May 2006 01:24:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhJwj-00xtensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 02:47 19/05/2006, Joe Touch wrote: >>>Since the attacker needs to guess both ends of the TCP connection >>>including IP addresses and TCP ports, I am not sure what the benefit >>>of ICMP payload parsing is in this case. >>> >>>I am sure I missed something here. >>The "benefit" is being a good network citizen. When you perform >>egress-filtering, you preventyour own users from performing >>ICMP-based attacks against systems that belong to other networks. > >What about errors based on loose source routes, Loose source routes? Does anybody still use this? Or, well, even worse, does any body still process this? >or just misdirected traffic? I.e., how do you know that it's not >appropriate to indicate that a host (especially) isn't in your net >when asked; that would cause certain ICMPs never to be issued (net >unreachable, host unreachable) if they reach a forwarding point in >your net that isn't a valid address for your net (which is entirely >reasonable). With the same argument, you could never implement ingress/egress filtering. Joe, the E in IETF stands for Engineering! Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm 02BG-LH for tcpm@ietf.org; Sat, 20 May 2006 01:24:13 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhJsq-0004pT-QX for tcpm@ietf.org; Sat, 20 May 2006 01:20:13 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4K5K2EN013711; Sat, 20 May 2006 02:20:13 -0300 Message-Id: <7.0.1.0.0.20060520021553.05218388@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 20 May 2006 02:19:00 -0300 To: "Bora Akyol" , "Templin, Fred L" , tcpm@ietf.org From: Fernando Gont Subject: RE: [tcpm] ICMP and TCP In-Reply-To: <03235919BBDE634289BB6A0758A20B365EB1E6@NT-SJCA-0751.brcm.a d.broadcom.com> References: <03235919BBDE634289BB6A0758A20B365EB1E6@NT-SJCA-0751.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 18:19 19/05/2006, Bora Akyol wrote: >The point is that TCP IMHO is powerless to secure ICMP messages. >By making changes to TCP to declare ICMP errors as soft errors >depending on the state and ignoring some errors altogether, >we are trying to create a workaround for a problem with another layer >in the protocol stack. Engineering, maybe? >This is all and well to solve a short term goal, but what is the long >term answer? Well, you are probably getting into "architecture" issues. You would end up asking other questions such as: Shouldn't multihoming be a network layer thing, rather than a transport protocol thing? Where should we really be doing congestion control? etc. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat May 20 01:25:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhJwq-0002I1-4f; Sat, 20 May 2006 01:24:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhJwk-0002BH-5A for tcpm@ietf.org; Sat, 20 May 2006 01:24:14 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhJsi-0004oh-R4 for tcpm@ietf.org; Sat, 20 May 2006 01:20:06 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4K5K2E3013711; Sat, 20 May 2006 02:20:04 -0300 Message-Id: <7.0.1.0.0.20060519091815.04901498@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 20 May 2006 01:29:08 -0300 To: Joe Touch From: Fernando Gont Subject: Re: [tcpm] Comments on draft-ietf-tcpm-icmp-attacks-00.txt In-Reply-To: <446D5BDB.9050002@isi.edu> References: <03235919BBDE634289BB6A0758A20B365EAFB8@NT-SJCA-0751.brcm.ad.broadcom.com> <7.0.1.0.0.20060519014730.06a6b2d0@gont.com.ar> <446D5BDB.9050002@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 02:47 19/05/2006, Joe Touch wrote: >>>Since the attacker needs to guess both ends of the TCP connection >>>including IP addresses and TCP ports, I am not sure what the benefit >>>of ICMP payload parsing is in this case. >>> >>>I am sure I missed something here. >>The "benefit" is being a good network citizen. When you perform >>egress-filtering, you preventyour own users from performing >>ICMP-based attacks against systems that belong to other networks. > >What about errors based on loose source routes, Loose source routes? Does anybody still use this? Or, well, even worse, does any body still process this? >or just misdirected traffic? I.e., how do you know that it's not >appropriate to indicate that a host (especially) isn't in your net >when asked; that would cause certain ICMPs never to be issued (net >unreachable, host unreachable) if they reach a forwarding point in >your net that isn't a valid address for your net (which is entirely >reasonable). With the same argument, you could never implement ingress/egress filtering. Joe, the E in IETF stands for Engineering! Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm 02BG-LH for tcpm@ietf.org; Sat, 20 May 2006 01:24:13 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhJsq-0004pT-QX for tcpm@ietf.org; Sat, 20 May 2006 01:20:13 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4K5K2EN013711; Sat, 20 May 2006 02:20:13 -0300 Message-Id: <7.0.1.0.0.20060520021553.05218388@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 20 May 2006 02:19:00 -0300 To: "Bora Akyol" , "Templin, Fred L" , tcpm@ietf.org From: Fernando Gont Subject: RE: [tcpm] ICMP and TCP In-Reply-To: <03235919BBDE634289BB6A0758A20B365EB1E6@NT-SJCA-0751.brcm.a d.broadcom.com> References: <03235919BBDE634289BB6A0758A20B365EB1E6@NT-SJCA-0751.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 18:19 19/05/2006, Bora Akyol wrote: >The point is that TCP IMHO is powerless to secure ICMP messages. >By making changes to TCP to declare ICMP errors as soft errors >depending on the state and ignoring some errors altogether, >we are trying to create a workaround for a problem with another layer >in the protocol stack. Engineering, maybe? >This is all and well to solve a short term goal, but what is the long >term answer? Well, you are probably getting into "architecture" issues. You would end up asking other questions such as: Shouldn't multihoming be a network layer thing, rather than a transport protocol thing? Where should we really be doing congestion control? etc. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat May 20 01:25:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhJwq-0002I1-4f; Sat, 20 May 2006 01:24:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhJwk-0002BH-5A for tcpm@ietf.org; Sat, 20 May 2006 01:24:14 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhJsi-0004oh-R4 for tcpm@ietf.org; Sat, 20 May 2006 01:20:06 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4K5K2E3013711; Sat, 20 May 2006 02:20:04 -0300 Message-Id: <7.0.1.0.0.20060519091815.04901498@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 20 May 2006 01:29:08 -0300 To: Joe Touch From: Fernando Gont Subject: Re: [tcpm] Comments on draft-ietf-tcpm-icmp-attacks-00.txt In-Reply-To: <446D5BDB.9050002@isi.edu> References: <03235919BBDE634289BB6A0758A20B365EAFB8@NT-SJCA-0751.brcm.ad.broadcom.com> <7.0.1.0.0.20060519014730.06a6b2d0@gont.com.ar> <446D5BDB.9050002@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 02:47 19/05/2006, Joe Touch wrote: >>>Since the attacker needs to guess both ends of the TCP connection >>>including IP addresses and TCP ports, I am not sure what the benefit >>>of ICMP payload parsing is in this case. >>> >>>I am sure I missed something here. >>The "benefit" is being a good network citizen. When you perform >>egress-filtering, you preventyour own users from performing >>ICMP-based attacks against systems that belong to other networks. > >What about errors based on loose source routes, Loose source routes? Does anybody still use this? Or, well, even worse, does any body still process this? >or just misdirected traffic? I.e., how do you know that it's not >appropriate to indicate that a host (especially) isn't in your net >when asked; that would cause certain ICMPs never to be issued (net >unreachable, host unreachable) if they reach a forwarding point in >your net that isn't a valid address for your net (which is entirely >reasonable). With the same argument, you could never implement ingress/egress filtering. Joe, the E in IETF stands for Engineering! Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat May 20 01:25:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhJwp-0002FX-Os; Sat, 20 May 2006 01:24:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhJwk-0002BH-0I for tcpm@ietf.org; Sat, 20 May 2006 01:24:14 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhJsk-0004p9-Vg for tcpm@ietf.org; Sat, 20 May 2006 01:20:07 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4K5K2EJ013711; Sat, 20 May 2006 02:20:12 -0300 Message-Id: <7.0.1.0.0.20060520021108.0488a3f8@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 20 May 2006 02:12:08 -0300 To: Matthew J Zekauskas , tcpm@ietf.org From: Fernando Gont Subject: RE: [tcpm] Re: Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt In-Reply-To: <0A6D76B6DA377E517F2C9950@DCFF15AFC1F6764BA3927E50> References: <70C6EFCDFC8AAD418EF7063CD132D064B1980C@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.co m> <0A6D76B6DA377E517F2C9950@DCFF15AFC1F6764BA3927E50> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 16:47 19/05/2006, Matthew J Zekauskas wrote: >pmtud is currently working on an ICMP-less PMTU discovery >method (at least, one where you may ignore ICMP if you choose); This doesn't meant that it will not benefit from ICMP. (The benefit being a reduction in the convergence time) Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat May 20 01:25:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhJwo-0002ES-7c; Sat, 20 May 2006 01:24:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhJwj-0002BG-Oc for tcpm@ietf.org; Sat, 20 May 2006 01:24:13 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhJso-0004pN-CX for tcpm@ietf.org; Sat, 20 May 2006 01:20:10 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4K5K2EF013711; Sat, 20 May 2006 02:20:10 -0300 Message-Id: <7.0.1.0.0.20060520020116.060be9c8@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 20 May 2006 02:05:37 -0300 To: "Bora Akyol" , "Templin, Fred L" , tcpm@ietf.org From: Fernando Gont Subject: RE: [tcpm] ICMP and TCP In-Reply-To: <03235919BBDE634289BB6A0758A20B365EB195@NT-SJCA-0751.brcm.a d.broadcom.com> References: <03235919BBDE634289BB6A0758A20B365EB195@NT-SJCA-0751.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 15:05 19/05/2006, Bora Akyol wrote: >After reading the tcp/icmp draft, this is what I am suggesting. > >The logic for what constitutes a hard error vs what constitutes a soft >error is getting convoluted. Please read the David D. Clark's paper on fault isolation and recovery (referenced in my "TCP's reaction to soft errors" draft), and/or see my presentations (ICMP attacks and TCP soft errors) at IETF 64. >1) Path MTU, this is an IP layer functionality. TCP is just a bystander. ? >2) Port unreachable, host unreachable etc type messages. This can be >fixed within TCP itself >by reclaiming resources are generalizing some of the optimizations >presented in draft-eddy-syn-flood. ICMP provides more specific information about what is really going on. The point is not to remove ICMP, or to blindly trust it. The point is to use it while it's useful, in the right way, till the point it begins to affect the security of the protocols that depend on it. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat May 20 01:25:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhJwp-0002FX-Os; Sat, 20 May 2006 01:24:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhJwk-0002BH-0I for tcpm@ietf.org; Sat, 20 May 2006 01:24:14 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhJsk-0004p9-Vg for tcpm@ietf.org; Sat, 20 May 2006 01:20:07 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4K5K2EJ013711; Sat, 20 May 2006 02:20:12 -0300 Message-Id: <7.0.1.0.0.20060520021108.0488a3f8@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 20 May 2006 02:12:08 -0300 To: Matthew J Zekauskas , tcpm@ietf.org From: Fernando Gont Subject: RE: [tcpm] Re: Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt In-Reply-To: <0A6D76B6DA377E517F2C9950@DCFF15AFC1F6764BA3927E50> References: <70C6EFCDFC8AAD418EF7063CD132D064B1980C@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.co m> <0A6D76B6DA377E517F2C9950@DCFF15AFC1F6764BA3927E50> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 16:47 19/05/2006, Matthew J Zekauskas wrote: >pmtud is currently working on an ICMP-less PMTU discovery >method (at least, one where you may ignore ICMP if you choose); This doesn't meant that it will not benefit from ICMP. (The benefit being a reduction in the convergence time) Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat May 20 01:25:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhJwo-0002ES-7c; Sat, 20 May 2006 01:24:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhJwj-0002BG-Oc for tcpm@ietf.org; Sat, 20 May 2006 01:24:13 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhJso-0004pN-CX for tcpm@ietf.org; Sat, 20 May 2006 01:20:10 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4K5K2EF013711; Sat, 20 May 2006 02:20:10 -0300 Message-Id: <7.0.1.0.0.20060520020116.060be9c8@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 20 May 2006 02:05:37 -0300 To: "Bora Akyol" , "Templin, Fred L" , tcpm@ietf.org From: Fernando Gont Subject: RE: [tcpm] ICMP and TCP In-Reply-To: <03235919BBDE634289BB6A0758A20B365EB195@NT-SJCA-0751.brcm.a d.broadcom.com> References: <03235919BBDE634289BB6A0758A20B365EB195@NT-SJCA-0751.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 15:05 19/05/2006, Bora Akyol wrote: >After reading the tcp/icmp draft, this is what I am suggesting. > >The logic for what constitutes a hard error vs what constitutes a soft >error is getting convoluted. Please read the David D. Clark's paper on fault isolation and recovery (referenced in my "TCP's reaction to soft errors" draft), and/or see my presentations (ICMP attacks and TCP soft errors) at IETF 64. >1) Path MTU, this is an IP layer functionality. TCP is just a bystander. ? >2) Port unreachable, host unreachable etc type messages. This can be >fixed within TCP itself >by reclaiming resources are generalizing some of the optimizations >presented in draft-eddy-syn-flood. ICMP provides more specific information about what is really going on. The point is not to remove ICMP, or to blindly trust it. The point is to use it while it's useful, in the right way, till the point it begins to affect the security of the protocols that depend on it. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat May 20 01:25:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhJwo-0002Ek-G4; Sat, 20 May 2006 01:24:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhJwj-0002BG-RW for tcpm@ietf.org; Sat, 20 May 2006 01:24:13 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhJsk-0004p0-Ns for tcpm@ietf.org; Sat, 20 May 2006 01:20:08 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4K5K2ED013711; Sat, 20 May 2006 02:20:09 -0300 Message-Id: <7.0.1.0.0.20060520015715.048f6050@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 20 May 2006 02:00:03 -0300 To: "Bora Akyol" , tcpm@ietf.org From: Fernando Gont Subject: Re: [tcpm] ICMP and TCP In-Reply-To: <03235919BBDE634289BB6A0758A20B365EB188@NT-SJCA-0751.brcm.a d.broadcom.com> References: <03235919BBDE634289BB6A0758A20B365EB188@NT-SJCA-0751.brcm.ad.broadcom.com> Mime-Version: 1.0 X-Spam-Score: 0.6 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0705696989==" Errors-To: tcpm-bounces@ietf.org --===============0705696989== Content-Type: multipart/alternative; boundary="=====================_235065676==.ALT" --=====================_235065676==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 14:48 19/05/2006, Bora Akyol wrote: >Should we stop beating around the bush and cut the cord between >these two altogether? Even >PMTU discovery is really an L3 function. Would you apply the same rationale to TCP's congestion control, too? >What the icmp/tcp draft proposes turns all hard errors to soft >anyway, why not just cut the cord and >let TCP react to only the other peer TCP. The soft errors will provide more specific information about the error condition, in the event the connection times out. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 --=====================_235065676==.ALT Content-Type: text/html; charset="us-ascii" At 14:48 19/05/2006, Bora Akyol wrote:

Should we stop beating around the bush and cut the cord between these two altogether? Even
PMTU discovery is really an L3 function.

Would you apply the same rationale to TCP's congestion control, too?


What the icmp/tcp draft proposes turns all hard errors to soft anyway, why not just cut the cord and
let TCP react to only the other peer TCP.

The soft errors will provide more specific information about the error condition, in the event the connection times out.

Kindest regards,

--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




--=====================_235065676==.ALT-- --===============0705696989== 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 --===============0705696989==-- From tcpm-bounces@ietf.org Sat May 20 01:25:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhJwo-0002Ev-N5; Sat, 20 May 2006 01:24:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhJwj-0002BG-SN for tcpm@ietf.org; Sat, 20 May 2006 01:24:13 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhJsk-0004oz-N7 for tcpm@ietf.org; Sat, 20 May 2006 01:20:08 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4K5K2EB013711; Sat, 20 May 2006 02:20:09 -0300 Message-Id: <7.0.1.0.0.20060520015307.06a5c618@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 20 May 2006 01:56:39 -0300 To: "Bora Akyol" , tcpm@ietf.org From: Fernando Gont Subject: RE: [tcpm] Comments on draft-ietf-tcpm-icmp-attacks-00.txt In-Reply-To: <03235919BBDE634289BB6A0758A20B365EB185@NT-SJCA-0751.brcm.a d.broadcom.com> References: <03235919BBDE634289BB6A0758A20B365EB185@NT-SJCA-0751.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 14:43 19/05/2006, Bora Akyol wrote: >My point is that you assume that a firewall somewhere in the network has >the information to decide what packets can originate from where and >filter it. > >The benefit of implementing this feature is minimal IMHO at a >considerable >complexity to hardware implementations. Ingress/egress filtering of ICMP packets is included as additional countermeasures that could be implemented. The real fix for each attack is right after the corresponding attack description. >Can you also document how this works with mobile IP and other protocols >that use >a care of address (I believe some of the Wireless LAN tunneling does >this too). Do you mean how simple ingress/egress filtering works with mobile IP? ;-) Well, in many cases it will probably be troublesome. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat May 20 01:25:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhJwo-0002Ek-G4; Sat, 20 May 2006 01:24:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhJwj-0002BG-RW for tcpm@ietf.org; Sat, 20 May 2006 01:24:13 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhJsk-0004p0-Ns for tcpm@ietf.org; Sat, 20 May 2006 01:20:08 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4K5K2ED013711; Sat, 20 May 2006 02:20:09 -0300 Message-Id: <7.0.1.0.0.20060520015715.048f6050@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 20 May 2006 02:00:03 -0300 To: "Bora Akyol" , tcpm@ietf.org From: Fernando Gont Subject: Re: [tcpm] ICMP and TCP In-Reply-To: <03235919BBDE634289BB6A0758A20B365EB188@NT-SJCA-0751.brcm.a d.broadcom.com> References: <03235919BBDE634289BB6A0758A20B365EB188@NT-SJCA-0751.brcm.ad.broadcom.com> Mime-Version: 1.0 X-Spam-Score: 0.6 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0705696989==" Errors-To: tcpm-bounces@ietf.org --===============0705696989== Content-Type: multipart/alternative; boundary="=====================_235065676==.ALT" --=====================_235065676==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 14:48 19/05/2006, Bora Akyol wrote: >Should we stop beating around the bush and cut the cord between >these two altogether? Even >PMTU discovery is really an L3 function. Would you apply the same rationale to TCP's congestion control, too? >What the icmp/tcp draft proposes turns all hard errors to soft >anyway, why not just cut the cord and >let TCP react to only the other peer TCP. The soft errors will provide more specific information about the error condition, in the event the connection times out. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 --=====================_235065676==.ALT Content-Type: text/html; charset="us-ascii" At 14:48 19/05/2006, Bora Akyol wrote:

Should we stop beating around the bush and cut the cord between these two altogether? Even
PMTU discovery is really an L3 function.

Would you apply the same rationale to TCP's congestion control, too?


What the icmp/tcp draft proposes turns all hard errors to soft anyway, why not just cut the cord and
let TCP react to only the other peer TCP.

The soft errors will provide more specific information about the error condition, in the event the connection times out.

Kindest regards,

--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




--=====================_235065676==.ALT-- --===============0705696989== 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 --===============0705696989==-- From tcpm-bounces@ietf.org Sat May 20 01:25:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhJwo-0002Ev-N5; Sat, 20 May 2006 01:24:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhJwj-0002BG-SN for tcpm@ietf.org; Sat, 20 May 2006 01:24:13 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhJsk-0004oz-N7 for tcpm@ietf.org; Sat, 20 May 2006 01:20:08 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4K5K2EB013711; Sat, 20 May 2006 02:20:09 -0300 Message-Id: <7.0.1.0.0.20060520015307.06a5c618@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 20 May 2006 01:56:39 -0300 To: "Bora Akyol" , tcpm@ietf.org From: Fernando Gont Subject: RE: [tcpm] Comments on draft-ietf-tcpm-icmp-attacks-00.txt In-Reply-To: <03235919BBDE634289BB6A0758A20B365EB185@NT-SJCA-0751.brcm.a d.broadcom.com> References: <03235919BBDE634289BB6A0758A20B365EB185@NT-SJCA-0751.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 14:43 19/05/2006, Bora Akyol wrote: >My point is that you assume that a firewall somewhere in the network has >the information to decide what packets can originate from where and >filter it. > >The benefit of implementing this feature is minimal IMHO at a >considerable >complexity to hardware implementations. Ingress/egress filtering of ICMP packets is included as additional countermeasures that could be implemented. The real fix for each attack is right after the corresponding attack description. >Can you also document how this works with mobile IP and other protocols >that use >a care of address (I believe some of the Wireless LAN tunneling does >this too). Do you mean how simple ingress/egress filtering works with mobile IP? ;-) Well, in many cases it will probably be troublesome. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat May 20 01:38:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhKAE-0005Bl-D3; Sat, 20 May 2006 01:38:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhKAD-0005Bg-BK for tcpm@ietf.org; Sat, 20 May 2006 01:38:09 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhKAB-0006QZ-06 for tcpm@ietf.org; Sat, 20 May 2006 01:38:09 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4K5bPU24575; Fri, 19 May 2006 22:37:25 -0700 (PDT) Message-ID: <446EAB0F.6020103@isi.edu> Date: Fri, 19 May 2006 22:37:19 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] Re: Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt References: <70C6EFCDFC8AAD418EF7063CD132D064B1980C@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <446E2786.2020704@isi.edu> <7.0.1.0.0.20060520021236.00f32648@gont.com.ar> In-Reply-To: <7.0.1.0.0.20060520021236.00f32648@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Christian Huitema , tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Fernando Gont wrote: > At 17:16 19/05/2006, Joe Touch wrote: > >>> So, Joe, you agree that at least some systems will simply ignore ICMP, >>> e.g. because a firewall is programmed to drop all ICMP messages. It >>> seems then that TCPM should be concerned with the behavior of TCP in >>> such environments. It would be nice to have ICMP-less alternatives for >>> the problems that you mention, starting with PMTU discovery, v6/v4 fall >>> back, etc. >> >> ICMP-less solutions to PMTUD are being developed already. > > I really doubt that implementations will completely get rid of ICMP > "frag needed". Hard to say why they'd keep it if they have a separate, more robust (to ICMP blocking) protocol that works sufficiently. > I bet they are going to implement the mechanism for improving robustness > in the case there are no ICMP messages, or that the advertised MTU or > something is incorrect. We'll have to wait to see what happens, but that's what the PMTUD is developing. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat May 20 01:43:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhKEq-0006uZ-Ka; Sat, 20 May 2006 01:42:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhKEo-0006h0-8P for tcpm@ietf.org; Sat, 20 May 2006 01:42:54 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhKEm-0006jd-Qn for tcpm@ietf.org; Sat, 20 May 2006 01:42:54 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4K5gPU25555; Fri, 19 May 2006 22:42:25 -0700 (PDT) Message-ID: <446EAC3C.6070409@isi.edu> Date: Fri, 19 May 2006 22:42:20 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] Re: Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt References: <7.0.1.0.0.20060518035047.06d3d718@gont.com.ar> <446C83E6.4030901@isi.edu> <7.0.1.0.0.20060519013043.06a4ef68@gont.com.ar> <446D5A33.8020202@isi.edu> <7.0.1.0.0.20060519031314.06a79038@gont.com.ar> <446DF5A0.3040607@isi.edu> <7.0.1.0.0.20060520013121.06a78248@gont.com.ar> In-Reply-To: <7.0.1.0.0.20060520013121.06a78248@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: d8ae4fd88fcaf47c1a71c804d04f413d Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Fernando Gont wrote: > At 13:43 19/05/2006, Joe Touch wrote: > >> Fernando Gont wrote: >>> NetBSD, FreeBSD, OpenBSD, Linux, Cisco, Microsoft Windows, Solaris, >>> et al, are all wrong, right? >> >> Screaming 'fire' in a crowded marketplace is a great way to get >> vendors to jump (off a cliff) > > Joe, I think you miss the facts, here. > > All BSD-derived and Mentat-derived stacks treat hard errors as soft > errors (for connections in any of the synchronized states) since at > least 1994. > > There was no scream of "fire". > > As a matter of fact, I met Kirk McKusick and Mike Karels, and asked why, > even before the security issues were raised, they had been implementing > this for decades. Both of them answered: resetting established > connections upon receipt of an ICMP error was simply nonsensical. Oh, so that's a fine reason. Skip the RFCs (1122 was 5 years prior). Just reason it out for yourself. That may be how implementations get built, but that's not what we're here to standardize. >> - consider the RST stuff, which is NOT needed by end hosts, but has >> made it into virtually every OS as well. > > That stuff is different. If you are concerned about them, use TCP MD5, > IPSec, or any similar mechanism. > > There's no (in practice) such a thing for ICMP. Filtering does the same thing as conversion to soft errors. >>>> The outer packet can go along paths that are not necessarily valid >>>> for the inner packet. There's no reason to enforce filtering on the >>>> signalling packet's contents in that case. >>> I wrote this for a friend: http://www.gont.com.ar/papers/icmp-errors . >> >> Your analysis (and some of the work of many throughout this WG, as >> well) tends to assume that everything unexpected is a deliberate >> attack, and thus must be quenched. What if the unexpected is >> legitimate? What capability are you disabling as a result? > > i strongly disagree. > > First, as Section 1.3.2 of RFC 1812 says: "It is best to assume that the > network is filled with malevolent entities that will send packets > designed to have the worst possible effect. This assumption will lead to > suitably protective design." Fine. Then filter all the ICMPs; that's your only protection, and it's sufficient. No need to change TCP for that. But once you force the drop in the TCP spec, users can't put it back when they actually want the service, and when they're in a trusted environment. If we were to drop everything that might be an attack, we'd never accept anything except signed packets. > Seconds, regarding the capability that "is lost"... in the event you > lose any, ICMP is unreliable, anyway. That's a block we've been around too. IP is unreliable, but if we drop them all all the time, we're protected, but also have no functionality. Do you drop all IP packets too? They might be attacks! Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat May 20 01:48:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhKJr-0006Nf-U5; Sat, 20 May 2006 01:48:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhKJq-0006NP-7b for tcpm@ietf.org; Sat, 20 May 2006 01:48:06 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhKJn-00077Q-Qa for tcpm@ietf.org; Sat, 20 May 2006 01:48:06 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4K5kvU26461; Fri, 19 May 2006 22:46:58 -0700 (PDT) Message-ID: <446EAD4C.8040202@isi.edu> Date: Fri, 19 May 2006 22:46:52 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] Re: Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt References: <7.0.1.0.0.20060518035047.06d3d718@gont.com.ar> <446C83E6.4030901@isi.edu> <7.0.1.0.0.20060519013043.06a4ef68@gont.com.ar> <446D5A33.8020202@isi.edu> <7.0.1.0.0.20060519031314.06a79038@gont.com.ar> <446DF5A0.3040607@isi.edu> <446E0DDB.3040404@isi.edu> <7.0.1.0.0.20060520020629.06a886f8@gont.com.ar> In-Reply-To: <7.0.1.0.0.20060520020629.06a886f8@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 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: , Errors-To: tcpm-bounces@ietf.org Fernando Gont wrote: > At 15:26 19/05/2006, Joe Touch wrote: > >>>> Your analysis (and some of the work of many throughout this WG, as >>>> well) tends to assume that everything unexpected is a deliberate >>>> attack, and thus must be quenched. What if the unexpected is >>>> legitimate? What capability are you disabling as a result? >>> Joe, >>> That's exactly the questions I'd like you to answer regarding your >>> suggestion that ignoring ICMP error messages (wrt. IPsec for >>> instance) is good thing to do >> >> I don't think it is in general. I think that IF you have a security >> concern, then you can decide to turn them off FOR YOURSELF (or at your >> firewall). But that's no different from blocking certain ports or >> protocols due to security concerns. > > "If you have a security concern"????? > > Who doesn't have a security concern? > > Even if the only thing I did with the Internet was to download pirated > music and porn, as a user I would still be concerned about my downloads > being interrupted by some idiot firing ICMP messages. Who is going to bother sending your host ICMP attacks, and why can't your system figure that out at the ICMP level (too many ICMPs received, so enable a filter to shut them down, in a reactive way)? Why do we need to shut off that capability for all TCPs? >> I don't want to dictate that sort of behavior for the protocol as a >> rule exactly because it turns off a capability for those not under >> attack. > > Yea... And the door you have in your house turns off a capability in > those cases in which there are no thieves out there. That's why it's not a wall. It opens when I want it to. Defining TCP to treat these as soft errors puts up a wall (to the capability); let the user do that when they want to, but don't force it. If an ICMP-level filter isn't enough (and it should be preferable - that's the place that you'd know that different protocols were under attack simultaneously), maybe you could define an API parameter (ala Nagle) that turns these hard errors to soft, sort of a "suspect_ICMP" parameter? That way the user could at least turn it back to non-suspect if they wanted to, and have a reactive system again. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat May 20 02:04:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhKZq-0001mF-10; Sat, 20 May 2006 02:04:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhKZp-0001mA-6g for tcpm@ietf.org; Sat, 20 May 2006 02:04:37 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhKZn-0008Bv-MM for tcpm@ietf.org; Sat, 20 May 2006 02:04:37 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060308/8.12.11) with ESMTP id k4K64ONp013638; Sat, 20 May 2006 09:04:24 +0300 Date: Sat, 20 May 2006 09:04:24 +0300 (EEST) From: Pekka Savola To: Bora Akyol Subject: RE: [tcpm] ICMP and TCP In-Reply-To: <03235919BBDE634289BB6A0758A20B365EB1E6@NT-SJCA-0751.brcm.ad.broadcom.com> Message-ID: References: <03235919BBDE634289BB6A0758A20B365EB1E6@NT-SJCA-0751.brcm.ad.broadcom.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1471/Fri May 19 17:07:46 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_20,NO_RELAYS autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: "Templin, Fred L" , tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Fri, 19 May 2006, Bora Akyol wrote: > The point is that TCP IMHO is powerless to secure ICMP messages. > By making changes to TCP to declare ICMP errors as soft errors > depending on the state and ignoring some errors altogether, > we are trying to create a workaround for a problem with another layer > in the protocol stack. The other way to put this would be that we're creating a solution that's deployable today (heck, a lot of it has been deployed for over 10 years) and brings by-default significant increase of security. The other alternative is to either: 1) put our head in the sand and get even farther disconnected from the way TCP has been implemented, or 2) try to invent an overall big picture solution to this (I think IPsec was supposed to do this, but it hasn't been exactly succesful), which very likely WON'T end up being used any time soon. We need the practical, easy solutions to *existing* protocols. "More architectural" alternatives are very good in paper, but should not preclude documenting the more direct approaches. Remember that these two "ICMP and TCP" documents aren't even geared towards Standards Track at this point. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat May 20 03:43:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhM4g-00055p-3p; Sat, 20 May 2006 03:40:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhM4e-00055W-1D for tcpm@ietf.org; Sat, 20 May 2006 03:40:32 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhM4b-000697-Cr for tcpm@ietf.org; Sat, 20 May 2006 03:40:32 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4K7eDmc005105; Sat, 20 May 2006 04:40:17 -0300 Message-Id: <7.0.1.0.0.20060520030428.04e07620@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 20 May 2006 03:13:00 -0300 To: Joe Touch From: Fernando Gont Subject: Re: [tcpm] Re: Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt In-Reply-To: <446EAC3C.6070409@isi.edu> References: <7.0.1.0.0.20060518035047.06d3d718@gont.com.ar> <446C83E6.4030901@isi.edu> <7.0.1.0.0.20060519013043.06a4ef68@gont.com.ar> <446D5A33.8020202@isi.edu> <7.0.1.0.0.20060519031314.06a79038@gont.com.ar> <446DF5A0.3040607@isi.edu> <7.0.1.0.0.20060520013121.06a78248@gont.com.ar> <446EAC3C.6070409@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 02:42 20/05/2006, Joe Touch wrote: >>Joe, I think you miss the facts, here. >>All BSD-derived and Mentat-derived stacks treat hard errors as soft >>errors (for connections in any of the synchronized states) since at least 1994. >>There was no scream of "fire". >>As a matter of fact, I met Kirk McKusick and Mike Karels, and asked >>why, even before the security issues were raised, they had been >>implementing this for decades. Both of them answered: resetting >>established connections upon receipt of an ICMP error was simply nonsensical. > >Oh, so that's a fine reason. Skip the RFCs (1122 was 5 years prior). >Just reason it out for yourself. > >That may be how implementations get built, but that's not what we're >here to standardize. So we're here to publish documents that will be completely irrelevant to the industry, and that are years behind of the current needs. Fine. Let's remove the E in IETF. Let's call it ITF >>> - consider the RST stuff, which is NOT needed by end hosts, but >>> has made it into virtually every OS as well. >>That stuff is different. If you are concerned about them, use TCP >>MD5, IPSec, or any similar mechanism. >>There's no (in practice) such a thing for ICMP. > >Filtering does the same thing as conversion to soft errors. No, it doesn't. If the connection times out, and you filtered the ICMP, you have no clue of what went wrong. >>First, as Section 1.3.2 of RFC 1812 says: "It is best to assume >>that the network is filled with malevolent entities that will send packets >>designed to have the worst possible effect. This assumption will >>lead to suitably protective design." > >Fine. Then filter all the ICMPs; that's your only protection, and >it's sufficient. No need to change TCP for that. But once you force >the drop in the TCP spec, users can't put it back when they actually >want the service, and when they're in a trusted environment. That's not true. You can make it a SHOULD/SHOULD NOT. An operating systems could haFrom tcpm-bounces@ietf.org Sat May 20 03:43:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhM4g-00055p-3p; Sat, 20 May 2006 03:40:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhM4e-00055W-1D for tcpm@ietf.org; Sat, 20 May 2006 03:40:32 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhM4b-000697-Cr for tcpm@ietf.org; Sat, 20 May 2006 03:40:32 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4K7eDmc005105; Sat, 20 May 2006 04:40:17 -0300 Message-Id: <7.0.1.0.0.20060520030428.04e07620@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 20 May 2006 03:13:00 -0300 To: Joe Touch From: Fernando Gont Subject: Re: [tcpm] Re: Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt In-Reply-To: <446EAC3C.6070409@isi.edu> References: <7.0.1.0.0.20060518035047.06d3d718@gont.com.ar> <446C83E6.4030901@isi.edu> <7.0.1.0.0.20060519013043.06a4ef68@gont.com.ar> <446D5A33.8020202@isi.edu> <7.0.1.0.0.20060519031314.06a79038@gont.com.ar> <446DF5A0.3040607@isi.edu> <7.0.1.0.0.20060520013121.06a78248@gont.com.ar> <446EAC3C.6070409@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 02:42 20/05/2006, Joe Touch wrote: >>Joe, I think you miss the facts, here. >>All BSD-derived and Mentat-derived stacks treat hard errors as soft >>errors (for connections in any of the synchronized states) since at least 1994. >>There was no scream of "fire". >>As a matter of fact, I met Kirk McKusick and Mike Karels, and asked >>why, even before the security issues were raised, they had been >>implementing this for decades. Both of them answered: resetting >>established connections upon receipt of an ICMP error was simply nonsensical. > >Oh, so that's a fine reason. Skip the RFCs (1122 was 5 years prior). >Just reason it out for yourself. > >That may be how implementations get built, but that's not what we're >here to standardize. So we're here to publish documents that will be completely irrelevant to the industry, and that are years behind of the current needs. Fine. Let's remove the E in IETF. Let's call it ITF >>> - consider the RST stuff, which is NOT needed by end hosts, but >>> has made it into virtually every OS as well. >>That stuff is different. If you are concerned about them, use TCP >>MD5, IPSec, or any similar mechanism. >>There's no (in practice) such a thing for ICMP. > >Filtering does the same thing as conversion to soft errors. No, it doesn't. If the connection times out, and you filtered the ICMP, you have no clue of what went wrong. >>First, as Section 1.3.2 of RFC 1812 says: "It is best to assume >>that the network is filled with malevolent entities that will send packets >>designed to have the worst possible effect. This assumption will >>lead to suitably protective design." > >Fine. Then filter all the ICMPs; that's your only protection, and >it's sufficient. No need to change TCP for that. But once you force >the drop in the TCP spec, users can't put it back when they actually >want the service, and when they're in a trusted environment. That's not true. You can make it a SHOULD/SHOULD NOT. An operating systems could have a sysctl for it. It could be net.inet.icmp.hackme, and current ICMP processing would be enabled by setting the variable to 1. >>Seconds, regarding the capability that "is lost"... in the event >>you lose any, ICMP is unreliable, anyway. > >That's a block we've been around too. IP is unreliable, but if we >drop them all all the time, we're protected, but also have no functionality. > >Do you drop all IP packets too? They might be attacks! Joe, While I respect your opinion, the WG has already got to consensus on these issues. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat May 20 03:43:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhM4f-00055f-II; Sat, 20 May 2006 03:40:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhM4d-00055P-Vl for tcpm@ietf.org; Sat, 20 May 2006 03:40:31 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhM4b-00069A-Cq for tcpm@ietf.org; Sat, 20 May 2006 03:40:31 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4K7eDme005105; Sat, 20 May 2006 04:40:18 -0300 Message-Id: <7.0.1.0.0.20060520031331.04df7568@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 20 May 2006 03:18:27 -0300 To: Joe Touch From: Fernando Gont Subject: Re: [tcpm] Re: Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt In-Reply-To: <446EAD4C.8040202@isi.edu> References: <7.0.1.0.0.20060518035047.06d3d718@gont.com.ar> <446C83E6.4030901@isi.edu> <7.0.1.0.0.20060519013043.06a4ef68@gont.com.ar> <446D5A33.8020202@isi.edu> <7.0.1.0.0.20060519031314.06a79038@gont.com.ar> <446DF5A0.3040607@isi.edu> <446E0DDB.3040404@isi.edu> <7.0.1.0.0.20060520020629.06a886f8@gont.com.ar> <446EAD4C.8040202@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 02:46 20/05/2006, Joe Touch wrote: >>Even if the only thing I did with the Internet was to download >>pirated music and porn, as a user I would still be concerned about >>my downloads being interrupted by some idiot firing ICMP messages. > >Who is going to bother sending your host ICMP attacks, and why can't >your system figure that out at the ICMP level (too many ICMPs >received, so enable a filter to shut them down, in a reactive way)? You only need one packet to reset a connection. >Why do we need to shut off that capability for all TCPs? It's already shut off. I can only think that you hacked the kernel of your OS to implement RFC1222-processing of ICMP messages. ;-) >>>I don't want to dictate that sort of behavior for the protocol as >>>a rule exactly because it turns off a capability for those not under attack. >>Yea... And the door you have in your house turns off a capability >>in those cases in which there are no thieves out there. > >That's why it's not a wall. It opens when I want it to. Defining TCP >to treat these as soft errors puts up a wall (to the capability); ve a sysctl for it. It could be net.inet.icmp.hackme, and current ICMP processing would be enabled by setting the variable to 1. >>Seconds, regarding the capability that "is lost"... in the event >>you lose any, ICMP is unreliable, anyway. > >That's a block we've been around too. IP is unreliable, but if we >drop them all all the time, we're protected, but also have no functionality. > >Do you drop all IP packets too? They might be attacks! Joe, While I respect your opinion, the WG has already got to consensus on these issues. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat May 20 03:43:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhM4f-00055f-II; Sat, 20 May 2006 03:40:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhM4d-00055P-Vl for tcpm@ietf.org; Sat, 20 May 2006 03:40:31 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhM4b-00069A-Cq for tcpm@ietf.org; Sat, 20 May 2006 03:40:31 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4K7eDme005105; Sat, 20 May 2006 04:40:18 -0300 Message-Id: <7.0.1.0.0.20060520031331.04df7568@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 20 May 2006 03:18:27 -0300 To: Joe Touch From: Fernando Gont Subject: Re: [tcpm] Re: Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt In-Reply-To: <446EAD4C.8040202@isi.edu> References: <7.0.1.0.0.20060518035047.06d3d718@gont.com.ar> <446C83E6.4030901@isi.edu> <7.0.1.0.0.20060519013043.06a4ef68@gont.com.ar> <446D5A33.8020202@isi.edu> <7.0.1.0.0.20060519031314.06a79038@gont.com.ar> <446DF5A0.3040607@isi.edu> <446E0DDB.3040404@isi.edu> <7.0.1.0.0.20060520020629.06a886f8@gont.com.ar> <446EAD4C.8040202@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 02:46 20/05/2006, Joe Touch wrote: >>Even if the only thing I did with the Internet was to download >>pirated music and porn, as a user I would still be concerned about >>my downloads being interrupted by some idiot firing ICMP messages. > >Who is going to bother sending your host ICMP attacks, and why can't >your system figure that out at the ICMP level (too many ICMPs >received, so enable a filter to shut them down, in a reactive way)? You only need one packet to reset a connection. >Why do we need to shut off that capability for all TCPs? It's already shut off. I can only think that you hacked the kernel of your OS to implement RFC1222-processing of ICMP messages. ;-) >>>I don't want to dictate that sort of behavior for the protocol as >>>a rule exactly because it turns off a capability for those not under attack. >>Yea... And the door you have in your house turns off a capability >>in those cases in which there are no thieves out there. > >That's why it's not a wall. It opens when I want it to. Defining TCP >to treat these as soft errors puts up a wall (to the capability); >let the user do that when they want to, but don't force it. No, you put a wall if you filtr ICMP in the network. If you implement that in TCP, then it's up to the user to enable it explicitly, and screw his life up himself. >If an ICMP-level filter isn't enough (and it should be preferable - >that's the place that you'd know that different protocols were under >attack simultaneously), maybe you could define an API parameter (ala >Nagle) that turns these hard errors to soft, sort of a >"suspect_ICMP" parameter? That way the user could at least turn it >back to non-suspect if they wanted to, and have a reactive system again. Joe, Again: do you think that resetting a TCP conenction in response to, say, an ICMP protocol unreachable is the proper thing to do? If not, I don't understand what you're arguing. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm >let the user do that when they want to, but don't force it. No, you put a wall if you filtr ICMP in the network. If you implement that in TCP, then it's up to the user to enable it explicitly, and screw his life up himself. >If an ICMP-level filter isn't enough (and it should be preferable - >that's the place that you'd know that different protocols were under >attack simultaneously), maybe you could define an API parameter (ala >Nagle) that turns these hard errors to soft, sort of a >"suspect_ICMP" parameter? That way the user could at least turn it >back to non-suspect if they wanted to, and have a reactive system again. Joe, Again: do you think that resetting a TCP conenction in response to, say, an ICMP protocol unreachable is the proper thing to do? If not, I don't understand what you're arguing. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat May 20 03:43:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhM4f-00055k-Tn; Sat, 20 May 2006 03:40:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhM4e-00055U-0R for tcpm@ietf.org; Sat, 20 May 2006 03:40:32 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhM4b-000696-Cq for tcpm@ietf.org; Sat, 20 May 2006 03:40:31 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4K7eDma005105; Sat, 20 May 2006 04:40:16 -0300 Message-Id: <7.0.1.0.0.20060520025919.06a96030@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 20 May 2006 03:02:50 -0300 To: Joe Touch From: Fernando Gont Subject: Re: [tcpm] Re: Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt In-Reply-To: <446EAB0F.6020103@isi.edu> References: <70C6EFCDFC8AAD418EF7063CD132D064B1980C@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <446E2786.2020704@isi.edu> <7.0.1.0.0.20060520021236.00f32648@gont.com.ar> <446EAB0F.6020103@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Christian Huitema , tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 02:37 20/05/2006, Joe Touch wrote: >>>>So, Joe, you agree that at least some systems will simply ignore ICMP, >>>>e.g. because a firewall is programmed to drop all ICMP messages. It >>>>seems then that TCPM should be concerned with the behavior of TCP in >>>>such environments. It would be nice to have ICMP-less alternatives for >>>>the problems that you mention, starting with PMTU discovery, v6/v4 fall >>>>back, etc. >>> >>>ICMP-less solutions to PMTUD are being developed already. >>I really doubt that implementations will completely get rid of ICMP >>"frag needed". > >Hard to say why they'd keep it if they have a separate, more robust >(to ICMP blocking) protocol that works sufficiently. There's the issue of "convergence time". For interactive applications, such as the web, it is important. More than one free operating system opposed to get rid of ICMP "frag needed" for PMTUD, for the above reason. This does not mean that they wouldn't implement PLPMTUD, but that they wouldn't implement it without the aid of ICMP. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat May 20 10:36:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhSYt-0000oN-W2; Sat, 20 May 2006 10:36:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhSYs-0000oI-M2 for tcpm@ietf.org; Sat, 20 May 2006 10:36:10 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhSYq-000588-Ao for tcpm@ietf.org; Sat, 20 May 2006 10:36:10 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4KEYkU16467; Sat, 20 May 2006 07:34:46 -0700 (PDT) Message-ID: <446F2901.7080309@isi.edu> Date: Sat, 20 May 2006 07:34:41 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] Re: Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt References: <7.0.1.0.0.20060518035047.06d3d718@gont.com.ar> <446C83E6.4030901@isi.edu> <7.0.1.0.0.20060519013043.06a4ef68@gont.com.ar> <446D5A33.8020202@isi.edu> <7.0.1.0.0.20060519031314.06a79038@gont.com.ar> <446DF5A0.3040607@isi.edu> <446E0DDB.3040404@isi.edu> <7.0.1.0.0.20060520020629.06a886f8@gont.com.ar> <446EAD4C.8040202@isi.edu> <7.0.1.0.0.20060520031331.04df7568@gont.com.ar> In-Reply-To: <7.0.1.0.0.20060520031331.04df7568@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 93238566e09e6e262849b4f805833007 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Fernando Gont wrote: ... > Again: do you think that resetting a TCP conenction in response to, say, > an ICMP protocol unreachable is the proper thing to do? Yes. It means the protocol is unreachable. If you don't trust ICMP, then block it altogether. Your other message want PMTUD to be reactive, so you want ICMP signals there. Why would you allow attackers to alter your PMTU, when you are so worried here? The same net effect results - throughput can be set to effectively zero in either case. IMO, *if* you don't trust ICMP, that's a transport-wide decision. I don't see a reason to discriminate within TCP. (and yes, if it's *broken* w.r.t. the specs, we ought to recommend fixing it; in the IETF, we're supposed to do what we thing needs to be done first and let the implementations follow, not the other way around. It's rough consensus and running code, not de-facto rubberstamps). Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat May 20 23:58:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fhf4B-00009B-6h; Sat, 20 May 2006 23:57:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fhf4A-000071-L3 for tcpm@ietf.org; Sat, 20 May 2006 23:57:18 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fhf4A-0005FD-2M for tcpm@ietf.org; Sat, 20 May 2006 23:57:18 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4L3vItx006523; Sun, 21 May 2006 00:57:19 -0300 Message-Id: <7.0.1.0.0.20060520235539.04b95370@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 21 May 2006 00:06:12 -0300 To: Joe Touch From: Fernando Gont Subject: Re: [tcpm] Re: Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt In-Reply-To: <446F2901.7080309@isi.edu> References: <7.0.1.0.0.20060518035047.06d3d718@gont.com.ar> <446C83E6.4030901@isi.edu> <7.0.1.0.0.20060519013043.06a4ef68@gont.com.ar> <446D5A33.8020202@isi.edu> <7.0.1.0.0.20060519031314.06a79038@gont.com.ar> <446DF5A0.3040607@isi.edu> <446E0DDB.3040404@isi.edu> <7.0.1.0.0.20060520020629.06a886f8@gont.com.ar> <446EAD4C.8040202@isi.edu> <7.0.1.0.0.20060520031331.04df7568@gont.com.ar> <446F2901.7080309@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 11:34 20/05/2006, Joe Touch wrote: >... >>Again: do you think that resetting a TCP conenction in response to, >>say, an ICMP protocol unreachable is the proper thing to do? > >Yes. It means the protocol is unreachable. It may mean that the protocol is unreachable.... or that some corrupted packet elicited the ICMP error message in question. ;-) And, btw, you were able to establish a connection, and now TCP is gone? Did you give root access to your kids, or what? (and they have a loadable-module TCP, which they load and unload all the time). What policy makes the network more robust? What policy makes TCP more robust? Shouldn't the Internet be robust? >If you don't trust ICMP, then block it altogether. Engineering is usually a trade-off, rather than a white or black thing. I'm interested in having a robust network, while still knowing the cause of problems when something goes on. Namely, if my connections time out, I'd like to know why. This is sort of what D. Clark said about twenty years ago, btw. >Your other message want PMTUD to be reactive, so you want ICMP >signals there. Why would you allow attackers to alter your PMTU, >when you are so worried here? The same net effect results - >throughput can be set to effectively zero in either case. In order for an attacker to defeat the mechanism discussed in the ICMP attacks draft, he has to be a "man in the middle". At that point, he wouldn't bother to set a low MTU. Why I'd like PMTU to be reactive? Because I wouldn't to be in the position to explain the user community while they now have to wait to get the web page they want to get. >IMO, *if* you don't trust ICMP, that's a transport-wide decision. I >don't see a reason to discriminate within TCP. The checks are transport-protocol specific. >(and yes, if it's *broken* w.r.t. the specs, we ought to recommend >fixing it; in the IETF, we're supposed to do what we thing needs to >be done first and let the implementations follow, not the other way >around. It's rough consensus and running code, not de-facto rubberstamps). If it takes us years to change the specs, I'm afraid it will be us following the implementations. And, no, I don't consider the ICMP attacks rubberstamps. For instance, I'd say all the people listed in the acknowledgements (other than you, if you want) agreed that this is the right thing to do. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun May 21 14:40:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fhspn-0007Dn-1X; Sun, 21 May 2006 14:39:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fhspm-0007Cr-8g for tcpm@ietf.org; Sun, 21 May 2006 14:39:22 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fhspj-0003ta-R8 for tcpm@ietf.org; Sun, 21 May 2006 14:39:22 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4LIcVI26807; Sun, 21 May 2006 11:38:31 -0700 (PDT) Message-ID: <4470B3A1.7060709@isi.edu> Date: Sun, 21 May 2006 11:38:25 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] Re: Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt References: <7.0.1.0.0.20060518035047.06d3d718@gont.com.ar> <446C83E6.4030901@isi.edu> <7.0.1.0.0.20060519013043.06a4ef68@gont.com.ar> <446D5A33.8020202@isi.edu> <7.0.1.0.0.20060519031314.06a79038@gont.com.ar> <446DF5A0.3040607@isi.edu> <446E0DDB.3040404@isi.edu> <7.0.1.0.0.20060520020629.06a886f8@gont.com.ar> <446EAD4C.8040202@isi.edu> <7.0.1.0.0.20060520031331.04df7568@gont.com.ar> <446F2901.7080309@isi.edu> <7.0.1.0.0.20060520235539.04b95370@gont.com.ar> In-Reply-To: <7.0.1.0.0.20060520235539.04b95370@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: e1b0e72ff1bbd457ceef31828f216a86 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Fernando Gont wrote: > At 11:34 20/05/2006, Joe Touch wrote: > >> ... >>> Again: do you think that resetting a TCP conenction in response to, >>> say, an ICMP protocol unreachable is the proper thing to do? >> >> Yes. It means the protocol is unreachable. > > It may mean that the protocol is unreachable.... or that some corrupted > packet elicited the ICMP error message in question. ;-) > > And, btw, you were able to establish a connection, and now TCP is gone? > Did you give root access to your kids, or what? (and they have a > loadable-module TCP, which they load and unload all the time). Maybe you ran an OS that installed updates as you went automatically. Maybe the node is a laptop that's been shut. There are many reasons for a legitimate message. > What policy makes the network more robust? What policy makes TCP more > robust? > > Shouldn't the Internet be robust? Yes. Especially to the whims of people who think that every message they don't _expect_ means an attack ;-) >> If you don't trust ICMP, then block it altogether. > > Engineering is usually a trade-off, rather than a white or black thing. Agreed. Which is also a reason not to burn this decision into the transport protocol. A separate filter can make the decisions you're suggesting just fine. > I'm interested in having a robust network, while still knowing the cause > of problems when something goes on. > Namely, if my connections time out, I'd like to know why. Goes to intent. Sometimes you can't. Sometimes all you know is that they went down. ... >> Your other message want PMTUD to be reactive, so you want ICMP signals >> there. Why would you allow attackers to alter your PMTU, when you are >> so worried here? The same net effect results - throughput can be set >> to effectively zero in either case. > > In order for an attacker to defeat the mechanism discussed in the ICMP > attacks draft, he has to be a "man in the middle". At that point, he > wouldn't bother to set a low MTU. Sure he would - to avoid your thinking he was there. To make you think you weren't under a 'real' attack. > Why I'd like PMTU to be reactive? > Because I wouldn't to be in the position to explain the user community > while they now have to wait to get the web page they want to get. So here you want to know what's going on, so the ICMP needs to get through. But in the case of TCP, you want to know what's going on, but that means blocking ICMP. This all goes to whether you expect the message under normal operations, not whether it's reasonable in a network that isn't under attack. >> IMO, *if* you don't trust ICMP, that's a transport-wide decision. I >> don't see a reason to discriminate within TCP. > > The checks are transport-protocol specific. How do they differ for TCP vs. SCTP and DCCP? >> (and yes, if it's *broken* w.r.t. the specs, we ought to recommend >> fixing it; in the IETF, we're supposed to do what we thing needs to be >> done first and let the implementations follow, not the other way >> around. It's rough consensus and running code, not de-facto >> rubberstamps). > > If it takes us years to change the specs, I'm afraid it will be us > following the implementations. You're not answering the question. The point is that the implementations don't weigh into the decision on how to proceed here. > And, no, I don't consider the ICMP attacks rubberstamps. For instance, > I'd say all the people listed in the acknowledgements (other than you, > if you want) agreed that this is the right thing to do. IETF process is by "rough consensus", which does not mean unanimous approval nor does it mean approval by those who contributed to the document. There's no need to state that there. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon May 22 00:59:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi2VO-0007Ux-J1; Mon, 22 May 2006 00:58:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi2VM-0007Us-MD for tcpm@ietf.org; Mon, 22 May 2006 00:58:56 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fi2VL-0003Rv-6n for tcpm@ietf.org; Mon, 22 May 2006 00:58:56 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060308/8.12.11) with ESMTP id k4M4wW6x017161; Mon, 22 May 2006 07:58:36 +0300 Date: Mon, 22 May 2006 07:58:32 +0300 (EEST) From: Pekka Savola To: Joe Touch In-Reply-To: <4470B3A1.7060709@isi.edu> Message-ID: References: <7.0.1.0.0.20060518035047.06d3d718@gont.com.ar> <446C83E6.4030901@isi.edu> <7.0.1.0.0.20060519013043.06a4ef68@gont.com.ar> <446D5A33.8020202@isi.edu> <7.0.1.0.0.20060519031314.06a79038@gont.com.ar> <446DF5A0.3040607@isi.edu> <446E0DDB.3040404@isi.edu> <7.0.1.0.0.20060520020629.06a886f8@gont.com.ar> <446EAD4C.8040202@isi.edu> <7.0.1.0.0.20060520031331.04df7568@gont.com.ar> <446F2901.7080309@isi.edu> <7.0.1.0.0.20060520235539.04b95370@gont.com.ar> <4470B3A1.7060709@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1474/Sun May 21 16:18:22 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: tcpm@ietf.org, Fernando Gont Subject: [tcpm] on rough consensus and running code X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Sun, 21 May 2006, Joe Touch wrote: [Joe quoting Fernando] >> If it takes us years to change the specs, I'm afraid it will be us >> following the implementations. > > You're not answering the question. The point is that the implementations > don't weigh into the decision on how to proceed here. Joe, I think the majority of the IETF has a very different view of what 'running code' implies in the slogan 'rough consensus and running code'. There _is_ an AND there, but (IMHO) that's relevant only if the running code and rough consensus were at significant odds with each other. I don't think that's the case, as it happens there was rough consensus to work on these docs, and this discussion isn't contributing anything to the drafts; we've been through this before and opted to go for it. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon May 22 10:15:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiBCE-0002z0-Hg; Mon, 22 May 2006 10:15:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiBCC-0002yv-3L for tcpm@ietf.org; Mon, 22 May 2006 10:15:44 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiBCA-0002Uz-Ok for tcpm@ietf.org; Mon, 22 May 2006 10:15:44 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4MEEaI17751; Mon, 22 May 2006 07:14:36 -0700 (PDT) Message-ID: <4471C746.4050208@isi.edu> Date: Mon, 22 May 2006 07:14:30 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Pekka Savola References: <7.0.1.0.0.20060518035047.06d3d718@gont.com.ar> <446C83E6.4030901@isi.edu> <7.0.1.0.0.20060519013043.06a4ef68@gont.com.ar> <446D5A33.8020202@isi.edu> <7.0.1.0.0.20060519031314.06a79038@gont.com.ar> <446DF5A0.3040607@isi.edu> <446E0DDB.3040404@isi.edu> <7.0.1.0.0.20060520020629.06a886f8@gont.com.ar> <446EAD4C.8040202@isi.edu> <7.0.1.0.0.20060520031331.04df7568@gont.com.ar> <446F2901.7080309@isi.edu> <7.0.1.0.0.20060520235539.04b95370@gont.com.ar> <4470B3A1.7060709@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 7d33c50f3756db14428398e2bdedd581 Cc: tcpm@ietf.org, Fernando Gont Subject: [tcpm] Re: on rough consensus and running code X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Pekka Savola wrote: > On Sun, 21 May 2006, Joe Touch wrote: > [Joe quoting Fernando] >>> If it takes us years to change the specs, I'm afraid it will be us >>> following the implementations. >> >> You're not answering the question. The point is that the >> implementations don't weigh into the decision on how to proceed here. > > Joe, I think the majority of the IETF has a very different view of what > 'running code' implies in the slogan 'rough consensus and running code'. It means proof of a protocol idea that gets it from PS to DS to S. It doesn't mean a vote in the process to decide whether to move forward to PS with an idea. Which is why it has no bearing at this phase in the process, IMO. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon May 22 12:10:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiCzC-0001bR-0d; Mon, 22 May 2006 12:10:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiCzA-0001ao-Ht for tcpm@ietf.org; Mon, 22 May 2006 12:10:24 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiCz8-0007zu-4u for tcpm@ietf.org; Mon, 22 May 2006 12:10:24 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4MG8YB18731; Mon, 22 May 2006 09:08:34 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.6/8.13.6/Submit) id k4MG8YL2010810; Mon, 22 May 2006 09:08:34 -0700 (PDT) (envelope-from faber) Date: Mon, 22 May 2006 09:08:34 -0700 From: Ted Faber To: Fernando Gont Subject: Re: [tcpm] ICMP and TCP Message-ID: <20060522160834.GA15259@hut.isi.edu> References: <03235919BBDE634289BB6A0758A20B365EB188@NT-SJCA-0751.brcm.ad.broadcom.com> <7.0.1.0.0.20060520015715.048f6050@gont.com.ar> Mime-Version: 1.0 In-Reply-To: <7.0.1.0.0.20060520015715.048f6050@gont.com.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@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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="===============1303546188==" Errors-To: tcpm-bounces@ietf.org --===============1303546188== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 20, 2006 at 02:00:03AM -0300, Fernando Gont wrote: > At 14:48 19/05/2006, Bora Akyol wrote: >=20 > >Should we stop beating around the bush and cut the cord between=20 > >these two altogether? Even > >PMTU discovery is really an L3 function. >=20 > Would you apply the same rationale to TCP's congestion control, too? Of course he wouldn't. Congestion control cannot be done (only) on a per-host basis, because individual sessions take different paths through the network and have different mechanisms for adaptation to reduced network capacity. (You slow down a video stream and a file transfer using different application and transport mechanisms, and slowing down sessions that are not passing through a congested router is a waste of time). While congestion *detection* is, IMHO, a legitimate L3 function, control is a more complex endeavour. --=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 --jI8keyz6grp/JLjh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEceICaUz3f+Zf+XsRAkTIAKDa4eAKJPBDRSIdk5U0bM212J2kXwCgwcok YGE5lvK/DovYbU4/g76X7jw= =KoIw -----END PGP SIGNATURE----- --jI8keyz6grp/JLjh-- --===============1303546188== 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 --===============1303546188==-- From tcpm-bounces@ietf.org Mon May 22 12:26:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiDE6-00010q-2E; Mon, 22 May 2006 12:25:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiDE4-00010l-He for tcpm@ietf.org; Mon, 22 May 2006 12:25:48 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiDE3-0008U0-5J for tcpm@ietf.org; Mon, 22 May 2006 12:25:48 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4MGPNB27141; Mon, 22 May 2006 09:25:23 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.6/8.13.6/Submit) id k4MGPNW6033291; Mon, 22 May 2006 09:25:23 -0700 (PDT) (envelope-from faber) Date: Mon, 22 May 2006 09:25:23 -0700 From: Ted Faber To: Fernando Gont Subject: Re: [tcpm] ICMP and TCP Message-ID: <20060522162523.GC15259@hut.isi.edu> References: <03235919BBDE634289BB6A0758A20B365EB188@NT-SJCA-0751.brcm.ad.broadcom.com> <7.0.1.0.0.20060520015715.048f6050@gont.com.ar> <20060522160834.GA15259@hut.isi.edu> Mime-Version: 1.0 In-Reply-To: <20060522160834.GA15259@hut.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@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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="===============1096232941==" Errors-To: tcpm-bounces@ietf.org --===============1096232941== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xo44VMWPx7vlQ2+2" Content-Disposition: inline --xo44VMWPx7vlQ2+2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 22, 2006 at 09:08:34AM -0700, Ted Faber wrote: > On Sat, May 20, 2006 at 02:00:03AM -0300, Fernando Gont wrote: > > At 14:48 19/05/2006, Bora Akyol wrote: > >=20 > > >Should we stop beating around the bush and cut the cord between=20 > > >these two altogether? Even > > >PMTU discovery is really an L3 function. > >=20 > > Would you apply the same rationale to TCP's congestion control, too? >=20 > Of course he wouldn't. >=20 > Congestion control cannot be done (only) on a per-host basis, because > individual sessions take different paths through the network and have > different mechanisms for adaptation to reduced network capacity. (You > slow down a video stream and a file transfer using different application > and transport mechanisms, and slowing down sessions that are not passing > through a congested router is a waste of time). >=20 > While congestion *detection* is, IMHO, a legitimate L3 function, control > is a more complex endeavour. I realize that wasn't exactly helpful to the discussion, but you know how congestion control gets the better of me. I do have sympathy for the position that TCP should be ICMP-independent, using ICMP messages only as hints. PMTUD seems to be the big stumbling block in that perspective, and the sooner we have ICMP-free PMTUD the happier I'll be. However, there are two issues on the table here: 1. Given the world in which we live, is the ICMP attacks draft a reflection of group consensus yet? 2. Should we also be writing a draft/taking a position on ICMP-free TCP? Does that generalize? Let's try to keep those clear while we are discussing. And try not to tease me with congestion control discussions. :-) --=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 --xo44VMWPx7vlQ2+2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEceXzaUz3f+Zf+XsRAv11AJwMv3qte7QIbCOa1WMkK7zC8xDuJgCgxzM4 2FEVwTewcXPHNbSDiYVdW+s= =5bul -----END PGP SIGNATURE----- --xo44VMWPx7vlQ2+2-- --===============1096232941== 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 --===============1096232941==-- From tcpm-bounces@ietf.org Mon May 22 12:33:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiDLf-0002Pn-SX; Mon, 22 May 2006 12:33:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiDLe-0002Pa-Ob for tcpm@ietf.org; Mon, 22 May 2006 12:33:38 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiDLd-0000Px-DJ for tcpm@ietf.org; Mon, 22 May 2006 12:33:38 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4MGWoI04446; Mon, 22 May 2006 09:32:50 -0700 (PDT) Message-ID: <4471E7AC.5050604@isi.edu> Date: Mon, 22 May 2006 09:32:44 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Bora Akyol Subject: Re: [tcpm] ICMP and TCP References: <03235919BBDE634289BB6A0758A20B365EB198@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <03235919BBDE634289BB6A0758A20B365EB198@NT-SJCA-0751.brcm.ad.broadcom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Bora Akyol wrote: > Joe > > Please see my other email, I think it was wrong for TCP to rely on these > > in the first place. > > The logic was that all L4 protocols can share the same control protocol > in ICMP, > but how does this help when L4 protocols are so divergent in their > nature? They're not all that divergent - SCTP, DCCP, all share state and have TCP-like congestion control. Where they do diverge (state vs. stateless), that difference is already described (RFC1122). > How does this help, when the security of one protocol is so tightly > coupled with another. Therein lies the rub. > How does it help, when responses to hard errors now become dependent on > the state we're in ;-) You're arguing for the deprecation of ICMP. That's independent from redefining it just within TCP. > I think lack of all the *+unreachable messages can be handled within > TCP. It's entirely consistent to handle those both within TCP and within other L4's, e.g., to allow a bunch of different protocols to react to the disappearance of a host. It's also consistent to allow the host to do other things - e.g., affect its forwarding table (L3) based on some of these messages. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon May 22 12:38:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiDQO-0005dj-W7; Mon, 22 May 2006 12:38:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiDQN-0005YY-Sw for tcpm@ietf.org; Mon, 22 May 2006 12:38:31 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiDQM-0000bQ-I7 for tcpm@ietf.org; Mon, 22 May 2006 12:38:31 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4MGbCI05636; Mon, 22 May 2006 09:37:12 -0700 (PDT) Message-ID: <4471E8B3.6080507@isi.edu> Date: Mon, 22 May 2006 09:37:07 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Ted Faber Subject: Re: [tcpm] ICMP and TCP References: <03235919BBDE634289BB6A0758A20B365EB188@NT-SJCA-0751.brcm.ad.broadcom.com> <7.0.1.0.0.20060520015715.048f6050@gont.com.ar> <20060522160834.GA15259@hut.isi.edu> <20060522162523.GC15259@hut.isi.edu> In-Reply-To: <20060522162523.GC15259@hut.isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 856eb5f76e7a34990d1d457d8e8e5b7f 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: , Errors-To: tcpm-bounces@ietf.org Ted Faber wrote: ... > 2. Should we also be writing a draft/taking a position on > ICMP-free TCP? Does that generalize? I don't think we should be writing that; that's a TSVWG issue, unless we have magic to explain why TCP should be the lone, first, or otherwise unique protocol to start deprecating ICMP. I agree that ICMP is an issue, and that the Internet is a mess. But standardizing incremental hacks to tweak TCP to fix that isn't a good way forward, regardless of what's deployed. Which goes to your first point, but my position on that is already clear. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon May 22 13:12:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiDwp-0008KV-6u; Mon, 22 May 2006 13:12:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiDwo-0008KQ-0t for tcpm@ietf.org; Mon, 22 May 2006 13:12:02 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiDwm-0001yy-KI for tcpm@ietf.org; Mon, 22 May 2006 13:12:02 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4MHAdB18581; Mon, 22 May 2006 10:10:39 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.6/8.13.6/Submit) id k4MHAY0n042570; Mon, 22 May 2006 10:10:34 -0700 (PDT) (envelope-from faber) Date: Mon, 22 May 2006 10:10:34 -0700 From: Ted Faber To: Joe Touch Subject: Re: [tcpm] ICMP and TCP Message-ID: <20060522171034.GB41441@hut.isi.edu> References: <03235919BBDE634289BB6A0758A20B365EB188@NT-SJCA-0751.brcm.ad.broadcom.com> <7.0.1.0.0.20060520015715.048f6050@gont.com.ar> <20060522160834.GA15259@hut.isi.edu> <20060522162523.GC15259@hut.isi.edu> <4471E8B3.6080507@isi.edu> Mime-Version: 1.0 In-Reply-To: <4471E8B3.6080507@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@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: tcpm@ietf.org, Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1478671052==" Errors-To: tcpm-bounces@ietf.org --===============1478671052== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mvpLiMfbWzRoNl4x" Content-Disposition: inline --mvpLiMfbWzRoNl4x Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 22, 2006 at 09:37:07AM -0700, Joe Touch wrote: > I agree that ICMP is an issue, and that the Internet is a mess. But=20 > standardizing incremental hacks to tweak TCP to fix that isn't a good=20 > way forward, regardless of what's deployed. If by "standardizing" you mean issuing an RFC on the standards track, that's not the current plan for this document. The last time we asked, at IETF-64 (http://tools.ietf.org/wg/tcpm/minutes?item=3Dminutes64.html), the group consensus was clearly for BCP or informational. If by "standardizing," you mean writing anything at all, well you're clearly on the wrong side of consensus. The last time we asked about that (same meeting), there was no opposition at all. The issue is what to say. Documenting current practice or analyzing the choices open to implementors seems reasonable to me. Y'know, without my hat on. --=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 --mvpLiMfbWzRoNl4x Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEcfCKaUz3f+Zf+XsRAnLuAKDpptik4MsZ5uBUaHVbUi65jGNgYgCgvO4A TVdbvcG5aFjJbMR9HqappQE= =zt6s -----END PGP SIGNATURE----- --mvpLiMfbWzRoNl4x-- --===============1478671052== 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 --===============1478671052==-- From tcpm-bounces@ietf.org Mon May 22 13:36:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiEKP-0001EJ-L5; Mon, 22 May 2006 13:36:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiEKO-0001EE-6d for tcpm@ietf.org; Mon, 22 May 2006 13:36:24 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiEKM-0002x7-QF for tcpm@ietf.org; Mon, 22 May 2006 13:36:24 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4MHZjI22004; Mon, 22 May 2006 10:35:45 -0700 (PDT) Message-ID: <4471F66B.1020104@isi.edu> Date: Mon, 22 May 2006 10:35:39 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Ted Faber Subject: Re: [tcpm] ICMP and TCP References: <03235919BBDE634289BB6A0758A20B365EB188@NT-SJCA-0751.brcm.ad.broadcom.com> <7.0.1.0.0.20060520015715.048f6050@gont.com.ar> <20060522160834.GA15259@hut.isi.edu> <20060522162523.GC15259@hut.isi.edu> <4471E8B3.6080507@isi.edu> <20060522171034.GB41441@hut.isi.edu> In-Reply-To: <20060522171034.GB41441@hut.isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 2409bba43e9c8d580670fda8b695204a 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: , Errors-To: tcpm-bounces@ietf.org Ted Faber wrote: > On Mon, May 22, 2006 at 09:37:07AM -0700, Joe Touch wrote: >> I agree that ICMP is an issue, and that the Internet is a mess. But >> standardizing incremental hacks to tweak TCP to fix that isn't a good >> way forward, regardless of what's deployed. > > If by "standardizing" you mean issuing an RFC on the standards track, > that's not the current plan for this document. That's what I meant. > The last time we asked, > at IETF-64 (http://tools.ietf.org/wg/tcpm/minutes?item=minutes64.html), > the group consensus was clearly for BCP or informational. Sure. ... > The issue is what to say. Documenting current practice or analyzing > the choices open to implementors seems reasonable to me. Y'know, > without my hat on. *always*. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon May 22 14:03:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiEku-0003HJ-Hv; Mon, 22 May 2006 14:03:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiEkt-0003HE-5f for tcpm@ietf.org; Mon, 22 May 2006 14:03:47 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiEkr-0004et-Ox for tcpm@ietf.org; Mon, 22 May 2006 14:03:47 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4MI2xB12285; Mon, 22 May 2006 11:02:59 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.6/8.13.6/Submit) id k4MI2xDw043898; Mon, 22 May 2006 11:02:59 -0700 (PDT) (envelope-from faber) Date: Mon, 22 May 2006 11:02:59 -0700 From: Ted Faber To: Joe Touch Subject: Re: [tcpm] ICMP and TCP Message-ID: <20060522180259.GD41441@hut.isi.edu> References: <03235919BBDE634289BB6A0758A20B365EB188@NT-SJCA-0751.brcm.ad.broadcom.com> <7.0.1.0.0.20060520015715.048f6050@gont.com.ar> <20060522160834.GA15259@hut.isi.edu> <20060522162523.GC15259@hut.isi.edu> <4471E8B3.6080507@isi.edu> <20060522171034.GB41441@hut.isi.edu> <4471F66B.1020104@isi.edu> Mime-Version: 1.0 In-Reply-To: <4471F66B.1020104@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@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: tcpm@ietf.org, Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0885588736==" Errors-To: tcpm-bounces@ietf.org --===============0885588736== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4VrXvz3cwkc87Wze" Content-Disposition: inline --4VrXvz3cwkc87Wze Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 22, 2006 at 10:35:39AM -0700, Joe Touch wrote: > Ted Faber wrote: > >On Mon, May 22, 2006 at 09:37:07AM -0700, Joe Touch wrote: > >>I agree that ICMP is an issue, and that the Internet is a mess. But=20 > >>standardizing incremental hacks to tweak TCP to fix that isn't a good= =20 > >>way forward, regardless of what's deployed. > > > >If by "standardizing" you mean issuing an RFC on the standards track, > >that's not the current plan for this document.=20 >=20 > That's what I meant. Then, be reassured. Informational/BCP is the plan.=20 > >The issue is what to say. Documenting current practice or analyzing > >the choices open to implementors seems reasonable to me. Y'know, > >without my hat on. >=20 > *always*. I do wear the chair hat *sometimes*. When Mark's not looking. Just not now. --=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 --4VrXvz3cwkc87Wze Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEcfzTaUz3f+Zf+XsRAh/RAJ9gWFLVQFlpiYlvD8Uj+k9smJJMfACgmhpr LuPRuuPLOyuxL/uKvbq12hQ= =GScw -----END PGP SIGNATURE----- --4VrXvz3cwkc87Wze-- --===============0885588736== 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 --===============0885588736==-- From tcpm-bounces@ietf.org Mon May 22 14:14:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiEv9-0007ku-V3; Mon, 22 May 2006 14:14:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiEv9-0007kp-Kf for tcpm@ietf.org; Mon, 22 May 2006 14:14:23 -0400 Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiEv8-00055x-AA for tcpm@ietf.org; Mon, 22 May 2006 14:14:23 -0400 Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Mon, 22 May 2006 11:14:10 -0700 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id B4BC82AE; Mon, 22 May 2006 11:14:10 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 5C0562B0; Mon, 22 May 2006 11:14:10 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id DOW43504; Mon, 22 May 2006 11:14:08 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 6D55220501; Mon, 22 May 2006 11:14:08 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] ICMP and TCP Date: Mon, 22 May 2006 11:14:07 -0700 Message-ID: <03235919BBDE634289BB6A0758A20B365EB2FC@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [tcpm] ICMP and TCP Thread-Index: AcZ9vJsJNBtpezZ1TTiQbmFgxxtOAAADm1vQ From: "Bora Akyol" To: "Ted Faber" , "Fernando Gont" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006052205; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230372E34343731464430442E303037312D412D; ENG=IBF; TS=20060522181412; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006052205_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 686F20F83NG19068395-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) 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: , Errors-To: tcpm-bounces@ietf.org =20 > -----Original Message----- > From: Ted Faber [mailto:faber@ISI.EDU] > I do have sympathy for the position that TCP should be=20 > ICMP-independent, using ICMP messages only as hints. PMTUD seems to=20 > be the big stumbling block in that perspective, and the sooner we have > ICMP-free PMTUD the happier I'll be. >=20 > However, there are two issues on the table here: >=20 > 1. Given the world in which we live, is the ICMP attacks draft > a reflection of group consensus yet? >=20 > 2. Should we also be writing a draft/taking a position on > ICMP-free TCP? Does that generalize? I am for (2) wherever that work happens to be done.=20 I can live with the draft as it is written provided that section 4.3 requiring ICMP payload parsing in firewalls gets removed as it has questionable value. Regarding BCP/Info vs Standards track, the draft is making recommendations to the way TCP treats errors based on the state that the connection is in, how can this be an informational draft? Bora _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon May 22 14:16:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiExA-000838-9b; Mon, 22 May 2006 14:16:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiEx9-00082s-4I for tcpm@ietf.org; Mon, 22 May 2006 14:16:27 -0400 Received: from mms2.broadcom.com ([216.31.210.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiEx7-0005CK-Pw for tcpm@ietf.org; Mon, 22 May 2006 14:16:27 -0400 Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Mon, 22 May 2006 11:16:15 -0700 X-Server-Uuid: D9EB6F12-1469-4C1C-87A2-5E4C0D6F9D06 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 055702AE; Mon, 22 May 2006 11:16:14 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id CABF62AE; Mon, 22 May 2006 11:16:14 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id DOW44508; Mon, 22 May 2006 11:16:13 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 6531E20501; Mon, 22 May 2006 11:16:13 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] Comments on draft-ietf-tcpm-icmp-attacks-00.txt Date: Mon, 22 May 2006 11:16:12 -0700 Message-ID: <03235919BBDE634289BB6A0758A20B365EB2FF@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [tcpm] Comments on draft-ietf-tcpm-icmp-attacks-00.txt Thread-Index: AcZ7zRXnCAUE5BGDR/u3A7XoCYdIQgB/nZeg From: "Bora Akyol" To: "Fernando Gont" , tcpm@ietf.org X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006052205; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230322E34343731464438392E303038362D412D; ENG=IBF; TS=20060522181615; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006052205_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 686F20654I814064191-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Fernando,=20 I don't think you put forth a single argument that can stand on its own as to why ICMP payload parsing in the firewalls is helping us in a significant way. I think you should at least add a paragraph to section 4.3 explaining what the value is and why we should do this. Regards, Bora =20 > -----Original Message----- > From: Fernando Gont [mailto:fernando@gont.com.ar]=20 > Sent: Friday, May 19, 2006 9:57 PM > To: Bora Akyol; tcpm@ietf.org > Subject: RE: [tcpm] Comments on draft-ietf-tcpm-icmp-attacks-00.txt >=20 > At 14:43 19/05/2006, Bora Akyol wrote: >=20 > >My point is that you assume that a firewall somewhere in the network=20 > >has the information to decide what packets can originate=20 > from where and=20 > >filter it. > > > >The benefit of implementing this feature is minimal IMHO at a=20 > >considerable complexity to hardware implementations. >=20 > Ingress/egress filtering of ICMP packets is included as=20 > additional countermeasures that could be implemented. >=20 > The real fix for each attack is right after the corresponding=20 > attack description. >=20 >=20 > >Can you also document how this works with mobile IP and=20 > other protocols > >that use > >a care of address (I believe some of the Wireless LAN tunneling does > >this too). >=20 > Do you mean how simple ingress/egress filtering works with=20 > mobile IP? ;-) >=20 > Well, in many cases it will probably be troublesome. >=20 > Kindest regards, >=20 > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 >=20 >=20 >=20 >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon May 22 14:49:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiFSX-0002do-07; Mon, 22 May 2006 14:48:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiFSW-0002de-0Y for tcpm@ietf.org; Mon, 22 May 2006 14:48:52 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiFSP-0006Ys-N3 for tcpm@ietf.org; Mon, 22 May 2006 14:48:51 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id LAA07602; Mon, 22 May 2006 11:48:21 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k4MImOr21235; Mon, 22 May 2006 11:48:24 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 May 2006 11:48:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] ICMP and TCP Date: Mon, 22 May 2006 11:48:18 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1818C44@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <03235919BBDE634289BB6A0758A20B365EB2FC@NT-SJCA-0751.brcm.ad.broadcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] ICMP and TCP Thread-Index: AcZ9vJsJNBtpezZ1TTiQbmFgxxtOAAADm1vQAADXbLA= From: "Templin, Fred L" To: "Bora Akyol" , "Ted Faber" , "Fernando Gont" X-OriginalArrivalTime: 22 May 2006 18:48:19.0448 (UTC) FILETIME=[4B2BF780:01C67DD0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org > Regarding BCP/Info vs Standards track, the draft is making recommendations > to the way TCP treats errors based on the state that the connection is in, > how can this be an informational draft? Assuming you are still referring to 'draft-ietf-tcpm-icmp-attacks', I checked the document for MUST/SHOULD/MAY and the only occurences are with direct reference to RFC1122, e.g., "The Host Requirements RFC [RFC1122] states that a TCP MUST...". The current state of affairs is that we have non-authenticated ICMPs which should be considered as advisory in certain situations and suspect in others. It seems like a BCP that clarifies those situations would be useful.=20 > I can live with the draft as it is written provided that > section 4.3 requiring ICMP payload parsing in firewalls gets removed > as it has questionable value. Not even as BCP? Fred fred.l.templin@boeing.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon May 22 15:55:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiGUE-0006R3-Vu; Mon, 22 May 2006 15:54:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiGUE-0006Qy-E6 for tcpm@ietf.org; Mon, 22 May 2006 15:54:42 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiGUA-0001JF-Lw for tcpm@ietf.org; Mon, 22 May 2006 15:54:42 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4MJqkB29567; Mon, 22 May 2006 12:52:46 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.6/8.13.6/Submit) id k4MJqj9k045894; Mon, 22 May 2006 12:52:45 -0700 (PDT) (envelope-from faber) Date: Mon, 22 May 2006 12:52:45 -0700 From: Ted Faber To: "Templin, Fred L" Subject: Re: [tcpm] ICMP and TCP Message-ID: <20060522195245.GG41441@hut.isi.edu> References: <03235919BBDE634289BB6A0758A20B365EB2FC@NT-SJCA-0751.brcm.ad.broadcom.com> <39C363776A4E8C4A94691D2BD9D1C9A1818C44@XCH-NW-7V2.nw.nos.boeing.com> Mime-Version: 1.0 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1818C44@XCH-NW-7V2.nw.nos.boeing.com> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: tcpm@ietf.org, Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1763079499==" Errors-To: tcpm-bounces@ietf.org --===============1763079499== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vk/v8fjDPiDepTtA" Content-Disposition: inline --vk/v8fjDPiDepTtA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 22, 2006 at 11:48:18AM -0700, Templin, Fred L wrote: > > Regarding BCP/Info vs Standards track, the draft is making > recommendations > > to the way TCP treats errors based on the state that the connection is > in, > > how can this be an informational draft? >=20 > Assuming you are still referring to 'draft-ietf-tcpm-icmp-attacks', > I checked the document for MUST/SHOULD/MAY and the only occurences > are with direct reference to RFC1122, e.g., "The Host Requirements > RFC [RFC1122] states that a TCP MUST...". >=20 > The current state of affairs is that we have non-authenticated > ICMPs which should be considered as advisory in certain situations > and suspect in others. It seems like a BCP that clarifies those > situations would be useful.=20 Hard to say it better than that. :-) I'd be happier if the document did have a paragraph that made exactly that point in the intro. There are a set of ICMP messages that SHOULD terminate a TCP connection, and this document is listing some ideas for determining when to go against that strong advice. Going against that SHOULD with good reason is certainly conformant behavior. >=20 > > I can live with the draft as it is written provided that > > section 4.3 requiring ICMP payload parsing in firewalls gets removed > > as it has questionable value. >=20 > Not even as BCP? IMHO, and I realize I'm not the one you asked, I'd like to see a little justification for the additional complexity. It seems to me like a fair amount of work for a fairly unlikely case (spoofed ICMP payload w/o a spoofed ICMP header). But I'm willing to be convinced.=20 If there are some implementations doing this by default, I'm curious about that, too. =20 With my chair hat off. --=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 --vk/v8fjDPiDepTtA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEchaNaUz3f+Zf+XsRAmHhAKD5l+1YII8xoJ3PUU7NdM4xp5/YHwCgrJZi XuF5Ln91Dx1G6QQckhU7wiI= =CK9V -----END PGP SIGNATURE----- --vk/v8fjDPiDepTtA-- --===============1763079499== 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 --===============1763079499==-- From tcpm-bounces@ietf.org Mon May 22 17:32:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiI0O-0007hP-FO; Mon, 22 May 2006 17:32:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiI0M-0007gl-Sz for tcpm@ietf.org; Mon, 22 May 2006 17:31:58 -0400 Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiI0L-0007UJ-H4 for tcpm@ietf.org; Mon, 22 May 2006 17:31:58 -0400 Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Mon, 22 May 2006 14:31:41 -0700 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 9A7B42B0; Mon, 22 May 2006 14:31:41 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 748202AE; Mon, 22 May 2006 14:31:41 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id DOX27829; Mon, 22 May 2006 14:31:38 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id B37AD20501; Mon, 22 May 2006 14:31:38 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] ICMP and TCP Date: Mon, 22 May 2006 14:31:37 -0700 Message-ID: <03235919BBDE634289BB6A0758A20B365EB365@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [tcpm] ICMP and TCP Thread-Index: AcZ92ZyugSDce7vVRrGmbvvAFI2GTAADM5kw From: "Bora Akyol" To: "Ted Faber" , "Templin, Fred L" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006052207; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230312E34343732324235422E303032442D412D; ENG=IBF; TS=20060522213144; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006052207_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 686CF2373NG19107517-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be 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: , Errors-To: tcpm-bounces@ietf.org Thanks for your replies. Please see comments in-line: > -----Original Message----- > From: Ted Faber [mailto:faber@ISI.EDU]=20 > Sent: Monday, May 22, 2006 12:53 PM > To: Templin, Fred L > Cc: Bora Akyol; Fernando Gont; tcpm@ietf.org > Subject: Re: [tcpm] ICMP and TCP >=20 > On Mon, May 22, 2006 at 11:48:18AM -0700, Templin, Fred L wrote: > > > Regarding BCP/Info vs Standards track, the draft is making > > recommendations > > > to the way TCP treats errors based on the state that the=20 > connection=20 > > > is > > in, > > > how can this be an informational draft? > >=20 > > Assuming you are still referring to=20 > 'draft-ietf-tcpm-icmp-attacks', I=20 > > checked the document for MUST/SHOULD/MAY and the only=20 > occurences are=20 > > with direct reference to RFC1122, e.g., "The Host Requirements RFC=20 > > [RFC1122] states that a TCP MUST...". > >=20 > > The current state of affairs is that we have=20 > non-authenticated ICMPs=20 > > which should be considered as advisory in certain situations and=20 > > suspect in others. It seems like a BCP that clarifies those=20 > situations=20 > > would be useful. >=20 > Hard to say it better than that. :-) >=20 > I'd be happier if the document did have a paragraph that made exactly > that point in the intro. There are a set of ICMP messages=20 > that SHOULD > terminate a TCP connection, and this document is listing some=20 > ideas for determining when to go against that strong advice. =20 > Going against that SHOULD with good reason is certainly=20 > conformant behavior. I did not say I disagree with what the draft recommends as far treatment of hard errors in certain states within TCP, what I am saying is that the draft recommends **modifications** to TCP implementation on how to deal with these and therefore it MUST NOT be left as an informational document. IMHO, it should be classified as standards track and should receive the scrutiny that a standards track document receives. For long term, I think handling all of the signaling (including PMTUD) without ICMP is the better way to go IMHO. > >=20 > > > I can live with the draft as it is written provided that=20 > section 4.3=20 > > > requiring ICMP payload parsing in firewalls gets removed=20 > as it has=20 > > > questionable value. > >=20 > > Not even as BCP? >=20 > IMHO, and I realize I'm not the one you asked, I'd like to=20 > see a little justification for the additional complexity. It=20 > seems to me like a fair amount of work for a fairly unlikely=20 > case (spoofed ICMP payload w/o a spoofed ICMP header). But=20 > I'm willing to be convinced.=20 >=20 > If there are some implementations doing this by default, I'm=20 > curious about that, too. =20 I could not have said this better. Things that seem simple enough when one is writing code for a 100 Mbps firewall seem to get a lot more difficult when one is designing hardware that can do that 100 Gbps or more. I would like to see more justification of this particular recommendation. Regards, Bora _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon May 22 22:22:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiMXD-0000JE-Cj; Mon, 22 May 2006 22:22:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiMXB-0000J9-8V for tcpm@ietf.org; Mon, 22 May 2006 22:22:09 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiMX7-0003b8-Rw for tcpm@ietf.org; Mon, 22 May 2006 22:22:09 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4N2KbB26631; Mon, 22 May 2006 19:20:37 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.6/8.13.6/Submit) id k4N2KalS051993; Mon, 22 May 2006 19:20:36 -0700 (PDT) (envelope-from faber) Date: Mon, 22 May 2006 19:20:36 -0700 From: Ted Faber To: Bora Akyol Subject: Re: [tcpm] ICMP and TCP Message-ID: <20060523022036.GI41441@hut.isi.edu> References: <03235919BBDE634289BB6A0758A20B365EB365@NT-SJCA-0751.brcm.ad.broadcom.com> Mime-Version: 1.0 In-Reply-To: <03235919BBDE634289BB6A0758A20B365EB365@NT-SJCA-0751.brcm.ad.broadcom.com> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: "Templin, Fred L" , tcpm@ietf.org, Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1789807019==" Errors-To: tcpm-bounces@ietf.org --===============1789807019== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KSyhVCl2eeZHT0Rn" Content-Disposition: inline --KSyhVCl2eeZHT0Rn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 22, 2006 at 02:31:37PM -0700, Bora Akyol wrote: > > From: Ted Faber [mailto:faber@ISI.EDU]=20 > > I'd be happier if the document did have a paragraph that made exactly > > that point in the intro. There are a set of ICMP messages=20 > > that SHOULD > > terminate a TCP connection, and this document is listing some=20 > > ideas for determining when to go against that strong advice. =20 > > Going against that SHOULD with good reason is certainly=20 > > conformant behavior. >=20 > I did not say I disagree with what the draft recommends as far > treatment of hard errors in certain states within TCP, what I am > saying is that the draft recommends **modifications** to TCP > implementation on how to deal with these and therefore it MUST NOT be > left as an informational document. IMHO, it should be classified as > standards track and should receive the scrutiny that a standards track > document receives. Ummm, I must have nodded off again. Too much multitasking, I guess. What change to TCP semantics are we discussing? I think the strongest thing that 1122 says about reacting to an ICMP is that the host SHOULD abort the connection. I'm pretty sure that this draft doesn't advocate being more strict than the SHOULD, and is only laying out criteria by which the SHOULD might be taken exception to. What am I missing? --=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 --KSyhVCl2eeZHT0Rn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEcnF0aUz3f+Zf+XsRAoUnAKCTncxhYrtK07Lx72Axiqc2PNI37QCfZhtd U/fOkolVDRacqh4aLEWxw6Y= =mNun -----END PGP SIGNATURE----- --KSyhVCl2eeZHT0Rn-- --===============1789807019== 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 --===============1789807019==-- From tcpm-bounces@ietf.org Tue May 23 01:01:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiP0f-0001ze-Qg; Tue, 23 May 2006 01:00:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiP0e-0001zZ-L8 for tcpm@ietf.org; Tue, 23 May 2006 01:00:44 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiP0c-0002KK-Sd for tcpm@ietf.org; Tue, 23 May 2006 01:00:44 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060308/8.12.11) with ESMTP id k4N50GGp022903; Tue, 23 May 2006 08:00:21 +0300 Date: Tue, 23 May 2006 08:00:16 +0300 (EEST) From: Pekka Savola To: Bora Akyol Subject: RE: [tcpm] Comments on draft-ietf-tcpm-icmp-attacks-00.txt In-Reply-To: <03235919BBDE634289BB6A0758A20B365EB2FF@NT-SJCA-0751.brcm.ad.broadcom.com> Message-ID: References: <03235919BBDE634289BB6A0758A20B365EB2FF@NT-SJCA-0751.brcm.ad.broadcom.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1478/Tue May 23 00:01:38 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: tcpm@ietf.org, Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Mon, 22 May 2006, Bora Akyol wrote: > I don't think you put forth a single argument that > can stand on its own as to why ICMP payload parsing > in the firewalls is helping us in a significant way. > > I think you should at least add a paragraph to section 4.3 > explaining what the value is and why we should do this. It *would* protect from external attackers reseting site-internal (or beyond the firewall at any point) sessions, similar to applying ingress filtering from the direction of the Internet does for TCP RST attacks. Whether that's significant or not is in the eye of the beholder... -- 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 May 23 02:03:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiPz6-0002lS-Q7; Tue, 23 May 2006 02:03:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiPz4-0002k5-UD for tcpm@ietf.org; Tue, 23 May 2006 02:03:10 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiPz3-0004vW-86 for tcpm@ietf.org; Tue, 23 May 2006 02:03:10 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4N634s3020197; Tue, 23 May 2006 03:03:05 -0300 Message-Id: <7.0.1.0.0.20060523015844.060fedd0@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 23 May 2006 02:03:35 -0300 To: Joe Touch From: Fernando Gont Subject: Re: [tcpm] Re: Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt In-Reply-To: <4470B3A1.7060709@isi.edu> References: <7.0.1.0.0.20060518035047.06d3d718@gont.com.ar> <446C83E6.4030901@isi.edu> <7.0.1.0.0.20060519013043.06a4ef68@gont.com.ar> <446D5A33.8020202@isi.edu> <7.0.1.0.0.20060519031314.06a79038@gont.com.ar> <446DF5A0.3040607@isi.edu> <446E0DDB.3040404@isi.edu> <7.0.1.0.0.20060520020629.06a886f8@gont.com.ar> <446EAD4C.8040202@isi.edu> <7.0.1.0.0.20060520031331.04df7568@gont.com.ar> <446F2901.7080309@isi.edu> <7.0.1.0.0.20060520235539.04b95370@gont.com.ar> <4470B3A1.7060709@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 15:38 21/05/2006, Joe Touch wrote: >>>If you don't trust ICMP, then block it altogether. >>Engineering is usually a trade-off, rather than a white or black thing. > >Agreed. Which is also a reason not to burn this decision into the >transport protocol. A separate filter can make the decisions you're >suggesting just fine. You can enable this explicitly if you want. Although nobody would do it. Most systems have been running with the proposed behaviour in place, with no way to enable it. >>I'm interested in having a robust network, while still knowing the >>cause of problems when something goes on. >>Namely, if my connections time out, I'd like to know why. > >Goes to intent. Sometimes you can't. Sometimes all you know is that >they went down. Exactly. That's the idea of changing the reaction, so that you keep the hint, without being vulnerable to attack. >... >>>Your other message want PMTUD to be reactive, so you want ICMP >>>signals there. Why would you allow attackers to alter your PMTU, >>>when you are so worried here? The same net effect results - >>>throughput can be set to effectively zero in either case. >>In order for an attacker to defeat the mechanism discussed in the >>ICMP attacks draft, he has to be a "man in the middle". At that >>point, he wouldn't bother to set a low MTU. > >Sure he would - to avoid your thinking he was there. To make you >think you weren't under a 'real' attack. If you are a MIM, you can fool the ICMP-less PMTUD, as you can drop packets. ;-) >>>(and yes, if it's *broken* w.r.t. the specs, we ought to recommend >>>fixing it; in the IETF, we're supposed to do what we thing needs >>>to be done first and let the implementations follow, not the other >>>way around. It's rough consensus and running code, not de-facto rubberstamps). >>If it takes us years to change the specs, I'm afraid it will be us >>following the implementations. > >You're not answering the question. The point is that the >implementations don't weigh into the decision on how to proceed here. As pointed out by Pekka, both the rough consensus and the implementations agree. (As a side note, FWIW, the stuff in RFC1122 about {netowork, subnet, 0} broadcast addresses seem to have been driven by implementations.) Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue May 23 02:03:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiPz6-0002ke-Dq; Tue, 23 May 2006 02:03:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiPz4-0002jv-RU for tcpm@ietf.org; Tue, 23 May 2006 02:03:10 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiPz3-0004vX-87 for tcpm@ietf.org; Tue, 23 May 2006 02:03:10 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4N634s7020197 for ; Tue, 23 May 2006 03:03:06 -0300 Message-Id: <7.0.1.0.0.20060523021302.060e2298@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 23 May 2006 02:23:19 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [tcpm] Next revision of the ICMP attacks draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Folks, I will be submitting a revision of the ICMP attacks draft next week. These are the changes I have in mind: * Update on the citation of the IPSec spec. * Address all feedback sent by Fred Templin * Add a paragraph on what the current state of affairs is, as suggested by Ted. * Add some words on the effectiveness of ingress/egress filtering based on the ICMP payload, as suggested by Bora Akyol * In the same section, replace the term "firewall" by "middle-boxes", as suggested by Pyda. * Will hopefully include references to firewall implementations that already perform this filtering. If there's any feedback I just missed, let me know. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue May 23 02:03:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiPz6-0002l3-JN; Tue, 23 May 2006 02:03:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiPz4-0002k0-T9 for tcpm@ietf.org; Tue, 23 May 2006 02:03:10 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiPz3-0004vb-87 for tcpm@ietf.org; Tue, 23 May 2006 02:03:10 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4N634sD020197; Tue, 23 May 2006 03:03:10 -0300 Message-Id: <7.0.1.0.0.20060523022349.06a27fc0@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 23 May 2006 02:29:32 -0300 To: Ted Faber , "Templin, Fred L" From: Fernando Gont Subject: Re: [tcpm] ICMP and TCP In-Reply-To: <20060522195245.GG41441@hut.isi.edu> References: <03235919BBDE634289BB6A0758A20B365EB2FC@NT-SJCA-0751.brcm.ad.broadcom.com> <39C363776A4E8C4A94691D2BD9D1C9A1818C44@XCH-NW-7V2.nw.nos.boeing.com> <20060522195245.GG41441@hut.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 16:52 22/05/2006, Ted Faber wrote: > > > I can live with the draft as it is written provided that > > > section 4.3 requiring ICMP payload parsing in firewalls gets removed > > > as it has questionable value. > > > > Not even as BCP? > >IMHO, and I realize I'm not the one you asked, I'd like to see a little >justification for the additional complexity. It seems to me like a fair >amount of work for a fairly unlikely case (spoofed ICMP payload w/o a >spoofed ICMP header). But I'm willing to be convinced. > >If there are some implementations doing this by default, I'm curious >about that, too. In all those cases the same box implements both NAT and firewall functionality, you have to translate the inner packet in order for it to have any effect. When a NAT receives an ICMP error message, it has to look up for state information for the inner packet, and modify that inner packet before forwarding the ICMP error message. In the case of pure-firewalling, I will dig into existing implementations. Last year, while talking with Linux guys, they said they were going to implement this. Don't not what they ended up doing, though. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue May 23 02:03:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiPz6-0002lr-W8; Tue, 23 May 2006 02:03:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiPz5-0002kZ-UZ for tcpm@ietf.org; Tue, 23 May 2006 02:03:11 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiPz4-0004vd-CJ for tcpm@ietf.org; Tue, 23 May 2006 02:03:11 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4N634sB020197; Tue, 23 May 2006 03:03:09 -0300 Message-Id: <7.0.1.0.0.20060523022202.06a304f8@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 23 May 2006 02:22:42 -0300 To: Ted Faber , Bora Akyol From: Fernando Gont Subject: Re: [tcpm] ICMP and TCP In-Reply-To: <20060523022036.GI41441@hut.isi.edu> References: <03235919BBDE634289BB6A0758A20B365EB365@NT-SJCA-0751.brcm.ad.broadcom.com> <20060523022036.GI41441@hut.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: "Templin, Fred L" , tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 23:20 22/05/2006, Ted Faber wrote: > > I did not say I disagree with what the draft recommends as far > > treatment of hard errors in certain states within TCP, what I am > > saying is that the draft recommends **modifications** to TCP > > implementation on how to deal with these and therefore it MUST NOT be > > left as an informational document. IMHO, it should be classified as > > standards track and should receive the scrutiny that a standards track > > document receives. > >Ummm, I must have nodded off again. Too much multitasking, I guess. > >What change to TCP semantics are we discussing? I think the strongest >thing that 1122 says about reacting to an ICMP is that the host SHOULD >abort the connection. I'm pretty sure that this draft doesn't advocate >being more strict than the SHOULD, and is only laying out criteria by >which the SHOULD might be taken exception to. That's exactly the case. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue May 23 02:03:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiPz5-0002kA-8U; Tue, 23 May 2006 02:03:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiPz4-0002jq-0I for tcpm@ietf.org; Tue, 23 May 2006 02:03:10 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiPz3-0004vY-86 for tcpm@ietf.org; Tue, 23 May 2006 02:03:09 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4N634s5020197; Tue, 23 May 2006 03:03:06 -0300 Message-Id: <7.0.1.0.0.20060523020921.0618fc28@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 23 May 2006 02:12:34 -0300 To: "Bora Akyol" , tcpm@ietf.org From: Fernando Gont Subject: RE: [tcpm] Comments on draft-ietf-tcpm-icmp-attacks-00.txt In-Reply-To: <03235919BBDE634289BB6A0758A20B365EB2FF@NT-SJCA-0751.brcm.a d.broadcom.com> References: <03235919BBDE634289BB6A0758A20B365EB2FF@NT-SJCA-0751.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 15:16 22/05/2006, Bora Akyol wrote: >I don't think you put forth a single argument that >can stand on its own as to why ICMP payload parsing >in the firewalls is helping us in a significant way. The draft never gets into "how significant" the help is. The effectiveness of both this filtering and egress filtering based on the source IP address of an IP datagram depends on the deployment level. You implement it in your firewall, and your users won't be able to perform ICMP-based attacks. Now, if the same box implements NAT functionality (as it is usual), then you will *need* to not only inspect the inner packet (the one contained in the ICMP payload), but also modify it, according to the state information you have for that instance of communication. If you don't inspect the inner packet, you won't know who you should forward the packet to. If you forward the ICMP error message without modifying the inner packet, the receiving host will simply drop it. >I think you should at least add a paragraph to section 4.3 >explaining what the value is and why we should do this. Okay. Will do. Does something like the above sound fine? Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue May 23 02:03:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiPz6-0002ke-Dq; Tue, 23 May 2006 02:03:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiPz4-0002jv-RU for tcpm@ietf.org; Tue, 23 May 2006 02:03:10 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiPz3-0004vX-87 for tcpm@ietf.org; Tue, 23 May 2006 02:03:10 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4N634s7020197 for ; Tue, 23 May 2006 03:03:06 -0300 Message-Id: <7.0.1.0.0.20060523021302.060e2298@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 23 May 2006 02:23:19 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [tcpm] Next revision of the ICMP attacks draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Folks, I will be submitting a revision of the ICMP attacks draft next week. These are the changes I have in mind: * Update on the citation of the IPSec spec. * Address all feedback sent by Fred Templin * Add a paragraph on what the current state of affairs is, as suggested by Ted. * Add some words on the effectiveness of ingress/egress filtering based on the ICMP payload, as suggested by Bora Akyol * In the same section, replace the term "firewall" by "middle-boxes", as suggested by Pyda. * Will hopefully include references to firewall implementations that already perform this filtering. If there's any feedback I just missed, let me know. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue May 23 02:03:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiPz6-0002l3-JN; Tue, 23 May 2006 02:03:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiPz4-0002k0-T9 for tcpm@ietf.org; Tue, 23 May 2006 02:03:10 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiPz3-0004vb-87 for tcpm@ietf.org; Tue, 23 May 2006 02:03:10 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4N634sD020197; Tue, 23 May 2006 03:03:10 -0300 Message-Id: <7.0.1.0.0.20060523022349.06a27fc0@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 23 May 2006 02:29:32 -0300 To: Ted Faber , "Templin, Fred L" From: Fernando Gont Subject: Re: [tcpm] ICMP and TCP In-Reply-To: <20060522195245.GG41441@hut.isi.edu> References: <03235919BBDE634289BB6A0758A20B365EB2FC@NT-SJCA-0751.brcm.ad.broadcom.com> <39C363776A4E8C4A94691D2BD9D1C9A1818C44@XCH-NW-7V2.nw.nos.boeing.com> <20060522195245.GG41441@hut.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 16:52 22/05/2006, Ted Faber wrote: > > > I can live with the draft as it is written provided that > > > section 4.3 requiring ICMP payload parsing in firewalls gets removed > > > as it has questionable value. > > > > Not even as BCP? > >IMHO, and I realize I'm not the one you asked, I'd like to see a little >justification for the additional complexity. It seems to me like a fair >amount of work for a fairly unlikely case (spoofed ICMP payload w/o a >spoofed ICMP header). But I'm willing to be convinced. > >If there are some implementations doing this by default, I'm curious >about that, too. In all those cases the same box implements both NAT and firewall functionality, you have to translate the inner packet in order for it to have any effect. When a NAT receives an ICMP error message, it has to look up for state information for the inner packet, and modify that inner packet before forwarding the ICMP error message. In the case of pure-firewalling, I will dig into existing implementations. Last year, while talking with Linux guys, they said they were going to implement this. Don't not what they ended up doing, though. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue May 23 02:03:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiPz6-0002lr-W8; Tue, 23 May 2006 02:03:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiPz5-0002kZ-UZ for tcpm@ietf.org; Tue, 23 May 2006 02:03:11 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiPz4-0004vd-CJ for tcpm@ietf.org; Tue, 23 May 2006 02:03:11 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4N634sB020197; Tue, 23 May 2006 03:03:09 -0300 Message-Id: <7.0.1.0.0.20060523022202.06a304f8@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 23 May 2006 02:22:42 -0300 To: Ted Faber , Bora Akyol From: Fernando Gont Subject: Re: [tcpm] ICMP and TCP In-Reply-To: <20060523022036.GI41441@hut.isi.edu> References: <03235919BBDE634289BB6A0758A20B365EB365@NT-SJCA-0751.brcm.ad.broadcom.com> <20060523022036.GI41441@hut.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: "Templin, Fred L" , tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 23:20 22/05/2006, Ted Faber wrote: > > I did not say I disagree with what the draft recommends as far > > treatment of hard errors in certain states within TCP, what I am > > saying is that the draft recommends **modifications** to TCP > > implementation on how to deal with these and therefore it MUST NOT be > > left as an informational document. IMHO, it should be classified as > > standards track and should receive the scrutiny that a standards track > > document receives. > >Ummm, I must have nodded off again. Too much multitasking, I guess. > >What change to TCP semantics are we discussing? I think the strongest >thing that 1122 says about reacting to an ICMP is that the host SHOULD >abort the connection. I'm pretty sure that this draft doesn't advocate >being more strict than the SHOULD, and is only laying out criteria by >which the SHOULD might be taken exception to. That's exactly the case. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue May 23 02:03:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiPz5-0002kA-8U; Tue, 23 May 2006 02:03:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiPz4-0002jq-0I for tcpm@ietf.org; Tue, 23 May 2006 02:03:10 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiPz3-0004vY-86 for tcpm@ietf.org; Tue, 23 May 2006 02:03:09 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4N634s5020197; Tue, 23 May 2006 03:03:06 -0300 Message-Id: <7.0.1.0.0.20060523020921.0618fc28@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 23 May 2006 02:12:34 -0300 To: "Bora Akyol" , tcpm@ietf.org From: Fernando Gont Subject: RE: [tcpm] Comments on draft-ietf-tcpm-icmp-attacks-00.txt In-Reply-To: <03235919BBDE634289BB6A0758A20B365EB2FF@NT-SJCA-0751.brcm.a d.broadcom.com> References: <03235919BBDE634289BB6A0758A20B365EB2FF@NT-SJCA-0751.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 15:16 22/05/2006, Bora Akyol wrote: >I don't think you put forth a single argument that >can stand on its own as to why ICMP payload parsing >in the firewalls is helping us in a significant way. The draft never gets into "how significant" the help is. The effectiveness of both this filtering and egress filtering based on the source IP address of an IP datagram depends on the deployment level. You implement it in your firewall, and your users won't be able to perform ICMP-based attacks. Now, if the same box implements NAT functionality (as it is usual), then you will *need* to not only inspect the inner packet (the one contained in the ICMP payload), but also modify it, according to the state information you have for that instance of communication. If you don't inspect the inner packet, you won't know who you should forward the packet to. If you forward the ICMP error message without modifying the inner packet, the receiving host will simply drop it. >I think you should at least add a paragraph to section 4.3 >explaining what the value is and why we should do this. Okay. Will do. Does something like the above sound fine? Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue May 23 02:03:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiPz6-0002ke-Dq; Tue, 23 May 2006 02:03:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiPz4-0002jv-RU for tcpm@ietf.org; Tue, 23 May 2006 02:03:10 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiPz3-0004vX-87 for tcpm@ietf.org; Tue, 23 May 2006 02:03:10 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4N634s7020197 for ; Tue, 23 May 2006 03:03:06 -0300 Message-Id: <7.0.1.0.0.20060523021302.060e2298@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 23 May 2006 02:23:19 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [tcpm] Next revision of the ICMP attacks draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Folks, I will be submitting a revision of the ICMP attacks draft next week. These are the changes I have in mind: * Update on the citation of the IPSec spec. * Address all feedback sent by Fred Templin * Add a paragraph on what the current state of affairs is, as suggested by Ted. * Add some words on the effectiveness of ingress/egress filtering based on the ICMP payload, as suggested by Bora Akyol * In the same section, replace the term "firewall" by "middle-boxes", as suggested by Pyda. * Will hopefully include references to firewall implementations that already perform this filtering. If there's any feedback I just missed, let me know. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue May 23 02:03:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiPz6-0002l3-JN; Tue, 23 May 2006 02:03:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiPz4-0002k0-T9 for tcpm@ietf.org; Tue, 23 May 2006 02:03:10 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiPz3-0004vb-87 for tcpm@ietf.org; Tue, 23 May 2006 02:03:10 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4N634sD020197; Tue, 23 May 2006 03:03:10 -0300 Message-Id: <7.0.1.0.0.20060523022349.06a27fc0@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 23 May 2006 02:29:32 -0300 To: Ted Faber , "Templin, Fred L" From: Fernando Gont Subject: Re: [tcpm] ICMP and TCP In-Reply-To: <20060522195245.GG41441@hut.isi.edu> References: <03235919BBDE634289BB6A0758A20B365EB2FC@NT-SJCA-0751.brcm.ad.broadcom.com> <39C363776A4E8C4A94691D2BD9D1C9A1818C44@XCH-NW-7V2.nw.nos.boeing.com> <20060522195245.GG41441@hut.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 16:52 22/05/2006, Ted Faber wrote: > > > I can live with the draft as it is written provided that > > > section 4.3 requiring ICMP payload parsing in firewalls gets removed > > > as it has questionable value. > > > > Not even as BCP? > >IMHO, and I realize I'm not the one you asked, I'd like to see a little >justification for the additional complexity. It seems to me like a fair >amount of work for a fairly unlikely case (spoofed ICMP payload w/o a >spoofed ICMP header). But I'm willing to be convinced. > >If there are some implementations doing this by default, I'm curious >about that, too. In all those cases the same box implements both NAT and firewall functionality, you have to translate the inner packet in order for it to have any effect. When a NAT receives an ICMP error message, it has to look up for state information for the inner packet, and modify that inner packet before forwarding the ICMP error message. In the case of pure-firewalling, I will dig into existing implementations. Last year, while talking with Linux guys, they said they were going to implement this. Don't not what they ended up doing, though. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue May 23 02:03:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiPz6-0002lr-W8; Tue, 23 May 2006 02:03:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiPz5-0002kZ-UZ for tcpm@ietf.org; Tue, 23 May 2006 02:03:11 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiPz4-0004vd-CJ for tcpm@ietf.org; Tue, 23 May 2006 02:03:11 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4N634sB020197; Tue, 23 May 2006 03:03:09 -0300 Message-Id: <7.0.1.0.0.20060523022202.06a304f8@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 23 May 2006 02:22:42 -0300 To: Ted Faber , Bora Akyol From: Fernando Gont Subject: Re: [tcpm] ICMP and TCP In-Reply-To: <20060523022036.GI41441@hut.isi.edu> References: <03235919BBDE634289BB6A0758A20B365EB365@NT-SJCA-0751.brcm.ad.broadcom.com> <20060523022036.GI41441@hut.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: "Templin, Fred L" , tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 23:20 22/05/2006, Ted Faber wrote: > > I did not say I disagree with what the draft recommends as far > > treatment of hard errors in certain states within TCP, what I am > > saying is that the draft recommends **modifications** to TCP > > implementation on how to deal with these and therefore it MUST NOT be > > left as an informational document. IMHO, it should be classified as > > standards track and should receive the scrutiny that a standards track > > document receives. > >Ummm, I must have nodded off again. Too much multitasking, I guess. > >What change to TCP semantics are we discussing? I think the strongest >thing that 1122 says about reacting to an ICMP is that the host SHOULD >abort the connection. I'm pretty sure that this draft doesn't advocate >being more strict than the SHOULD, and is only laying out criteria by >which the SHOULD might be taken exception to. That's exactly the case. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue May 23 02:03:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiPz5-0002kA-8U; Tue, 23 May 2006 02:03:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiPz4-0002jq-0I for tcpm@ietf.org; Tue, 23 May 2006 02:03:10 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiPz3-0004vY-86 for tcpm@ietf.org; Tue, 23 May 2006 02:03:09 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4N634s5020197; Tue, 23 May 2006 03:03:06 -0300 Message-Id: <7.0.1.0.0.20060523020921.0618fc28@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 23 May 2006 02:12:34 -0300 To: "Bora Akyol" , tcpm@ietf.org From: Fernando Gont Subject: RE: [tcpm] Comments on draft-ietf-tcpm-icmp-attacks-00.txt In-Reply-To: <03235919BBDE634289BB6A0758A20B365EB2FF@NT-SJCA-0751.brcm.a d.broadcom.com> References: <03235919BBDE634289BB6A0758A20B365EB2FF@NT-SJCA-0751.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 15:16 22/05/2006, Bora Akyol wrote: >I don't think you put forth a single argument that >can stand on its own as to why ICMP payload parsing >in the firewalls is helping us in a significant way. The draft never gets into "how significant" the help is. The effectiveness of both this filtering and egress filtering based on the source IP address of an IP datagram depends on the deployment level. You implement it in your firewall, and your users won't be able to perform ICMP-based attacks. Now, if the same box implements NAT functionality (as it is usual), then you will *need* to not only inspect the inner packet (the one contained in the ICMP payload), but also modify it, according to the state information you have for that instance of communication. If you don't inspect the inner packet, you won't know who you should forward the packet to. If you forward the ICMP error message without modifying the inner packet, the receiving host will simply drop it. >I think you should at least add a paragraph to section 4.3 >explaining what the value is and why we should do this. Okay. Will do. Does something like the above sound fine? Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue May 23 11:44:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiZ2q-00046l-U8; Tue, 23 May 2006 11:43:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiZ2p-00046g-Q1 for tcpm@ietf.org; Tue, 23 May 2006 11:43:39 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiZ2o-0005GO-Dp for tcpm@ietf.org; Tue, 23 May 2006 11:43:39 -0400 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4NFgjI23026; Tue, 23 May 2006 08:42:45 -0700 (PDT) Message-ID: <44732D73.4040803@isi.edu> Date: Tue, 23 May 2006 08:42:43 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] Next revision of the ICMP attacks draft References: <7.0.1.0.0.20060523021302.060e2298@gont.com.ar> In-Reply-To: <7.0.1.0.0.20060523021302.060e2298@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: e8a67952aa972b528dd04570d58ad8fe Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Fernando Gont wrote: > Folks, > > I will be submitting a revision of the ICMP attacks draft next week. > > These are the changes I have in mind: > > * Update on the citation of the IPSec spec. > > * Address all feedback sent by Fred Templin > > * Add a paragraph on what the current state of affairs is, as suggested > by Ted. The doc has two different components; one involves deeper inspection of the ICMP message, the other describes changes to how TCP handles hard errors based on its state. The latter should describe "what is implemented", and the extent to which it corresponds to existing spec. The doc should fall short of making recommendations that are intended to be interpreted as a change to spec, though. In particular: "or security reasons, it would be fair to treat ICMP port unreachable messages as soft errors (or completely ignore them) when they are meant for protocols that have their own mechanism for reporting this error condition." directly opposes RFC1122, which states specifically that (sec 3.2.2.1): "A transport protocol that has its own mechanism for notifying the sender that a port is unreachable (e.g., TCP, which sends RST segments) MUST nevertheless accept an ICMP Port Unreachable for the same purpose." IMO, the document needs a clear summary of where it diverges from RFC1122/792/etc. recommendations, and the conditions under which it would be appropriate to diverge (e.g., a threshold after which hard errors should be treated as soft, a switch for enabling that, etc.). The document also suggests that unexpected responses should be treated as attacks: "However, it would be strange to get such an error during the life of a connection, ... ...Thus, it would be fair to treat ICMP protocol unreachable error messages as soft errors (or completely ignore them" Again, if there were a switch that were enabled by seeing a large number of such ICMPs, or a number of ICMPs which have invalid contents, then this would be a reasonable reaction. In the absence of such, this is overly hostile to potentially valid network feedback. (I hope this is a way to move forward). Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue May 23 12:51:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fia5o-0003mW-1H; Tue, 23 May 2006 12:50:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fia5m-0003mR-Iv for tcpm@ietf.org; Tue, 23 May 2006 12:50:46 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fia5l-0007Y0-6i for tcpm@ietf.org; Tue, 23 May 2006 12:50:46 -0400 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4NGoAI11242; Tue, 23 May 2006 09:50:10 -0700 (PDT) Message-ID: <44733D40.3030901@isi.edu> Date: Tue, 23 May 2006 09:50:08 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Joe Touch Subject: Re: [tcpm] Next revision of the ICMP attacks draft References: <7.0.1.0.0.20060523021302.060e2298@gont.com.ar> <44732D73.4040803@isi.edu> In-Reply-To: <44732D73.4040803@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 4b800b1eab964a31702fa68f1ff0e955 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: , Errors-To: tcpm-bounces@ietf.org ... > In particular: > > "or security reasons, > it would be fair to treat ICMP port unreachable messages as soft > errors (or completely ignore them) when they are meant for > protocols that have their own mechanism for reporting this error > condition." > > directly opposes RFC1122, which states specifically that (sec 3.2.2.1): > > "A transport protocol > that has its own mechanism for notifying the sender that a > port is unreachable (e.g., TCP, which sends RST segments) > MUST nevertheless accept an ICMP Port Unreachable for the > same purpose." There is some ambiguity here; the paragraph RFC1122 states in total 3.2.2.1: A Destination Unreachable message that is received MUST be reported to the transport layer. The transport layer SHOULD use the information appropriately; for example, see Sections 4.1.3.3, 4.2.3.9, and 4.2.4 below. A transport protocol that has its own mechanism for notifying the sender that a port is unreachable (e.g., TCP, which sends RST segments) MUST nevertheless accept an ICMP Port Unreachable for the same purpose. (FYI - port unreachable is type 3, code 3) --- 4.1.3.3 discusses UDP 4.2.3.9 states that: o Destination Unreachable -- codes 2-4 These are hard error conditions, so TCP SHOULD abort the connection. 4.2.4 is about passing ICMP messages to the application. ------ 4.2.3.9 and 3.2.2.1 are somewhat contradictory. My interpretation of 3.2.2.1 is that: TCP MUST accept ICMP 3/3 for the same purpose as a TCP RST My interpretation of 4.2.3.9 is that, in being more general, it recommends a SHOULD for other ICMP error receipts, but that receiving a port unreachable is a hard error with a MUST. I plan on talking with Bob Braden today to find out what the motivation behind this particular text is; right now, I have a guess that it may have something to do with firewalls, which ought not spoof RSTs to indicate port unreachable, but rather should send ICMPs for the same purpose. I'll send a follow-up when I find out more. ------- Regardless, this document ought to be more specific about these sorts of interpretations, as well as the specific places in 1122/792/etc where such issues are divergent. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue May 23 14:00:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FibBL-0007pc-GQ; Tue, 23 May 2006 14:00:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FibBK-0007pX-ET for tcpm@ietf.org; Tue, 23 May 2006 14:00:34 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FibBJ-0002tQ-27 for tcpm@ietf.org; Tue, 23 May 2006 14:00:34 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4NHxLR14134; Tue, 23 May 2006 10:59:21 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.6/8.13.6/Submit) id k4NHxKeG071502; Tue, 23 May 2006 10:59:20 -0700 (PDT) (envelope-from faber) Date: Tue, 23 May 2006 10:59:20 -0700 From: Ted Faber To: Fernando Gont Subject: Re: [tcpm] ICMP and TCP Message-ID: <20060523175920.GB69193@hut.isi.edu> References: <03235919BBDE634289BB6A0758A20B365EB365@NT-SJCA-0751.brcm.ad.broadcom.com> <20060523022036.GI41441@hut.isi.edu> <7.0.1.0.0.20060523022202.06a304f8@gont.com.ar> Mime-Version: 1.0 In-Reply-To: <7.0.1.0.0.20060523022202.06a304f8@gont.com.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@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: "Templin, Fred L" , 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="===============1373008695==" Errors-To: tcpm-bounces@ietf.org --===============1373008695== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lc9FT7cWel8HagAv" Content-Disposition: inline --lc9FT7cWel8HagAv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 23, 2006 at 02:22:42AM -0300, Fernando Gont wrote: > At 23:20 22/05/2006, Ted Faber wrote: >=20 > >> I did not say I disagree with what the draft recommends as far > >> treatment of hard errors in certain states within TCP, what I am > >> saying is that the draft recommends **modifications** to TCP > >> implementation on how to deal with these and therefore it MUST NOT be > >> left as an informational document. IMHO, it should be classified as > >> standards track and should receive the scrutiny that a standards track > >> document receives. > > > >Ummm, I must have nodded off again. Too much multitasking, I guess. > > > >What change to TCP semantics are we discussing? I think the strongest > >thing that 1122 says about reacting to an ICMP is that the host SHOULD > >abort the connection. I'm pretty sure that this draft doesn't advocate > >being more strict than the SHOULD, and is only laying out criteria by > >which the SHOULD might be taken exception to. >=20 > That's exactly the case. I really think that the draft should state that right in the intro, since we seem to have to have this discussion every time the draft is discussed. It'll be much nicer when I can say "read the intro" rather than typing out that paragraph every time. Don't be shy about it. There's a SHOULD in 1122 and this draft suggests criteria for taking exception to that SHOULD. Point the SHOULD section of 1122 right out. --=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 --lc9FT7cWel8HagAv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEc014aUz3f+Zf+XsRAlbpAJ9+vxKvMNlxRVBWrWXiEpVHtu626QCfVwDK awPIE02+6H70aCNOADVHTOc= =/P5a -----END PGP SIGNATURE----- --lc9FT7cWel8HagAv-- --===============1373008695== 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 --===============1373008695==-- From tcpm-bounces@ietf.org Tue May 23 16:00:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fid3H-0002An-H9; Tue, 23 May 2006 16:00:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fid3G-0002Ad-Qc for tcpm@ietf.org; Tue, 23 May 2006 16:00:22 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fid3F-0000na-2N for tcpm@ietf.org; Tue, 23 May 2006 16:00:22 -0400 Received: from fgont.gont.com.ar ([200.70.144.192]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4NK0AZ2028646; Tue, 23 May 2006 17:00:20 -0300 Message-Id: <7.0.1.0.0.20060523154059.05176638@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 23 May 2006 16:23:27 -0300 To: Joe Touch , Joe Touch From: Fernando Gont Subject: Re: [tcpm] Next revision of the ICMP attacks draft In-Reply-To: <44733D40.3030901@isi.edu> References: <7.0.1.0.0.20060523021302.060e2298@gont.com.ar> <44732D73.4040803@isi.edu> <44733D40.3030901@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 13:50 23/05/2006, Joe Touch wrote: [Great work citing RFC1122, btw] >4.2.3.9 and 3.2.2.1 are somewhat contradictory. My interpretation of >3.2.2.1 is that: > > TCP MUST accept ICMP 3/3 for the same purpose as a TCP RST > >My interpretation of 4.2.3.9 is that, in being more general, it >recommends a SHOULD for other ICMP error receipts, but that >receiving a port unreachable is a hard error with a MUST. > >I plan on talking with Bob Braden today to find out what the >motivation behind this particular text is; right now, I have a guess >that it may have something to do with firewalls, which ought not >spoof RSTs to indicate port unreachable, but rather should send >ICMPs for the same purpose. I'll send a follow-up when I find out more. I recall at some point asking somebody (probably not Braden) on this issue. The answer I had got was that years and years ago there was some stack that rejected connections (say to a port on which there was no process listening) with a port unreachable rather than RST (as it should have). RFC1122 then tried to accommodate that/those stack/s. As I mentioned in some other e-mail, there's other stuff in RFC1122 which makes it clear that that RFC 1122 contains some text to accommodate what some (non-conformant, but yet popular) stacks were doing. >Regardless, this document ought to be more specific about these >sorts of interpretations, as well as the specific places in >1122/792/etc where such issues are divergent. I'd say that the only place in which the existing specs are violated is in the case of port unreachables. Now, The RFC attacks draft talk about treating the hard errors as soft errors for connections in the synchronized states. In the general case, the firewall will block a connection-establishment attempt, rather than accepting a connection and "resetting" it at some point later (yes, that *may* happen, though). But in the case of a connection request being rejected, the host that perform the active open will honor the ICMP unreachable, as the connection is in a non-synchronized state. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue May 23 16:00:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fid3I-0002BI-NF; Tue, 23 May 2006 16:00:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fid3H-0002As-UF for tcpm@ietf.org; Tue, 23 May 2006 16:00:23 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fid3G-0000nf-Bk for tcpm@ietf.org; Tue, 23 May 2006 16:00:23 -0400 Received: from fgont.gont.com.ar ([200.70.144.192]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4NK0AZ4028646; Tue, 23 May 2006 17:00:23 -0300 Message-Id: <7.0.1.0.0.20060523143647.04c227c8@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 23 May 2006 16:31:13 -0300 To: Joe Touch From: Fernando Gont Subject: Re: [tcpm] Next revision of the ICMP attacks draft In-Reply-To: <44732D73.4040803@isi.edu> References: <7.0.1.0.0.20060523021302.060e2298@gont.com.ar> <44732D73.4040803@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 12:42 23/05/2006, Joe Touch wrote: >The doc has two different components; one involves deeper inspection >of the ICMP message, the other describes changes to how TCP handles >hard errors based on its state. > >The latter should describe "what is implemented", and the extent to >which it corresponds to existing spec. The doc should fall short of >making recommendations that are intended to be interpreted as a >change to spec, though. Well, being that the document is meant for BCP/informational, the document explains what is supposed to be best currently. The document is not standards track, and has no words in caps. >directly opposes RFC1122, which states specifically that (sec 3.2.2.1): > > "A transport protocol > that has its own mechanism for notifying the sender that a > port is unreachable (e.g., TCP, which sends RST segments) > MUST nevertheless accept an ICMP Port Unreachable for the > same purpose." > >IMO, the document needs a clear summary of where it diverges from >RFC1122/792/etc. recommendations, and the conditions under which it >would be appropriate to diverge (e.g., a threshold after which hard >errors should be treated as soft, a switch for enabling that, etc.). Joe, I understand your point, but this would be something different from what we got consensus on. >The document also suggests that unexpected responses should be >treated as attacks: > > "However, it would be strange to > get such an error during the life of a connection, ... > ...Thus, it would be fair to treat ICMP > protocol unreachable error messages as soft errors (or completely > ignore them" What I meant by this text is that is not common to receive those messages during synchronized states. They are the exception, rather than the rule. >Again, if there were a switch that were enabled by seeing a large >number of such ICMPs, or a number of ICMPs which have invalid >contents, then this would be a reasonable reaction. In the absence >of such, this is overly hostile to potentially valid network feedback. You need just a single packet to tear down a connection. Reacting after that, i.e., turning hard errors -> soft errors, wouldn't make much sense: the attack has already succeeded. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue May 23 16:13:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FidGB-0006O9-4r; Tue, 23 May 2006 16:13:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FidG9-0006N8-Pl for tcpm@ietf.org; Tue, 23 May 2006 16:13:42 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FidG8-0001ZA-8U for tcpm@ietf.org; Tue, 23 May 2006 16:13:41 -0400 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4NKD9I07906; Tue, 23 May 2006 13:13:09 -0700 (PDT) Message-ID: <44736CD3.5030007@isi.edu> Date: Tue, 23 May 2006 13:13:07 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] Next revision of the ICMP attacks draft References: <7.0.1.0.0.20060523021302.060e2298@gont.com.ar> <44732D73.4040803@isi.edu> <44733D40.3030901@isi.edu> <7.0.1.0.0.20060523154059.05176638@gont.com.ar> In-Reply-To: <7.0.1.0.0.20060523154059.05176638@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 244a2fd369eaf00ce6820a760a3de2e8 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Fernando Gont wrote: > At 13:50 23/05/2006, Joe Touch wrote: > > [Great work citing RFC1122, btw] > >> 4.2.3.9 and 3.2.2.1 are somewhat contradictory. My interpretation of >> 3.2.2.1 is that: >> >> TCP MUST accept ICMP 3/3 for the same purpose as a TCP RST >> >> My interpretation of 4.2.3.9 is that, in being more general, it >> recommends a SHOULD for other ICMP error receipts, but that receiving >> a port unreachable is a hard error with a MUST. >> >> I plan on talking with Bob Braden today to find out what the >> motivation behind this particular text is; right now, I have a guess >> that it may have something to do with firewalls, which ought not spoof >> RSTs to indicate port unreachable, but rather should send ICMPs for >> the same purpose. I'll send a follow-up when I find out more. > > I recall at some point asking somebody (probably not Braden) on this > issue. The answer I had got was that years and years ago there was some > stack that rejected connections (say to a port on which there was no > process listening) with a port unreachable rather than RST (as it should > have). RFC1122 then tried to accommodate that/those stack/s. I asked Bob. He hinted it had more to do with a non-TCP answer to TCP's not being there on a port was appropriate for layering reasons, and should have the same effect as RST. > As I mentioned in some other e-mail, there's other stuff in RFC1122 > which makes it clear that that RFC 1122 contains some text to > accommodate what some (non-conformant, but yet popular) stacks were doing. Agreed. That's what "SHOULDs" would be there for, though - not MUSTs. >> Regardless, this document ought to be more specific about these sorts >> of interpretations, as well as the specific places in 1122/792/etc >> where such issues are divergent. > > I'd say that the only place in which the existing specs are violated is > in the case of port unreachables. That depends on what "SHOULD" means. When I asked Bob, he said it means "REALLY SHOULD". It's short of MUST in terms of conformance, but not intent. > Now, > > The RFC attacks draft talk about treating the hard errors as soft errors > for connections in the synchronized states. In the general case, the > firewall will block a connection-establishment attempt, rather than > accepting a connection and "resetting" it at some point later (yes, that > *may* happen, though). But in the case of a connection request being > rejected, the host that perform the active open will honor the ICMP > unreachable, as the connection is in a non-synchronized state. When you deploy a firewall or change its rules while it is deployed, these sorts of errors are legitimate and appropriate. Not everything you don't expect is an attack. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue May 23 17:57:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fies1-0001oJ-3j; Tue, 23 May 2006 17:56:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fierz-0001j7-Tv for tcpm@ietf.org; Tue, 23 May 2006 17:56:51 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fidjm-0002yJ-Q4 for tcpm@ietf.org; Tue, 23 May 2006 16:44:18 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FidLr-0002xT-Lu for tcpm@ietf.org; Tue, 23 May 2006 16:19:36 -0400 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4NKJ9I09479; Tue, 23 May 2006 13:19:09 -0700 (PDT) Message-ID: <44736E3C.2060707@isi.edu> Date: Tue, 23 May 2006 13:19:08 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] Next revision of the ICMP attacks draft References: <7.0.1.0.0.20060523021302.060e2298@gont.com.ar> <44732D73.4040803@isi.edu> <7.0.1.0.0.20060523143647.04c227c8@gont.com.ar> In-Reply-To: <7.0.1.0.0.20060523143647.04c227c8@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: -1.5 (-) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Fernando Gont wrote: > At 12:42 23/05/2006, Joe Touch wrote: > >> The doc has two different components; one involves deeper inspection >> of the ICMP message, the other describes changes to how TCP handles >> hard errors based on its state. >> >> The latter should describe "what is implemented", and the extent to >> which it corresponds to existing spec. The doc should fall short of >> making recommendations that are intended to be interpreted as a change >> to spec, though. > > Well, being that the document is meant for BCP/informational, the > document explains what is supposed to be best currently. The document is > not standards track, and has no words in caps. There's a big difference between BCP and informational. BCP is intended as advice to designers on what they should do, not just what has been done. If this doc is just about 'what is', it ought to be informational. >> directly opposes RFC1122, which states specifically that (sec 3.2.2.1): >> >> "A transport protocol >> that has its own mechanism for notifying the sender that a >> port is unreachable (e.g., TCP, which sends RST segments) >> MUST nevertheless accept an ICMP Port Unreachable for the >> same purpose." >> >> IMO, the document needs a clear summary of where it diverges from >> RFC1122/792/etc. recommendations, and the conditions under which it >> would be appropriate to diverge (e.g., a threshold after which hard >> errors should be treated as soft, a switch for enabling that, etc.). > > Joe, I understand your point, but this would be something different from > what we got consensus on. I didn't see consensus to have an obfuscated doc ;-) First, it'd be appropriate to describe what IS in terms of current implementations as well as noting clearly where it diverges from spec. It is also appropriate to consider that one alternative to "everything I don't expect is an attack" is "when I see other clues that I'm under attack, then change behavior". This latter part goes to the extent to which this doc makes recommendations to new implementers. If that's not part of this doc, then it isn't needed. But if it is, the design tradeoff of assuming everything is an attack - and an alternative that doesn't do that - should, IMO, be noted. >> The document also suggests that unexpected responses should be treated >> as attacks: >> >> "However, it would be strange to >> get such an error during the life of a connection, ... >> ...Thus, it would be fair to treat ICMP >> protocol unreachable error messages as soft errors (or completely >> ignore them" > > What I meant by this text is that is not common to receive those > messages during synchronized states. They are the exception, rather than > the rule. Exception != attack, though. >> Again, if there were a switch that were enabled by seeing a large >> number of such ICMPs, or a number of ICMPs which have invalid >> contents, then this would be a reasonable reaction. In the absence of >> such, this is overly hostile to potentially valid network feedback. > > You need just a single packet to tear down a connection. Reacting after > that, i.e., turning hard errors -> soft errors, wouldn't make much > sense: the attack has already succeeded. If you got a bunch of invalid ICMPs, you would not have let them tear anything down, but at that point you might want to change hard errors to soft during connections. If you get a bunch of attacks during connections, changing hard to soft makes it easier to keep new connections up, and is also a reasonable response to attack, even if some of the effects of that attack have already succeeded. The goal - IMO - isn't protection from every packet that might have been an attack, but a reasonable response to attacks that recovers. Innocent until proven guilty, so to speak. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue May 23 19:28:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FigHw-0000nW-B1; Tue, 23 May 2006 19:27:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FigHv-0000nR-Jb for tcpm@ietf.org; Tue, 23 May 2006 19:27:43 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FigHr-0002Ge-JI for tcpm@ietf.org; Tue, 23 May 2006 19:27:43 -0400 Received: from fgont.gont.com.ar ([200.70.178.228]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4NNRW4V025698; Tue, 23 May 2006 20:27:38 -0300 Message-Id: <7.0.1.0.0.20060523200012.044e0778@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 23 May 2006 20:02:21 -0300 To: Ted Faber From: Fernando Gont Subject: Re: [tcpm] ICMP and TCP In-Reply-To: <20060523175920.GB69193@hut.isi.edu> References: <03235919BBDE634289BB6A0758A20B365EB365@NT-SJCA-0751.brcm.ad.broadcom.com> <20060523022036.GI41441@hut.isi.edu> <7.0.1.0.0.20060523022202.06a304f8@gont.com.ar> <20060523175920.GB69193@hut.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: "Templin, Fred L" , tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 14:59 23/05/2006, Ted Faber wrote: > > >What change to TCP semantics are we discussing? I think the strongest > > >thing that 1122 says about reacting to an ICMP is that the host SHOULD > > >abort the connection. I'm pretty sure that this draft doesn't advocate > > >being more strict than the SHOULD, and is only laying out criteria by > > >which the SHOULD might be taken exception to. > > > > That's exactly the case. > >I really think that the draft should state that right in the intro, >since we seem to have to have this discussion every time the draft is >discussed. It'll be much nicer when I can say "read the intro" rather >than typing out that paragraph every time. > >Don't be shy about it. There's a SHOULD in 1122 and this draft suggests >criteria for taking exception to that SHOULD. Point the SHOULD section >of 1122 right out. That is one of the changes that I will made in the draft. (Although, IMO, confusion has raised among the ones that have been discussing the draft since version draft-gont -00 ;-)) Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue May 23 19:28:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FigHy-0000oe-Q4; Tue, 23 May 2006 19:27:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FigHy-0000oP-3K for tcpm@ietf.org; Tue, 23 May 2006 19:27:46 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FigHw-0002Gh-I3 for tcpm@ietf.org; Tue, 23 May 2006 19:27:46 -0400 Received: from fgont.gont.com.ar ([200.70.178.228]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4NNRW4Z025698; Tue, 23 May 2006 20:27:43 -0300 Message-Id: <7.0.1.0.0.20060523201036.05174fd8@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 23 May 2006 20:14:35 -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: 7655788c23eb79e336f5f8ba8bce7906 Cc: tcpm-chairs@tools.ietf.org Subject: [tcpm] Clarification on feedback on draft-ietf-tcpm-tcp-antispoof-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Folks, My point on section 4 ("ICMP") of the document is that only one of all the counter-measures of the ICMP attacks draft is discussed. Being that the ICMP attacks draft is a WG item, that the WG got rough consensus on, I don't think all the other (and main!) counter-measures should be excluded from the discussion. If anything, there should be consensus not to discuss them in the antispoof draft. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue May 23 19:28:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FigHx-0000o0-GE; Tue, 23 May 2006 19:27:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FigHw-0000nb-H6 for tcpm@ietf.org; Tue, 23 May 2006 19:27:44 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FigHq-0002Gc-T6 for tcpm@ietf.org; Tue, 23 May 2006 19:27:44 -0400 Received: from fgont.gont.com.ar ([200.70.178.228]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4NNRW4T025698; Tue, 23 May 2006 20:27:34 -0300 Message-Id: <7.0.1.0.0.20060523193434.044e0458@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 23 May 2006 19:59:37 -0300 To: Joe Touch From: Fernando Gont Subject: Re: [tcpm] Next revision of the ICMP attacks draft In-Reply-To: <44736E3C.2060707@isi.edu> References: <7.0.1.0.0.20060523021302.060e2298@gont.com.ar> <44732D73.4040803@isi.edu> <7.0.1.0.0.20060523143647.04c227c8@gont.com.ar> <44736E3C.2060707@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: tcpm-chairs@tools.ietf.org, tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 17:19 23/05/2006, Joe Touch wrote: >>>The doc has two different components; one involves deeper >>>inspection of the ICMP message, the other describes changes to how >>>TCP handles hard errors based on its state. >>> >>>The latter should describe "what is implemented", and the extent >>>to which it corresponds to existing spec. The doc should fall >>>short of making recommendations that are intended to be >>>interpreted as a change to spec, though. >>Well, being that the document is meant for BCP/informational, the >>document explains what is supposed to be best currently. The >>document is not standards track, and has no words in caps. > >There's a big difference between BCP and informational. BCP is >intended as advice to designers on what they should do, not just >what has been done. If this doc is just about 'what is', it ought to >be informational. This document is about what is the best current practice to deal with ICMP-based attacks. >>Joe, I understand your point, but this would be something different >>from what we got consensus on. > >I didn't see consensus to have an obfuscated doc ;-) Joe, let me make my point clear. If you make a comment that is meant to improve the draft the WG has agreed to work on, I will try to address it. No there's something you don't like about the draft, or you don't like the draft at all, I will probably not be able to address it at all. In the last couple of days you re-raised the discussion on soft/hard errors, almost hinted to introduce a switch (which would probably lead to a discussion on "what it should default to", and now we are "making science" around which the WG already had consensus on. >If you get a bunch of attacks during connections, changing hard to >soft makes it easier to keep new connections up, and is also a >reasonable response to attack, even if some of the effects of that >attack have already succeeded. > >The goal - IMO - isn't protection from every packet that might have >been an attack, but a reasonable response to attacks that recovers. >Innocent until proven guilty, so to speak. Yeah, use telnet, until you realize somebody is sniffing your connections. Then switch to ssh. That saves you from all the performance drawbacks of ssh, but keeps secure new connections that recover. (There is a long list of analogies that could be made... many of them even more funny, but...) The point is that I don't agree with that point of view at all. "It is best to assume that the network is filled with malevolent entities that will send packets designed to have the worst possible effect. This assumption will lead to suitably protective design." We won't be taken seriously if we ask implementors to implement a rather complex machinery that, until they get hacked once or a few times, will protect them from being hacked again for some period of time. Particularly when the solution to protect TCP from ICMP-based attacks is completely straightforward, and that's what most implementations have been doing for fifteen years or so. As a matter of fact, I'm spending more cycles in having people participate in the discussions, and provide feedback for "submitting new reviews". For some reason, you tend to take the discussion to the point we were in more than half an year ago. Most likely, if I were not the author of the draft, I wouldn't participate myself. The draft has been in a steady state for quite a long time. Probably since version -03 of draft-gont. Most of the stuff that was added in the revisions was stuff that I really thought is was needed. But it didn't hurt, so I granted it. The feedback I got even from people that had never provided feedback before have been mostly (if not completely) editorial. Minor tweaks. I am going to address the comments listed in the e-mail I sent to the list. Those are the comments that try to move forward the current draft, by improving it. I thank you for the effort you have put in making each version of the draft a better one, and even your last comments on the update of the reference to the IPSec standard. But adding switches to select the behaviour, heuristics to decide when to change the reaction to hard errors, etc., is, IMO, not what the WG agreed on, and, IMHO, something that adds unnecessary complexity, unnecessary pages and unnecessary discussion. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue May 23 23:58:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FikVZ-00009B-Ak; Tue, 23 May 2006 23:58:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FikVY-000096-Lj for tcpm@ietf.org; Tue, 23 May 2006 23:58:04 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FikVX-0005hS-Ae for tcpm@ietf.org; Tue, 23 May 2006 23:58:04 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4O3ucI23544; Tue, 23 May 2006 20:56:38 -0700 (PDT) Message-ID: <4473D96F.8050708@isi.edu> Date: Tue, 23 May 2006 20:56:31 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] Next revision of the ICMP attacks draft References: <7.0.1.0.0.20060523021302.060e2298@gont.com.ar> <44732D73.4040803@isi.edu> <7.0.1.0.0.20060523143647.04c227c8@gont.com.ar> <44736E3C.2060707@isi.edu> <7.0.1.0.0.20060523193434.044e0458@gont.com.ar> In-Reply-To: <7.0.1.0.0.20060523193434.044e0458@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: tcpm-chairs@tools.ietf.org, tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Fernando Gont wrote: .... > "It is best to assume that the network is filled with malevolent > entities that will send packets > designed to have the worst possible effect. This assumption will lead to > suitably protective design." "Be liberal in what you accept, and conservative in what you send" There is a large difference between documenting what is - and weighing the implications of that - with accepting what is implemented and recommending it for the future without substantial detail. I heard the WG agree to the former, not the latter; the chairs can clarify. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed May 24 00:05:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fikcw-0003Ay-Gi; Wed, 24 May 2006 00:05:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fikcv-0003Aq-AG for tcpm@ietf.org; Wed, 24 May 2006 00:05:41 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fikct-00063S-VF for tcpm@ietf.org; Wed, 24 May 2006 00:05:41 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4O44tI25535; Tue, 23 May 2006 21:04:55 -0700 (PDT) Message-ID: <4473DB60.3080602@isi.edu> Date: Tue, 23 May 2006 21:04:48 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] Clarification on feedback on draft-ietf-tcpm-tcp-antispoof-04.txt References: <7.0.1.0.0.20060523201036.05174fd8@gont.com.ar> In-Reply-To: <7.0.1.0.0.20060523201036.05174fd8@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 9466e0365fc95844abaf7c3f15a05c7d Cc: tcpm-chairs@tools.ietf.org, tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Fernando Gont wrote: > Folks, > > My point on section 4 ("ICMP") of the document is that only one of all > the counter-measures of the ICMP attacks draft is discussed. I've already noted that I would add a comment that there are other measures under development. > Being that the ICMP attacks draft is a WG item, that the WG got rough > consensus on, I don't think all the other (and main!) counter-measures > should be excluded from the discussion. The point of the document is not the countermeasures; it is that ICMP is not addressed by the techniques discussed, and that the primary (and still primary) method to deal with ICMP attacks is to drop all ICMP packets. I stand by that conclusion, and have heard nothing to refute it. > If anything, there should be consensus not to discuss them in the > antispoof draft. There was already consensus that they were added. I'd be glad to remove the section if there is consensus; IMO, it's premature to recommend in this document something that the WG has not agreed to recommend in another (documenting existing practice != recommend). Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed May 24 09:10:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fit86-0001Oj-Co; Wed, 24 May 2006 09:10:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fit84-0001Od-L6 for tcpm@ietf.org; Wed, 24 May 2006 09:10:24 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fit83-0006AR-6A for tcpm@ietf.org; Wed, 24 May 2006 09:10:24 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4OD3vS4006331; Wed, 24 May 2006 16:04:01 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 May 2006 16:03:53 +0300 Received: from siddha.research.nokia.com ([172.21.50.145]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 24 May 2006 16:03:53 +0300 Subject: Re: [tcpm] Can we advance F-RTO from Experimental? From: Pasi Sarolahti To: ext William Gilliam In-Reply-To: <72ac70ec93cffc1f6c5af924a9cbb0af@cup.hp.com> References: <72ac70ec93cffc1f6c5af924a9cbb0af@cup.hp.com> Organization: Nokia Research Center Date: Wed, 24 May 2006 16:03:52 +0300 Message-Id: <1148475832.30602.20.camel@siddha.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) X-OriginalArrivalTime: 24 May 2006 13:03:53.0800 (UTC) FILETIME=[824FD480:01C67F32] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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="===============1474780620==" Errors-To: tcpm-bounces@ietf.org --===============1474780620== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-xKnEjDX/npdqcjQWQml4" --=-xKnEjDX/npdqcjQWQml4 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2006-05-12 at 11:22 -0700, ext William Gilliam wrote: > At the Vancouver (IETF 64) meeting, during the discussion about possibly > advancing some RFCs, I suggested that it may be time to consider moving > F-RTO (RFC 4138) from Experimental to Standards-Track. I'd now like to > pass this suggestion on to the folks on the mailing-list. Moving F-RTO to PS would be ok for us, so if the WG decides that is the way to go, we are ready to use cycles for it. We are not aware of any significant issues with F-RTO, so it shouldn't take much effort on the editorial side. Of course any implementor feedback would be useful, for example regarding any possible unclear spots in the document. > Have there been any reports of F-RTO hurting the network? Personally, I > haven't heard any, but I'd be interested in hearing whatever relevant > reports are available. Same here. Also, if someone knows scenarios where use of F-RTO is particularly disadvantageous for the sender, we'd be interested to know. Thanks! - Pasi & Markku --=-xKnEjDX/npdqcjQWQml4 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBEdFm4oNa7NH1G2csRAsj1AJ9H9q8cXz0pPAXvIiTsdJIoOQvjqQCg0HiU yWxJ68PIOE89WctYbf8ws48= =uNXd -----END PGP SIGNATURE----- --=-xKnEjDX/npdqcjQWQml4-- --===============1474780620== 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 --===============1474780620==-- From tcpm-bounces@ietf.org Fri May 26 12:56:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjfbA-0003MR-MT; Fri, 26 May 2006 12:55:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjfb8-00032T-I3 for tcpm@ietf.org; Fri, 26 May 2006 12:55:38 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjfb7-0000Dq-6X for tcpm@ietf.org; Fri, 26 May 2006 12:55:38 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4QGt5R13421 for ; Fri, 26 May 2006 09:55:05 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.6/8.13.6/Submit) id k4QGt57S056793 for tcpm@ietf.org; Fri, 26 May 2006 09:55:05 -0700 (PDT) (envelope-from faber) Date: Fri, 26 May 2006 09:55:05 -0700 From: Ted Faber To: tcpm@ietf.org Message-ID: <20060526165505.GI51363@hut.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@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [tcpm] -00 cutoff for Montreal -- 12 June 9:00 AM EDT 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="===============1212152370==" Errors-To: tcpm-bounces@ietf.org --===============1212152370== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a7XSrSxqzVsaECgU" Content-Disposition: inline --a7XSrSxqzVsaECgU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable FYI: In order to expedite the processing of the many version -00 I-Ds that the Secretariat receives before an IETF meeting, we ask that you please notify the Secretariat prior to the initial submission cutoff date of all version -00 I-Ds that you expect to approve for posting as WG documents. Please send the filenames of your approved -00 I-Ds to internet-drafts@ietf.org. We would appreciate receiving your list of approved drafts five (5) business days prior to the cutoff date for -00 submissions, or by Monday, June 12th at 9:00 AM ET for the 66th IETF Meeting. Please include the word "Approved I-Ds" in the "Subject" field. This procedure will help to ensure that version -00 I-Ds are posted in a timely manner, allowing more time for review by the public. --=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 --a7XSrSxqzVsaECgU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEdzLpaUz3f+Zf+XsRAjAhAJ9/z7jNgkV8lf0f3AlPSyiXVwBOEgCgn76T WpJV/4wjDCNMP9lVGb1pfCU= =Zg/a -----END PGP SIGNATURE----- --a7XSrSxqzVsaECgU-- --===============1212152370== 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 --===============1212152370==-- From tcpm-bounces@ietf.org Sun May 28 09:35:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkLPr-0003jJ-Q4; Sun, 28 May 2006 09:34:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkLPq-0003j8-KS for tcpm@ietf.org; Sun, 28 May 2006 09:34:46 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkLPp-0002JX-3k for tcpm@ietf.org; Sun, 28 May 2006 09:34:46 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4SDYXQp004653; Sun, 28 May 2006 10:34:33 -0300 Message-Id: <7.0.1.0.0.20060528101746.05720d00@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 28 May 2006 10:18:25 -0300 To: Joe Touch From: Fernando Gont Subject: Re: [tcpm] Next revision of the ICMP attacks draft In-Reply-To: <4473D96F.8050708@isi.edu> References: <7.0.1.0.0.20060523021302.060e2298@gont.com.ar> <44732D73.4040803@isi.edu> <7.0.1.0.0.20060523143647.04c227c8@gont.com.ar> <44736E3C.2060707@isi.edu> <7.0.1.0.0.20060523193434.044e0458@gont.com.ar> <4473D96F.8050708@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: tcpm-chairs@tools.ietf.org, tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 00:56 24/05/2006, Joe Touch wrote: >>"It is best to assume that the network is filled with malevolent >>entities that will send packets >>designed to have the worst possible effect. This assumption will >>lead to suitably protective design." > > "Be liberal in what you accept, and > conservative in what you send" > >There is a large difference between documenting what is - and >weighing the implications of that - with accepting what is >implemented and recommending it for the future without substantial >detail. I heard the WG agree to the former, not the latter; the >chairs can clarify. What changes are you proposing, specifically? Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon May 29 06:39:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkf8u-0002q8-JE; Mon, 29 May 2006 06:38:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkf8t-0002q3-M6 for tcpm@ietf.org; Mon, 29 May 2006 06:38:35 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fkf8q-0004mj-3R for tcpm@ietf.org; Mon, 29 May 2006 06:38:35 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060308/8.12.11) with ESMTP id k4TAcIb4023643; Mon, 29 May 2006 13:38:18 +0300 Date: Mon, 29 May 2006 13:38:18 +0300 (EEST) From: Pekka Savola To: tcpm@ietf.org Subject: Re: [tcpm] WGLC on antispoof In-Reply-To: <20060517034349.BE52C40F5AE@lawyers.icir.org> Message-ID: References: <20060517034349.BE52C40F5AE@lawyers.icir.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1494/Sun May 28 21:27:02 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: touch@isi.edu X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Hi, On Tue, 16 May 2006, Mark Allman wrote: > Per the discussion in Dallas, we are kicking off a WGLC on the anitspoof > document. Joe has just posted a new rev of the document which is > available in the archives: > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-antispoof-04.txt I finally got around to checking my comments on -02, and the resulting text; I only looked at the comments I made then and the follow-up modifications. Issues: 1) address filtering text is still technically incorrect or assumptive 2) the text about TTL checking and tunnels not decrementing the TTL is misleading or incorrect 3) the reason why ICMPs are filtered is speculative I'll make separate posts about these to facilitate easier discussion (if any). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon May 29 06:59:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkfT3-0004Ya-Nk; Mon, 29 May 2006 06:59:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkfSu-0004Uu-Iy for tcpm@ietf.org; Mon, 29 May 2006 06:59:16 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkfSu-0008EL-HP for tcpm@ietf.org; Mon, 29 May 2006 06:59:16 -0400 Received: from netcore.fi ([193.94.160.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FkfFv-00032d-DV for tcpm@ietf.org; Mon, 29 May 2006 06:45:52 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060308/8.12.11) with ESMTP id k4TAjma2023841; Mon, 29 May 2006 13:45:48 +0300 Date: Mon, 29 May 2006 13:45:48 +0300 (EEST) From: Pekka Savola To: tcpm@ietf.org In-Reply-To: Message-ID: References: <20060517034349.BE52C40F5AE@lawyers.icir.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1494/Sun May 28 21:27:02 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on otso.netcore.fi X-Spam-Score: -2.3 (--) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: touch@isi.edu Subject: [tcpm] WGLC on antispoof -- address filtering X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Mon, 29 May 2006, Pekka Savola wrote: > Issues: > > 1) address filtering text is still technically incorrect or assumptive Specifically, the statement (and follow-up text): "It cannot restrict traffic from edges lacking filtering through the core to a particular edge, i.e., from upstream sources." is not correct. In response to previous comments, the editor said: "I disagree that "you can _yourself_ do the filting, without relying on anyone else", except in trivial multiconnected stub network cases." The last part may or may not be key to understanding and resolving the disagreement. I assert that an ISP can protect its own and its single-homed customers' sessions which are internal to the ISP by making sure its own borders are properly secure. I also claim that multihomed sites can do this on their own borders to protect their internal sessions. Hence, "internal sessions" in an administrative domain that cares about setting up proper security can be protected from TCP RST attacks. See the assumptions in Section 1 of draft-savola-rtgwg-backbone-attacks-00.txt for more on how this helps an ISP. I'd estimate that over 95% of net users are single-homed by that definition, though the amount of traffic that's "internal" is arguably limited. Hence, this is an important scenario especially if you consider *infrastructure* uses (which are typically internal, such as BGP) and needs to be properly addressed instead of just waived away as a trivial case. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon May 29 07:14:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkfhQ-0002ZW-Qv; Mon, 29 May 2006 07:14:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkfhP-0002QM-KZ for tcpm@ietf.org; Mon, 29 May 2006 07:14:15 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkfhO-0001QG-3d for tcpm@ietf.org; Mon, 29 May 2006 07:14:15 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060308/8.12.11) with ESMTP id k4TBEBH0024549; Mon, 29 May 2006 14:14:11 +0300 Date: Mon, 29 May 2006 14:14:11 +0300 (EEST) From: Pekka Savola To: tcpm@ietf.org In-Reply-To: Message-ID: References: <20060517034349.BE52C40F5AE@lawyers.icir.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1494/Sun May 28 21:27:02 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: touch@isi.edu Subject: [tcpm] WGLC on antispoof -- TTL checking X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Mon, 29 May 2006, Pekka Savola wrote: > Issues: > 2) the text about TTL checking and tunnels not decrementing the TTL is > misleading or incorrect The text in section 3.2.1 about TTL checking is still misleading or incorrect. Do you mean both you and your peer with "those nodes" in "or any traffic those nodes accept via tunnels - because tunnels need not decrement TTLs"? Either way, this gets back to whether your peer is complying to RFC 791, i.e., decrementing the TTL for packets which it forwards. There is no difference whether the link is physical or an IP tunnel. Tunnel head-end decrements the TTL if it forwards a packet to the tunnel; tunnel tail-end decrements the TTL if it forwards a packet out of the tunnel. TTL is unchanged for packets at the end which is originating or receiving packets. Exactly like physical interfaces. Therefore I don't see why it makes sense to make such a big deal about tunnels. Further, "only where all traffic from the other end of the tunnel is trusted" is misleading at best. It makes it sound as if transiting traffic (from all over the Internet) at tunnel head-end would need to be trusted if the tunnel head-end is conforming to the specifications. That's not the case; you only need to trust that the tunnel head-end isn't injecting inappropriate packets (which includes inappropriate modified copies of transited datagrams). But if the only thing the tunnel head-end can do is to reset its *OWN* (BGP or whatever) link-local session, what's the point? In practice, TTL checking for link-local control messaging may be inadequate if: 1) you don't trust the link layer (see draft-savola-rtgwg-backbone-attacks-00.txt section 2.1 why this isn't necessarily a big deal for control protocols such as BGP), 2) the link includes a large number of neighbors (e.g., an internet exchange Ethernet fabric) and other authentication is not used, or 3) GTSM implementation processes TCP RSTs for GTSM-enabled sessions which have TTL != 255. The behavior is currently unspecified, but GTSM revision will be looking at this. The text in the document right now is: A more recent variant of address filtering checks the IP TTL field, relying on the TTL set by the other end of the connection [15]. This technique has been used to provide filtering for BGP. It assumes the connection source TTL is set to 255; packets at the receiver are checked for TTL=255, and others are dropped. This restricts traffic to one hop upstream of the receiver (i.e., a BGP router), but those hops could include other user programs at those nodes (e.g., the BGP router's peer) or any traffic those nodes accept via tunnels - because tunnels need not decrement TTLs [30] (see Sec. 5.1 of [15]). This method works only where all traffic from the other end of the tunnel is trusted, i.e., where it does not originate or transit spoofed traffic. The use of TTL rather than link or network security also assumes an untampered point-to-point link, where no other traffic can be spoofed onto a link. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon May 29 07:21:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkfoT-0006FY-GU; Mon, 29 May 2006 07:21:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkfoS-0006FT-Mq for tcpm@ietf.org; Mon, 29 May 2006 07:21:32 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkfoQ-0001Yi-Gn for tcpm@ietf.org; Mon, 29 May 2006 07:21:32 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060308/8.12.11) with ESMTP id k4TBLMgo024733; Mon, 29 May 2006 14:21:23 +0300 Date: Mon, 29 May 2006 14:21:22 +0300 (EEST) From: Pekka Savola To: tcpm@ietf.org In-Reply-To: Message-ID: References: <20060517034349.BE52C40F5AE@lawyers.icir.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1494/Sun May 28 21:27:02 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: touch@isi.edu Subject: [tcpm] WGLC on antispoof -- ICMP filtering speculation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Mon, 29 May 2006, Pekka Savola wrote: > Issues: > 3) the reason why ICMPs are filtered is speculative The new text says: Unfortunately, [ICMP errors] also can originate at other places in the network. As a result, many networks filter all ICMP packets because validation may not be possible, especially because they can be injected from anywhere in a network, and so cannot be selectively address filtered. .. it seems that "As a result" is speculative. I don't know why people filter ICMPs; because there is no reference, I suspect you don't know either. You make it seem that filtering ICMPs is a result of certain bad ICMP packets, in particular ICMPs which reset sessions. I personally suspect that reasons are very different and have evolved much earlier on, like "we don't want to allow ping scanning to see which hosts are up". But that seems irrelevant to this particular document, as there is no way to know what the current or original motivations for filtering ICMPs were. Hence, I'd reword the latter sentence or remove it completely. If rewording, I'd be careful not to imply that the IETF thinks filtering all ICMP messages is a valid configuration... -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon May 29 08:18:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkghC-0002fB-Qn; Mon, 29 May 2006 08:18:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkghA-0002Ss-Ts for tcpm@ietf.org; Mon, 29 May 2006 08:18:04 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fkgh9-0007Wy-B4 for tcpm@ietf.org; Mon, 29 May 2006 08:18:04 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4TCHOI6027043; Mon, 29 May 2006 09:17:28 -0300 Message-Id: <7.0.1.0.0.20060529074658.04cc48d8@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 29 May 2006 08:02:48 -0300 To: Joe Touch From: Fernando Gont Subject: Re: [tcpm] Clarification on feedback on draft-ietf-tcpm-tcp-antispoof-04.txt In-Reply-To: <4473DB60.3080602@isi.edu> References: <7.0.1.0.0.20060523201036.05174fd8@gont.com.ar> <4473DB60.3080602@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: tcpm-chairs@tools.ietf.org, tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 01:04 24/05/2006, Joe Touch wrote: >>Folks, >>My point on section 4 ("ICMP") of the document is that only one of >>all the counter-measures of the ICMP attacks draft is discussed. > >I've already noted that I would add a comment that there are other >measures under development. Good. >>Being that the ICMP attacks draft is a WG item, that the WG got >>rough consensus on, I don't think all the other (and main!) >>counter-measures should be excluded from the discussion. > >The point of the document is not the countermeasures; it is that >ICMP is not addressed by the techniques discussed, and that the >primary (and still primary) method to deal with ICMP attacks is to >drop all ICMP packets. I stand by that conclusion, and have heard >nothing to refute it. I disagree with that of the primary counter-measure for ICMP is to drop all ICMP packets. First, the tests I have made with tools to perform the attacks described in the ICMP attacks draft made it clear that there's no such a big deployment of ICMP messages (actually, as I say in some other e-mail, ICMP messages get dropped at NATs because there's no state information for them. Just that). I propose to mention at tcpsecure (etc) do not address ICMP attacks (that include blind connection-reset attacks), and state that the WG is working on counter-measures, and that many TCP/IP stacks already implement them. That doesn't we are "recommending" them. Just stating facts. The deployment of systems implementing the "hard errors -> soft errors" behaviour outnumbers (by far) the deployment of systems blocking ICMP error messages for which there is state information. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon May 29 12:42:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkkom-0006wp-Cx; Mon, 29 May 2006 12:42:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkkol-0006sn-9i for tcpm@ietf.org; Mon, 29 May 2006 12:42:11 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fkkoi-0000QE-Te for tcpm@ietf.org; Mon, 29 May 2006 12:42:11 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4TGfNI04906; Mon, 29 May 2006 09:41:23 -0700 (PDT) Message-ID: <447B2427.9020908@isi.edu> Date: Mon, 29 May 2006 09:41:11 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Pekka Savola References: <20060517034349.BE52C40F5AE@lawyers.icir.org> In-Reply-To: X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: tcpm@ietf.org Subject: [tcpm] Re: WGLC on antispoof -- address filtering 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="===============1222056845==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1222056845== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2B8AC737E0A70210F6C4CD87" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2B8AC737E0A70210F6C4CD87 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pekka Savola wrote: > On Mon, 29 May 2006, Pekka Savola wrote: >> Issues: >> >> 1) address filtering text is still technically incorrect or assumptive= It would be useful to provide candidate substitute text. > Specifically, the statement (and follow-up text): >=20 > "It cannot restrict traffic from edges lacking filtering through the > core to a particular edge, i.e., from upstream sources." >=20 > is not correct. Assume you provide filtering from upstream sources that do not themselves filter (the opposite). Any traffic that appears sourced from upstream could have been spoofed. Can you explain how to provide filtering in this case? > In response to previous comments, the editor said: >=20 > "I disagree that "you can _yourself_ do the filting, without relying on= > anyone else", except in trivial multiconnected stub network cases." >=20 > The last part may or may not be key to understanding and resolving the > disagreement. >=20 > I assert that an ISP can protect its own and its single-homed customers= ' > sessions which are internal to the ISP by making sure its own borders > are properly secure. What percent of connections are internal to the ISP? Protecting only that small fraction of connections is not sufficient. > I also claim that multihomed sites can do this on > their own borders to protect their internal sessions. That's essentially a restatement of the exception I provided (internal sessions treat the net as a stub). > Hence, "internal > sessions" in an administrative domain that cares about setting up prope= r > security can be protected from TCP RST attacks. See the assumptions in= > Section 1 of draft-savola-rtgwg-backbone-attacks-00.txt for more on how= > this helps an ISP. >=20 > I'd estimate that over 95% of net users are single-homed by that > definition, though the amount of traffic that's "internal" is arguably > limited. Hence, this is an important scenario especially if you > consider *infrastructure* uses (which are typically internal, such as > BGP) and needs to be properly addressed instead of just waived away as = a > trivial case. This text is self-contradictory; I agree that a large percentage (though 95% seems arbitrary, and would need a reference to include) of users are single-homed, but the larger issue is the percent of internal traffic. One would hope that BGP would not be internal (it wouldn't be very effective). Once it originates outside your border, you're trusting the party one stream up to filter - even for BGP. Joe --------------enig2B8AC737E0A70210F6C4CD87 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEeyQrE5f5cImnZrsRAllAAJ9qUul+6jNoBbWxhgRSvl/i8JEJkACffyJN nVW2q8mnFVg0RvfflboArQo= =C/xU -----END PGP SIGNATURE----- --------------enig2B8AC737E0A70210F6C4CD87-- --===============1222056845== 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 --===============1222056845==-- From tcpm-bounces@ietf.org Mon May 29 12:45:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkkre-0007zN-Cr; Mon, 29 May 2006 12:45:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkkrc-0007yF-OG for tcpm@ietf.org; Mon, 29 May 2006 12:45:08 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fkkrb-0000Uz-BH for tcpm@ietf.org; Mon, 29 May 2006 12:45:08 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4TGibI05680; Mon, 29 May 2006 09:44:37 -0700 (PDT) Message-ID: <447B24ED.1020307@isi.edu> Date: Mon, 29 May 2006 09:44:29 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Pekka Savola References: <20060517034349.BE52C40F5AE@lawyers.icir.org> In-Reply-To: X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: tcpm@ietf.org Subject: [tcpm] Re: WGLC on antispoof -- TTL checking 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="===============0897782171==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0897782171== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig40525AB5BD08EE1976713BDB" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig40525AB5BD08EE1976713BDB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pekka Savola wrote: > On Mon, 29 May 2006, Pekka Savola wrote: >> Issues: >> 2) the text about TTL checking and tunnels not decrementing the TTL is= >> misleading or incorrect >=20 > The text in section 3.2.1 about TTL checking is still misleading or > incorrect. Do you mean both you and your peer with "those nodes" in "o= r > any traffic those nodes accept via tunnels - because tunnels need not > decrement TTLs"? Either way, this gets back to whether your peer is > complying to RFC 791, i.e., decrementing the TTL for packets which it > forwards. There is no difference whether the link is physical or an IP= > tunnel. Tunnel head-end decrements the TTL if it forwards a packet to > the tunnel; tunnel tail-end decrements the TTL if it forwards a packet > out of the tunnel. TTL is unchanged for packets at the end which is > originating or receiving packets. Exactly like physical interfaces. See section 3.1 of RFC2003; whether the TTL is decremented depends on whether forwarding is considered part of the operation, and this is a choice, not fixed. Can you evaluate the remainder of this note in the context of RFC2003 and let us know if there is still an inconsistency? > Therefore I don't see why it makes sense to make such a big deal about > tunnels. Further, "only where all traffic from the other end of the > tunnel is trusted" is misleading at best. It makes it sound as if > transiting traffic (from all over the Internet) at tunnel head-end woul= d > need to be trusted if the tunnel head-end is conforming to the > specifications. That's not the case; you only need to trust that the > tunnel head-end isn't injecting inappropriate packets (which includes > inappropriate modified copies of transited datagrams). But if the only= > thing the tunnel head-end can do is to reset its *OWN* (BGP or whatever= ) > link-local session, what's the point? >=20 > In practice, TTL checking for link-local control messaging may be > inadequate if: >=20 > 1) you don't trust the link layer (see > draft-savola-rtgwg-backbone-attacks-00.txt section 2.1 why this isn't > necessarily a big deal for control protocols such as BGP), >=20 > 2) the link includes a large number of neighbors (e.g., an internet > exchange Ethernet fabric) and other authentication is not used, or >=20 > 3) GTSM implementation processes TCP RSTs for GTSM-enabled sessions > which have TTL !=3D 255. The behavior is currently unspecified, but GT= SM > revision will be looking at this. >=20 > The text in the document right now is: >=20 > A more recent variant of address filtering checks the IP TTL field, > relying on the TTL set by the other end of the connection [15]. Thi= s > technique has been used to provide filtering for BGP. It assumes th= e > connection source TTL is set to 255; packets at the receiver are > checked for TTL=3D255, and others are dropped. This restricts traff= ic > to one hop upstream of the receiver (i.e., a BGP router), but those > hops could include other user programs at those nodes (e.g., the BGP= > router's peer) or any traffic those nodes accept via tunnels - > because tunnels need not decrement TTLs [30] (see Sec. 5.1 of [15]).= > This method works only where all traffic from the other end of the > tunnel is trusted, i.e., where it does not originate or transit > spoofed traffic. The use of TTL rather than link or network security= > also assumes an untampered point-to-point link, where no other > traffic can be spoofed onto a link. >=20 --------------enig40525AB5BD08EE1976713BDB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEeyTtE5f5cImnZrsRAk54AJ9Unxp+iqEjtTE1MtFLClL67/x2LQCaAlKT 0qz8Fp5IdoIThUCYe3WNJ5E= =kkr7 -----END PGP SIGNATURE----- --------------enig40525AB5BD08EE1976713BDB-- --===============0897782171== 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 --===============0897782171==-- From tcpm-bounces@ietf.org Mon May 29 12:49:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkkvT-00005a-5O; Mon, 29 May 2006 12:49:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkkvS-00005V-Ek for tcpm@ietf.org; Mon, 29 May 2006 12:49:06 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkkvR-0000aX-3B for tcpm@ietf.org; Mon, 29 May 2006 12:49:06 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4TGmlI06449; Mon, 29 May 2006 09:48:47 -0700 (PDT) Message-ID: <447B25E7.50901@isi.edu> Date: Mon, 29 May 2006 09:48:39 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Pekka Savola References: <20060517034349.BE52C40F5AE@lawyers.icir.org> In-Reply-To: X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: tcpm@ietf.org Subject: [tcpm] Re: WGLC on antispoof -- ICMP filtering speculation 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="===============1755317490==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1755317490== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB83F921585FB36DB5B405304" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB83F921585FB36DB5B405304 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pekka Savola wrote: > On Mon, 29 May 2006, Pekka Savola wrote: >> Issues: >> 3) the reason why ICMPs are filtered is speculative >=20 > The new text says: >=20 > Unfortunately, [ICMP errors] also can originate at other places > in the network. As a result, > many networks filter all ICMP packets because validation may not be > possible, especially because they can be injected from anywhere in a= > network, and so cannot be selectively address filtered. >=20 > .. it seems that "As a result" is speculative. I don't know why people= > filter ICMPs; because there is no reference, I suspect you don't know > either.=20 I'll add a citation to RFC4301, which asserts these reasons (without citation, FWIW). > You make it seem that filtering ICMPs is a result of certain > bad ICMP packets, in particular ICMPs which reset sessions. I personall= y > suspect that reasons are very different and have evolved much earlier > on, like "we don't want to allow ping scanning to see which hosts are u= p". Those are outgoing ICMPs; those are filtered for other reasons, including router load as well as address scanning. Incoming ICMPs are either information about the external world (which is good) or attacks (which is bad). > But that seems irrelevant to this particular document, as there is no > way to know what the current or original motivations for filtering ICMP= s > were. Hence, I'd reword the latter sentence or remove it completely.=20 > If rewording, I'd be careful not to imply that the IETF thinks filterin= g > all ICMP messages is a valid configuration... Can you recheck this suggestion in light of RFC4301 and repost? Joe --------------enigB83F921585FB36DB5B405304 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEeyXnE5f5cImnZrsRAibeAJsHvTFNvTh7ViRUOlbBeTgyGDImIACg/jiO v2J+wsRM4MJSyMRtN62eseM= =YH2p -----END PGP SIGNATURE----- --------------enigB83F921585FB36DB5B405304-- --===============1755317490== 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 --===============1755317490==-- From tcpm-bounces@ietf.org Mon May 29 12:59:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkl5n-0004ao-Im; Mon, 29 May 2006 12:59:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkl5l-0004ae-UD for tcpm@ietf.org; Mon, 29 May 2006 12:59:45 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fkl5k-00014H-IJ for tcpm@ietf.org; Mon, 29 May 2006 12:59:45 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4TGuwI08384; Mon, 29 May 2006 09:56:58 -0700 (PDT) Message-ID: <447B27D2.90404@isi.edu> Date: Mon, 29 May 2006 09:56:50 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] Clarification on feedback on draft-ietf-tcpm-tcp-antispoof-04.txt References: <7.0.1.0.0.20060523201036.05174fd8@gont.com.ar> <4473DB60.3080602@isi.edu> <7.0.1.0.0.20060529074658.04cc48d8@gont.com.ar> In-Reply-To: <7.0.1.0.0.20060529074658.04cc48d8@gont.com.ar> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: tcpm-chairs@tools.ietf.org, 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="===============2087349174==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2087349174== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5AF7958E9848C3DF5739A366" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5AF7958E9848C3DF5739A366 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: =2E.. >> The point of the document is not the countermeasures; it is that ICMP >> is not addressed by the techniques discussed, and that the primary >> (and still primary) method to deal with ICMP attacks is to drop all >> ICMP packets. I stand by that conclusion, and have heard nothing to >> refute it. >=20 > I disagree with that of the primary counter-measure for ICMP is to drop= > all ICMP packets. First, the tests I have made with tools to perform th= e > attacks described in the ICMP attacks draft made it clear that there's > no such a big deployment of ICMP messages (actually, as I say in some > other e-mail, ICMP messages get dropped at NATs because there's no stat= e > information for them. Just that). See RFC4301; that's the primary network security architecture for the Internet, and it discusses exactly this issue. It does suggest that a mechanism is required where ICMPs are *all* dropped, but requires that it be configurable. Interestingly, it requires that the capability be configurable, and makes _no_ recommendation to default it to ON. However, firewalls at enterprises dropping all ICMPs is fairly well known (at least AFAICT - is there really disagreement about this? I can dig into NANOG to get info, but it seems less useful given 4301 doesn't provide cites on this point). > I propose to mention at tcpsecure (etc) do not address ICMP attacks > (that include blind connection-reset attacks), and state that the WG is= > working on counter-measures, and that many TCP/IP stacks already > implement them. That'd be fine (modulo "countermeasures +for some cases+"), provided it comes with the additional caveat that the existing way to protect against ICMP attacks (which is already implemented as well) is to filter all ICMPs (ref 4301). > That doesn't we are "recommending" them. Just stating facts. Agreed, in both cases (yours and 4301's). > The deployment of systems implementing the "hard errors -> soft errors"= > behaviour outnumbers (by far) the deployment of systems blocking ICMP > error messages for which there is state information. This isn't a popularity contest; it's about specs, and 792 + 1122 + 4301 > I-D (again, just stating facts ;-) Joe --------------enig5AF7958E9848C3DF5739A366 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEeyfSE5f5cImnZrsRApbiAKCLH1bv1M92K153M+Q7cq9Kg+WnOwCg9YOb yLMtiZ3BbdMcH8X2XA+v5RQ= =SHnJ -----END PGP SIGNATURE----- --------------enig5AF7958E9848C3DF5739A366-- --===============2087349174== 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 --===============2087349174==-- From tcpm-bounces@ietf.org Mon May 29 13:38:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fklgv-0001ZJ-0U; Mon, 29 May 2006 13:38:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fklgt-0001TT-Kt for tcpm@ietf.org; Mon, 29 May 2006 13:38:07 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fklgs-0004KV-9c for tcpm@ietf.org; Mon, 29 May 2006 13:38:07 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4THb5I17237; Mon, 29 May 2006 10:37:05 -0700 (PDT) Message-ID: <447B3132.9030500@isi.edu> Date: Mon, 29 May 2006 10:36:50 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Joe Touch References: <20060517034349.BE52C40F5AE@lawyers.icir.org> <447B25E7.50901@isi.edu> In-Reply-To: <447B25E7.50901@isi.edu> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: tcpm@ietf.org Subject: [tcpm] Re: WGLC on antispoof -- ICMP filtering speculation 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="===============1157786767==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1157786767== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE62FB6AB1D040B72B7AEEA81" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE62FB6AB1D040B72B7AEEA81 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Joe Touch wrote: >=20 > Pekka Savola wrote: =2E.. >> You make it seem that filtering ICMPs is a result of certain >> bad ICMP packets, in particular ICMPs which reset sessions. I personal= ly >> suspect that reasons are very different and have evolved much earlier >> on, like "we don't want to allow ping scanning to see which hosts are = up". >=20 > Those are outgoing ICMPs; I should have noted some assumptions I was making: - ping ICMPs can be incoming - anyone doing port scanning can fairly trivially do so with non-ICMP sources which rely on ICMP replies for rapid operation (i.e., to hit any service, not just available ones, or - more easily - to try to connect to a typically nonavailable service, e.g., to port 0) Also, traceroute is useful for mapping enterprises, and these rely on ICMP replies but not sources as well. FWIW, I checked a simple case - my Westell DSL modem. When in 'medium or low secure mode', it drops: OUTGOING and INCOMING netbios INCOMING source 0.0.0.0 INCOMING ICMP (in high-secure it drops everything in both direction that isn't explicitly allowed; low filters out known attacks and medium allows only known ports - neither med nor low affect the ICMP rules) Note - it does NOT drop outgoing ICMPs except in high-security mode. Joe --------------enigE62FB6AB1D040B72B7AEEA81 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEezE5E5f5cImnZrsRAnKoAKCbWO8R8N7yN2ZLuUtRCpXcSLqQGACfbmLO j8EMl3W/a3cZDsJ8gu6Cdz4= =okCp -----END PGP SIGNATURE----- --------------enigE62FB6AB1D040B72B7AEEA81-- --===============1157786767== 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 --===============1157786767==-- From tcpm-bounces@ietf.org Mon May 29 14:55:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkmtB-0002E9-AD; Mon, 29 May 2006 14:54:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkmt9-0002Ak-8q for tcpm@ietf.org; Mon, 29 May 2006 14:54:51 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fkmt7-0005G0-M2 for tcpm@ietf.org; Mon, 29 May 2006 14:54:51 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 29 May 2006 11:54:49 -0700 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k4TIsmHd029641; Mon, 29 May 2006 11:54:48 -0700 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4TIsjLf023519; Mon, 29 May 2006 20:54:47 +0200 (MEST) Received: from lwood-wxp01.cisco.com (ams3-vpn-dhcp4137.cisco.com [10.61.80.40]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id TAA22289; Mon, 29 May 2006 19:54:43 +0100 (BST) Message-Id: <7.0.1.0.0.20060529191128.04a21310@surrey.ac.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 29 May 2006 19:54:59 +0100 To: Pekka Savola From: Lloyd Wood Subject: Re: [tcpm] WGLC on antispoof -- TTL checking In-Reply-To: References: <20060517034349.BE52C40F5AE@lawyers.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Authentication-Results: sj-dkim-3.cisco.com; header.From=L.Wood@surrey.ac.uk; dkim=neutral X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: tcpm@ietf.org, touch@isi.edu X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At Monday 29/05/2006 14:14 +0300, Pekka Savola wrote: >On Mon, 29 May 2006, Pekka Savola wrote: >>Issues: >>2) the text about TTL checking and tunnels not decrementing the TTL >>is misleading or incorrect > >The text in section 3.2.1 about TTL checking is still misleading or >incorrect. Do you mean both you and your peer with "those nodes" in >"or any traffic those nodes accept via tunnels - because tunnels >need not decrement TTLs"? Either way, this gets back to whether >your peer is complying to RFC 791, i.e., decrementing the TTL for >packets which it forwards. There is no difference whether the link >is physical or an IP tunnel. Tunnel head-end decrements the TTL if >it forwards a packet to the tunnel; tunnel tail-end decrements the >TTL if it forwards a packet out of the tunnel. You don't decrement TTL on packets you forward, you decrement TTL on packets you receive. (In RFC791 parlance, receiving the packet begins the act of processing it.) It's often viewed as a subtle distinction (or just a play on words) until you've written tunnel or endhost code, where this distinction does matter. TTL decrement is specified as always on ingress to the box in the RFCs; a packet to be tunnelled has its TTL decremented on ingress to the box before being passed to the local tunnel head for encap, and that packet then has another decrement after tunnel decap, only after it has 'entered' the receiving tail-end as a decapped packet. In forwarding implementations, many implementations do decrement TTL (and fixes the IPv4 checksum) very last thing before the packet is forwarded from the box, for performance reasons (the packet may be dropped inside the box, so why waste computing effort on a packet that will be dropped?). This only works where it is logically equivalent to TTL on ingress to the box to match the rfcs and interoperate properly with other boxes for traceroute etc. -- and, in my experience, the performance-oriented decrement-last-wherever-you-leave-the-box code is generally far more complex than a simple ingress-on-entry-at-the-chokepoint decrement implementation would be. (Your description also neglects the decrement of TTL in the encapsulating tunnel IP header that must also happen when the tunnelled packet is received, before decap of the tunnelled packet takes place. That's equivalent to an endhost receiving the packet at last hop; no further forwarding, but the decrement of TTL must still take place. Fixing ICMP reports so that both ends of the tunnel are visible and reported in traceroute, rather than the physical interfaces on the same box, is also a good idea.) On the quoted document text below from ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-antispoof-04.txt tunnels must decrement TTLs. I hope the note above makes that clear. If a packet is received with TTL set to 255 by the previous box, then treating decrement-on-ingress and checking once you reach the BGP code would really mean you would be checking against TTL 254 -- otherwise the original packet must have a TTL of zero that has looped around (and a TTL of zero is not permitted per RFC2003). In RFC 2003, charlie says: When encapsulating a datagram, the TTL in the inner IP header is decremented by one if the tunneling is being done as part of forwarding the datagram; otherwise, the inner header TTL is not changed during encapsulation. When is tunnelling not a part of forwarding? A hop over a tunnel is still a hop, even if you're localhost tunnelling and port forwarding to yourself. >TTL is unchanged for packets at the end which is originating or >receiving packets. Exactly like physical interfaces. if only physical interfaces worked like that, eh? L. >Therefore I don't see why it makes sense to make such a big deal >about tunnels. Further, "only where all traffic from the other end >of the tunnel is trusted" is misleading at best. It makes it sound >as if transiting traffic (from all over the Internet) at tunnel >head-end would need to be trusted if the tunnel head-end is >conforming to the specifications. That's not the case; you only >need to trust that the tunnel head-end isn't injecting inappropriate >packets (which includes inappropriate modified copies of transited >datagrams). But if the only thing the tunnel head-end can do is to >reset its *OWN* (BGP or whatever) link-local session, what's the point? > >In practice, TTL checking for link-local control messaging may be >inadequate if: > > 1) you don't trust the link layer (see > draft-savola-rtgwg-backbone-attacks-00.txt section 2.1 why this > isn't necessarily a big deal for control protocols such as BGP), > > 2) the link includes a large number of neighbors (e.g., an > internet exchange Ethernet fabric) and other authentication is not used, or > > 3) GTSM implementation processes TCP RSTs for GTSM-enabled > sessions which have TTL != 255. The behavior is currently > unspecified, but GTSM revision will be looking at this. > >The text in the document right now is: > > A more recent variant of address filtering checks the IP TTL field, > relying on the TTL set by the other end of the connection [15]. This > technique has been used to provide filtering for BGP. It assumes the > connection source TTL is set to 255; packets at the receiver are > checked for TTL=255, and others are dropped. This restricts traffic > to one hop upstream of the receiver (i.e., a BGP router), but those > hops could include other user programs at those nodes (e.g., the BGP > router's peer) or any traffic those nodes accept via tunnels - > because tunnels need not decrement TTLs [30] (see Sec. 5.1 of [15]). > This method works only where all traffic from the other end of the > tunnel is trusted, i.e., where it does not originate or transit > spoofed traffic. The use of TTL rather than link or network security > also assumes an untampered point-to-point link, where no other > traffic can be spoofed onto a link. > >-- >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 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon May 29 21:41:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FktEV-0000gu-5u; Mon, 29 May 2006 21:41:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FktET-0000fm-Er for tcpm@ietf.org; Mon, 29 May 2006 21:41:17 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FktER-0004AS-V4 for tcpm@ietf.org; Mon, 29 May 2006 21:41:17 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4U1eVI21137; Mon, 29 May 2006 18:40:31 -0700 (PDT) Message-ID: <447BA287.5080709@isi.edu> Date: Mon, 29 May 2006 18:40:23 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Lloyd Wood Subject: Re: [tcpm] WGLC on antispoof -- TTL checking References: <20060517034349.BE52C40F5AE@lawyers.icir.org> <7.0.1.0.0.20060529191128.04a21310@surrey.ac.uk> In-Reply-To: <7.0.1.0.0.20060529191128.04a21310@surrey.ac.uk> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e 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="===============1709302403==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1709302403== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0DCF99B9D24CF95314924844" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0DCF99B9D24CF95314924844 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Lloyd Wood wrote: > At Monday 29/05/2006 14:14 +0300, Pekka Savola wrote: >> On Mon, 29 May 2006, Pekka Savola wrote: >>> Issues: >>> 2) the text about TTL checking and tunnels not decrementing the TTL >>> is misleading or incorrect >> >> The text in section 3.2.1 about TTL checking is still misleading or >> incorrect. Do you mean both you and your peer with "those nodes" in >> "or any traffic those nodes accept via tunnels - because tunnels need >> not decrement TTLs"? Either way, this gets back to whether your peer >> is complying to RFC 791, i.e., decrementing the TTL for packets which >> it forwards. There is no difference whether the link is physical or >> an IP tunnel. Tunnel head-end decrements the TTL if it forwards a >> packet to the tunnel; tunnel tail-end decrements the TTL if it >> forwards a packet out of the tunnel. >=20 > You don't decrement TTL on packets you forward, you decrement TTL on > packets you receive. (In RFC791 parlance, receiving the packet begins > the act of processing it.) It's often viewed as a subtle distinction (o= r > just a play on words) until you've written tunnel or endhost code, wher= e > this distinction does matter. RFC1122 does not specify decrementing the TTL. Only RFC1812 does. Packets sent host-host do not decrement the TTL, for example. Host-router-host decrements the TTL by 1. > TTL decrement is specified as always on ingress to the box in the RFCs;= Which RFCs? As to tunnels, they are their own animal. They can decrement at the head, tail, or both; they can also decrement by more than one (to emulate some of the properties of the path underneath, or to encourage certain routes). When the packet terminates at the tunnel, it is not decremented. In BITW IPsec, the TTL would probably not be decremented at all, nor in other 'transparent' tunnels. =2E.. > On the quoted document text below from > ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-antispoof-04.txt= >=20 > tunnels must decrement TTLs. Tunnels do not decrement TTLs; as you noted, that happens after the decapsulation IF the node is forwarding. If the node terminates the packet, or if the node is considered a BITW device, it would not decrement the TTL. =2E.. > In RFC 2003, charlie says: >=20 > When encapsulating a datagram, the TTL in the inner IP header is > decremented by one if the tunneling is being done as part of > forwarding the datagram; otherwise, the inner header TTL is not > changed during encapsulation. >=20 > When is tunnelling not a part of forwarding? A BITW (bump in the wire) isn't forwarding, i.e., when a device has one input and one output and no forwarding decision is being made. Encryption devices work this wa. > A hop over a tunnel is > still a hop, even if you're localhost tunnelling and port forwarding to= > yourself. Agreed, but TTL counts forwarding steps, not links, not hops. Joe --------------enig0DCF99B9D24CF95314924844 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEe6KIE5f5cImnZrsRAuqEAKDYi8g+IDTMQ+fuv7RruZeCE+XYuQCfeRbt RsBEPqLJEYqM3AKQqYrPnFE= =LCsl -----END PGP SIGNATURE----- --------------enig0DCF99B9D24CF95314924844-- --===============1709302403== 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 --===============1709302403==-- From tcpm-bounces@ietf.org Tue May 30 12:21:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl6xW-00028J-Ba; Tue, 30 May 2006 12:20:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl6xU-00027w-JV for tcpm@ietf.org; Tue, 30 May 2006 12:20:40 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl6xS-00031G-6k for tcpm@ietf.org; Tue, 30 May 2006 12:20:40 -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 k4UGKJOr076655; Tue, 30 May 2006 09:20:24 -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 53B2F77A71D; Tue, 30 May 2006 12:20:18 -0400 (EDT) To: Ted Faber From: Mark Allman Subject: Re: [tcpm] ICMP and TCP In-Reply-To: <20060523175920.GB69193@hut.isi.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Legs MIME-Version: 1.0 Date: Tue, 30 May 2006 12:20:18 -0400 Message-Id: <20060530162018.53B2F77A71D@guns.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: "Templin, Fred L" , tcpm@ietf.org, Fernando Gont 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="===============1149309297==" Errors-To: tcpm-bounces@ietf.org --===============1149309297== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > > >What change to TCP semantics are we discussing? I think the > > >strongest thing that 1122 says about reacting to an ICMP is that > > >the host SHOULD abort the connection. I'm pretty sure that this > > >draft doesn't advocate being more strict than the SHOULD, and is > > >only laying out criteria by which the SHOULD might be taken > > >exception to. > > > > That's exactly the case. > > I really think that the draft should state that right in the intro, > since we seem to have to have this discussion every time the draft is > discussed. It'll be much nicer when I can say "read the intro" rather > than typing out that paragraph every time. > > Don't be shy about it. There's a SHOULD in 1122 and this draft > suggests criteria for taking exception to that SHOULD. Point the > SHOULD section of 1122 right out. I'd take this one step further and I'd say as the document steps through things that we should be reminded exactly what the relevant specs say before we go through other possible avenues that would fit within the current specs. (no hats) allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEfHDCWyrrWs4yIs4RAp+cAJ9ny0lDINspPwxp1LKMrCxtqqCNDgCfR3uY W3mjMwBqQxGSJuxm9B9sn/g= =AIsb -----END PGP SIGNATURE----- --=_bOundary-- --===============1149309297== 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 --===============1149309297==-- From tcpm-bounces@ietf.org Tue May 30 13:55:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl8Qz-0006QO-On; Tue, 30 May 2006 13:55:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl8Qy-0006QJ-KK for tcpm@ietf.org; Tue, 30 May 2006 13:55:12 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl8Qw-0004Hk-0y for tcpm@ietf.org; Tue, 30 May 2006 13:55:12 -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 k4UHt6Ag078902 for ; Tue, 30 May 2006 10:55:06 -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 5F86877A71D for ; Tue, 30 May 2006 13:55:05 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Legs MIME-Version: 1.0 Date: Tue, 30 May 2006 13:55:05 -0400 Message-Id: <20060530175505.5F86877A71D@guns.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Subject: [tcpm] big bunch o' icmp-attack comments X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0364079349==" Errors-To: tcpm-bounces@ietf.org --===============0364079349== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Folks- (chair hat off) Below are my comments on the icmp-attacks draft. IMO, despite I don't see this document as near ready yet. allman Meta: * The document is too prescriptive if indeed it is to be an informational type of document and not an update to the relevant specifications. As one egregious example (there are more), section 6 steps through that SQ messages are not supposed to be sent (RFC1812], but if received a host MUST react [RFC1122]. This supposed informational document then goes on to say: "Thus, hosts should completely ignore ICMP Source Quench messages meant for TCP connections." To me, this is a bogus avenue for an informational document to take. I.e., if one takes only the text from 1122 and this document you'd surely assume this document was updating 1122 with new thinking. But, if one looks at the document class then you'd be left with being required to follow 1122 and react to SQ messages if you wanted to be compliant. So, this sort of thing leaves us in a real mess, IMO. (There are other cases of this - e.g., the end of page 12 effectively recommending against the "hard error" classification in RFC1122 in favor of a "soft error" treatment.) There are some SHOULDs in the previous documents and if this document wants to simply clarify or offer some suggested approaches within these SHOULDs then that's fine for an informational, I guess. But, the document should be very clear when it is taking that approach. And, for cases where these is no wiggle room in the current specifications we should not be trying to make some wiggle room. Note #1: I have zero heartburn with saying that hosts should ignore SQ messages. My heartburn is with leaving things all ambiguous in the RFC series. Note #2: I cannot clearly reconstruct why the WG decided to head down the informational path at this point. I would be happy to see that changed such that we can make these sorts of actual changes to the current specs. Note #3: Just because there are no capital letters doesn't mean the text doesn't come off as prescriptive. I.e., the tone and the words themselves are as important in my eyes as whether one writes "must" or "MUST". Basically, I think I am agreeing with Joe and Bora here... as it stands if this document were an informational RFC I think it'd be a backdoor change to the previous specifications. I think we need to think this through very carefully and craft appropriate text if we want to progress as an informational because the IESG, it would seem to me, would be well within the bounds of reasonableness to reject this sort of document for leaving things in an inconsistent and ambiguous state. * The analysis of the threat these attacks impose needs to be much more carefully laid out. The current analysis is glib. E.g., in section 2.2 the text says: "If we assume the attacker knows the two end systems involved in the TCP connection to be attacked,". Why would we assume that? The argument continues that Internet services use well-known ports which leaves only one ephemeral port to be guessed. But, first *which* well-known port is involved in the connection? There are lots of them. The text seems to conclude that the worst case here is that you need to brute force 64K packets to get one wedged into the connection (which in general is very short, as well). I think that is wildly overblown as a general argument. You *might* be able to make this sort of case if you scope down to some case where it is actually plausible that you'd know some of this information (e.g., the BGP case). But, this document is not at all careful about showing perspective as to when ICMP messages are an actual threat and when they are not. * I don't think the revised PMTUD algorithm is a fit for this document. The revised algorithm may be perfectly fine (I would need to think on it more before I made up my mind one way or another). But, the algorithm goes beyond the scope of simply fixing a security problem. If this document wants to do only the security related stuff then that's fine. But, I think the larger work ought to be split out and made into its own document. We have a WG that is working on PMTUD and this would seem at first cut to be under their purview. Section 1: * "While the security" --> "While the possible security" Section 2.1: * "network congestion and rate-limiting" --> "network congestion or rate-limiting" Section 2.1.1: * "report network errors" --> "report errors" * It's not clear to me why the middle two paragraphs are in here. Why are we calling attention to these two things specifically right here? Section 3: * I am not an IPsec guru. So, I don't understand a few things... (1) If I am using IPsec and get an ICMP back then how is that supposed to be processed. In principle I *might* be able to match it to a connection because I saw the data go out on some connection and so I could still validate the first bits included in the reply. Right? I don't expect this happens because stacks don't hang onto packets they put on the wire to compare against, right? (2) So, are you hosed if you use IPsec? That is, are your choices to either ignore them or to pass them to all connections between two addresses? This draft argues against that sort of practice, but should it? I.e., can't that lead to a PMTUD black hole or something? For an IPsec-idiot this document is sort of a mess. I really don't know how this all plays together after reading the document. (Note: I am not advocating re-writing other things, but a sketch and some references would be nice.) Section 4.3: * I share the uneasiness expressed on the list with regards to this section. It's usefulness seems low and at least needs better motivation. One could put an extra warning in here that general egress filtering is useful and should be done. E.g., so I don't forge an ICMP that is supposedly from Joe's machine. Section 5.1: * "TCP is handled" --> "TCP is handed" * I didn't go back and look, but the notion of "frag needed" as a hard error seems odd to me. I think the document could certainly clarify this a bit. It's certainly not treated as a hard error. * More glibness about the ease of the attack: "even being off-path, an attacker could reset any TCP connection taking place". Of course, I cannot prove this statement wrong. But, I am willing to bet that in an empirical way it could not be shown to be accurate either. Section 5.2.1: * It's not clear to me why you apply protocol unreachables to certain states and don't do the same thing to port unreachables. Sections 6 & 7: * I don't quite understand the distinction between a "throughput-reduction" attack and a "performance-degradation" attack. It seems like these two attacks should be subsections of the same section such that I don't have to think about whether there is a real reason for the distinction. Section 7.1: * "(PMTUD) mechanism lets" --> "(PMTUD) lets" * "error message to sending" --> "error message to the sending" * You could cite the TCP model (Padhye 1998, Mathis 1997, etc.) which clearly shows the impact of packet size on performance. --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEfIb5WyrrWs4yIs4RAnZWAKCD8GmeJHs77l0HZWN19G0iRDmHYgCdGUcY +lo9GIcotcIQCxaHf3+IDQ0= =+G94 -----END PGP SIGNATURE----- --=_bOundary-- --===============0364079349== 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 --===============0364079349==-- From tcpm-bounces@ietf.org Tue May 30 13:56:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl8SV-0006YE-Hk; Tue, 30 May 2006 13:56:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl8SU-0006Y9-MS for tcpm@ietf.org; Tue, 30 May 2006 13:56:46 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl8ST-0004Rq-B1 for tcpm@ietf.org; Tue, 30 May 2006 13:56:46 -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 k4UHuiFQ078947; Tue, 30 May 2006 10:56:44 -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 3146977A71D; Tue, 30 May 2006 13:56:43 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Legs MIME-Version: 1.0 Date: Tue, 30 May 2006 13:56:43 -0400 Message-Id: <20060530175643.3146977A71D@guns.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Ted Faber Subject: [tcpm] Montreal meeting 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="===============1992500296==" Errors-To: tcpm-bounces@ietf.org --===============1992500296== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Folks- We need to put in our slot request for Montreal by Jun/5. If you want to contribute to our "WGs to avoid conflicts with" list please send Ted and I a note. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEfIdbWyrrWs4yIs4RAqtpAJ0Vn1JvmtCImD2spzUcjmUJvHpv4ACcCkI/ Te7xLTKGCMMQTGszuxAoC+4= =BfvO -----END PGP SIGNATURE----- --=_bOundary-- --===============1992500296== 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 --===============1992500296==-- From tcpm-bounces@ietf.org Tue May 30 14:00:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl8WG-00071Q-6o; Tue, 30 May 2006 14:00:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl8WE-00071D-Px for tcpm@ietf.org; Tue, 30 May 2006 14:00:38 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl8WC-0004yf-Eh for tcpm@ietf.org; Tue, 30 May 2006 14:00:38 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4UHxbR25491; Tue, 30 May 2006 10:59:37 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.6/8.13.6/Submit) id k4UHxajC032605; Tue, 30 May 2006 10:59:36 -0700 (PDT) (envelope-from faber) Date: Tue, 30 May 2006 10:59:36 -0700 From: Ted Faber To: Mark Allman Message-ID: <20060530175936.GL69771@hut.isi.edu> References: <20060530175643.3146977A71D@guns.icir.org> Mime-Version: 1.0 In-Reply-To: <20060530175643.3146977A71D@guns.icir.org> 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@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: tcpm@ietf.org Subject: [tcpm] Re: Montreal meeting 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="===============1264779450==" Errors-To: tcpm-bounces@ietf.org --===============1264779450== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zH41lVBEV8cLJnCl" Content-Disposition: inline --zH41lVBEV8cLJnCl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 30, 2006 at 01:56:43PM -0400, Mark Allman wrote: > =20 > Folks- >=20 > We need to put in our slot request for Montreal by Jun/5. If you want > to contribute to our "WGs to avoid conflicts with" list please send Ted > and I a note. Yes, thats tcpm-charis@tools.ietf.org - operators are standing by. --=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 --zH41lVBEV8cLJnCl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEfIgIaUz3f+Zf+XsRApjgAKC56chG3wYKiEZ/Makzc6gcqXsS3ACdFMTy dzCWHVWHdqHzuALMKcDo9z4= =hXeO -----END PGP SIGNATURE----- --zH41lVBEV8cLJnCl-- --===============1264779450== 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 --===============1264779450==-- From tcpm-bounces@ietf.org Tue May 30 14:28:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl8xW-00081N-IP; Tue, 30 May 2006 14:28:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl8xV-00081H-Dt for tcpm@ietf.org; Tue, 30 May 2006 14:28:49 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl8xT-00069R-L2 for tcpm@ietf.org; Tue, 30 May 2006 14:28:49 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k4UIROfi010356; Tue, 30 May 2006 15:27:32 -0300 Message-Id: <7.0.1.0.0.20060529224729.049b4618@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 29 May 2006 22:56:02 -0300 To: Joe Touch , Pekka Savola From: Fernando Gont Subject: Re: [tcpm] Re: WGLC on antispoof -- ICMP filtering speculation In-Reply-To: <447B25E7.50901@isi.edu> References: <20060517034349.BE52C40F5AE@lawyers.icir.org> <447B25E7.50901@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 13:48 29/05/2006, Joe Touch wrote: > > .. it seems that "As a result" is speculative. I don't know why people > > filter ICMPs; because there is no reference, I suspect you don't know > > either. > >I'll add a citation to RFC4301, which asserts these reasons (without >citation, FWIW). That's in the context of IPSec. How much of the traffic in the Internet corresponds to IPSec'ed traffic? Also, from that perspective, the antispoof draft should be one-page long, and would just mention something "if you are concerned about in-window attacks, use IPSec". > > But that seems irrelevant to this particular document, as there is no > > way to know what the current or original motivations for filtering ICMPs > > were. Hence, I'd reword the latter sentence or remove it completely. > > If rewording, I'd be careful not to imply that the IETF thinks filtering > > all ICMP messages is a valid configuration... > >Can you recheck this suggestion in light of RFC4301 and repost? IIRC, from the last time I looked at the IPSec specs, there's no recommendation on whether to filter or not to filter. The specs just state there should be a system toggle to decide what to do, and do not even specify what the default should be. Thus, I don't understand how can you take that as a recommendation for ICMP filtering. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue May 30 14:40:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl98B-0003Ae-DT; Tue, 30 May 2006 14:39:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl989-0003AZ-Lt for tcpm@ietf.org; Tue, 30 May 2006 14:39:49 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl988-00070L-Ap for tcpm@ietf.org; Tue, 30 May 2006 14:39:49 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4UIcvR07666; Tue, 30 May 2006 11:38:57 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.6/8.13.6/Submit) id k4UIcvk1001889; Tue, 30 May 2006 11:38:57 -0700 (PDT) (envelope-from faber) Date: Tue, 30 May 2006 11:38:57 -0700 From: Ted Faber To: Mark Allman Subject: Re: [tcpm] Re: Montreal meeting Message-ID: <20060530183857.GB1309@hut.isi.edu> References: <20060530175643.3146977A71D@guns.icir.org> <20060530175936.GL69771@hut.isi.edu> Mime-Version: 1.0 In-Reply-To: <20060530175936.GL69771@hut.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@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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="===============0079380743==" Errors-To: tcpm-bounces@ietf.org --===============0079380743== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gj572EiMnwbLXET9" Content-Disposition: inline --gj572EiMnwbLXET9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 30, 2006 at 10:59:36AM -0700, Ted Faber wrote: > On Tue, May 30, 2006 at 01:56:43PM -0400, Mark Allman wrote: > > =20 > > Folks- > >=20 > > We need to put in our slot request for Montreal by Jun/5. If you want > > to contribute to our "WGs to avoid conflicts with" list please send Ted > > and I a note. >=20 > Yes, thats tcpm-charis@tools.ietf.org - operators are standing by. tcpm-chairs@tools.ietf.org Sorry, --=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 --gj572EiMnwbLXET9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEfJFBaUz3f+Zf+XsRAmEWAKDDVrUCR1AdMokTwbwbMwvsSIv+MQCgv2FM /StntV+YAEMYpKL4SYcBZZc= =aKjE -----END PGP SIGNATURE----- --gj572EiMnwbLXET9-- --===============0079380743== 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 --===============0079380743==-- From tcpm-bounces@ietf.org Tue May 30 15:55:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlAIh-0008C9-Fc; Tue, 30 May 2006 15:54:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlAIg-0008C2-4Y for tcpm@ietf.org; Tue, 30 May 2006 15:54:46 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl9Nh-0008Nc-GA for tcpm@ietf.org; Tue, 30 May 2006 14:55:53 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fl943-0000jS-IR for tcpm@ietf.org; Tue, 30 May 2006 14:35:38 -0400 Received: from [70.215.46.25] (25.sub-70-215-46.myvzw.com [70.215.46.25]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4UIYnI08215; Tue, 30 May 2006 11:34:49 -0700 (PDT) Message-ID: <447C9040.4060606@isi.edu> Date: Tue, 30 May 2006 11:34:40 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] Re: WGLC on antispoof -- ICMP filtering speculation References: <20060517034349.BE52C40F5AE@lawyers.icir.org> <447B25E7.50901@isi.edu> <7.0.1.0.0.20060529224729.049b4618@gont.com.ar> In-Reply-To: <7.0.1.0.0.20060529224729.049b4618@gont.com.ar> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: -2.6 (--) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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="===============2032887997==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2032887997== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig09523D97E3E562D1816DE33D" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig09523D97E3E562D1816DE33D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > At 13:48 29/05/2006, Joe Touch wrote: >=20 >> > .. it seems that "As a result" is speculative. I don't know why peo= ple >> > filter ICMPs; because there is no reference, I suspect you don't kno= w >> > either. >> >> I'll add a citation to RFC4301, which asserts these reasons (without >> citation, FWIW). >=20 > That's in the context of IPSec. How much of the traffic in the Internet= > corresponds to IPSec'ed traffic? IPsec explains security reasons for discarding ICMPs. That's what you're doing as well. > Also, from that perspective, the antispoof draft should be one-page > long, and would just mention something "if you are concerned about > in-window attacks, use IPSec". To the extent that it makes recommendations, it probably is. The rest explains the attack and other solutions and properties thereof. >> > But that seems irrelevant to this particular document, as there is n= o >> > way to know what the current or original motivations for filtering >> ICMPs >> > were. Hence, I'd reword the latter sentence or remove it completely= =2E >> > If rewording, I'd be careful not to imply that the IETF thinks >> filtering >> > all ICMP messages is a valid configuration... >> >> Can you recheck this suggestion in light of RFC4301 and repost? >=20 > IIRC, from the last time I looked at the IPSec specs, there's no > recommendation on whether to filter or not to filter. The specs just > state there should be a system toggle to decide what to do, and do not > even specify what the default should be. That's correct. > Thus, I don't understand how can you take that as a recommendation for > ICMP filtering. The recommendation is that if you don't trust ICMP, filter it out entirely. The recommendation comes with the caveat that if you want to be responsive, you need to accept unauthenticated ICMPs since there is no way to authenticate them sufficiently. It's a choice that's up to you - but if you don't trust ICMP, the choice is very clear. Joe --------------enig09523D97E3E562D1816DE33D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEfJBAE5f5cImnZrsRAoMEAKCDKoKpe4GcljOBGCD5klnlJTsB3gCfR/j+ QnYy3AhIXNnVPg8XAlE9fkc= =zyO9 -----END PGP SIGNATURE----- --------------enig09523D97E3E562D1816DE33D-- --===============2032887997== 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 --===============2032887997==-- From tcpm-bounces@ietf.org Tue May 30 16:16:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlAdy-0007gf-D2; Tue, 30 May 2006 16:16:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlAdw-0007gZ-LT for tcpm@ietf.org; Tue, 30 May 2006 16:16:44 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlAdr-0000Do-93 for tcpm@ietf.org; Tue, 30 May 2006 16:16:44 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id NAA11961; Tue, 30 May 2006 13:16:27 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k4UKGQ315920; Tue, 30 May 2006 15:16:26 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 May 2006 13:16:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] Re: WGLC on antispoof -- ICMP filtering speculation Date: Tue, 30 May 2006 13:16:22 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1818C77@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <447C9040.4060606@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Re: WGLC on antispoof -- ICMP filtering speculation Thread-Index: AcaEJPGmssSlDzsXRxq0cuxZAa6glwAAIFjQ From: "Templin, Fred L" To: "Joe Touch" , "Fernando Gont" X-OriginalArrivalTime: 30 May 2006 20:16:24.0074 (UTC) FILETIME=[EC5BE6A0:01C68425] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Joe, >> Thus, I don't understand how can you take that as a recommendation for >> ICMP filtering. > > The recommendation is that if you don't trust ICMP, filter it out > entirely. The recommendation comes with the caveat that if you want to > be responsive, you need to accept unauthenticated ICMPs since there is > no way to authenticate them sufficiently. It's a choice that's up to you > - but if you don't trust ICMP, the choice is very clear. My only comment here is that things in our imperfect world are very rarely black-and-white; they are almost always shades of gray... Fred fred.l.templin@boeing.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue May 30 16:27:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlAoW-0002kH-HJ; Tue, 30 May 2006 16:27:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlAoU-0002kC-V3 for tcpm@ietf.org; Tue, 30 May 2006 16:27:38 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlAoT-0000U4-Jk for tcpm@ietf.org; Tue, 30 May 2006 16:27:38 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4UKRDR12046; Tue, 30 May 2006 13:27:13 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.6/8.13.6/Submit) id k4UKRDW7033935; Tue, 30 May 2006 13:27:13 -0700 (PDT) (envelope-from faber) Date: Tue, 30 May 2006 13:27:13 -0700 From: Ted Faber To: Joe Touch Subject: Re: [tcpm] Re: WGLC on antispoof -- ICMP filtering speculation Message-ID: <20060530202713.GI1309@hut.isi.edu> References: <20060517034349.BE52C40F5AE@lawyers.icir.org> <447B25E7.50901@isi.edu> <7.0.1.0.0.20060529224729.049b4618@gont.com.ar> <447C9040.4060606@isi.edu> Mime-Version: 1.0 In-Reply-To: <447C9040.4060606@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@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: tcpm@ietf.org, Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2108176923==" Errors-To: tcpm-bounces@ietf.org --===============2108176923== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2nTeH+t2PBomgucg" Content-Disposition: inline --2nTeH+t2PBomgucg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 30, 2006 at 11:34:40AM -0700, Joe Touch wrote: > Fernando Gont wrote: > > At 13:48 29/05/2006, Joe Touch wrote: > > Thus, I don't understand how can you take that as a recommendation for > > ICMP filtering. >=20 > The recommendation is that if you don't trust ICMP, filter it out > entirely. The recommendation comes with the caveat that if you want to > be responsive, you need to accept unauthenticated ICMPs since there is > no way to authenticate them sufficiently. It's a choice that's up to you > - but if you don't trust ICMP, the choice is very clear. Just for clarity, are you asserting that that recommendation is articulated by 4301 or that "all right-thinking networkers" should see it that way? The as anti-spoof is a TCPM document, recommedations like this are what we're looking for rough consensus on. --=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 --2nTeH+t2PBomgucg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEfKqhaUz3f+Zf+XsRApOHAJ9YMK5C2fLcSPrElkryToUOJgQ+qwCghG6s zvz7XzTc4T0uuvm9iah/NSo= =hbSq -----END PGP SIGNATURE----- --2nTeH+t2PBomgucg-- --===============2108176923== 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 --===============2108176923==-- From tcpm-bounces@ietf.org Tue May 30 20:17:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlENu-0004cF-Ht; Tue, 30 May 2006 20:16:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlENt-0004cA-2I for tcpm@ietf.org; Tue, 30 May 2006 20:16:25 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlENr-0006ZX-NX for tcpm@ietf.org; Tue, 30 May 2006 20:16:25 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4V0FBI25994; Tue, 30 May 2006 17:15:11 -0700 (PDT) Message-ID: <447CE009.5050503@isi.edu> Date: Tue, 30 May 2006 17:15:05 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Ted Faber Subject: Re: [tcpm] Re: WGLC on antispoof -- ICMP filtering speculation References: <20060517034349.BE52C40F5AE@lawyers.icir.org> <447B25E7.50901@isi.edu> <7.0.1.0.0.20060529224729.049b4618@gont.com.ar> <447C9040.4060606@isi.edu> <20060530202713.GI1309@hut.isi.edu> In-Reply-To: <20060530202713.GI1309@hut.isi.edu> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: tcpm@ietf.org, Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0935536831==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0935536831== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig307ED290D674735BA6B00422" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig307ED290D674735BA6B00422 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ted Faber wrote: > On Tue, May 30, 2006 at 11:34:40AM -0700, Joe Touch wrote: >> Fernando Gont wrote: >>> At 13:48 29/05/2006, Joe Touch wrote: >>> Thus, I don't understand how can you take that as a recommendation fo= r >>> ICMP filtering. >> The recommendation is that if you don't trust ICMP, filter it out >> entirely. The recommendation comes with the caveat that if you want to= >> be responsive, you need to accept unauthenticated ICMPs since there is= >> no way to authenticate them sufficiently. It's a choice that's up to y= ou >> - but if you don't trust ICMP, the choice is very clear. >=20 > Just for clarity, are you asserting that that recommendation is > articulated by 4301 or that "all right-thinking networkers" should see > it that way? I'm saying that the security folk saw it that way. > The as anti-spoof is a TCPM document, recommedations like this are what= > we're looking for rough consensus on. Rough consensus (and running code) are for specs. The doc makes no recommendations as to how to handle ICMP attacks anyway, so it isn't clear how that issue applies. Joe --------------enig307ED290D674735BA6B00422 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEfOAJE5f5cImnZrsRApCsAKDIB7vxAfSwMjvq1IWGG8pMcfZPJwCg9ruy eHIUAKua0oPSdFhPm0WLfYk= =gl8m -----END PGP SIGNATURE----- --------------enig307ED290D674735BA6B00422-- --===============0935536831== 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 --===============0935536831==-- From tcpm-bounces@ietf.org Tue May 30 20:28:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlEZV-0002wD-DH; Tue, 30 May 2006 20:28:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlEZT-0002vk-LI for tcpm@ietf.org; Tue, 30 May 2006 20:28:23 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlEZS-0007lN-95 for tcpm@ietf.org; Tue, 30 May 2006 20:28:23 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4V0R6I28217; Tue, 30 May 2006 17:27:06 -0700 (PDT) Message-ID: <447CE2D5.3070300@isi.edu> Date: Tue, 30 May 2006 17:27:01 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Templin, Fred L" Subject: Re: [tcpm] Re: WGLC on antispoof -- ICMP filtering speculation References: <39C363776A4E8C4A94691D2BD9D1C9A1818C77@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1818C77@XCH-NW-7V2.nw.nos.boeing.com> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: tcpm@ietf.org, Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0027722573==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0027722573== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5F70C1B0F1F4C726366FB776" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5F70C1B0F1F4C726366FB776 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Templin, Fred L wrote: > Joe, >=20 >>> Thus, I don't understand how can you take that as a recommendation > for >>> ICMP filtering. >> The recommendation is that if you don't trust ICMP, filter it out >> entirely. The recommendation comes with the caveat that if you want to= >> be responsive, you need to accept unauthenticated ICMPs since there is= >> no way to authenticate them sufficiently. It's a choice that's up to > you >> - but if you don't trust ICMP, the choice is very clear. >=20 > My only comment here is that things in our imperfect world > are very rarely black-and-white; they are almost always > shades of gray... In IPsec, they're black-and-white on a per-type (MUST) and possibly also per code (MAY) basis. There are also provisions for dealing with them on a per-address basis, e.g., to discriminate between addresses inside trusted domains with presumably trusted paths to the local domain, vs. others. However, my commercial DSL box basically just shuts them all off (in high security mode). This is my understanding of how many firewalls treat ICMPs (CAIDA papers, NLANR papers, NANOG discussions all refer to this). Joe --------------enig5F70C1B0F1F4C726366FB776 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEfOLVE5f5cImnZrsRAvHcAJ9mE72G3fV2FENnRb0Un7K5zq+CJgCcDEqQ rSI2LgSwymR7rvIjkqqr0QI= =si/P -----END PGP SIGNATURE----- --------------enig5F70C1B0F1F4C726366FB776-- --===============0027722573== 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 --===============0027722573==-- From tcpm-bounces@ietf.org Tue May 30 20:45:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlEqG-0002xU-7h; Tue, 30 May 2006 20:45:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlEqE-0002xP-Vy for tcpm@ietf.org; Tue, 30 May 2006 20:45:42 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlEqD-0002hQ-Jv for tcpm@ietf.org; Tue, 30 May 2006 20:45:42 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4V0j4R04561; Tue, 30 May 2006 17:45:04 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.6/8.13.6/Submit) id k4V0j4HY090317; Tue, 30 May 2006 17:45:04 -0700 (PDT) (envelope-from faber) Date: Tue, 30 May 2006 17:45:04 -0700 From: Ted Faber To: Joe Touch Subject: Re: [tcpm] Re: WGLC on antispoof -- ICMP filtering speculation Message-ID: <20060531004504.GL1309@hut.isi.edu> References: <20060517034349.BE52C40F5AE@lawyers.icir.org> <447B25E7.50901@isi.edu> <7.0.1.0.0.20060529224729.049b4618@gont.com.ar> <447C9040.4060606@isi.edu> <20060530202713.GI1309@hut.isi.edu> <447CE009.5050503@isi.edu> Mime-Version: 1.0 In-Reply-To: <447CE009.5050503@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@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: tcpm@ietf.org, Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1066934127==" Errors-To: tcpm-bounces@ietf.org --===============1066934127== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="t5C3/nrmPumNj5sH" Content-Disposition: inline --t5C3/nrmPumNj5sH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 30, 2006 at 05:15:05PM -0700, Joe Touch wrote: >=20 >=20 > Ted Faber wrote: > > On Tue, May 30, 2006 at 11:34:40AM -0700, Joe Touch wrote: > >> Fernando Gont wrote: > >>> At 13:48 29/05/2006, Joe Touch wrote: > >>> Thus, I don't understand how can you take that as a recommendation for > >>> ICMP filtering. > >> The recommendation is that if you don't trust ICMP, filter it out > >> entirely. The recommendation comes with the caveat that if you want to > >> be responsive, you need to accept unauthenticated ICMPs since there is > >> no way to authenticate them sufficiently. It's a choice that's up to y= ou > >> - but if you don't trust ICMP, the choice is very clear. > >=20 > > Just for clarity, are you asserting that that recommendation is > > articulated by 4301 or that "all right-thinking networkers" should see > > it that way? >=20 > I'm saying that the security folk saw it that way. You're saying that RFC 4301 recommends filtering ICMP if the administrative domain that controls the filters does not trust ICMP? You're saying that your sense of the security community is that they recommend filtering ICMP if the administrative domain that controls the filters does not trust ICMP? Or you're saying something else? >=20 > > The as anti-spoof is a TCPM document, recommedations like this are what > > we're looking for rough consensus on. >=20 > Rough consensus (and running code) are for specs. The doc makes no > recommendations as to how to handle ICMP attacks anyway, so it isn't > clear how that issue applies. Rough consensus of the WG is for WG documents; that's why there's a WGLC. Rough consensus of the IETF is for standards; that's not required for (all) Informationals/BCPs. --=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 --t5C3/nrmPumNj5sH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEfOcQaUz3f+Zf+XsRArLDAJ9PfF4nwTx1vvl014Q9JVQpQ9idFwCgwmh5 SVaut7tc4dRdBablWb73wFw= =TUKh -----END PGP SIGNATURE----- --t5C3/nrmPumNj5sH-- --===============1066934127== 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 --===============1066934127==-- From tcpm-bounces@ietf.org Tue May 30 21:23:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlFPv-00023Q-Pm; Tue, 30 May 2006 21:22:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlFPu-00023K-87 for tcpm@ietf.org; Tue, 30 May 2006 21:22:34 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlFPs-0005TT-TD for tcpm@ietf.org; Tue, 30 May 2006 21:22:34 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4V1LTI09564; Tue, 30 May 2006 18:21:29 -0700 (PDT) Message-ID: <447CEF93.3010400@isi.edu> Date: Tue, 30 May 2006 18:21:23 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Ted Faber Subject: Re: [tcpm] Re: WGLC on antispoof -- ICMP filtering speculation References: <20060517034349.BE52C40F5AE@lawyers.icir.org> <447B25E7.50901@isi.edu> <7.0.1.0.0.20060529224729.049b4618@gont.com.ar> <447C9040.4060606@isi.edu> <20060530202713.GI1309@hut.isi.edu> <447CE009.5050503@isi.edu> <20060531004504.GL1309@hut.isi.edu> In-Reply-To: <20060531004504.GL1309@hut.isi.edu> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: tcpm@ietf.org, Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0363363946==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0363363946== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig367705DB8ADA03AEEB6693A3" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig367705DB8ADA03AEEB6693A3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ted Faber wrote: =2E.. > You're saying that RFC 4301 recommends filtering ICMP if the > administrative domain that controls the filters does not trust ICMP? > > You're saying that your sense of the security community is that they > recommend filtering ICMP if the administrative domain that controls the= > filters does not trust ICMP? >=20 > Or you're saying something else? 4301 says, basically, that ICMPs present a conundrum: - accepting them presents a way to degrade service (an attack) - dropping them degrades service (sort of like you're attacking yourself)= It suggests that dropping ICMPs is also needed inside from 'trusted domains', since one compromised node can affect others. I.e., there still needs to be a way to drop the ICMPs, but still dropping is itself a service issue. It lets you pick. If the trust of ICMP is the issue, then drop them. If dropping them is more of an attack, then don't. --- The key question here is whether there is any real disagreement that dropping all ICMPs is the first and most prevalent line of defense from attack. The doc isn't recommending it, but it is stating that. Is that something we need to have 'rough consensus' on? If so, can some others please start reading the CAIDA/NLANR/NANOG docs and meeting notes, so we can proceed? Joe --------------enig367705DB8ADA03AEEB6693A3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEfO+TE5f5cImnZrsRAsUeAKCz+GMYnbMeVFqdf8o56cUWRj/eiACfeRes YOU1vE0Lk//Ed+ljSv6bb2A= =/48j -----END PGP SIGNATURE----- --------------enig367705DB8ADA03AEEB6693A3-- --===============0363363946== 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 --===============0363363946==-- From tcpm-bounces@ietf.org Tue May 30 22:48:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlGkM-0002dw-Ox; Tue, 30 May 2006 22:47:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlGkL-0002cz-9s for tcpm@ietf.org; Tue, 30 May 2006 22:47:45 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlGkJ-0005Sd-TA for tcpm@ietf.org; Tue, 30 May 2006 22:47:45 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4V2l8R06970; Tue, 30 May 2006 19:47:08 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.6/8.13.6/Submit) id k4V2l8s0092471; Tue, 30 May 2006 19:47:08 -0700 (PDT) (envelope-from faber) Date: Tue, 30 May 2006 19:47:08 -0700 From: Ted Faber To: Joe Touch Subject: Re: [tcpm] Re: WGLC on antispoof -- ICMP filtering speculation Message-ID: <20060531024708.GB90801@hut.isi.edu> References: <20060517034349.BE52C40F5AE@lawyers.icir.org> <447B25E7.50901@isi.edu> <7.0.1.0.0.20060529224729.049b4618@gont.com.ar> <447C9040.4060606@isi.edu> <20060530202713.GI1309@hut.isi.edu> <447CE009.5050503@isi.edu> <20060531004504.GL1309@hut.isi.edu> <447CEF93.3010400@isi.edu> Mime-Version: 1.0 In-Reply-To: <447CEF93.3010400@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@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: tcpm@ietf.org, Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0273531425==" Errors-To: tcpm-bounces@ietf.org --===============0273531425== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wq9mPyueHGvFACwf" Content-Disposition: inline --wq9mPyueHGvFACwf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 30, 2006 at 06:21:23PM -0700, Joe Touch wrote: >=20 >=20 > Ted Faber wrote: > ... > > You're saying that RFC 4301 recommends filtering ICMP if the > > administrative domain that controls the filters does not trust ICMP? > > > > You're saying that your sense of the security community is that they > > recommend filtering ICMP if the administrative domain that controls the > > filters does not trust ICMP? > >=20 > > Or you're saying something else? >=20 > 4301 says, basically, that ICMPs present a conundrum: >=20 > - accepting them presents a way to degrade service (an attack) >=20 > - dropping them degrades service (sort of like you're attacking yourself) >=20 > It suggests that dropping ICMPs is also needed inside from 'trusted > domains', since one compromised node can affect others. I.e., there > still needs to be a way to drop the ICMPs, but still dropping is itself > a service issue. >=20 > It lets you pick. If the trust of ICMP is the issue, then drop them. If > dropping them is more of an attack, then don't. That's a nice description of the tradeoff that an administrative domain's administrator could make their decisions from, IMHO. > The key question here is whether there is any real disagreement that > dropping all ICMPs is the first and most prevalent line of defense from > attack. The doc isn't recommending it, but it is stating that. Well, it seems to be a bone of some contention, or I'd be back at the WG chairs' palace indulging in all sorts of IETF-financed debauchery instead of typing an e-mail by fading daylight in an ISI oubliette, trying to clarify the issue. It seems logical to me that blocking ICMP would be the first thing to do if you distrusted those messages, but I can also imagine mitigating circumstances that would lead admins to make their borders more porous. The world is weirder than I'd like it to be. It seems certain that some admins will block all ICMP to deal with concerns about ICMP. Is this a key issue in the document? Is it important to make the stronger case that this is the prevalent condition? What happens if that changes tomorrow? Do the document's claims change fundamentally? If not, why not omit the prevalence claim and describe ICMP blocking as a common (or logical) defense having the drawbacks you describe clearly above? If it matters, lets get at the truth. If it doesn't, we have no shortage of arguments in this group. --=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 --wq9mPyueHGvFACwf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEfQOsaUz3f+Zf+XsRAs1aAJ9bej4K30JG0z+jXnXXjucPaYQFPACg6vAw FGhUWcV70efHrsdnfojzBL8= =BSbH -----END PGP SIGNATURE----- --wq9mPyueHGvFACwf-- --===============0273531425== 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 --===============0273531425==-- From tcpm-bounces@ietf.org Wed May 31 00:36:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlIQS-0003MN-6w; Wed, 31 May 2006 00:35:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlIQQ-0003MD-OM for tcpm@ietf.org; Wed, 31 May 2006 00:35:18 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlIQO-0005iN-BS for tcpm@ietf.org; Wed, 31 May 2006 00:35:18 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4V4YCI17502; Tue, 30 May 2006 21:34:12 -0700 (PDT) Message-ID: <447D1CBF.7060004@isi.edu> Date: Tue, 30 May 2006 21:34:07 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Ted Faber Subject: Re: [tcpm] Re: WGLC on antispoof -- ICMP filtering speculation References: <20060517034349.BE52C40F5AE@lawyers.icir.org> <447B25E7.50901@isi.edu> <7.0.1.0.0.20060529224729.049b4618@gont.com.ar> <447C9040.4060606@isi.edu> <20060530202713.GI1309@hut.isi.edu> <447CE009.5050503@isi.edu> <20060531004504.GL1309@hut.isi.edu> <447CEF93.3010400@isi.edu> <20060531024708.GB90801@hut.isi.edu> In-Reply-To: <20060531024708.GB90801@hut.isi.edu> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: tcpm@ietf.org, Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1423122393==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1423122393== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig142A0E5F22A3F00C5E668205" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig142A0E5F22A3F00C5E668205 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ted Faber wrote: > On Tue, May 30, 2006 at 06:21:23PM -0700, Joe Touch wrote: >> >> Ted Faber wrote: >> ... >>> You're saying that RFC 4301 recommends filtering ICMP if the >>> administrative domain that controls the filters does not trust ICMP? >>> >>> You're saying that your sense of the security community is that they >>> recommend filtering ICMP if the administrative domain that controls t= he >>> filters does not trust ICMP? >>> >>> Or you're saying something else? >> 4301 says, basically, that ICMPs present a conundrum: >> >> - accepting them presents a way to degrade service (an attack) >> >> - dropping them degrades service (sort of like you're attacking yourse= lf) >> >> It suggests that dropping ICMPs is also needed inside from 'trusted >> domains', since one compromised node can affect others. I.e., there >> still needs to be a way to drop the ICMPs, but still dropping is itsel= f >> a service issue. >> >> It lets you pick. If the trust of ICMP is the issue, then drop them. I= f >> dropping them is more of an attack, then don't. >=20 > That's a nice description of the tradeoff that an administrative > domain's administrator could make their decisions from, IMHO. >=20 >> The key question here is whether there is any real disagreement that >> dropping all ICMPs is the first and most prevalent line of defense fro= m >> attack. The doc isn't recommending it, but it is stating that. >=20 > Well, it seems to be a bone of some contention, or I'd be back at the > WG chairs' palace indulging in all sorts of IETF-financed debauchery > instead of typing an e-mail by fading daylight in an ISI oubliette, > trying to clarify the issue. >=20 > It seems logical to me that blocking ICMP would be the first thing to d= o > if you distrusted those messages, but I can also imagine mitigating > circumstances that would lead admins to make their borders more porous.= > The world is weirder than I'd like it to be. >=20 > It seems certain that some admins will block all ICMP to deal with > concerns about ICMP. Is this a key issue in the document? Is it > important to make the stronger case that this is the prevalent > condition? What happens if that changes tomorrow? Do the document's > claims change fundamentally? If not, why not omit the prevalence claim= > and describe ICMP blocking as a common (or logical) defense having the > drawbacks you describe clearly above? That's what I would suggest. Mitigated blocking - by opening up on type, type+code, or making it TCP-connection context-dependent are all variants of opening things up that should be noted there. > If it matters, lets get at the truth. If it doesn't, we have no > shortage of arguments in this group. Agreed. Joe --------------enig142A0E5F22A3F00C5E668205 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEfRy/E5f5cImnZrsRAoCVAJ9I6uurkpS4uqhX44zGnMUWuA+xZwCgqR11 qUfOfpsAD2isLkhnkLZX9GY= =sJEO -----END PGP SIGNATURE----- --------------enig142A0E5F22A3F00C5E668205-- --===============1423122393== 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 --===============1423122393==-- From tcpm-bounces@ietf.org Wed May 31 02:41:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlKNp-00017K-T2; Wed, 31 May 2006 02:40:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlKNo-00017D-0o for tcpm@ietf.org; Wed, 31 May 2006 02:40:44 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlKNl-0008CN-Ay for tcpm@ietf.org; Wed, 31 May 2006 02:40:44 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060308/8.12.11) with ESMTP id k4V6eXQu030283; Wed, 31 May 2006 09:40:33 +0300 Date: Wed, 31 May 2006 09:40:33 +0300 (EEST) From: Pekka Savola To: Joe Touch In-Reply-To: <447B24ED.1020307@isi.edu> Message-ID: References: <20060517034349.BE52C40F5AE@lawyers.icir.org> <447B24ED.1020307@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1500/Tue May 30 23:47:36 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: tcpm@ietf.org Subject: [tcpm] Re: WGLC on antispoof -- TTL checking X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Mon, 29 May 2006, Joe Touch wrote: >> >> The text in section 3.2.1 about TTL checking is still misleading or >> incorrect. Do you mean both you and your peer with "those nodes" in "or >> any traffic those nodes accept via tunnels - because tunnels need not >> decrement TTLs"? Either way, this gets back to whether your peer is >> complying to RFC 791, i.e., decrementing the TTL for packets which it >> forwards. There is no difference whether the link is physical or an IP >> tunnel. Tunnel head-end decrements the TTL if it forwards a packet to >> the tunnel; tunnel tail-end decrements the TTL if it forwards a packet >> out of the tunnel. TTL is unchanged for packets at the end which is >> originating or receiving packets. Exactly like physical interfaces. > > See section 3.1 of RFC2003; whether the TTL is decremented depends on > whether forwarding is considered part of the operation, and this is a > choice, not fixed. > > Can you evaluate the remainder of this note in the context of RFC2003 > and let us know if there is still an inconsistency? In my opinion, RFC 2003 section 3.1 (specifically the third-to-last and second-to-last paragraphs) says exactly the same thing as I say. The TTL is decremented if tunneling is a step in forwarding a datagram, not otherwise. Just like with a physical interface. The bottom line is that a compliant RFC 2003 encapsulator will decrement TTL for packets which it forwards. -- 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 Wed May 31 03:13:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlKtg-0004xV-Lv; Wed, 31 May 2006 03:13:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlKtf-0004xQ-T4 for tcpm@ietf.org; Wed, 31 May 2006 03:13:39 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlKte-0002vo-I3 for tcpm@ietf.org; Wed, 31 May 2006 03:13:39 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060308/8.12.11) with ESMTP id k4V7DW6a031752; Wed, 31 May 2006 10:13:32 +0300 Date: Wed, 31 May 2006 10:13:32 +0300 (EEST) From: Pekka Savola To: Joe Touch In-Reply-To: <447B2427.9020908@isi.edu> Message-ID: References: <20060517034349.BE52C40F5AE@lawyers.icir.org> <447B2427.9020908@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1500/Tue May 30 23:47:36 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Cc: tcpm@ietf.org Subject: [tcpm] Re: WGLC on antispoof -- address filtering X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Mon, 29 May 2006, Joe Touch wrote: >>> 1) address filtering text is still technically incorrect or assumptive > > It would be useful to provide candidate substitute text. In fact, I already did in my last round of comments, so I didn't re-post it. For convenience, I'll put that at the end of this note. >> Specifically, the statement (and follow-up text): >> >> "It cannot restrict traffic from edges lacking filtering through the >> core to a particular edge, i.e., from upstream sources." >> >> is not correct. > > Assume you provide filtering from upstream sources that do not > themselves filter (the opposite). Any traffic that appears sourced from > upstream could have been spoofed. > > Can you explain how to provide filtering in this case? In the interfaces towards upstream, in input filter, block your own or your singlehomed customers' IP addresses from being used as source addresses. This does not provide spoofing filtering for sources which are legitimately upstream, but it does prevent from TCP-RST attacks from upstream for sessions which are internal your network, which is what I've been saying. We've been doing this (and a lot of other filtering) for years. >> In response to previous comments, the editor said: >> >> "I disagree that "you can _yourself_ do the filting, without relying on >> anyone else", except in trivial multiconnected stub network cases." >> >> The last part may or may not be key to understanding and resolving the >> disagreement. >> >> I assert that an ISP can protect its own and its single-homed customers' >> sessions which are internal to the ISP by making sure its own borders >> are properly secure. > > What percent of connections are internal to the ISP? Protecting only > that small fraction of connections is not sufficient. 100% of iBGP, (non-discovery) LDP, telnet/SSH to the routers, or various other infrastructure uses are internal by that definition. Which is my point -- in some cases, it's an invaluable tool. I don't know that percentage, I'd assume it varies greatly depending on the region you're in, the size of the ISP, the application you're using (e.g., peer-to-peer has much higher rate), etc. (In practice, the practical non-spoofing boundary might be even wider, because at least some countries even have regulations which require spoofing prevention, so even all the internal traffic could end up being protected.) >> I also claim that multihomed sites can do this on >> their own borders to protect their internal sessions. > > That's essentially a restatement of the exception I provided (internal > sessions treat the net as a stub). Certainly. ISP case above is just a generalization of that. However, my point is that while that might not protect from sessions from the site to www.google.com, it could protect from various internal communications from outsider interference, or even spoofing inside the site if ingress filtering is applied on every link inside the site. >> Hence, "internal >> sessions" in an administrative domain that cares about setting up proper >> security can be protected from TCP RST attacks. See the assumptions in >> Section 1 of draft-savola-rtgwg-backbone-attacks-00.txt for more on how >> this helps an ISP. >> >> I'd estimate that over 95% of net users are single-homed by that >> definition, though the amount of traffic that's "internal" is arguably >> limited. Hence, this is an important scenario especially if you >> consider *infrastructure* uses (which are typically internal, such as >> BGP) and needs to be properly addressed instead of just waived away as a >> trivial case. > > This text is self-contradictory; I agree that a large percentage (though > 95% seems arbitrary, and would need a reference to include) of users are > single-homed, but the larger issue is the percent of internal traffic. The actual amount is not important, it's sufficient that we agree that most users are single-homed. I also agree that the much larger issue is the percentage of internal traffic. As I said, it varies a LOT. But it's indisputable that there are very important (e.g., infrastructure, server-to-server or router-to-router communications, etc.) uses that ARE in fact strictly internal. The presence of these alone is IMHO sufficient justification of properly discussing address filtering. > One would hope that BGP would not be internal (it wouldn't be very > effective). Once it originates outside your border, you're trusting the > party one stream up to filter - even for BGP. BGP has at least two things to secure: the transport protocol (e.g., TCP layer) and the routing data itself. The TCP layer of internal BGP sessions can be completely protected with address filtering. The TCP layer of external BGP sessions can be almost completely protected by address/TTL filtering. The routing data protection is out of scope of this WG, but in fact, the same basic route hijacking prevention techniques apply. For more general BGP routing data protection, RPSL and friedns have been used in some parts of the world, but there is not SIDR WG which is looking at this from certificate point of view. [*] -- copy from the comments on -02 which suggested text: " ... In order to try to converge on the text faster, let me try to suggest text which I think should be more accurate and I'd find acceptable. ================ 3.2. Network Layer (IP) Solutions There are two primary variants of network layer solutions to spoofing: address filtering and IPsec. Address filtering provides protection from spoofing for sessions which are internal to the set of domains where address filtering is applied. IPsec requires cooperation between the endpoints wanting to avoid attack on their connection, which currently involves pre-existing shared knowledge of either a shared key or shared certificate authority. 3.2.1. Address and TTL filtering Address filtering is often proposed as an alternative to protocol mechanisms to defeat IP source address spoofing [2][12]. Address filtering is deployed both at the downstream interfaces and at the upstream/peer interfaces. The former prevents all spoofing from the downstream direction; the latter prevents only upstream sources from spoofing your (or your downstreams') source addresses. Each border router should perform the appropriate filtering for overall protection to result; failure of any border router to filter opens a hole inside that border. Address filtering at the border can protect those inside it from some kinds of spoofing, because only interior addresses should originate inside the border. It cannot, however, protect connections originating outside the border except to restrict where the traffic enters from, e.g., if it expected from one AS and not another. As a result, address filtering can be deployed locally but it only protects communications where both parties are local. Therefore, the larger the address filtering border is, the more extensive the protection is. This is a particularly useful means of protection for specific kinds of sessions which are known to be local. However, as address filtering is performed in the network by trusted gateways, the users not know whether the filtering exists or not. Hence, the users cannot rely on it in general and other mechanisms for protection must be used as well. Still, address filtering is very useful to protect specific kinds of communications (e.g., network management, most router-to-router communication, etc.). A more recent variant of address filtering checks the IP TTL field, relying on the TTL set by the other end of the connection [14]. This technique has been used to provide filtering for BGP. It assumes the connection source TTL is set to 255; packets at the receiver are checked for TTL=255, and others are dropped. This restricts traffic to one hop upstream of the receiver (i.e., a BGP router), but those hops could include other user programs at those nodes (e.g., the BGP router's peer). This method of filtering works best where traffic originates one hop away, so that the address filtering is based on the trust of only directly-connected (tunneled or otherwise) nodes. Like conventional address filtering, this light-weight mechanism reduces spoofing traffic in general and provides a reliable security mechanism if peer can be trusted to operate correctly (see Section 5.1 of [14]). On the other hand, if the peer does not operate correctly, it is just shooting itself in the foot by allowing its sessios to be reset. ================ " -- 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 Wed May 31 10:29:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlRhP-0007hs-OK; Wed, 31 May 2006 10:29:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlRhO-0007hn-US for tcpm@ietf.org; Wed, 31 May 2006 10:29:26 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlRhN-0000GG-Hz for tcpm@ietf.org; Wed, 31 May 2006 10:29:26 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4VESPI10700; Wed, 31 May 2006 07:28:25 -0700 (PDT) Message-ID: <447DA804.8080406@isi.edu> Date: Wed, 31 May 2006 07:28:20 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Pekka Savola References: <20060517034349.BE52C40F5AE@lawyers.icir.org> <447B24ED.1020307@isi.edu> In-Reply-To: X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: tcpm@ietf.org Subject: [tcpm] Re: WGLC on antispoof -- TTL checking 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="===============2027239353==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2027239353== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig50747E301621B50C40AA4DF1" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig50747E301621B50C40AA4DF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pekka Savola wrote: > On Mon, 29 May 2006, Joe Touch wrote: >>> >>> The text in section 3.2.1 about TTL checking is still misleading or >>> incorrect. Do you mean both you and your peer with "those nodes" in = "or >>> any traffic those nodes accept via tunnels - because tunnels need not= >>> decrement TTLs"? Either way, this gets back to whether your peer is >>> complying to RFC 791, i.e., decrementing the TTL for packets which it= >>> forwards. There is no difference whether the link is physical or an = IP >>> tunnel. Tunnel head-end decrements the TTL if it forwards a packet t= o >>> the tunnel; tunnel tail-end decrements the TTL if it forwards a packe= t >>> out of the tunnel. TTL is unchanged for packets at the end which is >>> originating or receiving packets. Exactly like physical interfaces. >> >> See section 3.1 of RFC2003; whether the TTL is decremented depends on >> whether forwarding is considered part of the operation, and this is a >> choice, not fixed. >> >> Can you evaluate the remainder of this note in the context of RFC2003 >> and let us know if there is still an inconsistency? >=20 > In my opinion, RFC 2003 section 3.1 (specifically the third-to-last and= > second-to-last paragraphs) says exactly the same thing as I say. The TT= L > is decremented if tunneling is a step in forwarding a datagram, not > otherwise. Just like with a physical interface. The bottom line is > that a compliant RFC 2003 encapsulator will decrement TTL for packets > which it forwards. (presumably you mean decapsulator, not the encapsulator) RFC2003, sec 3.1, third-to-last (emphasis mine): When encapsulating a datagram, the TTL in the inner IP header is decremented by one **if the tunneling is being done as part of forwarding the datagram**; **otherwise, the inner header TTL is not changed during encapsulation**. If the resulting TTL in the inner IP header is 0, the datagram is discarded and an ICMP Time Exceeded message SHOULD be returned to the sender. An encapsulator MUST NOT encapsulate a datagram with TTL =3D 0. If that packet is generated at that node, or if the packet is sent to the tunnel in a non-forwarding (BITW) step, that decrement would not happ= en. The TTL in the inner IP header is **not changed when decapsulating**. If, after decapsulation, the inner datagram has TTL =3D 0, the decapsulator MUST discard the datagram. If, after decapsulation, the decapsulator forwards the datagram to one of its network interfaces, **it will decrement the TTL as a result of doing normal IP forwarding*= *. See also Section 4.4. The decapsulator decrements only if forwarding - again, if the packet stops at the destination or if the device isn't a forwarder (BITW), that wouldn't happen. Joe --------------enig50747E301621B50C40AA4DF1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEfagEE5f5cImnZrsRAhKJAKChfOz9FRWlgJp2YsfNp5iWq2BHNwCdG/Ny PEHenFKEaYwRd/sPSbRptWE= =kKZl -----END PGP SIGNATURE----- --------------enig50747E301621B50C40AA4DF1-- --===============2027239353== 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 --===============2027239353==-- From tcpm-bounces@ietf.org Wed May 31 11:17:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSRp-0002wu-Dv; Wed, 31 May 2006 11:17:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSRo-0002wo-JJ for tcpm@ietf.org; Wed, 31 May 2006 11:17:24 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlSRj-0007u4-73 for tcpm@ietf.org; Wed, 31 May 2006 11:17:24 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id IAA27196; Wed, 31 May 2006 08:17:09 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k4VFH9B21821; Wed, 31 May 2006 08:17:09 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 08:16:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] Re: WGLC on antispoof -- ICMP filtering speculation Date: Wed, 31 May 2006 08:16:55 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1818C78@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <447CE2D5.3070300@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Re: WGLC on antispoof -- ICMP filtering speculation Thread-Index: AcaESR54EGsrU6zwSGGFqGnlxOJ9dAAeycPw From: "Templin, Fred L" To: "Joe Touch" X-OriginalArrivalTime: 31 May 2006 15:16:56.0589 (UTC) FILETIME=[415103D0:01C684C5] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: tcpm@ietf.org, Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Joe, > However, my commercial DSL box basically just shuts them all off (in > high security mode). This is my understanding of how many firewalls > treat ICMPs (CAIDA papers, NLANR papers, NANOG discussions all refer to > this). To clarify then, does this mean that RFC1191 PMTUD is basically broken for nodes that sit behind commercial DSL boxes and many firewalls? I know that RFC2923 documents operational issues for PMTUD for some middleboxes that filter ICMPs, but I did not understand that the problems were so wide-spread. Should we basically consider that RFC1191 is broken for practical purposes? Fred fred.l.templin@boeing.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed May 31 11:36:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSjR-0004kP-9P; Wed, 31 May 2006 11:35:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSjQ-0004ie-Cz for tcpm@ietf.org; Wed, 31 May 2006 11:35:36 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlSjO-00013n-1p for tcpm@ietf.org; Wed, 31 May 2006 11:35:36 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4VFYkI29130; Wed, 31 May 2006 08:34:46 -0700 (PDT) Message-ID: <447DB791.5060605@isi.edu> Date: Wed, 31 May 2006 08:34:41 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Templin, Fred L" Subject: Re: [tcpm] Re: WGLC on antispoof -- ICMP filtering speculation References: <39C363776A4E8C4A94691D2BD9D1C9A1818C78@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1818C78@XCH-NW-7V2.nw.nos.boeing.com> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: tcpm@ietf.org, Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1544465410==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1544465410== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF7332B6D9AE86ACF5267409D" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF7332B6D9AE86ACF5267409D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Templin, Fred L wrote: > Joe, >=20 >> However, my commercial DSL box basically just shuts them all off (in >> high security mode). This is my understanding of how many firewalls >> treat ICMPs (CAIDA papers, NLANR papers, NANOG discussions all refer > to >> this). >=20 > To clarify then, does this mean that RFC1191 PMTUD is basically > broken for nodes that sit behind commercial DSL boxes and many > firewalls? Yes - that's what the more recent PMTUD WG is trying to fix using postive feedback rather than the lack of negative feedback. > I know that RFC2923 documents operational issues for > PMTUD for some middleboxes that filter ICMPs, but I did not > understand that the problems were so wide-spread. >=20 > Should we basically consider that RFC1191 is broken for > practical purposes? See the PMTUD WG docs ;-) Joe --------------enigF7332B6D9AE86ACF5267409D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEfbeRE5f5cImnZrsRAlnIAKCFZ8DBhY2ziq5amwQdN/b7e0sAHgCgkJgk XuSKwwE+R5kMn+ZOlcAlbyM= =p2h0 -----END PGP SIGNATURE----- --------------enigF7332B6D9AE86ACF5267409D-- --===============1544465410== 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 --===============1544465410==-- From tcpm-bounces@ietf.org Wed May 31 11:44:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSsP-0007ph-LZ; Wed, 31 May 2006 11:44:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSsO-0007pc-9i for tcpm@ietf.org; Wed, 31 May 2006 11:44:52 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlSsM-0001zw-0R for tcpm@ietf.org; Wed, 31 May 2006 11:44:52 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id IAA20749; Wed, 31 May 2006 08:44:36 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k4VFieB23830; Wed, 31 May 2006 08:44:40 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 08:44:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] Re: WGLC on antispoof -- ICMP filtering speculation Date: Wed, 31 May 2006 08:44:38 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1818C7A@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <447DB791.5060605@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Re: WGLC on antispoof -- ICMP filtering speculation Thread-Index: AcaEx9iZXcerj0C7TYK8ApbmHqfZOAAABFBA From: "Templin, Fred L" To: "Joe Touch" X-OriginalArrivalTime: 31 May 2006 15:44:39.0537 (UTC) FILETIME=[2082BE10:01C684C9] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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: , Errors-To: tcpm-bounces@ietf.org Joe, I know very well about the PMTUD WG documents, but that spec also talks about judicious treatment of ICMPs. I still say that we don't live in a black-and-white world and feedback should be considered before it is summarily ignored. (This is after having argued for ignoring all ICMPs in the past.) Fred fred.l.templin@boeing.com=20 -----Original Message----- From: Joe Touch [mailto:touch@ISI.EDU]=20 Sent: Wednesday, May 31, 2006 8:35 AM To: Templin, Fred L Cc: Fernando Gont; tcpm@ietf.org Subject: Re: [tcpm] Re: WGLC on antispoof -- ICMP filtering speculation Templin, Fred L wrote: > Joe, >=20 >> However, my commercial DSL box basically just shuts them all off (in >> high security mode). This is my understanding of how many firewalls >> treat ICMPs (CAIDA papers, NLANR papers, NANOG discussions all refer > to >> this). >=20 > To clarify then, does this mean that RFC1191 PMTUD is basically > broken for nodes that sit behind commercial DSL boxes and many > firewalls? Yes - that's what the more recent PMTUD WG is trying to fix using postive feedback rather than the lack of negative feedback. > I know that RFC2923 documents operational issues for > PMTUD for some middleboxes that filter ICMPs, but I did not > understand that the problems were so wide-spread. >=20 > Should we basically consider that RFC1191 is broken for > practical purposes? See the PMTUD WG docs ;-) Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed May 31 11:52:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSzs-0005NG-Bp; Wed, 31 May 2006 11:52:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSzq-0005NA-N3 for tcpm@ietf.org; Wed, 31 May 2006 11:52:34 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlSzp-0002jE-CL for tcpm@ietf.org; Wed, 31 May 2006 11:52:34 -0400 Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k4VFpLI03665; Wed, 31 May 2006 08:51:21 -0700 (PDT) Message-ID: <447DBB74.1070306@isi.edu> Date: Wed, 31 May 2006 08:51:16 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Templin, Fred L" Subject: Re: [tcpm] Re: WGLC on antispoof -- ICMP filtering speculation References: <39C363776A4E8C4A94691D2BD9D1C9A1818C7A@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1818C7A@XCH-NW-7V2.nw.nos.boeing.com> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: tcpm@ietf.org, Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2018171168==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2018171168== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC4A73227FC16EC2E87CCFC9F" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC4A73227FC16EC2E87CCFC9F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Templin, Fred L wrote: > Joe, >=20 > I know very well about the PMTUD WG documents, but that spec > also talks about judicious treatment of ICMPs. I still say > that we don't live in a black-and-white world and feedback > should be considered before it is summarily ignored. (This > is after having argued for ignoring all ICMPs in the past.) What we should do and what is done are two different things. I'm not arguing in this doc that dropping all ICMPs is a preferred, but rather more prevalent solution. Until we have a more protected infrastructure and signalling protocols, that's not likely to change. Joe --------------enigC4A73227FC16EC2E87CCFC9F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEfbt0E5f5cImnZrsRAoYiAJ9OTL1YOOwhZzaNU6rotdTpMTdBhwCfbjUv BNQJllwfuYVorJ/b9ZVN+H0= =dTZE -----END PGP SIGNATURE----- --------------enigC4A73227FC16EC2E87CCFC9F-- --===============2018171168== 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 --===============2018171168==-- From tcpm-bounces@ietf.org Wed May 31 20:35:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flb9x-0005qr-Uo; Wed, 31 May 2006 20:35:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flb9w-0005qm-Hv for tcpm@ietf.org; Wed, 31 May 2006 20:35:32 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flb9t-0006MU-VT for tcpm@ietf.org; Wed, 31 May 2006 20:35:32 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k510ZRog026577; Wed, 31 May 2006 21:35:31 -0300 Message-Id: <7.0.1.0.0.20060531200816.03493c00@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 31 May 2006 20:28:33 -0300 To: Joe Touch , Ted Faber From: Fernando Gont Subject: Re: [tcpm] Re: WGLC on antispoof -- ICMP filtering speculation In-Reply-To: <447CEF93.3010400@isi.edu> References: <20060517034349.BE52C40F5AE@lawyers.icir.org> <447B25E7.50901@isi.edu> <7.0.1.0.0.20060529224729.049b4618@gont.com.ar> <447C9040.4060606@isi.edu> <20060530202713.GI1309@hut.isi.edu> <447CE009.5050503@isi.edu> <20060531004504.GL1309@hut.isi.edu> <447CEF93.3010400@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 22:21 30/05/2006, Joe Touch wrote: > > Or you're saying something else? > >4301 says, basically, that ICMPs present a conundrum: > >- accepting them presents a way to degrade service (an attack) > >- dropping them degrades service (sort of like you're attacking yourself) The issue is that if you're securing a connection with IPSec, you require authentication for the packets that correspond to the connection, but you cannot enforce the same for the ICMP error messages that refer to that connection. In *that* case, you *may* choose either to drop ICMPs. RFC 4301 leaves it up to the administrator. And it makes it clear that in the case of PMTUD, you're in trouble. IIRC, it sort of suggest to honor the "frag needed" messages but enforce a lower limit for the Path-MTU. I'd not take that as a recommendation to "drop all ICMPs". Now, in the case on non IPSec'ed connections, what's it that makes you trust a TCP segment, but not an ICMP error message? The TCP segments are not authenticated, either. Yes, there are issues in the ICMP specs that need to be fixed. Clearly, the specs should have always required ICMP error messages to be in-window. >The key question here is whether there is any real disagreement that >dropping all ICMPs is the first and most prevalent line of defense from >attack. The doc isn't recommending it, but it is stating that. That's your assumption. The most prevalent defense against ICMP-based connection-reset attacks is simply to take the hard errors as a hint, for example. Again, run traceroute or ping. That will give you a hint to what extent there's a prevalence of "drop all ICMPs". >Is that >something we need to have 'rough consensus' on? If so, can some others >please start reading the CAIDA/NLANR/NANOG docs and meeting notes, so we >can proceed? I cannot understand why you oppose so much to performing checks on ICMP messages and taking the error messages as "hints", and at the same time encourage (one way or the other) people to drop all ICMPs. If you like have you system abort connection upon receipt of ICMP error messages, just hack your kernel code, and you're done. If such filtering gets widely deployed, then it would be almost impossible to go back on one's steps. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm