Mitigating IPv6 Vulnerabilities - Be Boulder Anywhere

Mitigating IPv6 Vulnerabilities
Capstone Research Project
April 24, 2015
Prateek Mali
Rohan Phadke
Jay Rao
Ronak Sanghvi
Prof. Joe McManus
Scholar in Residence
University of Colorado Boulder
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.
2.
3.
How can we mitigate the security issues caused due to
the IPv6 protocol header, focusing on the issues which
are specific to only IPv6?
What different security risks are associated due to RFC
non-compliant network devices and what can be done
in order to mitigate them?
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 modeltransport 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. 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
Fig. 2. Schematic Data Flow in Snort [9].
The syntax for writing a general SNORT rule is summarized in
Fig. 3 below:
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.
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)
2)
3)
4)
5)
6)
7)
8)
9)
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
IPv6 header
Hop-by-Hop Options header
Destination Options header
Routing header
Fragment header
Authentication header
Encapsulation Security Payload header
Destination Options header
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:
alert ip any any -> any any ( ip6_extnum: !1; msg:
"Multiple Extension Headers detected - Possible
malformed packet";
sid: 10000001; rev: 1;)
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 Denialof-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:
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;)
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 enduser 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
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]:
policy-map type inspect ipv6 ipv6-map; parameters;
verify-header order
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]:
edit security screen ids-option screen-name ip;
ipv6-extension-header limit 10
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
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
Fedora
21
Cent
os 6.3
Kali
Ubuntu
12.04
Win
7/8























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
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 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.
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.
Fig 8. Inspection of packet on Wireshark.
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.
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.
Fig. 6. Different Source IP addresses of the Teredo Traffic.
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. 16. Example of pie graph after packet inspection.
Fig. 13. Example of bar graph after packet generation.
V.
Fig. 14. Snapshot of script 'pktinspect_ipv6' running.
Fig. 15. Example of bar graph after packet inspection.
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
[13] S. Deering and R. Hinden, " Internet Protocol, Version 6
(IPv6) Specification." [Online]. Available:
https://tools.ietf.org/html/rfc2460. [Accessed: 20-Apr-2015]
[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].
[14] E. Davies, S. Krishnan, and P. Savola, "IPv6
Transition/Coexistence Security Considerations." Available:
https://www.ietf.org/rfc/rfc4942. [Accessed: 20-Apr-2015]
[2] G. Huston, “IPv4 Address Report,” 05-Dec-2014, [Online].
Available: http://www.potaroo.net/tools/ipv4/plotend.png
[15] B. Carpenter and S. Jiang, "Transmission and Processing of
IPv6 Extension Headers." Available:
https://tools.ietf.org/html/rfc7045. [Accessed: 20-Apr-2015]
[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.
[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]
[4] S. E. D. <[email protected]>, “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-extensionheaders/
[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]
[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-ipv6extension-header-limit.html. [Accessed: 22-Apr-2015].
[19] A. Atlasis, "Researching IPv6 Security Capabilities
(RISC)," [Online]. Available:
https://www.ernw.de/download/AAtlasis-RISC-projectpresentation-%20results.pdf. [Accessed: 22-Apr-2015].