Tuesday, 25 August 2015

IETF RFC 7610: "DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers"

We have just published IETF RFC 7610, entitled "DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers". The abstract of the RFC is:
This document specifies a mechanism for protecting hosts connected to
a switched network against rogue DHCPv6 servers.  It is based on
DHCPv6 packet filtering at the layer 2 device at which the packets
are received.  A similar mechanism has been widely deployed in IPv4
networks ('DHCP snooping'); hence, it is desirable that similar
functionality be provided for IPv6 networks.  This document specifies
a Best Current Practice for the implementation of DHCPv6-Shield.

We hope that this RFC will help in achieving parity of security features with IPv4.

Monday, 20 February 2012

IPv6 NIDS evasion and improvements in IPv6 fragmentation/reassembly


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:

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. #2:         BBBBBBBBBBB

Test #2

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

Test #3

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

Test #4

Frag. #2:                    BBBBBBBBBBB

Test #5

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

The results of the aforementioned test for different implementations are:

OS Test #1Test #2Test #3Test #4Test #5
NetBSD 5.0ICMPv6 TimedICMPv6 TimedICMPv6 TimedICMPv6 TimedICMPv6 Timed
OpenBSD 5.0First copyFirst copyLast copyLast copyFirst copy
OpenBSD-currentTime OutTime OutTime OutTime OutTime Out
FreeBSD 9.0ICMPv6 TimedICMPv6 TimedICMPv6 TimedICMPv6 TimedICMPv6 Timed
Linux kernelICMPv6 TimedICMPv6 TimedICMPv6 TimedICMPv6 TimedICMPv6 Timed
Windows XP SP2Time OutTime OutTime OutTime OutTime Out
Windows Vista (Build 6000)Time OutTime OutTime OutTime OutTime Out
Windows 7 Home PremiumTime OutTime OutTime OutTime OutTime Out

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:

OSAtomic Fragment SupportImproved Processing
FreeBSD 8.0 No No
FreeBSD 8.2 Yes No
FreeBSD 9.0 Yes No
Linux 3.0.0-15 Yes Yes
NetBSD 5.1 No No
OpenBSD-current Yes Yes
Solaris 11 Yes Yes
Windows XP SP2 Yes No
Windows Vista (Build 6000) Yes No
Windows 7 Home Premium Yes No

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-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.


    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.

    Wednesday, 21 December 2011

    DEEPSEC 2011 edition of our "Hacking IPv6 Networks" training

    Part of the materials used for the DEEPSEC 2011 edition of our "Hacking IPv6 Networks" training are now available on the SI6 Networks web site.

    The materials can be accessed here. Please stay tuned as new editions of our trainings are scheduled.

    Saturday, 17 December 2011

    A Proposal for Generating Stable Privacy-Enhanced Addresses in IPv6

    IPv6 hosts typically configure their IPv6 addresses by means of a mechanism known as StateLess Address AutoConfiguration (SLAAC). In SLAAC, a local router announces an IPv6 prefix to be used for address configuration, and the local hosts generate their IPv6 addresses by concatenating an Interface ID to the announced IPv6 prefix. For network technologies such as Ethernet, the Interface ID basically consists of the MAC address of the corresponding network interface card.

    The aforementioned procedure typically results in stable addresses (i.e., the each interface card always gets the same IPv6 address). Such "stable" addresses are generally considered to simplify network management, since they simplify ACLs and logging. However, since IEEE identifiers are typically globally unique, the resulting IPv6 addresses can be leveraged to track and correlate the activity of a node, thus negatively affecting the privacy of users.
    When a host moves from one network to another, the IPv6 prefix will change, but the Interface Identifier will be constant (since the MAC address does not change). As a result, it becomes trivial to track and correlate the activities of a node.
    The "Privacy Extensions for Stateless Address Autoconfiguration in IPv6" (specified in RFC 4941) were introduced to mitigate the aforementioned problem, and basically result in temporary (and random) Interface Identifiers that are typically more difficult to leverage than those based on IEEE identifiers (e.g. Ethernet addresses). Such temporary addresses are generated in addition to the traditional autoconfiguration addresses (i.e., the stable addresses typically constructed with MAC addresses): the temporary addresses are employed for "outgoing" communications, while the stable addresses are used for performing "server" functions (i.e., receiving incoming connections).

    Temporary addresses can be challenging in a number of areas.  For example, from a network-management point of view, they tend to increase the complexity of enforcing access controls and event logging.  As a result, some organizations disable the use of privacy addresses even at the expense of reduced privacy.
    On the other hand, even when privacy addresses are enabled, the "stable" addresses are still used for performing "server" functions, and hence can still be leveraged to affect the privacy of users (albeit with increased difficulty), and can still be leveraged for the purpose of host-scanning.
    IPv6 addresses based on IEEE identifiers (e.g. Ethernet addresses) can be easily predictable, particularly if all network interface cards in a subnet correspond to the same manufacturer: as soon as an attacker known one IPv6 address it can find the rest of the addresses by trying all possible combinations in the last three bytes of the IPv6 address.
    Fernando Gont has published an IETF Internet-Draft entitled "A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)", which proposes an algorithm for generating addresses that are stable within each subnet, but that result in different (and unpredictable) Interface Identifiers as hosts move from one network to another.  The aforementioned method is meant to be an alternative to generating Interface Identifiers based on IEEE identifiers, such that the same manageability benefits can be achieved without sacrificing the privacy of users.

    The proposal is being discussed at the 6man working group of the IETF. Feedback from the community will be appreciated.

    Thursday, 1 September 2011

    Router Advertisement Guard (RA-Guard) Evasion


    IPv6 Router Advertisement Guard (RA-Guard) is a mitigation technique for attack vectors based on ICMPv6 Router Advertisement messages. RFC6104 describes the problem statement of “Rogue IPv6 Router Advertisements”, and RFC6105 specifies the “IPv6 Router Advertisement Guard” functionality.
    Surprisingly enough, RFC6104 (the problem statement document) focuses on mis-configured routers, while RFC6105 describes RA-Guard as a security mechanism!
    The basic concept behind RA-Guard is that a layer-2 device filters ICMPv6 Router Advertisement messages, according to a number of different criteria. The most basic filtering criteria is that Router Advertisement messages are discarded by the layer-2 device unless they are received on a specified port of the layer-2 device. Clearly, the effectiveness of the RA-Guard mitigation relies on the ability of the layer-2 device of identifying ICMPv6 Router Advertisement messages.

    However, trying to filter layer-3 packets at layer-2 can be tricky.

    Router Advertisement Guard (RA Guard) Evasion Vulnerability 

    While there is currently no legitimate for IPv6 Extension Headers in ICMPv6 Router Advertisement messages, implementations allow the use of Extension Headers included in these messages, by simple ignoring the received options. Some implementations of RA-Guard (notably that of Cisco Systems) try to identify ICMPv6 Router Advertisement messages by looking at the “Next Header” field of the fixed IPv6 header, rather than following the entire header chain. As a result, these implementations fail to identify any ICMPv6 Router Advertisement messages that include any Extension Headers (for example, Hop by Hop Options header, Destination Options Header, etc.).

    The following figure illustrates the structure of ICMPv6 Router Advertisement messages that implements this RA-Guard evasion technique:

    While this attack vector is effective with RA-Guard implementations that fail to process the entire header chain (e.g., Cisco's), it could be easily mitigated by simply having the RA-Guard implementation process the entire header chain.

    However, a more sophisticated attack vector can be employed by leveraging the IPv6 fragmentation (i.e., the IPv6 Fragment Header).

    The basic idea is that if the forged ICMPv6 Router Advertisement is fragmented into at least two fragments, the layer-2 device implementing “RA-Guard” would be unable to identify the attack packet, and would those would fail do discard it.

    A simple implementation of this attack vector would be an original ICMPv6 Router Advertisement message preceded with a Destination Options Header, that results in two fragments. The following figure illustrates the “original” attack packet, prior to fragmentation, and the two resulting fragments which are actually sent as part of the attack.

    It should be noted that the length of the he Destination Options Header (its "Hdr Ext Len" field) is present only in the first fragment (but not in the second).  Therefore, it would be impossible for a device processing only the second fragment to locate the ICMPv6 header contained in that fragment, since it is unknown how many bytes should be “skipped” to get to the next header following the Destination Options Header.

    Thus, by leveraging the use of the Fragment Header together with the use of the Destination Options header, an attacker could conceal the type and contents of the ICMPv6 message he is sending (an ICMPv6 Router Advertisement in this example).  
    A layer-2 device could, however, at least detect that that an ICMPv6 message (or some type) is being sent, since the “Next Header” field of the Destination Options header contained in the first fragment is set to “58” (ICMPv6).
    It is be possible for an attacker to take this idea further, such that it is impossible for the RA-Guard implementation to even detect that the attacker is sending an ICMPv6 message in the first place. This can be achieved with an original ICMPv6 Router Advertisement message preceded with two Destination Options Headers, that results in two fragments. The following figure illustrates the “original” attack packet, prior to fragmentation, and the two resulting packets which are actually sent as part of the attack.

    In this variant, the “Next Header” field of the Destination Options header contained in the first fragment is set to “60” (Destination Options header), and thus it is impossible for a device processing only the first fragment to detect that an ICMPv6 message is being sent in the first place.

    The second fragment presents the same challenges as the second fragment of the previous variant.  That is, it would be impossible for a device processing only the second fragment to locate the second Destination Options header (and hence the ICMPv6 header), since the length of the first Destination Options header (i.e., its “Hdr Ext Len” field) is present in the first fragment (rather than the second).


    Fernando Gont has published (on behalf of CPNI) two IETF Internet-Drafts, that propose mitigations for these RA-Guard evasion vulnerabilities. One of the internet-drafts proposes to modify the protocol specifications such that use of IPv6 Extension Headers with Neighbor Discovery messages is forbidden (when SEND is not employed). The other internet-draft proposes an improved filtering policy that could be readily employed by network administrators and operators to mitigate these RA-Guard evasion techniques.

    These two internet-drafts have been presented at the 6man meeting and the v6ops meeting that took place at IETF 81, and are currently being discussed by the 6man and the v6ops working groups of the IETF.

    Some Conclusions 

    In IPv4,  options are limited to 40 bytes (resulting in a maximum IPv4 header of 60 bytes). On the other hand, IPv6 can easily employ 64K of options. This is just a simple example of how a protocol feature can be a two-sided knife: the larger option space available in IPv6 makes in much more difficult to enforce layer-2 ACLs.