ietf
[Top] [All Lists]

Re: Problem of blocking ICMP packets

2004-05-10 11:08:56
On Mon, 10 May 2004, Masataka Ohta wrote:

Dean Anderson;

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.

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.

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.

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.

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).

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

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.

This is the first I have heard that path mtu discovery software was
unreliable.

PMTUD software is unreliable!?

Then, it is anther reason to avoid it.

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

Err, _you_ said it:

On Sat, 8 May 2004, Masataka Ohta wrote:
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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf