Re: MTU path discovery and IPSec

[David Sinn <dsinn () dsinn com>]

Do not just blame random company's firewall's for dumping ICMP.  There are
some very well known hosting groups that filter ICMP on edge of their
network's in their routers.

It gets even worse when their server admin's decide to leave PMTU discovery
on.  Sort of defeats the purpose...

Given the nastiness of ICMP DDoS attacks of late, it might be better to hit
the server and client admin's with the clue bat about not using PMTU
discovery (which also extends to the writers of the App's and OS's).  Frag.
is in the fast path of just about every current version of brand C code, so
giving the tunneling folks the OK to frag the packet might be preferred to
forcing them to mess about with alternate options.

David

On 12/3/03 8:59 AM, "cproctor () epik net" <cproctor () epik net> wrote:

> The problem is described pretty clearly at
> http://www.cisco.com/warp/public/105/56.html.    The issue I have
> experienced is that fragmentation can lead to performance impacts that are
> unacceptable.  
>
> I wish we could start a clue campaign informing people why ICMP should not
> be summarily dumped at the firewall.
>
> Chris Proctor
> EPIK Communications
>
> > -----Original Message-----
> > From: Valdis.Kletnieks () vt edu [mailto:Valdis.Kletnieks () vt edu]
> > Sent: Wednesday, December 03, 2003 11:39 AM
> > To: jgraun () comcast net
> > Cc: nanog () merit edu
> > Subject: Re: MTU path discovery and IPSec
> >
> > On Wed, 03 Dec 2003 16:05:39 GMT, jgraun () comcast net  said:
> >
> > > 1) I assume MTU path discovery has to been in enabled on
> > each router in the path in order for it work correctly?!
> >
> > Actually, no.  All that's required is that:
> >
> > a) The router handle the case of a too-large packet with the
> > DF bit set by
> > sending back an ICMP 'Dest Unreachable - Frag Needed' packet.
> >  I've never
> > actually encountered a router that didn't get this part
> > right. (Has anybody ever
> > seen a router botch this, *other* than a config error covered
> > in (b) below?)
> >
> > b) said ICMP makes it back to the originating machine.  This
> > is where all the
> > operational breakage I've ever seen on PMTU Discovery comes
> > from. And in almost
> > all cases, one of two things is at fault.  Either some
> > bonehead firewall admin
> > is "blocking all ICMP for security" (fixable by reconfiguring
> > the firewall to
> > let ICMP Frag Needed error messages through), or some
> > bonehead network provider
> > numbered their point-to-points from 1918 space and the ICMP
> > gets ingress/egress
> > filtered (this one is usually not fixable except with a baseball bat).