[unisog] Practical, Legitimate IP Fragmentation?

Clarke Morledge chmorl at wm.edu
Wed Mar 12 23:00:21 GMT 2003


John, 

All good criticisms to make.  Please let me address some of your comments
in line...


On Wed, 12 Mar 2003, John Kristoff wrote:

> > But practically
> > speaking, in a world today where Ethernet is almost everywhere, the
> > chances of running into an MTU different from standard Ethernet is
> > relatively small.  Granted, there are exceptions, but a consistent MTU
> > intra-campus and across the Internet seems to hold.
> 
> Yes and no.  There is a tendency by various types of networks and
> services that force fragmentation (FDDI, IPSec, PPPoE and some streaming
> video services).  There is also a growing desire by many to have larger
> frame sizes supported on an end-to-end basis.  Blocking fragments now
> may hurt that progress in some circumstances.
> 
> While fragmentations are best avoided if at all possible in most cases,
> it is not best to simply drop them based on site policy.  As with many
> well intentioned filtering strategies may do, it would almost certainly
> cause some problems and most definitely limit applications, growth and
> flexibility in the future.

That's why I am asking about the pragmatism of fragmentation.  As you 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.

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?

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 than the Ethernet MTU, the
chance is extremely high that it is just going to get chopped up at some
point, and that seems inefficient to me when going over numerous hops
where packet loss is more likely. But that's probably another discussion
on another list :-)


> > However, the risk associated with allowing fragments to pass through a
> > campus edge seems high:  most router ACLs are unable to block IP
> 
> One must very carefully consider what you mean by risk.  Where is the
> risk?  Where is the best place to mitigate that risk?  What are the
> trade-offs?

Security is the main risk concern, but performance is a concern, too.  
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!


> How you deal with damaging payloads in fragments should probably be
> consistent with how you deal with damaging payloads generally.

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.
 

> > Considering the risks, can anyone tell me in terms of "real world"
> > experience why we should continue to pass fragments?  Cisco, our PIX
> > firewall vendor, recommends that IP fragments be dropped if at all
> > possible.  Do you agree?
> 
> Is that documented or is that what someone said?

>From the Cisco PIX documentation on the "sysopt security fragguard"
command:

"We recommend that packet fragmentation not be permitted on the network if
at all possible."

And from the Cisco PIX documentation of the "fragment" command:

"Based on your network security policy, you should consider configuring
the PIX Firewall to prevent fragmented packets from traversing the
firewall by entering the fragment chain 1 interface command on each
interface. Setting the limit to 1 means that all packets must be whole;
that is, unfragmented."


> It might be acceptable to block fragments on a specific host in
> special circumstances, but even then its probably not generally a good
> idea.

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.

Clarke Morledge
College of William and Mary
Information Technology - Network Engineering
Jones Hall (Room 18)
Williamsburg VA 23187
757-221-1536
chmorl at wm.edu



More information about the unisog mailing list