Subject: Re: Problem of blocking ICMP packets

From: Sally Floyd <[email-masked]>
Date: Wed, 16 Jun 2004 11:00:29 -0700

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 17 Jun 2004 08:51:20 +0900

Sally Floyd;

>  the deployment of new IP options in the Internet."

It implies that mobile IPv6 depndeing on routing header
may not work.

> If something like QuickStart was ever standardized,
> pass?  I don't know.

Presumeably if the web server wanted to use something
like PMTUD, it could have the firewall configured to allow related
ICMP not to be blocked. And the receiver could have the firewall
on their end configured to allow the ICMP to pass. You know.

> However, the fact that connections fail today

Same for PMTUD with out-band signalling.

> succeeds in being established...

As long as routers are not required to look into TCP options,
they are likely to interoperate even with complex TCP options.

						Masataka Ohta

---

From: [email-masked]
Date: Thu, 17 Jun 2004 11:23:02 -0400

> IP QuickStart Option not to be blocked on the outgoing SYN packet?

Given the number of times we've had IWF reports that basically boil
down to 'ntp-[12].vt.edu is probing me from port 123", and even more
interestingly the number of times we've been asked by the remote user
why their machine is trying to contact ntp-1.vt.edu, I have to classify
the concept that "People will remember to put appropriate punchouts
in their firewall when they deploy a service" as "wishful thinking".
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf