The STRIDE towards IPv6: A Threat Model for IPv6 Transition Technologies
draft-georgescu-opsec-ipv6-trans-tech-threat-model-01

Versions: 00 01                                                         
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]