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