North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Filtering ICMP (Was Re: SMURF amplifier block list)

  • From: Marc Slemko
  • Date: Mon Apr 20 16:34:58 1998

On Mon, 20 Apr 1998, Mark Whitis wrote:

> On Sun, 19 Apr 1998 [email protected] wrote:
> > You could always "deny icmp any aaa.bbb.ccc.ddd www.ccc.nnn.mmm log" on
> 
> Using "deny icmp" as anything other than an extremely temporary measure
> while you (or your customers) are actively under DoS attack and focused
> only on the affected hosts/nets (the systems under attack and/or the smurf
> amplifiers if it is a smurf attack) is downright irresponsible.  Even
> then, it will cause problems but they may be less than those caused by the
> DoS attack.  Most ICMP traffic is necessary to the correct operation of
> the net.
> 
> Filtering ICMP not only breaks ping, it breaks path mtu discovery which
> can cause much grief which is hard for the people affected to diagnose.

Agreed.  It is amazing how clueless so many people are about this problem,
even major backbone providers that just don't seem to be able to
understand it.  http://www.worldgate.com/~marcs/mtu/ for newbie-level
details on PMTU-D and why it needs functioning ICMP. 

[...]

> This is made much worse by filtering software which does not allow
> you to filter specific ICMP types and (unfragmented) packet sizes.
> A much better way to handle most of the DoS attacks (except smurf)
> is to force fragment reassasembly on a router which is not sucseptible
> before forwarding the packets; this puts a significant load on the
> router so it is best done on a router/firewall close to the
> systems being protected (which is also desireable because it
> gives more protection).

If it reassembles fragments then it isn't a router.