On Wed, Jun 22, 2005 at 03:33:37PM +0300, Fernando Gont wrote:
> At 03:43 a.m. 22/06/2005, Steven M. Bellovin wrote:
> 
> [quoting the OP]
> 
> >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.  The attacker opened up an HTTP connection to the customer's
> >>NetBSD webserver, sent an HTTP GET, and then when the response came 
> >flowing
> >>down the pipe, sent an ICMP unreachable, "fragmentation needed" message,
> >>with the "MTU wanted" size set to 1500.  NetBSD would then start
> >>retransmitting the data in the TCP window, only to get another ICMP
> >>unreachable message with the "MTU wanted" set to 1500.
> 
> 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.

> But I'd appreciate if you could clarify the explanation a bit.


RFC 1191 says this:

   Alternatively, the retransmission could be done in immediate response
   to a notification that the Path MTU has changed, but only for the
   specific connection specified by the Datagram Too Big message.  The
   datagram size used in the retransmission should, of course, be no
   larger than the new PMTU.

          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.

> >>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 is aready stated in the Path-MTU specifications (for IPv4 & IPv6) 
> themselves.

I guess we ought to implement it, then :-)