Internet DRAFT - draft-georgescu-opsec-ipv6-trans-tech-threat-model
draft-georgescu-opsec-ipv6-trans-tech-threat-model
Internet Engineering Task Force M. Georgescu, Ed.
Internet-Draft NAIST
Intended status: Informational March 21, 2016
Expires: September 22, 2016
The STRIDE towards IPv6: A Threat Model for IPv6 Transition Technologies
draft-georgescu-opsec-ipv6-trans-tech-threat-model-00
Abstract
This document provides a structured approach for analyzing the
threats associated with the various IPv6 transition technologies
specified by the IETF. The threat model is built around the
established STRIDE threat classification and is aimed at existing
IPv6 transition technologies, as well as their future developments.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 22, 2016.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Georgescu Expires September 22, 2016 [Page 1]
Internet-Draft IPv6 Trans Tech Threat Model March 2016
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. The Generic Categories of IPv6 Transition Technologies . . . 3
4. Building The Threat Model . . . . . . . . . . . . . . . . . . 4
4.1. Establish the function . . . . . . . . . . . . . . . . . 4
4.2. Identify the generic category . . . . . . . . . . . . . . 4
4.3. Decompose the technology . . . . . . . . . . . . . . . . 4
4.4. Identify the threats . . . . . . . . . . . . . . . . . . 5
4.4.1. STRIDE-DFD Assoctiation . . . . . . . . . . . . . . . 5
4.4.2. Level of Trust . . . . . . . . . . . . . . . . . . . 6
4.4.3. Documenting the Threats . . . . . . . . . . . . . . . 6
4.4.4. Complex Threats . . . . . . . . . . . . . . . . . . . 7
4.5. Review, Repeat and Validate . . . . . . . . . . . . . . . 7
5. Dual Stack Threat Model . . . . . . . . . . . . . . . . . . . 8
5.1. Establish the Function . . . . . . . . . . . . . . . . . 8
5.2. Identify the Generic Category . . . . . . . . . . . . . . 8
5.3. Decompose the Technology . . . . . . . . . . . . . . . . 8
5.4. Identify the threats . . . . . . . . . . . . . . . . . . 9
5.4.1. STRIDE-DFD Assoctiation . . . . . . . . . . . . . . . 9
5.4.2. From Trust to Likelihood . . . . . . . . . . . . . . 10
5.4.3. Documenting the Threats . . . . . . . . . . . . . . . 10
5.4.4. Complex Threats . . . . . . . . . . . . . . . . . . . 11
5.5. Review, Repeat and Validate . . . . . . . . . . . . . . . 12
6. Single Translation Threat Model . . . . . . . . . . . . . . . 13
6.1. Decompose the Technology . . . . . . . . . . . . . . . . 13
6.2. Identify the threats . . . . . . . . . . . . . . . . . . 14
7. Double Translation Threat Model . . . . . . . . . . . . . . . 15
7.1. Decompose the Technology . . . . . . . . . . . . . . . . 15
7.2. Identify the threats . . . . . . . . . . . . . . . . . . 15
8. Encapsulation Threat Model . . . . . . . . . . . . . . . . . 16
8.1. Decompose the Technology . . . . . . . . . . . . . . . . 16
8.2. Identify the threats . . . . . . . . . . . . . . . . . . 17
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
11. Security Considerations . . . . . . . . . . . . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
12.1. Normative References . . . . . . . . . . . . . . . . . . 18
12.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Appendix A . . . . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction
When building an IPv6 transition plan, security is arguably one of
the biggest concerns for network operators, as a heterogeneous IPv4
and IPv6 environment greatly increases the attack surface. To that
Georgescu Expires September 22, 2016 [Page 2]
Internet-Draft IPv6 Trans Tech Threat Model March 2016
end, building a threat model for IPv6 transition technologies can
help clarify and categorize the associated security threats. In
turn, this should facilitate the search for mitigation solutions.
The security considerations of IPv6 transition technologies has
generally been analyzed in each of the corresponding specifications,
and some documents have discussed the general threats associated with
transition technologies (see e.g. [RFC4942]).
However, more structured threat modeling has proved useful for
understanding the security of intricate systems. Structured
approachesallows one to discover, categorize and classify the threats
according to their potential impact on the system. Considering the
complicated nature of IPv6 transition technologies, threat modeling
makes a good candidate for better understanding their security
implications. This document follows a structured approach for
analyzing the threats asociated with transition technologies, that
considers the functions of a transition technology as well as the
cntext in which the technology is used.
The threat model uses the established STRIDE mnemonic and threat
classification. STRIDE stands for Spoofing, Tampering, Repudiation,
Information Disclosure, Denial of service and Elevation of Privilege,
a generic list of threats which can be used to classify various
threats and provides some basic mitigation directions. Since similar
transition technologies can be associated with a similar list of
threats, the document considers the generic classification of IPv6
transition technologies described in [draft-bmwg-v6trans].
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. The Generic Categories of IPv6 Transition Technologies
Table 1 presents the generic categories described in
[draft-bmwg-v6trans] and some sample IPv6 transition technologies
specified by the IETF.
Georgescu Expires September 22, 2016 [Page 3]
Internet-Draft IPv6 Trans Tech Threat Model March 2016
Table 1. IPv6 Transition Technologies Categories
+---+--------------------+------------------------------------+
| | Generic category | IPv6 Transition Technology |
+---+--------------------+------------------------------------+
| 1 | Dual-stack | Dual IP Layer Operations [RFC4213] |
+---+--------------------+------------------------------------+
| 2 | Single translation | NAT64 [RFC6146], IVI [RFC6219] |
+---+--------------------+------------------------------------+
| 3 | Double translation | 464XLAT [RFC6877], MAP-T [RFC7599] |
+---+--------------------+------------------------------------+
| 4 | Encapsulation | DSLite [RFC6333], MAP-E [RFC7597] |
| | | Lightweight 4over6 [RFC7596] |
| | | 6RD [RFC5569] |
+---+--------------------+------------------------------------+
4. Building The Threat Model
To build a threat model for IPv6 transition technologies a series of
steps is recommended. These steps are detailed in the following
subsections.
4.1. Establish the function
The function of the IPv6 transition technology needs to be clearly
documented. Depending on the context, the technology can incorporate
multiple services, which need to be clearly identified in order to
perform an effective threat analysis.
4.2. Identify the generic category
The category should be identified considering the generic
classification defined in Section 3. This step can help reuse the
threat analysis data for technologies which are part of the same
category.
4.3. Decompose the technology
Build a data flow diagram (DFD) and highlight the entry points,
protected resources and trust boundaries. The entry points should be
assigned a level of trust considering the trust boundaries.
The external entities, process, data store and data flow elements
should be depicted in the same diagram. The IP protocol suite and
the protocols used for the designated function should be identified
as well. This can narrow down the attack surface.
Figure 1 presents the basic elements of a data flow diagram as well
as general rules for their association with network elements.
Georgescu Expires September 22, 2016 [Page 4]
Internet-Draft IPv6 Trans Tech Threat Model March 2016
+----------+
| External | Represents a network node which is outside
| Entity | the control of a network provider
+----------+
___
,' `. Represents a middle-box or a network node
| Pro | which processes network data
\ cess/
`---'
============
Data store Represents a node where data is stored
============
Data Flow
------------> Data exchanged between network elements
Trust
() The border which marks the part of the
() network considered outside the control
() of a network provider
boundary
Figure 1. DFD Elements
4.4. Identify the threats
4.4.1. STRIDE-DFD Assoctiation
The STRIDE model associates the six categories of threats to each of
the elements described in the DFD. Based on this association, we get
an initial assessment of the threats as shown in Table 2. To
clarify, a data flow, for example, is susceptible to tampering,
information disclosure and denial of service threats. The initial
threat assessment must be followed by a detailed analysis which
should consider the protocols used in conjuncture with the transition
technology.
Georgescu Expires September 22, 2016 [Page 5]
Internet-Draft IPv6 Trans Tech Threat Model March 2016
Table2. DFD-STRIDE Associations
+----+---+---+---+---+---+
| S | T | R | I | D | E |
+----+---+---+---+---+---+
| # | | # | | | |
+----+---+---+---+---+---+
| O | O | O | O | O | O |
+----+---+---+---+---+---+
| | = | = | = | = | |
+----+---+---+---+---+---+
| | > | | > | > | |
+----+---+---+---+---+---+
| # | External entity |
+----+-------------------+
| O | Process |
+----+-------------------+
| = | Data store |
+----+-------------------+
| > | Data flow |
+----+-------------------+
4.4.2. Level of Trust
We associate a level of trust with each entry point. Entry points
that are trusted are assumed to behave as expected. That is, if the
entry point is considered trusted, we can assume the likelihood of an
attack is low. Furthermore, the six categories of STRIDE attacks
could be assigned a likelihood by considering their association with
the DFD elements that are entry points.
For instance, let's suppose we have an untrusted entry point (High
likelihood of exploitation) which is also an external entity.
Spoofing and repudiation are potential threats for an external
entity. By association, the two types of attacks can be considered
to have a high likelihood of being exploited. Using this logic, we
can assign a likelihood value to each found threat. This can
represent a base for prioritizing mitigation solutions. The
likelihood levels can be defined in accordance with the levels of
trust assigned to the the entry points.
4.4.3. Documenting the Threats
Each discovered threat should be documented using the format
presented in Table 3.
Georgescu Expires September 22, 2016 [Page 6]
Internet-Draft IPv6 Trans Tech Threat Model March 2016
Table2. Threat Info Format
+-------------+-----------------------------------------------+
| Field Name | Description |
+-------------+-----------------------------------------------+
| Threat-ID | A code associated with each identified threat |
+-------------+-----------------------------------------------+
| Description | A summarized description of the threat |
+-------------+-----------------------------------------------+
| STRIDE | The association with the STRIDE categories |
+-------------+-----------------------------------------------+
| Mitigation | Details about possible mitigation solutions |
+-------------+-----------------------------------------------+
| Likelihood | Likelihood of the threat being exploited |
+-------------+-----------------------------------------------+
| Validation | Empirical validation data |
+-------------+-----------------------------------------------+
The Threat-ID is supposed to be an easy way to refer and identify the
threat within the IETF. The tentative format is IETF-TDB-[associated
protocol/technology]-[serial number]. IETF-TDB stands for IETF
Threat Database in the hope that in the future a threat database will
be maintained within the IETF. The serial number is incremented with
each threat found for a particular protocol or technology.
4.4.4. Complex Threats
As the subcomponents and subprotocols interact, 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.
4.5. 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 analysis should be
confirmed with empirical data.
The next sections applied the proposed threat modeling approach to
the IPv6 transition technologies identified in Section 3.
Georgescu Expires September 22, 2016 [Page 7]
Internet-Draft IPv6 Trans Tech Threat Model March 2016
5. Dual Stack Threat Model
5.1. Establish the Function
The function for dual-stack transition technologies is to ensure a
safe data exchange over a dual-stack infrastructure. In other words,
the data can be transfered over both IPv4 and IPv6. From a network
service perspective, the main function is data forwarding. This
includes interior gateway routing solutions. We start with the
assumption that services such as address 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.
5.2. Identify the Generic Category
Since we are targeting the generic category itself, the step is
unnecessary here. This stands for the other three categories as
well.
5.3. Decompose the Technology
A DFD for dual-stack transition technologies is presented in
Figure 2. The diagram represents a basic use case and includes a
minimal set of elements.
Domain A-DS Core ___ Domain Domain B-DS
+----------+ ( ,' `. ) ============
| Customer |-----(------->| DS |------- )---> Provider
| Device |<----(-------- \ node/<--------)---- Data Store
+----------+ ( `---' IPv4/IPv6) ============
E P E P E P
________________________________________________________________________
Legend ___ Trust
+----------+ ,' `. ============ Data Flow () E=Entry
| External | | Pro | Data store ------------> () point
| Entity | \ cess/ ============ () P=Protected
+----------+ `---' boundary
Figure 2. Data Flow Diagram (DFD) for Dual Stack (DS) technologies
In Domain A, which is assumed to be 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 important 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 assumed network provider. The data request is
transmitted over IPv4 or IPv6 to a Dual-stack node.
Georgescu Expires September 22, 2016 [Page 8]
Internet-Draft IPv6 Trans Tech Threat Model March 2016
The Dual-stack node is another entry point and contains valuable
topology information which should to protected as well. The Dual-
stack node forwards in turn the data request to the provider data
store. The Data store is the last entry point in the system and it
is assumed to contain valuable data. The data reply is forwarded
back to the customer device.
The only trusted entry point in the system is the Dual-stack node.
The other two entry points are considered untrusted, since they are
outside the control of the production network.That means they can be
exploited with a higher likelihood by an attacker.
Considering the data can be transferred over both IPv4 and IPv6, we
need to consider both IP protocol suites. Furthermore, the
possibility of using security and routing protocols should be
considered.
5.4. Identify the threats
5.4.1. STRIDE-DFD Assoctiation
By analyzing the DFD in association with the STRIDE threats per
element chart, we can make the associations depicted in Table 3.
Table3. DFD-STRIDE Associations DS
+----+---+---+---+---+---+
| S | T | R | I | D | E |
+----+---+---+---+---+---+
|#-H | |#-H| | | |
+----+---+---+---+---+---+
| O-L|O-L|O-L|O-L|O-L|O-L|
+----+---+---+---+---+---+
| |=-H|=-H|=-H|=-H| |
+----+---+---+---+---+---+
| |>-H| |>-H|>-H| |
+----+---+---+---+---+---+
| # | Customer device |
+----+-------------------+
| O | DS node |
+----+-------------------+
| = |Provider data store|
+----+-------------------+
| > | Data flow |
+----+-------------------+
Georgescu Expires September 22, 2016 [Page 9]
Internet-Draft IPv6 Trans Tech Threat Model March 2016
5.4.2. From Trust to Likelihood
Looking at the associations in Table 3, The Customer Device can be
subject to spoofing and repudiation attacks. It being an untrusted
entry point, that means there is a high likelihood of an attack.
This is marked in Table 3 with H.
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 flow is vulnerable to tampering, information disclosure and
denial of service. Considering it traverses untrusted parts of the
system, the level of likelihood of an attack on the data flow is
high.
Lastly, the Data store could potentially be targeted by tampering,
repudiation, information disclosure and denial of service attacks.
The likelihood for these to happen is high as well, the data store
being an untrusted entry point.
5.4.3. Documenting the Threats
The Tables 5-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 first column. For
reuse purposes, the threats are organized 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 protocol threats
associated with the IPv4 suite (Table 6), IPv6 suite(Table 7),
routing (Table 10) and switching (Table 5) could potentially be
exploited from the 3 entries of the system: the untrusted (High
likelihood of exploitation) Customer device, the trusted (Low
likelihood of exploitation) Dual-stack node (Process) and untrusted
(High likelihood of exploitation) Provider Data store.
The IPv4 suite, transport layer and most of the IPv6 suite protocols
are associated with all the elements of the DFD. By extrapolation,
their threats have a high likelihood of occurrence. Some of the IPv6
protocol threats (Table 7), namely IETF-TDB-ND-3 to IETF-TDB-ND-6 and
the Layer 2 technologies' threats (Table 5) can only be associated
with routers or switches. In the context of the DFD, they could only
be associated with the Dual-stack node. That means they have a low
likelihood of occurrence. Similarly, the routing protocols
Georgescu Expires September 22, 2016 [Page 10]
Internet-Draft IPv6 Trans Tech Threat Model March 2016
(Table 10) can only be associated with the Dual-stack node. By
association, they also have a low likelihood of being exploited.
5.4.4. Complex Threats
By analyzing the interaction between the three elements of the DFD
and the protocols used by Dual stack transition technologies, we can
uncover other threats. For example, if the IETF-TDB-ARP-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 IETF-TDB-ND-10 (ND Replay Attacks) threats. IETF-TDB-
ARP-1 could be replaced by any other DoS threat associated with the
IPv4 protocol suite. This complex threat could be prevented 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 4.
Table4. Complex Threats
+---+------------+-------------+---+---+---+---+---+---+--------------+
| | ThreatID | Description | S | T | R | I | D | E | Mitigation |
+---+------------+-------------+---+---+---+---+---+---+--------------+
| 1 | IETF-TDB | IETF-TDB | H | H | H | H | H | | |
| V | -DS-1 | -ARP-1 | | | | | | | DoS |
| | | + | | | | | | | Mitigation |
| | | IETF-TDB | | | | | | | for |
| | | -ND-4 | | | | | | | IPv4 suite |
+---+------------+-------------+---+---+---+---+---+---+--------------+
| 2 | IETF-TDB | IETF-TDB | H | H | H | H | H | H | Crypto |
| V | -DS-2 | -ARP-1 | | | | | | | authen |
| | | + | | | | | | | |
| | | IETF-TDB | | | | | | | |
| | | -OSPFv3-1 | | | | | | | |
+---+------------+-------------+---+---+---+---+---+---+--------------+
| 3 | | IETF-TDB | H | | H | H | H | | No widely |
| X | IETF-TDB | IP/ICMP-3 | | | | | | | accepted |
| | -1transl-1 | + | | | | | | | mitigation |
| | | IETF-TDB | | | | | | | |
| | | -ICMPv6-1 | | | | | | | |
+---+------------+-------------+---+---+---+---+---+---+--------------+
| 4 | IETF-TDB | IETF-TDB | H | H | H | H | H | | Block |
| V | -1transl-2 | -TCP-1 | | | | | | | non-internal |
| | | + | | | | | | | traffic |
| | | IETF-TDB | | | | | | | |
| | | -ND-4 | | | | | | | |
+---+------------+-------------+---+---+---+---+---+---+--------------+
| 5 | | IETF-TDB | L | L | L | L | L | | No widely |
| X | IETF-TDB | -IP/ICMP-4 | | | | | | | accepted |
Georgescu Expires September 22, 2016 [Page 11]
Internet-Draft IPv6 Trans Tech Threat Model March 2016
| | -2transl-1 | + | | | | | | | mitigation |
| | | IETF-TDB | | | | | | | |
| | | -ND-4 | | | | | | | |
+---+------------+-------------+---+---+---+---+---+---+--------------+
| 6 | IETF-TDB | IETF-TDB | L | L | L | L | L | L | reverse |
| V | -2transl_2 | -IP/ICMP-1 | | | | | | | path |
| | | + | | | | | | | checks |
| | | IETF-TDB | | | | | | | |
| | | -OSPFv3-1 | | | | | | | |
+---+------------+-------------+---+---+---+---+---+---+--------------+
| 7 | | IETF-TDB | | | | H | H | | IPv4 |
| | IETF-TDB | -IPv6-1 | | | | | | | firewall |
| | -encaps-1 | + | | | | | | | before |
| | | IETF-TDB | | | | | | | decaps |
| | | -4encaps_1 | | | | | | | |
+---+------------+-------------+---+---+---+---+---+---+--------------+
| Legend | |
+---------------+-----------------------------------------------------+
| H | associaced with | | L | associaced with |
| | High likelihood | | | Low likelihood |
+---+----------------------------+-------+---+------------------------+
Another convoluted threat can result from exploiting IPv4 or IPv6
spoofing threats to increase the likelihood of an attack on routing
protocols with simple authentication, such as or IETF-TDB-OSPFv3-1,
IETF-TDB-OSPFv2-1 or IETF-TDB-RIPv2-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
authentication for the routing protocols.
The list of threats can help technology implementors and network
operators alike prioritize the threats and mitigate accordingly.
5.5. Review, Repeat and Validate
This step is necessary if the technology analyzed or associated
protocols change. For example if the routing system were to be only
OSPFv3, then the threats associated with other routing protocols
could be ignored. 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 presented threats, a simple penetration
testbed was built. The details of the testbed are presented in
Figure 3. MAP-T [RFC7599] was used as transition technology. Asamap
[asamap2014], a transition implementation developed in Japan, was
Georgescu Expires September 22, 2016 [Page 12]
Internet-Draft IPv6 Trans Tech Threat Model March 2016
used as the base for MAP-T. The threats which were successfully
emulated, have been marked accordingly in the first column of
Table 4. In the case of the convoluted threats identified for Dual-
stack transition technologies, both threats were emulated
successfully by performing ARP Cache Spoofing, Neighbor Advertisement
(NA) flooding and simple traffic analysis.
+----------+
+---------+---------------+ Kali |
|---------|+--------------> Attacker |
|| || +---+^-----+
|| || ||
|| || ___ || __
+--v-------+ || ( ,' `. || ,' `. ) ============
| Win8 +-+|--(---->+ amap +-+|->+ amap +-----)-----> Ubuntu
| Host <--+--(-----+\ CE /<--+--+\ BR /<-----)-----+ Server
+----------+ ( `+-+' IPvY `+-+' IPvX ) ============
E P E P E P E P
Figure 3. Pentestbed Setup
6. Single Translation Threat Model
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 single translation
technologies would require a node to algorithmically translate the
IPvX packets to IPvY, as shown in Figure 4.
6.1. Decompose the Technology
A DFD for single translation transition technologies is presented in
Figure 4. The diagram represents a basic use case and includes a
minimal set of elements.
Georgescu Expires September 22, 2016 [Page 13]
Internet-Draft IPv6 Trans Tech Threat Model March 2016
Domain A-IPvX Core___ Domain Domain B-IPvY
+----------+ IPvX ( ,' `. IPvY ) ============
| Customer |------(------>| Tra |------- )---> Provider
| Device |<-----(------- \ nsl /<--------)---- Data Store
+----------+ IPvX ( `---' IPvY ) ============
E P E P E P
________________________________________________________________________
Legend ___ Trust
+----------+ ,' `. ============ Data Flow () E=Entry
| External | | Pro | Data store ------------> () point
| Entity | \ cess/ ============ () P=Protected
+----------+ `---' boundary
Figure 4. DFD for 1transl technologies
6.2. Identify the threats
For both translation directions 4->6 and 6->4, the threats for the
IPv4 suite (Table 6), IPv6 suite (Table 7), routing (Table 10) and
switching (Table 5) should be considered. There are technologies
that use stateful mapping algorithms e.g. Stateful NAT64 [RFC6146],
which create dynamic correlations between IP addresses or {IP
address, transport protocol, transport port number} tuples.
Consequently, we need to consider the protocols used at the transport
layer (Table 9) as part of the attack surface. The threats presented
in Table X, 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
IETF-TDB-IP/ICMP-3 threat (IPAuth does not work with IP/ICMP) which
would increase the likelihood of IETF-TDB-ND-4 (Default router is
killed) or IETF-TDB-ND-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 connection was successfully
established using UDP encapsulation between the Windows Host and the
Ubuntu Server. Moreover, the IETF-TDB-ND-4 and IETF-TDB-ND-5 could
not be validated empirically, as Asamap [asamap2014] does not accept
RA messages when IPv6 forwarding is enabled.
If the IETF-TDB-TCP-1 threat (SYN flood) is exploited from an
untrusted entry point, it increases the likelihood of a IETF-TDB-
ND-10 (ND Replay attacks) threat. This threat can be mitigated by
blocking packets with non-internal addresses from leaving the
network. Both the SYN flood attack and the Neighbor Advertisement
(NA) flooding attacks were staged successfully.
Georgescu Expires September 22, 2016 [Page 14]
Internet-Draft IPv6 Trans Tech Threat Model March 2016
7. Double Translation Threat Model
The main difference between the Single translation case and the
double translation case is the need for an extra translation device
as part of the core network (Figure 5). Another important difference
would be that in the untrusted zone, the Customer device and Data
store would employ the same IP suite.
7.1. Decompose the Technology
A DFD for double translation transition technologies is presented in
Figure 5. The diagram represents a basic use case and includes a
minimal set of elements.
Domain A-IPvX ___ Core Dom ___ Domain B-IPvX
+----------+ IPvX( ,' `. IPvY ,' `. ) ============
| Customer |-----(-----| Tra |---->| Tra |---- )-----> Provider
| Device |<----(------\ nsl /<------\ nsl /<-----)------ Data Store
+----------+ ( `---' IPvY `---' IPvX ) ============
E P E P E P E P
_____________________________ _________________________________________
Legend ___ Trust
+----------+ ,' `. ============ Data Flow () E=Entry
| External | | Pro | Data store ------------> () point
| Entity | \ cess/ ============ () P=Protected
+----------+ `---' boundary
Figure 5. DFD for 2transl technologies
7.2. Identify the threats
The considered threats for the untrusted elements would be either the
IPv4 suite (Table 6) or the IPv6 suite (Table 7) protocol threats.
Similar to the single translation technologies, the routing
(Table 10), switching (Table 5), transport layer (Table 9) and IP/
ICMP (Table 8) threats should be analyzed as well.
The use of stateful translation mechanisms can expose a double
translation technology to the IETF-TDB-IP/ICMP-4 threat (DoS by
exhaustion of resources). A convoluted threat can result by
exploiting this threat on one of the translators and the IETF-TDB-
ND-4 or IETF-TDB-ND-5 threats on the other translator. This threat
would have a higher likelihood of exploitation since it is associated
with an untrusted entry point. In terms of mitigation, further
investigation is needed, as there are no widely accepted mitigation
techniques. Although the IETF-TDB-IP/ICMP-4 threat was replicated
with success, the IETF-TDB-ND-10 or IETF-TDB-ND-5 could not be
emulated because of a simple built-in mitigation mechanism
Georgescu Expires September 22, 2016 [Page 15]
Internet-Draft IPv6 Trans Tech Threat Model March 2016
implemented by Asamap [asamap2014]. Router advertisement (RA)
messages are not accepted while in IPv6 forwarding mode.
The IETF-TDB-IP/ICMP-4 threat can also fuse with the simple
authentication threats such as IETF-TDB-OSPFv3-1 , IETF-TDB-OSPFv2-1
or IETF-TDB-RIPv2-1 to affect both translating nodes. The likelihood
of the threats become higher by fusing them, since the flooding
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 flooding the translation table of the first
translator and forcing it to crash. OSPFv3 information disclosure
was emulated with simple traffic analysis. To validate the other
types of threats, a rogue router instance was created using Asamap
[asamap2014].
8. Encapsulation Threat Model
Similar to double translation IPv6 transition technologies,
encapsulation technologies, the core network traffic is forwarded
through at least two devices, an Encapsulator and a Decapsulator
(Figure 6). As the main difference, the traffic is encapsulated.
This means more overhead but also more support for end-to-end
security protocols. Packets are encapsulated either over IPv4 or
IPv6.
8.1. Decompose the Technology
A DFD for encapsulation transition technologies is presented in
Figure 6. The diagram represents a basic use case and includes a
minimal set of elements.
Domain A-IPvX ___ Core Dom ___ Domain B-IPvX
+----------+ IPvX( ,' `. IPvY ,' `. ) ============
| Customer |-----(-----| Enc |---->| Dec |---- )-----> Provider
| Device |<----(------\ aps /<------\ aps /<-----)------ Data Store
+----------+ ( `---' IPvY `---' IPvX ) ============
E P E P E P E P
_______________________________________________________________________
Legend ___ Trust
+----------+ ,' `. ============ Data Flow {) E=Entry
| External | | Pro | Data store ------------> {) point
| Entity | \ cess/ ============ {) P=Protected
+----------+ `---' boundary
Figure 6. DFD for encaps technologies
Georgescu Expires September 22, 2016 [Page 16]
Internet-Draft IPv6 Trans Tech Threat Model March 2016
8.2. Identify the threats
For the untrusted domain devices we would consider either the IPv4
suite (Table 6) or the IPv6 suite (Table 7) threats. In addition the
routing (Table 10), switching (Table 5), transport layer (Table 9)
and encapsulation-related (Table 8) threats should be considered.
Convoluted threats can arise by exploiting the IETF-TDB-4encaps-1
threat (avoiding IPv4 network security measures with encapsulation).
This threat can facilitate IPv6 suite DoS threats on the Decapsulator
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 firewall before decapsulating the
packets.
9. Acknowledgments
This document was derrived from a template contributed by the xml2rfc
project.
10. IANA Considerations
This memo includes no request to IANA.
All drafts are required to have an IANA considerations section (see
Guidelines for Writing an IANA Considerations Section in RFCs
[RFC5226] for a guide). If the draft does not require IANA to do
anything, the section contains an explicit statement that this is the
case (as above). If there are no requirements for IANA, the section
will be removed during conversion into an RFC by the RFC Editor.
11. Security Considerations
This memo attempts to build a threat model for IPv6 transition
technologies. The author would like to encourage the use of a
similar threat modeling approach when writing the security
considerations of standards developed in the IETF. To be more
concrete the following steps could be reused:
R1 Identify the function
R2 Associate the technology with a generic category (if any)
R3 Decompose the technology
R4 Identify the threats
R5 Review, repeat and validate
Georgescu Expires September 22, 2016 [Page 17]
Internet-Draft IPv6 Trans Tech Threat Model March 2016
12. References
12.1. Normative References
[draft-bmwg-v6trans]
Georgescu, M. and G. Lencse, "Benchmarking Methodology for
IPv6 Transition Technologies", 2015,
<https://tools.ietf.org/html/draft-ietf-bmwg-ipv6-tran-
tech-benchmarking-01>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/
Co-existence Security Considerations", RFC 4942,
DOI 10.17487/RFC4942, September 2007,
<http://www.rfc-editor.org/info/rfc4942>.
12.2. Informative References
[arps] Abad, C. and R. Bonilla, "An analysis on the schemes for
detecting and preventing ARP cache poisoning attacks",
2007.
[asamap2014]
Asama, M., "MAP supported Vyatta", 2014,
<http://enog.jp/~masakazu/vyatta/map/>.
[bellovin89]
Bellovin, S., "Security Problems in the TCP/IP Protocol
Suite", 1989.
[harris99]
Harris, B. and R. Hunt, "TCP/IP security threats and
attack methods", 1999.
[icmps] Low, C., "ICMP attacks illustrated", 2001.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998,
<http://www.rfc-editor.org/info/rfc2328>.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
DOI 10.17487/RFC2629, June 1999,
<http://www.rfc-editor.org/info/rfc2629>.
Georgescu Expires September 22, 2016 [Page 18]
Internet-Draft IPv6 Trans Tech Threat Model March 2016
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<http://www.rfc-editor.org/info/rfc3552>.
[RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6
Neighbor Discovery (ND) Trust Models and Threats",
RFC 3756, DOI 10.17487/RFC3756, May 2004,
<http://www.rfc-editor.org/info/rfc3756>.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971,
DOI 10.17487/RFC3971, March 2005,
<http://www.rfc-editor.org/info/rfc3971>.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213,
DOI 10.17487/RFC4213, October 2005,
<http://www.rfc-editor.org/info/rfc4213>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", RFC 4443,
DOI 10.17487/RFC4443, March 2006,
<http://www.rfc-editor.org/info/rfc4443>.
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality
for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006,
<http://www.rfc-editor.org/info/rfc4552>.
[RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic
Authentication", RFC 4822, DOI 10.17487/RFC4822, February
2007, <http://www.rfc-editor.org/info/rfc4822>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd)", RFC 5569, DOI 10.17487/RFC5569,
January 2010, <http://www.rfc-editor.org/info/rfc5569>.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
DOI 10.17487/RFC6052, October 2010,
<http://www.rfc-editor.org/info/rfc6052>.
Georgescu Expires September 22, 2016 [Page 19]
Internet-Draft IPv6 Trans Tech Threat Model March 2016
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011,
<http://www.rfc-editor.org/info/rfc6145>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <http://www.rfc-editor.org/info/rfc6146>.
[RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The
China Education and Research Network (CERNET) IVI
Translation Design and Deployment for the IPv4/IPv6
Coexistence and Transition", RFC 6219,
DOI 10.17487/RFC6219, May 2011,
<http://www.rfc-editor.org/info/rfc6219>.
[RFC6274] Gont, F., "Security Assessment of the Internet Protocol
Version 4", RFC 6274, DOI 10.17487/RFC6274, July 2011,
<http://www.rfc-editor.org/info/rfc6274>.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011,
<http://www.rfc-editor.org/info/rfc6333>.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation",
RFC 6877, DOI 10.17487/RFC6877, April 2013,
<http://www.rfc-editor.org/info/rfc6877>.
[RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.
Farrer, "Lightweight 4over6: An Extension to the Dual-
Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596,
July 2015, <http://www.rfc-editor.org/info/rfc7596>.
[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
Murakami, T., and T. Taylor, Ed., "Mapping of Address and
Port with Encapsulation (MAP-E)", RFC 7597,
DOI 10.17487/RFC7597, July 2015,
<http://www.rfc-editor.org/info/rfc7597>.
[RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S.,
and T. Murakami, "Mapping of Address and Port using
Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July
2015, <http://www.rfc-editor.org/info/rfc7599>.
[sws] Rouiller, S., "Virtual LAN Security: weaknesses and
countermeasures", 2003.
Georgescu Expires September 22, 2016 [Page 20]
Internet-Draft IPv6 Trans Tech Threat Model March 2016
[udps] Garg, A. and A. Reddy, "Mitigation of DoS attacks through
QoS regulation", 2004.
[x1037] ITU-T, "IPv6 technical security guidelines. Recommendation
X.1037", 2013, <https://www.itu.int/rec/T-REC-X.1037/en>.
Appendix A. Appendix A
Table5. L2 Technologies Threats
+---+----------+---------------+---+---+---+---+---+---+------------+
| | ThreatID | Description | S | T | R | I | D | E | Mitigation |
+---+----------+---------------+---+---+---+---+---+---+------------+
| 1 | | Exhaust | | | | | L | | IEEE |
| | IETF-TDB | a the FIB | | | | | | | 802.1x |
| | -VLAN-1 | of an | | | | | | | authen |
| | [x1037] | L2switch | | | | | | | tication |
+---+----------+---------------+---+---+---+---+---+---+------------+
| 2 | | | | | | | L | | port |
| | IETF-TDB | CAM | | | | | | | -security |
| | -VLAN-2 | Overflow | | | | | | | features |
| | [sws] | | | | | | | | |
+---+----------+---------------+---+---+---+---+---+---+------------+
| 3 | IETF-TDB | Basic | L | | | | | | Software |
| | -VLAN-3 | VLAN | | | | | | | update |
| | [sws] | Hopping | | | | | | | |
+---+----------+---------------+---+---+---+---+---+---+------------+
| 4 | IETF-TDB | Double | L | | | | | L | Disable |
| | -VLAN-4 | encapsulation | | | | | | | Auto |
| | [sws] | VLAN | | | | | | | -trunking |
| | | Hopping | | | | | | | |
+---+----------+---------------+---+---+---+---+---+---+------------+
| 5 | IETF-TDB | Spanning | | | | L | L | | Disable |
| | -VLAN-5 | Tree | | | | | | | STP; |
| | [sws] | Attack | | | | | | | BPDU |
| | | | | | | | | | Guard |
+---+----------+---------------+---+---+---+---+---+---+------------+
| Legend | |
+---------------+---------------------------------------------------+
| H | associaced with | | L | associaced with |
| | High likelihood | | | Low likelihood |
+---+----------------------------+-------+---+----------------------+
Table6. IPv4 Protocol Suite Threats
+----+--------------+------------+---+---+---+---+---+---+------------+
| | ThreatID | Description| S | T | R | I | D | E | Mitigation |
+----+--------------+------------+---+---+---+---+---+---+------------+
Georgescu Expires September 22, 2016 [Page 21]
Internet-Draft IPv6 Trans Tech Threat Model March 2016
| 1 | IETF-TDB | IP source | H | H | H | H | | | Apply |
| | -IPv4-1 | address | | | | | | | ACLs |
| | [harris99] | spoofing | | | | | | | filter |
| | | | | | | | | | source |
| | | | | | | | | | address |
| | | | | | | | | | traffic |
+----+--------------+------------+---+---+---+---+---+---+------------+
| 2 | IETF-TDB | Mal | | H | | | | | Version |
| | -IPv4-2 | formed | | | | | | | checked |
| | [RFC6274] | version | | | | | | | to be 4 |
| | | field | | | | | | | |
| | | | | | | | | | |
+----+--------------+------------+---+---+---+---+---+---+------------+
| 3 | IETF-TDB | forged | H | | | | H | | Filter |
| | -IPv4-3 | DSCP | | | | | | | unrecogn |
| | [RFC6274] | field | | | | | | | ized |
| | | | | | | | | | DSCP |
+----+--------------+------------+---+---+---+---+---+---+------------+
| 4 | IETF-TDB | Buffer | | | | | H | | avoid |
| | -IPv4-4 | overflow | | | | | | | illegit |
| | [RFC6274] | IP frag | | | | | | | imate |
| | | mentation | | | | | | | re |
| | | | | | | | | | assembly |
+----+--------------+------------+---+---+---+---+---+---+------------+
| 5 | IETF-TDB | Ping | | | | | H | | do not |
| | -ICMP-1 | o'death | | | | | | | accept |
| | [harris99] | | | | | | | | oversized |
| | | | | | | | | | ICMP |
+----+--------------+------------+---+---+---+---+---+---+------------+
| 6 | IETF-TDB | ICMP | H | H | H | H | H | | don't |
| | -ICMP-2 | redirects | | | | | | | update |
| | [bellovin89] | | | | | | | | routing |
| | | | | | | | | | tables |
| | | | | | | | | | with |
| | | | | | | | | | ICMP |
| | | | | | | | | | Redirects |
+----+--------------+------------+---+---+---+---+---+---+------------+
| 7 | IETF-TDB | ICMP | | | | H | | | Selective |
| | -ICMP-3 | sweep | | | | | | | filtering |
| | [icmps] | for recon | | | | | | | of ICMP |
| | | | | | | | | | |
+----+--------------+------------+---+---+---+---+---+---+------------+
| 8 | IETF-TDB | ICMP | | | | | H | | Selective |
| | -ICMP-6 | flooding | | | | | | | filtering |
| | [icmps] | | | | | | | | of ICMP |
+----+--------------+------------+---+---+---+---+---+---+------------+
| 9 | IETF-TDB | ARP | H | H | H | H | H | | Static |
| | -ARP-1 | cache | | | | | | | ARP |
Georgescu Expires September 22, 2016 [Page 22]
Internet-Draft IPv6 Trans Tech Threat Model March 2016
| | [arps] | poisoning | | | | | | | entries, |
| | | | | | | | | | arpwatch |
+----+--------------+------------+---+---+---+---+---+---+------------+
| 10 | IETF-TDB | ARP | | | | | H | | Selective |
| | -ARP-2 | cache | | | | | | | drop of |
| | [RFC6274] | overrun | | | | | | | packets |
| | | | | | | | | | |
+----+--------------+------------+---+---+---+---+---+---+------------+
Table7. IPv6 Protocol Suite Threats
+----+-----------+---------------+---+---+---+---+---+---+------------+
| | ThreatID | Description | S | T | R | I | D | E | Mitigation |
+----+-----------+---------------+---+---+---+---+---+---+------------+
| 1 | IETF-TDB | Routing | H | | | | H | | Access |
| | -IPv6-1 | header | | | | | | | controls |
| | [RFC4942] | to evade | | | | | | | based on |
| | | access | | | | | | | destination|
| | | controls | | | | | | | addresses |
+----+-----------+---------------+---+---+---+---+---+---+------------+
| 2 | IETF-TDB | Site-scope | | | | H | | | Drop |
| | -IPv6-2 | multicast | | | | | | | packets |
| | [RFC4942] | addresses | | | | | | | with |
| | | reconnaiss | | | | | | | site-scope |
| | | ance | | | | | | | destination|
| | | | | | | | | | addresses |
+----+-----------+---------------+---+---+---+---+---+---+------------+
| 3 | IETF-TDB | Anycast | | | | H | | | Restrict |
| | -IPv6-3 | traffic | | | | | | | outside |
| | [RFC4942] | identification| | | | | | | anycast |
| | | reconnaiss | | | | | | | services |
| | | ance | | | | | | | |
+----+-----------+---------------+---+---+---+---+---+---+------------+
| 4 | IETF-TDB | Extension | | | | | H | | Drop |
| | -IPv6-4 | headers | | | | | | | packets |
| | [RFC4942] | excessive | | | | | | | with |
| | | hop-by-hop | | | | | | | unknown |
| | | options | | | | | | | options |
+----+-----------+---------------+---+---+---+---+---+---+------------+
| 5 | IETF-TDB | Overuse | | | | | H | | Filter |
| | -IPv6-5 | of IPv6 | | | | | | | externally |
| | [RFC4942] | router alert | | | | | | | generated |
| | | Option | | | | | | | Router |
| | | | | | | | | | Alert |
| | | | | | | | | | packets |
+----+-----------+---------------+---+---+---+---+---+---+------------+
| 6 | IETF-TDB | IPv6 | | | | | H | | Mandating |
| | -IPv6-6 | fragmentation | | | | | | | the |
Georgescu Expires September 22, 2016 [Page 23]
Internet-Draft IPv6 Trans Tech Threat Model March 2016
| | [RFC4942] | overload of | | | | | | | size of |
| | | reconstruct | | | | | | | packet |
| | | buffers | | | | | | | fragments |
+----+-----------+---------------+---+---+---+---+---+---+------------+
| 7 | IETF-TDB | IPv4-Mapped | H | | | | H | | Avoid |
| | -IPv6-7 | IPv6 | | | | | | | IPv4 |
| | [RFC4942] | Addresses | | | | | | | -mapped |
| | | | | | | | | | IPv6 |
| | | | | | | | | | addesses |
+----+-----------+---------------+---+---+---+---+---+---+------------+
| 8 | IETF-TDB | ICMPv6 | H | | | | H | | IPAuth |
| | -ICMPv6-1 | spoofing | | | | | | | |
| | [RFC4443] | | | | | | | | |
+----+-----------+---------------+---+---+---+---+---+---+------------+
| 9 | IETF-TDB | ICMPv6 | H | | H | H | | | IPAuth |
| | -ICMPv6-2 | Redirects | | | | | | | or ESP |
| | [RFC4443] | | | | | | | | |
+----+-----------+---------------+---+---+---+---+---+---+------------+
| 10 | IETF-TDB | Back-to | | | | | H | | ICMP |
| | -ICMPv6-3 | -back | | | | | | | error |
| | [RFC4443] | erroneous | | | | | | | rate |
| | | IP packets | | | | | | | limiting |
+----+-----------+---------------+---+---+---+---+---+---+------------+
| 11 | IETF-TDB | Send ICMP | | | | H | H | | Secure |
| | -ICMPv6-4 | Parameter | | | | | | | multicast |
| | [RFC4443] | Problem | | | | | | | traffic |
| | | to multicast | | | | | | | |
| | | source | | | | | | | |
+----+-----------+---------------+---+---+---+---+---+---+------------+
| 12 | IETF-TDB | ICMP | | | | | H | | IPSec |
| | -ICMPv6-5 | passed to | | | | | | | |
| | [RFC4443] | upper-layers | | | | | | | |
+----+-----------+---------------+---+---+---+---+---+---+------------+
| 14 | | Address | | | | | H | | Tune |
| | IETF-TDB | Privacy | | | | | | | the change |
| | -SLAAC-1 | Extensions | | | | | | | rate of the|
| | [RFC4942] | Interaction | | | | | | | node |
| | | with DDoS | | | | | | | address |
| | | Defenses | | | | | | | |
+----+-----------+---------------+---+---+---+---+---+---+------------+
| 15 | IETF-TDB | NS/NA | H | | | | H | | SEND |
| | -ND-1 | Spoofing | | | | | | | |
| | [RFC3756] | | | | | | | | |
+----+-----------+---------------+---+---+---+---+---+---+------------+
| 16 | IETF-TDB | NUD | | | | | H | | SEND |
| | -ND-2 | failure | | | | | | | |
| | [RFC3756] | | | | | | | | |
+----+-----------+---------------+---+---+---+---+---+---+------------+
Georgescu Expires September 22, 2016 [Page 24]
Internet-Draft IPv6 Trans Tech Threat Model March 2016
| 17 | IETF-TDB | Malicious | | | L | L | L | | SEND |
| | -ND-3 | Last Hop | | | | | | | |
| | [RFC3756] | Router | | | | | | | |
+----+-----------+---------------+---+---+---+---+---+---+------------+
| 18 | IETF-TDB | Default | | | L | L | L | | No widely |
| | -ND-4 | router | | | | | | | accepted |
| | [RFC3756] | is 'killed' | | | | | | | mitigation |
| | | | | | | | | | technique |
+----+-----------+---------------+---+---+---+---+---+---+------------+
| 19 | IETF-TDB | Good | | | L | L | L | | No widely |
| | -ND-5 | Router | | | | | | | accepted |
| | [RFC3756] | Goes Bad | | | | | | | mitigation |
| | | | | | | | | | technique |
+----+-----------+---------------+---+---+---+---+---+---+------------+
| 20 | IETF-TDB | Spoofed | | | L | L | L | | SEND; |
| | -ND-6 | Redirect | | | | | | | Still an |
| | [RFC3756] | Message | | | | | | | issue for |
| | | | | | | | | | ad-hoc |
| | | | | | | | | | cases |
+----+-----------+---------------+---+---+---+---+---+---+------------+
| 21 | IETF-TDB | Bogus | | | | | L | | SEND |
| | -ND-7 | On-Link | | | | | | | |
| | [RFC3756] | Prefix | | | | | | | |
+----+-----------+---------------+---+---+---+---+---+---+------------+
| 22 | IETF-TDB | Bogus | | | | | L | | SEND; |
| | -ND-8 | Address | | | | | | | Still an |
| | [RFC3756] | Config | | | | | | | issue for |
| | | Prefix | | | | | | | ad-hoc |
| | | | | | | | | | cases |
+----+-----------+---------------+---+---+---+---+---+---+------------+
| 23 | IETF-TDB | Parameter | L | | L | L | | | SEND; |
| | -ND-9 | Spoofing | | | | | | | Still an |
| | [RFC3756] | | | | | | | | issue for |
| | | | | | | | | | ad-hoc |
| | | | | | | | | | cases |
+----+-----------+---------------+---+---+---+---+---+---+------------+
| 24 | IETF-TDB | ND Replay | H | | | H | | | SEND |
| | -ND-10 | attacks | | | | | | | |
| | [RFC3756] | | | | | | | | |
+----+-----------+---------------+---+---+---+---+---+---+------------+
| 25 | IETF-TDB | Neighbor | | | | | H | | Rate limit |
| | -ND-11 | Discovery | | | | | | | NS |
| | [RFC3756] | DoS | | | | | | | messsages |
+----+-----------+---------------+---+---+---+---+---+---+------------+
| | IETF-TDB | | | | | | | | |
| 26 | DAD_1 | DAD | | | | | H | | SEND |
| | [RFC3756] | DoS | | | | | | | |
+----+-----------+---------------+---+---+---+---+---+---+------------+
Georgescu Expires September 22, 2016 [Page 25]
Internet-Draft IPv6 Trans Tech Threat Model March 2016
| 27 | IETF-TDB | Authorization | | | | | H | | Cache |
| | -SEND-1 | Delegation | | | | | | | discovered |
| | [RFC3971] | Discovery | | | | | | | information|
| | | DoS | | | | | | | and limit |
| | | | | | | | | | the number |
| | | | | | | | | | of |
| | | | | | | | | | discovery |
| | | | | | | | | | processes |
+----+-----------+---------------+---+---+---+---+---+---+------------+
| 28 | IETF-TDB | Obsolete | H | | | | | | Secure |
| | -MIPv6-1 | Home | | | | | | | Binding |
| | [RFC4942] | Address | | | | | | | Update |
| | | Option | | | | | | | messages |
| | | Mobile | | | | | | | |
| | | IPv6 | | | | | | | |
+----+-----------+---------------+---+---+---+---+---+---+------------+
Georgescu Expires September 22, 2016 [Page 26]
Internet-Draft IPv6 Trans Tech Threat Model March 2016
Table8. Basic Transition Technologies Threats
+---+------------+--------------+---+---+---+---+---+---+-------------+
| | ThreatID | Description | S | T | R | I | D | E | Mitigation |
+---+------------+--------------+---+---+---+---+---+---+-------------+
| 1 | IETF-TDB- | IPv4 | L | | | | | | Implement |
| | IP/ICPM-1 | spoofing | | | | | | | reverse |
| | [RFC6052] | with | | | | | | | path |
| | | IPv4 | | | | | | | checks |
| | | -embedded | | | | | | | |
| | | IPv6 | | | | | | | |
+---+------------+--------------+---+---+---+---+---+---+-------------+
| 2 | IETF-TDB | ESP | | | | L | | | Use |
| | -IP/ICMP-2 | fails | | | | | | | checksum |
| | [RFC6145] | with | | | | | | | -neutral |
| | | IPv6 | | | | | | | addresses |
| | | -to- | | | | | | | |
| | | IPv4 | | | | | | | |
| | | translation | | | | | | | |
+---+------------+--------------+---+---+---+---+---+---+-------------+
| 3 | IETF-TDB | Auth | | | | L | | | No widely |
| | -IP/ICMP-3 | Headers | | | | | | | accepted |
| | [rfc6145] | cannot | | | | | | | mitigation |
| | | be used | | | | | | | |
| | | across | | | | | | | |
| | | IPv6- | | | | | | | |
| | | to-IPv4 | | | | | | | |
+---+------------+--------------+---+---+---+---+---+---+-------------+
| 4 | IETF-TDB | Stateful | | | | | L | | No widely |
| | -IP/ICMP-4 | translators | | | | | | | accepted |
| | [RFC6145] | resources | | | | | | | mitigation |
| | | exhaustion | | | | | | | |
+---+------------+--------------+---+---+---+---+---+---+-------------+
| 5 | 4encaps_1 | Tunneling | | | | L | | | route |
| | [RFC4942] | IPv6 over | | | | | | | encaps |
| | | IPv4 breaks | | | | | | | traffic |
| | | IPv4 | | | | | | | through |
| | | Network's | | | | | | | IPv4 |
| | | security | | | | | | | firewall |
| | | assumptions | | | | | | | before |
| | | | | | | | | | decaps |
+---+------------+--------------+---+---+---+---+---+---+-------------+
Table9. L4 Technologies Threats
+---+-----------------+-----------+---+---+---+---+---+---+-----------+
| | ThreatID |Description| S | T | R | I | D | E | Mitigation|
+---+-----------------+-----------+---+---+---+---+---+---+-----------+
Georgescu Expires September 22, 2016 [Page 27]
Internet-Draft IPv6 Trans Tech Threat Model March 2016
| 1 | IETF-TDB | SYN | | | | | H | | Block |
| | -TCP-1 | flood | | | | | | | non- |
| | [harris99] | | | | | | | | internal |
| | | | | | | | | | addresses |
| | | | | | | | | | from |
| | | | | | | | | | leaving |
+---+-----------------+-----------+---+---+---+---+---+---+-----------+
| 2 | IETF-TDB | SYN | H | | H | | H | | L3/L4 |
| | -TCP-2 | /ACK | | | | | | | Packet |
| | [harris99] | flood | | | | | | | Filtering |
+---+-----------------+-----------+---+---+---+---+---+---+-----------+
| 3 | IETF-TDB | ACK or | H | | H | | H | | L3/L4 |
| | -TCP-3 | ACK | | | | | | | Packet |
| | [harris99] | -PUSH | | | | | | | Filtering |
| | | Flood | | | | | | | |
+---+-----------------+-----------+---+---+---+---+---+---+-----------+
| 4 | IETF-TDB | Frag | | | | | H | | L3/L4 |
| | -TCP-4 | mented | | | | | | | Packet |
| | [harris99] | ACK | | | | | | | Filtering |
| | | Flood | | | | | | | |
+---+-----------------+-----------+---+---+---+---+---+---+-----------+
| 5 | IETF-TDB | TCP | H | | | | | | Block |
| | -TCP-5 | Spoofing | | | | | | | non |
| | [harris99] | sequence | | | | | | | -internal |
| | | number | | | | | | | traffic |
| | | prediction| | | | | | | from |
| | | | | | | | | | leaving |
+---+-----------------+-----------+---+---+---+---+---+---+-----------+
| 6 | IETF-TDB | TCP | H | H | H | H | H | H | Block |
| | -TCP-6 | session | | | | | | | non |
| | [harris99] | hijacking | | | | | | | -internal |
| | | sequence | | | | | | | traffic |
| | | number | | | | | | | from |
| | | prediction| | | | | | | leaving |
+---+-----------------+-----------+---+---+---+---+---+---+-----------+
| 7 | IETF-TDB | RST | | | | | H | | L3/L4 |
| | -TCP-7 | and | | | | | | | Packet |
| | [harris99] | FIN | | | | | | | Filtering;|
| | | DoS | | | | | | | Stateful |
| | | | | | | | | | Flow |
| | | | | | | | | | Awareness |
+---+-----------------+-----------+---+---+---+---+---+---+-----------+
| 8 | IETF-TDB | UDP | | | | | H | | QoS |
| | -UDP-8 | flood | | | | | | | regulation|
| | [udps] | | | | | | | | L3/L4 |
| | | | | | | | | | Packet |
| | | | | | | | | | Filtering |
+---+-----------------+-----------+---+---+---+---+---+---+-----------+
Georgescu Expires September 22, 2016 [Page 28]
Internet-Draft IPv6 Trans Tech Threat Model March 2016
| 6 | IETF-TDB | Port set | | | | | H | | Address |
| | -NAT44-9 | exaustion | | | | | | | -Dependent|
| | [rfc7957] | | | | | | | | Filtering |
+---+-----------------+-----------+---+---+---+---+---+---+-----------+
Table10. Routing Technologies Threats
+---+-----------+----------------+---+---+---+---+---+---+------------+
| | ThreatID | Description | S | T | R | I | D | E | Mitigation |
+---+-----------+----------------+---+---+---+---+---+---+------------+
| 1 | IETF-TDB | simple | L | L | L | L | L | L | crypto |
| x | -RIPv2-1 | password | | | | | | | authen |
| | [RFC4822] | authen | | | | | | | |
+---+-----------+----------------+---+---+---+---+---+---+------------+
| 2 | IETF-TDB | simple | L | L | L | L | L | L | crypto |
| x | -OSPFv2-1 | password | | | | | | | authen |
| | [RFC2328] | authen | | | | | | | |
+---+-----------+----------------+---+---+---+---+---+---+------------+
| 3 | IETF-TDB | OSPFv2 | L | L | L | L | L | L | crypto |
| x | -OSPFv2-2 | authen | | | | | | | sequence |
| | [RFC2328] | sequence | | | | | | | number |
| | | number | | | | | | | |
| | | prediction | | | | | | | |
+---+-----------+----------------+---+---+---+---+---+---+------------+
| 4 | IETF-TDB | OSPFv3 | L | L | L | L | L | L | no |
| | -OSPFv3-1 | using the | | | | | | | manual |
| | [RFC4552] | same | | | | | | | keys |
| | | manual | | | | | | | |
| | | key | | | | | | | |
+---+-----------+----------------+---+---+---+---+---+---+------------+
| Legend | |
+---------------+-----------------------------------------------------+
| H | associaced with | | L | associaced with |
| | High likelihood | | | Low likelihood |
+---+----------------------------+-------+---+------------------------+
Author's Address
Marius Georgescu (editor)
NAIST
Takayama 8916-5
Nara 630-0192
Japan
Phone: +81 743 72 5216
Email: liviumarius-g@is.naist.jp
URI: http://www.ipv6net.ro
Georgescu Expires September 22, 2016 [Page 29]
