From owner-freebsd-net Fri Jun 14 12:18:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (66-191-112-47.mad.wi.charter.com [66.191.112.47]) by hub.freebsd.org (Postfix) with ESMTP id 01BCF37B431 for ; Fri, 14 Jun 2002 12:18:15 -0700 (PDT) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.6/8.11.6) id g5EJHoF36825; Fri, 14 Jun 2002 14:17:50 -0500 (CDT) (envelope-from jlemon) Date: Fri, 14 Jun 2002 14:17:50 -0500 From: Jonathan Lemon To: Mike Silbersack Cc: Jonathan Lemon , net@freebsd.org Subject: Re: Broken PMTUD in FreeBSD? Message-ID: <20020614141750.E37376@prism.flugsvamp.com> References: <200206141740.g5EHe8533727@prism.flugsvamp.com> <20020614130811.E3117-100000@patrocles.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20020614130811.E3117-100000@patrocles.silby.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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