Mitigating IPv6 Vulnerabilities

Capstone Research Project

April 24, 2015

Prateek Mali Prof. Joe McManus Rohan Phadke Scholar in Residence Jay Rao University of Colorado Boulder Ronak Sanghvi

Interdisciplinary Telecom Program University of Colorado Boulder

Abstract:

This paper explores some of the vulnerabilities associated

with the IPv6 protocol and the proposed solutions provide a

benchmark for organizations who want to test the basic

security issues in their IPv6 capable networks. We have

performed a qualitative analysis of some of the common

security aspects of IPv6 protocol. With just a handful of IPv4

blocks remaining to be assigned, it is with certainty that the

future is heading towards IPv6, and hence it is essential that

organizations be aware of the IPv6 related attacks and are

ready to secure the infrastructure. This paper focuses on the

three main sub-problems related to IPv6 security. These sub

problems are focused on the security issues due to the

Request for Comments (RFC) non-compliant network

devices and the threats associated with the Teredo tunnels

(dual stack architecture) of the network. We created a lab

environment for test scenarios and analyzed the results using

different operating systems. For automation purposes, a

script has been created which can detect such vulnerabilities,

and we hope that this script will serve as a base point for

testing the organizational security related to IPv6. Hopefully,

this research will eventually lead to more organizations

adapting IPv6 in their networks. We expect that our

research will have positive economic implications for the

organizations which are reluctant to switch to IPv6 enabled

network.

Keywords — IPv6 vulnerabilities, RFC non-compliant network

devices, Teredo tunnels, Dual stack architecture

I. INTRODUCTION

A. Statement of the problem

With infrastructure deployment of IPv6 increasing at a rapid

pace, what are the known security issues, and how to mitigate

the vulnerabilities caused due to the IPv6 protocol related

features to make IPv6 more secure and adaptable?

Fig 1: RIR IPv4 address run-down model [2].

With just a handful of final available blocks of IPv4

addresses remaining to be given out, it is certain that the

extinction of IPv4 is around the corner [1]. As Geoff Huston

predicts in the above figure [2], all the major Regional Internet

Registries (RIRs, such as ARIN, APNIC, etc.) will not have

significant IPv4 address blocks to assign by the year 2018. IPv6

is the only available alternative to IPv4 that can support growth

of Internet enabled applications and services. Although quite a

few organizations have already deployed IPv6 in their internal

infrastructure, the migration from IPv4 to IPv6 has been stalled

since 2011. While it is almost certain that the future is going to

be IPv6, many organizations are still reluctant to start planning

for the deployment of IPv6 in their infrastructure. One of the

major reasons for the hesitation is security of the network and

therefore it is very important to consider the security

implications of IPv6 and protect the network from IPv6 attacks.

In this paper, we have researched some of the major security

issues with IPv6 protocol and have also presented our findings

and solutions on how to make it more secure.

Mitigating security issues in IPv6 is important from an

economic standpoint as well. New companies who want to start

their business will be handed out only IPv6 addresses and if the

other big organizations want to keep their business growing,

they have to provide services to these new companies so as to

generate more revenue. All the communication will happen over

IPv6 and if security is weak, then the communication can be

compromised. Since IPv6 is in an early stage, more testing needs

to be done to find out all the loopholes and resolve them.

Vulnerabilities in IPv6 include Transmission Control Protocol

(TCP) SYN flood attack, type-zero header attack, Domain Name

System (DNS) attacks, tunneling issues, and fragmentation and

extension vulnerabilities [3]. The scope of this research is

limited to researching on some of these known vulnerability

issues and proposing solutions to mitigate some of the security

attacks caused due to such vulnerabilities, thereby making IPv6

more secure. The aim of this research is to lessen some of those

security concerns and provide practical solutions to make IPv6

more secure and adaptable.

B. Sub-problems for the research question

In order to answer the aforementioned research question,

three sub-problems have been identified. They are as follows:

1. How can we mitigate the security issues caused due to

the IPv6 protocol header, focusing on the issues which

are specific to only IPv6?

2. What different security risks are associated due to RFC

non-compliant network devices and what can be done

in order to mitigate them?

3. What are the threats associated with the dual stack

architecture and what are the implementation and

architecture considerations for the same?

The first sub-problem deals with the issues that are specific

only to IPv6. Unlike IPv4, Internet Control Message Protocol

(ICMP) is a required component of IPv6 and hence the firewall

policy needs to be added in order to account for all the ICMPv6

type messages (which is optional in IPv4). Neighbor discovery

uses ICMPv6 messages to find out the link layer address for the

connected interface, find the neighboring routers and various

other functions, making the role of ICMPv6 in IPv6 to be quite

broad. Hence, care must be taken that the policies which are set

related to ICMPv6 protocol account for all these different

message types. Also, this problem of setting ICMPv6 firewall

policy is an important one since quite a large amount of attacks

can be in the form of ICMPv6 messages. The scope of this

research related to the first sub problem is to test the different

operating systems with respect to the Cisco ASA firewall and

Juniper SRX firewalls and come up with the basic rule set which

can be used by the vendors to ensure that the basic ICMPv6

related malicious packets are prevented from entering into the

internal network.

The second sub-problem is about the RFC non-compliant

network devices. Not all IPv6 enabled devices support IPv6

completely and different platforms have different performance

characteristics with respect to IPv6 attacks. RFC 2460 states that

the extension headers of a particular type should appear only

once (except in the case of destination options header) [4]. The

optional information in IPv6 is encoded in the extension headers.

Different end-user operating systems such as Red Hat, Ubuntu,

and FreeBSD react differently to extension headers. Also,

extension headers have caused some of the devices running these

operating systems to completely ignore the layer 4 (OSI model-

transport layer) segment and this vulnerability has been used to

exploit the internal network [5]. Some of the OS platforms do

not comply with the RFC 2460 and do allow more than one

extension header of a particular type in a single packet. The

scope of this research is to test the effect of sending malicious

packets on different platforms in this case and coming up with a

detailed analysis on the performance of various operating

systems.

The third sub-problem is related to the threats associated with

the dual stack nature of the network. All the organizations

throughout the world cannot change their network to IPv6

overnight, so the networks will remain dual stack for a

significant period of time. IPv6 will be gradually deployed as

IPv4 will only be supported for legacy services and clients.

Initially, there will be islands of IPv6 networks separated by

IPv4 networks. There has to be a way in which IPv6 networks

can communicate through IPv4 networks. This is accomplished

with the help of tunneling. Teredo tunnels are essential for users

behind NAT devices so that they can communicate with the

external IPv6 networks. Teredo tunnels bypass the NAT devices

and it is difficult to investigate the Teredo traffic since they work

on random port numbers [6]. Teredo tunnels can also bypass the

firewalls and the security based controls need to be made

intelligent in regards to Teredo tunnels [6]. Hence, applying

firewall policies becomes very difficult in case of Teredo traffic.

The solution should be presented in such a way that it supports

end-to-end host security. This third sub-problem deals with

researching some of the potential threats due to Teredo tunnels

which can be overlooked by most organizations and proposing a

solution on how to tackle the same.

II. Literature Review

Deployment of IPv6 protocol was started in networks by

most major organizations a few years earlier, after the

exhaustion of IPv4 address space became a major issue.

However, the networks are not yet fully IPv6 capable, and one of

the main reasons for that is the large number of security issues

associated with IPv6. Security is an essential component in any

organization deploying IPv6. The architecture of IPv6 has

evolved over the years and day by day more security

vulnerabilities have been exposed upon due the architecture of

IPv6 protocol. Some of these vulnerabilities are existing security

issues associated with IPv4, whereas some of the vulnerabilities

have emerged along with the development of IPv6 [7].

Recent research in the field of IPv6 security by Cisco and

other organizations on how to make the IPv6 protocol more

compatible with the traditional architecture of security has

helped overcome some of the shortcomings such as neighbor

exhaustion cache, first hop security, Neighbor Discovery

Protocol (NDP) security through Secure Neighbor Discovery

(SEND) but there are still a lot of vulnerabilities which needs to

be considered. Our research focuses on some of thecommon

vulnerabilities and proposes a solution to mitigate the same. The

current research hopes to further extend the state of the art by

making IPv6 more secure and also enable several organizations

(who are reluctant at this moment) to start deploying IPv6 in

their networks [3].

This research also extends the current state of the art by

attempting to fill the void in the market by providing IPv6

Intrusion Detection System rules, firewall rules and testing tools,

all of which can be used to test the basic security related to IPv6

before switching over from IPv4. Through our research, we have

created an automation program to generate malformed IPv6

traffic, which can be used for instant testing purposes. Another

script has been created which can detect the most basic IPv6

related malicious traffic and thus alert the organizations of any

loopholes in their security infrastructure. All these scripts have

been published on Google Code and GitHub for future use and

further improvement.

A. Snort

Snort is a free and open source Network Intrusion Prevention

System (IPS) and Network Intrusion Detection System (IDS),

for the UNIX and Windows platforms [8]. IDS implies that the

application in question can detect the security threats, but cannot

take any active action on its own. IPS, meanwhile, also have the

capability to drop the malicious packets. The packet processing

via Snort can best be described with the help of the following

illustration [9]:

Fig. 2. Schematic Data Flow in Snort [9].

The syntax for writing a general SNORT rule is summarized in

Fig. 3 below:

Fig. 3. Example of a Generic Snort Rule.

With respect to the SNORT rules, IPv6 lags behind IPv4 by

almost 15 years’ worth of security rules already implemented for

IPv4 [10]. In addition to the usual attacks that are present, IPv6

also falls prey to additional auto-configuration, neighbor

discovery mechanisms, and variable header attacks [10]. Certain

IPv6 plug-ins do exist, and we made use of these plug-ins to

come up with our own SNORT rules for mitigating IPv6

vulnerabilities.

B. Teredo Tunnels

A Teredo tunnel is a mechanism by which we can have an

IPv6 only host communicate with IPv4 only hosts [11]. Teredo

is unique in the fact that it can be successfully implemented on

devices from even behind a NAT [11] device. Unfortunately,

this also opens up unique security issues, specific to Teredo

tunnels. For one, a Teredo tunnel increases the possible attack

surface, by assigning routable IPv6 addresses to devices sitting

behind a NAT device [11]. It also opens the possibility of being

subject to Denial of Service (DoS) attacks on Teredo clients, and

Distributed Denial of Service (DDoS) attacks on the Teredo

Relay [12].

C. Extension Headers

In this part of the paper, we have examined the abuse of IPv6

extension headers and demonstrated a way to detect it. We have

developed scripts to generate malicious IPv6 packets, detect

malicious packets, and plot their summary at the end. There are

operating system vendors who have failed to comply with RFC

standards. Furthermore, some security devices like IDS and IPS

do not detect and properly handle attacks through malicious

extension headers. Our aim for this project is to flag and

potentially stop the abuse of IPv6 extension headers.

As shown in figure [4], IPv6 headers do not have

unnecessary and complex fields like IPv4 headers. This reduces

processing cost of packets. The changes have several advantages

but there was a need of extra fields to do the same work that the

options field did in an IPv4 header. This was a primary reason to

implement IPv6 extension headers.

Fig. 4. IPv6 Header [13].

As depicted in figure [5], the optional IPv6 extension headers

are added at the end of IPv6 header and before the upper layer

header. There is always an 8-bit field in IPv6 extension headers

that identify the next header value. An IPv6 packet can carry

zero, one or multiple extension headers. Each extension header

declares subsequent headers through the next header field.

Fig. 5. IPv6 Extension Header Chain [13].

According to RFC 2460, which defines the IPv6 standard, the

following types of extension headers are primarily used.

Hop-by-Hop Options

Routing

Fragment

Destination Options

Authentication

Encapsulation Security Payload

All IPv6 extension headers should occur only once (with an

exception for destination options header which at most can

appear twice) in an IPv6 packet [13]. Except for Hop-by-Hop

options extension headers, IPv6 extension headers are not

examined by any node along the way to the destination of the

packet. If more than one extension header is used in an IPv6

packet, RFC 2460 recommends following order to be maintained

[13].

1) IPv6 header

2) Hop-by-Hop Options header

3) Destination Options header

4) Routing header

5) Fragment header

6) Authentication header

7) Encapsulation Security Payload header

8) Destination Options header

9) Upper-layer header

The Hop-by-Hop Options header is used to specify delivery

parameters at each hop on the path to the destination. It is used

for padding (Type 0/1), jumbo payload option (packet larger

than 65535 bytes, Type 194), and router alert option (Multicast

Listener Discovery and RSVP, Type 5) [19].

Destination Options header can appear more than once in an

IPv6 packet [13]. It is used to specify delivery parameters for

either an intermediate destinations or the final destination. If a

routing header is present, it specifies delivery or processing

options at each intermediate destination otherwise it specifies

delivery or processing option at the final destination [19].

Routing header is similar to loose source routing in IPv4. For

routing type 0, the routing type-specific data is a list of

intermediate destination addresses [19]. When an IPv6 packet

reaches an intermediate destination, the Routing header is

processed and the address of the next intermediate destination

becomes the Destination Address in the IPv6 header.

Fragment header is used for fragmentation and reassembly

services. It contains same fields as IPv4 (fragment offset, more

fragment flag, and identification). When an IPv6 packet is

fragmented, it is initially divided into unfragmentable and

fragmentable parts: The unfragmentable part of the original IPv6

packet must be processed by each intermediate node between the

fragmenting node and the destination [19]. This part consists of

the IPv6 header, the Hop-by-Hop Options header, the

Destination Options header for intermediate destinations, and the

Routing header. The fragmentable part of the original IPv6

packet must only be processed at the final destination node. This

part consists of the Authentication header, the Encapsulating

Security Payload header, the Destination Options header for the

final destination, and the upper layer Protocol Data Unit (PDU).

Next, the IPv6 fragment packets are formed. Each fragment

packet consists of the unfragmentable part, a fragment header,

and a portion of the fragmentable part [19].

Authentication header and Encapsulating Security Payload

header fields remain same as in an IPv4 packet.

D. RFC Standards

For the purpose of this project, we studied RFCs to determine

vulnerability of the current standard practice to handle IPv6

packets and the ways attackers can exploit them for abuse. Here

is the brief description of some of the RFCs that have the

potential to cause IPv6 based attacks.

According to RFC 4942, the flexibility of IPv6 protocol may

also lead to changes in the boundaries between legitimate and

malicious traffic as identified by these rules [14]. It mentions

that RFC 2460 does not appear to take into account the behavior

of middle boxes that may be inspecting the packet and thus

limits security protection of these boxes. In order to locate the

transport header or other protocol data unit, the node has to parse

the header chain. A middle box cannot guarantee to be able to

process header chains that may contain headers defined after the

box was manufactured [14].

According to RFC 7045, an IPv6 capable node must

recognize and deal with all standard IPv6 extension headers

[15]. It also states that a node should not discard packets that

contain unrecognized extension headers [15].

RFC 7112 states implications of oversized IPv6 header

chains [16]. According to this RFC, an IPv6 packet must include

the whole header chain in the first fragment of an IPv6

datagram. A host receiving datagram violating this rule should

discard the packet. An intermediate node may discard the packet

and it may send an ICMPv6 error back to the source [16].

III. RESEARCH METHODOLGY

A. Snort

We set up two Kali Linux Virtual Machines in the Lab

environment, and installed Snort on both of them. By taking the

generic example mentioned earlier in this paper as a reference,

we wrote our own rules for the malicious IPv6 traffic, and

updated the 'rules.conf' file in the Snort directory, accordingly.

We developed two rules of significance, and they are discussed

below.

The first rule is for triggering an alert, any time multiple

extension headers are detected. Having multiple extension

headers is an indication of a possible malformed packet. Hence,

we wrote a SNORT rule to send an alert to the system

administrator, any time such a packet with multiple extension

headers is received. The rule is:

Neighbor Discovery related attacks are also a common

occurrence in IPv6. The Neighbor Detection attacks usually take

place via flooding, wherein a Neighbor Discovery message is

continuously flooded in the network, to create a sort of Denial-

of-Service attack. This eats up the network resources, and thus

the Neighbor Discovery does not get successfully completed.

So, we also wrote a Snort rule, which would trigger an alert if

we detect a flooding of Neighbor Discovery packets. We set the

threshold to be 50 packets in 5 seconds. If this threshold is

exceeded, it would trigger an alert. The rule is:

We then tested these rules against the malformed packets we

generated ourselves using the Scapy framework.

B. Teredo Tunnels

We set-up a virtual machine to simulate a Teredo client, and

initiated a successful Teredo tunnel between that virtual machine

and the Internet. We then observed all the IPv6 traffic that was

flowing through the Teredo tunnel, and carried out an analysis of

this traffic to understand the patterns. We checked which sources

were sending the most traffic through the Teredo tunnel, whether

they were possible DoS attacks, and other similar factors. We

also plotted some of these results graphically for better

understanding.

C. Analysis on End User Operating System

In order to test the second sub-problem of our research, we

analyzed the impact of malicious IPv6 packets on different end-

user operating systems. The impact was tested on two operating

systems, namely Kali Linux and Fedora 21. The setup for this

experiment was the same as that of the setup for applying snort

rules. A broad set of malicious packets was sent from a machine

into both of these operating systems and the incoming packets

were detected using Wireshark. These packets included

combinations of extension headers which should not have been

accepted by any operating system, as per RFC 2460. For

example, the order of extension headers was interchanged for

some of the packets. The order in which extension headers

should occur in a packet is Hop by Hop options header,

Destination Options header, Routing header, Fragment header

[13]. We observed how Kali Linux and Fedora 21 reacted when

packets having the order of extension headers interchanged were

given to them. Additionally, there is also a limit on the

occurrence of extension headers. For example, the Hop by Hop

options header cannot occur more than once in a packet, while

the Destination Options header cannot occur more than twice

[13]. We tested whether the operating systems were able to

detect this limitation in the malicious packets.

D. Theoretical Firewall rules

In the above section, some of the vulnerabilities we found in

the end-user operating systems are mentioned. One option to

tackle these vulnerabilities is to make the operating system

detect packets with incorrect occurrences of extension headers.

However, every operating system reacts differently to malicious

alert ip any any -> any any ( ip6_extnum: !1; msg:

"Multiple Extension Headers detected - Possible

malformed packet";

sid: 10000001; rev: 1;)

alert icmp any any -> any any (icmp6_nd;

detection_filter: track by_dst , count 50, seconds 5;

msg:"ICMPv6 flooding due to Neighbor Discovery

Protocol - Possible attack"; sid: 10000002; rev: 1;)

IPv6 packets, so to implement this solution for every operating

system is a long process. Another option to tackle some of the

vulnerabilities discovered in the above section is to use a

Firewall in the network, which can filter IPv6 packets based on

their extension headers. Using appropriate rules on the Firewall,

we can avoid passing malicious packets to the end user operating

system.

To write these rules on a Cisco ASA Firewall, it is necessary

to create an inspection-type policy map on the firewall. An

inspection policy map consists of a traffic matching command

and parameters that affect the behavior of the inspection engine

[17]. One of the applications of this is to prevent IPv6 packets

with jumbled extension headers reaching the end user operating

system. The rule for the same on a Cisco ASA Firewall is as

follows [17]:

From this rule, the Firewall will inspect all IPv6 traffic

passing through it and check if the extension headers in every

packet are in the correct order. If not, the packet will be blocked

by the Firewall itself, and will not reach the end-user. This rule

will prevent one of the vulnerabilities associated with Kali Linux

and Fedora 21, as discovered in the previous section.

The format to write rules on a Juniper SRX Firewall is

slightly different from the above. An application where we can

use Juniper SRX device to filter traffic is to eliminate the

vulnerability in which the end user operating system accepts

more than 10 extension headers in a packet. Using Juniper SRX

Firewall, we can write a rule to limit the number of extension

headers in a packet. The rule will be as follows [18]:

Thus, using Juniper SRX device we can eliminate another

vulnerability associated with Kali Linux and Fedora 21.

E. Script

We attempt to provide a platform to test capabilities of an

operating system against potential abuse of IPv6 extension

headers. The reason to test capabilities is vendors do not always

make RFC compliant products. We set up a simple test

environment where through one workstation we generated the

malformed IPv6 packet and on the second workstation we

monitored the response using different operating systems. In this

section several ways are covered by which an attacker can abuse

IPv6 extension headers. For our project, we selected some of the

widely representative operating systems.

Centos 6.3

Ubuntu 12.04

Windows 7

Windows 8

To generate custom IPv6 packets, we used a python script

which in turn used a Scapy framework. As a transport layer

payload, we used ICMPv6 echo request messages. The test

scenarios are listed below:

1) More than one occurrence of various extension headers

in an atomic IPv6 fragment: Atomic fragments are the

IPv6 packets where the offset is set to zero and the M

bit is also zero, which implies that this is the first and

only packet of the sequence. There is no obvious reason

to accept these kind of packets, though some OS accept

them.

2) Several types of extension headers multiple times:

Similar to first test, we mixed several types of extension

headers in a single IPv6 packet (atomic fragment).

Results show some operating systems accept this type

of packets.

3) Nested fragments: Most of the operating systems

allowed multiple occurrences of extension headers in a

single IPv6 datagram; for this test we split one fragment

inside other fragments to test how operating systems

respond to that.

Table 1. Summary of different operating systems responding to malformed IPv6

extension headers

Test

Scenarios

Fedora

21

Cent

os 6.3 Kali

Ubuntu

12.04

Win

7/8

1. More than

one occurrence

of various

extension

headers in

atomic IPv6

packets

2. Several

types of

extension

headers,

multiple times

3. Nested

fragments

4. Higher layer

protocol

information in

non-first

fragments

5. Overlapping

fragments

6. Arbitrary

data over layer

3

4) Higher layer protocol information in non-first

fragments: In this test, we sent upper-layer protocol

information in a non-first fragment which is against the

RFC recommendations [7].

5) Overlapping fragments: We sent three fragments in this

test where the third fragment has the same offset as the

policy-map type inspect ipv6 ipv6-map; parameters;

verify-header order

edit security screen ids-option screen-name ip;

ipv6-extension-header limit 10

second fragment, which led to overlapping of these

fragments.

6) Arbitrary data over layer 3: Most extension headers in

IPv6 serve strict purpose but destination options

extension header and hop-by-hop option extension

header carry TLV (type-length-value) field. According

to RFC 2460, if the first two bits of the field 'Type" are

equal to '01', the packet should be discarded [7]. We

send packets with ‘01’ as its first two bits.

Table 1 shows whether an operating system replied in the

case of the different test scenarios described above.

IV. RESEARCH RESULTS

A. Snort

The rules we wrote were successful in achieving the desired

results. In both the instances, we were successfully able to

generate an alert, whenever we sent malformed packets.

B. Teredo Tunnels

As mentioned earlier, we were able to get statistical data to

understand what kind of traffic was flowing through the Teredo

tunnel, how much was the volume of this traffic, and what the

possible implications of this traffic were, if any.

Fig. 6. Different Source IP addresses of the Teredo Traffic.

The figures shown here indicate which source IP addresses

traverse through the Teredo tunnel, when IPv6 test traffic is

passed through it. Fig. 6 maps the IP addresses with respect to

time, whereas Fig. 7 displays this information in the form of a

candlestick graph.

C. Analysis on End User Operating System

When the order of Hop by Hop options in a packet was

changed, it was observed that both Kali Linux and Fedora 21 did

not accept the packet. The Hop by Hop Options header has to be

the first extension header for any packet. When an ICMPv6

packet is sent with the Hop by Hop Options extension header

occurring at the end of the packet, both the operating systems

detect the wrong pattern, and do not reply to the ICMPv6 echo

request, as shown in Fig. 8.

Fig 8. Inspection of packet on Wireshark.

The other type of malicious packets that were sent were

those with more than the supported occurrence of an extension

header. When ICMPv6 echo request packet with more than one

occurrence of the Hop by Hop Options header was sent, both

Kali Linux and Fedora 21 could not detect the anomaly in the

packet. Both the operating systems accepted the packet and an

ICMPv6 echo reply was sent, as shown in Fig. 9.

Fig. 9. Inspection of packet on Wireshark.

Similar to the above packet, an ICMPv6 packet with more

than two occurrences of the Destination Options header was sent

to both the operating systems. Yet again, both the operating

systems accepted the packet and sent an ICMPv6 echo reply.

They were unable to detect that the ‘Next Header’ field in the

packet was invalid. Additionally, an IPv6 packet cannot have

more than 10 extension headers of any type. However, when the

number of Destination Options header is increased to 8, which

gives rise to more than 10 extension headers, it is observed that

both the operating systems cannot detect the anomaly. This is

demonstrated in Fig. 10.

Fig. 7. Concentration of Teredo Traffic.

Fig 10. Inspection of packet on Wireshark.

Thus, it was concluded that Kali Linux and Fedora 21 are

vulnerable to the security issue including multiple occurrences

of extension headers. However, they can detect change in order

of Hop by Hop Options header, thus avoiding the vulnerability

associated with it.

D. Script

To accomplish the test scenarios mentioned in Section III,

part E, we created five python scripts. The first script is for

generating malformed IPv6 packet, the second script is to check

whether the IPv6 address entered by the user is valid or not, and

the third script is to detect malformed IPv6 packets. The purpose

of the script is to check a system's compatibility and security

level in terms how that system responds when it receives

malformed IPv6 packets. The last two python scripts are

developed to plot bar and/or pie graphs as a summary.

The first python script, named 'pgs.py', allows user to

generate six types of malformed packets. The user has to provide

source IPv6, destination IPv6, number of packets he wants to

send, and type of the packet to be sent. After sending packets,

the script will ask the user if he wants to send more packets. The

script can be run in two modes: autonomous and interactive.

In autonomous mode, the user has to provide every detail

(source IP, destination IP, number of packets and type of packet)

alongside the script when the user runs it. This mode does not

require user input in run-time, therefore it can be used in bash

scripts to automate packet generation.

In interactive mode, the user has to enter information when

being asked by the script. In this mode, the user cannot

automate. He will be asked whether he wants to see the packet

he just generated. The script will ask whether the user wants to

send more packets or not. The script proceeds as per the user

input. At the end of the packet generation, in interactive mode,

the script will ask the user what type of graph he wants to

generate. The graph will plot the types of packets against

number of packets generated.

The second python script, named 'ipv6_check.py', checks

whether the IPv6 address entered by the user, either as a source

IP address or a destination IP address, is valid or not. This script

is internally used by the packet generation script to validate the

IPv6 address entered.

The third python script, named 'pktinspect_ipv6.py', is a

detection program. It checks whether the received IPv6 packet is

a proper or malformed one. The decision to declare a packet

malformed is done based on multiple RFCs (primarily RFC

2460). If the packet is suspected to be malformed one, the

program prints a warning message on the screen saying

'Malformed packet detected'. If the packet is found to be proper

(compliant with RFC standards), it does not print any warning

message. The script always prints data (source MAC, destination

MAC, source IP, destination IP, etc.) found in the IPv6 packet.

When the user stops the program, he is asked to select which

type of graph he wants to print. The program provides option to

select bar or pie chart. The graph plots proper packets and

malicious packets versus the number of packets received in each

category.

The fourth and fifth python scripts, named 'pgs_graphs.py'

and 'pis_graphs.py', generate graphs. One plots all the types of

packets generated and other plots the number of malformed

packets detected versus proper packets received.

When the user runs 'pgs.py' script in interactive mode, he will

be directed to terminal similar to figure [11].

Fig. 11. Snapshot of script 'pgs.py' running in interactive mode.

After the user completes generating all the packets, he will

be asked about which type of graphs he wants to print. Figure

[12] shows pie graph and figure [13] shows bar graph for packet

generation.

Fig. 12. Example of pie graph after packet generation.

When the user runs 'pktinspect_ipv6' script, he will see the

screen as shown in figure [14].

When the user stops the detection script, he will be asked to

select which type of graph he wants to print. If the user selects

bar graph, they will be shown graph similar to figure [15] and if

user selects pie graph, he will be shown graph similar to figure

[16].

This python project is shared online on GitHub at

"https://github.com/jayrao/capstone-ipv6". These scripts allows

user to determine capability of his/her system against possible

IPv6 attacks with malformed header.

Fig. 13. Example of bar graph after packet generation.

Fig. 14. Snapshot of script 'pktinspect_ipv6' running.

Fig. 15. Example of bar graph after packet inspection.

Fig. 16. Example of pie graph after packet inspection.

V. CONCLUSION

Through deployment of IPv6 enabled networks by

organizations it has become necessary to tackle the

vulnerabilities associated with IPv6. This paper identifies the

major security issues associated with IPv6 and provide solutions

or indications of anomalies associated with them. The majority

of these issues are caused by the modified packet header. This

paper details on the different IPv6 extension headers and how

they can impact network security. The effect of malicious IPv6

traffic is demonstrated on different operating systems and using

Snort acting as an IDS. This can bring into effect better

mechanisms to be built on operating systems and Snort, which

can tackle IPv6 malformed traffic. Additionally, Python scripts

which can detect and generate malicious IPv6 packets were

developed. Dual-stack routing is another important IPv6 security

issue covered in this paper. Teredo tunneling can be used to

carry malicious IPv6 traffic which can lead to DDoS attacks.

This paper analyses the security impact caused due to Teredo

tunneling, which can help further research to mitigate such

attacks. This paper also includes rules which can be written on

Cisco ASA and Juniper SRX firewalls in a network that can

block malicious IPv6 traffic. The intent of this paper is to

propose solutions for some of the problems associated with IPv6

and provides data for further research.

VI. REFERENCES

[1] D. York, “Goodbye, IPv4! IANA Starts Allocating Final

Address Blocks | Deploy360 Programme.” [Online].

Available:http://www.internetsociety.org/deploy360/blog/2014/

05/goodbye-ipv4-iana-starts-allocating-final-address-blocks/.

[Accessed: 09-Nov-2014].

[2] G. Huston, “IPv4 Address Report,” 05-Dec-2014, [Online].

Available: http://www.potaroo.net/tools/ipv4/plotend.png

[3] H. Dawood and K. F. Jassim, “Mitigating IPv6 Security

Vulnerabilities,” in 2013 International Conference on Advanced

Computer Science Applications and Technologies (ACSAT),

2013, pp. 304–309.

[4] S. E. D. <deering@cisco.com>, “Internet Protocol, Version 6

(IPv6) Specification.” [Online]. Available:

http://tools.ietf.org/html/rfc2460. [Accessed: 13-Oct-2014]

[5] B. Cerveny, “IPv6 Extension Headers,” Arbor Networks,

DDoS and Security reports, 02-Aug-2011,

http://www.arbornetworks.com/asert/2011/08/ipv6-extension-

headers/

[6] J. Hoagland, “The Teredo Protocol: Tunneling Past Network

Security and Other Security Implications.”

[7] A. Atlasis, “Security Impacts of Abusing IPv6 Extension

Headers,” in Black Hat security conference, 2012, pp. 1–15.

[8] “Snort Users manual”, The Snort Project. October 13, 2014.

[Online]. Available: https://www.snort.org/#get-started

[Accessed 22-Apr-2015

[9] M. Schutte, T. Scheffler, B. Schnor. “Development of a

Snort IPv6 Plugin” Available:

http://www.idsv6.de/Downloads/2012_Schuette_Scheffler_Schn

or-Snort_poster.pdf [Accessed 22-Apr-2015]

[10] C. Schutte, ‘The IPv6 Snort plugin,’ 18 March 2014.

Available:

https://www.ernw.de/download/20140318_Troopers14_Snort_IP

v6.pdf [Accessed 22-Apr-2015]

[11] “Teredo Tunneling,” InfoSec Institute. [Online]. Available:

http://resources.infosecinstitute.com/Teredo-tunneling/.

[Accessed: 22-Apr-2015].

[12] “Teredo: Tunnelling IPv6 over UDP through Network

Address Translations (NATs).” Available:

https://www.ietf.org/rfc/rfc4380.txt. [Accessed 22-Apr-2015]

[13] S. Deering and R. Hinden, " Internet Protocol, Version 6

(IPv6) Specification." [Online]. Available:

https://tools.ietf.org/html/rfc2460. [Accessed: 20-Apr-2015]

[14] E. Davies, S. Krishnan, and P. Savola, "IPv6

Transition/Coexistence Security Considerations." Available:

https://www.ietf.org/rfc/rfc4942. [Accessed: 20-Apr-2015]

[15] B. Carpenter and S. Jiang, "Transmission and Processing of

IPv6 Extension Headers." Available:

https://tools.ietf.org/html/rfc7045. [Accessed: 20-Apr-2015]

[16] F. Gont, V. Manral and R. Bonica, "Implications of

Oversized IPv6 Header Chains." Available:

https://tools.ietf.org/html/rfc7112. [Accessed: 20-Apr-2015]

[17] “Cisco ASA 5500 Series Configuration Guide using the

CLI, 8.4 and 8.6 - Configuring Special Actions for Application

Inspections (Inspection Policy Map) [Cisco ASA 5500-X Series

Next-Generation Firewalls],” Cisco. [Online]. Available:

http://cisco.com/c/en/us/td/docs/security/asa/asa84/configuration

/guide/asa_84_cli_config/mpf_inspect_maps.html. [Accessed:

21-Apr-2015].

[18] “ipv6-extension-header-limit - Technical Documentation -

Support - Juniper Networks.” [Online]. Available:

http://www.juniper.net/documentation/en_US/junos12.1x46/topi

cs/reference/configuration-statement/security-edit-ipv6-

extension-header-limit.html. [Accessed: 22-Apr-2015].

[19] A. Atlasis, "Researching IPv6 Security Capabilities

(RISC)," [Online]. Available:

https://www.ernw.de/download/AAtlasis-RISC-project-

presentation-%20results.pdf. [Accessed: 22-Apr-2015].