[unisog] Practical, Legitimate IP Fragmentation?

John Kristoff jtk at depaul.edu
Wed Mar 12 23:46:02 GMT 2003

On Wed, 12 Mar 2003 18:00:21 -0500 (EST)
Clarke Morledge <chmorl at wm.edu> wrote:

> That's why I am asking about the pragmatism of fragmentation.  As you

I think its a good question to ask and this is probably a very useful
discussion to be having.  However, I don't believe its a matter of being
pragmatic or not.  For better or worse, it really shouldn't be something
(blocking fragments) one should consider doing unless you see something
like a IETF BCP that states otherwise.

> have noted, there is no question that the RFCs do require support for
> fragmentation.  But if every TCP/IP stack supported RFC 1191 Path MTU
> discovery, then we would not really have this problem with fragments.

I'm not so sure.  See the following:


> So I could rephrase the question:  In a university campus environment,
> are we still really running applications over TCP/IP stacks that are
> not but probably should be supporting Path MTU discovery?

A completely different question if you ask me.  :-)  That might be a
good question to start with if eliminating fragmentation is your goal. 
Note, IPv6 requires that fragmentation be done on the end hosts and not
by IPv6 routers.

> On a local campus LAN, I can see the benefits of large frame sizes
> (jumbo Ethernet comes to mind for us). But I guess I am not really
> convinced as to the benefit of having large frame sizes on
> applications that traverse the Internet.  If the frame size is greater

There are a number of peole who see a lot of value in jumbos over a
internetwork.  There has been some discussion on this topic in other
places and we should probably take it off-list or someone else if you
want to discuss jumbos and Path MTU generally.  I will point you to a
very good presentation Joe St. Sauver recently gave at a Joint Techs
workshop last month showing how hard it is to actually use jumbos on an
internetwork today:


> For example, I don't know about every router vendor, but I continually
> run into problems with IP fragments getting dropped by Cisco router
> ACLs that filter at the TCP/UDP port level (Cisco IOS does not bother
> to check if a packet is an IP fragment before applying a port-level
> ACL).  That could translate into a performance hit.  Just another
> thing to think about!

Sounds more like a integrity hit (bug?) and a completely different, but
equally serious problem.  I'd love to hear more about that if you have
details, perhaps shoot me something offline if you're willing to share.

> It might be more complex than that when it comes to fragments.  What
> about IDS evasion techniques that take advantage of fragment
> overlapping? Granted, I have not seen any successful IDS evasion
> strategies in the wild, but that might change.

You're right.  This is one of many reasons why fragments are annoying
and suboptimal.  I would encourage a project to learn about fragments by
monitoring.  I think that would be extremely useful work.  Then we could
perhaps build better systems (IDSs, hosts, routers, applications and so
on) to address and respond to malicious fragments.

> From the Cisco PIX documentation on the "sysopt security fragguard"
> command:
> And from the Cisco PIX documentation of the "fragment" command:

Interesting, thanks.

> Gee, if I can find a router/firewall vendor that could block fragments
> on a per host basis, then that would be helpful!  I could then at
> least try it.

Many host based firewalls will do this for you.


More information about the unisog mailing list