In message <NFBBJDHCNMOLGCHLENGOIEDKCAAA.s.huelbrock@biodata.de>, =?US-ASCII?Q?
Stefan_Hulbrock?= writes:
>> > [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.

The attacker can forge a REDIRECT claiming to be from the first-hop 
router.  The theoretical situation where that's useful is if you have 
two routers on your LAN with external connectivity, and the one you used
loses its link to the outside.  That router would learn that its 
neighbor has a better (i.e., working) link to the outside, so it would 
send you a REDIRECT.

But it doesn't matter -- someone who can eavesdrop on your traffic can 
do anything they want, without bothering with REDIRECT.  There are all 
sorts of session-hijacking tools out there; some rely on ARP, which is 
below the level of ipf.
>
>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?

If that's in your threat model, use end-to-end IPsec.

		--Steve Bellovin, http://www.research.att.com/~smb