From owner-freebsd-hackers Fri Jan 4 15:35:49 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id A114C37B417 for ; Fri, 4 Jan 2002 15:35:46 -0800 (PST) Received: from pool0477.cvx22-bradley.dialup.earthlink.net ([209.179.199.222] helo=mindspring.com) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16Mds8-0003RU-00; Fri, 04 Jan 2002 15:35:36 -0800 Message-ID: <3C363C47.1AE94141@mindspring.com> Date: Fri, 04 Jan 2002 15:35:35 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Louis A. Mamakos" Cc: Guido van Rooij , William Carrel , freebsd-hackers@FreeBSD.ORG Subject: Re: path_mtu_discovery References: <26E71536-013D-11D6-8ED3-003065D5E9A4@infospace.com> <3C36149B.B9C02DCF@mindspring.com> <20020104223235.GA64301@gvr.gvr.org> <200201042302.g04N2A789953@whizzo.transsys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "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