Blog

Introduction

More than ten years ago, Ptacek and Newsham published a seminal paper on network instrusion evasion, entitled “Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection“, in which they described how ambiguity in the “reassembly” function of protocols such as TCP and IP could be leveraged to evade Network Intrusion Detection Systems. Essentially, the attacker causes the security device to obtain a different data stream from that obtained by the victim system, such that he is able to conceal his attack traffic from the security device while still successfully performing the attack against the victim system.

Recently, we assessed the fragmentation and reassembly policies of some popular IPv6 implementations, such that we could evaluate the feasibility of IPv6-fragmentation-based insertion/evasion attacks with current IPv6 implementations (similar to those described by Ptacek and Newsham for IPv4). The aforementioned assessment was not “casual”, but was mostly motivated by recent improvements in the IPv6 fragmentation and reassembly implementations of a number of popular IPv6 stacks. The improvements mostly fall into these categories:

• Forbidding overlapping fragments (RFC 5722)
• Improving the handling of IPv6 atomic fragments (draft-ietf-6man-ipv6-atomic-fragments)
• Improving the Fragment Identification generation policy (draft-gont-6man-ipv6-predictable-id)

As one might expect, all of these aspects are intimately related, and interact with each other in most scenarios.

This article discusses the first two items: the basic fragment reassembly policy of some popular IPv6 implementations (item #1 above) and the processing of IPv6 atomic fragments (item #2 above) of such implementations.

The discussion of the fragment Identification generation is left for future posts.

Assessing the fragment identification policy of popular implementations

Based on previous experience with IPv4 fragmentation and reassembly, we selected a total of five tests to be performed with each of the target implementations, to infer their IPv6 fragment reassembly policy. Each test involves sending a fragmented ICMPv6 Echo Request message of which some fragments have total or partial overlap, and then analysing the corresponding “response”. The possible responses to the aforementioned probes are:

• An ICMPv6 Echo Reply message, from which the fragment reassembly policy can be inferred (i.e., which copy of the data was used for the reassembled packet),
• A time-out, implicitly signalling implementation of RFC 5722, or, 
• An ICMPv6 Time Exceeded error message, implicitly signalling implementation of RFC 5722.

The tests performed on each IPv6 implementation are as follows:

Test #1

Frag. #1:  AAAAAAAAAAA

Frag. #2:         BBBBBBBBBBB

Test #2

Frag. #1:  AAAAAAAAAA
Frag. #2:                    BBBBBBBBBBB
Frag. #3:         CCCCCCCCCCC

Test #3

Frag. #1:  AAAAAAAAAA
Frag. #2:                    BBBBBBBBBBB
Frag. #3:            CCCCCCCCCCC

Test #4

Frag. #1:  AAAAAAAAAA
Frag. #2:                    BBBBBBBBBBB
Frag. #3:            CCCCCCCCCCCCCCCCCCCCCCCCCC

Test #5

Frag. #1:  AAAAAAAAAA
Frag. #2:                    BBBBBBBBBBB
Frag. #3:                           CCCCCCCCCCC
Frag. #4:            DDDDDDDD

The results of the aforementioned test for different implementations are:

Clearly, all current implementations are converging towards the implementation of RFC 5722.

Processing of IPv6 atomic fragments

A special case of IPv6 fragments is that in which a fragment has a Fragment Offset of 0 (i.e., it is the first fragment), and at the same time has the “M” (More fragments) bit set to 0 (i.e., it is the last fragment). While these packets might seem non-sensical/non-legitimate, there are a number of scenarios, notably those in which IPv6/IPv4 translators are employed, in which these fragments may be legitimately generated.

Unfortunately, some implementations mistakenly consider atomic fragments as illegitimate, and silently drop them, causing an interoperability problem in scenarios in which nodes rely on atomic fragments.

What makes these fragments special is that, being both the first and the last fragment at the same time, they are “atomic” fragments — no other fragments are needed for the “fragment reassembly” to be performed.

Unfortunately, some implementations don’t take advantage of the “atomic” property of these fragments, and may “mix” atomic fragments with regular fragments (if such fragments are present in the fragment reassembly queue when the atomic fragment is received). That is, if one of such implementations receives an atomic fragment with the same set (IPv6 Source Address, IPv6 Destination Address, Fragment Identification) as that of a fragment already present in the reassembly queue, and e.g. both fragments overlap, the two fragments will be processed as regular overlapping fragments (e.g., “silently dropped” if the stack implements RFC 5722). This sub-optimal processing allows an attacker to launch any fragmentation-based attack against traffic flows employing atomic fragments, while the improved handling successfully mitigates such attacks, since the atomic fragments are essentially processed as non-fragmented traffic.

The following table contains a summary of the assessment of a number of popular IPv6 implementations with respect to the processing of IPv6 atomic fragments:

Ongoing work in the area of IPv6 fragmentation and reassembly

There is ongoing work at the IETF in the area of IPv6 fragmentation and reassembly. Part of that work is being carried out in the following documents:

• draft-ietf-6man-ipv6-atomic-fragments: Specification fo the improved processing of atomic fragments. Already adopted by the 6man wg as a working group item. 

• draft-gont-6man-ipv6-predictable-id: Security assessment of predictable fragment Identification values (individual submission by Fernando Gont). 

• draft-gont-6man-oversized-header-chain: Discusses the security implications that may arise from (among other reasons) small IPv6 fragments (individual submission by Fernando Gont and Vishwas Manral).

These documents are being formally discussed on the 6man wg mailing-list, although they have also received their share of discussion on the ipv6hackers mailing-list, and on LACNIC’s security forum mailing-list (in Spanish).

Feedback from the security and developer community is key to arrive to the best possible security-wise specifications, which will hopefully reflect into improved IPv6 implementations.

Conclusions

IPv6 implementations are converging towards the implementation of RFC 5722, which forbids overlapping fragments. This is a clear improvement over the IPv4 case, in which overlapping fragments are allowed, and hence insertion/evasion attack are harder to detect.

In a similar way, IPv6 implementations are slowly converging towards the implementation of the improved processing of IPv6 atomic fragments specified in draft-ietf-6man-ipv6-atomic-fragments. The aforementioned improved processing is key to avoid a number of fragmentation-based attacks that would otherwise be more trivial to perform in IPv6 than in IPv4.

It should be noted, however, that it will take time until some legacy implementations that implement neither RFC 5722 nor draft-ietf-6man-ipv6-atomic-fragments are phased out. Until that happens, those legacy implementations may still be subject to the similar insertion/evasion attacks than those that have traditionally been applied on IPv4 networks, and they may also be subject to some fragmentation-based attacks that could be performed in previously-unavailable ways.