]> NAIST

Takayama 8916-5 Nara 630-0192 Japan +81 743 72 5216 liviumarius-g@is.naist.jp http://www.ipv6net.ro

General Internet Engineering Task Force template 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.

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 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. ). However, more structured threat modeling has proved useful for understanding the security of intricate systems. Structured approaches allows 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 .

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.

Table 1 presents the generic categories described in and some sample IPv6 transition technologies specified by the IETF.

To build a threat model for IPv6 transition technologies a series of steps is recommended. The steps were inspired by the threat modelling approach described in . These steps are detailed in the following subsections.

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.

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.

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.

Data in transit 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

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.

Table2. DFD-STRIDE Associations | | > | > | | +----+---+---+---+---+---+ | # | External entity | +----+-------------------+ | O | Process | +----+-------------------+ | = | Data store | +----+-------------------+ | > | Data flow | +----+-------------------+ ]]>

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.

Each discovered threat should be documented using the format presented in Table 3.

Table2. Threat Info Format

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.

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.

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.

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.

Since we are targeting the generic category itself, the step is unnecessary here. This stands for the other three categories as well.

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.

| 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. 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.

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 -H| |>-H|>-H| | +----+---+---+---+---+---+ | # | Customer device | +----+-------------------+ | O | DS node | +----+-------------------+ | = |Provider data store| +----+-------------------+ | > | Data flow | +----+-------------------+ ]]>

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.

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 (Table 10) 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 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

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.

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 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.

Attacker | || || +---+^-----+ || || || || || ___ || __ +--v-------+ || ( ,' `. || ,' `. ) =========== | Win8 +-+|--(---->+ amap +-+|->+ amap +-----)-----> Ubuntu | Host <--+--(-----+\ CE /<--+--+\ BR /<-----)-----+ Server +----------+ ( `+-+' IPvY `+-+' IPvX ) =========== E P E P E P E P ]]> Figure 3. Pentestbed Setup

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.

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.

| 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

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.

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.

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.

| 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

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 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].

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.

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.

| 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

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.

The author would like to thank Fernando Gont for his review and useful suggestions. This document was derrived from a template contributed by the xml2rfc project.

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 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.

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: Identify the function Associate the technology with a generic category (if any) Decompose the technology Identify the threats Review, repeat and validate

&RFC2119; &RFC4942; &RFC2328; &RFC2629; &RFC3552; &RFC3756; &RFC3971; &RFC4213; &RFC4443; &RFC4552; &RFC4822; &RFC5226; &RFC5569; &RFC6052; &RFC6145; &RFC6146; &RFC6219; &RFC6274; &RFC6333; &RFC6877; &RFC7596; &RFC7597; &RFC7599; Dept. of Computing, Lancaster University, UK ITU-T

Table5. L2 Technologies Threats

Table6. IPv4 Protocol Suite Threats

Table7. IPv6 Protocol Suite Threats

Table8. Basic Transition Technologies Threats

Table9. L4 Technologies Threats

Table10. Routing Technologies Threats