Evaluation of Intrusion Detection Systems in IPv6 Networks

Max Schr

otter

, Thomas Schefﬂer

and Bettina Schnor

Operating Systems and Distributed Systems, University of Potsdam, Potsdam, Germany

School of Engineering - Energy and Information, Hochschule f

ur Technik und Wirtschaft Berlin, Berlin, Germany

Keywords: IDS, IDSv6, Benchmark, IPv6.

Abstract:

This paper introduces a benchmark suite for the evaluation of intrusion detection systems in IPv6 environ-

ments. We use this benchmark to evaluate the prominent intrusion detection systems Snort, Zeek and Suricata.

Further, an IPv6 Plugin Suite is presented and evaluated which enhances Snort by stateful attack detection.

The results of our evaluation demonstrate the current abilities to detect IPv6 link-local attacks.

1 INTRODUCTION

Relatively early after the ﬁnalization of the IPv6 stan-

dard, it became apparent, that the automatic host con-

ﬁguration mechanism deﬁned in the protocol did not

work well with the proposed IPsec security mech-

anisms and that the Neighbor Discovery Protocol

(NDP) (Narten et al., 2007) suffered from similar se-

curity problems as the Address Resolution Protocol

(ARP) in IPv4 (Arkko et al., 2002).

The root cause of these issues lies in the early au-

thentication problem (Nikander, 2002), which is com-

mon to all Layer 2 protocols without strong node

authentication (most importantly Ethernet). There-

fore, most mitigation techniques such as port-based

Network Access Control (IEEE 802.1X), IP Secu-

rity (IPSec) and SEcure Neighbor Discovery (SEND)

propose cryptographic host authentication. However,

this either requires some form of pre-conﬁguration of

credentials and keying material or resource intensive

computations, which is not a practical solution within

most networks. Another approach advocates the ﬁl-

tering of IPv6 messages on Layer 2 devices as speci-

ﬁed by the IPv6 Router Advertisement Guard (Levy-

Abegnoli et al., 2011) which requires hardware sup-

port in the switches as well as conﬁguration effort.

The network research community is aware of the

security issues of IPv6 and the Neighbor Discovery

Protocol (NDP) (Hogg and Vyncke, 2009; Nikander

et al., 2004) and the IETF has re-worked some of the

standards in recent years to limit the attack surface

of the protocols (Gont, 2013). However, countermea-

sures not always exist, since some of these problems

are protocol inherent.

This leads to a third approach, that focuses on

network monitoring and anomaly detection. Work

started with (Beck et al., 2007), which introduced the

host-based tool ndpmon that listens to all NDP mes-

sages in order to detect NDP anomalies and report

them. Another suitable approach is based on the ex-

tension of Intrusion Detection Systems (IDS) with ad-

equate protocol support for the detection of speciﬁc

IPv6-attacks. The authors of (Sch

utte et al., 2012)

developed an IPv6 Plugin Suite for the well known

IDS Snort 2. This approach beneﬁts from the already

implemented packet capturing, decoding, conﬁgura-

tion, logging mechanisms, and log analysis tools of

the IDS framework. A new preprocessor module and

several new IPv6-speciﬁc rule options make the def-

inition of IPv6-speciﬁc attack signatures possible. In

this paper, we present our ﬁndings on implementing a

similar Plugin Suite that supports the new version of

the IDS Snort 3.0 (see Section 4.1) and comparing its

detection results with other popular intrusion detec-

tion systems (see Section 6). For the comparison, we

propose an IDSv6 benchmark suite consisting of IPv6

speciﬁc network attacks (see Section 3).

2 RELATED WORK

In 2015, Jon Mark Allen published a report which

examined the IPv6 support by the intrusion detec-

tion systems Snort, Suricata, and Bro (Zeek) (Allen,

2015). One of his observation was the unsatisfying

tool support at that time - such as not displaying the

corresponding IPv6 address in case of Snort when

viewing an alert from an IPv6 stack. Different to our

408

Schrötter, M., Schefﬂer, T. and Schnor, B.

Evaluation of Intrusion Detection Systems in IPv6 Networks.

DOI: 10.5220/0007840104080416

In Proceedings of the 16th International Joint Conference on e-Business and Telecommunications (ICETE 2019), pages 408-416

ISBN: 978-989-758-378-0

approach, Allen investigated web application attacks

in IPv6 trafﬁc, but no IPv6 speciﬁc attacks. All three

IDS systems were tested with the same network cap-

tures of a web application vulnerability scan: one over

IPv4, and one over IPv6. While the three IDS systems

behaved different in their number of alerts, each IDS

reported a comparable amount of alerts for the IPv4

and IPv6 trafﬁc as one would expect.

Salih et al. present a tool which detects and clas-

siﬁes covered channels in IPv6 networks (Salih et al.,

2015). Sources of covert channels are header ﬁelds

which are not set properly. Salih et al. identify

the following header ﬁelds as potential covert chan-

nels: Trafﬁc Class, Flow Label, Payload Length, Next

Header, Hop Limit, and Source Address. They pro-

pose a Machine Learning approach to detect covert

channel implementing an enhanced feature selection

algorithm supporting Naive Bayesian classiﬁer. The

results of the conducted experiments show a high de-

tection performance of about 96 %. While this is a

promising result, it is questionable whether these at-

tacks should be detected by an intrusion detection sys-

tem, since the misuse of IPv6 header ﬁelds may al-

ready be prohibited by a packet ﬁlter.

In order to prove that IPv6 attacks are real and

exploitable, Marc Heuse implemented different link-

local attacks in “The Hacker’s Choice” (THC) toolkit

(Heuse, nd). The toolkit implements several denial-

of-service and fragmentation attacks as well as a

covert channel attack where a destination option

header is misused. The toolkit is easy to use also for

non-security experts, constantly updated and runs on

Linux. We use the THC toolkit as the base of our

IDSv6 benchmark (see Section 3).

Fernando Gont developed the SI6 Networks’ IPv6

toolkit

. Like the THC toolkit, the SI6 implements

link-local attacks special to IPv6, but it is highly con-

ﬁgurable and may be used for protocol analysis as

well as attack purposes. The tools need to be param-

eterized correctly in order to be effective and usually

require more protocol knowledge and conﬁguration

overhead than the THC toolkit. Contrary to the THC

toolkit the SI6 implementation runs also on BSD-type

UNIXes such as FreeBSD and MacOS.

3 THE IDSV6 BENCHMARK

One question that is going to be asked by researchers

and practitioners alike is: ”How effective is a partic-

ular IDS in detecting network attacks”? It is possi-

ble to use the THC toolkit and SI6 directly to mea-

https://www.si6networks.com/tools/ipv6toolkit/

sure the effectiveness of attack detection and defense

mechanisms but this method has several drawbacks.

Software versions change also for attack tools and

may implement subtile changes that can lead to vary-

ing detection results. Necessary network setups de-

pend on additional devices and their conﬁguration, are

time consuming to create and may be difﬁcult to repli-

cate exactly. Attributing changes in detection results

to speciﬁc root causes becomes difﬁcult, even if the

same tools are used for different measurements.

The problem of comparatively benchmarking dif-

ferent Intrusion Detection Systems is not new. Hav-

ing a common benchmark dataset eases comparison

between different systems and makes trial runs easily

reproducible. Between 1998 and 2000, Lincoln Lab-

oratory of MIT released several datasets for the eval-

uation of IDS, the so called DARPA datasets

. The

datasets were aimed to represent real-world trafﬁc

mixes interspaced with attack trafﬁc. Right after re-

lease, these datasets drew immediate criticism regard-

ing the modelling and generation of the attack and

background trafﬁc (McHugh, 2000), however, they

are still used to the present day, simply because no

other common benchmarks exist.

When we started developing the IPv6 Plugin Suite

for Snort, we were looking for a quick way to ver-

ify our development efforts. In order to automatize

attack detection testing and to minimize administra-

tive overhead, we created the IDSv6 benchmark suite,

that now consists of several pcap ﬁles derived from

real attack tools created in the network setup depicted

by Figure 1. This collection of pcap ﬁles can be ap-

plied quickly and consistently in order to test detec-

tion rates and functionality of intrusion detection sys-

tems. The IDS present in the ﬁgure plays no active

part during capturing of the attack trafﬁc. It simply is

a placeholder to indicate from what position within

the network trafﬁc patterns will be observed if the

benchmark pcap ﬁles are used. IDS usually support

direct input from capture ﬁles. If this is not possi-

ble, tools like tcpreplay

could be used to reproduce

previously captured network events.

Table 1 lists all the different attacks that are

included in the suite. With the exception of

dos mld chiron, all attacks were created by the THC

toolkit in Version v3.5-dev. We choose the THC

toolkit because of its maturity and ease of use, which

makes it likely to be used during real network attacks.

The Chiron tool can be found on Github

. We used

Version 1.0 of this tool.

The IDSv6 benchmark is focused on attacks that

https://www.ll.mit.edu/r-d/datasets

https://tcpreplay.appneta.com

https://github.com/aatlasis/Chiron

Evaluation of Intrusion Detection Systems in IPv6 Networks

409

Figure 1: Testbed for the recording of the IDSv6 benchmark

pcap ﬁles.

are new to IPv6 and / or that exist because of missing

early authentication. For example, it includes record-

ings of an attack created by the THC parasite6 tool,

which implements the IPv6 version of an ARP cache

poisoning.

Different attacks affect different parts of the net-

work. While most attacks are local to a speciﬁc

subnet, some attacks were carried out across a net-

work border. The parasite6 attack, for example,

affected only components of the 2001:db8:1::0/64

subnet. It manipulated the communication between

Client (:1) and Server (:5). The Attacker (:2) send

spoofed Neighbour Discovery Advertisements to the

Client and thereby redirected trafﬁc to himself or to a

non-existing target on the network.

When we tried to upset the ﬂow of Multicast

trafﬁc in the network, we found that the THC tool

dos mld was not able to disrupt multicast trafﬁc in

our testbed. We therefore chose to use the Ch-

iron tool to generate a successful attack, that is

called dos mld chiron in the benchmark. The at-

tack vector of the tool is described in the talk MLD

considered harmful (Rey et al., 2016). A multi-

cast source in the 2001:db8:2::0/64 subnet sends

continuous multicast messages to a client in subnet

2001:db8:1::0/64. The attacker is placed in the

same subnet as the client. The attacker stopped the

ﬂow of multicast messages by ﬁrst becoming the lo-

cal MLD Querier and sending a spoofed MLD Report

removing listeners for this MLD group. Afterwards

it sends a Last Listener Query and periodic Generic

Queries to the unicast address of the router.

The frag attacks, which create variously frag-

mented packets, and the denial6 attacks, which cre-

ates packets ﬁlled with too many extension head-

ers and options, are conducted with the attacker

placed in the 2001:db8:2::0/64 subnet and the

client in subnet 2001:db8:1::0/64.

The Benchmark inluding all pcap ﬁles is publicly

available

4 INTRUSION DETECTION

SYSTEMS

This section gives a short overview of the evaluated

intrusion detection systems. All three systems are

open source, free to use and have done their home-

work and support the necessary decoding of IPv6

packets for the upper layer protocol analysis and at-

tack detection. In section 6, we will further evaluate

whether these systems can also detect IPv6-speciﬁc

attacks.

4.1 Snort

Snort (Roesch, 1999) is a powerful and widely used

IDS that provides basic IPv6 support. In prior work, it

was recognized that Snort in version 2 lacks the abil-

ity to detect many attacks on IPv6-speciﬁc protocol

mechanisms (Sch

utte et al., 2012) and had to be ex-

tended to handle those attacks.

Snort 3, also called Snort++, is the next generation

of Snort. It ﬁxes many of the performance and conﬁg-

uration shortcomings of Snort 2. Snort++ also gains

a lot more ﬂexibility by modularizing Snort prepro-

cessors, and thereby gaining service speciﬁc inspec-

tors. Despite the new codebase, we found, that it still

lacks many of the features provided by the IPv6 Plu-

gin Suite that had been developed for Snort 2 (Sch

utte

et al., 2012).

We therefore made the decision to implement a

corresponding IPv6 Plugin Suite for Snort++. This

new Plugin Suite is inspired by the prior version and

expands its functionality based on our IDSv6 bench-

mark (Section 5 discusses the new Plugin Suite in

more detail).

4.2 Zeek/Bro

Zeek, previously known as Bro

, has been originally

developed by Vern Paxson (Paxson, 1999) at UCB.

The Zeek IDS emphasizes a clean separation between

the decoding stage, implemented in C, and the anal-

ysis and alarm generation which is implemented in a

domain-speciﬁc language called bro script.

Basic IPv6 support is enabled by default since

Bro 2.1. Further, support for IPv6 fragmentation re-

assembly, tunnel decapsulation and IPv6 header chain

analysis was added in subsequent versions.

https://redmine.cs.uni-potsdam.de/projects/pcap

https://www.zeek.org

SECRYPT 2019 - 16th International Conference on Security and Cryptography

410

Table 1: List of attacks in the IDSv6 benchmark.

Attack Description

covert send6 Sends data covertly by putting it into a Destination Options Header.

denial 1-6 Various attacks to conduct a DoS attack against a host. It increases the decoding

effort of the host by including a large amount of unknown options or extension

header.

dos mld chiron An attack that cancels an arbitrary MLD subscription by becoming the MLD

querier and faking the multicast speciﬁc queries.

dos new ipv6 An attack that disrupts SLAAC by always replying with advertises and therefore

prevents new hosts from obtaining an IP address.

fake mldrouter6 advertise Advertising a wrong MLD router via MRD to interfere with ﬁltering of MLD

snooping switches.

fake mldrouter6 terminate Terminates a MLD router via MRD to interfere with ﬁltering of MLD snooping

switches.

ﬂood * Attacks that ﬂood the network with various NDP and MLD messages.

frag 1-36 Various fragmentation attacks that send malformed fragments to circumvent ﬁre-

walls or attack the victim’s network implementation.

kill router6 Removes the given router as gateway from all SLAAC conﬁgured systems in the

network.

ndpexhaust26 An ﬂooding attack that ﬂoods the network with ICMPv6 toobig messages.

parasite6 real An neighbour cache poisoning attack to divert trafﬁc to the attacker.

parasite6 fake An neighbour cache poisoning attack to divert trafﬁc to a not used MAC address.

redir6 A man in the middle attack that diverts the trafﬁc with ICMPv6 redirect messages.

rsmurf6 An attack that sends a ping from a multicast address to the victim.

smurf6 An attack that sends a ping with the victims IP address to a multicast address.

toobig An attack causing atomic fragments and therefore a DOS attack as described in

RFC8021

4.3 Suricata

Suricata is the youngest of the three IDS projects de-

veloped by the Open Information Security Founda-

tion

, a non-proﬁt organization founded in 2009. Its

goal is to develop an IDS that is backward compatible

with existing Snort rule sets, but not limited by Snort’s

development and architecture history. Suricata’s ar-

chitecture is targeted at parallel execution to beneﬁt

from modern multicore processor architectures.

Suricata promises IPv6 support only for packet

decoding (IPv6, ICMPv6).

5 IPV6 PLUGIN SUITE

In this section we present the functionality of the IPv6

Plugin Suite for Snort 3. Due to the new architecture

and code base of Snort 3, no existing code could be

reused and the Plugin Suite needed to be developed

from the ground up. As mentioned in Section 4.1 the

Snort++ preprocessor stage is now split up in many

Inspector sub stages. Also, all plugins are embedded

in their own modules and Inspector and Rule Options

are separate types of plugins. Therefore, we did not

https://oisf.net

had to create one, but several plugins. The Plugin

Suite is open source and can be found online

5.1 NDP Inspector

In contrast to Snort 2, which ran all preprocessors on

all captured packets, now only inspectors speciﬁc to

that packet are executed. The types of packets for

which an inspector can be written are predeﬁned by

Snort 3. There is an IP packet type but no sub-type for

the different versions of the Internet Protocol. There-

fore, our inspector is called on all IP packets.

The plugin needs some pre-conﬁguration to be ef-

fective. For example it needs to know the address of

the current IPv6 subnet, for which it is going to exam-

ine the correct execution of the Neighbor Discovery

Protocol. The plugin then examines the source and

destination addresses of all incoming IPv6 packets. If

these addresses match the conﬁgured subnet, it tries to

learn the corresponding IPv6 address together with its

Layer 2 address and create a host-list for the subnet.

One problem, that any detection tool must avoid,

is the state-explosion that is possible in IPv6 net-

works. Due to the large size of IPv6 subnets (2

pos-

https://redmine.cs.uni-potsdam.de/projects/

snort3-ipv6-plugin

Evaluation of Intrusion Detection Systems in IPv6 Networks

411

sible hosts) it is comparatively easy to overwhelm de-

tection tools by sending packets with randomly gen-

erated IPv6 Host-IDs.

Our original idea was to monitor the Duplicate

Address Detection (DAD) process for each host and

learn only hosts, for which DAD had been success-

fully completed. However, this strategy would require

that each host on the subnet needs to perform DAD

after our plugin starts and would exclude hosts where

DAD was administratively disabled or broken. We

therefore implemented a different strategy. Before a

host address is learned and marked as active, the host

must send at least two and receive one packet that can

be observed by the plugin.

Once the plugin has a complete overview of the

subnet, it becomes possible to detect attacks that ex-

ploit the authentication gap between Layer 2 and

Layer 3.

One example for such an attack can be observed

by looking at the mechanism of the dos new ipv6

tool. The tool interferes with the stateless autoconﬁg-

uration process for new IPv6 addresses, by answer-

ing each DAD Neighbor Solicitation request with the

message that the address is already present in the net-

work. This attack effectively hinders an IPv6 host

from correctly conﬁguring an IPv6 address and en-

tering the network. The plugin can detect this attack

by checking protocol messages against the recorded

network structure. If the DAD Neighbor Solicitation

request is answered with a spoofed Neighbor Adver-

tisement the plugin triggers an alert.

Each host is identiﬁed by MAC and IP-Address

in the data structure and the plugin is able to distin-

guish different virtual machines from the same virtu-

alisation host. The data structure used to manage ac-

tive hosts is a combination of a hash map and a dou-

ble linked list and has a user conﬁgurable size. The

hash map allows for quick access to entries by a key

and the linked list allows for a fast least recently used

(LRU) replacement strategy, should the number of en-

tries outgrow its conﬁgured size. A fast replacement

of entries is needed to avoid that our plugin itself be-

comes the target of a DoS ﬂooding attack.

The plugin also records the amount and type of

NDP and MLD messages present in the network in

order to detect ﬂooding attacks. An alert can be trig-

gered by the amount of packages seen within a time

window. Time and trafﬁc parameters for ﬂooding de-

tection are conﬁgurable and their exact values depend

on the size and kind of network under observation.

There are also some attacks such as

kill router6 that can be detected without having

to analyze the underlying network structure. Some

of the necessary checks, that needed to be imple-

mented for Snort 2 within a plugin, are now already

covert by Snort 3 decoder inspectors. This includes

the check for the right order and amount of IPv6

extension headers. The mentioned kill router6

attack, however, is not yet covered and needs to

be implemented within the Plugin Suite. It detects

Router Advertisement messages that are send with a

lifetime of zero and can be misused to signal to hosts

that a particular router is going down and it should be

removed from routing tables.

In total, our new NDP inspector supports 17 alerts

described in Table 2. Not all of them are used to detect

attacks, some also exist for debugging reasons (5,8,9).

The plugin does not create alerts directly but gen-

erates so called detection events. These detection

events must be conﬁgured to trigger alerts via Snort

rules. We suggest to use the priorities shown in Ta-

ble 2. The priority is an integer value stating the sever-

ity level of an event. It starts with the value 1, which

represents the highest priority. Priorities can also be

set by assigning a classtype to a rule. The classtype

priorities vary from 1 to 4, where 4 is the lowest pri-

ority.

The following example shows the use of such an

alert within a newly deﬁned Snort rule:

alert (msg:"Possible Neighbour Cache

Poisoning";

sid: 15;

gid:1001;

rev:1;

classtype:mitm;)

And the following class deﬁnition:

{ name = ’mitm’, priority = 1,

text = ’man in the middle attack’ }

Snort identiﬁes events uniquely by assigning sev-

eral ID values, such as Generator ID (GID), Signature

ID (SID), and Revision ID (REV). The GID indicates

which Snort module generated the event. Normal de-

tection rules are evaluated by the text rule inspector,

which uses the default value of 1 (gid:1). Our IPv6

Plugin Suite uses the GID value 1001 (gid:1001).

Each module itself may signal many different

events and each of these events needs to be identiﬁed

clearly. This is done using SID values. SID values

may be re-used between modules and may sometimes

have internal guidelines regarding the value range that

may be applicable for user-deﬁnable IDs. The as-

signed SID values for our IPv6 Inspector Plugin are

given in Table 2 and currently range from 1 to 17.

REV values are mainly relevant for user-deﬁned

text rules, which may be rewritten over time and here

the REV value will be used to indicate that a rule had

been altered from a previous state.

SECRYPT 2019 - 16th International Conference on Security and Cryptography

412

Table 2: Snort 3 IPv6 Inspector Plugin Alerts.

SID PRIO MESSAGE

1 1 Spoofed Redirect Message

2 2 Neighbor Discovery ﬂood de-

tected

3 1 Router Kill detected

4 1 Router Advertisement from non-

Router

5 4 New Router Alert

6 2 Change Router Flag Alert

7 2 Change Router Preﬁx Alert

8 4 New DAD

9 4 New Host Alert

10 3 DAD Conﬂict Alert

11 1 Spoofed DAD Conﬂict Alert

12 3 Unsolicited Advertise Alert

13 2 MLD ﬂood detected

15 1 Possible Neighbour Cache Poi-

soning

16 1 MLD Query from non-Router

MAC

17 1 MLD Router Advertisement from

non-Router

5.2 IPv6 Rule Options

The other function provided by the IPv6 Plugin Suite

is the extended support for multiple options that ex-

pand the Snort rule language. These options enable

the user to write rules that can be IPv6 aware and spe-

ciﬁc. Snort rules typically target Layer 4 trafﬁc and

are agnostic to different versions of the Internet Pro-

tocol. While this is the desired behaviour to detect the

majority of network attacks, it hinders the detection of

attacks that target speciﬁc Network Layer functions.

A Snort rule is based on the following scheme:

action proto source dir dest ( body )

A rule must contain an action that the rule should

invoke and a protocol for which this rule is created.

The source, direction and destination are optional.

The body contains a Signature ID, Generator ID and

Revision ID to identify the rule. It also contains a

message that will be logged on match. There are more

options in the body that further specify the rule, but

most of the available options are signature options to

differentiate detected packets.

The following example shows a rule, that uses the

Snort rule options ﬂow and http uri:

alert http (msg:"Access to dubious URI!";

flow:established, to_server;

http_uri:"attack";

sid:1000001;)

The rule examines HTTP messages contained

within an established TCP session which are directed

to the server. Should the URI of the HTTP command

contain the string attack, it triggers an alert.

The IPv6 Plugin Suite adds the following options

to target IPv6 speciﬁc rules within Snort 3 (Table 3):

Table 3: IPv6 Plugin Suite Options.

ipv: n IP version, n is allowed to be 4

of 6

ip6 flow: n matches the IPv6 Flow Label, n

has a value between 0 and 2

ip6 exthdr: n checks the whole IPv6 header-

chain for a Next Header value

equal to n

ip6 rh: n checks the Routing Type of a

IPv6 Routing Header, n is an 8

bit value

ip6 optionId: n checks the presence of an option

with ID n in a Hop-by-Hop or

Destination header.

This allows Snort to ﬁlter on IPv6-speciﬁc at-

tributes, as the following rule shows:

alert ip (msg:"Fragmented IPv6 packet with

router alert!";

ip6_exthdr: 44;

ip6_optionId: 5;

priority: 2;

gid:1;

sid:1000002;)

The IPv6 Standard (Deering and Hinden, 2017)

deﬁnes a Next Header value of 44 for the Fragment

header. This rule will ﬁre if Snort detects a Fragment

header in the header chain (ip6 exthdr: 44 ) and

when there is a Hop-by-Hop or Destination header

which carries the option 5 for a router alert (Faucheur,

2011) (ip6 optionId: 5). This rule has been given

the second highest priority (priority: 2).

6 IDSV6 BENCHMARK RESULTS

In this section we present the results from our exper-

iments running the IDSv6 benchmark against the in-

trusion detection systems Snort, Zeek and Suricata in

order to test their ability to detect protocol-level at-

tacks targeted at IPv6 and compare the results against

our IPv6 Plugin Suite.

The systems under test were Snort 3.0.0 (beta)

with and without the IPv6 Plugin Suite, Zeek 2.5 and

Suricata 3.2.1. For Snort the community rules, the

snort subscriber rules

and the built-in rules were in-

https://www.snort.org/downloads

Evaluation of Intrusion Detection Systems in IPv6 Networks

413

stalled and activated. For Suricata all available rule

sets from suricata-update

were installed. Also all

Zeek modules were activated.

The outputs from intrusion detection systems are

often very verbose. It happens frequently that not only

one, but several warnings are generated for an attack.

Sometimes these warnings ﬁt to the attack, but some-

times they are misleading, redundant and of no bene-

ﬁt for the system administrator. This makes it difﬁcult

for the IDSv6 benchmark to automatically produce a

meaningful score value. Instead, the output was an-

alyzed manually to determine which attacks are cor-

rectly detected. The complement set, i.e. the set of

attacks which are not recognized, shows where the

systems have to be improved.

The IDSv6 benchmark consists of 62 attacks, this

includes 36 attacks that use various forms of fragmen-

tation to evade attack detection by ﬁrewalls and to

trigger undesired behaviour in host systems. We will

brieﬂy discuss our ﬁndings for each individual IDS.

Table 4 summarizes the results of our experiments.

6.1 Zeek

Zeek is capable to detect fragmentation overlap

attacks (fragmentation6 1-4,6-8,17,18,28,29)

and gives correct warnings (“fragment inconsistency”

or “fragment overlap”). It also detects most other

fragmentation anomalies as in fragmentation test 13

where Zeek warns “excessively large fragment”

when an ICMPv6 request (Ping) with a payload size

of 65486 Bytes is sent. In summary, Zeek detects 22

of the 36 fragmentation attacks.

Zeek still fails completely to detect abnormalities

like the ﬂooding attacks and all other attacks based on

IP spooﬁng.

6.2 Suricata

Suricata detects 22 of the 33 fragmentation attacks,

but the detection sets of Zeek and Suricata are not the

same, Suricata detects correctly one-shot fragments

(fragmentation6 9-12,25-29) with the alert “IPv6

useless Fragment extension header”. In contrast to

Zeek, Suricata does not detect all overlapping and

large fragments. It also fails to detect the presence

of two fragmentation headers in a packet.

Apart from fragmentation attacks, Suricata suc-

cessfully detects 5 of the 7 denial6 attacks. For not

correctly detected attacks, Suricata gives a lot of false

positive warnings. For the parasite6 attack, Suri-

cata warns “HTTP Host header invalid” for a correct

HTTP request created by curl. In almost all attacks it

https://github.com/OISF/suricata-update

Table 4: IDSv6 Benchmark Results.

Attack

Snort3-

beta

Snort3-

ipv6-suite

Zeek

Suricata

covert send6 3 3 7 3

denial6-1, 2, 3,

4, 7

3 3 7 3

denial6-5 7 7 7 7

denial6-6 3 3 7 7

dos mld chiron 7 3 7 7

dos new ipv6 7 3 7 7

fake mldrouter6

advertise

7 3 7 7

fake mldrouter6

terminate

7 7 7 7

ﬂood advertise6,

mld26, mld6,

router26, rs6,

solicitate6

7 3 7 7

frag-1, 2, 3, 4,

15, 16, 17, 18,

26, 28, 29, 31,

32, 33

3 3 3 3

frag-5, 19, 20,

21, 34

7 7 7 7

frag-6, 7 7 7 3 3

frag-8, 13, 14,

30, 35, 36

7 7 3 7

frag-9, 10, 11,

12, 27

3 3 7 3

frag-22, 23, 24 3 3 7 7

frag-25 3 3 7 3

kill router6 7 3 7 7

ndpexhaust26 7 3 7 7

parasite6 fake,

real

7 3 7 7

redir6 7 3 7 7

rsmurf6 3 3 7 3

smurf6 3 3 7 7

toobig 3 3 7 7

Total = 62 33 47 22 29

also falsely detects “zero length padN option” which

is a valid padding option for 2 bytes. In total Suricata

detects 29 attacks.

6.3 Snort

Snort without the IPv6 Plugin Suite detects 6 of the 7

denial6 attacks. It detects the denial6-6 attack that

Suricata missed and warns correctly “short fragment,

possible DOS attempt” and “fragmentation overlap”.

However, it fails to detect the fragmentation over-

SECRYPT 2019 - 16th International Conference on Security and Cryptography

414

lap attacks (fragmentation6 6-8). On the other

hand, Snort is the only IDS that detects some incom-

plete fragments (fragmentation6 22,23,24). In

total, Snort detects 23 of the 36 fragmentation attacks.

Snort also creates correct warnings for covert send6

and rsmurf6 as Suricata did, but with more pre-

cise descriptions. Additionally, it detects smurf and

toobig.

6.4 Snort with IPv6 Pugin Suite

When we include the IPv6 Plugin Suite in Snort,

we are now able to detect 47 of 62 attacks of the

IDSv6 benchmark. Snort gains the ability to detect

NDP and MLD ﬂooding attacks. Because of the im-

plemented inspector, it also detects NDP related at-

tacks. For example, a fake mldrouter advertise

is detected by comparison with the conﬁgured

router list. However, Snort still fails to detect the

fake mldrouter terminate attack, because we cur-

rently have no way do distinguish legitimate Multicast

Router Termination messages from spoofed ones.

The plugin has no negative inﬂuence on the native

detection ability for denial6 and fragmentation6

attacks. All previously detected attacks are still rec-

ognized by Snort.

6.5 Usability

All three tested IDS were able to directly examine

recorded pcap ﬁles and supported multiple output

modules including a log output. We found that the

created default log ﬁles varied greatly in readability.

Zeek/Bro produces human-readable tabulated output,

while Suricata and Snort fail to write condensed hu-

man readable log ﬁles with their respective log mod-

ules, even though they have JSON output modules.

The log ﬁles contain one entry for each packet that a

rule matches and therefore creates an alert.

Especially in the case of Suricata, critical warn-

ings can easily be missed by system administrators,

because they may be hidden within a ﬂood of irrel-

evant warnings. This problem is increased by the

fact that almost all relevant attacks were categorized

as a low priority warning. Suricata provided some

warnings with higher priority like ”BAD-TRAFFIC

IP Proto 103 PIM”, but which were (with the excep-

tion of one) either false positives or irrelevant for the

attack.

7 CONCLUSION

When we compare the detection results for attacks

against the IPv6 Neighbor Discovery process with re-

sults from (Sch

utte et al., 2012), we ﬁnd that the cur-

rent generation of IDS made little progress regarding

the detection of such attacks. The results over all three

systems, Snort, Suricata and Zeek, show that the in-

trusion detection systems are only able to detect basic

IPv6 abnormalities such as fragmentation and header

errors. Although similar detection functionality does

already exist for IPv4 (Snort, for example, already has

the functionality to detect ARP poisoning) the IPv6

version was never implemented.

The development of our IPv6 Plugin Suite greatly

enhances the detection capabilities for genuine IPv6

attacks. When our IPv6 Plugin Suite is used, Snort

exhibits an improved detection rate that results in the

correct identiﬁcation of 76% of the attacks covered

by the IDSv6 benchmark suite, whereas it previously

only detected about 53%.

Another area that is in need of improvement is the

usability of IDS. We think that the correct interpre-

tation of events should not be difﬁcult and although

in most cases alerts from IDS will be fed into moni-

toring systems, it is still beneﬁcial for administrators

to be able to directly read and understand the alerts

generated by the system.

Zeek currently shows the most readable output.

Even the new Snort 3, which is still in develop-

ment, does not create very human readable reports

and therefore makes it necessary to use third party log

analytics and visualization tools such as ELK

REFERENCES

Allen, J. M. (2015). A Performance Comparison of Intru-

sion Detection Systems with Regard to IPv6. Techni-

cal report, SANS Institute InfoSec Reading Room.

Arkko, J., Aura, T., Kempf, J., M

antyl

a, V.-M., Nikander,

P., and Roe, M. (2002). Securing IPv6 neighbor and

router discovery. In WiSE ’02: Proceedings of the

1st ACM workshop on Wireless security, pages 77–86,

New York, NY, USA. ACM.

Beck, F., Cholez, T., Festor, O., and Chrisment, I. (2007).

Monitoring the Neighbor Discovery Protocol. In The

Second International Workshop on IPv6 Today - Tech-

nology and Deployment - IPv6TD 2007, Guadeloupe.

Deering, S. and Hinden, R. (2017). Internet Protocol, Ver-

sion 6 (IPv6) Speciﬁcation. RFC 8200, Internet Engi-

neering Task Force.

Faucheur, F. L. (2011). IP Router Alert Considerations and

Usage. RFC 6398, Internet Engineering Task Force.

https://www.elastic.co/elk-stack

Evaluation of Intrusion Detection Systems in IPv6 Networks

415

Gont, F. (2013). Security Implications of IPv6 Fragmenta-

tion with IPv6 Neighbor Discovery. RFC 6980, Inter-

net Engineering Task Force.

Heuse, M. (nd). THC IPv6 attack tool kit.

Hogg, S. and Vyncke, E. (2009). IPv6 Security. Cisco

Press, Indianapolis, IN 46240 USA.

Levy-Abegnoli, E., de Velde, G. V., Popoviciu, C., and Mo-

hacsi, J. (2011). IPv6 Router Advertisement Guard.

RFC 6105, Internet Engineering Task Force.

McHugh, J. (2000). Testing intrusion detection systems: A

critique of the 1998 and 1999 darpa intrusion detec-

tion system evaluations as performed by lincoln labo-

ratory. ACM Transactions on Information and System

Security (TISSEC), 3(4):262–294.

Narten, T., Nordmark, E., Simpson, W., and Soliman, H.

(2007). Neighbor Discovery for IP version 6 (IPv6).

RFC 4861, Internet Engineering Task Force.

Nikander, P. (2002). Denial-of-Service, Address Owner-

ship, and Early Authentication in the IPv6 World.

In Christianson, B., Malcolm, J., Crispo, B., and

Roe, M., editors, Security Protocols, volume 2467

of Lecture Notes in Computer Science, pages 12–21.

Springer, Berlin/Heidelberg.

Nikander, P., Kempf, J., and Nordmark, E. (2004). IPv6

Neighbor Discovery (ND) Trust Models and Threats.

RFC 3756, Internet Engineering Task Force.

Paxson, V. (1999). Bro: a system for detecting network

intruders in real-time. Computer Networks, 31(23-

24):2435–2463.

Rey, E., Atlasis, A., and Salazar, J. (2016). Mld considered

harmful.

Roesch, M. (1999). Snort: Lightweight Intrusion Detection

for Networks. In Proceedings of the 13th USENIX

conference on System administration, pages 229–238.

Salih, A., Ma, X., and Peytchev, E. (2015). Detection and

Classiﬁcation of Covert Channels in IPv6 Using En-

hanced Machine Learning. In Proc. of The Interna-

tional Conference on Computer Technology and In-

formation Systems.

Sch

utte, M., Schefﬂer, T., and Schnor, B. (2012). Devel-

opment of a Snort IPv6 Plugin - Detection of Attacks

on the Neighbor Discovery Protocol. In 9th Interna-

tional Conference on Security and Cryptography (SE-

CRYPT), Rom, Italy.

SECRYPT 2019 - 16th International Conference on Security and Cryptography

416