28.3. Fragmentation Settings

IP is able to transport up to 65,536 bytes of data. However, most media, such as Ethernet, cannot carry such huge packets. To compensate, the IP stack fragments the data to be sent into separate packets, each one given their own IP header and information that will help the recipient reassemble the original packet correctly.

Many IP stacks, however, are unable to handle incorrectly fragmented packets, a fact that can be exploited by intruders to crash such systems. Protection against fragmentation attacks is provided in a number of ways.

Pseudo Reass Max Concurrent

Maximum number of concurrent fragment reassemblies. To drop all fragmented packets, set PseudoReass_MaxConcurrent to 0.
System:/> set Settings FragSettings PseudoReass_MaxConcurrent=1024

Default: 1024

Illegal Fragments

Determines how cOS Stream will handle incorrectly constructed fragments. The term "incorrectly constructed" refers to overlapping fragments, duplicate fragments with different data, incorrect fragment sizes, etc. Possible settings include:
The choice of whether to discard individual fragments or disallow the entire packet is governed by two factors:
System:/> set Settings FragSettings IllegalFrags=Drop

Default: DropLog – discards individual fragments and remembers that the reassembly attempt is "suspect".

Duplicated Fragment Data

If the same fragment arrives more than once, this can mean either that it has been duplicated at some point on its journey to the recipient or that an attacker is trying to disrupt the reassembly of the packet. In order to determine which is more likely, cOS Stream compares the data components of the fragment.

The comparison can be made in 2 to 512 random locations in the fragment, four bytes of each location being sampled. If the comparison is made in a larger number of samples, it is more likely to find mismatching duplicates. However, more comparisons result in higher CPU load.

System:/> set Settings FragSettings DuplicateFragData=Check8

Default: Check8 – compare 8 random locations, a total of 32 bytes

Failed Fragment Reassembly

Reassemblies may fail due to one of the following causes:
Under normal circumstances, you would not want to log failures as they occur frequently. However, it may be useful to log failures involving "suspect" fragments. Such failures may arise if, for example, the IllegalFrags setting has been set to Drop rather than DropPacket.

The following settings are available for FragReassemblyFail:

System:/> set Settings FragSettings FragReassemblyFail=LogSuspectSubseq

Default: LogSuspectSubseq

Dropped Fragments

If a packet is denied entry to the system as the result of the settings in the Rules section, it may also be worth logging individual fragments of that packet. The DroppedFrags setting specifies how cOS Stream will behave. Possible settings for this rule are as follows:
System:/> set Settings FragSettings DroppedFrags=LogSuspect

Default: LogSuspect

Duplicate Fragments

If the same fragment arrives more than once, this can mean either that it has been duplicated at some point on its journey to the recipient or that an attacker is trying to disrupt the reassembly of the packet. DuplicateFrags determines whether such a fragment should be logged. Note that DuplicateFragData can also cause such fragments to be logged if the data contained in them does not match up. Possible settings are as follows:
System:/> set Settings FragSettings DuplicateFrags=LogSuspect

Default: LogSuspect

Fragmented ICMP

Other than ICMP ECHO (Ping), ICMP messages should not normally be fragmented as they contain so little data that fragmentation should never be necessary. FragmentedICMP determines the action taken when cOS Stream receives fragmented ICMP messages that are not either ICMP ECHO or ECHOREPLY.
System:/> set Settings FragSettings FragmentedICMP=DropLog

Default: DropLog

Minimum Fragment Length

Minimum Fragment Length determines how small all fragments (with the exception of the final fragment) of a packet can be expressed in bytes.

Although the arrival of too many fragments that are too small may cause problems for IP stacks, it is usually not possible to set this limit too high. It is rarely the case that senders create very small fragments. However, a sender may send 1480 byte fragments and a router or VPN tunnel on the route to the recipient subsequently reduce the effective MTU to 1440 bytes. This would result in the creation of a number of 1440 byte fragments and an equal number of 40 byte fragments.

Because of the potential problems this can cause, the default settings are designed to allow the smallest possible fragments, 8 bytes, to pass. For internal use, where all media sizes are known, this value can be raised to 200 bytes or more.

System:/> set Settings FragSettings MinimumFragLength=8

Default: 8

Reassembly Timeout

A reassembly attempt will be interrupted if no further fragments arrive within Reassembly Timeout seconds of receipt of the previous fragment.
System:/> set Settings FragSettings ReassTimeout=65

Default: 65

Max Reassembly Time Limit

A reassembly attempt will always be interrupted Reassembly Time Limit seconds after the first received fragment arrived.
System:/> set Settings FragSettings ReassTimeLimit=90

Default: 90

Reassembly Done Linger Limit

Once a packet has been reassembled, cOS Stream is able to remember reassembly for this number of seconds in order to prevent further fragments, for example old duplicate fragments, of that packet from arriving.
System:/> set Settings FragSettings ReassDoneLinger=20

Default: 20

Reassembly Illegal Linger Limit

Once a whole packet has been marked as illegal, cOS Stream is able to retain this in memory for this number of seconds in order to prevent further fragments of that packet from arriving.
System:/> set Settings FragSettings ReassIllegalLinger=60

Default: 60

Reject Minimal Fragment

Send an ICMP parameter problem message when the non-last fragment is smaller than the minimum allowed length which is specified by IPv6MinNonFinalFragment.
System:/> set Settings FragSettings RejectMinimalFrag=No

Default: No

IPv6 Minimum Non-final Fragment

This is the minimum allowed length of non-last IPv6 fragments.
System:/> set Settings FragSettings IPv6MinNonFinalFragment=640

Default: 640

IPv6 Nop Fragments

The packet is the first and last fragment at the same time (and by definition not a fragment, though it has got a fragment header). Note that these packets are legal, and serves a purpose as an non-IPv6 to IPv6 connection mechanism (see RFC2460 for more details).
System:/> set Settings FragSettings IPv6NopFrags=Ignore

Default: Ignore