Date: Fri, 14 Jun 2002 14:17:50 -0500 From: Jonathan Lemon <jlemon@flugsvamp.com> To: Mike Silbersack <silby@silby.com> Cc: Jonathan Lemon <jlemon@flugsvamp.com>, net@freebsd.org Subject: Re: Broken PMTUD in FreeBSD? Message-ID: <20020614141750.E37376@prism.flugsvamp.com> In-Reply-To: <20020614130811.E3117-100000@patrocles.silby.com> References: <200206141740.g5EHe8533727@prism.flugsvamp.com> <20020614130811.E3117-100000@patrocles.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jun 14, 2002 at 01:17:24PM -0500, Mike Silbersack wrote: > > 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. Correct. Either approach is acceptable from the RFC standpoint. However, if you set IP_DF, you /MUST/ be able to handle a PMTU response, which is not true of the current code. > > 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. 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 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. Because the syncache does not go through tcp_output, so the normal TCP packet sizing mechanism does not apply here. > 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. If we do that, the determination of whether IP_DF should be set or not would depend on the total packet size, so we'd have to calculate the ipoptlen in a similar way that tcp_output does now, which does seem decidedly overkill. -- Jonathan 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?20020614141750.E37376>