In message <E1DkuEo-0006sh-00@smeg.dsg.stanford.edu>, Jonathan Stone writes:
>
>In message <20050621180211.GA360@panix.com>,Ed Ravin writes:
>
>>One of my customers with NetBSD 2.0 was recently hit with an interesting
>>DoS attack. [...]
>
>
>>I looked over netinet/ip_icmp.c, and though I don't grok the code fully,
>>I have a few suggestions that should be able to blunt this attack:
>>
>>1) ignore the ICMP unreachable "need to fragment" message if the "MTU size
>>wanted" in the message is equal to or larger than the current MTU size for
>>this connection.  This will limit the attacker to sending "only" 1431
>>messages before reaching the minimum MTU, 68.  Not enough to stop the
>>attack, but at least it blunts it.
>
>A nice reponse. But what's the impact on PMTU discovery, specifically
>in the case that path-PMTU increases?  Isn't the required PMTU-probe
>behaviour in that case exactly the scenario (remote peer sends "DF"
>segment with a lenght larger than the current mtu) which you propse to ignore?
>
>Or maybe not, I haven't read that RFC in some time....
>

No, you never get such messages from remote routers; they have no idea 
what size you could have sent, so they can't tell you to send something 
larger.  You're supposed to try larger MTUs after some interval.  
See Sections 6.3 and 7.1 of RFC 1191.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb