Subject: Re: DoS using crafted ICMP "frag needed" packets
To: Ed Ravin <eravin@panix.com>
From: Fernando Gont <fernando@gont.com.ar>
List: tech-net
Date: 06/23/2005 16:22:29
At 04:40 p.m. 22/06/2005, Ed Ravin wrote:
> > I'm not sure I understood your explanation. But if I did, that
> behaviour is
> > really weird.
> > If you receive an ICMP "fragmentation neded and DF bit" that would make
> you
> > *reduce* the assumed Path-MTU, you should honor it, and retransmit the
> > corresponding data.
>
>The NetBSD code assumes that the remote client has specified a valid MTU
>in the "MTU wanted field" of the ICMP message. Since the malicious
>client put a 1500 there, NetBSD uses that field.
If it's the client that is sending this packets, then the server could
track the client by its IP address.
> Note: One MUST not retransmit in response to every Datagram
> Too Big message, since a burst of several oversized segments
> will give rise to several such messages and hence several
> retransmissions of the same data. If the new estimated PMTU
> is still wrong, the process repeats, and there is an
> exponential growth in the number of superfluous segments sent!
>
>I think this is where the NetBSD code is failing - it is probably
>responding to every "Too Big" message. The "burst" they refer to
>is exactly what my NetBSD 2.0 host was doing.
Yes, I have seen this in other implementations.
Basically, you should only honor the IMCP message if the advertised
NeXT-Hop MTU is *less* than the current value used for the PMTU.
This way you'd avoid those retransmissions.
--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org