Re: Problem of blocking ICMP packets
Sally Floyd <floyd@icir.org> Wed, 16 June 2004 22:05 UTC
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21389 for <ietf-archive@ietf.org>; Wed, 16 Jun 2004 18:05:11 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BaiWs-00077i-G0 for ietf-archive@ietf.org; Wed, 16 Jun 2004 18:05:10 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BaiRz-0005bw-00 for ietf-archive@ietf.org; Wed, 16 Jun 2004 18:00:08 -0400
Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BaiOx-0004T6-02; Wed, 16 Jun 2004 17:56:59 -0400
Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BaiM2-0006gB-AL; Wed, 16 Jun 2004 17:53:58 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bahhk-00080w-Ne; Wed, 16 Jun 2004 17:12:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BagB0-0007I4-Hp for ietf@megatron.ietf.org; Wed, 16 Jun 2004 15:34:26 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08135 for <ietf@ietf.org>; Wed, 16 Jun 2004 15:34:24 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BagAw-0006jV-BJ for ietf@ietf.org; Wed, 16 Jun 2004 15:34:22 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bafj7-0001LH-00 for ietf@ietf.org; Wed, 16 Jun 2004 15:05:39 -0400
Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx with esmtp (Exim 4.12) id 1Baei3-0001mJ-00 for ietf@ietf.org; Wed, 16 Jun 2004 14:00:27 -0400
Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.9p1/8.12.8) with ESMTP id i5GI0TCS079218; Wed, 16 Jun 2004 11:00:29 -0700 (PDT) (envelope-from floyd@cougar.icir.org)
Message-Id: <200406161800.i5GI0TCS079218@cougar.icir.org>
To: Christian Huitema <huitema@windows.microsoft.com>
From: Sally Floyd <floyd@icir.org>
Date: Wed, 16 Jun 2004 11:00:29 -0700
Cc: Alberto Medina <medina@icsi.berkeley.edu>, ietf@ietf.org, Rajat <myself_rajat@yahoo.com>, Mark Allman <mallman@icir.org>
Subject: Re: Problem of blocking ICMP packets
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Christian - >This restriction affects the way we design protocol extensions. I see >that as an argument for "in-band" signaling, e.g. parameters in TCP >packets or in IP headers of TCP packets, by opposition to "out of band", >e.g. ICMP messages. Yes, that is the thought behind things like the proposal for QuickStart ("http://www.icir.org/floyd/papers/draft-amit-quick-start-02.txt"), which would use an IP Option in the TCP SYN packet to find out if the TCP sender would start off with a higher initial sending rate. However, there is another section of our recent measurement paper, Section V.C., with our measurements of paths that block known and/or unknown IP options on paths to web servers: "As Figure 5 shows, in many cases no connection was established when the [IP] Record Route Option or the [IP] Timestamp Option was included in the SYN packet. When IP Option X [a new IP Option; e.g., QuickStart] is included in the SYN segment, the connection was not established to over 70% of the web servers tested. This does not bode well for the deployment of new IP options in the Internet." Of course, this involves IP Options on SYN packets on the path *to* the web server. If something like QuickStart was ever standardized, the IP Option would only be needed on the path *from* the web server to the browser. Presumeably if the web server wanted to use something like QuickStart, it could have the firewall configured to allow the IP QuickStart Option not to be blocked on the outgoing SYN packet? And the receiver could have the firewall on their end configured to allow the IP QuickStart option on the incoming SYN packet to pass? I don't know. However, the fact that connections fail today when unknown IP Options are used on the SYN from the browser to the web server does not *necessarily* mean that there is no hope for using IP Options for in-band signalling. The good news is that known or unknown TCP options are not blocked on paths to web servers. Or at any rate, the connection still succeeds in being established... - Sally Measuring the Evolution of Transport Protocols in the Internet: http://www.icir.org/tbit/ _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
- Problem of blocking ICMP packets Rajat
- RE: Problem of blocking ICMP packets Christian Huitema
- Re: Problem of blocking ICMP packets Masataka Ohta
- Re: Problem of blocking ICMP packets Iljitsch van Beijnum
- Re: Problem of blocking ICMP packets Mark Smith
- Oops, quote in the wrong place (Re: Problem of bl… Mark Smith
- Re: Firewalling for the new millennium, was: Prob… Iljitsch van Beijnum
- Re: Problem of blocking ICMP packets Masataka Ohta
- Re: Problem of blocking ICMP packets Mark Smith
- Re: Problem of blocking ICMP packets Masataka Ohta
- Re: Firewalling for the new millennium, was: Prob… Melinda Shore
- Re: Problem of blocking ICMP packets Dean Anderson
- Re: Problem of blocking ICMP packets Masataka Ohta
- Re: Problem of blocking ICMP packets Mark Smith
- Re: Problem of blocking ICMP packets Matt Mathis
- Re: Problem of blocking ICMP packets Dean Anderson
- Re: Problem of blocking ICMP packets Anthony DeRobertis
- Re: Problem of blocking ICMP packets Masataka Ohta
- Re: Problem of blocking ICMP packets Masataka Ohta
- Re: Problem of blocking ICMP packets Anthony DeRobertis
- Re: Problem of blocking ICMP packets Mark Smith
- Re: Problem of blocking ICMP packets Masataka Ohta
- Re: Problem of blocking ICMP packets Mark Smith
- Re: Problem of blocking ICMP packets Masataka Ohta
- Re: Problem of blocking ICMP packets Iljitsch van Beijnum
- Re: Problem of blocking ICMP packets Sally Floyd
- Re: Problem of blocking ICMP packets Mike S
- RE: Problem of blocking ICMP packets Christian Huitema
- Re: Problem of blocking ICMP packets Valdis.Kletnieks
- Re: Problem of blocking ICMP packets Vernon Schryver
- Re: Problem of blocking ICMP packets Sally Floyd
- Re: Problem of blocking ICMP packets Armando L. Caro Jr.
- Re: Problem of blocking ICMP packets Michael Richardson
- Re: Problem of blocking ICMP packets Eric A. Hall
- Re: Problem of blocking ICMP packets Masataka Ohta
- RE: Problem of blocking ICMP packets Soliman Hesham
- Re: Problem of blocking ICMP packets Jean-Jacques Puig
- RE: Problem of blocking ICMP packets Soliman Hesham
- Re: Problem of blocking ICMP packets Joe Touch
- Re: Problem of blocking ICMP packets Harald Koch
- Re: Problem of blocking ICMP packets Mark Allman
- Re: Problem of blocking ICMP packets Valdis.Kletnieks
- Regarding IP address allocation Rajat
- Re: Regarding IP address allocation Harald Tveit Alvestrand