[unisog] Practical, Legitimate IP Fragmentation?
jtk at depaul.edu
Wed Mar 12 18:53:15 GMT 2003
On Wed, 12 Mar 2003 11:58:11 -0500 (EST)
Clarke Morledge <chmorl at wm.edu> wrote:
> network? In view of the security risks associated with fragmentation,
> is this a good idea?
> Theoretically, you should always pass IP fragments due to variances in
Its not just theory, its interoperable behavior. From RFC 1812 -
Requirements for IP Version 4 Routers section 220.127.116.11:
"Fragmentation, as described in [INTERNET:1], MUST be supported
by a router.
The host requirements RFC has something similar.
...and I don't think putting something in front of the router and
calling it a firewall makes blocking fragments OK. :-)
> Maximum Transfer Units (MTU) along a traffic path. 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.
> 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
> fragments at the UDP/TCP port level, and damaging payloads can be
> hidden in fragments with some relative ease.
Damaging payloads can be contained in SMTP too, but I'm guessing you
don't block SMTP entirely at the border. How you deal with damaging
payloads in fragments should probably be consistent with how you deal
with damaging payloads generally.
> 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?
> I am having a difficulty in seeing how this practice by RTP
> applications is really necessary. It seems horribly inefficient to
> fragment this type of traffic, particularly in a "real time"
> application. You drop one packet, you lose the whole UDP data chunk
> spread across multiple IP fragments. Can anyone tell me why some of
> these RTP applications work this way?
Someone more knowledgable than I about video encoding into IP can
hopefully answer that one. My guess is that a video frame (PDU) just
gets sent as is without fragmentation occuring at the application layer,
because it is easier for it to do that.
> I am very tempted to just go ahead and block fragments and wait until
> someone screams, but I was wondering if anyone else has had any
> experience in this area.
I'm very tempted to encourage you to do so and see what happens. :-)
I don't know your environment so perhaps it might not be a big deal
today, but I certainly wouldn't recommend that as standard practice. It
might be better to just monitor fragments. If you see something strange
you can reactively address a potential problem. It might be acceptable
to block fragments on a specific host in special circumstances, but even
then its probably not generally a good idea.
More information about the unisog