Date: Fri, 14 Jun 2002 12:40:08 -0500 (CDT) From: Jonathan Lemon <jlemon@flugsvamp.com> To: silby@silby.com, net@freebsd.org Subject: Re: Broken PMTUD in FreeBSD? Message-ID: <200206141740.g5EHe8533727@prism.flugsvamp.com> In-Reply-To: <local.mail.freebsd-net/20020611112119.N23986-100000@patrocles.silby.com> References: <local.mail.freebsd-net/3D060A6C.5204B402@clavister.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <local.mail.freebsd-net/20020611112119.N23986-100000@patrocles.silby.com> you write:
>
>(I'm redirecting this back to freebsd-net, as it doesn't seem appropriate
>for bugtraq.)
>
>I did some quick investigation last night, and agree with Phil that this
>is a bug. When the syncache was implemented, only a subset of the normal
>tcp output code was copied over for the purpose of sending syn-acks. One
>part of the code that was not moved over was the part that determines when
>the DF and tos bits are set.
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.
Since the maximum size(*) of the SYN,ACK packet being sent out is:
sizeof(struct ip) + sizeof(struct tcphdr) + TCP_OPTIONS
20 20 4 + 4 + 12 + 8
== 68 octets
And since routers /MUST/ be able to forward this packet without
fragmentation, according to RFC 791 (minimum MTU), there isn't
any need to set the DF bit. In fact, if a router generates a
Datagram too Big message in response to this SYN,ACK then it is
in error.
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
(*) Yes, this ignores any possible IP options, but the only IP options that
might come into play here are source routing, which are fairly unlikely.
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?200206141740.g5EHe8533727>