From owner-tcp-impl@grc.nasa.gov Sun Dec 1 05:04:58 2002 Received: from seraph2.grc.nasa.gov (seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02088 for ; Sun, 1 Dec 2002 05:04:58 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 34396C6909 for ; Sun, 1 Dec 2002 05:07:15 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id gB19jJ6M016826 for tcp-impl-outgoing; Sun, 1 Dec 2002 04:45:19 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gB19jHwg016822 for ; Sun, 1 Dec 2002 04:45:18 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gB19jHSl017198 for ; Sun, 1 Dec 2002 04:45:17 -0500 (EST) Received: from leonis.nus.edu.sg (leonis.nus.edu.sg [137.132.1.18]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 8D168640C6 for ; Sun, 1 Dec 2002 04:45:13 -0500 (EST) Received: from pod.ddns.comp.nus.edu.sg (pod.ddns.comp.nus.edu.sg [137.132.81.90]) by leonis.nus.edu.sg (8.12.1/8.12.1) with SMTP id gB19kY5M025227 for ; Sun, 1 Dec 2002 17:46:34 +0800 (SGT) Date: Sun, 1 Dec 2002 17:46:37 +0800 From: Gokul Poduval To: tcp-impl@grc.nasa.gov Subject: receive window limited to 8192 bytes in PPP connections Message-Id: <20021201174637.74bd3419.gokulpod@comp.nus.edu.sg> In-Reply-To: <20021128190146.1c6e3378.gokulpod@comp.nus.edu.sg> References: <20021128190146.1c6e3378.gokulpod@comp.nus.edu.sg> Organization: National University of Singapore X-Mailer: Sylpheed version 0.8.6 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Recently when I was testing a few PPP connections, I found out that PPP connections in linux limit their receive window to 8192 bytes. Is there anyway to increase the receive window upto 64kbytes ? -- Gokul Poduval http://www.comp.nus.edu.sg/~gokulpod From owner-tcp-impl@grc.nasa.gov Tue Dec 3 10:26:05 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26013 for ; Tue, 3 Dec 2002 10:26:05 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id E999C64102 for ; Tue, 3 Dec 2002 10:28:24 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id gB3F8P9W007775 for tcp-impl-outgoing; Tue, 3 Dec 2002 10:08:26 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gB3F8Nwg007756 for ; Tue, 3 Dec 2002 10:08:23 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gB3F8LSl023963 for ; Tue, 3 Dec 2002 10:08:22 -0500 (EST) Received: from lawyers.ir.bbn.com (dhcp081-077.bbn.com [128.89.81.77]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 85CF2C694F for ; Tue, 3 Dec 2002 10:08:21 -0500 (EST) Received: from lawyers (mallman@localhost) by lawyers.ir.bbn.com (8.9.3/8.9.3) with ESMTP id IAA16254 for ; Tue, 3 Dec 2002 08:31:52 -0500 Message-Id: <200212031331.IAA16254@lawyers.ir.bbn.com> To: tcp-impl@grc.nasa.gov From: Mark Allman Reply-To: mallman@grc.nasa.gov Subject: Re: receive window limited to 8192 bytes in PPP connections Organization: BBN Technologies/NASA GRC Song-of-the-Day: Empty Sky Date: Tue, 03 Dec 2002 08:31:52 -0500 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk ------- Forwarded Message Date: Mon, 2 Dec 2002 14:25:37 +0100 From: Andi Kleen To: Gokul Poduval Cc: tcp-impl@grc.nasa.gov Subject: Re: receive window limited to 8192 bytes in PPP connections On Sun, Dec 01, 2002 at 10:46:37AM +0100, Gokul Poduval wrote: > Recently when I was testing a few PPP connections, I found out that > PPP connections in linux limit their receive window to 8192 bytes. Is > there anyway to increase the receive window upto 64kbytes ? Look at a longer trace. The window starts at 8k, but increases over time. - -Andi ------- End of Forwarded Message From owner-tcp-impl@grc.nasa.gov Tue Dec 3 10:26:22 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26035 for ; Tue, 3 Dec 2002 10:26:22 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 490D964112 for ; Tue, 3 Dec 2002 10:28:42 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id gB3F8SAl007801 for tcp-impl-outgoing; Tue, 3 Dec 2002 10:08:28 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gB3F8Pwg007772 for ; Tue, 3 Dec 2002 10:08:25 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gB3F8NSl023972 for ; Tue, 3 Dec 2002 10:08:23 -0500 (EST) Received: from lawyers.ir.bbn.com (dhcp081-077.bbn.com [128.89.81.77]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 8C5F8C694D for ; Tue, 3 Dec 2002 10:08:22 -0500 (EST) Received: from lawyers (mallman@localhost) by lawyers.ir.bbn.com (8.9.3/8.9.3) with ESMTP id IAA16238 for ; Tue, 3 Dec 2002 08:29:54 -0500 Message-Id: <200212031329.IAA16238@lawyers.ir.bbn.com> To: tcp-impl@grc.nasa.gov From: Mark Allman Reply-To: mallman@grc.nasa.gov Subject: Re: rtt in freebsd Organization: BBN Technologies/NASA GRC Song-of-the-Day: Empty Sky Date: Tue, 03 Dec 2002 08:29:53 -0500 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk ------- Forwarded Message Date: Thu, 28 Nov 2002 10:47:00 -0600 From: Jonathan Lemon To: Gokul Poduval Cc: tcp-impl@grc.nasa.gov Subject: Re: rtt in freebsd >From tcp_input.c: /* * srtt is stored as fixed point with 5 bits after the * binary point (i.e., scaled by 8). The following magic * is equivalent to the smoothing algorithm in rfc793 with * an alpha of .875 (srtt = rtt/8 + srtt*7/8 in fixed * point). Adjust rtt to origin 0. */ srtt is the smoothed RTT. rtttime is the current tick value, and is used for timing segments. - -- Jonathan On Thu, Nov 28, 2002 at 07:01:46PM +0800, Gokul Poduval wrote: > Hello, > > In the tcpcb structure in freebsd (release 4.5), what variable > maintains the instantaneous rtt ? I tried printing tp->t_rtttime in the > congestion avoidance section in tcp_input.c, but it always seems to be > 0. > tp->t_srtt seems to reflect a more accurate value of rtt, but its > value seems to be 10 times of what the actual rtt is. (if the rtt is > 60ms, srtt is ~600). > > -- > > Gokul Poduval > http://www.comp.nus.edu.sg/~gokulpod ------- End of Forwarded Message From owner-tcp-impl@grc.nasa.gov Tue Dec 3 10:26:44 2002 Received: from seraph2.grc.nasa.gov (seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26068 for ; Tue, 3 Dec 2002 10:26:44 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 20DF9C6952 for ; Tue, 3 Dec 2002 10:29:04 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id gB3F8TW3007804 for tcp-impl-outgoing; Tue, 3 Dec 2002 10:08:29 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gB3F8Pwg007779 for ; Tue, 3 Dec 2002 10:08:25 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gB3F8NSl023977 for ; Tue, 3 Dec 2002 10:08:24 -0500 (EST) Received: from lawyers.ir.bbn.com (dhcp081-077.bbn.com [128.89.81.77]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 72AF7C694A for ; Tue, 3 Dec 2002 10:08:23 -0500 (EST) Received: from lawyers (mallman@localhost) by lawyers.ir.bbn.com (8.9.3/8.9.3) with ESMTP id IAA16267 for ; Tue, 3 Dec 2002 08:37:17 -0500 Message-Id: <200212031337.IAA16267@lawyers.ir.bbn.com> To: tcp-impl@grc.nasa.gov From: Mark Allman Reply-To: mallman@grc.nasa.gov Subject: Re: CFP-The First ACM Conference on Embedded Networked Sensor Systems Organization: BBN Technologies/NASA GRC Song-of-the-Day: Empty Sky Date: Tue, 03 Dec 2002 08:37:17 -0500 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk ------- Forwarded Message From: "Lynette Millett" To: erdal@ece.gatech.edu Message-ID: <85256C83.0053EFD7.2D@smtpmta.nas.edu> Date: Mon, 2 Dec 2002 10:19:04 -0500 Subject: CFP-The First ACM Conference on Embedded Networked Sensor Systems Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Our apologies if you have received multiple copies of this CFP =============================================== PRELIMINARY CALL FOR PAPERS The First ACM Conference on Embedded Networked Sensor Systems SenSys 2003 http://www.cens.ucla.edu/sensys03 November 5-7, 2003, Los Angeles, California, USA Sponsored by: ACM (Sigcomm, Sigmobile, Sigarch, Sigmetrics, Sigops), and NSF SenSys 2003 introduces a high caliber forum for research on systems issues in the emerging area of embedded, networked sensors. These distributed systems of numerous smart sensors and actuators connecting computational capabilities to the physical world have the potential to revolutionize a wide array of application areas by providing an unprecedented density and fidelity of instrumentation. They also present a host of novel systems challenges because of resource constraints, uncertainty, irregularity, and scale. SenSys design issues cut across multiple fields, including wireless communication, networking, operating systems, architecture, low-power circuits, distributed algorithms, data processing, scheduling, sensors, energy harvesting, and signal processing, so a holistic approach is required. SenSys seeks to provide a cross-disciplinary venue for researchers addressing the rich space of networked sensor system design issues to interact and exchange recent results. It is the first of a planned series of annual meetings with a highly selective, single-track technical program and a hands-on research exhibition. This inaugural 2003 conference shall take place in Los Angeles, CA. PAPERS: Technical papers describing original, previously unpublished research are solicited. In general this conference is interested in papers that address system issues in embedded networked systems. Specific topics of interest include the following: * Network protocols for sensor networks * Operating system and middleware for sensor networks * Distributed database processing in sensor networks * Distributed algorithms for sensor networks * Novel sensor node hardware and software platforms * Sensor network planning and deployment * Energy management in sensor networks * Adaptive topology management * In-network processing and aggregation * Data storage in sensor networks * Distributed and collaborative signal processing * Distributed Actuation, Control, and Coordination * Localization in time and space * Distributed calibration in sensor networks * Simulation and optimization tools * Applications of distributed sensor networks * Security and Robustness in sensor networks Please consult the program chairs at sensys03-pcchairs@cens.ucla.edu if you are uncertain whether your paper is in the scope of the conference. PAPER SUBMISSION INSTRUCTIONS All submissions will be handled electronically and must be in PDF or PostScript format. Papers must not exceed 15 pages (US "Letter" size, 8.5 x 11 inches) including text, figures and references. The font size must be at least 10 points. Accepted papers will be published in the conference proceedings. We will adopt a double-blind process for paper review, where the identities of the authors are withheld from the reviewers. Authors' names and their affiliations must not be revealed or mentioned anywhere in the paper or in the postscript or PDF file. Submitted papers should be original, unpublished work and not currently under review for any other conference or journal. Papers not following these guidelines will be rejected. To submit a paper, please refer to the paper submission link at the conference website, http://www.cens.ucla.edu/sensys03. Questions about the submission process should be directed to the Program Co-Chairs at . RESEARCH EXHIBITS and POSTERS There will be a research exhibition and poster session. Details will be provided in the final Call for Papers. IMPORTANT DATES Paper Registration & Abstract: April 1, 2003 Paper Submission Deadline: April 8, 2003 Notification of Acceptance: June 27, 2003 Camera Ready Copy: August 1, 2003 CONFERENCE COMMITTEE General Co-Chairs: Ian Akyildiz Deborah Estrin Program Co-Chairs: David Culler Mani Srivastava STEERING COMMITTEE Ian Akyildiz , Deborah Estrin , and Taieb Znati Please visit the SenSys 2003 Home Page at http://www.cens.ucla.edu/sensys03, or send email to sensys03@cens.ucla.edu for more information about the conference. ------- End of Forwarded Message From owner-tcp-impl@grc.nasa.gov Wed Dec 4 06:32:14 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06420 for ; Wed, 4 Dec 2002 06:32:14 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 3675A64106 for ; Wed, 4 Dec 2002 06:34:33 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id gB4BHuF6021121 for tcp-impl-outgoing; Wed, 4 Dec 2002 06:17:56 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gB4BHswg021115 for ; Wed, 4 Dec 2002 06:17:54 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gB4BHsSl007329 for ; Wed, 4 Dec 2002 06:17:54 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id ED527C6968 for ; Wed, 4 Dec 2002 06:17:52 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB4BHDG23526 for ; Wed, 4 Dec 2002 13:17:13 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 4 Dec 2002 13:17:49 +0200 Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 4 Dec 2002 13:17:48 +0200 Received: from maebe001.NOE.Nokia.com ([10.209.0.44]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 4 Dec 2002 13:17:48 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: Retransmission timer in TCP Date: Wed, 4 Dec 2002 12:17:46 +0100 Message-ID: <89DB9A29605CFD4CA07BEE7C0FCAC0D16F1A31@maebe001.europe.nokia.com> Thread-Topic: Retransmission timer in TCP Thread-Index: AcKbhsXN5NmqdeP3RKSyFwGpUP1/EQ== From: To: X-OriginalArrivalTime: 04 Dec 2002 11:17:48.0180 (UTC) FILETIME=[C6BA0D40:01C29B86] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id gB4BHtwg021116 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit Hi all, RTO computation as in recommended in RFC2988 uses one retransmission timer per transmission window. Does this provide a more robust solution than having one retransmission timer per segment ? I mean: 1) In the first case any ACK that acknowledges new data resets the timer, so increasing the transmission window ( and RTT) provides a more conservative retransmission timer. Because, RTO *RTT(one packet) + TxWindowDelay(because of buffering), and time for next ACK is roughly RTT(one packet). 2) In the second case, the retransmission timer of one packet would be only reset when that packet is acknowledged, so time for ACK * RTT(one packet) + TxWindowDelay, and the retransmission timer would be more sensible to delay spikes ( eg. likely in wireless networks). I haven't found much information about how second option is implemented, maybe it is implemented in a different way. Do you know some reference that discuss this difference?. Or maybe this is not really an issue, I'm not sure about if the option 2) is really widely used, or it is really that most common systems (Windows, Solaris, Linux ... etc) just implement RFC2988. Thanks in advance, Best regards, Rafa From owner-tcp-impl@grc.nasa.gov Wed Dec 4 09:59:41 2002 Received: from seraph2.grc.nasa.gov (seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14617 for ; Wed, 4 Dec 2002 09:59:40 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 24B1EC6947 for ; Wed, 4 Dec 2002 10:02:01 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id gB4EhYwA000799 for tcp-impl-outgoing; Wed, 4 Dec 2002 09:43:34 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gB4EhVwg000781 for ; Wed, 4 Dec 2002 09:43:31 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gB4EhUSl007414 for ; Wed, 4 Dec 2002 09:43:30 -0500 (EST) Received: from lawyers.ir.bbn.com (new-ir04.bbn.com [128.89.80.214]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id EAA09640FE for ; Wed, 4 Dec 2002 09:43:29 -0500 (EST) Received: from lawyers (mallman@localhost) by lawyers.ir.bbn.com (8.9.3/8.9.3) with ESMTP id JAA20862 for ; Wed, 4 Dec 2002 09:43:15 -0500 Message-Id: <200212041443.JAA20862@lawyers.ir.bbn.com> To: tcp-impl@grc.nasa.gov From: Mark Allman Reply-To: mallman@grc.nasa.gov Subject: CFP:IFIP WG 6.8 Conference on Personal Wireless Communications Organization: BBN Technologies/NASA GRC Song-of-the-Day: Empty Sky Date: Wed, 04 Dec 2002 09:43:15 -0500 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk ------- Forwarded Message Date: Wed, 04 Dec 2002 14:41:07 +0100 From: Raffaele Bruno Subject: CFP:IFIP WG 6.8 Conference on Personal Wireless Communications To: Raffaele Bruno - --Boundary_(ID_gdX9OYs/0qifnjvS8eGmkw) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7bit [Our sincere apologies if you receive multiple copies of this CFP] ========================================================= Conference Announcement and Preliminary Call for Papers PWC 2003 The Eighth International Conference on Personal Wireless Communications Sponsored by the IFIP WG 6.8 - Mobile and Wireless Communications http://www.iit.cnr.it/pwc2003 September 23-25, 2003 Telecom Italia Future Centre - Venice, Italy http://www.futurecentre.telecomitalia.it/eng/ PWC is the premier international forum for discussions between researchers, practitioners and students interested in the symbiosis of mobile computing and wireless networks. PWC 2003 is the eight conference of this series and is sposored by IFIP WG 6.8 The PWC 2003 technical program committee is soliciting papers describing original, previously unpublished, completed or on-going research, on topics. including, but not limited to, the following: - - Mobile Web Access - - Mobile and Wireless Applications - - Pervasive computing - - Mobile and Wireless Networking - - IP-based Mobile Networks - - Mobility Management - - QoS in the Mobile and Wireless Networks - - Real-time voice/video over mobile and wireless networks - - Multicasting in Wireless Services - - Analysis, Simulation and Measurement of wireless and mobile systems - - Mobile ad hoc networks - - Wireless BAN, PAN and LAN - - Wi-Fi - - Third and Fourth Generation Systems - - 3G/WLAN internetworking - - Energy-efficient Protocols and Power Management This year conference includes two special tracks to address hot topic issues: sensor networks and wireless security. PAPER SUBMISSION AND PUBLICATION ================================= Papers should neither have been published elsewhere nor currently under review by another conference or journal. For paper submission, please follow the submission instructions at: http://www.iit.cnr.it/pwc2003 All papers will be reviewed by the program committee members. Accepted papers will appear in the conference proceedings. IMPORTANT DATES =============== Full papers due: February 10, 2003 Notification: May 10, 2003 Camera Ready due: June 10, 2003 GENERAL Chair: Enrico Gregori, IIT - CNR, Italy GENERAL Vice-Chair: Fabrizio Davide, Telecom Italia, Italy TECHNICAL PROGRAM Chair: Marco Conti, IIT - CNR, Italy SPECIAL TRACKs PROGRAM Chair: Silvia Giordano, SUPSI, Switzerland PUBLICITY chair: Raffaele Bruno, IIT CNR, Italy STEERING COMMITTEE Members: Imrich Chlamtac, University of Trento, Italy (Chair) Jon Crowcroft, University of Cambridge, UK Sajal K. Das, The University of Texas at Arlington, USA Anthony Ephremides, University of Maryland, USA Guy Omidyar, National University of Singapore, Singapore Adam Wolisz, Technical University of Berlin, Germany TECHNICAL PROGRAM COMMITTEE Members: TBD - -- Raffaele Bruno ======================================= Publicity chair PWC 2003 Ph.D. Student Italian National Research Council - IIT Institute Via G. Moruzzi,1 - 56100 Pisa, ITLAY ======================================= phone: +39 050 3153078 fax: +39 050 3152593 email: raffaele.bruno@iit.cnr.it ======================================= - --Boundary_(ID_gdX9OYs/0qifnjvS8eGmkw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7bit  
[Our sincere apologies if you receive multiple copies of this CFP]
=========================================================

Conference Announcement and Preliminary Call for Papers

PWC 2003

The Eighth International Conference on Personal Wireless Communications
Sponsored by the IFIP WG 6.8 - Mobile and Wireless Communications
http://www.iit.cnr.it/pwc2003

September 23-25, 2003
Telecom Italia Future Centre - Venice, Italy
http://www.futurecentre.telecomitalia.it/eng/


PWC is the premier international forum for discussions between researchers, practitioners and students interested in the symbiosis of mobile computing and wireless networks. PWC 2003 is the eight conference of this series and is sposored by IFIP WG 6.8

The PWC 2003 technical program committee is soliciting papers describing original, previously unpublished, completed or on-going research, on topics. including, but not limited to, the following:

- Mobile Web Access
- Mobile and Wireless Applications
- Pervasive computing
- Mobile and Wireless Networking
- IP-based Mobile Networks
- Mobility Management
- QoS in the Mobile and Wireless Networks
- Real-time voice/video over mobile and wireless networks
- Multicasting in Wireless Services
- Analysis, Simulation and Measurement of wireless and mobile systems
- Mobile ad hoc networks
- Wireless BAN, PAN and LAN
- Wi-Fi
- Third and Fourth Generation Systems
- 3G/WLAN internetworking
- Energy-efficient Protocols and Power Management

This year conference includes two special tracks to address hot topic issues: sensor networks and wireless security.
 

PAPER SUBMISSION AND PUBLICATION
=================================

Papers should neither have been published elsewhere nor currently
under review by another conference or journal. For paper submission,
please follow the submission instructions at:
http://www.iit.cnr.it/pwc2003
All papers will be reviewed by the program committee members.
Accepted papers will appear in the conference proceedings.
 

IMPORTANT DATES
===============

Full papers due: February 10, 2003
Notification:   May 10, 2003
Camera Ready due: June 10, 2003
 

GENERAL Chair: Enrico Gregori, IIT - CNR, Italy

GENERAL Vice-Chair: Fabrizio Davide, Telecom Italia, Italy

TECHNICAL PROGRAM Chair: Marco Conti, IIT - CNR, Italy

SPECIAL TRACKs PROGRAM Chair: Silvia Giordano, SUPSI, Switzerland

PUBLICITY chair: Raffaele Bruno, IIT CNR, Italy
 

STEERING COMMITTEE Members:

Imrich Chlamtac, University of Trento, Italy (Chair)
Jon Crowcroft, University of Cambridge, UK
Sajal K. Das, The University of Texas at Arlington, USA
Anthony Ephremides, University of Maryland, USA
Guy Omidyar, National University of Singapore, Singapore
Adam Wolisz, Technical University of Berlin, Germany
 

TECHNICAL PROGRAM COMMITTEE Members: TBD
 

--
Raffaele Bruno
=======================================
Publicity chair PWC 2003

Ph.D. Student
Italian National Research Council - IIT Institute
Via G. Moruzzi,1 - 56100 Pisa, ITLAY
=======================================
phone: +39 050 3153078
fax:     +39 050 3152593
email: raffaele.bruno@iit.cnr.it
=======================================
 
 

- --Boundary_(ID_gdX9OYs/0qifnjvS8eGmkw)-- ------- End of Forwarded Message From owner-tcp-impl@grc.nasa.gov Wed Dec 4 16:39:26 2002 Received: from seraph2.grc.nasa.gov (seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05151 for ; Wed, 4 Dec 2002 16:39:26 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 749D9C69D5 for ; Wed, 4 Dec 2002 16:41:39 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id gB4LN3VG021690 for tcp-impl-outgoing; Wed, 4 Dec 2002 16:23:03 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gB4LMwwg021662 for ; Wed, 4 Dec 2002 16:22:58 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gB4LMwSl021669 for ; Wed, 4 Dec 2002 16:22:58 -0500 (EST) Received: from lawyers.ir.bbn.com (new-ir04.bbn.com [128.89.80.214]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id D8E68C6980 for ; Wed, 4 Dec 2002 16:22:57 -0500 (EST) Received: from lawyers (mallman@localhost) by lawyers.ir.bbn.com (8.9.3/8.9.3) with ESMTP id QAA22093 for ; Wed, 4 Dec 2002 16:22:43 -0500 Message-Id: <200212042122.QAA22093@lawyers.ir.bbn.com> To: tcp-impl@grc.nasa.gov From: Mark Allman Reply-To: mallman@grc.nasa.gov Subject: Re: Retransmission timer in TCP Organization: BBN Technologies/NASA GRC Song-of-the-Day: Hotel California Date: Wed, 04 Dec 2002 16:22:42 -0500 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk ------- Forwarded Message Date: Wed, 04 Dec 2002 12:45:30 +0100 To: From: Reiner Ludwig Subject: Re: Retransmission timer in TCP Cc: At 12:17 04.12.2002, Ext-Rafael.M.Sanchez@nokia.com wrote: > RTO computation as in recommended in RFC2988 uses one retransmission > timer per transmission window. Does this provide a more robust solution > than having one retransmission timer per segment ? One timer per segment causes more burden for the CPU, which is one reason why you wouldn't want to do that. Think of busy web servers. > 1) In the first case any ACK that acknowledges new data resets the > timer, so increasing the transmission window ( and RTT) provides a more > conservative retransmission timer. Because, RTO *RTT(one packet) + > TxWindowDelay(because of buffering), and time for next ACK is roughly > RTT(one packet). This is explored in detail in this paper: http://iceberg.cs.berkeley.edu/papers/Ludwig-Eifel-Xmit/index.html ///Reiner ------- End of Forwarded Message From owner-tcp-impl@grc.nasa.gov Fri Dec 13 10:11:29 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25177 for ; Fri, 13 Dec 2002 10:11:29 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id B22C86BA30 for ; Fri, 13 Dec 2002 10:13:55 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id gBDEnoeI017742 for tcp-impl-outgoing; Fri, 13 Dec 2002 09:49:50 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gBDEnmwg017735 for ; Fri, 13 Dec 2002 09:49:48 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gBDEnmSl016306 for ; Fri, 13 Dec 2002 09:49:48 -0500 (EST) Received: from prv-mail21.provo.novell.com (PRV-MAIL21.PROVO.NOVELL.COM [137.65.81.126]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id A205F6BA1F for ; Fri, 13 Dec 2002 09:49:47 -0500 (EST) Received: from Novell.com (hema.dnsdhcp.provo.novell.com [137.65.56.87]) by prv-mail21.provo.novell.com; Fri, 13 Dec 2002 07:49:36 -0700 Message-ID: <3DF9F380.1070403@Novell.com> Date: Fri, 13 Dec 2002 07:49:36 -0700 From: Ramesh Shankar Organization: Novell Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: end2end , TCP-IMPL Subject: Question on "identification" field of IP header Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit If the "Don't fragment bit" is set in the IP header, what purpose does the "identification" field serve? Why can't I simply put 0 for this field in such a case? I remember coming across some e-mail chain in one of the mailing lists (TCP-IMPL, e2e, TSVWG) about this issue and the interaction with NAT. But I am not sure what came out of that discussion. Also, some of the "OS fingerprinting" techniques in the networking world apparently use the IP ID field to identify various operating systems. Apparently some operating systems (or protocol stacks, if you prefer) don't increment this by 1. Why would anyone want to do this? Wouldn't this cause possibles issues wrt to wrap around in the possible case of fragmentation? One could always argue that with high speed Ethernet, that anyway would be a possibility, but I would like to understand the reason behind such a case. Thanks for your time, S.R. From owner-tcp-impl@grc.nasa.gov Fri Dec 13 11:33:37 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27514 for ; Fri, 13 Dec 2002 11:33:36 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id BD81F6BAB4 for ; Fri, 13 Dec 2002 11:36:03 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id gBDGKGLS016803 for tcp-impl-outgoing; Fri, 13 Dec 2002 11:20:16 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gBDGKEwg016798 for ; Fri, 13 Dec 2002 11:20:14 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gBDGKESl002818 for ; Fri, 13 Dec 2002 11:20:14 -0500 (EST) Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 891F66BA27 for ; Fri, 13 Dec 2002 11:20:13 -0500 (EST) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id LAA10993; Fri, 13 Dec 2002 11:20:11 -0500 (EST) From: der Mouse Message-Id: <200212131620.LAA10993@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Fri, 13 Dec 2002 16:41:51 +0100 (CET) To: end2end-interest@postel.org, tcp-impl@grc.nasa.gov Subject: Re: Question on "identification" field of IP header In-Reply-To: <3DF9F380.1070403@Novell.com> References: <3DF9F380.1070403@Novell.com> Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit > If the "Don't fragment bit" is set in the IP header, what purpose > does the "identification" field serve? It says which datagram is affected if an ICMP is returned in resposne to it, if nothing else. > I remember coming across some e-mail chain in one of the mailing > lists (TCP-IMPL, e2e, TSVWG) about this issue and the interaction > with NAT. Heh. My usual response to "NAT interacts badly with " is "don't use NAT, then". It just breaks too many of the assumptions underlying IP-based networking. But it wouldn't surprise me a bit if there were NAT implementations broken enough to assume that packets with identical IDs arriving within a small enough temporal window of one another were actually the same packet. Note that the portion of a packet returned in an ICMP does not include even the IP source and destination addresses; the identification value is almost the only value that can be relied upon to identify the original packet upon getting an ICMP.... /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From owner-tcp-impl@grc.nasa.gov Fri Dec 13 12:01:32 2002 Received: from seraph2.grc.nasa.gov (seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28456 for ; Fri, 13 Dec 2002 12:01:31 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 68B0868990 for ; Fri, 13 Dec 2002 12:03:58 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id gBDGofgv025673 for tcp-impl-outgoing; Fri, 13 Dec 2002 11:50:41 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gBDGoewg025659 for ; Fri, 13 Dec 2002 11:50:40 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gBDGoYcR001851 for ; Fri, 13 Dec 2002 11:50:34 -0500 (EST) Received: from irongate.swansea.linux.org.uk (pc2-cwma1-4-cust86.swan.cable.ntl.com [213.105.254.86]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id A4DC66BB5B for ; Fri, 13 Dec 2002 11:43:06 -0500 (EST) Received: from irongate.swansea.linux.org.uk (localhost [127.0.0.1]) by irongate.swansea.linux.org.uk (8.12.5/8.12.5) with ESMTP id gBDHLPlQ026304; Fri, 13 Dec 2002 17:21:27 GMT Received: (from alan@localhost) by irongate.swansea.linux.org.uk (8.12.5/8.12.5/Submit) id gBDHLLTx026299; Fri, 13 Dec 2002 17:21:22 GMT X-Authentication-Warning: irongate.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: Question on "identification" field of IP header From: Alan Cox To: Ramesh Shankar Cc: end2end , TCP-IMPL In-Reply-To: <3DF9F380.1070403@Novell.com> References: <3DF9F380.1070403@Novell.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 13 Dec 2002 17:21:18 +0000 Message-Id: <1039800079.25123.103.camel@irongate.swansea.linux.org.uk> Mime-Version: 1.0 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2002-12-13 at 14:49, Ramesh Shankar wrote: > If the "Don't fragment bit" is set in the IP header, what purpose does > the "identification" field serve? Why can't I simply put 0 for this > field in such a case? I remember coming across some e-mail chain in one Linux does this in some situations. At high speed it becomes a real issue because the ip id reuse time is way way lower than the amount of time fragments get lost in the network Checksums should help avoid this but they are not very strong From owner-tcp-impl@grc.nasa.gov Fri Dec 13 12:27:29 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29042 for ; Fri, 13 Dec 2002 12:27:29 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id A38B16BA39 for ; Fri, 13 Dec 2002 12:29:56 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id gBDHG8gj004778 for tcp-impl-outgoing; Fri, 13 Dec 2002 12:16:08 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gBDHG6wg004765 for ; Fri, 13 Dec 2002 12:16:06 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gBDHG5cR007967 for ; Fri, 13 Dec 2002 12:16:05 -0500 (EST) Received: from frantic.weston.bsdi.com (frantic-dmz.weston.BSDI.COM [206.196.54.22]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 6C0496BA13 for ; Fri, 13 Dec 2002 12:16:04 -0500 (EST) Received: (from dab@localhost) by frantic.weston.bsdi.com (8.10.1/8.10.1) id gBDHEBr05725; Fri, 13 Dec 2002 11:14:11 -0600 (CST) Date: Fri, 13 Dec 2002 11:14:11 -0600 (CST) From: David Borman Message-Id: <200212131714.gBDHEBr05725@frantic.weston.bsdi.com> To: end2end-interest@postel.org, mouse@Rodents.Montreal.QC.CA, tcp-impl@grc.nasa.gov Subject: Re: Question on "identification" field of IP header Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Just a minor nit that I feel should be clarified: > From: der Mouse > Date: Fri, 13 Dec 2002 16:41:51 +0100 (CET) > Subject: Re: Question on "identification" field of IP header ... > Note that the portion of a packet returned in an ICMP does not include > even the IP source and destination addresses; the identification value > is almost the only value that can be relied upon to identify the > original packet upon getting an ICMP.... Actually, ICMP packets are supposed to return the entire IP header (including options) plus 64 bits of the IP data. So, you should get up to the TCP and UDP port numbers. (RFC 792 explicitly states that it assumes that higher level protocols have their port numbers in the first 64 bits). -David Borman From owner-tcp-impl@grc.nasa.gov Fri Dec 13 13:30:27 2002 Received: from seraph2.grc.nasa.gov (seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01129 for ; Fri, 13 Dec 2002 13:30:26 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 5B0E068943 for ; Fri, 13 Dec 2002 13:32:54 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id gBDIFuB3020893 for tcp-impl-outgoing; Fri, 13 Dec 2002 13:15:56 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gBDIFqwg020873 for ; Fri, 13 Dec 2002 13:15:52 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gBDIFXEb003114 for ; Fri, 13 Dec 2002 13:15:33 -0500 (EST) Received: from prv-mail21.provo.novell.com (PRV-MAIL21.PROVO.NOVELL.COM [137.65.81.126]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id B947168B53 for ; Fri, 13 Dec 2002 13:05:20 -0500 (EST) Received: from Novell.com (hema.dnsdhcp.provo.novell.com [137.65.56.87]) by prv-mail21.provo.novell.com; Fri, 13 Dec 2002 11:05:18 -0700 Message-ID: <3DFA215F.8090107@Novell.com> Date: Fri, 13 Dec 2002 11:05:19 -0700 From: Ramesh Shankar Organization: Novell Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: end2end-interest@postel.org, tcp-impl@grc.nasa.gov Subject: Re: Question on "identification" field of IP header References: <200212131714.gBDHEBr05725@frantic.weston.bsdi.com> In-Reply-To: <200212131714.gBDHEBr05725@frantic.weston.bsdi.com> Content-Type: multipart/alternative; boundary="------------080309060600020206000708" Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk --------------080309060600020206000708 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I would suspect that for the ICMP case, the IP ID wouldn't be too useful for the transport and above layers as these layers typically don't know (or care) about the ID in the IP header. Even for the retransmit cases, typically new IDs are used and no attempt is made to reuse the ID with which the previously lost packet was sent. Hoping that someone would clarify the purpose in life of the IP ID field if the don't fragment bit is set. One answer that Jamshid Mahdavi told me privately was that it would be useful at debugging time while looking at packet traces. Thanks, S.R. David Borman wrote: >Just a minor nit that I feel should be clarified: > > > >>From: der Mouse >>Date: Fri, 13 Dec 2002 16:41:51 +0100 (CET) >>Subject: Re: Question on "identification" field of IP header >> >> >... > > >>Note that the portion of a packet returned in an ICMP does not include >>even the IP source and destination addresses; the identification value >>is almost the only value that can be relied upon to identify the >>original packet upon getting an ICMP.... >> >> > >Actually, ICMP packets are supposed to return the entire IP header >(including options) plus 64 bits of the IP data. So, you should get >up to the TCP and UDP port numbers. (RFC 792 explicitly states >that it assumes that higher level protocols have their port numbers >in the first 64 bits). > > -David Borman > > -- ------------------------------------------------------------------------------- NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information meant for the sole use of the recipient(s) specified in the e-mail. Any unauthorized review, use, disclosure or distribution (including but not limited to: forwarding, replying to, or including recipients not included in the original e-mail) without the sender's prior approval is STRICTLY prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -------------------------------------------------------------------------------- --------------080309060600020206000708 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I would suspect that for the ICMP case, the IP ID wouldn't be too useful for the transport and above layers as these layers typically don't know (or care) about the ID in the IP header.

Even for the retransmit cases, typically new IDs are used and no attempt is made to reuse the ID with which the previously lost packet was sent.

Hoping that someone would clarify the purpose in life of the IP ID field if the don't fragment bit is set. One answer that Jamshid Mahdavi told me privately was that it would be useful at debugging time while looking at packet traces.

Thanks,

S.R.

David Borman wrote:
Just a minor nit that I feel should be clarified:

  
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: Fri, 13 Dec 2002 16:41:51 +0100 (CET)
Subject: Re: Question on "identification" field of IP header
    
...
  
Note that the portion of a packet returned in an ICMP does not include
even the IP source and destination addresses; the identification value
is almost the only value that can be relied upon to identify the
original packet upon getting an ICMP....
    

Actually, ICMP packets are supposed to return the entire IP header
(including options) plus 64 bits of the IP data.  So, you should get
up to the TCP and UDP port numbers.  (RFC 792 explicitly states
that it assumes that higher level protocols have their port numbers
in the first 64 bits).

			-David Borman
  

-- 
-------------------------------------------------------------------------------
NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information meant for the sole use of the recipient(s) specified in the e-mail. Any unauthorized review, use, disclosure or distribution (including but not limited to: forwarding, replying to, or including recipients not included in the original e-mail) without the sender's prior approval is STRICTLY prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
--------------------------------------------------------------------------------
--------------080309060600020206000708-- From owner-tcp-impl@grc.nasa.gov Fri Dec 13 13:38:33 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01276 for ; Fri, 13 Dec 2002 13:38:33 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 395616BA66 for ; Fri, 13 Dec 2002 13:41:01 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id gBDIPt6O025192 for tcp-impl-outgoing; Fri, 13 Dec 2002 13:25:55 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gBDIPqwg025174 for ; Fri, 13 Dec 2002 13:25:52 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gBDIPpEb006353 for ; Fri, 13 Dec 2002 13:25:51 -0500 (EST) Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 509C06BA2C for ; Fri, 13 Dec 2002 13:25:50 -0500 (EST) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id NAA11305; Fri, 13 Dec 2002 13:25:47 -0500 (EST) From: der Mouse Message-Id: <200212131825.NAA11305@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Fri, 13 Dec 2002 19:23:54 +0100 (CET) To: end2end-interest@postel.org, tcp-impl@grc.nasa.gov Subject: Re: Question on "identification" field of IP header In-Reply-To: <200212131714.gBDHEBr05725@frantic.weston.bsdi.com> References: <200212131714.gBDHEBr05725@frantic.weston.bsdi.com> Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit >> Note that the portion of a packet returned in an ICMP does not >> include even the IP source and destination addresses; [...] > Actually, ICMP packets are supposed to return the entire IP header > (including options) plus 64 bits of the IP data. Duh. You are, of course, correct. I even went and checked 792 when I wrote that; I don't know how I managed to misread it so egregiously. My apologies to everyone for spreading misinformation. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From owner-tcp-impl@grc.nasa.gov Sat Dec 14 16:26:41 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10606 for ; Sat, 14 Dec 2002 16:26:40 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 28B476BAC9 for ; Sat, 14 Dec 2002 16:29:08 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id gBEL8PGh028362 for tcp-impl-outgoing; Sat, 14 Dec 2002 16:08:25 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gBEL8Owg028358 for ; Sat, 14 Dec 2002 16:08:24 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gBEL8NEb016210 for ; Sat, 14 Dec 2002 16:08:23 -0500 (EST) Received: from prv-mail21.provo.novell.com (PRV-MAIL21.PROVO.NOVELL.COM [137.65.81.126]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 1521A6BAA4 for ; Sat, 14 Dec 2002 16:08:23 -0500 (EST) Received: from Novell.COM ([164.99.193.213]) by prv-mail21.provo.novell.com; Sat, 14 Dec 2002 14:08:05 -0700 Message-ID: <3DFB9D6D.700@Novell.COM> Date: Sat, 14 Dec 2002 14:06:53 -0700 From: Ramesh Shankar User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: end2end , TCP-IMPL Subject: Re: [e2e] Re: Question on "identification" field of IP header References: <3DFA4620.7060108@cs.unc.edu> In-Reply-To: <3DFA4620.7060108@cs.unc.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Thanks for the pointer. I have heard that the IP ID field is used for covert channel by hackers. Apparently a rogue SSL implementation was leaking session keys in the IP ID field. While not foolproof or the ultimate defense, if I don't need to use the IP ID field for IP datagrams with the don't fragment bit set (mostly TCP), then it may be useful as an intrusion detection technique. Thanks, S.R. Felix Hernandez-Campos wrote: > Ramesh Shankar wrote: > >> If the "Don't fragment bit" is set in the IP header, what purpose >> does the "identification" field serve? Why can't I simply put 0 for >> this field in such a case? I remember coming across some e-mail chain >> in one of the mailing lists (TCP-IMPL, e2e, TSVWG) about this issue >> and the interaction with NAT. But I am not sure what came out of that >> discussion. > > > You may want to have a look at Steve Bellovin's "A Technique for > Counting NATed Hosts", presented at IMW 2002. The paper discusses how > the IP header's ID field can be used to infer the number of hosts > behind a NAT box. > > Regards, > Felix. > -- ------------------------------------------------------------------------------- NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information meant for the sole use of the recipient(s) specified in the e-mail. Any unauthorized review, use, disclosure or distribution (including but not limited to: forwarding, replying to, or including recipients not included in the original e-mail) without the sender's prior approval is STRICTLY prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -------------------------------------------------------------------------------- From owner-tcp-impl@grc.nasa.gov Wed Dec 18 10:48:25 2002 Received: from seraph2.grc.nasa.gov (seraph2.grc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11230 for ; Wed, 18 Dec 2002 10:48:25 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 5F6D668A9E for ; Wed, 18 Dec 2002 10:50:56 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id gBIFZgOL011393 for tcp-impl-outgoing; Wed, 18 Dec 2002 10:35:42 -0500 (EST) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gBIFZeO6011385 for ; Wed, 18 Dec 2002 10:35:40 -0500 (EST) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id KAA27775; Wed, 18 Dec 2002 10:35:40 -0500 (EST) Message-Id: <200212181535.KAA27775@guns.lerc.nasa.gov> To: tcp-impl@grc.nasa.gov From: Mark Allman Reply-To: mallman@grc.nasa.gov Subject: FWD:: Re: Question on "identification" field of IP header Organization: BBN Technologies/NASA GRC Song-of-the-Day: Not Fade Away Date: Wed, 18 Dec 2002 10:35:40 -0500 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk ------- Forwarded Message Date: Fri, 13 Dec 2002 15:42:08 -0500 From: Felix Hernandez-Campos To: end2end , TCP-IMPL Subject: Re: Question on "identification" field of IP header Ramesh Shankar wrote: > If the "Don't fragment bit" is set in the IP header, what purpose does > the "identification" field serve? Why can't I simply put 0 for this > field in such a case? I remember coming across some e-mail chain in one > of the mailing lists (TCP-IMPL, e2e, TSVWG) about this issue and the > interaction with NAT. But I am not sure what came out of that discussion. You may want to have a look at Steve Bellovin's "A Technique for Counting NATed Hosts", presented at IMW 2002. The paper discusses how the IP header's ID field can be used to infer the number of hosts behind a NAT box. Regards, Felix. - -- Felix Hernandez-Campos http://www.cs.unc.edu/~fhernand ------- End of Forwarded Message From owner-tcp-impl@grc.nasa.gov Wed Dec 18 10:48:25 2002 Received: from seraph3.grc.nasa.gov (seraph3.grc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11232 for ; Wed, 18 Dec 2002 10:48:25 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id D61056BC6F for ; Wed, 18 Dec 2002 10:50:56 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id gBIFZ0Vo011200 for tcp-impl-outgoing; Wed, 18 Dec 2002 10:35:00 -0500 (EST) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gBIFYwO6011183 for ; Wed, 18 Dec 2002 10:34:58 -0500 (EST) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id KAA27758; Wed, 18 Dec 2002 10:34:58 -0500 (EST) Message-Id: <200212181534.KAA27758@guns.lerc.nasa.gov> To: tcp-impl@grc.nasa.gov From: Mark Allman Reply-To: mallman@grc.nasa.gov Subject: FWD:: Re: Question on "identification" field of IP header Organization: BBN Technologies/NASA GRC Song-of-the-Day: Not Fade Away Date: Wed, 18 Dec 2002 10:34:58 -0500 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk ------- Forwarded Message To: David Borman Cc: end2end-interest@postel.org, mouse@Rodents.Montreal.QC.CA, tcp-impl@grc.nasa.gov Subject: Re: Question on "identification" field of IP header Date: Fri, 13 Dec 2002 10:42:28 -0800 From: Kevin Fall And, the including of 64-bits of "data" was later updated by rfc1812: ... 4.3.2.3 Original Message Header Historically, every ICMP error message has included the Internet header and at least the first 8 data bytes of the datagram that triggered the error. This is no longer adequate, due to the use of IP-in-IP tunneling and other technologies. Therefore, the ICMP datagram SHOULD contain as much of the original datagram as possible without the length of the ICMP datagram exceeding 576 bytes. The returned IP header (and user data) MUST be identical to that which was received, except that the router is not required to undo any modifications to the IP header that are normally performed in forwarding that were performed before the error was detected (e.g., decrementing the TTL, or updating options). Note that the requirements of Section [4.3.3.5] supersede this requirement in some cases (i.e., for a Parameter Problem message, if the problem is in a modified field, the router must undo the modification). See Section [4.3.3.5]). ... - - K > > From: David Borman > To: end2end-interest@postel.org, mouse@Rodents.Montreal.QC.CA, tcp-impl@grc.nasa.gov > Subject: Re: Question on "identification" field of IP header > Date: Fri, 13 Dec 2002 11:14:11 CST > > Just a minor nit that I feel should be clarified: > > > From: der Mouse > > Date: Fri, 13 Dec 2002 16:41:51 +0100 (CET) > > Subject: Re: Question on "identification" field of IP header > ... > > Note that the portion of a packet returned in an ICMP does not include > > even the IP source and destination addresses; the identification value > > is almost the only value that can be relied upon to identify the > > original packet upon getting an ICMP.... > > Actually, ICMP packets are supposed to return the entire IP header > (including options) plus 64 bits of the IP data. So, you should get > up to the TCP and UDP port numbers. (RFC 792 explicitly states > that it assumes that higher level protocols have their port numbers > in the first 64 bits). > > -David Borman ------- End of Forwarded Message From owner-tcp-impl@grc.nasa.gov Wed Dec 18 10:48:26 2002 Received: from seraph2.grc.nasa.gov (seraph2.grc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11245 for ; Wed, 18 Dec 2002 10:48:26 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 9DDE868B09 for ; Wed, 18 Dec 2002 10:50:56 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id gBIFYIGq010960 for tcp-impl-outgoing; Wed, 18 Dec 2002 10:34:18 -0500 (EST) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gBIFYFO6010943 for ; Wed, 18 Dec 2002 10:34:15 -0500 (EST) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id KAA27748; Wed, 18 Dec 2002 10:34:15 -0500 (EST) Message-Id: <200212181534.KAA27748@guns.lerc.nasa.gov> To: tcp-impl@grc.nasa.gov From: Mark Allman Reply-To: mallman@grc.nasa.gov Subject: FWD:: Re: [e2e] Re: Question on "identification" field of IP header Organization: BBN Technologies/NASA GRC Song-of-the-Day: Not Fade Away Date: Wed, 18 Dec 2002 10:34:15 -0500 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk ------- Forwarded Message From: "alok" To: "der Mouse" , , Subject: Re: [e2e] Re: Question on "identification" field of IP header Date: Fri, 13 Dec 2002 22:18:46 +0530 think about the usage of that fields in ATM and MPLS core scenarios.... TCP_MSS can get screwed up... - ----- Original Message ----- From: der Mouse To: ; Sent: Friday, December 13, 2002 9:11 PM Subject: [e2e] Re: Question on "identification" field of IP header > > If the "Don't fragment bit" is set in the IP header, what purpose > > does the "identification" field serve? > > It says which datagram is affected if an ICMP is returned in resposne > to it, if nothing else. > > > I remember coming across some e-mail chain in one of the mailing > > lists (TCP-IMPL, e2e, TSVWG) about this issue and the interaction > > with NAT. > > Heh. My usual response to "NAT interacts badly with " is "don't > use NAT, then". It just breaks too many of the assumptions underlying > IP-based networking. But it wouldn't surprise me a bit if there were > NAT implementations broken enough to assume that packets with identical > IDs arriving within a small enough temporal window of one another were > actually the same packet. > > Note that the portion of a packet returned in an ICMP does not include > even the IP source and destination addresses; the identification value > is almost the only value that can be relied upon to identify the > original packet upon getting an ICMP.... > > /~\ The ASCII der Mouse > \ / Ribbon Campaign > X Against HTML mouse@rodents.montreal.qc.ca > / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B > ------- End of Forwarded Message From owner-tcp-impl@grc.nasa.gov Wed Dec 18 10:48:26 2002 Received: from seraph3.grc.nasa.gov (seraph3.grc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11246 for ; Wed, 18 Dec 2002 10:48:26 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 63CFD6BC76 for ; Wed, 18 Dec 2002 10:50:57 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id gBIFb7jw011856 for tcp-impl-outgoing; Wed, 18 Dec 2002 10:37:07 -0500 (EST) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gBIFb5O6011849 for ; Wed, 18 Dec 2002 10:37:05 -0500 (EST) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id KAA27795; Wed, 18 Dec 2002 10:37:05 -0500 (EST) Message-Id: <200212181537.KAA27795@guns.lerc.nasa.gov> To: tcp-impl@grc.nasa.gov From: Mark Allman Reply-To: mallman@grc.nasa.gov Subject: FWD:: Re: [e2e] Re: Question on "identification" field of IP header Organization: BBN Technologies/NASA GRC Song-of-the-Day: Not Fade Away Date: Wed, 18 Dec 2002 10:37:05 -0500 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk ------- Forwarded Message Date: Mon, 16 Dec 2002 14:14:05 -0800 From: "Fred L. Templin" To: Kevin Fall Cc: David Borman , end2end-interest@postel.org, mouse@Rodents.Montreal.QC.CA, tcp-impl@grc.nasa.gov Subject: Re: [e2e] Re: Question on "identification" field of IP header Kevin, Just wondering - do you have any idea of the proportion of implementations in the installed base that still implement the old standard vs. those that implement the "SHOULD" from rfc1812? It seems to me that a number of operational issues could be resolved if the outdated implementations were to move forward - any thoughts on how to encourage this among vendors? Thanks, Fred Templin ftemplin@iprg.nokia.com Kevin Fall wrote: > And, the including of 64-bits of "data" was later updated by rfc1812: > > ... > > 4.3.2.3 Original Message Header > > Historically, every ICMP error message has included the Internet > header and at least the first 8 data bytes of the datagram that > triggered the error. This is no longer adequate, due to the use of > IP-in-IP tunneling and other technologies. Therefore, the ICMP > datagram SHOULD contain as much of the original datagram as possible > without the length of the ICMP datagram exceeding 576 bytes. The > returned IP header (and user data) MUST be identical to that which > was received, except that the router is not required to undo any > modifications to the IP header that are normally performed in > forwarding that were performed before the error was detected (e.g., > decrementing the TTL, or updating options). Note that the > requirements of Section [4.3.3.5] supersede this requirement in some > cases (i.e., for a Parameter Problem message, if the problem is in a > modified field, the router must undo the modification). See Section > [4.3.3.5]). > > ... > > - K > > >>From: David Borman >>To: end2end-interest@postel.org, mouse@Rodents.Montreal.QC.CA, > > tcp-impl@grc.nasa.gov > >>Subject: Re: Question on "identification" field of IP header >>Date: Fri, 13 Dec 2002 11:14:11 CST >> >>Just a minor nit that I feel should be clarified: >> >> >>>From: der Mouse >>>Date: Fri, 13 Dec 2002 16:41:51 +0100 (CET) >>>Subject: Re: Question on "identification" field of IP header >> >>... >> >>>Note that the portion of a packet returned in an ICMP does not include >>>even the IP source and destination addresses; the identification value >>>is almost the only value that can be relied upon to identify the >>>original packet upon getting an ICMP.... >> >>Actually, ICMP packets are supposed to return the entire IP header >>(including options) plus 64 bits of the IP data. So, you should get >>up to the TCP and UDP port numbers. (RFC 792 explicitly states >>that it assumes that higher level protocols have their port numbers >>in the first 64 bits). >> >> -David Borman > > ------- End of Forwarded Message From owner-tcp-impl@grc.nasa.gov Wed Dec 18 11:41:46 2002 Received: from seraph2.grc.nasa.gov (seraph2.grc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11249 for ; Wed, 18 Dec 2002 10:48:26 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id F0C9D68AEB for ; Wed, 18 Dec 2002 10:50:56 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id gBIFaOuX011565 for tcp-impl-outgoing; Wed, 18 Dec 2002 10:36:24 -0500 (EST) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gBIFaMO6011558 for ; Wed, 18 Dec 2002 10:36:22 -0500 (EST) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id KAA27785; Wed, 18 Dec 2002 10:36:22 -0500 (EST) Message-Id: <200212181536.KAA27785@guns.lerc.nasa.gov> To: tcp-impl@grc.nasa.gov From: Mark Allman Reply-To: mallman@grc.nasa.gov Subject: FWD:: Re: [e2e] Re: Question on "identification" field of IP header Organization: BBN Technologies/NASA GRC Song-of-the-Day: Not Fade Away Date: Wed, 18 Dec 2002 10:36:22 -0500 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk ------- Forwarded Message From: Rick Jones Subject: Re: [e2e] Re: Question on "identification" field of IP header To: RShankar@Novell.COM Date: Mon, 16 Dec 2002 10:49:21 -0800 (PST) Cc: end2end-interest@postel.org, tcp-impl@grc.nasa.gov > Thanks for the pointer. I have heard that the IP ID field is used for > covert channel by hackers. Apparently a rogue SSL implementation was > leaking session keys in the IP ID field. While not foolproof or the > ultimate defense, if I don't need to use the IP ID field for IP > datagrams with the don't fragment bit set (mostly TCP), then it may be > useful as an intrusion detection technique. I'd be very careful fixing the IP ID - I have been told by one major "interconnect" vendor that some of their products have ways to allow the customer (at customers persistent request) to cause the devices to ignore and clear the DF bit... rick jones ------- End of Forwarded Message From owner-tcp-impl@grc.nasa.gov Wed Dec 18 13:01:13 2002 Received: from seraph3.grc.nasa.gov (seraph3.grc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14193 for ; Wed, 18 Dec 2002 13:01:13 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 0CF0F6BA5B for ; Wed, 18 Dec 2002 13:03:43 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id gBIHpnO1015625 for tcp-impl-outgoing; Wed, 18 Dec 2002 12:51:49 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gBIHpkWi015582; Wed, 18 Dec 2002 12:51:46 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gBIHpdPn007631; Wed, 18 Dec 2002 12:51:40 -0500 (EST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id F36AD68B52; Wed, 18 Dec 2002 11:23:09 -0500 (EST) Received: from isi.edu ([207.151.149.14]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id gBIGN8C06179; Wed, 18 Dec 2002 08:23:08 -0800 (PST) Message-ID: <3E00A0BF.1000407@isi.edu> Date: Wed, 18 Dec 2002 08:22:23 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mallman@grc.nasa.gov Cc: tcp-impl@grc.nasa.gov Subject: Re: FWD:: Re: [e2e] Re: Question on "identification" field of IP header References: <200212181536.KAA27785@guns.lerc.nasa.gov> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Mark Allman wrote: > > > ------- Forwarded Message > > From: Rick Jones > Subject: Re: [e2e] Re: Question on "identification" field of IP header > To: RShankar@Novell.COM > Date: Mon, 16 Dec 2002 10:49:21 -0800 (PST) > Cc: end2end-interest@postel.org, tcp-impl@grc.nasa.gov > > >>Thanks for the pointer. I have heard that the IP ID field is used for >>covert channel by hackers. Apparently a rogue SSL implementation was >>leaking session keys in the IP ID field. While not foolproof or the >>ultimate defense, if I don't need to use the IP ID field for IP >>datagrams with the don't fragment bit set (mostly TCP), then it may be >>useful as an intrusion detection technique. > > > I'd be very careful fixing the IP ID - I have been told by one major > "interconnect" vendor that some of their products have ways to allow > the customer (at customers persistent request) to cause the devices to > ignore and clear the DF bit... That would be a violation of the STDs (1812, 791), which could cause problems that would be very difficult to debug (e.g., path MTU, etc.) I.e., you're worried about changing the IP ID field because vendors who violate standards will break? Go right ahead, IMO. Laws for the lawless are a waste of effort (shades of NAT). Joe From owner-tcp-impl@grc.nasa.gov Wed Dec 18 21:26:11 2002 Received: from seraph3.grc.nasa.gov (seraph3.grc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26234 for ; Wed, 18 Dec 2002 21:26:11 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 5B0446BA43 for ; Wed, 18 Dec 2002 21:28:42 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id gBJ2G6jP016769 for tcp-impl-outgoing; Wed, 18 Dec 2002 21:16:06 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gBJ2G5Wi016763; Wed, 18 Dec 2002 21:16:05 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gBJ2G4Pn002752; Wed, 18 Dec 2002 21:16:04 -0500 (EST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id DE95868984; Wed, 18 Dec 2002 21:16:03 -0500 (EST) Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id gBJ2FeC29219; Wed, 18 Dec 2002 18:15:40 -0800 (PST) Message-ID: <3E012BCD.9080002@isi.edu> Date: Wed, 18 Dec 2002 18:15:41 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: richard@codeburst.co.uk Cc: mallman@grc.nasa.gov, tcp-impl@grc.nasa.gov Subject: Re: FWD:: Re: [e2e] Re: Question on "identification" field of IP References: <200212190122.BAA01846@starburst.demon.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Richard Wendland wrote: >>>I'd be very careful fixing the IP ID - I have been told by one major >>>"interconnect" vendor that some of their products have ways to allow >>>the customer (at customers persistent request) to cause the devices to >>>ignore and clear the DF bit... >> >>That would be a violation of the STDs (1812, 791), which could cause >>problems that would be very difficult to debug (e.g., path MTU, etc.) >> >>I.e., you're worried about changing the IP ID field because vendors who >>violate standards will break? Go right ahead, IMO. >> >>Laws for the lawless are a waste of effort (shades of NAT). > > An admirable attitude, but even Linux backtracked on this IP ID issue > when faced with practical connectivity problems. Linux for a time used > to set IP ID zero if DF was set, but went back to setting changing IP > IDs for TCP with DF. What I'm asserting is that what we do should be related to the standards, not necessarily what NAT-supporting vendors need to make their systems still work. I mean that anyone who clears the DF bit gets what they deserve - a nonfunctioning brick. > I'm not a Linux kernel developer, but I think that change back is related > to the comment in the kernel include/net/ip.h: > > /* This is only to work around buggy Windows95/2000 > * VJ compression implementations. If the ID field > * does not change, they drop every other packet in > * a TCP stream using header compression. > */ I'm not sure we want specs to provide workarounds for bugs. Bugs should be fixed at the source. > I also think I have observed a middlebox clearing DF; circumstantial > evidence not proof though. It appeared to me, from remote observation, > that a HTTP load balancing device was clearing DF on TCP segments > en-route from HTTP servers to clients. I presume this is because the load > balancer's developers could not be bothered to "route" ICMP fragmentation > needed back to the appropriate HTTP server. If this is correct, and the > load balancer isn't cleverly changing the IP ID, there could be problems > if TCP stacks don't set a real IP ID. ... > It's horrid, and wrong. But it is a problem for practical connectivity. It's a bug that needs to be fixed, but not one that should drive standards. Joe From owner-tcp-impl@grc.nasa.gov Wed Dec 18 23:38:28 2002 Received: from seraph2.grc.nasa.gov (seraph2.grc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28725 for ; Wed, 18 Dec 2002 23:38:27 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 7911568999 for ; Wed, 18 Dec 2002 23:40:57 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id gBJ4T4rT003926 for tcp-impl-outgoing; Wed, 18 Dec 2002 23:29:04 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gBJ4T3Wi003922 for ; Wed, 18 Dec 2002 23:29:03 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gBJ4T3Pn020426 for ; Wed, 18 Dec 2002 23:29:03 -0500 (EST) Received: from pop-1.dnv.wideopenwest.com (gtwy.nap.wideopenwest.com [64.233.207.11]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 9880E6898C for ; Wed, 18 Dec 2002 23:29:02 -0500 (EST) Received: from thoth.ir.bbn.com (d53-203-209.clv.wideopenwest.com [64.53.209.203]) by pop-1.dnv.wideopenwest.com (8.11.6/8.11.6) with ESMTP id gBJ4PrF18544 for ; Wed, 18 Dec 2002 22:25:53 -0600 Received: from thoth.ir.bbn.com (localhost [127.0.0.1]) by thoth.ir.bbn.com (8.12.6/8.12.6) with ESMTP id gBJ4XoJg040392 for ; Wed, 18 Dec 2002 23:33:51 -0500 (EST) (envelope-from mallman@thoth.ir.bbn.com) Message-Id: <200212190433.gBJ4XoJg040392@thoth.ir.bbn.com> To: tcp-impl@grc.nasa.gov From: Mark Allman Reply-To: tcp-impl@grc.nasa.gov Subject: Re: FWD:: Re: [e2e] Re: Question on "identification" field of IP Organization: BBN Technologies/NASA GRC Song-of-the-Day: Not Fade Away Date: Wed, 18 Dec 2002 23:33:50 -0500 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk ------- Forwarded Message From: Richard Wendland Subject: Re: FWD:: Re: [e2e] Re: Question on "identification" field of IP To: touch@ISI.EDU (Joe Touch) Date: Thu, 19 Dec 2002 01:22:44 +0000 (GMT) Cc: mallman@grc.nasa.gov, tcp-impl@grc.nasa.gov > > I'd be very careful fixing the IP ID - I have been told by one major > > "interconnect" vendor that some of their products have ways to allow > > the customer (at customers persistent request) to cause the devices to > > ignore and clear the DF bit... > > That would be a violation of the STDs (1812, 791), which could cause > problems that would be very difficult to debug (e.g., path MTU, etc.) > > I.e., you're worried about changing the IP ID field because vendors who > violate standards will break? Go right ahead, IMO. > > Laws for the lawless are a waste of effort (shades of NAT). An admirable attitude, but even Linux backtracked on this IP ID issue when faced with practical connectivity problems. Linux for a time used to set IP ID zero if DF was set, but went back to setting changing IP IDs for TCP with DF. I'm not a Linux kernel developer, but I think that change back is related to the comment in the kernel include/net/ip.h: /* This is only to work around buggy Windows95/2000 * VJ compression implementations. If the ID field * does not change, they drop every other packet in * a TCP stream using header compression. */ I believe that comment and associated code setting IP ID was added in Linux 2.4.4. I also think I have observed a middlebox clearing DF; circumstantial evidence not proof though. It appeared to me, from remote observation, that a HTTP load balancing device was clearing DF on TCP segments en-route from HTTP servers to clients. I presume this is because the load balancer's developers could not be bothered to "route" ICMP fragmentation needed back to the appropriate HTTP server. If this is correct, and the load balancer isn't cleverly changing the IP ID, there could be problems if TCP stacks don't set a real IP ID. It's horrid, and wrong. But it is a problem for practical connectivity. Richard - -- Richard Wendland richard@codeburst.co.uk ------- End of Forwarded Message From owner-tcp-impl@grc.nasa.gov Thu Dec 19 12:50:48 2002 Received: from seraph3.grc.nasa.gov (seraph3.grc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21433 for ; Thu, 19 Dec 2002 12:50:48 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 52E546BA94 for ; Thu, 19 Dec 2002 12:53:18 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id gBJHdNFn021970 for tcp-impl-outgoing; Thu, 19 Dec 2002 12:39:23 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gBJHdKWi021959; Thu, 19 Dec 2002 12:39:20 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gBJHdKPn022288; Thu, 19 Dec 2002 12:39:20 -0500 (EST) Received: from irongate.swansea.linux.org.uk (pc2-cwma1-4-cust86.swan.cable.ntl.com [213.105.254.86]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 3BD62689BE; Thu, 19 Dec 2002 12:39:19 -0500 (EST) Received: from irongate.swansea.linux.org.uk (localhost [127.0.0.1]) by irongate.swansea.linux.org.uk (8.12.5/8.12.5) with ESMTP id gBJIKBlQ029556; Thu, 19 Dec 2002 18:20:12 GMT Received: (from alan@localhost) by irongate.swansea.linux.org.uk (8.12.5/8.12.5/Submit) id gBJIKAEL029554; Thu, 19 Dec 2002 18:20:10 GMT X-Authentication-Warning: irongate.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: FWD:: Re: [e2e] Re: Question on "identification" field of IP From: Alan Cox To: Joe Touch Cc: richard@codeburst.co.uk, mallman@grc.nasa.gov, tcp-impl@grc.nasa.gov In-Reply-To: <3E012BCD.9080002@isi.edu> References: <200212190122.BAA01846@starburst.demon.co.uk> <3E012BCD.9080002@isi.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 19 Dec 2002 18:20:09 +0000 Message-Id: <1040322010.29151.18.camel@irongate.swansea.linux.org.uk> Mime-Version: 1.0 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 2002-12-19 at 02:15, Joe Touch wrote: > I'm not sure we want specs to provide workarounds for bugs. Bugs should > be fixed at the source. Yeah sure. Given some large vendors can't even get CIDR right still (try connecting to ftp2.linux.org.uk from various non Unix systems some day) I don't think we can expect vendors to fix their hardware. The reality is that even things like TCP ECN are still undeployable because large allegedly competent organisations have everything broken. Its only recently that tcp path mtu has become generically usable. Alan From owner-tcp-impl@grc.nasa.gov Thu Dec 19 13:10:56 2002 Received: from seraph2.grc.nasa.gov (seraph2.grc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21923 for ; Thu, 19 Dec 2002 13:10:56 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id BD19E68A68 for ; Thu, 19 Dec 2002 13:13:26 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id gBJI4eVp028041 for tcp-impl-outgoing; Thu, 19 Dec 2002 13:04:40 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gBJI4cWi028029; Thu, 19 Dec 2002 13:04:38 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gBJI4bPn027054; Thu, 19 Dec 2002 13:04:37 -0500 (EST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id C4431689B3; Thu, 19 Dec 2002 13:04:35 -0500 (EST) Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id gBJI4OC20053; Thu, 19 Dec 2002 10:04:24 -0800 (PST) Message-ID: <3E020A29.3090108@isi.edu> Date: Thu, 19 Dec 2002 10:04:25 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Cox Cc: richard@codeburst.co.uk, mallman@grc.nasa.gov, tcp-impl@grc.nasa.gov Subject: Re: FWD:: Re: [e2e] Re: Question on "identification" field of IP References: <200212190122.BAA01846@starburst.demon.co.uk> <3E012BCD.9080002@isi.edu> <1040322010.29151.18.camel@irongate.swansea.linux.org.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Alan Cox wrote: > On Thu, 2002-12-19 at 02:15, Joe Touch wrote: > >>I'm not sure we want specs to provide workarounds for bugs. Bugs should >>be fixed at the source. > > > Yeah sure. Given some large vendors can't even get CIDR right still (try > connecting to ftp2.linux.org.uk from various non Unix systems some day) > I don't think we can expect vendors to fix their hardware. Agreed. Perhaps we make interim software patches, but we don't adjust specs. If vendors can't get the first spec right, what is the point of making a modified spec? > The reality is that even things like TCP ECN are still undeployable > because large allegedly competent organisations have everything broken. > Its only recently that tcp path mtu has become generically usable. Agreed on both counts. IMO, endsystems should deploy many such things as 'default off' - so that those interested in playing in the _experiment_ of trying them can, accepting the risk of debugging it up front. (but then, I think the IETF doesn't take full use of the experimental track as a stepping stone to draft standard). Joe From owner-tcp-impl@grc.nasa.gov Fri Dec 27 18:47:41 2002 Received: from seraph3.grc.nasa.gov (seraph3.grc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16560 for ; Fri, 27 Dec 2002 18:47:41 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 26D896BAAE for ; Fri, 27 Dec 2002 18:50:12 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id gBRNTPHU028125 for tcp-impl-outgoing; Fri, 27 Dec 2002 18:29:25 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gBRNTN48028119 for ; Fri, 27 Dec 2002 18:29:23 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gBRNTNPn010073 for ; Fri, 27 Dec 2002 18:29:23 -0500 (EST) Received: from lawyers.ir.bbn.com (d53-203-209.clv.wideopenwest.com [64.53.209.203]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 7EA206B9ED for ; Fri, 27 Dec 2002 18:29:22 -0500 (EST) Received: from lawyers (mallman@localhost) by lawyers.ir.bbn.com (8.9.3/8.9.3) with ESMTP id RAA15264 for ; Fri, 27 Dec 2002 17:22:55 -0500 Message-Id: <200212272222.RAA15264@lawyers.ir.bbn.com> To: tcp-impl@grc.nasa.gov From: Mark Allman Reply-To: tcp-impl@grc.nasa.gov Subject: Re: FWD:: Re: [e2e] Re: Question on "identification" field of IP Organization: BBN Technologies/NASA GRC Song-of-the-Day: Night Moves Date: Fri, 27 Dec 2002 17:22:55 -0500 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk ------- Forwarded Message Date: Thu, 19 Dec 2002 12:53:26 +0100 From: Andi Kleen To: Joe Touch Cc: richard@codeburst.co.uk, mallman@grc.nasa.gov, tcp-impl@grc.nasa.gov Subject: Re: FWD:: Re: [e2e] Re: Question on "identification" field of IP > I mean that anyone who clears the DF bit gets what they deserve - a > nonfunctioning brick. The most common scenario in my experience is VPN boxes not copying DF when they encapsulate a TCP packet into an IPSEC header. The reason is that doing so would require working path mtu discovery to the TCP sender to tell it about the smaller MTU, and path mtu discovery is often broken due to packet filters blocking all of ICMP or NAT gateways not properly rewriting ICMP frag-needed. This has the same effect in the network. Worse as noted earlier in the thread some routers do not send enough headers to reconstruct the original sender after IPSEC decapsulation. (I don't know if it is still the case but at one point routers from a particular popular router vendor were notorious for this in their default configuration - they only returned 64bits of payload) The worst part is that many IPSEC implementations drop ICMPs for security reasons when they don't contain the full original packet, because it is impossible to authenticate it otherwise (and they would be vunerable to a DoS of an attacker forcing an unusable small MTU on them with forged ICMPs). ICMPs are only required to fill up 576 bytes to avoid fragmentation, but TCP packets tend to be much bigger than that. In fact the ICMP cannot be bigger than the MTU and when the MTU the TCP/IPSEC packet was formatted for is the same as the ICMP is sending then the ICMP sender has no choice but to drop some part of the payload because the ICMP header takes space too (or fragment, which is forbidden) The only alternative they have is to not copy DF and don't do path MTU discovery. Of course for a common scenario (VPN gateway receiving and sending on the same MTU) after adding the IPSEC header this results in getting every full sized packet being fragmented into two packets. This disturbs all the TCP packet accounting mechanisms and makes the connection react very badly to any packet loss. - -Andi ------- End of Forwarded Message From owner-tcp-impl@grc.nasa.gov Sun Dec 29 19:33:24 2002 Received: from seraph3.grc.nasa.gov (seraph3.grc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04983 for ; Sun, 29 Dec 2002 19:33:24 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id BB14D6BA2C for ; Sun, 29 Dec 2002 19:36:01 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id gBU0KNoo026157 for tcp-impl-outgoing; Sun, 29 Dec 2002 19:20:23 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gBU0KM48026153 for ; Sun, 29 Dec 2002 19:20:22 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gBU0KMPn000369 for ; Sun, 29 Dec 2002 19:20:22 -0500 (EST) Received: from irongate.swansea.linux.org.uk (pc2-cwma1-4-cust86.swan.cable.ntl.com [213.105.254.86]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 1E4936896D for ; Sun, 29 Dec 2002 19:20:21 -0500 (EST) Received: from irongate.swansea.linux.org.uk (localhost [127.0.0.1]) by irongate.swansea.linux.org.uk (8.12.5/8.12.5) with ESMTP id gBU11jHZ001340 for ; Mon, 30 Dec 2002 01:01:46 GMT Received: (from alan@localhost) by irongate.swansea.linux.org.uk (8.12.5/8.12.5/Submit) id gBU11heN001338; Mon, 30 Dec 2002 01:01:44 GMT X-Authentication-Warning: irongate.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: FWD:: Re: [e2e] Re: Question on "identification" field of IP From: Alan Cox To: tcp-impl@grc.nasa.gov In-Reply-To: <200212272222.RAA15264@lawyers.ir.bbn.com> References: <200212272222.RAA15264@lawyers.ir.bbn.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 30 Dec 2002 01:01:43 +0000 Message-Id: <1041210103.1215.13.camel@irongate.swansea.linux.org.uk> Mime-Version: 1.0 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2002-12-27 at 22:22, Mark Allman wrote: > The most common scenario in my experience is VPN boxes not > copying DF when they encapsulate a TCP packet into an IPSEC header. There are reasons for doing this. Given an ICMP must fragment response to an IPSEC frame how do you prove the ICMP frame is valid. DF and IPSEC don't mix. When you mix them via a magic box in the middle its even worse because the ICMP may be hostile and the man in the middle box is hard pushed to tell. Certainly it would have to keep state and handle rate filtering and issue its own equivalent 'vetted' icmp frames. > The worst part is that many IPSEC implementations drop ICMPs > for security reasons when they don't contain the full > original packet, because it is impossible to authenticate > it otherwise (and they would be vunerable to a DoS of > an attacker forcing an unusable small MTU on them with > forged ICMPs). It happens unfortunately. Several years ago people were trying to drop BGP peering sessions down to 68 byte frames (which really messes things up). Rock and a hard place..IPv6 makes it even more fun