Date: Fri, 14 Jun 2002 16:26:12 -0400 From: Barney Wolff <barney@tp.databus.com> To: Mike Silbersack <silby@silby.com> Cc: Jonathan Lemon <jlemon@flugsvamp.com>, net@FreeBSD.ORG Subject: Re: Broken PMTUD in FreeBSD? Message-ID: <20020614162612.A1139@tp.databus.com> In-Reply-To: <20020614143731.K3117-100000@patrocles.silby.com>; from silby@silby.com on Fri, Jun 14, 2002 at 02:41:08PM -0500 References: <20020614141750.E37376@prism.flugsvamp.com> <20020614143731.K3117-100000@patrocles.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
There may be an issue with T/TCP, but otherwise I see no reason to set DF on syn-ack, even when PMTUD is on. There is simply no point to avoiding fragmentation of a single packet per connection, and it's highly unlikely anyway in today's Internet. The current behavior is perfectly acceptable to any reasonable person. On Fri, Jun 14, 2002 at 02:41:08PM -0500, Mike Silbersack wrote: > > On Fri, 14 Jun 2002, Jonathan Lemon wrote: > > > It is a DoS. Suppose that for some reason, we send out a SYN,ACK of > > 80 octets, which hits a router with the minimum MTU of 68 octets. > > Unlikely, yes, but still legal. If IP_DF is set, the packet gets dropped, > > and a ICMP PMTU response is sent back, but the syncache will still resend > > the 80 octet datagram. If IP_DF is clear, the datagram will get through. > > In theory, I guess that could happen. Give me a few days to examine the > PMTU code to see if there's an easy way to handle that case. If the DF > bit is removed on the resend, would that be acceptable? > > /me has this bad feeling that he just roped himself into auditing the PTMU > code. > > Mike "Silby" Silbersack > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- Barney Wolff I never met a computer I didn't like. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020614162612.A1139>