The STRIDE Towards IPv6: A Comprehensive Threat Model for IPv6

Transition Technologies

M. Georgescu, H. Hazeyama, T. Okuda, Y. Kadobayashi and S. Yamaguchi

Nara Institute of Science and Technology, 891-6 Takayama, Ikoma, Nara, Japan

Keywords:

IPv6 Transition Technologies, Threat Model, STRIDE, Dual-stack, Single Translation, Double Translation,

Encapsulation.

Abstract:

The IPv6 worldwide deployment rate is still a single ﬁgure. This is due to the many challenges introduced

by the transition period through which both IPv4 and IPv6 will need to coexist. One of the biggest concerns

related to the IPv6 transition is security, which is more difﬁcult to ensure in a heterogeneous environment. To

clarify the security threats introduced by IPv6 transition technologies, this article proposes a comprehensive

threat model built around the established STRIDE approach. To verify the usefulness of the proposed model, a

threat analysis of four generic categories of IPv6 transition technologies is performed. Existing and new threats

are documented, classiﬁed and prioritized. To further validate some of the documented threats, preliminary

penetration test data is presented.

1 INTRODUCTION

The IPv4 address space exhaustion is imminent and

can affect the further expansion of the Internet. The

Internet Assigned Numbers Authority (IANA) has al-

located on February 3rd 2011 the last blocks of IPv4

addresses (NRO, 2014). Four out of the ﬁve Regional

Internet Registries (RIR) have entered the last stage

of IPv4 exhaustion. A detailed report is presented in

(Huston, 2015) by APNIC’s G. Huston. IPv6 was in-

troduced in 1998. However, the IPv6 worldwide de-

ployment rate is still very low, approaching 5% as the

APNIC Labs (APNIC, 2015) report. The root cause

for this low deployment status is the lack of back-

wards compatibility between IPv6 and IPv4. In other

words, IPv4-only nodes and IPv6-only nodes cannot

communicate directly. That means transition mecha-

nisms have to be used and also that the Internet has to

undergo a period through which both protocols have

to coexist. This period can be simply referred as the

IPv6 transition.

Aside from the larger address space, IPv6 has,

in theory, a number of advantages over its predeces-

sor in terms of design: a more efﬁcient and exten-

sible datagram, improved routing with easier route

computation and aggregation, stateless autoconﬁgu-

ration and mandatory security. Over the years, how-

ever, some of these new features have proved to be ei-

ther challenges for enforcing security (e.g. extension

headers, stateless autoconﬁguration), or not-feasible

(e.g. widespread deployment of IPv6 with IPsec).

The IPv6 transition has further aggravated these chal-

lenges as transition technologies are generally ex-

posed to the threats associated with both IP versions

and hybrid blends, depending on the subcomponents.

When building an IPv6 transition plan, security

is arguably the biggest concern for network opera-

tors, as a heterogeneous IPv4 and IPv6 environment

greatly increases the attack surface. To that end,

building a threat model for IPv6 transition technolo-

gies can help clarify and categorize the associated se-

curity threats. In turn, this should facilitate the search

for mitigation techniques and can lead to a security

quantiﬁcation method for IPv6 transition implemen-

tations. Considering all of the above, this article pro-

poses a threat model built around the well established

STRIDE approach described in (Hernan et al., 2006).

The STRIDE mnemonic is used to classify the doc-

umented threats. The correlations between elements

of the Data Flow Diagrams (DFD) and the STRIDE

threat categories detailed in (Hernan et al., 2006) are

used for the initial basic assessment of the threats for

each of the sub-elements.

The generic STRIDE approach represents only the

base of our proposal. The main contribution lies in

identifying the threat modeling steps necessary for

IPv6 transition technologies in particular. To prove

the validity of the proposal, the model is used to de-

Georgescu, M., Hazeyama, H., Okuda, T., Kadobayashi, Y. and Yamaguchi, S.

The STRIDE Towards IPv6: A Comprehensive Threat Model for IPv6 Transition Technologies.

DOI: 10.5220/0005652402430254

In Proceedings of the 2nd International Conference on Information Systems Security and Privacy (ICISSP 2016), pages 243-254

ISBN: 978-989-758-167-0

243

ﬁne and categorize existing and new threats for the

four generic types of IPv6 transition technologies.

The resulting non-exhaustive threat analysis and pen-

etration test data can be considered another important

part of the contribution of this work.

The rest of the paper is organized as follows: Sec-

tion 2 gives an overview of IPv6 transition technolo-

gies, Section 3 presents related literature, in Section

4, we introduce the proposed threat model, section 5

discusses our approach and lastly section 6 states the

conclusions.

2 IPv6 TRANSITION

IPv6 was not designed to be backwards compatible.

Consequently, in a heterogeneous environment coex-

istence and transition technologies need to be em-

ployed. Initially, three basic transition mechanisms

were proposed: dual-stack, translation and tunnel-

ing. The associated implementation standards are pre-

sented in RFC 4213 (Nordmark and Gilligan, 2005)

and RFC 6144 (Baker et al., 2011).

For dual-stack, IPv4 and IPv6 are implemented on

the same node. This method is used mostly for host-

side nodes and edge nodes. The biggest challenge

introduced by dual-stack is overhead. Translation is

the only method which ensures direct communication

between IPv4 and IPv6 by translating the message

format and information between different versions of

Internet Protocol. The complication introduced by

translation is breaking the end-to-end characteristic

of the Internet, something that IPv6 was supposed

to bring back. Tunneling or encapsulation is used

to traverse heterogeneous network environments, by

encapsulating the IPvX packets into the payload of

IPvY packets, where X,Y ∈ {4, 6}. At the border of

the IPvY and IPvX networks the packets are decap-

sulated back into IPvX by an edge router. Tunneling

mechanisms are mainly confronted with fragmenta-

tion problems because of encapsulation.

In an attempt to compensate for the design sim-

plicity of the two IP versions, IPv6 transition tech-

nologies grew in complexity. Most of the modern

transition technologies use one or more basic tran-

sition technologies. For instance, Dual-Stack Lite

(DSLite)(Durand et al., 2011) used dual-stack and

translation at the edge nodes and encapsulation in the

core. Considering all of the above, a generic classiﬁ-

cation of the transition technologies can prove useful.

2.1 IPv6 Transition Technologies

Generic Categories

We can consider a basic production IP-based network

as being constructed using the following components:

• Customer Edge (CE) segment: connects the cus-

tomer network to the production network’s core.

• Core network segment: the main part of the pro-

duction network, which connects the CE and PE

segments.

• Provider Edge (PE) segment: connects the core

network to the up-link provider.

According to the technology used for the core net-

work traversal, the IPv6 transition technologies can be

categorized as follows:

1. Dual-stack: the core network devices implement

both IP protocols

2. Single translation: either IPv4 or IPv6 is used to

traverse the core network, and translation is used

at one of the edges

3. Double translation: a translation mechanism is

employed for the traversal of the core network;

CE nodes translate IPvX packets to IPvY packets

and PE nodes translate the packets back to IPvX.

4. Encapsulation: an encapsulation mechanism is

used to traverse the core network; CE nodes en-

capsulate the IPvX packets in IPvY packets, while

PE nodes are responsible for the decapsulation

process.

Table 1 shows how some of the existing IPv6 transi-

tion technologies can ﬁt into the generic categories.

3 RELATED WORK

Threat models have been proposed and used for the

security analysis of online applications for some time.

Probably the most popular is the one introduced in

(Hernan et al., 2006), more commonly known as

the STRIDE approach. At the heart of the pro-

posal is the STRIDE mnemonic, which stands for

Spooﬁng, Tampering, Repudiation, Information dis-

closure, Denial of service and Elevation of privilege,

a set of generic security threats. The mnemonic offers

a simple and comprehensible classiﬁcation base. Us-

ing STRIDE in conjuncture with a good understand-

ing of the system’s components, can result in a good

overview of the threats and possible mitigation direc-

tions. As a measure of its success, the STRIDE cate-

gories are used as well in (OWASP, 2015), the threat

ICISSP 2016 - 2nd International Conference on Information Systems Security and Privacy

244

Table 1: IPv6 transition technologies association.

Generic category IPv6 Transition Technology

1 Dual-stack Dual IP Layer Operations(Nordmark and Gilligan, 2005)

2 Single translation NAT64(Bagnulo et al., 2011), SIIT-DC(Anderson, 2015), SA46T-AT(Matsuhira, 2015), IVI(Li et al., 2011b)

3 Double translation 464XLAT(Mawatari et al., 2013), MAP-T(Li et al., 2015), dIVI(Bao et al., 2014)

4 Encapsulation DSLite(Durand et al., 2011), Lightweight 4over6(Tsou et al., 2015), MAP-E(Troan et al., 2015)

modeling process used by the Open Web Application

Security Project (OWASP). Furthermore, in (Gervais,

2012), the STRIDE approach has been used to model

the threats of industrial control systems.

As for the security of IP-based systems, there are

many articles in current literature dedicated to the is-

sues introduced by IPv4 and IPv6. In terms of IPv4

security, we have consulted the following references:

(Harris and Hunt, 1999), (Gont, 2011),(Low, 2001),

(Abad et al., 2007), (Khallouf et al., 2005). As for

IPv6 security, the following documents were very

helpful: (Davies et al., 2007), (Convery and Miller,

2004), (Pilihanto, 2011). These documents have done

a ﬁne job of documenting existing threats for the two

protocols and basic transition mechanisms. However,

a threat model for IPv6 transition technologies has not

emerged so far.

Threat modeling has proved useful for under-

standing the security of intricate systems. The main

reason is its structured approach, which allows one to

discover, categorize and classify the threats accord-

ing to their potential impact on the system. Consid-

ering the complicated nature of IPv6 transition tech-

nologies, threat modeling makes a good candidate for

better understanding their security implications. The

proposed model aims to open this path, which could

lead as well to a better understanding of the inner-

workings of IPv6 transition technologies.

4 THREAT MODEL

The proposed threat model involves a series of

steps which were inspired by the STRIDE model-

ing approach presented in (McRee, 2009) and the

Open Web Application Security Project (OWASP)

foundation’s application threat modeling guidelines

(OWASP, 2015). In the context of IPv6 transition

technologies we recommend the following steps.

(1) Establish the Function: the function of the

IPv6 transition technology needs to be clearly doc-

umented. Depending on the context, the technol-

ogy can incorporate multiple services, which need to

be clearly identiﬁed in order to perform an effective

threat analysis.

(2) Identify the IPv6 Transition Technology

Category: the category should be identiﬁed consid-

ering the generic classiﬁcation deﬁned in Section 2.1.

This step will help build the data ﬂow diagram (DFD)

used in the following steps.

(3) Decompose the Technology: build a data

ﬂow diagram (DFD) and highlight the entry points,

protected resources and trust boundaries. The entry

points should be assigned a level of trust consider-

ing the trust boundaries. The external entities, pro-

cess, data store and data ﬂow elements should be

depicted in the same diagram as deﬁned in (Hernan

et al., 2006). The IP protocol suite and the protocols

used for the designated function should be identiﬁed

as well. This can narrow down the attack surface.

(4) Identify the Threats: The STRIDE model as-

sociates the six categories of threats to each of the

elements described in the DFD. Based on this asso-

ciation, we get an initial assessment of the threats as

shown in Table 2. To clarify, a data ﬂow, for example,

is more susceptible to tampering, information disclo-

sure and denial of service threats. The initial threat

assessment must be followed by a detailed analysis

which should consider the protocols used in conjunc-

ture with the transition technology.

Considering the level of trust assigned to each en-

try point, an associated likelihood of attack from that

entry point can be deduced. For example, if the en-

try point is considered trusted, we can assume the

likelihood of an attack is low. By extrapolating, the

six categories of STRIDE attacks could be assigned

a likelihood, considering that their association with

the DFD elements that are entry points. For instance,

if we have an untrusted entry point which is also an

external entity, for which we can have spooﬁng and

repudiation as potential threats, the two types of at-

tacks can be considered to have a high likelihood, as

they would be exploited from an untrusted entry. Us-

ing this logic, by associating the detailed threats with

the STRIDE model and the DFD elements they could

be applied to, we can assign each threat a likelihood

value. This can represent a base for prioritizing mit-

igation solutions. Each discovered threat should be

documented by using the following format.

Field Name Description

Threat ID A code associated with each identiﬁed threat

Description A summarized description of the threat

STRIDE The association with the STRIDE categories

Mitigation Details about existing mitigation solutions

Likelihood Likelihood of the threat being exploited

Validation Empirical validation data

For an easy reference in future publications the

[Threat ID] should follow the format: [Code]-[First

The STRIDE Towards IPv6: A Comprehensive Threat Model for IPv6 Transition Technologies

245

Table 2: STRIDE threats per element.

Spooﬁng Tampering Repudiation Info Disclosure Denial of Service Elevation of Privilege

External

Process

Data Store †

Data Flow

Author Initials]-[Publication Submission Year]-

[Serial number]. For an author named John Doe,

who is submitting a publication proposal in 2015, an

example ThreatID is: IPv6-JD-2015-1. The serial

number is incremented with each threat found for

a particular protocol or technology. A list of codes

for the basic transition technologies and generic

transition technologies can be found in the Appendix,

Table 4. For the well-known TCP/IP protocol suite

we have used the usual acronyms as codes. As the

subcomponents interact and the used protocols stack,

the threats can fuse and result in convoluted threats

with a higher likelihood of exploitation. Depending

on the list of discovered threats, the possibility of a

fusion between threats should be analyzed.

(6) Review, Repeat and Validate: steps 1 and

3 have to be reviewed in the context of potential

changes in the technology function and associated

protocols. Step 4 should be repeated periodically, as

threats may have been overlooked, or the context set

by steps 1 and 3 may have changed. If the transition

technologies have existing implementations, the anal-

ysis should be conﬁrmed with empirical data. To that

end, penetration testing can be used.

In the following subsections, the proposed threat

modeling technique is used for the four generic IPv6

transition technologies categories deﬁned in Section

2.1. The threat models can be viewed as a starting

point for IPv6 transition technologies associated with

each category.

4.1 Dual-stack IPv6 Transition

Technologies

4.1.1 Establish the Function

The function for dual-stack transition technologies is

to ensure a safe data exchange over a dual-stack in-

frastructure. In other words, the data can be trans-

fered over both IPv4 and IPv6. From a network ser-

vice perspective, the main function is data forward-

ing. This includes interior gateway routing solutions.

We start with the assumption that services such as ad-

dress provision, DNS resolution or exterior gateway

routing are performed by other nodes within the core

network. This assumption in common for all the four

generic categories of IPv6 transition technologies.

External

entity

Proc

ess

Data store

Trust boundary

Customer

Device

Data over

IPvX/IPvY

Dual-stack

node

Data store

Customer side

Provider side

Production core

network

P - protected asset

E - entry point

P, E

X,Y

∈

Data flow

{4,6}

Data over

IPvX/IPvY

Data over

IPvX/IPvY

Data over

IPvX/IPvY

(a) Dual-stack

Customer

Device

Data over

IPvX

Trans

lator

Data store

Customer side

Provider side

Production core

network

P, E

Data over

IPvX

Data over

IPvY

Data over

IPvY

(b) Single translation

Customer

Device

Data over

IPvX

Trans

lator

Data store

Customer side

Provider side

Production core

network

P, E

Data over

IPvX

Data over

IPvX

Data over

IPvX

Trans

lator

P, E

Data over

IPvY

Data over

IPvY

Customer

Device

Data over

IPvX

Encap

sulator

Data store

Customer side

Provider side

Production core

network

P, E

Data over

IPvX

Data over

IPvX

Data over

IPvX

P, E

Data over

IPvY

Data over

IPvY

Decap

sulator

(d) Encapsulation

Figure 1: Data Flow Diagrams for the generic IPv6 transi-

tion technologies categories.

4.1.2 Identify the IPv6 Transition Technology

Category

This step is meant for more speciﬁc transition tech-

nologies. Since we are targeting the generic category

itself, the step is unnecessary here. This stands for the

other three categories as well.

4.1.3 Decompose the Technology

A DFD for dual-stack transition technologies is pre-

sented in Figure 1(a). The diagram represents the ba-

sic use case and includes a minimal set of elements.

On the customer side, we have a Customer Device

which initiates the data exchange. It represents one

of the entry points of the system and contains im-

ICISSP 2016 - 2nd International Conference on Information Systems Security and Privacy

246

v6 NIC

v4 NIC

Transl

192.168.1.0/24

2001:2:16a::/48

198.18.1.0/24

v4 NIC

v6 NIC

transl

asamap vyatta

NAPT44

Win8

Host

Ubuntu14.04

Server

Attacker

Kali Linux

asamap vyatta

Figure 2: MAP-T Penetration Testbed

portant data, which should be regarded as an asset

and protected. The Customer Device is regarded as

an external element because it is outside the control

zone of the production network. The data request is

transmitted over IPv4 or IPv6 to a Dual-stack node.

The Dual-stack node is another entry point and con-

tains valuable topology information which should to

be protected as well. The Dual-stack node forwards

in turn the data request to the provider data store. The

Data store is another entry point in the system and it

is assumed to contain valuable data. The data reply

is forwarded back and makes its return on the same

path.

The only trusted entry point in the system is the

Dual-stack node. The other two entry points are con-

sidered untrusted, since they are outside the control

of the production network.That means they can be ex-

ploited with a higher likelihood by an attacker. Con-

sidering the data can be transferred over both IPv4

and IPv6, we need to consider IP protocol suites. Fur-

thermore, the possibility of using security and routing

protocols should be considered.

4.1.4 Identify the Threats

By analyzing the DFD in association with the

STRIDE threats per element chart, we can observe

that the Customer Device can be subject to spooﬁng

and repudiation attacks. It being an untrusted entry

point, it means there is a high likelihood of an attack.

The Dual-stack node can be subject to all six types of

attacks. However, the likelihood of that happening is

low, considering it is a trusted entry point. The Data

ﬂow is vulnerable to tampering, information disclo-

sure and denial of service. Considering it traverses

untrusted parts of the system, the level of likelihood

of an attack on the data ﬂow is high. Lastly, the Data

store could potentially be targeted by tampering, re-

pudiation, information disclosure and denial of ser-

vice attacks. The likelihood for these to happen is

high as well, the data store being an untrusted entry

point.

Tables 5,7, 6, 8, 9 and 10 of the Appendix contain

a non-exhaustive collection of existing threats, which

have been collected by surveying a part of existing

literature on this subject. For further documentation,

each threat has been provided with a reference in the

ﬁrst column. For reuse purposes, the threats are orga-

nized according to the categories of protocols which

would be necessary for accomplishing the function of

the IPv6 transition technologies.

For dual-stack transition technologies the proto-

col threats associated with the IPv4 suite (Table 5),

IPv6 suite(Table 7), routing (Table 8) and switching

(Table 10) could potentially be exploited from the 3

entries of the system: the untrusted - High likeli-

hood of exploitation Customer device (External en-

tity), trusted - Low likelihood of exploitation Dual-

stack node (Process) and untrusted - High likelihood

of exploitation Provider Data store (data store).

The IPv4 suite, transport layer and most of the

IPv6 suite protocols are associated with all the ele-

ments of the DFD. By extrapolation, their threats have

a high likelihood of occurrence. Some of the IPv6

protocol threats (Table 7), namely ND-MG-2015-3 to

ND-MG-2015-6 and the Layer 2 technologies’ threats

(Table 10) can only be associated with routers or

switches. In this context, they could only be associ-

ated with the Dual-stack node. That means they have

a low likelihood of occurrence. Similarly, the routing

protocols can only be associated with the Dual-stack

node. By association, they also have a low likelihood

of being exploited.

By analyzing the interaction between the three el-

ements of the DFD (Figure 1(a)) and the protocols

used by Dual stack transition technologies, we can

uncover other threats. For example, if the ARP-MG-

2015-1(ARP cache poisoning) is used to perform a

Denial of Service attack on the Dual-stack node from

the Customer device, the likelihood of exploitation

rises for the ND-MG-2015-10 (ND Replay Attacks)

threats. Table 7. ARP-MG-2015-1 could be replaced

by any other DoS threat associated with the IPv4 suite

protocols. This complex threat could only be pre-

vented by ensuring that the IPv4 suite DoS threats are

properly mitigated. Examples of convoluted threats

for the four generic IPv6 transition technologies are

presented in Table 3.

Another convoluted threat can result from exploit-

ing IPv4 or IPv6 spooﬁng threats to increase the like-

lihood of an attack on routing protocols with sim-

ple authentication, such as or OSPFv3-MG-2015-1,

OSPFv2-MG-2015-1 or RIPv2-MG-2015-1. Since

the attack could be performed from an untrusted entry

point (Customer device or Data store), the likelihood

of the threat being exploited rises to High. This type

of attack can be mitigated by using cryptographic au-

thentication for the routing protocols.

The STRIDE Towards IPv6: A Comprehensive Threat Model for IPv6 Transition Technologies

247

Table 3: Generic IPv6 Transition Technologies Convoluted Threats.

ThreatID Description S T R I D E Mitigation Validation

Generic IPv6 Transition Technologies

1 DS -MG-2015-1 ARP-MG-2015-1 + ND -MG-2015-10 H H H H H

Ensure DoS mitigation for

IPv4 suite protocols; use SEND

2 DS-MG-2015-2 ARP-MG-2015-1 + OSPFv3-MG-1 H H H H H H Use OSPv3 with IPsec

3 1transl -MG-2015-1 IP/ICMP -MG-2015-3 + ND-MG-2015-5 H H H H No widely accepted mitigation X

4 1transl -MG-2015-2 TCP-MG-2015-1 + ND-MG-2015-10 H H H H H

Block packets with non-internal

addresses; use SEND

5 2transl -MG-2015-1 IP/ICMP -MG-2015-4 + ND -MG-2015-4 H H H H H No widely accepted mitigation X

6 2transl -MG-2015-2 IP/ICMP-MG-2015-4 + OSPFv3-MG-2015-1 H H H H H H OSPFv3 with IPsec

7 encaps -MG-2015-1 IPv6-MG-2015-1 + 4encaps -MG-2015-1 H H

Use IPv4 ﬁrewall before

decapsulating

Legend

L Associated with low likelihood of exploitation H Associated with high likelihood of exploitation

The list of threats can help technology implemen-

tors and network operators alike prioritize the threats

and mitigate accordingly. The protocols which have

threats with no widely accepted mitigation techniques

have been highlighted and should be treated as ﬁrst

priority.

4.1.5 Review, Repeat and Validate

This step is necessary if the technology analyzed or

associated protocols change. For example if the rout-

ing system were to be only OSPFv3, then the threats

associated with other routing protocols could be ig-

nored. Also, the detailed analysis of threats is far

from exhaustive. In terms of convoluted new threats,

only a few are presented as an example. If this

was to be an updated database of threats, it would

need constant update. To further validate the pre-

sented threats, a simple penetration testbed was built.

The details of the testbed are presented in Figure

2. MAP-T (Li et al., 2015) was used as transition

technology. Asamap (Asama, 2014), a transition im-

plementation developed in Japan, was used as the

base for MAP-T. The threats which were successfully

emulated, have been marked accordingly in the last

column of Table 3. In the case of the convoluted

threats identiﬁed for Dual-stack transition technolo-

gies, both threats were emulated successfully by per-

forming ARP Cache Spooﬁng, Neighbor Advertise-

ment (NA) ﬂooding and simple trafﬁc analysis.

4.2 Single Translation Transition

Technologies

To avoid redundant information, the following three

subsections will only mark the differences with the

threat modeling process presented for Dual-stack

transition technologies.

One of the fundamental differences is that the sin-

gle translation technologies would require a node to

algorithmically translate the IPvX packets to IPvY, as

shown in Figure 1(b). For both translation directions

(4 → 6 and 6 → 4) the threats for the IPv4 suite (Table

5), IPv6 suite (Table 7), routing (Table 8) and switch-

ing (Table 10) should be considered.

There are technologies that use stateful mapping

algorithms e.g. Stateful NAT64 (Bagnulo et al.,

2011), which create dynamic correlations between IP

addresses or {IP address, transport protocol, transport

port number} tuples. Consequently, we need to con-

sider the protocols used at the transport layer (Table

6) as part of the attack surface. The threats presented

in Table 9, associated with the IP/ICMP translation

algorithm (IP/ICMP), should be considered as well.

In terms of convoluted threats, one example could

be exploiting the IP/ICMP-MG-2015-3 threat (IPAuth

does not work with IP/ICMP) which would increase

the likelihood of ND-MG-2015-4 (Default router is

killed) or ND-MG-2015-5 (Good router goes bad)

threats being exploited. Since there is no widely-

accepted mitigation for any of the three threats, this

convoluted threat is laking a mitigation solution as

well. Fortunately, both complex threats could not

be validated empirically. An IPsec VPN connec-

tion was successfully established using UDP encap-

sulation between the Windows Host and the Ubuntu

Server. Moreover, the ND-MG-2015-4 and ND-MG-

2015-5 could not be validated empirically, as Asamap

(Asama, 2014) does not accept RA messages when

IPv6 forwarding is enabled.

If the TCP-MG-2015-1 threat (SYN ﬂood) is ex-

ploited from an untrusted entry point, it increases the

likelihood of a ND-MG-2015-10 (ND Replay attacks)

threat. This threat can be mitigated by blocking pack-

ets with non-internal addresses from leaving the net-

work. Both the SYN ﬂood attack and the Neigh-

bor Advertisement (NA) ﬂooding attacks were staged

successfully.

4.3 Double Translation Transition

Technologies

The main difference between the Single translation

case and the double translation case is the need for

ICISSP 2016 - 2nd International Conference on Information Systems Security and Privacy

248

an extra translation device as part of the core net-

work (Figure 1(c)). Another important difference

would be that in the untrusted zone, the Customer de-

vice and Data store would employ the same IP suite.

Hence, the considered threats for the untrusted ele-

ments would be either the IPv4 suite (Table 5) or the

IPv6 suite (Table 7) protocol threats. Similar to the

single translation technologies, the routing (Table 8),

switching (Table 10), transport layer (Table 6) and

IP/ICMP (Table 9) threats should be analyzed as well.

The use of stateful translation mechanisms can ex-

pose a double translation technology to the IP/ICMP-

MG-2015-4 threat (DoS by exhaustion of resources).

A convoluted threat can result by exploiting this threat

on one of the translators and the ND-MG-2015-4 or

ND-MG-2015-5 threats on the other translator. This

threat would have a higher likelihood of exploita-

tion since it is associated with an untrusted entry

point. In terms of mitigation, further investigation

is needed, as there are no widely accepted mitiga-

tion techniques. Although the IP/ICMP-MG-2015-

4 threat was replicated with success, the ND-MG-

2015-10 or ND-MG-2015-5 could not be emulated

because of a simple built-in mitigation mechanism

implemented by Asamap (Asama, 2014). Router ad-

vertisement (RA) messages are not accepted while in

IPv6 forwarding mode.

The IP/ICMP-MG-2015-4 threat can also fuse

with the simple authentication threats such as

OSPFv3-MG-2015-1 , OSPFv2-MG-2015-1 or

RIPv2-MG-2015-1 to affect both translating nodes.

The likelihood of the threats become higher by fusing

them, since the ﬂooding attack can be performed

from an untrusted entry point, the customer network.

This threat could be mitigated by using cryptographic

authentication or implementing reverse path checks.

The convoluted threat was validated by ﬂooding the

translation table of the ﬁrst translator and forcing it to

crash. OSPFv3 information disclosure was emulated

with simple trafﬁc analysis. To validate the other

types of threats, a rogue router instance was created

using Asamap.

4.4 Encapsulation Transition

Technologies

Similar to double translation IPv6 transition tech-

nologies, encapsulation technologies, the core net-

work trafﬁc is forwarded through at least two de-

vices, an Encapsulator and a Decapsulator (Figure

1(d)). As the main difference, the trafﬁc is encap-

sulated. This means more overhead but also more

support for end-to-end security protocols. Packets

are encapsulated either over IPv4 or IPv6. Conse-

quently, for the untrusted domain devices we would

consider either the IPv4 suite (Table 5) or the IPv6

suite (Table 7) threats. In addition the routing (Ta-

ble 8), switching (Table 10), transport layer (Table 6)

and encapsulation-related (Table 9) threats should be

considered.

Convoluted threats can arise by exploiting the

4encaps-MG-2015-1 threat (avoiding IPv4 network

security measures with encapsulation). This threat

can facilitate IPv6 suite DoS threats on the Decapsu-

lator device. This convoluted threat would increase

the likelihood of a successful DoS attack from the

Customer Device. The threat could be mitigated by

making use of an IPv4 ﬁrewall before decapsulating

the packets.

5 DISCUSSION

The security of IPv6 transition technologies, as the

technologies themselves, are hard to grasp and ana-

lyze. Although many documents have targeted dif-

ferent aspects of the security of these technologies,

a comprehensive threat model has not been proposed

yet. With this article, we want to take a ﬁrst step in

that direction. Our approach is built around the well-

established STRIDE model, which has proved to be

an adaptive tool for threat modeling. We have used

the proposed threat model to analyze the security is-

sues of the generic IPv6 transition technologies de-

ﬁned in Section 2.1.

One of the limitations of the proposed threat

model is the lack of speciﬁcity of the scenario. How-

ever, given the diversity of existing production net-

work this would be close to impossible. This is why

we targeted a very common use case of production

networks and a very basic network function for the

IPv6 transition technologies. The model is a starting

point, which we hope to keep developing in the future.

This hindrance can be extended to the generic

IPv6 transition technologies. However, by being in-

clusive, rather than speciﬁc and exclusive, we contend

that the proposed threat model can be applied to most

of the existing IPv6 transition technologies and their

future developments.

The use of STRIDE for IPv6 transition technolo-

gies can be another discussion point. One can claim

that Elevation of Privilege or Repudiation threats are

not exploitable at the level the transition technolo-

gies are used. However, we contend that these threats

are indeed plausible. For instance, by exploiting a

VLAN Hopping threat, an attacker can violate the

isolation principle and by extension perform an ele-

vation of privilege attack. In terms of repudiation, an

The STRIDE Towards IPv6: A Comprehensive Threat Model for IPv6 Transition Technologies

249

attacker could perform a router impersonation attack

and cover his tracks.

A more fundamental hindrance of the approach is

represented by the lack of an associated risk quantiﬁ-

cation step. However, we believe this step to have

deeper implications, particularly implementation-

speciﬁc details which should be considered as well.

This motivates us to continue this work by associat-

ing a risk quantiﬁcation technique to the current threat

model. To that end, staging penetration tests to em-

pirically validate the threats discovered analytically

could also be employed to quantify the risk associated

with particular implementations.

6 CONCLUSION

In this article, we have proposed a wide-ranging threat

model for IPv6 transition technologies. As part of

the contribution, this article also provides a mean to

generically classify IPv6 transition technologies. To

prove the adequacy of the proposed threat model, we

have used it to analyze the security threats of the four

generic categories of IPv6 transition technologies.

As part of the threat modeling process, for each

of the four categories we have deﬁned a common use

case, deconstructed the system using Data Flow Di-

agrams (DFDs), and obtained an initial overview of

the security threats by association with the STRIDE

approach. Subsequently, we have documented exist-

ing threats and mitigation solutions for the IP protocol

suites and basic transition technologies representing

dependencies of the system. The documented threats

have been mapped with the STRIDE elements identi-

ﬁed in the DFD, to obtain a rough likelihood for the

threats to be exploited. We have shown how existing

threats can lead to new threats by the interaction be-

tween subcomponents and various protocols. Lastly,

we have empirically validated some of the analyti-

cally discovered threats by building a simple penetra-

tion testbed.

As a summary, the proposed, holistic threat model

has revealed that the concerns related to the security

of IPv6 transition technologies are well-endowed. Al-

though it is too early to say that certain technologies

are more secure than others, we contend that the pro-

posed method can represent the basis for establishing

a methodology that can lead us there. As a general

observation for double translation and encapsulation

technologies, the lack of shared secrets between the

CE and PE devices can have serious consequences on

the core network exploit-ability.

The main contribution of this article is represented

by the proposed threat model. As shown, the threat

model can be used to classify and prioritize already

documented threats. Moreover the threat model can

help discover new threats and indicate their level of

mitigation. As a secondary contribution , this arti-

cle contains a non-exhaustive database of documented

threats associated with IP enabled devices. Moreover,

preliminary penetration test data was introduced for

one of the existing IPv6 transition implementations.

We contend that this approach can be the starting

point for analyzing the threats of speciﬁc IPv6 transi-

tion technologies. Moreover, we intend to extend this

work by proposing a risk quantiﬁcation technique,

which should lead to a security quantiﬁcation method

for IPv6 transition technologies. The ﬁrst steps in this

direction were taken by proposing penetration testing

as a validation technique. Although the presented data

is preliminary, we aim to continue this effort in future

work.

ACKNOWLEDGEMENTS

This research has been supported by the Strategic

International Collaborative R&D Promotion Project

of the Ministry of Internal Affairs and Commu-

nication, Japan, and by the European Union Sev-

enth Framework Programme (FP7/2007- 2013) under

grant agreement No. 608533 (NECOMA). The opin-

ions expressed in this paper are those of the authors

and do not necessarily reﬂect the views of the Min-

istry of Internal Affairs and Communications, Japan,

or of the European Commission.

REFERENCES

Abad, C. L., Bonilla, R., et al. (2007). An analysis on

the schemes for detecting and preventing arp cache

poisoning attacks. In Distributed Computing Sys-

tems Workshops, 2007. ICDCSW’07. 27th Interna-

tional Conference on, pages 60–60. IEEE.

Anderson, T. (2015). SIIT-DC: Stateless IP/ICMP Trans-

lation for IPv6 Data Centre Environments. draft-ietf-

v6ops-siit-dc-01.

APNIC (2015). IPv6 measurements for The World.

Arkko, J., Kempf, J., Zill, B., and Nikander, P. (2005). SE-

cure Neighbor Discovery (SEND). RFC 3971 (Pro-

posed Standard). Updated by RFCs 6494, 6495.

Asama, M. (2014). MAP supported Vyatta [Online]. Avail-

able: http://enog.jp/∼masakazu/vyatta/map/.

Atkinson, R. and Fanto, M. (2007). RIPv2 Cryptographic

Authentication. RFC 4822 (Proposed Standard).

Bagnulo, M., Matthews, P., and van Beijnum, I. (2011).

Stateful NAT64: Network Address and Protocol

Translation from IPv6 Clients to IPv4 Servers. RFC

6146 (Proposed Standard).

ICISSP 2016 - 2nd International Conference on Information Systems Security and Privacy

250

Baker, F., Li, X., Bao, C., and Yin, K. (2011). Framework

for IPv4/IPv6 Translation. RFC 6144 (Informational).

Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and Li,

X. (2010). IPv6 Addressing of IPv4/IPv6 Translators.

RFC 6052 (Proposed Standard).

Bao, C., Li, X., Zhai, Y., and Shang, W. (2014). dIVI: Dual-

Stateless IPv4/IPv6 Translation. draft-xli-behave-

divi-06.

Bellovin, S. M. (1989). Security problems in the tcp/ip

protocol suite. SIGCOMM Comput. Commun. Rev.,

19(2):32–48.

Conta, A. and Gupta, M. (2006). Internet control message

protocol (icmpv6) for the internet protocol version 6

(ipv6) speciﬁcation. RFC 4443 (Proposed standard).

Convery, S. and Miller, D. (2004). Ipv6 and ipv4 threat

comparison and best-practice evaluation.

Davies, E., Krishnan, S., and Savola, P. (2007).

IPv6 Transition/Co-existence Security Considera-

tions. RFC 4942 (Informational).

Durand, A., Droms, R., Woodyatt, J., and Lee, Y. (2011).

Dual-Stack Lite Broadband Deployments Following

IPv4 Exhaustion. RFC 6333 (Proposed Standard).

Garg, A. and Reddy, A. N. (2004). Mitigation of dos at-

tacks through qos regulation. Microprocessors and

Microsystems, 28(10):521–530.

Gervais, A. (2012). Security analysis of industrial control

systems. Aalto University-KTH Stockholm, Jun, 29.

Gont, F. (2011). Security assessment of the internet protocol

version 4. RFC 6274 (Informational).

Gupta, M. and Melam, N. (2006). Authentica-

tion/Conﬁdentiality for OSPFv3. RFC 4552 (Pro-

posed Standard).

Harris, B. and Hunt, R. (1999). Tcp/ip security threats

and attack methods. Computer Communications,

22(10):885–897.

Hernan, S., Lambert, S., Ostwald, T., and Shostack, A.

(2006). Threat modeling-uncover security design

ﬂaws using the stride approach. MSDN Magazine-

Louisville, pages 68–75.

Huston, G. (2015). IPv4 Address Report.

ITU-T (2013). ITU-T Rec. X.1037 (10/2013) IPv6 techni-

cal security guidelines. Recommendation X.1037.

Khallouf, Z., Roca, V., Moignard, R., and Loye, S. (2005).

A Filtering Approach for an IGMP Flooding Resilient

Infrastrcuture. 4th Conference on Security and Net-

work Architectures(SAR’05), Batz sur Mer, France.

Li, X., Bao, C., and Baker, F. (2011a). IP/ICMP Translation

Algorithm. RFC 6145 (Proposed Standard). Updated

by RFC 6791.

Li, X., Bao, C., Chen, M., Zhang, H., and Wu, J. (2011b).

The China Education and Research Network (CER-

NET) IVI Translation Design and Deployment for the

IPv4/IPv6 Coexistence and Transition. RFC 6219 (In-

formational).

Li, X., Bao, C., Dec, W., Troan, O., , Matsushima, S., Mu-

rakami, T., and Taylor, T. (2015). Mapping of Address

and Port using Translation (MAP-T). RFC 7599 (Pro-

posed Standard).

Low, C. (2001). Icmp attacks illustrated. SANS Institute

URL: http://rr. sans. org/threats/ICMP attacks. php

(12/11/2001).

Matsuhira, N. (2015). SA46T Address Translator. draft-

matsuhira-sa46t-at-05.

Mawatari, M., Kawashima, M., and Byrne, C. (2013).

464XLAT: Combination of Stateful and Stateless

Translation. RFC 6877.

McRee, R. (2009). IT Infrastructure Threat Modeling

Guide. Microsoft Technet.

Moy, J. (1998). OSPF Version 2. RFC 2328 (INTERNET

STANDARD). Updated by RFCs 5709, 6549, 6845,

6860.

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

Neighbor Discovery (ND) Trust Models and Threats.

RFC 3756 (Informational).

Nordmark, E. and Gilligan, R. (2005). Basic Transition

Mechanisms for IPv6 Hosts and Routers. RFC 4213

(Proposed Standard).

NRO (2014). Free Pool of IPv4 Address Space Depleted

[Online]. Available: http://www.nro.net/news/ipv4-

free-pool-depleted.

OWASP (2015). Application Threat Modeling. OWASP

Foundation.

Pilihanto, A. (2011). A complete guide on ipv6 attack and

defense. Sans. org [online].

Rouiller, S. A. (2003). Virtual lan security: weaknesses and

countermeasures. available at uploads. askapache.

com/2006/12/vlan-security-3. pdf.

Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., Mu-

rakami, T., and Taylor, T. (2015). Mapping of Address

and Port with Encapsulation (MAP-E). RFC 7597

(Proposed Standard).

Tsou, T., Cui, Y., Boucadair, M., Farrer, I., and Lee, Y.

(2015). Lightweight 4over6: An Extension to the

Dual-Stack Lite Architecture. RFC 7596 (Proposed

Standard).

APPENDIX

Table 4: ThreatID Codes.

Basic IPv6 transition technologies

IP/ICMP Translation Algorithm RFC6145 IP/ICMP

Encapsulation of

IPv6 in IPv4

RFC4213 4encaps

Generic IPv6 transition technologies

Dual Stack - DS

Single Translation - 1transl

Double Translation - 2transl

Encapsulation - encaps

The STRIDE Towards IPv6: A Comprehensive Threat Model for IPv6 Transition Technologies

251

Table 5: IPv4 suite protocols threats.

ThreatID Description S T R I D E

# #

O O O O O O

= = = =

IPv4 Suite Protocols

> > >

Mitigation

IPv4-MG-2015-1

(Harris and Hunt, 1999)

IP source address spooﬁng H H H H

Apply ACLs and ﬁlter source address

routed trafﬁc

IPv4-MG-2015-2

(Gont, 2011)

Malformed version ﬁeld H Version ﬁeld must be checked to be 4

IPv4-MG-2015-3

(Gont, 2011)

Packets with a forged DSCP

ﬁeld

H H Filter packets with unrecognized DSCP

IPv4-MG-2015-4

(Gont, 2011)

Buffer overﬂow with

IP fragmentation

IP module should implement measures to

avoid illegitimate reassembly

ICMP-MG-2015-1

(Harris and Hunt, 1999)

Ping o’death H

Patch software to not accept oversized

ICMP messages

ICMP-MG-2015-2

(Bellovin, 1989)

ICMP redirects H H H H H

routing tables should not be modiﬁed in

response to ICMP Redirect messages

ICMP-MG-2015-3

(Low, 2001)

ICMP sweep for recon H Selective ﬁltering of ICMP messages

ICMP-MG-2015-4

(Low, 2001)

ICMP traceroute H Selective ﬁltering of ICMP messages

ICMP-MG-2015-5

(Low, 2001)

ICMP ﬁrewalk H Selective ﬁltering of ICMP messages

ICMP-MG-2015-6

(Low, 2001)

ICMP ﬂooding H Selective ﬁltering of ICMP messages

ARP-MG-2015-1

(Abad et al., 2007)

ARP cache poisoning H H H H H Static ARP entries, arpwatch

ARP-MG-2015-2

(Gont, 2011)

ARP cache overrun H Selectively drop packets

IGMP-MG-2015-1

(Khallouf et al., 2005)

IGMP ﬂooding H

selective ﬁltering of IGMP messages,

multicast group authentication

Legend

associated with

High likelihood

# external, O process #

Untrusted element with High likelihood

of being exploited

associated with

Low likelihood

>data ﬂow, = data store O

Trusted element with Low likelihood

of being exploited

Table 6: Layer4 Protocols Threats.

ThreatID Description S T R I D E

# #

O O O O O O

= = = =

Transport Layer

Protocols

> > >

Mitigation

TCP-MG-2015-1

(Harris and Hunt, 1999)

SYN ﬂood H

Block packets with non-internal addresses

from leaving the network

TCP-MG-2015-2

(Harris and Hunt, 1999)

SYN/ACK ﬂood H H H L3/L4 Packet Filtering

TCP-MG-2015-3

(Harris and Hunt, 1999)

ACK or ACK-PUSH Flood H H H L3/L4 Packet Filtering

TCP-MG-2015-4

(Harris and Hunt, 1999)

Fragmented ACK Flood H L3/L4 Packet Filtering

TCP-MG-2015-5

(Harris and Hunt, 1999)

TCP Spooﬁng based on

sequence number prediction

Block packets with non-internal addresses

from leaving the network

TCP-MG-2015-6

(Harris and Hunt, 1999)

TCP session hijacking based

on sequence number prediction

H H H H H H

Block packets with non-internal addresses

from leaving the network

TCP-MG-2015-7

(Harris and Hunt, 1999)

RST and FIN DoS H

L3/L4 Packet Filtering;

Stateful Flow Awareness

UDP-MG-2015-8

(Garg and Reddy, 2004)

UDP ﬂood H QoS regulation; L3/L4 Packet Filtering

NAT44-MG-2015-9

(ITU-T, 2013)

Port set exaustion H Address-Dependent Filtering

ICISSP 2016 - 2nd International Conference on Information Systems Security and Privacy

252

Table 7: IPv6 suite protocols threats.

ThreatID Description S T R I D E

# #

O O O O O O

= = = =

IPv6 Suite

Protocols

> > >

Mitigation

IPv6-MG-2015-1

(Davies et al., 2007)

Routing header can be used to evade access

controls

H H

Access controls based on destination

addresses

IPv6-MG-2015-2

(Davies et al., 2007)

Site-scope multicast addresses for

reconnaissance

Drop packets with site-scope destination

addresses

IPv6-MG-2015-3

(Davies et al., 2007)

Anycast trafﬁc identiﬁcation for

reconnaissance

Restrict the use of outside anycast

services

IPv6-MG-2015-4

(Davies et al., 2007)

Extension headers excessive hop-by-hop

options

H Drop packets with unknown options

IPv6-MG-2015-5

(Davies et al., 2007)

Overuse of IPv6 router alert Option H

Filter externally generated Router

Alert packets

IPv6-MG-2015-6

(Davies et al., 2007)

IPv6 fragmentation that would potentially

overload the reconstruction buffers

Mandating the size of packet fragments;

drop non-ﬁnal fragments smaller

than 640 octets

IPv6-MG-2015-7

(Davies et al., 2007)

IPv4-Mapped IPv6 Addresses H H

Avoid using IPv4-mapped IPv6

addesses

ICMPv6-MG-2015-1

(Conta and Gupta, 2006)

ICMPv6 message spooﬁng H H Use IPAuth

ICMPv6-MG-2015-2

(Conta and Gupta, 2006)

ICMPv6 Redirects H H H Use IPAuth or ESP

ICMPv6-MG-2015-3

(Conta and Gupta, 2006)

Back-to-back erroneous IP packets H

Implement correctely ICMP error rate

limiting mechanism

ICMPv6-MG-2015-4

(Conta and Gupta, 2006)

Send ICMP Parameter Problem

Message to the multicast source

H H Secure multicast trafﬁc

ICMPv6-MG-2015-5

(Conta and Gupta, 2006)

ICMP messages passed to the

upper-layers

H Use IPSec

ICMPv6-MG-2015-6

(Pilihanto, 2011)

ICMPv6 echo request

for reconnaissance

H Deny inbound ICMPv6 echo request

SLAAC-MG-2015-1

(Davies et al., 2007)

Address Privacy Extensions Interact

with DDoS Defenses

Tune the change rate of the

node address

ND-MG-2015-1

(Nikander et al., 2004)

Neighbor Solicitation/Advertisement

Spooﬁng

H H Use SEND

ND-MG-2015-2

(Nikander et al., 2004)

Neighbor Unreachability Detection

(NUD) failure

H Use SEND

ND-MG-2015-3

(Nikander et al., 2004)

Malicious Last Hop Router L L L L L Use SEND

ND-MG-2015-4

(Nikander et al., 2004)

Default router is ’killed’ L L L L L

No widely accepted mitigation

technique

ND-MG-2015-5

(Nikander et al., 2004)

Good Router Goes Bad L L L L L

No widely accepted mitigation

technique

ND-MG-2015-6

(Nikander et al., 2004)

Spoofed Redirect Message L L L L L

Use SEND;

Still an issue for the ad-hoc case

ND-MG-2015-7

(Nikander et al., 2004)

Bogus On-Link Preﬁx L Use SEND

ND-MG-2015-8

(Nikander et al., 2004)

Bogus Address Conﬁguration Preﬁx L

Use SEND;

Still an issue for the ad-hoc case

ND-MG-2015-9

(Nikander et al., 2004)

Parameter Spooﬁng L L L

Use SEND;

Still an issue for the ad-hoc case

ND-MG-2015-10

(Nikander et al., 2004)

ND Replay attacks H H

Use roughly synchronized clocks

and timestamps; Use SEND

ND-MG-2015-11

(Nikander et al., 2004)

Neighbor Discovery DoS threat H Rate limit Neighbor Solicitations

DAD-MG-2015-1

(Nikander et al., 2004)

Duplicate Address Detection DoS H Use SEND

SEND-MG-2015-1

(Arkko et al., 2005)

The Authorization Delegation Discovery

process may be vulnerable to DoS

Cache discovered information and limit

the number of discovery processes

MIPv6-MG-2015-1

(Davies et al., 2007)

Obsolete Home Address Option

in Mobile IPv6

H Secure Binding Update messages

Legend

associaced with

High likelihood

# external, O process #

Untrusted element with High likelihood

of being exploited

associated with

High likelihood

>data ﬂow, = data store O

Trusted element with Low likelihood

of being exploited

The STRIDE Towards IPv6: A Comprehensive Threat Model for IPv6 Transition Technologies

253

Table 8: Routing Protocols threats.

ThreatID Description S T R I D E

# #

O O O O O O

= = = =

Routing Protocols

> > >

Mitigation

RIPv2-MG-2015-1

(Atkinson and Fanto, 2007)

RIPv2 simple password authentication

issues

L L L L L L Use cryptographic authentication

RIPv2-MG-2015-2

(Atkinson and Fanto, 2007)

RIPv2 Security Association expiration L

Let RIPv2 routing fail when the last

key expires

RIPv2-MG-2015-3

(Atkinson and Fanto, 2007)

RIPv2 Security Association L

The receiver should not try all RIPv2

Security Associations

OSPFv2-MG-2015-1

(Moy, 1998)

OSPFv2 simple password authentication L L L L L L Use cryptographic authentication

OSPFv2-MG-2015-2

(Moy, 1998)

OSPFv2 cryptographic authentication

sequence number prediction

L L L L L L Use cryptographic sequence number

OSPFv3-MG-2015-1

(Gupta and Melam, 2006)

OSPFv3 using the same manual key L L L L L L avoid using manual keys

Legend

associaced with

High likelihood

# external, O process #

Untrusted element with High likelihood

of being exploited

associaced with

Low likelihood

>data ﬂow, = data store O

Trusted element with Low likelihood

of being exploited

Table 9: Basic IPv6 Transition Technologies Threats.

ThreatID Description S T R I D E

# #

O O O O O O

= = = =

Routing Protocols

> > >

Mitigation

IP/ICMP-MG-2015-1

(Bao et al., 2010)

IPv4 address spooﬁng with

IPv4-embedded IPv6

Implement reverse path checks to verify

that packets are coming from an authorized location.

IP/ICMP-MG-2015-2

(Li et al., 2011a)

transport mode ESP will fail with

IPv6-to-IPv4 translation

L Use checksum-neutral addresses

IP/ICMP-MG-2015-3

(Li et al., 2011a)

Authentication Headers cannot be used

across an IPv6-to-IPv4

L No widely accepted mitigation

IP/ICMP-MG-2015-4

(Li et al., 2011a)

Stateful translators can run out

of resources

L No widely accepted mitigation

4encaps-MG-2015-1

(Davies et al., 2007)

Tunneling IPv6 through IPv4 networks

could break IPv4 Network’s security assumptions

route the encapsulated through an IPv4

ﬁrewall before decapsulating them

Table 10: L2 Technologies Threats.

ThreatID Description S T R I D E

# #

O O O O O O

= = = =

L2 Technologies

> > >

Mitigation

VLAN-MG-2015-1

(ITU-T, 2013)

Exhaust a forwarding information base (FIB)

of an L2switch

L IEEE 802.1x authentication

VLAN-MG-2015-2

(Rouiller, 2003)

Content Addressable Memory (CAM) Overﬂow L

Use the port-security

features

VLAN-MG-2015-3

(Rouiller, 2003)

Basic VLAN Hopping L Software update

VLAN-MG-2015-4

(Rouiller, 2003)

Double encapsulation VLAN Hopping L L Disable Auto-trunking

VLAN-MG-2015-5

(Rouiller, 2003)

Spanning Tree Attack L L Disable STP, Use BPDU Guard

ICISSP 2016 - 2nd International Conference on Information Systems Security and Privacy

254