A few years back I noted some 512-536 MTU links in ASIA. I've been doing
some testing and can't seem to find them anymore. Is is safe to assume
that 99.9% of the Internet is running on 1500 MTU or higher these days?
define safe.
I know some people artificially set their end point MTU a bit lower
(like 1400) to deal with things like having their traffic encapsulated
by GRE or IPSec. With this in mind, would we be safe to flag/drop/what
ever all fragments smaller than 1200 bytes that are not last fragments
(i.e., more fragments is still set)? Does anyone maintain, or is aware,
of links that would not meet this 1200 MTU?
now that you mention it... 
btw, what will your IDS/firewall do when presented w/ a 9k mtu?
> Is is safe to assume
> that 99.9% of the Internet is running on 1500 MTU or higher these days?
define safe.
<GRIN>
I agree, this is a bit of a loaded question. I guess by safe I mean "Is
anyone aware of a specific link or set of conditions that could cause
_legitimate_ non-last fragmented packets on the wire that have a size of
less than 1200 bytes". I agree there are bound to be inexperienced users
who have shot themselves in the foot and tweaked their personal system
lower than this threshold, thus my 99.9% requirement.
I had a couple of people e-mail me about Cisco's Pre-fragmentation
feature for IPSec. If I understand it correctly (someone please correct
me if I'm wrong), its the original datagrams that get fragmented. Thus
its the encapsulated payload that will have MF set, not the actual IPSec
packet seen on the wire. With this in mind, the exposed IP header would
just show it to be a small packet, not a small fragment. Am I off here?
now that you mention it...
btw, what will your IDS/firewall do when presented w/ a 9k mtu?
Depends on the setup. I've actually been running this as a set of IDS
rules for a few years and have detected a few 0-day events this way. I
have not hit any false positives that I'm aware of, but then again we're
only talking my small view of the Internet. Thus my question to the
group. If anyone is going to know the answer its this crew.
I'm looking to move the rules into the firewall/IPS realm, but want to
be sure before I do as now we are talking blocking the traffic rather
than just recording it. First implementation would be a set of iptables
rules, with pf shortly after. I have not seen any commercial firewalls
with this type of capability, but I have not had a chance to focus on
this aspect too deeply as of yet. Checkpoint has possibilities, but
implementation would probably be beyond the typical point and click
admin.
Thanks for all the great feedback!
C
Chris Brenton <cbrenton@chrisbrenton.org> writes:
I agree, this is a bit of a loaded question. I guess by safe I mean "Is
anyone aware of a specific link or set of conditions that could cause
_legitimate_ non-last fragmented packets on the wire that have a size of
less than 1200 bytes". I agree there are bound to be inexperienced users
who have shot themselves in the foot and tweaked their personal system
lower than this threshold, thus my 99.9% requirement.
You mean like everyone who's still running TCP/IP over AX.25 in the
ham radio community? They're generally technically adept and good at
complaining... I'm sure rbush would encourage his competitors to do this.
What are you trying to accomplish by killing off the fragments?
---Rob
Or the X.25/IP gateways beloved of Airlines who are also good at
complaining when traffic is dropped on the floor
Scott C. McGrath
You mean like everyone who's still running TCP/IP over AX.25 in the
ham radio community?
I actually thought of this, but only as an end-point which would not
generate fragmented packets. I didn't consider that people could be
using Linux or what ever to hide an Ethernet network behind the link,
which of course would fragment the stream.
Looks like I need to drop my threshold to < 500. This is exactly what I
needed, thanks!
What are you trying to accomplish by killing off the fragments?
My experience has been that attackers still like to use fragmentation as
a method of covering their tracks. No they do not do it all the time,
but I've noticed that a lot of the time when I've been able to catch
0-day stuff its fragmented in order to help stealth it.
So what I'm looking for is a definable limit to be able to say "a
non-last fragment below this size is very likely to be hostile and
should be handled accordingly". Running with less than 500 bytes is
still cool, as the stuff I've found is always less than 100 bytes. I'm
just looking to add as much "slop" as possible to catch what I have not
thought of without triggering false positives.
So unless someone knows of a case below 500 bytes, I think I'm all set.
Thanks for the great feedback.
C
You mean like everyone who's still running TCP/IP over AX.25 in the
ham radio community? They're generally technically adept and good at
complaining... I'm sure rbush would encourage his competitors to do this.
Whats IP over DNS, 512 bytes.. wouldnt want to kill my hotel access now huh?
Steve
LOL!
And least we forget RFC 1149. I think this limits carrier pigeon MTU to
256 milligrams. 
C