Subject: RE: Problem of blocking ICMP packets

From: "Christian Huitema" <[email-masked]>
Date: Wed, 16 Jun 2004 10:19:32 -0700

> "Since a non-trivial number of network elements discard well-known
> ICMP packets the results of our tests do not offer hope for protocol
> designers proposing to use new ICMP messages to signal various
> network path properties to end systems (e.g., for explicit corruption
> notification, handoff or outage notification, etc.)."

Yes, this is a very serious issue. Very often, a server that is
configured for a service will open exactly the port necessary for that
service, and drop all other traffic. For example, a web server will
accept TCP packets sent to ports 80 and 443, but it will either drop
everything else, or be located behind a firewall that drops everything
else. 

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. 

-- Christian Huitema

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Jun 2004 16:28:51 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Christian" == Christian Huitema <[email-masked]> writes:
    Christian> This restriction affects the way we design protocol
    Christian> extensions. I see that as an argument for "in-band"
    Christian> signaling, e.g. parameters in TCP packets or in IP
    Christian> headers of TCP packets, by opposition to "out of band",
    Christian> e.g. ICMP messages.

  But, that doesn't work either.
  The boxes that are responsible for 90% of the ICMP lossage were also 
intolerant of the ECN options in TCP, and pretty much all TCP options in
general.

  The boxes are broken.
  The faster we make this clear, the better.

  The biggest mistake we made with ICMP (and ICMPv6) was in assigning 
an IP-level protocol number to it. We should have done it with IP
options instead. That would make it clear that the information carried
by ICMP is really part of layer 3, rather than being some new layer-4.

  I don't have a fix for this, alas. I think the ICMP design was very
elegant. The problem has been a decade of firewall deployment done by people
who didn't understand the protocols. This can't be easily reversed.

- --
]     "Elmo went to the wrong fundraiser" - The Simpson         |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 16 Jun 2004 16:28:10 -0500

On 6/16/2004 12:19 PM, Christian Huitema wrote:

> This restriction affects the way we design protocol extensions.

said restrictions on extensions apply to TCP as well

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Mark Allman <[email-masked]>
Date: Wed, 16 Jun 2004 22:52:20 -0400

A couple bits to add to the discussion.

> intolerant of the ECN options in TCP, and pretty much all TCP options in

This is not quite right, IMO.  In the past there have been problems with
packets with the ECN bits set getting through the network (see the
original TBIT SIGCOMM paper - available from http://www.icir.org/tbit/).
However, our recent measurements show that this is not as much of a
problem anymore.  And, contrary the the above assertion, blocking based
on ECN is not nearly as prevalent as PMTUD failure.  Our measurements do
not speak to whether the boxes that block ECN also block PMTUD.  If
someone has such measurements, we'd love to hear about them.

Masataka Ohta:
> > 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...
> 
> As long as routers are not required to look into TCP options, they are
> likely to interoperate even with complex TCP options.

The trouble is that it just isn't routers getting their grimy hands on
our packets these days.  Middleboxes look at, touch and mangle packets
for all sorts of reasons (from transparent caches to performance
enhancing proxies to normalizers to protocol scrubbers to load balancers
to ....).  So, while our measurements show no problems with TCP options,
I don't think it is a foregone conclusion, nor not something to keep our
collective eye on.

allman