[unisog] Practical, Legitimate IP Fragmentation?
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
> 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"
> And from the Cisco PIX documentation of the "fragment" command:
> 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