Minimum Internet MTU
Greetings all, I'm working with a few folks on firewall and IDS rules that will flag suspicious fragmented traffic. I know the legal minimum of a non-terminal fragment is 28 bytes, but given non-terminals should reflect the MTU of the topologies along the link, this number is far lower than what I expect you should see for legitimate fragmentation in the wild. 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? 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? Any and all feedback would be greatly appreciated, C
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?
Any and all feedback would be greatly appreciated, C
On Mon, 2003-12-22 at 08:27, bill wrote:
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 On 22 Dec 2003, Robert E. Seastrom wrote:
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
On Mon, 2003-12-22 at 09:36, Robert E. Seastrom wrote:
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
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)?
No. Check previous thread about IPSec and MTU. Some IPSec implementations split the greater-than-mtu sized packet in half in order to avoid the possibility of further fragmentation down the road, thus better performance. ~Hani Mustafa
I'm working with a few folks on firewall and IDS rules that will flag suspicious fragmented traffic. I know the legal minimum of a non-terminal fragment is 28 bytes, but given non-terminals should reflect the MTU of the topologies along the link, this number is far lower than what I expect you should see for legitimate fragmentation in the wild.
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?
there are many deployment of DSL-based layer 2 providers, which use L2TP (or whatever) tunnelling as well as PPPoE to associate end clients to layer 3 ISPs. they enforce MTU like 1450 or lower. in Japan, NTT east/west (NTT is a previously-government-owned telco) provide such service and enforce MTU of 1454. itojun
participants (8)
-
bill -
Chris Brenton -
Hani Mustafa -
itojun＠itojun.org -
neil＠DOMINO.ORG -
Robert E. Seastrom -
Scott McGrath -
Stephen J. Wilcox