Date: Fri, 14 Jun 2002 13:17:24 -0500 (CDT) From: Mike Silbersack <silby@silby.com> To: Jonathan Lemon <jlemon@flugsvamp.com> Cc: net@freebsd.org Subject: Re: Broken PMTUD in FreeBSD? Message-ID: <20020614130811.E3117-100000@patrocles.silby.com> In-Reply-To: <200206141740.g5EHe8533727@prism.flugsvamp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 14 Jun 2002, Jonathan Lemon wrote: > Actually, this is not a bug, except possibly for the TOS bits. I just > reread RFC 1191, and there isn't anything in there that requires DF to > always be set on a TCP connection. In fact, RFC 1191 states: > > Or, the host may elect to end the discovery process > by ceasing to set the DF bit in the datagram headers; it may do so, > for example, because it is willing to have datagrams fragmented in > some circumstances. Normally, the host continues to set DF in all > datagrams, so that if the route changes and the new PMTU is lower, it > will be discovered. It doesn't seem to exclude the practice either. > Also, since the syncache does not have any provision to create a > smaller packet, setting the DF bit will result in a denial of service > if for some reason, the SYN,ACK packet actually triggers the PMTU > discovery. So there's two choices: > 1) set IP_DF and deny service if we trigger PMTU (and violate RFC 1191), > 2) omit IP_DF and let the router fragment things if needed. > > The section of the commit relating to PMTU discovery should be backed out. > > Finally, as far as 'fingerprinting' goes, we're not the only *BSD doing this. > -- > Jonathan I'm not sure it's a real denial of service; anyone who was behind a router that bounced all packets with the DF bits set would have a system that would be virtually useless. I can't see anyone making such a modification just for the purpose of a DoS; it would be easier to just synflood. In cases where DF packets were being bounced for whatever reason, the syn cache should recover in exactly the same method as normal packets from tcp_output would. Whether or not the recovery method works or not is unknown to me; however, I don't see why starting the discovery with the syn-ack packet (as would have been done before the syn cache) would make the situation any worse. One reason I somewhat like the DF bit present relates to the the ip_id field. I noticed that linux has moved to setting 0 in the ip_id field for all packets with DF set. This sounds like a good way to go for me, as it's a lot cheaper than some randomization scheme. However, if we don't set DF on syn-ack packets but do on others, we'd be basically making a public counter of how many connections / second the server is trying to accept. Mike "Silby" Silbersack 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?20020614130811.E3117-100000>