Date: Tue, 29 Jul 2008 14:52:43 +0300 From: Giorgos Keramidas <keramida@ceid.upatras.gr> To: "Ronald F. Guilmette" <rfg@tristatelogic.com> Cc: freebsd-questions@freebsd.org Subject: Re: Two minor IPFW-related questions Message-ID: <87d4kwzz3o.fsf@kobe.laptop> In-Reply-To: <84492.1217303289@tristatelogic.com> (Ronald F. Guilmette's message of "Mon, 28 Jul 2008 20:48:09 -0700") References: <84492.1217303289@tristatelogic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 28 Jul 2008 20:48:09 -0700, "Ronald F. Guilmette" <rfg@tristatelogic.com> wrote: >On Mon, 28 Jul 2008 18:15:32 -0700, "Ronald F. Guilmette" <rfg@tristatelogic.com> wrote: >> deny any to any in frag >> >> Is that actually a Good Thing To Do? Are there really no legitimate >> packate fragments out there on the Internet? > > First, on one particular machine of mine, I'm seeing a fair number... > many dozens or so per hour... of /var/log/security logfile entries for > ipfw-rejected packet fragments. This is on a machine that has a very > busy name server. [...] The majority of the rejected "frag" packets > are UDP packets, and I've just now determined that many/most/all of > those are coming from actual name servers elsewhere. It's fairly non-trivial to make TCP fragments (TCP tries its best to avoid fragmentation and it splits traffic to 'segments' using its own logic, not how many bytes the user application wrote). So it's "normal" to see mostly UDP fragments. > In short, I do believe that these packet fragments are mostly (or > entirely) perfectly legitimate packet fragments... probably partial > answers to DNS queries that the nameserver on this machine sent out. DNS will fallback to TCP when UDP fails (i.e. when an answer datagram is too large for UDP to deliver). So I might consider dropping them anyway. > So now, given that I understand (or believe I do, anyway) everything > that you, Giorgos, said about the possibility of a DoS attack based on > packet fragmentation, and given that I _do not_ believe that anybody > has it in mind to do a DoS against me at the present time (either > using packet fragements or any other sort of DoS technique) is it > really wise for me to be dropping all of these DNS response packet > fragments? Wouldn't I be better off letting them in? It depends on why/when the fragmentation occured. If a name server is sitting behind a link with a small MTU or a link with a bit of data loss, losing one fragment means that *all* fragments must be transmitted again. In those cases relying on the capability of DNS to fallback on TCP may be a slightly better choice. > I'm most particularly concerned about the possibility that... because > I have ipfw dropping all fragments... I may be completely losing some > DNS responses that I actually do want No that's fine. You may get a delayed response, when DNS decides to switch to TCP, or a timeout if the whole "try UDP, fail, try TCP, fail" dance takes too long. But in that case plain UDP would have failed anyway, so you are just given an extra chance with TCP queries. > OK, one last question. I've just read the helpful little brief tutorial > about path MTU discovery... which Google helped me to find: > > http://www.netheaven.com/pmtu.html > > This is kinda sorta enlightening about why most of the fragments that > my ipfw is currently rejecting are either at offset 1472 or at offset > 1480... but not quite. What's the significance of these specific > offset numbers (1472 and 1480)? Is there some particular kind of > hardware or well-known- phenomenon (like the one described in the > document above) that commonly produces fragments with those specific > offsets, i.e. 1472 and 1480? The two "standard" Ethernet encapsulation formats ("IEEE 802.2/802.3" vs. "RFC 894") specify how data is laid out in an Ethernet 'frame'. The encapsulated data areas in the two frame formats can hold: IEEE 802.2/802.3 38-1492 bytes of data RFC 894 46-1500 bytes of data The numbers you are seeing are 20 bytes less than the maximum, because they account for the minimum IP header of 20 bytes. With a minimal IP header of 20 bytes, without any IP options, the two Ethernet frame formats can hold 1472 and 1480 bytes of IP-encapsulated data. That's the "magic" reason for the fragment sizes you see. In reality the full-path MTU may be even smaller for a variety of reasons, but that's another thing :)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?87d4kwzz3o.fsf>