Two minor IPFW-related questions

[Giorgos Keramidas]

On Mon, 28 Jul 2008 20:48:09 -0700, "Ronald F. Guilmette" <rfg at tristatelogic.com> wrote:
>On Mon, 28 Jul 2008 18:15:32 -0700, "Ronald F. Guilmette" <rfg at 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 :)