> > [Stefan Hulbrock]
> [Darren Reed]

> > In my opinion "good ICMPs" (tm ;-) that should be allowed if a
> TCP conn is
> > established are
> > the dst-unreachable's, source-quench and ttl-exceeded (hope I forgot
> > none...)
> > I can think of no reason where a conn is established to a server and it
> > sends a redirect to the source (this should normally only
> happen in a local
> > LAN), or any other ICMP.
> >
> > This behaviour could be hard coded.
>
> It is already:
>
>         /*
>          * If it's not an error type, then return
>          */
>         if ((type != ICMP_UNREACH) && (type != ICMP_SOURCEQUENCH) &&
>             (type != ICMP_REDIRECT) && (type != ICMP_TIMXCEED) &&
>             (type != ICMP_PARAMPROB))
>                 return NULL;
Ok... sorry for writing without looking into the source ("look into the
source, luke" (Obi Wan)) ;-)
I see that I forgot paramprob.... was writing out of memory.

But why accepting redirect? Can't think of a scenario where this is useful.
Could you explain? Only thing I could think of is that the redirect is from
the filtering machine itself. (and if this is possible, it could be allowed
explicitly as a normal (stateless) filter.
In my view people are often very paranoid if it comes to REDIRECT, even if
there might be no danger.

You're right that there are other means to  do a DOS (for example Microsoft
(sorry for this flat joke)). TCP and IP aren't the most secure protocols and
there are some things one can't help about with a firewall (like one sending
an RST with a spoofed source address). But why don't help in the things that
are possible?

Just my 2 pence
Stefan