Subject: Re: Problem of blocking ICMP packets

From: Sally Floyd <[email-masked]>
Date: Tue, 15 Jun 2004 21:34:45 -0700

Alberto Medina, Mark Allman, and I have a draft paper on
"Measuring the Evolution of Transport Protocols in the Internet"
that has a section (Section V.B.) on Path MTU Discovery.
>From the paper:

"Table X shows that PMTUD is used and succeeded for slightly less
than half of the [web] servers on our list.  For 31\% of the servers
on our list, the server did not attempt Path MTU Discovery.  For
18\% of the servers on our list, Path MTU Discovery failed, presumably
because of middleboxes that block ICMP packets on the path to the
web server."
...
"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.)."

We would appreciate any feedback, either on the paper, or on other
measurement studies that would be useful on sometimes-unanticipated
interactions between transport protocols and routers or middleboxes.

The paper and test code are both available from 
"http://www.icir.org/tbit/".

- Sally
http://www.icir.org/floyd/

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

---

From: [email-masked] (Mike S)
Date: Wed, 16 Jun 2004 11:23:44 -0400

At 12:34 AM 6/16/2004, Sally Floyd wrote...
>because of middleboxes that block ICMP packets on the path to the

Any router configured to block ICMP packets is, quite simply,
in violation of RFC792 (STD5), which clearly states "ICMP is actually 
an integral part of IP, and must be implemented by every IP module." 
For a router, "implemented" means forwarded to the destinations next
hop.

So the fact is, by blocking ICMP, such ISPs have broken IP connectivity, 
and can no longer claim to be providing Internet (IP) service.

---

From: [email-masked]
Date: Wed, 16 Jun 2004 13:23:40 -0400

> and can no longer claim to be providing Internet (IP) service.

Be careful there - that's uncomfortably close to saying that every firewall
in existence is in violation of the RFCs, because they intentionally don't
make a best-effort attempt to deliver every packet (I know of no vendors
whos gear *can't* forward ICMP - but know plenty that provide knobs
to prevent it under administrative control (i.e. a firewall))...

An even more annoying problem is when our site sends a packet with
the DF bit set, it hits a tunnel near the far end - and the ICMP returned
has an RFC1918 source address (You tier-1 and tier-2 who number their
links out of 1918 know who you are..;).  The ICMP is then dropped on
the return path by a router properly implementing martian filtering...
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 16 Jun 2004 12:02:35 -0600 (MDT)

> From: [email-masked] (Mike S)

> and can no longer claim to be providing Internet (IP) service.

I agree, but which flavor of other than "Full Internet Connectivity"
would it be?  Does
http://www.ietf.org/internet-drafts/draft-klensin-ip-service-terms-02.txt
need a category of "Public address, stupid filtering"?
Or is "Client only, public address" close enough?

Many people who install or defend such stupid filters are offended by
the observation that they are not doing real IP.  Labelling such
filtered access as what it is or at least something other than "Full
Internet Connectivity" would reduce its popularity.

Vernon Schryver    [email-masked]

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Wed, 16 Jun 2004 14:27:57 -0400 (EDT)

> and can no longer claim to be providing Internet (IP) service.
      ^^^^^^^^^^^^^^^^^^^

Actually, the fact is that they _can_ and they _do_ claim to provide IP
service even though they _shouldn't_. So we should be searching for ways
to discourage ISPs from blocking ICMP. We could spend energy replacing
each of ICMP's uses (such as PMTU discovery), but that would probably just
split the original problem (ICMP's security vulnerabilities) into smaller
problems and push them into other areas.

~armando

0--                                              --0
| Armando L. Caro Jr.  |  Protocol Engineering Lab |
| www.armandocaro.net  |    University of Delaware |
0--                                              --0

---

From: Joe Touch <[email-masked]>
Date: Wed, 16 Jun 2004 13:01:41 -0700

> For a router, "implemented" means forwarded to the destinations next

RFC1812, Sec 5.2.7.1, where the 'frag needed' variant is mentioned (type 
3, code 4), is more specific on this point. Routers must emit these 
errors - or, if administrative restrictions apply, code 13 
"Communication Administratively Prohibited" errors.

> and can no longer claim to be providing Internet (IP) service.

The same can be said for those providing NAT'd IP service, for similar 
reasons. ;-)

Joe

---

From: "Harald Koch" <[email-masked]>
Date: Wed, 16 Jun 2004 19:08:37 -0400

> and can no longer claim to be providing Internet (IP) service.

<yawn> This debate has been going on since before I became a firewall
developer back in 1995...

Unfortunately, customers are more interested in a "usable" internet than a
"correct" one. As long as the bad guys keep abusing ICMP, we security people
will keep blocking it. The trick, therefore, is to convince the "block
everything" crowd to be selective about ICMP the same way they are selective
about (eg) TCP port numbers.

It's pretty easy these days to write good firewall rules that allow, for
example, Path MTU discovery to work.The "RELATED" state in Linux's iptables
rules is a good start...

-- 
Harald Koch [email-masked]