Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 04 Jan 2002 15:35:35 -0800
From:      Terry Lambert <tlambert2@mindspring.com>
To:        "Louis A. Mamakos" <louie@TransSys.COM>
Cc:        Guido van Rooij <guido@gvr.org>, William Carrel <william.carrel@infospace.com>, freebsd-hackers@FreeBSD.ORG
Subject:   Re: path_mtu_discovery
Message-ID:  <3C363C47.1AE94141@mindspring.com>
References:  <26E71536-013D-11D6-8ED3-003065D5E9A4@infospace.com> <3C36149B.B9C02DCF@mindspring.com> <20020104223235.GA64301@gvr.gvr.org> <200201042302.g04N2A789953@whizzo.transsys.com>

next in thread | previous in thread | raw e-mail | index | archive | help
"Louis A. Mamakos" wrote:
> One possibility is that the code in icmp_input() processing the
> PMTU discovery-induced ICMP message could verify that the returned
> header in fact is associated with a connection on the host and
> maybe even has sane sequence numbers (for TCP segments).  This would
> make it more difficult to just spray these packets at host and
> drop the MTU on routes.

Of course, now you've let the dirty little secret out of the
bag: the MTU is on the *route*, which means on the next hop,
so a spoof that got through would frag basically all traffic
out of the victim machine down to 296 bytes...

A client machine could do much worse, of course, fragging the
inverse traceroute until the fragging was successful, after
sending the SYN, in response to the server's "SYN-ACK"...

The obvious "fix" for that is to not let the MTU be dropped
if the last sent packet's size is smaller than the drop-to
(can't use a "max successful" because of multiple routes
and/or route assymetry).  This would prevent doing it on the
"SYN-ACK", or other small packet (maybe disallowing it
entirely, until the first data packet has been sent).  But
the obvious "fix" for the obvious "fix" is to establish a
connection, and then trigger the largest packet you can to
be sent from the server (e.g. request a big HTTP document,
which most initial pages in fact are).

It's always an arms race...

-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C363C47.1AE94141>