Subject: Problem of blocking ICMP packets

From: Rajat <[email-masked]>
Date: Fri, 7 May 2004 04:49:52 -0700 (PDT)

Dear All,
I am in process of implementing Path MTU detection technique. So for that I have to send ICMP ECHO request packets to destination host, and process the received ICMP ECHO reply packets.
I read that the ICMP server is embedded in the kernel of OS itself, so there is no need to write server code at all. So for sending and receiving of ICMP packets we will use raw sockets without specifying any port number.
But in between the network, some routers have some firewall configuration so that they will simply drop any incomming ICMP packet without sending any response to the sender. Hence originating host will not be aware of the status of destination host.
These firewall settings are due to some attacks like Ping of deth, Denial of request etc.
Can any one provide me any solution to overcome this problem. 
 
Thanks in advance.

---------------------------------
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 08 May 2004 05:35:01 +0900

> Can any one provide me any solution to overcome this problem. 

In addition to PMTUD, you should have PMUTD availability
discovery that if it is discovered, say by persistent lack
of responses, that PMTUD is not working, you should turn off
PMTUD and just live with fragmentations.

I recommend that, to avoid long initial delay and intermediate
lack of communication after path changes of, PMTUD should turnd
off by default and should be activated only on extreme
conditions.

Further, it should be noted that PMTUD is so unreliable that
no applications rely on it, which means that even under
extreme conditions rational operators won't turn on PMTUD.

In short, forget PMTUD.
						Masataka Ohta

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

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 08 May 2004 05:35:01 +0900

In short, forget PMTUD.
						Masataka Ohta

---

From: Dean Anderson <[email-masked]>
Date: Sun, 9 May 2004 19:33:39 -0400 (EDT)

> off by default and should be activated only on extreme

Just the opposite, unless you want to lose connectivity with a number of 
web servers that want to send big packets with DF turned on.

> extreme conditions rational operators won't turn on PMTUD.

It is not true that no applications rely on PMTU. A number of commercial
products and applications do rely on PMTU to work, and will do an PATH MTU 
discovery, and send the MTU sized packets with DF (don't frag).  If you 
have a smaller MTU somewhere that was not discovered, such DF marked 
packets will be dropped.

This is the first I have heard that path mtu discovery software was
unreliable.  I have only heard that those that block ICMP echo have had
problems.  This doesn't make PMTU unreliable. It makes the concept of
blocking ICMP echo unwise.

I suggest, that if you want to use security by obscurity, that you use 
NAT, and that you permit ICMP echo to the NAT device.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Sun, 9 May 2004 19:33:39 -0400 (EDT)

--Dean

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 10 May 2004 10:55:43 +0900

Dean Anderson;

> web servers that want to send big packets with DF turned on.

There were (still are?) number of web servers that wanted to send
big packets with DF turned on, because PMTUD was turned on on the
servers but ICMP errors were filtered.

> A number of commercial
> discovery, and send the MTU sized packets with DF (don't frag).

and send packets larger than MTU expecting to receive ICMP
errors in vain.

Read the original mail of the thread on the reality.

> unreliable.

PMTUD software is unreliable!?

Then, it is anther reason to avoid it.

Can you tell me who said it with an appropriate reference?

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 10 May 2004 10:55:43 +0900

Dean Anderson;

						Masataka Ohta

---

From: Mark Smith <[email-masked]>
Date: Mon, 10 May 2004 13:02:10 +0930

On Mon, 10 May 2004 10:55:43 +0900

> > A number of commercial
> > products and applications do rely on PMTU to work, and will
> > do an PATH MTU discovery, and send the MTU sized packets with
> > DF (don't frag).
> 

The problem identified has nothing to do with the concept or
typical implementations of PMTUD being broken.

RFC1192 (http://www.rfc-editor.org/rfc/rfc1191.txt) is the spec
for PMTUD. 

The issue that PMTUD is addressing is :

"1. Introduction

   When one IP host has a large amount of data to send to another
host, the data is transmitted as a series of IP datagrams.  It
is usually preferable that these datagrams be of the largest
size that does not require fragmentation anywhere along the path
from the source to the  destination.  (For the case against
fragmentation, see [5].)  This datagram size is referred to as
the Path MTU (PMTU), and it is equal to the minimum of the MTUs
of each hop in the path. A shortcoming of the current Internet
protocol suite is the lack of a standard mechanism for a host
to discover the PMTU of an arbitrary path."

PMTUD is a performance optimisation, specifically a throughput
optimisation. 

The problem being discussed is directly caused by broken
firewall/NAT devices or configurations, blocking network
management traffic (ie. ICMP Destination Unreachable,
Fragmentation Needed and Don't Fragment was Set) that they
should be permitting.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Mon, 10 May 2004 13:02:10 +0930

"1. Introduction

Regards,
Mark.

---

From: Dean Anderson <[email-masked]>
Date: Mon, 10 May 2004 13:53:42 -0400 (EDT)

> servers but ICMP errors were filtered.

There still are such apps.  I ran into this recently, last winter.

I'd suggest those complaining should get a few more clues about what ICMP
does, and stop filtering ICMP packets that aren't threatening.  The
network can't possibly work if people are going to turn critical parts of
it off, parts that they don't fully understand.  There is no surprise that
they have problems. This isn't a reason to change the network. There are
other things that they don't understand, and could turn off.  One can't
remove all switches and levers.

> Read the original mail of the thread on the reality.

I think we disagree on the "reality". The reality is that most sensible
people and ISPs don't block harmless ICMP messages. Of course, not _all_
ICMP messages from anywhere are harmless, but that doesn't mean that all
such messages are all harmful.  Blocking everything is a club-footed
method of security, if you'll pardon the pun.

Those that pick such an approach cannot be accomodated, because they're
clubfooted, as it were---if it isn't this, its something else.  
Cluelessly turning things off will have a bad effect on any system. Case
in point: It seems that something similar (in principle anyway) was what
caused the Three Mile Island Nuclear Plant to melt down: The operators
turned off the emergency cooling system pumps wrongly. It took an engineer
to tell them to turn them back on, but by then it was too late to prevent
damage.  People have suggested that the switch to turn off the pumps
should be removed from all nuclear plants. This is also wrong. There might
be a need to do that someday.

The solution is to better train the operators, so that they don't mess
with things they don't fully understand.  This is just as true of
networks, as it is of nuclear power plants. Probably more so of networks,
since these sorts of things happen more frequently, and even the network
engineers aren't nearly as uniformly trained, much less so the operators.

> Can you tell me who said it with an appropriate reference?

Err, _you_ said it:

---

From: Dean Anderson <[email-masked]>
Date: Mon, 10 May 2004 13:53:42 -0400 (EDT)

Err, _you_ said it:

---

From: Anthony DeRobertis <[email-masked]>
Date: Mon, 10 May 2004 14:01:29 -0400

On May 9, 2004, at 19:33, Dean Anderson wrote:
> I have only heard that those that block ICMP echo have had
> problems.

Nothing to do with ICMP echo. It's blocking ICMP unreachable, 
fragmentation needed that causes problems.

ICMP unreachables related to known connections should be allowed 
through the firewall.

---

From: Anthony DeRobertis <[email-masked]>
Date: Mon, 10 May 2004 14:01:29 -0400

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 11 May 2004 03:48:57 +0900

Mark Smith;

> typical implementations of PMTUD being broken.

Wrong.

> RFC1192 (http://www.rfc-editor.org/rfc/rfc1191.txt) is the spec

Read the RFC.

It says "To detect increases in a path's PMTU, a host periodically
increases its assumed PMTU".

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 11 May 2004 03:48:57 +0900

Mark Smith;

Wrong.

Read the RFC.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 11 May 2004 04:25:16 +0900

Dean Anderson;

> There still are such apps.  I ran into this recently, last winter.

So, that is the reality. Note that we run into this only if
there are both such servers and such filters.

> The
> network can't possibly work if people are going to turn
> critical parts of it off, parts that they don't fully understand.

The most critical ICMP generated by intermediate routers is
TTL exceeded, I think, though it is not critical for real
applications.

We can do without others. However, there are people who want to
invent inappropriate use of inessential features. For example,
TCP should not be disconnected upon network unreachable ICMP but
some TCP did. PMTUD is, IMHO, another example.

> people and ISPs don't block harmless ICMP messages.

Sensible people should block PMTUD, too.

> Err, _you_ said it:

I never said software unreliable.

Note that an example of unreliable software is Windows.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 11 May 2004 04:25:16 +0900

Dean Anderson;

						Masataka Ohta

---

From: Anthony DeRobertis <[email-masked]>
Date: Mon, 10 May 2004 16:03:24 -0400

> Sensible people should block PMTUD, too.

Why? Do you just enjoy breaking random things?

---

From: Anthony DeRobertis <[email-masked]>
Date: Mon, 10 May 2004 16:03:24 -0400

---

From: Mark Smith <[email-masked]>
Date: Tue, 11 May 2004 13:08:02 +0930

On Tue, 11 May 2004 03:48:57 +0900
Masataka Ohta <[email-masked]> wrote:

> >>>do an PATH MTU discovery, and send the MTU sized packets
> >with>>DF (don't frag).
> >>

Ok, if you think I'm wrong, what is it that is preventing PMTUD
working, as per the RFC method of operation, in this discussion ?

> 
> > RFC1192 (http://www.rfc-editor.org/rfc/rfc1191.txt) is the
> > spec for PMTUD. 
> 
> Read the RFC.

> 
> It says "To detect increases in a path's PMTU, a host
> periodically increases its assumed PMTU".

And how does the host know that it has increased the PMTU too far
? 

I'm really interested in some references to documentation or
information that has helped you form your opinion. I'm keen to
find out if my understanding of PMTUD purpose and operation is
incorrect.

Here is a summary of the references I've cited, including an
additonal one, for further information :

(a) The RFC of course. This is the reference for PMTUD operation.

(b) Radia Perlman's book, "Interconnections", 2nd Edition. Pg
185, section 8.7. There is also some discussion of fragmentation
- related to PMTUD - on page 233, section 10.4.7

and an additional one

(c) W. Richard Stevens' book, "TCP/IP Illustrated, Volume 1".
Page 340, Section 24.2

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Tue, 11 May 2004 13:08:02 +0930

and an additional one

Regards,
Mark.

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 11 May 2004 13:44:16 +0900

Mark Smith;

> I'm keen to

Read the RFC or my quotation of it.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 11 May 2004 13:44:16 +0900

Mark Smith;

						Masataka Ohta

---

From: Mark Smith <[email-masked]>
Date: Tue, 11 May 2004 14:17:17 +0930

On Tue, 11 May 2004 13:44:16 +0900
Masataka Ohta <[email-masked]> wrote:

> Mark Smith;
> 
> > I'm keen to
> > find out if my understanding of PMTUD purpose and operation
> > is incorrect.
> 

Ok, well, I haven't got far into it, and it seems to correspond
to what I've understood :

"2. Protocol overview

   In this memo, we describe a technique for using the Don't
Fragment   (DF) bit in the IP header to dynamically discover the
PMTU of a path.   The basic idea is that a source host initially
assumes that the PMTU   of a path is the (known) MTU of its first
hop, and sends all   datagrams on that path with the DF bit set. 
If any of the datagrams   are too large to be forwarded without
fragmentation by some router   along the path, that router will
discard them and return ICMP   Destination Unreachable messages
with a code meaning "fragmentation   needed and DF set" [7]. 
Upon receipt of such a message (henceforth   called a "Datagram
Too Big" message), the source host reduces its   assumed PMTU for
the path."

I'll continue reading, although I'm happy enough that my original
understanding was correct.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Tue, 11 May 2004 14:17:17 +0930

"2. Protocol overview

Regards,
Mark.

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 11 May 2004 14:38:26 +0900

Mark Smith;

> understanding was correct.

Let's agree that you are as correct as PMTUD.

If you have further comments, do so offline.

					Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 11 May 2004 14:38:26 +0900

Mark Smith;

					Masataka Ohta

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 11 May 2004 09:57:00 +0200

On 11-mei-04, at 6:47, Mark Smith wrote:

> The basic idea is that a source host initially
                ^^^^^
And this is where all the problems start. This flies directly in the 
face of the the robustness principle. If the host would just set the DF 
bit in one in 1000, one in 100 or one in 10 packets, we wouldn't be in 
this mess.

Note that the RFC doesn't say the DF bit must be set on ALL packets. 
But then, it also doesn't say this shouldn't be done either.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 11 May 2004 09:57:00 +0200

^^^^^